Chances are that you have very smart switches in your corporate environment, but only use them for a small portion of their capability to do some VLANs or so.
So some tips of what switches can do for you on the security side of things with a little reconfiguration.
You will notice that most of these will require a managed switch port per host, so combine them together to get to this.
Private VLANsPrivate VLANs can be used to stop certain ports to talk among themselves. Now where would such a thing be a good thing (TM)?
Think of your DMZs: would it be good if your email gateway cannot talk to your public webserver, while still sitting in the same network ? Sure, it would mean that if somebody finds a vulnerability in your SMTP server they cannot escalate their tools towards your webserver and from there e.g. move towards your database back-end.
Another environment where this can do wonders is a internal LAN: do clients have any business need to talk to other clients ? Or do they just need to talk to default routers and servers? Worms can run rampant inside an Internal LAN, but if the machines cannot exchange packets, there is little to propagate over. Imagine running such a network and having 5 employees clicking on an email worm and only having to clean up 5 workstations (while it was network aware and would have taken out your network).
Limit the number of MACs per portTeaching switch ports to shutdown when they learn more than one MAC address is not only an obvious way to stop rogue hubs, to stop flooding mac stables, but it teaches the users that the network and its policies is something to be taken serious.
If they have policies that deny them to mess with the network and the network shuts down when they do it anyway, you force them into turning themselves in... . Even if you can be less strict for the first problem, they learn the lesson not to mess very fast.
Manage unknown MAC addressesIf you keep a good inventory of what MAC addresses are known good (It's not that hard to do it, really all you need is entry, replacement and exit processes for machines or network parts), you can decide what to do if a switch learns an unauthorized MAC address:
Limit trafficMany switches understand traffic and can actually filter it, interesting things to limit are the ability to answer on requests such as DHCP, except for your official DHCP servers. It helps to avoid the problems with rogue DHCP servers racing to hand configuration to your clients.
Monitor traffic.Check traffic statistics on ports using commercial setups or simply with "rrd", can often detect anomalies long before anybody has analyzed the malware and or written signatures for it. Moreover you can trace it back to physical ports and physical machines that you can go and collect, no matter what clever hiding the bad guys tried to do.
Shutdown unused portsShutting down unused ports keeps the ability to add rogue machines much lower and allows for enforcing processes that require a consious action on the network to enable the machines to use it.
VLANs vs. airgapsVLANs are easy to configure and many network engineers just love them, but in high security environments, keep in mind that an airgap using real air is fundamentally more secure than one using logic in a switch. Also you might find that small switches, even managed ones that can do all on this page, aren't all that expensive to use in e.g. a DMZ.
Manage the switches, keep them secureA bit obvious perhaps, but SNMP v1/2 community strings are basically passwords and "public" and "private" are real bad choices. Go for v3 if you can. And if you do not use SNMP, turn it off.
Web based management might be appealing at first, but take great care with it. Using a separate VLAN to manage the switches is common good practice. So is not using protocols like telnet but relying on ssh instead. VLAN multiplexing such as 802.1q should only be done towards other switches under the same management, not towards hosts not absolutely needing this ...
Follow up on vulnerabilities for the vendor and plan the updates accordingly.
Swa Frantzen -- Section 66
Aug 11th 2006
Aug 11th 2006
1 decade ago