March 19, 2001, 9:16 AM —
In last month's column, we looked at how services run on various Unix ports, and how the superserver, inetd, listens on behalf of many other network services. I advocated running only the network services that you require; this creates fewer opportunities for someone to compromise your systems.
Minimizing services is just the beginning of adopting a defensive posture, however. Numerous security experts suggest that thinking like an attacker is the only way to prepare yourself to defend your site. This month, we'll examine port scanning (sending packets to systems and gaining insight from the responses) -- which has been compared to tapping on walls to determine where beams are located -- and look at what an intruder can determine about services you're running.
Who's there?
One simple form of scanning sends pings to every address in a network to determine which correspond to systems that are up and running. For example, if you know the address of a single host and its subnet mask, you can easily generate a list of all of the IP addresses in the subnet, then ping sweep to determine which addresses are actually in use. Using this technique, an attacker hopes to gain a network map -- a selection of addresses worth looking into during the next round of data gathering. It's not unlike walking around your office saying, "Knock knock." Anyone who answers, "Who's there?" is a candidate for the subsequent joke.
Of course, ping sweeps generally reveal very little about the systems in question. Assuming that most attacks will come across a firewall or router, reply packets won't even contain the MAC address of the target systems. (They'll contain the router's MAC address instead.) Basically, they'll only tell whether each address is in use and whether the system is up.
Strictly speaking, ping sweeps are not port scanning. Unlike TCP and UDP, the ICMP protocol doesn't use a port abstraction. Nevertheless, ping sweeps are an option in many port-scanning tools, and are often used to seek out data for subsequent, more sophisticated attacks.
True port scanning involves sending requests to all interesting ports on a particular system or group of systems to determine which services can be exploited. An interesting port is generally a well-known one on which services are likely running. High-numbered ports usually represent outgoing connections rather than system services (e.g., the difference between a user running telnet and the system's telnet daemon). However, scanning up to port 65536 is not uncommon.
Port scanning works because when a service is running, a port responds differently than when it is inactive. Otherwise, legitimate connections would have trouble working. For example, if you tried to telnet to a server, you'd expect a denial if the server didn't support telnet and a login prompt if it did. Though most port-scanning techniques operate at a lower level than a telnet request, the concept is the same. Port scanning takes advantage of the necessary elements of communications protocols.
Any port in a storm
Just in case you came in late, a port is simply a communications channel on which particular network services (like telnet, sendmail, httpd, and POP3) can be reached. If those services are running, your probe will generally elicit the expected response; if they're not, you'll get a different response.
If you only wanted to create a list of active IP addresses, a ping sweep might do the job. On the other hand, you stand a much better chance of getting through a firewall if you send an ACK ping to port 80, which provides access to Web servers. An ACK ping sends an ACK packet to port 80 and expects a reset (RST) if the host is up. We're using port 80 to get through the firewall and sending the ACK ping merely to find hosts. That is why it is called an ACK ping.
If port 80 is blocked on all but Web servers, though, the results will be limited. It's possible to ping random high-numbered ports; many firewalls allow packets to high-numbered ports when the ACK bit is set, probably assuming that those packets are part of ongoing connections. To some extent, crossing firewalls is a guessing game; however, some guesses are much better than others. Even a well-configured firewall is likely to pass ports 80 (http) and 22 (ssh).
