(I felt this message had enough operational relevance to post on this list. If any feels otherwise, please let me know.) After having experienced a rather malicious attack on our corporate network by someone running a rogue DHCP server, I'm wondering if there's any way to prevent this from happening again? The perpetrator basically managed to renumber most of an entire subnet (into an entirely different IP block) of our network, causing a major denail of service. I've read the RFC's and checked all the network reference books I can find, and none of them indicate any way to prevent this from happening again. Am I missing something here, or is it time to start writing RFC's? Thanks in advance. -- Nick Bastin - RBB Systems, Inc. The idea that Bill Gates has appeared like a knight in shining armour to lead all customers out of a mire of technological chaos neatly ignores the fact that it was he who, by peddling second-rate technology, led them into it in the first place. - Douglas Adams
Nicholas Bastin wrote:
(I felt this message had enough operational relevance to post on this list. If any feels otherwise, please let me know.)
After having experienced a rather malicious attack on our corporate network by someone running a rogue DHCP server, I'm wondering if there's any way to prevent this from happening again?
You don't specify whether this was a corporate network or a production (e.g. cable) network. The short answer (especially if a corporate network): get him fired, or worse. (I.e. take some sort of legal action). If a public, network, such as a cable modem system, that'd be fairly nasty...
The perpetrator basically managed to renumber most of an entire subnet (into an entirely different IP block) of our network, causing a major denail of service. I've read the RFC's and checked all the network reference books I can find, and none of them indicate any way to prevent this from happening again. Am I missing something here, or is it time to start writing RFC's? Thanks in advance.
Well, the problem that comes up, is how does the workstation figure out who to trust? The DHCP client basically knows nothing about the IP addressing of the network (which is why it's asking a DHCP server). It's not desirable to have it know anything, because that'd limit the ability to have your DHCP client be portable. The best thing about DHCP is the ability to plug into any LAN anywhere that supports DHCP, and be able to operate. There may well be some ways to authenticate a legitimate DHCP server from an illegitimate one, but discussion of that is probably off-topic for NANOG. I'd be happy to discuss the matter further off this list, or on an appropriate list, however, and would like to hear more details of the situation in your case. Dan -- ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranthnetworks.com
At 22:45 7/24/99 -0400, Daniel Senie wrote:
You don't specify whether this was a corporate network or a production (e.g. cable) network. The short answer (especially if a corporate network): get him fired, or worse. (I.e. take some sort of legal action). If a public, network, such as a cable modem system, that'd be fairly nasty...
Our cable modems have the option of directional port filtering. When we realized what a problem rogues could be, we very quickly filtered off traffic from the customer PC with destination port 68. Andrea. ************************************************** Andrea Di Lecce (416) 935-6485 Rogers@Home Network Operations 1 Mount Pleasant Road, Toronto, M4Y 2Y5 **************************************************
-----BEGIN PGP SIGNED MESSAGE-----
After having experienced a rather malicious attack on our corporate network by someone running a rogue DHCP server, I'm wondering if there's any way to prevent this from happening again?
Ask your ethernet switch/bridge or cablemodem vendor for a method of disabling non-ARP broadcasts from being received by client machines. You can then trust your switches to direct such requests only to anything you let receive broadcasts, which should only be trusted servers. Cisco's IRB bridging has "subscriber-policy" which roughly approximates this that I use for our DSL customers. I believe their higher-end switches can take layer-2 access-lists, which could be made to work similarly. Any protocol that relies on trusting the first server to reply to a broadcast is similiarly vulnerable. I'm not sure theres a way to secure the protocol itself if the client has zero knowledge of the network its on when it starts up, which is the point of DHCP. Note that disabling broadcasts may adversely affect some already-broken protocols, such as WINS or SMB. This might only prevent shares off of "client" machines from showing up in others' Network Neighborhood, but I can't say that I've tested it. Aaron Hopkins aaron@cyberverse.com Chief Technical Officer, Cyberverse Inc. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBN5qJmUfJWHAEvsjBAQHa/QP/TnuMtu17O2wn5F15fFITHdCUDOCLUqy1 4QyfzRLdyeNFQA5o5bSoPirP3DjgPb2s5l/0IgQjJDPPMehCnFNCQ7sFq/A3/+3I 3e7XsxASmHXDsxbQP490oPbKkfMEvtAXH9pYolwnfmuhxn/VPYXqOg4A1GomukBp PQlYBTOnSL0= =77jy -----END PGP SIGNATURE-----
WINS and SMB file sharing are not broadcast based. The name location mechanism in Windows networking is broadcast based, if you don't use WINS. WINS eliminates that need. Eric At 08:50 PM 7/24/99 -0700, Aaron Hopkins wrote:
-----BEGIN PGP SIGNED MESSAGE-----
After having experienced a rather malicious attack on our corporate
network by
someone running a rogue DHCP server, I'm wondering if there's any way to prevent this from happening again?
Ask your ethernet switch/bridge or cablemodem vendor for a method of disabling non-ARP broadcasts from being received by client machines. You can then trust your switches to direct such requests only to anything you let receive broadcasts, which should only be trusted servers.
Cisco's IRB bridging has "subscriber-policy" which roughly approximates this that I use for our DSL customers. I believe their higher-end switches can take layer-2 access-lists, which could be made to work similarly.
Any protocol that relies on trusting the first server to reply to a broadcast is similiarly vulnerable. I'm not sure theres a way to secure the protocol itself if the client has zero knowledge of the network its on when it starts up, which is the point of DHCP.
Note that disabling broadcasts may adversely affect some already-broken protocols, such as WINS or SMB. This might only prevent shares off of "client" machines from showing up in others' Network Neighborhood, but I can't say that I've tested it.
Aaron Hopkins aaron@cyberverse.com Chief Technical Officer, Cyberverse Inc.
-----BEGIN PGP SIGNATURE----- Version: 2.6.2
iQCVAwUBN5qJmUfJWHAEvsjBAQHa/QP/TnuMtu17O2wn5F15fFITHdCUDOCLUqy1 4QyfzRLdyeNFQA5o5bSoPirP3DjgPb2s5l/0IgQjJDPPMehCnFNCQ7sFq/A3/+3I 3e7XsxASmHXDsxbQP490oPbKkfMEvtAXH9pYolwnfmuhxn/VPYXqOg4A1GomukBp PQlYBTOnSL0= =77jy -----END PGP SIGNATURE-----
========================================================================== Eric Germann CCTec ekgermann@cctec.com Van Wert, OH 45891 http://www.cctec.com Ph: 419 968 2640 ICQ: 41927048 Fax: 419 968 2641 Network Design, Connectivity & System Integration Services A Microsoft Solution Provider
After having experienced a rather malicious attack on our corporate network by someone running a rogue DHCP server, I'm wondering if there's any way to prevent this from happening again? The perpetrator basically managed to renumber most of an entire subnet (into an entirely different IP block) of our network, causing a major denail of service. I've read the RFC's and checked all the network reference books I can find, and none of them indicate any way to prevent this from happening again. Am I missing something here, or is it time to start writing RFC's? Thanks in advance.
In a cable modem environment, we make use of packet filtering to prevent any cable modem user from responding to DHCP requests. Customer cable modems can act as a clients for such requests, but not as servers. In other environments, we essentially use the same tactic; we partition the network so that valid servers are on controlled segments, and only allow DHCP servers on those segments. Right now, it seems we have the tools to authenticate and authorize DHCP with current RFCs. I would be very interested in hearing about potential attacks we have missed. regards, fletcher
I'd like to hear more about the filtering capabilities of the cable modems. Is there somewhere I could find the provider-oriented documentation (as opposed to the two-pager given to consumers with the modems)? I'd like to see if additional uses of this filtering could be made which would increase the user's security (e.g. filtering out ports 137-139 TCP and UDP to prevent neighbors from attacking neighbors), and that of the Internet (ingress filtering). I believe you're correct that sufficient tools exist today to protect DHCP in cable modem and switched Ethernet environments. I don't believe there's sufficient knowledge of that information spread around. As such, I was thinking of writing an informational RFC on the subject, and would be interested in having your input, especially from the cable modem plant angle. Interested? Dan -- ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranthnetworks.com
participants (7)
-
Aaron Hopkins -
Alex Bligh -
Andrea Di Lecce -
Daniel Senie -
Eric Germann -
Fletcher E Kittredge -
Nicholas Bastin