iptables and state

NotionCommotion · 04-14-2014, 07:56 AM

I've added some rules for ports 445, 139, 138, 137, 25, 10000, 443, and 80 to iptables. The rule for port 22 was already existing. I added rules using the following:

Code:

iptables -I INPUT 5 -p tcp --dport 80 -m state --state NEW -j ACCEPT

Questions:

Port 22 shows "state NEW" before "tcp dpt:22" unlike the rest. No difference, right? Just curious, but how do I make all the rules look this way (other than manually editing the file)?
I've seen examples of using "state NEW, ESTABLISHED". ESTABLISHED is redundant since I already allow all ESTABLISHED connections, right?
To add a state, I used "-m". This is for "match", right? Please elaborate.
Is adding state advised? iptables works fine without adding it. What is the purpose?

Thank you

Code:

[root@desktop var]# iptables --list -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:22
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:445 state NEW
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:139 state NEW
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:138 state NEW
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:137 state NEW
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:25 state NEW
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:10000 state NEW
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:443 state NEW
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:80 state NEW
REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
[root@desktop var]#

salasi · 04-14-2014, 12:14 PM

I apologise if I've mis-read your rules, but I'm not really used to reading them in this form.

Quote:

Originally Posted by NotionCommotion

I've added some rules for ports 445, 139, 138, 137, 25, 10000, 443, and 80 to iptables. The rule for port 22 was already existing. I added rules using the following:

Code:

iptables -I INPUT 5 -p tcp --dport 80 -m state --state NEW -j ACCEPT

I am unclear what your objective was in adding that rule, but it seems unlikely that you have achieved it. Can you explain in more detail, please?

Quote:

Originally Posted by NotionCommotion

Code:

[root@desktop var]# iptables --list -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:22
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:445 state NEW
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:139 state NEW
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:138 state NEW
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:137 state NEW
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:25 state NEW
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:10000 state NEW
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:443 state NEW
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:80 state NEW
REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited

So, first thing that you do is allow all related and established packets. Possibly fair enough, if you are going to do something different with the new packets, but not much point if you aren't...

You then accept all icmp packets.

The next thing that you do is accept all packets - any destination, any source. This makes both the previous rules irrelevant (if they weren't there accepting things, those same things would be accepted by this rule) but also most of the subsequent ones (as this rule has accepted all of the traffic, there is no traffic coming the way of subsequent rules).

So, functionally (ignoring the use of processor cycles), your rules appear to be equivalent to:

Code:

[root@desktop var]# iptables --list -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0

Which is simpler, clearer, but I'm not sure that its what you were trying to achieve.

(There is - potentially - a point in your 'reject all' rule, but I'm not sure if it applies to your situation. If this is a remote box (eg, a co-lo server) and hard to physically access, you might get worried about the situation in which you delete some rules and you could no longer access the box. In this situation there would be a case for the combination of a 'reject all' rule and a policy of accept. This are functionally the same as a 'reject' policy, but when you delete the wrong rules, you still have a chance of ssh-ing and putting it right. But, of course, the firewall rules are giving you no protection while you are doing it.)

NotionCommotion · 04-14-2014, 12:52 PM

Hi salasi,

The purpose of adding the rule was to allow the server to act as a webserver. The list of rules I included in my original post was misleading. Please see the below. Does this make more sense now? Do my original questions make sense now?

Thanks

Code:

> iptables -L -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 1002  136K ACCEPT     all  --  any    any     anywhere             anywhere            state RELATED,ESTABLISHED 
    0     0 ACCEPT     icmp --  any    any     anywhere             anywhere            
    2   219 ACCEPT     all  --  lo     any     anywhere             anywhere            
    0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere            state NEW tcp dpt:ssh 
    0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere            tcp dpt:microsoft-ds state NEW 
    0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere            tcp dpt:netbios-ssn state NEW 
    0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere            tcp dpt:netbios-dgm state NEW 
    0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere            tcp dpt:netbios-ns state NEW 
    0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere            tcp dpt:smtp state NEW 
    7  2371 ACCEPT     tcp  --  any    any     anywhere             anywhere            tcp dpt:ndmp state NEW 
    0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere            tcp dpt:https state NEW 
    1    60 ACCEPT     tcp  --  any    any     anywhere             anywhere            tcp dpt:http state NEW 
    4   463 REJECT     all  --  any    any     anywhere             anywhere            reject-with icmp-host-prohibited 

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 REJECT     all  --  any    any     anywhere             anywhere            reject-with icmp-host-prohibited 

Chain OUTPUT (policy ACCEPT 1048 packets, 245K bytes)
 pkts bytes target     prot opt in     out     source               destination

Smokey_justme · 04-14-2014, 01:23 PM

salasi has read it wrong.. (well, not his fault since the first display didn't show him the interface)...

@salasi: the rule that allows all is for the loopback interface (seen better in the post above this one)

@NotionCommotion:
1) No difference.. I think the difference in display is the parameter order.
2) Yes, those will get accepted from the first rule
3) Yes
4) Yes.. By default anything should be dropped except new connections to services you own and ESTABLISED or RELATED to everything else (or you may find it difficult to do even simple things, like browsing :P ). You can read about states here: https://www.frozentux.net/iptables-t...l#STATEMACHINE

