to use or not to use stateful capabilities

to use or not to use stateful capabilities

[__ Radien__]

Dear All

  For letting outside clients to access the webserver behind the
firewall:

  I want to know, what is the difference
1.   if I use connection states in rules tp accept for forwarding in the
firewall rulset:

Conn. State             -s                     -d                --proto
  -sport        -dport      SYN   ACK

New               outside_client    web_server         tcp       <1024  
       80     Yes   No
Established   web_server       outside_client      tcp       80         
     <1024 Yes   No
Established   outside_client    web_server         tcp       <1024      
   80     No   Yes
Established   web_server        outside_client     tcp       80         
     <1024 No   Yes


2.   or simple fwd rules:

iptables -t filter -A FORWARD -p tcp -s $WEBSERVER --sport 80 -d $OUT -j
ACCEPT
iptables -t filter -A FORWARD -p tcp -d $WEBSERVER --dport 80 -s $OUT -j
ACCEPT


I have a little knowledge about statefulness of the firewall, and can
not underestand what is the deference in such a case. I mean
practically.

Regards
__Radien__

Re: to use or not to use stateful capabilities

[__ Radien__]

here is just the table and may not be viewed well in my last post:

Conn.State   -s         -d         --proto   -sport  -dport   SYN   ACK

New          out        web_server  tcp       <1024  80       Yes   No
Established  web_server out         tcp       80     <1024    Yes   No
Established  out        web_server  tcp       <1024  80       No    Yes
Established  web_server out         tcp       80     <1024    No    Yes

Re: to use or not to use stateful capabilities

[Antony Stone]

On Monday 05 April 2004 11:49 am, __ Radien__ wrote:

> Dear All
>
>   For letting outside clients to access the webserver behind the
> firewall:
>
>   I want to know, what is the difference
> 1.   if I use connection states in rules tp accept for forwarding in the
> firewall rulset:
>
> Conn. State             -s                     -d                --proto
>   -sport        -dport      SYN   ACK
>
> New               outside_client    web_server         tcp       <1024
>        80     Yes   No

Why "source port <1024"?   I would have thought most often it will be >1024, 
although that's not always going to be true.

> Established   web_server       outside_client      tcp       80
>      <1024 Yes   No

I think you mean "SYN: Yes, ACK: Yes" here?

> Established   outside_client    web_server         tcp       <1024
>    80     No   Yes
> Established   web_server        outside_client     tcp       80
>      <1024 No   Yes
>
>
> 2.   or simple fwd rules:
>
> iptables -t filter -A FORWARD -p tcp -s $WEBSERVER --sport 80 -d $OUT -j
> ACCEPT
> iptables -t filter -A FORWARD -p tcp -d $WEBSERVER --dport 80 -s $OUT -j
> ACCEPT
>
>
> I have a little knowledge about statefulness of the firewall, and can
> not underestand what is the deference in such a case. I mean
> practically.

In this setup with only a single server behind the firewall, you are right in 
thinking there's not much practical difference between using the stateful and 
non-stateful versions of the rules.

However, once you've got five servers running behind the firewall (eg web, 
mail, ftp, dns, news), it's simpler to have one inbound rule per service plus 
one outbound rule for all the replies (- 6 rules) than to need one inbound 
rule plus one outbound rule per service (= 10 rules).

Also, stateful rules are much better for clients accessing the Internet, 
because it's impossible to think up a non-stateful rule which will allow 
replies inn to your network without also opening it up to port scanning 
attempts from people who use source port 80, 25, 53 etc for their port 
scanners.

Finally, some protocols such as ftp, irc etc are also very hard to support 
securely without using stateful rules.

So, in this simple case, pick whichever you prefer - no difference.

For a more complex situation, go stateful.

Regards,

Antony.

-- 
"Black holes are where God divided by zero."

 - Steven Wright

                                                     Please reply to the list;
                                                           please don't CC me.

Re: to use or not to use stateful capabilities

[Antony Stone]

On Monday 05 April 2004 11:59 am, __ Radien__ wrote:

> here is just the table and may not be viewed well in my last post:

Okay, thanks, here are my comments on just the table again, since it is much 
easier to read now :)

> Conn.State   -s         -d         --proto   -sport  -dport   SYN   ACK
>
> New          out        web_server  tcp       <1024  80       Yes   No
> Established  web_server out         tcp       80     <1024    Yes   No

That should be "Yes Yes" at the end, I think.

