Re: PIX 515 Security Intrusion Logging

bbeck · ‎02-20-2003

I have just recently taken over our PIX firewall and have been experimenting with the logging features. I am currently logging up to Warning Level, and have seen a lot of activity that leads me to believe that several people have attempted to get past our firewall. The current level will tell me the attempts that fail, however I can't tell if they ever succeeded. I have tried logging at the Informational level so that I could see the successful connections also, but I am getting way to many messages to be useful. I have already eliminated most of the message codes that I don't want to see, but I can't find a way around getting both incoming and outgoing messages for 302013 and 302015 (98% of the messages I get are related to my users accessing the internet). Is there something that I am missing or should I go a different direction to monitor attacks on our network? I am using the Kiwi Syslog Daemon to capture the log messages (freeware version, although I would purchase it if it can do what I want).

gfullage · ‎02-20-2003

I'm a little confused by your statement:

"but I can't find a way around getting both incoming and outgoing messages for 302013 and 302015"

what do you mean exactly? These syslogs will show both inbound and outbound connection attempts, and you mention that 98% of the messages point to outbound messages, so what's the problem exactly? You can't limit these connections to just one way if that's what you're trying to do. What makes you think people are trying to get past your firewall?

bbeck · ‎02-21-2003

I was hoping to log only inbound connection attempts, that way, If I saw an IP address scanning ports on our IP range, I could see if that address ever made a successful connection to one of our servers. Unfortunately as far as I can tell the only way to log inbound is to log outbound also, which shows me every connection created to a website by about 500 users on my side of the network along with those coming inbound, thus making it much harder to find the type of activity I am looking for. I am just trying to keep an eye on who is accessing out network systems from the outside.

The reason I'm concerned is I've noticed a lot of traffic like this late at night

2003-02-20 03:57:56 Local4.Error 10.2.69.10 Feb 20 2002 03:56:16: %PIX-3-106011: Deny inbound (No xlate) icmp src outside:62.203.9.230 dst

outside:xxx.xxx.xxx.xxx (type 8, code 0)

2003-02-20 03:58:01 Local4.Critical 10.2.69.10 Feb 20 2002 03:56:21: %PIX-2-106001: Inbound TCP connection denied from 62.203.9.230/16288 to xxx.xxx.xxx.xxx/139 flags SYN on interface outside

The traffic lasted about 30 minutes and originated from Switzerland. Since we have no one in Switzerland with any reason to be accessing our network, I am a bit concerned. Also, according to this site, the first message is explained as - "This usually indicates that a security breach is occurring".

Please note, I may be going the wrong direction to accomplish security, I am just trying to start doing something that the previous person in charge of this system completely ignored. I am just becoming familiar with the PIX and may not be taking the best route. I am just trying to find a way to insure that our Firewall is preventing most unwanted users from getting in, and logging those who are able to circumvent the security so we know what has happened. Thanks for the help.

gfullage · ‎02-22-2003

According to the logs, the PIX did what you're paying it to and stopped the connections and the pings, and I'd say it was just someone probing to see what's out there before launching a more specific attack. Denying pings inbound is a good idea, and certainly only opening the specific ports that need to be open is vital to a good firewall.

as for logging, you're right, the PIX will show all connections, there's no way to get it to just show inbound. You can easily search for keywords like "inbound" and parse those out to a different file (on a Unix syslog server, not sure about Kiwi, I'd say it has some sort of feature like that).