Using network security kernel tunables to protect your system

If you are not using an advanced firewall to protect your system, it is possible to protect it against TCP and UDP protocol-level attacks by setting a list of kernel parameters, or tunables. Most operating systems allow this type of setting for protection against flood attacks, spoof, and ICMP-type attacks.

In this recipe we will enable network protection using kernel tunables. All steps will be performed as root on nodeorcl1.

How to do it...

All tunables must be added to /etc/sysctl.conf to be persistent across system reboots.

To enable them immediately execute the following command:

[root@nodeorcl1 xinetd.d]# sysctl –p

All security kernel tunables require restarting the network service to take effect:

[root@nodeorcl1 xinetd.d]# service network restart

The following is the list and description of tunables:

1. Enable TCP SYN cookie protection: A SYN attack or SYN flood is a form of denial of service attack in which an attacker sends a succession of SYN requests. The main scope of this type of attack is to consume all the resources from a machine and to make it irresponsive to subsequent network traffic by filling up the SYN queue . SYN cookies allow a server to avoid dropping connections when the SYN queue fills up. One well known tool with SYN flood capabilities available on Linux is hping, but there are several other free tools that can generate this kind of attack. These days almost all major Linux distributions have this tunable set to 1. To enable TCP SYN cookie protection or SYN flood protection, add the following network tunable to /etc/sysctl.conf:

   net.ipv4.tcp_syncookies = 1
   

   More details about TCP SYN cookie attacks can be found at the following link: http://etherealmind.com/tcp-syn-cookies-ddos-defence/

2. Disable IP source routing: Source routing is a technique whereby an attacker can specify a route through the network from source to destination. This will force the destination host to use the same route as the source packets. To disable IP source routing add the following tunable to /etc/sysctl.conf:

   net.ipv4.conf.all.accept_source_route = 0
   

3. Disable ICMP redirect acceptance: ICMP protocol is used by routers to redirect a source host to an alternative better path to other networks. An intruder could potentially redirect the traffic by altering the host's routing table and changing the traffic route. To disable ICMP and redirect acceptance, add the following tunable to /etc/sysctl.conf:

   net.ipv4.conf.all.accept_redirects = 0
   

4. Enable IP spoofing protection: IP spoofing is a technique where an intruder conceals his identity by sending out packets that claim to be from another host. The manipulation of packets is made by forging the IP header's address making them appear as though they are sent from a different address. To enable IP spoofing protection add the following tunable:

   net.ipv4.conf
   .all.rp_filter = 1
   

5. Ignore ping requests: If you want or need Linux to ignore ping requests, to enable ignoring of ICMP requests, add the following tunable:

   net.ipv4.icmp_
   echo_ignore_all = 1
   

   To enable logging for spoofed packets, source routed packets, and redirect packets, add the following tunable to /etc/sysctl.conf:

   net.ipv4.conf.all.log_martians = 1
   

6. Enable bad error message protection: Bad error messages are usually used in DoS type attacks and are indented to fill up the the filesystems on the disk with useless log messages. To enable bad message protection add the following tunable to /etc/sysctl.conf:

   net.ipv4.icmp_ignore_bogus_error_responses = 1
   

How it works...

The protection is activated at kernel level and it is very effective. There are slight differences between Linux distributions but you should find the same parameters that address network protection at kernel level.

There's more...

Usually these modifications should be tested first. Placing your server behind a properly configured firewall is typically the preferred way to enable these types of protections. However, a database administrator tasked with protecting sensitive data may want to consider kernel-level tunables as a technique that may provide an additional level of protection, or that adds a defensive layer in case of a firewall configuration issue.