PFSense — DHCP Logging Problem
Ports 67 and 68 don’t appear in firewall logs unless you add firewall rules for that traffic
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
⚙️ Check out my series on Automating Cybersecurity Metrics | Code.
🔒 Related Stories: Bugs | Network Security | PFSense | Netgate
💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You won’t see DHCP in the firewall logs unless you explicitly create a rule for it, so it’s hard to know if it is blocked.
In other words, create a rule to allow UDP 67 to 68 from the current interface network to anywhere (since it’s a broadcast address to figure out what the IP is for a particular MAC).
Then create a rule to allow UDP 68 to 67 from the expected gateway back to the current interface network.
Once you do that, you will see logs for DHCP requests.
Now I’m thinking…is there a way to alter DHCP to only allow requests to end up at a specific gateway? And if not, why not? Can someone create that option?
If you incorrectly configure DHCP to allow UDP 67 and 68 to and from anywhere, someone on the network at your ISP could, in theory, request an IP address from your DHCP server. No? I mean if the traffic can reach your WAN Interface IP on port 67 from the Internet, what would happen? Curious. I’ll let someone else write about that.
With packet capture turned on, I was able to see a quest for a an IP address to Comcast / Xfinity that returned an address with 98.x.x.x in the Savannah area, even though that is not the number my IP address starts with. I saw a successful request for that IP address and the assignment. I was confused for a minute thinking that the request was made to my firewall and that my firewall assigned that IP but then I remember that doesn’t make any sense. That IP is not on my firewall. Additionally, the request was not from my firewall due to the direction of the traffic. Therefore, I seemed to be seeing someone else’s DHCP request to the Comcast router, I guess?
Just saw this again. If you configure DHCP on your WAN then you’ll probably be able to get other Comcast IPs to hit your device successfully on port 68. Interesting. But then you probably shouldn’t have DHCP on your WAN or in floating rules.
That’s somewhat curious, but I guess it’s like sniffing traffic on a wifi network? I’m not too familiar with the inner workings of Comcast and have other things to do so I’ll just leave that there for someone else to explore further.
But I do think that DHCP traffic for your own firewall needs to show up by default in the firewall traffic logs on PFSense. Why wouldn’t it? I personally don’t like the magical firewall rules I can’t control, either. Give people the option to take those over and control them. If you don’t explicitly create a rule to block IPv6 I don’t think it really gets blocked, even when you disable all the other settings. I’ll let someone else test that for any potential exploit paths unbeknownst to those who do not turn on logging for the magic pfsense-controlled rules.
Follow for updates.
Teri Radichel | © 2nd Sight Lab 2023
About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight LabNeed Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for PresentationFollow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab
