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 from 12.x to 13.x. It might be a coincidence. Did packet captures and the F5 responds to a SYN with SYN ACK, scanner doesn't respond with a ACK and also no RST from the F5, so scanner marks the ip and port as alive but its a false positive. Is there a way to change the F5 behavior or whitelist the scanner ip's ?

 

application delivery
LTM
  • Nath's avatar
    Nath
    Icon for Cirrostratus rankCirrostratus
    Apr 10, 2018

    Have you check the sshd and httpd configuration? Kindly validate if there are ciphers changed during the upgrade.

     

  • Surgeon's avatar
    Surgeon
    Ret. Employee
    Apr 10, 2018

    which ports you are getting response on? Which interface you are getting response on? Is it self-ip or mgmt?

     

    Do you have any wildcard vip e.g 0.0.0.0:* , or subnet vip e.g. 192.168.0.0/24:*? If yes then you need to review your config.

     

  • jba3126's avatar
    jba3126
    Icon for Cirrus rankCirrus
    Oct 21, 2018

    We are having the same issue. What was the resolution? In our case it appears that the F5 is responding to our nmap discovery requests for all IPs and lower 1000 tcp requests that the scanner sends. Example, the outside/external interface/VLAN has a 10.10.64.253/19. One of the asstests that responded was a 10.10.80.0 which is not define. We have a wildcard VS and the scanner is on the inside interface/VLAN. The F5 is the layer 3 bridge between the inside and outside VRF on our core so to get to this IP, routing would carry the scan traffic to this IP via Distribution Switch -> Core SW Inside VRF -> F5 Inside/Outside Int -> Core Sw Outside VRF. Both the SVI on the Core and F5 External VLAN are in the /19. In our case we didn’t have this issue until we went from 3900s to i5800s with vCMP.

     

  • Simon_Blakely's avatar
    Simon_Blakely
    Icon for Employee rankEmployee
    Oct 21, 2018

    Jeff,

     

    What sort of virtual is the Wildcard virtual (standard or Performance Layer 4/IP Forwarding)?

     

    Does the tcp profile enable SynCookie protection?

     

    When SynCookies protection kicks in, even a fastl4 will respond to the [SYN] with a [SYN,ACK].

     

    K14779: Overview of BIG-IP SYN cookie protection (11.3.x - 12.x)

     

    If you are running a network range port scan, the virtual will see (and cache) a large number of [SYN] packets, with no corresponding [SYN,ACK]. Once the SYN cookie cache value is exceeded, the LTM will start responding to [SYN] packates with a [SYN,ACK] containing a syncookie.

     

    This behavioural change may trigger false positive results in the network scanner.

     

    The observed change probably relates to functional differences in the hardware platforms and default trigger values.

     

  • Markie_Parkie_1's avatar
    Markie_Parkie_1
    Icon for Nimbostratus rankNimbostratus
    Jan 09, 2019

    Guessing you have only the one port set on the forwarding VS that the clients are configured to go to and you are using explicit proxy?

     

    • jba3126's avatar
      jba3126
      Icon for Cirrus rankCirrus
      Jan 09, 2019

      Markie Parkie, This was/is a wildcard VS so it listens for all IPs/Ports. We had this same setting on our 3900s with no issues; however when we went to vCMP Guests on i5800s we started seeing these issues. Above describes the article we used to resolve this. The only caveat is to watch for this issue to crop up after upgrades.

       

  • Jacqueline_Tadr's avatar
    Jacqueline_Tadr
    Icon for Altocumulus rankAltocumulus
    Jun 07, 2021

    I have the same issue when we scan for open ports from the internet destined to one of the virtual servers IP on the front end of the load-balancer. we upgraded to 14.1.4 when this started happening again after the fix. pcap doesn't show any SYN or SYN/ACK packets but only ACK then followed by RST. It doesn't even go through for the 443 allow. I'm trying to understand from the answers above but can't grasp the whole picture. Also some say scanning is to the internal servers on the backend. Can anyone share the whole document/explanation? This False Positive creates concerns to security,

     

    • jba3126's avatar
      jba3126
      Icon for Cirrus rankCirrus
      Jun 07, 2021

       for us, it was an internal scan, not an external scan. What happened was we had SYN Cookie protection enabled on the profile for our Forwarding VS. This caused the F5 to challenge the SYNs from Discovery scans even though these IPs in some cases didn't even exist behind the F5 making the scanner tee these IP and Ports up for actual vulnerability checks. To top this off the F5 was trying to deal as it was a DoS attack and began consuming memory until it finally fell over. We disabled SYN Challenge Handling in the Fastl4 profile and this fixed our issue. Make sure that you don't have this enabled on your VIP and VLAN as it could do the same.

       

      /jba

  • 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.