> Established  out        web_server  tcp       <1024  80       No    Yes
> Established  web_server out         tcp       80     <1024    No    Yes

All the client connections are shown as using ports <1024 - that should be 
"usually >1024", but even that isn't a certainty.   You should allow for 
clients using any port number at all.

Regards,

Antony.

-- 
If the human brain were so simple that we could understand it,
we'd be so simple that we couldn't.

                                                     Please reply to the list;
                                                           please don't CC me.

Re: to use or not to use stateful capabilities

[__ Radien__]

Antony, I made mistake in specifying the port greater than 1024, and I
meant  >1024.
----
Anyway, for a more complex configuration same as example you wrote,
can you tell me what is the benefit?
If I just accept packets w/ ACK flag that is of the conneciton has a
established state in the state table, rather than accepting every
packets that seems to be of a connection in established state. I mean
plz explain more :) , and give examples of disclosure if I don't use
stateful feature.

I wrote those rules, set of 4 rules. I can't underestand it's necessity,
yet.

Regards
__Radien__

Re: to use or not to use stateful capabilities

[Antony Stone]

On Monday 05 April 2004 1:53 pm, __ Radien__ wrote:

> Antony, I made mistake in specifying the port greater than 1024, and I
> meant  >1024.

Good, but remember that not all client connections will come from source
ports >1024 - some will be from ports <=1024, so you have to allow for both.

> Anyway, for a more complex configuration same as example you wrote,
> can you tell me what is the benefit?

Suppose you have the five servers I mentioned: web, dns, ftp, mail and news.

Let's see what rules we would need:

1. Stateful

iptables -A FORWARD -i $DMZ -o $EXT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i $EXT -o $DMZ -p tcp --dport 80 -d $WEB -j ACCEPT
iptables -A FORWARD -i $EXT -o $DMZ -p tcp --dport 53 -d $DNS -j ACCEPT
iptables -A FORWARD -i $EXT -o $DMZ -p udp --dport 53 -d $DNS -j ACCEPT
iptables -A FORWARD -i $EXT -o $DMZ -p tcp --dport 21 -d $FTP -j ACCEPT
iptables -A FORWARD -i $EXT -o $DMZ -p tcp --dport 25 -d $MAIL -j ACCEPT
iptables -A FORWARD -i $EXT -o $DMZ -p tcp --dport 119 -d $NEWS -j ACCEPT

2. Non-stateful

iptables -A FORWARD -i $EXT -o $DMZ -p tcp --dport 80 -d $WEB -j ACCEPT
iptables -A FORWARD -i $DMZ -o $EXT -p tcp --sport 80 -s $WEB -j ACCEPT
iptables -A FORWARD -i $EXT -o $DMZ -p tcp --dport 53 -d $DNS -j ACCEPT
iptables -A FORWARD -i $DMZ -o $EXT -p tcp --sport 53 -s $DNS -j ACCEPT
iptables -A FORWARD -i $EXT -o $DMZ -p udp --dport 53 -d $DNS -j ACCEPT
iptables -A FORWARD -i $DMZ -o $EXT -p udp --sport 53 -s $DNS -j ACCEPT
iptables -A FORWARD -i $EXT -o $DMZ -p tcp --dport 21 -d $FTP -j ACCEPT
iptables -A FORWARD -i $DMZ -o $EXT -p tcp --sport 21 -s $FTP -j ACCEPT
iptables -A FORWARD -i $EXT -o $DMZ -p tcp --dport 25 -d $MAIL -j ACCEPT
iptables -A FORWARD -i $DMZ -o $EXT -p tcp --sport 25 -s $MAIL -j ACCEPT
iptables -A FORWARD -i $EXT -o $DMZ -p tcp --dport 119 -d $NEWS -j ACCEPT
iptables -A FORWARD -i $DMZ -o $EXT -p tcp --sport 119 -s $NEWS -j ACCEPT

... and these rules don't even allow for the second data channel on FTP, and
active connections (which are very difficult to do with non-stateful rules)

You see how the stateful version is simpler, easier to understand, and in the
case of ftp, actually makes full use of the protocol *possible*?


The other example I quoted was internal clients.   Suppose for a moment that
you want to allow internal clients to access any service they like out on the
Internet.

1. The stateful version:

iptables -A FORWARD -i $EXT -o $LAN -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i $LAN -o $EXT -j ACCEPT

2. The non-stateful version:

iptables -A FORWARD -i $LAN -o $EXT -j ACCEPT
... and then you have to work out a way for reply packets to come in from
the outside, without simply opening up your entire network to the Internet
using a rule such as:

