Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Answers

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 ?

0
Rate this Question

Answers to this Question

placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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.

1
Comments on this Answer
Comment made 4 months ago by Jeff Allen 250

The VS is a Performance L4/IP Forwarding. We disabled Hardware SynCookie Protection last week based on an article that mentioned this setting was not compatible with TCP Loose Init/Close. We honestly thought we had this figured out and now we aren't sure we truly have made a difference. While we didn't have Production impact during the scan we still observed higher connection counts on the Forwarding VS and thousands of more assets than previously on the 3900 hardware before we shut the scan down. Not sure if it matters or not, but we are running vCMP Guest on the i5800s.

Are reviewing the article you shared, I see that pvasyncookies.enabled is enabled globally; however as mentioned above it is disabled for the Forwarding VS's fastl4 profile. I do see that this is enabled on the tcp profile applied to our VIPs; however, I wouldn't see these responding to SYN requests for different destinations than what we have configured. As mentioned in the first post, all the responses we see in the discovery asset list are IPs that would fall within the /19 in which our External VLAN and Self IPs reside which has us puzzled. One final note that I'd like to share. When we scan smaller subnets, say a /24 we don't seem to see the issue as noted by our scan engineer; however we def. see the behavior with larger scans, say /23 or /22 which almost leads me to believe that Syn Cookie protection is still somehow enabled. I don't know if this is because there is an active connection that is persisting and therefore the new logic hasn't applied or if we need to cycle the guest to ensure all connections are cleared out. At a complete loss at this point.

/jeff

0
Comment made 2 months ago by Jeff Allen 250

I wanted to follow up on this one. This turned out to be Hardware SYN Cookie Protection on the Fastl4 profile applied to our Wildcard Forwarding VS. We still observed higher (740,000+ connections) than previous connection counts on the new hardware; however after setting this to Disable Challenges it stopped responding to the scanner with TCP RST, which is what made it believe there were more hosts alive on the network. Above I mentioned we thought we had this issue resolved and then we had another problem. It turned out when we upgraded from 12.1.2 HF2 to 13.1.0.8 it reverted our settings back to default, hence why I thought we had not truly resolved anything.

/jeff

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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

0
Comments on this Answer
Comment made 10-Apr-2018 by g1 1

No ciphers were changed during the upgrade

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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.

0
Comments on this Answer
Comment made 10-Apr-2018 by g1 1

We do have wildcard ip forwarding servers using SNAT pool for outbound internet traffic. Let me know what i should modify/change on the wildcard vip.

No particular ports, it seems like the whole range.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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?

0
Comments on this Answer
Comment made 2 months ago by Jeff Allen 250

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.

0