FCW issues hacker challenge

So you think your network is secure just because you have a firewall? Think again. No network that allows external traffic is 100 percent secure, no matter what kind of firewall is in place. Any type of traffic entering and exiting a network opens up channels that hackers can use to break in.

We set out to debunk the popular myth that firewalls render a network completely secure. The fact is that while most firewalls do protect as advertised, no network is invulnerable from attacks. The question for government buyers is: How much protection will you get from a firewall?

The only way to conduct a realistic test of firewalls is to invite hackers in to try to break through them. But how to do that without risking FCW's own network? We set up a simple test network with a dedicated T-1 line and installed the firewalls on it. At first, we wanted to take the hacker challenge public and invite anyone to break into our network, but the International Computer Security Association, which certifies firewalls, was opposed to this methodology and forbid its members to participate in our contest. So we came up with a compromise in which we would invite a select group of security experts to do the hacking.

We invited security experts from Deloitte and Touche, Ernst & Young and Security Design International Inc. (SDI) to try to break into our test-bed network using any means available to them. They used a number of hacker tools available on the Internet as well as their own scripts. Their challenge was to access files on the server and garner any information they could about our test network. The files were located in two directories: a regular user directory and an administrative directory. The project was a joint effort with our sister publication, Computerworld, which coordinated the hacker groups while we monitored the results.

We convinced four firewall vendors to put their products to our hacker challenge: Axent Technologies Inc.'s Raptor Firewall for NT, Version 5.0.1; Compaq Computer Corp.'s AltaVista Firewall 98; NetGuard Inc.'s Guardian Firewall for NT, Version 3.01; and Secure Computing Corp.'s Firewall for NT, Version 3.0.2. CheckPoint Software Technologies Ltd. and other major firewall vendors declined to participate.

Each firewall was installed on our test-bed network for a week, during which time the hacker groups attacked the system without knowing whose product it was. The test-bed network permitted three kinds of traffic: two-way File Transfer Protocol (FTP), Simple Mail Transfer Protocol (SMTP) and Hypertext Transfer Protocol (HTTP) directly from the server. To monitor and identify attacks on the network, we set up Internet Security Systems Inc.'s (ISS) RealSecure Version 2.1 intrusion- detection system (see sidebar, Page 48).

In addition to evaluating performance against hacker attacks, we looked at each firewall's setup, user interface, management and documentation. For more details about the firewalls, visit our World Wide Web site at www.fcw.com.

All four products protected the network from penetration and performed generally as advertised, except Secure Computing's firewall, which froze during a denial-of-service attack by SDI but still kept out illegitimate traffic. Axent's firewall withstood the same attack because it had the latest security patches installed.

One shortcoming we discovered is that the attack teams were able to learn more information about the network than the firewalls should have allowed. For example, the Ernst & Young team learned the identities of the server and the various services running on it. The team also was able to determine the IP address of the internal network card and the status of various NT ports. These leaks were partially due to NT security weaknesses, but the firewalls should have been able to prevent them, according to Eric Schultze, a senior manager in Ernst & Young's security practice.

Deloitte & Touche also was able to learn the identities of the makers of internal server software, hardware and two of the firewall vendors. Fred Rica, a partner and attack team member, said that information should have been hidden. He said bits and pieces of information that at first seem innocuous can be pieced together to garner a larger picture of the network, thereby increasing the likelihood of a successful attack.

Types of Attacks

Through the RealSecure software, we recorded half a dozen denial-of-service attacks and a dozen unauthorized access attempts in which a hacker tried to read, write or modify files he was not authorized to change. There were also several attempts to gain key information about our test network, such as user names and passwords. Other suspicious activity included duplicate Internet Protocol address events.

Denial-of-service attacks come in several flavors. Their goal is not to steal information but rather to block all traffic entering and exiting a network or device. A technique called IP spoofing is often used as part of a denial-of-service attack, and it showed up in our RealSecure logs. IP spoofing works by deceiving a router or firewall into thinking that the unauthorized traffic is legal and is coming from within the network.

Other denial-of-service attacks launched against our network included Ping of Death and Teardrop attacks. These programs exploit bugs in the Transmission Control Protocol/Internet Protocol (TCP/IP) implementations of computer and host systems. A Ping of Death uses a ping utility to create an oversized data packet that is sent to a vulnerable system, causing it to hang, crash or reboot. A Teardrop attack takes advantage of weaknesses in IP packet reassembly. It creates IP fragments with overlapping offset fields so that when the fragments are reassembled at the destination, a system will hang, crash or reboot.

