© 1997 The McGraw-Hill Companies, Inc. All rights reserved. Any use of this Beta Book is subject to the rules stated in the Terms of Use.

Chapter 7

What is an Internet/Intranet Firewall After All?

As I wrote in a book I co-authored with Ablan and Yanoff, by Sams.Net (Web Site Administrator’s Survival Guide), the first time I heard about firewalls was with my mechanic. Seriously! He was explaining to me that cars have this part that separates the engine block from the passenger compartment, and it’s called a firewall. If the car explodes, the firewall protects the passengers.

Similarly, a firewall in computer terms protects your network from untrusted networks. On one side you have a public network, without any kind of control over what is being done, how or where. On the other side you have the production network of a company with a corporate network that must be protected against any damaging action. Some even question: if we really need to protect a corporate network, so then why allow a network of public domain, such as the Internet, to access it.

The reason is simple: It’s a matter of survival! Companies rely more on the Internet to advertise their products and services. The Internet is growing tremendously, just like big market places and shopping malls, more people are coming to the Internet. The more that come, the more security is necessary to guarantee the integrity of products sold, as well as the safety of those participating in this market (a.k.a., electronic commerce). It has become necessary to protect data, transmissions and transactions from any incidents, regardless if the cause is unintentional or by malicious acts.

This chapter discusses the mechanisms used to protect your corporate network/Intranet and/or Web servers against unauthorized access coming from the Internet or even from inside a protected network. It also reviews what firewalls are after all and how important they are in providing a safe Internet connection. You will learn about the following:

• The purpose of firewalls
• Advantages and disadvantages of firewalls
• Basic design decisions
• Threats and countermeasures provided by firewalls
• Major firewall vendors (a more detailed list is in the Appendix)
• Firewall procurement and administration
• How to install a typical firewall

What are Firewalls After All?

There are several models and configurations of firewalls out there, but the basic idea behind it is always the same. You need to allow users from a protected network, such as your corporate network, to access a public network, such as the Internet, and at the same time, to make available to this public network the services and products of the company.

The problem is that when your company is connected to the Internet without proper security measurements in place, you become exposed to attacks from other servers on the Internet. Not only does your corporate network become vulnerable to unauthorized access, but also do all other servers in your corporate network.

Therefore, when you begin to plan out how you will protect your network from the many threats the Internet can bring you will start by thinking about firewalls. However, even before thinking about it, you must define how and which services and information you will make available to the Internet. Evidently, and first of all, you will want to make sure that your server is secure. You will have to be able to block unauthorized login access, file transfer access, and remote command execution, and perhaps even deny services such as Rlogin, telnet, (t)FTP, SMTP, NFS, and other RPC services. Once you start to use, or have access to these services, that’s when you will need to build a firewall. Figure 7.1 gives you a basic idea of a firewall and its purpose.

But what is a firewall anyway? Basically, a firewall separates a protected network from an unprotected one, the Internet. It screens and filters all connections coming from the Internet to the protected (corporate) network, and vice versa, through a single, concentrated security checkpoint. A firewall makes sure that you cannot reach the Internet from the internal network, nor vice versa, unless you pass through this checkpoint (also known as choke-hold firewall). Some systems even require you to telnet the firewall.

But even before you define what type of firewall best suites your needs you will need to analyze the topology of your network to determine if the various components of your network, such as hubs, switches, routers and cabling are suitable for an specific firewall model. Chapter 10, "Putting It Together: Firewall Design and Implementation," provides information on what to look fort in a firewall, according to your corporate environment and security needs. Also, chapter 14, "Types of Firewalls," provides an extensive list of the main firewall products and in-depth information about their technology, security and management features.

To better understand a firewall and its purpose you should have a more detailed understanding of what a firewall and this protection barrier is. You need look at your corporate network based on the layers of its International Standards Organization (ISO) model. There you find the repeaters and hubs acting at the first layer, switches and bridges acting at the second layer and routers at the third layer. A firewall passes through all these layers as it acts at the sixth and seventh level, the layers responsible for the session establishment controls and applications. Thus, with a firewall we can control the flow of information throughout the establishment of sessions or even by determining which operations will or not be allowed.

However, as you will see, a firewall does more than protect you against the electronic version of airbrushing someone else’s wall or breaking glass windows on the digital street. It will help you manage a variety of aspects on your gate to the Web by keeping the jerks out while enabling you to concentrate on your job.

