Some of you might think I’m in need of some mental help when you read this blog about switches in a security forum. That’s okay. Don’t worry. I know that…
When I started my career in ICT, networking was rather simple. You had Ethernet coax cables, repeaters, and some hubs. As long as you didn’t forget a “terminator,” your L2 network was fine. There was no need to configure a lot for layer 2. So the focus was on routers and servers. And in some networks, you would see firewall instead of packet filters on the routers.
A lot has changed since then. No company in its right mind would connect to the Internet without a firewall–of course with that firewall preferably being an SRX. Routing is done and looked at carefully. WebApp Secure and DDoS Secure are implemented. But what about the switches?
Quite often, the switch is configured with VLANs and some inter-VLAN routing, but not much more. A leftover from the early networking days, I think. Or, when security is needed on layer 2, a quick step is made to 802.1x. But there is a lot between “nothing” and 802.1x offered at the switch level!
The idea for this blog came to me after a reseller asked me to help him in designing a network for a small student campus. About 120 rooms needed to be connected to the Internet using 1G copper cabling in the building. Students were only to be able to connect to the Internet and definitely not to each other. And only about four or five devices per connection were to be accepted. (As if students know nothing about natting and private networks behind a single DHCP address).
Configuring Switches for Security
The initial question was: How to configure 120 subnets as easy as possible on an SRX? After some discussion, we came to an entirely different solution. We thought: What about the security features of a switch?
Let’s take a quick look at the port security toolkit of an EX switch. In our case, we went for a virtual chassis of EX3300 switches and an SRX 240 for the Internet connection.
- DHCP snooping. Monitor DHCP traffic and build a database of MAC/IP addresses.
- Dynamic Arp inspection. Only accept arp requests on a switch port if the MAC/IP combination matches an entry in the DHCP snooping database
- IP source guard checks of every packet against the DHCP snooping database
- MAC learn limiting. Limit the amount of Ethernet addresses you want to learn on a port.
- MAC move limit. This will limit the possibility of connecting to different ports on a switch in a short period of time.
Further, we looked at another nice security feature of switches: private VLANs. This is a great feature security-wise. A device connected to a private VLAN cannot communicate with other devices, except the default gateway when you configure things the right way.
So looking at it, we thought we’d do it quite simply.
Configure privates VLANs for every port in the virtual chassis. Configure MAC learning limit on the ports to the student. Configure one big DHCP scope on the SRX. And make sure with IP source guard that no one would mess anything up with static configured IP addresses. And last, but not least: an auto recovery from a violation to reduce management efforts.
After we configured the devices, the switch config was extremely small given what it does. The SRX is just allowing all outbound traffic with source nat while blocking inbound traffic and acting as a DHCP server for the students.
The Switch Itself
So the switch itself. Let me show you what we did there:
Configuring the access ports:
interface-range std-poorten {
member-range ge-0/0/0 to ge-0/0/46;
member-range ge-1/0/0 to ge-1/0/46;
member-range ge-2/0/0 to ge-2/0/22;
unit 0 {
family ethernet-switching {
vlan {
members std;
}
}
}
}
Configuring the VLAN for the student with isolation (private VLAN):
vlans {
std {
vlan-id 200;
no-local-switching;
}
}
And the Mac limiting DHCP snooping and IP source guard:
ethernet-switching-options {
secure-access-port {
interface std-poorten {
mac-limit 5;
}
vlan std {
examine-dhcp;
ip-source-guard;
}
}
nonstop-bridging;
port-error-disable {
disable-timeout 300;
}
}
As you can see, configuring these security features isn’t difficult. You just have to realize they’re there and then put them to good use! To me, it’s clear that a layer 2 network should never be taken for granted, but should be configured to meet the given requirements. It’s also clear that it’s worth taking the time to learn about all features and actually put them to good use.
