I started out describing a method of compartmentalizing your networks into security groups. Each group represents a collection of devices with a specific security policy — who is permitted to access the devices. These compartments act as fire door, slowing down the spread of an attack and alerting you to its presence.
If you’ve followed my strategy, you have compartmentalized your network. Now it’s time to start enforcing policies.
Before we get into the details, let me make a general comment: no matter what polices you decide to enforce to protect your network, there will always be exceptions. It is a fact of networking life that there will be exceptions to the rules you create. Often, there are very good business reason for having these exceptions, and rather than trying to avoid it, it’s best to plan ahead. Whatever exceptions you need to make, make sure you document them: what systems are involved, what policies it bypasses, what the rationale is, who requested it, who approved it and when. By documenting the exceptions, you will be able to identify them as “normal” traffic. And if you know what normal traffic is, you can begin to identify the abnormal traffic indicative of a network compromise.
Workstation Policies
Let’s start with user workstations since they are the primary entry point for most network attacks (Some say because they are attached to users!). What other systems do workstations need to talk to? Fewer than you might imagine. For example, workstations probably need to connect to:
- Servers (file, print, application, etc.)
- IT administrator workstations or help desk workstations
- Proxies or gateways to other networks (e.g., the Internet)
More importantly, we should define what workstations should not connect to:
- Other workstations
- Directly to the Internet (If you are not using proxies, limit protocols – http and https. Block smtp, dns and other ‘server’ protocols)
- Printers, IP Telephony devices, security devices or any other similar device.
- Servers via RDP or VNC
The rationale behind these policies is to limit what workstations can access. By blocking access to other workstations, you prevent an attacker from leapfrogging from one workstation to another – a common method of creating multiple entry points into the network.
The simplest way to do this is to configure your host firewalls to block incoming connections from other workstations. If you summarized your IP addresses, the ACL in the firewall configuration can be a single entry. For example. if all your workstation subnets can be summarized as 172.16.4.0/20, you you configure your host firewall to block incoming connections from the 172.16.4.0/20 range.
Similarly, by preventing workstations from communicating directly with printers, you prevent an attacker from using the printer as a staging device or another attack vector (printers are notorious for having weak or no passwords). Finally, by blocking remote desktop protocols, you prevent an attacker from accessing server consoles. That ability is usually reserved for administrators.
This workstation policy improves security in two ways: first, it blocks malicious traffic (or traffic that can be at least considered suspect). Second, by logging policy violations, it makes you aware of malicious activity so that you can take action. If you see log entries showing a workstation accessing the HR server via RDP, it’s a very good chance that you are looking at a compromised workstation. Now you can investigate that workstation and clean up the malware. Without the access list in place, you’d never know you had a compromised PC in your network.
Server Policies
Your servers also need access policies. Servers are allowed to talk to:
- Other (specific) servers
- Management workstations or help desk workstations
- Gateways or proxies to other networks as needed
- Workstations (on approved ports)
Servers cannot talk to
- The Internet
- Other, unrelated servers.
Like the workstation policy, the server policy limits what servers can access. Since your sensitive data is on your servers, above all, servers should not have access to the Internet. Doing so only gives an attacker a direct route to steal your data. If you have publicly-accessible servers, they should be placed in a DMZ and controlled accordingly.
If a server needs to download a patch or other software, download it first to a management workstation and then apply it from there.
Restrict management protocols to only management workstations/subnets. Block RDP (tcp 3389), VNC (tcp 5900), SSH (tcp 22) and SNMP (udp 161) from user workstations. Be sure to configure your ACL to log any connection attempts from user workstations, as that is a good indicator of something worth investigating.
You should limit inter-server traffic. An attacker might not be able to attack a sensitive server directly. Instead, he’ll attack another, less important server, and then use that as a stepping stone to reach the sensitive server. If all your servers are on the same VLAN, this is a simple matter — one that you’re not likely to detect.
Most servers do not need to communicate with other servers. A few servers, such as name servers, are accessed by all other servers, but most need to talk with few, if any. One way to enforce this policy is to implement private VLANs that prevent inter-server traffic.
I also recommend that you isolate servers according to function. You can group your servers into functional “tiers” according to how they are accessed. For example, web servers and file/print servers are accessed by users directly. Application or back-end database servers are only accessed by other servers. Place these back-end servers on separate VLANs and enforce a policy that prevents direct access by user workstations.
If you have implemented these suggestions, you have significantly improved your security posture by blocking several attack avenues. Moreover, you are now generating actionable forensic data that can be used to detect the presence of an attack. In part 3 of this blog series, I’ll show how to collect and analyze this data to identify network attacks. I’ll also talk about other ways to defend your network and make it more resistant to attack.