Forum Discussion

g1_253413's avatar
g1_253413
Icon for Nimbostratus rankNimbostratus
Apr 09, 2018

Vulnerability scan lists all ip's and port as open

Vulnerability scan on subnets behind F5 lists all ip's and ports as open. We use the Big ip as LTM currently running 13.1.0.2. Security team started seeing these results right around when we upgraded...
application delivery
LTM
Jacqueline_Tadr's avatar
Jacqueline_Tadr
Icon for Altocumulus rankAltocumulus
Jun 07, 2021

Thank you for your response jba. I can see that my case if different. First we do scan from the Internet. Then the pcap doesn't show the whole 3 hand shake process and the F5 front end receives only the ACK then the RST packets. I'm not an expert on the Big IP but I get the understanding that another device in the uplink path is intercepting the traffic then send to the F5 the RST packet. I wonder if this is possible at all? Only profile used on the front end is the ssl profile and the tcp profile. This issue starting happening while we had the image 14.1.2.6 on the i58000. Trying to figure out why is a packet destined to a VS IP on the front end give faulty open ports without touching the F5 interface except by 2 packets only an ACK and a RST. It doesn't go through anything at all, neither the sec policies nor anything. This Virtual server works fine however for normal traffic,

  • Simon_Blakely's avatar
    Simon_Blakely
    Icon for Employee rankEmployee
    Jun 07, 2021

    Jacqueline,

     

    Again - the answer is SYN Cookie protection.

     

    Your TCPdump is only showing packets that reach tmm, and SYN Cookie protection occurs in hardware (there are also software SYN Cookies, but we will treat them as the same).

     

    When the BigIP starts performing SYN Cookies, the hardware switch on the BigIP starts handling SYN packets. It responds to the SYN with a SYN,ACK that has some special information encoded in the SYN,ACK, and then it forgets about the SYN - it does not track the SYN or open a pending connection. This saves memory. If it gets an ACK back from a proper TCP stack containing that special information, then it uses the special information to reconstruct the handshake and open the connection. The ACK then gets passed to tmm as the first packet of the connection.

     

    So when you see a connection in tmm that starts with an ACK, that probably indicates that the device is protecting the virtual IP (or entire device) with SynCookie protection. You can only see the full SynCookie three-way handshake by collecting packets on the physical interface (which is rate limited to 200 packets per second).

     

    Some versions of BigIP have more sensitive thresholds to enabling SynCookies, and there are some bug IDs relating to devices not disabling SynCookies after a SYN flood has passed, so that connections are always handled by SynCookies.

     

    But SynCookies will always make it appear as if a port is available even if there is no actual listener for that port due to the SynCookie challenge.