[Kea-users] Duplicate Addresses, address pool exhaustion with DHCPDECLINE flood

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[Kea-users] Duplicate Addresses, address pool exhaustion with DHCPDECLINE flood

Kari Karvonen
Hello

If there is faulty DHCP-client on a network that keeps requesting IP's
and after receiveing IP-offer client sends DHCPDECLINE and DHCP-server
marks IP-address as declined for 24 hours. If client keeps repeating
this, address after address will be marked as declined and soon entire
DHCP-pool is exhausted.

I looked Kea 1.5.0 user guide and found that it is possible to shorted
decline time

  "decline-probation-period": 3600

But is there something else on dhcp-server side to prevent this kind of
behaviour?

--
Kari Karvonen
Network specialist
+358445557360
www.kasenet.fi
_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users
M K
Reply | Threaded
Open this post in threaded view
|

Re: [Kea-users] Duplicate Addresses, address pool exhaustion with DHCPDECLINE flood

M  K
Hello Kari,

I'm not sure about Kea, Kea hooks, or if someone is going to write a Kea hook for that, but there is no DHCP server that I know about that implements this outside-of-the-box. Actually, most or all effective solutions in network-originating layer 2 attacks are basically built on networking devices software and/or network monitoring software, or the least: manual troubleshooting.

If your switching equipment has a feature to help, then use it. If not, you can set a network monitoring software that analyzes DHCP DISCOVER messages and alert you if the rate from a specific MAC is abnormal, or the general rate on the network is abnormal. SolarWinds and PRTG come to mind.

--
MK


On Wed, Apr 17, 2019 at 2:56 PM Kari Karvonen <[hidden email]> wrote:
Hello

If there is faulty DHCP-client on a network that keeps requesting IP's
and after receiveing IP-offer client sends DHCPDECLINE and DHCP-server
marks IP-address as declined for 24 hours. If client keeps repeating
this, address after address will be marked as declined and soon entire
DHCP-pool is exhausted.

I looked Kea 1.5.0 user guide and found that it is possible to shorted
decline time

  "decline-probation-period": 3600

But is there something else on dhcp-server side to prevent this kind of
behaviour?

--
Kari Karvonen
Network specialist
+358445557360
www.kasenet.fi
_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users

_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users
Reply | Threaded
Open this post in threaded view
|

Re: [Kea-users] Duplicate Addresses, address pool exhaustion with DHCPDECLINE flood

Alberto Pollastro

Hi all,

