 Given this network and we have a firewall on router RA, we want to stop computer 12 from accessing the web servers on network 3330. So we want to write a firewall rule on router RA that will prevent that. What do we do? What's the answer? Find the answer now. Try and write the rule looking at those five criteria of the addresses and the protocol number. So the IP and port number addresses, block computer 12 from accessing web servers on network 3. And we're always assuming at this stage, we'll change it shortly, the default policy of the firewall is to accept, which usually means we need to write rules to drop something. So except everything creates some rules to drop the things that we want to drop and stop computer 12 from accessing the web service. So the source IP, destination IP, protocol and the port numbers we need to consider. And we'll take some action. What should the source IP be? Right, we're trying to stop computer 12 from accessing the web service. So the source IP should be that of computer 12, so that we don't stop computer 11, for example. Destination IP, we want to stop computer 12 from accessing the web service on network 3. Right, we can use a network address there. Usually the firewall will allow different structures of the address. So for example, I'll write 3.3.3.0 and to be precise, slash 24, meeting any IP address that starts with 3.3.3 in this case. The subnet mask of slash 24 indicates that those first three numbers must match. Protocol, web browsing uses TCP. So let's do a number 6, source port. What should the source port be? Don't care, any value. That is, my web browser today may be use one port number, but tomorrow use a different port number. So when we set up the firewall, we don't have to specify the exact port number of the web browser because it changes. We cannot add all of them. So any value in this case, destination port. The web servers should be listening on port 80. Action, so we set a number of conditions. The source addresses, the protocol number are the conditions. And if those conditions match for a packet that comes to the firewall, we take some action. So it's not so hard to write the rules for different examples of security policies. So consider our aim, write the rules that we've tried to implement that aim. Any questions so far on firewall rules? The syntax we're using is just a general syntax to simplify how to specify the addresses. Particular firewall software or devices may have their own syntax. There may not be a star, it may be some other character or some other representation. It depends upon the software that you're using. Until now we've considered the default policy of accept. Now let's consider some examples where the default policy is drop, which is the recommended policy. If anyone needs some more pictures, there are a few here but I think we only have one or two networks remaining or examples. Let's try a different case. Let's say the default policy is to drop all packets at our router. And our internal network, we have a web server on computer 12 that we want to allow people outside to access. So this is my internal network, I have a public web server here. So I've set up my website on computer 12 and everyone outside should be able to access that website. But they shouldn't be able to access any other computers internal on this network one. In particular computer 11, people outside shouldn't be able to access that. And to keep things simple, let's say that no one inside needs to access services outside. So the purpose of this network with respect to communications with the external entities is that those outside can access the website on computer 12. Try to create a rule that will do that. People outside can access the website, nothing else can happen. And while you're thinking of that, I'll change the way that I write the rules because I run out of space. I'll just think of the rules as a table. That is, if we go back to our previous examples, if I can find them, this was one example that we did. We allowed secure shell. We can think there are a number of columns in each rule. There's a source IP, destination IP, protocol, source port, destination port. So five different values there and then action. That was one rule. That was to allow, actually that was to block secure shell. And then we had another rule we just created to allow web browsing, to drop access to the web service on computer network 3. So our firewall table will have multiple rules. We have two examples here and we can think the firewall table or the firewall maintains the rules in a table form. That's one way to think of it as a data structure. So every rule is a row in the table which specifies a set of conditions like the addresses, the protocol number, the ports and an action. And we build up our rules depending upon the things that we want to implement. So so far we have two rules in our table and we think there are two rows in the table. And when a packet comes into the firewall it checks that packet against all the rules in the table. And if none of those rules match it takes the default action. So in the next example I'll write it instead of just as a line like this as a table, almost the same. So returning to the goal of default policy as drop, we want to allow people outside to access the web server on computer 12. Try to write the rule to do that. Think of it as a table which we have the source and destination, both IP address and port, source and the protocol number and the action that we take. What can we do to allow people to access the website? Computer 12. Computer 12 is running a web server. Let's allow people outside to access that web server but nothing else internally. What should the source be? What should our source address be in this case? Anyone. So we're thinking about allowing anyone outside to access the web server on computer 12. So the source can be from anyone. So star for the source, source IP, source port number. Again a web browser who's the client that is the initial source may use any port number. Not any but we do not know the specific port number. So the source will be any. Destination should be the computer 12. So let's write that and I'll write it in a slightly condensed form. The source is the IP address and I'll write both the IP and port number together. The IP address, the colon character and then the port number. And for the destination the IP address is 11112 and the port number. Destination port should be web server listens on port 80. Just slightly different notation when I specify the IP address and the port number together. Web browsing uses what transport protocol? TCP number six. We could write TCP or six. Usually the firewall will allow you to specify say TCP and then automatically map to number six. And what action should we take if those conditions match? Here we're using a default policy of drop so the action here should be accept. I'll just note down here for the firewall the default action we've set to be drop. So this is the opposite. Drop everything except what we specify in the rules. Any questions on this rule? Does it work? No, it doesn't work. Find out what's wrong with it. It is that rule works but I think our aim of allowing our external users to access the website is not going to work. Let's see what happens when someone tries to access that website. Let's say, and I'll just make some space. Let's give a specific case where computer 35, for example, wants to access the website. So this will be the source and the source IP will be 3.3.3.35 and the source port will be what? Whatever the operating system gives to the web browser. So let's give it a number. Let's say the source port, just choose a random port number that's given to the browser when the browser tries to connect to the web server. It's given by the operating system on that computer. So the source IP is 3.3.3.35, source port 50123, protocols number 6. It's using TCP. What happens is it sends a packet, destination address. It's trying to contact the web server, computer 12, destination 11112, destination port is 80. We're using web browsing. The packet gets to the firewall router RA and we check that packet against the conditions. Source, anything, okay, this matches. Source port, anything, okay, 50123 matches. Destination address, 11112, yes, it was to there, that matches. Destination port, 80 matches. Protocol matches, so yes, it matches. And we accept the packet through router RA. The packet goes on to computer 12. What happens next? Web web browsing, we've sent a request to the web server for a web page. What happens next with web browsing? The web server needs to send back the web page. Web browsing involves sending a request for a web page and the server sending back a reply. What happens with the reply? Source is computer 12. Source port is 80. Destination is computer 33335. Destination port is 50123. That packet, the response packet gets to the firewall. The firewall checks the rules and it will not match that rule because the destination of this packet is 35. So it doesn't match the first rule, so it takes the default action of dropping that packet. So we have the problem that we haven't considered the response. And most protocols, most applications we use have a request and a response. So we allowed the request in but haven't allowed the response back. How do we fix that? Add a new rule, add a second rule to accept the response. Try. So add a second rule in this case. When we use the default policy of accept, it worked okay because we just dropped the first packet and that blocks the application. But now we have a default policy of drop, we need to accept the packets in both directions. The request coming in and the response coming out. So we need two rules in this case. So when you, the administrator set up the firewall, you would add the second rule. The response coming from computer 12, the web server to someone outside, the source. What's the source address? The web server. Good. And port 80. This is the response. So the web server, when it sends a packet, the source port is 80. It's coming from the web server. Destination. What's the destination in this rule? It's not 3.3.3.35. In this instance, yes, we would need the destination to be that. But what if the next time computer 36 wants to access our website, then we would need a specific rule for that one. And what if computer 2 on the network 2 does it? So it needs to be any in the destination. Note that when we set up these rules, it's like when we build the network and turn on the firewall, we add these rules and they should be static. That is, we shouldn't have to change them every second. We usually set them up and maybe for days or weeks they remain the same. This setting the rules is the job of a administrator. So the destination should be really the same as the source of the first rule because it may come from computer 35 and we may need to send back to computer 35 with port 50123 or we may need to send back to computer 36 with a different port number. So we need to allow any value. It's still using TCP and we should accept that. Now we should accept packets in both directions. The request that comes in and the response that comes back. The goal was to allow external people to access the website on computer 12. They won't be able to access anything on computer 11 because if someone sends in destination computer 11, it's not going to match the first rule. What about the second rule? Will it match? Computer 35 sends to computer 11. It doesn't match the first rule because the destination is computer 12. Does it match the second rule? No, because it's coming from source computer 35. It's not computer 12. So therefore the default action if you send to computer 11 will be to drop. So that's our intention that no one can contact computer 11. So that works. But maybe there's a problem. Anyone see a problem with this? What if we have a malicious user outside? Computer 36 is trying to access computer 11 or send a packet to computer 11. Our policy is that they shouldn't be able to. What if we set a fake source address? Computer 36 changes its source address. So when it sends a packet, it sets a fake source address. Can we bypass the firewall? That is, can we get our packet accepted? Remember when a computer sends a packet, the computer generates that packet and sets the values in the IP header and the TCP header. So in theory, the computer can set the values to whatever they like. The normal behavior is it's set to your IP address and the port number given to you. But as we saw with the denial of service attacks, setting fake source addresses is actually quite easy. Your homework task involves doing that. So it's possible for a computer with the IP address 3.3.3.36 to send a packet with a different source address than the one it actually has. So how could computer 36 defeat our security policy? Any suggestions? What about if we do use a fake source address on computer 36 and we set the source to be, I can squeeze it in here, 1.1.1.12. So it sends a packet, but before it sends that packet, it sets the source address to this 1.1.1.12 and the source port set to what? So the malicious user on computer 36 creates their own special application with the intent of getting a packet to computer 11. If they can, then we've defeated our goal of the firewall. We said the firewall should be set up so that no one can contact computer 11. Again, the same as that you can set a fake source address, the computer has control of the port numbers that it uses. Normally, you create an application and the operating system will assign a port number within a range to that. You have no control, but in game it's possible, it's very easy, to specify a selected port number. So computer 36 can run an application and set the source port to anything they like. What would they set it to? Your computer 36, you want to get a packet to computer 11? What would you set the source port to? Not any. Yes, it will be a value. What specific value should you set it to to get through the firewall? 80. Let's try. So we create a packet. Normally, 80 is reserved for web servers. But again, it's our computer we can use whatever port we like. So the default is for web servers, but the person who sends the packet can set the value to whatever they like. So we set the source address to 11112, the source port to 80. Destination, let's send to computer 11 using TCP. Destination port, whatever. Whatever I choose. We send the packet. It gets to the firewall. So the firewall sees the packet. Source address is 11112. Source port is 80. It matches this condition on the second rule. It also matches this one. The destination address is 11111. It doesn't match the first rule, but it does match the second rule. Destination can be anything. Well, 11111, is it any value? Destination port, whatever we chose from the malicious user, it could have been any port number that we wanted. It will match. The protocol we're using is TCP. So this protocol number six matches. So the firewall accepts that packet in. The packet comes in and is sent to computer 11. It defeated our intention of the firewalls to block people from contacting computer 11. So we need to be careful with the rules. But it's not so obvious in some... Well, it's not so easy to implement what sounds like a simple aim. Blocking people from accessing computer 11. Any questions on this limitation of our firewall so far? We created two rules to first allow the requests to come in to computer 12, port 80, and then allow computer 12 to port 80 to reply to send the response out. But that rule we created, the second one left a hole in our firewall such that if someone used a fake source address, they could still get through the firewall, which we don't want to happen. How could we fix that? We can fix it in the firewall or have the router do something special. What are some suggestions to stopping this malicious node from contacting computer 11? Assuming we can't stop computer 36 from setting a fake source address. They can do what they like. What could we do? Set another rule. What other conditions could we do? So far we've looked at just the addresses, the source and destination IP and port and the protocol number. But in fact, another thing that we can look at, if we look at the slides that maybe IP addresses, port numbers, protocol numbers, the direction or the interface can be used. That is, our firewall, which is running on a router, has two interfaces in our example. The one connected to the internal network and the one connected to the external network. So we can use that information as well in our conditions. We can specify rules that apply to specific interfaces. And we can use that to really implement direction. If it's packets coming from one direction do one thing, if it's coming from a different direction do something else. So we could do that. And I don't know if I can fit it in, but I can say what we wanted is if the packet was going out from computer 12, allow it. But if it's coming in from computer 12, don't allow it. So we could add another condition here. Where will I squeeze it in? Maybe here. INT for interface. Router, I think we have two interfaces. The internal and the external are the one that goes out or from outside. Actually, maybe we should rename them just external. The router has an interface for an internal and an external interface. For example, on a Linux operating system it could be ETH0 and ETH1. So in our firewall rule, if the first packet arrives on the external interface going to the web server, accept it. If the second packet arrives on the internal interface, coming from the web server, accept it. If the packet is coming and arrives on the external interface, it's coming from outside, coming in, then the second rule will no longer match and that packet will be dropped. So by specifying something about the direction we can overcome this problem of this fake address being used. Because what we wanted, allow the response from 11112 to come out, but don't allow someone using a fake address of 11112 to come in. And we can make use of the interface conditions to check the direction of that packet. So sometimes it's specified by the interface or more generally the direction. If it's going out, allow it. If it's coming in, don't allow it. So even to do a simple thing like allow someone to access my website, we need two rules and we need to be careful about the interface as the directions as well. In means just, maybe I should have used a different label, it means that the name of this interface, the internal interface, in for internal. I didn't want to use int for interface. So maybe a better name would be eth0. It depends upon the operating system. So if you're using Linux, eth0, maybe the name of the interface and this may be eth1. You can specify the specific interface name there. Or you can think of it more generally as going out versus coming in. So that should achieve our aim. People can access our website on computer 12, but they cannot contact computer 11. Now, let's say I want to allow some other things to happen. I want to allow not just contacting the website or the web server on port 80, most websites support HTTBS. And we'll cover that in a later topic, but HTTBS is similar to HTTP, but one thing that differs is that a web server that supports HTTBS uses port 443. It uses a different port number on the server. So if we wanted to allow both normal HTTP and the secure version, HTTBS, we'd need another two rules specifically for port 443. And for every other service that we need to allow people to access, say a secure shell server on a particular computer internally, an email server, we'd need at least two rules to support the request coming in and the response coming out. And it can get quite complicated. That is the rules that you need to enter into the table can, of course, become quite long. And it's easy to make a mistake. And if we make a mistake, like not specifying the interface, it opens up a hole in our security. So some extensions of normal packet filtering firewalls is what we call stateful packet inspection, which tries to make it a little bit easier for us to specify the rules to capture this behavior of allowing someone to contact the server and allowing the response to come back. So in this case we added a second rule to allow the response to come back. And basically for every application we'd need to have two rules, one to allow the request in and one for the response back. But that gets tiresome to do that for every application. So what stateful packet inspection tries to achieve is to make that automatic. We create one rule to allow the packet to come in and then the firewall has some special features that will, if a packet comes in, it will allow the packet to go out automatically and any subsequent packets to be passed through. So we'll explain that concept next. Sorry. Right. In this case, we created both rules, one to let the packet in and the corresponding one to let the response out. What stateful packet inspection will allow us to do is we create one rule to let the packet in then the firewall automatically allows all subsequent packets related to that packet that came in to go through the firewall. So basically we will just have to create the one rule and the firewall will automatically handle the subsequent rule, the next rule. And that can be achieved mainly because of the fact that most applications use a request-response type communications and in particular use TCP. And in TCP, before we exchange data, we set up a connection. So let's just have a look at TCP behavior to see how we can use that. What can we draw? So we've talked generally about packet filtering firewalls. We'll come back to some examples later and the advantages and disadvantages. Now we're going to talk about stateful packet inspection, SPI for short, and explain how that works. And we'll do it via examples. First, how does TCP work? TCP, I know some of you are studying it in a course right now. Does anyone, or maybe you haven't got to the point of how to establish a connection. TCP as a transport protocol is a connection-oriented protocol. You establish a connection up front with a three-way handshake and then you exchange data. So let's just briefly draw that. The idea is that we have some client and some server and what happens in terms of the exchange of messages between client and server over time, the client initiates communications. So the client is the one that sends the first message. And they send a message to the server with TCP. Those that are studying TCP, no need to draw this, you'll be experts on this from your other courses. So this is just the basic concepts of TCP. The details are not so important, it's just to set up how SPI works. With TCP, before we send any data between client and server, we establish a connection. We agree upon some initial values that we're going to use and really inform the other side. Let's transfer some data. And the normal way to establish a connection is the client sends a special packet to the server. It's called a synchronized packet. We abbreviate that to SIN. SIN for synchronized. It's about synchronizing some sequence numbers, but that doesn't really matter with respect to the firewall. We just call it a SIN packet. The server realizes, okay, the client's about to set up a connection with me. So the server we can think was in some state. It was initially, let's say, doing nothing, it was maybe idle. So think of the server goes through a set of states with respect to TCP. It's initially idle, doing nothing, just waiting for someone to connect. Then when they send a SIN segment, we say it's in some state. Let's say the SIN received. I'll just give it a name. That is, we're in the state of the server that we've just received a SIN, a synchronized message. And that tells us that let's allocate some memory for this upcoming data transfer. And let's send back, in the TCP 3-ray handshake, send back a acknowledgement. What's the name of the acknowledgement? It's actually an ACK saying thank you for the SIN and it's also a SIN saying I want to synchronize my values. So we call it a SIN ACK. When the client receives that, the client should send back one last message to establish this connection. What's it called? A final ACK. This is saying thank you for your SIN message. So it happens in both directions. SIN ACK, SIN ACK. It's just that the middle message combines the synchronize and the ACK into one. And from the service perspective it's received the first SIN message and now it's waiting for the ACK. When it receives that ACK what can we say about the connection? Is it set up? Yes, this is the step to set up the connection. So we say once we receive the ACK everything's okay and we say the connection is established. The idea of this was to set up or establish a connection. The server initially is idle. When it receives a SIN it goes into a special state of the SIN is received I'm now waiting for an ACK and once it gets that ACK everything's ready to transfer data so we say the connection is established. And then the client and server can start sending data. So in either direction usually from the client to the server for example with HTTP if this is our web browser and this is our web server they establish a connection first and then send the data as a HTTP request and eventually get a HTTP response. There may be an ACK in there as well, a TCP ACK. But the point is that the server goes through some states idle, nothing's happening receive a SIN and then eventually when we receive that ACK we can say our connection is established and once the connection is established we expect to get data messages we expect to receive and send and in fact eventually there's a to close the connection there's some special messages to say stop and it's called a FIN message connection. We'll not draw that. We can take advantage of this in our firewall to say that if we accept a client trying to connect to our server if we have a rule that says this client can contact our server because we want them to access our server we'll write one rule to allow them to accept the first packet and the second packet automatically maintains information such that all subsequent packets of setting up the connection and then once the connection is established of the data packets they're all automatically accepted we don't need rules to accept those subsequent packets that makes it easier for the firewall administrator they only need to create one rule not rules for the responses and the firewall now is create a rule to allow the SIN packet we specify who the source is the destination the same as we created our previous rules once that SIN packet is received the firewall will automatically keep track okay I've received a SIN packet if I next receive an act packet from the same client with the appropriate sequence numbers then I'll automatically allow that through the firewall and if I'm in the established state anyone who is sending a data packet to me or going out through the firewall it will automatically accept those packets let's see how that works in in our example network any questions on first the TCP connection establishment procedure you don't really need to know why it's SIN SINAC act not in this course but just be aware that it's these three messages to establish a connection and then data can flow in either direction so stateful packet inspection let's try and create a firewall rule that will handle our previous case of allowing everyone outside to access our web server on computer 12 we'll do that again find my network same as before anyone outside should be able to access the web server on computer 12 so we can think with respect to the firewall when we're using stateful packet inspection we have two sets of data the firewall rules and something that keeps track of the connections let's create the firewall rule first we'll draw it again there's a few more left over sheets so grab one the last one's there you should only I think this will be the last example in half if there's not enough tear it in half same as before we have a firewall rule source, destination protocol action I will not list the interface we should have the interface here as well but we will not need that in this case we could have it to be precise actually we'll have space so let's include it interface I'll call the interface IF instead of INT and we'll talk about again what do we call this is the external interface and this is the internal interface INT not the input the internal so our firewall rule will create a rule that allows the request to come in or allows specifically the sin message to come in source we said was anyone from any port and the destination was computer 12 port 80 our web server coming from the external interface that is coming in protocol 6 so this is the same as before we should accept still as before our default policy is drop so we create that initial rule we want to allow people from outside to contact our web server the interface that this packet arrives on should be the external interface it gets the firewall from this interface we'll accept it if for some reason it came from the internal interface this rule would not match now with a stateful packet inspection enabled we don't need to add the second rule SPI we handles the second case automatically and the way that it works is we can think there's a second table SPI for stateful packet inspection has its own table not of rules but of recently accepted connections and we can say that inside that table there'll be a source a destination protocol number and a state so this is a second table of information called the SPI table there are two different tables in the firewall now one is a table of rules that we created and the second is a table of connections that is going to be automatically maintained by the firewall the administrator doesn't have to update the second table to create rules in the first table and the way that the second SPI table is updated is that when a SIN packet is accepted so again computer 35 sends a packet to computer 12 let's see what happens the example we're considering is computer 35 let's say has a source port of 50123 and that's going to contact the web server or attempt to contact the web server it should be allowed source port 50123 source address is that of computer 35 it creates a packet and sends it to computer 12 web server port 80 so the packet will come to the router RA on the external interface the firewall will check that packet source address matches any value matches destination it's going to computer 12 port 80 matches it's coming from the external interface that matches it's TCP it's protocol number 6 that matches so the firewall rule says accept this packet this is the SIN packet in our connection setup remember the first packet of TCP is this SIN packet coming in so what happens now is that we add a row to the or add an entry to the SPI table that keeps track of those recent connections let's say the source was specifically 33 3 35 port number 50123 destination was 11112 port 80 protocol is 6 and we store also the state of our TCP connection at the server or the expected state and remember after receiving the SIN the first SIN packet we said the state is SIN received so the state here initially is SIN received this is the this is let's come back to that TCP handshake diagram and maybe we'll add a new one to be clear so the state of the TCP connection at the start it's idle then we receive a SIN so we say the state is SIN received from the client's perspective after receiving the SIN act let's call it SIN act received SIN act looking from the perspective of the TCP connection it goes through some states first it's idle there's no connection no attempt to establish the SIN goes through and we move into the state the SIN has been received by the server when the server sends back the SIN act eventually that SIN act has been received and when finally the act comes back the connection is established so in our firewall when that first packet goes through the firewall the firewall adds data to the SPI table saying ok I've just received the first packet the rule said accept it so I accepted that first packet and let's record who sent it in our example it was 33336 port 502 50123 and who they sent it to our computer 12 port 80 and let's say that the state is now SIN received now the next packet that the firewall sees should be a SIN act so let's go back to our firewall so currently we're in the state SIN is received with respect to this connection the SIN was received so we have an entry to our SPI table saying a SIN has been received for these pairs of computers what happens next in terms of packets being sent computer 12 sends the SIN act the next packet the SIN act coming from computer 12 it gets to the firewall does the rule accept it well in fact with SPI we don't check the rules first we check the SPI table that is when the packet comes in to the firewall source is computer 12 destination computer 35 this is a SIN act packet what the firewall does now is it checks its entries in the SPI table and it knows that there should be a SIN act between computer 12 and computer 35 because I just recorded a moment ago a SIN packet and that information is stored in this entry any questions so far this is getting more complex but it's a key part how firewalls work today so again the SIN act is coming from computer 12 going to computer 35 it gets to the firewall the firewall doesn't check the rules it first checks what's in its SPI table and it sees that I previously saw a message between 35 and 12 which was a SIN message and I recorded that by saying the state was SIN received so I expect computer 12 to be sending to computer 35 a SIN act and I should accept that because it's part of the connection establishment procedure so this entry in the SPI table tells the firewall to automatically accept the SIN act to come back be careful here with the source and destination let's list who the source and destination are of this SIN act packet we run out of space squeeze it in at the top the SIN act packet the one that was sent by computer 12 port 80 sent to computer 35 port 50123 so that the address information it's also TCP so the source is 12 port 80 the destination is computer 35 port 50123 this is the SIN act packet accepted when the firewall receives that this entry in the SPI table says accept it because that's the normal behavior with TCP if we have received a SIN packet from these pair of computers then when we receive a SIN act in the opposite direction we should accept it because we need that to set up the connection but be careful that the SPI table this is the original source of the SIN packet 333 35 and the destination of the SIN packet the SIN act the addresses have swapped it's the one coming back it still matches this row with the SPI table we just look at the pairs of addresses the type of packet determines the ordering expected questions before we finish this part I don't know this is the information the firewall stores you can think the firewall has seen a SIN being passed through it the very first message accepted by this rule was the SIN packet and when I say the state SIN received it's not really it's been received by the firewall and sent on to the server so from the firewall's perspective after that SIN packet passes through it thinks okay I've received a SIN so the next thing expected from the firewall is I should receive a SIN act in the opposite direction I received a SIN coming from 35 to 12 therefore if the next packet is a SIN act from computer 12 to computer 35 then I will automatically accept it right because the way of TCP is the thing expected after the SIN received should be a SIN act in the opposite direction and the packet the SIN act is from 12 to 35 the port numbers match therefore the firewall automatically accepts the SIN act coming back when the SIN act passes through the firewall the firewall changes the state changes the state to what to SIN act received in TCP the SIN is the first message coming from client to server and the SIN act is the first reply yes coming from server back to client so this state will change I'll just cross it out it will become SIN act received because that SIN act has now passed through the firewall it automatically accepted the firewall doesn't check these conditions if there's a match in the SPI table the SIN act comes out to computer 35 what happens next remember TCP 3-way handshake SIN SIN act AC so the next packet computer 35 will send an act to computer 12 and the details of that AC it's from computer 35 port 50123 in the connection we use the same port numbers for each packet going to computer 12 port 80 and this packet arrives at the firewall and the firewall checks okay I previously saw a SIN act going from 12 to 35 now I see an AC going from 35 to 12 let's accept it because that is expected because we expect to see SIN SIN act AC so this entry tells the firewall to automatically accept the AC message what happens next when the AC is accepted what state are we in established so this state is changed to established when the AC passes through the firewall the AC will be received by the server actually established here and in the established state any data packet that goes in either direction is accepted if for example there's data packets from computer 12 to and you don't need to write this one should be obvious we'll see if there's data from computer 12 with port 80 to computer 35 with port 50123 this SPI entry says automatically accept that no need to check the firewall rules because we know that there's a connection established between those two computers any data now should be automatically accepted and similar in the opposite direction if it's going from 35 to 12 if the packet sees a data packet in this direction then again this entry in the SPI table says automatically accepted once the connection is recorded as established data packets going in either direction are accepted by the firewall without checking the rules and this is done automatically that is the firewall has some software that once the administrator has added this rule and has set up SPI stateful packet inspection the firewall automatically when it gets the SIN message and it's accepted by this rule it automatically maintains this state for the connection and updates it as it sees the SIN and the AC and as it receives the data and at some stage the connection may be closed and there may be a FIN message saying finish this connection let's close the connection no more data to come and at that point the state will be changed to finished and eventually this information will be deleted because once the connection is closed the firewall should not accept any more packets automatically from those pairs of computers because it shouldn't be expected so the firewall automatically keeps track of the TCP connection and automatically accepts anything that was specified by our rule by the administrator on the TCP you either explicitly close the connection send a FIN message but maybe if you don't do that the firewall will probably have some time out value here after two minutes let's remove this data if there's been no packet sent between these pair of computers let's assume the connection's been closed let's remove this entry so the next packet that comes in will not match any of these this rule will be checked if it's accepted then a new entry will be added here if this rule is not met then no entry is added so the way that the firewall works overall now is that as a packet comes in check the SPI table first if there's some information about an existing connection in the SPI table that matches the packet then accept it if there's no information in the SPI table then revert to our normal rules check them if they don't match then drop if they do match then add more a new entry to the SPI table and a time out will cause this entry to be deleted from the SPI table or a FIN message will cause it to be deleted that's a lot of detail of how stateful packet inspection works the the main point to remember is that SPI automatically keeps track of TCP connections once the firewall administrator needs to add just one rule to accept the start of the connection and the firewall that will then keep track and accept all subsequent packets related to that connection so packets are connected, are related to a connection between two entities what if computer 36 tries to send to computer 12 well it will not match the entry in the SPI table because it's a different IP address or what if computer 35 using a different port number 50124 tries to contact the web server again it will not match the entry in the SPI table because the entry records the exact port number so that automatically keeps track only accept things between 50123 on 35 and the web server on computer 12 another port number it will not match here and will need to check the rules and if it's accepted here a new entry will be added to the SPI table the end result should be much easier for the firewall administrator just add one rule let the firewall keep track of the responses and that's commonly used in firewalls today right if a packet comes to the firewall and it matches the first purple rule here then that will trigger a new entry added to the SPI table if it doesn't match, if it's dropped then of course nothing's added to the SPI table so the ordering again check the SPI table first if that doesn't match check the firewall rules if not take the default action if the SPI table if there's a match accept automatically and note that the match in the SPI table any order that is the source and destination address recorded is just that of the first packet if the source and destination is in the opposite order it's still a match that is explained to some extent on the slides here stateful packet inspection is what we're doing but I think the example captures all the things that we need to know it makes it easier for the firewall administrator at the expense of the firewall needs to keep track of all this state of connections and a firewall may have millions of connections passing through it and requires a lot of state information there memory and processing to record that that's the disadvantage but I think that is enough for today what we'll do next week is we'll just summarise and what we've learnt about packet filtering firewalls the basic approach then the extension using stateful packet inspection and then we'll look at just quickly with few examples or almost no examples the last two approaches how to arrange firewalls and we should finish that on Thursday next week