 Packet filtering firewalls, as a packet comes into the firewall, it checks the packet details like addresses, protocol type, and so addresses include IP addresses, port number, and then makes a decision to drop or allow the packet through. So we've done some details of that. We can think in terms of implementation regarding layers that the packet filtering firewall, the packet comes in, let's say a TCP packet comes in, the firewall, if it accepts it, it just passes through as is. If the packet is accepted, nothing's modified. So the packet filtering firewall doesn't change anything when a packet is accepted. And in fact, often packet filtering firewalls don't look at the data. They just look at the header fields to see where it's going, what protocols being used. They don't look at the contents of the message. One good thing about that is it's quite generic. The firewall doesn't have to understand the contents of messages. It just needs to know the common packet formats. It doesn't need to know anything about HTTP requests or secure shell messages or one of the many other application layer protocols. So packet filtering firewalls don't normally do not worry about what applications being used except based on port numbers. Makes them very easy to implement and very fast. The packets can flow through them very quickly. But sometimes we'd like to control the traffic based on what application is being used. And there are a couple of ways to do that. So we've gone through different aspects of packet filtering firewalls. We saw an extension of that is stateful packet inspection where we not only create rules but the firewall automatically keeps some information about the recent or the created TCP connections. They keep some state information. We'll look at two different types of firewalls called an application proxy. And we'll see another type of proxy as well. Here an application proxy which is also sometimes referred to as an application level gateway. It acts as a relay really for application traffic. So maybe the picture tries to show that. So this is our firewall application proxy, the device. You can think to the left of that is internal devices like your computer inside the network and to the right is the outside world, the external networks that we want to connect to or vice versa. So the packets come through the proxy from say inside going out. And when you run your application like a good example is your web browser, you're running your web browser on an internal computer. Normally that web browser talks to a web server on an external computer. What we do with an application proxy is that really the web browser talks to the proxy, an application instance on this firewall. It talks to that which then may inspect what's happening, what exchange of web pages is taking place and then if everything's accepted that firewall device will then start a separate application connection to the real server. So this is the role of a proxy. A proxy does something on behalf of others. So what the proxy is doing here is acting as a client and a server on behalf of the real client and server. And the benefit from a security perspective is that this firewall understands the application level protocol such as HTTP. And when I say understand, it means it knows the formats of the messages. It knows the fields, what's expected, what's not. And it will even look at the data, look at the URLs requested, the HTML that comes back. And it can inspect that information and make a more accurate decision whether to accept or reject this packet. For example, it can reject based upon the content. Not based on whether you access Facebook but whether the page you accessed on Facebook contains specific content. So it can be more finer detail inspection of the content. And therefore it can be more secure because we can control in more detail what comes in and what goes out. So that's one of the advantages. The main problem with an application level proxy is that this firewall must understand the application level protocol like HTTP. Well that's fine. It's not hard to write some software that understands HTTP. But it only works for HTTP. It doesn't work if someone uses secure shell. It doesn't work if someone uses a game application or one of the many other thousands of applications. So application level proxies are usually specific to one type of application like web browsing. But they won't work for email. For that you need a separate proxy. So they only for specific uses but for those particular uses can be more secure. So what we can, if we use HTTP as an example we can try and draw what happens with an application level proxy. We have your say client computer. So the original client internal let's say the internal network and the external will be over here. The outside world. And there's a client computer. Here's our client computer or your computer, the internal computer. This is the firewall device. Normally when you're using HTTP your internal computer communicates directly with the external computer. Let's say the web browser talks to the web server using HTTP. But with an application level proxy what happens is that the HTTP request is intercepted by the firewall. So you send your HTTP request to get a web page, that's a P. Instead of going through the firewall and then eventually to the web server it's inspected by the firewall. So it really ends there as received by the firewall. If the firewall wants to allow this request to go out the firewall then creates a separate request that sends to the real web server. That's if the request was accepted. If it was rejected of course it doesn't go out. And the real web server receives a request. Who did it receive a request from? It receives a request from the firewall. So if you think of the source IP address it can be that of the firewall and the server sends back a response to that firewall. The web page for example. And the firewall can then inspect the response. So the firewall must implement both a HTTP server to receive the request and a HTTP client to send a request and get a response. If it processes that response and sees everything is okay, there's no content in there that it wants to reject then it's passed on through to the internal computer. So in this case this is the web server client, the client application. This was the server application but what the firewall does really, the application level proxy is it acts as both. You can think it's a server from this perspective, it receives a request, sends a response. So our internal computer, the client has communicated with the server on the firewall and from the perspective of the external computer the firewall is a client. Because it creates a HTTP request and receives and processes a HTTP response. So that's the typical role of a proxy. In general a proxy is someone in the middle who acts on behalf of the others, communicating. So the proxy acts as a server from the original client and acts as a client to the original server. And from a security perspective allows the firewall to inspect the contents in much finer detail. Whereas a packet filtering firewall would not understand what a HTTP request was. It would just see an IP packet, it would look at the addresses, source IP, destination IP, source port, destination port, protocol and decide to accept or reject it. But it doesn't look at the HTTP header fields, it doesn't look at the content of the HTTP response. So that's the difference in this case. It can be more secure than packet filtering firewall but extra overhead and specific to the application. So they are used usually just tailored for specific applications. So they're not generic and one of the problems from a user's perspective, if the packet goes through the firewall, it's effectively modifying the original packet sent from the client and the client may observe that. So the original client may observe something's been changed in my original request. So that may have an impact on some applications when you use a proxy. There's a variation of the application level proxy called a circuit level proxy firewall. It's almost the same, if we look at the two diagrams down the bottom, the difference. So it's also a proxy, it acts as a server to the original client and a client to the final server but it does the proxying at the transport layer level. It intercepts the TCP packets. That first TCP SIN packet that comes from client to server is intercepted by this proxy. The proxy looks at it, makes a decision to allow it. If it allows it, then it sends a TCP SIN to the real server and when the TCP SIN act comes back it does the same, it intercepts, checks that and may even modify those packets where necessary. So it intercepts the TCP connection in this case. We say it's at the transport level. The benefit here is that it can be independent of the applications. It works at the TCP level rather than at HTTP or the specific applications. Essentially we end up with two TCP connections between client and proxy and proxy to server. So with a circuit level proxy, it looks similar but we think it's not at the application level but at the TCP level. The same situation where we have a TCP client and a TCP server. The above one was a HTTP client and a HTTP server. And when we send our request, the TCP packets are intercepted by this circuit level proxy and I'll not write the names but this becomes TCP connection one. We have a connection from our client to the firewall and a second separate TCP connection here. And the device, the firewall in the middle is acting as a TCP server from the perspective of the original client and a client from the perspective of the final server. So again it's a proxy acting on behalf of the original communicators but it's doing it at the level of TCP or the transport. So it sets up a TCP connection. Of course HTTP messages can be sent using TCP but other applications also use TCP. So this can be more generic than an application level firewall because it handles or it operates just at the TCP level but the problem being it doesn't necessarily inspect the content of the data. It doesn't care whether the message is a HTTP request, an email, an instant message or a game packet. It just looks at the TCP data. So the firewall in this case must be designed and implemented to handle those two TCP connections. And it gives some more control to the firewall compared to packet filtering firewalls but extra complexity involved in that firewall. Think that internally we don't just have one computer, we have thousands of computers inside our organization making thousands, hundreds of thousands of TCP connections going out. So the firewall must keep track of all of them and all of them require some memory and some processing to keep track of. So it becomes quite complicated here. So there's a significant overhead compared to a simple packet filtering firewall. So there are some overheads involved with using application level firewalls. So often they're only used for specific purposes. One case may be to use application level gateways for incoming traffic, for people connecting into your servers and have a circuit level TCP proxy to control from the internal users connecting out. So there are different variations so that we don't have to inspect everything at the application level. So I just wanted to mention those because you may see proxies come up in a number of different scenarios. Proxy servers come up where it acts on behalf of the original communicating entities. To finish let's have a brief look at where we can put a firewall. And we've mentioned it already. We can say a firewall can be in a host on your computer but maybe for larger organizations it makes more sense not to have one on every computer but to have a single firewall that sits on a router or at some point in the network that controls all the traffic coming into the network. Let's look at the firewall locations. So we can have firewalls on hosts. On your computer you may have a firewall. It controls the traffic just coming into and out of your computer. Maybe on a server that we have operating we can install a firewall. So it controls or tries to secure just that computer. But as our number of users grows having a firewall on every single computer is very inconvenient. We need to set it up, have the software running, make sure the software is up to date. So it makes more sense to have firewalls on devices that protect the entire network. So it's common to then if we're going to have a firewall on a device that protects the network is to split the internal network into different components. And a simple split is to split the internal network into two zones. Think of SIT as our internal network. What computers are inside SIT? What are the purposes of the computers? What do we have inside SIT? In our Bunker-D network what type of computers or groups of computers do we have? What do we use our computers for? For study, okay, so who uses it? Students, okay, so students use computers, their own computers which connects the internal network, the lab computers, alright, so students use computers, anyone else? Study members do, the lecturers use computers for teaching, okay, again for study purposes, plus for other things like the office computer, anyone else? We do have staff around that are not teaching but doing things like keeping track of finances, when you have to pay your money, when you have to keep your academic records, they need to have computers to keep track of all of that. Where is all that data stored? Like all your academic records, all the finance information for SIT, where is that stored? Is that on my desktop computer? No, where is it? It's on some server or servers somewhere in the network, okay, so we have the end-user computers for students, for faculty, for staff, for running, for doing their normal jobs, but we also often have some servers for storage of data and providing special services, including a website, multiple websites in fact, and email service, so that we can send emails to each other and outside. So we can split them into two types of devices or into two zones. We have servers which we want to allow people outside to access, like the SIT webpage, registration, ICT, all those websites are what we say public-facing servers. And not just for internal use, we want outsiders to access them, and email servers, even DNS servers, so there are a number of servers which we may want to allow others to access. Then we have our internal computers. There's no real need for someone outside to initiate contact with my laptop inside. I may want to initiate contact to a website outside, that's normal, but there's no need for someone to try and be outside and connect to, say, a web server on my laptop. If I have a web server on my laptop, I don't want people outside to access it, because my laptop is not a real official SIT website, it's just for an internal use only. So we say they're a public-facing service, then there's the end-user computers and internal servers even, like the database for finances. It's a server that people can access only from inside SIT, very internal. So we put these public-facing computers in a separate zone of our network and give them a separate level of protection with our firewall, and that zone is often called the DMZ, the demilitarized zone. It's a separate part from the other part of the internal network. That's shown via the diagrams here. The top one first. Here's the outside world. Beyond this red router, so out here is the outside world, this is the router that connects the outside world into our internal network. So everything comes via that router. When it says WANIA means the wide-area network connection. So as data comes from outside in, it comes through the router, and this green box here is a firewall. So this firewall will control if people send from outside in what can come in and may also control what goes out. But internally we've got two zones. We've got what's called our intranet, which is our end-user computers, our laptop, your mobile phones, the lab computers, the internal computers, and maybe some internal servers, like the database servers, which we don't need people outside to connect to. We don't want people outside to connect to our internal computers. And then we have our public-facing computers, our website for SIT, our email server, maybe DNS server and other servers. We separate them into the DMZ, the demilitarized zone. And then we configure our firewall in this box such that anything coming from outside, if it's coming from outside, it can never go in unless it's a response from an initial connection from internal. Remember back to stateful packet inspection, we only need to control that very first packet. So if someone outside is trying to connect to a server on a computer on the intranet, that packet gets to the firewall, the packet, the firewall says, no, you cannot. Nothing is allowed to come in to the intranet from outside. Everything is rejected. The only things that are allowed to come into our network, the only request to create a connection, are if they're destined to one of the servers on the DMZ, like our website. Yes, people outside can send a request to our web server, so the firewall would be configured to say, okay, if the destination is the SIT web server, we direct that packet down to this DMZ zone. And it goes to the web server. The point of doing this is it makes the configuration of the firewall very easy regarding securing the internal network. Reject everything destined to the intranet. Very easy to create a rule there. Very hard for you to make a mistake when you write that rule. And that's important with firewalls, that we don't set up the firewall in an incorrect manner and allow traffic in that shouldn't be. And it's quite easy to identify that only the packets that are allowed in are those destined to the computers in the DMZ, which is just usually a small set of computers, not maybe five, ten computers as opposed to thousands on the intranet. So the idea is to make the rules we used in the firewall simple to set up. Nothing to the intranet is allowed in. The only thing allowed in is it goes to the DMZ. Going out, well, we can allow the intranet to connect out to the public websites. That's okay. And we can even allow the intranet connect to the DMZ. But it's the inwards bound traffic that we want to control. That's the first case of using these two zones using the DMZ with our firewall. What's the second case? The bottom picture, what's the difference? The bottom one has two firewalls. Why would we want two firewalls? The top one just has a single that controls. Think of the traffic coming in. The bottom picture has two firewalls, the two green boxes. What's the benefit of having, well, maybe easier. What's the problem of having two firewalls? We need two devices. Maybe we need to set up two devices. We need to have the extra cost. We don't just have one, we have two now. What's the benefit? Why would we want to have two if it costs more to have two? Share what? Share the errors in what way, yeah? They can have different purposes. They can have different purposes. What's an example in this case? What could one do that's different than the other? Again, it's about simplifying things that's set up and protecting from mistakes. Firewall rules in practice, the firewall tables may have not just three or four rules, they may have hundreds of rules in there, even thousands of rules in a firewall. And some human needs to write those rules. If they make a mistake, that may make our entire network insecure. So one of the backup solutions is to try and, in this case, use two firewalls. So the way that we can configure them is that from the first firewall, if we think of the inbound traffic coming from outside in, if it reaches the first firewall, similar to the previous one, if it's destined to the DMZ, allow it. If it's destined to the internet, don't allow it in. So what's the purpose of the second one? Well, the second one sort of acts as a backup here. From the second one's perspective, if traffic is inbound, if it's destined to the internet, to anywhere beyond that firewall, reject it. Everything's rejected that comes into that firewall because there's no need for traffic to be initiated from outside and come to the internet. So it greatly simplifies this firewall setup, at least for one direction. Everything coming in, reject. Just one rule. The first firewall allows the trafficer to go to the DMZ. The second one acts as a backup, just in case. So it adds that second level of protection. And in security, we often apply the principle of defense in depth. We don't just rely on one security mechanism. We rely on multiple layered security mechanisms. So if one fails, the next one will back us up. And if that fails, the next technique backs us up. And this is the principle applied here. If something goes wrong in the first firewall, the second one will back us up and not allow the traffic in. So that's another configuration of using a DMZ. More costly, but maybe more secure. This is just another picture showing that second case. The external firewall, the DMZ, the intranet, and the internal firewall, similar to the bottom picture before. So that's a little bit about the zones that we can use. Public facing servers are kept in a separate zone. We can use one or two firewalls to protect them. To finish, we know firewall controls traffic into and out of a network or a computer in special cases. We can control based upon what applications or services people are using, the direction of traffic in or out, who the users are and maybe what they're doing. Packet filtering firewalls are the simplest because they just look at fixed, predictable headers. I'm very fast. Stateful packet inspection is usually used with packet filtering firewalls. It makes the TCP rules much easier. Proxy firewalls are usually specific to applications and allow further control but add more overhead. A big issue with firewalls is human error. When you go get a job and you're asked to configure a firewall, what if you make a mistake? Maybe you get sacked from your job. You make a mistake and someone attacks your network. Well, that was your responsibility to set up the firewall. So unfortunately, we do make errors when we have a large number of rules. It's easy to miss something or maybe put the wrong number in. So there are different techniques we've seen to try and back up the human errors. The other problem with firewalls is that people bypass them. The firewall is set up to block packets to particular destinations. You find out what they are and you send via some intermediate device using virtual private networks. And we'll see that in one of our last topics or tunnels in general. So there are ways to bypass firewalls. And another way that things bypass firewalls is through external means, like using my mobile phone and my 3G connection. And a virus comes into our internal network and now it spreads internally because the firewall doesn't protect internal only communications. Or similar, someone brings in their laptop or USB and data gets in from outside bypassing the firewall. Those issues often need to be dealt with, not with firewalls, but with policies, with rules for the users, guidelines and education of the users. Don't pick up a USB disk from the car park and plug it into your computer at work. So some organizations will have such policies and teach people how to behave. One of the challenges with firewalls is that when you look at the packet, the firewall looks at the packet, it can make a better decision what to do with it if it looks in more detail of that packet. It doesn't just look at the headers, but it looks at the data. The further it looks into the packet, the slower the firewall will be, but the more secure it may be in making decisions. And that concept of looking deeper into the packet is called deep packet inspection. So there are many devices that will try to do that. There's a compromise between security and performance with that.