Jump to content

RichardW

Members
  • Posts

    25
  • Joined

  • Last visited

About RichardW

  • Rank
    Newbie
    Newbie

Profile Information

  • Location
    U.K.
  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
×
×
  • Create New...