SUBSCRIBE NOW!

Vol. 23 No. 5 — May 2003

In the ocean of potential cybervictims, libraries are small fish, but that doesn't necessarily mean that we have no cause for alarm. Hackers prefer to target high-profile sites—governmentagencies, military, e-commerce, and political foes. They might be motivated by achieving economic gain, making political statements, or just proving their prowess as hackers and pointing out the stupidity of the victims. I've seen many postings in the hackers' realm reflecting the attitude that if anyone is inept enough to leave obvious vulnerabilities in their computer systems, they deserve to be hacked. Ignorance is no excuse when it comes to computer security. It's also fair to say that a strong anti-Microsoft sentiment pervades hacker communities. In the last few years, computers running any of Microsoft's operating systems find themselves the victims of a constant onslaught of attacks.

When Hackers Attack

Fortunately, breaking into a library computer doesn't bring the hacker the same level of glamour or prestige as some of the other potential targets around. As best as I can tell, the hacking community generally regards libraries quite favorably. All in all, libraries experience a fairly low rate of downtime and disruption due to security breaches and subsequent system compromises. Things could be a lot worse.

Unfortunately, the hacking community also perceives library computers as "easy marks." Libraries often don't have full-time systems administrators and security specialists. So, while a library machine may not be the ultimate destination targeted by a hacker, it may be a convenient intermediate stage in a broader plan of attack. A typical strategy for breaking into a system involves capturing access to a series of other computers throughout the world to make it difficult to trace the attack to its source.

I recall a security incident at my own library a number of years ago that serves as an example of the stepping-stone attack strategy. Hackers managed to break into one of our servers, placing many gigabytes worth of illicit software—called "warez"—and making it available for the entire world. For a brief period of time, we observed hundreds of simultaneous FTP sessions from hackers all over the world. Our investigation of this break-in revealed that the computer used to attack our system was in Greece. But this computer itself turned out to be hijacked. The initiator of the attack, as best we could determine, resided in Belgrade, Yugoslavia. As we learned, the stepping stones of a security attack can span the globe.

Dynix Was Put on Alert

So while we're seldom prime targets, we aren't totally bypassed either. One of the popular hacking magazines recently printed an article pointing out some of the lax practices and security vulnerabilities found in some installations of Dynix—one of the most common library automation systems ("Breaking Down the Dynix Door," 2600: The Hacker Quarterly 19:3, Fall 2002, pp. 47­48). The author goes by iCe799, consistent with hackers not wanting to use their real names. The article describes the author's observation that at least some implementations of the Dynix ILS lacked even the most basic security precautions. He provides a basic recipe for discovering servers that run Dynix and identifying ones with lax security, and what exploits might be successful in gaining access.

