Jump to content

TonyK

Members
  • Posts

    13
  • Joined

  • Last visited

  • Days Won

    1

TonyK last won the day on December 12 2021

TonyK had the most liked content!

About TonyK

  • Rank
    Newbie
    Newbie

Profile Information

  • Location
    USA

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. You're comparing apples to oranges here: ESET Endpoint products (inclusive of 'Server-branded' AV engines - unaffected, they don't use apache- the installs do not place any form of Apache on these systems -------- Your endpoints aren't at risk directly, if you're solely utilizing HTTP Proxy to distribute content to those systems or connectivity to ESET's public servers, then there is a potential issue (though again ESET saying they don't utilize those components) ESET PROTECT (management console) - there are two web-engines on this system: The TOMCAT engine, which runs the front-end ESET PROTECT UI Webpage, again not applicable The only component that is potentially impacted is the APACHE HTTP PROXY component, ESET did release 9.0.10.2 of the Protect console -- but those not wanting to download a gig to update a 12MB install, the literal only change is that under the HTTP Proxy component download, that is showing 2.4.51.0 for downloads So there is either potential on the Log4J or just simply keeping up with the latest release of Apache (which being a security company, makes sense)... In the time it took to explain this, updating the 12mb installer and hopping your config file changes, you'd be done And the statement is correct about it's not up to ESET to patch endpoints is true -- you deploy your own version updates to your endpoints (though if you're already running 9 on console and endpoints, automation for workstation-version ESET is already in place)
  2. Also bear in mind, while today we have 3k endpoints, however those numbers will be increasing drasticlally over the next year or so; our organization is pushing hard a security as a service in our portfolio; we could be looking around doubling or even tripling these numbers in the near future... So this is also long term architecture I am looking at (and yes I'll be moving from SQL Express to full SQL)
  3. Not all our customers will be allowing 'public' internet access (compliance reasons), those who do have internet access will not be using the proxy This is for those who do not - we are trying to limit the number of firewall rules we have to make on customers (again, compliance reasons) I am aware that HTTP Proxy doesn't have it built in - I am talking about deploying 2-3 regional HTTP Proxies that have a loadbalancer in front with one DNS name Customers cannot host proxies on their sites (once more, they will not be allowing public internet access over port 80/443) What i am asking, is this scenario: can I use multiple proxies that are behind a virtual/hardware loadbalancer; So the overall purpose is to only allow agent communications AND product updates/content be distributed from our whitelisted environments; no I already tried to say that KB332 is a requirement however, our management is determined to use proxies The load balancer is to also make sure that the ESMC console is NOT overloaded, as we are seeing considerable performance hits with the MSSQL Express built in
  4. Hey gang, I have a question on placing ESET HTTP Proxies behind a load balancer for distributive/regional workloads. I might have missed it but would the Proxy solution be able to accommodate usage of a load balancers. Our use case is that we operate the ESMC console in a MSP role with clients concentrated around the entire North American region, currently we are hosting around 3000 endpoints with 95% of them located statically in North American region, and the remainder 5% could be potentially roaming globally. My concern is that we are needing to balance communications intervals responsiveness (granted I know from defaults that recommendations were to have communications intervals slated to 20-60 minutes for heartbeat) - but due to our customer base and needs, I would like to maintain a 10-20 minute interval at maximum for endpoints that report 'healthy' status and devices with warning flags in ESMC have 1-2 minute intervals (to allow for 'rapid' configuration changes/commands) SO TLDR - Would ESET Apache HTTP proxy work behind a loadbalancer
  5. So lets assume here 1) ESMC Server is behind corporate network say 10.10.0.10 (just go with it) - your server resolves to that IP address 2) When your endpoints are connected to VPN, their connection (say 10.10.1.121 is one of the IPs) 3) Lets assume 10.10.1.0/24 can route back and forth to 10.10.0.0/24 while on VPN Everything is working A-OK! When your endpoints are not part of the VPN, eg. they are on their own network, whether a home network, coffee shop, public wifi...regardless of the case, they are no longer attached to your 'local network' - they are part of that networks 'local network' In order for those endpoints to reach your ESMC server, you must do three things: 1) The ESMC will need an outside IP address to reach with ports 2222 open (this can be accomplished by placing a public IP NAT that is bound to the internal IP address or port forwarding 2222 from that internal address, but traffic must be allowed in and out) -- obtain the public IP address of that device (typically will be firewall external address if going port forwarding, or NAT public internet address, save that for next step) 2) Create a new ESET Remote Administrator policy Include the IP address on the inside, include the inside IP address as first on list, and add the external address (NAT or FW pub IP) as second and then assign that to (I usually would just say all, it wouldn't hurt) those devices; its best to use that red lightning bolt for admin enforcement, and just to make sure there isnt any other conflicts at hand --- test out one or two devices if possible, take a laptop home or something for a test 3) Have endpoints that have not received policy - VPN in or connect to corporate network as soon as possible once that step two is successful. When the endpoints check in, they should obtain the policy update for the ESMC/ERA agent
  6. Just a heads up - I will be trying to revisit this next week, my unix colleague has to get this deployed onto a few (10-15 prod devices), he ended up doing so without letting me know and it appears that the OS'es are somewhat out of date so I'll get you all more info I am hoping we can go for deploying EFSL 7 instead but there is a portion of folks still deploying ESETS (Mail/File/Gateway 4.5.15 still) -- unfortunately reshaping a direction of an organization to go is a bit difficult
  7. As far as I know we are only using Ubuntu and Redhat flavors, there might be some CentOS-based as well, but AFAIK there is no plans for Fedora, but I would assume that Fedora is a RHEL-ish distro and would have similar requirements. But if you have any info on SuSE and CentOS as well, that'd be helpful
  8. Looking over an older topic, I found this forum thread for the legacy 4.x Linux clients. As I have been looking through the docs: https://help.eset.com/efs/7/en-US/system_requirements.html?index.html I already looked through the docs here and I have not seen an actual list of dependencies required for each OS platform/Unix flavor, I did see a 'how to list missing dependencies' however, I need a masterlist for our provisioning teams as we have extremely diverse environments as my application is a multi-tenant cloud; if there is a listing of dependencies that is available, this would help my efforts as I work on transitioning as much as possible from our 4.x (we do have a lot of dated unix machines that may be 'stuck' for now) clients to 7.x (and any items here will help drive requirements to our business/clients Could this dependency list be replicated for 7.1.x?
  9. I actually just went into one of the servers that I ran the attempt on (I have a client that needs protection functional sooner rather than later) - hoping that "setenforce 0" would be all that is missing; I ran a new task with deployment of ESET Mail/File/Gateway Security for Linux 4.5.15 with the license included - it looks like the task is hung in the console for 'Waiting for Product' but it looks to be installed: running command 'service esets start' results in failed I did grab the entire remote administrator folder so that way it has all the trace history -- there were multiple activation tasks/install/uninstall -- trying to get something to work... At this point it's probably best to wipe the slate clean and start over so I might end up uninstalling all ESET products and reinstalling the agent and then start deployment again RemoteAdministrator.zip
  10. Okay - I'll see if I can get my colleague to run those in the next couple days - I have been pulled into a couple other projects at the moment, but should have an answer by Friday or next Monday
  11. I attempted to do the same as well with v7 File Security for Linux but I wasn't able to start the AV engine, I'll be honest, I am not a linux guru though, I only enough to get me into trouble When deploying the ESET File Security for Linux v7 (7.1.558.0) with license the endpoint reports that the product is installed but is not running, when attempting to start the service it errors out - this on two lab machines on VMWare 6.5 (HW13) on fresh installs of RHEL on one and CENTOS on the other Then with working on ESET Mail/File/Gateway Security for Linux that version is 4.5.15.0 Obviously under MSP program I cannot get the lic files - which limits the routes I can go. The caviat is, I am not sure how folks got it to work in the past (it seemed to work on ERA 6.x somewhat) but the team who implemented it and gave us the process is no longer with our organization. Frankly, I'd rather move everyone to ESFS-Linux v7 anyways as it seems to be better overall on the feature enrichment, but I am more concerned with getting a working product no matter what - and right now I am stuck
  12. Similar to this topic here: https://forum.eset.com/topic/21462-cannot-start-license-not-found/ Couple items: We are a Multi-tenant MSP provider for ESET Services I am working on migrating our customer base from ERA 6.5.x to EMSC 7.1.717.0 When attempting to install ESET Mail/File/Gateway Security for Linux on devices that are managed through us, the application does not start up - upon looking at the endpoints, the remote management reports to ESMC that "Product is not connected. No connection attempt occurred" The object in ESMC does not show a license attached to the endpoint details When attempting to check on the individual endpoint's licensing status "service esets status" - the services are dead When attempting to start the endpoint ESET engine - the product fails to start because of licensing During deployment: the license IS specified with the remote deployment; also further tasks fail on running a product activation task Manual application of LIC files is not practical as we do not provide the LIC files to clients directly and our other teams have limited access to the MSP Licensing portal Is there a specific route to install this product onto endpoints all remotely: (install agent>AV endpoint>license separate task) or (install agent>install AV+license together [which is the route i done])
×
×
  • Create New...