asked on

PIX Firewall Syslog Messages

Hello,

I was going through our PIX syslogs and noticed that we are getting a large volume of 106015 messages. See example below:

2009-07-06 02:39:42 Lpr.Info 10.10.16.228 %PIX-6-106015: Deny TCP (no connection) from 208.70.187.70/80 to 64.122.142.138/31632 flags ACK on interface outside

Here is Cisco's explanation:

106015

Error Message %PIX-6-106015: Deny TCP (no connection) from IP_address/port to
IP_address/port flags tcp_flags on interface interface_name.

Explanation This message is logged when the firewall discards a TCP packet that has no associated connection in the firewall unit's connection table. The firewall 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 not an existing connection, the firewall discards the packet.

Recommended Action None required unless the firewall 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.

In our case, we are getting a large volume of these. I would like to know if this is something I should look into further? I am not sure what the best way is to trace the packets from the source to the destination. Is there software that can do this for me? Any recommendations would be appreciated.

Thanks, T

Nothing_Changed

The source of that traffic is www.freshloc.net. the .com side of that is a temperature control and monitoring system company, the .net side is (im assuming) their customer/dealer support site nad requires login. The source port is 80, implying a SYN ACK to an ack that someone in your site sent into their webserver. You may be getting these log entries if there is a poorly written app on their side sourcing traffic back to you on a different IP than you are establishing a connection to (a kind of assymetrical routing). If freshloc.net or freshloc.com is NOT a place you or your people would be connecting to, it's an attack someone out in the wild is either bouncing off that company's compromised server, or they are source spoofing the traffic just to see if they can get into your network.

You can ignore it safely if it is not impacting site function, and if it is not enough traffic inbound to negatively impact your internet bandwidth.

You can verify that it is a bad response to a connection request coming out of your network in a number of ways. The simplest would be to tap the link between your firewall and your outside network, and watch a Sniffer for connection requests out that retry again and again to connect to port 80 on www.freshloc.com or .net that correlate with these log entries occuring. You could also turn your PIX logging up to debug for a while, and look for outbound SYNs to port 80 that dont get answered, then compare the destination port of these log entries to those and look for correlation. For instance, in your example 208.70.187.70/80 to 64.122.142.138/31632 shows your side's high port to be 31632 connected to the other side's port 80. If this is a bad web app and not an attack, you would expect to see traffic that never gets answered from your inside or outside IP heading to port 80, then an answer coming back to that same ip and port but FROM a different source on port 80, and that triggers the log entry.

Streppa09

ASKER

Freshloc is a program that we are using internally to monitor temperature for food coolers and freezers. It sends information to their website, were users can login to view sensor readings.

You mentioned putting a sniffer between our firewall and outside connection. Do you have any software that you would recommend to do this? How would you go about this?

Thanks, T

ASKER CERTIFIED SOLUTION

Nothing_Changed

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

Streppa09

ASKER

I looked at a few things. First, CPU usage is at 0%. Second, memory utilized is less than 75%. So, we're good there. I also looked my syslogs again and I have over 7000 of the 106015 syslog messages, with many different ip addresses associated in each message. My question is, before I get hot and heavy with your procedure, which I very much appreciate you sharing your knowledge, will I have to repeat this for all 7000 messages? I am not sure if I have the time to slowly weed through all of the messages. Do you know if there an easier way to do this, or is this just the nature of the beast?

Thanks, T

Nothing_Changed

No no, we only need to really catch one to verify the problem. Without even seeing traces, I'd wager that your service provider is answering requests you are sending to one ip/server from aonther one, due most likely to a misconfigured content switch(load balancer), or a misconfigured NAT at tehir edge.