Home > Articles > Operating Systems, Server > Solaris

  • Print
  • + Share This
Like this article? We recommend

Verifying Firewall Services

After installing a host, it is prudent security practice to verify that only those services that are intended to be exposed to the network are exposed. Most Linux distributions provide the open source utility nmap, which is a general-purpose network scanner. The nmap utility lists ports that are open. The utility has many options, but for our purposes only two are necessary: -sT and -sU, which scan for open TCP and UDP ports, respectively.

Scanning for open TCP ports is simple. Performing a TCP port scan using nmap shows the following output.

[root@scl1 root]# nmap -sT lsg-parity4

Starting nmap V. 2.54BETA22 ( http://www.insecure.org/nmap/ )
Interesting ports on lsg-parity4 (192.168.0):
(The 1526 ports scanned but not shown below are in state: closed)
Port    State    Service
21/tcp   open    ftp
22/tcp   open    ssh
23/tcp   open    telnet
37/tcp   open    time
111/tcp  open    sunrpc
1014/tcp  open    unknown
6000/tcp  open    X11
22289/tcp open    wnn6_Cn
32770/tcp open    sometimes-rpc3

Nmap run completed -- 1 IP address (1 host up) scanned in 0 seconds

It is clear that this host exposes too many services to the network. On a production system, most of these services are unnecessary and should be turned off, and the software that implements them removed.

After installing the firewall configuration, we have only two services exposed:

[root@scl1 root]# nmap -sT lsg-parity4

Starting nmap V. 2.54BETA22 ( http://www.insecure.org/nmap/ )
Interesting ports on lsg-parity4 (192.168.0):
(The 1538 ports scanned but not shown below are in state: filtered)
Port    State    Service
21/tcp   open    ftp
22/tcp   open    ssh
80/tcp   closed   http
113/tcp  closed   auth

Nmap run completed -- 1 IP address (1 host up) scanned in 139 seconds

The host does not run a web server, but our firewall allows web server traffic (http) to pass through, so nmap is able to get a response from the TCP stack. No configuration changes were made to the host, except for the installation of the firewall.

For more information about nmap, refer to the nmap(1) manual page or the web site at http://www.insecure.org/nmap/.

If the behavior of the firewall is not what you are expecting, the following might be helpful. Enter the following command:

# iptables -vL

This command produces a list of firewall rules that includes the number of times each rule has matched. This list can be useful when determining which rule in the firewall is causing unexpected behavior.

The iptables firewall we created passes log entries to the system log daemon, which by default writes them to the file /var/log/messages. The nmap probe causes the firewall to generate lines of the form:

Oct 28 11:36:42 testhost kernel: IN=eth0 OUT= MAC=00:c0:f0:3e:28:b9:00:03:47:31:89:41:08:00
 SRC=192.168.44.12 DST=192.168.44.105 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=57606 DF PROTO=TCP
 SPT=53360 DPT=374 WINDOW=5840 RES=0x00 SYN URGP=0 
Oct 28 11:36:48 testhost kernel: IN=eth0 OUT= MAC=00:c0:f0:3e:28:b9:00:03:47:31:89:41:08:00 
 SRC=192.168.44.12 DST=192.168.44.105 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=29197 DF PROTO=TCP 
 SPT=53569 DPT=7009 WINDOW=5840 RES=0x00 SYN URGP=0 
Oct 28 11:36:54 testhost kernel: IN=eth0 OUT= MAC=00:c0:f0:3e:28:b9:00:03:47:31:89:41:08:00 
 SRC=192.168.44.12 DST=192.168.44.105 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=36024 DF PROTO=TCP 
 SPT=53786 DPT=1414 WINDOW=5840 RES=0x00 SYN URGP=0 

Information like this can be invaluable. Ideally, this information should be logged to a secure host, and it should be monitored either automatically or periodically, as determined by your security policies and procedures.

  • + Share This
  • 🔖 Save To Your Account