Perimeter Security

He looked at the screen in disappointment. He had seen others do it, but he wouldn't be doing it to this network. The library staff had done their homework. The popular ports were closed on the firewall or router. The web server was secured as tight as a drum. He had even sent an e-mail message with a bot attached to see if he could open a hole in the firewall. Either the e-mail address was dead, the library staff was wise to the exploit, or the firewall was configured to block outbound traffic addressed to the port he needed.

Maybe he would visit personally sometime, he thought.

Maybe not.

With a sigh he began scanning another site. This one wasn't worth the time.

Router/Firewall Security

Routers are network devices that "join" (or separate, depending on your view) two distinct networks. Routers allow data from one network to be transmitted to the other while keeping data intended for its own network from crossing over. Routers can be configured to allow or deny individual data packets access to the other network based on a number of parameters. Depending on need and expense, routers can be relatively simple to configure or very complex. The router's level of "protection" of an internal network from an external attack varies widely as a result.

A firewall is a device that usually assists a router in protecting the internal network. Normally it offers features in addition to those supplied by the router. One feature found on firewalls we've discussed previously, in our discussion of IP addresses. When private IP addresses are used on internal workstations that also need to access the Internet, the private IP addresses must be "translated" to public IP addresses. A firewall (but sometimes a router) usually supplies this service, called network address translation (or NAT).

Firewalls included with ISDN and DSL routers usually provide little protection beyond network address translation. These may suffice in very small library environments where no public servers (such as a web server) are used. If the library provides only Internet access, then the router/firewall can be configured to deny virtually all inbound requests, minimizing the risk of attack.

On the other hand, if the library will be providing web-based access to its library catalog, or will be contracting with a vendor for remote management of its network, then we recommend the use of a separate firewall device, now often called an Internet security appliance. These devices offer stateful packet inspection, additional functionality providing much more security against Internet-based attacks (such as denial-of-service attacks). Wherever possible, we advocate the use of standalone firewalls.

  • Use a three-port firewall; public services (web/ftp/e-mail) are provided on a separate network segment, the DMZ

