I'm trying to understand some basic functions of iptables running a VM Centos 6.6.
This is the default for INPUT chain:

The first rule, I assume, is that iptables accepts any connection (regardless of protocol or port) which has already been established or which is related (I know what that means, roughly, so there's no problem with that).

First of all, why is there an accept all anywhere anywhere if at the end of the chain there's a rule (which substitutes the policy, basically) that rejects all traffic? Aren't all the other rules made redundant? I know they aren't, because I've tested it, but I don't really understand why.

Secondly, if I wanted to give access only to ssh (no other traffic whatsoever) and create a stateful rule related only to ssh, how can I do it?
I tried:
before flushing the INPUT chain and changing its policy to DROP, but it has a strange behaviour. I have to wait for tens of seconds before it accepts the connection, so it means that it's processing something, which I suppose is a waste of resources. This is how the current INPUT chain looks:
Thirdly, why does the table show "state NEW tcp dpt:ssh" in this particular word order and not "tcp dpt:ssh state NEW"? The former is the default iptables script, the latter is the rule introduced manually by myself.

You need to include the "-v" when you run "iptables -L" or else you won't see the input or output interface parameters in the rule. You will probably find that "anywhere" ACCEPT rule applies only to the "lo" interface.

Oh, thank you. That's quite basic and it suddenly clears things up for me. What about the other things?

First of all the single most efficient way to show Netfilter rule sets is with the command because this lists all rules and as they are in use. Posting output of that also makes it easier for us to edit and gauage the effect of proposed changes and for you to reload it using 'iptables-restore'. Next to that have you tried searching LQ for common iptables rule sets? And have you visited the single most comprehensive document at https://www.frozentux.net/documents/iptables-tutorial/?

I have been reading what I consider to be a rather good tutorial and yes, I've been been searching for common iptables rule sets, but sometimes that is not enough. People often need help with their particular configuration, help which I see is quite difficult to get on this forum, even after I've read tutorials, searching and so on. This is extremely daunting, especially for newbies.

What you seem to not understand (from my point of view, I'm not trying to be offensive, really, I'm just a little bit frustrated, because this isn't the first time I've received these almost dismissive answers) is that one can understand the theory pretty well and can search for examples and understand them too, but if you lack the necessary experience, there's always something subtle (not at all subtle for the experienced) that the beginner seems to omit. And that's what I was trying to identify.

I wasn't lazy and since I started this thread I've been constantly trying to learn, etc. and I've changed my iptables.
As you can see, I've changed the ssh rules (so instead of having two INPUT rules on ssh, I wrote one in INPUT and another one in OUTPUT) and I've tried to make it secure using stateful rules.

The reason for the delay I wrote about in the first post I still don't understand - and I don't think there's actually any site I can get this information from if there's no one who can answer specificially to my case.

So my questions are, are the ssh rules reasonably well done? Secondly, what was wrong exactly with my first ssh configuration? I know it was tortuous, and I know now there's no use for the second INPUT ssh rule, as is redundant, but I don't understand what was going on exactly and why the delay. (in my previous configuration, the OUTPUT was flushed and had an ACCEPT policy)

There's a couple of problems here, one of which you could not have known about unless you used CentOS earlier, and that is that CentOS 6.n no longer comes with a default iptables rule set file "/etc/sysconfig/iptables": to correct that you have to first install the "system-config-firefall-tui" package. The second thing then becomes that some of your questions make no sense because the rule set you've used isn't the CentOS or RHEL default. Now this is not the default filter table rule set but it looks something like this:

A more optimized and less exposed take on that could look like:
This simple policy ensures no hosted services are exposed (unless you do so explicitly), allow existing connections to pass and allow new outbound connections. The rule flow ensures loop back device traffic is out of the way (unless you have other Ethernet devices you don't need to specify a device name again in the same chain), existing (== allowed) connections aren't filtered further. Logging is enabled for SSH (the only allowed inbound service) for auditing reasons, new connections are limited to 1 per second and access is only allowed from the 192.168.0.0/24 subnet. Note SSH best practices like not allowing root to SSH in, only allowing pubkey auth and limiting allowed Users and Groups in /etc/ssh/sshd_config, and using a tool like fail2ban or equivalent are strongly suggested.


I'd say it depends on how you write the rule, you can test that yourself, though it really does not matter as long as the effect of the rule is the same.

1 members found this post helpful.

Thank you for your ample reply. Really appreciate it.

I am not sure though about the default rule of /etc/sysconfig/iptables. I installed Centos 6 some years ago and I can't remember exactly what options I've chosen during the installation. I did (probably) specify ssh to run and that must have created an access rule to it in the iptables scripts. But what I'm sure of is that the sysconfig iptables file did have what I'd call a default rule, meaning that I haven't tinkered with iptables at all until now. I know that # service iptables save generates a backup iptables file, so I'm going to list what the file says:
So believe me when I say that I haven't changed it a bit (with the exception of what I might have done during the installation - which was a basic graphical installation). That's why I called it default script. So what do you think has happened actually?

Now that I think about it, I should also mentionat that I actually have two Centos 6.6 (a virtual machine and a proper PC). I've recently installed the VM and that was the default sysconfig iptables file rule for the VM too. The VM is minimal, doesn't have any graphic environment, etc.

One more thing, is there any reason why I shouldn't replace the ssh ACCEPT rule with
Is it about visual consistency or is there any other significant difference?

Thank you!

[later edit]
Ok, I've just read that -m state is becoming deprecated and is probably going to be removed altogether with further kernel upgrades.

[later edit 2]
Ok, now I see that the file that I've listed is basically the same as what you've said are the defaults. So the problem was that in the first post I only showed what the INPUT rules are listing iptables -L INPUT, instead of just doing an iptables-save or a cat on /etc/sysconfig/iptables. But my first post is NOT inconsistent with these default values, it's only incomplete, really (and there's no -v option, which of course creates even further confusion, especially because of the lo rule).

Another question: would it be better to change the default policy of OUTPUT to DROP and write another rule specific to what I want to allow? Or it doesn't make any difference?

All I know is the "old school" default /etc/sysconfig/iptables rule set was easy to spot for using the filter table INPUT chain name "RH-Firewall-1-INPUT".


It would be more precise to say that from kernel version 3.7 on the Netfilter "state" module will be deprecated and only "conntrack" remains.


No, I explicitly said mine aren't defaults. "Minimal" would have been a better choice. And given that rules are parsed in top down order the rule set isn't the same ;-p Intricacies I'm sure and only matters if you're into stuff like this and such.


It makes a huge difference.

From the Frozentux document:
*Suffice to say this is clear evidence it really is good to read the document twice or thrice.

1 members found this post helpful.