ip source guard feature and dhcp DHCP scope exhaustion (client spoofs other clients)
A dhcp server assigns ip adress based on mac address carried by client hardware field in dhcp packets.
One potential attack is when a rogue host mimics different mac addresses and causes dhcp server to assign the ip addresses until no ip address is left for legitimate host.
For e.g a host h1 with mac1 has assigned ip address by dhcp server as:
Dhcp server has the above entry in its database.
Using hacking tools such as Yersinia or Gobbler one can create a dhcp discover messages each time creating a different mac for client hardware field in dhcp server thereby causing a dhcp server to assign ip addresses because to dhcp server , these are legitimate dhcp discover messages with each carrying a different mac in client hardware addresses.
You might say use dhcp snooping and it will prevent that ( dhcp scope exhaustion) and configure the switch to check if src mac matches the client hardware address in dhcp message. But still we can creat spoofed discover messages where src mac in ethernet header will match the client hardware address in dhcp discover message. We still did not overcome the problem.
You might say use IP source guard feature but will it really prevent that problem from happening?
Let me illustrate it :
Let say we have configured dhcp snooping on sw1 and f1/1 is untrusted port. The switch has following dhcp binding
126.96.36.199 mac1 vlan1 f1/1
Next we configure ip source guard to validate both src mac and src ip against the dhcp bindings . When we configures ip source guard first , it will allow dhcp communication only so a host can request ip address and a dhcp binding can be built. After that ip source guard will validate src ip or src mac or both against the dhcp binding.depending upon how we configure ip source guard.
In our case we have configured ip source guard to validate both src mac and src ip against the dhcp binding.
A dhcp binding is already created as:
188.8.131.52 mac1 vlan 1 f1/1
Now using the hacking tools Yersinia or Gobbler on h1, we create our first spoofed dhcp discover message where src mac=mac2 in ethernet header and client harware address= mac2 in dhcp discover message. Since switch is configured with ip source guard feature and therefore allows dhcp discover message to pass through. Dhcp server upon receiving the dhcp message assigns another ip address from the pool. Now the dhcp server has following entries:
We can continue to craft spoofed dhcp discover messages as mentioned above and have dhcp server keep assigning ip addresses until the whole pool is exhausted.
So my question is how does ip source guard in conjuction with dhcp snooping prevent this particular attack from happening? ( i.e DHCP scope exhaustion)
ip source guard feature and dhcp DHCP scope exhaustion (client s
But am little confused with your statement on dhcp snooping. You are going to have the dhcp snooping on the access ports where the enduser machines/servers connected to prevent any dhcp attack. It means if any of user connected in that switch/vlan runs a dhcp services like vmware for eg. Snooping will prevent the dhcp/bootp servers connected to that port will not be able to process. Only the dhcp discover message from the clients will get broadcast. Obviously it will go to the trusted port i.e. your uplink in most of the cases. If you define your ip helper address in the VLAN's then it forwards the request to the same and gets responded.
Very critical part when a client sends discover message as u said rogue servers will try to send the dhcp offer message. When we have the dhcp snooping it prevents the 1st level of hacking itself. I don't think so it will have any impact on dhcp address releasing.
This is going very intresting. We can share more ideas...
Re: ip source guard feature and dhcp DHCP scope exhaustion (clie
First of all, we gather all the information about the locations of legitimate dhcp servers in our network. Once we have this information, we will configure the ports used to reach them as trusted. All the ports where end users will connect will be untrusted and therefore subject to dhcp snooping .
it means if any of user connected in that switch/vlan runs a dhcp services like vmware for eg. Snooping will prevent the dhcp/bootp servers connected to that port will not be able to process.
Yes that is correct. Because dhcp snooping feature will check these ports for the messages usually sent by dhcp server such as dhcp offer, etc. If the end user is running dhcp server using virtual machine, that port should be configured as trusted if it is dertermined that end user is running a legitimate dhcp server using vm ware.
When we have the dhcp snooping it prevents the 1st level of hacking itself. I don't think so it will have any impact on dhcp address releasing.
I am sorry. You lost me here. What is 1 level of hacking?
Dhcp snooping checks for dhcp messages such as dhcp release, dhcp decline.on untrusted port against the dhcp bindings.
Here is why;
Let say we don't have dhcp snooping in above attack and h2 is a legitimate user has already assigned ip address 184.108.40.206 by dhcp server. Thus the dhcp server has an entry:
Next we connect rogue user and it gets ip address 220.127.116.11 now the dhcp server has entries:
199.199.199. 1 mac1
Now using hacking tools, h1 create a fake dhcp release message with 18.104.22.168.2 mac2
Dhcp server upon receiving this message, will release the ip address and returns it to the pool.
By using DHCP snooping, switch will peer inside dhcp release message and checks against the binding. If there is conflict, it will drop the message.
If have dhcp snooping configured , then switch will have adhcp binding as:
22.214.171.124 mac1 vlan 1 f1/1 lease time
126.96.36.199 mac2 vlan 2 f1/2 lease time.
If h1 tries to send fake dhcp release with ip address 188.8.131.52 mac2
Switch will check ip address 184.108.40.206 and mac2 against the binding related to f1/1 . Sw will find a conflict and therefore drops the dhcp release packet.
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...