Designing Defensible Networks Part 2

NetCraftsmen®

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.

Leave a Reply

 

Nick Kelly

Cybersecurity Engineer, Cisco

Nick has over 20 years of experience in Security Operations and Security Sales. He is an avid student of cybersecurity and regularly engages with the Infosec community at events like BSides, RVASec, Derbycon and more. The son of an FBI forensics director, Nick holds a B.S. in Criminal Justice and is one of Cisco’s Fire Jumper Elite members. When he’s not working, he writes cyberpunk and punches aliens on his Playstation.

 

Virgilio “BONG” dela Cruz Jr.

CCDP, CCNA V, CCNP, Cisco IPS Express Security for AM/EE
Field Solutions Architect, Tech Data

Virgilio “Bong” has sixteen years of professional experience in IT industry from academe, technical and customer support, pre-sales, post sales, project management, training and enablement. He has worked in Cisco Technical Assistance Center (TAC) as a member of the WAN and LAN Switching team. Bong now works for Tech Data as the Field Solutions Architect with a focus on Cisco Security and holds a few Cisco certifications including Fire Jumper Elite.

 

John Cavanaugh

CCIE #1066, CCDE #20070002, CCAr
Chief Technology Officer, Practice Lead Security Services, NetCraftsmen

John is our CTO and the practice lead for a talented team of consultants focused on designing and delivering scalable and secure infrastructure solutions to customers across multiple industry verticals and technologies. Previously he has held several positions including Executive Director/Chief Architect for Global Network Services at JPMorgan Chase. In that capacity, he led a team managing network architecture and services.  Prior to his role at JPMorgan Chase, John was a Distinguished Engineer at Cisco working across a number of verticals including Higher Education, Finance, Retail, Government, and Health Care.

He is an expert in working with groups to identify business needs, and align technology strategies to enable business strategies, building in agility and scalability to allow for future changes. John is experienced in the architecture and design of highly available, secure, network infrastructure and data centers, and has worked on projects worldwide. He has worked in both the business and regulatory environments for the design and deployment of complex IT infrastructures.