Jump in Suspicious HTTP Evasion Found and Suspicious TLS Evasion notifications

Reply
Highlighted
L1 Bithead

Jump in Suspicious HTTP Evasion Found and Suspicious TLS Evasion notifications

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.


Accepted Solutions
Highlighted
L7 Applicator

Re: Jump in Suspicious HTTP Evasion Found and Suspicious TLS Evasion notifications

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:

EvasionDisable.jpg

View solution in original post


All Replies
Highlighted
Cyber Elite

Re: Jump in Suspicious HTTP Evasion Found and Suspicious TLS Evasion notifications

@Jrice01,

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? 

Highlighted
L1 Bithead

Re: Jump in Suspicious HTTP Evasion Found and Suspicious TLS Evasion notifications

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

Highlighted
Cyber Elite

Re: Jump in Suspicious HTTP Evasion Found and Suspicious TLS Evasion notifications

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.

Highlighted
L1 Bithead

Re: Jump in Suspicious HTTP Evasion Found and Suspicious TLS Evasion notifications

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?

Highlighted
L1 Bithead

Re: Jump in Suspicious HTTP Evasion Found and Suspicious TLS Evasion notifications

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?

Highlighted
L7 Applicator

Re: Jump in Suspicious HTTP Evasion Found and Suspicious TLS Evasion notifications

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:

EvasionDisable.jpg

View solution in original post

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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 Live Community as a whole!

The Live Community thanks you for your participation!