Network Security

Network Security

Network security is arguably one of the most critical functions of IT – yet organizations frequently overlook easy to implement security design practices. Here are a few common mistakes that could compromise your network defenses and put company assets at risk.


1: Set it and forget it

The first flaw is more a planning flaw than a design flaw. It involves something called the “set it and forget it” mentality. This is what happens when organizations work hard to secure their networks without stopping to reevaluate their security plans again later. The threats to security are constantly evolving, and your security architecture must evolve as well. The best way to accomplish this is to reevaluate your security needs on a regular basis.

2: Opening more firewall ports than necessary

While opening an excessive number of firewall ports is bad, but sometimes opening ports is unavoidable. Take Microsoft Office Communications Server 2007 R2 as an example. If you are planning on providing external access, about a dozen ports must be opened. In addition, OCS 2007 R2 assigns a wide range of ports dynamically. So what should the security administrator do?

One of the best solutions is to make use of a reverse proxy (such as Microsoft’s ForeFront Threat Management Gateway). A reverse proxy sits between the Internet and the server that requires the various ports to be opened. While there is no getting around the need for open ports, a reverse proxy can intercept and filter requests and then pass them on to the server they’re intended for. This helps hide the server from the outside world and helps ensure that malicious requests do not reach the server.

3: Pulling double duty

With the economy in shambles, there is increasing pressure to make the most of existing server resources. It might be tempting to host multiple applications or multiple application roles on a single server. While this practice is not necessarily bad, there’s a law of computing that states that as the size of the code base increases, so does the chance that an exploitable vulnerability exists.

It isn’t always practical to dedicate a server to each of your applications, but you should at least be careful about which applications or application roles are hosted on a single server. For example, at a minimum, an Exchange 2007 organization requires three server roles (hub transport, client access, and mailbox server). While you can host all three roles on a single server, you should avoid doing so if you are going to be providing Outlook Web Access to external users. The Client Access Server role makes use of IIS to host Outlook Web Access. Therefore, if you place the client access server role on the same server as your hub transport and mailbox server roles, you are essentially exposing your mailbox database to the Internet.

4: Ignoring network workstations

Workstations make up the single largest threat to network security. Organizations go to great lengths to secure their network servers but practically neglect their workstations. Unless workstations are locked down properly, users (or malicious web sites) can install unauthorized software with untold consequences.

5: Failing to use SSL encryption where it counts

Web sites needs to use SSL encryption any time a user is going to be entering sensitive information, such as a username and password, or a credit card number. However, many organizations include insecure content on a secure page. When this happens, users receive a prompt asking if they want to display both secure and insecure content. This gets users in the habit of giving Internet Explorer permission to provide insecure content.

A less obvious but even more common problem is that organizations often fail to encrypt critical pages within their web sites. Any page that provides security information, security advice, or contact information should be SSL encrypted. It isn’t that these pages are especially sensitive, yet the certificate used by the encryption process guarantees users that they are accessing a legitimate web page rather than a page someone has set up as a part of a phishing scam.

6: Using self-signed certificates

Since some organizations completely neglect the importance of SSL encryption, Microsoft has begun to include self-signed certificates with some of its products. That way, web interfaces can be used with SSL encryption even if the organization hasn’t acquired its own certificate yet.

While self-signed certificates are better than nothing, they are not a substitute for a valid SSL certificate from a trusted certificate authority. Self-signed certificates are primarily intended to help boost a product’s security until an administrator can properly secure it. Yes, a self-signed certificate can provide SSL encryption, but users will receive warning messages in their browsers because their computers do not trust the certificate (nor should they). Furthermore, some SSL-based web services (such as ActiveSync) are not compatible with self-signed certificates because of the trust issue.

7: Excessive security logging

Although it’s important to log events that occur on your network, it’s also important not to perform excessive logging. Too much logging can make it difficult or impossible to locate the security events you’re really interested in. Rather than trying to log everything, focus on logging the events that are really meaningful.

8: Randomly grouping virtual servers

Virtual servers are commonly grouped on host servers by their performance. For example, a high demand virtual server might be paired on a host with a few low demand virtual servers. From a performance standpoint, this is a good idea, but this approach may not be the best idea from a security standpoint.

Using dedicated virtualization hosts for any Internet-facing virtual servers would be the best idea for your business. In other words, if you have three virtual servers that provide services to Internet users, you might consider grouping those servers on a virtualization host, but don’t put infrastructure servers (such as domain controllers) on that same host.

The reasoning behind this is to provide protection against an escape attack. An escape attack is one in which a hacker can escape from a virtual machine and take control of the host. While nobody has yet figured out a way to perform a real-world escape attack yet, it is only a matter of time before they do. When they do, your odds of prevailing against such an attack are going to be a lot higher if virtual machines that are exposed to the Internet share a virtualization host only with similarly hardened web-facing servers.

9: Placing member servers in the DMZ

If you can avoid it, try not to place any member servers in your DMZ, an additional layer of network security which acts as a buffer between the internet and your LAN. If compromised, a member server can reveal information about your Active Directory.

10: Depending on users to install updates

One last common security flaw is depending on users to deploy security patches. Many network deployments use WSUS to patch network workstations. Unfortunately, many of these deployments rely on the users to click the option to install the latest updates. The problem with this is that the users know that the update process is going to require them to reboot their computers. Some users may end up putting off the updates indefinitely. Rather than relying on the end users, use a patch management solution that pushes security patches automatically without giving users a choice in the matter.