Re: IPFW - keep-state/check-state And setup/established Confusion

2003-03-20 Thread Giorgos Keramidas
On 2003-03-19 15:19, Drew Tomlinson [EMAIL PROTECTED] wrote:
 I'm using ipfw2 to setup a firewall on 4.8-RC for my home network.
 I used the rule set at

 http://www.bsdtoday.com/2000/December/rc.firewall.current

 as an example but am confused regarding the differences between
 setting rules using setup/established and keep-state /
 check-state.  I've read the ipfw man page and understand that
 setup/established matches syn/ack bits in a packet where
 keep-state/check-state actually creates a dynamic rule.
 But not being real knowledgeable about how IP packets are
 constructed, I'm not sure what this means in the real world.

It means that `established' uses a very simple test of packet contents
to find out if this packet belongs to an existing connection.  This
simple test is good enough for some packets, but will match packets
that are not part of a real, existing connection too.

 If I understand it correctly, the example at BSDToday basically uses
 setup/established to allow traffic in for services that I allow.
 So in my case I would use it for FTP, SMTP, SSH, and HTTP.  Then the
 rule set uses keep-state/check-state for connections originating
 from my internal network to the outside world.  But why should I not
 use keep-state/check-state for everything by adding my check-state
 rule near the top and then adding the following rule for incoming
 services:

 ipfw add allow ip from any to $inwr 21,22,25,80 keep-state

As a matter of fact, you should.  The 'established' keyword is not as
nice as a real, stateful firewall (which {keep,check}-state gives you).

 I've actually done this and it is working but I'd like to know if
 this is a good or bad idea and why.

In a reply to a private message, a few weeks ago, I tried to explain
the different to someone.  Here's the message, without any names.
I hope this helps a bit :-)

From: Giorgos Keramidas [EMAIL PROTECTED]
Date: Wed, 26 Feb 2003 03:51:08 +0200

On 2003-02-25 17:15, you wrote:
On Wed, 26 Feb 2003 02:36:18 Giorgos Keramidas wrote:
On 2003-02-25 16:29, you wrote:
 On Wed, 26 Feb 2003 02:25:12 Giorgos Keramidas wrote:
 
 The changes from your own set of rules are summarized below: [...]

 Indeed!  I do have the variables listed defined, and have natd
 configured and working.  Thank you very much--not only did you
 answer my question, but gave me a better understanding of ipfw!

I did?  Oh, cool :)))

 Just wondering, do I not need the 'established' rule to let existing
 connections persist?

The ipfw manpage contains this description of the 'established'
keyword, which means a lot to someone who knows how TCP handles
connections and what the bits RST and ACK are used for.

 established
 Matches TCP packets that have the RST or ACK bits set.

This is, alas, a very cryptic and strange thing for someone who
doesn't know the internals of the TCP protocol.  Which is something
that I wouldn't expect the casual reader of the manpage to know.  The
detailed explanation of how this keyword matches packets is very large
for me to include in a single email reply, and I won't even attempt to
do something like this.

For the moment, let's say that 'established' is a very simplistic way
of filtering packets that are part of an existing connection.  The
keep-state and check-state combination that I used instead of your
initial established ruleset works a lot better and has a quite better
chance of blocking packets that are not part of a real TCP
connection.  Bearing this in mind, you might find it easier to accept
the keep-state/check-state pair as a safer way of filtering.  The
keep-state keyword creates a dynamic rule for ever successful
connection that matches, and check-state runs through the list of
dynamic rules looking for matches before passing a packet.  It's safer
to use because the dynamic rules are created by keep-state to match
the existing connections and then deleted after the connection dies;
instead of allowing through any packet that is possibly part of an
existing connection because it includes one of ACK or RST flags or
both.

When you use the 'established' keyword, your firewall is open to
attacks by ingenious hackers who know the way TCP works and create
their own 'custom' packets, including RST or ACK flags, in the hope
that their packet will pass through improperly configured firewalls
(such as those who depend on 'established' for their blocking rules).
Once a packet has been allowed through by an 'stablished' rule it will
probably have a chance to reach the internal network, going out
through a different interface, and let the attacker establish a
limited but nevertheless important channel of information retrieval
for your internal network.

Now, after all this, you might be wondering if 'established' is so
   

Re: IPFW - keep-state/check-state And setup/established Confusion

2003-03-20 Thread Drew Tomlinson
- Original Message -
From: Giorgos Keramidas [EMAIL PROTECTED]
To: Drew Tomlinson [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Thursday, March 20, 2003 8:52 AM

 On 2003-03-19 15:19, Drew Tomlinson [EMAIL PROTECTED] wrote:
 I'm using ipfw2 to setup a firewall on 4.8-RC for my home network.
 I used the rule set at

 http://www.bsdtoday.com/2000/December/rc.firewall.current

 as an example but am confused regarding the differences between
 setting rules using setup/established and keep-state /
 check-state.  I've read the ipfw man page and understand that
 setup/established matches syn/ack bits in a packet where
 keep-state/check-state actually creates a dynamic rule.
 But not being real knowledgeable about how IP packets are
 constructed, I'm not sure what this means in the real world.

It means that `established' uses a very simple test of packet contents
to find out if this packet belongs to an existing connection.  This
simple test is good enough for some packets, but will match packets
that are not part of a real, existing connection too.

 If I understand it correctly, the example at BSDToday basically uses
 setup/established to allow traffic in for services that I allow.
 So in my case I would use it for FTP, SMTP, SSH, and HTTP.  Then the
 rule set uses keep-state/check-state for connections originating
 from my internal network to the outside world.  But why should I not
 use keep-state/check-state for everything by adding my check-state
 rule near the top and then adding the following rule for incoming
 services:

 ipfw add allow ip from any to $inwr 21,22,25,80 keep-state

As a matter of fact, you should.  The 'established' keyword is not as
nice as a real, stateful firewall (which {keep,check}-state gives you).

 I've actually done this and it is working but I'd like to know if
 this is a good or bad idea and why.

In a reply to a private message, a few weeks ago, I tried to explain
the different to someone.  Here's the message, without any names.
I hope this helps a bit :-)

Thank you for the explaination.  It does help.  One other question I have is
that I never see the check-state packet count incrementing.  However I
vaguely recall reading somewhere that it doesn't, even when packets pass via
the rule.  Is this correct?

I'm happy to know that the keep/check-state rules are the way to go.  It
makes my rule set simpler too.  Now on to traffic prioritization via
dummynet!  :)

Thanks again,

Drew


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-questions in the body of the message


Re: IPFW - keep-state/check-state And setup/established Confusion

2003-03-20 Thread Giorgos Keramidas
On 2003-03-20 09:22, Drew Tomlinson [EMAIL PROTECTED] wrote:

 It does help.  One other question I have is that I never see the
 check-state packet count incrementing.  However I vaguely recall
 reading somewhere that it doesn't, even when packets pass via the
 rule.  Is this correct?

I'm not sure if this is the way it works.  I'd have to check the
kernel side of ipfw to see if this works this way, and IPFW2's
kernel part is far from understandable for a kernel newbie like me :)

- Giorgos


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-questions in the body of the message


Re: IPFW - keep-state/check-state And setup/established Confusion

2003-03-20 Thread Giorgos Keramidas
On 2003-03-20 11:56, James Long [EMAIL PROTECTED] wrote:
 On Thu, Mar 20, 2003 at 06:52:32PM +0200, Giorgos Keramidas wrote:
   use keep-state/check-state for everything by adding my check-state
   rule near the top and then adding the following rule for incoming
   services:
  
   ipfw add allow ip from any to $inwr 21,22,25,80 keep-state
 
  As a matter of fact, you should.  The 'established' keyword is not as
  nice as a real, stateful firewall (which {keep,check}-state gives you).

 A learning question:  First, I am working from the understanding that
 the keep-state flag results in _one_ rule from any to $inwr, but creates
 the complementary $inwr to any rules for the return traffic on an dynam-
 ic basis, and that there is one dynamic rule for each connection that is
 active at the time.  I welcome enlightenment if I am mistaken in this.

 Given that one wants to run those four ports wide open to the world, won't
 keep-state result in the firewall creating N dynamic rules for the return
 traffic, where N is the number of connections open to those four ports?
 When N is large (i.e., when there are many connections to those ports),
 would it not result in fewer firewall rule comparisons to just run them
 wide open and be done with it?

 If one accepts traffic from anyone coming in to those ports, what is to
 be gained by restricting the IPs to which our server can send return
 traffic from those ports?

 ipfw add allow ip from any to $inwr 21,22,25,80
 ipfw add allow ip from $inwr 21,22,25,80 to any

 Wouldn't this result in a maximum of two rules, instead of N + 1?

True.  This is probably a good way of avoiding the overhead associated
with dynamic rules.  I was only comparing 'established' to '*-state' ;)



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-questions in the body of the message