Be aware, however, that a lot of traffic--legitimate and illegitimate--is running over Port 80. For example, WebDAV (Web-based Distributed Authoring and Versioning) is a protocol that, among other things, lets you mount hard drives remotely. When Apple says WebDAV support is built into the new version of Mac OS X, one of the features touted is that it can work through firewalls.
Another security flaw is having a hole in the network that lets users bypass the firewall. Big offenders here are devices that have modems to allow dial-in administration. Some organizations consider attaching a modem to a computer on the LAN such a security risk that it's punishable by immediate termination. While it may be convenient to dial into a network-monitoring box to see why the corporate Internet connection is down, an attacker could gain access to the LAN if he or she can guess the passwords. This is why you should deploy internal firewalls--the biggest threat to your network likely will come from the inside, be it an outsider with a modem or an untrustworthy employee.
Network-based firewalls also are ineffective when dealing with hostile code. A network firewall by itself can't determine if the traffic passing through it is legitimate or dangerous. But personal firewalls, which shim themselves into the IP stack of an operating system, can monitor traffic closely. Unlike hardware firewalls, personal firewalls have no physical separation between public and private interfaces. The personal firewall software intercepts packets before they are sent out via the network interface and before passing incoming packets up the stack to the application (see "No Desktop Is an Island.").
|
Glossary
• SYN packets: Initiate the process of establishing TCP connections, which must be made before other packets can be sent.
• Stateful devices: Monitor all details of sessions in which they are involved. For example, a stateful firewall goes beyond examining an individual packet's header and looks at the entire TCP session.
|
There are Trojans whose sole purpose is to capture keystrokes and e-mail them to attackers or broadcast them to IRC channels. Not all Trojan traffic waits for incoming connections either--some initiate contact with an outside host, even using normal traffic such as HTTP. One advantage of personal firewalls here is that they can look at which application is sending the data, and the better products let you set access rules based not only on ports but on applications. You can, for example, let only Microsoft Internet Explorer and Netscape send data through Port 80. Remember, though, that personal firewalls cannot remove Trojans, and viruses are still a threat, so you need to run antivirus software as well (see "How Trojan Viruses Work: A New Wrinkle").
Halt! Who Goes There?
Say you have a public Web server connected directly to your LAN, and incoming connections are blocked to all machines except the Web server. Sounds good--unless someone takes advantage of an exploit on the server. The attacker then has access to your LAN.
This is where a DMZ comes into play. In the military, a DMZ is a buffer between two warring parties to prevent further incursions or attacks. A DMZ in the IT sense is a neutral zone protecting a host or network that is assumed vulnerable. You have the public network (the Internet), a private network that you want to protect and a DMZ network, which is reachable from the Internet. Firewalls with DMZ capabilities have a third network interface for this purpose. You can have several DMZs, depending on the features and number of interfaces on your firewall. By restricting traffic in and out of the DMZ, you make it difficult to hop through the firewall.
The theory is that you never want an external user making a direct connection to private internal resources, so the DMZ is a semipublic zone. The DMZ should have only tightly controlled connections to the corporate LAN so if your Web server is violated, the attackers can't reach corporate records.
Sometimes this hard separation is nearly impossible. You may have a Web server that needs to communicate with a back-end database that sits on the LAN. This opens up a way to communicate from the Internet through the DMZ to the LAN. Never assume an attacker won't be able to figure out how your network is laid out. Terminate all remote users in the DMZ, limit access to those areas to which the users need entry rights. All remote users are external users, which means you shouldn't trust them. Also, make sure all hosts in the DMZ are hardened and locked down. Make applications as secure as possible; the default settings are not necessarily good enough. Finally, check the logs often to detect trends or attacks; DMZs don't make getting into your network impossible, just more difficult.
For more information, see our Survivor's Guide security section. Remember that securing your network is not a fire-and-forget-it process. Attackers are staying up nights devising ways around your defenses. As Irish orator John Philpot Curran has been paraphrased, "Eternal vigilance is the price of liberty." We'll add, "And of security."
Michael J. DeMaria is an associate technology editor based at Network Computing's Syracuse University's Real-World Labs®. Send your comments on this article to him at mdemaria@nwc.com.
RSS
