Denial of Service Attacks (Part 3): TCP SYN Flooding

typically whenever you have two parties who want to communicate over the internet they use a protocol known as tcp/ip and as part of tcp/ip they have to engage in what's called the TCP three-way handshake three-way handshake and this is this video I'll tell you about how that works and I'll talk a bit about how one could mount an analysis attack on this three-way antics and it begin with let's say you have two parties and we typically think of them as a client and let's say the client wants to communicate with a server and they're communicating somehow over the Internet so there is kind of the internet in the middle I think this is the big Internet right here and you want to communicate with each other and the way that works is the client begins and initiates by sending a request to the server to request to initiate a connection this request is typically known it's there's a message involved that message is typically called a syn message okay and this is basically the client indicating to the server that it wants to connect it's basically a message of intent of some sort and in this case sin actually stands for for synchronized stands for synchronized okay and the server basically will respond back assuming it wants to communicate with this particular client it responds back with a syn ACK message and in this case the app is part of syn ACK stands for acknowledge so basically it's telling the client that it acknowledges that the client wants to connect that it's basically offering an opportunity to complete the connection and the client in turn sends back a response if it if it's a roof confirm and gets intent with the initial syn packet it sends back an ACK as a response there's basically the flow is syn syn ACK and then a can again accurate stands for acknowledge and once these three messages and have been passed back and forth the connection between the client and server is effectively established this is kind of what establishes the connection so connection is established at this point the connection is established okay and it turns out this approach as I mentioned earlier is subject to a pretty well-known denial of service attack and that a Dallas Otis attack is called a syn flood and as a name suggests the attack works by having the client send different Sigma sages to the server however the key is into this particular attack because the client will not respond back with an ACK and let's think about what's going to happen so whenever a syn message is sent from a client to a server each time the server receives a syn request it has to basically allocate some space so it's going to have a little space table or state table rather and it's basically going to allocate some information in this table associated with this sin request so basically it has to maintain this entry in this table and you might want to pause the video for a moment and think about why the server even needs to maintain any kind of state in the first place and the short answer here is that the server needs to allocate resources so that when the final act message is sent when this particular message is sent that message can be then identified with the original sin message and therefore these three messages together will be tied together as part of one transaction between a particular client a particular server really by transaction in a particular session and when you consider the fact that in real life you may have a server that's accepting many different syn messages for many clients it has to be able to keep track of who is receiving messages from and it needs to maintain this date table to be able to keep track of these messages appropriately okay now at this point when the syn message is sent from a client to a server and the server allocates space at this point prior to what is this ACK message is sent let's let's kind of call this point one at point one we have what's called a half-open connection a half-open connection between the client and server okay and at this point it stays in this half open state until the final act message is sent and once the ACK messages is received from the by the server from the client then it becomes regular connection so basically the half-open nature of the connection zone there is a regular connection between the clients service a fully open connection if you will okay now um you know I think what's interesting here is that if you start to send if the server start to receive many different send messages it's going to start allocating a lot of space for those syn messages and if it never receives back and act message it's going to just keep that space available for some period of time and so the idea is when you actually receive the final act the server can then D allocate the space and start using it for other purposes but if it doesn't receive an act message it's going to just keep allocating space now to make matters worse it turns out that in the Internet Protocol or IP the client can actually provide and normally what happened to these messages is the client is part of a syn message includes in the packet it'll include a copy of its IP address so it'll send sent a copy of its IP address now in in a legitimate use case if somebody was a legitimate client it'd be sending their actual IP address which is their kind of location on the Internet but if we're dealing with the case where somebody's trying to mount a denial of service attack they may not send back the real IP address they may actually only send kind of a fake IP address a forged IP address if it turns out that you can what's called spoof said the term that we typically use it's proofing an IP address is where you provide a fake IP address this is something that actually can be done on the inert today there's no way to the Internet Protocol itself has no way to kind of prevent IP spoofing in in effect where IP spoofing does is it provides to the server a fake location for where the client is and in this case not only will the the connection you know never complete obviously if the server receives a fake IP address it might be sending back this syn ACK to some other client somewhere on the internet doesn't even know what it's talking to you because it's not going to be talking back to the real client because it's going to think the real client or the client that it's talking to is located at this fake IP address and what it sends some that IP address the system if this address is well I don't really send the sim packet so it's probably just going to ignore the sit ack and not only will this will having a the IP address or spoofed IP address cause the server never to respond back to the client in an appropriate fashion in this case is also no way for the server to actually tell who really initiated the connection and so the server's basically going to do is it's going to keep allocating space with these half-open connections and gradually that space is just going to get all filled up there soon they'll be just no more space left and when the state space is filled up what that means is now if there's a legitimate request imagine there's a legitimate client right here if the legitimate client sends a request a syn request then it's going to basically say tender send requests to this to the server the server could have know where to allocate information about the syn requests basically it's going to drop your request until legitimate clients are not going to be able to to be able to respond to requests once they've filled up their state space or even worse it in some cases depending on the implementation you know some servers might actually crash once they've used up all like they may have no more room left no just will just effectively die and so you know these are obviously legitimate concerns and in either case what's happening is there's a denial of service attack and this is the TCP syn flood I should I should be clear is a denial of service attack it prevents legitimate parties from gaining access to a very important service and this attack it's very much a classic attack and there are not some countermeasures in place for dealing with it but the reason that I wanted to mention it is in part that that many novice service attacks try to leverage a situation in which a server has to maintain state of some sort and allocate memory for that state and also a log denial of service attack to involve the notion of spoofing an IP address and so I thought that by kind of understanding these particular elements of denial of service attacks you may be able to recognize some alternate situations and protocols in which similar attacks can be mounted

Channel: Sourcefire

Views: 54,817

Rating: 4.9441538 out of 5

Keywords: dos attack, ddos attack, denial of service, tcp syn flooding, tcp flooding, ddos

Id: sUrM7_G_y7A

Length: 8min 51sec (531 seconds)

Published: Tue Apr 02 2013