... "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
3. Faster WP Super Cache with NginX

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

As you may have read in one of my previous blog entries, specifically “NginX and Apache, but no memcached”, I prefer to use NginX as the front-end serving static files, and Apache as a back-end dealing with the dynamic pages. So it would be ideal if NginX could serve up static WordPress files, which is exactly what I am doing now with the help of WP Super Cache.

WP Super Cache is a rather popular plugin and converts the output generated by WordPress into a static HTML file. Installation is quick and painless, and automates a few tasks for you (or lets you know what needs to be changed on your website).

To make it work with a NginX front-end and Apache back-end, a few additional changes need to be made, primarily to the NginX configuration.

WordPress / Apache Changes

Firstly, enable  WP Super Cache into the “full on” setting, meaning it generates a “cache” and a “super cache”. WP Super Cache will then ask you to change the .htaccess file, by adding a few Rewrite Rules. In this case, we do not need those entries and we can reduce it to just the following:

# BEGIN WPSuperCache

### WARNING: This is handled by NginX!

# END WPSuperCache

This will keep the plugin’s setting page from complaining about the need to configure .htaccess.

I have also enabled the “Super Cache Compression” option, however this is not mandatory. I choose to do this to relieve NginX from a few CPU cycles (as the HTML is already compressed then).

NginX Changes

Next the NginX website configuration needs to be modified. And a few of these modifications will depend on your website or needs. In my case, I  am using a separate template for the iPhone, Android and other smart phones and do not wish to use the cache for these. So I have the following entry in my NginX that will detect mobile phones:

server {



... (snip!) ...



        # Check if it's a mobile phone

        set $mobile "";

        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 $mobile "M";

        }



... (snip!) ...

This will set the variable $mobile to “M” if  the user-agent is from a mobile web browser. If you don’t need or want this, then you can simply leave it out of your NginX configuration.

We also need to modify the common location section. There are a number of ways to approach this, but I choose to use a number of “if” statements to build a variable $wpsc_flags. Depending on the list of “if” statements NginX will output the static cached file from WP Super Cache or continue to the Apache back-end (which will handle the rest).

Unfortunately NginX does not provide support for nested “if” statements or booleans, so this is a slightly dirty hack:

       location / {

                # If it's a POST request, send it directly backend:

                if ($request_method = POST) {

                        access_log      off;

                        proxy_pass      http://apache_backend;



                        break;

                }



                # Is it a mobile user?

                set $wpsc_flags "${mobile}";



                # Is the user logged in?

                if ($http_cookie ~* "(comment_author_|wordpress_logged_in_|wp-postpass_)" ) {

                        set $wpsc_flags "${wpsc_flags}C";

                }



                # Do we have query arguments?

                if ($is_args) {

                        set $wpsc_flags "${wpsc_flags}Q";

                }



                # Does the (gzip) Super Cache exist?

                if (-f $document_root/wp-content/cache/supercache/$host/$uri/index.html.gz) {

                        # The file exists in the WP Super Cache

                        set $wpsc_flags "${wpsc_flags}F";

                }



                # If the following flags are set (in this order) we use the cached version:

                if ($wpsc_flags = "F") {

                        expires         1h;

                        rewrite ^(.*)$ /wp-content/cache/supercache/$host/$uri/index.html.gz break;

                }



                # Or else it goes to the backend:

                access_log      off;

                proxy_pass      http://apache_backend;

        }

By reading the comments it should be clear what this does, but I’ll clarify further just in case.

A HTTP POST should not be cached, and so it will be sent directly to the Apache back-end server(s) and stops doing any other checking.

In the next step, it creates a $wpsc_flags variable based on the $mobile variable we created earlier. If you do not use the $mobile variable, then you can simply replace it as following:

set $wpsc_flags "";

Then it will add flags to $wpsc_flags depending on whether the current user is logged in, if the request contains arguments (ie.: “someurl.com?this=is&an=argument”). This will prevent an editor or commenter from being presented cached pages, which can be bothersome.

