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 
correct.

>>>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 
patch attached?

--
Pablo