Servers

10 common network security design flaws

Solid planning and design can help reduce the potential for security breaches. Here are some security design missteps to watch out for.

Solid planning and design can help reduce the potential for security breaches. Here are some security design missteps to watch out for.


Network security is arguably one of the most critical functions of IT - yet I frequently see organizations that have overlooked easily implemented security design practices. Here are a few common mistakes that could compromise your network defenses and put company assets at risk.

Note: This article is also available as a PDF download.

1: Set it and forget it

The first flaw I want to talk about is more a planning flaw than a design flaw. It involves what I like to think of as 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. The threats to security are constantly evolving, and your security architecture must evolve too. The best way to accomplish this is to reevaluate your security needs on a regular basis.

2: Opening more firewall ports than necessary

We all know that opening an excessive number of firewall ports is bad, but sometimes opening ports is unavoidable. For instance, take Microsoft Office Communications Server 2007 R2. 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's a security administrator to 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. So 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

About a year ago, someone asked me during a radio interview what I thought was the single biggest threat to network security. My answer was, and still is, that workstations make up the single largest threat. I constantly see organizations that 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

We all know that a Web site 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 make some bad decisions when it comes to securing their Web portals. The security flaw I see most often is including 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. In my opinion, any page that provides security information, security advice, or contact information should be SSL encrypted. It isn't that these pages are especially sensitive. It's just that the certificate used by the encryption process guarantees to 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 go hog wild and 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.

I recommend using dedicated virtualization hosts for any Internet-facing virtual servers. 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 the host.

My 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. To the best of my knowledge, nobody has figured out a way to perform a real-world escape attack yet, but I'm sure that day is coming. When it does, your odds of prevailing against the 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. 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. I have seen several network deployments recently that 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.


Check out 10 Things... the newsletter

Get the key facts on a wide range of technologies, techniques, strategies, and skills with the help of the concise need-to-know lists featured in TechRepublic's 10 Things newsletter, delivered every Friday. Automatically sign up today.

About

Brien Posey is a seven-time Microsoft MVP. He has written thousands of articles and written or contributed to dozens of books on a variety of IT subjects.

11 comments
Spitfire_Sysop
Spitfire_Sysop

In the following quote: "In my opinion, any page that provides security information, security advice, or contact information should be SSL encrypted. " Does "any page" include this tech blog giving "security advice"? This page is viewable without SSL. What is worse? We log in to the techrepublic! User names and passwords with no https? Perhaps we need an HTTPS login page? Once logged in we could get a secure version of all the content on this site? That would protect our form entry too, for these comments and such.

zoredache
zoredache

You might want to check out this article (http://blogs.techrepublic.com.com/security/?p=2550). I think the who Certificate Authority system and assumption that if I pay $$$ to some 3rd part is somewhat flawed. Unfortunately, running your own CA infrastructure isn't particularly easy either. Especially if you must support platforms where distributing CA certificates is not easy.

Deadly Ernest
Deadly Ernest

thing you SHOULD avoid, it's something you MUST avoid AT ALL COSTS. The DMZ is for machines you don't mind getting hacked or slashed, and should be easy to re-image and replace. I notice you missed the most basic for a secure gateway, have the OS on the servers at the front of the gateway a totally different OS to the ones at the back of the gateway, with a router at each end too. Also, totally different IP address ranges for the gateway and the LAN. Different OSs on the servers at each end make it much harder for hackers to punch through as the hacks that work on Windows don't work on Unix or Linux - thus they have to change styles as they work to penetrate. Often the hack moves to punch through the back end won't get through the already penetrated front end either.

kevaburg
kevaburg

....it sounded more like marketing for Microsoft! OK, I specialise heavily in Microsoft infrastructure myself but there were a couple of points that, in this day and age, were moot for me. Firstly was your point about ignoring network workstations. Most networks I work on nowadays are governed using Group Policy and are broken down into computers and users. Any administrator worth his salt knows how this works and will use it early on in his design planning. Your thoughts on placing member servers in the DMZ were, in my opinion WAY off track. The sorts of machinery seen there include web servers, certain database and email servers and FTP servers just to start the list off. These would never be put onto AD servers because of the inherrent security risks involved. So how should they be included in the network? A mention of certain Linux-based technologies belongs in this category because I believe that, at the moment, this is where it shines the most. The deployment of patches is also a moot point and one you did not explain well at all. Before ANY patch is deployed it gets tested thoroughly to ensure that there will be no problems. To assume the end-user will take responsibility for that is a grossly irresponsible attitude to take. That is why WSUS is so important and seeing as it doesn't cost anything, no administrator has the umbrella of saying that they didn't know. As users, they should have NO control over the download and installation of patches. The last point I wantto bring out is the point you made about having too many ports open. If the ports have to be open then so be it. That is how it is. IDS was invented to detect signatures from potentials threats and in most cases, subvert them. If you have a lot of ports open, then set them as stealth ports and don't advertise their status. Use Honeypots to help divert a potential threat away from anything deemed precious. My point from what I have said here is that there is a number 11 in your list that I see all the time: Do not rely on a single vendor for your solutions. Routers are not the realm of Microsoft, Firewalls (although ISA is not bad) belong to a dedicated appliance like Ironhand for example. Web servers running Apache are far more secure than IIS and there are other effective email servers to relace Exchange. The one-vendor mindset is what cripples most networks flexibility and security I believe.

kevaburg
kevaburg

I think that is the most aggresive writing I have seen from you! I don't know about you but the original article seemed to be composed of writings and excerpts from amateur computing magazines and formulated without true substance.

kchandley
kchandley

The number one issue that creates the biggest vulnerability is physical security. I've seen server rooms with 6 digits of equipment with weak or no locks, or denying access to no one inside the company. If I can get my hands on a server, I can completely compromise it. Many of the more significant breaches of networks started with a breach of physical security, often through social engineering.

jamesgrimes
jamesgrimes

In general, I agree with what you are saying. However, we must also remind the users to NEVER give out there user name and password to others. The other issue, is reminding users to never open an email if they do not know whom it is from. Users should be reminded at least once a quarter about this. Besides, users should not be doing anything personal on business-owned machines anyway. Should that not be a company policy that is enforceable on the network?

Gis Bun
Gis Bun

I remember an ex-boss telling me the story of how someone he knew boasted excellent server room security. No way anyone can get in. They forgot the ceiling. The walls didn't go all the way up. So you could crawl over the wall in the lowered ceiling. Meanwhile I worked for a very large communications company and the server room door would open on its own quite often early often [causing alarms to go off] because of a wind tunnel issue on the floor. Took forever until they got it fixed. Another place I worked at, had the server room door always open because of a ventilation issue! [didn't take long before I fixed that]

kevaburg
kevaburg

I, and I guess alot of other techs, have seen equipment simply standing on the ground in the form of pedestal servers or NAS devices. The problem some companies have though is keeping the kit cool if it is in a closed room such as a closet. These people need to consider whether the cost of air conditioning outweighs the cost of their company data. It isn't as if I would say it is the most important point of all but it certainly runs par with alot of the other points.

wizard57m-cnet
wizard57m-cnet

October 2009...March 2013...I'll let you figure that out... let sleeping zombie sleep. Wizard57M TR Moderator

TenguTech
TenguTech

"No way anyone can get in. They forgot the ceiling. The walls didn't go all the way up. So you could crawl over the wall in the lowered ceiling." And that's not taking into account one of the really big problems with having a drop ceiling and crawl space, it's how the Aliens will get in! :)