Hi James,
On 6 Feb 2016, at 11:36 AM, James Harper <mailto:james@ejbdigital.com.au> wrote:
The ‘pxe’ package under debian appears only able to run on the proxy dhcp port 4011, which I don’t want or need because my PXE server is not running on the > same server as the DHCP server. I think that’s just a permissions issue but I was hoping for something that “just worked” out of the box. Any suggestions?
Your router had to support the option 60. It cannot be done separately.
The option 60 tells the client the ip and path to you tftp server.
That is incorrect. You can have a regular DHCP server, and then have the boot options supplied by the PXE server (Microsoft's WDS does this). The communication goes (very approximately) like: Client: Give me the info I need to boot DHCP Server: Here is an IP address, subnet mask, DNS Server, gateway, etc PXE Server: Here is your tftp server and path It is possible to run PXE on the same server as the DHCP server, but it's a bit hacky. In this case the DHCP server sets option 60 that tells the client to do another DHCP request on port 4011, so it doesn't try to use the standard DHCP port. (http://www.experts-exchange.com/articles/2978/PXEClient-dhcp-option-60-what-...) You can still do it the old fashioned way and just set next-server and path on the DHCP server, which would work but my DHCP server is in the router and doesn't support this. Thanks James
James Harper via luv-main writes:
Your router had to support the option 60. It cannot be done separately. The option 60 tells the client the ip and path to you tftp server.
That is incorrect. You can have a regular DHCP server, and then have the boot options supplied by the PXE server (Microsoft's WDS does this). The communication goes (very approximately) like:
Client: Give me the info I need to boot DHCP Server: Here is an IP address, subnet mask, DNS Server, gateway, etc PXE Server: Here is your tftp server and path
It is possible to run PXE on the same server as the DHCP server, but it's a bit hacky. In this case the DHCP server sets option 60 that tells the client to do another DHCP request on port 4011, so it doesn't try to use the standard DHCP port. (http://www.experts-exchange.com/articles/2978/PXEClient-dhcp-option-60-what-...)
You can still do it the old fashioned way and just set next-server and path on the DHCP server, which would work but my DHCP server is in the router and doesn't support this.
I don't understand how this works. Assuming the DHCP server can't be configured, i.e. it does not send 'next-server' (66) & 'filename' (67), how does the PXE server provide it? They write: | When using a PXEService, dhcp options 66 and 67 are sent to the PXE | clients by the PXE service itself, not by DHCP service. So the DHCP client does a DISCOVER, and the DHCP and PXE servers both reply with independent OFFERs, and the client somehow merges them together? <VERY CONFUSED> Can you share a .pcap of where this is happening? ...ah, never mind: https://en.wikipedia.org/wiki/Preboot_Execution_Environment#Integration It sounds like you're talking about this "proxyDHCP" thing, and "the client somehow merges them together" is right. YUK. PS: Just so we're all on the same page re DHCP options, https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol#DHCP_optio... | 60 Vendor class identifier minimum of 1 octet | 61 Client-identifier minimum of 2 octets | 66 TFTP server name minimum of 1 octet | 67 Bootfile name minimum of 1 octet
So the DHCP client does a DISCOVER, and the DHCP and PXE servers both reply with independent OFFERs, and the client somehow merges them together? <VERY CONFUSED>
Can you share a .pcap of where this is happening?
...ah, never mind:
https://en.wikipedia.org/wiki/Preboot_Execution_Environment#Integration
It sounds like you're talking about this "proxyDHCP" thing, and "the client somehow merges them together" is right. YUK.
That's exactly right, and it's actually really good. Your DHCP server can just focus on assigning addresses, and your PXE server(s) focus on looking things up in databases and assigning the right boot image etc. I can see why you'd be a bit "yuck" about it on a small scale though. I'm working on a project for doing streaming restores of Windows servers (PXE boot and the restore starts but you can use the server while you're restoring it), and actually wrote a tiny PXE server for it, so I know what I'm talking about here, I just wanted the same PXE setup for net booting my Linux servers and didn't know what tools to use. Dnsmasq is probably overkill, but does the job so I'll go with using that. Thanks to those who suggested that. Thanks James
James Harper wrote:
https://en.wikipedia.org/wiki/Preboot_Execution_Environment#Integration So the DHCP client does a DISCOVER, and the DHCP and PXE servers both reply with independent OFFERs, and the client somehow merges them together[ ... YUK.]
That's exactly right, and it's actually really good. Your DHCP server can just focus on assigning addresses, and your PXE server(s) focus on looking things up in databases and assigning the right boot image etc. I can see why you'd be a bit "yuck" about it on a small scale though.
I meant yuk more in the sense of: now the DHCP poisoner doesn't need to race with the legitimate DHCP server. As long as the legitimate DHCP server doesn't offer PXE, he can guarantee his own PXE rules will be used, every time. And the standard answer appears to be something like: if your threat model includes attackers with access to LAN, buy programmable switches and instruct them to discard DHCPOFFERs except from specific ports (and physically secure both the switches and the whitelisted ports).
participants (3)
-
James Harper -
Trent W. Buck -
trentbuck＠gmail.com