Vulnerability scan on subnets behind F5 lists all ip's and ports as open. We use the Big ip as LTM currently running 220.127.116.11. 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 ?
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.
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.
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].
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, 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.
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,
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.
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 18.104.22.168 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,
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.