The Purpose of a Firewall

Say you have just acquired a car. It’s blue with four doors. Is an alarm enough to secure it? In case the car disappears, its color and the fact it has four doors won’t make much difference. I’m sure you wouldn’t be so casual about it. You probably would have insurance for it and would list its vehicle identification number, any accessories it has, plate numbers, and so on. But believe it or not, many companies treat the security of their network assets especially data communication and internetworking assets very lightly. Often there will be no policies, or any sort of record keeping, where the security of their systems are treated with much less information than you would with your car.

That’s where firewalls come in, but you must realize that a firewall alone will not secure your network. It is only part of a broader area in protecting your web site and networking in general.

In order to secure your corporate network, you must define your idea of a network perimeter. You need to determine what things must be protected, develop a security policy, and establish mechanisms to enforce the policy and methods you are going to employ. Of course, there are mechanisms besides the firewall that you can add to tremendously increase your level of security.

These mechanisms must come after your security policy is developed, not before. This should be the main idea you should retain for this section: to define a security mechanism that will protect your corporate site , in specific firewalls, and to provide you with the prerequisites to implement it. Policies and procedures are one indispensable prerequisite. The methods you are going to employ and your analysis of the results are another.

Many companies and data centers are guided by computing security policies, particularly those organizations in the public sector that are likely to be a target, such as the Department of Defense (DoD) and other government agencies. Procedures are established that must be adhered to. Curiously, it rarely happens with the private sector, especially when it comes to connecting to the Internet. You would be surprised to learn that many private companies very often neglect the development of a security policy, and therefore their security mechanisms are weak if not faulty.

Security policies vary from organization to organization, of course, but one issue that will set these policies aside will be the platform for what they are being developed. I firewall can be implemented on UNIX, NT, DOS or a proprietary platform. You must look closely at the platform you will be choosing, as it will definitely define all future projects, level of security and consequently the security policy being developed. That’s why a security policy must come first to guarantee the success of the mechanisms that will be implemented.

As a LAN or Web administrator, you already know that the hardest part of connecting your corporation to the Internet is not justifying the expense or effort, but convincing management that it is safe to do so, especially at a large companies. A firewall not only adds real security, but also plays an important role as a security blanket for management.

Furthermore, have you ever thought about the functions of a United States Embassy in other countries? A firewall can act just like one. As your corporate ambassador to the Internet, a firewall can control and document the foreign affairs of your organization.

The Firewall Role of Protection

A firewall greatly improves network security and reduces risks to servers on your network by filtering inherently insecure services. As a result, your network environment is exposed to fewer risks because only selected protocols are able to pass through the firewall.

For example, a firewall could prohibit certain vulnerable services such as NFS from entering or leaving a protected network. This provides the benefit of preventing the services from being exploited by outside attackers, but at the same time permits the use of these services with greatly reduced risk of exploitation. Services such as NIS or NFS that are particularly useful on a Local Area Network basis can thus be enjoyed and used to reduce the server management burden.

Firewalls can also provide protection from routing-based attacks, such as source routing and attempts to redirect routing paths to compromised sites through ICMP redirects. It could reject all source-routed packets and ICMP redirects and then inform administrators of the incidents.

The problem with firewalls, though, is that they limit access to and from the Internet. In some configurations, you may decide to use a proxy server, which is explored in more detail later to filter the inbound and outbound access your policy has determined to be safe

Firewalls Providing Access Control

A firewall can provide access control to site systems. For instance, some servers can be made reachable from outside networks, whereas others can be effectively sealed off from unwanted access. Depending on the level of risk you are willing to take in your corporate network, watch for outside access to the internal network servers, except for special cases such as mail servers or RAS services.

Also, watch for viruses being downloaded by users via e-mail and spread throughout the protected network. Another threat are that so called applets (mainly Java, JavaScript and ActiveX), that could initiate remote process on a workstation that could affect a server or even disable a firewall.

This brings us to one of the main purposes an access policy is particularly adept at enforcing: Never provide access to servers or services that do not require access as they could be exploited by hackers since the access is not necessary or required.

The Security Role of a Firewall