I agree with Kari; it could be useful to have an option which permits to ignore the DHCP DECLINE messages like the one present in ISC dhcpd ("declines" keyword in config file: https://www.isc.org/wp-content/uploads/2018/02/dhcp44.html).
Another option it could be to implement on server side a DHCP DECLINE per source MAC rate limiting (or a kind of Fail2ban for DECLINE messages) because usually the L2 switch support DHCP rate limiting accordint to the switch port.

Thanks,
Alberto

Il 18/04/2019 09:08, Mohammed Khallaf ha scritto:
Hello Kari,

I'm not sure about Kea, Kea hooks, or if someone is going to write a Kea hook for that, but there is no DHCP server that I know about that implements this outside-of-the-box. Actually, most or all effective solutions in network-originating layer 2 attacks are basically built on networking devices software and/or network monitoring software, or the least: manual troubleshooting.

If your switching equipment has a feature to help, then use it. If not, you can set a network monitoring software that analyzes DHCP DISCOVER messages and alert you if the rate from a specific MAC is abnormal, or the general rate on the network is abnormal. SolarWinds and PRTG come to mind.

--
MK


On Wed, Apr 17, 2019 at 2:56 PM Kari Karvonen <[hidden email]> wrote:
Hello

If there is faulty DHCP-client on a network that keeps requesting IP's
and after receiveing IP-offer client sends DHCPDECLINE and DHCP-server
marks IP-address as declined for 24 hours. If client keeps repeating
this, address after address will be marked as declined and soon entire
DHCP-pool is exhausted.

I looked Kea 1.5.0 user guide and found that it is possible to shorted
decline time

  "decline-probation-period": 3600

But is there something else on dhcp-server side to prevent this kind of
behaviour?

--
Kari Karvonen
Network specialist
+358445557360
www.kasenet.fi
_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users

_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users

_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users
Reply | Threaded
Open this post in threaded view
|

Re: [Kea-users] Duplicate Addresses, address pool exhaustion with DHCPDECLINE flood

Tomek Mrugalski
On 18/04/2019 15:16, Alberto Pollastro wrote:
> I agree with Kari; it could be useful to have an option which permits to
> ignore the DHCP DECLINE messages like the one present in ISC dhcpd
> ("declines" keyword in config file:
> https://www.isc.org/wp-content/uploads/2018/02/dhcp44.html).
> Another option it could be to implement on server side a DHCP DECLINE
> per source MAC rate limiting (or a kind of Fail2ban for DECLINE
> messages) because usually the L2 switch support DHCP rate limiting
> accordint to the switch port.
We were thinking about rate limiting of various things, but never got
round to implement this mechanism.

As a crude workaround, you could try setting up
"decline-probation-period" to something very small, like 10 seconds or
less. But please keep in mind that this would be effectively disabling a
protocol feature that's there for a reason.

Also, if you want to do some experiments, disabling DECLINE handling on
the server side is a trivial code modification. Open up
src/bin/dhcp4/dhcp4_srv.cc and comment out line 1024:

// processDecline(query, ctx);

Note the side effect is that your buggy client will think the lease was
declined, will revert back to discover and the server will assign the
same lease again. This loop will likely repeat over and over again.

Depending on your situation this may be a better or worse workaround
compared to low decline-probation-period.

Tomek
_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users
Reply | Threaded
Open this post in threaded view
|

Re: [Kea-users] Duplicate Addresses, address pool exhaustion with DHCPDECLINE flood

attila.domjan.hu
I will disable in kea the decline feature too. In our FTTH access
network IP conflict never ever can happen, because of the dhcp snooping
based ip- and arp anti spoofing, so it is just a vulnerability. I suggest, the dhcpdecline feature should be disable via configuration option.

Attila

On Thu, 2019-04-18 at 19:31 +0200, Tomek Mrugalski wrote:

> On 18/04/2019 15:16, Alberto Pollastro wrote:
> > I agree with Kari; it could be useful to have an option which
> > permits to
> > ignore the DHCP DECLINE messages like the one present in ISC dhcpd
> > ("declines" keyword in config file:
> > https://www.isc.org/wp-content/uploads/2018/02/dhcp44.html
> > ).
> > Another option it could be to implement on server side a DHCP
> > DECLINE
> > per source MAC rate limiting (or a kind of Fail2ban for DECLINE
> > messages) because usually the L2 switch support DHCP rate limiting
> > accordint to the switch port.
>
> We were thinking about rate limiting of various things, but never got
> round to implement this mechanism.
>
> As a crude workaround, you could try setting up
> "decline-probation-period" to something very small, like 10 seconds
> or
> less. But please keep in mind that this would be effectively
> disabling a
> protocol feature that's there for a reason.
>
> Also, if you want to do some experiments, disabling DECLINE handling
> on
> the server side is a trivial code modification. Open up
> src/bin/dhcp4/dhcp4_srv.cc and comment out line 1024:
>
> // processDecline(query, ctx);
>
> Note the side effect is that your buggy client will think the lease
> was
> declined, will revert back to discover and the server will assign the
> same lease again. This loop will likely repeat over and over again.
>
> Depending on your situation this may be a better or worse workaround
> compared to low decline-probation-period.
>
> Tomek
> _______________________________________________
> Kea-users mailing list
> [hidden email]
>
> https://lists.isc.org/mailman/listinfo/kea-users
>

_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users
Reply | Threaded
Open this post in threaded view
|

Re: [Kea-users] Duplicate Addresses, address pool exhaustion with DHCPDECLINE flood

Tomek Mrugalski
On 23.04.2019 07:59, [hidden email] wrote:
> I will disable in kea the decline feature too. In our FTTH access
> network IP conflict never ever can happen, because of the dhcp snooping
> based ip- and arp anti spoofing, so it is just a vulnerability. I suggest, the dhcpdecline feature should be disable via configuration option.
That's a great justification! Thanks for sharing. Can I ask you to go to
gitlab.isc.org/isc-projects/kea and open up a feature request for this?

Thanks,
Tomek
_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users