The premiere source of truth powering network automation. Open and extensible, trusted by thousands.
NetBox is now available as a managed cloud solution! Stop worrying about your tooling and get back to building networks.
Contest lessons in security
By stretch | Saturday, January 10, 2009 at 12:00 a.m. UTC
With the third Packet Life contest wrapped up I wanted to take a moment to point out what I hope a number of people noticed independently, if subconsciously. Each contest over the past several months was designed to carry some sort of lesson in security which I'll discuss here.
The first contest challenged participants to identify the access VLAN of the switch port from which the capture was taken. The solution showed how the VLAN ID could be derived from an 802.1t-format spanning tree bridge ID. While this is a novel demonstration, it could present an issue if the integrity of your network design assumes that a malicious attacker won't know what VLAN he is on.
The second contest follows the same vein, illustrating how implementing secured OSPF adjacencies can actually expose the system time configured on a router. While this may seem benign, such information leakage could prove beneficial to an attacker. For example, if I encounter a router whose clock is set to May 14, 2002, I might deduce that a) NTP is not in use and b) the router has been up for 75 days (counting from 1 March 2002, the default date for many IOS versions). It might also be handy to know exactly what time a router thinks it is to assist in certain cryptographic attacks.
And finally, the most recent contest demonstrates how a network can be compromised by the weakest link in its chain of security measures. We saw how, despite the strong authentication and privacy provided by SNMPv3, it's easily negated if the credentials it uses can be gleaned from an insecure protocol like Telnet.
Admittedly, the scenarios in these contest are pretty obscure (if they weren't, what fun would the contests be?). Instead of expecting people to remember the intricacies presented in these specific illustrations, I intended to highlight these abstract points:
- Information leaks are everywhere; assume an attacker knows your network well.
- Securing one entity may expose another to exploitation or unavailability.
- To borrow a cliché, you are only as strong as your weakest link.
Suggestions for the next theme are welcome.
Posted in Security
Comments
January 10, 2009 at 1:19 a.m. UTC
These contests and the explanations are great. Keep them coming.
January 10, 2009 at 10:48 a.m. UTC
How about a forensic analysis for your next contest? Assuming the role of the victim rather than the attacker.
January 10, 2009 at 7:34 p.m. UTC
Still security related I know, but a contest involving VoIP Security would be interesting. Perhaps decoding a packet capture into a Wav file? Or multiple Wav files that need to be pieced to together to find the the information?
Wireless hacking perhaps?
How about, a GNS3 lab that is broken and needs fixing? The submitted answer would be the configs of the routers involved, with a limitation on the commands that we are allowed to use?
Or, a 'hackthissite' type contest?
January 11, 2009 at 8:06 a.m. UTC
While I agree with MattG that doing ethical hacking for network security is a good suggestion; I really appreciate this approach of showing potential security 'holes' as it were, or information leaks in this 'stock network' setup that a lot of people may make the mistake of doing without realising.
It demonstrates the need to harden or add that extra layer of security. Though, aside from some obvious solutions such as 'do not use telnet' or use it in a different manner, thinking up solutions and presenting them for these 'information leaks' would be interesting to see.
January 11, 2009 at 11:54 a.m. UTC
Security contests are gr8, Like last contest of packet caputring clearly shows that how easy to crack SNMPv3 encrypted packet on telnet session.
January 12, 2009 at 10:16 a.m. UTC
The problem with telnet i think is not that someone can "see" what you are configuring but more that someone can steal your credentials and after that use them to access the router ( even with access-list for access it can be done via spoofing etc )