In-Depth
How Secure is Your Network?
Seven network scanners test your security before the crackers do.
- By Greg Saoutine
- 09/01/2001
Network scanning is one of the most misinterpreted terms
in computer security. As technology continues to evolve,
its definition changes. Network scanning is sometimes
confused with system scanning, application scanning or
even modem scanning (sometimes called war dialing). Sometimes,
network scans are referred to as penetration testing or
even hacking. Strictly speaking, a network scan is a systematic
test of an operating system's network stack. A stack is
a set of system applications or services that allow one
system to communicate with other systems connected to
the same wired or wireless medium. For example, the TCP/IP
protocol is implemented as a network stack. This type
of a scan is often called a port scan.
In the current IT environment, we expect network scanners
to perform a lot more than just a port scan. Additional
functionality may include network discovery (finding
all devices on a network), OS identification (also called
fingerprinting), and vulnerability checking (searching
for common security flaws such as configuration errors
and Trojan horses). For this article, I'll look at tools
that perform network discovery, OS identification, port
scanning and vulnerability checking of common network
services such as FTP and DNS. Such a tool should perform
all these actions without being physically installed
on the computer being scanned, and even without logging
onto the computer. Here's what we look at this month:
Some scanners are more sophisticated than others about
checking systems to which they connect. Scanners with
application-level checks (such as CGI scanners) are
designed to understand higher-level protocols (for example,
HTTP), and the input/output application parameters are
most often available via an HTML page. Using a Web site
as an example, a network scanner could find an HTTP
server on a certain port and check for vulnerabilities
(for example, unpatched security holes), while an application
scanner would be able to browse Web pages and try to
test the strength of exposed scripts. Some of the scanners
discussed in this article provide application scanning.
To test the scanners, we scanned a default installation
of Windows 2000 Advanced Server that included these
components:
- IIS 5.0 running a Web site on port 80 and another
Web site on port 8086. Traffic was split between the
two sites based on host headers. No virtual IP addresses
were assigned.
- An FTP site allowing Read and Write permissions
to the root directory to anonymous users.
- Telnet server.
- Simple Network Management Protocol (SNMP) with
public string as Read-Only and private string as Read
and Write.
- DNS server.
- DHCP server.
- Terminal Services.
- Service Pack 2.
After the first round of testing, we installed Back
Orifice 2000 remote management software (a multi-functional
Trojan) from Cult of the Dead Cow and retested the scanners
for their ability to detect this potentially malicious
application on the host computer.
10
Steps for a Successful Scan |
Pre-Execution
- Determine the overall scan objective
and pick the right tools. During
this stage, determine what you’re
going to scan. Is it a firewall
scan, intrusion-detection test,
bastion host assessment, or “cracker”
emulation attack? Make sure you
always try to scan the most important
link in your security—firewall,
Web server, Web application, scripts—as
well as the most vulnerable links.
Based on this determination, choose
the right tool.
- Train all personnel who will
perform scans on how to use the
software. Always test the scanner
in a lab environment prior to using
it, but after you update it with
the latest vulnerability probes
(if any).
- Contact the parties involved
in a scan and obtain their agreement
for a scan. Note that the use of
scanners may result in denial of
service (DOS). Without permission,
your “attack” may be reported to
a security authority such as CERT,
or there might be other legal consequences.
- Analyze the architecture of the
target network. Ideally you should
know about intrusion detection systems
(IDS) and other alarms on the network
that you scan (some IDSs can disable
your scanner). Load balancers, proxy
servers, firewalls and other network
equipment can potentially interfere
with the scan.
Execution
- Monitor the scan and be available
to turn it off (should the circumstances
demand). If possible, run a sniffer
on a target subnet to make sure
the scanner “hits” your target as
expected (this may also be useful
in analyzing scanning traffic and
identifying “false positives,” something
most scanners can produce).
- Let all parties involved know
the scan’s over.
Post-Execution
- Verify the scanner’s accuracy
based on OS recognition and overall
responses. Analyze the results and
filter false positives.
- Explore any serious vulnerabilities
in depth. System settings may have
to be examined to confirm the findings.
Some scanners, such as Hailstorm
or Nessus, allow you to create custom
packets to do further testing.
- Compare the results with previous
scans. This is called trending.
Keep a copy of the results for the
future. Only a few tools allow you
to do this, but you can construct
a simple database to store your
results quickly.
- Forward a completed copy to those
who got scanned as a good-faith
move and make yourself available
to answer questions.
—Greg Saoutine
|
|
|
Choosing the Right Scanner
Good network scanning tools can enable network administrators
to perform quick and fairly efficient assessments of
their networks on a periodic basis. They can also help
in keeping track of the latest vulnerabilities. More
sophisticated tools such as ISS, Nessus and Retina can
“probe” vulnerabilities by sending actual attacks (or
more often, by sending probes simulating an attack)
to targets. The most sophisticated scanners also provide
engines that allow more experienced users to create
custom attacks.
You should realize, though, that network scanners aren’t
infallible. None of the scanners we reviewed was able
to detect the Back Orifice Trojan that was installed
on a non-standard port. It’s quite a challenge to detect
such Trojans because the scanner would need to check
every listening port for every known Trojan. Note, though,
that the scanners we reviewed reported an unknown service
on the port where we installed Back Orifice. If you’re
auditing your own server, finding such unknown services
should be treated as a warning bell.
When choosing a network scanner, you need to understand
your environment and capabilities of various products.
If a quick inventory scan with information-gathering
elements and basic password checks are required, one
of the free, basic products (such as LANguard) can be
used. For a more comprehensive, targeted assessment,
more sophisticated products should be used: ISS, Retina,
and even Nessus provide IT professionals with an easy,
“point-and-click” solution, regular vulnerability database
updates and excellent reporting. When choosing a vendor,
don’t forget to ask about the frequency of updates to
the scanner’s database.
For a more sophisticated user who wants to have full
control over the test or needs to customize testing
for complex network components (such as intrusion detection
systems), tools with scripting capabilities (such as
Nessus or Hailstorm) are ideal.
Finally, while it’s a good idea to have a relationship
with a commercial vendor, several free products are
available on the Internet. Some of the free products
have advanced features that may not even be available
in your vendor’s product.
About the Author
Greg Saoutine, MCSE, is an IT Consultant working in New York City.