DHCP Starvation attack on my WAN interface

goulou

…or something else?

Since installing pfSense I'm seeing continuous DHCP broadcasts which are filling up my F/W logs fast. The rouge DHCP broadcasts are being denied by the default pfSense rule--> WAN, Block In: Private IP's.

My setup is pretty simple:
Internet--->CableModem--->(F/W + Router + DHCP server on LAN = pfSense 1.2.1)--->Switch--->Private LAN Clients

So... the following F/W event is logged every 10 - 15 seconds.
WAN 10.x.x.x:68 -> 255.255.255.255:67 UDP [Broadcast]

When I switch to raw F/W logging, I can see the source of these DHCP broadcasts are all from one private External Gateway address: 10.x.x.x. Interestingly, the client IP's and corresponding MAC's are unique routable addresses on my own WAN subnet… they begin to repeat by the 4th to 5th logged entry (I assume the Client IP and MAC's are spoofed and maybe the source gateway is too).

1. Can someone offer an informed opinion about whether I'm seeing a DHCP starvation attack here?
2. Is there anything creative I can do with the WAN rules to reduce the numerous log entries?
3. Any new functionality planned for V 2.0... perhaps some added logic which can classify various types of attacks and label as such (if it really is an attack). If that's possible maybe log entries (arriving from the same source) could be reduced once a pattern emerges that suggests it's an attack. Something like that would be awesome for version 2.0 but of course it's easier to suggest than it is to code.... I'm just sayin'.

Thanks in advance and many thanks to pfSense for this awesome replacement to my SonicWall who halted the firmware upgrade cycles for my model and would have made me pay for them even if they hadn't >:(

http://www.networkdictionary.com/networking/DHCPStarvationAttack.php

cmb

That's pretty routine on cable connections, not likely to be an attack. You have thousands of hosts on the same broadcast domain as you, so you see a lot of noise like that. Just add a rule on your WAN to block but not log that traffic.

goulou

@cmb:

That's pretty routine on cable connections, not likely to be an attack. You have thousands of hosts on the same broadcast domain as you, so you see a lot of noise like that. Just add a rule on your WAN to block but not log that traffic.

Thanks cmb for your reply… guess I just don't completely grasp how the traffic source (the logged external G/W address) shows up as a private range (10.x.x.x RFC 1918) when the corresponding client IP's and MAC's are unique route-able addresses... about 5 of them before the pattern repeats. Can you kindly give any details about why (if this is not a malicious broadcast) is the G/W address not also on my same ISP subnet as are the client IP's? Thanks very much!

Thank you also for your suggestion... So the new rule would have to be above the default rule to block private IPs inbound to the WAN. I'll give it go.

Obliv10n

Hi guys,

While searching for similar problems on the forums, I came up to this post.
I'm also seeing DHCP replies / BOOTP broadcasts packets coming to my WAN side, since I've upgraded my PF to 1.2.1, 1 week ago. But here, the packets shows up in this format every couple of seconds, depending on the external traffic. Like I said, never had this precise broadcast before 1.2.1. Here's the example (from bottom to top):

Jan 8 09:28:42 pf: <009> Client-Ethernet-Address 00:1b:38:b5:37:d7 [|bootp]
Jan 8 09:28:42 pf: <009> Gateway-IP 24.230.210.1 (Provider Default Gateway)
Jan 8 09:28:42 pf: <009> Your-IP 24.226.134.73 (Client's assigned address)
Jan 8 09:28:42 pf: 25. 469461 rule 38/0(match): block in on fxp0: (tos 0x0, ttl 255, id 53914, offset 0, flags [none], proto UDP (17), length 341) 172.29.128.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 313, xid 0xff1e06b, Flags [Broadcast] (IANA sending his replies)

So, the IANA address (172.29.128.1) sends replies to some other ISP clients . MAC and "Your-IP" changes every time of course. So, I tried two rules (WAN side) to drop this noise :

First one was : Source : ANY - Dest : 32 bits (255.255.255.255) - Proto : UDP - Port : 68 - Drop - No log
Second one : Source : ANY - Dest : ANY - Proto : UDP - Port : 68 - Drop - No log

Neither of those did the job. I keep seeing this noise, both in local logs and syslogs.

What kind of rule did you define goulou or cmd to drop and not show this traffic ?

Any other can confirm that this is a behavior that showed up after upgrading to 1.2.1 ?

Any help or feedback to what you've done goulou will be appreciated !

Thanks

goulou

Obliv10n,

Thanks for checking in on this…

I compared your raw F/W log entries with mine and the only difference (other than the actual addresses themselves) is that your "Gateway-IP" is a valid route-able address: 24.230.210.1 ...where mine is not. My logs shows the Gateway-IP is a reserved RFC 1918 address. I checked the 24.230.210.1 address on isc.sans.org/ipinfo.htm just to see if there were any reports on it... there isn't.

Sorry that I can't add much else, I appeciated "CMB's" reply which indicates that the traffic is likely not malicious but still... why is mine coming from a private address Gateway-IP on the public WAN? That just doesn't sound right to me.

I had not yet put up any new rules... from what you mentioned I'm going to pass on doing so since it apparently doesn't help to drop the constant log entries.

Obliv10n

Hi goulou,

I also find it strange that you're seeing private traffic replies coming to your WAN side.
But maybe this would make a difference at your place :
Go to the PF admin page, click on Interfaces / WAN, go down at the bottom, and check both "Block private networks" and "Block bogon networks". Maybe your bad DHCP replies will stop afterwards.
For my case, they're both checked, but it won't do it for me, since my replies are coming from a legitimate ip.
If you enable these two options, and it doesn't do the trick, and If you ever create a rule that doesn't log this traffic, feel free to share ! Even doing a rule like : source : ip in question - destination : ANY - proto : ANY - drop - no log … still fills up the logfiles.

Good luck

goulou

Yep… agreed, it's definitely some strange stuff; unless all the 10 dot source traffic is spoofed and then it begins to make more sense. Meantime I had already added the rule to "Deny Bogon Networks" in addition to denying private networks (WAN default rule).

As far as my log space goes, I guess it's better to be aware of that traffic then never to see it at all but I have another idea. I'm going to have 2 separate log views by installing a Syslog Daemon and then adding a custom filter to drop the redundant logging porting out to my Syslog box.

Don't know if this is asking for too much (short of posting a bounty to the Developers) but how cool would it be if in a future pfSense release, that additional logic is added to the F/W logging algorithm; so basically the firewall recognizes known patterns (like this one?) and labels/highlights the traffic pattern for what it is. I'm willing to assume that it's not an attack but, could it be labeled by the logging algorithm for whatever it actually is? Whether a rouge DHCP server, etc., if events like that can be labeled and condensed when appropriate, that would be some truly awesome stuff. My newly retired SonicWall identified DDoS attacks, SynFlood, portscans etc. but I'm far more impressed overall with pfSense and I don't want to sound greedy ;D

cmb

ISPs frequently use private IPs on some infrastructure devices, it's not unusual to see DHCP from 10.x addresses.

This has always happened, it's just now showing up in the logs in 1.2.1 and newer because an auto added rule that silently dropped DHCP and shouldn't have been added was removed. Just add a rule to the top of your WAN rules to block it if you're seeing noise in your logs.

goulou

CMB, I wouldn't have assumed that when trying to piece it together but hey, that's good enough for me.

Sorry to keep this thread going but while following your solution to use a manual WAN rule on top to drop the noise, I found a reason not to be in a rush over this…

1. I Created a new rule to block the specific private IP (broadcast) source address; as expected the 2 system rules found on the WAN tab (enabled by check-box) remain on top but there seems to be no way to relocate my new manually created rule to the top of the heap... so...
2. I released my ISP assigned address on my WAN... (or just unplug the WAN)
3. Then I deleted both system WAN rules (block private IP's and Bogon Networks)... now with only my manual WAN rule still present...
4. Went back to the WAN tab and reselected the block private IP's system rule and it immediately populates itself right back on top of my manual rule... I was afraid of that.

So that means I will need to create replica's of one or both system WAN rules manually starting with 3 separate rules to cover all 3 private IP ranges/RFC1918. As much as I appreciate your suggestion, for now I'm just going to stick to the system (default rules) and work around this with a syslog daemon and hopefully a filter to not re-log traffic from that single broadcast gateway (source) address... Thanks again! Any general knowledge book suggestions on residential ISP's which you can recommend... I would like to get up to speed on this stuff.