Networking

Protect your network from internal attacks with access control lists

Learn how to utilize access control lists on internal servers and clients to lock down your network against a variety of attacks.


This article is from TechRepublic's Security Solutions e-newsletter. Sign up instantly to begin receiving the Security Solutions e-newsletter in your inbox.

Most security administrators do a good job of using firewalls, filtering routers, and other defense-in-depth tools to protect their network from external hackers. However, your network's most destructive enemy could be an internal one. Internal access control lists (ACLs) can help protect and secure your network from the insider threat.

Internal ACLs on your routers and switches give you another tool in your security architecture. By limiting the type of traffic within your network, you can increase performance and decrease your vulnerability to insider attacks, Trojans, and worm propagation. When you develop internal ACLs, keep in mind this general rule: Clients talk and servers listen.

Servers listen
Unless you've set up a script to run on a server, or you use a server to control other servers or connections (e.g., a terminal server or a print server), servers don't initiate connections. They serve information requests from client machines.

So when you're developing ACLs, start by determining what each server does and which clients need to access its information. For instance, if you run an internal, non-SSL Web server, you can place an access list on the port going to your Web server(s) and allow TCP port 80 only. But if the server is a domain controller (DC), you'll need to allow a range of ports going to this server for your clients' authentication and logon services.

Specifically, for a Windows NT DC, you'll need to allow:
  • NetBIOS name: UDP port 137
  • NetBIOS Netlogon and Browsing: UDP port 138
  • NetBIOS session: TCP port 139
  • Remote procedure call (RPC): TCP port 135

Or, for a Windows 2000 DC, you'll need to allow:
  • Kerberos authentication: UDP/TCP port 88
  • RCP: TCP port 135
  • Lightweight Directory Access Protocol (LDAP): UDP/TCP port 389
  • Microsoft Directory Services: TCP port 445
  • LDAP global catalog: TCP port 3268 (if the DC maintains the global catalog for the domain)

The server list continues, depending on the type and function of the server.

Clients talk
As I said before, clients "talk," or initiate, connections. To increase internal security, you'll want to filter clients' outbound connections. Although trying to filter client-side connections might seem difficult, once you know which ports your servers are listening on, you'll know which ports your clients are trying to connect to.

Develop your access list for client outbound connections by determining what services your clients should be able to access. For example, if you don't want a client to be able to access Telnet, don't allow outbound client connections to TCP port 23.

Final thoughts
You might think these types of ACLs are too difficult to manage. But before you throw in the towel, run NMAP or another port scanner and record the connections between clients and servers. This will provide you with a working baseline on which to build your internal ACL, and it will greatly increase your likelihood of success.

Trojan horses and worms need ports to communicate. Strictly controlling the ports and protocols you allow within your internal network diminishes their ability to propagate, so keep a close eye on the open ports to your servers and clients. Controlling your network's security starts at your Internet connection and ends with your clients.

Editor's Picks