One of the other features of many standalone firewalls or security appliances is a third network port (the first two ports connect to the library's internal network and the Internet connection). This port is normally referred to as a DMZ (demilitarized zone) port, to which the library would connect its public servers (web server, mail server, or others). This port provides controlled access to the public servers without putting them on the library's internal network, enhancing security of the internal network.

  • Implement network address translation (NAT), if possible

  • Use private IP addresses LAN-wide, if possible

As mentioned, the router or firewall must supply network address translation if the internal network is configured with private IP addresses.

  • Configure router to deny inbound access to unused ports (unless specific library services require them); for example, FTP on port 21, Telnet on port 23, and others

There are many Internet-based services besides the World Wide Web, which provides access to web pages. Older services include e-mail, file transfer protocol (ftp), and telnet (terminal emulation). Much of the router/firewall configuration will have to do with denying access to many of these services. In fact, if no public services are provided by the library (meaning, basically, the library does not maintain its own web server, or Internet-based access to its library catalog), then all inbound service requests can be denied.

Many outbound service requests may need to be blocked as well. For example, if your library policy states that patrons are not allowed to download files, one step in automatically implementing the policy would be to deny outbound connections to ftp servers. This will block some Internet downloads, but not all. Nevertheless, it's an attempt to make configuration consistent with policy. Outbound blocking will also help protect sites on the Internet should a library workstation become infected with a Bot, a software robot. (Bots can lead to Internet-connected computers participating in a coordinated attack on other sites and connections.)

  • Configure firewall so no packets with source addresses outside the LAN are allowed into the LAN, but only to DMZ

  • Firewall uses stateful packet inspection, providing protection against denial-of-service attacks and IP spoofing

  • Document settings for future use in reconfiguring router/firewall; make backup copy of router configuration file, if possible, and store in secure location

These items concern two common attack types that need to be blocked, if possible. This comprises a very basic level of security. The individual responsible for implementing your library's network securitymay choose more settings to protect against other potential threats. As you discuss firewall security with the vendor, document the decisions made, their justifications, and the firewall settings changed when they are implemented. Just like server setup, document all settings for use should the router/firewall ever have to be reconfigured from scratch (such as when defective equipment is replaced). If possible create an electronic copy of the router and firewall configuration files. This can make restoration of the settings much simpler if equipment must be replaced. Store the documentation in a secure location.

  • Schedule periodic installation of firmware updates

  • File all router/firewall documentation (papers/manuals/disks) for use by service technicians

Repeating earlier items, be sure the router and firewall firmware is upgraded as specified by the manufacturer. Some firewalls may have the capability to update themselves across the Internet during idle moments. (If your firewall has this feature, see if the update can be scheduled for non-peak times so that service disruption is minimized.) For a device that requires human implementation, I highly recommend having the update performed by a qualified network technician. This, of course, requires maintenance funding in the library budget.

Web Server Security

This section is included for any library providing web pages on its own web server. Libraries providing public access to their library catalog over the Web generally fall into this category. [Note: If a library is interested only in maintaining a general web site with no catalog access, I encourage contracting with a Web hosting provider. The Web hosting provider will take care of all the configuration, security, and maintenance of the server.]

Web server security actually involves two phases. The first is to secure the server itself. The second is to configure the web server software (Internet Information Server on most Windows NT/2000-based servers). Because the web server is accessible to Internet users, it is a common target of Internet-based attacks. One of the most common attacks involves defacing one or more web pages stored on the web server. This normally doesn't disrupt service so much as cause embarrassment. On the other hand, there are many tricks that allow an attacker to break into a web server, gain Administrator privileges, and potentially access other resources on the library's network. This is a much more substantial threat.

  • Implement normal server security steps as listed in Section 6 of the Checklist (with exceptions noted)

Many of the same steps required to secure a Windows NT/2000 file or logon server apply to securing the server upon which the web server software is built. Repeat the server security as indicated. The configuration of the web server software adds a surprising number of additional items.

  • Configure web server as standalone server (especially not a domain server)

The web server should be a completely separate computer made available on a separate network segment attached to the firewall. In particular, the web server should not be the library's main file server, with IIS running in addition to everything else and Internet users allowed to pass through the library's firewall to access web pages. Such a configuration is courting disaster! When installing Windows NT/2000, the server should be installed as a "standalone server," not a domain controller or a member server.

  • Configure web server to run as separate user (not with root or admin privileges)

No web server software should have administrator privileges. Should an attacker break in, he would have the same privileges.

  • Secure the anonymous IIS account

It is possible to authenticate users (requiring logon names and passwords) to a web site. You may have accessed a web page that popped up a logon box. These require specific user accounts on the server. Most web pages are not protected this way and operate under an account called the anonymous user. IIS uses one account (IUSR_computer name) for this service. In order to keep attackers from accessing the server through this account, security experts recommend renaming the account on your server and then creating a new account with the IUSR name. The new IUSR account can be disabled, and access attempts logged to track any break-in attempts.

  • Disable directory browsing

In IIS and other web servers, it is possible to turn off directory browsing. Directory browsing means listing the contents of a directory contained in the main web documents folder. It can be dangerous to allow Internet users to see directories where scripts and other sensitive information are stored. Turn off directory browsing for all web folders or at minimum for any script folders.

  • Set proper file system access permissions

In the folder containing all documents shared through the web server, make sure that the Write permission is never assigned to a file also having Script/Execute permission through IIS. This could potentially allow an attacker to upload a script file, which he could then execute on the server. Make sure that scripts only have Script permission (and not Execute). Finally, place the script-interpreter (such as Perl or PHP) into a different folder than the folder where its scripts are stored.

  • Remove unnecessary services

  • Remove unnecessary files/programs

These two echo similar items for server security. It is especially important to turn off any unneeded services. It is also a good idea to remove any unneeded files or programs from the web server, since a limited configuration gives an attacker less bullets to use in shooting at your network.

  • Unless absolutely required, remove FrontPage extensions if installed

If your web site was constructed using Microsoft FrontPage, some additional files called FrontPage Extensions are required on the web server for users to properly view your web pages. The Extensions (especially for older versions of FrontPage) can open security holes in your server configuration. If your web site was designed with some other program, but these extensions are installed, they should be removed.

  • Restrict scope of indexing if Index Server is used

Index Server is a utility that comes with IIS. It can be very helpful in making textual documents stored on your web server searchable. It can also be dangerous if it indexes script and other sensitive files stored on your site. If the utility is used, restrict the folders it indexes just to those storing non-sensitive files.

  • Configure registry settings for proper IIS security

  • Document settings for future use in reconfiguring web server, and store in secure location

There are other registry settings that may be configured to enhance IIS security. A list of these is available in other resources. As with all servers, be sure to document all the decisions made in configuring the web server, and store them in a controlled location.

  • Configure web server auditing and audit logs properly

  • Implement procedure for creating/monitoring audit logs

Just like any server, it is important to audit system activities and review the logs created. By doing so regularly, one may discover the probes of an attacker before any lasting damage is done.

  • Have a trusted source review for security flaws any CGI-type scripts (downloaded from Web or developed locally) used in web pages

Many web sites make use of a variety of forms and server-based scripts to process the data supplied in them. There are a number of ways to create security holes inadvertently by using insecure coding practices. If you've downloaded scripts from the web and use them on your web pages, or if someone whose experience you are unsure of has assisted in designing your web pages, have the scripts reviewed by a trustworthy third party.

  • Update IIS web server software with patches as soon as they are released by Microsoft; repeating 4-42, update the web server's underlying NT/2000 operating system as patches are released by Microsoft (several recent break-ins are directly attributable to the lack of applying patches to protect against well-known vulnerabilities)

  • Subscribe to Microsoft's Product Security Notification service

The requirement to update IIS with current patches is probably the most important of all the items. Many commercial web servers have been broken into, resulting in stolen credit card databases and other sensitive data disclosure. Most of the break-ins came as a result of a lack in diligence in applying patches to Windows NT/2000 and IIS. The need for this one item cannot be overemphasized! It is also important to remember to patch the underlying Windows NT/2000 Server operating system regularly, too. Be sure to subscribe to Microsoft's Product Security Notification service (see page 146 in the bibliography for the contact site), which provides e-mail notification of security problems as they arise with Microsoft products. It's the best way to know when patches are available.

  • File web server documentation (papers/manuals/ disks) for use by service technicians

As with all servers, file the documentation for the server and for IIS so that it can be accessed easily by service technicians when maintenance or repair needs to be performed on the server.

Virtual Private Network (VPN) Security

Virtual private networks are "simulated" private connections over the Internet between an individual computer (or other network) and an organizational network-the library network in this case. These types of Internet-based connections use encryption technology to encapsulate all of the information between the endpoint and the library network and protect it from spying eyes.

Virtual private networks require special server configuration and firewall configuration to implement, and not many local vendors have experience in setting them up. Therefore, the time, frustration, and expense factors present a deterrent in small libraries. Nevertheless, the concept is attractive because it presents a way to allow remote maintenance and administration of library networks.

This is an area of security that will be expanded here in the future. For now, the following features are recommended for any VPN solution implemented in libraries.

  • Supports Microsoft's point-to-point tunneling protocol (PPTP) or IPSec

  • Document all server changes required to support the VPN

  • Document firewall configuration changes required to support the VPN

Continue to Part Three


Page last modified: March 2, 2011