SRX

What are the drawbacks with turning off TCP SYN checking? Also, does it affect the operation of Screens in any way?

Thanks!

Screens are separate from the tcp check.

Turning off tcp check means your network has asymmetrical routing.  Always the best solution is to restore symmetry through the firewall.  This also means you need to find the second path make sure that also has the appropriate firewall to protect the flow.

Asymmetrical routing means only have of the traffic, one direction of the flow from the two hosts, is transiting the firewall.  This means all of the deep inspection features of a NGFW are pretty much broken.  App-id, url filtering and deep inspection for threats rely on being able to see the content inside a flow.  When half the data is missing they won't work reliably.

Thanks for the response spuluka. I'm more looking for the drawbacks of turning off SYN checking. The security risks of turning off just SYN checking. I have configured routing so that it's not asymmetrical, but a failure to a secondary firewall means all TCP applications will need to re-initiate. Turning off TCP SYN checking will solve the issue, but outside of footprinting, what are the real dangers of turning off TCP SYN checking?

Outside of these two things, are there any other dangers to turning SYN checking off:

• Reconnaissance Holes—...
• Session Table Floods—...

Details found here: https://www.juniper.net/documentation/en_US/junos/topics/concept/reconnaissance-deterrence-attack-evasion-tcp-syn-check-understanding.html

Pevangelista,

TCP Syn check basically ensures 3-way handshake taken place before allowing traffic to pass.

The risk you take by turning off TCP SYN, is that you're basically allowing partial TCP connection, that can potenially  lead to many type(s) of DoS attack.  An attacker's incoming SYNs floods is an attemp choke the hosts kernal memory, and eventually to fill up TCB (transmission control block) that contributes to other delays in network to establish TCP session on target host device.

Also, as pointed out in the following document:

https://www.juniper.net/documentation/en_US/junos/topics/concept/reconnaissance-deterrence-attack-evasion-tcp-syn-check-understanding.html

Session Table Floods—If SYN checking is disabled, an attacker can bypass the Junos OS SYN flood protection feature by flooding a protected network with a barrage of TCP segments that have non-SYN flags set. Although the targeted hosts drop the packets—and possibly send TCP RST segments in reply—such a flood can fill up the session table of the Juniper Networks device. When the session table is full, the device cannot process new sessions for legitimate traffic.

And for failure to a secondary firewall, the following KB & doc can help:

Configuring TCP SYN Check options on a per policy basis:

https://kb.juniper.net/InfoCenter/index?page=content&id=KB21266&actp=METADATA

How to selectively disable TCP SYN or Sequence checking:

https://kb.juniper.net/InfoCenter/index?page=content&id=KB25094

[KUDOS! If you think I earned it!
If this solution worked for you please flag my post as an "Accepted Solution" so others can benefit..]

Regards,

Karan Dhanak

So if I didn't have SYN flood protection configured and that's an accepted risk, disabling TCP SYN checking doesn't create more risks?

Doesn't create "More Risk" per say..Why wouldn't it?..SYN floods can create pretty serious damage. Turning the SYN check off would be like welcoming more vulnerability in the network unless the your network's TCP/IP stack is harden enough that's backed by setting firewall filtering rules/polices and other security element in network to defend the flood.

Regards,

Karan Dhanak