Procsys recommendations
/proc/sys settings recommendations
As could be seen from System boot procedure section, your Debian system can automatically have its kernel configured on boot, using the sysctl utility; all you have to do for that is to edit ../etc/sysctl.conf. The file will usually be there already, but every line is commented out. Read the manuals (man sysctl and man sysctl.conf) to see how they work; we're not going to explain that here.
What we're going to look at, is what settings we would want to make in sysctl.conf, and more importantly, why. For this, we're going to discuss our own sysctl.conf line by line.
IPV4 Network settings
The /proc/sys virtual filesystem is a powerful way to manipulate the way your kernel handles network packages coming in (and going out) of your machine. For security purposes, we make the following settings - already in sysctl.conf notation:
- net.ipv4.icmp_echo_ignore_broadcasts = 1
This setting makes sure our server will not respond to echo requests to a broadcast address. This is because when the source address of the echo request is forged, your server will be replying with echo replies to an innocent machine, that might well be flooded with echo replies it didn't request (this is a classic network dDOS attack). - net.ipv4.icmp_echo_ignore_all = 0
It is possible to make your server more "stealthily" by not having it respond to echo requests. However, since ping is one of our favourite diagnostic tools, we do not want to disable echo replies on our machines (you might, ofcourse). - net.ipv4.icmp_ignore_bogus_error_responses = 1
- net.ipv4.conf.all.accept_redirects = 0
An ICMP redirect is an error message sent by a router to the sender of an IP packet. Redirects are used when a router believes a packet is being routed sub-optimally and it would like to inform the sending host that it should forward subsequent packets to that same destination through a different gateway. However, no network should need ICMP redirect; though ICMP redirects serve to point out issues with sub optimal routing, network re-architecting should be favored over their use. Well designed networks should never lend themselves to the reliance on or desire for ICMP redirects for reasons of performance, consistency, reliability, and security. Therefore, we see no need to enable this setting on our routers/gateway servers. - net.ipv4.conf.all.rp_filter = 1
Enabling rp_filter means Reverse Path filtering; it enables the kernel to do Source Address Verification; this prevents spoofing attacks against our internal networks. If a network packet is incoming on an external interface with an internal source- and destination IP address (probably forged by an attacker), then the kernel will not allow the packet, based on it having invalid source address. This should never harm legitimate network traffic, but will stop certain network attacks.
- (external addresses can still be spoofed)
- net.ipv4.conf.all.accept_source_route = 0
Source Routed packets can ask for a specific route; however they can be misused to route packets around firewalled interfaces. To our knowledge, no sane network configuration requires Source Routing these days, so we (explicitly) disable it. - net.ipv4.tcp_syncookies = 0
By default SYNcookies are off, and we don't enable them either, but if you believe you're under a SYN attack, you might want to enable this setting (either for one time only, or permanently). Setting TCP SYN cookies enables SYN flood protection, but causes some problems as well, including masking legitimate overloading. WARNING - only enable SYN cookies if you really understand what it does! - net.ipv4.conf/all/log_martians = 0
Setting log_martians "on" means the kernel will log to the kernel log all packets (including their source addresses) that have no known route. If it is set off, those "martians" are dropped silently. We usually don't need logging on Martians, but you might want to enable it for diagnostic purposes.
Note that we DON'T use sysctl.conf to enable forwarding on our multi-homed servers; it is too easy to make a mistake, and have a system with forwarding enabled and the firewall disabled. Therefor, we program our firewall to directly manipulate the forwarding property, and then only after the firewall is fully initilised.
Other settings
Nope, that's just it; we only make changes to the network settings :-)