Five steps to controlling network access

In the final part of his series, Wes Noonan describes five ways to harden the network infrastructure and protect data in the event that the network perimeter fails.

In this three-part series, Wes Noonan, author of "Hardening network infrastructures," will review steps you can take from both a Windows and network perspective to protect your data regardless of what is occurring at the network perimeter. Click to return to part one or part two.


In part one, I explained that the key to handling network de-perimeterization is not to remove the perimeter, but to acknowledge that it is so porous you must take steps in securing data from the malicious traffic that crosses it. Part two covered steps for hardening Windows, and here I'll focus on steps for securing the network infrastructure.

One common security mistake is to treat the network and applications as separate entities that never interact. You may have separate people maintaining them, separate security policies, separate procedures and so on. Hardening Windows servers will go a long way toward protecting the integrity of the data on those servers, but you must also harden the network infrastructure itself. Start by taking the following five steps.

1. Implement access control lists (ACLs)

If someone can get inside your network, they can gain access to your Windows systems. You need to implement strict ACLs on your network equipment and grant access only to those users that require it. For example, do users in Houston ever need access to systems in New York? If not, chances are the traffic passing between those systems isn't essential to the business.

2. Implement network-based access control (NBAC)

Connecting systems to the network used to be a hassle: You had to build the network drivers, assign addresses and physically connect systems to get them to talk. Although this made it difficult for unauthorized systems to easily connect to the network, it created excessive administrative overhead. Then technologies like star-wired networks and Dynamic Host Configuration Protocol (DHCP) made it exceedingly simple to connect systems to the network. At first I rejoiced! But now I realize anyone can connect to the network. In fact, approximately 90% of the customers I visit have live network jacks that I can easily plug into to gain network access even if they have some written policy that states unauthorized connections are not permitted.

NBAC seeks to provide an enforcement mechanism to support those written policies. With NBAC, you want to define what is an authorized user and ensure connected systems are running the appropriate patches and software versions. If they aren't, they are placed in quarantine until the system is patched or updated.

3. Restrict remote connections

Implementing a VPN can be a risky endeavor. It permits network access for both users and viruses. Instead of allowing VPN access to your entire network, implement network ACLs that restrict remote users only to the servers and resources they need. For instance, using a VPN to connect Citrix or Terminal Server farms ensures that the only traffic allowed through the VPN is the Citrix traffic to the Citrix servers; if a remote client's system is infected, it will not infect your network.

4. Restrict and secure wireless connections

If implemented behind your firewall, wireless LAN connections create a particularly large, gaping hole in your network perimeter. As a result, your wireless LAN connections should be treated like any other remote connection: Terminate them outside your firewall and require a VPN connection to gain access to internal and protected resources.

5. Implement IPsec

Implementing IPsec on your network is a great way to protect data in transit from being compromised. But it's no panacea. For example, if a machine is infected with Slammer, IPsec will only ensure the Slammer traffic is encrypted before it is transmitted. When used in conjunction with the other hardening methods, however, IPsec can serve as an effective method for protecting your internal traffic from prying eyes.

Conclusion

Due to network de-perimeterization, you can no longer rely exclusively on the network perimeter to protect systems and data. Removing the perimeter entirely is not the solution, nor is hardening the perimeter alone. You must also harden your Windows systems and network infrastructures to protect data in the event that the network perimeter fails or is circumvented.

Click to return to part one about the weakened state of the network perimeter or part two for eight ways to protect Windows from perimeter threats.


About the Author
Wesley J. Noonan has been working in the computer industry for over 12 years, specializing in Windows-based networks and network infrastructure security design and implementation. He is a senior network consultant for Collective Technologies, LLC (www.colltech.com). Wes recently authored the book "Hardening network infrastructures" for Osborne/McGraw-Hill and previously authored a chapter on network security and design for "The CISSP training guide" by QUE Publishing.


For More Information

Read part one to learn about the de-perimeterization of the network.

Read part two for eight ways to protect Windows from perimeter threats.

Learn 10 steps NOT to take when securing your Windows perimeter.

This was first published in October 2004

Dig deeper on Windows Server and Network Security

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchServerVirtualization

SearchCloudComputing

SearchExchange

SearchSQLServer

SearchWinIT

SearchEnterpriseDesktop

SearchVirtualDesktop

Close