 Success. OK, great. Oh, thank you. OK, sorry for the delay. We're going to get right into it. So today we're talking about TCP, right? So up until this point, we've talked about how to do port scanning with TCP, right? And we saw there's all these different ways we can try to extract some useful information about another machine's TCP port, right? Try to determine, is there a service running and listening on that port? So we saw connect scanning, SIN scanning, FIN scanning, Christmas tree scanning, all kinds of crazy scanning. We saw idle scanning, where we could see that we could actually use another machine to actually try to scan our victim, right? Which is a very cool security technique. So some of the other things we can learn. So from that, right? So Christmas tree scans, FIN scans, right? They all depend on the behavior of the specific, did I shut it off? I spent so long trying to turn it off. I found the button that's here, which is impossible to see when it's off, which seems like a terrible design. OK, so we saw that with all these kinds of scanning, right, they take advantage of certain peculiarities of certain types of TCP IP implementations, right? Specifically, what happens if I send a TCP IP packet with all ones as the flags, or all zeros as the flags, right? And so what we can actually use, and some techniques that have been used, one of the things we want to discover, right, we're trying to, or a hacker would like to discover, is what operating system is that machine running, right? Oftentimes you just have an IP address, so you don't know if it's Windows, or if it's Linux, or VSD, or an iPhone, or any of these other things. So what people have found is you can actually use these weird bits of the difference between the different TCP IP implementations, and you can try to fingerprint the operating system to try to say, is it a Windows machine? Is it a Linux machine? What kind of machine is it? So the idea is you can craft packets to the host to try to determine what kind of operating system it's actually running. This is actually a very, very cool technique. So you could say what happens if I send a thin packet? What happens, what does it do? Or what if I respond to a thin packet by sending more data, right? Does it send a request packet? What if I know that it's the wrong thing? All these kinds of things. So if I, yeah, so some like weird combinations of flags in certain operating systems will drop the packet in certain operating systems, it'll send a reset packet. So you can use that determination to try to fingerprint the version number. You can use the, sometimes the initial sequence numbers will be different. The window size will be different on different devices, different operating systems, different, yeah, devices operating systems. What happens when I send ICMP messages, right? Does it block the ICMP messages? Does it have some kind of an error rate? How much of the ascending datagram, so if there's a bad packet, how much of that packet does it include in the reply to help you debug certain implementations do it differently? What happens with TCP options? Does it respect certain TCP options or not? So it's actually very cool. So you can do this in a passive manner with a program like TOF, which will actually just look at all the network traffic and be able to determine or try to determine, hey, this looks like a Windows 7 machine or this looks like a Linux machine. Other things, Nmap has a configuration for this where you can say, hey, try to determine what operating system it is. I think it's the dash big O sign. And so it has essentially, you think about it, a tree, right? All these different, if I send this packet, if I get this response, it means it's in this half and if I get this other response, it means it's in this other half and it can refine all the way down to try to determine exactly what operating system is running. Where's something to have to be careful of here? So what does it tell us when it says, I think this IP address is this operating system? Maybe, right? It tells us that this tool thinks that it is that operating system. Does it mean that it absolutely is? Not necessarily. What are some cases where it might not be? So yeah, maybe before you, in the time between you made the scan versus the time you actually launched an attack, maybe the OS got upgraded. All this tells us is that I think this IP is this operating system based on the packets that I sent to it and its responses, right? So if that IP is actually a load balancer for two different machines, who knows where those packets actually went if they went to the behind the load balancer machine, if it went to one of those two machines or if it went to the load balancer itself, right? Or what about, think about ASU, right? Or your home, right? You're probably not connected directly to the internet, right? You have a router in between you and the internet that's doing natting so that it appears that all of your traffic is coming from one IP address, right? So then who's it scanning really, right? All your packets are gonna be dropped from the router. And so it's just gonna say I couldn't really determine the operating system. But even if it could, it's probably wrong, right? Because it's not actually getting through. So these are just some things to keep in mind, right? So this is more about, okay, I can use this tool, right? To run, it'll give me some output. But really to trust that, I need to know how it's working. Right, so I need to understand more about the operating system. Okay. So now we're gonna go back to our old friend, Spoofing. So what is Spoofing again? What was it? Yeah, we wanna impersonate, we wanna pretend to be some other IP address, right? That we're not for some other host. All right. So the idea is we wanna try to impersonate a host, impersonate another machine when establishing a TCP connection. It was discussed in this paper, which is a really interesting read if you wanna do it. Anybody recognize the name there? RTM, the Morrisworm guy. This was like two years before, or a year, I think two years, three years before the worm. So it's just showing that he was very interested in security and knew what he was talking about and probably had the knowledge to build the worm. It was also used by Kevin Nittnick and is attacked against the San Diego Supercomputing Center. But now we actually have enough background knowledge where we can understand this attack and kind of how it worked. So why do we wanna do this? Why do we wanna spoof another host? Get some confidential data. How? Why? Moving all the TCP packets and if it's unexpected, then you can get the data from it. This isn't snooping, right? We're not trying to listen to the packets. We wanna spoof, so what is that? What are we trying to do? We're trying to get the wrong information. We can send the wrong information? Yeah, what was that? If you spoof a trusted host. Right, so yeah, we're taking advantage of the fact that this machine trusts some other machine that trusts it only based on the IP address. So we can pretend to be that IP address. Now we can take advantage of this trust relationship, which is how the Morrisworm propagated and it's how we'll see how Nittnick got into the San Diego Supercomputing Center. So for instance, if host A trusts host B, to log in with no password, basically so it's a configuration that says, hey, if you're coming from host B, then you don't have to type in your password because I trust you, I trust this IP address. So we wanna impersonate node B to get this trusted relationship, right? Because host A does not trust us, right? Host A only trusts host B. We're some third thing. So what do we wanna do at a high level? Have to do to be able, let's think about like, to be successful, how are we gonna spoof this connection? It's TCP, what do we know we have to do? Handshake, that we have to do three way handshake with C as if it's coming from B, right? So let's walk through that process, right? So what's the first thing we're gonna wanna send? A send to B from who? From C, right, exactly. Or from B, so we're gonna send it to A from B, but actually from us, right? So then node A, then what are they gonna send? A SINAC back to host B from host A, and then we have to reply with what? An AC from host B to host A that has the correct sequence and acknowledgement numbers from that other host, right? Well, what's one problem? So let's say we try to do this, right? We send a packet to host A, a SIN packet to host A from host B. What are they gonna do? A SINAC to B, and then what's B going to do? Reset. Yeah, reset and be like, what are you talking about? We haven't made this connection, right? Reset. So our very first step is we need to somehow kill A or kill B or have it not respond to these SIN requests. Because if it responds and resets our connection, then the whole game is up. It's not that difficult. We could probably take out B pretty easily. And we only need to really be successful once, right? So we could just make a lot of traffic and keep trying this over and over. And maybe one time that packet, that reset packet gets dropped and then our attack is successful, right? So as an attacker, we have time on our side because we only need it to work once, right? We first have to kill B, then just like we said, right? That's trivial quote, quote from a high level, right? Because all we have to do, all we have to do, so is this part difficult? Is sending a TCP SIN packet with a spoof IP a spoof source IP difficult, right? We saw that in the IP layer, right? We can just spoof ICMP messages, we can spoof UDP packets, all that. So when A replies back with its SIN ACK, right? So B, we're counting on B ignoring this packet, right? Because we denial of service that we've taken it off the network, it's not gonna respond. So do we get that packet, that SIN ACK packet? So is this a bad thing? Yeah, it makes things a lot harder, right? Why is it making things harder? We don't know the sequence number. Yes, the sequence, we have to reply back with a valid sequence number, right? A is going to generate this server-side sequence number, right, and we have to acknowledge that with, in this case, SS plus one, right? To establish the connection. So we don't get that, but we have to reply with that plus one. So how can we do this? Let's think attack mode. Is all hope lost? Can we never do this? Yeah. What happens when BU receives a bad ACK back from the SIN ACK? So it sends a SIN ACK, what does BU do? Can I send multiple ACKs with the current? I really don't know off the top of my head. I would just blast it with every, you know. Yeah, so you could guess. I mean, that'd be a good board. I think it would drop the connection or it would send a reset or something and say, okay, something messed up is off the top of my head. But either way, you could just brute force in the sense that you just keep doing it two to 32 times, right? You don't have to send two to 32 packets, ACK packets, right? You can do a SIN, they send a SIN ACK and then you send an ACK with one thing, then you send a reset and then just keep doing that again. You know how I'm generating it. It just wouldn't be very safe to get caught and you can make your connection and see where the sequence is and then make sure it's also connected. Yeah, so one way would be if we can guess what that sequence number is, right? And we can be reasonably certain we actually know what if that is. What's another way though? Maybe I accidentally put it out of scope, yeah. Yeah, right? If we even drop that packet, if we see that packet somehow, then it's great, then we're good, right? If that node is on our Wi-Fi network and we're sniffing packets because it's an unencrypted Wi-Fi, when we see that packet and we can use that sequence number, we can just use it, right? Or we have to somehow guess it, right? And somehow we guess correctly the sequence number, right? Then we do SIN plus one and everything's good. So let's see how this looks like. So we first, what's the very first thing we wanna do? Kill B, we first need to kill B, right? Make sure it does not send any packets. Then we're gonna send a packet to A as if it was from B, right? And so we send the SIN and then they're gonna send the SIN act to host B, which we don't see. And then we have to somehow try to reply with, right? So we need to make sure that this act here is this sequence number plus one. And then we can send data and everything's gonna go properly. So this is tricky. So there's, you know, the spec said that the sequence number should be random, right? Don't really specify how to actually do this. So there's been some updates of how to improve that. But oftentimes implementations don't actually generate random numbers in a real random sense. So there's a great paper called Strange Detractors and TCTIP sequence number analysis where basically they look at the distribution of sequence numbers in like a graph space. And so you can see how it looks like. So you can see based on, I believe it's calculating the X value of the difference between sequence, like the past two sequence. You take n minus one, n minus two, n minus three is the last three sequence numbers. And you can take basically the delta between two and three and the delta between one and two and graph that delta. So what is this kind of gonna show you? I guess this does actually in three dimensions. Yes. All right. So what's this gonna show you then? So there are some things back in generative in two dimension which says it's not exactly random and exact random ones and it's very, very different. Right, so if it's random, how should it look in this 3D space? A complete sphere with equally uniform distributed Yeah, right, so it should be disperse or some kind of a good kind of like a cloud in some sense, right, very disperse is how we want it to look, right? Because if it's not, then that means we can predict what the sequence numbers are going to be here. And if we can predict the sequence numbers, then this three-way handshake thing we can completely spoof trivially, even if we're not able to eavesdrop on that syntax package. So it turns out by doing this to a bunch of operating systems, we get some super secure looking clouds like this. So this is for Windows 2000 XP, which is pretty good, right? I mean, it's fairly distributed. There is like a concentration here, right? This is Windows 95 and 98. Probably not very one of these, right? This is pretty insecure. So this is Linux, the Linux distribution, right? So this is kind of what you'd want it to be, kind of this distributed cloud. Here's like the free BSD one, which is actually even more disperse. So we talked about, I believe, the Cisco operating system on the routers, right? It's called iOS, heavily confusing. So they had a problem, it was they called before the cure. So after they did this fix, they could see that it was followed this very even distribution pattern that was very easy to predict. And then after they fixed it, it disperses. Like this is actually very well dispersed. I don't know if it's coming through on all the, okay, kind of shows up there a little bit, but it's very dispersed. On the Mac, the Mac was also fairly dispersed. HP, I actually don't know what to say. Is it HP Unix? Is that what the UX says for? Okay, you can see that it's definitely not, not really distributed how you want it, right? And you can see that after the cure, it actually, when it did get fixed, it has like less of this core. This one, I don't know if you can tell, but there's just like a few dots right here. Like this is before, yeah. So you can see that it's really hard to get this right. And so TCP, right? And it's interesting to think about, like this is just something, think about, this is some networking detail, right? Like how do you generate these sequence numbers? So the fact that, when they were writing this TCP specification doesn't, they didn't specify how to create random numbers or what it would mean to be a random number. And possibly, why did they think about that? Are they horrible people? What do you think? Could we shame the spec writers? Shame on you. It was not meant for security purpose when it was disarmed. Yeah, right. So they probably weren't thinking about, is this really a problem? Because it's kind of the administrator who has established this trust relationship between these two hosts, right? And so the fact that the security in essence relies on correctly choosing this one random number that nobody has ever said up to this point that hey, maybe it's a security problem that this number is not absolutely crazy random. So yeah, so it's kind of, in one sense, you can defend them by saying like, well, the spec, and say that it's secure or anything, they're just designing a network protocol. On the other hand, you'd be like, Gabby, you're designing a network protocol that the internet uses, so maybe you should think of security. The flip side of that, right? They weren't really thinking, nobody was thinking about security back then. And it wasn't until applications built on top of that rate that it actually became a problem, right? If nobody trusted IP addresses, then this wouldn't be really as near a problem. So the fact that there's trust relationship exists really does cause a problem. Okay, so we talked about spoofing. So what's the difference between spoofing and hijacking? I think so. The control of the session. What was that? Taking control of the entire session. Yeah, or taking control, or just even injecting data into a virtual circuit, right, a TCP circuit between two hosts, right? So it's essentially, it is in some sense spoofing, because you need to spoof data from one side to the other side. But in this case, we're not establishing a whole connection. We're trying to inject into an already established connection. So the idea, so what are we gonna do? So we wanna do this, what do we have to do? So do we need to do like a SIN, SINAC, and MAC? No, what do we have to do? Route the packets towards us. Route the packets towards us? What do we can? I mean, at high level, what do we have to do? Maybe mirror all the traffic. Mirror all the traffic, maybe. That could be a technique. These are all techniques we can use to do this. Kill the bee and dig the session. Couldn't kill bee? Yeah, we'll see that we may need to do that, or it may happen automatically. Man in the middle? Man in the middle. Essentially, that's what we're doing, right? We wanna try to inject some traffic into the middle there. What do we do? Like so. Switching up, switching up, switching up, it's becoming a little bit. The route. We're making it up. Not quite. Hubs, these are all techniques, right? Change entry in the ARP table. Change entry in the ARP table, that's gonna be how we want to actually do it. Or kill a bee session at bee site, but just and connect that session to us. Almost. Close. How many packets do we, let's say we just wanna inject some data into the conversation. How many packets do we have to send? So before we need to send two of the three-way handshake, how many packets do we need to send? Just one if we have to send. Just one. If our data can fit into that one. Make the system accept that it is valid data. So how do we make the system accept that it's valid data from this communication? How does it know? How does the host know that it's a valid data? Yes, the sequence number is what it's expecting, right? Is inside the window. What else? Source IP. Source IP. What else? Source port. And what else? Source IP. Destination IP. Destination port. Yeah, exactly, right? So this is where all that studying all those crazy details of this would be protocol, right? So it knows it's the connection because source IP, source port, destination IP, destination port, right? And it knows where that data goes because it's inside the TCP window, right? That sequence number is inside that. So that's essentially all we have to do is throw a packet out and make sure that it's in that window, right? How we actually do that, we can use all of these techniques that everyone's saying about how to actually eavesdrop on this communication channel or how to maybe take control and do kind of a man in the middle thing. So the idea is, yeah, we're gonna try to insert most often, and the most interesting case is when we wanna insert some data in there, right? But we could also, if we wanna do like a manual service, we could just send a reset packet, right? To make it close the string, which could have important security ramifications, right? If you can stop the backup process after you've broken into a server, now maybe your actions aren't backed up anywhere and so you're less likely to get popped. So, but we have to do the, we have to have the correct sequence and acknowledge the numbers, right? So that way, we know that everything's in the border. So we talked about that, right? You all actually have incredibly good suggestions based on what we've learned so far, right? So we can eavesdrop the traffic, right? We can see if we could eavesdrop the traffic by doing art poisoning, right? And getting everyone to send their packets to us, right? In front of the local network. We can also eavesdrop if we were to turn the switch into a hub, or if we were on a hub and could see all the traffic on there. We can also guess the correct sequence and act numbers. And so there's a good paper to read if you wanna learn more about that, about how to do this. So, one problem is if we wanna inject data to the two sides or continually exchanging information, what's gonna happen to that, the TCP window that we want to inject into? Yeah, that's gonna be slightly, it's gonna be constantly changing, right? As they continue changing data. So it's like, how am I trying to hit a moving target? Right, it's gonna be harder to try to land in there if it's constantly moving, right? So the first thing is we kinda wanna try to wait until the connection is quiet, right? And nobody's really sending any data. So, both end points, I've acknowledged all the traffic, now we just need to somehow get in there. So, then we inject our data in the stream, right? Let's say we're able to do this, we correctly guess or whatever. What's gonna happen now to both of our end points and their view of this TCP connection? Just to be clear, I'm aware we're having a change. On which, on both of them? Yes, on one of them, right? And that's, is that a problem? Yeah, right? They're never gonna be able to talk to each other because one side's gonna say, hey, here's, if I inject, let's say sequence number 10, right? And the side that I injected acknowledges that. The next time the other side tries to talk, it's gonna send that at sequence 10. It sends, hey, here's sequence 10. And the other side goes, I already got this, I'm expecting 20, what are you doing? And so they can never, so we've essentially, if you think about it, right? You think about kind of the state that the TCP connection on both sides being the current sequence and acknowledgment numbers, right? That they've seen on both sides. And we've desynchronized this process. So what's gonna happen after we successfully do this? So let's think about this, right? So we have this connection, let's go with 10, right? We're starting at sequence number 10, then both quiet, not talking. Nobody's terminated the connection. We inject a packet 10, right? Here's 10 bytes of data, starting at sequence number 10 to host A. Then what, coming from host B, right? So what's host A gonna do whenever C is that packet? Drop the packet, because it has already gone to packet. No, no, from our packet. So we're gonna roll back again and start from the beginning, right? So they're not talking, A is expecting sequence number 10. B hasn't sent it yet. We send 10 byte packet starting at sequence number 10 to host A, coming from host B, right? What happens when A gets that packet? It'll acknowledge the packet, right? So it's gonna send us zero byte packet. It's gonna acknowledge, it's acknowledgement number's gonna be 20. Say I've read up to sequence byte 19, the next byte I'm expecting is byte 20. It's gonna send that back. So what's the other side gonna do? Send a reset. Yeah, actually it's one of these things. Well, it's kind of weird, right? Now we're acknowledging data that we actually never sent. So we're gonna inject in there, right? And when the receiver of that data we inject, they're gonna acknowledge just like we said and say, hey, great, I've seen up to 20. When the person we just moved gets that, they're actually not gonna reset. They're gonna say, actually I've only sent you up to 10. Like here's an acknowledgement. I'm for sequence number 10. Like I've only sent you up to a 10. And because the receiver gets that and it thinks, well, okay, I'm getting an act for like an earlier packet. So I should send back that, hey, I'm actually at 20, this is what I've received. And then the recipient's gonna get that and this whole cycle's going to keep repeating where they continue to acknowledge each other. Until what happens? Yeah, one packet gets dropped. Right, so it's kind of like one side goes, hey, great, I'm expecting 20. And then the guy goes, I'm only expecting, I only sent 10. And the guy's, no, no, no, I'm expecting 20. No, no, no, I'm expecting 10. Right, so one packet gets dropped and then they're like, that's what I thought. Good. Until they try to send more data or try to do anything else, right, then there'll be a problem. Right, so the problem as we get this is called an act storm where these hosts just continue to act in the cycle of work. Yeah. Okay, you know as the attacker sends something to the other box at the same time, you know, that would get them back in. So send the right message to get them back in sync so it thinks that it's, I think you could. Is there some way to do that? Yes, I think it becomes more difficult. Well, it all depends on how you're getting those sequence numbers. If you're getting it because you're e-straping the conversation, then yeah, you can do that, right. But if it's because you can guess one way is sequence number, you may not be able to guess the other way. So you're never gonna be able to act like you came from the other direction. But yeah, it's possible, it just makes it more difficult in a sense. But it's kind of funny to think about this act storm where you cause this like weird confusion. And so yeah, so anytime they try to send data, they're gonna have this problem. And it's just gonna go into a package problem. And so yeah, so yeah, we could do this as an attacker by, if we're actually man in the middle lane, we can change the sequence numbers as they come across us, right. So that we maintain this fiction that one side thinks it's on 10, the other side thinks it's on 20, and we just change that as it comes back and forth. Or like Eric said, we could fix this by telling one side, oh, that's totally fine. Like don't worry about it. So we can see this, right. So we have the client and the server here. So we're our attacker. So they've already established a connection, right. But it's a quiet connection, nothing's happening. So we're gonna send a TCP packet with sequence number, whatever the client's current sequence number is, with 30 bytes of data. And so then they're gonna act back with that, the sequence number plus 30, and they're gonna act back, hey, I've actually only sent up to sequence number, right, and this key's happening until packets are dropped. And so we can actually use this, like kind of like Eric was alluding to, right. We can use this, not just on one way of the conversation, but we use it on both ways. So that way we can hijack the entire conversation to do what we want. Or, and I think actually somebody mentioned this, right. We could actually try to reset both packets and then make a new connection between them, right, coming through us. Or we could basically impersonate both sides of the connection here, which is very cool. So we can actually see an act storm in action. So here we see two hosts that are DC grant us. We have .10 and .20 to port 23. And so we can see that, let's see. Here's, okay, here's 101, 15, 112, and it's acknowledging that it's received up to that. So that with 21 bytes. So it's expecting 101, 515, 33.10 response back. Actually, I've only sent you up to 112, right. So this first packet is 21 bytes of injected HTTP, I'm sorry, HTTP, injected TCP traffic. And so this continues where they go, no, no, I've seen up to 23, like well, I've sent up to 112 and it just keeps going until finally somebody stops and then it doesn't become a problem anymore. Okay, questions on this? Yeah. Doesn't the act storm extend the attacker's window to as long as he wants until something breaks? He can go on talking to the seller, I mean. Yes, absolutely. So yeah, the part of this, right, so all this relies on is being able to get that sequence number, right. If you can guess the client's sequence number, you can inject data. And once you've done that, now you own that connection, right, and they can never send any data to each other. So you're going to keep sending data, exactly. I don't know if I'd say it elongates the window, but yeah, in a sense, basically as soon as you've done this desync, it's fine for the rest of like, you can continually inject data into the street. When and how does the client and server decide they don't drop the packet? They don't actually decide, it's just, and yeah, at some point the router will get overflowed over, not overrun, but there'll be too much in the router or the link level or something, or there'll be something else going on and it'll just stop. I mean, otherwise it'll just continue. Should be bad, yeah. So does this mean that even if this, because these things are still processes that might be able to do the same demo? Oh yeah, it will process all these packets, right, and respond to them, but it can't actually send any more data because it thinks they're different. Acknowledgment and sequence numbers. It'll try to send out new packets, but when it does, it'll be sending like, no, no, no, I'm expecting different bytes and so they'll be desynced like this. Okay, let's look very briefly before we quick today. I wanna talk about some denial of service attacks in the TCP level and then we'll be able to wrap this up. So a SYN flooding attack is a very common and, or it used to be, I think, more common, but it's a way to do a denial of service attack against the TCP implementation. So what happens, so you're a server, right? You get a SYN packet that comes in. So what do you have to do? What do you reply with first? This is a SYN act and then what are you waiting for? An act back, right? So as the server, where does that state of this maybe half open socket live, right? Because that takes some memory, right? Because you need to remember, okay, on this IP, this port, I got a connection on this port from the four-tubble, right? Source IP, source port, destination IP, destination port. I got a SYN and I sent back a SYN back, a SYN act back and what else do you have to store? You have to store that for, right? You need to know who it is. The sequence number? The sequence number, yeah, you have to send that sequence number that you sent so you know when you get it back if it was the right response. But, so, if we think about it from the attacker's perspective, so the attacker can send one packet, right? How much, when the attacker sends a SYN packet, how much memory do they have to create? They don't have to store anything, right? They can just send a SYN. They wait for that response back, right? But in the meantime, the server doesn't matter. Omega, right, Omega isn't clearly too much, but we've caused the server to generate some memory when we have to generate none for ourselves. All right, so this is what a SYN flooding attack is. You just flood with SYN packets to the server and for each of those SYN packets, the server creates, you know, stores some memory in the kernel in the TCP IP stack, right? And then at some point, and so they respond with a SYN act and we just never say anything, right? We don't close that because what in the TCP stack sends how long they should wait for the act to a SYN act. It says all of a sudden, like I should send a SYN and then you send a SYN act and then I send an act back, right? But the fact of what that timeout is in between, right? How long do you stay waiting? Because it could be the network is busy, right? So for this attack, we overload the memory of the server and cause it to crash just by sending SYN packet. So can we spoof the idea in the SYN? We don't care about those response packets so we can make them come from anywhere, right? Which makes this attack even more tricky. And even if we can't cause it to crash, right? What happens if the TCP IP stack can't allocate any more of these connections, these SYN SYN act? What happens when somebody else tries to connect? Yeah, it'll drop, right? It can't, it can't, if it has a limit and then it's gonna say I can't open this, I'm out of memory or whatever. And so in this way we can cause it to not have a service so that nobody else can talk to this machine, right? So now we're taking this machine off the network. So there's a couple different ways to deal with this. One way is like filtering. So we can try to somehow filter these either by the source IP. Sometimes the source IP will be constant so it's trivial to filter. We can use more memory, right? We can just say increase the length here. We can reduce the timeout, right? And say that, okay, let's time out our connections. We can cause like a, some sort of queuing system for our half open connections. So when we get new ones and we're at a limit we can drop old ones out, right? So we have this, so they're not staying open for a long time. We can limit half open connections coming from a certain, you know, we can put per IP, source IP limits. The other one we can do is we can use SYN cookies, which are actually super cool, which we're gonna go over very briefly. So the idea of a SYN cookie is instead of me allocating memory on the server about what connection was, what the sequence number was, I can actually code that information in the sequence number that I send to you. So that way when I did it back, I can verify that this actually came from me at an earlier time and it's a valid sequence number. So it's really cool. So the idea is, and we won't go into the details, but the idea is we're gonna have a counter that increases, right, that's gonna change so we'll get different sequence numbers here. And then we're gonna encode the, the specifics aren't really important. But the idea is we're gonna use a hash of our counter and the source destination IP addresses and ports, right? So this is the four top, right? The source IP, source port, destination IP, destination port, we're gonna use that in the sequence number along with this counter so that that way when we get an ACK back, right? We don't know anything about this connection, right? We have not stored any state about this SYN SYN ACK. But I can use this sequence number, I can use the source IP, the source port, the destination IP, the destination port, plus this counter T, which is random and the, or random in that the attacker can't guess it, right? I can use that, I can hash all these to see if this actually came from me at an earlier time without knowing or storing any state. So if you enable this, you send back a SYN ACK as if you made a new connection, right? You don't actually make any new connection. You don't actually store any new state on your server. So when you receive an ACK, right? That's to start a new connection. You check that function and you see, hey, did this come from me? Is this from one of the Ts that I originally used this counter? Then it rebuilds this, rebuilds the original SYN packet from that, but, well, that's, I don't really think. Yeah, so it's kind of, it can be a pain. I think some websites actually do use this. It's a setting that you can enable in like your kernel. But it goes to kind of a general class of like state attacks, right? So if it can be the case, so if to cause you, your kernel to store one megabyte of memory, if it costs me a megabyte of memory, it's not really a denial of service attack, right? Because you have to have as much memory as me, which maybe in a distributed botnet setting is a problem, but in this case for like Amazon or big company, right? They can buy a lot of memory. But if it takes zero memory for you to cause me to store one meg, now that's where you have that leverage, right? Where you can just force me to create and allocate all this memory and then run out of memory. So this is what, there's a bunch of other denial of service types of attacks that take advantage of this. So they can do, you know, they can do the SYN SYN act and then not say anything, right? And just have these dummy connections that just store state in the kernel. They can try to overload the process, like how the process limit or the thread limit of your operating system or of your web server. They can send you, yeah, so this is a tricky one. So if you, right, so if they are sending you data, but you're not acknowledging it, they have to still buffer that data in case they have to retransmit it to you. So I can make your kernel store a lot more data that it's normally used to by never acknowledging all the data that it sends and continually making these connections. So I drop all the data on the floor, but you still have to keep it in your buffer listening. So there's a lot of these kinds of attacks. So network insecurity, because I really don't want to do this today. So the idea is, right, the network is important because this is how we get into the computers, right? I mean, the nodes, the systems are talking to each other, right? This is how, as an attacker, we're able to influence and get into the systems on the computer. And I think it's really important. One of the things I've tried to harp on, I really want you to get to think about is to understand what's trusted and what's not trusted, right? So by studying the IP stack, we saw, hey, the source IP isn't validated or trusted, you know, is not validated by anyone. So anyone should send an IP packet with a source of anybody else's IP address, right? So we can't trust that because an attacker can control that, right? And that's kind of one of the key ideas here. By looking at networking, you can see what an impact that has this really small thing in this networking protocol, how big of an impact that has for security. We saw how we can, we're building up, building blocks to attacks, right? So we looked at snipping, like how we can see things on the network, spoofing, how we can pretend to be other people, hijacking, taking advantage of a connection. We saw some denial of service attacks, right? So we can, which are attacks in their own right and also help us do some of these other attacks, right? So these denial of service attacks are important because we can leverage them to do other types of attack. We saw we could probably brute force some of the sequence numbers pretty easily if it's not very randomly generated. And then we looked at some tools and we talked about some countermeasures, so. Thanks for being patient today, I appreciate that.