There are a number of places network engineers look by default for security holes; there are others that aren’t so obvious. In this section, we’ll try to cover some of the less obvious places to look for security holes so that you don’t find them the hard way.
Close a Door, Open a Door
One of the most important things to remember when building out a security system is that security—like all network design—is always a trade-off. For instance:
To prevent rogue routers from injecting false routing information, HMAC/SHA signatures are deployed across all the routing
processes in a network.
To ensure compliance with change control mandates throughout a network, RADIUS authentication is enabled on all routers, and command logging per user is enabled as well.
To counter prefix hijacking, a service provider implements a global RPKI system and ties it to BGP policy so any route that isn’t
authenticated is automatically rejected out of the BGP table.
To counter spam, a company connects its firewall to a
whitelist/blacklist service, and sets its email servers to reject any email from domains that are not listed in the whitelist.
Each of these may (or may not, depending on your point of view) be
perfectly valid options in the war against security breaches in a network. But they all come with some form of costs. Before reading the following list, try to find the door that’s being opened to new attacks in the process of closing the door against other attacks.
What new forms of attack have been added through these actions?
The amount of work required to process an HMAC/SHA (or otherwise cryptographically signed) packet is much higher than the work required to process an unsigned version of the very same packet. By turning encrypted signatures on, you’re opening each router in the network to a denial of service attack through
overflowing the processor by streaming a high rate of cryptographically signed packets into a router’s interface.
If the RADIUS server itself is not reachable, what capability do network engineers have to modify the configurations on each individual router? If there is no “back door,” you’ve given the attacker a single point to attack that will cut off the network
engineering team’s ability to manage the network—probably not a good thing.
If the global RPKI system becomes unreachable, what happens to the routing system itself? Will all routes be accepted, or all
rejected? What can the attacker accomplish by bringing down the RPKI itself?
If all the mail servers in the network are configured to reject any mail that’s not on a whitelist provided by an external provider, what will happen when access to that provider fails? Will all email be rejected? The attacker, rather than focusing on hundreds of separate email accounts, now only has to focus on the connection to a single service to disrupt email throughout the entire
enterprise.
Each time a door is closed, a door is opened. It’s not that these secondary doors can’t be closed as well—but they do need to be considered. The cost of the first door needs to be weighed against the danger of opening the second door, the cost of closing that door, and any doors that might be opened by closing that second door.
A useful way to think about this is to consider the entire security perimeter of the network anattack surface. What is the shape of that surface? Will closing a hole here open a hole there? Security is a system, not a set of individual components.
There’s always a trade-off. The job of the network architect, the security professional, the network engineer, is to find that trade-off and consider it.
There’s never a time when there isn’t a trade-off, so if you’ve not found it, you’re not done thinking through the implications of implementing some specific form of security.
Beware of Virtualization
When the IETF set about deliberating a new version of the Internet Protocol, one problem they ran into was the question, “How do we deploy this new protocol?” The answer the engineers involved in the process came to was,
“We tunnel it over IPv4.” Tunneling, of course, is a fine answer; tunneling and tunneled protocols are widely deployed in the real world to meet all sorts of different needs. From backhaul to deploying new protocols and services to security, tunneling is almost ubiquitous.
But as with all things in the real world, there are trade-offs. IPv6 transition mechanisms are a case in point. For instance, RFC6324 documents an attack using disjointed control plane information on either side of an automatic 6to4 tunnel to loop packets along an IPv6 tunnel indefinitely, eating bandwidth and potentially acting as a denial of service attack against the path along which the tunnel travels.
The only way to really be safe about tunnels is to treat each tunnel as if it were a physical link for security purposes.
Now we know this is actually impossible; there are too many tunnels between too many devices using too many protocols to track every tunnel and monitor it for security breaches. There are just too many tunnel types, and too many places they’re used—SSL, IPsec, GRE, LISP, IPv6 transition, and a hundred other besides, running from routers to hosts, hosts to hosts, servers to hosts, and in many other combinations.
Tunneling mechanisms, by providing virtual topologies attackers can take advantage of, create a major hole in the attack surface of your network.
There is little you can do other than deploy effective monitoring to find as much of the tunnel traffic as you can and monitor and manage it as
effectively as possible.
Social Engineering
The same property that allows humans in the security process to counter brittleness also creates holes in the security process through social
engineering, a form of attack that leverages perceived trust to convince the
people in your company to open security holes or provide information that can be used to open the right doors for the attacker to operate successfully within your network. Here are some examples of social engineering:
Calling an employee from an (apparently) internal line and asking for the employee’s current password to fix a problem the
employee hasn’t noticed. If the attacker can convince the person that the attacker is a valid member of the company’s staff, there is a good chance the employee will work with the attacker to be helpful, or to correct the unseen problem.
Walking into a store wearing the right name badge or the right clothes (uniform) and asking to borrow a particular piece of
equipment for some special project, or to transfer equipment from one store to another. Most people are going to trust the
appearance of sincerity, rather than questioning and appearing to be unreasonable or unhelpful.
Posing as someone who should rightly be able to ask for specific information, or to access specific areas, such as a police officer, fireman, auditor, or a member of a partnering company’s staff.
Don’t ever underestimate the power of social engineering.
Even the best trained people can be caught in the web of trusting those they shouldn’t trust, particularly when the attacker poses as someone who is in desperate need, or someone who can really help them in some way. On the other hand, that doesn’t mean you shouldn’t put the right policies in place, and provide the right training, to cull out as many social engineering attacks as possible. For instance:
Have clear, written policies about who an employee can give any sort of information to, from phone numbers to passwords.
Get people in the habit of asking someone else, even if it’s just a co-worker, before helping anyone with anything that seems remotely unusual. In detecting scams, two heads are almost always better than one.
Encourage people to work horizontally within the company, rather than strictly vertically. The more people know the IT staff, the more likely they are to recognize an intruder or attacker as someone who doesn’t belong in the right group to be asking questions.
Summary
Yes, you should build security in, rather than bolting it on after. But how can a network architect actually build security in?
First, use the OODA loop as a tool to help you analyze where and how you can provide the tools to tighten up your response times in the case of an attack. Second, remember that a lot of the good design principles you’re using to make the network scalable and resilient are also effective security tools. Think about modularization and resilience not only in terms of good
design, but also in terms of secure design. Finally, watch your attack surface, and remember that when you close one hole, you’re most likely opening another. Never implement something new in security until you’ve chased down and studied the trade-off. There’s always a trade-off.
Although this chapter hasn’t provided you with every tool you’ll ever need to be an effective security engineer, it has, hopefully, given you enough tools to interact with real security engineers effectively, and to think through where and how to build security in to the network design from the start.
Chapter 10. Measure Twice
If there were a poll taken for the least favorite topic among network
engineers, network management would surely win without much trouble. And yet...without solid management, network engineers are running blind, like a builder without a level or a tape measure. It’s not good enough to have a blueprint; you need to know how your current building stacks up against that blueprint, and what and where to change to bring things into line.
This chapter aims to minimize the pain of network management while maximizing the gain. In a perfect world, the measurements and analysis network architects need to manage a network would just “fall out” of the process of building the network. But networks are never perfect worlds, whether virtual or real. To begin, we’ll examine the “why” of network
management; why trouble with measuring things? After this, we’ll consider some models to try and come to grips with the network management world a little better. In the third section of this chapter, we’ll look at some practical considerations in deployment management, and then finally we’ll take a tour of the documentation you should have on hand.