[SOLVED] Not requiring dhcp_server_identifier, Security hole?

krork · 2015-09-22 20:49:40

Hi,
I'm in a student dormitory and our server admin is an unknown and unreachable phantom, just every now and then something changes and things stop working.

dhcpcd ignored the IPs it was offered, so I commented out the line 'require dhcp_server_identifier' in /etc/dhcpcd.conf and that did the trick.

Is this a bad idea?

Could e.g. a rogue DHCP server on our network now reroute my traffic?

If so, is there a way to identify him / to make things secure again?

When I run

dhcpcd -T interface

I can see the dhcp server identifier. Should I watch out for when that changes, or would he spoof our legit server's IP?

I'm very happy about any thoughts on the subject.

Cheers!

Last edited by krork (2015-09-23 08:01:01)

rsmarples · 2015-09-22 21:19:11

RFC2131 says the server MUST include the server identifier in every message, section 4.3.1.

dhcpcd has that as a require mainly because rogue DHCP servers forget to include that option

Even if you have two servers, rogue without server id and real one with server id, dhcpcd should still work with the real server.
It's also common in big business to have >1 DHCP server, and the server id becomes very important here - also with DHCP servers on different subnets as found in some ISP setups.

I know this hasn't answered your question, but it should provide insight on how dhcpcd should react given the environment you have described.

branch · 2015-09-22 21:55:15

DHCP is inherently insecure. How do you know the server you are currently using isn't a rogue? If you allow the DHCP client to set either the default route or the DNS server then a rogue server can reroute your traffic regardless of whether a server identifier was required. Attempting to secure it on an uncontrolled network is futile because layer 2 is insecure. Any rogue gateway just has to win an ARP race with the real one to hijack your traffic.

Proper use of https/ssl for anything important will minimize potential damage from these types of attack.

rsmarples · 2015-09-22 22:05:13

branch wrote:

DHCP is inherently insecure. How do you know the server you are currently using isn't a rogue?

Well, this is why DHCP Authentication RFC's exist. dhcpcd supprts this, but sadly not many servers actually support it, and it's a PITA to lockdown.
A better approach is to block DHCP messages (or IPv6 RA for that matter) at the hub/router/AP level unless it's from a whitelisted source.
Blocks all rogue DHCP dead, clients don't have to care about it.

If you allow the DHCP client to set either the default route or the DNS server then a rogue server can reroute your traffic regardless of whether a server identifier was required. Attempting to secure it on an uncontrolled network is futile because layer 2 is insecure. Any rogue gateway just has to win an ARP race with the real one to hijack your traffic.
Proper use of https/ssl for anything important will minimize potential damage from these types of attack.

Given that thwate was recently reported for issuing fake Google certs, how can you be so sure to trust ssl at all for any remote host?
Once you accept that ssl only blocks MiM attacks and plan security around that it's much easier.

branch · 2015-09-22 22:55:14

rsmarples wrote:

A better approach is to block DHCP messages (or IPv6 RA for that matter) at the hub/router/AP level unless it's from a whitelisted source.
Blocks all rogue DHCP dead, clients don't have to care about it.

Agreed, but we often do not control the infrastructure of the networks we connect our clients to.

Given that thwate was recently reported for issuing fake Google certs, how can you be so sure to trust ssl at all for any remote host?
Once you accept that ssl only blocks MiM attacks and plan security around that it's much easier.

Your right of course, but until we can convince our banks that keys should be exchanged in person it's the only thing we've got.

rsmarples · 2015-09-23 01:12:33

branch wrote:

rsmarples wrote:
A better approach is to block DHCP messages (or IPv6 RA for that matter) at the hub/router/AP level unless it's from a whitelisted source.
Blocks all rogue DHCP dead, clients don't have to care about it.
Agreed, but we often do not control the infrastructure of the networks we connect our clients to.

So if you don't control the infrastructure, you can at least blacklist rogue DHCP servers by ip address.
Not sure what other functionality I can provide here.

branch · 2015-09-23 01:41:12

rsmarples wrote:

Not sure what other functionality I can provide here.

None needed . My original point to the OP was that since ARP (and IPv6 NDP) are also insecure, on an untrusted network we have no option but to assume traffic may be intercepted/rerouted/snooped, and use higher layers of the protocol stack to secure it.

rsmarples · 2015-09-23 01:52:08

branch wrote:

rsmarples wrote:
Not sure what other functionality I can provide here.
None needed

YAY

This Open Source Warrior will sleep well knowing a job well done

krork · 2015-09-23 08:00:09

Thank you brave Open Source Warriors, this sheds light on the situation I will mark it as solved. A new day can begin.

Arch Linux

#1 2015-09-22 20:49:40

[SOLVED] Not requiring dhcp_server_identifier, Security hole?

#2 2015-09-22 21:19:11

Re: [SOLVED] Not requiring dhcp_server_identifier, Security hole?

#3 2015-09-22 21:55:15

Re: [SOLVED] Not requiring dhcp_server_identifier, Security hole?

#4 2015-09-22 22:05:13

Re: [SOLVED] Not requiring dhcp_server_identifier, Security hole?

#5 2015-09-22 22:55:14

Re: [SOLVED] Not requiring dhcp_server_identifier, Security hole?

#6 2015-09-23 01:12:33

Re: [SOLVED] Not requiring dhcp_server_identifier, Security hole?

#7 2015-09-23 01:41:12

Re: [SOLVED] Not requiring dhcp_server_identifier, Security hole?

#8 2015-09-23 01:52:08

Re: [SOLVED] Not requiring dhcp_server_identifier, Security hole?

#9 2015-09-23 08:00:09

Re: [SOLVED] Not requiring dhcp_server_identifier, Security hole?

Board footer