Bob's Blogs

Put another log on the fire

Some years ago, I presented a paper at TISC (The Internet Security Conference) titled How and Why to Read Firewall Logs. That was about (or past) the end of an era when it was humanly possible to read one's firewall logs -- and most of mine were condensed for automated reporting simply because of time and space constraints.

However, it remains a subject near and dear to my heart (professionally speaking, that is) as a means of keeping tabs on what sorts of things are going on on one's network. To that earlier list, of course, one must add in IDS/IPS logs, VPN authentication (or failure thereof). As I've mentioned with other topics, most of you have resources that you don't know you have.

One of my favorite toys of late is the Cisco MARS product (formerly "Protego" before Cisco acquired them). This box will take logs from many different sources and correlate them into "incidents" which can be examined and drilled down into. It catches lots of stuff and, like an IDS, will have to be tuned to cut down on false positives. Network Intelligence and others make roughly comparable products also.

But what if you don't have one?

One of my favorite things to do, which I spend 15-30 minutes per day on (sometimes more), is to go through the firewall logs, selected different ways, and sometimes export different aspects of firewall logs into Excel and sort the data different ways to see if any patterns jump out at me.

Recently, I just chose all outbound connections aimed at ports 1025 and higher. Sorting by destination port showed one group of heavy traffic with a destination port of 6667, which is IRC (Internet Relay Chat). Experience has taught me that most systems talking to an IRC server are doing so without the owner/user being aware of it -- that is, they're infected by a worm, virus, Trojan or bot, which is usually "phoning home" for instructions or to provide reports of some sort. When I found this set of logs, I ran mIRC (an IRC Chat client) to try and connect to each of the servers. There were three that refused my connection outright. So the systems connecting to them have already been reported to the desktop support group for immediate investigation. The clients going to IRC servers that permitted me to connect will also get investigated, but are slightly lower priority.

Peer-to-peer traffic is a problem as well. I've mentioned that in previous blogs. By sorting source and destination addresses and looking for known P2P port numbers, I've learned that any time a given system contacts a P2P server, it attempts to open a wide variety of ports. In return, the system contacted immediately tries to open many corresponding ports back on the originating system. One experiment I tried with BitComet showed that it momentarily opened dozens and dozens of listening ports when it was first brought up and then stopped most of them. As a result, I've gained more insight into some of their behavior. I've also gone to read all the documentation on BitTorrent (www.bittorrent.com) that they have to offer. Even though I personally never use these things - it pays to know your "enemy"

Setting the firewall log monitor (Checkpoint, in this instance) to filter on popular attack vectors (NetBIOS, A/D, SNMP, HTTP/S, etc.) often reveals attack patterns, virus infected systems, misconfigured systems and the like.

Looking for broadcast addresses (particularly using a wider broadcast mask than is used internally), and even a 32 bit (IP version 4 of course, and ignoring DHCP/BOOTP requests) shows both attackers and systems with misconfigured subnet masks.

Meeting Network Security & Control Requirements: (408) 395-3921