Re: ASA logging behaviour?

fsmontenegro · ‎07-18-2008

I'm seeing some weird logging behavior on an ASA5550 active/standby pair (Internet facing, running 7.2.4). As you can see from the example below, it is logging a number of denied messages for a normal (allowed by policy) TCP session.

Jul 16 2008 09:27:25: %ASA-6-302013: Built outbound TCP connection 120549741 for outside:<src/port> (<src/port>) to inside:<inside/port> (<nat/port>)

Jul 16 2008 09:27:29: %ASA-6-302014: Teardown TCP connection 120549741 for outside:<src/port> to inside:<inside/port> duration 0:00:04 bytes 30713465 TCP Reset-I

Jul 16 2008 09:27:29: %ASA-2-106001: Inbound TCP connection denied from <src/port> to <nat/port> flags ACK on interface outside

Jul 16 2008 09:27:29: %ASA-6-106015: Deny TCP (no connection) from <inside/port> to <src/port> flags RST on interface inside

Jul 16 2008 09:27:29: %ASA-2-106001: Inbound TCP connection denied from <src/port> to <nat/port> flags ACK on interface outside

Jul 16 2008 09:27:29: %ASA-2-106001: Inbound TCP connection denied from <src/port> to <nat/port> flags PSH ACK on interface outside

Jul 16 2008 09:27:29: %ASA-2-106001: Inbound TCP connection denied from <src/port> to <nat/port> flags ACK on interface outside ...

Naturally, this is affecting logging (many, many more messages than what we expected) and is confusing MARS as well.

This seems a bit strange because we're seeing almost 300 of these events per 5 minute period. There's two messages that get generated very frequently:

%ASA-2-106001: Inbound TCP connection denied from <src/port> to <dst/port> flags <flags> on interface <name>

%ASA-6-106015: Deny TCP (no connection) from <src/port> to <dst/port> flags <flags> on interface <name>

In MARS, these get normalized into the following events:

Deny packet due to security policy

Deny connection - no xlate

I know that technically these are not false positives, but the end result is lots of alerts/incidents that can be tracked to these spurious log events.

Is there any tuning I should be doing on the ASA state mechanism or under logging to address this?

Thanks!

jgary · ‎07-18-2008

If you receives a lot of these messages, you should trace the packets to

the source and determine the reason these packets were sent. Meanwhile disable login to improve performance.

no logging message 106001

I hope help.

fsmontenegro · ‎07-18-2008

Hi, thanks for your message.

My concern with not logging these messages is that it seems to be treating the symptom and not the cause. Should we be making a distinction between unauthorized traffic that happens JUST AFTER we close a connection/xlate and unuathorized traffic that we should never see in the first place?

r.sneekes · ‎07-18-2008

I think part of this is normal behaviour.

This happens when 1 of the hosts sends an reset. That connection will be remove out of the connection table at once.

But sometimes the oher hosts thinks he is still communication with the other side over the same session. So these packets arrive at the firewall as part of an old session.

since the firewall removed the session out of the connection table it drops these packets.

fsmontenegro · ‎07-18-2008

Roy, I agree with you that it is normal behaviour. My concern is that we're seeing enough of these (300 or so within a 5-minute period) to make logging very cumbersome and make MARS report several "incidents" when in reality it is a "false" positive (BTW, tuning MARS false positives is not an option because it happens to multiple src/dst pairs).

Is there any way of tuning logging behaviour (short of ignoring these messages, which is not good because there are times when they're meaningful) so that traffic related to a recently closed session is treated differently?

rsullivan1 · ‎02-13-2009

I am seeing a large amount of these messages as well. Have you to a resolution?

fsmontenegro · ‎02-13-2009

Best I could come up with was removing a "deny ip any any log" at the end of the ACL and rely on the default nature of the ASA of denying traffic not explicitly allowed.