opswat
3 TopicsAPM 12.1.2 EHF 271 OPSWAT Mac File Check Issues
I have an access policy that I'm having issues with. I had to update APM to 12.1.2 with engineering hotfix 271. When I updated it, OPSWAT v4 was installed inadvertently. As soon as it was installed, any user in my company with McAfee Endpoint Encryption v6.x could not get past the HD Encryption check. I ran the OESIS Diagnostic tool on their computers and it did not detect any HD Encryption software. Users that have Bitlocker work just fine. I was able to get around this by setting up a process check coming off of the fallback branch of the HD Encryption macro, and everything is fine for Safeboot/Endpoint Encryption 6.x users (about 1500). I have some other users with Mac OS 10.12.5 that are unable to pass the client check. This is a bug in the version of the OPSWAT SDK that is installed (4.2.1067.0). There's also an issue with Mac Endpoint Security 10.x. I was going to try to get around the issue for now by checking that the files exist for the endpoint encryption and the endpoint security processes. I put the files in a Mac file check but it is still failing to see them. The files are: /Library/Application Support/JAMF/JAMF.keychain for JAMF, and /Library/Application Support/JAMF/status.0 for Filevault. Does anyone out there with Mac experience have the ability to check to see if that is correct? The only thing I can think of is that it needs a ~ in front of /Library. If I remove the check altogether it works. The other issue Mac users are having is that they keep getting disconnected right when they log in. Their log files show this: 1106,1106,edge, 48, , 143, TunnelController, Tunnel Server, Connecting state 1106,1106,edge, 2, , 171, TunnelController, Disconnected state, Error code, Routing table cannot be patched 1106,1106,edge, 48, , 183, ConnectivityService, activeServices, Service is active, en5 1106,1106,edge, 48, , 183, ConnectivityService, activeServices, Service is active, en0 1106,1106,edge, 48, , 183, ConnectivityService, activeServices, Service is active, awdl0 1106,1106,edge, 48, , 84, DoRequest, DoRequest, cancel 1106,1106,edge, 48, , 165, TimerController, TimerController, Captive Network Not Detected 1106,1106,edge, 48, , 77, TimerController, Timer Controller, Activated 1106,1106,edge, 48, , 80, TimerController, Timer Controller, Timer Activated (interval: 10 secs) 1106,1106,edge, 48, , 124, TimerController, Timer Controller, Deactivated 1106,1106,edge, 48, , 330, SvpnHandler::StopSvpn, TunnelService, Cannot open pid file, svpn already closed Does anyone know why this would be happening? F5 support suggested adding a split tunnel entry of 0.0.0.0/0.0.0.0 to their network access profile, but I don't know if that will help.461Views0likes1CommentAPM Antivirus (EPSEC/OPSWAT) checking
Hi all, First post, long-time crawler. We are currently doing a proof of concept using the built-in APM client-side antivirus checking (EPSEC/OPSWAT) for compliance. I've got everything setup and working as I would expect, but there's one thing I can't quite figure out. We are specifying the antivirus age to be no older than 7 days and are not seeing any resultant session variables set that would indicate database ages out of compliance. Does this function look at the session.check_av.last.item_x.db_time variable? If so, I don't understand the value that is set for this variable (ie. a Kaspersky database dated Apr 20, 2014 gives db_time=1405626209, SEP database dated Jul 17, 2014 gives db_time=1405569600). The end result for both AV checks is check_av.last.result=1, check_av.last.state=1, and check_av.last.error=0, which is a PASS/SUCCESS. If anyone can even shed light on the db_time variable value, then I can just write an iRule and set a custom flag for database age myself. That said, I know that would require the db_time to be consistent across all AV platforms. Thanks for any help that can be provided on this. James399Views0likes3CommentsAPM :: EPSEC / OPSWAT :: Dealing with Unsupported Antivirus Applications
How do folks deal with unsupported antivirus applications when requiring passing of this check prior to logging in? For example, some users have repackaged applications from their ISPs, and it is typically something they either pay for or comes with their subscription. They generally aren't too keen on moving to something else because of that. I would entertain the idea of a bypass... but EPSEC doesn't even see it. Removing the troublesome AV suite and enabling/updating Defender would work and get them in... but again, they're generally not too keen on removing something they pay for. And giving the ISP-specific nature of it... I doubt OPSWAT is going to accommodate an update in that regard? Anyway... Does anybody have any tricks for this in their environment? Thanks!263Views0likes0Comments