Get this Security+ CertiGuide for your own computer.
Click Here!
Use coupon code "certiguide" to save 20%!
(Expires 2004/12/31)

Also available: 300-question Security+ practice test!
Get It Here!

Custom Search







Table Of Contents  CertiGuide to Security+
 9  Chapter 3:  Infrastructure Security (Domain 3.0; 20%)
      9  3.5  Security Baselines
           9  3.5.3  Application Hardening

Previous Topic/Section
3.5.3.7  File/Print Servers
Previous Page
Pages in Current Topic/Section
1
Next Page
3.5.3.9  Data Repositories
Next Topic/Section

3.5.3.8  DHCP Servers

Dynamic Host Configuration Protocol (DHCP) servers are used to assign and distribute host configuration information to clients who request it. Each DHCP server is configured by the organization with data including ranges of addresses it can hand out (possibly including some “static” IP addresses that are always assigned when a host with a particular MAC address makes a request), and configuration information such as the gateway out of the network, the DNS server, etc.

DHCP

Dynamic Host Configuration Protocol (DHCP) servers assign and distribute host configuration information to clients who request it. Information assigned can include IP address, network gateway, and other configuration information..


DHCP Security Issues

Since DHCP servers don’t require authentication of either client or server, they are vulnerable to exploits by attackers. For example, any client can request a network address – if enough spurious requests are aimed at a DHCP server, its pool of available addresses can be exhausted, depriving legitimate users of access to the network. Therefore, it is recommended that your DHCP server be configured to hand out addresses only to those hosts that are “known” to you (for example, those hosts whose MAC addresses appear in a file on your DHCP server).

On the other side, anyone can run their own DHCP server on a network, and if that server is faster at responding to DHCP queries than the “real”, authorized server, clients will accept the data from the rogue DHCP server. Among the problems this can lead to is the rogue DHCP server providing incorrect DNS nameserver addresses, which might allow the attacker to redirect traffic originating at that client, and destined for legitimate sites, to other sites, by “faking” bogus DNS information for the legitimate site. Therefore, it is recommended that DNS information be configured statically on each client rather than provided by the DHCP server.

DHCP Vulnerabilities

Possible attacks on DHCP servers include DoS and spoofing. Spoofing can enable an attacker to provide bogus DNS server information to clients, causing more trouble by directing clients to bogus sites that masquerade as common sites such as amazon.com (possibly leading to identity theft or credit card fraud, etc).

Because of the DNS risk, it is recommended that you not hand out DNS information via DHCP, but instead configure static DNS information on each client.


[spacer]DHCP Issues

The industry has somewhat addressed the problem of rogue DHCP servers, but alas, the solutions provide a bit of a false sense of security. For example, when using the DHCP server capability provided by Microsoft Windows 2000, a DHCP server must be “authorized” by an administrative user before it can accept requests for IP addresses. This helps keep Joe newbie admin from installing a machine and setting it up as a DHCP server, without realizing the impact it might have on network connectivity to do so. However, understand that it does nothing to prevent someone from obtaining a freeware DHCP server from another source and installing it on a Windows Server, in order to run an “unauthorized” DHCP server handing out whatever information he or she wishes.


On the bright side, attacks against DHCP servers tend to be limited to the local network, because DHCP requests are made as network “broadcasts” which typically do not get passed out of a subnet. If your DHCP server is on a different subnet from the hosts, you must configure your router to use the “BOOTP relay” protocol378 (via UDP port 67) to allow the DHCP requests to cross the subnet boundary. When doing this, exercise care so that you do not allow more clients access to the DHCP server, than is absolutely required.

BOOTP Relays

When using BOOTP relay functionality to distribute DHCP information across a router boundary, the router should allow communication via UDP port 67.



 __________________

378. http://www.ietf.org/rfc/rfc1542.txt

Previous Topic/Section
3.5.3.7  File/Print Servers
Previous Page
Pages in Current Topic/Section
1
Next Page
3.5.3.9  Data Repositories
Next Topic/Section

If you find CertiGuide.com useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider buying an inexpensive PDF equivalent of the CertiGuide to Security+ from StudyExam4Less.com. (Use coupon code "certiguide" by December 31, 2004 to save 20%!) Thanks for your support!
Donate $2
Donate $5
Donate $10
Donate $20
Donate $30
Donate: $



Home - Table Of Contents - Contact Us

CertiGuide for Security+ (http://www.CertiGuide.com/secplus/) on CertiGuide.com
Version 1.0 - Version Date: November 15, 2004

Adapted with permission from a work created by Tcat Houser et al.
CertiGuide.com Version Copyright 2004 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.