30

Specifically

I have an iptables ruleset defined on a server running CentOS. Am I guaranteed / can I guarantee / how can I guarantee that when networking comes online (either at machine boot, or after restarting the network service) the iptables ruleset is already applied (and if iptables failed to start up or failed to apply the ruleset the network interface will fail to come up)?

(I know this is a noob question, but I've never run a server on anything but trusted networks behind a masquerading DHCP NAT and a firewall, so... expect noob questions from noobs.)

Parthian Shot
  • 1,155
  • 3
  • 16
  • 32
  • 15
    Really not a noob question at all. This is essentially how hackers got into the PlayStation network back in 2011, causing 24 days of outage and $15MM in settlements. When their firewalls rebooted (as they did monthly) the firewall went wide open for a few moments - apparently long enough. – Chris S Jul 29 '14 at 18:21
  • @ChrisS The weirdest thing about that, to me, would be that I'm sure the sysadmins responsible for that network would almost certainly be smart enough to balk if someone suggested turning off the firewall, but didn't bat an eyelash at, monthly, turning it off... and then back on again. Not sure which combination of [these](http://en.wikipedia.org/wiki/List_of_cognitive_biases) would explain it, though. – Parthian Shot Jul 30 '14 at 19:23
  • Another option is to disable to port on the network switch until the server is fully booted -- if you are on site and have switch access. This is not ideal, but it would definitely work, unless the server had a network dependency such as NFS. – jftuga Aug 05 '14 at 21:16
  • @jftuga Well, sure. But then the server wouldn't be connected to the Internet, and so that solution technically doesn't fall under the purview of this question. If I'm on site, I could just unplug the ethernet cable during reboot. And the underlying issue would remain with the port-blocking solution, anyway; that another computer attacking over the network wouldn't be stopped by the local firewall. If the router is hacked, or malfunctions, or someone else on the local net is compromised, the game is still over. – Parthian Shot Aug 06 '14 at 15:28
  • @jftuga In fact, the issue is even worse than that. Assuming someone has already gotten a piece of software to run on the local machine, but my firewall does egress filtering, say the rule is that outgoing packets are only allowed if they are established or related, and incoming new connections are only allowed to port 80. Normally, that would prevent a reverse shell from an unprivileged account. But if the connection is initiated on boot, it will be sustained through firewall initialization. I suppose that also means the firewall rules should change, but that's an easy mistake to make. – Parthian Shot Aug 06 '14 at 15:30
  • @ChrisS Wait, how did you know that about the Playstation hack? I haven't been able to find anything so specific. – Parthian Shot Jul 16 '15 at 18:22

3 Answers3

18

Out of the box, you are guaranteed that iptables will start before the interface is brought up by the order of the startup scripts. Look at the "chkconfig" line in each startup script and you will see the runlevels it is "on" when active, the start order, and the stop order.

You are not guaranteed that the interface will not be brought up if the iptables ruleset was not applied properly (or at all).

Example:
chkconfig: 2345 08 92
This line states that the service in question will be active in runlevels 2, 3, 4, and 5, and will start at 8 and stop at 92. Anything with a greater "start" value will start only after this script completes, but this script erroring out is considered a completion and will not prevent downstream scripts from running.

Please note this answer applies to CentOS 6 and earlier, not necessarily to CentOS 7. I haven't personally researched 7 sufficiently to answer this question for 7.

John
  • 8,920
  • 1
  • 28
  • 34
  • 1
    +1 And... not to look a gift horse in the mouth, because you're answer is quite helpful, but... Would you happen to know of any standard way to give services a dependency order, so that if one fails early in the chain subsequent ones don't start? Ooh- and also if someone manages to crash the firewall (somehow) that the network interface will "go down with the ship"? Ideally, I'd want everything to fail safe, even on the offchance someone has an 0day to DoS the firewall... – Parthian Shot Jul 29 '14 at 18:33
  • 5
    With SysV startup scripts (i.e. CentOS 6 and earlier), there isn't a good way to do so. CentOS 7 does dependencies as you want - if B depends on A and A fails, B doesn't start. For 7, to see dependencies use `systemctl list-dependencies --all` (I just looked at the man page for that 30 seconds ago). – John Jul 29 '14 at 18:35
  • While that news is a bit disappointing (I am on 6 at the moment), at least I now know that modifying the init scripts is an acceptably awful hack. – Parthian Shot Jul 29 '14 at 18:42
  • 5
    Be very careful about modifying init scripts - doing so can cause false alarms on any intrusion detection software you may have in place, and modifications will be overwritten if the `initscripts` package is ever updated (e.g. an errata release). I really don't recommend doing that. – John Jul 29 '14 at 18:45
  • I haven't set up an IDS yet, so false alarms aren't a problem at the moment (the server isn't live yet, and I know I'm nowhere near ready to deploy; this question is part of my preparation. But I am going to put in a HIDS). I'll be as careful as I possibly can, and if there's a way that doesn't involve manually modifying core parts of init's config, I am definitely doing that. – Parthian Shot Jul 29 '14 at 19:11
1

You can also use the ifup-post option in centos:

/etc/sysconfig/network-scripts/ifup-post

Called when any network device EXCEPT a SLIP device comes up. Calls /etc/sysconfig/network-scripts/ifup-routes to bring up static routes that depend on that device. Calls /etc/sysconfig/network-scripts/ifup-aliases to bring up aliases for that device. Sets the hostname if it is not already set and a hostname can be found for the IP for that device. Sends SIGIO to any programs that have requested notification of network events.

Could be extended to fix up nameservice configuration, call arbitrary scripts, etc, as needed.

This script runs and after the above ( ifup-route and ifup-aliases )it looks for ifup-local

if [ -x /sbin/ifup-local ]; then
   /sbin/ifup-local ${DEVICE}
fi

So you can create this file and make sure it calls iptables again for example using iptables-restore: 

iptables-restore < /etc/sysconfig/iptables
Moti
  • 287
  • 1
  • 2
1

A little addendum: to ensure the needed rules will be there next time you boot the server, save it with

sudo sh -c "iptables-save > /etc/iptables.rules"
manu
  • 11
  • 1