Previous Table of Contents Next

Network Design in the Real World: Network Attacks

A recent ZDNet publication provided hackers with the opportunity to attack a specially established network with a typical security model. The site provided Linux- and NT-based Web servers and used general firewall software, in addition to application-level security, on each server.

The first successful attack made on this network did not defeat the front-end firewall or any of the access lists on the routers—two typical security methods used by network designers and administrators. These devices blocked the failed attempts and permitted only the approved traffic to access the site.

The attackers ultimately created a suidroot shell (a means to gain root, or super-user access) in a directory accessible by the hacker. While this required a fairly detailed level of CGI, C, and Linux knowledge, the attack showed how easy it is to defeat the network designer’s primary tools. Few network architects concern themselves with server security, but a partner-ship with the groups that do can significantly improve the overall security model.

There are a number of ways to reduce the likelihood of a successful network attack. First, most servers provide information to all systems regarding their operating system version and applications. A hacker may use this information to find bugs and opportunities specific to that software. Designers and server administrators should work together to block all unnecessary identification information from being sent to clients.

Second, many of the techniques used in this case study were published and/or patched mere days before the attack. While such monitoring is impractical, a technician constantly monitoring the various hacking Web sites may discover a technique to defeat the attack in time to implement a solution. Many companies rely on their vendors to perform this task, though restrictive permissions on the server and firewall can greatly diminish the number of techniques that can be used. To provide the best security for the corporation, security technicians and designers must become hack-ers themselves—similar to the way law enforcement officers profile criminals—although this activity must be balanced with the other tasks required by the organization.

A colleague at Cisco likes to cite the quote “The question isn’t if you’re paranoid. The question is, Are you paranoid enough?’” Well-placed paranoia can be a very useful tool so long as it does not result in paralysis.

Network Security Solutions

A wide array of tools and methods are available to the network designer for providing protection against attacks. This section presents a number of solutions for the network designer to consider and use as part of an overall security model. Firewalls, the Cisco PIX, caching, access lists, address translation, and encryption can all work together to provide a strong security presence.


Firewalls have been regarded as the sole critical protection from the evils of the Internet. While firewalls are helpful, this position is inaccurate. Firewalls do not provide complete protection from external threats. They offer a single point of attack, and, according to the latest surveys (1998), most attacks avoid the firewall as a contention point altogether. These attacks may be accomplished via dial-up, social engineering, or backdoor tactics, but the net result is the same.

In addition, most firewalls are deployed without concern to internal threats. Designers should always consider the possibility of internally sourced attacks, including those that exploit internal systems from the outside—an attack scenario that starts with an external host compromising an internal, trusted host and then using that trusted host to attack another internal resource.

The best firewalls offer the designer solid security options with easy administration and configuration. Application-level firewalls go far beyond the basic protocol-based selection process available from a router. For example, many firewalls can block Java applets within HTTP streams—the router could only permit or deny HTTP. A router cannot block Java or ActiveX applets, nor can it provide virus-scanning functions. Many firewalls can provide these services.

Protecting the Router-Based Firewall

There are many arguments in favor of using firewalls as opposed to routers for protecting the perimeter of a network. For our purposes, a firewall has awareness beyond Layer 4, while also performing a routing function.

Cisco has introduced the IOS Firewall Feature Set, which adds some firewall functionality to the basic port filtering available in access lists. Designers will have to evaluate the appropriateness of this solution against other systems, including Gauntlet, Sidewinder, the Cisco PIX, and Checkpoint.

However, even with these systems it is important to provide whatever protection you can for the firewall itself. This frequently warrants some configuration of the router for basic, front-line security. Your efforts should include the following:

  Use static routes. This protects against route spoofing, where the attacker redirects data to resources they control. Route spoofing is one of the top techniques used by internal hackers.
  Do not configure the router for additional services, including TFTP.
  Disable Telnet access to the router and use a locally attached console. If this is not practical, use an access list to permit a handful of addresses to the VTY interfaces, and then allow only data flowing into the internal interface from an authorized source.
  Disable small servers on the router. Cisco considers a number of services to be part of the small servers keyword, including the echo and finger services.
  Use the password-encryption features, ideally using TACACS+ for authentication.
  Disable proxy ARP.
  Disable or strengthen security on SNMP services. Deny these services on the external interface.
  Block Telnet access to internal resources from external hosts and the firewall. Blocking firewall-sourced Telnet sessions requires placing a router inside the firewall; once compromised, the firewall can no longer be trusted to provide this protection.

In addition, administrators should invoke interface-level access lists on the front-line router. These access lists should protect both the front-line router and the firewall. The only drawback to this method is reduced router performance, though placing a short list on a reasonable routing platform should add only negligible delay. NetFlow and other technologies can reduce the impact of access lists on router performance and should be evaluated against the specific hardware in use. Inbound access lists can impact performance more than outbound ones; however, it is more secure to block on the inbound interface, and doing so negates the need for a routing lookup. The specific placement of access lists in your network will depend on the type of router, the type of IOS, and the level of security required.

Previous Table of Contents Next