This is a small list of how to harden your TCP/IP stack on your linux server.

Most modern server distributions already have a more hardened stack, but most of the time, you can even tighten it up further, which is generally a good idea in my humble opinion.

This list is by no means complete and I welcome more suggestions for further tightening down.

Decrease the ARP cache cleanup interval

First thing you can do is set the interval on your ARP to reduce the risk of ARP attacks. Google if you want to know more about that as explaining how that works is beyond this scope and would take an article on its own.

If you are using linux, ‘# man 7 arp’ command will give you extensive information on what ARP is and how to manipulate it. What we are looking for is ‘gc_interval’ and ‘gc_stale_time’. If you are using a recent version of linux, gc_interval and gc_stale_time is defaulted to 30 and 60 seconds respectively. If that is the case, you don’t need to change anything. You can check the values by issueing the following commands :

# sysctl -a | grep gc_interval
# sysctl -a | grep gc_stale_time

(yes i realize there is also a more neat way to do this : sysctl -n for example, but we want to get all settings from all interfaces as you can have more than 1)

It should produce output similar to this :

net.ipv4.neigh.default.gc_stale_time = 60
net.ipv4.neigh.lo.gc_stale_time = 60
net.ipv4.neigh.eth0.gc_stale_time = 60

net.ipv4.route.gc_interval = 30

If these values are different, we are going to change them with the sysctl command again :

# sysctl -w net.ipv4.neigh.eth0.gc_stale_time=60
# sysctl -w net.ipv4.route.gc_interval=30

If you want to make that permanent, put those commands in your /etc/rc.sysinit or /etc/rc.local.

Disable ICMP broadcast echo

To prevent your server being used for something called a smurf attack you need to disable your ICMP broadcasting.

if you want to check the current setting, do

# sysctl -a | grep icmp_echo_ignore_broadcasts

if that produces anything like the following result, you have to turn it off.

net.ipv4.icmp_echo_ignore_broadcasts = 1

turn this off by issuing the following command and putting that in your /etc/rc.sysinit or /etc/rc.local.

# sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=0

Disable ICMP routing redirects

There is something called ICMP routing redirect attacks. Google that if you want to know more about it.

to find out if your system is allowing ICMP routing redirects, issue the following command :

# sysctl -a | grep _redirects

If this produces the following result (or similar) you have your work cut out for you :

net.ipv4.conf.all.accept_redirects = 1
net.ipv4.conf.all.send_redirects = 1

# sysctl -w net.ipv4.conf.all.accept_redirects=0
# sysctl -w net.ipv4.conf.all.send_redirects=0

Disable IP source routing

Another way to hack your box is by spoofing IP adresses that you might trust as internal hosts, and thus allowing a spoofer access to services that you would normally deny them based on IP.

To find out if your box allows source routing, issue the following commands :

# sysctl -a | grep accept_source_route
# sysctl -a | grep forwarding
# sysctl -a | grep mc_forwarding

if your box is not acting like a router as well as a server, if any output on the NIC’s you are targeting is set to 1, disable them with similar commands again.

# sysctl -w net.ipv4.conf.all.accept_source_route = 0
# sysctl -w net.ipv4.conf.default.accept_source_route = 0
# sysctl -w net.ipv4.conf.eth0.accept_source_route = 0
# sysctl -w net.ipv4.conf.all.forwarding = 0
# sysctl -w net.ipv4.conf.eth0.forwarding = 0
# sysctl -w net.ipv4.conf.all.mc_forwarding = 0
# sysctl -w net.ipv4.conf.eth0.mc_forwarding = 0

Enforce packet sanity checking

If your server receives a packet where the source and/or destination field in the header don’t make much sense, it’s safe to assume you don’t want it around or do anything with it.

To check if this filter is on or off, issue the following command :

# sysctl -a | grep rp_filter

The result should be something like this :

net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.eth0.rp_filter = 1

If it is not set to 1, we will make it so :

# sysctl -w net.ipv4.conf.all.rp_filter=1
# sysctl -w net.ipv4.conf.eth0.rp_filter=1

Again add this to your /etc/rc.sysinit or /etc/rc.local if need be.

Log and drop ‘martian’ packets

Martian packets are packets that the host has no valid route back to it’s source. So it doesn’t know how to reply to them. These may be issued by attackers trying to obfuscate their location. Anyone that actually wants to use your services has no desire to obfuscate their location and prevent your box from contacting them back. So it’s safe to assume you want to drop these packets and log them for your review.

To check the state of this setting, issue the following command :

# sysctl -a | grep log_martians

net.ipv4.conf.all.log_martians = 0
net.ipv4.conf.default.log_martians = 0
net.ipv4.conf.eth0.log_martians = 0

These values ofcourse should not be 0, but 1.

# sysctl -w net.ipv4.conf.all.log_martians=1
# sysctl -w net.ipv4.conf.eth0.log_martians=1

Make your system more resistant to (SYN) flood attacks

The first and primary thing you can do to harden your system against a flood attack is simple : put in more RAM.
Each SYN packet has the purpose of establishing a connection to your server, which requires resources. Therefore having more RAM available to allocate those resources will make it more resilient against this form of attack.

Other things you can do on a linux server is enforcing the use of something called TCP SYN Cookies. This will prevent the server from really allocating resources for TCP buffers unless the server gets an ACK back on it’s own ACK/SYN reply to the client. If it does get an ACK back it means the client is legit only then will it allocate TCP buffers and use resources for it.

To check your current setting for this, issue the following command :

# sysctl -a | grep tcp_syncookies

net.ipv4.tcp_syncookies = 0

If you get this response, with the setting as 0, you will want to fix it.

# sysctl -w net.ipv4.tcp_syncookies=1

This is currently all that i can think of at this time that you need to do for hardening your TCP/IP stack on a linux server.

However, if you as a reader have more suggestions for me, feel free to drop me a line in the comment box.

VN:F [1.9.1_1087]
Rating: 7.0/10 (1 vote cast)
How to harden your TCP/IP stack, 7.0 out of 10 based on 1 rating