IPtables allow all rules

Latest response

Most firewalls end with a deny all rule. IPtables starts with 3 allow all
rules by default for INPUT, OUTPUT and FORWARD (don't care about FORWARD in this case)

In one of the IPtables Tutorials they suggest changing:


But, if order matters then this will block everything and my SSH session will end, or
I won't be able to get in again.

Does that Rule actually go to the end? Even though it is at the beginning of the file...

Or do we need to use -I 9insert) asnd a line number to force it to the end?

It isn't clear because the format of the first 3 rules is different from all other examples
in the file.



one more question, about the numbers that follow:
:OUTPUT ACCEPT [70:7296]

What are those numbers, iptables put them in there... port range?

The first line you mention (:INPUT ACCEPT [0:0]) is the default policy for the chain. This is what is done to any traffic which doesn't match any rules in that chain.

Yes, you can lock yourself out of a system with incorrect firewall rules, though the same can be said for any network equipment. An old network engineer trick is to schedule a firewall stop or restart a few minutes into the future. This way if you lock yourself out, you just have to wait and you gain access again. You could do this with the command echo "service iptables restart" | at now + 5 minutes. You can view current jobs with atq and remove a job with atrm. See man at for more details.

The numbers in square brackets (:INPUT ACCEPT [0:0]) are packet and byte counters. You can save the current counters into the permanent rules with service iptables save. You can reset them with iptables -Z. You can also see per-rule counters with iptables -L -v.

The config file isn't the only source of information, you can see the manual page by typing man iptables.

We also have a small overview here in the product documentation. It might be a good place to start if you aren't familiar with the concept of iptables' chains.

The Frozentux iptables tutorial is a little old but much of it is probably still relevant. The in-depth packet inspection and theory is really great, though maybe some of the actual command syntax has changed over time.

Beyond that, I think the best way to learn iptables is to setup a couple of test machines and start playing. Two virtual machines will do. You can use the -j LOG target to see if/when traffic hits a certain point in the rules.

A program that I like to use for building elaborate iptables rules (with a GUI) is FWbuilder (http://www.fwbuilder.org/). Sometimes it is just useful to design a rule/chain then use it to inspect how it generated the command to put in /etc/sysconfig/iptables. Also, like Jamie said, you can easily lock yourself out of your SSH session. I like to make sure that established connections are never denied and keep a root terminal SSH session open if I need to service iptables stop.

:INPUT DROP simply means that, failing a match to an ACCEPT or other rule, incoming connection will be dropped. The inference here is that any other rule either in the INPUT chain or referenced from the input chain via a jumpout (i.e., "-J OtherChain") will get processed first. Thus, your ACCEPT rule for ssh will get processed first.

Having "DROP" as the default is good from a couple perspectives:
1) You don't need to ensure that there's an explicitly-stated deny rule (DROP is implicit)
2) As an extension of #1, since you don't need an explicitly-stated deny rule, you don't have to worry about where in the INPUT chain that rule sits (it should always be last, but, in a dynamic environment, it can end up not last if rules aren't added carefully)
3) As an extension of #2, you reduce the number of opportunities for getting "weirdness" when rules end up in incorrect orders - particularly with respect to your explicit-deny rule

One down side is, if you flush your rulesets rather than entirely-deactivating iptalbes; you'll completely stop your networking. Make sure that you've got local or remote console access to your host if you implement DROP as your implicit packet-handling rule.