WebDeveloper.com �: Where Web Developers and Designers Learn How to Build Web Sites, Program in Java and JavaScript, and More!   
Web Developer Resource Directory WebDev Jobs
Animated GIFs
CSS Properties
HTML 4.01 Tags
Site Management
WD Forums

    Web Video
    Expression Web



    Forum, Blog, Wiki & CMS

 Site Management
    Domain Names
    Search Engines
    Website Reviews

 Web Development
  Business Issues

    Business Matters

    The Coffee Lounge
    Computer Issues

The Educated Shopper's Guide to Firewalls

by J.M. Ivler

Concerned about potential break-ins by Internet intruders, many companies decide to set up a firewall. Firewalls limit the kinds of network traffic that can pass between the corporate intranet (LAN) and the Internet. Determining the best level of host and network security can pose a stiff challenge for system administrators trying to secure their sites. It's a challenge that can be exacerbated by unclear communications with one's service provider. Consider the true story of one unlucky company that, on the recommendation of its Internet service provider, turned to a firewall solutions vendor to request "a turnkey system that requires little maintenance." In this case, the vendor proposed a Sun Netra with Firewall-1 as the solution.

The firewall solutions vendor showed up with a Netra and some documentation on Firewall-1. The technicians spent 10 minutes putting the system on the router and installing NCSA httpd 1.3 for a Web server. Announcing that the system was completed, the technicians left without further ado.

The vendor had indeed installed the most secure firewall possible. It required absolutely no maintenance by the customer, and was the only 100 percent secure firewall I have ever seen. You see, this particular Sun Netra they installed had but one Ethernet port. Great for talking to the Internet or the internal network, but not both at once.

A second port was duly ordered and installed, but at that point the company's systems staff had determined that the firewall didn't support dual-homed DNS and thus did not meet their needs. This company, which had wanted a simple turnkey solution, wound up spending three weeks and 120 worker-hours to end up exactly where it had started out.

Before you and your company purchase a firewall system--or even solicit bids on one--it's crucial that you educate yourself about what exactly a firewall can and can't do for your company's security. Some background reading is a must for anyone planning to even look at a firewall or any other security solution prior to connecting to the Internet. It is important that you educate yourself before even speaking to vendors; see "Recommended Texts," for some good starting points. As my cautionary tale illustrates, vendors may know less than you do--but you may be the last to find that out. Arming yourself with accurate information will help you eliminate a large number of vendors right off the bat.

Next, you'll need to make a list of your company's special security requirements. What kind of services do you want to use or offer? Are there differences in how you want to react to inbound versus outbound traffic? Who will be entrusted with certain access privileges, and why? What methods of authorization will be used? And what will be the configuration on your side of the router?


If you're wondering, "Can't I build my own firewall?"--the answer is yes. This begs the obvious question, "Why should I pay thousands of dollars for one when I can build it myself?"

One option for a homebuilt firewall is to use the router to the Internet to do IP packet filtering. By obtaining and installing xinetd to replace inetd, access to services can be limited. Using a package such as SOCKS for proxy service, and various TCP wrappers, you can make a homebuilt firewall.

Such homebuilt firewall systems will work, and many sites have built them to provide simple levels of protection. These sites also hire a security administrator to maintain control over the access on services. In simple terms, this is not a "turnkey solution" to the needs of a company. And, depending on the variety of internal machines that will be accessing the firewall, the proxies or the services on the internal machines may have to be modified to work with the homebuilt firewall. For something a bit easier to maintain, consider a commercial application.

If you're really interested in "doing it yourself," I highly recommend that you contact Trusted Information Systems and look at The Firewall Toolkit, which may be found at http://www.tis.com/docs/products/fwtk/index.html. If you're interested in SOCKS, mentioned above, it is available at For World-Wide Web applications, look at the CERN Web Proxy Server at http://www.w3.org/hypertext/WWW/Daemon/Status.html.

Leaving homebuilt systems behind, commercial systems provide some turnkey solutions. As the true story at the beginning of this article points out, not everyone defines turnkey the same way. Therefore, let us consider four general criteria for defining the needs of the firewall: services, authorization, authentication, and configuration.


