I'm having a bit of a headache with this one,
We are building a firewall to serve as a SYN flood mitigation tool, and are employing the SYN cookies mechanism to do so. If you aren't familiar with SYN cookies, it changes the TCP process to something like:
1) Firewall receives SYN not matching authenticated flow, does not forward this SYN into end device, but sends SYN-ACK back to source host of the SYN packet with sequence number set as 'cookie'.
2) Legitimate host replies to SYN-ACK with ACK number set to previous packet's sequence + 1, in this case our 'cookie'. We authenticate this information (this is a stateless check as info can be encoded into the cookie) and begin to reconstruct the TCP handshake on the end device. We send a SYN packet into the end device matching the sequence number of the first packet we received, catch the SYN-ACK response and respond with our own ACK (legitimate host trying to connect has still not seen any actual traffic from end device behind firewall).
3) After sending our last ACK, we unlock both connections and let packets matching the authenticated flow pass through. Instantly the legitimate host gets a "TCP Spruious transmission" as wireshark calls it, the sequence number in the response is completely out of line with what it is expecting.
4) Legitimate host keeps re-transmitting ACK packet that was in response to SYN-ACK challenge packet because it has yet to get any valid response, if the end device gets this ACK, it also does not line up with any of it's criteria, it keeps re-transmitting it's ACK that does not match up on legitimate host, and it repeats.
So the problem becomes, by authenticating a connection and needing to then re-establish a TCP connection on one side, the sequence number gets modified on the end device from our SYN cookie, to whatever random number out of 1 through 4 billion it picks. How can it then be re-established?
This same concept is offered of many security switching platforms, here are the Juniper docs behind this concept: https://www.juniper.net/documentation/en_US/junos/topics/concept/denial-of-service-network-syn-cookie-protection-understanding.html
They have a nice illustration that says "Send ACK to both ends", in our implementation, only 1 ACK is being sent into the end device, perhaps I am missing another one to the legitimate host that can somehow make the flows sequences line up? I've thought about this and can't see how it can be used to modify the connection info to make the 2 line up, but there doesn't seem to be any other way? Any help would be appreciated.
No comments:
Post a Comment