SRX

Expand all | Collapse all

Block SYN packets on existing sessions

Jump to Best Answer
  • 1.  Block SYN packets on existing sessions

    Posted 09-06-2018 09:07

    I have a Pulse Secure SSLVPN behind my Juniper SRX240 and I'm trying to figure out how to block SYN packets on existing sessions as described in this KB article from Pulse Secure. Can anyone clue me in on how to do this?

     

    https://kb.pulsesecure.net/articles/Pulse_Secure_Article/KB40346



  • 2.  RE: Block SYN packets on existing sessions
    Best Answer

    Posted 09-06-2018 18:52

    Hi , syn-check and sequence-check  is enabled by default. 

    You can disable it via

    set security flow tcp-session no-syn-check
    set security flow tcp-session no-sequence-check
    

     



  • 3.  RE: Block SYN packets on existing sessions

     
    Posted 09-06-2018 22:19

    Configuring these options will make the SRX as good as a stateless device and it is more vulnerable.

    Not sure how this will prevent SRX from dropping the unwanted SYN packet, I belive with these options SRX will accept the SYN

     

    To block the SYN attack as described in the document you have shared you may need SYN-Flood screen, please check below documents.

     

    https://www.juniper.net/documentation/en_US/junos-cc15.1/topics/reference/general/15.1x49-d60/configuring-tcp-syn-flood-attack.html

    https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/security-edit-syn-flood-protection-mode.html



  • 4.  RE: Block SYN packets on existing sessions

    Posted 09-07-2018 00:42

    As already mentioned , this option (block syn packets ) is enabled by default , and you do not need to configure anything 



  • 5.  RE: Block SYN packets on existing sessions

    Posted 09-12-2018 00:45

    Hi Joshua

     

    The article mentions that the attackers will inject TCP SYN or RST messages, on ongoing TCP connections, that will look as legitimate packets from those TCP streams (including sequence numbers becuase they were already guessed by the attackers.)

     

    If this is the case, if the attacker sends a RST, the SRX will reset the connection and close the TCP session becasue it looks like a legitimate RST message from the source. Now, If the attacker sends a SYN message, the SRX will notice that there is an already exisiting session that matches the characteristics of this packet and will drop the new packet becuase this packet is trying to create a new session but there is already an ongoing one.

     

    I believe the TCP checks mentioned in above posts are for different scenarios.