state ESTABLISHED, RELATED

state ESTABLISHED, RELATED

[Andrew Kolt]

Hello everybody. I lately found my kernel logfile to be flooded with 
connections that seemed to have no meaning.
They did until a couple of days ago when, while running nmap on a 
computer on my network, i 'tailed' the logfile and discovered they were 
replies from the target computer to my request.

As a temp solution i added the following to the INPUT chain, in order to 
let those replies in:

-A INPUT -i eth0 -p tcp -s 0/0 -d zzz.zzz.zzz.zzz -m state --state 
ESTABLISHED,RELATED -j ACCEPT

Everything works well now, but i'd like to know if there's any other way 
to go about this and if the line above is "good" practice as far
as security goes.

with regards,
Andrew

Re: state ESTABLISHED, RELATED

[Simion Onea]

On Wed, 2009-07-15 at 23:25 +0300, Andrew Kolt wrote:
> As a temp solution i added the following to the INPUT chain, in order to 
> let those replies in:
> 
> -A INPUT -i eth0 -p tcp -s 0/0 -d zzz.zzz.zzz.zzz -m state --state 
> ESTABLISHED,RELATED -j ACCEPT
> 
> Everything works well now, but i'd like to know if there's any other way 
> to go about this and if the line above is "good" practice as far
> as security goes.

Hi Andrew!

In my opinion it is good practice. We have been using such a rule for
some time. In our set of iptables rules we have these in the beginning:

#------------------------------------------------------------------
# Drop invalid packets, unrelated to any connection
iptables -t filter -A INPUT -m state --state INVALID -j DROP

# Block and log several types of network scans that use malformed packets
# FIN / URG / PSH
iptables -t filter -A INPUT -p tcp --tcp-flags ALL FIN,URG,PSH -m limit --limit 5/minute \
  -j LOG --log-level notice --log-prefix "NMAP-XMAS:"
iptables -t filter -A INPUT -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP

# SYN / RST
iptables -t filter -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -m limit --limit 5/minute \
  -j LOG --log-level notice --log-prefix "SYN/RST:"
iptables -t filter -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP

# SYN / FIN -- scan (probably)
iptables -t filter -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -m limit --limit 5/minute \
  -j LOG --log-level notice --log-prefix "SYN/FIN:"
iptables -t filter -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP

# Accept packets related to previously established connections
iptables -t filter -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Accept locally generated packets unconditionally
iptables -t filter -A INPUT -i lo -j ACCEPT
#------------------------------------------------------------------

The same rules can also be applied to FORWARD chain.

Regards,
Simion.

Re: state ESTABLISHED, RELATED

[Richard Horton]

2009/7/16 Simion Onea <simionea@gmail.com>:!
>
> In my opinion it is good practice. We have been using such a rule for
> some time. In our set of iptables rules we have these in the beginning:
>
> #------
.... snip  long set of rules...

> The same rules can also be applied to FORWARD chain.
>

As a thought could you add those to a custom tables, say for the sake
of example shared:

iptables -N shared
iptables -A shared <whatever>

then in the input chain and forward chains make the first rule a jump to shared.

This makes it easier to manage the 'common' rule set as you only need
to change it at a single point rather than having to remember to
change both occurances...


-- 
Richard Horton
Users are like a virus: Each causing a thousand tiny crises until the
host finally dies.
http://www.solstans.co.uk - Solstans Japanese Bobtails and Norwegian Forest Cats
http://www.pbase.com/arimus - My online photogallery

Re: state ESTABLISHED, RELATED

[Andrew Kolt]

thanks for the replies. i will leave it on and further refine my rules.

ps. custom tables is the way to go, spares me and my colleague a lot of 
headache

regards,
Andrew Kolt

Re: state ESTABLISHED, RELATED

[Simion Onea]

On Thu, 2009-07-16 at 09:21 +0100, Richard Horton wrote:
> As a thought could you add those to a custom tables, say for the sake
> of example shared:
> 
> iptables -N shared
> iptables -A shared <whatever>
> 
> then in the input chain and forward chains make the first rule a jump to shared.
> 
> This makes it easier to manage the 'common' rule set as you only need
> to change it at a single point rather than having to remember to
> change both occurances...

Yes, I agree.