iptables -A FORWARD -i $EXT -o $LAN -j ACCEPT

I really wouldn't know how to do this securely, therefore I always use
stateful rules for the reply packets.

Hopefully this answers your question?

Regards,

Antony.

-- 
People who use Microsoft software should be certified.

                                                     Please reply to the list;
                                                           please don't CC me.

Re: to use or not to use stateful capabilities

[__ Radien__]

Thanks Antony, you did fine.

ByTheWay, about ftp service, do u mean that w/ iptables I can set such
rules that can detect and pass the data connection corresponding to
existing control-connection further than ordinary accepting
control-conneciton to fwd.

Does RELATED state match such cases?

Regards
__Radien__
  

Re: to use or not to use stateful capabilities

[Cedric Blancher]

Le mar 06/04/2004 à 09:01, __ Radien__ a écrit :
> ByTheWay, about ftp service, do u mean that w/ iptables I can set such
> rules that can detect and pass the data connection corresponding to
> existing control-connection further than ordinary accepting
> control-conneciton to fwd.
> Does RELATED state match such cases?

Yes.
For FTP, the date connection first packet will have RELATED state, for
it complies to informations that were gathered within control connection
by ip_conntrack_ftp module, allowing you to match and accept it.

-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread!

Re: to use or not to use stateful capabilities

[__ Radien__]

Thx Cedric

and this is my experience
---------------------------------------

#!/bin/bash
#

#Interfaces
IF0='192.168.0.67'
IF1='192.168.10.67'

#LAN's
LAN0='192.168.0.0/24'
LAN1='192.168.10.0/24'

###############################################
#Flush all the tables
service iptables stop

#or this one
#iptables -F OUTPUT
#iptables -F FORWARD
#iptables -F INPUT

#allow everything go through
iptables -P INPUT DROP
iptables -P OUTPUT DROP

#suite 1  //Does not worksfor data connection
#iptables -t filter -A FORWARD -i eth0 -o eth1 -p tcp -m state --state
RELATED,ESTABLISHED -j ACCEPT
#iptables -t filter -A FORWARD -i eth1 -o eth0 -p tcp --dport 21 -j
ACCEPT

#suite 2 //works for passive and active data connection 
#iptables -t filter -A INPUT -i eth0 -p tcp -m state --state
RELATED,ESTABLISHED -j ACCEPT
#iptables -t filter -A OUTPUT -o eth0 -p tcp -m state --state
RELATED,ESTABLISHED -j ACCEPT
#iptables -t filter -A INPUT -i eth0 -p tcp --dport 21 -j ACCEPT

#suite 3  //Does not worksfor data connection
#iptables -t filter -A INPUT -i eth0 -p tcp -m state --state
NEW,RELATED,ESTABLISHED --dport 21 -j ACCEPT

#suite 4  //works for active data connections
#iptables -t filter -A INPUT -i eth0 -p tcp -m state --state
RELATED,ESTABLISHED -j ACCEPT
#iptables -t filter -A OUTPUT -o eth0 -p tcp -m state --state
ESTABLISHED -j ACCEPT
#iptables -t filter -A INPUT -i eth0 -p tcp --dport 21 -j ACCEPT

#suite 5  //works for passive data connections
iptables -t filter -A INPUT -i eth0 -p tcp -m state --state ESTABLISHED
-j ACCEPT
iptables -t filter -A OUTPUT -o eth0 -p tcp -m state --state
RELATED,ESTABLISHED -j ACCEPT
iptables -t filter -A INPUT -i eth0 -p tcp --dport 21 -j ACCEPT


Cedric Blancher <blancher@cartel-securite.fr> wrote:
> 
> Le mar 06/04/2004 à 09:01, __ Radien__ a écrit :
> > ByTheWay, about ftp service, do u mean that w/ iptables I can set such
> > rules that can detect and pass the data connection corresponding to
> > existing control-connection further than ordinary accepting
> > control-conneciton to fwd.
> > Does RELATED state match such cases?
> 
> Yes.
> For FTP, the date connection first packet will have RELATED state, for
> it complies to informations that were gathered within control connection
> by ip_conntrack_ftp module, allowing you to match and accept it.
> 
> -- 
> http://www.netexit.com/~sid/
> PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
> >> Hi! I'm your friendly neighbourhood signature virus.
> >> Copy me to your signature file and help me spread!
> 



But, what does RELATED state good for other services? what is it's
application?

Regards
__Radien__