Strong Host-Based Security
We strongly recommend that all LAWN users practice strong Host-Based Security on their devices. This includes running a personal firewall, using secure services, keeping current on operating system and application patches, and running an up-to-date virus scanner. Details on these are available on the OIT Website.
Due to the inherent insecurities of wireless networks, they should be treated as untrusted networks. We have implementing filters on the LAWN that exist at our campus borders. The impact of blocking these ports will be loss of access to some applications, such as Windows File Sharing.
Web Login Hijacking
Because of the architecture of the LAWN network, there is a chance that someone may try to fool your computer into contacting a rogue server and presenting you with a fake LAWN login screen. The purpose behind such an attack would be to gain your login and password.
Though LAWN may look on the surface to be susceptible to such an attack, if you pay attention to how your browser presents the LAWN login screen, you can avoid being fooled. You should look for two things:
Authentication Security with PEAP
When authenticating to eduroam, Protected EAP (PEAP) is used to create a secure tunnel between your device and the LAWN RADIUS servers, so that the authentication process is encrypted. However, it is possible for someone to create a rogue wireless network that presents itself as being eduroam in order to obtain your GT account credentials. How does LAWN make sure that this does not happen, and your credentials are kept safe?
PEAP utilizes TLS to facilitate the encryption of the authentication session, and also allows for the client to verify the server’s identity through the use of public key certificates. Since the authentication session is encrypted, your authentication credentials are never transmitted over the network in cleartext, so eavesdroppers cannot skim your credentials or any other information from the authentication process.
When PEAP initiates the TLS session between the client device and RADIUS server, the RADIUS server presents the client with a X.509 certificate. If the client is sufficiently content that the certificate presented could have only be sent via a legitimate RADIUS server, the client can proceed to transmit it’s authentication credentials over the encrypted TLS session to the server. How does the client know that it is being presented with a legitimate certificate?
For reference, HTTPS uses TLS in much the same manner as PEAP to secure HTTP requests between web browsers and web servers on the Internet. Web browsers are able to verify that a certificate presented by a web server is legitimate by checking two things. First, a browser checks that the common name, or one of the subject alternative names, of the server certificate matches the domain of the URL being requested by the browser. If I browse to https://google.com, the web browser expects to be presented with a certificate that has a name of google.com. If the web browser does not find the name google.com, it warns the user that malicious activity could be involved. Second, the browser will make sure that the certificate presented has been marked as trusted by the operating system, or the certificate presented has been signed by a root Certificate Authority (CA) that has been marked as trusted by the operating system. When browsing to https://google.com, the web browser sees that the certificate with a name of google.com has been signed by a certificate named GeoTrust Global CA which has been installed as a trusted root certificate by every modern operating system. Since the operating system trusts the CAs that sign certificates to make sure the people requesting certificate signing also own the associated domain name, the browser can be confident that the google.com certificate presented by the web server is from the actual Google.com.
Operating systems verify certificates presented by radius servers during PEAP by once again checking that either the certificate has been marked as trusted, or the certificate has been signed by a trusted root CA. In this way, the client software responsible for overseeing the PEAP authentication process, called the 802.1X supplicant, can verify that the certificate being presented is from who they say they are. PEAP differs from HTTPS, though, in the fact that the supplicant often has no way of verifying that the name of the certificate is the intended name. When connecting to eduroam, the supplicant usually has no way of knowing wether it should be expecting a certificate with a name of gatech.edu versus uga.edu as a specific domain is usually never requested by the end user. Because of this, most supplicants will prompt the end user on whether or not they trust the RADIUS server certificate before continuing with the authentication attempt.
lawn.gatech.edu Certificate Fingerprints
Often times LAWN users will be content that they are connecting to the correct network by seeing that the common name (CN) of the presented certificate is “lawn.gatech.edu”. All LAWN radius servers present the same certificate with a CN of lawn.gatech.edu, so once you trust this certificate on your device you will not need to trust another unless you delete your wireless profile, or the LAWN team needs to replace the server certificate. However, if you are ever unsure whether or not you are being presented with the real LAWN certificate, you can verify that both the SHA-1 and SHA-256 fingerprints of the presented certificate exactly match the values here:
Some devices display SHA fingerprints differently. Hex characters may be uppercase or lowercase, and octets may be separated with whitespace, colons (:), or hyphens (-). As long as both hex values match exactly you can be sure you are authenticating to a real LAWN RADIUS server. Most operating systems have a way of checking the fingerprints graphically. For instance, when connecting to eduroam from an iOS device, iOS will prompt the user to trust the RADIUS server certificate.
We can see that the name of the certificate is indeed lawn.gatech.edu as expected. If we want to check the fingerprints, we can tap "More Details", and scroll to the "FINGERPRINTS" section.
You can aslo check the fingerprints on a local copy of the certificate with openssl:
Use of Insecure Services
Many frequently used Internet protocols (e.g. http, POP, IMAP, telnet, ftp) transmit account and password information in "clear text," unencrypted. The danger of this is that anyone with a machine on the same network as a machine using those protocols can easily acquire any login and passwords sent using those protocols (e.g., if you use Eudora to POP email while using LAWN, someone can easily steal your login and password that you use to access your email server). LAWN is a shared network. Using unencrypted protocols on just about any shared network (including LAWN) places you at risk and is a bad idea. The following table offers safe alternatives for the most common protocols:
What are the LAWN network ranges?
LAWN is composed of multiple networks. Depending on how you access the LAWN will determine which network range you will be assigned to.
If you are attempting to configure your host based firewall and would like to control traffic to/from the LAWN network ranges, they are published here for your convenience:
What is Inbound Service Security ?
Inbound Service Security (ISS) uses stateful packet inspection to help protect your LAWN-connected device from hacking/virus attacks originating from outside of the LAWN network.
When Inbound Service Security is enabled for your LAWN session, hosts outside of the LAWN network are blocked from connecting to services running on your machine. For example, if your LAWN-connected device is running a Web server, with Inbound Service Security enabled, hosts not on the LAWN network will not be able to connect to your machine's Web server.
A service can be provided by any application on your machine which listens for and accepts TCP connections to your machine by another host. Because these services commonly present vulnerabilities which hackers exploit, and are often unintentionally enabled, it is in your best interest, security-wise, to use Inbound Service Security when logging into LAWN. ISS will be enabled for your LAWN login session unless you check the "disable Inbound Service Security" box on the login form.
Note that Inbound Service Security is not a complete security solution; you should make sure your computer is up-to-date with vendor supplied patches, disable any unnecessary services, and utilize a personal firewall.
On eduroam: By default, eduroam users are placed behind a stateful firewall (ISS enabled), which does not allow unsolicited connections from outside of LAWN. If you do not want a stateful firewall (ISS disabled) on eduroam, please contact
By disabling this safeguard, you accept full responsibility for the increased risk associated with allowing connections to your machine. Please note that disabling Inbound Service Security allows access from outside of the LAWN network to any TCP port in use by any service on your machine.
An important technical note: Communication is automatically permitted between any two LAWN hosts (without authenticating), regardless of network (LAWN utilizes multiple networks). When using eduroam, all of your devices (logged in under the same username) should be on the same network (unless you have requested ISS disabled).
For those of you who need additional technical information, devices placed on the same Layer 2 network and broadcast based services (such as Apple's Bonjour protocol) should work as expected. If you need any additional details or have any specific questions, please contact the LAWN Services Team (at firstname.lastname@example.org).
We welcome input into our Security forum. Please feel free to add to the forum below in regard to security-related topics. Our hope is that a contribution from the campus will enrich the information of this site for all to benefit.
Please note that the forums are not meant as a replacement for the official OIT help system ServiceDesk (which can be reached via email, email@example.com, or via the phone at 404-894-7173).
You must Login to LAWN Forums in order to post to this forum (HTTP cookies required).