Content deleted Content added
→Operation: In Ethernet the destination MAC comes first. |
BrainStack (talk | contribs) Link suggestions feature: 3 links added. |
||
Line 49:
===Discovery===
The DHCP client [[Broadcasting (networking)|broadcasts]] a DHCPDISCOVER message on the network subnet using the destination address {{IPaddr|255.255.255.255}} (limited broadcast) or the specific subnet [[broadcast address]] (directed broadcast). A DHCP client may also request an IP address in the DHCPDISCOVER, which the server may take into account when selecting an address to offer.
For example, if HTYPE is set to 1, to specify that the medium used is [[Ethernet]], HLEN is set to 6 because an Ethernet address (MAC address) is 6 octets long. The CHADDR is set to the MAC address used by the client. Some options are set as well.
Line 481:
====Client vendor identification====
An option exists to identify the vendor and functionality of a DHCP client. The information is a [[Variable-length code|variable-length string]] of characters or octets which has a meaning specified by the vendor of the DHCP client. One method by which a DHCP client can communicate to the server that it is using a certain type of hardware or [[firmware]] is to set a value in its DHCP requests called the Vendor Class Identifier (VCI) (Option 60).
The value to which this option is set gives the DHCP server a hint about any required extra information that this client needs in a DHCP response. Some types of [[set-top boxes]] set the VCI to inform the DHCP server about the hardware type and functionality of the device. An [[Aruba Networks|Aruba]] campus [[wireless access point]], for example, supplies value 'ArubaAP' as option 60 in its DHCPDISCOVER message.<ref name="option60">{{cite web|title=Aruba DHCP Option 60|date=7 October 2020 |url=https://the-ethernets.com/2020/10/aruba-dhcp-option-60/}}</ref> The DHCP server can then augment its DHCPOFFER with an IP address of an Aruba [[wireless controller]] in option 43, so the access point knows where to register itself.
Line 596:
* Resource exhaustion attacks from malicious DHCP clients.
Because the client has no way to validate the identity of a DHCP server, unauthorized DHCP servers (commonly called "[[rogue DHCP]]") can be operated on networks, providing incorrect information to DHCP clients.<ref name="Stapko2011"/> This can serve either as a [[denial-of-service attack]], preventing the client from gaining access to network connectivity,<ref name="Rountree2013">{{cite book |first= Derrick |last=Rountree |title = Windows 2012 Server Network Security: Securing Your Windows Network Systems and Infrastructure |url = https://books.google.com/books?id=NFzou_d4MGUC&pg=SA2-PA13 |year = 2013 |publisher = Newnes |isbn = 978-1-59749-965-1 |page = 22 }}</ref> or as a [[man-in-the-middle attack]].<ref name="Rooney2011">{{cite book |first= Timothy |last=Rooney |title = Introduction to IP Address Management |url = https://books.google.com/books?id=QgRDxkuI1MkC&pg=PA180 |year = 2010 |publisher = John Wiley & Sons |isbn = 978-1-118-07380-3 |page = 180 }}</ref> Because the DHCP server provides the DHCP client with server IP addresses, such as the IP address of one or more DNS servers,{{Ref RFC|2131}}{{rp|sec. 7}} an attacker can convince a DHCP client to do its DNS lookups through its own DNS server, and can therefore provide its own answers to DNS queries from the client.<ref name="DNSRedirect">{{cite web |url = http://www.securelist.com/en/blog/208188095/TDSS_loader_now_got_legs |title = TDSS loader now got "legs" |first= Sergey |last=Golovanov (Kaspersky Labs) |date = June 2011 | archive-url=https://web.archive.org/web/20210125194521/https://securelist.com/tdss-loader-now-got-legs/30844/| archive-date=25 January 2021}}</ref> This in turn allows the attacker to redirect network traffic through itself, allowing it to eavesdrop on connections between the client and network servers it contacts, or to simply replace those network servers with its own.<ref name="DNSRedirect" />
Because the DHCP server has no secure mechanism for authenticating the client, clients can gain unauthorized access to IP addresses by presenting credentials, such as client identifiers, that belong to other DHCP clients.<ref name="Stapko2011"/> This also allows DHCP clients to exhaust the DHCP server's store of IP addresses—by presenting new credentials each time it asks for an address, the client can consume all the available IP addresses on a particular network link, preventing other DHCP clients from getting service.<ref name="Stapko2011">{{cite book |first= Timothy |last=Stapko |title = Practical Embedded Security: Building Secure Resource-Constrained Systems |url = https://books.google.com/books?id=Mly55VntuYMC&pg=PA39 |year = 2011 |publisher = Newnes |isbn = 978-0-08-055131-9 |page = 39 }}</ref>
| |||