A firewall can actually be less expensive for an organization in that all (or most) modified software and additional security software can be located on the firewall system than if distributed on each server or machines. In particular, one-time-password systems and other add-on authentication software can be located at the firewall rather than be on each system that needs to be accessed from the Internet.

Also, don’t neglect internal security. Very often too much emphasis is giving to the firewall, but if a hacker cracks in, unless you have some internal security policy in place, your network will be exposed. That’s why many times it might be a good idea to place the server to be available to the Internet outside of the firewall. The services on this server will very likely become exposed to the Internet threats, but you could easily have a replica of the server inside the firewall and available for quick recovery. You could also keep all the systems configuration of the external server in a CD-ROM, making it secure against modifications.

Other solutions to your corporate network security could involve modifications at each server system. Although many techniques are worthy of consideration for their advantages and are probably more appropriate than firewalls in certain situations, firewalls tend to be simpler to implement, because only the firewall needs to run specialized software, unless if you have a package filtering firewall or require your users to Telnet it. In this case, you either will need a router filtering the packages or a dedicated machine.

Promoting Privacy with a Firewall

Privacy should be of great concern for every corporate network because what normally would be considered innocuous information might actually contain clues that would be useful to a hacker. By using a firewall, your site can block access from services such as Finger and Domain Name Service, for example. Finger, to refresh, displays information about users such as their last login time, whether they’ve read mail, and other items. But Finger can also reveal information to hackers about how often a system is used, whether the system has active users connected, and whether the system could be attacked without attracting the attention of administrators and other monitoring systems.

Another advantage of using a firewall at your site is that by having all access to and from the Internet passing through a firewall, you can log accesses and provide valuable statistics about network usage.

Advantages and Disadvantages of Firewalls

Besides logins and statistics, there are many other advantages to using firewalls. Despite these advantages, you should be aware that there are also a number of disadvantages: things that firewalls cannot protect against, such as access restrictions, back-doors treats (modem and/or RAS servers by-passing the firewall), and vulnerability to inside hackers, to name a few. Chapter 10, "Putting it Together: Firewall Design and Implementation" provides a summary of the pros and cons of the different types of firewalls available.

Access Restrictions

Obviously, a firewall will very likely block certain services that users want, such as Telnet, FTP, X Window, NFS, and so on. These disadvantages are not unique to firewalls alone, however network access could be restricted at the server level as well, depending on a site’s security policy. A well-planned security policy that balances security requirements with user needs can help greatly to alleviate problems with reduced access to services.

Nonetheless, some sites might lend themselves to a firewall due to their topology, or maybe due to services such as NFS, which could require a major restructuring of network use. For instance, you might depend on using NFS and NIS across major gateways. In this case, your relative costs of adding a firewall would need to be compared against the cost of exposure from not using a firewall.

Back-Door Challenges: The Modem Threat

By now, you have figured that existing back doors in your corporate network are not protected by firewalls. Therefore, if you have any unrestricted modem access, it is still an open door for hackers who could effectively use the access to bypass the firewall. Modems are now fast enough to make running SLIP (Serial Line IP) and PPP (Point-to-Point Protocol) feasible. A SLIP or PPP connection inside a protected subnet can also very easily become a potential back door. So if you are going to allow SLIP or PPP to exist without any kind of monitoring, why bother to have a firewall?

Risk of Insider Attacks

Generally, there is not much protection a firewall can provide against inside threats. Although a firewall might prevent outsiders from obtaining sensitive data, it does not prevent an insider from copying files or stealing information.

It is not safe to assume that a firewall provides protection from insider attacks. It would be unwise for you to invest resources in a firewall if you don’t close the door of your systems to insider attacks as well.

Despite these disadvantages, I strongly recommend that you protect your site with firewalls.

Firewall Components

The basic components in building a firewall include:

• Policy
• Advanced authentication
• Packet filtering
• Application gateways

The following topics give you a brief overview of each of these components and how they affect your site’s security and, consequently, the implementation of your firewall.

Network Security Policy

The decision to set up a firewall can be directly influenced by two levels of network policy:

• Installation
• Use of the system

The network-access policy that defines services that will be allowed or explicitly denied from the restricted network is the high-level policy. It also defines how these services will be used. The lower-level policy defines how the firewall will actually restrict access and filter the services defined in the higher-level policy. However, your policy must not become an isolated document sitting in a drawer or a shelf it would be useless. The policy needs to become part of your company’s security policy. Let’s take a brief look at different types of security policies.

