cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2182
Views
0
Helpful
4
Replies
Contributor

ip source guard feature and dhcp DHCP scope exhaustion (client spoofs other clients)

Hi everybody.

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:

199.199.199.1 mac1

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 :

h1---------f1/1SW---------DHCP server

Let say we have configured dhcp snooping on sw1 and f1/1 is untrusted port.  The switch has following dhcp binding

199.199.199.1    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:

199.199.199.1 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:

199.199.199.1 mac1

199.199.199.2 mac2.

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)

I really appreciate your input.

thanks and have a great week.

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted
Rising star

ip source guard feature and dhcp DHCP scope exhaustion (client s

Hi Sara,

You query was quite interesting. As far as i know anything from untrusted snooping port will not let your fake dhcp server.

You can shoot this query in the below mentioned expert forum which is specific for dhcp snooping and source guard.

https://supportforums.cisco.com/message/3689811#3689811

Please do rate if the given information helps.

By

Karthik

View solution in original post

4 REPLIES 4
Highlighted
Rising star

ip source guard feature and dhcp DHCP scope exhaustion (client s

Hi Sara,

You query was quite interesting. As far as i know anything from untrusted snooping port will not let your fake dhcp server.

You can shoot this query in the below mentioned expert forum which is specific for dhcp snooping and source guard.

https://supportforums.cisco.com/message/3689811#3689811

Please do rate if the given information helps.

By

Karthik

View solution in original post

Highlighted
Contributor

ip source guard feature and dhcp DHCP scope exhaustion (client s

Thanks Natarajan.

DHCP protocol does not have authentication  so open to attack.

Possible attacks are:

1) Rogue DHCP server

2) DHCP scope exhaustion.

I totally understand how dhcp snooping can prevent the first problem( Rogue dhcp server) but how dhcp scope can  be prevented  using dhcp snooping ,still shrouds in mystery for me.

Thanks anyway and have a great week Natarajan.

Highlighted
Rising star

ip source guard feature and dhcp DHCP scope exhaustion (client s

Hi Sara,

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...

Please do rate for the helpful posts.

By

Karthik

Highlighted
Contributor

Re: ip source guard feature and dhcp DHCP scope exhaustion (clie

Thanks Karthikeyan.

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;

h1---------SW1-------dhcp server

               |

             h2

Let say we don't have dhcp snooping in above attack and  h2 is a legitimate user has already assigned ip address 199.199.199.2 by dhcp server. Thus the dhcp server has an entry:

199.199.199.2 mac2

Next we connect rogue user and it gets ip address 199.199.199.1 now the dhcp server has entries:

199.199.199. 1  mac1

199.199.199.2   mac2

Now using hacking tools, h1 create a fake dhcp release message  with  199.199.199.199.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.

IFor e.g

If have dhcp snooping configured , then switch will have adhcp binding as:

199.199.199.1    mac1    vlan 1   f1/1  lease time

199.199.199.2     mac2    vlan 2    f1/2 lease time.

If h1 tries to send fake dhcp release with ip address 199.199.199.2    mac2

Switch will check ip address 199.199.199.2  and mac2 against the binding related to f1/1 . Sw will find a conflict and therefore drops the dhcp release packet.

Thanks