Jump to content

RichardW

Members
  • Posts

    25
  • Joined

  • Last visited

Everything posted by RichardW

  1. Hi, I've recently been running Nessus reports against our PCI platform and the below result has shown up https://www.tenable.com/plugins/nessus/172186 Apache 2.4.x < 2.4.56 Multiple Vulnerabilities This one is classed as critical It looks as if the version downloadable from eset is at 2.4.55 - https://www.eset.com/uk/business/download/eset-protect/ are there any plans to switch to 2.4.56 any time soon?
  2. Hi, I've recently been running Nessus reports against our PCI platform and a couple of results have show up regard Apache Proxy OpenSSL 1.1.1 < 1.1.1o Vulnerability | Tenable® Apache 2.4.x < 2.4.54 Multiple Vulnerabilities | Tenable® One is classed as Critical the other High Currently I'm on Apache proxy 2.4.53 which seems to be the latest from the main Eset download page are there any plans to switch to 2.4.54 any time soon? since I think that would fix at least one of them. Apache HTTP Server 2.4 vulnerabilities - The Apache HTTP Server Project
  3. Thanks very much for looking into this with the developers. I admit the use case is kind of unusual in that I'm not using apache for caching. But unfortunately the PCI auditors tend to be quite strict over what is allowed when it comes to non SSL ports. Typically allowing port 80 requires a lot of paperwork is part of the reason, even though the proxy limits access to certain hosts and the updates are signed.
  4. Ok found it Inside the Business Account Login Licences -> Select Licence (show details) -> Products -> Select Product Select Download Legacy Licence File and it shows up there
  5. From the looks of things if you try and set the Update URL Manually to a https link by turning "Choose Autmatically" here then it also requires manual input of the username / password It mentions it here - Modules Update | ESET PROTECT | ESET Online Help I've been able to determine my username / EAV-number using Ctrl-U on the eset window But since the licence is activated online I'm not sure how to get the password to use Unless I have to do an offline activation or something. Tried having a look on the Eset Business Account site where the licences are listed but I couldn't see anything there
  6. Ok so this nearly works, although that url is asking for a username password This currently prevents eset from downloading module updates from that url is there a specific thing I should be using for the username / password for that url?
  7. The 2nd message is actually what I was looking for if it works. Our use of the Apache Proxy isn't really for caching, instead it's for making sure machines within a L1 environment don't have direct access to the internet. Since the environment is PCI based and makes using port 80 very difficult.
  8. Hi, Currently we have ESET Server Security Setup on multiple servers within a PCI Environment As part of the Setup we're using ESET Management Agent / Web UI and Apache Proxy to handle the updates So that the Eset client on each box connects to the Apache Proxy (that eset installs) to do the updates to the outside world. One thing we've noticed is that if we block port 80 (which is an unsecure port) to the outside world This seems to interfere with Eset updates. Do you know if there's a way to avoid this while at the same time avoiding the use of port 80 for access to the internet (just 443 for Https) Many Thanks
  9. Hi, I currently have a setup involving Eset Protect Server and Apache Proxy This is located on a PCI Compliant system so as part of it I need to run Nessus scans every so often I've updated to the latest Eset versions recently but there seems to be a single High Vulnerability showing on the Nessus Reports associated with Apache Proxy OpenSSL 1.1.1 < 1.1.1l Vulnerability https://www.tenable.com/plugins/nessus/152782 Port 3128 Banner : Apache/2.4.46 (Win64) OpenSSL/1.1.1i-dev Reported version : 1.1.1i Fixed version : 1.1.1l Other Links: https://github.com/openssl/openssl/commit/59f5e75f3bced8fc0e130d72a3f582cf7b480b46 https://www.openssl.org/news/secadv/20210824.txt Can I ask is this something I need to worry about?, will it be addressed in a future Eset Protect update? It looks like a similar query was raised here back in September https://forum.eset.com/topic/29836-nessus-reports-critical-openssl-vulnerability-on-eset-protect-server/ Although I don't think an update to Apache Proxy has been rolled out as part of the latest Eset Protect Version 9 Many Thanks Richard
  10. 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
  11. 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.
  12. 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?
  13. 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
  14. Thanks for pointing me in the right direction, I'll have a look at that KB article
  15. 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
  16. 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?
  17. 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)
  18. 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
  19. 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
  20. 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
  21. 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
  22. 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 10.10.0.12:63758] 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 10.10.0.12:63774] AH01083: error parsing URL /repository.eset.com/v1/com/eset/apps/business/efs/windows/metadata3: Malformed URL
  23. Hello, we've recently moved over to using ESet File Security for our servers, and ESet Security Management Center Server (7.0.577.0) Just to give a bit of background the platform is basically a PCI Compliant one some of the servers are not allowed to reach the internet directly so we decided to move over from Avira which stopped supporting downloading updates from a central location on the network. So Far I've installed everything fine and everything works okay I also updated the SQL Express instance included in the all in one installer up to the latest SP3 and Cumalitive Update to avoid issues with TLS1.0 being turned off in the registry. However one of the things that cropped up when doing a network scan with Nessus Is that the version of the Apache Proxy used is 2.4.33 and Nessus warned that this had some security issues that were patched in later versions. So I figured I'd try and manually update the Apache Proxy to 2.4.38 Using this guide - https://help.eset.com/era_install/65/en-US/upgrade_apache_http_proxy_windows_instructions_manual.html?upgrade_apache_http_proxy_windows_instructions_manual.html And the x32 Windows version from https://www.apachehaus.com/cgi-bin/download.plx (I was able to determine that the version Eset had installed was x32) I've managed to install it okay the only change to httpd.conf was to change .dll to .so for the Loaded modules However when trying to check for updates within ESet File Security this results in a "Product Update Failed / Unauthorised Access" error I'm guessing something has changed in the apache config that needs to be specified but I'm not sure what just yet [Wed Apr 10 16:52:08.785451 2019] [mpm_winnt:notice] [pid 12632:tid 600] AH00455: Apache/2.4.39 (Win32) OpenSSL/1.0.2r configured -- resuming normal operations [Wed Apr 10 16:52:08.785451 2019] [mpm_winnt:notice] [pid 12632:tid 600] AH00456: Server built: Mar 27 2019 11:11:12 [Wed Apr 10 16:52:08.785451 2019] [core:notice] [pid 12632:tid 600] AH00094: Command line: 'C:\\Program Files\\Apache HTTP Proxy\\bin\\httpd.exe -d C:/Program Files/Apache HTTP Proxy' [Wed Apr 10 16:52:08.785451 2019] [mpm_winnt:notice] [pid 12632:tid 600] AH00418: Parent: Created child process 13392 [Wed Apr 10 16:52:09.285511 2019] [ssl:warn] [pid 13392:tid 560] AH01873: Init: Session Cache is not configured [hint: SSLSessionCache] [Wed Apr 10 16:52:09.332392 2019] [mpm_winnt:notice] [pid 13392:tid 560] AH00354: Child: Starting 1500 worker threads. The 'ApacheHttpProxy' service is running. [Wed Apr 10 16:57:02.070161 2019] [access_compat:error] [pid 13392:tid 12756] [client 10.20.0.43:56497] AH01797: client denied by server configuration: proxy:http:/repository.eset.com/v1/com/eset/apps/business/efs/windows/metadata3 [Wed Apr 10 16:57:13.087089 2019] [access_compat:error] [pid 13392:tid 12756] [client 10.20.0.43:56505] AH01797: client denied by server configuration: proxy:http:/repository.eset.com/v1/com/eset/apps/business/efs/windows/metadata3 [Wed Apr 10 16:57:41.637342 2019] [access_compat:error] [pid 13392:tid 12756] [client 10.20.0.43:56515] AH01797: client denied by server configuration: proxy:http:/repository.eset.com/v1/com/eset/apps/business/efs/windows/metadata3 [Wed Apr 10 16:58:19.313679 2019] [access_compat:error] [pid 13392:tid 12756] [client 10.20.0.43:56523] AH01797: client denied by server configuration: proxy:http:/repository.eset.com/v1/com/eset/apps/business/efs/windows/metadata3 [Wed Apr 10 16:59:10.819770 2019] [access_compat:error] [pid 13392:tid 12756] [client 10.20.0.43:56531] AH01797: client denied by server configuration: proxy:http:/repository.eset.com/v1/com/eset/apps/business/efs/windows/metadata3 [Wed Apr 10 17:02:09.575292 2019] [access_compat:error] [pid 13392:tid 12732] [client 10.20.0.43:56546] AH01797: client denied by server configuration: proxy:http:/repository.eset.com/v1/com/eset/apps/business/efs/windows/metadata3 [Wed Apr 10 17:04:20.896687 2019] [access_compat:error] [pid 13392:tid 12732] [client 10.10.0.12:62526] AH01797: client denied by server configuration: proxy:http:/repository.eset.com/v1/com/eset/apps/business/efs/windows/metadata3 [Wed Apr 10 17:09:24.261892 2019] [access_compat:error] [pid 13392:tid 12732] [client 10.10.0.12:62590] AH01797: client denied by server configuration: proxy:http:/repository.eset.com/v1/com/eset/apps/business/efs/windows/metadata3 [Wed Apr 10 17:10:23.268876 2019] [access_compat:error] [pid 13392:tid 12756] [client 10.10.0.12:62632] AH01797: client denied by server configuration: proxy:http:/repository.eset.com/v1/com/eset/apps/business/efs/windows/metadata3 [Wed Apr 10 17:10:31.222944 2019] [access_compat:error] [pid 13392:tid 12756] [client 10.10.0.12:62648] AH01797: client denied by server configuration: proxy:http:/repository.eset.com/v1/com/eset/apps/business/efs/windows/metadata3 [Wed Apr 10 17:58:55.551049 2019] [access_compat:error] [pid 13392:tid 12732] [client 10.10.0.12:63246] AH01797: client denied by server configuration: proxy:http:/repository.eset.com/v1/com/eset/apps/business/efs/windows/metadata3
×
×
  • Create New...