However, you might want to consider rethinking your firewall for your ease of use..

Basically you should change the default policy for input to drop everything (and just abandon the last rule that says to abandon everything) and then add allow rules one by one (without the need to use a number to order the rules)

NotionCommotion · 04-14-2014, 02:50 PM

Quote:

Originally Posted by Smokey_justme

However, you might want to consider rethinking your firewall for your ease of use..

Basically you should change the default policy for input to drop everything (and just abandon the last rule that says to abandon everything) and then add allow rules one by one (without the need to use a number to order the rules)

Thanks Smokey,

I'm a little confused. Default policy? I thought the approach is always to white-list what you wish to allow through, and then have a drop everything at the end.

In regards to adding NEW state, I take it there must be more states that just NEW, RELATED,and ESTABLISHED. If not, then RELATED and ESTABLISHED are already passed, so adding NEW to later rules would not have any effect.

Smokey_justme · 04-14-2014, 03:39 PM

Well, the effect is the same.. But if a packet doesn't match any rule then the default policy will be applied.. So the last rule becomes obsolete..

Here are some example script you can browse throw: https://www.frozentux.net/iptables-t...EXAMPLESCRIPTS

They are more complex then you actually need, but it's a good read....

salasi · 04-14-2014, 06:49 PM

Sorry for having confused the situation with my first post (however, as you pointed out, it was based on the information available to me at the time).

This bit

Quote:

Default policy? I thought the approach is always to white-list what you wish to allow through, and then have a drop everything at the end.

I did already dealt with. The 'policy for a chain' (and only in-built chains can have a policy) is usually advised to be 'drop by default'. This can have the effect that on the fly edits to the rules for that chain, if they go wrong, can lock you out of the box. From that point of view, what you have done with the last explicit rule as 'drop' and the policy as 'allow' is less likely to lock you out when updates go wrong, but has the same function when everything goes right.

This always causes some issues, because the frequent advice is 'always policies should be drop' and people try to apply that as a law, without actually understanding what is behind it.

The next issue is ssh; you need to be taking adequate security measures with ssh (and it isn't apparent from this listing whether you are, or not).

Is ssh still on the default port? (moving port isn't a particularly great security measure on its own, but maybe useful in combination with other measures). If you just allow people to have an infinite number of goes at guessing your ssh password, eventually they will succeed, so what you have may be OK if you have something like fail2ban or denyhosts involved (or, if you are passwordless), but otherwise you probably have not done enough. (If you have moved from the default port, your listing of rules is presumably wrong, as the bit that says 'ssh' is no longer the ssh port.)

Although, that said, many people find that moving the ssh port is enough to keep much of the 'noise' out of their logfiles (but 'quiet logfiles do not a secure box make' - however, quiet logfiles may well make it easier to spot the exceptions that are the remaining serious attacks, rather than just the 'oh, look, here are today's few thousand noise attacks' with possibly something serious hiding in amongst them. And obviously, it does all depend on actually looking at the logfiles regularly.)

You have three rules for netbios packets, and I'm not sure why you need to be allowing netbios packets at all. What is there in your webserver utilising the Microsoft netbios protocol (and can netbios packets really come from anywhere)?

You are allowing tcp ndmp packets from anywhere. I'm not sure whether this is sensible, but will point out that ndmp can use both tcp and udp, so this may not have done enough, provided you are happy with ndmp (from anywhere).

Allowing http/https clearly makes sense for a webserver, but I wonder whether in reality there might be even more of an efficiency gain than is shown on this small example by moving those rules up behind, say, the 'lo' rule. After all, presumably, the majority of the packets should be one of those two... you could argue for dealing with these two via ipset, but, for just two destinations, it probably isn't a worthwhile complication.

NotionCommotion · 04-14-2014, 09:14 PM

Quote:

Originally Posted by salasi

Sorry for having confused the situation with my first post (however, as you pointed out, it was based on the information available to me at the time).

No, the apology is mine. Sorry for the confusion.

In regards to the rest of your post, let me digest it for a bit. Note that this server is currently for the benefit of my learning and not production, and has a hardware $20 firewall between it and the world, and the clients using netbios are behind my powerful firewall.