Now, as I had turned on the “Super Cache Compression” in the WordPress plugin, I am looking for files that end with “.html.gz”. If you are not using the compression option, simply remove the “.gz” from the “if (-f” statement as well as the “rewrite” statement.

Also note that it will only display the cached data if, and only if, $wpcs_flags is set to “F”. If you were logged in, this variable would actually be “CF” (in this order!) and so it will continue to the portion where everything is sent to the Apache back-end.

Speed Improvements

A while ago I had posted a message on a forum that showed how a WordPress cache could improve responsiveness. The (truncated) results of a simple “ab -n 1000 -c 50 http://<website>” (ApacheBench) showed the following back then:

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

Time per request:       28.521 [ms] (mean)

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

The cached responses were generated by Hyper Cache at the Apache back-end, then forwarded to NginX to be delivered to the user (“ab” in this case).

With the new setup, where NginX is responsible for the delivery of a cached response opposed to Apache / WordPress:

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

Time per request:       10.610 [ms] (mean)

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

Although these are not conclusive, lab-certified benchmarks, the crude test does show a rather impressive improvement. The time for each request has been reduced by more than half. So it’s well worth the effort.

Photo “Ashley Force” by Ford Racing (CC)

Related posts:

1. A simplified Nginx-Apache combo with WordPress support
2. NginX and Apache, but no memcached
3. Compiling NginX on Debian / Ubuntu

Once I had run the namebench too again, the results were showing a huge leap in performance. But strikingly, BT’s DNS servers were still faster than my own local servers. Jonathan, the resident monkey, also commented about this based on his own tests. It seems that there might be something amiss with the namebench tool (and I shall dutifully point this out to Google, to see what they have to say).

Nevertheless, I had run the namebench several times and it did indeed radically change from two days ago where my own service provider’s DNS servers were the upstream. Following is a chart from the last benchmark:

Namebench Chart (Updated)

As you can see, my primary (SYS-10.10.24.4) and secondary (SYS-10.10.31.1) are now right at the top of the chart, showing a slight slow start for the primary. Unfortunately, my service provider’s DNS server (in orange) was once again trailing everyone else in this test. In fact, it did so in all the tests.

Following is a chart showing the mean response times in milliseconds:

Mean Response Times (Updated)

And this (chart) is the odd part. You would expect that a server on the same network, solely used for DNS and with less than 5% average usage, would perform better than any external server once the DNS responses have been cached.

While the primary DNS server is now faster than the poor performing DNS server of my service provider, it is still lagging behind BT and even Google’s public DNS servers. I am curious to know about its cause!

In all, namedbench reported that my primary server is 89.7% slower than “BT-30 GB”. Up from the 274.4% a few days ago – an improvement indeed!

Related posts:

1. DNS performance benchmarking by Google
2. NginX and Apache, but no memcached

In fact, this is the damning message that namebench gave me:

namebench 1.0.5 - data/alexa-top-10000-global.txt (weighted) on 2009-12-12 09:15:57.450225

threads=40 tests=200 runs=1 timeout=2.0 health_timeout=4.0 servers=10

------------------------------------------------------------------------------



... (snip!) ...



********************************************************************************

In this test, BT-70 GB is 274.4% faster than your current primary DNS server

********************************************************************************

Yikes!

Follwing is a chart generated by the data generated by namebench (click on it to enlarge). My primary DNS server is represented by SYS-10.10.24.4 (cyan) and secondary by SYS-10.10.31.1. (yellow). My service provider is SYS-213.186.33.9 (purple):

Namebench Chart

The primary server is accessible internally only, powered by BIND9 in a typical split DNS setup. It provides the local names of internal servers (which may be different from public names) and it will cache responses for external servers (like www.google.com) through the upstream server, which are the DNS servers owned by my service provider.

As this and the chart below will show, the response times of my service provider’s DNS serer are rather poor. This directly correlates to a poor performance on my own primary DNS server:

Mean Response Times

My secondary DNS server, powered by PowerDNS, is publicly accessible. However, on the public side it will only answer requests directly related to servers I own. Internally, it will also do this and cache responses for other external servers I do not own. The upstream DNS server is OpenDNS.

In the first namebench chart you can see how well my secondary DNS server is performing. But strangely enough, BT’s “BT-70″ DNS server is providing an even better performance, particularly in response times as shown in the second chart. Because of this, namebench came to this final conclusion:

Recommended configuration (fastest + nearest):

----------------------------------------------

nameserver 62.6.40.162     # BT-70 GB

nameserver 10.10.24.4      # SYS-10.10.24.4

nameserver 10.10.31.1      # SYS-10.10.31.1  NXDOMAIN Hijacking

In other words, I should move my current primary and secondary servers a position down, and use BT’s DNS server as the primary instead. (A note the “NXDOMAIN Hijacking”, which is explained here, I do not practice in this behaviour!)

Despite the fact I was unaware of the overall poor quality of my provider’s DNS servers until now, I will actually keep the primary and secondary servers in their current position. Instead I will be replacing the primary upstream DNS server with OpenDNS (which is currently the case for my secondary server) or with BT’s “BT-70″. This will depend on its uptime of BT-70, comparing it to OpenDNS’ uptime of 99.98% according to my own monitors.

In all, I must say that the new namebench tool is an instant hit. It even picked up on two errors that I can now correct. All the previous “DNS checkers” I have used, commercial or free, failed to pick up on these. Excellent!

Related posts:

1. DNS performance benchmarking update
2. Blocking w00tw00t scans
3. Faster WP Super Cache with NginX

Like anyone else, at times I forget how to do certain things when it comes to networking.

Here are a few reminders / tips specific to Debian and Ubuntu.

IPv4 Specific

Enable Proxy ARP (Address Resolution Protocol)

Assuming eth0 as the interface, in /etc/network/interfaces add:

iface eth0 inet static

    ...

    post_up echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp

Route incoming traffic to another server

In other words, all traffic arriving at a certain IP should be forwarded to another server (public or internal).

Using iptables, issue the following command from the shell:

iptables -t nat -I PREROUTING -d <original ip> -j DNAT --to <other server>

Where <original ip> is the IP where incoming traffic is  received, and <other server> is where the traffic should be routed to.

Route outgoing web traffic via another IP

In other words, make outgoing web traffic appear as if coming from another public IP address (registered to the server and router).

Assuming that eth0 is the public interface, using iptables issue the following command from the shell:

iptables -t nat -A POSTROUTING -o eth0 -p tcp -m tcp --dport 80 -j SNAT --to-source <ip>

Where <ip> is the IP address to be used.

Note: You can substitute tcp for udp, or use a different port for other applications such as FTP. Also, the IP must be routable to your server.

Viewing the NAT table

Issue the following command from the shell:

iptables -t nat -L

Flush iptables

The clear the iptables entirely,  issue the following command from the shell:

iptables -F && iptables -t nat -F && iptables -t mangle -F

IPv6 Specific

Enable Proxy NDP for IPv6 (Neighbor Detection Protocol)

Assuming eth0 as the interface, in /etc/network/interfaces add:

iface eth0 inet static

 ...

 post_up echo 1 > /proc/sys/net/ipv6/conf/eth0/proxy_ndp

Manually announce an IPv6 neighbor

Assuming eth0 as the public IPv6 interface:

ip -6 neigh add proxy <ipv6> dev eth0

Where <ipv6> is the actual IPv6 address.

Enable IPv6 forwarding

In /etc/sysctl.conf uncomment:

net.ipv6.conf.all.forwarding=1

 

Adding more than one IPv6 address per interface

Edit /etc/network/interfaces, add:

iface eth0 inet6 static

    ...

    up /sbin/ifconfig eth0 inet6 add <ip>/<netmask>

Where <ip>/<netmask> is the actual IPv6 and netmask respectively, i.e.: dead:beef:cafe:1::1/64.

Note:  The last entry takes priority.

Setup a 6to4 tunnel (IPv6 to IPv4 translation)

Obtain IPv6 address for 6to4:

printf "2002:%02x%02x:%02x%02x::1\n" $(echo <ipv4> | tr . ' ')

Where <ipv4> is the actual IPv4 address, i.e.., 91.2.3.4 would result in 2002:5b02:0304::1.

Edit /etc/network/interfaces, add:

auto tun6to4

iface tun6to4 inet6 v4tunnel

    address <ipv6 obtained>

    netmask 16

    gateway ::192.88.99.1

    endpoint any

    local <actual ipv4>

Where the <ipv6 obtained> and <actual ipv4> is from the explanation given earlier. For example:

auto tun6to4

iface tun6to4 inet6 v4tunnel

    address 2002:5b02:0304::1

    netmask 16

    gateway ::192.88.99.1

    endpoint any

    local 91.2.3.4

Note: 192.88.99.1 will automatically select the nearest IPv6 to IPv4 gateway.

Application Specific

Setup OpenVPN tap tunnel interface on a bridge

Edit /etc/network/interfaces, add:

iface vmbr0 inet static

    ...

    bridge_ports tap0

    ...

    pre-up /usr/sbin/openvpn --mktun --dev tap0

    post-down /usr/sbin/openvpn --rmtun --dev tap0

Enable OpenVZ/Proxmox for IPv6

Edit /etc/vz/vz.conf and change:

...

IPV6="yes"

...

Adding a failover IP (OVH)

Edit /etc/network/interfaces and add a new alias:

auto eth0:<alias number>

iface eth0:<alias number> inet static

    address  <failover ip>

    netmask  255.255.255.255

Where <alias number> is a sequential number starting at 0 (zero) and <failover ip> is the actual failover IP address. For example:

auto eth0:0

iface eth0:0 inet static

    address  91.2.3.4

    netmask  255.255.255.255

Related posts:

1. Compiling NginX on Debian / Ubuntu
2. Guide: Firewall and router with Proxmox
3. Blocking w00tw00t scans

For Debian and Ubuntu users installing NginX couldn’t be easier. Simply issue the command  apt-get install nginx command and do some basic configuration.

However, the version availble in the Debian and Ubuntu’s package repositories has not been compiled with IPv6 support. If you need this, or if you prefer to use bleeding-edge technology, then compiling NginX is the solution.

Personally I prefer to install NginX from the Debian/Ubuntu package repository before I compile the source code from NginX; this so that I have the proper directory layouts and an official init script. If you prefer a pure source code install, then not to worry as this will cover both.

Required library packages

Other than the compiler you also need a few libraries installed, such as the zlib and libssl. The required libraries and the compiler can be obtained with the following command:

aptitude -y install build-essential libc6 libpcre3 libpcre3-dev libpcrecpp0 libssl0.9.8 libssl-dev zlib1g zlib1g-dev lsb-base

Obtain the latest source code

Be sure to check NginX’s official website for the latest stable version  of NginX, currently 0.7.61. Download it using the following command:

wget http://sysoev.ru/nginx/nginx-0.7.61.tar.gz -P /usr/src

This will place the file in the /usr/src directory. Let’s untar it:

cd /usr/src

tar -xvf nginx-0.7.61.tar.gz

cd nginx-0.7.61

Configure NginX compilate-time options

To see which compile-time options are available, type

./configure --help

The configuration I prefer to use keeps in line with Debian / Ubuntu’s default directory layouts, provides support for IPv6, SSL (https://), WebDAV and Streaming FLV:

./configure --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-ipv6

This will display various “checking” messages, but the important bit is that it reaches the following summary:

Configuration summary

 + using system PCRE library

 + using system OpenSSL library

 + md5: using OpenSSL library

 + sha1 library is not used

 + using system zlib library



 nginx path prefix: "/usr/local/nginx"

 nginx binary file: "/usr/sbin"

 nginx configuration prefix: "/etc/nginx"

 nginx configuration file: "/etc/nginx/nginx.conf"

 nginx pid file: "/var/run/nginx.pid"

 nginx error log file: "/var/log/nginx/error.log"

 nginx http access log file: "/var/log/nginx/access.log"

 nginx http client request body temporary files: "/var/lib/nginx/body"

 nginx http proxy temporary files: "/var/lib/nginx/proxy"

 nginx http fastcgi temporary files: "/var/lib/nginx/fastcgi"

Compile and install NginX

You are now ready to compile and install NginX by issuing the following commands:

make && make install

If all everything compiled without error, you should be able to type the command:

nginx -v

And the result would be:

nginx version: nginx/0.7.61

If you have installed NginX through the Debian or Ubuntu package repositories prior, you will need to restart NginX:

/etc/init.d/nginx restart

However, if you are using a source-only install then you would likely need the init script as well. Following is the init script courtesy Debian, which you need to create at /etc/init.d/nginx :

#! /bin/sh



### BEGIN INIT INFO

# Provides:          nginx

# Required-Start:    $all

# Required-Stop:     $all

# Default-Start:     2 3 4 5

# Default-Stop:      0 1 6

# Short-Description: starts the nginx web server

# Description:       starts nginx using start-stop-daemon

### END INIT INFO



PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

DAEMON=/usr/sbin/nginx

NAME=nginx

DESC=nginx



test -x $DAEMON || exit 0



# Include nginx defaults if available

if [ -f /etc/default/nginx ] ; then

        . /etc/default/nginx

fi



set -e



case "$1" in

  start)

        echo -n "Starting $DESC: "

        start-stop-daemon --start --quiet --pidfile /var/run/$NAME.pid \

                --exec $DAEMON -- $DAEMON_OPTS || true

        echo "$NAME."

        ;;

  stop)

        echo -n "Stopping $DESC: "

        start-stop-daemon --stop --quiet --pidfile /var/run/$NAME.pid \

                --exec $DAEMON || true

        echo "$NAME."

        ;;

  restart|force-reload)

        echo -n "Restarting $DESC: "

        start-stop-daemon --stop --quiet --pidfile \

                /var/run/$NAME.pid --exec $DAEMON || true

        sleep 1

        start-stop-daemon --start --quiet --pidfile \

                /var/run/$NAME.pid --exec $DAEMON -- $DAEMON_OPTS || true

        echo "$NAME."

        ;;

  reload)

        echo -n "Reloading $DESC configuration: "

        start-stop-daemon --stop --signal HUP --quiet --pidfile /var/run/$NAME.pid \

            --exec $DAEMON || true

        echo "$NAME."

        ;;

  configtest)

        echo -n "Testing $DESC configuration: "

        if nginx -t > /dev/null 2>&1

        then

          echo "$NAME."

        else

          exit $?

        fi

        ;;

  *)

        echo "Usage: $NAME {start|stop|restart|reload|force-reload|configtest}" >&2

        exit 1

        ;;

esac



exit 0

Remember to make the init script executable:

chmod +x /etc/init/nginx

And if you wish to start NginX automatically at boot time:

update-rc.d nginx defaults

All that’s left is configuring NginX in the /etc/nginx/ directory. You can refer to the NginX Wiki for further assistance. Enjoy!

Related posts:

1. Quick Debian/Ubuntu networking tips
2. A simplified Nginx-Apache combo with WordPress support
3. Faster WP Super Cache with NginX

NginX outperforms Apache on small- to mid-range servers when it comes to static file handling, particularly because it is event driven.

The downside of NginX is that PHP can only be used with FastCGI. In general, most how-to’s explain how to implement PHP FastCGI with NginX using TCP. This is adding extra overhead and slows PHP to a crawl. A better solution is to use the UNIX sockets instead, which is explained well in Till’s blog.

But even using UNIX sockets, the PHP FastCGI and NginX combination is not as fast as Apache can handle PHP requests. For this reason, NginX can act as a great accelerator for static files while Apache deals with all the PHP requests. Even with the extra TCP overhead between NginX and Apache, this makes for quite a speedy combination.

Thinking logically, some people figured that loading static files from RAM memory instead of the harddrive must make things even faster. But that really depends…

Using Memcached

Loading static files from RAM memory is accomplished using the memcached daemon and the NginX memcached module. Various how-to’s describe the procedure along these lines:

• A script that’s run at boot time, using a CRON or other method, that loads static files from the harddrive into memcached (RAM).
• NginX is configured to load a requested file from memcached and if failed to do so, load it directly from the harddrive instead.

But unfortunately the NginX memcached module is only capable of TCP communications. If memcached is located on the same server, it would have made more sense to use UNIX sockets instead (just like PHP FastCGI over UNIX sockets).

See, in my case there was so much overhead that NginX slowed to less than 8,000 requests per second. To put this in perspective, Apache was capable of serving 18,898 static 100-byte files per second on the same server.

So using memcached is only worth it if you are caching files that are spread over several back-end servers or are dynamic of nature (ie., PHP output that changes very little). Not if these files are local to NginX, especially with NginX’s highly efficient caching methods.

Speedy NginX

Now, how much faster is NginX compared to Apache when it comes to static files anyway? Well, I’ve have some non-definitive numbers for you, obtained on a low-range server:

Server:

Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz, 2x750GB Seagate Barracuda 7200.11 32M RAID-1, 4GB RAM, Debian Lenny (5.0) i386 (2.6.24-7 Ubuntu-based, back-ported kernel)

Test parameters:

ab -k -c5 -t10000 http://<server>/100.html

Apache:

Server Software:        Apache/2.2.9

Server Hostname:        <server>

Server Port:            80



Document Path:          /100.html

Document Length:        100 bytes



Concurrency Level:      5

Time taken for tests:   2.646 seconds

Complete requests:      50000

Failed requests:        0

Write errors:           0

Keep-Alive requests:    49508

Total transferred:      22577856 bytes

HTML transferred:       5000000 bytes

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

Time per request:       0.265 [ms] (mean)

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

Transfer rate:          8333.56 [Kbytes/sec] received



Connection Times (ms)

              min  mean[+/-sd] median   max

Connect:        0    0   0.0      0       0

Processing:     0    0   0.5      0      49

Waiting:        0    0   0.5      0      49

Total:          0    0   0.5      0      49



