What are network defenses?
At first, the subject of network defenses might seem redundant or very general. However, there’s nothing redundant or general about this area. Network defenses address the issues involved in connecting networks to each other and in operating a network as a whole. Network defenses don’t address things such as external firewalls or dial up connections, since the perimeter security layer covers these. Nor do network defenses cover individual servers and workstations, since the host-defenses layer covers these. Instead, network defenses cover things like protocols and routers.
Internal firewalls
Just because the subject of network defenses doesn’t cover external firewalls, it doesn’t mean that it doesn’t cover firewalls at all. One of the first steps that I recommend taking toward securing your network defenses is to enable internal firewalls where possible. Internal firewalls are basically the same as external firewalls. The main difference is that their primary job is to protect the machine against traffic that is already on your network. There are a couple of reasons for implementing internal firewalls.
First, imagine for a moment that a hacker or a virus was able to manipulate your external firewall in a way that allowed all varieties of traffic to flow through it. Normally, this would mean that it was open season against your network. However, if you had enabled internal firewalls, the internal firewalls would block the malicious packets that the external firewall had let slip through.
The other main reason for enabling some internal firewalls is that many attacks tend to be internal in nature. At first, you might hear this statement and think that an internal attack couldn’t possibly happen on your network, but I’ve seen internal attacks and other security breaches in every company that I’ve ever worked for.
At two of the places that I used to work, people in other departments who were hacker or administrator wannabes thought that it would be cool to probe the network to see how much information they could acquire. In both cases, they had no ill intent (or so they said), they were just looking to impress their friends by hacking the system. Whatever their motivation, they did attempt to break through the network’s security. You’ve got to protect your network from people like this.
In other places that I’ve worked, I’ve seen people bring in unauthorized software that was infected with Trojan horses (remember “Back Orifice”?). These Trojan horses would then broadcast on specific ports. The firewall was powerless to stop malicious packets from entering the network because the packets were already on the network.
This actually brings up an interesting point: Most of the techs I know configure their external firewalls to block all but a few inbound ports and to allow all outbound traffic. I recommend being just as picky with the outbound ports as you are with the inbound ports because you never know when a Trojan horse could be using some obscure port to broadcast information about your network to the world.
Internal firewalls ideally should be placed on each PC and on each server. There are several good personal firewall products on the market, such as Norton’s Personal Firewall 2003 from Symantec. However, you may not have to spend a dime on an internal firewall for your workstations as Windows XP contains its own built in personal firewall.
To enable the Windows XP firewall, right-click on My Network Places and select the Properties command from the resulting shortcut menu to display the Network Connections window. Next, right-click on the network connection that you want to protect and select Properties. Now, select the Advanced tab and then click on the check box in the Internet Connection Firewall section. There’s also a Settings button that you can click to enable any ports that should remain open. Although the Windows XP firewall is intended as an Internet firewall, it works great as an internal firewall as well.
Encryption
The next step that I recommend taking is to encrypt your network traffic. Begin by implementing IPSec wherever possible. However, there are a few things that you need to know about implementing IPSec security.
When you configure a machine to use IPSec, you have the option of configuring IPSec to either request encryption or to require encryption. If you configure IPSec to require encryption, then any machine that the machine attempts to connect to will be informed that encryption is required. If the other machine is capable of IPSec encryption, then a secure channel will be established and the communications session will begin. If, on the other hand, the other machine is incapable of IPSec encryption, then the communications session will be denied because the required encryption can’t occur.
The request encryption option works a little differently. When a machine requests a connection, it also requests encryption. If both machines support IPSec encryption, then a secure channel is established and communications begin. If one of the machines doesn’t support IPSec encryption, then the communications session is established anyway, but the data simply isn’t encrypted.
For this reason, there are a couple of things that I recommend doing. First, I recommend placing all of the servers within a site on a secure network. This network should be completely isolated from the normal network. Each server that users require access to should have two network cards, one for connecting to the main network and the other for connecting to the private server network. The server network should consist of only servers and should have a dedicated hub or switch.
By implementing such a configuration, you create a dedicated backbone between the servers. All server-based traffic, such as RPC traffic and traffic used for replication, can flow across this dedicated backbone. By doing so, you’ve helped to secure the server-based traffic and you’ve increased the amount of available bandwidth on the main network.
Next, I recommend implementing IPSec. For the server-only network, IPSec should be configured to require encryption. After all, this network consists of nothing but servers, so unless you’ve got UNIX, Linux, Macintosh, or some other non-Microsoft server, there’s no reason why all of your servers shouldn’t support IPSec. Therefore, you’re perfectly safe requiring encryption.
Now, for all of the workstations and the server connections on the primary network, you should configure the machines to request encryption. By doing so, you’ve achieved the optimal balance between security and functionality.
Unfortunately, IPSec can’t distinguish between network adapters on multihomed computers. Therefore, unless a server is attached exclusively to the server network, you’ll want to use the request encryption option or else clients may not be able to access the server.
Of course IPSec isn’t the only type of encryption available for your network traffic. You must also consider how you’ll secure traffic that flows through your perimeter and the traffic flowing across your wireless networks.
Wireless encryption tends to be a touchy subject these days because the wireless networking devices are still evolving. A lot of administrators view wireless networks as inherently insecure because of the fact that network packets are flying through the air and anyone with a laptop and a wireless NIC card can intercept those packets.
While there are certainly risks associated with wireless networks, in some ways, wireless networks are even more secure than wired networks. The reason is that the primary mechanism for encrypting wireless traffic is WEP encryption. WEP encryption ranges in strength from 40 bit on up to 152 bit or even higher. The actual strength depends on the lowest common denominator. For example, if your access point supports 128-bit WEP encryption, but one of your wireless clients only supports 64-bit WEP encryption, then you’ll be limited to using 64-bit encryption. These days, however, just about all wireless devices support at least 128-bit WEP encryption.
What many administrators fail to realize is that just because wireless networks use WEP encryption, it isn’t the only encryption type that they can use. WEP encryption simply encrypts whatever traffic is flowing across the network. It doesn’t care what type of traffic it is encrypting. Therefore, if you are already encrypting data with IPSec, as you should be, then WEP will simply provide a second level of encryption to the already encrypted data.
Network isolation
If your company is very big, then there’s a good chance that you have a Web server that hosts the company’s Web site. If this Web server doesn’t require access to a backend database or to other resources on your private network, then there’s no reason to place it on your private network. Why run the risk of someone using a Web server as an entry point to your private network when you can fix the problem by isolating the server into its own network?
If your Web server does require access to a database or to some other resource on your private network, then I recommend placing an ISA Server between your firewall and the Web server. Internet users will communicate with the ISA Server rather than with the Web server directly. ISA Server will proxy requests between the users and the Web server. You may then establish an IPSec connection between the Web server and the database server and an SSL connection between the Web server and the ISA Server.
Packet sniffers
After you have taken the necessary steps to secure the traffic flowing across your network, I recommend occasionally using a packet sniffer to monitor network traffic. This is just a precautionary step because it allows you to see what types of traffic are actually present. If you detect unexpected packet types, you can see where those packets are coming from.
The biggest problem with protocol analyzers is that they can be used as a hacker tool. I used to think that it was impossible to detect someone that was using a packet sniffer on my network because of the nature of packet sniffing. Packet sniffers simply watch traffic flowing across the wire and report the contents of each packet. Since packet sniffers don’t transmit packets, how could you possibly detect them?
It’s actually easier than you might think to detect packet sniffing. All you need is a bait machine. The bait machine should be a workstation that no one knows exists except for you. Make sure that the bait machine has an IP address, but is not a part of a domain. Now, place the bait machine on the network and generate some packets. If someone is sniffing the network, the sniffer will pick up the packets that the bait machine produces. The problem is that the sniffer will know the machine’s IP address, but not its host name. Usually, the sniffer will do a DNS lookup to try to determine the machine’s host name. Since you are the only one who knows about the machine, no one should be doing DNS lookups on the machine. Therefore, if you check the DNS logs and see that someone has been doing DNS lookups on your bait machine, then there’s a good chance that the detected machine is sniffing the network.
Another step that you can take toward preventing sniffing is to replace any existing hubs with VLAN switches. The idea is that these switches create virtual networks between the sender and the recipient of a packet. No longer does the packet flow to every machine on the network. Instead it flows directly to its destination. This means that it would be difficult for someone who might be sniffing the network to get anything useful.
These types of switches have another benefit as well. With a standard hub, all of the nodes fall into a single collision domain. This means that if you have 100 Mbps of total bandwidth, then the bandwidth is divided among all of the nodes. However, with a VLAN switch, each virtual LAN has a dedicated amount of bandwidth that it doesn’t have to share. That means that a 100 Mbps switch could potentially handle many hundreds of Mbps at a time, all on different virtual networks. Implementing VLAN switches will improve both security and efficiency.