Hardening Internal Networks against Worms

Friday, January 23, 2004

There used to be an old metaphor used by network security designers :
Networks should be hard on the exterior, and soft and squishy on the interior. Like a chocolate.1
Recent events thoughout 2003 and early 2004 show that this is no longer the case. With mobile computing ( such as PDAs, and laptops ), wireless networks, and increasing demands for access to mobile content it is no longer sufficient to attain security simply by installing a firewall between the enterprise network and the Internet.

Highly Invasive Worms

Recent worm attacks, such as MS-Blaster, SQL Slammer and Code Red have shown surprising ability to bypass the firewalls used by organisations to protect themselves from the Internet. There is a number of ways that such worms can evade the firewall between the enterprise network and the Internet:
  • Carried in by laptops. Probably one of the most common causes. Here, an employee takes his laptop away from the workplace and connects it to the Internet. The laptop is invaded by a worm, which migrates to the enterprise network when the user reconnects it at the workplace.

  • Via telecommuting/VPN links. A telecommuter is working at home, connected to the Internet and with a VPN connection to the internal enterprise network. A worm invades the user's computer and transfers itself to the enterprise network over the VPN link.

  • Wireless. A worm-infected computer associates to an insecure wireless access point. Even though the computer will probably not ba able to login to the LAN servers, the resident worm code will be able to attack all systems on the internal networks.
Its also common for worms residing on enterprise networks to migrate outwards : firewall systems commenting to the Internet generally allow unfettered access from internal systems outwards, therefore greatly aiding propagation of the worm.

The Worst-case Scenario

Consider the following scenario.
A new worm is announced that attacks Microsoft servers over the DCOM/RPC service, which is enabled on a large proportion of servers and workstations. It rapidly spreads across the Internet. Initially, the enterprise network is safe : the Internet-facing systems are all running Apache on Solaris and are therefore immune. But one side-effect of the worm is that it send high volumes of ICMP ( ping ) packets, which causes a very high load on the Internet-facing infrastructure.

Suddenly, the internal network begins to fail in erratic ways. The intranet and Email servers are down, an internal firewall running Firewall-1 on Solaris crashes incapacitating many network connections. After much diagnostic work, you realise that the internal network has been attacked by the worm - probably introduced by a laptop user who was connected directly to the Internet yesterday. The worm has spread from the laptop to many other Windows servers and workstations. The resulting floods of ICMP traffic has brought down network router and firewalls, and it will take many hours ( if not days ) before systems are operational again. The cost of the downtime is in the tens of thousands of dollars, the impact on the company's credibility much higher.

This scenario has actually happened at a company I know of. The worm was the W32.Nachi worm in August of 2003.

Do firewalls and anti-virus systems work?

Firewalls do a lot to prevent attacks, but they have holes in them. If you have a web server which you want to make available to public Internet users, then you must open up the HTTP port for incoming access. If a new worm arrives which attacks web servers via the HTTP port, then your firewall is going to let it straight though. The only exception in this case, is some of the newer firewall technologies which can perform "deep inspection" which will closely analyse the data traffic coming through connections, and detect malicious data.

Firewalls separating internal networks are often proposed as an attempt to mitigate rampant worm ( or human ) attacks. Although, in most cases these quickly became difficult to manage or contain too many holes to be very effective.

Anti-virus software will also help, but these don't resolve the problem. In almost all cases, they work by recognising patterns of data in files or network traffic which matches their database of known virus patterns ( signatures ). This is reliant on regular updates of the signature database. Consider a very fast-moving worm, such as the Code Red worm which swept most of the Internet in approximately 20 minutes. In this case, the anti-virus software vendor would need to analyse the worm code, add its signature to its database and distribute the updates to all clients within an extremely short time. Within this time, the enterprise systems may have already been incapacitated by the worm and not capable of loading the new signatures.

Intrusion Detection Systems (IDS) do a good job of detecting the presence of worms ( and other malware types ) on networks, but again they rely on the updating of signatures to compare against. At best, an IDS can notify administrators of the presence of a problem after that problem has occurred - which may or may not be useful.

These systems offer little protection once a worm is operational and attacking internal systems. The best feasible and practical defense is to maintain a higher level of security for the internal systems themselves.

Security Best Practices for Internal Networks

The following is some practices which can be applied to protect the internal enterprise network ( in no particular order ).
  • Maintain security on enterprise-internal systems. Don't think that because the internal network is behind a firewall then it is implicitly safe. Keep up to date with security fixes for all systems.

  • Protect critical infrastructure systems. Critical enterprise servers such as file servers, DNS servers, and anti-virus systems must receive extra attention to keep them protected. For example, consider what would happen if your internal DNS servers became unavailable - would all of your applications also fail ? Would you be able to access systems to perform remedial work?
    Consider using highly secure operating systems such as SELinux for critical functions.

  • Don't allow all outgoing traffic on firewalls by default. As with incoming traffic, you should only allow those services which you need to go out.

  • Have an Intrusion Detection System ( IDS ) on your internal networks, but don't rely on it to detect all problems. An IDS will help you identify which worm you have, and on which systems it is residing - but it won't protect your network.

  • Possibly use firewalls to partition internal networks, but use them carefully. Be sure you have considered the levels of protection and how much managment work it will take to maintain an internal firewall. Be careful about creating a single point of failure within the internal network.

  • The terminating point of VPNs should be protected by a firewall, and potentially with IDS monitoring as well. A VPN from outside should never terminate on an unprotected internal node.

Bear in mind that the expression "all rules are meant to be broken" applies here, and that every network and organisation has its own unique idiosyncrasies possibly requiring unique solutions.



1. Paraphrased from a quote by Bill Cheswick of AT&T Bell Labs. In The Design of a Secure Internet Gateway, Bill writes that "... ARPAs protection has, by design, left the internal AT&T machines a sort of crunchy shell around a soft, chewy center.". This is an observation of the common state of internal protection systems, and not a recommendation to implement security on the outside only. Bill Cheswick and Steven Bellovin are widely credited as the inventors of rht firewall, and are both often credited for the remark.

This paper also appears on the Interop LOOP Portal site. Thanks to David Piscitello of Core Competence Inc.. Visit his weblog here.