>For the past two to three weeks, I’ve been testing out an EX4200 switch on loan to us from Juniper. It’s been pretty damn sweet – that thing has a lot of really great monitoring and prevention features.
One thing that’s been kicking my ass, though, is setting up the switch to do NAC using 802.1X. It’s been a combination of things, really: the learning curve is for the EX4200 (minimal as it is), the RADIUS implementation on Windows 2008 (IAS doesn’t exist anymore; it’s now NPS), incompatible packet formats… All in all, I’ve had configuration woes.
So here’s an attempt at turning this frown upside-down. I’m writing myself a guideline from scratch, in hopes that it’ll help me get it right! Writing’s good for that; to me, there’s no better cure for confusion than having to explain it to someone else.
Here’s a suggestion of the equipment you should use to get this right:
- A good amount of room and light – you’re going to be hosting a lot of crap for what could be many days
- 1 x power outlet, 1 x multi-plug. The multi-plug should have 5 plugs minimum, 7 plugs to be comfortable, and would preferably have an on-off switch. Make sure they’re grounded! Blowing up expensive switches is ill-advised, and might get you in trouble with your Finance department.
- 1 x Juniper EX4200 switch (or equivalent). Should come with a serial cable.
- 3 CAT5 cables or equivalent (ethernet, not crossover; if you don’t know the difference, you might want to consider finding that out first… :-D)
- 1 x linux workstation with a serial port, gtkterm, wireshark and a hypervisor (VirtualBox is free, easy, and yields good performance)
- 1 x linux VM. radiusd will be installed on it
- 1 x windows 2008 VM. Certificate services will be installed on it (optional)
- 1 x linux workstation, with the FreeRADIUS client utilities (freeradius-utils package in ubuntu) installed.
- 1 x Windows XP workstation (or Windows 7, if you prefer. For Pete’s sake, don’t talk to me about Vista)
- 1 x laptop (or tablet) with wireless access to the ‘net – for note-taking and frequent research
- There are two buttons on the front panel of the switch – one to switch options (the menu button), and one to enter options (the enter button). Hit the menu button until you get to the Maintenance Menu, then press the enter button
- Within the maintenance menu, hit the menu button until you get to Reset Factory Settings, then press the enter button
- Press the enter button to confirm; the switch will display a message indicating that it’s resetting everything to factory settings.
- Press the menu button until you get to Maintenance Menu, then press enter
- Press the menu button until you get to EZSetup, then press enter
- Plug your admin workstation into the first port of the switch in the front panel (port 0) – note that this differs on other models
- The manual suggests that the switch will automatically attribute an IP addy to your workstation via DHCP – that’s a bunch of hooey. You’ll need to configure a static IP address. By default, the network setup for the switch is 192.168.1.0/24, so you’ll probably want to attribute 192.168.1.2 to your admin box.
- Open a browser window to 192.168.1.1 and follow the initial setup instructions. If you follow the default options, you generally set up a default management VLAN of 0, and opt for in-band management. This works fine for simple configs – adapt your approach to your infrastructure if this isn’t the case, obviously.
- Via the web interface, you can assign MAC addresses to different ports via the Port Security section. You can also ‘trust DHCP’; didn’t get to play with that but presumably, you’d be able to initialize your switch by ticking this option, and then un-ticking it afterwards. (Note, of course, that MAC address filtering is not the safest option for NAC, since it is possible to spoof a MAC address. However, it will prevent your users from plugging in their personal computers and potentially infecting the entire campus with a worm…)
- You can set up port mirroring on multiple ports, allowing you to perform specific analyses or even to ‘load balance’ your traffic sniffing.
- Ever gotten an ARPwatch alert and not known where the hell a rogue computer’s connecting from? The J-Web interface allows you to see the switching table information; you can therefore see what port a rogue MAC address is on.
- You apply 802.1X at the port level. This is to say that some of the ports of your switch can have 802.1X enabled, and some not. At first I thought, “crap – if I have to apply it to each port one by one, it’s going to take hours.” Not so: you can select multiple ports at the same time and enable 802.1X to your selection.
- You apply 802.1X by “Setting the 802.1X profile”. You disable it by selecting one or many ports and clicking on “Delete”. Search me why they didn’t use a consistent vocabulary – but hey, it works.
- Before you can set the 802.1X profile, you have to set the port’s role. This is analogous to Cisco’s smart ports; you essentially set up a profile for the device to which the port is connected. You can define your own, but there are a few pre-defined roles such as ‘default’, ‘desktop’, ‘switch’ or ‘phone’. If you don’t apply a port role, you simply can’t set the profile. Addendum: you can leave the RADIUS server’s role to none or default.
- How does 802.1X work? God, I’ve read a gazillion definitions, some very academic, others very high-level; and quite frankly, I’ve found that all of them lack either clarity or detail. I finally found a decent overview in the following excerpt, which I’ve taken from an Avaya support article (click here for the full document). I’ll admit that the wikipedia section on the authentication progression helped, as well. If anyone out there has a better definition than the one below, please let me know:
At this point, you’re pretty much ready to attack the ‘hard part’ of the problem, which is getting the authenticator (switch), supplicant (workstation) and the authentication server (RADIUS box).
- Install RADIUS: sudo apt-get install freeradius
- Navigate to the /etc/freeradius directory (you’ll need to be logged in as root to do this)
- Edit the users file; add a user with only the Cleartext-Password attribute set (there should be examples of this in the file)
- Edit the clients file; set the RADIUS secret of the localhost (eventually, we’ll have to specify one for the juniper switch)
- Restart freeradius: /etc/init.d/freeradius restart
- Test freeradius: radtest <user> <password> localhost 10 <secret>
- If you have trouble connecting, I suggest you stop freeradius, then start it with -X. Consult this link for more information on debugging: http://wiki.freeradius.org/Basic_configuration_HOWTO
Note: stupidly, I had added a user to the users file with the same name as a user in my passwd file. By default, freeradius does have PAP enabled, and it does have priority over the users file.
- Log onto the J-Web interface
- Go to the Configuration tab
- Go to the 802.1X section
- Click on the RADIUS Servers button toward the top right of the page, and add a new server. The terminology is a bit confusing here, so make sure that you put the RADIUS server IP in the destination address field, and the swtich IP in the source address field. Also, make sure you specify the correct port (1812). You’ll need to fill all the fields – the switch will happily take blanks but I’m pretty sure it mucks up the transmission.
Also remember that in this case, the only machine that will be directly communicating with the RADIUS server is the juniper switch. A common mistake is to think that all hosts will need an entry in the clients file of freeradius – in fact, the only device that does is the juniper switch.
You want to start by making sure that your XP box can connect without the additional mumbo jumbo – without preemptively setting any 802.1X profiles for the port, plug your XP machine in and ping the switch (presumably, you’re going to have to set up a static IP address before you’re able to connect). You should proceed only if you’re able to hit the switch successfully at this point; at the risk of stating the obvious, your workstation isn’t going to automagically fix itself once you’ve got the whole thing configured.
Next, you should make sure that your XP box is running the necessary service to talk 802.1X to the client. Once upon a time (in pre-SP3 versions of XP), this meant starting the Wireless Zero config service – which, you know, makes oh-so-much sense when you’re trying to set up a wired connection. As of SP3, the service you’re looking for is Wired AutoConfig – make sure it’s set to Automatic startup and is, in fact, started now. Navigate to Network Connections (Start > Settings > Network Connections), right-click on the wired NIC and hit Properties. You should see at least three tabs, one of which is ‘Authentication’; if you don’t see the Authentication tab, re-read the beginning of this paragraph and slap yourself on the wrist – you’re skipping steps.
In the Authentication tab, enable 802.1X authentication, set it to use Protected EAP, and hit the Settings button. Disable validation of the server cert (though you’re obviously going to want to revisit that one later to be safer), and set your authentication method to be MD5. Click on Configure and make sure that your machine isn’t using your windows creds to authenticate, though this may be the case later. Finally, make sure that Fast Reconnect is enabled and the two other options are disabled (once again – you’re going to have to revisit that later), and hit OK. Note that you should still be able to ping the switch; what we’ve done is configure an additional layer which is only used if it is needed. This is practical if a lot of your users have laptops.
This should be a decent config for now – very simple, starting easy. I find that it’s easier to start simple and work toward the more complicated configs incrementally; it reduces chances of getting a composite problem that isn’t easily fixed with the flick of a switch.
Returning where we left off in step 3, we’re now going to assign an 802.1X profile to the port on which your XP box is connected. Return to the J-Web interface, and navigate to Configure > Security > 802.1X. Click on your XP box port, then click Edit > Apply 802.1X profile. That will enable 802.1X security on the port. Note that you can select as many ports as you like and apply 802.1X to them in bulk.
Look at your XP box, now: you should get a bubble appearing over your network connection, indicating that you have to specify additional information to connect. If you click on it, you’re prompted for a user name and password. Great success! You’ve just set up RADIUS authentication.
Now that you’ve configured 802.1X on your wired network, you’re probably thinking “great, so now that’s done. Whatever happens, I don’t have to worry about network access control ever again.” Right?
You’re just getting started. This is pretty much the tip of the iceberg – iteration one of dozens, if not hundreds, of iterations to get your systems secure. Let me show you what I’m talking about:
Your RADIUS server
Right now, your RADIUS server is sitting on your switch happily answering auth requests. You need to think about locking that baby down; for one thing, it should only accept requests from the switch – this can and should be done using ACL’s on the juniper and on the RADIUS box.
You should at least be logging failed requests: there aren’t a gazillion reasons why those should be occuring. Someone on your team might be (re)configuring a workstation; or maybe an end-user is trying something he/she shouldn’t be doing, like hooking up a personal device to the network or messing with the network config. Maybe someone’s trying to brute-force the connection… Use your imagination.
Monitoring’s nice, alerting is better. What system are you going to be using? How are your alerts delivered? Be sure to use the appropriate monitoring tool, make sure you’re not leaking information or generating unnecessary traffic, and spend time testing and pruning the data your system is generating. Data is not information if there’s too much shit to read! You want as little false positives as possible (don’t we all…) – so think about what scenarios you should truly be following up on and cut down on the noise.
Encryption and validation
What we’ve configured up above is insecure:
- Packets are not encrypted
- Authentication is done via MD5 challenge – MD5 has some vulnerabilities (c.f. this paper).
- If you don’t choose a good RADIUS shared secret, it can be crackable. In fact, RADIUS itself does possess a number of vulnerabilities (c.f. Joshua Hill’s article on untruth.org) which, if you’re not careful, could lead to DOS conditions or password compromise (and if your RADIUS box is relying on Active Directory for authentication, the extent of the damage could be consequential).
Speaking of MS-CHAP-V2… Have you considered using LDAP? [Edit – was going to add some derisive comment pointed at a company we all know and love. But that’d be below me… Heheh, right.]
If you’re using Active Directory in your infrastructure, you can of course hook your RADIUS server up to that. An added benefit of this is that you’ll be disabling both the user’s access to services and the network from a centralized location. The disadvantage is that, once again, your network access is relying on a centralized AAA system that has been known to fail. Plus, there’s a good chance that if you’re able to compromise credentials via the RADIUS server, you’d pretty much have the keys to the kingdom. If you’re going to use LDAP with RADIUS, you should at least be thinking about using TLS for encryption (which requires setting up a Cert Authority).
You probably noticed the ‘Enable quarantine checks’ checkbox when configuring your client in step four. Sounds enticing, doesn’t it? Essentially, what it means is that your client would accept participating in Statement of Health checks; of course, it does mean that you have to set up a Windows Network Policy Server. If you’re doing that, then you might as well set up RADIUS on the same server. c.f. step three to see why I think this is a bad idea…
Multiple connections on a single port, and special ports
One of 802.1X’s potential pitfalls is that of multiple machines connected to a single port. What happens if somebody comes in with a switch of their own? They could plug it into their ethernet connection and put a corporate machine on it as well as an external machine. If the switch isn’t configured correctly, the corporate machine could answer the RADIUS auth requests and the external machine would have all the access to the network it needs.
The EX4200 has provisioned for this possibility, and can be locked down in two following ways:
- You can prohibit a port from having multiple devices connected to it
- You can configure the switch to require that all devices connected to the port need to authenticate
You can use MAC address filtering