We are still talking about the different types of OSI Layer attacks, and now we have to discuss another type of attack which is the DHCP Rogue attack.
This attack is so hard to detect. Any attacker, who is connected to our Layer 2 network which a Kali Linux machine (or other tools) or a simple router, is able to be a DHCP Server and can run this attack.
You can see, the attacker can make his Kali Linux machine become a DHCP server while R1 is the legitimate DHCP server, then once the PC got connected to the network, it will have to ask for an IP address from the DHCP server. As we do have 2 DHCP servers on the network (R1 and Kali Linux), it may happen that the PC will get a lease from the Kali Linux DHCP server faster before the R1 does. This way, the PC will end up using the IP, subnet, gateway and DNS from the Kali Linux.
The attacker is smart enough, he will run some type of capturing because now all traffic from the PC will go via the Kali Linux (because he is the gateway now of the PC) and this will end up that the Kali Linux will be able to capture and analyze all type of data that the PC is doing. Imagine guessing the passwords, credit cards, login to network devices, and the list can go on.
For this reason, we should deploy something on our network to secure it from such type of DHCP rogue attacks.
Let’s see on a LAB how this can be done.
LAB: DHCP Rogue Attack Prevention
I do have this scenario now. R1 has an IP on its interface Ether1 of 172.80.80.1/24 and I have DHCP server enabled on this interface.
I do have a switch (SW1) where I put in bridged ports Ether1 and Ether2 so they become in the same broadcast domain. This way, the PC should receive an IP address from R1. Let’s check if everything is working as it should work:
Indeed, everything looks very normal for now.
I know that R1 will always be connected to the interface Ether1 of the switch. So, I have to make a configuration on the switch saying that the DHCP server connected to its interface Ether1 is a trusted one and can accept the DHCP messages (DORA), and in case a DHCP server is found on another interface (but Ether1) then do not allow it to pass the DHCP messages. Got me?
Let me show you how you can do that on the switch.
1st you need to go to the bridge interface on the switch and enable DHCP snooping globally. After you do that, you have to go to each particular physical interface, (which are inside the bridge) and say that the trusted interface is the one where the DHCP server is connected to, and all the other interfaces are untrusted.
I have made Ether1 as a trusted port. Be careful, by default all ports are untrusted, so you only need to check “Trusted” box on the interface connected to the legitimate DHCP Server, and for the others you can keep them as they are (untrusted).
Let me just show you that Ether2 does not have “Trusted” box checked:
Fair enough. Let me now release the IP on my PC and renew it to see if will receive the IP address from the DHCP server (all devices are still connected the same as on the picture I showed beginning of this LAB):
I can see clearly that I have received successfully the IP from the DHCP server, meaning that DHCP messages worked between my PC and R1 on this setting.
Now to make another test, I am going to put the interface Ether3 inside the bridge and leave it untrusted, then plug the DHCP server on Ether3 and see if my PC will get an IP from the DHCP server or not.
Let’s add Ether3 inside the bridge port:
Ether3 interface is now inside the bridge as an untrusted port.
I will plug R1 to that port and see if my PC will get an IP from it.
It clearly shows that my PC could not get an IP from the DHCP server when we plugged it into Ether3 which is an untrust port.
This is all what I wanted to show you in this LAB, let me just share the export command line for this LAB for your reference:
/interface bridge
add dhcp-snooping=yes name=bridge1
/interface bridge port
add bridge=bridge1 interface=ether1 trusted=yes
add bridge=bridge1 interface=ether2
add bridge=bridge1 interface=ether3
0 Comments