>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
Contrary to the Juniper setup guide, I don’t tend to start by mounting my equipment on the rack. The average server room is loud, cold, dark, and has entirely too little room to be faffing about in it trying to configure your new equipment. Seriously, you’re more likely to damage yourself and your existing equipment than anything.
Do pick somewhere roomy, dry, well-lit and safe from danger. A good example of this is your office. If you have one. Perhaps an infrequently used conference room. A corner table in the cafeteria is not an option, regardless of how temptingly close it is to the coffee machine. And, once again, remember: it might take you a few days to get this right, so maximize your chances.
Step One: configuring your admin workstation
This sounds silly. However, if you don’t have the right tools for diagnosis, you’re going to waste a whole lot of effort for no reason; in the very least, you should peruse this section to make sure you’ve got the ideal setup.
My admin workstation is a dual-core 32-bit Ubuntu box with 4 GB of RAM. Not particular fast, but it has enough space and memory to host a VM without dying a horrible, rattling death. The idea is to run your RADIUS server on a VM so that you can sniff traffic on it without having to set up port mirroring; additionally, you want to be able to snapshot you RADIUS server in order to try different permutations of your configs, or revert to an earlier state if you’ve screwed things up.
Another important thing is that your admin workstation must have a serial port and terminal. You can configure the switch without it, in all probability; be that as it may, you’ll want to at least be able to connect to the serial port so that you can get the switch’s status when you shut down for the day.
Step Two: the physical environment, VM, and switch
Once your admin workstation is ready, spend a little time prepping the environment. Get the multi-plug connected to the outlet and physically accessible at all times (you’ll find that you have to power-cycle the switch a lot). Do not plug the switch in yet! Place your admin workstation close to the switch, and plug in the serial cable and launch your terminal, so that when then switch turns on you can monitor its status as it boots up.
Before you get started on the switch, I recommend you install the base O/S of your RADIUS VM. Set up a barebones distro (I use ubuntu server LTS) with SSH on it, to start. When configuring the virtual hardware, make sure you have enough resources dedicated to it and, most importantly, set it to bridge the ethernet connection – don’t use NAT. The benefit of setting up the VM first is that while the O/S is installing you can focus on configuring the switch.
While system files are being copied to the VM, plug in your switch – it’ll start booting the minute it’s got power. Out of the box, it’s in initial setup mode; if you’ve bought it second-hand or inherited it, you’ll probably have to reset the factory settings; here’s how you do that:
- 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.
These switches are configurable via two interfaces: the CLI interface (serial port), or the J-Web interface (http). I’ve found that there is really no benefit to using the CLI for the initial setup, so I’m going to explain how it works the J-Web way:
- 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.
This is pretty much where I’ve found the manual ceases to be useful. Yippee. So here are a few notes I’ve collected over the past few days:
I couple of helpful things to know about your EX4200
The first thing to know is that the web interface is pure gold. We use a lot of Cisco Catalyst switches – which are very powerful, of course, but the web interface really feels like an afterthought. The J-Web interface is badass. Here are just a few of the things I really like about it:
- 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.
But I digress – let’s focus on a few things you need to know about the switch in order to understand how to configure it for 802.1X:
- 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).
Step Three: getting 802.1X up and running
The first thing you’ll need to do is configure the RADIUS server. Your best bet is to go with Linux; I know that Windows NPS is tempting! It’s easy to perform the install, it integrates with all the other components in a windows network, it allows you to bind it to AD effortlessly, it provides more useful features than a swiss army knife. Yackity yackity. Linux might not be the easiest to install, but it’ll work once it’s installed; and it’ll continue to work for a long, long time. The last bloody thing you need is for your entire campus to go tits up every second wednesday of the month, if you know what I mean.
At this point, your VM is probably ready to be configured. Let’s get started with a basic configuration – one that will allow users to authenticate using user creds present in the radius users config file:
- 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.
Then, you should make the switch aware of the RADIUS server – in other words, configure the Authenticator to interface with the Authentication Server. To do this, follow these steps:
- 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.
Remember that the switch’s role as Authenticator will be to take the auth packet coming from the XP workstation, encapsulate it in an EAPOL frame and pass it on to the RADIUS box.
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.
Step four: connecting an XP machine to your 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.
Step five: expanding your horizons
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).
Quite a few of the vulnerabilities mentioned above can be circumvented by restricting access to the RADIUS server from the network (as mentioned above), getting relevant alerts when a new device is plugged in, and using a different authentication mechanism (MS-CHAP-V2 might be an option, but it’s definitely not 100% secure either as you can see
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
Nope, it’s not a mistake – I indicated that there were two ways to lock down the switch and listed three. That’s because the third’s not a viable option: I’m stating it so I can shoot it down right away, because it’s no ridiculously easy to circumvent.
I think that further research into the implementation of option two is necessary to be able to sign off on it fully… But that, like many other elements of this article, is for another time.
I hope that you found this little intro to 802.1X and Juniper useful. It’s meant as an introduction and is by no means comprehensive, but will hopefully get you thinking about the various infrastructural and security aspects that you need to consider when implementing such a mechanism.
Frightfully sorry about some of the gaps in explanations – if you write to me or comment on my post, I will do what I can to answer any questions!