Like this article? We recommend
Like this article? We recommend
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.