cancel
Showing results for 
Search instead for 
Did you mean: 

HTTP TRACE behavior question

Jimmy_L
Altostratus
Altostratus

For security purposes, we need to ensure that an HTTP OPTIONS request does not return TRACE or other "potentially risky" HTTP options as identified by an NMAP scan (https://nmap.org/nsedoc/scripts/http-methods.html). My understanding is that NMAP sends HTTP requests to obtain this info, which will normally be proxied to the back end server, and that the best solution is to disable these HTTP methods on the back end server. If that isn't possible, we can intercept the requests and block them via ASM policy, HTTP profile configuration, or iRule, per https://support.f5.com/csp/article/K85840901.

 

In our case, we're having trouble getting this done on the back end server, so I'm looking into doing it on F5. I'm finding though, that some of my existing VIPs do NOT return TRACE when scanned with NMAP even though the servers DO have it enabled, and at least one other VIP DOES return TRACE when scanned. It seems like F5 is somehow blocking the requests on some VIPs, even though no ASM policy is applied, the HTTP client profiles are identical, and no iRules or LTM policies are applied. So either I'm missing something about how F5 is working, or there's something we're missing about the IIS8 configuration of our servers that is different.

 

Any ideas? Am I understanding things correctly, with the server normally the one that would respond to the HTTP requests generated by the NMAP scan, not the F5 unless it's explicitly configured to do so? I'll personally mail a delicious snack to anyone who can help.

1 REPLY 1

Jimmy_L
Altostratus
Altostratus

UPDATE: I figured it out. To clarify, I was never asking HOW to block these insecure HTTP methods on F5, I was asking why scanning two VIPs that had identical HTTP profiles, security settings, and no iRules or policies would return different results.

 

The answer is that I had a local hosts file entry that defined a name for one of the IPs of the VIPs and not the other, which changed the behavior of the NMAP scan and the service on the back end server that responded to its HTTP probes.

 

Thanks to all that read and contributed, but I'm keeping my delicious snack for myself sorry!