This is the eleventh and last in a series of class notes as I go through the free Udacity Computer Networking Basics course.
This is the third of a 3 part miniseries on Network Operations and Management.
Why Network Security?
There are a wide variety of attacks on various parts of the infrastructure we have covered in this series (I will not link them here for brevity but you can scroll to the bottom for the relevant topics we covered):
- Routing (BGP): In 2010, China accidentally hijacked 50,000 IP prefixes from 170 countries for 18 minutes. This highlights the BGP's vulnerability where any AS can advertise an IP prefix to a neighboring AS and they will take it at face value and rebroadcast it to the rest of the Internet.
- Naming (DNS): A Reflection Attack is a type of Distributed Denial of Service - generating very large amounts of traffic targeted at a victim. Phishing is also a common attack attempting to get the user's personal information on a rogue website.
The Internet's design is fundamentally insecure. It was design for simplicity over security, and a host is "on by default" or reachable by any other host, so if you have an insecure host, it is wide open to attack. This was fine when the Internet was a small network of trusted networks, but is no longer fine now. Its decentralized nature also makes it hard to coordinate defense.
Resource Exhaustion Attacks
As we learned in the first post, packet switching allows multiple hosts to share the same link using statistical multiplexing, making it easy to achieve high utilization, but also making it easy to overload the link. These attacks target the Availability of a system.
Confidentiality and Authenticity Attacks
We also want our systems to provide Confidentiality, Authenticity, and Integrity, for example when we execute a banking transaction we want it to be private and to make sure the origin of the information really is our bank and that it hasn't been modified in-flight (a Man In The Middle attack).
The Negative Impacts of Attacks
Compromising Availability, Confidentiality, Authenticity, and Integrity can lead to:
- Theft of confidential info
- Unauthorized use of resources
- False information
- Disruption of legitimate services
Routing Security
Focusing on BGP and control plane security, this involves authentication of messages being advertised by the routing protocol:
- Session authentication: protects point-to-point communication between routers
- Path authentication: protects the AS path
- Origin authentication: protects the origin AS, guaranteeing that the origin AS that advertises a prefix is actually the owner of that prefix. (e.g. preventing route hijacking)
Origin Authentication: Route Hijacking
For a successful MITM attack, all traffic headed for the legitimate destination needs to be routed to the attacker, while the attacker's original connection with the legitimate location remains intact.
This is done by AS path poisoning - for the attacker's route to the legitimate location to be preserved, it prepends the path hosts onto its own AS advertisements so that they ignore the attacker's messages in an effort to avoid a loop.
This makes the MITM successful, however the circuitous route might be spotted when running a traceroute. The MITM can be hidden even from that, since a traceroute just consists of "ICMP time exceeded messages" from when a packet reaches a TTL of 0 - which normally would be decremented by each router along the way. If the routers in the attacker's network never decrement the TTL... then no messages would be generated, and the attacker AS would not be visible in a traceroute.
Session Authentication
The session between two ASes is a TCP session, so we just use TCP's MD5 authentication option. Every message exchanged in the connection not only contains the message, but also the MD5 hash of the message with a shared secret key (manually distributed "out of band" (aka offline) between the AS1 and AS2 operator).
Another way to guard connections is to send packets with a TTL < 254. Because most eBGP sessions are only a single hop, and an attacker would be remote, it is not possible for the recipient AS to accept packets from a remote attacker. This is called the TTL Hack Defense.
Origin and Path Authentication: BGPsec
To guarantee Origin and Path authentication, the BGPsec proposal was introduced. It is made up of two parts:
- Origin Attestation (aka Address Attestation): A signed certificate binding an IP prefix to its owner. It must be signed by a "trusted party" like a routing registry or prefix allocating organization
- Path Attestation: A set of signatures that accompany the AS path as it is advertised from one AS to the next. So say along a path AS1-AS2-AS3, each AS has a public-private key pair. Each AS signs a path with its own private key and every other AS can check it with the public key. When an AS is rebroadcasting a path from another AS, it forwards on that original path's signature, as well as a new signature adding itself to the path. Thus each AS can independently verify every step of a path is untampered because it has cumulative information signed by every private key along the path.
BGPsec would prevent against a variety of possible related attacks:
- Path hijacks
- Path shortening
- Path modification
However there are others it doesn't account for:
- Path Suppression (if an AS -fails- to advertise a new route, or a route withdrawal)
- Replay attacks (readvertisement of a withdrawn route)
- There is no way to guarantee that the data traffic actually travels along the advertised path (!!! a significant weakness yet to be solved by any routing protocol)
DNS Security
A small refresher on how DNS works:
- Your browser requests a new, unknown domain name
- Your ISP's stub resolver issues a query to a caching resolver
- Caching resolver has nothing in cache so it forwards the query to an Authoritative Name Server (ANS)
- the ANS often has Master and Slave replication for resilience
- the ANS also contains Zone files and a Dynamic Update System
Here are some vulnerabilities in that system:
- MITM attack between stub resolver and caching resolver
- Defense: DNSSEC
-
Cache Poisoning attack on the caching resolver to send a reply back to it before the real reply comes back from the ANS. This is a big one so we will spend more time on it below.
- Defense: 0x20
- Spoofing of the master or slave ANSes
- Defense: DNSSEC
- "DNS Reflection": using DNS to mount a large DDoS attack
DNS resolvers are fundamentally vulnerable because their queries create a race condition - they trust the first respondent whoever it is. The basic DNS protocols have no means for authenticating responses. DNS also uses UDP, which is "connectionless" (no session like TCP has) so the resolver has no way of mapping the response it receives for a query other than a query ID.
DNS Cache Poisoning and how to Defend from them
In an ideal world, the stub resolver sends its A query to the caching (or recursive) resolver, which sends it on to the ANS, which replies with the IP all the way back.
Attacks
To attack it, the attacker just needs to flood multiple replies guessing different query IDs and let one of them match. As long as the bogus message is received before the legitimate one, it will be accepted, and cached! DNS has no way to expunge a message once it has been cached, so it will continue to respond with this bogus data until the entry expires from the cache. Here is a related paper on Prefix Hijack Attacks.
A further vulnerability lies in the A vs NS query system. A records request specific subdomains, whereas NS records request entire zones. An attacker can generate a stream of bogus A record queries that clearly don't exist like fakesubdomain.google.com and then respond with an NS record for the entire zone, and it would still own google.com. This is known as the Kaminsky attack.
Defenses
The query ID is a first-level defense, but of course, it can be guessed. It can be made harder to guess by randomizing it, but it is only 16 bits (32,000) so the entire space is guessable (and by probability will match within a few hundred replies). We can add an additional 16 bits of entropy to the ID randomization by randomizing the source port of the query, however this may be resource intensive and counteracted by NATs.
The 0x20 defense refers to the fact that DNS is case insensitive, so the 0x20 character (which controls capitalization) isn't used, so we can use it to introduce additional entropy. So we can capitalize a request like www.GoOgLE.com and the pattern of upper-and-lower case would form an encoded "channel". Agreeing on a shared key between the resolver and the ANS would help generate the correct sequence of upper and lower case. This makes it even more difficult to inject a bogus reply.
The DNSSEC protocol adds authentication on top of DNS by adding signatures to responses returned for each DNS reply. So when a resolver sends a A google.com query to a root server, it responds with the referral to the .com server but also a signature of the root of the IP address and the public key of the .com server. So if the resolver has the public key of the root server, it can now transfer its trust over to the .com server as well, which sends a signed referral to the google.com server. In other words, each level in the hierarchy now not only responds with the next level's data, but also a signature containing the IP address of that referral as well as the public key for that referral.
DNS Amplification Attack
There is an asymmetry in size between queries and responses. An attacker's query can spoof a victim as the query source, and it is only 60 bytes. However, the DNS resolver's response will be about 3000 bytes! This is the "amplification" in this attack. Using multiple attackers to send spoofed requests will generate multiple large replies all heading to the victim, creating a DDoS attack.
To defend against this we must prevent IP address spoofing by disabling the ability for a DNS resolver to resolve queries from arbitrary locations on the Internet, which limits its usefulness.
The end of our series
Hopefully this has been a good high level overview of how Network Security works, and this entire series has been a useful introduction to you in some way. As a reminder, here are all the topics we have covered:
- Architecture and Principles
- Switching
- Routing
- Naming/Addressing/Forwarding
- DNS
- Congestion Control and Streaming
- Rate Limiting and Traffic Shaping
- Content Distribution
- Software Defined Networks
- Traffic Engineering
- Network Security
What do you think? What other topics should I cover? Let me know @swyx on Twitter!
Top comments (0)