Network Security Flashcards
What kinds of attacks can BGPSec successfully protect against? i.e., what specific attacks
are possible against BGP but are defeated by BGPSec? (Explain clearly how these attacks
would be executed – if there’s more than one way to execute an attack, consider those as
two different attacks.)
A BGP message could be sent to a router by some host (e.g., a remote attacker) that is
not the router’s legitimate neighbor
› Note that although BGPSec provides session authentication, this kind of attack
can also be prevented without BGPSec by using the gTTL Hackh.
œ An AS could lie about being the origin of a particular subnet (i.e., claiming that the AS
contains a subnet when it does not, in fact)
› BGPSec prevents this by providing certificates that sign the origin claim
œ An AS could lie about the AS-path to a particular subnet (i.e., claiming that there is a
path through the AS when there is not, or that there is a more efficient path than there
really is)
› BGPSec prevents this by providing a chain of signed paths, each partial path in
the chain being signed by the AS that advertised that part of the path
How does an attacker who performs BGP hijacking prevent being detected by traceroute?
When an attacker performs a BGP hijack and leaves its own AS out of the path, it can ensure
that even traceroute cannot discover it (the missing AS, that is) by simply not decrementing the
TTL field on the traceroute when it passes through the attacking AS. To traceroute, it then looks
like that AS isn’t actually there.
How can DNS be manipulated (i.e., attacked) to allow someone to become a
“man-in-the-middle”?
There are several ways this could happen, but the most common is DNS poisoning. The attacker
can SPAM DNS responses with a bad domain→IP address mapping to a local DNS server. If the
attacker is lucky, or keeps trying for long enough, at some point the local server will issue a
query that a SPAMed response could potentially be a legitimate response to (i.e., it has an ID
that matches the request). When this happens, the local server will accept the attacker’s
response and not only reply to the request with the bad mapping but also cache it and use it to
respond to new requests for the same domain name. Once the bad entry is in place, hosts that
want to reach that domain will instead go to the IP address given by the attacker. The attacker’s
machine at that IP could then intercept traffic as a MITM or simply spoof the legitimate server
(e.g., to collect login credentials).
How can ARP be used to mount a “man-in-the-middle” attack against a host on the same
local (Layer 2) network as the attacker? (Notice how Wi-Fi is especially vulnerable to this,
particularly “public hotspots”!) For a hint to help you get started, try a web search for
“gratuitous ARP”.
ARP poisoning works similarly to DNS poisoning, except that there is not ID value that the
attacker needs to guess (or SPAM enough guesses that one of them might be right). Not only
that, a host will accept an ARP response even if no ARP request for that IP→MAC mapping was
ever made – such a response is referred to as a “gratuitous ARP response”. An attacker could
send gratuitous ARP responses for a particular IP address to hosts on its local network so that
those hosts send messages to the attacker’s MAC instead. For example, the attacker may send
gratuitous ARP to a host for the network’s gateway router, ensuring all packets headed for
outside the local network instead come to the attacker’s host instead. It could also send a
gratuitous ARP to the router for the host’s IP address, ensuring that return traffic is also sent to
the attacker’s host.
This is particularly powerful because it’s very easy to do and can let an attacker become a MITM
for virtually all traffic to/from a target host. It’s also a little harder to detect because the IP addresses are still the correct IP addresses for all the machines involved – only the MAC address
have changed. The main drawback compared to something like DNS poisoning is that the
attacker must be on the same local network as the target in order to do this. However, users
connected to the same “public hotspot” are indeed all on the same local network, making them
particularly vulnerable to this sort of attack.
How do SYN cookies work? How does this prevent resource exhaustion type denial of
service (DoS) attacks on a server (i.e., trying to exhaust the server’s resources, rather than
exhausting the network’s resources)?
The server does not allocate resources for the TCP connection immediately upon receiving a
SYN packet, but instead waits for the ACK (final part of the 3-way handshake) to allocate those
resources. In order to prevent attackers from simply doing an “ACK flood” instead of a SYN
flood, the server’s SYN/ACK response to the SYN packet contains a special “SYN cookie” that it
uses as the connection’s initial sequence number. When the server gets an ACK, it can calculate
whether or not the sequence number in that ACK could have been legitimately generated as a
SYN cookie. (The ACK number is the SYN cookie +1, so the server subtracts 1 to get the
candidate SYN cookies that it tests.) If the ACK sequence number (SYN cookie) checks out, then
the server knows 1) that the client has engaged in the entire 3-way handshake, rather than
sending spurious ACKs, and 2) the client’s IP address given by the IP headers is it’s legitimate
address, because otherwise it wouldn’t have received the SYNACK that contains the SYN cookie. (There are some more details about how exactly it is able to programmatically verify the
legitimacy of a SYN cookie extracted from an ACK message without having stored any data after
the SYN and SYN/ACK steps, as well as how it is able to prevent replay attacks. However, we’ll
leave this answer at this moderate level of detail for now.)
If you are trying to detect TCP SYN flooding attacks and want to raise an alarm when there are 1048576 (i.e., 1024 2 ) attack packets using a /12 subnet as the telescope, how many backscatter packets do you need to observe to detect the attack?
The /12 subnet contains 2 32-12 = 2 20 = 1048676. So 1048576/1048576 = 1 packet to observe.
