Analyzing Cisco Pix firewall logs with FireGen Log Analyzer - A firewall administrator diary
Send your comments!

All the notes on this page are derived from our daily analysis of our Cisco Pix firewall logs using FireGen for Pix Log Analyzer, Version 2.0.

March 19, 2004
The Web traffic Top visited sites section was showing a couple of IP addresses with many connections but no host name (there was no reverse name resolution). By looking up the IP address through EventID.Net's whois we determined that the IP address belonged to "Akamai Technologies", a provider of transparent cache services. So most probably these are IPs used by popular web sites to host their images or by ISPs to "ease" the load on their network. We opened the DNS cache and added entries like "207.61.132.=Web cache server". So any IP address matching 207.61.132. will be labeled as Web cache server. We removed all the existing entries for 207.61.132.x.

In the Protocols section we notice quite a few connections on TCP/91 from one of the administrators. We fired up Ethereal on that computer and monitored if for a while. It turned out that the traffic was generated by a Java applet running in a browser. The application was using HTTP but on port 91 instead of 80 (the nature of the application required as much security as possible and this was part of the "security by obscurity" approach).

The "Denied protocols" section shown the typical protocols: NetBIOS (UDP/137, UDP/139 and TCP/445), MS RPC (TCP/135) as well as a couple of pings (ICMP echo).

March 18, 2004
We noticed 4 Critical events in the "Summary" section and noticed that some "Deny IP spoof from (127.0.0.1) to ... on interface outside" messages that we encountered before have reappeared. A while ago we did some research on this and apparently these are just some form of denial of service. There is not much we can do to prevent this unless the ISP is willing to make changes in their routers. Since we are not high profile customer that's highly unlikely to happen. The "Errors" section contains the common list of "denied" connections from various infected hosts out there. The "firewall" surely deserves its name these days - it is burning out there!

Verify the top internal web users we noticed that not all the hosts have a pointer record for their IP address. Since we run a Windows 2000 with Dynamic DNS this should not happen. We have re-checked the computers' settings and it turned out that some were configured NOT to register their name with DNS.

The "Denied protocols" section shown a large number of connection attempts on TCP/51938. By following the hyperlinks for that protocol we did research it on Google but without finding any relevant information. The "Internet Storm Center" would show a surge in traffic for this port but without any additional information. It may be a new Trojan.

The "Firewall management" section indicated that 2 telnet connections took place but they were from computers used by our admins.

March 12, 2004
A look at the "Web Traffic - Top outbound connections" indicated many hosts like "www42.thny.bbc.co.uk" or "adcounter.theglobeandmail.com" and other similar sites. We could easily guess that these are in fact connections to the BBC or "Globe and Mail" web sites. Just to make things easier to read, we decided to alter the DNS cache and just put BBC and Globe and Mail for the entire subnets containing the IP addresses of these hosts. For example, all the Globe and Mail hosts appear to be on the 199.246.67.0 subnet. So we opened the DNS cache and added 199.246.67.=Globe_and_Mail. We also removed all the existing entries for the 199.246.67.0 subnet. We did the same thing for BBC (all 212.58.240.x hosts will then become "BBC" instead of multiple hosts like www42.thny.bbc.co.uk - there were at least 10 of them). For CNN we found 6 entire subnets! This process may be a bit tedious but in a couple of days we may cover all the major web sites.

We have a custom protocol defined as UDP/137 (NetBIOS). In its section we found a large number of requests coming from our 2003 Domain Controller to 2 private IPs: 192.168.189.1 and 192.168.236.1. We do not use this range so this was intriguing. What we realized was that one internal server has WMWare installed on it. WMWare is creating to virtual network adapters. Even though their IP address was set to "obtain automatically" and we do have a DHCP server their actual IPs were the 2 addresses mentioned above. Most probably the server was trying to register these IPs through a broadcast. The domain controller would receive the broadcast and respond to it. Since the IP addresses were not on the same subnet as the domain controller, they would be sent to the default gateway, the firewall (and from there to the big Internet!). Since WMWare was not in use, we disabled these virtual adapters. All this information was a bit tricky to determine. It just happened that somehow we related those IPs with WMWare and we searched for computers running it. We also ran another FireGen for Pix report with "192.168.189.1" as "include keyword" for the last 1 hour. Analyzing the "message details" section we noticed that the attempt to connect on UDP/137 happened approx. every 15 minutes and that is the default interval for a NetBIOS host (re-)registration. In a similar fashion we identified other computers configured with private IPs generating this type of traffic.

Pix Analysis Archives: 03/11/04-03/08/04  

Featured Links GFI EventsManager - Network-wide event log management - Download free 30-day trial! Free Online Event Scanner - Scan your pc for high security events with GFI's free online service. EventID.Net Subscription - So much information for so little!

Legal - EventID.Net © 2001-2008 Altair Technologies Ltd., All rights reserved - Sign up for our Email Newsletter