Flexibility Policy

If you are going to develop a policy to deal with Internet access, web administration, and electronic services in general, it must be flexible. Your policy must be flexible because:

• The Internet itself changes every day at a rate that no one can follow including books, by the way. As the Internet changes, services offered through the Internet also change. With that, a company’s needs will change also, so you should be prepared to edit and adapt your policy accordingly without compromising security and consistency. But remember: a security policy almost never change, but procedures should always be reviewed!
• The risks your company faces on the Internet are not static, either. They change every moment, always growing. You should be able to anticipate these risks and adjust the security processes accordingly.

Service-Access Policy

When writing a service-access policy, you should concentrate on your companies’ user issues as well as dial-in policy, SLIP connections, and PPP connections. The policy should be an extension of your organizational policy regarding the protection of Information Systems (IS) resources in your company. Your service-access policy should be realistically complete. Make sure you have one drafted before implementing a firewall. The policy should provide a balance between protecting your network and providing user access to network resources.

Firewall Design Policy

A firewall design policy is specific to the firewall. It defines the service-access policy implementation rules. You cannot design this policy without understanding the firewall capabilities and limitations, as well as the threats and vulnerabilities associated with TCP/IP. As mentioned earlier, firewalls usually do one of the following:

• Permit any service unless it is expressly denied.
• Deny any service unless it is expressly permitted.

A firewall that implements the first policy allows all services to pass into your site by default, except for those services that the service-access policy has determined should be disallowed. By the same token, if you decide to implement the second policy, your firewall will deny all services by default but then will permit those services that have been determined as allowed.

As you will surely agree, to have a policy that permits access to any service is not advisable because it exposes the site to more threats.

Notice the close relationship between the high-level service-access policy and the lower-level one. This relationship is necessary because the implementation of the service-access policy depends on the capabilities and limitations of the firewall systems you are installing as well as the inherent security problems that your Web services bring.

For example, some of the services you defined in your service-access policy might need to be restricted. The security problems they can present cannot be efficiently controlled by your lower-level policy. If your company relies on these services, which usually Web sites do, you probably will have to accept higher risks by allowing access to those services. This relationship between both service-access policies enables their interaction in defining both the higher-level and the lower-level policies in a consistent and efficient way.

The service-access policy is the most important component in setting up a firewall. The other three components are necessary to implement and enforce your policy. Remember: the efficiency of your firewall in protecting your site will depend on the type of firewall implementation you will use, as well as the use of proper procedures and the service-access policy.

Information Policy

As an Internet manager, or even LAN or web administrator, if you intend to provide information access to the public, you must develop a policy to determine the access to the server (probably a web server) and include it in your firewall design. Your server will already create security concerns on its own, but it should not compromise the security of other protected sites that access your server.

You should be able to differentiate between an external user who accesses the server in search for information and a user who will utilize the e-mail feature, if you are incorporating one, for example, to communicate with users on the other side of the firewall. You should treat these two types of traffic differently and keep the server isolated from other sites in the system.

Dial-in and Dial-out Policy

Remote-access systems add useful features to authenticated users when they are not on-site or cannot access certain services or information through the company’s web site. However, users must be aware of the threat of unauthorized access that a dial-in capability can generate.

You must be able to demonstrate the vulnerabilities that this feature will create if users are not cautious when accessing the internal network through a modem. A user’s dial-out capability might become an intruder dial-in threat.

Therefore, you must consider dial-in and dial-out capabilities in your policy when designing your firewall. You must force outside users to pass through the advanced authentication of the firewall. This should be stressed in your policy, as well as the prohibition against unauthorized modems attached to any host or client that were not approved by MIS (Management of Information Systems) or are not passing through the firewall. Your goal is to develop a policy strong enough to limit the number of unauthorized modems throughout the company. By combining such a policy with an efficient pool of modems, you will be able to reduce the danger of hacker attacks on your company using modems as well as limiting your vulnerability.

Another factor you should consider involves web servers. Worse than having a modem line that enables dial-in and dial-out capabilities is the use of serial line IP (SLIP) or Point-to-Point Protocol (PPP) through the Web server or any other means of access to the company network. By far, it is a more dangerous back door to your system than modems could ever be, unless, of course, you pass it through the firewall.