Percentage of the requests served within a certain time (ms)

  50%      0

  66%      0

  75%      0

  80%      0

  90%      0

  95%      0

  98%      1

  99%      1

 100%     49 (longest request)

NginX:

Server Software:        nginx/0.7.61

Server Hostname:        <server>

Server Port:            80



Document Path:          /100.html

Document Length:        100 bytes



Concurrency Level:      5

Time taken for tests:   1.928 seconds

Complete requests:      50000

Failed requests:        0

Write errors:           0

Keep-Alive requests:    49502

Total transferred:      19397510 bytes

HTML transferred:       5000000 bytes

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

Time per request:       0.193 [ms] (mean)

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

Transfer rate:          9826.54 [Kbytes/sec] received



Connection Times (ms)

              min  mean[+/-sd] median   max

Connect:        0    0   0.0      0       0

Processing:     0    0   0.1      0       5

Waiting:        0    0   0.1      0       5

Total:          0    0   0.1      0       5



Percentage of the requests served within a certain time (ms)

  50%      0

  66%      0

  75%      0

  80%      0

  90%      0

  95%      0

  98%      0

  99%      0

 100%      5 (longest request)

This is the setup I’m using on all the web servers I am deploying, NginX as the front-end and a number of Apache servers at the back-end to deal with non-static files, including PHP.

Related posts:

1. A simplified Nginx-Apache combo with WordPress support
2. Faster WP Super Cache with NginX
3. Compiling NginX on Debian / Ubuntu

An additional issue arises when a hosting provider blocks servers if unauthorized MAC addresses are detected. As Proxmox’s bridged network creates and exposes MAC addresses for its virtual network interfaces, this may cause your server to be blocked from the hosting provider’s network.

To combat both this article will describe how to create your own virtual network with firewall protection using Shorewall, a popular and effective firewall / router software package.

Overview

Figure 1.

We will be creating three separate zones, namely:

1. The Internet (“net”);
2. The firewall / Proxmox Host Node (“fw”); and
3. The virtual network (“dmz”)

All traffic from the Internet is filtered or blocked by the firewall, after which it is routed to its final destination on the virtual network or the Proxmox Host Node itself. A visual representation of this can be seen in the figure 1.

Host Network Configuration

Some modifications are required to your host network configuration, particularly the default vmbr0 network interface. We will turn it into a blind bridge (without any bride ports) and assign it an IP address within the private IP range of 10.0.0.0/8 (A-Class).

Determine the current network configuration

Before we do this, we need to determine the current network configuration because this can be different depending on the hosting provider and other factors. Assuming that eth0 is the network interface that connects the server to the Internet, we issue the following command:

ifconfig eth0

This will give an output similar to:

eth0      Link encap:Ethernet  HWaddr 00:ff:ff:ff:ff:ff

 inet addr:91.11.22.33  Bcast:91.11.22.255  Mask:255.255.255.0

...

It gives us the current IP address, broadcast address and netmask used by eth0.  One last piece of information we need is the gateway used by eth0, which is obtained with the follwing command:

route -n

You will see an output similar to:

...

0.0.0.0         91.11.22.254    0.0.0.0         UG    0      0        0 eth0

The first column of 0.0.0.0 designates the default route (any traffic that has no specific route), and the second column the gateway. Now that we have obtained all this information, we can edit the /etc/network/interfaces file.

First we need to verify that eth0 has already been defined within this file. It will look similar to:

auto eth0

iface eth0 inet static

        address 91.11.22.33

        netmask 255.255.255.0

        broadcast 91.11.22.255

        gateway 91.11.22.254



...(additional stanzas)...

Where the IPs match those you have obtained by use of the ifconfig and route commands.

Or if your server uses DHCP to assign the IP address then it will look similar to:

allow-hotplug eth0

iface eth0 inet dhcp



...(additional stanzas)...

If either is the case, you can skip the follow section and continue to change the vmbr0 network interface.

Updating the eth0 network interface

If you have reached this section, then your vmbr0 network interface was most likely directly bridged with your eth0 network interface, meaning that vmbr0 contains your public IP address, network gateway and other settings. Because we will turn vmbr0 into a blind bridge in the next section, we need to create or edit a separate eth0 stanza in the /etc/network/interfaces file first.

In the previous steps we have obtained all the information required for this purpose (using the ifconfig and route commands). This information may already be present in your vmbr0 stanza as well, in which case you can use this instead.

We edit the eth0 stanza to look as following:

auto eth0 iface

eth0 inet static

         address 91.11.22.33

         netmask 255.255.255.0

         broadcast 91.11.22.255

         gateway 91.11.22.254

Where the example IPs are replaced by the actual address, netmask, broadcast and gateway IPs found in the previous steps or obtained from the current vmbr0 stanza.

WARNING: It is important to understand that editing the eth0 stanza can lead to an inability to connect to the server if done incorrectly. If you rely on remote access such as SSH, or if you are uncertain about the information that needs to be entered in the various fields, please contact your administrator or hosting provider for assistance. As always, use care and make backups of existing files.

Change the vmbr0 network interface

The vmbr0 stanza in the /etc/network/interfaces will be changed to look like:

... (original configuration) ...



auto vmbr0

iface vmbr0 inet static

        address 10.254.254.254

        netmask 255.0.0.0

        broadcast 10.255.255.255

        bridge_ports none

        bridge_stp off

        bridge_fd 0

The significant changes here are the IP addresses used for the address, netmask and broadcast as well as changing bridge_ports to “none”.  The IP address of 10.254.254.254 can be any in the 10.0.0.0/8 range and so may be changed if you wish. It will later be used as the gateway address for the virtual servers.

