... "GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 ...

Using Iptables

The quickest method of making sure it never reaches your webserver (and thus wasting resources like processor, disk space [log files], etc) is to use iptables, and it can be done with a one-liner like this:

iptables -I INPUT -d xxx.xxx.xxx.xxx -p tcp --dport 80 -m string --to 70  --algo bm --string 'GET /w00tw00t.at.ISC.SANS.' -j DROP

Simply replace xxx.xxx.xxx.xxx with the IP of your web server. If you want to use this for a range of IPs (ie., you’re using multiple IPs to host web servers), simply replace the “-d xxx.xxx.xxx.xxx” portion with:

-m iprange --dst-range start.xxx.xxx.xxx-end.xxx.xxx.xxx

where start.xxx.xxx.xxx and end.xxx.xxx.xxx are the first and last IPs of your web servers respectively.

If you wish to have a fancier option, one where it will for example blacklist an IP for a certain period, etc., have a look at SpamCle@ner’s website.

They go deeper into this subject and have provided two scripts near the end of their article. Simply save one of these scripts in a file named, for example, /opt/blockw00t.sh and make it executable with:

chmod +x /opt/blockw00t.sh

You can run it manually with typing “/opt/blockwoot.sh” in the shell or to automatically load it at boot time you can add it to your /etc/rc.local file, or on Debian/Ubuntu systems add it to your /etc/network/interfaces like so:

auto eth0

inet eth0 static

   ... [existing configuration that remains unaltered] ...

   # Load anti-w00t script:

   post-up /opt/blockw00t.sh

Using Fail2Ban

If you are using Fail2Ban, like described in the Shorewall firewall configuration, you can create a new definition that scans for the w00tw00t entries in the webserver log files.

The following definition assumes your webserver log entries look like the following (Nginx and Apache 2):

203.127.11.214 - - [15/Jul/2010:15:50:04 +0200] "GET /w00tw00t.at.ISC.SANS.test0:) HTTP/1.1" 400 173 "-" "-"

Create a file /etc/fail2ban/filter.d/webserver-w00tw00t.conf:

[Definition]

failregex = ^<HOST> .*"GET \/w00tw00t\.at\.ISC\.SANS\..+\:\).*?"



ignoreregex =

This catches the known variants of the scanner, including “DFind”, “test0″, “MSlog” and “ntsvc”.

Note: The <HOST> portion is specific to fail2ban and is a shorthand for the regex (?:::f{4,6}:)?(?P<host>\S+), which matches either an IPv4 or IPv6 address. See the fail2ban manual for more details.

*Tip: If you wish to change the regular expression, I recommend RegExr to play with various options/search criteria. It’s a time saver and free :)

*Tip 2: To test your definition’s regular expression, use:

fail2ban-regex logfile /etc/fail2ban/filter.d/webserver-w00tw00t.conf

Where logfile is the actual log file name, such as /var/log/apache2/access.log.

Add this definition to the fail2ban Jail configuration (/etc/fail2ban/jail.conf):

... [existing configuration] ...



[webserver-w00tw00t]

enabled  = true

port     = http,https

filter   = webserver-w00tw00t

# !!! Keep in mind to specify the correct web server log here:

logpath  = /var/log/apache2/access.log

maxretry = 1

# Time in seconds, in this case, one day:

bantime  = 86400

Now reload the service (ie., “/etc/init.d/fail2ban reload” or “service fail2ban reload”).

Related posts:

1. Guide: Firewall and router with Proxmox – Extending its use
2. Guide: Firewall and router with Proxmox

My previous Nginx configuration became a nightmare to maintain and WordPress had become slower because Apache’s children were being killed by OOM. This was due to a  misguided PHP cache (PHP XCache to be precise) that decided to take every available bit of memory from my system, despite having max-requests per child set low (before it was purged).

This, along with my endeavors in seeking the fastest solution to everything and the introduction of a new Cloud servers by OVH, lead me to today’s article.

Which is faster – Varnish or Nginx?

The first thing I wanted to do is make all the caching happen before things get pushed through to Apache. This because I wanted to eliminate both PHP XCache and the WordPress Super Cache plugin I was using, so to increase WordPress compatibility but decrease complexity.

At first I thought about using Varnish – either as a the sole front-end, or in between Nginx and Apache (the reasoning later). Also, I had gotten my hands on OVH’s Cloud servers whilst they were still in “alpha”, and used this as the base system for building a pool of web servers.

The following tests have all been performed on those Cloud servers – mC 256 (256 MBytes of guaranteed RAM, 2 GByte total memory with excess swapped to SSD’s), 4 CPU cores and 5 GBytes of storage space. The OS is Ubuntu 10.04 LTS. The output of /proc/cpuinfo is as following (x4 for briefness):

