| [ Team LiB ] |
|
Recipe 9.13 Testing for Open Ports9.13.1 ProblemYou want a listing of open network ports on your system. 9.13.2 SolutionProbe your ports from a remote system. To test a specific TCP port (e.g., SSH): $ telnet target.example.com ssh $ nc -v -z target.example.com ssh To scan most of the interesting TCP ports: # nmap -v target.example.com To test a specific UDP port (e.g., 1024): $ nc -v -z -u target.example.com 1024 To scan most of the interesting UDP ports (slowly!): # nmap -v -sU target.example.com To do host discovery (only) for a range of addresses, without port scanning: # nmap -v -sP 10.12.104.200-222 To do operating system fingerprinting: # nmap -v -O target.example.com For a handy (but less flexible) GUI, run nmapfe instead of nmap. 9.13.3 DiscussionWhen attackers observe your systems from the outside, what do they see? Obviously, you want to present an image of an impenetrable fortress, not a vulnerable target. You've designed your defenses accordingly: a carefully constructed firewall, secure network services, etc. But how can you really be sure? You don't need to wait passively to see what will happen next. Instead, actively test your own armor with the same tools the attackers will use. Your vulnerability to attack is influenced by several interacting factors:
Start by testing the last two subsystems in isolation. Verify your firewall operation by simulating the traversal of packets through ipchains. [Recipe 2.21] Examine the network state on your machines with netstat. [Recipe 9.14] Next, the acid test is to probe from the outside. Use your own accounts on distant systems, if you have them (and if you have permission to do this kind of testing, of course). Alternatively, set up a temporary test system immediately outside your firewall, which might require cooperation from your ISP. The nmap command is a powerful and widely used tool for network security testing. It gathers information about target systems in three distinct phases, in order:
To probe a single target, specify the hostname or address: # nmap -v target.example.com # nmap -v 10.12.104.200 We highly recommend the -v option, which provides a more informative report. Repeat the option (-v -v...) for even more details. You can also scan a range of addresses, e.g., those protected by your firewall. For a class C network, which uses the first three bytes (24 bits) for the network part of each address, the following commands are all equivalent: # nmap -v target.example.com/24 # nmap -v 10.12.104.0/24 # nmap -v 10.12.104.0-255 # nmap -v "10.12.104.*" Lists of addresses (or address ranges) can be scanned as well: # nmap -v 10.12.104.10,33,200-222,250 By default, nmap uses both TCP and ICMP pings for host discovery. If these are blocked by an intervening firewall, the nmap -P options provide alternate ping strategies. Try these options when evaluating your firewall's policies for TCP or ICMP. The goal of host discovery is to avoid wasting time performing port scans for unused addresses (or machines that are down). If you know that your targets are up, you can disable host discovery with the -P0 (that's a zero) option. The simplest way to test an individual TCP port is to try to connect with telnet. The port might be open: $ telnet target.example.com ssh Trying 10.12.104.200... Connected to target.example.com. Escape character is '^]'. SSH-1.99-OpenSSH_3.1p1 or closed (i.e., passed by the firewall, but having no server accepting connections on the target): $ telnet target.example.com 33333 Trying 10.12.104.200... telnet: connect to address 10.12.104.200: Connection refused or blocked (filtered) by a firewall: $ telnet target.example.com 137 Trying 10.12.104.200... telnet: connect to address 10.12.104.200: Connection timed out Although telnet's primary purpose is to implement the Telnet protocol, it is also a simple, generic TCP client that connects to arbitrary ports. The nc command is an even better way to probe ports: $ nc -z -vv target.example.com ssh 33333 137 target.example.com [10.12.104.200] 22 (ssh) open target.example.com [10.12.104.200] 33333 (?) : Connection refused target.example.com [10.12.104.200] 137 (netbios-ns) : Connection timed out The -z option requests a probe, without transferring any data. The repeated -v options control the level of detail, as for nmap. Port scans are a tour de force for nmap: # nmap -v target.example.com Starting nmap V. 3.00 ( www.insecure.org/nmap/ ) No tcp,udp, or ICMP scantype specified, assuming SYN Stealth scan. Use -sP if you really don't want to portscan (and just want to see what hosts are up). Host target.example.com (10.12.104.200) appears to be up ... good. Initiating SYN Stealth Scan against target.example.com (10.12.104.200) Adding open port 53/tcp Adding open port 22/tcp The SYN Stealth Scan took 21 seconds to scan 1601 ports. Interesting ports on target.example.com (10.12.104.200): (The 1595 ports scanned but not shown below are in state: closed) Port State Service 22/tcp open ssh 53/tcp open domain 137/tcp filtered netbios-ns 138/tcp filtered netbios-dgm 139/tcp filtered netbios-ssn 1080/tcp filtered socks Nmap run completed -- 1 IP address (1 host up) scanned in 24 seconds In all of these cases, be aware that intervening firewalls can be configured to return TCP RST packets for blocked ports, which makes them appear closed rather than filtered. Caveat prober. nmap can perform more sophisticated (and efficient) TCP probes than ordinary connection attempts, such as the SYN or "half-open" probes in the previous example, which don't bother to do the full initial TCP handshake for each connection. Different probe strategies can be selected with the -s options: these might be interesting if you are reviewing your firewall's TCP policies, or you want to see how your firewall logs different kinds of probes.
UDP ports are harder to probe than TCP ports, because packet delivery is not guaranteed, so blocked ports can't be reliably distinguished from lost packets. Closed ports can be detected by ICMP responses, but scanning is often very slow because many systems limit the rate of ICMP messages. Nevertheless, your firewall's UDP policies are important, so testing is worthwhile. The nc -u and nmap -sU options perform UDP probes, typically by sending a zero-byte UDP packet and noting any responses. By default, nmap scans all ports up to 1024, plus well-known ports in its extensive collection of services (used in place of the more limited /etc/services). Use the -F option to quickly scan only the well-known ports, or the -p option to select different, specific, numeric ranges of ports. If you want to exhaustively scan all ports, use -p 0-65535. If you are interested only in host discovery, disable port scanning entirely with the nmap -sP option. This might be useful to determine which occasionally-connected laptops are up and running on an internal network. Finally, the nmap -O option enables operating system fingerprinting and related tests that reveal information about the target: # nmap -v -O target.example.com
...
For OSScan assuming that port 22 is open and port 1 is closed and neither are firewalled
...
Remote operating system guess: Linux Kernel 2.4.0 - 2.5.20
Uptime 3.167 days (since Mon Feb 21 12:22:21 2003)
TCP Sequence Prediction: Class=random positive increments
Difficulty=4917321 (Good luck!)
IPID Sequence Generation: All zeros
Nmap run completed -- 1 IP address (1 host up) scanned in 31 seconds
Fingerprinting requires an open and a closed port, which are chosen automatically (so a port scan is required). nmap then determines the operating system of the target by noticing details of its IP protocol implementation: Linux is readily recognized (even the version!). It guesses the uptime using the TCP timestamp option. The TCP and IPID Sequence tests measure vulnerability to forged connections and other advanced attacks, and Linux performs well here. It is sobering to see how many details nmap can learn about a system, particularly by attackers with no authorized access. Expect that attacks on your Linux systems will focus on known Linux-specific vulnerabilities, especially if you are using an outdated kernel. To protect yourself, keep up to date with security patches. nmap can test for other vulnerabilities of specific network services. If you run an open FTP server, try nmap -b to see if it can be exploited as a proxy. Similarly, if you allow access to an IDENT server, use nmap -I to determine if attackers can learn the username (especially root!) that owns other open ports. The -sR option displays information about open RPC services, even without direct access to your portmapper. If your firewall makes decisions based on source addresses, run nmap on different remote machines to test variations in behavior. Similarly, if the source port is consulted by your firewall policies, use the nmap -g option to pick specific source ports. The nmap -o options save results to log files in a variety of formats. The XML format (-oX) is ideal for parsing by scripts: try the XML::Simple Perl module for an especially easy way to read the structured data. Alternately, the -oG option produces results in a simplified format that is designed for searches using grep. The -oN option uses the same human-readable format that is printed to stdout, and -oA writes all three formats to separate files. nmap supports several stealth options that attempt to disguise the source of attacks by using third-parties as proxies or decoys, or to escape detection by fragmenting packets, altering timing parameters, etc. These can occasionally be useful for testing your logging and intrusion detection mechanisms, like Snort. [Recipe 9.20] 9.13.4 See Alsonmap(1), nmapfe(1), nc(1), telnet(1). The nmap home page is http://www.insecure.org/nmap. The XML::Simple Perl module is found on CPAN, http://www.cpan.org.
|
| [ Team LiB ] |
|