The changes can be applied without having to reboot the system using:

/etc/init.d/networking restart

Shorewall

Installing Shorewall is simply a matter of executing the following command:

apt-get install shorewall

If you wish to use shorewall with IPv6 capabilities, a few additional steps will be required. At the moment of writing, Debian has not included the latest version of Shorewall6 into its main package source. You will therefore need to add the SID (unstable branch) to your available package sources:

echo "deb http://ftp.fr.debian.org/debian sid main" >> /etc/apt/sources.list

aptitude update

Once this has been done, Shorewall with IPv6 support – aptly named shorewall6 – can be installed with:

apt-get install shorewall6

It is important to note that Shorewall6 makes a strict distinction between IPv4 and IPv6 and each has to be configured individually. That is, the files located in /etc/shorewall/ are for IPv4 only and /etc/shorewall6/ contains files related to IPv6 only. The IPv4 version cannot control what will happen on IPv6 and vice versa!

Most rules and policies in for Shorewall are directly transferable between /etc/shorewall/ and /etc/shorewall6/. Due to this, this article will only focus on IPv4 configuration with one exception:

You will want to edit the /etc/shorewall/shorewall.conf file, and change the following value from:

DISABLE_IPV6=Yes

to:

DISABLE_IPV6=No

If this is not done, any configuration done in /etc/shorewall6/ would be ignored (and will also disable any existing IPv6 traffic).

Enable IP Forwarding

First, a minor modification to the Shorewall application configuration is made to enable IP forwarding. This will permit some functions that will be discussed later.

Edit /etc/shorewall/shorewall.conf and change the following value from:

IP_FORWARDING=Off

to:

IP_FORWARDING=On

Zones

The /etc/shorewall/zones file is created to establish the zones names and what type of zones they are:

#ZONE   TYPE            OPTIONS         IN                      OUT

#                                       OPTIONS                 OPTIONS

fw      firewall

net     ipv4

dmz     ipv4

The fw zone is a self-reference to the server on which Shorewall is running. Note that this will not include the Proxmox virtual servers; you have to consider this as an entirely separate server in this sense.

Interfaces

The network interfaces on the server need to be defined and assigned to a specific zone. The net zone will be assigned to the eth0 network interface and will designate all traffic coming from or going to the internet. The dmz zone will be the internal zone for the virtual network, which will contain the virtual servers that either use venet or veth network interfaces.

Create the /etc/shorewall/interfaces file and add the following:

#ZONE   INTERFACE       BROADCAST       OPTIONS

net     eth0            detect          blacklist,nosmurfs

dmz     venet0          detect          routeback

dmz     vmbr0           detect          routeback,bridge

Policy

A base policy needs to defined for each one of the zones. It specifies the default actions on in- and outgoing traffic, and in this article the following policies will be defined:

Traffic from the firewall to:

• the internet is permitted
• DMZs is permitted
• other processes on the firewall is permitted

Traffic from the DMZ (virtual servers) to:

• another virtual server is permitted
• the internet is permitted
• the firewall is denied and 1 information message per second (with a burst of 2) will be record when access is attempted.

Traffic from the internet to:

• the firewall is denied
• DMZs is denied, generating 8 messages per second (with a burst of 30 messages) whenever access is attempted.

Any traffic not defined in any of the zones (either by accident or purposely) will be rejected.

To do this, we will create the /etc/shorewall/policy file:

#SOURCE DEST    POLICY          LOG     LIMIT:          CONNLIMIT:

#                               LEVEL   BURST           MASK



# From Firewall Policy

fw      fw      ACCEPT

fw      net     ACCEPT

fw      dmz     ACCEPT



# From DMZ Policy



dmz     dmz     ACCEPT

dmz     net     ACCEPT

dmz     fw      DROP            info



# From Net Policy

net     fw      DROP            info

net     dmz     DROP            info 



# THE FOLLOWING POLICY MUST BE LAST

#

all     all     REJECT          info

Update: For those who have followed this guide before and are experiencing some performance issues, please remove the limit burst options after “info”, ie “1/sec:2″. The reason is that this takes priority over rules; this was a painful discovery on my end!

Basic Rules

The policy defined earlier will deny any traffic coming from the internet to the firewall, which will include the SSH service and the Proxmox web-based manager. Since this is undesirable, a few rules need to be created that override this base policy.

Create the /etc/shorewall/rules file:

#ACTION          SOURCE     DEST       PROTO   DEST        SOURCE     ORIGINAL    RATE



# Permit access to SSH

SSH/ACCEPT       net        fw         -       -            -          -          6/min:5



# Permit access to Proxmox Manager and Console

ACCEPT           net        fw         tcp     443,5900:5999



# PING Rules

Ping/ACCEPT      all        all



# LAST LINE -- DO NOT REMOVE

As you may notice, there is also an additional rule for ping. For testing purposes, it would be wise to permit a ping from and to any of your zone, including the internet.

The SSH/ACCEPT rule is in fact a macro that comes with Shorewall. You could also define the same rule as following:

ACCEPT       net        fw         tcp       22            -          -          6/min:5

Also, at the very end of the SSH rule you notice “6/min:5″. This specifies the connection rate and in this case it reduces the connection rate to 6 per minute (1 per 10 seconds) with a maximum initial burst of 5. It is added here to slow down brute force SSH attacks.

Testing Configuration

After creating the files, your /etc/shorewall/ directory might look similar to:

drwxr-xr-x  2 root root 4096 2009-07-01 06:36 .

