Other Kinds of Firewalls Packet lters are the crudest kind of rewall: they operate at the network level, and generally look only at TCP, UDP, and IP headers. One can also build rewalls that restrict trafc according to the contents of the data elds; these are known as application-layer rewalls, or application rewalls for short. Application rewalls have some security advantages, because they can enforce more restrictive security policies and because they can transform data on the y. We may come back to the topic of application rewalls later in the course. We've only scratched the surface of the topic in this lecture. For more information on rewalls, the authoritative reference is Cheswick, Bellovin, and Rubin: Firewalls and Internet Security: Repelling the Wily Hacker. Packet ltering software is available for many operating systems: e.g., Linux has iptables, OpenBSD/FreeBSD has PF, and Windows XP has its own rewall. 5 Principles Firewalls embody several useful principles that you can apply elsewhere in computer security. As mentioned earlier, rewalls can be thought of as enforcing a particular kind of access control policy, and they are 4There are some details I'm omitting here. The attacker will need to know the initial sequence number (ISN) the target host has chosen for this connection. The ISN appears in the SYNjACK packet, but the SYNjACK packet has been routed to 1.2.3.7, not to the attacker. However, sufce it to say that there are usually several ways that an attacker can predict, guess, or learn this ISN and continue the attack. CS 161, Fall 2005, Notes 2 6 reference subject request monitor object Figure 3: A reference monitor controls access by subjects to objects. optimized for this special task. The notion of a chokepoint is crucial, because it is what makes it possible to enforce the access control policy, and we see the same thing come up elsewhere in access control. In general, the mechanism that enforces an access control policy often takes the form of a reference monitor. The purpose of a reference monitor is to examine every request to access any controlled resource (an object) and determine whether that request should be allowed. See Figure 3. There are three security properties that any reference monitor should have: Always invoked: The reference monitor should be invoked on every operation that is controlled by the access control policy. There must be no way to bypass the reference monitor. This is sometimes also known as the complete mediation property: all security-relevant operations must be mediated by the reference monitor. Tamper-resistant: The reference monitor should be protected from tampering by other agents. For instance, other parties should not be able to modify its code or state. The integrity of the reference monitor must be maintained. Verifiable: It should be possible to verify the correctness of the reference monitor, including that it does actually enforce the desired access control policy correctly. This usually requires that the reference monitor be extremely simple, as generally it is beyond the state of the art to verify the correctness of subsystems with any appreciable degree of complexity. We can recognize a rewall as merely an instance of a reference monitor. How are these three properties achieved? Always invoked: We assumed that the packet lter is placed on a chokepoint link, with the property that all communications between the internal and external networks must traverse this link. Thus, the packet lter has an opportunity to inspect all such packets. Moreover, packets are not forwarded across this link unless the packet lter inspects them and forwards them (there is no other mechanism by which packets might ow across this link). How do we know whether the packet lter really is a chokepoint? The following thought experiment might help elucidate. Get out a giant bucket of red paint, and imagine painting every internal machine red. Then, we'll paint every wire that's coming out of any red machine red. (During this step, all of the networks connected to internal machines get painted red.) And any machine connected to a red network will be painted red, too, with only one exception: don't ever paint the packet lter itself red. Continue this recursively until there is no more painting to be done. Now ask yourself, when the whole process has stopped, which machines are painted red? We can see that the only way any red device can come in contact with any non-red device is if the non-red device is the packet lter. If we've set up our system properly, then the red machines should be exactly the machines on our internal network. Moreover, no external machine on the other side of the Internet should have recieved any red paint. In this case, we can interpret red things as resources to be protected, and non-red things are things we CS 161, Fall 2005, Notes 2 7 don't have to trust (because their access to our internal network is limited by the packet lter). If it works out like this, then we know that the packet lter cannot be bypassed. Of course, in some cases we discover that it doesn't work out we hoped. For instance, maybe a user hooks up an unsecured wireless access point to his internal machine. Then anyone who drives by with a wireless-enabled laptop effectively gains access to the internal network (gets painted red), bypassing the packet lter. This illustrates that, to use a rewall safely, we'd better be sure that we've covered all the links between the internal network and the external world with rewalls. This set of links is sometimes known as the security perimeter. Tamper-resistant: We haven't really discussed how to make packet lters resistant to attack. However, they obviously should be hardened as much as possible, because they are a single point of failure. Fortunately, their desired functionality is relatively simple, so we should have a reasonable chance at protecting them from outside attack. For instance, they might not need to run a standard operating system, any user-level programs, or network services, eliminating many avenues of outside attack. Of course, the physical security of the packet lter device must be protected. Verifiable: In current practice, no one bothers verifying (in any systematic way) that the packet lter is correct. Sadly, packet lter software is usually too complex for this to be feasible. And we do suffer as a result of our failure to verify packet lters: over time, there have been bugs that allowed attackers to defeat the intended security policy by sending unexpected packets that the packet lter doesn't handle quite the way it should. The notion of a reference monitor recurs over and over again, and the three requirements for a secure reference monitor are worth memorizing. Firewalls also embody another useful principle: Orthogonal security: If the security mechanism is orthogonal from, and transparent to, the rest of the application, then it can be deployed to protect pre-existing legacy systems much more easily than security mechanisms that must be integrated with the rest of the system. A reference monitor that lters the set of requests, dropping unallowed requests but allowing allowed requests to pass through unchanged, is essentially transparent to the rest of the system: other components do not need to be aware of the presence of the reference monitor. Such mechanisms are easier to retrot into legacy systems. Another potential benet of orthogonal mechanisms is that they can be cascaded in series or in parallel. When cascading a number of reference monitors in series, each request will be allowed only if all reference monitors allow it, and such redundancy might provide a higher level of security, as any attack must defeat all of the monitors. Cascading in parallel allows separation of concerns: for instance, we could arrange that all TCP connections are directed to one reference monitor specialized at handling TCP connections, and all UDP connections to a different one (though it is not clear what benet this would provide). 6 Experience with Firewalls Firewalls have been tremendously widely used. They are one of the best success stories of technology transfer from the research to practice; the rst paper was published at a research conference in 1990, and CS 161, Fall 2005, Notes 2 8 within a few years rewalls were widely used5. Why do they work well? Central control: A rewall is a single point of control. When security policies change, only the rewall has to be updated; individual machines do not need to be touched. For instance, if a new worm comes out, it is often possible to very quickly block it by modifying the rewall's security policy slightly, and all internal machines benet from this protection. This makes it easier to administer, control, and update security policy for an entire organization. Easy to deploy: Because rewalls are essentially transparent to internal hosts, there is an easy migration path, and they are easy to deploy (incrementally, or all at once). Because one rewall can protect thousands of machines, they provide a huge amount of leverage. An important problem: They address a burning problem. Security vulnerabilities in network services are rampant. In principle, a better response might be to clean up the quality of the code in our network services; but that is an enormous challenge, and rewalls are much easier. Firewalls have some serious shortcomings, though. How do rewalls fail? What are their disadvantages? Loss of functionality: The very essence of the rewalls concept involves turning off functionality, and often users miss the disabled functionality. Some applications don't work with rewalls. For instance, peer-to-peer networks have big problems: if both users are behind a rewall, then when one user tries to connect to another user, the second user's rewall will see this as an inbound connection and will usually block it. The observation underlying rewalls is that connectivity begets risk, and rewalls are all about managing risk by reducing connectivity from the outside world to internal machines. It should be no surprise that reducing network connectivity can reduce the usefulness of the network. The malicious insider problem: Firewalls make the assumption that insiders are absolutely trusted. In security, trust is a ve-letter word, because a trusted party is someone who you have given the power to violate your security policy. Firewalls are usually used to establish a security perimeter between the inside and outside world. However, if a malicious party breaches that security perimeter in any way, or otherwise gains control of an inside machine, then the malicious party becomes trusted and can wreak havoc, because inside machines have unlimited power to attack other inside machines. For this reason, Bill Cheswick called rewalled networks a crunchy outer coating, with a creamy center. There is nothing that the rewall can do once a bad guy gets inside the security perimeter. We see this in practice. For example, laptops have become a serious problem. People take their laptop on a trip with them, connect to the Internet from their hotel room (without any rewall), get infected with a worm or virus, then bring their laptop home and connect it to their company's internal network, and the worm proceeds to infect all other internal machines. "Malicious” applications: The previous two properties can combine in a particularly nasty way. Suppose that an application developer realizes his protocol is going to be blocked by his users' rewalls. What do you think he is going to do? Often, what happens is that the application tunnels its connection over HTTP (web, port 80) or SMTP (email, port 25). Many rewalls allow port 80 trafc, because the web is the killer app of the Internet, but now the rewall cannot distinguish between this 5For instance, the company Checkpoint was founded in 1993. Today it has the greatest market share in rewalls and brings in $500 million per year in revenue. CS 161, Fall 2005, Notes 2 9