Advanced Authentication

Despite all of the time and effort writing up policies and implementing firewalls, many incidents result from the use of weak or unchanged passwords.

Passwords on the Internet can be cracked in many ways. The best password mechanism will also be worthless if you have users thinking that their login name backwards or a series of Xs are good passwords!

The problem with passwords is that once an algorithm for creating them is specified, it merely becomes a matter of analyzing the algorithm in order to find every password on the system. Unless the algorithm is very subtle, a cracker can try out every possible combination of the password generator on every user on the network. Also, a cracker can analyze the output of the password program and determine the algorithm being used. Than, he just need to apply the algorithm to other users so that their passwords can be determined.

Furthermore, there are programs freely available on the Internet to crack user’s passwords. Crack, for example, is a program written with the sole purpose of cracking insecure passwords. It is probably the most efficient and friendly password cracker available at no cost. It even includes the ability to let the user specify how to form the words to use as guesses at user’s passwords. Also, it has a built-in networking capability, which allows the load of cracking to be spread over as many machines as are available on the network.

Also, you should be aware that some TCP or UDP services authenticate only to the level of server addresses and not to specific users. An NFS server, for example, cannot authenticate a specific user on a server it must grant access to the entire server. As an administrator, you might trust a specific user on a server and want to grant access to that user, but the problem is that you have no control over other users on that serve, and will be forced to grant access to all users. It’s all or nothing!

The risk you take is that a hacker could change the server’s IP address to match that of the trusted client (the user you trust). The hacker could then construct a source route to the server specifying the direct path that IP packets should take to your web server and from the server back to the hacker’s server all this using the trusted client as the last hop in the route to your server. The hacker sends a client request to the web server using the source route. Your server accepts the client request as if it came directly from the trusted client, and returns a reply to the trusted client. The trusted client, using the source route, forwards the packet on to the hacker’s server. This process is called IP spoofing.

Figure 7.2 shows a basic example of a spoofed source IP address attack. Even though most routers can block source-routed packets, it’s still possible to route packets through filtering-router firewalls if they are not configured to filter incoming packets whose source address is in the local domain. This attack is possible even if no reply packets can reach the attacker.

The following are examples of configurations that are potentially vulnerable to those attacks:

• Routers to external networks supporting multiple internal interfaces;
• Routers with two interfaces supporting subnets on the internal network, and
• Proxy firewalls where the proxy applications use the source IP address for authentication.

Please note that in the figure 7.2 the attack shown won’t work if you have a properly configured router. Before about couple year ago, it would have worked, but after Kevin Mitnick, all the router vendors came out with fixes and told their customers to implement them. Most have, but the illustration is still valid though as many UNIX servers will still accept source-routed packets and pass them on as the source route indicates. Routers will accept source-routed packets as well, although most routers can block source-routed packets.

Couple years ago, the Internet Computer Emergency Response Team (CERT) sent out a security alert describing how hackers were using IP spoofing to break into many Internet sites. More than 23 million university, businesses, government facilities, and home computers connected to the Internet are exposed to the threat of having information stolen, systems time-bombed, and data corrupted through worms, Trojan horses, and viruses. All this, most of the time, for fun.

These kinds of attacks are usually aimed at applications that use authentication on source IP addresses. When the hacker can pass the packet, access to unauthorized data will be totally available. Keep in mind that the hacker doesn’t have to get a reply packet back this break-in is possible even without it. Moreover, some network administrators tend to believe that disabling source routing at the router would prevent it. Not so! It cannot protect the internal network from itself.

If you have a router to external networks that supports multiple internal interfaces, you should consider a firewall because you are potentially exposed to hacker spoofing attacks. The same is true for routers with two interfaces supporting subnets on the internal network, as well as proxy firewalls if the proxy applications use the source IP address for authentication.

Usually, what the hackers want is to access the root directory of your UNIX box. Once inside, they can dynamically replace telnetd and/or login, which enable them to capture existing terminal and login connections from any user on the system. This enables them to bypass the authentication schemes.

According to CERT, there are two steps you can take in order to prevent this kind of attack:

• Install a filtering router that will restrain the input to the external interface if it identifies the packet source as coming from inside the network. Even if it’s an authenticated one, it won’t go through.
• Filter outgoing packets to determine if the address is different from the internal network, so that attacks originated from inside can be prevented.