The author cautions the hacker community not to do bad things with this information. "Some of the various systems I have been looking through contain very interesting personal information. Information that should not be used for malicious purposes. I would advise anyone finding that these methods work alert the system administrator immediately." (But don't count on receiving kind treatment from hackers—it's imperative to operate systems in a way that's not vulnerable to such attacks.)

iCe799 notes some of the information that—from his own experience—can be revealed from patron records in the system: names, birthdays, addresses, driver's license numbers, e-mail addresses, past overdue items, current overdue items, fines owned, refunds owed, and notes. It's easy to figure out which records identify minors both through the birthday field and through the presence of information about a guardian and the school attended. Clearly, a typical library automation system holds very sensitive information about patrons that must be protected from unauthorized access, regardless of the effort necessary.

Dynix (formerly epixtech), the company that produces and supports the Dynix ILS, was notified by an attentive customer about the article the day it was posted (it ran online and in print). The company promptly issued a general security warning to its customers running Dynix, reminding them to follow the fundamental security precautions necessary to avoid system compromise: Use firewalls, disable unnecessary network services, do regular backups, and practice rigorous account and password management. A day later, the company issued a warning outlining the specific vulnerabilities described in the article. This warning gave clear instructions regarding the security vulnerabilities publicized in the article that, if followed, would effectively foil hackers attempting to use these methods for intrusion. Further, Dynix issued a security pack to the Dynix ILS that included a number of security-related enhancements. The vendor asserts that it's not aware that any of its customers' systems were compromised as a result of this article. While it's always possible that there were some minor intrusions that went undetected, after some investigating, I have also found no reports of major Dynix systems compromises. I think that everyone involved—the company and its customer libraries—now has a higher level of security awareness than before.

I exchanged e-mail with the individual who wrote the article in 2600. One of my main questions was whether he continued to find Dynix systems with the same security weaknesses after the article was published. He maintained that a large number of Dynix systems remain vulnerable, and that some have been compromised.

In my view, Dynix's ILS is no more vulnerable to attack than any other. There are over 2,300 installations of Dynix worldwide. I'm sure that only a very small percentage of these had the security issues noted in the article. None of the vulnerabilities described in the 2600 article reflected problems with the design of Dynix itself, but rather involved lax practices in the systems administration of the underlying UNIX operating system. In the hands of a good systems administrator, any of the major library automation systems on the market today can be well-hardened against the threats of hackers.

Another issue that comes up frequently involves the relative security of Windows operating systems versus UNIX. While Windows has been the prime target for the latest onslaught of virus and worm attacks, I'm not convinced that the operating system itself is any less secure than the various forms of UNIX. Given equal attention by a competent systems administrator, a Windows-based server (2000, XP, .NET, NT) can be thoroughly secured. Most problems occur when organizations deploy Windows servers without an adequate level of technical administration. Both UNIX and Windows are complex and powerful operating systems that need constant attention or they will lapse into vulnerability. Good security demands vigilance and involves a complex set of tasks. Realizing that any set of guidelines will be incomplete, I offer the following tips that, if followed, should protect your ILS reasonably well.

Marshall's Top 10 ILS Server Security Tips

1. Keep the operating system up-to-date. Take advantage of any automatic notification or updating service offered by the operating system's developer. Apply OS upgrades and security-related patches as soon as you possibly can. The last few worms that spread through the world exploited vulnerabilities for which patches had been available for at least 6 months. We may not be so lucky the text time—the attack may come days and not months after the security lapse has been identified and patched.

2. Keep the application software up-to-date. Libraries must give careful consideration to when upgrades can be installed. Academic libraries, for example, generally don't want to install upgrades that bring changes to the way that the system works in the middle of a semester. Nevertheless, strive not to run software that is too far out-of-date. Any patches related to security vulnerabilities should be installed promptly. Make sure that your vendor understands your concern for good security.

3. Turn off all network services you don't absolutely need. When installing the operating system, it's often the case that many network services that you will not need for the task at hand just load automatically. You can easily check to see what network ports have been activated on your server by using a port scanning utility. Gibson Research Corp. offers a free service called ShieldsUP from http://grc.com that will test the security of a Windows-based system.

4. Use industrial-strength passwords.A good password will not include any word in the dictionary (including foreign languages), a proper noun, or a keyboard pattern (e.g., qwerty), and will include one or more non-alphanumeric characters. Granted, such passwords are tough to remember, but that's the cost of keeping your system safe. Require that all staff members (not just the system administrators) who have accounts usestrong passwords. Make sure that they do not write passwords down in public view. If they mustbe written down, make sure their owners keep them in safe locations.

5. Change passwords frequently. Even good passwords can find their way into the wrong hands. Enforce mandatory password expiration so that any compromised passwords will be of limited value. Changing passwords every 90 days is a good guideline.

6. Restrict file system permissions.Carefully review what accounts have access to each drive, volume, and directory. Be especially mindful of the account associated with your Web server and of other anonymous accounts that users can access. Provide privileges to create and modify files in a directory only when absolutely necessary.

7. Review system accounts frequently.Disable or remove any accounts not needed.Disable any user accounts immediately after an employee leaves the organization. Monitor the system for any suspicious accounts—this is often the first indicator of the security intrusion.

8. Install machine-specific firewall software. Often called personal firewalls, this type of utility monitors all incoming and outgoing network traffic, blocking all unauthorized activity. For UNIX, TCP Wrappers continues to be popular; for Windows-based systems, consider something like ZoneAlarm (http://www.zonelabs.com).

9. Avoid running mail clients or Web browsers on servers. These two applications provide the means for viruses and worms to find their way onto servers. While necessary for end-user computers, they don't belong on servers to the same extent.Many server components must be installed through a Web interface, making it necessary to install a Web browser on the server. Connecting only to trusted sites will reduce the risk.

10. Maintain a thorough backup regimen. Even well-maintained servers can fall victim to an attack, or they might experience data loss through human error or hardware failure. Good backup practices will allow you to restore your system to working order with little or no loss of data.

It's often said that the only way to guarantee the security of a computer would be to keep it unplugged from any network. This is not exactly a practical option, especially in libraries where our main role involves providing access to information. We have to balance the risk factors against the accessibility and availability of information.As long as we give security issues a reasonable priority and maintain constant vigilance, we in libraries should be able to accomplish that balance, fulfilling our key mission with reasonable safety from the threats that exist in our dangerous world.