ENS 10.7 ATP MODULE Realprotect not working GTI without TIE
Only WORKS with OPTION "Enable offline scanning (Might result in increased false positives)"
We have several customers with the ATP/TIE Module in place since years and know the product very well. Those are large deployment with TIE-Server, ATD-Sandbox etc.
Wanted to integrate and test the one without a TIE-Server and over GTI. The seem to do nothing or something is wrong or buggy?
* We are aware of KB79640 and have all open already for GTI normal ENS and MSME 8.X
* ENS 10.7 APRIL 2020 (Platform, Threat, ATP Module > 3) > Exmaple realprotect1.mcafee.com open
* Windows 10 PRO OR ENT EN/GERMAN with all latesst patches
* 2 x different TEST CLients have Internet Access (1 x LAB DIRECT + 1 x Customer all Mcafee Fortigate open)
* tested with Mcafee RP Files (RP-D TestFile.exe/RP-S TestFile.exe)
The only WAY to get something BLOCKED OR LOGGED in NON TIE-Server (GTI only) mode is when we TURN ON THE OPTION "Enable offline scanning (Might result in increased false positives)".
As we understood and would say this is from Endpoint with no WAN/Internet Access isolated in VLAN's. There this would be OK. (Non change machines/Validated)
In longterm this we would like to use with all our customers since the ATP Mdoule is free now. However we need this solved first. We all understand this is very important to keeping False/Positive LOW without the TIE and ATD-Sandbox in place.
Any help welcome, we asume it's a bug today 04.05.2020
We asume you have all URL/IP open on the Firewall Points where the client goes to WAN?
We seen following on a machine with the ATP Module PLUS the one you did mention: realprotect1.mcafee.com
Gruss aus Basel
If you don't/can't have the firewall open, you can configure it to go out your proxy. That may be an easier course, though it adds a bit of latency most likely.
Hello Dave, we know. It's not the proxy or WAN access. We see all the related IP/URL going out in the flow on the Fortigate. We extra made a setup of ENS + EPO in a LAB with direct WAN (NO IPS/AV Filters Firewall side) and the bug is still there.
So this is not Firewall related. 😉
Hmm.. I just set my client to GTI-only connectivity and I was still able to get the RP-S file to detect. I am also on the April release. Maybe because I do have DXL connectivity? I'm not sure at that point. If you hit the About menu in ENS, under ATP, what does it say for your connectivity?
Thanks i hope this helps all others if we document this is a little bit here.
DId they fix something in the REAL PROTECT CONTENT release today? LAB works now.
The other one we tested clearly seems no connection to GTI we have to see what is missing.
I remember in last Mcafee Partner presentation they talked about reducing Firewall Ports / Protocolls needed in new Agent.I extra updated the Partner client to 18.104.22.168 but it did not work before and after Agent update (Was just a try before we searched further)
Strange in the TEST LAB since this morning this works. (Nothing changed except AMCORE Update and Real Protect DEF Update). (See Screenshots) (Agent 22.214.171.124)
LAB, Agent 126.96.36.199 > I see "Mcafee GTI Connectivity Only" > There is NO TIE OR DXL-Server there EPO 5.9.1
INTERNAL PARTNER, Agent 188.8.131.52 > I see "Disconnected/Getrennt" > So for sure the Fortigate Firewall there blocks something i guess. Have to see what they block again there.
Screenshot from LAB (The seen effect > Log did not happen yesterday > Works since this morning)
Screenshot from LAB PC with direct WAN access. But i also see the same settings on my home office PC behind a restricted Sophos Firewall.
I can only asume this change is now related to the REAL PROTECT DEF (Maybe our Ticket we have open did help on Mcafee side...)