Now this has been working fine for a long time now, using the original geoip module and patch-o-matic-ng method of installation (similar to what is very well described here). Still, this is unmaintained, and starting with kernel 2.6.22 it is no longer working. There is a patch that will make it work with a newer kernel, but if you run iptables 1.4.x this will again fail and even if there are some manual walkarounds this is still not the best solution.

The solution is called Xtables-addons. Xtables-addons is the successor to patch-o-matic-ng. Likewise, it contains extensions that were not, or are not yet, accepted in the main kernel/iptables packages. Xtables-addons is different from patch-o-matic in that you do not have to patch or recompile the kernel, sometimes recompiling iptables is also not needed.
The latest version 1.12 supports: iptables >= 1.4.1 and kernel-source >= 2.6.17.

The installation is very simple and requires only the following steps exemplified on a debian lenny machine (kernel 2.6.26 and iptables 1.4.2):

1. Install the needed dependencies: kernel headers and iptables dev:
aptitude install linux-headers-2.6.26-1-amd64 iptables-dev
libtext-csv-xs-perl will be also needed if you plan to update the database (normally you will want this to be able to update the db from time to time):
aptitude install libtext-csv-xs-perl

2. Download the xtables-addons package and the supplied database (or the sources to build your own):
wget http://switch.dl.sourceforge.net/sourceforge/xtables-addons/xtables-addons-1.12.tar.bz2
wget http://jengelh.medozas.de/files/geoip/geoip_iv0_database-20090201.tar.bz2

3. Configure and compile the package. There are several iptables modules included; you can leave them all enabled or choose to compile and install only the ones needed. For this edit the mconfig file and leave only the ones you want:
build_CHAOS=m
build_DELUDE=m
build_DHCPADDR=m
build_ECHO=
build_IPMARK=m
build_LOGMARK=m
build_SYSRQ=m
build_TARPIT=m
build_TEE=m
build_condition=m
build_fuzzy=m
build_geoip=m
build_ipp2p=m
build_ipset=m
build_length2=m
build_lscan=m
build_quota2=m

Compile and install:
./configure --with-xtlibdir=/lib/xtables
make
make install

this will add the iptables extension /lib/xtables/libxt_geoip.so and the kernel module in /lib/modules/<kernel>/extra/xt_geoip.ko

4. Now we have to put the geoip database files under the expected location (/var/geoip); this is hardcoded in the code, but you can change it if really needed and recompile. I would like to add that even if this uses the same geoip source (the free GeoLite Country database) as the original geoip iptables module, but the format has changed. You can either get the database from the source, or build your own with the supplied script. Once you have that copy the files to /var/geoip

wget http://www.maxmind.com/download/geoip/database/GeoIPCountryCSV.zip
unzip GeoIPCountryCSV.zip
./runme.sh
cp -R var/geoip/ /var/

That’s it! All you have to do is use the module based on your needs. The syntax is the same as the original geoip iptables module:
[!] –src-cc, –source-country country[,country...] = Match packet coming from (one of) the specified country(ies)
[!] –dst-cc, –destination-country country[,country...] = Match packet going to (one of) the specified country(ies)
NOTE:  The country is inputed by its ISO3166 code.

We use something like this to mark and send each type of traffic to its own destination:
iptables -t mangle -A PREROUTING -p tcp -m geoip --src-cc US -d <IP> --dport 80 -j MARK --set-mark 1
iptables -t mangle -A PREROUTING -p tcp -m geoip ! --src-cc US -d <IP> --dport 80 -j MARK --set-mark 2

I hope you found this article useful, and as me, are grateful that Xtables-addons project took over the patch-o-matic-ng broken modules and made them available on current distributions. Xtables-addons was also accepted in debian repository (in testing) and this will make it even simpler to install and use in the future.

The SkipFiles parameter is by default empty, and in order to use it we have to add the appropriate config in our awstats.conf file.  For example to ignore a file called somefile.php we will add “/somefile.php“:
SkipFiles="/somefile.php"
while if we want to ignore all the pages in a folder called somefolder we will have to use a regex value like: “REGEX[^\/somefolder]“
We can add several rules separated by spaces:
SkipFiles="/somefile.php REGEX[^\/somefolder]"

Note: this will be effective only for new updates; meaning existing data will not be affected by this (if really needed you will have to regenerate your stats to get rid of those pages in old stats).

Useful: there is really no need to disclose this information to everyone. As shown in “Discover the web server software and version of a remote server” anyone can find valuable information from our web server banner. Hiding it  will not protect in any way from real vulnerabilities if they exist, but it will at least make their life harder. This will also not stop more complex fingerprinting programs to detect some information on the web server, but at least we should not make their life easier .

