Network access control on wired networks with IEEE 802.1X
Some distributions include a makefile in the /etc/raddb/certs directory. You can use this makefile in combination with OpenSSL to create three kinds of certificates: a certificate for (first) a small CA that will later sign the certificates for (second) the server and (third) the clients. However, if this directory is empty, as is the case with Ubuntu 9.04, you can grab the files from the FreeRADIUS GitHub at raddb/certs/ . The package includes a configuration file for each certificate and a shared makefile. To create a new CA certificate, you need to modify ca.cnf. Modify the [certificate_authority] section as shown in Listing 2. The values for input_password and output_password must be identical.
Excerpt from ca.cnf
01 [certificate_authority] 02 countryName = DE 03 stateOrProvinceName = Hamburg 04 localityName = Hamburg 05 organizationName = UebelHacker 06 emailAddress = email@example.com 07 commonName = "UebelHacker CA"
To edit the [server] section in server.cnf, follow the same steps, but choose a different commonName to differentiate between the certificates (see Listing 3). Next, insert private_key_password, specified in eap.conf, as the password. Finally, make all will create both the CA and server certificates, the required Diffie-Hellman file (dh), and the random file, both of which are important components in the SSL/TLS handshake.
Excerpt from server.cnf
01 [server] 02 countryName = DE 03 stateOrProvinceName = Hamburg 04 localityName = Hamburg 05 organizationName = UebelHacker 06 emailAddress = firstname.lastname@example.org 07 commonName = "UebelHacker Radius Server"
In EAP-TLS, each device needs its own client certificate, which you can create with client.cnf. The FreeRADIUS makefile signs these credentials with the server certificate by default. To use the CA to sign them, change the lines in Listing 4 and watch out for the tab at the start of line 2. You can then give the supplicants the CA certificates directly.
Modifying the Makefile for CA
01 client.crt: client.csr ca.pem ca.key index.txt serial 02 openssl ca -batch -keyfile ca.key -cert ca.pem -in client.csr -key $(CAPWD) -out client.crt -extensions xpclient_ext -extfile xpextensions -config ./client.cnf
The commonName in the [client] section specifies the user name for permissions and other settings in RADIUS. Again, the certificate is password-protected using the passwords set as input_password and output_password:
[client] countryName = DE stateOrProvinceName = Hamburg localityName = Hamburg organizationName = UebelHacker emailAddress = email@example.com commonName = uebelacker
In contrast to the CA and server certificates, you need to create multiple certificates here – one for each user. As make client only creates one certificate, it makes sense to script this task. You can then hand out the certificates, passwords, and the CA certificate to the users in a secure manner, preferably on a USB stick or smartcard.
Setting up Users
The next things the RAS server needs are the details of the authorized users. To keep this simple, you can simply give each user a client certificate signed by the CA. If you don't change the users configuration file on the RADIUS server, it will give access to anybody with a valid certificate. The switch will then assign the supplicant to the specified VLAN.
However, if you prefer to give the RAS server more details about the users, a number of options are available for doing so: The fastest approach would be to add the authorized and non-authorized users to the users file. See Listing 5 for an example of this method.
01 dau Auth-Type := Reject 02 03 DEFAULT Auth-Type := EAP, Login-Time := "Wk0800-2000" 04 Tunnel-Type = 13, 05 Tunnel-Medium = 6, 06 Tunnel-Private-Group-Id = 23, 07 Fall-Through = Yes 08 09 uebelacker Auth-Type := EAP, Login-Time = "Any" 10 Tunnel-Private-Group-Id = 42
Line 3 of Listing 5 defines the defaults for any supplicant that provides a valid certificate via EAP. The Tunnel-Type and Tunnel-Medium details are required by the standard if you want the switch to assign a VLAN – for example, 23 as the user segment. RFC 2869 defines more RADIUS extensions; for example, you can restrict user logins to weekdays between 8am and 8pm to prevent night hacking sessions.
The first line blocks the user dau, who has just left the company but still has a valid certificate. As an alternative, you could implement this business logic with Certificate Revocation Lists (CRLs), although this step is slightly more complex. The first match rule applies for this file, unless you have set the Fall-Through attribute as shown in line 7. The additional attributes overwrite the settings for the administrator, uebelacker, who is not subject to time restrictions and lands directly in the administrative segment.
radiusd -X launches the RAS in debug mode to identify any incorrect configurations. If the server launches cleanly, RADIUS will show that it is now responding to requests:
Listening on authentication address 192.168.123.23 port 1812 Ready to process requests.
It makes sense to run the daemon in debug mode until the network port is unlocked; this will log any activities verbosely on standard output.
Should you trust an online service to store your online passwords?
New B+ board lets you build cool things without the complication of a powered USB hub.
Redmond rushes in to root out alleged malware haven.
New initiative will bring futuristic virtual reality effects to the web surfing experience.
Dyreza malware launches a man-in-the-middle attack that compromises SSL.
New cloud combines worldwide access with local attention to data security.
A first cousin of the recent Heartbleed attack affects EAP-based wireless and peer-to-peer authentication.
FOSS community acts to protect freedom of choice for laptop devices.
Quintessential open source browser shores up its market share with a step toward the proprietary dark side.
Authorities in 16 countries take action against users of the imfamous BlackShades malware tool.