SUBSCRIBE NOW!

Vol. 26 No. 1 — January 2006

Following a few fundamental procedures can go a long way toward protecting your small network from hacking pirates, adventurous patrons, and careless crew members.

Reliably providing electronic services has become increasingly difficult for small public libraries as the Internet environment has become increasingly threatening. Our communities expect us to provide the latest information services, but skilled and experienced technical support is often in short supply in these smaller libraries and communities. What is a librarian to do?

I have been helping many small libraries across western Montana manage their IT environments for a dec­ade. The techniques for meeting the needs of a small library running Microsoft platforms don't vary much, so it is easy to describe a standard model. Since public libraries are in the enviable position of receiving substantial generosity from the Bill & Melinda Gates Foundation and Microsoft Corp., the most widely used software on the market is almost free for us and so it is the obvious platform to use. I'd like to share some of the security components of that model with you now.

Storm's a Brewin', Matey

A small library's essential technical problem is that it has to chart a course through the technology shoals without a navigator on board. Small libraries in small towns often have a very low level of technical skill on staff. Furthermore, obtaining skilled technical support can frequently be pretty expensive. Even when one is available, a clever systems and network support person can underestimate the needs of the library environment or simply not be familiar with some of the specialized tools designed for our environment. The problem is compounded by the fact that libraries invite anyone who walks in the door to sit down at the public PCs and do as they like.

