More than 50 percent of all users have heard of firewalls, but only a handful know what a firewall really is. This is because firewalls are only used by those actively engaged in protecting networks connected to the Internet.
A firewall is any device used to prevent outsiders from gaining access to your network. This device is usually a combination of software and hardware. Firewalls commonly implement exclusionary schemes or rules that sort out wanted and unwanted addresses.
To understand how firewalls work, consider some of the subjects discussed earlier in this book. First, most simple authentication procedures use the IP address as an index. The IP address is the most universal identification index on the Internet. This address can be either a static or dynamic address:
Whether your address is static or dynamic, it is used in all network traffic that you conduct. For example, as discussed in Chapter 13, "Techniques to Hide One's Identity," a Web server records your IP address when you request a Web page. This is not to intrude on your privacy; it is done so that the server knows how to send you the requested data. In a similar fashion, all network services capture your IP (either temporarily or permanently) so they can return data to your address. In essence, it works much like the postal service: Imagine if every letter mailed had a return address. On the Internet, things are just so. The IP is the return address.
When a connection is made between your machine and a remote machine, various dialogs may ensue. I discussed some of those dialogs in Chapter 6, "A Brief Primer on TCP/IP." A common one--which you are apt to remember--is the TCP/IP three-way handshake. At any rate, such dialogs occur, during which time your IP is known by the target machine.
Under normal circumstances, where no firewall or other superseding utility (such as TCP_Wrapper) has been installed, the dialog between your machine and the remote machine occurs directly (see Figure 27.1).
FIGURE 27.1.
The route of information.
When I say that information travels directly, that is a very qualified term. As you can see, the process (even without security measures) is complex:
NOTE: I have greatly simplified the network outlay design by providing only relevant details. In practice, there might be all sorts of devices located between Your Network and Their Network.
If neither side has installed security measures, the path is deemed (for all purposes) direct. Router 2, for example, allows packets from any source (IP) address to travel directly to Their Server and ultimately, to Their Network. At no point during that travel do the packets meet an obstacle. This is a completely insecure situation. However, for many years, this was the standard. Today, the type of situation illustrated in Figure 27.1 is too dangerous. Over the years, network engineers considered a wide range of solutions, including the firewall.
The most fundamental components of a firewall exist neither in software nor hardware, but inside the mind of the person constructing it. A firewall, at its inception, is a concept rather than a product; it is an idea in the architect's mind of who and what will be allowed to access the network. Who and what dramatically influence how network traffic (both incoming and outgoing) is routed. For this reason, constructing a firewall is part art, part common sense, part ingenuity, and part logic.
Suppose the architect knows a Web server must exist on the host network. This Web server will obviously accept connections from almost any IP address. A restricted area, therefore, must be created for that server. In other words, in providing Web services from the host network, the architect must ensure that the Web server does not endanger the remaining portions of the network. Likewise, incoming mail is also an issue.
Firewalls can be composed of software, hardware, or, most commonly, both. The software components can be either proprietary, shareware, or freeware. The hardware can be any hardware that supports the software being used.
If hardware, a firewall can (and often does) consist of no more than a router. As you will learn in Chapter 28, "Spoofing Attacks," routers have advanced security features, including the capability to screen IP addresses. This screening process allows you to define which IP addresses are allowed to connect and which are not.
Other implementations consist of both hardware and software. (These can get pretty eclectic. I have seen people using 386 boxes with shareware firewall/bridge products on them.)
In any event, all firewalls share a common attribute: the capability to discriminate or the capability to deny access generally based on source address.
There are different kinds of firewalls, and each type has its advantages and disadvantages. The most common type is referred to as a network-level firewall. Network-level firewalls are usually router based. That is, the rules of who and what can access your network is applied at the router level. This scheme is applied through a technique called packet filtering, which is the process of examining the packets that come to the router from the outside world.
In a router-based firewall implementation, the source address of each incoming connection (that is, the address from which the packets originated) is examined. After each IP source address has been identified, whatever rules the architect has instituted will be enforced. For example, perhaps the architect decides that no network traffic will be accepted from any address within Microsoft Corporation. Thus, the router rejects any packets forwarded from microsoft.com. These packets never reach the internal server or the network beneath it.
NOTE: Routers are about the size of a small printer. Generally, at the back of the router are connection points for Ethernet and digital telephone lines. Use these connection points to connect the telephone line (T1, T3, and so on) and Ethernet to your server. Routers are configured using special software. In most instances, the software is quite easy to use. Most newer implementations are controlled through a windowed interface (such as the X Window system, OpenWindows, and so on). Routers range in price (from used to new) from $600 to $1800.
Router-based firewalls are fast. Because they only perform cursory checks on the source address, there is no real demand on the router. It takes no time at all to identify a bad or restricted address. Nevertheless, the speed comes with a price: Router-based firewalls use the source address as an index. That means (barring controls against such access) packets sent from forged source addresses can gain at least some level of access to your server.
In fairness, many packet-filtering techniques can be employed with router-based firewalls that shore up this weakness. The IP address header is not the only field of a packet that can be trapped by a router. As packet-filtering technology becomes more sophisticated, so do the schemes or rules employed by an administrator. One can now even apply rules related to state information within packets, using indexes such as time, protocol, ports, and so forth.
Cross Reference: For an excellent discussion of the fields that can be filtered, as well as a comprehensive look at packet filtering, "Network (In)Security Through IP Packet Filtering" by D. Brent Chapman is a must. Find it online at http://www.unix.geek.org.uk/~arny/pktfilt.ps.
However, these are not the only deficiencies of packet-filtering, router-based firewalls. For example:
Cross Reference: The preceding paragraph is excerpted from "Problems with Packet Filtering Routers" by John Wack. It can be found online at http://www.telstra.com.au/pub/docs/security/800-10/node51.html.
Wack discusses RPC as a potential problem because the ports can be assigned dynamically at startup. However, in most cases, this type of filtering (appropriately called protocol filtering) is not a problem. Very sophisticated schemes can be implemented in protocol filtering, and these rely primarily on the port called by the remote host.
Cross Reference: For an excellent discussion of protocol filtering and packet filtering in general, check out "Packet Filtering in an IP Router" by Bruce Corbridge, Robert Hening, and Charles Slater. This paper offers an inside look at exactly how packet filtering is accomplished in Telebit routers. More importantly, the document takes you through the design and implementation of the router. You can find it online at http://www.alw.nih.gov/Security/FIRST/papers/firewall/cslater.ps.
Packet filtering can be implemented without instituting a complete firewall. There are many free and commercial packet-filtering tools on the Internet. Following is a list of several such utilities.
TCP_Wrappers is a program written by Wietse Venema (also the co-author of the famous scanning utility, SATAN). Arguably, no other tool more easily or efficiently facilitates monitoring connections to your machine. The program works by replacing system daemons and recording all connection requests, their time, and most importantly, their origin. For these reasons, TCP_Wrappers is one of the most critical evidence-gathering tools available. TCP_Wrappers also has the capability to screen out unwanted networks and IP addresses, preventing users from such addresses from connecting.
Cross Reference: TCP_Wrappers is available online at ftp://ftp.win.tue.nl/pub/security/tcp_wrappers_7.4.tar.gz.
NetGate (developed by SmallWorks) is a rule-based packet filtering system. It was designed for use on SPARC systems running SunOS 4.1.x. Like most packet filters, NetGate can examine each and every packet it encounters and can apply various rules, based upon the source address revealed in that examination. (NetGate also sports some pretty strong logging capabilities.) Reportedly, the distribution can be obtained either as a binary installation ($1500) or source ($2500). If your company needs a product with support (as opposed to freeware), I would recommend NetGate as a reasonable and economical alternative to other, more high-profile products.
Cross Reference: You can find information about NetGate at http://hosaka.smallworks.com/netgate/packetfiltering.html.
This interesting package is freely available. Written by Darren Reed, the Internet Packet Filter has all the amenities of a finely coded, commercial application. (Reed took particular pride in developing a package that could defeat the type of IP spoofing attack that Kevin Mitnik purportedly launched against machines at the San Diego Supercomputer Center.) Some interesting tidbits: Reed provided functionality not only to discard TCP packets that were incomplete or malformed, but to do so silently (your host returns no ICMP error). Internet Packet Filter also offers a comprehensive testing utility, so you can ensure your rules are sound before you implement them. (The program actually can take previous logs as input, and you can watch as the rules are applied. Very cool.) It is available for SunOS.
Cross Reference: The Internet Packet Filter can be found at ftp://coombs.anu.edu.au:/pub/net/kernel/ip_fil3.0.4.tar.gz.
Packet filters, when used in conjunction with powerful auditing tools, can greatly assist in protecting your network and identifying intruders. The right combination of these types of tools can be every bit as effective as a commercial firewall (and generally, a whole lot less expensive). Following are some good auditing tools.
Argus was developed at Carnegie Mellon University's Software Engineering Institute. Argus is known to compile without errors, at least on the following platforms:
In the document announcing Argus's availability, authors report that Argus is suitable for network monitoring, identifying potential network problems, and perhaps most importantly, verifying access control policies.
Cross Reference: The document announcing Argus's availability can be found online at ftp://ftp.sei.cmu.edu/pub/argus-1.5/argus-1.5.announce. The tool can be obtained online at ftp://ftp.sei.cmu.edu/pub/argus-1.5/.
Netlog, developed at Texas A&M University, can log all TCP and UDP traffic. To use this product, you must have a C compiler that will take ANSI C conventions. This tool also supports logging of ICMP messages (though the developers report that performing this logging activity soaks up a great deal of storage).
Cross Reference: Netlog is available online at ftp://coast.cs.purdue.edu/pub/tools/unix/TAMU/.
This tool is covered extensively in Chapter 12, "Sniffers." However, I will reiterate that this is a suite of applications that is well crafted; it is arguably the most complete package of its kind ever made.
Cross Reference: Netman is available online at ftp://ftp.cs.curtin.edu.au/pub/netman/.
NOCOL/NetConsole v4.0 is a suite of standalone applications that perform a wide variety of monitoring tasks. This suite offers a Curses interface, which is great for running on a wide range of terminals (it does not require the X Window system in order to work). It is extensible, has support for a Perl interface, and is quite complex. It also operates on networks running AppleTalk and Novell NetWare.
Cross Reference: NOCOL/NetConsole v.4.0 is available online at ftp://ftp.navya.com/pub/vikas/nocol.tar.gz.
There are other platform-specific packet filters. One well-known one is packetfilter, which runs on Ultrix 4.3. It is kernel resident.
Cross Reference: The man page for packetfilter is available online at http://198.233.42.11/ cgi-bin/man2html/packetfilter(4).
Nonetheless, many of these tools, although capable of examining and monitoring packet traffic, cannot institute access-control policies. And that is the whole purpose of a firewall. It gives the administrator the ability to finely control who can (and cannot) access the network.
Other types of firewalls exist. A common type is application-proxy firewalls (sometimes referred to as application gateways). These work a bit differently from packet-filtering, router-based firewalls. Application gateways are software-based. When a remote user from the void contacts a network running an application gateway, the gateway blocks the remote connection. Instead of passing the connection along, the gateway examines various fields in the request. If these meet a set of predefined rules, the gateway creates a bridge between the remote host and the internal host. Bridge refers to a patch between two protocols. For example, in a typical application gateway scheme, IP packets are not forwarded to the internal network. Instead, a type of translation occurs, with the gateway as the conduit and interpreter. This is sometimes referred to as the man-in-the-middle configuration.
The advantage of the application-gateway proxy model is the lack of IP forwarding. More importantly, more controls can be placed on the patched connection. Finally, such tools often offer very sophisticated logging facilities. Again, there is no such thing as a free lunch. As you might expect, this gateway scheme has a cost in terms of speed. Because each connection and all packet traffic are accepted, negotiated, translated, and reforwarded, this implementation can be slower than router-based packet filtering.
IP forwarding occurs when a server that receives an external request from the outside world forwards that information in IP format to the internal network. Leaving IP forwarding enabled is a fatal error. If you allow IP forwarding to occur, a cracker can get in from the outside and reach workstations on your internal network.
Another disadvantage of this scheme is that a proxy application must be created for each networked service. Thus, one is used for FTP, another for Telnet, another for HTTP, and so forth. As John Wack explains in his article titled "Application Gateways":
Cross Reference: "Application Gateways" by John Wack can be found online at http://www.telstra.com.au/pub/docs/security/800-10/node52.html.
A typical example of an application-gateway firewall package is the Trusted Information Systems (TIS) Firewall Tool Kit (hereinafter referred to as the FWTK). This software package, early versions of which are free for noncommercial use, contains many separate components. The majority of these components are proxy applications. It includes proxies for the following services:
The FWTK is a comprehensive system. Nonetheless, it does not protect your network immediately upon installation. This is not a product that you simply install and abandon. The TIS FWTK is a tool kit. After you unpack the software, you must make certain decisions. You must also understand what you are doing. This is not a simple configuration problem. If you make erroneous rules or decisions along the way, your network might be unreachable from the void, even from friendly networks. Reading the documentation is paramount.
The beautiful thing about the FWTK is that it has excellent access control built into its design. For example, you can allow or deny access (connection) from a network, a part of a network, or even a single address. In this respect, it has granular access control.
Cross Reference: Before you get the TIS FWTK, you should probably examine a posting of a message from Marcus Ranum, one of the developers of TIS FWTK. This is a short, entertaining document that gives some insight into how the FWTK started. That document is located online at http://www.micrognosis.com/~nreadwin/fwtk/history.txt.
Cross Reference: Obtain a copy of the TIS Firewall Tool Kit at ftp://ftp.tis.com/pub/firewalls/toolkit/dist/.
Cross Reference: The FWTK requires a UNIX system and a C compiler. Moreover, although the FWTK is known to compile on SunOS and BSD without problems, configuration issues exist for Linux. To sort out these problems quickly, there is no better document than "Creating a Linux Firewall using the TIS Toolkit" by Benjamin Ewy. That document is located online at http://www.ssc.com/lj/issue25/1204.html. Patches for use with the FWTK on Linux are located online at ftp://ftp.tisl.ukans.edu/pub/security/firewalls/fwtkpatches.tgz.
The reason I mention the TIS FWTK is because it was the first, full-fledged firewall of this class. It was a ground breaker in the firewall field.
Cross Reference: "Thinking About Firewalls," also by Marcus Ranum, is a very good document about firewalls in general. This document details the types of firewalls that can be implemented and their advantages and disadvantages. It can be found online at http://hp735c.csc.cuhk.hk/ThinkingFirewalls.html.
NOTE: Another extremely popular firewall in this class is SOCKS, which is based on the application-proxy model. The connect request is intercepted by SOCKS and translated. Thus, a direct connection never occurs between your network and the outside world. SOCKS is of great significance because it is so well established that support for it is already included in many browser packages, most notably Netscape Navigator.
Cross Reference: There is a very comprehensive coverage of SOCKS technology on the Internet. The document is so well designed and written that anyone can get a solid grasp of how SOCKS works in just a few moments. That document is at http://www.socks.nec.com/introduction.html.
It is my opinion that application-gateway systems (proxy-based firewalls) are more secure. This is because there is no IP forwarding scheme. That means IP packets from the void cannot reach any machine on your internal network.
One of the main ideas behind a firewall is that your network will remain theoretically invisible (or at least unreachable) to anyone not authorized to connect. This process works through the exclusionary schemes that one can apply using a firewall.
CAUTION: Your firewalled network will not be entirely invisible. At least one scanner, called Jakal, can scan for services running behind a firewall. Jakal, a stealth scanner, will scan a domain (behind a firewall) without leaving any trace of the scan. According to the authors, all alpha test sites were unable to log any activity (though it is reported that "some firewalls did allow SYN | FIN to pass through"). Refer to Chapter 9, "Scanners," for the scoop on that utility.
Theoretically, a firewall is the most stringent security measure you can implement (barring, of course, disconnecting your system from the Internet). Nevertheless, issues regarding this stringent security environment remain. One is that security with a firewall can be configured so stringently that it can actually impair the process of networking. For example, some studies suggest that the use of a firewall is impractical in environments where users critically depend on distributed applications. Because firewalls implement such a strict security policy, these environments become bogged down. What they gain in security, they lose in functionality. Universities are a perfect example of this type of environment. Research in universities is often conducted where two or more departments (often on network segments located far from each other) are involved in the compilation of data (and corroboration of research efforts). In these environments, it is very difficult to work under such tight security restraints.
A second issue regarding firewalls is that they lead to placing most of your eggs in one basket. Because a firewall is your face to the void, a breach can cause your internal network to be easily destroyed. That is, firewalls can foster a climate in which they are the only real access control and security you have. Firewalls are almost always described as the bottleneck of a network, where all authentication is to be done. This seems suitable as long as firewalls are infallible. But what if they aren't? What if a technique is discovered to crack any firewall? Networks that rely on firewalls would be completely exposed, and odds of survival would be slim.
Before you construct a firewall, you should undertake some serious research. When you construct a firewall, you must know your network intimately. This requires true organization. Various network segments (either on the same network or different ones) will need to communicate with each other. These networks can communicate through automated processes or human interaction. Automated processes might prove easy to accommodate. Human-initiated processes, however, can differ dramatically.
For some organizations, a firewall is just plain impractical. ISPs are within this class. One could quickly lose customers by instituting harsh security policies. Indeed, some contend that firewalls are not needed. These people argue that solid system administration practices will render the same benefit as a firewall, without slowing the network or making connections difficult.
There are other problems with establishing a firewall as well. If FTP, Telnet, Gopher, HTTP, RPC, rlogin, and NFS were the only protocols that the Internet would ever use, a firewall would pose only limited problems with access. After all, proxies have been written for all of these applications. The problem is, these are not the only services; new services crop up each month. Thus, to provide your internal users with effective Internet access, you must keep up with the applications now emerging. Proxies for such services will generally be obtainable, but after the new service or protocol has already been on the market for some time. Of course, some time is generally only a few months, but during those months, your internal users will fuss.
The construction of a firewall is not for the faint of heart. It is for a system administrator (or other individual) who intimately knows the network to be firewalled. The process is not simple; the steps include
The first step is to understand the network in its entirety. This task might involve more than simply looking over the machines, the logs, and so forth. It might involve discussing these matters with individual departments. For example, in larger networks, there might be many interactions between a specific department in one building and a specific department in another. These buildings might be located hundreds or even thousands of miles away from each other. You need to know what type of outgoing traffic users require.
It is important to maintain your tact during this process. You will often run into users who insist, "We've been doing it this way for 10 years now." Even though you have great authority (because security is such a serious concern), you should work with these people as much as possible. It is not necessary that they understand the process in full. Nevertheless, if you intend to restrict or otherwise hamper their ability to reach out into the void, you should explain why to them. The last thing you need is to anger (or otherwise foster resentment within) local users. Rather, you need their support because after you finish building your firewall, you will distribute a policy. How closely local users follow that policy will dramatically affect the security of your network. For example, if insecure modems are located in this or that department, this is a potential hole. If you have dealt tactfully with local users, you will probably have nothing to fear. However, if you have issued Draconian decrees, you can be pretty sure that local users will trip you up.
NOTE: I hear folks dispute this all the time. They insist that no one can simply install a modem on a machine. Why not? I have seen it happen in many companies. There is nothing in a policy alone that will prevent an employee from doing so. Furthermore, on networks with PC-based workstations, many machines or workstations have internal modems to begin with. I dealt with one client who had a Novell NetWare network from the old days. Even the client was unaware that some machines had modems (1200 baud, of course).
So, your first job is to determine what can and cannot be restricted. A list should be made of all nonstandard protocols that are essential between this network and any other. That done, you can begin to get a picture of how the firewall will be built (at least, the local access policies). Determining whom (or what) not to let in is a little less perplexing. More than likely, you will want to restrict connections from any network known to forward unsolicited e-mail, sexual content, or other materials not related to your business. You might also want to restrict addresses that are known hacking or cracking havens.
NOTE: I would restrict all known hacking and cracking addresses. For example, a well- known hacking group recently conducted a wide scan of U.S. domains, purportedly under the guise of security research. This caused a stir in security-related mailing lists and newsgrouqa and rightly so.
Are firewalls foolproof? Are humans foolproof? The answer to both questions is no. Firewall products have not been proven to be flawed, but human implementation has. Crackers have conducted various studies on breaking firewalls. The majority of those studies point to two phases of an attack. The first is to discover what type of firewall exists on a particular network and what type of services are running behind it. That first task has already been encapsulated in an automated package; the Jakal scanner can accomplish this for you.
The second task, finding a hole in the firewall, is a bit more difficult. Cracker studies indicate that if there is such a hole, it exists as a result of human error (or rather, misconfiguration on the part of the system administrator). This is not a rare occurrence. One must recognize that no matter what platform is in use, this is a problem. In UNIX networks, it can be at least partially attributed to the fact that UNIX is so complex. There are hundreds of native applications, protocols, and commands. This is before you begin to construct a firewall. Failed firewall implementation on Microsoft platforms might occur for other reasons (for instance, because administrators might be unfamiliar with TCP/IP). In either case, human error is a likely possibility. For this reason, companies should be extremely selective when choosing the personnel responsible for implementing the firewall. Some common cracker agendas include
Cross Reference: Decoys bear at least a fleeting resemblance to the box (reportedly built by Steven Bellovin) described in the article by B. Cheswick titled "An Evening With Berferd In Which a Cracker is Lured, Endured and Studied." This article can be found online at ftp://research.att.com/dist/internet_security/berferd.ps.
Also, no firewall can effectively prevent attacks from the inside. If a cracker can place someone (perhaps himself or herself) in your employ, it won't be long before your network is cracked. I know someone who managed to gain employment with a well-known oil company. That hacker collected extensive information not only about the internal network there, but also about the firewall hosts.
Finally, firewalls have been bypassed or broken in the past. The Quake site at Crack dot Com is one such example. Although relatively little information has been distributed about how the crack was accomplished, it was reported in Wired that:
Cross Reference: The preceding paragraph is excerpted from "Hackers Hack Crack, Steal Quake," an article, by Annaliza Savage, that appeared in Wired. Find the article online at http://www.wired.com/news/culture/story/1418.html.
It is possible to identify the type of firewall being run on a given server. However, printing that is beyond the level of irresponsibility to which I am prepared to stoop just to sell a book. I will say this: You can do it with a combination of the Jakal scanner and a script written to jackhammer a site. Which addresses are blocked matters less than how they are blocked (that is, you need to elicit responses from the firewall).
The Eagle Family of Firewalls by Raptor
Company: Raptor Systems
Specs: http://www.raptor.com/products/brochure/40broch.html
Home: http://www.raptor.com
Raptor has been around a long time. It introduced its line of firewall products in 1991. The company has a solid reputation. As stated in its online company description:
Cross Reference: Check out Raptor's online company description at http://www.raptor.com/products/brochure/40broch.html#aboutraptor.
Its products combine a wide range of firewall techniques, including heavy logging; specialized, event-triggered treatment of suspicious activity; and extremely granular access controls. This family of firewall products integrates application proxies.
Check Point Firewall and Firewall-1
Company: Check Point Software Technologies Ltd.
Specs: http://www.checkpoint.com/products/firewall/intro.html
Home: http://www.checkpoint.com/
Check Point is based in Israel and was founded in 1993. It also has outposts in eight U.S. cities, including Redwood City, Los Angeles, New York, and others. The product line offers cross-platform support.
Cross Reference: Articles and press releases about Check Point are located online at http://www.checkpoint.com/press/index.html. More important information about Check Point's flagship product is located at http://www.checkpoint.com/products/white/index.html.
One of the more interesting elements of Check Point Firewall-1 is that it includes time object control. That is, one can assign certain times of the day to perform certain access restrictions. Firewall-1 also has provisions to distribute process loads among a series of workstations.
SunScreen
Company: Sun Microsystems
Specs: http://www.sun.com/security/overview.html
Home: http://www.sun.com
Sun's SunScreen is comprised of a series of products. In the SunScreen product line, Sun has addressed one of the primary problems I mentioned previously: If your bottleneck is broken, your network is completely exposed. Sun's new line of products will likely revolutionize the firewall industry (certainly on the Sun platform). The chief products include
Cross Reference: Some specs for SunScreen EFS are located online at http://www.sun.com/security/prod_spec.html.
Cross Reference: Check out SunScreen SKIP online at http://www.sun.com/security/skip.html.
IBM Internet Connection Secured Network Gateway
Company: Internal Business Machines (IBM)
Specs: http://www.ics.raleigh.ibm.com/firewall/info.htm
Home: http://www.ics.raleigh.ibm.com/firewall/overview.htm
This product is designed for AIX. Like Sun's SunScreen product line, it is capable of hiding the IPs of your internal network. It supports application proxies and has exceptional logging and reporting capabilities, as well as isolated Web services.
Cross Reference: For an extremely comprehensive study of IBM's Internet Connection Secured Network Gateway, visit http://www.ncsa.com/fpfs/ibm.html at NCSA.
Cisco PIX Firewall
Company: Cisco Systems
Specs: http://www.cisco.com/univercd/data/doc/cintrnet/prod_cat/pcpix.htm
Home: http://www.cisco.com
This firewall relies not on application proxies (which can consume additional network resources and CPU time) but instead on a secure operating system within the hardware component itself. Special features include an HTML configuration and administration control tool, IP concealment and non-translation, easy configuration, and support for 16,000 instant connections.
Firewalls now comprise the most commonly accepted method of protecting a network and, for the most part, seem to be impenetrable when attacked by 95 percent of the cracking community. Moreover, firewall technology is yet in its infancy. Nevertheless, firewalls have been cracked in the past. It is also worth noting that some firewalls can raise security issues themselves. For example, it was recently found that the Gopher proxy in a Raptor product can, under certain circumstances, leave a Windows NT server vulnerable to a denial-of-service attack. (The CPU climbs to near 100 percent utilization.)
The future of firewall technology is a very interesting field indeed. However, if you have truly sensitive data to protect (and it must be connected to the Internet), I advise against using a firewall (commercial or otherwise) as your only means of defense.
Internet Firewalls and Network Security (Second Edition). Chris Hare and Karanjit Siyan. New Riders. ISBN: 1-56205-632-8. 1996.
Internet Firewalls. Scott Fuller and Kevin Pagan. Ventana Communications Group Inc. ISBN: 1-56604-506-1. 1997.
Building Internet Firewalls. D. Brent Chapman and Elizabeth D. Zwicky. O'Reilly & Associates. ISBN: 1-56592-124-0. 1995.
Firewalls and Internet Security : Repelling the Wily Hacker. William R. Cheswick and Steven M. Bellovin. Addison-Wesley Professional Computing. ISBN: 0-201-63357-4. 1994.
Actually Useful Internet Security Techniques. Larry J. Hughes, Jr. New Riders. ISBN: 1-56205-508-9. 1995.
Internet Security Resource Library: Internet Firewalls and Network Security, Internet Security Techniques, Implementing Internet Security. New Riders. ISBN: 1-56205-506- 2. 1995.
Firewalls FAQ. Marcus J. Ranum.
NCSA Firewall Policy Guide. Compiled by Stephen Cobb, Director of Special Projects. National Computer Security Association.
Comparison: Firewalls. Comprehensive comparison of a wide variety of firewall products. LANTimes. June 17, 1996.
There Be Dragons. Steven M. Bellovin. Proceedings of the Third Usenix UNIX Security Symposium, Baltimore, September 1992. AT&T Bell Laboratories, Murray Hill, NJ. August 15, 1992.
Rating of Application Layer Proxies. Michael Richardson.
Keeping Your Site Comfortably Secure: An Introduction to Internet Firewalls. John P. Wack and Lisa J. Carnahan. National Institute of Standards and Technology.
SQL*Net and Firewalls. David Sidwell and Oracle Corporation.
Covert Channels in the TCP/IP Protocol Suite. Craig Rowland. Rotherwick & Psionics Software Systems Inc.
If You Can Reach Them, They Can Reach You. William Dutcher. A PC Week Online Special Report, June 19, 1995.
Packet Filtering for Firewall Systems. February 1995. CERT (and Carnegie Mellon University).
Network Firewalls. Steven M. Bellovin and William R. Cheswick. IEEECM, 32(9), pp. 50-57, September 1994.
Session-Layer Encryption. Matt Blaze and Steve Bellovin. Proceedings of the Usenix Security Workshop, June 1995.
A Network Perimeter With Secure External Access. Frederick M. Avolio and Marcus J. Ranum. An extraordinary paper that details the implementation of a firewall purportedly at the White House.
Packets Found on an Internet. Steven M. Bellovin. Lambda. Interesting analysis of packets appearing at the application gateway of AT&T.
Using Screend to Implement TCP/IP Security Policies. Jeff Mogul. Rotherwick and Digital.
Firewall Application Notes. Livingston Enterprises, Inc. Good document that starts by describing how to build a firewall. It also addresses application proxies, Sendmail in relation to firewalls, and the characteristics of a bastion host.
X Through the Firewall, and Other Application Relays. Treese/Wolman. Digital Equipment Corp. Cambridge Research Lab.
Intrusion Protection for Networks 171. BYTE Magazine. April, 1995.
Benchmarking Methodology for Network Interconnect Devices (RFC 1944). S. Bradner and J. McQuaid.
Firewall Performance Measurement Techniques: A Scientific Approach. Marcus Ranum.
Warding Off the Cyberspace Invaders. Amy Cortese. Business Week. 03/13/95.
Vulnerability in Cisco Routers Used as Firewalls. Computer Incident Advisory Capability Advisory: Number D-15.
WAN-Hacking with AutoHack--Auditing Security behind the Firewall. Alec D.E. Muffett. Written by the author of Crack, the famous password-cracking program. Extraordinary document that deals with methods of auditing security from behind a firewall (and auditing of a network so large that it contained tens of thousands of hosts).
Windows NT Firewalls Are Born. PC Magazine. February 4, 1997.
IP v6 Release and Firewalls. Uwe Ellermann. 14th Worldwide Congress on Computer and Communications Security. Protection, pp. 341-354, June 1996.
The SunScreen Product Line Overview. Sun Microsystems.
Product Overview for IBM Internet Connection Secured Network Gateway for AIX, Version 2.2. IBM firewall information.
The Eagle Firewall Family. Raptor firewall information.
Secure Computing Firewall&tm; for NT. Overview. Secure Computing.
Check Point FireWall-1 Introduction. Check Point Technologies firewall information.
Cisco PIX Firewall. Cisco Systems firewall information.
Protecting the Fortress From Within and Without. R. Scott Raynovich. LAN Times. April 1996.
Internet Firewalls: An Introduction. Firewall white paper. NMI Internet Expert Services.
Features of the CentriTM Firewall. Centri firewall information.
Five Reasons Why an Application Gateway Is the Most Secure Firewall. Global Internet.
© Copyright, Macmillan Computer Publishing. All rights reserved.