A firewall is a critical part of the security of any Internet site. Basically, a firewall improves the security of a site by limiting the access of that site to an absolute minimum. It’s important to remember that although a firewall doesn’t solve all Internet security problems, no Internet site should be without a firewall. This section covers only the basics of firewalls and how they affect Internet programming. If you need more detailed information, the book Building Internet Firewalls by O’Reily & Associates, Inc., is an excellent source.
Three basic types of firewalls exist: the bastion host, the packet filter, and the proxy gateway. Before you do any Internet programming, you need to find out which kind of firewall you have. Each kind affects Internet programming in different ways. Also, your site’s particular implementation factors into the programming picture. A firewall can be completely transparent to your program in some cases. In other cases, it might make your program impossible to write. If this is the case, you need to ask yourself and the security people at your site whether a way exists to relax the restrictions your firewall imposes, without compromising the security of your site. Sometimes the answer to this question is no, and you just have to give up on your project.
It’s also possible to combine or modify the three basic firewall types to make more complex security setups. If this is done correctly, you can get exactly the security you want. The variations are endless and each has its own effect on Internet programming. Therefore, I cover only the effects of the basic types. If you have a more complex setup, extrapolate the information here into your own environment.
You can either buy a firewall or design your own if you don’t have one. Internet routers, such as Cisco or Bay Networks, offer all the packet-filtering options you could want. Because you need a router to connect to the Internet anyway, this is a good, inexpensive option. The only negative is that these devices can be hard to configure. You can purchase a variety of products, such as Firewall-1, Gauntlet, CheckPoint, and Sidewinder. These products offer advanced firewall configurations but are very expensive.
If you build your own firewall, take a look at Trusted Information Systems’ (TIS) Firewall Toolkit as a base on which to build. Building your own firewall can be relatively inexpensive until you factor in personnel costs, but it probably won’t be as high-quality. The good news about building your own firewall is that you can customize it highly to meet the needs of your programs.
The bastion host firewall scheme is usually simple to implement, but it is very noticeable and cumbersome to users and programmers alike. The bastion host sits between the Internet and the internal network. The Internet can talk to the bastion host. The internal network can talk to the bastion host. However, the Internet and the internal network can’t talk directly to each other.
For any communication to occur between the Internet and the internal network, a login must exist to the bastion host. In the old days of the Internet, this kind of firewall was potentially very secure and the loss of functionality was acceptable in many cases. Over time, though, the network has changed-with the explosion of the Web and PCs with Internet access. In today’s world, a true bastion host would make using a graphical Web browser on a PC impossible without going to extreme lengths.
Any services your site plans to make available to the Internet must reside on the bastion host. This includes your e-mail routing server and your Web server. But these services can be too much load for one machine; you might need to have multiple bastion hosts to handle all the servers.
For Internet programmers, the bastion host can stop many programming projects cold. Basically, your programs must reside on the bastion host itself, or they won’t be able to talk to the Internet at all. One trick is to have a program on the bastion host that relays information between the Internet and your main program running on the internal network. If you do this, however, you no longer have a true bastion host; you have created a proxy gateway. Proxy gateways are covered in their own section later in this chapter.
Instead of trying to force all traffic between the Internet and the internal network to be authenticated through one host, like the bastion host system, the packet filter tries to screen out harmful traffic between the Internet and the internal network. In addition, the packet filter allows traffic directly between the Internet and the internal network.
Packet filters often are implemented as part of the router that ties together the Internet and the internal network. Less often, you’ll find them implemented in a host computer. Packet filters are implemented differently at every site. Their security can range from dangerously lax to incredibly strict.
With a packet filter, you can almost always restrict access on protocol and IP addresses (both source and destination addresses). With this level of control, it’s possible to allow another company you work with often to have more access to your systems, while not giving any access to the rest of the Internet. Some packet filters will even look inside packets and only forward packets based on some content inside the packet.
In terms of how the firewall will affect your programs, some sites might have access to your running code, while others don’t. This scheme can be helpful to you at times to help manage program security.
A proxy gateway is similar to a bastion host except for one major difference. The proxy gateway has a program or a set of programs running on it to relay packets between the Internet and the internal network.
The idea is basically a game of smoke-and-mirrors, giving the user the perception that she’s directly connected to services on the other side of the firewall, when in reality she isn’t.
Proxies are very good security mechanisms and are great at logging Internet activity. The bad news is that they’re a lot of extra work. Your client and server programs must normally be modified to be able to deal with the proxy. The good news is that the major Web browsers already support proxying, so they won’t need modification.
Another problem with proxies is that the proxies have to be written for almost every different protocol. They’re already written for almost every protocol currently in wide use on the Internet, but new releases of protocols can break proxies, and they might need to be rewritten. Also, for a few protocols (for example, talk), no proxy has been written, and writing one might even be impossible.