Very good tutorial, but it took me 3-4 times to rewatch to understand the concept. Is there any source for implementation, would be wonderful if you share. Thanks!
So, basically, the server get's rid of the state table, and therefore it saves disk or RAM space, but it still has a port open. And also to correctly compute the 's'-value, it needs some space to keep track of 't'-value and associated client (either via port number, or IP address). Since SYN flood attack is about keeping open ports in a waiting mode, I don't really understand, how that problem can be solved with this. Could you please specify this a bit in more details? Thanks in advance!
So that closes the problem of storing the TCP SYN table, but opens a whole new can of worms. Now you just spam the server with illegitimate or maybe even legitamate SYN ACK and it dies recalculating values from those. Or is that protected from that somehow?
How would you configure the syn cookies. Ive searched this on google but Im slightly confused. Am I suppose to open up the command prompt and type in the information Router>enable idk!!!! I guess im frustrated because I was gaming and pissed someone off who continues to boot me. If you could help me in this it would be greatly appreciated
You fail to explain well, if at all, how you recompute s. s is computed. You mentioned that you compute s from n. No you don't. You still need to keep some sort of state which is the server IP, server Port, client IP, and client Port on the server side. If you don't, someone could send a n + 1 and you'd get back n and bam spoofed. Just because you have an encrypted s, doesn't mean you can reconstruct it with itself. That doesn't make any sense. Fix that part and this video is good.
Musique.com I'm sorry. It's my bad. When a connection comes in, you can read directly from the packet the client port and client ip. You know your own server ip and server port you're listening on and can thus compute s because the t is sent along with it. My bad.
Very good tutorial, but it took me 3-4 times to rewatch to understand the concept. Is there any source for implementation, would be wonderful if you share. Thanks!
So, basically, the server get's rid of the state table, and therefore it saves disk or RAM space, but it still has a port open. And also to correctly compute the 's'-value, it needs some space to keep track of 't'-value and associated client (either via port number, or IP address). Since SYN flood attack is about keeping open ports in a waiting mode, I don't really understand, how that problem can be solved with this. Could you please specify this a bit in more details? Thanks in advance!
I see, firewall sets the RST or reset, it closes it for protection.
I think the server closes the connection after it saves the state in SYN Cookie. This frees up the TCP stack that resides in memory.
What happens if the t is missing in the hashKey?
Is the "t" stored on server and is used later to compute "s" when it gets the ACK?
I think 't' is used to valid whether the 'ACK' is too old to accept by comparing it to the current timestamp.
So that closes the problem of storing the TCP SYN table, but opens a whole new can of worms. Now you just spam the server with illegitimate or maybe even legitamate SYN ACK and it dies recalculating values from those. Or is that protected from that somehow?
I think there mechanism where the first packet from session must always be "syn" packet.
@@waedtttret how?
The value t is also included in the s.
How would you configure the syn cookies. Ive searched this on google but Im slightly confused. Am I suppose to open up the command prompt and type in the information Router>enable idk!!!! I guess im frustrated because I was gaming and pissed someone off who continues to boot me. If you could help me in this it would be greatly appreciated
etherealmind.com/tcp-syn-cookies-ddos-defence/
You fail to explain well, if at all, how you recompute s. s is computed. You mentioned that you compute s from n. No you don't. You still need to keep some sort of state which is the server IP, server Port, client IP, and client Port on the server side. If you don't, someone could send a n + 1 and you'd get back n and bam spoofed. Just because you have an encrypted s, doesn't mean you can reconstruct it with itself. That doesn't make any sense. Fix that part and this video is good.
Musique.com I'm sorry. It's my bad. When a connection comes in, you can read directly from the packet the client port and client ip. You know your own server ip and server port you're listening on and can thus compute s because the t is sent along with it. My bad.
Listen properly kiddo :P
so much theory and not even a single command, glad i did not waste time on this theoretical bullshit