Our network also was subjected to the Syn Flood and LAND programs, both of which are types of denial-of-service attacks. These programs launch during initiation of a communication session between two applications. A Syn Flood overloads a network with a series of synchronization (Syn) packets, which eventually causes the system to ignore all legitimate incoming packets, rendering it unavailable to authorized users. A LAND attack floods the network with Syn packets using a spoofed source IP address of the targeted system. This way, the host computer thinks it sent the packets to itself, thereby making it unavailable to legitimate users because the target system is trying to respond to itself.

In addition, there were some brute-force denial-of-service attacks recorded against our network. These programs, such as Smurf, flood a network with useless data. Smurf uses Internet Control Message Protocol (ICMP) to overwhelm the system with echo request packages. If numerous hosts are involved, the large amount of echo request and response traffic clogs the network.

Password sniffing attacks also hit our test network. Separate from denial-of-service programs, these attacks monitor IP traffic. By capturing the first 128 bytes of an FTP or Telnet session, for example, a password sniffer can pick up user names and passwords as they are typed in. Special-purpose password-sniffing toolkits are widely available on the Internet.

The Ernst & Young team used a structured approach to hacking. They would ping the network and then use commercial tools to scan for unprotected ports. Once the team found open ports, they could find out what services the network was running, what operating system were in use and which service packs were installed.

While the Ernst & Young team was unable to penetrate the network, it was able to gather a lot of information about it. The team accessed Port 135 and ran an older Microsoft Corp. application called End Point Dump. This allowed them to see all protocols and services running; all external, registered IP addresses; and even the internal, nonregistered server IP address.

The hacker group at Deloitte & Touche, consisting of about six people, used a variety of commercially available tools to try to penetrate our network, including ISS's Internet Scanner, Cisco Systems Inc.'s Net Sonar and other port-scanning software. The group identified two of the firewalls- Axent's Raptor and Compaq's AltaVista- by looking at the structure and setup of the firewalls.

Beekey said his group was able to find out which services and ports were open on our network and how the directory structure was set up as well as hardware information such as the fact that our server was from Dell Computer Corp. and at least one of the machines running the firewall was from Hewlett-Packard Co. These information leaks are dangerous for a network, Beekey said, because "the more information you get, the more you can focus the attacks." He added that in most cases, it is actually Web, e-mail or FTP servers that fall, not the firewall, because people have not set them up properly.

The Deloitte & Touche group offered several recommendations for protecting a Windows NT network. One is to make sure you have intrusion-detection software (such as RealSecure) set up. The first thing hackers will try to attack, according to Beekey, is a firewall's audit logs; this way, hackers can erase the traces of their own traffic entering the network. Intrusion-detection software is separate from the firewall, and it keeps real-time logs, so it offers added protection.

Administrators also should change or disable the firewall's banners; lock down the router and enable packet filtering at the router level; and disable the NetBIOS on all levels.

Beekey also recommended that administrators sign up for mailing lists that notify subscribers of all the latest available flaws in network applications and alert administrators to possible fixes. These lists generally disseminate the information more quickly than Microsoft, so you will be as up to date as possible.

Beekey's strongest recommendation, however, was that administrators of a Windows NT network should constantly monitor their firewall. They should review and save all logs, even logs that are months old, because hackers gradually can attack a network over time, sending one packet at a time— activity that may not be noticed on a small scale, but on a large scale a pattern will emerge.

Lessons Learned

All the firewalls we tested did their jobs as advertised, keeping the hackers out of our test network. However, remember that no firewall offers a network 100 percent protection because there is always some traffic allowed to enter and exit a network. If hackers are determined, they can use open channels to break through.

There are, however, some precautions you can take to protect your networks. First, make sure you have the latest service packs installed. Security administrators should have tight control over the kinds of passwords allowed— for example, passwords should be alphanumeric and at least eight characters long. Users that come through the firewall should be validated through a virtual private network, and public information should be stored on a separate network. As far as the firewall itself, it is best to buy one that defaults to denial of all traffic and only allows traffic you specifically permit.

If you are in the market for a firewall, look at the features, management functionality, ease of use and logging capabilities before making your selection. Also consider setup because there are considerable differences between the systems, and configuration problems can leave your network vulnerable to attack.

-- Gary Anthes of Computerworld contributed to this report.

***

Top 10 Recommendations to Secure an NT Firewall

1. Install latest Microsoft Service Pack and Hotfixes.2. Disable Server Service from the external interface.3. Disable other unnecessary services.4. Do not install the firewall server as a Primary or Back Domain Controller.5. Disable the Auto Admin Logon feature.6. Disable unnecessary "shares'' (C$, D$, admin$).7. Disable remote administrator log-on access.8. Enable security auditing.9. Encrypt the user account database.10. Disable remote registry access.

