iptables not working as it should

rootaccess · 03-08-2014, 03:10 PM

Let me first start off by saying I have 4 years of linux experience under my belt mostly with Centos and Debian. Yes, debian/ubuntu doesn't have an iptables service, it uses ufw, but I dont use that. Generally on the debian side, people use scripts and load them, they are more robust that way as kernel parameters can be configured as well rather than editing the typical ruleset as found in Centos/RH's /etc/sysconfig/iptables file or a file thats been created on either system using 'iptables-save > /etc/iptables.rules' and thus reloaded with 'iptables-restore < /etc/iptables.rules'. In debian, one can insert the command 'pre-up iptables-restore < /etc/iptables.rules' in /etc/network/interfaces to load the ruleset before the network interface is loaded. Smart.

Here is the issue. I am noticing that if I have a given ruleset using the latter approach above, I can delete that rule in the /etc/iptables.rules file, run an iptables-restore and the rule is still valid, meaning the restore did not reload the new ruleset. Am I supposed to flush them first? Because let me tell you, sometimes they do work with some rules like blocking pings from outside and allowing only inside but I recently removed httpd access from outside, reloaded my ruleset only to find out it is STILL accessible from outside. Why?

If I am however to go the script route, and forget ever editing the actual ruleset that is automatically defined in /etc/iptables.rules (debian custom file generated automatically with iptables-save) or in centos' default /etc/sysconfig/iptables, wouldn't flushing the rules even for a millisecond allow some type of vulnerability to be exposed? I do tweak my conf files for each service first before any firewall ruleset as I am starting more and more to believe that firewalls are nearly useless. Security seems to be mostly configured in the conf files themselves (ssh, httpd, ntp, bind, etc) and if possible, at the edge routers, rather than using any iptables rules.

I would appreciate any responses especially in regards to reloading a script live which executes iptables -F. I am confused if iptables-restore deletes the old rule or just silently remains there. Thanks

brebs · 03-08-2014, 04:02 PM

You'd have to *show* your iptables-save output, for us to check it

Or debug it yourself, using e.g. LOG - an example:

Code:

$ipt -N logndrop
$ipt -A logndrop -m limit --limit 1/min --limit-burst 3 -j LOG --log-level warning --log-prefix "disallowed: "
$ipt -A logndrop -j DROP

Firewalls are very far from useless. They are another layer in the many layers of security, and can do some useful tricks, e.g. rate-limiting ("man iptables-extensions" and look at the sections on "commlimit" and "limit").

rootaccess · 03-08-2014, 04:28 PM

I understand but what I am trying to find out if running iptables-restore from a file actually flushes the tables or not? Im not sure of that.

brebs · 03-08-2014, 04:39 PM

It would be insane for iptables-restore not to, if you think about it

There's also this evidence, from "man iptables-restore":

Code:

-n, --noflush
don't flush the previous contents of the table. If not specified, both commands flush (delete) all previous contents of the respective table.

rootaccess · 03-08-2014, 04:42 PM

Appreciate the response. I have however reverted back to using a regular script to load my rules but in either case, I don't know why apache would still be accessible even though I removed it and reloaded the ruleset. Like I said, it seems to work mostly but I don't think you can really trust it.