Jump to content

Peter Randziak

ESET Moderators
  • Posts

    3,511
  • Joined

  • Last visited

  • Days Won

    207

Posts posted by Peter Randziak

  1. Hello @FranceBB,

    2 hours ago, FranceBB said:

    Reverting to 9.1.11 worked (9.11 to be precise).

    well yes, as the v9 didn't have the Web Access Protection feature at all.
    I recommend to follow it up via a ticket so it can be checked and resolved / work-around-ed.
    The WAP brings an important additional level of protection...

    2 hours ago, FranceBB said:

    How long is 9.x gonna be supported?

    The support schedule is available at https://support-eol.eset.com/en/policy_business/product_tables.html

    Peter

  2. Hello @j-gray,

    thank you for the feedback provided and the summary.

    I hope you have cases with the Support team opened to tackle them together.

    When it comes to the #1 it is a think of ESET PROTECT management platform as well as the #3.

     

    When it comes to the issues with the EI activation, the support team would need 

    1. enable the ECP logging 

    2. send the activation task and wait until it finishes; mark the UUID of the activation task

    3. collect the logs from a client, where the activation task was sent, but was not activated

    4. Update / open a new ticket with the Support team to have it checked.

    Peter

  3. Hello @xiaowu

    the error should be only temporary, see https://support.eset.com/en/kb7297-resolve-act-or-ecp-errors-during-activation-home-users

    0x00030000 (macOS)
    0x1003000d (macOS)

    We could not reach the activation server

    This error commonly occurs when your computer is not properly connected to your network and your internet connection is not active.

    Verify you have an active internet connection

    Your ESET product is having trouble connecting to the ESET servers. Verify that your computer has an active internet connection by going to https://www.eset.com.

  4. Hello @FranceBB,

    I understand your frustration, but from our past experience it was really needed to list systems, on which our products bas been tested and are supposed to work as expected. With the vast amount of Linux distros it's not feasible to support all of them, as it is a wild place :D 

    22 hours ago, FranceBB said:

    Unfortunately Fedora is not a supported operating system and while the software may work when installed, it is not fully tested and we cannot guarantee all functionality will work.

    Don't tell anyone 😉, but I recommend to set it up on a supported distribution to check if the issue is the same and if yes, report a ticket from it.

    I guess that the solution / work-around will be than same for the Linux distribution of your choice 😉 

    Peter

  5. Hello @SALC,

    On 7/14/2023 at 2:14 PM, SALC said:

    1) why won't make any sense to use VPN? We plan to roll out new devices (managed) for all employees and that will be a good oportunity to setup everything from scratch. It will give us an extra security layer for agent-server communication

    VPN is a great tool, but from my PoV to use it just to secure the EP server <-> agent communication would be cracking a nut with a sledgehammer

    On 7/14/2023 at 2:14 PM, SALC said:

    2) I have seen that it's possible to use squid, place the server and agents certificates there so they are checked on proxy side. That's it's tedious to be sincere and that's something I would like to avoid... Also, I do not see the benefit of using squid and check the certificates. Supossedly that's what agent-server do when communicating each other

    I'm afraid that the checking of the agent's certificate on the proxy level is not possible, at least not easy to achieve, see the links on the end of my post

    On 7/14/2023 at 2:14 PM, SALC said:

    3) I haven't been able to run ESET Proxy (Apache) or ESET bridge with authentication (not sure if you meant that). I configured a policy (and also in the installer) the proxy but I always get 407 and agents are not able to connect to the server (and therefore does not appear as devices)

    I recommend to check it with the support.

    On 7/14/2023 at 2:14 PM, SALC said:

    4) Cloud option is quite expensive compared to the price we are paying at the moment (minimum 100 nodes, +-3600K for 1 year)

    Sure the cloud license brings some additional costs, but many benefits as well - like to do not need to host the EP infrastructure and do not need to keep it updated / maintained.

    On 7/14/2023 at 2:14 PM, SALC said:

    5)When you say, teams are taking care of it. You mean the service itself or some other security around it?.
    I do not like the idea of having this service publicly available (even if we 2FA)

    I meant of the proxies in this case 🙂 

    Additional details on the EP server <-> agent communication can be found in the posts by MartinK

    https://forum.eset.com/topic/27187-securing-port-2222-on-sonicwall-firewall-to-allow-remote-connections-to-esmc-server-on-premise/

    https://forum.eset.com/topic/29496-public-facing-esmc-port-2222/

    https://forum.eset.com/topic/24859-management-protocol-reverse-proxy/

     

     

    Peter

  6. Hello @SALC,

    5 minutes ago, SALC said:

    EsetBridge listens in "ep.domain.com:3128" (server reachable from internet) and should redirect connections to "eset.int.domain.com:2222" (which it's only available from the internal network and also reachable from ep.domain.com).

    I configured an Agent policy (that's used in the Agent installer) with the proxy details.
    After I install the agent in a device out of the internal network, does not appear in the ESET Server. I get 403 in the logs
    AGENT_IP - - [17/Jul/2023:13:44:39 +0200] "CONNECTeset.int.domain.com:2222 HTTP/1.0" 403 146 "-" "grpc-httpcli/0.0".

    User and password for the proxy are well configured so I'm not sure why I get a 403...

    I recommend to open a support ticket to have it checked, provide the with the configuration of the proxy, policy of the agent and the log from the proxy to have it checked.

    Peter

  7. Hello @SALC,

    well yes the VPN would be a very good solution, but deploying it for this purpose only probably does not make a sense.

    As far as I know it is not possible to verify the agent certificate on the proxy, but you can set up the proxy with an authentication, set it up in the agent's policy so the agents will connect to the on-prem server via it.

    Or you can migrate to the cloud version, where are teams are taking care of it 😉 

    Peter

  8. Hello @cyb,

    I found a similar case from the past

    This behavior might be a security feature of the underlying authentication protocol (see https://docs.microsoft.com/en-us/dotnet/framework/wcf/feature-details/extended-protection-for-authentication-overview). 

    We recommend to create an exception on the affected endpoints (this is the preferred solution):

    1. Open the following configuration path: Web and email -> SSL/TLS -> List of known certificates
    2. Click Add, URL, enter extwadfs2v.seas.sk (alternatively you can import the certificate manually by clicking File)
    3. Change Scan action to Ignore

    Peter
    note for us: P_EESW-2983

×
×
  • Create New...