SOURCE: ERNST & YOUNG

***

RealSecure 2.1 tracks network intrusions

By Chip Pettirossi

To help us monitor and identify attacks coming into our network over the Internet, we contacted a leading security consulting company, Fortrex Technologies Inc., Gaithersburg, Md. The Fortrex consultants arrived at our test center with Internet Security Systems Inc.'s (ISS) RealSecure Version 2.1 intrusion-detection system. RealSecure is a traffic-monitoring engine that sits on the network, scans for external or internal attacks and alerts administrators when known attacks are identified. The engine is accessed via a management console that contains alarm views and a built-in database for logging session captures.

With assistance from Fortrex, we loaded the RealSecure engine and the management console on separate Windows NT workstations running Microsoft Corp.'s latest service pack. We had to install a Microsoft patch to allow 128-bit encryption on the workstations. Network administrators also can buy a Unix version of RealSecure. For optimal performance and monitoring capabilities,

RealSecure recommends 128M of memory on the engine and console workstations. We plugged the RealSecure engine into our Ethernet network (see figure at right) located outside the firewall and used a second local-area network adapter and cross-over cable to connect the engine to the network interface card in the management console. ISS recommends setting up the engine and monitor in a "stealth configuration," in which the first adapter in the engine connects to the unprotected network outside the firewall with no protocol bindings enabled and the second adapter connects to a secure network and the management console. Because our console was directly connected to the engine, we set up the most secure implementation option for the intrusion-detection system. RealSecure also will work in Fast Ethernet and Token Ring environments using LAN adapters that support promiscuous mode.

We ran through several configuration tasks to install the engine and console software on our two workstations. RealSecure uses handy install wizards to guide users through the software setup process. At the first menu option, we had to decide whether to load the engine and console on separate computers or both on the same workstation. We chose to install on separate systems. Administrators will need to pick an authentication scheme based on their security needs. We chose strong authentication, which requires an administrator to load the public key on the engine via floppy disk or over the network. We also chose the default cryptologic algorithm for data encryption services.

RealSecure has decided to license its software using a license key for the management console to control the number of engines and IP addresses used. Our evaluation software was time stamped.

After rebooting the console workstation, we launched the RealSecure console to initialize communications with the engine. By default, RealSecure assigns a maximum coverage policy to the engine covering security and connection events, filters and notification mechanisms.

RealSecure bundles five other pre-defined policies with the software. Multiple policies can be applied to a single engine.

We created our own policy to disable protocol decodes, turn on attack signatures, send notifications to the management console, log attacks to the database and monitor HTTP, FTP, FTP data, SMTP and Telnet connection events. When an attack is detected, RealSecure can perform the following actions: log activity to a database, send an e-mail to the network administrator, kill the connection, view the session, lock the firewall (CheckPoint-compatible), and generate a trap to the SNMP management console.

Administrators will need to use the Engine Properties dialog box to configure:

* Communications between the engine and the management console.

* Engine statistics collection frequency.

* The selection of LAN adapters.

* E-mail notification.

* Communications with an SNMP console.

* Filters, attack signatures and firewall parameters.

The console supports a number of configuration settings, from the amount of time that an event is displayed in each of the three priority windows, to the number of events that are stored on the console, to terminal emulation parameters. The console's graphical interface is very helpful and easy to use. The menu and toolbars provide quick access to common console functions.

We relied heavily on the Activity Tree Windows on the console to display events captured by the engine. The events can be sorted by source machine, destination machine and the name of the event. The handy tree structure of these windows allows administrators to quickly obtain more detailed information with a few mouse clicks. The event inspector window shows the name of the event, the date and time of the event, the source and destination addresses, the engine IP address, the network protocol used, the source and destination ports and the actions invoked by RealSecure in response to the event. When properly configured, the session playback window on the management console can display a recorded event down to a keystroke-by-keystroke level.

During our five weeks of testing, RealSecure recorded a number of attacks coming across the Internet to our four test firewalls. The number and types of attacks in existence today is extensive, and new attacks are constantly being developed. ISS defines more than 100 attack signatures in its user manual.

We recorded a half-dozen denial-of-service attacks, which try to prevent a computer from providing some or all of its services. We saw a dozen unauthorized access attempts, which occur when a person tries to read, write or modify files that they are not authorized to change. An attacker also can try to gain unauthorized access privileges, such as administrator or root privileges. There were several attempts to gain key information about our network, including user names and passwords. Other suspicious activity recorded by RealSecure included duplicate IP address events.