Installing the Operating System

Once you have chosen an operating system, you should make sure you have the necessary hardware, software, and configuration information to install it. You can then install it, taking extra care to make sure you install and configure only what you need and disable what you don't.

Preparing for the OS Installation

After selecting your operating system, you can begin to plan your build. Before the actual build process begins, you need to confirm some preliminary information and resources. The following checklist covers most of the important considerations. Complete this checklist before you begin the installation process?it will simplify the build process and identify any configuration issues before you begin building the box(es).

• Do you have the required hardware?

  - Ensure that you have enough network interface cards. It never hurts to have extra network ports handy in case your network grows.

  - Ensure that you have the disk space for logs on your management console.

• Do you have the operating system installation media?

  - Ensure that you also have a proper license for your operating system (if necessary).

  - Determine which version of the operating system you are going to install.

  - Obtain the latest system patches or service packs.

• Do you have the FireWall-1 installation media or can you get it from an accessible FTP server?

  - Obtain the proper licenses.

  - Obtain the latest service/feature packs for FireWall-1.

  - If installing via FTP, determine the IP address of the FTP server.

  - If installing via FTP, determine the username and password necessary to access this software.

  - If installing via FTP, ensure that it is accessible from where you plan to install the platform.

• How will you configure the operating system? Establish the system configuration by determining the following information:

  - System name

  - Name, IP address, and netmask of all interface cards

  - IP address of the DNS server

  - Default router and additional network routes

  - Routing protocols (BGP, OSPF, RIP)

  - Disk partitions

  - User accounts and passwords

• How will you configure the firewall? Determine the following information for the firewall configuration:

  - IP address(es) of machine(s) that will run the GUI client

  - IP addresses of remote modules or management module (if required)

  - Accounts for firewall administration

Guidelines for the OS Installation

Once you have identified the required information, you can begin the build process. The first step in building your operating system is to start with a new installation. Never trust previous installations of an operating system. By installing and configuring the operating system from scratch, you know exactly how it has been configured and can better trust it. Each operating system has its own unique installation process. You will want to build an installation checklist for your particular operating system.

When you receive a Nokia IP Security Platform from the factory, it comes preinstalled with IPSO and a fresh configuration you must configure via a consolecable. These installations can generally be trusted, but it is likely that an earlier version of either FireWall-1 or IPSO is loaded on the platform. You can either upgrade the existing software or simply reinstall the system from scratch from an FTP server where you have loaded all of the necessary software bits.

During the installation and build procedure, ensure that the system is never attached to a live network. Attaching an unsecured operating system to a network exposes it to a variety of risks. It is quite possible to have a system probed, attacked, and compromised within 15 minutes of being connected to the Internet! If you need to add software to your system, such as OS patches or additional software, use an intermediate system to download the required software. You can then either burn the software to a CD or directly connect the two systems over a private, secured network.

Once the operating system has been installed, the next step is to configure it for your environment. This usually consists of adding system accounts (in a secure manner discussed in Securing the Operating System, below) and configuring all networking including DNS. This is where the preceding checklist comes in handy. Remember, the operating system?not FireWall-1?is responsible for all networking and routing. The firewall only determines what can and cannot happen. Once a session has been approved or authenticated by the firewall, it is up to the operating system to send the packets in the correct direction. You must ensure that you set up networking properly, or traffic will not reach its destination. Each operating system has its own specific ways of setting up interfaces and routing. If you are employing address translation, refer to Chapter 10 for additional notes about changes to routing that might need to be made.

Once the system has been fully secured and configured, build a lab network that replicates the network point your firewall will protect. Have lab equipment replicate the routers and networks the firewall will route from and to. This way your network configurations can be tested before being implemented. Unfortunately, many organizations do not have the luxury of a lab to test their configurations. A second technique is to verify the system configuration during the implementation phase. Once the system is ready and the firewall has been installed and configured, the box is deployed on the network. Once plugged into the network, turn off both the firewall and routing on the box (do this only with a fully armored system). Then, from the box, attempt to ping every network that should be accessible from the firewall, including the Internet. The key point is to confirm that the operating system is properly configured before turning on the firewall. If the system can ping every network it is supposed to, more than likely, the system is properly configured. If you cannot ping a network that should be accessible, fix the problem before turning on the firewall. Once again, use this method only with a fully armored system and IP routing turned off. You won't be able to test routing through the firewall in this configuration, but you can ensure that the firewall knows how to get everywhere it is supposed to.

Securing the Operating System

The entire purpose of a firewall is to secure your resources. However, a firewall is only as secure as the operating system it resides on. If the operating system is compromised, so is the firewall, defeating your organization's security. Therefore, you need to build the operating system as securely as possible. Each operating system has unique and specific issues. For detailed examples on how to properly build a secure system for a firewall, see Appendix A. However, there are standard concepts that apply to every operating system; these are described here.

The OS hardening process begins with the installation. Most UNIX systems allow the user to select the applications or packages to install during the installation process. By selecting the minimal installation possible, you can limit the vulnerabilities present in the new operating system. With other operating systems, such as Windows 2000, lots of unnecessary components are installed by default, and no choice is given as to whether or not to install them. Once the installation is complete, additional services, such as Workstation and Server, need to be removed or disabled.

