It would be amiss not to tighten TCP-IP with a few resilient settings suitable for Linux servers.
We'll use sysctl (system control), the Linux runtime kernel manager, to accomplish this.
Editing sysctl's TCP-IP settings
Open sysctl‘s configuration file:
OK. Let's get geeky. (Do wake up.) The following rules are given boolean values, 0 equating to ‘no' and 1 to ‘yes pretty please':
-
Refuse IP source routing
Do I need this? Yes.
When we ask for something, for instance by clicking a link, our data packets say they want to go to some destination.
‘Source routing' is where data packets are engineered to specify pitstops along the journey as well. This can be used for IP spoofing.
-
Prevent IP spoofing
Do I need this? Yes.
IP spoofing was covered in the Cop's Risk section. These ‘reverse path filters' run a simple IP check and work for all our network interfaces, whether eth0, venet0 etc.
-
Disable traffic forwarding
Do I need this? Probably but not always.
It's possible to manipulate a server's routing to and from resources.
Unless your box is some kind of a router, like maybe a VPN or SOCKS proxy, turn these off.
-
Secure against routing redirects
Do I need this? Almost certainly.
The administrative Internet Control Message Protocol has many uses, is best known for pinging a box to check it's online, but can be hacked quite easily.
ICMP can be used to route traffic via a man-in-the-middle, for instance, for info gathering and for DoS attacks.
-
Avoid smurf attack participation
Do I need this? Yes.
Smurf attacks are DoS attacks that heavily ping a target to sap its resources, maybe crashing the thing.
Unless we set this value a machines can be hacked to help in a distributed denial of service, effectively working as a zombie.
-
More ping safeguards
Do I need this? Probably.
We ping a host to check its availability, as we know. So do hackers, pinging for network clues. Unless you love pinging your box, ‘ignore_all'.
The ‘bogus_error_messages', meanwhile, are harmless but do clog up our logs (and our time) with irrelevant info, so we'll bin those.
-
Stop SYN flood DDoS attacks
Do I need this? Yes.
‘Syncookies' are a server-side cookie-ish measure to resist one type of denial of service attack. They're likely enabled but we'll make sure.
-
Log dodgy IP addresses
Do I need this? All in all, probably.
The ‘log_martians' rules say whether or not to log instances of, for instance, three of the issues we've tried to secure with rules above – source routed traffic, redirected traffic & spoofed IPs.
In case our previous rules are somehow side-stepped we may want to have this record to snore over.
For the sake of an easy life, here's that lot again in a single copy-paste. Don't thank me, just send whiskey:
Admittedly, many of these networking values are set by default. Then again, let's be sure. It's not a bad idea to know about them either.
Having added those TCP-IP directives to your sysctl file, save it and activate them like this:
And to check your active sysctl settings, do this:
Splendid.
More networking & sysctl reference
There's a lot of info online about what settings to use. Unfortunately very little explains ‘why', perhaps leading to broken functionality or a false sense of security. Here are three useful resources, though, to help with your network security awareness.
We'll be revisiting the server's network security soon enough, among other things protecting against (distributed) denial of service attacks, adding a really cool network intrusion detection system (a NIDS) and even giving our WordPress sites their very own web application firewall.
For now though, having kicked most of the Cop's network security tutorials into touch, I don't know about you but I'm off down the pub for a beer or three. 😛
See you later at WordPress Server Security: Defense in Depth, where we'll crank out the last of our ultra-tough WordPress server security. Hurrah.