| No discussion of firewall and security tools is complete without a brief discussion regarding security-testing tools. Firewall administrators should make regular use of two primary tools to perform basic testing of the firewall ruleset and the firewall's ability to protect hosts and networks: port-scanning tools and vulnerability-scanning tools. To be sure, for an in-depth review of security, other tools such as password-cracking tools, packet-crafting tools, and exploit frameworks should absolutely be considered (a discussion of which is beyond the scope of this appendix). Port-Scanning Tools Port-scanning tools function by attempting to connect to a host using a range of TCP and UDP ports. This information can then be used to determine which ports are listening, and thus which applications are probably running on the host. Port-scanning tools are one of the best ways to test your firewall ruleset, because the ruleset should allow traffic only on the ports that you have defined. If you port scan the firewall (or the IP addresses of the protected hosts the firewall is protecting) and find that it responds on ports other than the ones that you have defined, there is a good chance that the firewall ruleset is misconfigured and therefore may be exposing the protected host/network to external threats. The most common and popular port scanner is Nmap. Nmap is an open source utility that runs on Windows, Linux, and UNIX hosts and can be downloaded from http://www.insecure.org. Nmap contains both a command-line utility and a graphical front end; however, the Windows graphical front end has not been maintained and updated for quite some time. Running Nmap is a straightforward process. Running Nmap without any options brings up the usage screen, as shown in Example A-9. Example A-9. Nmap Usage Screen C:\Download\Hacking Tools\Nmap\nmap-3.93>nmap Nmap 3.93 Usage: nmap [Scan Type(s)] [Options] <host or net list> Some Common Scan Types ('*' options require root privileges) * -sS TCP SYN stealth port scan (default if privileged (root)) -sT TCP connect() port scan (default for unprivileged users) * -sU UDP port scan -sP ping scan (Find any reachable machines) * -sF,-sX,-sN Stealth FIN, Xmas, or Null scan (experts only) -sV Version scan probes open ports determining service & app names/versions -sR RPC scan (use with other scan types) Some Common Options (none are required, most can be combined): * -O Use TCP/IP fingerprinting to guess remote operating system -p <range> ports to scan. Example range: 1-1024,1080,6666,31337 -F Only scans ports listed in nmap-services -v Verbose. Its use is recommended. Use twice for greater effect. -P0 Do not ping hosts (needed to scan www.microsoft.com and others) * -Ddecoy_host1,decoy2[,...] Hide scan using many decoys -6 scans via IPv6 rather than IPv4 -T <Paranoid|Sneaky|Polite|Normal|Aggressive|Insane> General timing policy -n/-R Never do DNS resolution/Always resolve [default: sometimes resolve] -oN/-oX/-oG <logfile> Output normal/XML/grepable scan logs to <logfile> -iL <inputfile> Get targets from file; Use '-' for stdin * -S <your_IP>/-e <devicename> Specify source address or network interface --interactive Go into interactive mode (then press h for help) Example: nmap -v -sS -O www.my.com 192.168.0.0/16 '192.88-90.*.*' SEE THE MAN PAGE FOR MANY MORE OPTIONS, DESCRIPTIONS, AND EXAMPLES
|
Nmap supports both TCP and UDP port scanning, and for TCP port scanning it supports the following methods: Connect scan This is a basic form of TCP scanning and uses the connect() system call provided by the operating system to attempt to connect to the remote host on the given port number and open a session. This is essentially the three-way handshake process, and although it provides a relatively certain method of identifying open ports, it is also easy to detect and is slower to perform a complete scan because of the additional overhead and wait time required for session establishment and teardown. SYN scan This is the most common type of scan and is frequently referred to as "half-open" scanning because of how it works. For a SYN scan, Nmap attempts to initiate a SYN request to the target host on the given port number. If a RST response is received, the port is considered closed. If a SYN/ACK is received, the port is considered open. Nmap immediately sends an RST to tear down the session and proceeds to test the next port. This makes a SYN scan a fast scan to perform and complete, but it can produce incorrect results and requires root access on Linux and UNIX hosts to be run. FIN stealth, Xmas tree, and Null scan These scanning techniques are all intended to be as quiet and difficult to detect as possible by sending packets that are out of context and have various TCP flags set (or unset in the case of a Null scan). The general concept behind these techniques is that a closed port is supposed to respond to a connection attempt with an RST, whereas open ports generally ignore these kinds of packets out of context. Nmap sends packets with the FIN flag (FIN stealth); FIN, URG, and PUSH flags (Xmas tree); and no flags (Null scan) in an attempt to "surprise" the host (that is, the host is receiving packets that it does not have a corresponding session with). The drawback to these kinds of scans is that although all hosts should support RFC 793, many do not and therefore respond inappropriately to FIN scans. This lack of support causes them to respond with an RST for all ports, when they should instead be dropping the packets on open ports. Therefore, these are rarely used.
In most cases, a SYN or Connect scan is more than adequate for testing your systems. Example A-10 shows the running of a SYN scan. Example A-10. Basic Nmap SYN Port Scan Against a Cisco Secure PIX Firewall [root@keoland nmap]# nmap -sS -P0 -O -vv 10.10.10.1 Starting nmap 3.93 ( http://www.insecure.org/nmap/ ) at 2005-10-04 14:10 CDT Initiating ARP Ping Scan against 10.10.10.1 [1 port] at 14:10 The ARP Ping Scan took 0.01s to scan 1 total hosts. Initiating SYN Stealth Scan against firewall.myco.com (10.10.10.1) [1668 ports] at 14:10 Discovered open port 443/tcp on 10.10.10.1 Discovered open port 25/tcp on 10.10.10.1 Discovered open port 21/tcp on 10.10.10.1 Discovered open port 80/tcp on 10.10.10.1 SYN Stealth Scan Timing: About 32.99% done; ETC: 14:11 (0:01:00 remaining) Discovered open port 110/tcp on 10.10.10.1 The SYN Stealth Scan took 65.80s to scan 1668 total ports. Warning: OS detection will be MUCH less reliable because we did not find at least 1 open and 1 closed TCP port For OSScan assuming port 21 is open, 33480 is closed, and neither are firewalled Host firewall.myco.com (10.10.10.1) appears to be up ... good. Interesting ports on firewall.myco.com (10.10.10.1): (The 1663 ports scanned but not shown below are in state: filtered) PORT STATE SERVICE 21/tcp open ftp 25/tcp open smtp 80/tcp open http 110/tcp open pop3 443/tcp open https MAC Address: 00:0C:CE:E5:16:23 (Cisco Systems) Device type: general purpose Running: Microsoft Windows 2003/.NET | NT/2K/XP OS details: Microsoft Windows 2003 Server or XP SP2, Microsoft Windows 2000 SP3 OS Fingerprint: TSeq(Class=TR%IPID=I%TS=0) T1(Resp=Y%DF=Y%W=402E%ACK=S++%Flags=AS%Ops=MNWNNT) T2(Resp=N) T3(Resp=N) T4(Resp=N) T5(Resp=N) T6(Resp=N) T7(Resp=N) PU(Resp=N) TCP Sequence Prediction: Class=truly random Difficulty=9999999 (Good luck!) TCP ISN Seq. Numbers: E44FD2A5 AA5F5E6D 8CCB934 69128FD1 6AD48312 4CDF45B5 IPID Sequence Generation: Incremental Nmap finished: 1 IP address (1 host up) scanned in 68.462 seconds Raw packets sent: 5029 (202KB) | Rcvd: 25 (1244B)
|
Vulnerability-Scanning Tools Vulnerability scanning takes the concept of port scanning to the next level. Now that you know which ports are open, which vulnerabilities might exist on the host that is listening on those ports? You can use a number of commercial and freeware vulnerability scanners to test virtually any system on a network, including firewalls. One of the most popular is the open source vulnerability scanner named Nessus. You can obtain Nessus from http://www.nessus.org/; it is freeware and can be installed on Linux/UNIX hosts (for testing of your own systems only) or is a commercial product for installation on Windows hosts (named Tenable NeWT). Nessus operates in a client/server fashion with the server performing all the testing and scanning and the client providing the front-end configuration and reporting. You can install the client and server on the same system, or you can install the client on a remote system that will connect to the server. If configured in that manner, you can use a freeware Windows client named NessusWX to allow the Windows client to connect to the Linux/UNIX server. Nessus maintains a list of plug-ins that have been written to detect vulnerabilities; at the time of this writing, it contains 9700 plug-ins. To run Nessus, you need to perform two steps. First, start the Nessus server. Second, start the Nessus client. You can do this by running the commands in Example A-11. Example A-11. Running Nessus on a Linux host [root@keoland nessus]# nessusd -D All plugins loaded [root@keoland nessus]# nessus &
|
Using the switch & specifies to run the command and return to the command line after the application has launched. When Nessus launches, you are prompted to log in to the server, as shown in Figure A-4. Figure A-4. Nessus Login Screen 
At this point, performing a scan is just a matter of navigating the tabbed screens and specifying the appropriate plug-ins to load, options for the scan, and target hosts. As shown in Figure A-5, if I want to scan Cisco hosts for vulnerabilities, I just ensure that I select the appropriate Cisco plug-ins and start the scan. Something to keep in mind is that not all plug-ins are considered "safe" to run. What that means is that some plug-ins are risky in nature and could result in the targeted host crashing or otherwise having a negative result. These "risky" plug-ins are identified by a red triangle with an exclamation point in the middle. Use caution when you decide to run these plug-ins. Figure A-5. Nessus Plug-In Screen 
When the scan has completed, Nessus launches the report containing the status of what was detected, as shown in Figure A-6. Keep in mind that all vulnerabilities scanners make a best guess at what they believe is occurring, but this is not a guarantee. Consequently, you may find false positives, false negatives, or downright incorrect results. You always need to investigate the results of the vulnerability scan in more detail using more specialized tools to ascertain whether the targeted system is indeed vulnerable to the stated exploit. This last sentence is important to understand because a lot of companies think running Nmap or Nessus constitutes an audit. They do not! Anyone you pay to audit your environment who just performs those steps is ripping you off, because you can do that yourself for free. Figure A-6. Nessus Results 
|
