Jump to content


  • Posts

  • Joined

  • Last visited

About RichardW

  • Rank

Profile Information

  • Location
  1. Hi, We're currently using Eset within a PCI Compliant environment as part of that we need to run quarterly nessus scans I ran one just recently and something cropped up regarding the version of Apache Proxy used by Eset Currently the latest version from eset is 2.4.46 High 150280 Apache 2.4.x < 2.4.47 Multiple Vulnerabilities The version of Apache httpd installed on the remote host is prior to 2.4.47. It is, therefore, affected by multiple vulnerabilities as referenced in the 2.4.47 changelog: IAVA: 2021-A-0259 CVE: CVE-2019-17567, CVE-2020-13938, CVE-2020-13950, CVE-2020-35452, CVE-2021-26690, CVE-2021-26691, CVE-2021-30641 Medium 150244 Apache 2.4.x < 2.4.48 Vulnerability The version of Apache httpd installed on the remote host is prior to 2.4.48. It is, therefore, affected by a vulnerability as referenced in the 2.4.48 changelog. IAVA: 2021-A-0259 CVE: CVE-2021-31618 Are there any plans to update the version of apache proxy used by eset? I'll probably have to look into using the apache sources otherwise Many Thanks
  2. Hi, We're currently using Eset File Security on a bunch of windows 2012R2 / 2016 servers With the ESet Security Management Center managing the policies / updates etc The one I've been testing with is using the latest version of File Security - 7.1.12008.0 A scan that is manually triggered seems fine But a scan that is triggered via a schedule does not appear to show in the logs at all Looking at the schedule this is fine so far (set via a policy setting which I tried deleting and re-creating for info), the scheduled scan is at the bottom of the list set for midnight Next I watched and saw that the scan did actually run at midnight and shows up under the scan tab so far so good. Next lets click on "Show log" to see what shows Hmm the date on that log isn't correct, almost as if it's just picking a different log at random Next lets look at the Log window What we're actually seeing at the top is the last time I did a manual scan not a scheduled one, the scheduled one doesn't appear to be listed Checking the Security Management center, it appears to be showing the date of the last manual scan, not the scheduled scan Typically for PCI purposes we need to show the auditor that we've been running scans each day so the logs are kind of important in this regard.
  3. Hi, I've another question this time over encryption between Eset Security Management Center Server and the SQL Server Express instance it's running on. If I enable the use of a certificate on the SQL Express (2014) instance under "SQL Server Configuration Manager" and then set Force Encryption to True, and the certificate is signed by a trusted CA installed in the machine certificate store This prevents network scanners from picking up on port 14222 as having a clear text login however this breaks the Eset server software is there anyway to configure Eset Security Management Center to use encrypted / ssl database access?
  4. Thanks I just needed to change sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2" to sslEnabledProtocols="TLSv1.1,TLSv1.2" within C:\Program Files\Apache Software Foundation\apache-tomcat-7.0.92\conf\server.conf
  5. Thanks for pointing me in the right direction, I'll have a look at that KB article
  6. Note I didn't have to make any changes to the clients to get it to work generally for PCI TLS1.1 / TLS1.2 is fine, but TLS1.0 is a big no no
  7. Hi Marcos this seems to fix ports 2222 and 2223 port 443 seems to flag up as still supporting TLS1.0 (for the web gui), will there be a way in the future to disable TLS1.0 on this port as well?
  8. Hi, we're currently trying to use "ESET File Security for Servers" and "ESET Security Management Center" within a PCI environment one of the requirements of this is to avoid TLS1.0 and use TLS1.1 or TLS1.2 instead. One of the things that showing up on the nessus port scan is that ESET Security Management Center is using TLS1.0 on ports 443 / 2222 / 2223 I have TLS1.0 disabled at the operating system level (within the registry) but is there any way to get ESET Security Management Center to use TLS1.1 or TLS1.2? (to disable the use of TLS1.0)
  9. Thanks for the info Currently I'm going through and checking to see if I can do anything to harden the Apache setup. The first thing nessus recommends is "TraceEnable Off" so I've set that up so far
  10. Okay I managed to find a version that does work, this uses VC11 instead of VC15 / VC14 https://www.apachelounge.com/download/VC11/ Apache 2.4.38 Win32 so it looks like it's ether something added between 2.4.38 -> 2.4.39, or the use of VC15 / VC14 instead of VC11 for the C++ library's under windows. Edit: Nessus still mentions it would prefer 2.4.39 due to several patched bugs https://httpd.apache.org/security/vulnerabilities_24.html I wonder if the change they made to URL normalization inconsistincy (CVE-2019-0220) might have something to do with the compatibility with the Eseet applications
  11. logs_and_conf.zip Hi Janoo, I did check that the original Apache proxy included by eset was working okay in fact when I reverted back to it (since I'd made a backup of C:\Program Files\Apache HTTP Proxy) everything started working fine again. I think the only errors in the error log were related to access to the cache directory under C:\\ProgramData\\Apache HTTP Proxy\\ but that didn't seem to affect the check for updates I've done a bit of additional checking to provide as much info as possible and I've attached the error log and httpd.conf files from the different tests I've done so far In order to test I've run updates for Eset File Security on a machine that doesn't have direct access to the internet but can access the Proxy, and does also have Eset Management Agent installed which tells it to use the proxy via the default policy setting. ## Version included with Eset Security Management Center Server (ESMCS) This appears to be version 2.4.33 of Apache, probably a custom build since it's using .dll files for the modules. The error logs don't show all that much, potentially a couple of cache related errors But the machine doing the updates works fine and shows no errors https://www.eset.com/int/business/security-management-center/download/ All in one installer ## Standalone version of Apache Http Proxy - Eset I did a file comparison and this is identical to the version included with the all in one installer https://www.eset.com/int/business/security-management-center/download/#standalone ## Apache Lounge 2.4.39 Win32 https://httpd.apache.org/docs/current/platform/windows.html#down https://www.apachelounge.com/download/ httpd-2.4.39-win32-VC15.zip https://aka.ms/vs/15/release/VC_redist.x86.exe Using exactly the same httpd.conf as from the eset install the only change made to rename LoadModule entires from .dll to .so since the extensions on the modules is different Same errors as already listed Strangely enough if I set Firefox to use the Proxy it works fine / as expected in that it only allows access to sites ending in eset.com in the URL Based on what I'm seeing I suspect there may be a problem in the way the ESet app (in this case file security) is passing the URL to the proxy Something that works with older versions of Apache Proxy but not the newer versions. possibly it's missing the "http" prefix in the URL
  12. Hi Janoo, the proxy configuration I've been using httpd.conf is the same one included with the all in one installer for the ESET Security Management Center Installer. I'm just using a more uptodate version of Apache but with the same config. The only change to it is replacing .dll with .so in httpd.conf (which is something recommended in the eset documentation link above) I also tried a different binary release from https://www.apachelounge.com/download/ but it had the same result
  13. Okay just to follow I tried turning off the default block rule for the Proxy just to see what would happen <Proxy *> # TODO #Deny from all Allow from all </Proxy> The end result was a malformed URL error when attempting to download updates for ESet File Security [Wed Apr 10 18:41:19.985040 2019] [proxy_http:error] [pid 9480:tid 12756] [client] AH01083: error parsing URL /repository.eset.com/v1/com/eset/apps/business/efs/windows/metadata3: Malformed URL [Wed Apr 10 18:41:26.657705 2019] [proxy_http:error] [pid 9480:tid 12756] [client] AH01083: error parsing URL /repository.eset.com/v1/com/eset/apps/business/efs/windows/metadata3: Malformed URL
  • Create New...