At 11:45 PM 9/12/02 -0400, dfolkins wrote:
>now this is a very interesting discussion and all, but um, could someone
>take a look at what i posted originally and tell me why there is this rogue
>short-lived dynamic rule popping up and what i can do about it that does
>_not_ involve making non-stateful rules? pretty please? :) it would really
>appreciate it.

Ran into this when tinkering with dynamic rules and checking out the
features of IPFW2. It is not a rouge connection. The problem I saw was
the connection would time out and the external host would then try opening
a connection on a different port, which would be denied.

Did not find a solution or answer, though it was supposedly answered by
Ruslan Ermilov according to a message posted to -ipfw on Feb 13th, 2002 and
yet was indirect:

         Keep-state combined with divert is really tricky.
         Search ML archives for a possible solution. I
         posted them once.

Keep state works without NAT, which is how I use it on stand-alone systems.

Might want to try some "log" sprinkling, check the log, and then try a
second rule for the external IP. Am not sure if the connection is
initiated from the eIP or to. Didn't get around to that.

Removing the "setup" from the rule only means that the first packet in the
3-way isn't necessary for a dynamic rule to be created. It may be that
adding a similar rule for the eIP *before* divert is the trick. Whether it
needs to be in or out is also in question. Changing timeouts is not an
option for a decent firewall and TCP keepalives (new with IPFW2) will only
work with an established connection.

*Or* IPFW needs a method of relating connections. Otherwise doing stateful
FTP will not work either (or require opening the door a bit more). Will
guess that IPFilter does this and why it works better with stateful
rules. The fact that it harvests the LHF (thanks for answering that
Darren) makes it more DOS resistant when incoming connections are involved.

A solution for IPFW would be an excellent addition to a how-to. I'd
imagine this should otherwise move to -doc or -ipfw. Would rather have
somewhere to point someone than just tell them this is OT for -security.

Jeff Mountin - jeffmountin.net
Systems/Network Administrator
FreeBSD - the power to serve

To Unsubscribe: send mail to majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]