RE: Strange Pix behavior.

["Paul Melson" <psmelson () comcast net>]

I'm sorry.  You're absolutely correct.  It is not an RST+ACK, but rather a
FIN+ACK from the server in response to a FIN+ACK sent by the browser.

I would wager that if George looks through his logs, he is only seeing these
entries for TCP connections.  The example he gave was specific to HTTP, so I
think this still applies.

As far as the normalcy of this behavior, I think that nearly any stateful
firewall that has multiple clients behind it experiences session state
mismatch, which these log messages are a symptom of.  It's part of the
nature of stateful firewalls.  I wouldn't suggest that anybody eliminate all
'drop' messages from their log stream, but if you know that any drop message
from [someaddr]:80 to [nataddr]:[>1023] is erroneous, why not keep it out of
your monitoring/analysis?

PaulM

-----Original Message-----
Subject: Re: [fw-wiz] Strange Pix behavior.

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.


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