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.
>
> --
> dfolkins
>
> P.S. i have to say that i put my eggs in the stateful basket (as opposed to
> nonstateful). chuck's argument with respect for dyn-rule overflow dos is a
> valid one, but only if one allows stateful _incoming_ connections. overall
> stateful rules are more restrictive, and the argument of "what if you
> accidentally make an outgoing connection to an evil site" holds no water cuz
> its just as bad with nonstateful rules. anyway, back to our scheduled
> program - why does the strange short-lived dynamic rule show up?
>
> P.P.S. thank you mike for the aaron gifford link, those patches look pretty
> nice. but i already have a _workaround_ - i.e. remove "setup" from the
> outgoing stateful rule. i wanted to find out what was going on and why.
>
> P.P.P.S. [wow, three of them!] switching to ipnat as per pierres advice
> maybe is a good idea, but seems to involve lots of work. heh, maybe i will
> play with ipfw for a while longer. its what i "grew up" with, after all. i
> can't just abandon it in its hour of need, can i? :)

Yep u can, it will take you 5 minutes depending on the speed of your
hardware to remake your kernel with 3 more options. And maybe you'll
take an hour to get the rules synthax in your mind. I used to have ipfw
as a stateless packet filter for a long time but when I first tried ipf
I've never been back. In fact stateful packet filtering as ipf provide
it is a powerfull tool for avoiding DOS and bad tcp flags packet. It
means a ack (or any other flag) not belonging to any connection list in
the kernel table won't be authorised as it would be in established mode.
It also checks the tcp sequence number and the window of packet
transmitting. In terms of outgoing traffic you don't even need to
specify the re-incoming traffic which is automaticly recognize and
accept by the filter. The last point i will speak about is the
difference between natd from ipfw suite which is a standalone daemon,
and ipnat which is implement into the kernel, if it's more secure in
term of performance it permits a faster forwarding of the packets on
your internal network. I hope I helped you change your mind ;)

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

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

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