Keep Your Small Network Sailing Safely in Dangerous
by Jim Semmelroth
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?
Four Fundamentals for Developing a Secure Network
1. Know your network.
2. Develop defense in depth.
3. Apply the principle of least privilege.
4. Detection is more important than protection.
I have been helping many small libraries across western Montana manage their
IT environments for a decade. 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
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 specific
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 method 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 Microsoft 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.1
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 Microsoft
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 automated
at each individual PC or with free Microsoft tools such as Windows Server Update
Know the deployment schedule of your antivirus vendor's signature distributions
and arrange for your stations to get them automatically. Microsoft
Antispyware and Spybot are two tools that are free in a library environment
and are reasonably effective against spyware. Microsoft Antispyware works well
but occasionally presents a fairly technical question to the user about whether
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 server
(maybe), 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 recommending
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
Use the Microsoft Baseline Security Analyzer. This tool,
and useful information about it, is available at http://www.microsoft.com/technet/
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.3
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.4 I
would strongly suggest you go with the newer operating system than the older
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
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. Moskowitz5 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 included in the SCT download,
and it provides clear instructions on how to use the SCT in the workgroup and
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
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.
Segregation by ARP Cache Poisoning
Consider a library with two PCs, one for staff and one for the public.
The IP on the staff PC is 192.168.1.5. The IP on the public PC is 192.168.1.8.
At a command prompt on the staff PC, type "arp s 192.168.1.8 00-00-00-00-00-00".
Similarly, on the public PC type "arp s 192.168.1.5 00-00-00-00-00-00".
This has the effect of associating a given IP address with an invalid
MAC address, thereby disabling communication. It need only be done on
one of the PCs for functionality, but for defense in depth do both.
A problem with this technique is that the ARP cache is kept in RAM,
which is to say that the Address Resolution Protocol cache is kept in
Random Access Memory. This means the ARP cache is lost when the PC is
turned off. So you need to create a batch file with these commands that
will be run automatically at start-up to fill the cache with the static
entries you need. If you have a server and are using Group Policies,
that's the way to apply this batch file. Absent a server, use the start-up
folder on each PC or the Registry at HKLM-SOFTWARE-Microsoft-Windows-CurrentVersion-Run.
Be cautious modifying the Registry; you can make your PC unbootable by
doing something wrong. The most basic batch file need only contain the
following two lines:
ARP S 192.168.1.8 00-00-00-00-00-00
Add additional lines for each PC that you need to deny access to.
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/
3. ‑Microsoft Shared Computer Toolkit for Windows XP. 2005. Microsoft
Windows XP. 30 Oct. 2005. http://www.microsoft.com/windowsxp/
4. ‑Public Access Computer Security Tool. 2005. WebJunction Technical
5. ‑Moskowitz, Jeremy. Group Policy, Profiles, and IntelliMirror
for Windows 2003, Windows XP, and Windows 2000. San Francisco: SYBEX,
Jim Semmelroth is the information systems coordinator at the Missoula Public
Library in Missoula, Mont. He also runs Acme Gadget, a small IT consultancy.
He holds degrees in physics and philosophy from Montana State University and
the University of Montana, respectively. He also holds Microsoft, Cisco,
and security certifications. After a decade of supporting various small public
libraries in western Montana, he thinks he's starting to get the hang of it.
His e-mail address is firstname.lastname@example.org.