 The point we tried to finish on in the last lecture was that when we have a default policy of drop, and a default policy of drop is good, it's good for security. We should drop everything and then we just allow the things in that we want. That's a good approach because if we make a mistake, let's say I forget to add a rule, the attacker still can't get in because their packets will be dropped. It may mean our normal users can't do something, but that's just an inconvenience. It's not a security violation. So it's a good to have a default policy of drop. But we saw in our very simple case, when we have a default policy of drop, we need two rules to allow an application to work. We need a rule that allows the packets to go out and a rule really for the opposite direction for the packets to come back. Because our applications, we don't send data in just one direction, it's bi-directional communications. So it makes setting up the firewall table a little bit more complex, because for everything that we want to do, we need two rules, not one. More chances to make a mistake or forget something. But not only that, with the two rules that we created, we said that there's a potential security flaw, because using the second rule, it allows someone outside to send a specially crafted packet, where the source port is 80, and it's going to computer 12. And it will get through the firewall, which was not our intention. We don't want someone to send a packet in to computer 12. We only want the responses to our web requests to get to computer 12. So we need maybe some extra information to say, only allow these packets if there's some responses. And it starts to get more complicated about how to set up those rules. We have to give more conditions. So to overcome that complexity, most firewalls today have an extra feature called Stateful Packet Inspection. And the concept is quite easy. We create one rule that allows the first packet to go out, the first packet of the exchange to be accepted. And when that happens, the firewall keeps track of some information saying, all subsequent packets related to that first one are automatically accepted. So with a Stateful Packet Inspection based firewall, what we will do is we'll create the top rule. We will accept everything going out to destination port 80. The first packet in our exchange, when this goes through the firewall, the firewalls will see this packet and see, the rules as accept, good, we'll let it go out. In addition, the firewall will keep track and realize, because I just let this TCP sync go out, I expect to get a TCP sync from 333.35. So I'll keep track of that and I will allow that sync to come back. The important thing is that the firewall does that automatically. The administrator doesn't have to configure the firewall to allow the reverse packets to come back. And that's what Stateful Packet Inspection does. It maintains a record of the connections that have been accepted by that first packet. So let's see how SPI, Stateful Packet Inspection, works. It makes setting up the firewall much easier, because we are dealing with connections in many cases, in particular TCP connections. We know with TCP it's always at the start. SIN, SINAC, ACC, and then data. So there's this typical flow. Rather than the administrator having to create rules to allow all of those packets, the administrator creates one rule to allow the first packet, and then the SPI component of the firewall allows subsequent packets. So it keeps track of the connections which have been accepted. And a TCP connection is uniquely identified by the source and destination IP address, who sent it, who did it go to, which computer, the source and destination port, so that's the applications communicating. We can also use sequence numbers, because we know with TCP there's a sequence number involved. We can think the first, we have some initialized sequence numbers, and then we increment the data. And with TCP, we also have a connection state. And you may not have seen them described in detail, at least in my courses, but we go through a process when we use TCP. We initially don't have a connection. When we send the SIN and get the SINAC and the final ACC, we've established a connection. We exchange some data. And when we want to stop sending data, we close the connection. So we can say the connection goes through a series of states. And our firewall will keep track of those states. Let's see what the states look like. I'll draw a new picture to get rid of this one. Let's consider a generic TCP connection and look at the states that we go through. With TCP, we have a client and a server. The client initiates the communications. The first message which is sent is the TCP SIN. So the sequence of TCP packets, the first one is a SIN message to synchronize sequence numbers. The next one is a SINAC, then a final ACC, and that's the three-way handshake to establish the connection. Then we send data. We may send data in both directions. Now, there are a number of named states that each side goes through, depending upon what's happened so far. We can think that initially both sides are idle. They haven't done anything. When the TCP client sends the SIN packet, it changes state. Now it's in the SIN SENT packet, a SIN SENT state. That is, the client has just sent the SIN packet. It's in the SIN SENT state. What's the client expect to get next? What does the client think will happen next in the normal case? It expects to get the SINAC message. So we keep track of what we've done in the past because based upon what we've done, we expect something in the normal case to happen. And if that happens, we would like our firewall to automatically allow those packets through. Similar to the server, the server is idle. It has SIN received, and then after it sends the response, SINAC SENT. And when the SINAC is received, of course, the client is SINAC received. And after the server receives the AC, what state are we in? Anyone want to give it a name? After the server receives the AC. Well, note that that's the end of the connection establishment. This procedure of sending three messages, SIN, SINAC, AC, the idea is to establish a connection. So we say the connection is established at that stage. And similar from the client's perspective, after it sends the AC, the connection is established. We send some data, the connection is still established. While the connection is established, we can exchange data. We'll not draw all the details. There are ways to close the connection. Eventually, we may send some packets and it changes states to, it's a little bit complex for closing, but eventually we may see something like time wait. We're waiting for the connection to finally close and then closed. And there are some other states as well in special cases. But each side goes through a set of states normally. Now what our firewall will do is keep track of the state from what it's seen of the packets. So the firewall is in the middle. So the client, maybe our computer inside the network, the server is a computer out on the external network. The firewall is in the middle and sees these packets going past. So when the firewall sees the very first SIN packet go past, it realizes this client is trying to communicate with this server. And the administrator of the firewall allows this SIN packet to go out. So it needs to be a rule to accept this SIN packet. If there is, then the firewall keeps track and thinks, okay, this client and server wants to communicate. Currently, the SIN has been sent by the client. So if a SIN act comes back in the reverse direction and a SIN has just been sent, then I will allow that SIN act come in. I'll automatically allow it without checking the rules in the firewall. And then the firewall, once it sees the SIN act go through, it knows that the SIN act has been received. So the next thing the firewall expects is to see the act coming in the reverse direction, back from client to server. And if it sees this act, the firewall will automatically accept this act. And finally, when the act has got passed through the firewall, the firewall knows the connection is now established. And now, if there's any TCP SIN packet coming from this client to this server, same IP addresses, same port numbers, and the connection is already established from the firewall's perspective, the firewall automatically allows it through. And same in the opposite direction because we're allowed to send data in both directions. And eventually, the client or server will send a special message to finish the connection and they'll go through some states to close the connection. The key point is the firewall, the administrator sets one rule to allow the very first packet and the firewall keeps track of that and then will automatically accept all subsequent packets related to that connection. And that's done in the stateful packet inspection table. And it's mainly relevant for TCP. It can be done for UDP and others, but it's primarily used for TCP because TCP goes through states, UDP doesn't. It's more complicated. So let's see what it would look like in a couple of examples. We'll return to our example network, if I can find it. Come back to our network, here it is. Here's our network, where's our firewall? Just remind ourselves, here's our firewall, same as the previous examples. We have, we want to allow computer 12 to access one of the web servers on network three. That was our previous example. And we had to create two rows in the firewall to do that. Let's do it with stateful packet inspection. So the same aim as before, we want to let this computer to access the websites on these external computers. So first, we need a rule in our firewall table that says we allow the first packet out. And this is the same as we did in the firewall before. We have a rule that says, so this is the firewall table. We have source address, destination address. And to save some space, we'll write both the IP address and the port number together. So we'll not have two separate columns. I'll show you how. We have the protocol and the action. This is our firewall table. And what we say is we want to allow the packet to go out. So that if the source is 111.12, port number, and I'll write the colon followed by the port number. If you remember back to our previous example, any port number. And the destination we said was 3330 slash 24, port number 80. Protocol six for TCP, the action will be accept. Remember, we are using a default action of drop, the default policy we refer to it. This is in fact the first rule we created in the previous example. Computer 12 using any port can send our packet out to anyone on network three. And in the previous example, we had a second rule that says that the response packet should be accepted. But with stateful packet inspection, we don't need that. We don't need the second rule. Instead, what happens using just this rule, we have stateful packet inspection enabled. We in fact have a second data structure stored in the firewall, the SPI table I'll refer to it as. What happens when we communicate from computer 12 to computer 36, for example, we send a packet. Think of the very first packet sent from computer 12, we could draw it as this. It's an IP packet and a TCP inside that. Some of the field values in this packet, the source address, it's coming from computer 12 and the destination, going to computer 36. Protocol number, because we're using TCP, it's number six. And in the TCP header, we have a source port and that would be assigned to that computer 12 application. Let's just make up a number, 48037. Destination port, what's the value? We're trying to create a TCP connection to the web server from 12 to 36. This is the very first packet sent by computer 12. What's the destination port? Browser to web server. Destination port is 80. So destination port 80. Source port was assigned randomly to the browser. I just made up a number. Source and destination IP of those two computers. So computer 12 creates this packet. Destination port 80. This packet sent by computer 12, it gets to the firewall. What happens at the firewall? Well, what the firewall does is it first checks the stateful packet inspection table, but there's nothing in there at the moment. So there's nothing to do there. So now it checks that packet against the firewall rule. We only have one rule, very easy to check. Does it match? Yes or no? Hands up for yes. Does our packet match the rule? Hands up for yes. Right, it does. Source in the rule, 11112, yes. Source port. So I've shortened the way to write the IP address and port number. Source port, any value? Yes, it's some value. Destination is network 3330, which includes 33336. So yes. Port 80, yes. Protocol 6, yes. All the conditions match in the rule. So we accept the packet. So this is the normal behavior. This packet is accepted through. The firewall sends it out. It will go to computer 36. But when we accept that packet, the firewall does something else. It starts to add an entry to the stateful packet inspection table. Because it knows this is the first TCP SIN, and maybe I should have written on here, in the TCP header. There's a flag that says this is a SIN segment. It's inside the header, a field saying this is a SIN segment. The firewall says, ah, this is a SIN segment. In the normal case, if a SIN segment is going out, I'd expect a SIN act to come back. So it adds an entry to the stateful packet inspection table, keeping track that these two applications are communicating. So let's add that entry to the table. It's a different data structure. And we keep track of, if we can fit it in, we keep track of a source, destination, protocol, and the state. And the source, the one that sent the packet, we know, 1, 1, 1, 12. Port number, we know. So the firewall knows it used port 48037. Let's record that. Destination, we know, was 3336, port 80. Protocol was 6. And the state, what's the state from the firewall's perspective of this TCP connection? Go up to the top picture. The firewall has just seen the TCP SIN come from client to server. So we can think the state is SIN sent. We know the SIN has been sent from the client's perspective SIN sent. And eventually, it will be SIN received by the server. So we record the state that say the SIN has been sent. Actually, the state from the client's perspective is SIN sent. The state from the server's perspective will be SIN received. What the firewall normally does, it assumes, of course, if the firewall lets it through, the SIN will be received. So it records the receiver's state. SIN received. Let's write it down. Just records those values for future use. What happens next? The server receives the packet. It sends a reply. What does the reply look like? Let's draw it up the top. IP header, TCP header. Let's be complete for this packet. Source, destination, protocol, source port, which is in the TCP header. Destination port in the TCP header. And the flag, flags. What are the values? This is the return packet. That is, what we're drawing here is this one. The first one was accepted, received by the server. So it sends back, eventually, a response. What are the values in that response? Fill them in. Fill in the values. What's the value of the source IP? This is the response. What is it? Source IP. There's only really two to choose from. What's the source IP? We've just, the very first packet I drew was from the client to the server, from 12 to 36. The server receives that packet, sends back a response. So the address has changed. So the source of this packet is computer 36. Destination is computer 12. Protocol is still TCP. And the source ports. And the destination port are the opposite of what we had here. It's coming from port 80, going to port 483037. And the flags, just going back up, SINAC. SINAC are the flags here. That's the next packet in the sequence. This packet was sent from 36 to 12. It eventually gets to the firewall. What the firewall does is, before checking the rules, it checks the SPI table. And the way that it checks, it sees in the SPI table, the computer 12 with 483037 is communicated with computer 36, port 80. And the previous state was SIN received. So now I've seen a packet belonging to those two. Even though the source and destination are swapped, it's part of the connection. Because we expect it to change when the return comes. So even though we record the source address as 12, and this packet has source address of 36, it's still the part of the same connection. Because the connection is identified by those ports and IP addresses. They all match, which are just swapped. The previous state was SIN received. Now I see a SINAC. Ah, that makes sense. Previously, the SIN went past. Now a SINAC is coming back. Let's accept this packet. This packet is automatically accepted. And that's using the SPI table. And the state changes. It was SIN received before. Now the SINAC goes back. So the SINAC is received. And you won't be able to, hopefully you can fit it in better than I can. The state changes. It's now SINAC received. So the key point here is that we didn't need a second rule to allow this return packet to come back. The stateful packet inspection table deals with that automatically. What happens next? The AC comes back, the third packet. All right, this client sends back the AC. I will not draw it. It looks similar to the one on the left. Same source and destination values. Same protocol. The flag will not be seen. It will be AC. It comes back. It goes via the firewall. The firewall sees it and checks. I previously recorded a SINAC was received between this pair. Now I see an AC. Let's automatically accept it through. We accept that AC through and the state changes to what? What's the new state? The state will be established. The connection is established. When the AC goes through, we're finished with this connection establishment. So the state changes to established. What happens next? Either of the sides send data. 12 cents data to 36 or 36 cents data to 12. The connection is established. When the connection is established, if the firewall sees a packet with this combination of IP address port, IP address port in either direction. So 12 doesn't have to be the source. 33336 can be the source. So we accept both directions. Then since the connection is established, if we see data going through, just let it through the firewall. No need to check the rules. Just let it through. And that keeps going. And at changes state, there's actually a final connection close packets come to change it to a state. It actually change it to an intermediate close state, not a final close. And it waits for maybe a couple of minutes and then it really closes the connection. So there's some extra details of how to close connections. Once the connection is closed, this entry is removed. The SPI table doesn't keep track of this pair. Any packet belonging to these two will not be automatically accepted. We'll need to process them with our original firewall rules. So we only accept packets between this pair while we have an entry in the SPI table. Any questions on SPI so far? The benefits and how it works, okay? Be careful that when we draw the SPI table, we identify the source and destination. But when a packet comes and is processed, we can accept in either order. So the second packet, the source was 36, destination 12, source port 80, destination 48037, that matches this entry because we accept both orders. Any questions before another example? Most firewalls would use stateful packet inspection today because it simplifies things greatly. The administrator creates one rule to let the first packet in. Everything else is accepted automatically. The administrator doesn't have to care about SINACs and the closing of the state. The firewall will handle that for you. So what the admin needs to do is says, all right, I need to allow computer 12 to access web servers on this subnet, create that one rule and the SPI table will deal with the rest. You have seen these states probably when we use netstat as a command line tool. As a quick example, when we use netstat, it shows us the TCP connections from this computer or this IP port 22 to this one and the state is established. Let's finish with one example of a quiz question from previous years. We'll go through this example question and see how the firewall in that stateful packet inspection table is used. You may not have this in your handouts. I can't remember if I included it. No, you'll see this picture in the quiz when you take on firewalls. So this is one grabbed from the quizzes. So we'll just step through it. At the top is our network topology. We have some subnets, quite simply one, one, one, zero, subnet two, three and four and in this case, the firewall, I think the question said the firewall was on, where was the firewall? Let's say the firewall is on router A. So assume subnets one and two are internal and three and four are outside and the firewall is on router A and I'll show you an example of the firewall table. Firewall is here. In the quiz, there are two different variations but the question gives you an existing firewall table. Let's have a look at the firewall table. So the administrators added these five rules already. So they wanted to achieve some aims. The first rule says that source IP 3336, any source port consent to the secure shell server on computer 1112, protocol TCP, let's accept that. Default policy has dropped and there are five rules in total which have been added. Some allow for specific computers to communicate. Some are entire subnets. So that's some rules which have been added just for this example. In addition, in this question, we assume that some of those, some connections have been established in the past. So there is a stateful packet inspection table as well in the firewall. This records the current state of connections and we're assuming that established connections. It says there's eight currently established connections. There's a connection between 3336 and 1112, specifically using port 44981 to port 22. And there's also a connection between that same pair of computers but using a different source port. Look at the connection one and two in the stateful packet inspection table. What do you think that means? What's happened? Looking at one and two, what has happened recently? How did computer 336 communicate with 1112? What application was used according to SPI rule one? Port 22 is secure shell. So someone on computer 336 has secure shelled into computer 1112. Twice. Well, it turns out three times. The SPI connection one, two, and three, same IP addresses, same destination port, secure shell, secure shell, secure shell, different source ports. So maybe they've opened up three terminals and they've secure shelled in the same destination three times. That's what's happened here. And there's some other connections already established. So this is the current state of the firewall. Now the firewall receives a packet. I'll write down the packet conditions and we'll see what happens. A packet comes into the firewall and it has these characteristics. We'll draw the packet. There's an IP header, TCP, and some data. We don't care what the data is in this packet filtering firewall. And the address values, source port is 23. Destination port is 44981 and the source IP and destination IP source is 1112. 3335 is the destination. This packet comes into the firewall. What happens? What does a firewall do with this packet? Two answers, except or drop. And then the more interesting question, what rule or what entry, one to five in the firewall table or one to eight in the SPI table, which entry causes that action to take place? So what we do is we go through the tables and check the packet values against the table values. First we check the SPI table. Doesn't match any of those rows, any of those eight SPI entries. First one, well, no, we must match the IP addresses. So it's between 1112 and 3335. So 12 and three do not match because 12 and three are with 3336. So no match there, this is 3335. This one doesn't match, five does not match. So just checking the IP addresses, you can quickly see, do any of them match? None of them match here. So this packet is not related to an ongoing connection, an established connection. Maybe it's a new packet, a new connection. But we know because we haven't seen this connection before, so this is not an ongoing connection we've observed. So we now compare this against the firewall rules. Does it match any of our rules? Hands up for yes. Does this packet match any of our five firewall rules? Source IP 1112, this is even easier to check. 1112, source, no, no, no, no, no. What happens with our packet? Default policy drop, okay? It matches nothing in the SPI table, nothing in the firewall rule table, so we take the default action, the packet's not allowed through. So that's a simple case, but note we check the SPI table first and then the firewall table. Now let's try a different packet. And I will not draw the entire packet, I'll just write down the values. Source IP 4447, destination IP, and you can check as we go through, as I write them down, find the answer. What happens? 2223, source port 44981, destination port 80. Well we check the SPI table first. Do they match? Does this packet match any of the existing established TCP connections? Which one? Five, six, hands up for one, two, three, four. Does it match five, six? Does it match six? Why does it match six? Source IP of our packet is 4447, source port 44981, destination 222380. It does match this rule because the SPI table we allow in either direction. So be careful here. So yes, it is a match because with SPI, even though we list them as source and destination, it's the original packet that it was a source of. That very first syn, the source was 2223, 44981. So we check in both directions. So yes, it does match here. So row six of the SPI table matches. What happens to our packet? Accept or drop? Accept. If we have a match in the SPI table, it's automatically accepted. So that one's allowed through. We don't even check the firewall rules. So that packet belonged to an existing connection. If it didn't match any of those rules, any of the SPI entries, then we'd go through here, check normally whether it matches. If it did match one of these, it'll be accepted. In addition, we would add an entry to the SPI table. Okay, so if we get a match in one of our five rules from the firewall table, we accept the packet, plus we add a new row, the ninth SPI entry in the SPI table, and then subsequent packets would be matched. And if we will not see it in the example, if eventually a pair closed the connection, the row from the SPI table will be automatically deleted. So this is updated over time by the firewall. Stateful packet inspection is a key feature for most packet filtering tables today. It makes things much simpler because we just need to set up a rule to allow the initial packet through.