Figure 7.3 describes the CERT’s recommendation for preventing IP spoofing. In this model, any external incoming packets must go through an additional router installed between the external interface (A) and the outside connection (B). This new intermediary router should be configured to block packets that have internal source address (C) on the outgoing interface connected to the original router.

If lack of security is risky, excessive complexity in configuration and controls is also. Use common sense, use the KISS (keep it simple... err steward) method. Server-access controls can be complex to configure and test.

One of the first things you should probably tell your Internet users is to choose passwords that are difficult to guess. You also tell them not to share their passwords with anyone. However, most users don’t follow this advice, and even if they did, hackers can monitor passwords that are transmitted. One of the most effective alternatives to fight the hacker is to adopt advanced authentication measures.

Smartcards, such as credit card-like ID cards and other magnetic encoded cards, and software-based mechanisms are alternatives to cope with the weaknesses of traditional passwords. If you adopt one of these advanced authentication devices, hackers will not be able to reuse a password that was monitored during a connection. If you consider all of the inherent problems with passwords on the Internet, an Internet-accessible firewall that does not include some kind of advanced authentication system does not make much sense. The few mistakes and threats discussed previously give you an idea of what you are facing when announcing your new web site.

Some of the more popular advanced authentication devices in use today are called one-time password systems. A smartcard, for example, generates a response as an authenticator instead of a traditional password. It works in conjunction with software or hardware. Even if monitored, it can be used only once. The firewall’s advanced authentication system should be located in the firewall because it centralizes and controls access to the site. You could install it on another server, but loading it on a firewall makes it more practical and manageable to centralize the measures.

Figure 7.4 illustrates what happens when advanced authentication is present. All connections and requests for sessions such as Telnet or FTP originating from the Internet to site systems must pass the advanced authentication before permission is granted. Passwords might still be required, but before permitting access, these passwords would be protected even if they were monitored.

Packet Filtering

Usually, IP packet filtering is done using a router set up for filtering packets as they pass between the router’s interfaces. These routers can filter IP packets based on the following fields:

• Source IP address
• Destination IP address
• TCP/UDP source port
• TCP/UDP destination port

Although not all packet-filtering routers can filter the source TCP/UDP port, most of them already have this capability. Some routers examine which of the routers network interfaces a packet arrived at, and this is used as an extra criterion. Unfortunately, most UNIX servers do not provide packet-filtering capability.

In order to block connections from or to specific web servers or networks, filtering can be applied in many ways, including the blocking of connections to specific ports. For instance, you might decide to block connections from addresses or sites that you consider being untrustworthy, or you might decide to block connections from all addresses external to your site all this can be accomplished by filtering. You can add a lot of flexibility simply by adding TCP or UDP port filtering to IP address filtering.

Servers such as the Telnet daemon usually reside at specific ports. If you enable your firewall to block TCP or UDP connections to or from specific ports, you will be able to implement policies to target certain types of connections made to specific servers but not others.

You could, for example, block all incoming connections to your web servers except for those connected to a firewall. At those systems, you might want to allow only specific services, such as SMTP for one system and Telnet or FTP connections to another system. Filtering on TCP or UDP ports can help you implement a policy through a packet-filtering router or even by a server with packet-filtering capability. Figure 7.5 illustrates packet-filtering routers on such services.

You can set up a ruleset to help you outline the permissions. Figure 7.6 shows a very basic, example ruleset of packet filtering. Actual rules permit more complex filtering and greater flexibility.

The first rule allows TCP packets from any source address and port greater than 1023 on the Internet to enter the destination address of 123.4.5.6 and port of 23 at the site. Port 23 is the port associated with the Telnet server, and all Telnet clients should have unprivileged source ports of 1024 or higher.

The second and third rules work in a similar way, except that packets to destination addresses 123.4.5.7 and 123.4.5.8, and port 25 for SMTP, are permitted.

The fourth rule permits packets to the site’s NNTP server, but only from source address 129.6.48.254 to destination address 123.4.5.9 and port 119 (129.6.48.254 is the only NNTP server that the site should receive news from; therefore, access to the site for NNTP is restricted to that system only).

The fifth rule permits NTP traffic, which uses UDP as opposed to TCP, from any source to any destination address at the site.

