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. |