Re: Strange Pix behavior.

[Jim MacLeod <jmacleod () gmail com>]

Paul Melson wrote:

> If the firewall successfully deletes the state table entry before the remote
> server can send an RST+ACK (which is what you want, you don't want your
> firewall waiting for an untrusted system's predicted response before it
> revokes its access), that packet will be compared to the access-lists that
> allow traffic from the outside and if no match is found, it will be dropped
> and logged.
>  
I'm not aware of any TCP implementation that will ACK a RST, since RST 
indicates that the host has destroyed the connection.  It's invalid to 
ACK a RST, and would provoke yet another RST.  That's one of the reasons 
to use a FIN+RST, rather than a full FIN-ACK-FIN-ACK.  Your explanation 
also doesn't account for UDP, although typically a stateful firewall 
will keep a running timer for UDP pseudo-sessions and remove the table 
entries once the timer expires.

My first guess in cases like this - HA pair, replies dropped - has 
historically been unintentional asymmetric routing, when the outbound 
connection goes through one firewall, but the response returns through a 
different one, and the RTT is less than the sync interval for the 
firewalls.  In that case, the inbound firewall would act as expected, 
dropping a session for which is has no table entry.  Granted, I haven't 
seen this problem in quite a while, and even then it was primarily on 
inbound connections. 

I'd be interested in seeing if there's a correlation in the logs with 
existing connections from the client to the server.  Are these really 
dropped responses, or is it attack traffic designed to mimic that 
traffic pattern?  Real dropped responses should have Accept messages to 
the same servers from the same client IP around the same time.  The fact 
that the drop messages are in proportion to the outbound connections is 
a good sign that it's not an attack.

> Your firewall is working just fine, or at least, it's working as it was
> designed to work.  If you don't want to see it, I recommend using Kiwi or
> syslog-ng to remove these entries from the syslog stream before they reach
> your log analyzer.  
>  
I'd argue instead that this behavior is unusual, and furthermore that 
blocking Deny log entries is a good way to ignore evidence of actual 
attacks.  Granted, there's a signal-to-noise ratio problem right now, 
but that can easily be corrected by filtering on known protocols in the dst.

-Jim
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards