Version 1.

0
10 common network security design flaws October 23, 2009

By Brien Posey
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.

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.

Page 1
Copyright © 2009 CNET Networks, Inc., a CBS Company. All rights reserved. TechRepublic is a registered trademark of CNET Networks, Inc
For more downloads and a free TechRepublic membership, please visit http://techrepublic.com.com/2001-6240-0.html
10 common network security design flaws

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.

Page 2
Copyright © 2009 CNET Networks, Inc., a CBS Company. All rights reserved. TechRepublic is a registered trademark of CNET Networks, Inc
For more downloads and a free TechRepublic membership, please visit http://techrepublic.com.com/2001-6240-0.html
10 common network security design flaws

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.

Additional resources

TechRepublic's Downloads RSS Feed

Sign up for the Downloads at TechRepublic newsletter
Sign up for our 10 Things Newsletter
Check out all of TechRepublic's free newsletters
10 things to look for in a hardware-based firewall
10 ways to detect computer malware
10 ways to avoid viruses and spyware

Version history
Version: 1.0
Published: October 23, 2009

Tell us what you think

TechRepublic downloads are designed to help you get your job done as painlessly and effectively as possible.
Because we're continually looking for ways to improve the usefulness of these tools, we need your feedback.
Please take a minute to drop us a line and tell us how well this download worked for you and offer your
suggestions for improvement.

Thanks!

—The TechRepublic Content Team

Page 3
Copyright © 2009 CNET Networks, Inc., a CBS Company. All rights reserved. TechRepublic is a registered trademark of CNET Networks, Inc
For more downloads and a free TechRepublic membership, please visit http://techrepublic.com.com/2001-6240-0.html