The Motivation for Firewalls Suppose you are given a machine, and asked to harden it against external attack. How do you do it? One starting point is to look at the network services that this machine is providing to the outside world. If any of its network services are buggy or have security holes, a hacker may be able to penetrate your machine by interacting with that application. As we know, bugs are inevitable, and bugs in security-critical applications often lead to security holes. Thus, the more network services your machine runs, the greater the risk. This suggests one simple way to reduce the risk of external attack. Turn off every unnecessary network service. Disable every network-accessible application that isn't absolutely needed. Build a stripped-down box that is running the least amount of code necessary; after all, any code that you don't run, can't harm you. And for any network service that you do have to run, double-check that is has been implemented and congured securely, and take every precaution you can to render its use safe. This is an intuitive and effective approach, and it can work well when you only have one or two machines to secure, but now let's consider what happens when we scale things up. Suppose you are in charge of security for all of Macrosloth Corp. Your job is to protect the computer systems, networks, and computing infrastructure of the entire company from external attack. How are you going to do it? If the company has thousands of computers, it won't be easy to harden every single machine individually. There may be many different operating systems and hardware platforms. Different users may have vastly different users, and a service that can be disabled for one user might be necessary to another user's job. Moreover, new machines are bought all the time, machines come and go every day, and users upgrade their machines. At this scale, it is often hard even to get an accurate list of all machines inside the companyand if you miss even one machine, it is then a vulnerable point that can be broken into and might serve as a jumping-off point for attackers to use to attack the rest of your network. The sheer complexity of managing all of this might make it infeasible to harden each machine individually. Nonetheless, it's still true that one risk factor is the number of network services that are accessible to outsiders. This suggests a defense. If we could block, in the network, outsiders from being able to interact with many of the network services running on internal machines, we could reduce the risk. This is exactly the concept behind firewalls: the rewall is a device designed to block access to network services running on internal machines. At this point, it's clear that there are two questions we'll have to settle: 1. What is our security policy? For example: Which network services should be made visible to the outside world, and which ones should be blocked? How do we distinguish insiders from outsiders? 2. How will we enforce this security policy? How do we build a rewall that does what we want? What are the implementation issues? CS 161, Fall 2005, Notes 2 1 Internet Internal Network Figure 1: An example network topology, with a single link connecting the internal and external networks. We'll tackle these each on their own. 2 Security Policy A little bit of background. In its simplest form, we can visualize the topology of the internal network as shown in Figure 1. We have an internal network, which hosts all the company's machines, and the external world (e.g., the rest of the Internet), and a communications link between the two. How do we decide what is inside, and what is outside? We might decide that we trust all company employees, but we don't trust anyone else (a very simple threat model). Then we'll dene the internal network to contain machines owned by trusted employees, and the external world to include everything else. The link to our ISP might be the link between these two worlds. The very simplest security policy is an outbound-only policy. Let's distinguish between inbound and outbound connections. Inbound connections are initiated by external users and attempt to connect to services running on internal machines, while outbound connections are attempts by internal users to initiate contact with external services. An outbound-only policy would permit all outbound connections (reasoning: internal users are trusted; if they want to open a connection, we'll let them), but all inbound connections would be strictly denied. The effect is that none of our network services are visible to the outside world, though of course they can still be accessed by internal users. Unfortunately, this policy is probably too restrictive for any large organization, since it means that the company cannot run a webserver, a mail server, a FTP server, and so on. Therefore, we will need a little more exibility in how we dene the security policy. In general, the security policy is going to be a particular kind of access control policy. We will have two subjects: an anonymous external user, and a generic inside user1. The objects are the set of network services that are run on all inside machines; if there are 1000 machines, and each machine runs 5 network services, we end up with 5000 objects. The access control policy should then specify, for each subject and each object, whether that subject has permission to access that object. Firewalls are usually used to enforce a particularly simple kind of access control policy. Inside users are permitted to connect to any network service desired. External users are restricted: there are some services that are intended to be externally visible, and external users are permitted to connect to these services, but there are also other services that are not intended to be accessible from the outside world, and those services are blocked by the access policy. The rst thing the security administrator needs to do is identify a security policy, or in other words, which services external users should and shouldn't be given access to. How should we do it? Broadly speaking, there are two philosophies we might use to determine which services we allow external users to connect to: Default-allow: By default, every network service is permitted, unless it has been specically listed 1Alternatively, we could say that the subjects will be divided into two groups. The inside users group contains all company employees, and the external users group contains all everyone else. In our case, the access granted to a subject will be determined solely by which group he or she is in. CS 161, Fall 2005, Notes 2 2 as denied. Under this approach, one might start off by allowing outside users access to all internal services, and then mark a few that are known to be unsafe and should be blocked. For instance, if tomorrow we hear about a new Slammer II worm, which spreads by exploiting a vulnerability in SQL servers, then we might revise our security policy by denying outsiders access to all our SQL servers. Default-deny: By default, every network service is denied, unless it has been specically listed as allowed. We might start off with a list of a few known servers that need to be visible to the outside world and that have been adjudged to be reasonably safe; external users will then be implicitly denied access to any service not the list. If our users complain that, say, their department's FTP server is not accessible to the outside world, we can check whether they are running a reasonably safe and properly congured implementation of the FTP service and add them to the allow list if so. A default-allow policy sounds a lot more convenient, because from a functionality point of view, everything stays working. However, from a security perspective, default-allow is seriously awed. The problem is that default-allow fails open: if you make any mistake (i.e., there is some service that is vulnerable, but you forget to add it to the deny list), then the result is likely to be a security failure. In comparison, default-deny fails closed: if you make a mistake (i.e., some service that is safe has been mistakenly omitted from the allow list), then the result is merely a loss of functionality or availability. When operating at large scales, such errors of omission are likely to be common2. Because errors of omission are a lot more dangerous in a default-allow policy than in a default-deny policy, and because the cost of a security failure is often a lot more than the cost of a loss of functionality, default-deny is usually a much safer bet. Default-deny has another advantage. When the system fails open, you may never notice the failure. Attackers who penetrate your system security are unlikely to tell you that they have done so, and so security breaches may go unnoticed for a long time. This gets you into an arms race, where you have to keep up with all the attacks hackers discover and even stay ahead of them. Arms races are generally a losing proposition, because there are a lot more of the hackers than there are of the defenders, and the hacker only has to win once to make you really miserable. In contrast, when the system fails closed, someone will probably notice (they'll complain: why isn't the FTP service working?), and the omission will be immediately evident and easily correctable. This makes failures in default-allow systems that much more costly than failures in default-deny systems. For these reasons, almost all well-implemented rewalls use a default-deny policy. The security policy species a list of allowed services which external users are permitted to connect to, and all other services are forbidden. In many cases, some kind of risk assessment and cost-benet analysis is applied to every network service on the allowed list; if some service is too risky compared its benets, then it is removed from the allowed list. How can we identify network services? Let's recall some background on TCP/IP networks. A TCP service is recognized by the machine's IP address and the TCP port number on that machine. For instance, the web server on www.cs.berkeley.edu (currently) resides at IP address 169.229.60.105, port 80. The mail service resides at 169.229.60.93, port 25. UDP services are identied similarly, though of course the port namespace for TCP and UDP is disjoint (a TCP service on port 25 is different from a UDP service on port 25). 2Indeed, sins of omission are a lot more likely than sins of commission. There may be thousands of potential services out there, but only a few dozen are likely to make your deny or allow list. This means there are thousands of chances to inadvertently omit a service from the list (an error of omission), but only a few dozen chances to inadvertently put something on the list that doesn't belong there (an error of commission). CS 161, Fall 2005, Notes 2 3 Internet