"Deny unknown clients" enabled, getting an IP anyway…
-
Next try:
Client shutdown. Added a pcmcia network interface and rebooted to Win 7 (delete temporary lease for 10.0.2.2 at pfSense in advance). Connected this new interface via RJ45 to the OPT1.
Same result, get the 10.0.2.2 IP and even worse: The ICMP from my ISP gateway is back!
I don't really understand what's going on here…
-
Ok, I have an idea what's going wrong here:
I recognized that both the fixed network interface of the client notebook AND the pcmcia network interface have a DHCP Static Mapping on the LAN (!!), but not on the OPT1 interface. But apparently pfSense does not differentiate between the interfaces w.r.t. static mappings and provides an IP even when the network interface is added to the WRONG network (here: OPT1 instead of LAN)
Proof of concept:
Took a pcmcia network adapter without static mapping, result: No IP was leased to the client(as to be expected), see pic 1
Next, take another client with a static mapping for LAN (but not OPT1) and connect it to OPT1, result: Get an IP lease (10.0.2.2, as usual) at the wrong interface, see pic 2.
Can anybody reproduce this?
-
yes this is know thing… The dhcp server shares this database.. So if it knows about a client, its know no matter what interface it connects on.
There have been many threads about this, would have dig up a few.
-
From security point of view this is eeehhhm sub-optimal. Not?
Did anybody file a bug for that?
-
Why would it be a security bug… The client is KNOWN to pfsense and the dhcp server.. Just because you move it to a different segment, still known - so why should it not get an IP? Or why would it not be able to talk to pfsense?
Look through the bug list, dok is the bug king he like knows them all off the top of his head ;)
here
https://redmine.pfsense.org/issues/4584 -
Hi John!
I highly appreciate your competent comments from the first day I joined this forum, but at certain points we will never share the same opinion.
Look, I have different networks at the same pfSense to strictly separate certain resources from each other. These networks have normally no way to communicate with each other BY DESIGN. I don'T want any clients from the dirty network to be active in the other network, to keep it simple.
So it definitely IS a security bug if a client not authorized for this network gets an IP and can browse arround .
But I guess you see this as "security by obscurity".
Let's see it the other way arround: Why has the GUI a static mapping tab for each DHCP server, as this suggests that you can manage access for each network SEPARATELY? Then scrap that and say to the user: "Only one tab here, as there is no way to limit access. Anybody having access to ANY network here has access to ALL networks."
That would be fair. But hard so sell for a "security appliance"….
-
I am just saying that your security appliance KNOWS about this client, the wording in the setting should be changed for sure. But its an issue with the wording, and the fact that the known clients is shared in one listing..
See the bug.. From 9 months ago..
There are many people that might say, hey I know this client - he can connect to any network he wants. Maybe he changes wifi networks, maybe he plugs into the conf room, and his desk with this laptop, etc.
The wording should reflect this issue that its a shared database for known clients, and that if it moves to network B, he would get an IP there if dhcp is on that network since he is known from network A static settings, etc.
I don't really see it as a security issue that the wording of static arp and deny "unknown" needs more clarification.
And to be honest not sure I would classify security as not giving a client dhcp.. Your firewall rules should prevent what you don't want from any client talking on the network.. MACs can be spoofed for sure.. Limiting communication based on mac is not really good security if you ask me.
-
…had a look now at the bug report, two things come to my mind:
1. Thanx to Phil that he gave me the chance to reproduce this and find the same things as he did ;-)
2. Typical pfSense: Nobody has taken the slightest notice of this bug report within 9 months... wuuuaaaa. All busy brushing up the GUI, which will not help to improve network security (but has to be done someday, I know)
Someday soon I will get Parkinsons from all the head shaking day in and day out...
-
Your more than welcome to jump in and fix it ;)
I would say the move to 2.3 and yes a new gui is a bit more involved than cosmetics..
-
Ok, I need a crash course in …eeehm ...which language btw? :-D