Compared with Apache (apache by default will show a lot of information even about the linux distribution and installed apache modules), lighttpd will only show its server version in the header. This is good enough, but still we probably want to hide that information anyway. For this, we will use the global lighttpd variable server.tag that defines the string returned by the server. The default (if not defined) is:

server.tag = "lighttpd <current-version>"

and this will look in a regular header output like:
...
Server: lighttpd/1.4.19
...

To overwrite this, we just have to define our own output for the server.tag variable in lighttpd.conf. Usually I like to define it like this:
server.tag = "lighttpd"
leaving the lighty name, but taking out the version; you can of course enter anything you like (even to forge an apache or iis server output, etc.)
server.tag = "Apache/1.3.29 (Unix) mod_perl/1.29 PHP/4.4.1 mod_ssl/2.8.16 OpenSSL/0.9.7g"

Conclusion: if you want to provide minimum information about your system then customize your lighty server.tag:
server.tag = "lighttpd"

Go to:
Main page of all my Lighty Tips & Tricks

CloudFront is the answer to all users’ requests about using S3 as a CDN, delivering the content using a global network of 14 edge locations. CloudFront uses S3 to store the original file, and caches copies of the content close to end users locations, lowering latency when they download the objects.

Amazon CloudFront uses the following edge locations:
United States
* Ashburn, VA
* Dallas/Fort Worth, TX
* Los Angeles, CA
* Miami, FL
* Newark, NJ
* Palo Alto, CA
* Seattle, WA
* St. Louis, MO
Europe
* Amsterdam
* Dublin
* Frankfurt
* London
Asia
* Hong Kong
* Tokyo

CloudFront advantages:

• simple to implement; uses S3 as a ‘backend’;
• cost effective – pay only for what you use; priced very well just as S3 with prices starting at $0.170 per GB for content delivered in the US and Europe, and $0.210 per GB for content delivered in Asia;
• reliable - even though this is launched as beta and there is no SLA, we can expect to have a very reliable service from Amazon built on the experiences of s3 and ec2.

CloudFront disadvantages:

• this is a http only service; if you will need https for ex. you will not be able to do that.
• no control over caching; CloudFront will cache the file from your S3 bucket and serve it based on the closest dns location; this cache can expire in case of infrequent used files.
• no stats (besides the aws bill of course ).
• this is not trying to compete with the big CDN solutions out there, as it will be hard to match their features, but to provide a simple and cost effective solution that everybody can use.

In conclusion, this is great news from Amazon, and I am sure that even as I am writing this, many users that are serving their content from S3 have just finished switching over to CloudFront. For more details about CloudFront check out the AWS CloudFront page.

A while ago setting up a pptp server was not so simple. It involved patching the kernel and the ppp daemon. These days in Debian Etch everything comes out of the box and we just have to install the pptpd server and configure it based on our needs. First let’s install pptpd:
aptitude install pptpd
(this will install also some dependencies: bcrelay and ppp). The default pptpd configuration file is installed under /etc/pptpd.conf ; you can change any of the available options (samples are included in the configuration file as comments), but really the only thing that needs to be configured is the ip of the local server used by pptpd as the local gateway for the remote hosts and the remote users assigned ips:
localip 192.168.1.1
remoteip 192.168.1.100-120
here we will use the local ip 192.168.1.1 as the pptpd ip and the remote users will be allocated the first available ip from the range 192.168.1.100 – 192.168.1.120 (meaning we can have a maximum of 20 simultaneous vpn users connected to this pptp server). These ips are assigned based on the particular setup, being either a pair of private ips (just like in my example above) or even real ips.

The debian package also uses the file /etc/ppp/pptpd-options containing the main pptpd server configs. A typical config will look like this:

name My.VPN

refuse-pap
refuse-chap
refuse-mschap
require-mschap-v2
require-mppe-128

ms-dns 192.168.1.1

proxyarp
nodefaultroute
lock
nobsdcomp
noipx
mtu 1490
mru 1490

Finally, you will need to add your vpn users in /etc/ppp/chap-secrets, each user on a separate line using the regular pppd format:

# client        server  secret                 IP addresses
user            *       password               *

To limit connections from specific hosts, add the allowed ip instead of the * at the end.

Activate the changes restarting the pptp server:
/etc/init.d/pptpd restart
and look for the logs under /var/log/syslog to troubleshoot any problems.

You can now connect to your new PPTP VPN server using the built-in pptp vpn client from any modern windows workstation (except probably vista that is broken by sp1) using the default connection settings.

Cisco PIX firewalls have been around for many years and I was aware of the stupid limitation they had about not being able to add ip aliases on their interfaces. Again this was many years ago… Today when I had to configure a small Cisco ASA 5505 device, I didn’t even thought that the fanciest line of Cisco firewalls still has this limitation. You could say that the 5505 is the cheapest models and this is the reason for the limitation. Well, it costs much more than any other similar hardware firewall and honestly every other box I have seen support this (I can’t even call it feature)… I can’t be certain as I don’t have such a device to test out, but from what I can tell, all the ASA product line has the same issue, including the higher level 5550 and 5580.

Now, why would I need this? Maybe I have several network ranges behind the ASA, and for whatever reason I don’t need them in separate vlans (my switches don’t support vlans, I have ips from both ranges configured on some systems, etc.) and I don’t what to pay a lot of money to just enable more vlans on the box, etc.

I will not give a linux system as an example as this is quite obvious to anyone that you can add as many ip aliases you want on one ethernet interface. Still the ASA will not be able to do this. You could try out to use the familiar ios command to add a secondary ip on the interface/vlan, as you might hope it is undocumented feature, but you will see it is just not there…

Let’s see what trick we can use to overcome this stupid limitation: we will be using the Proxy-ARP facility in order to respond for another IP requests on the same ethernet interface, without actually bringing it up. In my example I will be using eth0/1 and the ‘inside’ vlan, vlan1 with an existing ‘main’ ip range configured: 192.168.0.1/24; I will add another ip 192.168.1.1 so hosts from this range will also work behind the ASA:

1. first find out the mac address of the ethernet interface you will be using.
   sh interface Ethernet0/1
   this should show you the MAC address of the network interface.
2. force this arp address on the internal vlan:
   interface Vlan1
mac-address 0019.0726.xxxx
nameif inside
3. now let’s define a static arp entry for the IP we want to use as secondary, using the same mac address as the one from above, and enable proxy ARP on it:
   arp inside 192.168.1.1 0019.0726.xxx alias
   you can verify this is working properly using the show arp command that should return you the ip and mac address, like this:
   sh arp
inside 192.168.1.1 0019.0726.xxx alias
...
4. at this point any system on the local interface can use the ip as its default gateway and it will work just fine. We just need to ensure that return packets are coming back to the source, and this means we have to add a static route for this network on the inside interface (pointing to the main ip of the interface, let’s say 192.168.0.1 in my case):
   route inside 192.168.1.0 255.255.255.0 192.168.0.1 1
5. also we need to ensure that traffic is allowed between the same interface hosts, and same level of security interfaces:
   same-security-traffic permit inter-interface
same-security-traffic permit intra-interface
   and you probably want to be sure that access lists will allow the traffic from/to the newly added network.

That’s it…

The “Cisco way” to achieve this is to use separate vlans for each network range. Let’s try to speculate why doesn’t Cisco want this ‘feature’ in their firewalls? Maybe because on the standard license the box doesn’t support more than 2 full vlans (and 1 DMZ – limited)? and so you can’t do this using vlans even if you wanted… And you have to buy a license upgrade to support more? Or just to trunk them? What do you think? Do you think this is intentional to make peoples buy their higher end ASAs or upgrade to Security Plus license? (about 400-500$ extra)?

Note: the only limitation this method has is that the ‘secondary’ ip will work as expected as a gateway for the systems behind the asa, but will obviously not respond itself to network requests (like ping for ex.). If this is not acceptable, you should then go ahead and use the vlan method.

I hope this post will help other peoples that have the same frustration and will show them how to use any number of secondary ip they want. Even though this post was examplified using one ASA5505 it should work just fine on other ASAs and even on PIXes.

You might say that you are not saving any private information in memcached and just cache parts of your public pages. Well, even in this case you will want your memcached daemon protected and not open to DOS attacks. Basically, regardless of the data you will cache (even if this is public or backend sql private data), you will probably want to control who can access it and since memcached doesn’t have any built-in authentication and doesn’t require any user or password we will have to use external protection methods like a iptables or other firewall rules for protection.

1. Run the memcached daemon under a non-privileged user.

You should run the memcached daemon under a user with the least privileges needed for its purpose. You can safely run it with a user with minimal privileges like nobody for ex. as memcached doesn’t require any special privileges. Still, many people will run this as root, because they start it directly from a root shell (rc.local or similar) like:
./memcached -d -m 2048 -p 11211
(as it will start as the running user). Also this happens for ex. in the debian etch memcached package where the default is to run it as root (this is fixed in the lenny package that will run by default as nobody).

To run as a regular unprivileged user just use the -u switch to start memcached:
./memcached -d -m 2048 -p 11211 -u nobody
or if you use a configuration file like in the debian package edit it and add (-u nobody) and comment out the default entry -u root, inside /etc/memcached.conf.

