Troubleshooting cisco 5585 ASA-6-106015 messages related to tcp deny syslog message

[asad ali]

I'm troubleshooting a scenario where I'm getting countless TCP DENY messages in cisco asa 5585 traffic log. The sample logs looks like:-

Troubleshooting  cisco 5585 ASA-6-106015 messages related to TCP deny syslog message

166>May 07 2014 13:04:50: %ASA-6-106015: Deny TCP (no connection) from 10.10.71.203/46273 to 10.14.16.34/80 flags ACK  on interface inside

and in most other cases I'm getting (RST)

<166>May 07 2014 13:40:28: %ASA-6-106015: Deny TCP (no connection) from 10.10.71.203/57620 to 10.14.16.18/49156 flags RST  on interface inside

The syslog id reads as:-

106015

Error Message %ASA-6-106015: Deny TCP (no connection) from IP_address /port to IP_address /port flags tcp_flags on interface interface_name.
Explanation The ASA discarded a TCP packet that has no associated connection in the ASA connection table. The ASA looks for a SYN flag in the packet, which indicates a request to establish a new connection. If the SYN flag is not set, and there is no existing connection, the ASA discards the packet.

Recommended Action None required unless the ASA receives a large volume of these invalid TCP packets. If this is the case, trace the packets to the source and determine the reason these packets were sent

I want to know Is there a possibility these messages I see are result of local system firewall which is denying these messages. In such form, when the packet is rejected e.g receiving an rst from end-station what would be the possible message/event name. Should it be TCP DENY or teardown etc.

So, what I'm interested to know If for suppose the end-station is refusing the connection to a port, what would be the message I would get from syslog? I have googl'ed and found reset-0 to be msg when the connection is refused from the end-station. I want to be clear since I'm analyzing logs from security point the wrong interpretation could mean not responding correct manner in case of real security incident E.g scanning attack. 

[Julio Carvajal]

Hello,

My recommendation would be take a capture on both the inbound and outbound interfaces of the ASA in regards of the traffic.

Then you will determine whether the connection is getting closed and after a few ms you are still receiving traffic for the previous session closed or if you are seeing asymetric routing that will cause that specific log.

Let me know how this goes

Regards,

Jcarvaja

[asad ali]

Thank you for the quick update. Here is few things I want to mention. To verify I did:-

a) run a nmap scan to same remote network. There were very few tcp teardown messages as oppose to scan which I run through nessus (vulnerability scanner) which contributed to large number of teardown messages.

b) Some patterns I was able to deduce is in case of scanning through nessus, the replied came from gateway address of 10.12.24.1 with message containing the phrase 'TCP Reset-I '.? 

Also, the scan was only able to identify single host where in namp scan more then 100+ endstations were discovered. The other teardown message I get is

%PIXASA-6-302014: Teardown TCP connection id for interface:real-address/real-port to interface:real-address/real-port duration hh:mm:ss bytes bytes [reason] [(user)]

with reason

Failover primary closed
The standby unit in a failover pair deleted a connection because of a message received from the active unit.

This is the message I get when nmap queries a port on system which is closed.

[Julio Carvajal]

Hello,

First we will need to identify the probes that NMAP sends against the ones from Nessus.

We might see different traffic patterns as their functionality is similar but Nessus is more powerful when used properly.

If what you are looking for is to make sure you are not able to identify that many hosts when running the NMAP scan you should be considering working with Threat-Detection Advance option and then customizing the measure values so shunning can happen faster in such an attack.

Does it make sense?

Regards,

Jcarvaja

[asad ali]

The exact probe in terms of scan type is 'aggressive'. Nessus does tcp scan by default.

What I'm trying to do is to find where these packets are being dropped at the end-station level or the firewall level. Thats why I have shared these messages. I'm from the sec team, the networking guys manage the routing / firewall part.

Firewall needs to differentiate on the syslog message level on which ends these packets are being dropped.

The settings allowed for scanning allows for any to any communication between source (scanner) and target.