 So, our packet filtering firewall is trying to protect an internal network and also control what the internal users can do to the outside network. So, our firewall looks at the packets that go through it and based upon the packet information it accepts or drops those packets to implement some policy. So we talk about accept and drop as the actions to take on particular packets and the main information or the simple information we're looking at for each packet is the IP addresses, source and destination, the source and destination port numbers which will identify applications, the protocol number which identifies the transport protocol, TCP or UDP there are others as well. For example, ICMP has protocol number one so if we want to block pin packets we could look at the protocol number, sometimes we'll also look at which direction from the firewall the packets coming from, the interface and based on that information we create some rules and those rules tell the firewall which packets to allow through and which not. So, let's go through some examples and look at a new feature. Here's our simple network, we have a firewall, connects an internal network, the inside to some outside network and to keep the example simple we'll let's just look at two computers but there are many computers imagine, that is there are many computers inside and of course many networks outside so this is the internet on the outside but we'll use computer one and computer two as some examples here. So let's say we have the task of configuring the firewall so we need to create rules in the firewall table and that's what we'll draw here. The rules we'll use those five protocol header fields of source destination IP, source destination port and protocol, transport protocol and based on those rules we'll perform some action. Let's say as the first case we are going to have a default policy of accept everything. So with a firewall we normally create rules and for the packets that don't match those rules we take some default action and for the first example let's say our default action is accept everything, we're very open, we want to allow all the traffic through but for a simple case let's say we want to block computer two from accessing the web server on computer one. So create a rule that does that so try and think of a rule that will stop computer two from accessing the web server on computer one and the default policy, so a firewall table will often think about what do we do if we don't have a rule that matches let's say in this case it's accept. So now create a rule let's say rule number one that will block computer two from accessing computer one. What do we do? Any suggestions? This is what your quizzes and homeworks will require you to do and the exams is given a policy, given a requirement, block computer two from accessing the web server on computer one. So let's set up the firewall, source IP is 2.2.2, so here this column of source actually to save a little bit of space I'll say the source will specify both the source IP and the source port number, source IP which computer did it come from and the source port which application does it come from. So if we need to block computer two then we need to specify the source IP would be 2.2.2 and just to do it in shorthand the column to separate what port number doesn't matter with a, so this is the source application. We want to block the application here from accessing the web server. What application accesses a web server, a web browser? What port number does a web browser use? We don't know in advance, that is the firewall doesn't know. How does a web browser get a port number, the operating system on this computer assigns one, usually within some range, above 30,000 up to 65,000. So the firewall won't know what port number it uses. So let's say any value, doesn't matter what source port it is. We can write star or some other notation, star meaning matches any value. That's the source information, destination. We want to block it from accessing computer one so the destination IP. So imagine there are other computers on the internal network, I just didn't draw them. So we should specify the destination, port for web browsing port 80 because the web server on computer one should use port 80 and the firewall would know that. Protocol for web browsing we use TCP, action, default action is accept, we should drop the packet. So there's our simple firewall rule. So it should stop all the traffic between the web browser on computer two and the web server on computer one. Question? Okay, what does star mean? They have the web no port already. So I see what you're getting at. Star means all possible values in some range. Port numbers are 16 bit values so their possible values are zero up to around 65,000. So that's the possible range. Star means any of those 65,000 values if they match here then this is match. We could be more specific and say a range of values. Any value between 10,000 and 50,000, any value within some range that we want. So yes we can be more specific. In this case, well let's leave it at this and let's see another example and see what we can do to deal with other port values. But star is okay here means anything that this one says sends, doesn't matter what port that web browser uses, port one, port 100, doesn't matter what one it will be dropped if it's sent to the web server. If we were more specific, if we reduce the range then it may mean the computer 2 could use a port outside that range. Does it work? Well I think you can see that if computer 2 creates a packet, so remember most applications are client server based. Someone initiates the communications. Web browsing, computer 2 initiates the communications, it creates a packet. Source address is 2222, if it's sending the web server. Destination IP is 1111, destination port is 80 and let's say the source port is 40,123. So the browser has a port of some random number within a range of say 40,123. That packet is sent, it reaches the firewall. The protocol being used is TCP because web browsing uses TCP and this rule would match with a port number of 40,123. This star matches that value. The conditions match therefore the action is taken for that packet to drop it. So that would work and that stops the web browsing because if we stop the first packet there will be no response. So we will never get a response from the web server from computer 2's perspective. That's easy that one. Let's try a different one. Any questions on that rule? Let's say we want to do something different. We want to have a default policy of, I'll just note it down the bottom, of drop. Which is better normally. That is drop all packets that don't match our rules and we'll create some rules to accept some. Now let's say a different case where we want to allow our web browser on computer 1 to access the web server on computer 2. So computer 2 is an important web server that we need to allow our user to access. So we want to allow them to access that web server, nothing else. Create a rule or rules to do so. Now computer 1 to access the website on computer 2. Source, source IP 1111, source port, don't care. We don't know in advance. The firewall doesn't know what port number the web browser will use because today it uses 40,000, tomorrow it uses 50,000. So we cannot configure it in advance to know the port number so let's say any value, any port. Destination, easy. Destination port, web server port 80, again using TCP. Action, accept. Okay so in this case something different, default policy is to drop packets. Anything that doesn't match is dropped. So let's draw and let's, given this rule, allow computer 1, any port to contact computer 2 on port 80. What's, is it going to work? What's the problem? The policy, the requirement was allow computer 1 to access the web server on computer 2. Let's, any ideas of, here's the hint, it won't work. Any ideas why? What's wrong? I want to drop. I want that. I'm not going to change that because that's a good security approach to drop everything that we don't create rules for. So what's wrong with that? Alright let's go to the details and see, we have web browsing. So the protocol we're using is HTTP but actually before we transfer any HTTP data we actually have to set up a TCP connection. So we need to establish a connection. Let's draw what happens when we establish a connection. Computer 1 is sending something to computer 2 and they open their browser and they type in the address of computer 2 and that triggers TCP to go to work and TCP creates a connection and it sends a TCP SIN segment. If you remember TCP, we've got a 3-way handshake to establish a connection SIN, SINAC, AC. This TCP SIN segment, the source address is of course of computer 1 and let's say our web browser chose a port, I'll just choose a random number 540561. Where does that come from? The operating system chooses a port number within some range. So my browser triggers a connection to be created from client to server where the source IP is 1111, source port is 40561 and the destination IP is going to be 2222 and the destination port we know is 80, the web server. So this TCP segment has a source port, a source IP and source port and a destination IP and destination port. Is it accepted by a firewall? So this segment is created by computer 1, it goes to the firewall, does it match this condition? Well, IP address matches, port matches because it's any value. It matches, destination port matches, the protocols TCP, this packet is accepted, it gets out. The server receives it, computer 2 receives this TCP SIN and what does the server do? It replies with a SINAC and the SINAC, the source is IP 2222, it's coming from computer 2. Port is 80, the destination IP is 1111, destination port is 40561 and it's a SINAC, a TCP segment. What's our firewall do with this packet? It drops it because if the source is these two values, it doesn't match the first rule and we've only got one rule so therefore if it doesn't match the first rule, we take the default action of dropping this packet. The firewall drops this response, so the packet goes from computer 2 across the network, it gets to the firewall, compares the source values to this rule, doesn't match, therefore moves on to the default action of dropping the packet. Therefore we don't get to set up a connection and therefore our computer 1 doesn't get to browse to the website of computer 2. We didn't achieve our aim. Our aim was allow computer 1 to access computer 2 web server, allow it to browse the website. What do we do? Add a new rule. So therefore remember we need to be careful, even though we allow the 1 packet out, most protocols are request response. We send 1 packet out, 1 comes back. So our firewall should be configured to allow in both directions. So let's add a rule to allow the response. Any suggestions? What should the source be? Okay, the response comes from computer 2. Port number? Okay, because it's going to come from a web server. Destination is going to be computer 1. Port number? Again, we must configure this firewall in advance. So in this instance the port number is known but the firewall doesn't know that. So when we configure the firewall we must say any number and the protocol is still TCP. So then with this second rule, this response packet, the CINAC, doesn't match the first one but it should match the second rule and therefore would be accepted. So the response would come back and with TCP connection set up, there's a CINAC and another AC, but that third AC would match the first rule, it's the same conditions as the first packet, and then we send the HTTP GET request, again it matches the first rule, same source values, still using TCP. So the HTTP GET request would be allowed, the response would be allowed to come back because of this second rule. So we'd allow now our web browsing to work. So we need to be careful with making sure that we allow the request and the response or both directions. Any problems? So now our web browsing works from computer 1 to computer 2. We've got a problem though. What is it? Sorry? HTTP still uses TCP, so in our packet filtering firewall we're not looking at the application layer protocol, all we're looking at is the addresses and the transport layer protocol. So if we keep drawing out our sequence here, I think you'll see that it will allow the web browsing to work because the CINAC would not be dropped but it would come back because of the second rule, and then if we kept going the TCP connection would be set up, the AC would be allowed again, the source port and the destination values match, and then we send a HTTP request, the web page request, which is really just TCP, a TCP segment, TCP data. And again, because the source IP is still 1111, source port matches out any value, destination IP and the destination port still match the first rule, this one would be allowed or accepted by the firewall. And the response would be accepted to come back, so our web browsing would work. With these two rules, we've achieved our goal of allowing computer 1 to browse to computer 2, but we've created another problem. Anyone see it? Our original goal was allow only computer 1 to browse to computer 2, drop everything else, don't allow other applications, that means. We didn't allow computer 2 to browse to computer 1, we didn't allow secure shell or other applications, but there's another problem we've introduced. This second rule means that if computer 2 creates a packet and the source port is 80 and the destination is computer 1, with any port, that packet will be accepted. So this rule that we just added to allow the response actually allows computer 2 to send a packet to computer 1. And it may not be a web browsing packet, it may be some other packet. Anything that comes from this source port of 80, what comes from port 80, well normally it's a web server uses port 80. But if computer 2 was a malicious user, there's nothing to stop them from creating their own application that uses port 80. The ports are controlled by the user of the computer. Although port 80 is normally used by a web server, there's nothing to stop me from starting an application on my computer that uses port 80, an application for some malicious purpose. So what a malicious user could do then is on computer 2 start their own application that uses a source port of 80 and therefore send a packet to computer 1. Because computer 1, this rule accepts on any destination port and the firewall would allow that packet to come in. And the firewall would allow the response to go out. So if a malicious user uses computer 2, they can control the ports that they use. So we have a problem now. We created this rule to allow the response but it allows this case of a malicious user now sending packets through our firewall and defeating our purpose of controlling access to the network. Any questions on that concept? So we need to be careful with our rules that by creating a rule we don't allow something else in. And this one does allow other unintended packets in. We really just wanted it for the response. What can we do to overcome that? Yeah, we'll see that one thing we can do is allow the firewall to keep track of the port numbers that it uses. Before we get to that, what's another thing? Well, a related thing to do is we could look at the TCP flags, whether it's a SIN segment or a SIN Act. We know that a TCP SIN segment should be the first segment that comes. So this first rule, we could start to add more rules. This first one, we could add another condition that allow it if it's a TCP SIN. Now this response, if it's a SIN Act, so add another condition that looks not just at the addresses and whether it's TCP, but looks at the details of the TCP segment and looks at the flags. And maybe create further rules that have these extra conditions as what type of TCP segment it is. And that can allow us to now, if we have this condition, malicious user on computer 2 creates their own packet to send to computer 1. The first packet that that application sends is always a TCP SIN, whereas this one says the condition must be at a SIN Act. So the firewall would detect that if computer 2 creates a packet to send to computer 1, it wouldn't match this rule because it's not a SIN Act, it's just a SIN segment and therefore the firewall would drop it. So by adding further conditions, we can start to again achieve our goal of allowing just web browsing. But then we'd need conditions to allow the SIN to go out. The SIN Act to come back and then the Act to go out, maybe another rule for that and then special conditions for the data as well. It gets complex just to allow web browsing. Our firewall table of rules becomes harder and harder to create. Well, there's a simpler way around that in that people, essentially there's an extension that allows the first packet and then another part of the firewall keeps track of that connection. It keeps track of, okay, a connection has now been established or is in the process of being set up and established, allow any packet related to that connection only. That's what we want going back to, there we have it. Just look at the first rule, assume the second rule is no longer there. That allowed our SIN segment to go out but we had a problem that their SIN Act wouldn't come back. But what we do is we add another feature of the firewall that says if we allow a SIN to go out, record the addresses involved, record the source IP and source port, record the destination IP and destination port, store them in some table and any packets that come back which use those addresses, let's automatically allow them because they're all related to that one connection. Instead of having to create separate rules to allow the request and response, allow just the first packet and then add this extra feature of the firewall that will keep track of all related packets. The related packets are those which have the same five values of IP port, IP port and transport protocol TCP. Because of the way TCP creates connections, there will be subsequent packets all using those same values. And the concept is called stateful packet inspection. We go back to our lecture slides to discuss and then extend our example to see that. Normally a simple packet filtering firewall doesn't keep track of the past packets, it's stateless. But as we saw, things get complex if we want to create rules to allow simple applications like web browsing. Therefore to make it simpler, we use stateful packet inspection which really stores information about the past packets, especially the past packets which have been accepted. So if we allow that first SIN segment out, then the concept is allow all other packets which use those same pair of addresses, store information about the ones allowed and then make decisions based upon that. So store some state and then we get stateful packet inspection, SPI. It's really an extension of a very simple packet filtering firewall. It adds an extra feature. It requires some memory to store the state information, which can be an issue when there are thousands of connections happening at the same time through the firewall. Let's go back to our example and see how we could use that. Let's go back to the start. So come back to our first rule that we created. We want to allow computer one to browse to computer two. Nothing else. That's our aim. So we have our firewall table. Our default policy was drop and we'll come back to that first rule that we created. If the source is one, one, one, one, source port any value, if it comes from computer one, going to computer two, port 80, TCP, accept. And let's say we also use this feature of stateful packet inspection. The firewall is set up to use that. What that means is actually the firewall maintains another table of any connections that have been set up or established. So let's see if we can see what happens. Let's draw our SPI table, our stateful packet inspection table. Think of it, another table. It looks like similar to our firewall table, source, destination, protocol, and state, not action. So we have a second table stored in the firewall, initially empty. Now our web browser starts to contact the server. So what happens? We'll draw that exchange again. Computer one is trying to contact computer two. What does it do? It sends the TCP SIN segment. Again the source IP address and the browser chose some port number, 50,167. It changes. Sends the TCP SIN and the destination is computer two, port 80. So that's the first packet created. Is it accepted by our firewall? Now we have two tables to look at. So we see the packet information. We actually, when a packet comes in, one, the concept is think about you compare the packet to the stateful packet inspection table. If it matches any entry in here, we can accept it. There's no entries in here at the start. So let's ignore this table. Or we compare it against our original firewall rule. Doesn't match the rule? Does this packet match rule number one in our firewall? Yes, source port, source IP, OK, source port, OK, destination, OK, TCP, OK, therefore we accept it. So we're going to accept this packet. And what we do now is that the firewall, because it accepts this packet, it adds an entry to the SPI table. It records these values of the addresses in the table. Let's add them. The source, and it record the specific port number as well. And the destination, port 80, TCP. So we record the values of that packet that has been accepted out. So the intention that if we accept this SIN packet out, we should accept subsequent packets related to this connection. And how do we know a packet's related to this connection? Because of the addresses. There shouldn't be another application on computer one that uses the same port number. Because the computer assigns unique port numbers to each application. So on computer one, no one else is going to use 50,167. And similar, there's no other applications on computer two that use port 80, because it's the web server there. Actually what is the state here? I think the state is that the connection is being set up. We're in the state of setting up this connection. I want to write it down, because we're going to change it in a moment. But the state, let's say, setting up is the state, meaning the firewall knows that the SIN segment is being sent out. That was allowed. Computer two responds with a SIN act. And instead of looking at the firewall rule, look first at the SPI table. And even though we listed them as source and destination, the SPI table is used in that any packet that includes these four addresses and is using TCP, we will process and accept. So this packet is SIN act, source address is 2222, source port is 80. And therefore it's related to this connection. So this specifies a connection. Because even though this is the destination, that's the destination of the first packet, meaning we should allow to that destination and also allow back. So we should allow anything with this source, this destination, and also anything with this source and this destination, because we need to allow both way communications. So this packet, the addresses match what's already in the table. And the state would have said being set up. So the firewall would know if there's a SIN act coming back, let's accept it automatically. Let's not worry about the other rules. So accept this SIN act packet because of the SPI table, not because of the firewall rules. I'll just note that the SPI accept here. And the same concept that the next packet, actually the firewall accept, the SPI table processes at first, source, OK, destination, OK, protocol, TCP. It's related to setting up the connection, so we'll accept this one out as well. And at that point, the state will change from setting up the connection to established. And that's what we'll often see in firewall tables, in SPI tables. That this connection is established as the state of our connection. We've established through the three-way handshake and TCP. It would have went through an initial state of setting up. Now it's in the established state, which means any packet that comes to the firewall, which has these five values will be allowed, automatically allowed. That is IP import as either source or destination. IP import as either destination or source and using TCP. Because we have this entry in the SPI table, we'll automatically accept it. We don't check the firewall rules. So really the SPI table keeps track of the connections that we've allowed and allows any subsequent packet related to that connection. So the HTTP request will be allowed out because of this, the response allowed and the closing of the connection will be allowed because of the SPI table. Once the TCP connection is closed, the state will change to closed. And packets related to those using those same addresses will not be allowed. TCP goes through a connection, a state of opening established and then the applications close the connection. Once it's closed, then you think this entry will be deleted from the table. And any packet using these values will not be automatically allowed. We have to go back to the firewall rules. So that's the concept of stateful packet inspection. We now have two tables, a set of rules in our firewall and we think we create them to allow the initial packet. And then once that initial packet is allowed, the firewall automatically adds entries to the stateful packet inspection table which allows subsequent packets related to that connection. It greatly simplifies the setting up of the firewall. The creation of this SPI table is done by the firewall software. The creation of the rules is done by you. It's done by the administrator. So all you need to do is create this one rule. The firewall software will keep track of the connections for you. Questions on SPI. It's a little bit more complex but it relies on the fact that all internet applications, we can keep track of those connections, the communications using really these five values. The two IP addresses, the two port numbers and the protocol. No other application is going to use those same set of values. So they identify some application communications from a web browser to a web server. If you open your browser or open up another tab and contact the visit the same website, then most likely you'll get a different port number here, 50168. Or if you contact a different web server, then there'll be a different IP address here. Or if you contact the email server on the same computer, there'll be a different port number here. So those five values uniquely identify connections in the internet. Any questions on SPI? Sorry, how many resources are used here? Yeah, because you would use it at a different point. Correct. So the administrator sets up the firewall. In this case, our goal, allow web browsing to computer two. Maybe another rule, allow web browsing to computer three. Allow email to computer four. We'd add our rules. As those rules, as packets go through and accept packets, the firewall automatically adds entries here. So you can imagine with a large firewall with many rules, this and many people connecting, this can be quite large. Because the rule may not be allow computer one. It may be allow all computers internally to access computer two. So star as the IP address here, which mean computer one accesses, an entry will be added. Another computer internally accesses, an entry will be added. So this staple packet inspection table can grow quite rapidly. So that's the limitation. You need enough memory to store all of those values. So to store the addresses and the state. The entries are deleted either when the connection's established or after some timeout. If there are no packets, which are seen by the firewall that match these values after two minutes, delete the entry as an example. So we can clean up this table. Let's have a look at an example. This is an example of a firewall on a computer. We will not go through the format of this. Not in this course. Some of you may see it in the lab. So in our example, I drew the table using some general format, like star meaning any value. But different applications will use different syntax. So when you look at a real firewall, there are different implementations of this concept. Here's one of them. And without looking at all the details, you can notice some things. Think of these as the rules. Some action, except if the protocol is TCP. Some source address, meaning any value in this case. This special case meaning any source. Some destination and some other features like the destination port. So here are some rules, some example rules. Destination port 80 for web serving, 25 for email, 22 for secure shell. So some rules have been added to this firewall table. And this firewall table has been set up to use stateful packet inspection. And the specific way this software did it was using this rule here, saying anything to this network record the established connections, which tells the firewall in another table, record this SPI information. So whenever a packet matches, say, this rule here, destined port 80 to this IP address, then this firewall will add the entry into the SPI table. Let's have a look at the SPI table. It's hard to see because it's quite large, but we'll try. Essentially, the firewall tracks connections. So there's this file connection track. Hard to see, but let's zoom in on one. There are many entries here. Just focus on one line here. This is one connection that's been tracked. There are many. And it's keeping track of TCP. The connection state is established. The source address was this IP. The destination was this IP. The source port was 80. The destination port was 53968. There's other information, but not relevant at this point. So this is the SPI table. It's keeping track of who has recently communicated through the firewall. Any packet that matches these combinations of addresses and port numbers will be automatically allowed through this firewall. It's in the established state. Keeps other statistics of how many time this has been used and something about a time as to when to stop using it. And there are many rules, many entries in this table. So this will be updated over time. In a rather small firewall, there are probably hundreds of entries. So a firewall needs the administrator to create the rules. And then the firewall automatically keeps track of connections. And that's common in most firewalls today. Without it, it would be very hard to set up a useful firewall. Our diagram here, I think, just captures the fact that a stateful packet inspection, we store some extra state information about the connections. We've covered this, that we keep track of the connection state, maybe other things like sequence numbers in the TCP connection. It's very useful for TCP connections, but also used for UDP. It's a bit harder in that case. Packets arriving that belong to an existing connection can be automatically accepted without looking at the firewall rules, what's remaining. So we said that there were four types of firewalls. Packet filtering, we've gone through. Stateful packet inspection just extends upon that. And let's look at two other types, application and circuit level proxies. Just briefly look at these. Our packet filtering firewall, packets pass through it, whether they're accepted or dropped, they just don't go through. In the simplest form, it doesn't worry too much about what the content is. It just looks at the IP and transport layer headers. An application proxy or an application level gateway acts as some form of relay. So this diagram tries to capture it. Here's our internal network on the left, external on the right, so computers over there. The idea is that our application on our internal computer, when it wants to access an external application, say web browser to external web server, it actually contacts and connects to the application proxy, which is really running a web server here or a cut down web server. And that proxy is running both a web server for our internal application to contact and the proxy is also running a simplified browser or web client that then contacts the real server. So the proxy is doing the communications on behalf of the two nodes that are intending to communicate. The packet filtering firewall, even with SPI, doesn't deal with the application and it just has to filter packets based upon the headers. An application proxy actually has to implement part of the application server and client. So if it's a web proxy, it implements a simple or possibly a cut down web server and a web client. Now not a graphical browser, but an application that can send requests. So it is not a browser here, even though we say it's a web client, it's just some piece of software that can send a get request out. So it acts as a go between the client and the source. Now for this to work, the proxy must implement those applications or has to have code for them. So it's usually only for specific applications, say for web browsing. So we have a web application proxy. We cannot have a proxy for all possible applications. There's too much effort to create. And it may restrict some features of those applications. So if it's a proxy for a web browser, to keep the proxy simple, it may not implement all features of a normal web server. But it allows very fine grain control over that application. So what can happen is that I open my browser internally. I try to contact some external website. My request goes to the proxy. The proxy can then look at the request, not just looking at the IP headers and the TCP headers, but looking at the HTTP request, all the fields in the request, what the URL was for the request, and make some decision whether to allow that or not, or even modify the request. So it can look at the application-level information. And if it allows it, then essentially creates a request to the real server on the behalf of the internal client. And the response comes back. So we can do more inspection of the content using a proxy. But there's more overhead of processing. We need some software to do that. And it takes time. Imagine the SIT application proxy, web proxy. Every time a student accesses a website, the request doesn't go direct to that website. The request goes to the proxy, which does some processing on that request, and then goes out. So add some delay to the request, and say a delay to the response. Because the response that comes back is processed by the proxy. Maybe one thing is that the proxy could filter out some content. So not just looking at the headers. Similar is what's called a circuit-level proxy. Same concept. We have this intermediate proxy between internal and external. But it deals at the transport level. So what happens is, say, my web browser creates a TCP connection to the proxy. And the proxy creates a separate TCP connection to the real web server. So similar features to the application-level proxy, but it's doing it at the transport layer as opposed to the application layer. And it can monitor the connections. So again, it's just looking at the transport information and can determine, do you allow a connection to go out or not. Not so common, or we don't see so many, but still used. One way is that internal user's traffic that goes out, which is generally trusted, allow everyone to access out, goes through this proxy. But allowing to come in, which we want to control much more, we may want to inspect the data that comes in, we may use application-level proxy, which may have more overhead, but can provide more security. So in some practical networks, they'll combine them in different directions. So just to understand the idea of a proxy in general, some intermediate device that works or that behaves on behalf or operates on behalf of the two users that want to communicate. Now a proxy, a web proxy implements a web server and a web client and allows us to communicate between internal, external, or other way and communicates on behalf of the intended source and destination, allowing the proxy to do some processing and to check whether the content should be allowed. However, both of these proxy approaches not necessarily transparent to the users. That is, the user's data may be changed by the proxy. I make a request to Facebook, the proxy filters out some of that request. Or the response that comes back, the web page that comes back, the proxy changes it. You may have seen that some ISPs maybe have done that you request a web page. The web page comes back, but they modify the content before it gets to your browser. Maybe they insert an ad in there, an ad for their ISP. So it's not coming from the original web server. It's coming from the proxy. So it's not transparent to the users. Something's changed in the content. To finish, questions? Yes, we said with SPI, the firewall automatically creates this list of connections. So we need memory on the firewall to store this list of connections. Now, imagine a rule again that is not per device but allows all devices in the network contacting out. So there may be many connections, thousands, tens of thousands of connections happening to be stored. Therefore, if the amount of memory allocated for the firewall is small, and we fill up that memory, then subsequent connections will not be allowed out. So if we could, as an attacker, fill up this table, use up all the memory, then any other connections would not be allowed through the firewall, providing some form of denial of service attack. How do you overcome that? Well, make sure you have enough memory for the typical number of connections that you need in the network. Where do we put a firewall? Last two slides, I think. Well, either on the end-user computer or in a network device. End-user computer is not very convenient. So if I put a firewall on all computers inside SIT, it would protect those computers. But I have to, as the administrator of the network, I must set up that firewall, make sure it's installed and up-to-date and configured correctly. So rather than putting firewalls on the end computers, put just one firewall on a device that all of the data goes through for those computers. And that's more practical, so on network devices. Firewalls are located on network devices, devices that connect internal and external networks. We may arrange them in different ways. And these diagrams try to capture some examples. So here's our external network in the top diagram, an internal LAN with all the office computers. But we have maybe some servers, a web server, an email server, a database server, which are supposed to be accessible from people outside. This green box is our firewall. So this red box is a router that connects us to the rest of the world. So traffic comes in to the red one and reaches the firewall. And the firewall should have rules that control who can access our web server, our email server, and our other servers here. Who can access them? So if it's a public web server for SIT, essentially everyone should be able to access the SIT web server, although we may create restrictions and block some people. So the firewall would be configured to allow people to access these publicly accessible servers, but nothing should be able to come into the internal internet, the internal intranet is called here, the internal network. There should be no reason for someone outside to try and contact a web server running on my computer in the office. Because that web server should not be publicly accessible. The organization, if there's any web servers available to the public, put them in this other special area. And this area will call the demilitarized zone, DMZ. It's the zone of the network that we sort of keep separate from the special internal and the external. So the firewall would need to be configured to allow some people to access the servers in this zone. And it can be configured to block all access coming out towards the internet. But of course, allow those inside to access out to the public websites. Another arrangement is to use two firewalls, these two green blocks in the bottom diagram. Similar setup, why use two firewalls? What can we gain there? It can add more security, especially in the case that some attacks take place or there's some misconfiguration. What we can do in this case, we have a physical separation of our network. So this first firewall can be configured that all traffic originating from outside must go into the DMZ. So it redirects everything that comes from outside into here. It will not let it go here because there should be no need for outside traffic, say people on web browsers outside, to access anything internal. Of course, we need to allow some traffic to go out and the responses. So these firewalls would be configured to allow connections to be established from internal out and the responses to come back. If there's a misconfiguration, we essentially have two lines of defense here. Or if something goes wrong on one of them, then we still have a backup protection here. That is, it's very easy to configure this first firewall. Everything that comes in goes into here. And it's very hard to make a mistake with setting up the rules in that case. Whereas this firewall may have hundreds or thousands of rules in there to allow specific applications out or specific computers out and also into this network. So this one can be very complex. Therefore, to avoid security compromises due to errors, make this simplify wall just redirect everything to here. Nothing can come in there. And therefore, even if we make a mistake on this one, still nothing will get in. So it's a way to add this extra line of defense that if something goes wrong, we're still protected in most cases. Whereas in this one, one firewall, if we make a mistake in the configuration, then it may allow traffic into our internal network. If we make a mistake on the configuration in one firewall here, then the second one should block it. Now if we make a mistake on both, we're in trouble. But the idea is that the configuration of the first one is so simple that if you make a mistake, you should get fired. So it's about managing the complexity of setting it up. In theory, you could keep adding firewalls. The more you add, the more protection you have. OK? Yep? Can I add a public picture? Thought I had a picture. Yeah, you could have a second zone if you wanted to say have a honeypot that was separate from here. We mentioned honeypots in the previous intrusion detection topic. We could have a separate zone, maybe. But normally, honeypots need to look like real servers and therefore direct it to the same. Of course, every firewall we add, we need more equipment. We need more setup. And we have more processing overhead of our packets. So there's some performance disadvantage of having multiple firewalls and a cost. But maybe more secure. I think that one's just an extension of the second diagram there. Control traffic in and out of our network, our firewalls, or a computer. But we will focus mainly on organizations for networks. We control based upon the servers, port numbers, which direction the traffic's going in, which users. We can identify users by IP addresses. But there are also other ways to identify users. And the behavior, for example, looking at the content of the data. And we've gone through some detailed examples for packet filtering, where we accept or reject packets based upon the headers of those packets. And we can extend that with stateful packet inspection, which keeps track of pass connections. And we've mentioned briefly that we can have proxies as an even better measure, a level of security by essentially running the application separately, server and client, but more costly. The main thing, setting up firewalls, is hard because it involves a human writing these rules. And if you've got hundreds of rules to write, if you make a mistake, you may allow traffic into the network that should not be. So that's a problem. Managing the complexity is a problem. People can bypass firewalls. So the firewall may allow secure shell. And in one of our later topics, we'll see that we can use this to create what's called a tunnel, that we send our normal traffic via this secure shell connection. So the firewall is set up, say, to allow web browsing and secure shell. It doesn't allow email, for example. Therefore, to bypass this rule that blocks email would be to create a secure shell tunnel through the firewall and send our email via this secure shell connection. There are ways to bypass tunnels, bypass firewalls using tunnels. And other ways is to use other network connections that don't direct the traffic through the firewall. That ends this topic. What's next? Next, we'll move on to aspects of web security.