SRX

Hello everyone,

I'm preparing for JNCIS-SEC exam and I was reading about SYN cookies.

When SYN cookie is enabled on Junos OS and becomes the TCP-negotiating proxy for the destination server, it replies to each incoming SYN segment with a SYN/ACK containing an encrypted cookie as its initial sequence number (ISN). The cookie is an MD5 hash of the original source address and port number, destination address and port number, and ISN from the original SYN packet. After sending the cookie, Junos OS drops the original SYN packet and deletes the calculated cookie from memory. If there is no response to the packet containing the cookie, the attack is noted as an active SYN attack and is effectively stopped.

I can't figure out why an attacker won't be able to send an ack with the cookie+ 1 as a sequence number if he receives the SYN/ACK packet from the firewall. Am I missing something?

Normally SYN flood attack will be using spoofed source ip addresses. Attacker simply send thousands of SYN packets to the target server using spoofed or non-existent source ip addresses and will not respond to the SYN/ACK packets coming from the target(server/SRX). This causes resource starvation in target server /SRX becuase it has to store the half open connection information.  

In case of SYN Cookie, SRX won’t record any state of the connection, in case the SYN is spoofed. Instead, it will send the SYN/ACK back toward the client with syn cookie. If it was spoofed, the client will either drop the SYN or send a reset, but won’t process the packet.  If the client (attacker) is real, it will respond with its ACK using the sequence number provided by the server. If the sequence number doesn’t match what is expected, then the SRX will not process the connection.
Essentially, this ensures that the client is real and not spoofed (assuming that the attacker isn’t in the same path) so that a host can’t do a massive spoofed SYN flood, and at the same time we can validate that the client is real.
After the client has completed the three-way handshake, then the SRX will open the connection to the destination server.

Reference: https://www.oreilly.com/library/view/juniper-srx-series/9781449339029/ch11.html  Section: SYN flood/spoofing attacks

I do understand when the IP is spoofed or forged, but when the attacker IP is real using a syn-ack-ack proxy will do the same as syn-cookie right?  Using SYN-Cookie won't save the resouces from being reserved for the attacker session.

You are right, but now we know the attacker real ip address and do necessary action (legal or block the ip permanently) and using real ip address for attack is not effective as spoofed ip addresses (Difficult to block as source ip will change continuously). Normally SYN flood attack will be used by many spoofed ip addresses (like DDoS) and attacker will not reveal his real ip address / identity.

SYN-ACK-ACK comes into picture where a 3-way handshake is complete and the theshold configured is for a single source IP. Even after the handshake is complete, if the attacker continues sending SYN-ACK is where this screen option increases its counter for the same source IP.

Whereas, SYN-Cookie is used in case of a SYN Flood from from multiple spoofed IP's at the same time creating half-open connections where the attacker does not respond with SYN-ACK. Here, using SYN-Cookie mechanism saves the memory from utilized by the half-open connections otherwise.

Eventually all the screen options do the same job of protecting the internal servers or the firewalls from ddos attacks but with various patterns. SYN-Cookie from SYN flood creating half open connections and SYN-ACK-ACK form fully established connections followed by SYN-ACK's instead of data.

Hope this helps.

Regards,

Pradeep.

@pradkm is it possible to enable both screen options at the same time (syn-ack-ack-proxy and syn-cookie)? 

Yes it is possible.

Regards,

Pradeep.