In the first part of this series on intelligent edge switches and better using LAN edge switch security features,...
we looked at how to filter port traffic and use switch ACLs. In part 2, we explore how to use edge switches for network access authentication. Edge switches are an important part of in-depth network defense, essential to protecting edge nodes from each other and able to decrease the low-end workload on security devices deeper in the network so they can focus on higher-level threats.
Of all the unused security features lying dormant on intelligent edge switches in LAN data closets, perhaps the single most important one for improving LAN security is authenticated network access.
In the data center, IT has complete control over who can plug something into the network and who can have physical access to a device on the network. Outside the data center, that's not the case. In the LAN, that's where authenticated network access comes in. It ensures that users provide credentials at the switch in order to talk to anything beyond on the network.
How switch-based network access authentication works
The IEEE 802.1X standard governs the authenticated access, and both wired and wireless networks can require 802.1X authentication before providing access. The standard defines traffic among three entities: the supplicant, the authenticator, and the authentication server.
The supplicant is the computer (or other device) trying to connect through the authenticator -- the switch or access point. They communicate using the Extensible Access Protocol (EAP). The switch or access point uses the Remote Authentication Dial-In User Service (RADIUS) protocol to send credentials to the authentication server (AS), which checks them and sends back either a success or a failure, accepting or denying the supplicant.
Choosing the right RADIUS servers and readying them for 802.1X and EAP
For authenticated network access to work, the network needs a RADIUS server that supports EAP. Enabling the Network Policy Server on a Windows server (Internet Authentication Service, prior to Windows 2008) provides the service in a Windows domain. Lots of other RADIUS servers are available from network vendors, including Alcatel-Lucent, Cisco and Juniper. Freeware is also available. The key to long-term manageability is making sure your RADIUS service is connected to your domain authentication service (be it Active Directory, Lightweight Directory Access Protocol, or something else) and that it doesn't maintain a separate set of credentials.
To make the RADIUS server 802.1X-ready, an admin must set up a key and get a digital certificate. (This may have been done in support of some other security appliance, such as a VPN concentrator.) Any OpenSSL client or Windows IIS server can request a certificate with the right attributes in place. The most secure systems use EAP-TTLS or PEAP, which require certificates on client machines too, but this is optional. This is not required with EAP-TTLS.
Also, supplicants must support EAP and gracefully handle the transition from the un-trusted state (black hole VLAN and address) to the trusted state (usable IP address and VLAN). Some older desktop operating systems did not do well with this, but even Windows XP (post service pack 1) is sufficient.
Enabling LAN switch security
The next step is to enable security on the switches. Methods vary by switch vendor but should look something like this (with actual IP addresses substituted):
radius server host 192.168.001.001 key RadiusServersEncryptionKey
aaa authentication dot1x default radius
interface Ethernet g2-g48 dot1x port-control auto
- Tell the switch what RADIUS server to talk to.
- Tell it to use RADIUS authentication with 802.1X.
- Tell it to turn on 802.1X.
- Tell it to require 802.1X on ports g2 through g48.
Many variations are possible; for example, one might want to have a VLAN on which authentication is not required but which allows access to the Internet only and not to the rest of the corporate LAN:
interface Ethernet g2-g48 dot1x port-control auto unauth-vlan 13
Specifying network access authentication for specified user groups
The choice of whether to require network authentication, and what to do with unauthenticated access attempts, has to be driven by careful consideration of user populations and can be sanctioned for specific user groups or scenarios. An organization may want to grant mobile, temporary Internet access without credentials to user populations such as consultants or professional services staff while not wanting to grant data center access. That same organization might want to require authentication for any access by a user plugging into a regular office's network jack on the assumption that only company staff should be using those for access.
The more switches, RADIUS servers, and relevant VLANs you have, the more important it becomes not only to maintain standard "golden" switch configurations but to use automated configuration tools and run configuration audits consistently.
Read the next part of this series on intelligent edge switches, discussing the integration of LAN edge switch security with NAC.
About the author: John Burke is a principal research analyst with Nemertes Research, where he focuses on software-oriented architectures and management. As an analyst, John draws on his experiences as a practitioner and director of IT to better understand the needs of IT executives and the challenges facing vendors trying to sell to them. A frequent speaker, his career began at The Johns Hopkins University, where he supported the engineering faculty in its use of computers in research and teaching. He moved on to systems and network administration at The College of St. Catherine, in St. Paul, MN, and then to directing staff in voice, data, desktop and systems management at the University of St. Thomas, also in St. Paul.