Abnormal FWLSM behavior

[Mark Pareja]

Today I was working an issues that involved a single hosting box that was taking an abnormal number of connections, well the normal automated security systems kicked up and the XLATE tables on the FWLSM started to fill up and shun connections after clearing the XLATE tables for this particular host I noticed that all connections dropped and stayed dropped. I still say hits on the ?permit any host X.X.X.X? ACL however saw no connections to the host. Furthermore I was able to telnet externally to the host on port 80, but when I began a query the connection timed out. All the amount of connection clearing did not help, until I removed the host from the host group and re-compiled the access-list?s, then added it back and re-compiled again. After this procedure all valid traffic began to pass normally.

Has anyone seen similar behavior?

[ebreniz]

Change the TCP port used for communication and see it will solve the problem.

[lowen]

I have seen something vaguely similar. Running multiple transparent contexts on 3.1(1), I've seen an instance where an ACE stopped registering hits (although a capture clearly shows traffic matching the ACE hitting the outside interface where the ACL is applied), and the traffic "fell through". In my case, it was rdp; if the source address was such that it matched an ACE further down in the ACL, the traffic was permitted and *that* ACE's hit count incremented; if it didn't match any other ACE, the traffic was denied. Removing and replacing the ACE (forcing the recompile) fixed the problem. My ACE also used an object-group for the source address, but in my case it affected all members of the object-group, not just a single one.

[Mark Pareja]

I have recently found that my guards were registering minimal amounts of malitious traffic, for giggles i placed the server behind a zombie filter and presto! ! the firewall started behaving normally. The server had in fact been under a zombie attack but did not exibhit any of the usual signs of a zombie attack.