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
    unsafe in comparison to keep-state why is it still supportd by ipfw?"
    The real answer to this is "because Luigi, the author of ipfw, chose
    to keep backwards compatibility with rulesets that use 'established'
    instead of removing it long ago and causing many administrators around
    the world to curse, when they discovered that their firewall rulesets
    broke when they upgraded from one version of FreeBSD 4.X to a newer
    version in the 4.X branch of development."

    I think I will ask Luigi to remove 'established' in FreeBSD 5.X.  If
    he doesn't like the idea, I will probably sit down and write a big,
    fat warning in the manpage that suggests avoiding 'established' and
    going for a pair of 'keep-state/check-state' rules instead.

    I hope I didn't confuse the heck out of you,

    - Giorgos

Attachment: pgp00000.pgp
Description: PGP signature

Reply via email to