Local Scanners

Local scanners can plow through the contents of files looking for configuration problems. Many real-time network and system IDSs look at individual events, such as the moment that a file is modified, without knowing what changes were made to the file. A system scanner can look into the file to discover configuration errors or unwanted changes made by a hacker. A very useful hybrid approach would combine the best of both real-time IDSs and scanners. When the file change event is detected by the real-time IDS, part of the scanner is invoked as a response to inspect the file’s contents.

Many times in this book, we have mentioned that a difficult administrative task is configuration of owners, groups, and permissions for files and directories. Scanners can help ensure that these aspects of your security policy are properly implemented. For example, even if you add SeOS to your systems, scanning the SeOS configurations and the OS resources you may have not included in SeOS will improve security. As a security officer or administrator, you are paid to be paranoid. Worrying about whether you have initially configured your systems properly or whether your original secure configurations have been changed is part of the ongoing assessment necessary for a secure site.

Because the local scanner is actually a process running on the target node, you can look for problems that cannot be detected by remote scans. For example, in order to run programs and look for buffer overflow attacks, you must be able to create processes on the system. A remote scanner cannot create arbitrary processes on a system unless it is able to crack into the system.

Local scanners also can inspect patch levels to ensure that you have the latest security fixes installed. As in looking for buffer overflow attacks, this process requires the capability to query the system’s software product inventory. A remote scan is unable to do this unless some type of systems management application is running to provide this information in a client-server manner.

Network configuration errors for a node also can be inspected locally by looking at files such as /etc/services, /etc/inetd.conf, and /etc/rc.tcpip. A remote scanner is unable to peer into individual files (again, unless it is able to crack the system).

Remote Scanning

Remote scanners examine the network and distributed computing vulnerabilities in your system. If your system allows anonymous FTP users to write into the public download directory, hackers can use your site as a distribution center for stolen software. Network services that give away information or allow a hacker to gain access into your system should not be running. The remote scanner will look for these scenarios.

Local scanners look for buffer overflow attacks in programs by running them. Remote scanners look for buffer overflow attacks in network services by sending them bogus packets. To make something happen on a local system, you either run a program or send a program a command. The corollary in network computing is to send a packet to a listening process or software server. Remote scanners primarily probe your system by sending network packets.

Sometimes a remote probe sends random packets to look for any exposure in the system. More intelligent poking also occurs when scanners look for trust relationships to exploit. A root .rhosts file, which is spoofable by IP address impersonation, is one trust weakness that a remote scanner tries.

Many of the exposures a system will exhibit are independent of how the system is being used, such as running network services that you should not. A remote scanner also looks for specific weaknesses in your firewall configuration, your Web server configuration, and possibly application configurations. Intrusion detection products are continually moving higher up the OS stack, and application-specific scans already are creeping into products such as ISS SAFESuite. A local scanner will peek into the contents of a Web server and firewall configuration files to uncover mistakes.

A scan run locally on a node will look to see whether there is a root /.rhosts file and report this finding in its results. The /.rhosts file can be used to exploit a system from a remote node, so it is really a network security vulnerability opened by the local system configuration. A remote scanning engine will look for this same problem by attempting to gain system access via programs that rely on /.rhosts for authentication. Both types of scans are discovering (a) a configuration problem in the target system and (2) a network security vulnerability.

As you can see from the discussion so far, combining local and remote scans is necessary in your environment because they complement each other. Sometimes, they detect the same problem in different ways, but this is also useful because it implements security in layers.

How a Scanner Works

A scanner probes for weaknesses in your system or network by comparing its database of known vulnerabilities against data about your configurations. Most scanners enable you to configure what you want to scan and when you want to scan for it. Extensibility is another important feature to look for in a scanner. You want to be able to add your own scanning routines to look for site-specific application weaknesses that concern you.

Under the general category of systems management, your scanner should provide for optional centralized reporting. If you have two or three systems, running a local scan on each node and reading the reports on each node may be tolerable. Sites with dozens of systems or more want consolidated reports on a central server. Other capabilities such as the grouping of nodes into scan groups, flexible output report formats, and customized scan options are valuable for large environments.

Using a scanner is actually simple. If you don’t require any customization, by default the scanner will look for a preconfigured list of vulnerabilities and report the results to you. Usually, the results are saved in a file so that you can come back later to review the findings. The scanner works by either examining attributes of objects, such as owner and permissions for files or by emulating the hacker. To act as a hacker, the scanner runs a variety of scripts that try to exploit weaknesses in the target node. To keep the systems and networks from being overloaded, you should give careful thought to what you want to scan and when you want to scan for it. Otherwise, you might find that your entire site becomes sluggish because the mission-critical servers are busy responding to a simulated SYN Flood attack.

Scanning is not limited to computers. Routers and other switching devices also can be scanned, because they, too, have been exposed in the public news forums for containing security flaws.