This article is the first of a series explaining layer 2 attacks identification and mitigation techniques, which will be a part of a bigger series discussing Security Infrastructure.
We will be discussing the most common attacks and how to mitigate them; but more important, we will discuss deployment and design considerations.
During this series of articles, I will follow two different approaches;
1) Explain attacks related to OSI model layers (Like this layer2 security series)
2) Securing a specific traffic flow (Like securing user Internet traffic)
There will also be video lectures, webinars, and open discussions at the end of each major part. If you are interested in security infrastructure architecture, stay tuned.
Dynamic Host Configuration Protocol (DHCP) is a protocol designed to dynamically assign network configuration to clients/hosts that require IP connectivity.
DHCP uses 4 types of messages; Discovery, Offer, Request, acknowledge (DORA); and the process goes like this:
Client sends a discovery (DHCPDiscover) broadcast message looking for a DHCP server.
DHCP server replies with an offer (DHCPOffer) broadcast message contains an IP address lease.
Client accepts the offer by broadcasting a request (DHCPRequest) message back to the DHCP server.
DHCP replies with and acknowledge (DHCPAcknowledgment) broadcast message to the client.
In a typical deployment client and DHCP server don’t exist in the same layer 2 domain; there will be multiple layer 3 hops between them. Now, as you noticed the DHCP (DORA) messages are all broadcast messages. So how will the client communicate with DHCP server and vice versa?
Typically, a client is connected to a switch; the switch can act a DHCP relay agent. A DHCP relay agent receives DHCP messages from the client and sends it to the DHCP server configured on the switch on behalf of the client as a unicast message using the “giaddr” (Gateway IP Address) filed.
There are 4 other DHCP messages:
- DHCPInform: Client uses this message to request DHCP options from a DHCP server.
- DHCPNak: When DHCP is not able to provide IPs, it will reply with a DHCPNack (Negative Acknowledge).
- DHCPDecline: If the configuration received by the client is invalid; the client will reply with a decline message.
- DHCPRelease: The client sends a release request to DHCP server to release the IP address assigned to it.
DHCP starvation: An attacker keeps sending DHCP requests until the whole scope is exhausted on the DHCP server and other legitimate clients can’t find IP addresses which will cause a denial of service for the whole scope/VLAN.
Rogue DHCP server: Where an attacker places himself as a DHCP server and start leasing IP addresses to legitimate clients from a wrong scope causing a denial of service for all clients in that scope. This could also happen unintentionally, like when an employee brings his wireless router and plugs it to the company switch.
Forged release and decline messages: An attacker can manipulate DHCPRelease, or DHCPDecline messages forcing the server to release of decline registration of legitimate clients. IP addresses will become available for leasing by the server which will lead to duplicate IP addresses that will cause issues in the network.
DHCP snooping is a mechanism that provides protection to clients from rogue DHCP servers. Almost all of switches support DHCP snooping.
Figure 1 – DHCP Snooping. source h3c.com.hk
How it works
After activating DHCP snooping, it will start monitoring DHCP messages from and to clients connecting to the network, once a client receives a DHCPAcknowledgment message from the server, DHCP snooping will create an entry contains the client IP address MAC address, lease time, VLAN, and interface in a database file called the “Binding Table”.
DHCP snooping allows administrators to identify which ports are trusted to receive DHCP messages from and which are not. Uplinks leading to the DHCP server are identified as trusted, while all other access ports are identified as untrusted.
Dropping rouge DHCP messages
Snooping will drop DHCP messages following the below criteria:
If the source MAC address of the of the client mismatch the “CHADDR” field in the DHCPDiscover message; snooping will drop it. This mitigates the DHCP starvation attacks.
If the switch receives a DHCPOffer or DHCPAcknowledgment message on an untrusted port, it drops and logs it. This will mitigate rouge DHCP server attacks.
Snooping will also drop and log any DHCPRelease or DHCPDecline messages from clients if they are not sent from the same interface that originated the first DHCP messages exchange with the server. That mitigates the forged messages attacks. (See Figure 1)
Figure 2 – Cascaded switches. source h3c.com.hk
DHCP deployment considerations:
Most vendors automatically mark access ports as untrusted and trunk ports (uplinks) as trusted. If there are cascaded switches, consider changing those trunk ports to untrusted. (See Figure 2)
Binding table is very important, as a best practice, consider saving the database file to a TFTP server; that way, when the switch crashes, it can still retrieve the database file and resume clients’ operations quickly; especially when combining DHCP snooping with Dynamic ARP Inspection or IP Source Guard.
In the next article we will be discussing Dynamic ARP Inspection; which is another layer 2 security technique that builds upon DHCP snooping.