processor       : 0

vendor_id       : GenuineIntel

cpu family      : 6

model           : 26

model name      : Intel(R) Xeon(R) CPU           E5504  @ 2.00GHz

stepping        : 5

cpu MHz         : 1995.000

cache size      : 4096 KB

fdiv_bug        : no

hlt_bug         : no

f00f_bug        : no

coma_bug        : no

fpu             : yes

fpu_exception   : yes

cpuid level     : 11

wp              : yes

flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss nx rdtscp lm constant_tsc arch_perfmon pebs bts xtopology tsc_reliable nonstop_tsc aperfmperf pni ssse3 cx16 sse4_1 sse4_2 popcnt hypervisor lahf_lm

bogomips        : 3990.00

clflush size    : 64

cache_alignment : 64

address sizes   : 40 bits physical, 48 bits virtual

power management:

Concurrency Level:      100

Time taken for tests:   29.548 seconds

Complete requests:      100000

Failed requests:        0

Write errors:           0

Total transferred:      25009500 bytes

HTML transferred:       3901482 bytes

Requests per second:    3384.27 [#/sec] (mean)

Time per request:       29.548 [ms] (mean)

Time per request:       0.295 [ms] (mean, across all concurrent requests)

Transfer rate:          826.55 [Kbytes/sec] received



Connection Times (ms)

              min  mean[+/-sd] median   max

Connect:        0   12  39.1     12    1960

Processing:     9   18  49.6     14    2036

Waiting:        1   15  45.9     12    1966

Total:         14   29  65.9     26    2159

Concurrency Level:      100

Time taken for tests:   13.489 seconds

Complete requests:      100000

Failed requests:        0

Write errors:           0

Total transferred:      28315282 bytes

HTML transferred:       1100594 bytes

Requests per second:    7413.64 [#/sec] (mean)

Time per request:       13.489 [ms] (mean)

Time per request:       0.135 [ms] (mean, across all concurrent requests)

Transfer rate:          2049.99 [Kbytes/sec] received



Connection Times (ms)

              min  mean[+/-sd] median   max

Connect:        0    6   2.2      6      71

Processing:     2    7   1.9      7      70

Waiting:        1    6   2.0      5      66

Total:          3   13   3.1     13      81

Concurrency Level:      100

Time taken for tests:   9.438 seconds

Complete requests:      100000

Failed requests:        0

Write errors:           0

Total transferred:      27706648 bytes

HTML transferred:       5201248 bytes

Requests per second:    10595.55 [#/sec] (mean)

Time per request:       9.438 [ms] (mean)

Time per request:       0.094 [ms] (mean, across all concurrent requests)

Transfer rate:          2866.87 [Kbytes/sec] received



Connection Times (ms)

              min  mean[+/-sd] median   max

Connect:        0    4   1.0      4      56

Processing:     2    6   9.7      5     253

Waiting:        0    5   9.7      5     253

Total:          5    9   9.7      9     257

ulimit -n 65535

apt-get install nginx libapache2-mod-php5 memcached \

php5-mysql php5-curl php5-gd php5-idn php-pear php5-imagick \

php5-imap php5-mcrypt php5-memcache php5-mhash php5-ming \

php5-ps php5-pspell php5-recode php5-snmp php5-sqlite \

php5-tidy php5-xmlrpc php5-xsl php5-json

# apt-get install libc6 libpcre3 libpcre3-dev libpcrecpp0 libssl0.9.8 libssl-dev zlib1g zlib1g-dev lsb-base

wget http://www.nginx.org/download/nginx-0.7.67.tar.gz

tar -xf nginx-0.7.67.tar.gz

cd nginx-0.7.67

./configure \

--user=www-data \

--group=www-data \

--sbin-path=/usr/sbin \

--conf-path=/etc/nginx/nginx.conf \

--error-log-path=/var/log/nginx/error.log \

--pid-path=/var/run/nginx.pid \

--lock-path=/var/lock/nginx.lock \

--http-log-path=/var/log/nginx/access.log \

--http-client-body-temp-path=/var/lib/nginx/body \

--http-proxy-temp-path=/var/lib/nginx/proxy \

--http-fastcgi-temp-path=/var/lib/nginx/fastcgi \

--with-debug \

--with-http_stub_status_module \

--with-http_flv_module \

--with-http_ssl_module \

--with-http_dav_module \

--with-http_gzip_static_module \

--with-http_realip_module \

--with-mail \

--with-mail_ssl_module \

--with-ipv6

make && make install

NameVirtualHost *:8080

Listen 127.0.0.1:8080

<VirtualHost *:8080>

... etc ...

</VirtualHost>

mkdir /etc/nginx/includes

mkdir -p /var/cache/nginx/tmp

mkdir /var/cache/nginx/cached

chown -R www-data:www-data /var/cache/nginx

user                    www-data;



worker_processes        4;

worker_rlimit_nofile    16384;



error_log               /var/log/nginx/error.log;

pid                     /var/run/nginx.pid;



events {

        worker_connections  2000;

}



http {

        include                 /etc/nginx/mime.types;

        default_type            application/octet-stream;



        access_log              /var/log/nginx/access.log;



        sendfile                on;

        tcp_nopush              on;

        tcp_nodelay             on;

        keepalive_timeout       75 20;



        gzip                    on;

        gzip_vary               on;

        gzip_comp_level         3;

        gzip_min_length         4096;

        gzip_proxied            any;

        gzip_types              text/plain text/css application/x-javascript text/xml

                                application/xml application/xml+rss text/javascript;



        include                 /etc/nginx/conf.d/*.conf;

        include                 /etc/nginx/sites-enabled/*;

}

proxy_redirect                  off;



proxy_set_header                Host $host;

proxy_set_header                X-Forwarded-For $proxy_add_x_forwarded_for;



proxy_connect_timeout           90;

proxy_send_timeout              90;

proxy_read_timeout              90;



proxy_buffer_size               4k;

proxy_buffers                   4 32k;

proxy_busy_buffers_size         64k;

proxy_temp_file_write_size      64k;



proxy_max_temp_file_size        56m;

proxy_temp_path                 /var/cache/nginx/tmp;

proxy_cache_key                 $scheme$host$request_uri;

proxy_cache_path                /var/cache/nginx/cached levels=2:2 keys_zone=global:64m inactive=60m max_size=1G;



proxy_cache_valid               200 302 30m;

proxy_cache_valid               301 1h;

proxy_cache_valid               404 1m;



proxy_cache_use_stale           error timeout http_500 http_502 http_503 http_504;



proxy_pass_header               Set-Cookie;

if ($http_cookie ~* "comment_author_|wordpress_(?!test_cookie)|wp-postpass_") {

    set $no_cache 1;

}



if ($http_user_agent ~* "(2\.0 MMP|240x320|400X240|AvantGo|BlackBerry|Blazer|Cellphone|Danger|DoCoMo|Elaine\/3\.0|EudoraWeb|Googlebot-Mobile|hiptop|IEMobile|KYOCERA\/WX310K|LG\/U990|MIDP-2\.|MMEF20|MOT-V|NetFront|Newt|Nintendo Wii|Nitro|Nokia|Opera Mini|Palm|PlayStation Portable|portalmmm|Proxinet|ProxiNet|SHARP-TQ-GX10|SHG-i900|Small|SonyEricsson|Symbian OS|SymbianOS|TS21i-10|UP\.Browser|UP\.Link|webOS|Windows CE|WinWAP|YahooSeeker\/M1A1-R2D2|NF-Browser|iPhone|iPod|Android|BlackBerry9530|G-TU915 Obigo|LGE VX|webOS|Nokia5800)" ) {

    set $no_cache 1;

}



proxy_no_cache      $no_cache;

# Enable caching:

proxy_cache     global;



# Default:

location / {

        proxy_pass              http://127.0.0.1:8080;

}



# Rarely changed items can remain cached longer:

location ~* \.(jpg|jpeg|png|gif|ico|css|mp3|wav|swf|mov|doc|pdf|xls|ppt|docx|pptx|xlsx)$ {

        proxy_cache_valid       200 3h;

        proxy_pass              http://127.0.0.1:8080;

}



# Deny access to .ht* files:

location ~ /\.ht {

        deny                    all;

}

server {

        listen          80;

        server_name     _;



        root            /var/www/sites/default/public;

        index           index.html index.htm;



        access_log      /var/www/sites/default/logs/access.log;

        error_log       /var/www/sites/default/logs/nginx.error.log;



        # Includes:

        include         /etc/nginx/includes/wordpress.inc;

    include         /etc/nginx/includes/default_proxy.inc;

}

Concurrency Level:      100

Time taken for tests:   6.694 seconds

Complete requests:      50000

Failed requests:        0

Write errors:           0

Keep-Alive requests:    0

Total transferred:      2822197200 bytes

HTML transferred:       2806393092 bytes

Requests per second:    7469.02 [#/sec] (mean)

Time per request:       13.389 [ms] (mean)

Time per request:       0.134 [ms] (mean, across all concurrent requests)

Transfer rate:          411700.31 [Kbytes/sec] received



Connection Times (ms)

              min  mean[+/-sd] median   max

Connect:        0    2   0.4      2      16

Processing:     3   11   0.8     11      27

Waiting:        1    3   1.2      3      25

Total:          6   13   0.8     13      32

Related posts:

1. NginX and Apache, but no memcached
2. Faster WP Super Cache with NginX
3. Compiling NginX on Debian / Ubuntu

Proxy ARP

The most common question is in regards to proxy ARP. Enabling this option will allow you to assign a public IP directly to your guest VM, eliminating the need for port forwarding (DNAT) or having to worry about the MAC address.

As an example use for proxy ARP, it is helpful for those using a a SIP-based VoIP server since a STUN server is no longer required.

Enabling Proxy ARP

The first step is to ensure that Proxy ARP is enabled.  This is a fairly simple task and involves adding an single line to one of your static network stanzas. Which one precisely depends on your system setup; for those who have an eth0 stanza, you can use it there. For others who only have a vmbr0..n stanza, the additional line should be placed there.

iface eth0 inet static

    # ... existing lines ...

    post-up echo 1 > /proc/sys/net/ipv4/conf/all/proxy_arp

These changes will take effect on your next boot or whenever you restart your networking services.

Add a route to Shorewall

Shorewall needs to know that you’d like to use proxy ARP, for which IP that is and where this IP needs to be routed to. The beauty of Shorewall is its simplicity and so this can be quickly done by creating a file named /etc/shorewall/proxyarp that will contain this:

#ADDRESS    INTERFACE    EXTERNAL    HAVEROUTE    PERSISTENT

92.22.33.44 vmbr0        eth0

Translated, this informs Shorewall that the public IP 92.22.33.44 attached to eth0 needs to be forwarded to a guest VM (using this public IP) attached to the vmbr0 bridge.

As you can tell from the first line, there are two additional options: haveroute and persistent.

The haveroute option determines whether Shorewall should create a route from the external interface to the bridge. For guest containers based on OpenVZ, Proxmox will take of creating the route. But for fully virtualised containers (based on KVM), you need to create this route yourself. In this case we tell Shorewall to create the route for us, by keep this option’s value at its default value (blank, or No).

When the haveroute option is set to No (default), the persistent option tells Shorewall if it should keep the created route active if Shorewall is stopped. Generally, and for security reasons, you should leave this at its default option (blank or No). This prevents the guest VM from being exposed without a firewall protecting it.

Creating Shorewall rules

In the original guide all traffic from the public side to internal VMs is blocked. This continues to be the same when you are using proxy ARP and thus need to create rules that permit traffic to certain ports. This can be done by adding rules like:

ACCEPT    net    dmz:92.22.33.44    udp    5060

This will permit UDP traffic on port 5060 to proceed to the guest VM on IP 92.22.33.44. You can also use the Shorewall macros, for example:

HTTP/ACCEPT    net     dmz:92.22.33.44

And in this case it will make a web server on 92.22.33.44 accessible to the public.

Alternatively, you may setup a single rule that accepts all traffic on all ports:

ACCEPT    net     dmz:92.22.33.44

However you should take care that the guest VM has its own set of rules to block unwanted or unsafe traffic.

The main thing to take care of with these proxy ARP firewall rules is to use “ACCEPT” and not “DNAT” as explained in the original guide.

Multiple public IPs

Another common question is in regards to multiple public IP addresses. The original guide assumed that the host has one public IP address, so here are a few additional pointers.

If you are following the original guide, then any public IP will be applied the same rule. So let’s say you have two public IP addresses, 94.11.22.33 and 94.22.33.44 and the following rule:

ACCEPT    net    fw    tcp    5900:5999

With this rule, you can use both 93.11.22.33:5900 or 94.22.33.44:5900 to connect to Proxmox’s VNC. But you wish to restrict it to a specific IP address, then you need to modify the rule as following:

ACCEPT    net   fw:94.22.33.44    tcp    5900:5999

Now you can only use 94.22.33.44:5900 to connect, but not 93.11.22.33:5900.

The same applies to port forwarding (DNAT) rules, which is written in a slightly different format. Let’s say we have this rule:

DNAT    net    dmz:10.0.0.1    tcp    1234

This will forward any public IP to port 1234 on the guest VM at 10.0.0.1. So both 94.11.22.33:1234 and 94.22.33.44:1234 will work. If you wish to restrict this to a certain public IP address, the rule needs to be modified as following:

DNAT    net    dmz:10.0.0.1    tcp    1234    -    94.22.33.44

Only 94.22.33.44:1234 will be allowed at this point.

Memorable names

If you have many IP addresses, it becomes easy to forget which IP to use. You can use Shorewall’s “params” file to give IPs a memorable name. Edit the file /etc/shorewall/params as following:

IP_ALEX=94.11.22.33

IP_SONIA=94.22.33.44

IP_ERIC=94.33.44.55

IP_VM1=10.0.0.1

IP_VM2=10.0.0.2

IP_VM3=10.0.0.3

Now you can use these names instead of the IP address in any of your Shorwall rules, like so:

HTTP/DNAT    net     dmz:$IP_VM1    -    -    -    $IP_SONIA

And this would forward HTTP traffic from 94.22.33.44 to a guest VM running on 10.0.0.1.

Mixed use and bridging

The original guide not only adds a firewall, but also helped those who’s hosting provided blocked IPs on unauthorized MACs. One such hosting provided was OVH, and they have recently introduced a “Virtual MACs for VPS” option that allows you to assign an IP address to a MAC. This eliminates the need for Proxy ARP or port forwarding/NAT, however the original guide will still prove itself useful for protecting the host.

I will provide a sample setup below, which can be modified to suit your needs and network configuration. This assumes you have have a basic understanding of networking and read my previous guide.

Interfaces

We modify the /etc/network/interfaces as following:

# The loopback network interface

auto lo

iface lo inet loopback



# Public Network. Make sure to only use MACs that were assigned to you

auto vmbr0

iface vmbr0 inet static

 # The following settings are specific to your hosting provider:

 address 94.11.22.33

 netmask 255.255.255.0

 network 94.11.22.0

 broadcast 94.11.22.255

 gateway 94.11.22.254

 # The following assumes eth0 is the public-side NIC, the remained is always the same

 bridge_ports eth0

 bridge_stp off

 bridge_fd



# Optional Private Network. This network cannot be access directly from the public side

auto vmbr1

iface vmbr1 inet auto

 address 10.0.0.1

 network 255.0.0.0

 broadcast 10.255.255.25

 bridge_ports none

 bridge_stp off

 bridge_fd 0

The host, accessible by 94.11.22.33, will have two bridges at this point: vmbr0 serving the public-side and vmbr1 serving inter-VM communication.

To assign a public IP address to a KVM, you use the vmbr0 bride and must ensure the MAC corresponds to the one provided by your hosting provider (if a MAC restriction is in place).

You can also add a 2nd NIC (or as the only NIC) to the KVM, which is bridged with vmbr1. In this case, you need to use an IP within the 10.0.0.2-10.255.255.254 range, and as gateway 10.0.0.1. This particular IP range can only be used between other VMs on the same host / bridge, unless you use port forwarding or a VPN on the same IP range.

Shorewall Interfaces and Zones

The basic /etc/shorewall/interfaces will be:

#ZONE    INTERFACE    BROADCAST    OPTIONS

pub    vmbr0        detect        routeback,bridge

loc    vmbr1        detect        routeback,bridge



#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE

You could also add the blacklist option, or any of the other possible Shorewall options if you wish.

The accompanying /etc/shorewall/zones will look like this:

#ZONE    TYPE        OPTIONS        IN            OUT

#                    OPTIONS            OPTIONS

fw    firewall

pub    ipv4

loc    ipv4



#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE

You now have three distinct Shorewall zones. The fw zone is a self-reference to the host (in our sample setup 94.11.22.33 and 10.0.0.1). The pub zone represents the publicly accessible vmbr0 bridge and loc our internal vmbr1 bridge.

Shorewall Policy

The following policy defines these basic rules:

• Traffic from the the host anywhere else is permitted
• Traffic from the public side to the host and the internal network is denied
• Traffic from the internal side to the host is denied, anywhere else is permitted

Edit /etc/shorewall/policy:

#SOURCE    DEST    POLICY        LOG    LIMIT:        CONNLIMIT:

#                    LEVEL    BURST        MASK



# From Firewall:

fw        fw    ACCEPT

fw        pub    ACCEPT

fw        loc    ACCEPT



# Public Bridge (read the policy warnings!):

pub        pub    ACCEPT

pub        loc    ACCEPT

pub        fw    DROP        info



# Local (internal) Bridge:

loc        loc    ACCEPT

loc        pub    ACCEPT

loc        fw    DROP        info



# THE FOLLOWING POLICY MUST BE LAST

#

all    all    REJECT        info



#LAST LINE -- DO NOT REMOVE

Policy Warnings

With this sample policy it means that each publicly accessible guest VM should have its own firewall. If you wish to change this behavior, and let Shorewall handle the firewall for each such guest VM, then change the Public Bridge section:

pub        pub    DROP      info

You then need to create specific rules that allow traffic to VMs on vmbr0.

A similar warning applies to traffic from vmbr0 to vmbr1. The policy assumes that vmbr0 does not receive any routable traffic on a private IP range (also called “martians”). Although this is often the case, it depends on the hosting provider’s internal networking. If you are not sure whether there’s routable traffic on a private IP range from the public side, you have two options. The first is to disallow all traffic from vmbr0 (pub) to vmbr1 (loc) by editing the Public Bridge section:

pub        loc    DROP      info

The alternative is to have a set of rules in /etc/shorewall/rules like so:

# ...

SECTION NEW



# Leave these at the top, right after "SECTION NEW"!

DROP        pub:10.0.0.0/8        all

DROP        pub:192.168.0.0/16    all

DROP        pub:172.168.0.0/12    all



# ... Other rules follow ...



#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE

In all cases, you should verify whether traffic is truly blocked and never assume that it is!

Shorewall and Fail2ban

Fail2ban in its own words “scans log files like /var/log/pwdfail or /var/log/apache/error_log and bans IP that makes too many password failures. It updates firewall rules to reject the IP address”. This can for instance be used to (temporarily) ban a bot that is attempting a brute-force entry through SSH.

Fail2ban is an ideal companion to Shorewall and can be installed in a matter of minutes on a Proxmox host. You start by installing Fail2ban from the Debian packages:

apt-get install fail2ban

Configure Shorewall

Next you need to edit one line in the Shorewall configuration file, located at /etc/shorewall/shorewall.conf:

BLACKLISTNEWONLY=No

That’s all you need to configure in Shorewall. Remember to apply your settings by restarting Shorewall with the command “shorewall restart”.

Configure Fail2ban

The last step is to configure Fail2ban. The file /etc/fail2ban/jail.conf is extensively documented and of particular interest are the following settings:

...

#

# Destination email address used solely for the interpolations in

# jail.{conf,local} configuration files.

destemail = myemail@address.com



...

#

# ACTIONS

#



# Default banning action (e.g. iptables, iptables-new,

# iptables-multiport, shorewall, etc) It is used to define

# action_* variables. Can be overriden globally or per

# section within jail.local file

banaction = shorewall



...

# Choose default action.  To change, just override value of 'action' with the

# interpolation to the chosen action shortcut (e.g.  action_mw, action_mwl, etc$

# globally (section [DEFAULT]) or per specific section

action = %(action_mwl)s

Inform fail2ban of these changes by issuing the following command:

fail2ban-client reload

The destemail variable should be changed to your own e-mail address, where you will be informed of any ban actions. The banaction variable specifies that Shorewall should be used to block possible intruders. And finally, the action variable tells fail2ban to ban any detected intruder and then send an you a detailed e-mail with the relevant log lines (that caused the ban). Following is an example of an actual e-mail:

Hi,



The IP 193.86.5.103 has just been banned by Fail2Ban after

3 attempts against ssh.



Here are more information about 193.86.5.103:



% This is the RIPE Database query service.

% The objects are in RPSL format.

%

% The RIPE Database is subject to Terms and Conditions.

% See <a class="moz-txt-link-freetext" href="http://www.ripe.net/db/support/db-terms-conditions.pdf">http://www.ripe.net/db/support/db-terms-conditions.pdf</a>



% Note: This output has been filtered.

%       To receive output for a database update, use the "-B" flag.



% Information related to '193.86.4.0 - 193.86.5.255'



inetnum:      193.86.4.0 - 193.86.5.255

netname:      BRANO

descr:        BRANO, Inc.

descr:        Hradec nad Moravici

country:      CZ

admin-c:      BK230-RIPE

tech-c:       TP231-RIPE

status:       ASSIGNED PA

mnt-by:       GTSCZ-MNT

source:       RIPE # Filtered



person:       Bohumil Kriz

address:      BRANO, Inc.

address:      Computer Centre

address:      Hradec nad Moravici

address:      747 41

address:      The Czech Republic

phone:        +420 653 918118

fax-no:       +420 653 911791

nic-hdl:      BK230-RIPE

source:       RIPE # Filtered



person:       Tomas Partl

address:      Brano, Inc.

address:      Computer Centre

address:      Hradec nad Moravici

address:      747 41

address:      The Czech Republic

phone:        +420 653 918371

fax-no:       +420 653 911791

nic-hdl:      TP231-RIPE

source:       RIPE # Filtered



% Information related to '193.86.0.0/16AS2819'



route:        193.86.0.0/16

descr:        CZNET-A

origin:       AS2819

mnt-by:       GTSCZ-A-MNT

source:       RIPE # Filtered



Lines containing IP:193.86.5.103 in /var/log/auth.log



Feb 27 03:32:02 host sshd[21460]: Failed password for root from 193.86.5.103 port 35833 ssh2

Feb 27 03:32:04 host sshd[21502]: Failed password for root from 193.86.5.103 port 36302 ssh2

Feb 27 03:32:06 host sshd[21504]: Failed password for root from 193.86.5.103 port 36719 ssh2



Regards,



Fail2Ban

By default fail2ban is configured to monitor SSH, which for a Proxmox host works without any additional changes. Personally I prefer a ban on 3 attempts instead of the default 6, so I have made this one change in the /etc/fail2ban/jail.conf file:

[ssh]

maxretry = 3

But again, the configuration file is quite well documented, so any personal preferences or modifications should be easy to accomplish.

“Online Hoodies” photo by gwire, CC Attribution License

Hi,

The IP 193.86.5.103 has just been banned by Fail2Ban after
3 attempts against ssh.

Here are more information about 193.86.5.103:

% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf

% Note: This output has been filtered.
%       To receive output for a database update, use the "-B" flag.

% Information related to '193.86.4.0 - 193.86.5.255'

inetnum:      193.86.4.0 - 193.86.5.255
netname:      BRANO
descr:        BRANO, Inc.
descr:        Hradec nad Moravici
country:      CZ
admin-c:      BK230-RIPE
tech-c:       TP231-RIPE
status:       ASSIGNED PA
mnt-by:       GTSCZ-MNT
source:       RIPE # Filtered

person:       Bohumil Kriz
address:      BRANO, Inc.
address:      Computer Centre
address:      Hradec nad Moravici
address:      747 41
address:      The Czech Republic
phone:        +420 653 918118
fax-no:       +420 653 911791
nic-hdl:      BK230-RIPE
source:       RIPE # Filtered

person:       Tomas Partl
address:      Brano, Inc.
address:      Computer Centre
address:      Hradec nad Moravici
address:      747 41
address:      The Czech Republic
phone:        +420 653 918371
fax-no:       +420 653 911791
nic-hdl:      TP231-RIPE
source:       RIPE # Filtered

% Information related to '193.86.0.0/16AS2819'

route:        193.86.0.0/16
descr:        CZNET-A
origin:       AS2819
mnt-by:       GTSCZ-A-MNT
source:       RIPE # Filtered

Lines containing IP:193.86.5.103 in /var/log/auth.log

Feb 27 03:32:02 host sshd[21460]: Failed password for root from 193.86.5.103 port 35833 ssh2
Feb 27 03:32:04 host sshd[21502]: Failed password for root from 193.86.5.103 port 36302 ssh2
Feb 27 03:32:06 host sshd[21504]: Failed password for root from 193.86.5.103 port 36719 ssh2

Regards,

Fail2Ban

Related posts:

1. Guide: Firewall and router with Proxmox
2. Blocking w00tw00t scans
3. Guide: Installing OpenSolaris on a remote dedicated server

Changes

• A new option has been introduced to hide the license and attribution information in the footer.
• Bug fix: Config hash file was never initialized
• Bug fix: Enabling “cacheable” option resulted in fatal PHP errors in some cases
• Bug fix: Preview option did not work when “cacheable” option was enabled
• Bug fix: “All Rights Reseved” licenses had no URLs

In addition, WP Flickr Background is no longer compatible with WordPress version 2.8 or older.

Links: Direct download WP Flickr Background (192) | WordPress Plugin Directory

Related posts:

1. WP Flickr Background version 1.0.2 (Beta) available
2. WP Flickr Background
3. WP Flickr Background in Alpha testing

My biggest concern is that a fraudster will simply replace the account information to one he owns him or herself. Because it is such a hot topic on Twitter at the moment, this altered message would make its rounds quickly.

I was able to trace the original message back to @CruzRojainforma, the Chilean Red Cross. So far the retweeted message hasn’t been altered – other than being translated into English. But I’ve urged people to stop retweeting the account details and visit the official Red Cross website at www.redcross.org instead. There’s a link right on their main page that explains how you can donate time or money to the Chilean earthquake efforts.

On a final note, Twitter is also used to find missing persons. And with positive results I may add, as this article explains. Google also has a Person Finder database running, which it had done for te Haiiti earthquake as well. But please ensure that you do not give out too much personal details about the person you’re looking for, because it becomes a (nearly) permanent part of the Internet.

Again, the intentions are good, but there are too many people out there waiting to take advantage of every possible situation so be careful!

Fuerza Chile!

Related posts:

1. Hawaii Tsunami, Sprecks image gallery
2. Add hashtags support to WordTwit
3. Lifestream for March 2nd

While the actual waves were thankfully less high than expected, you do notice two distinct surges in the images. The view here is of the Sprecks towards the West Maui mountains.

Here’s a video which will give a better idea of what it looked like on the ground:

I have another set (with a smoother timeline) from a different location as well, which may add soon as well. A few images from that set stood out and I will share this one with you here:

Apparently this person wasn’t aware that there was a tsunami warning in effect and that you shouldn’t be on the beach, especially not making any phone calls.

Related posts:

1. Lifestream for March 1st

Satisfied with this, I’ve now made version 1.0.2 available as a Beta product. That means you can now use it for your own purposes, however I do not recommend using this in a production environment just yet (although nothing is stopping you from doing so – use at your own risk!).

The likely issues that I’m expecting are with the installation, plugin usage and the back-end (administration). But hopefully those will only be a few. In meantime, I will start the registration procedure with WordPress.org so that the code will be available in the SVN, and the plugin available for download / upgrade within WordPress itself. Hopefully this will be a matter of just a few days.

If you are running in any kind of issue, how small it may seem, I’d really like to know about it so I can improve the plugin. You can use the contact form, or leave a comment below and I will make note of it.

The static page for WP Flickr Background is http://www.myatus.co.uk/wp-flickr-background, and it will be updated with the latest version as it becomes available. You can also click on Downloads at the top.

Enjoy!

P.S.: A small update, WP Flickr Background is also available through the Flickr App Garden.

P.P.S.: Quicker than expected, WordPress has accepted the plugin into the Plugin Directory. If you wish to use the development version (provided you know what you are doing!), see the SVN.

Related posts:

1. WP Flickr Background version 1.0.3 (Beta) available
2. WP Flickr Background
3. WP Flickr Background in Alpha testing

All you need to do is create one or more galleries within the plugin’s settings, each containing a collection of photos from Flickr that you have chosen, and WP Flickr will randomly select a photo from the active gallery to display as the theme background.

You can also customise a gallery by adding CSS styling code that will be loaded along with the photo, allowing you to color match the WordPress theme to the particular photo displayed or for other use.

Links: Direct download: WP Flickr Background (192) | WordPress Plugin Directory

If you have an idea for WP Flickr Background or wish to report a bug, click the feedback tab shown on your left or visit UserVoice.

Related posts:

1. WP Flickr Background version 1.0.2 (Beta) available
2. WP Flickr Background version 1.0.3 (Beta) available
3. WP Flickr Background in Alpha testing

I had taken down the website to make some changes to the web server, which quickly became a major overhaul. I figured that since it was already down, I might as well do the things I had long planned.

A good portion of it is implemented now, but I’m not completely done. I’ll give it my best effort to ensure there will be little to no downtime. Once again, my apologies!

No related posts.

If you’re new to this website, you probably haven’t noticed. But the background you’re seeing is actually something new. And random. And streamed from Flickr. It’s a new plugin that I am developing for WordPress called ‘WP Flickr Background’.

A little over two weeks ago I changed my theme to Motion by 85ideas, and was intrigued by its effective use of transparencies and the background. And since I quickly get bored looking at the same thing, I thought ‘Why not make this background random’? Flickr provides millions of photos, many of them under a Creative Commons Attribution License, and this would be an excellent source for those random backgrounds. So I started coding…

Interestingly, it wasn’t as straight forward as one would expect. After all, you could simply use a dynamically generated CSS style sheet with a ‘background’ element pointing to a random Flickr photo. Right?

But small photos cascade and your website will look like a bad 1995 rendition of your first HTML page. And the large photos may be SO large, you end up staring at just a grain of sand instead of a beach.

CSS3, the brand-spanking new version of CSS style sheets, supports stretching of background images. Unfortunately, not a single browser I have tried supports it. So I reverted to good-old image hacking, basically injecting the background in a negative Z-indexed <div> block at a fixed position.

Yes, that last sentence is a great conversation breaker. But trust me, it is the injection portion that’s trickiest. For one, I do not like it when plugins require me to manually modify files, let alone modify files in the first place. So I assume there are other people out there who think alike. So how can I change a WordPress theme without actually modifying its files? Enter Javascript, jQuery to be specific, and we are on our way to great trickery!

So in the end, WP Flickr Background will use Javascript to add a new background image overlaid by the actual (original) contents. And it works! At least, it does so with Opera 10, Firefox 3, Google Chrome 3, MSIE 8 and Safari 4. Hence I am now putting the plugin through a public Alpha test, waiting for complaints to roll in: “Your website looks weird” and “I’m getting Javascript errors” are some of the things I am expecting to see during testing, but hopefully there will be none! You will let me know, right?

If I am satisfied that there are no major issues with the plugin, then I will make it available for download. In meantime, I will be re-arranging a few things on the website once again to make room for the new plugin and a few others I am thinking about writing. So please excuse construction going on in the next few days!

Related posts:

1. WP Flickr Background
2. WP Flickr Background version 1.0.2 (Beta) available
3. WP Flickr Background version 1.0.3 (Beta) available