drwxr-xr-x 82 root root 4096 2009-07-06 10:03 ..

-rw-r--r--  1 root root  522 2009-06-26 20:05 interfaces

-rw-r--r--  1 root root  453 2007-11-15 23:24 Makefile

-rw-r--r--  1 root root  781 2009-06-26 21:16 policy

-rw-r--r--  1 root root 2355 2009-07-02 22:42 rules

-rw-r--r--  1 root root 4134 2009-06-20 21:58 shorewall.conf

-rw-r--r--  1 root root  438 2009-06-26 20:04 zones

Before using the configuration you will want to test it first, particularly to make sure you are not blocking SSH access. Issue the following command:

shorewall try /etc/shorewall 60

The parameter 60 refers to 60 seconds. Shorewall will use the configuration located in /etc/shorewall/ for 60 seconds and then reverts to the previous settings (or no firewall).

After issuing the command, establish a new connection to your server using SSH and check whether your Proxmox web-based manager is accessible. If you are receiving error messages from Shorewall or you are unable to access SSH during the 60-second test period, please verify the configuration and try again.

Starting Shorewall

By default Shorewall is not enabled during boot time as a safety precaution for first-time configurations. To enable it, edit /etc/default/shorewall file and change:

startup=0

to:

startup=1

You can start Shorewall manually with:

shorewall start

And after making any changes to the Shorewall configuration, issue the command:

shorewall restart

Note: It is best not to use /etc/init.d/shorewall restart. Doing so will temporarily disable the firewall, which permits access to normally blocked ports. Although this period is brief, it may still be enough time for someone to establish a connection to the server – Shorewall does not block existing connections by default.

Proxmox

Once Shorewall has been configured, there will be three distinct zones on the Proxmox server:

• the Firewall / Proxmox host at fw
• the virtual network zone for virtual servers at dmz
• the internet at net

IP Assignment

To further separate the internet and virtual servers as distinct areas, each virtual server will be assigned an IP address in the 10.0.0.0/8 range (10.0.0.1 – 10.255.255.254).

The exception is that one can no longer use 10.254.254.254 as this has been assigned to the vmbr0 network interface earlier in this guide.

Outgoing internet traffic

Due to this separation and the use of A-class (10.0.0.0/8) IP addresses, outgoing traffic from a virtual server to the internet needs to be translated (so that Shorewall and other Internet routers know where to send responses to). This will be defined in the /etc/shorewall/masq file.

In its simplest form, /etc/shorewall/masq can be set to the follwing:

#INTERFACE      SOURCE          ADDRESS         PROTO   PORT(S) IPSEC   MARK

eth0            10.0.0.0/8



# LAST LINE -- DO NOT REMOVE

This means that all traffic originating from 10.0.0.0/8 and going to the internet will pass through the eth0 network interface using the IP address assigned to eth0.

If you wish to make all traffic appear from a particular IP addresses, it can be specified as the third parameter. For example:

eth0            10.0.0.0/8    91.121.0.1

Or perhaps there’s a specific internal IP address that must appear externally as another IP address, you can do this as folowing:

+eth0           10.0.1.101    91.121.0.2

eth0            10.0.0.0/8    91.121.0.1

Notice the plus (‘+’) sign in front of eth0. All traffic from 10.0.0.0/8 will appear to be coming from IP 91.121.0.1, except traffic coming from 10.0.1.101 will appear as coming from 91.121.0.2.

Incoming internet traffic

The separation between the internet and virtual servers not only applies to outgoing traffic, but also incoming traffic. There are two methods of directing incoming traffic,which is Proxy ARP or DNAT. This article will focus on DNAT; for more information on Proxy ARP and Shorewall, visit http://www.shorewall.net/manpages/shorewall-proxyarp.html.

For example, to forward HTTP traffic on any external IP address to a virtual server with the assigned IP of 10.0.1.101, edit the /etc/shorewall/rules file as following:

...(existing rules)...

DNAT                    net     dmz:10.0.1.101          tcp     80

The added benefit of DNAT is that a single IP address can be used for multiple virtual servers, provided that the traffic is on a different port. For example, HTTP traffic on external IP address 91.121.0.1 may be sent to a virtual server with the assigned IP of 10.0.1.101, whereas FTP traffic may be sent to a virtual server with assigned IP of 10.0.1.102 instead:

...(existing rules)...

DNAT                    net     dmz:10.0.1.101          tcp     80       -    91.121.0.1

DNAT                    net     dmz:10.0.1.102          tcp     21,23    -    91.121.0.1

It is even possible to route traffic to a different internal port. For example, to forward HTTP traffic on external IP address 91.121.0.1 to a virtual server with the assigned IP of 10.0.1.103 and listening on 8180:

...(existing rules)...

DNAT                    net     dmz:10.0.1.103:8180     tcp     80       -    91.121.0.1

Bridged Networking

The venet network interface is certainly the simplest method to use in Proxmox. However, venet is not available in KVM (fully virtualized servers) and there may be another reason why you might want to use the veth network interfaces with regular containers (such as the use of DHCP).

For this reason the vmbr0 network interface on the host was reconfigured to use the IP address of 10.254.254.254. It will act as the gateway entry for those virtual servers using veth network interfaces.

Although additional configuration needs to be done within a virtual server, you can use the same Shorewall rules for in- and outgoing traffic as described earlier (ie., DNAT or outgoing traffic).

Linux (Debian)

Inside a Debian Linux virtual server, you will specify /etc/network/interfaces as following:

auto eth0