This article lists standard tasks that will get you pretty good security at minimal cost. The underlying theme is to develop "defense in depth." To do this is to do little things throughout the network rather than to set up a single point of protection that is expected to be fail-safe. Developing defense in depth is one of four fundamental principles of developing a secure environment. Additionally, you should "know your network," you should apply the "principle of least privilege," and, lastly, "detection is more important than protection." (Although it really is important, I can't cover this last principle in this article.)

When I say that you need to know your network, I mean that you should know what ports you are exposing to the Internet at your router, what programs and services are running on all your PCs, what network ports are physically available to patrons to plug their notebooks into, what mischief patrons can wreak at one of your PACs, what authority your various logons have, and the list goes on.

The principle of least privilege holds that people should have the means and the authority to do their jobs, but no more than that. Systems administrators impose restrictions across their networks and there are two logically different ways to do so. The first is to allow everything, and then deny a spe­cif­ic set of items. The second, and more thorough, is to deny everything, but allow a specific set of items. One need only live briefly with teenage progeny to recognize the futility of the first me­thod of applying restrictions. The principle of least privilege is an assertion of the second.

Outfitting to Set Sail

You should be using only Windows 2000, Windows XP with Service Pack 2, or Windows Server 2003. Prior Micro­soft platforms don't really pay any attention to security. You should be using only the NT File System (NTFS). You are almost certainly using a privately addressed LAN with one public IP address at the outside interface of your router, and that is a good thing.¹

The most important and useful things you can do are the most basic: Apply Windows updates, run antivirus and anti-spyware, and keep the signature files updated. Be sure to run Office updates too if you are running the Micro­soft Office suite. Microsoft releases its updates every second Tuesday of the month. Your PCs should all be patched by the end of that week. This can be au­tomated at each individual PC or with free Microsoft tools such as Windows Server Update Services.²

Know the deployment schedule of your antivirus vendor's signature distributions and arrange for your stations to get them automatically. Mi­cro­soft Antispyware and Spybot are two tools that are free in a library environ­ment and are reasonably effective against spyware. Microsoft Antispyware works well but occasionally presents a fairly technical question to the user about whe­ther something should be allowed or blocked. Most of my users are unable to understand some of these questions so I simply tell them they have a 50/50 chance of getting it right. I haven't had too much trouble with this yet.

Use strong passwords on all your accounts. A strong password these days has at least eight characters of lowercase, capital, and numeric characters. Better yet, use a pass-phrase of at least 15 characters. The length of the pass-phrase, even if just lowercase, makes it stronger than a cryptic eight-character password. I find that the phrase "I like ice cream" is much easier to remember than "1seKream."

Password security is not primarily meant to protect staff members from other staff members. It is primarily to protect the organization from the Internet. It is a common, automated, and fairly easy process for pirate-like hackers to place password-breaking spyware on your PCs, then attempt to break your passwords and to use that information to do whatever they want with your network. One account with an easy-to-break password makes the whole network vulnerable. I'm even OK with the "yellow sticky note" technique of remembering passwords. Just keep these notes well away from overly curious eyes.

You may be thinking you have just a small library network with a few PCs. Why would Internet invaders care about you? The answer is that the bad guys want your identity, your platforms to send their spam, and your storage space for their illegal files. Their tools are
all automated so they are not focused specifically on you or your network. It is just another place on the Internet they might be able to use. You need to think about what is going to happen to your staff dynamic when someone finds illegal images on one of your PCs. Maybe worse, what is going to happen when your local newspaper hears about it?

Heading into Deeper Water

There are generally only four types of devices on a small public library's network. You have a router, which is your connection to the Internet, a ser­ver (may­be), the staff PC, and the public PC, these last two being very different creatures. Impose restrictions as follows. (There are a wide variety of router brands and models you could use, but nearly all will support these features.)

• Block ports 135, 139, and 445, both ingress and egress. These ports are used for communication between Microsoft platforms on a LAN. There is no valid reason for anyone outside your LAN to access these ports, and there are a number of exploits designed to capitalize on these vulnerabilities.

• Block all access into the router from the outside that purports to be from an IP address within the address space used by the library. For example, say your LAN is using 192.168.1.x and a packet arrives at the outside port of the router with a source address of 192.168.1.23. It is probably a spoofed packet from a bad guy.

• Change the default password on your router to something unique and difficult to guess. Most devices like this have a default logon and many organizations never change it. This is easy picking for the pirates. And pick a password more unique than "library" or "books." There are lists that the bad guys circulate (like the one at http://geodsoft.com/howto/password/common.htm) that name 1,500 of the most commonly used passwords, and many basic library terms are on them.

You may or may not have a server and, if you don't, I am not recommend­ing that you get one. It's a decision unique to your environment based on cost and need. Generally, the first two needs a server meets are fault-tolerant storage of important staff documents and centralized management of public PCs. My experience is that it doesn't take a very large network for a server to be cost-effective. If you have a server, follow these recommendations to stay afloat.

• Use the Microsoft Baseline Security Analyzer. This tool, and useful information about it, is available at http://www.microsoft.com/technet/
security/tools/mbsahome.mspx. Install the latest version of this tool on your server and run it against the server. It will provide a list of items and a security score associated with each. Examine the red- and yellow-scored items for a description of the inadequacies and directions for how to repair them. Run this tool through multiple iterations to continually improve your server's security level until the security assessment reports no more red- or yellow-flagged issues.

• Don't use Dynamic Host Configuration Protocol (DHCP). There are few enough hosts on the network that it is not a critical work-saving feature. Not using it makes it harder for your patrons to surreptitiously use one of your network ports. Manually configure all host IP addresses. The other side of this is to not allow patrons access to network drops. The threat presented by a patron's notebook on the library's network is substantial and should be guarded against carefully.

• Use the Security Configuration Wizard that comes with Service Pack 1 for Server 2003. Search the Microsoft site for information about how to deploy this tool.

Network administrators in public libraries have to manage their staff and public PCs very differently. Public PCs must be denied access to staff PCs completely, and to the server as much as possible. This segregation may be accomplished in a variety of ways, all of them requiring a bit of work under the hood. In larger environments, it may be cost-effective to get a router that can support two subnets separately, one public and one staff. Another hardware solution is to use a switch that supports VLANs. Both these techniques use costly hardware.

You can also work with the address resolution protocol (ARP). The smallest networks can use a technique called "poisoning the ARP cache." This disables access between appropriately configured PCs at a very deep level and does so quite effectively. (See the sidebar for a description of how you can use ARP cache poisoning for segregation.)

Another great technique for disabling unwanted access to a PC is simply to turn off the "Server" service on that PC. Unfortunately, it disables so much that it is usually more trouble than it is worth in all but the smallest environments. It's worth a look if you don't have a server in your environment though.

All Hands! Man the Sides to Repel Boarders

Only a very few patrons can be considered malicious, but many of the others are too uninhibited. Patrons have told my librarians that they come to the library to visit some sites so they don't infect their home PCs. This is why even the smallest public library needs industrial-strength protection on its PACs. Last summer our options got a lot better with Microsoft's release of a product called the Shared Computer Toolkit (SCT). You can find out all about it at Microsoft's Web site.³

If you must support Windows 2000 PACs, you will have to use a much less user-friendly and older tool called the Public Access Computer Security Tool found at WebJunction.org.⁴ I would strongly suggest you go with the newer operating system than the older security tool.

Management of public PCs proceeds along two distinct paths. First, the PC must be locked down to block common avenues of mischief. Second, it must also be managed so that any unexpected failures of the secure configuration are easily recovered. The SCT supports both these efforts with the User Restrictions Tool and the Windows Disk Protection Tool.

The SCT is really designed for the workgroup environment but also has components for the domain environment. The Windows Disk Protection Tool works the same regardless of whether the environment is a workgroup or a domain. The SCT does provide a scripting tool to manage PCs using the Windows Disk Protection Tool, but the gold standard is still a product called Deep Freeze from Faronics (http://www.faronics.com). Deep Freeze is the most cost-effective technology expenditure a small library can make.

The User Restrictions Tool, great in a workgroup, is inappropriate for the domain. In a workgroup you install the tool on an individual PC and configure it at that PC. If you have 10 PCs, you do it 10 times. If you have to make a change, you make it 10 times. You soon recognize that this is time better spent being a librarian than a geek.

The alternative is to get Server 2003, install Active Directory, and use Group Policies. Group Policies is a very powerful environment for passing configuration settings to a large number of PC's. Large, in this case, simply means more than you care to deal with one-by-one. Using Group Policies, you make the change once at the server and it is applied to the group. Group Policies is a fabulous work-saving tool. It can be daunting to learn fully but quite easy for the simple needs of a small library network. Moskowitz⁵ is a good bound resource for learning how to use this valuable tool.

Thankfully, the SCT has provided a template for use in a domain environment. Called SCTSettings.adm, the template need only be applied to the User Configuration portion of the Group Policy object as per the instructions in the SCT Handbook, and most of the settings available in the workgroup version are now available in the domain version. The SCT Handbook is includ­ed in the SCT download, and it provides clear instructions on how to use the SCT in the workgroup and domain environments.

Dropping the Anchor

It's not enough to make the changes indicated above. You should also test the effect of your efforts by thinking like a pirate and trying to wreak a little havoc on your public machines. The tools and techniques below are useful on your staff PCs and server.

• Autoruns and TCPView are great free tools from Sysinternals (http://www.sysinternals.com), a site with a lot of free tools. Use Autoruns to see what executables are started automatically. Use TCPView to inspect what ports are open.

• Ping between staff and public PCs to ensure their segregation. Public PCs should not be able to get a reply back from the staff PCs and vice versa.

• Verify that private folders are private. Make sure that any folder with sensitive documents is available only to the accounts authorized to see those documents.

• The Event Viewer is your friend. Errors and Warnings in the System and Application event logs are indicators of areas that need attention. Use the filtering option in the Event Log viewer to look for suspicious events in the Security log. Keep you server running smoothly by solving all problems indicated by an error or warning.

Not long ago, I was inspecting the event logs from a server that had been accessible directly from the Internet for a brief period. As if to illustrate the value of taking these steps, as well as the principle that detection is as important as protection, I found a series of failed logons. A robot, or an extraordinary typist, had attempted 280 unique logon/password pairs in 42 seconds. A number of the passwords were simple ones that I might have used in years gone by.

We all know that IT is a dynamic environment and so you should try to keep up with important changes. One good way to keep abreast of security issues is by occasionally looking at http://isc.sans.org. You can learn quite a bit by glancing at some of the material there. For example, today the average time between attacks on a PC connected to the Internet is 20 minutes. That should give you something to think about as you guide your library network across the waves. Smooth sailing to ya matey.

References

1.  ‑Internet RFC/STD/FYI/BCP Archives. 2005. Internet FAQ Archives. 10 Jan. 2005. http://www.faqs.org/rfcs/rfc1918.html

2.  ‑Windows Server Update Services Product Information. 2005. Windows Server System. 31 Oct. 2005. http://www.microsoft.com/windowsserversystem/
updateservices/evaluation/default.mspx

3.  ‑Microsoft Shared Computer Toolkit for Windows XP. 2005. Microsoft Windows XP. 30 Oct. 2005. http://www.microsoft.com/windowsxp/
sharedaccess/default.mspx

4.  ‑Public Access Computer Security Tool. 2005. WebJunction Technical Support. http://pacomputing.webjunction.org/do/DisplayContent?id=7593

5.  ‑Moskowitz, Jeremy. Group Policy, Profiles, and IntelliMirror for Windows 2003, Windows XP, and Windows 2000. San Francisco: SYBEX, Inc., 2004.