Finally, the sixth rule denies all other packets. If this rule wasn’t present, the router might not deny all subsequent packets.

Although packet filtering can effectively block connections from or to specific hosts, which increases your level of security substantially, packet-filtering routers have a number of weaknesses. Their rules are complex to specify and tough to test, because you either have to employ exhaustive testing by hand or find a facility where you can test the correctness of their rules. Logging capability is not found in all routers. If the router doesn’t have this capability, you won’t know if dangerous packets are passing through until it is too late.

Besides, in order to allow certain types of access (that normally would be blocked) to go through, you might have to create an exception to your rules. Exceptions sometimes can make filtering rules very difficult, or even unmanageable. How? Lets suppose you specify a rule to block all inbound connections to port 23 (the Telnet server). Assuming that you made exceptions such as accepting Telnet connections directly, a rule for each system needs to be added, right? Well, sometimes this kind of addition can complicate the entire filtering scheme! Don’t forget: Testing complex sets of rules for correctness might be so difficult that you could never be able to set it right.

Another inconvenience to watch for is that some packet-filtering routers will not filter on the TCP/UDP source port. The filtering ruleset can become very complex because of it, and you can end up with flaws in the whole filtering scheme.

The RPC (Remote Procedure Call) services are very difficult to filter too. The associated servers listen at ports that are assigned randomly at system startup. The portmapper service maps initial calls to RPC services to the assigned service numbers. However, there is no such equivalent for a packet-filtering router. It becomes impossible to block these services completely because the router cannot be told on which ports the services reside (unless you block all UDP packets) because RPC services mostly use UDP. But if you block all UDP packets, you probably would block necessary services (DNS, for example). The question becomes to block or not to block RPCs.

You should get more information on packet filtering and associated problems. It’s not the scope of this chapter to exhaust the subject, but packet filtering is a vital and important tool. It is very important to understand the problems it can present and how they can be addressed.

Procuring a Firewall

After you’ve decided on the security policy, there are a number of issues to be considered in procuring a firewall. Standard steps to be taken are requirement definition, analysis, and design specification. The following sections describe some considerations, including minimal criteria for a firewall and whether to build or purchase a firewall.

Needs Assessment

When the decision is made to use firewall technology to implement your organization’s Web site security policy, the next step is to procure a firewall that provides the appropriate level of protection and cost-effectiveness. Ask these questions:

1. What features should a firewall have?
2. What would be considered effective protection?

Of course, by now you can entirely answer these questions with specifics but it is easy to assert that firewalls have the following features or attributes for which you should always look for:

• A firewall should be able to support a deny all services, except for those specifically permitted design policy. Even if you didn’t read this chapter from the beginning, this should not be the policy to use! You must be able to permit few and still keep a sound level of security to your organization.
• A firewall should support your security policy, not force one.
• A firewall should be flexible. It should be able to be modulated to fit the needs of your company’s security policy and be responsive to organizational changes.
• The firewall should contain advanced authentication measures or should be expandable to accommodate these authentications in the future.
• A firewall must employ filtering techniques that allow or disallow services to specified server systems as needed.
• The IP filtering language must be flexible, user-friendly to program, and capable of filtering as many attributes as possible, including source and destination IP addresses, protocol type, source and destination TCP/UDP ports, and inbound and outbound interfaces.
• A firewall should use proxy services for services such as FTP and telnet so that advanced authentication measures can be employed and centralized at the firewall. If services such as NNTP, X, HTTP, or Gopher are required, the firewall should contain the corresponding proxy services.
• A firewall should contain the capability to centralize SMTP access in order to reduce direct SMTP connections between site and remote systems. This will result in centralized handling of site e-mail.
• A firewall should accommodate public access to the site, such that public information servers can be protected by the firewall but can be segregated from site systems that do not require the public access.
• A firewall should contain the capability to concentrate and filter dial-in access.
• A firewall should contain mechanisms for logging traffic and suspicious activity, and should contain mechanisms for log reduction so those logs are readable and understandable.
• If the firewall requires an open operating system such as UNIX and NT, a secured version of the operating system should be part of the firewall, with other security tools as necessary to ensure firewall server integrity. The operating system should have all patches installed.
• A firewall should be developed in a manner so that its strength and correctness is verifiable. It should be simple in design so that it can be understood and maintained.
• A firewall and any corresponding operating system should be updated and maintained with patches and other bug fixes in a timely manner.