The following basic services are generally supported by all firewall systems. If these basic services aren't supported, then you should probably start looking elsewhere (unless you have determined that you won't need that service either today or in the future).

  • Telnet: the ability to log into a remote system

  • FTP: the ability to perform a file transfer

  • Gopher: the ability to transverse tree-structured information

  • SMTP: the ability to send and receive e-mail

  • HTTP: the ability to access the World Wide Web

  • NNTP: the ability to access Usenet newsgroups

  • DNS: the ability to do name resolution (discussed further below in the dual-homed gateway section)

Each of these services is actually a "dual" service, since a site can provide either inbound or outbound access to each service (in the case of FTP, it's a dual/dual service, as FTP provides separate levels of access for downloading files onto the guest system (put) or obtaining a file from the guest system (get)).

To properly view the services available and the company's needs, build a matrix as shown in the example in Figure 1. To indicate that a service should be provided with no limitations, place a "Yes" in the service box. If not, place a "No." Where service is to be provided on a case-by case basis, put "Yes (1)". The restrictions will be set based on classification of the users.


Clarification of the users and the establishment of levels of trust for those users is the next step. For instance, in our example we trust all users of our internal network, so we will require no authorization or authentication for our LAN users to go outbound. On the other hand, we have different levels of trust for people trying to access our network from the Internet.

Create a list of inbound users of the system and organize them into common groupings. For instance, if several full-time employees will be using Telnet to log into your system, then a group called "Employees" should be created to support rule simplification. With our example, five common groupings will be created: employees, consultants, customers, vendors, and the general public. Some companies choose to break down classifications even further. For instance, the Employees group might contain other subgroups, like the Developers group, the Support group, and the Documentation group. This allows for finer granularity of access control, which will be discussed later.

We can now make a matrix of inbound access and services, as shown in Figure 2. This matrix clarifies the restrictions that were specified in the services/needs matrix in Figure 1. The inbound matrix illustrates at a glance which services are allowed or disabled for each group of users.


Do you want to be able to limit access by IP? By domain? By subnet? What levels of authorization will be supported? Do you want to be able to limit access to certain windows of time, or specific dates? Do services default to being denied? Each of these questions, once answered, will help define the security requirements for the firewall.

In general, almost everyone will recommend that any service not explicitly allowed is denied. Remember, the idea is to protect the network. The application of this simple rule will ensure that you are consciously disabling protection of your corporate intranet when providing access. This makes disabling the protection a proactive process.

Since service access has been defined by "group name," it makes sense to define access by group name as well. This doesn't preclude permitting or limiting access by other methods, such as subnet, domain, or IP, as will be discussed later.

The first question that must be addressed is what level of authentication is needed. On outbound traffic, in the example being used here, there is no need to authenticate. If the person is a user on the internal system, we permit full outbound access of permitted services without further authentication.

There are three basic authentication models used in firewall security:

  • None: This is what we have declared our intranet users will have in the example.

  • Password: This is a set password on the firewall.

  • One-time password: This method requires a different password each time a user logs in. This method uses a challenge/ response mechanism.

There are two basic models for this: software-based and hardware-based.

In our example, the employees and consultants access the Internet often. Therefore, packet sniffers on the Internet must not be able to find out what their passwords are through repetition. In order to ensure this, the users in this class have to come in and leave with a unique password each time (a one-time password). This narrows the choices down to a software-based password generator (such as S/Key, freely available at http://www.bellcore.com/SECURITY/skey.html) or a hardware-based one (such as ACE from Security Dynamics) that uses SecureID. Both of these systems use the challenge/ response model.

When these users log in, they will be required to provide a unique key. Then, based on the method used, they will enter that key into a separate piece of hardware, or they will use a software package to enter the challenge key. Both the hardware system and the software system will provide a unique response key to the challenge.

If there are just a few employees and consultants who will be accessing this way, then the most secure method (SecureID) would be a wise choice, but at more than $50 for each hardware unit, it can become an expensive proposition. Therefore we use S/Key in our example.

Customers and vendors access less frequently; these groups use a standard firewall password for FTP. The Public class is only accessing via HTTP, so no password is required here. Figure 3 shows what our authentication matrix will look like.

The next issue to consider is access control. Access control determines when and how to permit access. This allows for finer grains of isolation of access to the internal network.

In the example, inbound access from employees is permitted only during non-working hours. Vendors are allowed access only during working hours. Consultants may Telnet only during working hours, but can FTP at any time.

To establish even additional rule complexity, a sister company (, whose users are considered employees, should have full access at all times.

These rules are not uncommon. In fact, in some cases it might be necessary to allow only a certain single customer access beyond that of the normal customer group coming in via a particular IP address, at a specific time. An example of this might be a customer that sends a logfile via a cron job to the intranet system every week (say, on Monday) so that the logfile can be analyzed to measure the performance of the customer's system. The cron job runs on their IP and starts at 0600 GMT. It can take anywhere from 10 minutes to three hours to make the log file. To accept this file, the firewall should open an FTP-put window for that customer from that IP for a period of six hours on Monday, starting at 0600 GMT.

This will require the firewall to handle a specific ruleset--a rule that opens a single window for a single user from a single IP for a single day for a six-hour period for a single service. While this is a very specialized case, it is not unusual. Much like writing software, maintaining a firewall is as much about controlling exceptions as it is about creating blanket rules.

In the example firewall, the system has been defined to have the following requirements:

  • The firewall permits non-authenticated outbound access from the intranet.

  • The firewall allows firewall users to be assigned into groups.

  • Authentication consists of both constant passwords and one-time passwords (challenge/response) that do not require special hardware.

  • Access should be controlled by time-of-day, day-of-week, and combinations of these, as well as by specific dates and date ranges.

  • Defined users and groups access with different levels of security.

  • Access should be able to be controlled by IP, subnet, and domain of the inbound user.

  • Any service not specifically allowed shall be denied (default).


The final issue any site must consider is configuration. The example used throughout this article makes the assumption that all services will be offered through the firewall. That is not always the case. This section covers the prospect of placing services between the router and the firewall, and the issues that arise when doing that. It is important to reiterate that you must be willing to completely reconfigure any of your machines between the Internet and your firewall--an area also known as the DMZ--if they are compromised.

It is recommended that any machine placed in the DMZ be very limited. It should be a single-service machine, with no connection to any part of your internal network (no NFS-mounted disks). Any machine between the firewall and the router should be limited in its ability to resolve IP addresses; it should recognize only itself, the firewall, and the router.

A Web server and an FTP server are examples of specific service machines that could be placed between the router and your firewall. In the case of the FTP server, a site would define the following rules on the firewall:

  • Internal users can access the Internet for FTP-get without authentication.

  • Internal users are permitted to perform an FTP-put to the FTP server only.

You should create on your FTP server an upload directory that cannot be read, and subdirectories for all customers. Create a cron job to move files placed in these customer-upload directories to the associated customer-download directory. Now any user on the intranet can access the FTP server with an FTP-put to place files for the customer to obtain from a customer-download directory. Then the server would also be set up to support either customer logins, or anonymous logins with sub-logins to customer accounts (this is supported by the WU Archive FTP daemon, which is highly recommended).

Dual-homed Gateway

One key aspect of ensuring the security of an intranet is to render it invisible. If full name service is provided to the Internet from the firewall, it will be possible for a cracker to obtain a "picture" of the internal network. To prevent this, DNS can be established to support a dual-homed gateway.

In this case, a very limited name service is supported on the firewall, but the firewall itself uses the internal network to perform name-service resolution prior to resolving on the Internet. In this way, any successful connection to the firewall will provide that connection with name-service access to the inner network beyond, but that information will not be served beyond the firewall.

This also affects the way SMTP service is supported. When hiding the internal network, it is important to consider masquerading the addresses on e-mail envelopes. This requires some modifications to the sendmail.cf file on the firewall (or the e-mail gateway) to change the name of the internal machines to the domain name, or the e-mail gateway at the domain. Make sure that you check the CERT advisories at ftp://info.cert.org/ to ensure that the sendmail you are running on your gateway is secure.

It is highly recommended that the DNS, BIND and Sendmail books mentioned in "Recommended Texts" be part of any library.


The matrix system described in this article will help you generate a clear and concise overview of your security needs for a firewall. Specific configuration issues can be researched further in the books mentioned in "Recommended Texts." Then, by creating straightforward matrix charts depicting the site's security, you can help ensure that your company gets what it needs, and also what will fit its anticipated growth. The matrix approach also provides a clear and simple way to explain your security needs to all who will be involved in the process--from management to prospective security vendors. And clear communication may be the best way to get your company the right security solution on the first try.

HTML5 Development Center

Recent Articles