REJECT using invalid data
pablo at eurodev.net
Tue Dec 7 23:14:44 CET 2004
Simon Kirby wrote:
>On Tue, Dec 07, 2004 at 12:07:15PM +0100, Pablo Neira wrote:
>>not really, my ruleset drops it, actually another rule here is
>>previously logging it.
>>-A INPUT -m state --state INVALID -j DROP
>That's all fine and dandy, except that we can't use state tracking in our
>configuration because of asymmetric routing (which is required due to
>BGP). This is fairly common, and not an incorrect setup.
Hm I thought that you were using state tracking... I agree your setup is
>>>REJECT can be set to reject with a
>>>tcp-reset or some ICMP response at this point. If so, it will actually
>>>use the possibly-incorrect information from the bad TCP packet and send a
>>>rejection packet. As far as I can tell, this is a bug.
>>yes, that's a bug, but in your ruleset, people should log/drop/let
>No! It is not a bug in our ruleset, it is a bug in REJECT.
>It is incorrect to reply to packet layers that have bad checksums.
>REJECT in this case must DROP, because anything else would be broken.
Now I see, if state tracking is not enable there's no way to avoid this
problem. But I guess that we should drop all malformed packets, not only
those which have bad checksums. Would you like to give a try to the
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3030 bytes
Desc: not available
Url : /pipermail/netfilter-devel/attachments/20041207/ab6babea/reject-0001.bin
More information about the netfilter-devel