Each year I lecture at a number of events and consult for a large number of clients, and one recurring question I hear is how to leverage your investment in the network infrastructure (switches/routers) to secure the network against a variety of threats. The key solution to this quandary is not to focus on the unique characteristics of each threat. Instead we should focus on the common vectors that these threats leverage for success, a reliance on the client system using server protocols.
A client acting as a server sounds like it shouldn’t be an awful thing, but it can be if left unchecked. Let’s look at a few examples.
- A number of viruses use their own mail engine to replicate versus trying to understand what the victim’s computer uses for email
- Worms that spread across data networks often start a TFTP server on the infected system and use TFTP to copy themselves from system to system
- Man-in-the-middle (MITM) attacks often use ARP cache poisoning of victim computers to ‘claim’ the MAC address of the router for their own system
Understanding how the network layer is used in each of these attacks can help us build a defensible network layer using a very simple approach.
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
Buyer’s Guide: Sales Force Automation
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
I’ve taken the position that “clients should not be servers”. That sounds simple, but what does this mean? In data networks, there are a number of IP services (represented by protocols on the network) that should only be provided by specific systems located in the data center and managed by the IT organization. If these IP services are accidentally or maliciously attached to the edge of the network, they often disrupt the operation of the network by causing performance, reliability or security problems. A common example is the case of the rogue DHCP server. It could occur on your network for a number of reasons: a contractor that forgot he left a DHCP server running on his laptop from his last demo, an administrative assistance noticing an unplugged cable and attaching the DSL modem to the corporate network, or a person with malicious intent wanting to route traffic on your network through their device. The first two examples result in downtime for the systems affected and IT having to chase down the ghost in the network. The third example may require external assistance.
Rogue DHCP servers present only one common vector we can easily rectify at the network edge. Below are the top protocols for which you should consider policy control at the edge of your network. Each represents a common mistake or exploit vector in the majority of enterprise networks deployed today.
|DHCP Server Protocol||Automatically mitigate the accidental or malicious connection of a DHCP server to the edge of your network to prevent DoS or data integrity issues.|
|DNS Server Protocol||DNS is critical to network operations. Automatically protect your name servers from malicious attack or unauthorized spoofing/redirect.|
|Routing Topology Protocols||RIP, OSPF, BGP and MPLS topology protocols should only originate from authorized router connection points to ensure reliable network operations.|
|Router Source MAC & Router Source IP Address||Routers and default gateways should not be moving around your network without approved change processes being authorized. Prevent DoS, spoofing, data integrity and other router security issues.|
|SMTP/POP Server Protocol||Prevent data theft and worm propagation.|
|SNMP Protocol||Only approved management stations or management data collection points need to be speaking SNMP. Prevent unauthorized users from using SNMP to view/read/write management information.|
|FTP/TFTP Server Protocol||Ensure file transfers and firmware upgrades are only originating from authorized file and configuration management servers.|
|Web Server Protocol||Stop malicious proxies and/or application-layer attacks by ensuring only the right Web servers can connect from the right location at the right time.|
|Legacy Protocols||IPX, AppleTalk, DECnet or other protocols should no longer be running on your network—prevent clients from using them. Some organizations even take the approach that unless a protocol is specifically allowed, it is denied.|
These suggested policies improve security and will harden your network against a variety of threats. Optionally you can create a variety of network profiles based on the person’s or device’s use of the network. These profiles, more accurately described as ‘roles’, allow today’s network manager to better manage resources and manage their threat model. I’ve used the convention “Role Based Network Access Control” to describe this function as it mirrors the concepts in “Role Based Access Controls” published by the US National Institutes of Standards and Technology. You can view their version here: http://csrc.nist.gov/groups/SNS/rbac/
I hope you find this information helpful and would welcome your feedback – did you find this helpful or are you deploying some version of this on your network today? I’d be happy to answer your questions.
Remember, every network is unique. Evaluate your network and consider each policy before deploying it.