We have put together such a venture. Our team attempts to penetrate a system or an organization's network by taking on the role of attacker. Using an external attack approach, the team typically performs "zero-knowledge" attacks, meaning the team is given only the name of the target organization. Sometimes the client provides th e team with the names or the types of systems or information management is most concerned about.

Targets can include payroll and human resources departments, fund transfers, proprietary data (such as product designs and source code) and customer databases. The clients are varied: manufacturing, health care and pharmaceuticals companies and major financial institutions. Here we discuss our attack and intrusion-detection procedures and offer an approach to intrusion prevention.

In addition, we present the methodology used to analyze individual system security and show you how to strengthen intrusion detection using commonly available tools. For more specific information concerning the attack systems and tools used, see "Test Systems and Tools" and "Specific System Attack," on Network Computing Online at www.NetworkComputing.com/815/815ws1.html.

Playing the Hacker Our methodology of attack is similar to that of a would-be attacker. It begins with exploring and mapping the target organization's Internet connections. We start with whois queries to the Internet Network Information Center (InterNIC) to determine domain information, namely Domain Name System (DNS) servers. We attempt to map the internal network topology using DNS queries. Typically, we request a DNS zone transfer from the organization's authoritative name servers. Although most commercial firewalls can block this type of probe, a surprising number of organizations don't implement the block.

Next, using traceroute, we try to uncover possible candidates for a firewall host or packet-filtering router, which would reveal itself as the last hop before our probe packets begin to get dropped. We make a note of this machine's address for reference.

With the DNS zone transfers as a guide, we attempt to find supposedly untrusted machines, just outside the firewall. Most administrators are not overly concerned with security on external machines because these are considered sacrificial machines, relegated to a demilitarized zone. However, th ese same administrators open their firewalls to permit any type of network traffic coming from these sacrificial machines to connect to machines behind the firewall--either as a convenience to themselves or because of an oversight.

Another problem we see all too frequently is that the untrusted DNS server, though outside the firewall, contains the organization's complete DNS maps. Properly configured, it should contain maps only for those hosts that the Internet-at-large needs to know about, such as the DNS server, the external mail gateway, and possibly, the company's Web site.

Using strobe to perform port scans on these external machines, we can note any and all system services that can be reached for possible exploitation. If we are successful at breaking into any of these machines on the outside of the firewall, we make note of all valid user names in the password file and see if there are any machines mentioned in the hosts file that weren't listed in our DNS maps.

If we obtain "super-user" acce ss, we run crack, a Unix-based password decoder, on the shadowed password file, in anticipation that these same logins and passwords also exist on other machines. We've found that crack does some rather extensive dictionary attacks on people's encrypted passwords and generally has a high rate of success. In some cases, the password file isn't even shadowed, and super-user access isn't required to get at the encrypted passwords.

To download an Adobe Acrobat .pdf format version of Network Security Hot Spots graphic, click here.