For many pentesters, myself included, switches and routers are a favourite target when performing internal assessments. Why ARP spoof devices on the network when you can configure mirroring ports and bring the traffic to you? Having control of the switching infrastructure is just plain fun and in more than 50% of the tests we do they are ours in short order. Badly configured switches and internal routers are almost as common as blank SA passwords on MSSQL databases (yes people do still have em). In Australia it is at the moment winter. Granted the winter temperature in Sydney is pretty much the same as it is in London in summer, but for us it is cold. Many Australians, including myself, grew up in the northern hemisphere and Christmas just isn't Christmas when the icecream melts faster than you can scoop. So we often have a Christmas in July. Find a cold spot (usually in the mountains where there is snow), get some friends together, fish, drink, cook a turkey and have a Christmas dinner. Including, sometimes, presents. My present this July was to put together a network for one of our clients. :-) I asked, they bought and I configured. Moving to a new datacentre and new premises is just great for getting it right (well, so far) from the start. So it got me thinking about hardening the networking devices so the next pentester that comes on site does not have a free pass to the network. We still have some things to do, but I thought I'd share the few things that we have done so far and hopefully it will help you out, or you might be able to add to it. So here are some of the things we did to start with on the switches:
So these are some of the starting things to do. The next stage is port security, which is a whole different kettle of fish and for a different day. Document the hardening steps for your environment and implement a process to make sure that the configurations do not change without approval. There are a number of tools around that will download the configuration from the switch and perform a comparison with a previous version (make sure you protect these of course). Another thing to consider is to regularly dump the mac address tables on each of the devices so you can trace which device was connected to which switch. It allows you to identify devices on the network. Something like Nedi or Netdisco (you may know others) will do this for you, it places the info in a database and allows you to find any network device and which switch port it is plugged into. Very handy when you need to chase down a device. If you have some hints on hardening your switches (we'll leave routers for another day), let me know and I'll update this diary with your additions. Happy hardening. Couple of updates Port Security - 802.1x port security may be a bit much for you, but you can still do a few things on most switches, such as preventing ports from learning more than 1 mac address, assigning mac addresses to ports. Dynamic VLAN - Allocate the VLAN dynamically and if the user doesn't match place them on a holding VLAN. NTP - I had logging and in my head that included time synchronisation, but someone pointed out that it would be better to spell it out Monitoring - Ports that receive 10x the usual traffic may need a closer look If using CISCO there are a swag of other things you can/need to do. there is a link in the comments to the NSA guide which is very comprehensive. Many of the things also apply to other vendor devices. Thanks for sending in your suggestions. There were a number of other good suggestions, but either product specific, leaning more towards routers or general security management so I left them out for the moment. Mark H - Shearwater
|
Mark 392 Posts ISC Handler Aug 4th 2009 |
Thread locked Subscribe |
Aug 4th 2009 1 decade ago |
I would also suggest a good reading:
http://www.amazon.com/LAN-Switch-Security-Networking-Technology/dp/1587052563 (Take a look to the reviews where you'll find some known security guys) |
vmforno 8 Posts |
Quote |
Aug 3rd 2009 1 decade ago |
Remember to update the firmware before you finish implementing that new switch! If the switch has the ability to lock down the port or MAC address for your DHCP server, use it.
|
Andrew 41 Posts |
Quote |
Aug 3rd 2009 1 decade ago |
The NSA has good switch and router guides. The switch guide can be found at http://www.nsa.gov/ia/_files/switches/switch-guide-version1_01.pdf
|
Andrew 1 Posts |
Quote |
Aug 3rd 2009 1 decade ago |
I do on-site and remote penetration testing on a weekly basis, visiting financial organizations from coast to coast. Network-based attacks account for at least half of the vulnerabilities that I identify regularly. I believe that this really comes down to what auditors require and how people educate themselves accordingly. FDIC/GLBA/FFIEC regulations require in depth patch management, log monitoring, IPS/IDS devices, etc, yet don't mention much at all about network-based attacks. Subsequently the IT directors for these financial institutions spend their resources becoming proficient in these types of technologies (patch management, logging, etc).
Education is the only way to fix these problems but until people are required to understand the problems through regulations I don't think it will happen. |
Andrew 1 Posts |
Quote |
Aug 4th 2009 1 decade ago |
I have made it a habit to never use username/passwords on SSH, a 4096bit key is harder to guess.
Generally avoid passwords if you can and use public key. Provide a good map of the network to make sure that the next guy can understand why things were done this way. |
Sten 4 Posts |
Quote |
Aug 8th 2009 1 decade ago |
Sign Up for Free or Log In to start participating in the conversation!