The Goal
The goal is to detect, alert to, and log this type of activity. We do this in several ways. First, we receive an email alert whenever someone is attempting to scan or probe your network. We want to automate the entire process, saving you time and energy, this way you do not have to spend hours looking through your logs for scanning activity. We also want to archive this information in a database for future use. One possible email alert would look as follows:

Date: Wed, 31 Dec 1997 15:40:01 -0600 (CST) 
From: ids@example.net 
To: fwadmin@example.net 
Subject: #### Firewall ALERT #### 

You have received this message because someone is potentially scanning your systems. The
information below is the packet that was denied and logged by the Firewall. This is email alert
number 3, with a limit of 5 from evil.example.org. 

----- CRITICAL INFORMATION ----- 

Date: 31Dec1997 
Time: 15:39:59 
Source: evil.example.org 
Destination: ns1 
Service: domain-tcp 

----- ACTUAL LOG ENTRY ----- 

31Dec1997 15:39:59 drop fw1 >elx0 mail proto tcp src evil.example.org dst ns1 service
domain-tcp s_port 37401 len 44 rule 6 

As you see, this email is alerting the fwadmin that someone has attempted to conduct an un-authorized zone transfer from the nameserver. However, the firewall denied the attempt, logged it, AND alerted the fwadmin. In the email alert, we have parsed the critical information for easy reading, and also included the actual log entry for more data. You can also creat your own alerts, such as text pages or snmp traps. In addition, we want to log these alerts to a file for archiving and future reference.

The Solution
To detect and monitor these scans, we will build a script that first logs whenever someone connects to a predetermined port, and then emails us an alert. To do this, we will be using the User Defined Alert. The User Defined Alert will be our script, alert.sh. Whenever the User Defined Alert is activated, it will launch our script, which parses the data and does all the work for us. We set up our Firewall rule base as follows.. First, we identify the most commonly scanned ports we want to monitor. Then we select several systems to listen on these ports. When an intruder scans our network, he will most likely hit our systems listening on these ports. When these ports are scanned, the Firewall logs the attempts then executes the User Defined Alert.

The end result is you receive an email for each port scanned. If you have 3 systems, each listening on 4 ports, then you may get up to 12 emails from a single network port scan. However, this is normally not the case. If black-hats are scanning an entire network, they are normally looking for a single vulnerability, such as imap (port 143). In this case, we would have received only three emails, one from each system. When they scan a single target, often they scan a range of ports, such as 1-1024. In that case, we would have received only 4 emails, one for each port on the system. Based on what emails you get, you can quickly determine what the intruder is interested in. Also, the script alert.sh is configurable to limit the total amount of emails as a result of a scan (the default limit is 5). All scans are also logged to a database.

For those of you with more then one firewall, the script should be installed on the Management Server. The Management Server receives all firewall logs and executes the User Defined Alert (our script) local on itself. So if you have 5 Firewall modules reporting to a single Managment Module, you would install the script on the single Management Module. All 5 Firewall modules can use the script(as defined in their rulebases), however the script is executed on the Management module (where all the logs are). This is extremely advantageous to you, as you can detect scan patterns happening across multiple firewalls.

Implementation
To implement this methodology, we first identify two to three systems for each firewall to use for monitoring. I often select DNS servers, as these are primary targets, many scanning tools start by scanning these systems. Once you have identified the systems you will monitor, create a workstation object in your Firewall 1 GUI for each of the systems. The systems do not necessarily have to actually exist. Create an object for a non-existing system, give it a valid IP that your are not using, and use this as one of your scannable objects. Once you have created your workstation objects, then select the most commonly scanned ports. Ensure that your systems are not using these ports, or every time someone connects to it, you will be alerted. To identify commonly scanned ports, CERT alerts are a great place to start, you can find these alerts at http://www.cert.org. Some ports that you can use are:

dns zone transfer 53/TCP
portmapper 111/TCP
http 80/TCP
SMB 139/TCP
imap 143/TCP
BackOrrifce 31337/UDP --> Yes, people are STILL scanning for old BO.

I like these ports since black-hats commonly look for them, but most of your systems will not be using them. Make sure these ports are not already blocked by a screening router. We will then set several system to listen on these ports, alerting us when there is a connection. Below is an example of a rule that monitors and detects the scans. Notice that quite a few ports are being monitored for these systems.

1. First, we need to customize our script, which is done in the beginning of the script. This should be self explanatory.

################################################################# 
# BEGIN CUSTOMIZING SCRIPT HERE # 
################################################################# 

# INSTALL DIRECTORY 
# Define the directory that this script is in. 
# Do NOT put a slash at the end. 
# EXAMPLE: dir=/home/fwadmin/alert 
dir= 

# FW ADMIN 
# Define the name of who gets the email alerts 
# EXAMPLE: user=fwadmin@example.com 
user= 

# SCAN LIMIT 
# Define maixmum number of scans/email alerts 
limit=5 

# EMAIL REMOTE SYSTEM 
# Define as "true" if you want to automatically email 
# the remote admin when you reach your scan limit. 
email=false 

# SAM 
# Define as "true" if you want to autotmatically block 
# the source if you reach your scan limit. 
sam=false 

# SAM TIMEOUT 
# How long do you want the source blocked 
# Default is 3600 seconds (1 hour). 
timeout=3600 

################################################################# 
# FINISH CUSTOMIZING SCRIPT HERE # 
################################################################# 

2. We then define our system variables. Also, we check to see if we have met our scan limit. If we have, bail now to save CPU cycles. This is where the speed optimization happens.

4. We then build our alert emails. This is the template used for every email alert that is generated.

cat <<EOF > $send

You have received this message because someone is potentially
scanning your systems. The information below is the packet
that was denied and logged by the Firewall. This is email alert
number $scan, with a limit of $limit from $src.

----- CRITICAL INFORMATION -----

Date: $date
Time: $time
Source: $src
Destination: $dst
Service: $service

----- ACTUAL FW-1 LOG ENTRY -----

`cat $message`
EOF

5. Last, we reach the phases part. This is where we define what the script does (in addition to the alert emails) based on how many time the source has probed us. This is broken down into three parts, or phases. Feel free to change/modify these phases as you see fit. I've tried to make this as modular as possible for just that reason. Regardless, once we are done, we send off the email alert.

• PHASE 1: This is when we receive the very first packet. The entry is logged in the alert.uniq file.
• PHASE 2: This is when we receive the 2nd to $limit-1 packets. Currently nothing happens during phase 2
• PHASE 3: This is when we receive our $limit packets (default is 5). Here is where most of the action happens. This is where the functions Blocked(), TrackDown(), and anything else you want to add.