There are undoubtedly more issues and requirements, but many of them are specific to each site’s own needs. A thorough requirements definition and high-level risk assessment will identify most issues and requirements; however, it should be emphasized that the Internet is a constantly changing network. New vulnerabilities can arise, and new services and enhancements to other services might represent potential difficulties for any firewall installation. Therefore, flexibility to adapt to changing needs is an important consideration.

Buying a Firewall

A number of organizations might have the capability to build a firewall for themselves. At the same time, there are a number of vendors offering a wide spectrum of services in firewall technology. Service can be as limited as providing the necessary hardware and software only, or as broad as providing services to develop security policy and risk assessments, security reviews, and security training.

Whether you buy or build your firewall, it must be restated that you should first develop a policy and related requirements before proceeding. If your organization is having difficulty developing a policy, you might need to contact a vendor who can assist you in this process.

If your organization has the in-house expertise to build a firewall, it might prove more cost-effective to do so. One of the advantages of building a firewall is that in-house personnel understand the specifics of the design and use of the firewall. This knowledge might not exist in-house with a vendor-supported firewall.

Building a Firewall

An in-house firewall can be expensive in terms of time required to build and document the firewall and the time required maintaining the firewall and adding features to it as required. These costs are sometimes not considered organizations sometimes make the mistake of counting only the costs for the equipment. If a true accounting is made for all costs associated with building a firewall, it could prove more economical to purchase a vendor firewall.

In deciding whether to purchase or build a firewall, answers to the following questions might help your organization decide whether it has the resources to build and operate a successful firewall:

• How will the firewall be tested?
• Who will verify that the firewall performs as expected?
• Who will perform general maintenance of the firewall, such as backups and repairs?
• Who will install updates to the firewall, such as new proxy servers, new patches, and other enhancements?
• Can security-related patches and problems be corrected in a timely manner?
• Who will perform user support and training?

Many vendors offer maintenance services along with firewall installation, so the organization should consider whether it has the internal resources needed.

Setting It Up

If you decide to build your firewall, make sure you respond to all of the preceding questions and that you indeed will be able to handle all the details of setting the firewall. Most importantly, make sure that your organization’s upper management is 100-percent with you.

The following is an example of a firewall setup. Later on this chapter I give you an example of a firewall installation, should you decide to purchase one instead of setting it up yourself. Hardware requirements and configuration will vary, of course, but if you follow the outlined steps you should be able to avoid lots of frustration and time-consuming surprises.

Also, make sure you have your firewall policy written up, understood, and on hand. When that is complete, write the following outlined steps on a board or notepad. They will be your roadmap in putting your firewall together:

• Select the hardware required.
• Install the necessary software (NOS, utilities, and so on).
• Connect and configure your machine on the network.
• Test it out.
• Add security (through firewalling software).
• Set up and configure the proxy server.

If your company is a medium size, I tried to complement the information to suit your needs with the following example of a company with 200 employees. Keep in mind: Far from being a sample firewall plan, this plan should be considered as a template to be modified as needed.

Select the Hardware Required

Let’s assume for example that I am setting up a firewall for my company, Vibes (Virtual Business Educational Services, in case you’re wondering). For comparison reasons (and comparison reasons only!), consider Vibes to be a medium-sized company with 200 employees where all users have access to the Web and other services such as Telnet, FTP, Gopher, and SMTP.

The computer I will be using for the firewall is a 90Mhz Pentium with 16MB of RAM, a 540MB Linux partition, and a PPP connection to an Internet provider over a 28,800bps modem. To make the Linux box a firewall, I added an Ethernet network interface card and connected it to the company’s LAN. All clients are running either Windows 95 (with SP1) or Windows NT Workstation 4.0 (with SP3 update).

Install the Necessary Software

Now I have to set up my Linux box. I have to recompile the Linux kernel. In order to do that, I will have to issue a make config, where I will:

1. Turn on my network support and TCP/IP networking.
2. Turn off my IP forwarding (CONFIG_IP_FORWARD).
3. Turn on my IP firewalling.
4. Turn on IP accounting, which is not necessary but recommended, because we do want to institute security.
5. Turn on network device support.
6. Turn on my PPP and Ethernet support. If you’re not using the same inter