- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
04-21-2019 12:57 PM
Recently I have noticed a jump in detections of Suspicious HTTP Evasion Found and Suspicious TLS Evasion Found going to genuine website such as eBay, Amazon, Apple etc. The firewall is setup as a DNS proxy that forwards on to PiHole and then out to a public DNS and as far as I can see I have nothing setup incorrectly.
Does anyone here have any ideas what may be casuing this?
Thanks.
04-25-2019 12:09 PM
It's normal, support will likely direct you to disable the alerts if it bothers you. The evasion detection is prone to false positives because it is a very simple check. I had to dig, but found it from the 7.1 New Features Guide:
Setting up this evasion prevention feature enables the firewall to check that the hostname or SNI indicated in an initial HTTP or TLS request corresponds to the destination IP address for the connecting client.
The problem is that if the firewall's DNS query for the hostname/SNI happens to get a different address, this signature will trigger even if it is a valid address.
Personally, I've disabled the logging for those two signatures by setting them to "allow" instead of alert or higher:
04-21-2019 08:14 PM
Have you been running the DNS proxy through your PiHole for a while now, or was this something that you just configured and then starting seeing this behavior?
04-22-2019 03:43 AM - edited 04-22-2019 05:02 AM
Hi,
Thanks for the quick reply.
Good question, I used to have it pointing at a DC then that would go to PiHole but I recently changed it to point to PiHole directly as the cleints behind this VWire didn’t need to resolved my internal hostnames.
Do do you think it’s related to the PiHole blocking parts of the sites?
thanks
04-22-2019 12:53 PM
I just deployed a 3220 in tap mode and have quite a few logs of both TLS and "Suspicious HTTP Evasion Found" threat logs going to legit sites as well (Such as O365.)
This deployment is actually down stream from another upstream FW which also sees this O365 traffic and I'm not seeing the same threat alert logs in the upstream FW.
So I'm thinking the reason the down stream 3220 is throwing these alerts in how the data is coming to the FW via the tap.
tl;dr -- Like me the reason I think you're seeing this alert is how the data is being seen by the FW and not necessarily the threat actually occurring.
04-22-2019 02:07 PM - edited 04-22-2019 02:14 PM
Interesting.
I would think your TAP 3220 is throwing the alerts becuase it isn't set up it self as a DNS proxy.
In my case becuase I have PiHole after the proxy, I am wondering if the fact that this some times intercepts the DNS lookups and inserts a fake resolved address (127.0.0.1) for lookups such as Ads, MS telemetry etc its casuing these alerts to fire?
04-25-2019 09:41 AM
I'm still seeing this quite a lot and can't quite work out why. I wonder if its worth raising a support case for this?
04-25-2019 12:09 PM
It's normal, support will likely direct you to disable the alerts if it bothers you. The evasion detection is prone to false positives because it is a very simple check. I had to dig, but found it from the 7.1 New Features Guide:
Setting up this evasion prevention feature enables the firewall to check that the hostname or SNI indicated in an initial HTTP or TLS request corresponds to the destination IP address for the connecting client.
The problem is that if the firewall's DNS query for the hostname/SNI happens to get a different address, this signature will trigger even if it is a valid address.
Personally, I've disabled the logging for those two signatures by setting them to "allow" instead of alert or higher:
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!