iface eth0 inet static

  address 10.0.1.101

  netmask 255.0.0.0

  gateway 10.254.254.254

where 10.0.1.101 is the IP address to be used by this particular virtual server.

If you are using both venet and veth network interfaces at the same time, as may be the case with certain IPv6 configurations, the file /etc/network/interfaces.tail should be used instead.

Microsoft Windows

For networking within Windows, proceed to your Networking control panel (or the Network and Sharing Center). Select the appropriate Local Area Connection and right-click to reveal the Properties menu option. UAC (User Account Control) may request your permission to proceed.

In the list of This connection uses the following items, select Internet Protocol (TCP/IP) (or Internet Protocol Version 4 (TCP/IPv4)). Click the Properties button.

At the General tab, change the following selections:

Use the following IP address:

• IP address: 10.0.1.101
• Subnet mask: 255.0.0.0
• Default gateway: 10.254.254.254

Use the following DNS server addresses:

• Preferred DNS server: xxx.xxx.xxx.xxx
• Alternate DNS server: yyy.yyy.yyy.yyy

Where xxx… and yyy… are your preferred DNS servers.

Non-private IP Assignment

The setup as described above has separated your virtual servers from the internet by use of a zone (dmz) and A-class IP range (10.0.0.0/8). However, it is still possible to assign a non-private IP directly to one of your virtual servers if the venet network interface is used.

Internet traffic (from the net to the dmz zone) will still be blocked per the policy established in the above setup, and you will need to add additional rules to your Shorewall configuration. The major difference is that you must use ACCEPT instead of DNAT.

For example, let’s assume the IP address 91.121.0.1 was directly assigned to a virtual server. To permit internet Web traffic (port 80) to this container, add the following rule to your /etc/shorewall/rules file:

ACCEPT                  net     dmz:91.121.0.1             tcp     80

Please note that for veth network interfaces (bridged) Proxy ARP is required.

Extra Hardening

Following are considered advanced topics to further enhance the firewall and Proxmox. They may not be required in all situations.

Restricting IP Addresses per MAC

When the veth bridged networking is used in Proxmox, the virtual server will have a fully emulated network interface with its own MAC address. The downside is that Proxmox cannot assign the IP address directly and so you will have to configure this within the virtual server.

This should not be an issue if you have full control over the virtual server. However, if the virtual server belongs to a customer or in a worst case scenario is compromised, you no longer have full control over it and it will be possible to change or assign additional IP addresses to the virtual server.

Although earlier in this article containers have already been separated from the internet, it would still be possible to use a private IP address or network interface of an already existing other container. It may therefore be possible to spoof another virtual server.

To implement additional safeguards against this, Shorewall needs a few extra rules described here.

Enable the maclist

First the maclist option needs to be enabled for the interface we will monitor MAC / IP relations on. Your /etc/shorewall/interfaces may currently look like this:

#ZONE   INTERFACE       BROADCAST       OPTIONS

net     eth0            detect          blacklist,nosmurfs

dmz     venet0          detect          routeback

dmz     vmbr0           detect          routeback,bridge



# LAST LINE -- DO NOT REMOVE

We will add the maclist option to vmbr0 in the dmz zone, ending up with:

...

dmz     vmbr0           detect          routeback,bridge,maclist



# LAST LINE -- DO NOT REMOVE

Defining MAC / IP relation

Now we need to obtain the MAC address of the veth interface used in the virtual server and there are several methods for this. We can obtain the MAC address from within the container by issuing the command:

ifconfig | grep eth

which produces an output similar to:

eth0      Link encap:Ethernet  HWaddr 00:18:51:f9:43:1e

Alternatively, we can issue the following command from the host node (Proxmox server):

cat /etc/vz/conf/<VEID>.conf | perl -lne 'print for /mac=(.*),host_ifn/g'

Or in case it is a fully virtualized server (KVM):

cat /etc/qemu-server/<VEID>.conf | perl -lne 'print for /virtio=(.*)$/g'

where <VEID> is the number of the virtual server (container) for which you wish to obtain the MAC address. This will produce an output similar to:

00:18:51:F9:43:1E

Once we have obtained the MAC address, we create (or edit) the /etc/shorewall/maclist file as following:

# DISPOSITION   INTERFACE       MAC                     IP

ACCEPT          vmbr0           00:18:51:f9:43:1e       10.0.1.101

# LAST LINE -- DO NOT REMOVE

In this example, the MAC address has been provided in our earlier examples and the IP address 10.0.1.101 is the only permitted IP address that can be used by this virtual server.

Apply the changes by issuing the command

shorewall restart

At this point, if the virtual server changed the IP address (or added another IP address) other than 10.0.1.101, that traffic will be rejected as per the default behaviour of a Shorewall installation on Proxmox/Debian. If this behaviour needs to be changed, it can be set in the /etc/shorewall/shorewall.conf file with this variable:

MACLIST_DISPOSITION=REJECT

Additonal Notes

This guide is only intended to provide basic protection for your virtual servers and the Proxmox host node. No guarantees or warranties are implied, and you should always remain vigilant against potential network intrusions (in other words: do not rely on a firewall alone).

You may also wish to configure Shorewall according to your particular needs. For example, in this guide virtual servers are permitted to connect to each other within the dmz zone and could pose a risk.  You may wish to shield the virtual servers from each other in case one of them has been compromised (hint: edit the policy).

The Shorewall website includes numerous examples in its documentation that may help you further.

Related posts:

1. Guide: Firewall and router with Proxmox – Extending its use
2. Quick Debian/Ubuntu networking tips
3. Blocking w00tw00t scans