2. Specify which IP address to listen on.

Since memcached has no built-in authentication as it is concerned to be as fast as possible the only way we can protect our memcached daemon is by blocking access to the daemon to anyone else than the hosts that need to have access. By default, memcached will listen on all IP addresses if the -l switch is not used. I recommend to use -l and have memcached listen only on the ip you need.

- if memcached is used just by the local system then use -l 127.0.0.1 and run it like:
./memcached -d -m 2048 -p 11211 -u nobody -l 127.0.0.1
- if you have a backend private network used by your servers use that to bind it only on the private ip, for ex: -l 192.168.0.1 like:
./memcached -d -m 2048 -p 11211 -u nobody -l 192.168.0.1
- if you really need to run this on a public ip, in this case just bind it on a single ip anyway (to ease maintenance if the box has more ips, etc.) using -l <ip>:
./memcached -d -m 2048 -p 11211 -u nobody -l <ip>
and depending from your setup filter the access to the TCP port 11211 for that IP to only the hosts that need to reach it and block all other access. If you run it on a different port (-p) or use more daemons on the same machine, do this for each one of them.

I hope you found this information useful and will help you have a safer and more secure memcached setup.

Changes in 3.0.18 include among others:

• New Guardian Digital Health Center for proactive hardware monitoring
• FwkNop and PSAD Tools for new levels of Security (featured in the the new Linux Firewalls book by Michael Rash)
• New stress-kernel package with a new stress testing suite
• Several new packages such as drbd (8.2.1), dsniff (2.3), psad (2.1), quota (3.15), sdparm (1.02), stress-kernel (3.0).
• The latest stable versions of MySQL (5.0.45), asterisk (1.4.14), kernel (2.6.23), openswan (2.4.10), samba (3.0.27a), syslog-ng (2.0.5), webtool (3.18), etc.
• Numerous fixes and features enhancements

A full list of changes in this release can be found here.

To download EnGarde Secure Linux Community 3.0.18 go here.

Description: How to disable the HTTP TRACE method on recent apache versions.

Most vulnerability scanners (like the popular nessus, but commercial ones also) will complain (normally as a low thread or warning level) about TRACE method being enabled on the web server tested.

Normally you will have this enabled by default, but if you want to test if it is really enabled on your server you just have to telnet on the port your web server is running and request for “TRACE / HTTP/1.0” if you get a positive reply it means TRACE is enabled on your system. The output of a server with TRACE enabled will look like:

telnet 127.0.0.1 80
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
TRACE / HTTP/1.0
Host: foo
Any text entered here will be echoed back in the response <- ENTER twice to finish

HTTP/1.1 200 OK
Date: Sat, 20 Oct 2007 20:39:36 GMT
Server: Apache/2.2.6 (Debian) PHP/4.4.4-9 mod_ruby/1.2.6 Ruby/1.8.6(2007-06-07)
Connection: close
Content-Type: message/http

TRACE / HTTP/1.0
Host: foo
Any text entered here will be echoed back in the response

Connection closed by foreign host.

Traditionally experts will suggest to disable this using some rewrite rules like:

RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^TRACE
RewriteRule .* - [F]
(this needs to be added somewhere in your main apache config file outside of any vhost or directory config).

Still this has the disadvantage that you need to have mod_rewrite enabled on the server just to mention one. But for apache versions newer than 1.3.34 for the legacy branch, and 2.0.55 (or newer) for apache2 this can be done very easily because there is a new apache variable that controls if TRACE method is enabled or not:
TraceEnable off
This needs to be added in the main server config and the default is enabled (on). TraceEnable off causes apache to return a 403 FORBIDDEN error to the client.

After setting this and reloading the apache config the same server as above shows:

telnet 127.0.0.1 80
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
TRACE / HTTP/1.0
Host: foo
testing...  <- ENTER twice

HTTP/1.1 403 Forbidden
Date: Sat, 20 Oct 2007 20:38:31 GMT
Server: Apache/2.2.6 (Debian) PHP/4.4.4-9 mod_ruby/1.2.6 Ruby/1.8.6(2007-06-07)
Content-Length: 320
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML(link) PUBLIC "-//IETF//DTD HTML(link) 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access /
on this server.</p>
<hr>
<address>Apache/2.2.6 (Debian) PHP/4.4.4-9 mod_ruby/1.2.6 Ruby/1.8.6(2007-06-07) Server at foo Port 80</address>
</body></html>
Connection closed by foreign host. 

Go to:
Main page of all my Apache Tips & Tricks