Let’s begin our discussion with some basics about firewalls. From the implementation perspective, firewalls can be classified into those that are host-based and the network firewalls.
Host-based firewalls
These are software running on a single host (read, computer system), which are used to control inbound traffic (traffic from the network towards the host) and outbound traffic (from the host towards the network). These are installed on the operating systems of individual computers. Examples include IPTables and Firestarter for Linux, and Zone Alarm and Tiny Personal Firewall, for Windows.
Host-based firewalls control the access of various services running on the host in a granular way, so that important services are accessible only to a few computers in the network. For example, the FTP service may be accessible only to a few IP addresses; others will not even know that FTP runs on this server.
Similarly, they can also be configured to allow only certain programs installed on the host to access the Internet. For example, you may block Internet Explorer, and allow Mozilla Firefox to browse the Internet. You may also block Nero Burning ROM from checking for updates every time you boot the PC.
Network firewalls
These are either hardware devices, software, or combinations of hardware and software, which are used to control inbound traffic from the external, unprotected network (typically the Internet) toward the protected network (typically an internal network such as a LAN), and outbound traffic from the protected network towards the external network.
Firewalls are installed in between the protected and unprotected network. They watch all traffic going to and fro, and are configured by setting rules to allow only the required inbound and outbound traffic, according to the Internet usage policy of the organisation. The firewall compares all access requests with the predefined rule-set, and only the traffic that matches these rules, is allowed across.
Once the firewalls are installed and configured as per requirements, it becomes a must to verify whether the configured rules are according to the access policy. One of the best ways to verify this is to use Nmap. This article demonstrates scanning a network firewall using Nmap.
Before we proceed, let us recap the various Nmap commands that were covered in earlier articles. The summary of important Nmap options is given in Table1.
Nmap command line:
nmap [Scan Type(s)] [Options] {target specification}
| Table1: Summary of important Nmap commands | ||
| Type | Command | Description |
| Type of scanning | -sS |
TCP SYN Scan |
-sT |
TCP Connect Scan | |
-sF |
FIN Scan | |
-sA |
ACK Scan | |
-sW |
Window Scan | |
| Port specification | -p |
Scan for TCP ports |
-sU |
Scan for UDP ports | |
-r |
Do a sequential port scan (don’t randomise the ports) | |
-F |
Fast scan, scans fewer ports | |
| OS/Service/Version Detection | -O |
Detect operating system |
-sV |
Version detection | |
| Host Discovery | -sL |
List targets |
-PN |
Do a ‘ping scan’ | |
| Timing/Performance | -T(0-5) |
5 is the fastest, 0 is the slowest |
-F |
Fast scan, scans fewer ports | |
| Firewall/IDS Evasion and Spoofing | -D IP_Addresses |
Decoy hosts |
-g port_number |
Spoof source port | |
-f |
Fragment packets | |
| Output | -oN |
Normal output |
-oG |
Grepable output | |
-oX |
XML output | |
-oA |
Output in all three formats | |
| Target Specification | IP address —192.168.100.1, 192.168.100.2 |
Specify comma-separated IP addresses |
List of IP addresses —192.168.100.1-50 |
Give a range of IP addresses | |
CIDR —192.168.100.1/24 |
CIDR specification | |
-iL filename |
Read the list of IP addresses from the file filename |
|
To scan a firewall effectively, you must check all open ports, their status and the services running on them. The best strategy is to use as many scan types as possible. Combine all of them, and arrive at the final list of ports and corresponding services. While scanning, do not forget to use Nmap timing options to fine-tune the scan and get fast results.
Table 2 details firewall scanning basics.
| Table 2: Firewall scanning details | ||
| Port status | Port type | Details |
| Blocked | Closed port | Most of the firewall ports should be in a closed state |
| Filtered | Filtered port | A few ports may be filtered to restrict access of the running services to a few IP addresses |
| Allowed | Open port | Very few ports should be in an open state. Whenever you find them, do not forget to probe further and close non-required ports |
Now that we’ve refreshed our memories about the basics, let us proceed to scan firewalls by using Nmap — live! There is a saying that “Experience is the most effective guru”. To understand the firewall scanning technique effectively, let us scan a live firewall, and study the output results.
Live firewall scanning
The test environment was set up using the IPCop firewall, PPPoE Internet connection, and openSUSE with Nmap version 5.21. The details are as follows:
- Nmap PC: openSUSE Linux — 192.168.1.201 (scans performed with root privileges)
- Firewall Internet (Red) port — PPPoE, IP 117.x.x.x
- Firewall Internal (Green) port — 192.168.1.1
Various other parameters of the firewall were set as follows:
- The firewall’s default Web access (HTTPS) port, TCP 445, was changed to a non-standard port, TCP 775, for better understanding of the scanning technique.
- External access to this non-standard HTTPS port was enabled.
- The ping response of the firewall to the Internet was disabled.
(Some of the scan result lines were removed from the actual scan output, due to space constraints.)
So, here we go. Let’s start the scanning with an ACK scan, and check for open TCP ports. First, the firewall was scanned without using the -PN option, but since the ping response was disabled, Nmap recommended using the -PN option.
| Table 3: ACK scan | |
| Command and results | Explanation |
nmap -PN -sA -vv -n -p1-1000 -T4 -oNmapACKScan.txt 117.X.X.X |
Scan command line; -n doesn’t do reverse DNS, thus saving scan time. |
| Nmap scan report for 117.X.X.X | |
| Host is up. | Though ping is disabled on the firewall, it detects that the host is up. |
| All 1000 scanned ports on 117.195.42.218 are filtered | But fails to find the open port, 775. |
| # Nmap done at Wed Jan 5 02:04:44 2011 — 1 IP address (1 host up) scanned in 101.87 seconds | Requires slightly less than two minutes to complete the scan. |
The ACK scan as well as a Window scan (-sW) couldn’t find any open ports on the firewall. So, let’s proceed with another scanning technique, the TCP connect scan.
| Table 4: TCP connect scan | |
| Command and results | Explanation |
nmap -PN -sT -vv -n -p1-1000 -T4 -oNmapTCPConnect.txt 117.X.X.X |
|
| Nmap scan report for 117.X.X.X Not shown: 999 filtered ports PORT STATE SERVICE 775/tcp open entomb |
Open port 775 found, running service entomb |
| # Nmap done at Wed Jan 5 02:33:32 2011 — 1 IP address (1 host up) scanned in 91.78 seconds | |
The TCP connect scan did find the open TCP port 775. Since version detection was not performed, the default service related to the port number (entomb) is seen in the output. A SYN scan with fragmentation was performed next. Here, one more option was selected — reduce maximum RTT timeout setting to 15 milliseconds.
| Table 5: SYN scan | |
| Command and results | Explanation |
nmap -PN -sS -f -vv -n -p1-1000 -T4 -max-rtt-timeout 15 -oNmapSYNScan.txt 117.X.X.X |
Timing settings changed for better performance |
| Nmap scan report for 117.X.X.X Host is up (0.049s latency). Scanned at 2011-01-05 02:41:20 IST for 14s Not shown: 999 filtered ports PORT STATE SERVICE 775/tcp open entomb |
Finds open port 775, service entomb |
| # Nmap done at Wed Jan 5 02:39:34 2011 — 1 IP address (1 host up) scanned in 14.74 seconds | Note the improvement in timing by applying the maximum timeout setting. Instead of 2 to 8 minutes, it completed in less than 15 seconds! |
The SYN scan also detected TCP 775 as an open port. The time required to complete the full scan was less than 15 seconds, compared to earlier scans, which required 100 to 120 seconds.
Performing a SYN scan with the command line nmap -PN -sS -vv -p1-1000 -oNmapSYNStandardscan.txt 117.X.X.X required more than 300 seconds to complete in this scenario. For efficient Nmap scanning, it is best to choose proper timing options.
The probing was continued further, to detect the actual service running on the open port that was found, by performing a version detection scan, shown in Table 6.
| Table 6: Version detection scan | |
| Command and results | Explanation |
nmap -PN -sV -vv -n -p775 -oNmapServiceDetection.txt 117.X.X.X |
|
PORT STATE SERVICE VERSION 775/tcp open http Apache httpd |
|
| Service detection performed. Please report any incorrect results at http://nmap.org/submit/. | You may send the incorrect reports to the Nmap development team for improvement in further Nmap versions. |
| # Nmap done at Wed Jan 5 02:47:29 2011 — 1 IP address (1 host up) scanned in 11.43 seconds | So, it requires less than 12 seconds to detect that Apache httpd is running on the non-standard TCP port 775. |
Though, as examples, we have scanned only TCP ports 1 to 1,000 above, it would be prudent to scan all 65,535 TCP as well as UDP ports, by using all important scan techniques, and version detection thereafter.
Once various scans are completed, the combination of all the results should be used to verify the firewall settings. If any unwanted services are running on the firewall, or if unwanted ports are open, they should be disabled or closed, respectively.
Now, let us go ahead and scan the same firewall from inside the network.
| Table 7: Firewall scan from inside the network | |
| Command and results | Explanation |
nmap -vv -sU -sT -p1-1000 -n -r -T4 -oNmapIPCopInternal.txt 192.168.1.1 |
We run a UDP port scan and TCP connect scan, for ports 1-1,000. Running this command generates a lot of logs on the firewall. Please see Figure 1, for a screenshot of the firewall logs. Also notice that the open port does not generate any log. |
| Host is up (0.040s latency). Scanned at 2011-01-05 15:24:01 IST for 44 Not shown: 998 open|filtered ports, 994 filtered ports PORT STATE SERVICE 53/tcp open domain 80/tcp open http 123/tcp closed ntp 222/tcp open rsh-spx 775/tcp open entomb 800/tcp open mdbs_daemon 53/udp open domain 123/udp closed ntp |
|
We then probe the open ports further by running a service detection scan, as in Table 8.
| Table 8: Service detection | |
| Command and results | Explanation |
nmap -vv -p53,80,123,222,775,800 -sV -oNmapIPCopIntUDPServDet.txt 192.168.1.1 |
We probe only the open ports. |
| Running service detection against all ports may take just too long!! Scanned at 2011-01-05 15:36:56 IST for 12s PORT STATE SERVICE VERSION 53/tcp open domain dnsmasq 2.45 80/tcp open http-proxy Squid webproxy 2.7.STABLE9 123/tcp closed ntp 222/tcp open ssh OpenSSH 4.7 (protocol 2.0) 775/tcp open http Apache httpd 800/tcp open http-proxy Squid webproxy 2.7.STABLE9 |
|
Observations
The scanned firewall runs various services for the inside network, including DNS, SSH, HTTPS and Web proxy. These are accessible to all PCs on the internal network. It also runs a transparent proxy on port 80, so that client browser settings are not required to be changed. Running an OS version scan on this firewall (-A) correctly reveals its operating system as IPCop Firewall 1.4.10/1.4.21, Linux 2.4.31-2.4.36, along with its SSH host keys.
Recommendations for this firewall
- The firewall HTTPS interface is being used for remote management. This should be enabled only at the time of remote management/reconfiguration.
- Disable the transparent proxy mode of the firewall. You can effectively control browsing traffic only by non-transparent proxying.
- HTTPS and SSH services are required to reconfigure the firewall. Restrict their access only to the MAC address of administrator PC.
- Further scan all ports (1,001-65,535) to identify running services, and close unwanted services.
- The NTP service running on the firewall is closed for the protected network. Reconfigure firewall to provide NTP service on the internal network.
Some important details of the Nmap latest release
The current stable release of Nmap is version 5.21. It is available for free download here. The latest development release is 5.35DC1, available since December 29, 2010.
One of the most important features of Nmap is scripting, which enables users to write predefined scans and automate various tasks. The latest release adds some very interesting scripts in the Nmap database, which include ftp-bounce to detect servers with the FTP bounce vulnerability, stuxnet-detect to detect the presence of the Stuxnet worm, ftp-anon to list directory listings if an anonymous FTP login is enabled — to name a few.
Keep a watch on this series for further information about the interesting world of Nmap.
In Table 1, the description for -PN sould be corrected from “Do a ‘ping scan’” to “Don’t perform a ‘ping scan’”