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.
|69 udp||tftp Trivial FTP|
|111 tcp/udp||SunRPC - Sun's Remote Procedure Call port|
|135 tcp||DCE endpoint resolution|
|137-139 tcp/udp||NetBIOS - ports used for Windows file shares & SAMBA drive mounts|
|161 udp||SNMP - Simple Network Monitoring Protocol|
|445 tcp/udp||Windows Secure File Share - File sharing between Windows 2000 and Windows XP systems|
|515 tcp||Line Printer - Printer daemon with multiple exploits across multiple UNIX operating systems|
|1433-1434 tcp/udp||Microsoft SQL|
|1521 tcp/udp||Oracle8i Listener|
|2049 tcp/udp||SunNFS - provides Sun drive mounts initialized on port 111|
|27374 tcp/udp||default subSeven - port commonly used for subSeven trojan|
|31337 tcp/udp||default Back Orifice - port commonly used for BO trojan|
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:
- First, check to see that the your browser URL matches exactly:
Pay close attention to the https:// prefix. It must say https:// and not http://. If your browser displays anything other than the above URL, do not log in. Report the problem to the OIT Technology Support Center (404-894-7173, firstname.lastname@example.org).
- Make sure that your browser creates the https:// connection cleanly, without any warning messages. If, after clicking the Login button, you get a pop-up message alerting you to any warning or error, do not log in. The warning may say something like "The name on the security certificate does not match the name of the site" or "The security certificate was issued by a company you have not chosen to trust," or something similar. Report the error to the OIT Technology Support Center (404-894-7173, email@example.com).
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:
openssl x509 -inform pem -in lawn.gatech.edu.pem -noout -fingerprint -sha1
openssl x509 -inform pem -in lawn.gatech.edu.pem -noout -fingerprint -sha256
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:
POP, IMAP, SMTP
POP, IMAP and SMTP are protocols used by email clients to read and send email messages. If you use Eudora, Outlook or Outlook Express, you are most likely using POP or IMAP to read your mail and SMTP to send mail.
Without encryption, when you use POP or IMAP to log into your email server to retrieve your messages, your login and password are sent in the clear and can be intercepted. Most email clients default to using non-encrypted POP or IMAP. However, both POP and IMAP can be enabled to use encryption, via SSL/TLS (POPs/IMAPs).
Both your email client and email server must support POP or IMAP encryption. OIT's SPECTRUM email service allows users to read email via unencrypted and encrypted versions of POP and IMAP. If you are checking email from the LAWN you should be using encrypted POP or IMAP only. If you don't, you place your login and password information at risk.
SMTP is used to send email, and like POP and IMAP is usually unencrypted. Some email servers allow for secure (AKA SSL encrypted) SMTP and you should use it if your email server supports it. OIT's SPECTRUM email service allows for encrypted SMTP.
Information passed via telnet is not encrypted. For example, if you use telnet to login to acme, then your username and password are sent to acme in the clear, and thus can be intercepted. Interactive connectivity can be achieved with encryption using ssh (secure shell). There are commercial/shareware/freeware ssh clients for various operating systems. The machine you are connecting to via ssh must be running an ssh server (acme can be accessed via ssh).
FTP sends its login information, as well as its files, unencrypted. There are two popular secure alternatives, sftp and scp. As with ssh above, commercial/shareware/freeware sftp and scp clients are available for various platforms. And again, the machines you are contacting via sftp/scp must be running a sftp or ssh server (respectively).
Another common use of ftp is public access to files (i.e., "anonymous ftp"). In the case of anonymous ftp, there is less of a risk, as the account/password ("anonymous" or "ftp," and an email address) are shared and publicly known.
Any information that you submit via form on a Web page can be intercepted if the site you are viewing is using http and not https. All major Web browsers support https, so there is no additional software for you to use. Just be aware that sensitive information shouldn't be typed into any form on a page whose URL begins with http:// .
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:
|126.96.36.199/24||N/A||1332||eduroam (ISS Disabled)|
|188.8.131.52/22||2610:148:1F00:6000::/64||396||eduroam (visitors from other institutions)|
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
firstname.lastname@example.org and include your GT account and the wireless MAC address of the device. This setting is permanent until you request us to change it back.
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 email@example.com).