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 11, 2004
Analyzing the traffic from the day before, we have noticed quite a few UDP/137 connections from the machine hosting the FireGen for Pix Analyzer and various hosts on the Internet. We opened the log for the day before and looked-up some of the IP addresses shown in the reports as being accessed on UDP/137. We found that all those IPs appeared in the log at an earlier hour but with other protocols. Later they appear as being queried on UDP/137 (NetBIOS) by the FireGen host. The reason for this is the way MS DNS resolver attempts to perform reverse host name resolution. It will first attempt to use the DNS and if the IP is not resolved it will query the host directly for its NetBIOS name using UDP/137. The FireGen Log Analyzer was attempting to resolve the name of these hosts during the analysis from the day before. One way to avoid the report being filled with this requests is to exclude the IP address from the analysis (using the "Exclude keywords" settings). To avoid having this kind of traffic generated by FireGen, we implemented a different DNS resolver, a component that would query the DNS server directly with just "pure" DNS requests.

March 9, 2004
The analysis of the "SMTP - Top outbound" connections revealed that our Exchange server performed over 200 connections to IP 67.32.49.2. No reverse name resolution was available for this IP. Since these were SMTP connections, we telnet-ed to it on port 25. The response was from an Exchanger server advertising itself as "xchg.oilmens.com". Most probably, our Exchange server was trying to deliver an email to this server but it was rejected for some reason. We have verified the outbound queue on our Exchange server and removed the email for the oilmens.com domain. We updated the FireGen cache so the 67.32.49.2 IP is now resolved to xchg.oilmens.com. Another IP with many SMTP connections was 68.20.101.204, resolving to wix1isa.CI.WIXOM.MI.US. Telnet-ing on port 25 revealed that is an email gateway running InterScan VirusWall. Most probably, another email had to be delivered there but the server would reject it. The problem with the rejection is that it has to be done properly, otherwise the sender will keep trying. Most probably this is an improperly configured antivirus/antispam gateway. We do not spam anybody but sometimes, keywords in the email may trigger antispam engines. The outbound queue on our Exchange was already empty.

The RPC section (a custom protocol that we monitor) revealed few hundreds of attempts, most probably from infected hosts. Just a good reminder to make sure that no internal machine is ever exposed to this!

Another protocol that we monitor is MSN (TCP/1863). Several connections would point to Hotmail servers but some to unresolved IPs. Since all were for hosts within the 207.46.106 or 207.46.107 subnets, we have added them to our DNS cache so they will be reported next time as "hotmail.com".

The "Other protocols" section contained lots of UDP/137 (NetBIOS), ICQ and Yahoo Messenger traffic, lots of DNS requests to the root servers (which is normal).

In the "Denied connections" section, the usual cohort of denials for TCP/445, TCP/135 (ms rpc), UDP/1434 (sql monitor), pings from various hosts (ICMP/8) along with some TCPs for ports higher than 30000 (indicating just a delay in a packet delivery). To learn from this is that lots of worms are crawling out there! Many connections on TCP/39222 but no relevant information about this protocol could be found.

The "Firewall management" section indicated that an internal IP address was used to connect to the firewall and make modifications to the firewall configuration. We did that so there was no cause for alarm.

In the "HTTP Top outbound" section we noticed the first host (65.19.143.79) with an unusual number of connections, over 500. The IP did not provide a reverse host name. We used a browser to connect to 65.19.143.79 but we only got a "db error", most probably the web server is using host headers to identify the site. Next, we looked at the "Message details" section, the "Notification" part (that holds the URLs) and found that the page accessed was "/suspended.page". Again, opening in the browser we got now to a page saying that the account was "suspended". Discussing with the end user that accessed that page, it turned out that the site was for an ISP that went bankrupt and they posted that page. There was programming error however that would redirect that page to itself causing an infinite loop. According to the user, all those connections took place in a few seconds interval.

March 8, 2004
Analyzing the "Other protocols" section in the FireGen report, we noticed that some workstations would attempt to connect with FTP (TCP/21) to 63.218.13.197. There was no reverse name resolution for this IP address but doing a quick port scan we found that it is in fact ftp.nai.com, the FTP site used for McAfee virus pattern updates. We added 63.218.13.197 in the FireGen DNS cache so future reports will display it as ftp.nai.com.

Through the "Internal IP addresses" section, we checked outbound protocols used by the our domain controller and confirmed that only FTP (for antivirus updates) and SMTP (for outgoing emails) were used.

Analyzing the section for a custom monitored protocol, POP3 (TCP/110), we noticed that one remote user had its client configured to check the email every 1 minute, generating quite a few POP3 connections. An email was sent asking him to change the checking interval to 10 min.

Another custom protocol we monitor is RPC (TCP/135). We have it configured so it will also report the denied attempts to connect with this protocol, not only successful connections. The report indicates that there are in average 20 attempts/hour.

The analysis of the "HTTP outbound connections" section revealed the "regular" news sites browsing, personal online banking sites, Hotmail/MSN traffic, connections to Internet cache servers (akamai), online music download from musicmatch.com - but that is ok because it was us ;)

The "Denied connections" shown several denied connections from musicmatch.com with reason "no connection". This is not surprising as the music stream download could experience delay due to load on the site. The section contained quite a few "no xlate" messages from infected computers on the Internet using TCP/135 (RPC) along with UDP/137 (NetBIOS). Several entries for denials having "no connection" as reason were for ports higher than 30000 (i.e. 37341). The source of these denials were known, secure hosts so all these entries are most probably caused by Internet delays. This can be used to discard similar entries from unknown hosts (but not all the time). Several connection attempts were on port UDP/1434, probably scanning for unprotected MS SQL servers.

The "Denied protocols" section would confirm several TCP/135 scans (FireGen properly recognized them as Internet worm).

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