Firewall Log-Checking Techniques

Mark Prager

Many companies have a firewall installed, and they think this will keep their systems safe. But, how can you stop intrusion attempts and determine who is attempting to break in? This article addresses these questions and is written with Checkpoint's Firewall-1 log in mind.

To get anything out of the log file, your Firewall rules must be logged. I tend to put "logged" rules wherever possible, but I filter out the stuff that I don't want in my logs. Also, I tend to go over my logs daily. If you keep them for more than a few days, they tend to fill up very quickly and scrolling with Checkpoints' log viewer can get tediously slow, especially if you have the name resolution option enabled.

I first looked over the whole firewall log checking for patterns. A port scan will look like a single host trying a stream of ports on one IP address as shown in Figure 1. Another type of scan is an IP range scan -- a single host scanning a range of IPs (see Figure 2). Or, it can even be a combination of the two.

Another type of pattern is the denial of service (DoS) or distributed denial of service (DDoS). This might be a little harder to detect, and you must look at the time and date stamps. If you get a number of hosts trying to access your site at the same time, it might indicate a DoS or DDoS attack, which can be true especially if the source hosts are fictitious addresses. However, remember the log messages might be legitimate, especially if you have a very busy site . This requires that you go over not only the "reject" or "drop" part of the log, but also the "accept" part of the log. If you have a VPN installed, and you have VPN connections, make sure that they are legitimate. Is this person connecting from overseas or have their IDs been cracked?

What can you do after you have gone through the logs and found various patterns and intrusion attempts? You can report it the local authorities, which can be particularly helpful if the intrusion attempts are continuous. Remember, each intrusion attempt is also using up your Internet connection bandwidth.

I have written a small batch of scripts that (paired with some small C programs to go over a firewall log) find out who is responsible (using whois) for each possible intrusion attempt, and email them a warning concerning the intrusion attempt. This usually has the affect of a person or ISP receiving emails from me, and in the case of an ISP, they sometimes run their own intrusion detecting software and try and "catch" the potential hacker.

I remove all the rejects and drops that have occurred in the firewall log, thus:

#!/bin/ksh
/etc/fw/bin/fw log -l -n -c drop -c reject | grep hme0 | grep -v \
  domain > /tmp/logfw$$

The main script that runs the whole procedure, is shown below:

#!/bin/ksh
#Checkfwlog script.

# Firstly filter out all the non necessary stuff.
awk '{printf("%s\t%s\t%s\t%s\t%s\t%s\t%s\t%s\t%s\t%s\n",$1, $2, \
  $3 ,$5, $7, $9, $11,$13, $15, $17)}' $1 > /tmp/checkfw$$

# add to the firewall log, who is responsible for each line
c_checkfwlog /tmp/checkfw$$ > /tmp/fwandemail$$

# find all email addresses and sort it by email address
grep @ /tmp/fwandemail$$ | sort -d -k 11 > /tmp/fwemailonlysorted$$

# Mail out the complaint letters according to the file
mail_complaints /tmp/fwemailonlysorted$$

After I have removed what is unnecessary, I run the program c_checkfwlog. This is a program used in conjunction with the following script:

#!/bin/ksh
# Script: check_whois
rwh='whois -h whois.ripe.net $1 | grep e-mail | awk '{print $NF}' \
  | sed '2,$d''
if [[ $rwh != "" ]]
then
echo $rwh
exit
fi
irw='whois $1 | grep @ | awk '{print $NF}' | sed '2,$d''
if [[ $irw != "" ]]
then
echo $irw
exit
fi

The c_checklog program is a little more complicated. As shown by the comments inside the C program, the log file is opened, then the program sifts out the source IP address. Before running the check_whois script, the program runs through an array of all the IP addresses found with the email responsible for them. This is much more efficient than running the whois command for each IP address in the log, since many of the log lines will be repeated.

If the email address is not found, the program calls the check_whois script and finds out who is responsible for the IP address. Before continuing, the program adds this address to the email address array. The program then adds this email address to the current line of the log.

After going through the whole log file, the file is closed. We are then left with an adapted log file with added email addresses responsible for each IP address. See Listing 1. (Listings for this article are available from the Sys Admin Web site: http://www.sysadminmag.com.)

Going back to the main script, the following line now runs:

grep @ /tmp/fwandemail$$ | sort -d -k 11 > /tmp/fwemailonlysorted$$

Following this, we run the mail_complaints.c program (Listing 2) to go over this new adapted log and mail out the letters to the email addresses:

The program runs in a very simple manner. Since we are working on an email sorted logfile, the program runs through the file by first starting the email header, which contains details of "Dear ..." explaining why we are sending the email. Then for each line of the same email, it writes out the content of the log to another temporary file. When the program reaches a different email, it attaches the temporary file to the email header, and writes out the email footer, saying "thank you", etc. The email is then sent to the email address, and a copy is sent to the admin for reference.

The above two programs were written on the fly and can probably be written in a more efficient manner or easily transcribed to a shell script or a Perl script that works on the same algorithm. Listing 3 is of an address scan by a person, trying to intrude our systems, and Listing 4 is the email response.

These programs and scripts are obviously no substitute for commercial intrusion detection software, and the firewall log should also be checked for those addresses that receive an accept or do get through, since they could also indicate a successful intrusion by a cracker, as I indicated above.

Conclusion

Having a firewall installed is not enough; you must review the logs checking for intrusion attempts and also successful log attempts. I have shown that with a few simple scripts and programs, you can locate these attempts and even do something about them. Furthermore, if necessary, these sorted log scripts can be handed over to the local authorities for further criminal investigation.

Mark Prager is the Senior UNIX Manager at Seabridge and has a 15-year history with the software industry. He is skilled in many aspects of the software industry, including software engineering, computer security, and network planning. He is also a frequent contributer to the CCIUG newsgroup and experienced in the management of Rational's Clearcase and Multisite.