TCP/IP Stack Hardening

Modified 04 April 2007

If you run a UNIX-like operating system, you can make it more secure by modifying behavior of the TCP/IP implementation. This page lists modifications for the various TCP/IP protocols. For the most part, these are commands that would go into a boot script such as /etc/rc.sysinit or /etc/rc.local.

The tables only list the possible commands -- some tuning steps are not possible (at least as far as I know) on certain UNIX implementations. If there is a dangerous type of packet that might be allowed under a strict interpretation of the protocols, but which is currently considered to be risky, the listed commands frequently list how to both ignore inbound packets and refuse to send outbound packets. This prevents your host from being victimized and prevents it from being used to launch attacks.

This page only describes how to harden the TCP/IP stack on UNIX-like operating systems. It is based on the recommendations found in the following pages, plus my commentary and explanation:

• On a Linux system, see the file /usr/src/linux/Documentation/filesystems/proc.txt
• http://docs.sun.com/db/doc/816-0607
• http://secinf.net/info/unix/ip-stack-tuning.html

ARP

Decrease the ARP cache cleanup interval.

Consider static ARP (but also consider the maintenance problems!). This does not scale well to routine use on LANs, but it might be worth its trouble on a small sensitive LAN -- a DMZ LAN in your network perimeter, or a small LAN populated by a few sensitive servers and a router port. Remember that if you change the Ethernet card in one machine, you must then modify and re-run the static ARP script boot script on every host on that LAN!

If you want to do this, you will need a script like the following, with IP and MAC addresses changed as needed. For thorough paranoia, define a MAC address for all possible IP addresses on the LAN, even ones not in use. For the unused IP addresses, use a MAC address that you know will not exist on that LAN (maybe that of an Ethernet card on another LAN).

ICMP

Disable ICMP broadcast echo activity. Otherwise, your system could be used as part of a Smurf attack:

Disable ICMP routing redirects. Otherwise, your system could have its routing table misadjusted by an attacker.

Disable ICMP router solicitations and advertisements, and ICMP subnet mask requests and replies. An attacker might be able to use unsolicited advertisements and replies to misadjust host routing tables. An attack also might be able to use solicitations and requests to reverse engineer some details of your network infrastructure. It appears that you will have to do this with packet-filtering rules on the host.

Disable ICMP broadcast probes. Otherwise, an attacker might be able to reverse engineer some details of your network infrastructure.

IP

Disable IP source routing. The only use of IP source routing these days is by attackers trying to spoof IP addresses that you would trust as internal hosts.

Enforce sanity checking, also called ingress filtering or egress filtering. The point is to drop a packet if the source and destination IP addresses in the IP header do not make sense when considered in light of the physical interface on which it arrived.

Log and drop "Martian" packets. A "Martian" packet is one for which the host does not have a route back to the source IP address (it apparently dropped in from Mars). These days most hosts have a default route, meaning that there would be no such thing as a Martian packet, but to be safe and complete...

Enforce strict multi-homing for non-forwarding multi-homed systems. If a host is connected to more than one LAN, but it should not act as an IP router, make certain that it does not forward IP datagrams between networks. Maybe it is a firewall, or maybe it is just a multi-homed host.

TCP

Increase resiliance under heavy TCP load (which makes the system more resistant to SYN Flood attacks). There are five major steps to making a system more resiliant under heavy, possibly malicious, TCP load:

• Buy more RAM. Each inbound SYN packet is intended to establish a TCP circuit, which requires resources on the server. The TCP buffers require memory to be allocated.
• Use TCP SYN Cookies (Linux and BSD only). With TCP Syn Cookies, the kernel does not really allocate the TCP buffers unless the server's ACK/SYN packet gets an ACK back, meaning that it was a legitimate request.
• Reduce the allowed number of HALF_OPEN TCP circuits. Further requests are refused, a denial of service, but at least the server hasn't run out of memory.
• Reduce the amount of time an opening TCP circuit can stay in the HALF_OPEN state. The server is made less patient -- if the TCP circuit is not fully established quickly, it is dropped and the client, if legitimate but very slow, must start again.
• Reduce the amount of time a closing TCP circuit can stay in the TIME_WAIT state. Some clients are very rude, apparently Microsoft Explorer is particularly bad. They establish a connection, get their data, but then refuse to participate in cleanly shutting down the TCP circuit. At least for busy web servers, make them very impatient with such nonsense, dropping these no longer active connections and freeing resources.

The following show the vendor recommendations for tuning the TCP queue length and circuit establishment timers, and how to reduce TCP TIME_WAIT to 60 seconds.

Defend against TCP connection hijacking by following the recommendations of RFC 1948. Most UNIX implementations use RFC 1948 recommendations to generate initial sequence numbers, but Solaris (at least up through Solaris 8) needs a little help.

Increase TCP send and receive window sizes to at least 32 kbytes. But do not increase these above 64 kbytes unless you fully understand and support both RFC 1323 and RFC 2018.

Security Page

© Bob Cromwell May 2008. Created with /bin/vi, hosted on OpenBSD with Apache.    Root password available here