SANS ISC: SANS Internet Storm Center

• SANS Site Network
  • Current Site
  • SANS Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • DFIR
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

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: 

• Default passwords - change the default passwords on the device, all of them, not just the one on the account being used.  A number of switches have multiple built in accounts, some of which are easily forgotten.
• SNMP v3 - if the device supports it used it, otherwise use a nice long comunity string, just be aware that it will be compromised and at least read access to the device will be gained.
• Logging - Use centralised logging of switch activities.
• AAA - Create a management group in AD, place those that need access to the devices in the group and then use Radius to authenticate users.  This does make access as good as the password used by staff, but you can also use tokens to authenticate. Shouldn't be much of a problem as people generally don't need to log into switches anyway.
• Backup userid/password - if using AAA authentication make sure you have a local userid or password that can be used in case the radius servers aren't available.
• Management VLAN - Many switches support a management VLAN so configure it and then use ACL to control access to this VLAN.  This just takes the management function of the main network and makes life harder for the pentester.
• Network Segmentation - Set up VLANs to segregate your network segments, then use ACLs to control traffic flows between them (Note: use with care as this is easy to get wrong). Also for network segments of different security requirements such as a DMZ, use a different physical switch, don't just VLAN them off.
• Labeling of Ports - Not really a security measure as such, but many switches allow you to name ports.  This means that with a simple show command you can see which port is your uplink, downlink, etc. Comes in handy when the diagram is missing or out of date.  Of course this does mean that if someone compromises the device they know what to target.
• SSH /Telnet - Use SSH v2, disable telnet.
• Web interface - If you need it use SSL, otherwise disable it.  Unfortunately many switches still need you to mange the device using multiple interface as not all the functionality is available from every interface.
• TFTP - well if you really, really need it, but at least configure the location that is valid. 
• Management IPs - Many switches allow you to configure the management IP addresses for the device.  Configure these and you make life harder for attackers.

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