ONLamp.com    
 Published on ONLamp.com (http://www.onlamp.com/)
 See this if you're having trouble printing code examples


FreeBSD Basics

Monitoring IPFW Logs

07/05/2001

In the last article, we were introduced to the names and the locations of the files that contain information logged by ipfw. We left off at /var/log/security which is the file I'd like to concentrate on in today's article as it wraps up this series on ipfw nicely.

We had to learn a fair bit about IP packets and some of the more common TCP/IP applications in order to correctly set up the ipfw firewall. Now as we read through the security log, we'll get to see first-hand what sort of packets do try to make their way into your FreeBSD computer.

When I first set up a firewall on a system, I like to keep an eye on the security log for the first week or so to see the amount and type of traffic which is being logged. As the superuser, I'll open up a terminal other than the console, and run the following command:

tail -f /var/log/security

This allows me to watch the log as it grows as any changes to the log will also be sent to this terminal.

As a demonstration of how to decipher what is being logged, let's take a tour of my most recent security log. You'll note that my security log has been "sanitized" as my IP address has been replaced by x.x.x.x. There are several ways to replace text on your FreeBSD system, but my favorite is to use the following Perl one-liner:

perl -pe 's/my_IP_address/x.x.x.x/g' /var/log/security > ~genisis/clean

I had to run this command as the superuser due to the permissions on the /var/log/security file. The syntax of this one-liner is fairly simple. The perl -e syntax tells Perl to run this line directly from the command prompt instead of looking for a Perl script to read. Don't forget to include the p in your -pe, or else Perl won't print its output. The 's tells Perl to look for the regular expression (regex) found between the first two slashes and replace it with the string of characters enclosed between the last two slashes. If you decide to use this command, replace /my_IP_address/ with your real IP address. The g' tells Perl to replace every occurrence of /my_IP_address/, not just the first occurrence. Finally, I told Perl to run this operation on the file /var/log/security and to send the results to a file named clean which was to be created in the home directory of the user "genisis".

As a reminder, the only rules I'm logging in my firewall are attempted TCP connections to my FreeBSD system (rule 00301) and any other packets that were denied because I didn't explicitly allow them (rule 00700):

ipfw show
<snip to just show logged rules>
00301     52     2727 deny log logamount 10 tcp from any to any in established
00700    213    14082 deny log logamount 10 ip from any to any

One of the first things I noticed when I started to read my firewall logs was that I was logging entries from the same host to port 119 (the news port) on a regular basis:

Jun  5 12:17:21 hostname /kernel: ipfw: 700 Deny TCP 24.0.0.203:58668 x.x.x.x:119 in via ed1
Jun  8 14:04:28 hostname /kernel: ipfw: 301 Deny TCP 24.0.0.203:50849 x.x.x.x:119 in via ed1
Jun  9 07:21:19 hostname /kernel: ipfw: 301 Deny TCP 24.0.0.203:37248 x.x.x.x:119 in via ed1
Jun 17 13:22:50 hostname /kernel: ipfw: 301 Deny TCP 24.0.0.203:49221 x.x.x.x:119 in via ed1
Jun 18 04:42:59 hostname /kernel: ipfw: 301 Deny TCP 24.0.0.203:39324 x.x.x.x:119 in via ed1
Jun 20 13:25:56 hostname /kernel: ipfw: 301 Deny TCP 24.0.0.203:57611 x.x.x.x:119 in via ed1
Jun 21 02:33:09 hostname /kernel: ipfw: 301 Deny TCP 24.0.0.203:53902 x.x.x.x:119 in via ed1

To find out who this mysterious host is, I'll use the -x option to the dig utility to perform a reverse DNS lookup:

dig -x 24.0.0.203

When I run this command, I'll receive about a page's worth of output; I'll find the portion that is useful for determining who this host is in the answer section:

;; ANSWER SECTION:
203.0.0.24.in-addr.arpa.  59m38s IN PTR authorized-scan1.security.home.net.

The host name in the answer section reminds me that my ISP routinely runs scans to see if any of its clients are running unauthorized news servers.

With that mystery solved, let's see if any other interesting ports are appearing in my log. I occasionally notice connection attempts to port 113 (the auth or identd port). Here is an example:

Jun  5 13:32:23 hostname /kernel: ipfw: 301 Deny TCP 216.13.25.80:47892 x.x.x.x:113 in via ed1
Jun  5 13:32:23 hostname last message repeated 3 times

And here is the result of the reverse lookup on this host:

dig -x 216.13.25.80
<snip>

;; ANSWER SECTION:
80.25.13.216.in-addr.arpa.  23h58m26s IN PTR atlas.ctsolutions.com.

The name ctsolutions.com rang a bell, and when I checked my mail reader's outbox, I saw that I had sent an email to that company about a minute before these entries appeared in my security log. It is common practice for some mail servers to do an identd lookup whenever you send them an email message. It is also common practice to make a special rule in your ruleset to respond with a TCP packet that has its reset flag set. This speeds up communications with the mail server as it doesn't have to wait for the identd request to timeout before it processes your email message.

Because the mail server is initiating the request, I'll have to ensure this new rule is numbered before my keep-state rules. I'll show the first bit of my ruleset so you can see the syntax of this new rule and where it was placed:

more /etc/ipfw.rules

#speed up email
add 00150 reset log tcp from any to any 113

#from man 8 ipfw: allow only connections I've created
add 00300 check-state
add 00301 deny log tcp from any to any in established
add 00302 allow tcp from any to any out setup keep-state
<snip>

I decided to log this new rule to see if it made any difference in my security log; the next time I sent an email to this mail server, the following entries were logged:

Jun  8 13:29:57 hostname /kernel: ipfw: 150 Reset TCP 216.13.25.80:37824 x.x.x.x:113 in via ed1
Jun  8 13:30:04 hostname last message repeated 4 times

Mail servers aren't the only types of servers that may do an identd lookup; FTP servers, POP3 servers and IRC servers may also try to send packets to port 113.

Also in FreeBSD Basics:

Fun with Xorg

Sharing Internet Connections

Building a Desktop Firewall

Using DesktopBSD

Using PC-BSD

Unfortunately, not all packets sent to your computer are as benign as the examples I gave for ports 119 and 113. If someone was looking for a machine to compromise, they could in theory try to get in on any open port. Fortunately, they usually tend to use common exploits on a few "notorious" trojan ports. There will be times when you are reading your firewall log that you'll be glad you that you took the time necessary to create and maintain your firewall.

There are numerous resources on the Internet to find out which ports are used by which exploits. One of the best places to start is with Robert Graham's "What am I seeing? FAQ":

If you come across a port you haven't seen before, there is a comprehensive port search utility here.

If you'd like to see a list of common trojans sorted by different categories, try this page.

The above resources will help to satisfy your curiosity concerning the entries that appear in your firewall log, but the question still remains: What, if anything, can I do about these entries? You can send a polite email with a copy of the firewall entries to either the host's service provider or to the administrator of the network where the host resides. To find out who to send the email to, do a:

dig -x IP_address_of_sender

to get the host name of the machine that sent the undesirable packets. You can then try a whois query on the last portion (or TLD) of the host name to see who registered that TLD (top-level domain). For example, I received a lot of netbus (a common trojan) entries from a host whose name ended with "home.com". When I ran the whois utility, I received the following response:

whois home.com
Whois Server Version 1.3
Domain names in the .com, .net, and .org domains can now be registered with many different competing registrars. Go to http://www.internic.net for detailed information.

HOME.COM.CURTISMORAN.COM
HOME.COM

To single out one record, look it up with "xxx", where xxx is one of the of the records displayed above. If the records are the same, look them up with =xxx to receive a full display for each record.

>>> Last update of whois database: Thu, 28 Jun 2001 02:04:50 EDT <<<

The registry database contains only .com, .net, .org, .edu, domains and registrars.

Because there were two registrants that had "home.com" as part of their name, I re-ran the inquiry like so:

whois =home.com
<snip output>

Registrant:
Home Network (HOME-DOM)
   425 Broadway St.
   Redwood City, CA 94063
   US

   Domain Name: HOME.COM

   Administrative Contact, Technical Contact:
      DNS Administration  (DA24627-OR)  abuse@HOME.COM
      @Home Network
      425 Broadway St
      Redwood City , CA 94063
      US
      650-556-5399
      Fax- 650-556-6666
<snip>

Because this is a service provider, I'm not surprised that the email address of the administrative contact is "abuse@home.com". If this had been a small company who had not set up an "abuse" email account, I could instead send an email to the person listed in the "Administrative Contact, Technical Contact" section.

You'll note from the original whois query that there are several competing registrars. If you don't receive any results from your whois query, the host probably lives in a different portion of the globe and its TLD may be registered in a different database. The whois utility on your FreeBSD system has several switches to allow you to query the various whois databases. The following useful switches are taken from man whois:

WHOIS(1)    FreeBSD General Commands Manual    WHOIS(1)

DESCRIPTION
Whois looks up records in the databases maintained by 
several Network Information Centers (NICs).

The options are as follows:
<snip>

-p   Use the Asia/Pacific Network Information Center 
     (APNIC) database. It contains network numbers used 
     in East Asia, Australia, New Zealand, and the 
     Pacific islands.

-r   Use the R'eseaux IP Europ'eens (RIPE) database.  It 
     contains network numbers and domain contact 
     information for Europe.

<snip>

A common complaint from those who take the time to send polite email is that they never receive acknowledgement that their email was even received or that any satisfactory action against the offending host took place. As a result, many administrators now upload their firewall logs to a centralized database. There are several interesting initiatives available; even if you don't want to participate, you can still view the accumulated statistics to see which ports are being probed and by whom.

One initiative is at www.mynetwatchman.com. Its script allows you to upload your ipfw logs and I will be demonstrating its usage in a future article.

Another is at aris.securityfocus.com. They accept snort logs and I'll cover this initiative in more depth later on this year when I demonstrate creating an intrusion detection system with snort. Securityfocus also has several valuable mailing lists. My favorite is the "incidents" mailing list. You can read the archives or sign up for any of their mailing lists at www.securityfocus.com.

Yet another initiative is at Incidents.org, which is headed up by the SANS Institute. If you are interested in security issues, it sends out a weekly newsletter via email. To subscribe, email sans@sans.org with the subject line: Subscribe Newsbites

The links mentioned in today's article should get you started on understanding the entries in your firewall log. In next week's article, I'd like to take a break from firewalls and do my semi-annual tour through the ports collection.

Dru Lavigne is a network and systems administrator, IT instructor, author and international speaker. She has over a decade of experience administering and teaching Netware, Microsoft, Cisco, Checkpoint, SCO, Solaris, Linux, and BSD systems. A prolific author, she pens the popular FreeBSD Basics column for O'Reilly and is author of BSD Hacks and The Best of FreeBSD Basics.


Read more FreeBSD Basics columns.

Return to the BSD DevCenter.

Copyright © 2009 O'Reilly Media, Inc.