Once the operating system has been loaded, you should remove any unnecessary applications and software that were installed. If the firewall does not require a particular application, remove it. The new system should be a dedicated firewall. Do not run other applications on it, such as DNS, a Web server, a mail server, a Windows domain controller, and so on. The more applications you have on your system, the greater the risk for compromise. If an application is not installed, it cannot be compromised. As discussed earlier, this armoring process begins during installation, where you install only the bare minimum of software required. Once the installation is complete, ensure that all other unnecessary services are turned off. You can verify that services are not running by running netstat -na and making sure that you can account for all the ports shown as listening. You can also run a port scanner against the system to validate what netstat ?na shows you. Even if a service is not running, binaries remaining on the operating system can be locally exploited; these need to be removed. Several of the descriptions in Appendix A explain how to remove binaries for unused programs (e.g., removing packages in Linux/Solaris).

The firewall should be as isolated as possible from other components within the network. This means that a firewall operating system should not participate in any network logon scheme such as a Windows Domain/Active Directory or Network Information Service (NIS). These kinds of services not only increase the risk of compromise but also create the possibility you will not be able to log into the firewall if the authentication server is down. All authentication should be done locally using strong passwords (abc123 is not a strong password), or perhaps authenticating against a one-time password system such as S/Key or even SecurID. For name resolution, you can't entirely get away from DNS, but it is important that the local host file on the firewall operating system contain entries for critical servers within the infrastructure. This will reduce the delays that will occur in interaction with the firewall when DNS is offline.

The next step is to patch the operating system. New exploits and vulnerabilities are constantly being identified for all operating systems. Patches help protect against these known vulnerabilities. Make sure the new system is fully patched after the initial installation. For Windows, this requires the latest service packs and hotfixes. For Solaris, it is advised to install the latest recommended patch cluster from Sun. Patching an operating system is not a one-time event; due diligence must be exercised to ensure that all the latest security patches are applied. Security Focus (http://www.securityfocus.com) is an excellent source for this information. As new vulnerabilities are discovered, vendors release new patches to update their operating systems.

After you have applied all the latest patches and hotfixes, you should update and secure whatever services and applications you are running on the box just as you would your operating system. Most services can be secured to some extent. If the service cannot be secured, you may want to replace it with an alternative or eliminate it all together. For example, if you are running Telnet or FTP daemons on UNIX systems, you will want to install TCP wrappers to limit who can access these services. Replacing these services with more-secure applications is an even better solution. SSH can be used like Telnet and FTP to log on to a system and transfer files to a system. It also provides stronger authentication and encryption than Telnet or FTP alone. Regardless, ensure that any additional applications you are running on the operating system are current and secured.

Logging is another critical feature. Just like the firewall, most operating systems log user and kernel activity on the system. Make sure your operating system is logging important events. This helps you troubleshoot better because logs can often warn you if something is going wrong. They can also let you know if someone is trying to break in, because logon failures are usually logged. Logs also leave an audit trail, telling you who did what, which is especially important when something goes wrong. Many organizations use a dedicated log server to store system logs. The firewall operating system can be configured not only to log all system information locally but also to send the logs over the network to the dedicated log server. This ensures two sources of logging information in case one source becomes corrupted or inaccessible. Regardless of which options you choose, ensure that your operating system is logging all system and user activity. However, also note that too much logging can slow the system down, so although logging is a good thing overall, judicious use is best.

In addition, you should secure user access to the operating system. More than one person, but not too many, should have access to the system. Limit the access to a small group of people who are trusted?three is a good number. The more people who have access to the operating system, the greater the chance that something can go wrong. These accounts should have hard-to-guess passwords or even require a one-time password scheme. You should also establish these accounts on the local system only. Do not use any network login scheme like NIS or a Windows Domain Logon, but SecurID or some other one-time password scheme is acceptable.

Never use a generic account for the initial login. Often, part of breaking into a system is choosing the right username to try. A hacker tries common usernames like admin, root, fwadmin, guest, and so on because they are highly likely to exist on a system. Disable these logins, if possible, and require a login that identifies a specific user. This same rule applies to the firewall administrator account used to access the FireWall-1 Management GUIs (more about these in Chapter 4).

Always require users to first authenticate themselves; then allow them to gain the necessary access. This procedure builds in at least two layers of authentication (which is more secure) and leaves an audit trail of who is doing what. Windows 2000 provides a RunAs feature that allows you to run commands with greater privilege. Windows NT also has similar functionality through the use of third-party applications. Make sure users have only the access they absolutely require. Do not give them root or administrator access if they do not require it to administer or maintain the system. The same is true for the FireWall-1 Management GUIs.

As far as routing goes, I generally recommend using static routes on a firewall. If you must use dynamic routing, which makes sense in complex environments, ensure that you have enabled authentication within the routing protocol to limit the possibility of importing spoofed routes, and log any authentication failures. Avoid using RIP, if at all possible, because it's relatively easy to pollute a RIP routing table. Additionally, you can use FireWall-1 to restrict who is allowed to send routing updates.