Infractal
-
Posts
19 -
Joined
-
Last visited
Posts posted by Infractal
-
-
Is there a roadmap for adding TLS 1.2 support for SSL inspection? I would also like to see the following forward secrecy ciphers supported to match the Win8.1/10 schannel stack, along with the ability to configure the cipher and protocol config on clients so I can do things like disable RC4 ciphers for my enterprise clients.
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 -
No, this is an AD-joined system. Processes running as both System and Network Service execute with the token of the computer AD object, which is a member of Domain Computers and has access to the share. Local Service is the only built-in account that accesses network resources anonymously. If what you were saying was true, then domain joined computers would never be able to auth and access group policy data off the domain sysvol share before a user logon, which is not true. Like I said before, I can make this work on pre-Win10 but something screwy is going on here and I doubt I am the only one who is propagating definition updates this way.
System command prompt from Win7
PsExec v1.98 - Execute processes remotely Copyright (C) 2001-2010 Mark Russinovich Sysinternals - www.sysinternals.com Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:\Windows\system32>whoami nt authority\system C:\Windows\system32>pushd \\nod32\mirror Z:\>dir update.ver Volume in drive Z has no label. Volume Serial Number is 4C55-E814 Directory of Z:\ 10/10/2014 02:06 PM 82,342 update.ver 1 File(s) 82,342 bytes 0 Dir(s) 7,302,033,408 bytes free Z:\>
Same thing on Win10 with identical group permissions
PsExec v1.98 - Execute processes remotely Copyright (C) 2001-2010 Mark Russinovich Sysinternals - www.sysinternals.com Microsoft Windows [Version 6.4.9841] (c) 2014 Microsoft Corporation. All rights reserved. C:\Windows\system32>whoami nt authority\system C:\Windows\system32>pushd \\nod32\mirror The system cannot contact a domain controller to service the authentication request. Please try again later. C:\Windows\system32>
I'm guessing Microsoft is ultimately responsible for this and there is some kind of security thing happening under the hood that is breaking things, but since you are a dev partner with them it seems worth pursuing since this is a feature that currently works but might be broken with the upcoming OS. And it isn't a problem with communicating with the DC because all the traffic in wireshark is passing, group policy applies, and domain logons are processing just fine.
-
Yeah, if I I change it to the Current User option or hard-code credentials then I can make it work, but that isn't a good solution. If I use the currently logged in credentials, then it only updates when there is an active user session. If I hard code it, then credentials could possibly be stolen or if they are ever changed I have to go through the work of pushing a new config.
Pulling with the System credentials fixes both those problems, and appears to only have problems on this specific OS. The system account is a member of the domain computers account, which has read access to the share and its contents. It's not a permissions issue. I'm looking at a wireshark trace of the traffic when it fails and its extremely weird. The client initializes a SMB connection to the server, the server responds saying it supports SMB2, the client reconnects on SMB2, server sends back the protocol initialization response, and then the client sends a reset packet to the server and the whole thing dies without ever getting to the session setup request.
When I change it to use the current user credentials, it gets through the protocol initialization with zero problems and moves on to session setup and then pulls the update.ver file and everything proceeds normally. I don't know why its freaking out and sending resets that kill the connection, maybe there is some new security feature in the OS that is conflicting, but either way Nod32 is the only software I have seen so far that has problem accessing data over SMB, everything else works fine.
-
We have a SMB file share of our Mirror folder on the RAS server that we use to propigate definition updates internally. With our Win7/2008R2/2012R2 client using a mix of version 4/5 clients, we have no problem getting updates.
I started testing out the Win10 tech preview running 5.0.2229.1 client and gave it the same configuration as our other systems to connect to the \\[RAS]\mirror share (Domain Computers and Domain Users have read access) and I get a generic Could Not Connect To Server error. I can browse to it in Windows Explorer no problem, the update.ver and all the .nup files are readable and ready to go, but there's something about this OS that appears to be breaking the ability to update.
No idea what is causing it, and if there is some kind of detail client log that I should be enabling to get better information on what is going on then I will give that a shot. But I suspect this is some kind of bug in the client or incompatibility with the new OS, possibly the attempted SMB3 handshake throwing it off.
-
This is pulling directly from Microsoft's update servers. I haven't seen a problem with contacting internal WSUS servers over HTTPS but I would assume Microsoft is being much more permissive there since an internal WSUS deployment could be using any certificate, where as the ones hosted on Microsoft.com can be pinned.
This is for the Windows 7 Windows Update Agent 7.6.7600.256 that was released around July 1st/2nd. When you say re-add the cert, do you mean the ESET one that it uses for SSL inspection or the one on Microsoft's end?
-
After the update to the windows update agent on Windows 7 (possible 8/8.1 as well) I am not longer able to pull and install updates from Microsoft over WU when SSL inspection is enabled. The connection fails citing a certificate error. I assume MS is tightening up their update agent and pinning a cert to it, so when it sees the ESET cert sitting in the middle for traffic inspection it kills the connection without pulling updates. I disabled SSL inspection and things started working correctly again, but I assume there is a list of URLs used by the Windows Update agent that I can exclude from SSL inspection to give a better workaround?
-
Still seeing the issue on 5.0.2228 with the mydish.com login.
Macros,
Is there an ETA to when that module will hit the pre-release channel?
-
Okay, extra info and a way to reproduce it. Trying to go to the login link on www.mydish.com fails with a cert error against identity1.dishnetwork.com on Firefox 27.0.1. IE11 passes it without an issue.
-
Group policy deployments are pretty simple. Do a manual install on a client and set it up so its pointed to your management server and whatever other customizations you want, then export the config out to a file you name cfg.xml. Put the msi installer and that cfg.xml file out on a network share in the same directory and when the installer launches it automatically parses the cfg.xml file as an answer file to configure your clients. Assigned software installs work as expected from there.
You can set up the management servers so that one is the upstream master of the other. If things are set up like that, you should be able to use a single master license key for your entire environment because license consumption information from the subordinate server will be pushed up to the master during their regular synchronization.
-
Since re-enabling the SSL scanning feature on 5.0.2225, I occasionally run in to websites that throw the following cert error in Firefox 27.0.1: ssl_error_bad_mac_alert
No idea if this is because of an issue with the way Nod32 implements the SSL interception, or its a problem on the other end with a bad SSL implementation on the target server, but the error doesn't give me a lot to go on when it crops up.
Win 7 64-bit SP1
Firefox 27.0.1
Endpoint Protection 5.0.2225.0
Virus signature database: 9533P (20140312)
Rapid Response module: 3808 (20140312)
Update module: 1048 (20140204)
Antivirus and antispyware scanner module: 1421 (20140219)
Advanced heuristics module: 1147 (20140114)
Archive support module: 1193 (20140303)
Cleaner module: 1086 (20140303)
Anti-Stealth support module: 1058 (20140130)
ESET SysInspector module: 1240 (20131202)
Self-defense support module: 1022 (20121129)
Real-time file system protection module: 1009 (20130301)
Translation support module: 1145 (20131121)
HIPS support module: 1120 (20140305)
Internet protection module: 1113 (20140312)
Database module: 1056 (20140303) -
That seems to have fixed the problem. Thanks for the help!
-
This seems to have fixed the LSASS memory leak issue that I was seeing. Great work! Unfortunately IMAPS scanning still breaks Outlook, but you can't have everything.
-
KB2735855 has been superseeded by KB2790655, 2845690, 2868623, and 2888049 all of which have been approved for install and deployed by our WSUS server. I tried manually installing KB2789397 but it says the update does not apply to my system, and I am assuming that the contents of the hotfix have been merged in to one of the other KBs that are already installed.
I will send you the info on the sysinspector logs in the PM.
-
This is on Win7 x64 SP1.
-
Yep, pulled it out of the pre-release channel, cleared the update cache, and forced an update that brought the module back down to 1096. Still gags on my Gmail folder in Outlook. Disable IMAPS scanning and the problem goes away immediately.
-
With SSL/HTTPS scanning enabled my iTunes TuneUp add-in never successfully connects to its remote servers. Added the TuneUp .exe's to the SSL application exclusion list and things started connecting normally again. Probably a bug on their side by not honoring the browser's trusted certs, but I figured I should report it.
v7.0.302.26 on Win7 x64
-
Nope, still seeing the issue in the pre-release channel using module 1097.
-
I've been testing out the SSL, POP3S, and IMAPS scanning in our work environment on 5.0.2225 and have been having some problems. I use Outlook 2010 64-bit with the Eset Outlook plug-in, and Outlook is attached to an Exchange mailbox, Gmail over IMAPS, and my university email account over IMAPS. Exchange and my university IMAPS accounts work fine, but the the Gmail account consistently throws 0x800CCC0E "Outlook cannot synchronize subscribed folders for [account name]. Error: Cannot connect to the server." when synchronizing mail. If you force a Send/Recieve 3 or 4 times messages eventually get through, but it is inconsistent. The second I disable IMAPS scanning, and the access issues to Gmail clear up.
At home I run a similar setup with Outlook accessing the same two accounts over IMAPS, but using home edition 7.0.302.26. The same issue is seen in that environment as well.
SSL Inspection TLS 1.2 Support?
in ESET Endpoint Products
Posted
After doing a bit more digging, I am noticing that browsers are behaving differently. Qualys tests against IE11 doing SSL inspection show TLS 1.2 support, but Firefox 36 is only going up to TLS 1.1.
Is cipher customization a possibility? I'd really like to get those RC4 ciphers pulled out.