Hallo Fred,

Fred Wright schrieb am 10. August 2004:

>>>02:52:14.472848 sis0 @0:15 b 192.168.100.111,1081 -> 24.99.173.2,6881
>>>                PR tcp len 20 112 -AP IN 
 
>>Those are packets that are deemed by ipfilter not to match any
>>existing state table entry.

>Or that matched but were deemed "inappropriate" by other criteria,
>such as sequence and/or ACK numbers.

I see both your points. Looking at the current rulesets:

@14 skip 1 in proto tcp from any to any flags S/FSRA
@15 block in log quick proto tcp from any to any

Would it be a good idea [tm] to replace "from any" with "from <wan>"?
This way only the incoming side gets blocked and the approach to a
largely trusted intranet is maintained.

>Personally, I think the only purpose of the filter should be to
>provide security, not to punish people for communicating with mildly
>buggy TCP implementations, but the IPFilter guys seem to think
>otherwise.

One could argue about that. Even mild bugs may turn out to be a
security problem in the future. See ICMP for example, was meant to be
good, but with faked TTLs, utils like "firewalker", etc. a (skilled)
hacker can do a lot. (Not to mention the abuse of fragmented ICMP, the
old "Ping of Death", X-Mas Scan, null scan, etc.)

Although I am personally "punished" by this behaviour, I can
understand the IPFilter developers. Standards are standards and not
meant to be broken. I guess that's one of the reasons, why m0n0wall is
not implemented with e.g. Windows CE ;-) Where to draw the line, when
a packet is mildly buggy or potentially harmful?

As I understand it, pf (from OpenBSD) is making it's way into the
other *BSDs, so eventually m0n0wall might even switch to pf in a
future release. (IMHO pf is awesome, "scrub in all" e.g. really does a
lot for security).

Thank you very much for your valueable input and kind regards

Frederick