How to provide Plesk Support Team with the direct access to the server?

Follow

Comments

10 comments

  • Avatar
    Mario

    Hi, 

    How can I list the installed keys to check if the process was successfully done?

    Thanks!

    0
    Comment actions Permalink
  • Avatar
    Artyom Baranov

    Hello Mario,

    You may use any text editor (like vi or vim) to open the file /root/.ssh/authorized_keys and find out if the key is there.

    Or you may use just less (less /root/.ssh/authorized_keys) or cat (cat /root/.ssh/authorized_keys)

    1
    Comment actions Permalink
  • Avatar
    Mario

    Hi, 

    Today I got these IP's from one of your colleagues:

    * 64.131.89.14
    * 91.204.24.0/24
    * 91.204.25.0/24
    * 91.204.26.0/24
    * 91.204.27.0/24

    * 195.214.232.10
    * 195.214.233.106
    * 195.214.233.155
    * 81.184.0.141
    * 195.214.234.4
    * 95.170.131.46

    * 203.32.4.0/26
    * 203.214.176.0/24
    * 80.237.178.180
    * 195.214.233.10
    * 195.214.233.8

     

    What's Plesk's current IP's/ranges to whitelist?

    Thanks!

    0
    Comment actions Permalink
  • Avatar
    Alexandr Bashurov

    Hi @Mario,

    You may find the most actual IP addresses in this exact article. They are as follows:

    • 195.214.233.0/24
    • 91.204.24.0/22
    • 203.32.4.0/26
    • 203.214.176.0/24
    • 80.237.178.180
    • 81.184.0.141
    • 95.170.131.46
    • 2A00:1730:FFF9::/48

    The current IP address ranges are almost the same as previous.
    Netmasks were changed to take less time to whitelist IPs in firewalls, and some outdated IP addresses were removed.

    0
    Comment actions Permalink
  • Avatar
    Michel vd Lingen

    Silly question, I am going to block several countries with ipset from our hardware nodes. This includes Russia.
    Now I noticed a week or two ago, Plesk couldn't connect to the server as a result of this.

    Now it's not clear; if I block a country with ipset and later on add the Plesk support IP's (as accepted IP's) is they can access the servers?
    In other words will the IP's in the ACCEPT list overrule the country block?

    Let me know. Thanks.

    1
    Comment actions Permalink
  • Avatar
    Nikita Nikushkin

    Hello @Michel vd Lingen,

    Yes, whitelist has to work

    Besides, you can allow connections for our IP addresses explicitly, however, make sure that these allowing rules are located before your blocking ones

    Also, if you have several firewalls allow connection for each

    0
    Comment actions Permalink
  • Avatar
    b_p

    From a security point fo view, I do have huge concerns of providing direct (unmonitored) access to a third party. May I suggest to think about adding the option of running a screen sharing session (e.g. TeamViewer) for such cases?

    Already from a privacy perspective (EU GDPR), we have to ensure that private data is appropriately protected (e.g. GDPR article 28 & 29) and that persons with access to personal data are well instructed (Article 32 paragraph 4, https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679&from=EN). So besides the fact that we actually might need to check if a data processing / confidentiality agreement needs to be signed, it would be great if we find a way that no unmonitored access needs to be granted.

    0
    Comment actions Permalink
  • Avatar
    Francisco Garcia

    Hi b_p,

    From one side, in order to access the server, we require first to sign and verify a DPA (Data Processing Agreement), only after that we can access a server.

    From the other side, we are all instructed on how to handle data according to GDPR, plus no data is taken out from the server without your explicit consent (for example, we don't download Backups, database dumps or files from the server). Also, we have internal audits for taking care of possible violations of GDPR, and in that case, the customer will be informed asap.

    And third, it's not required to share root credentials with the Support SSH extension, a new user with keys will be created (on Linux, for Windows it's possible to create an additional user within the Administrators group).

    Apart from that, and based on my experience, TeamViewer sessions are prone to delay (a lot) the investigation and resolution of issues, so it's not the recommended way, especially speaking when the Development team should be involved in the matter. Still, with a TV session, a DPA is required.

    I hope I could answer your doubt :)

    0
    Comment actions Permalink
  • Avatar
    b_p

    Hi Francisco Garcia

    Well, but even beyond GDPR, it is a matter of trust: I know quite a few people who would consider their servers to be compromised if they need to provide unmonitored access to a third party. And beyond trust, there is the issue of traceability: In order to understand side effects (or prevent follow-up requests), it is much preferred to have a full overview of what is done on the server.

    0
    Comment actions Permalink
  • Avatar
    Ivan Postnikov

    Hello b_p

    Thank you for sharing your thoughts.

    Server access isn't a "must". Issues investigation without access is also provided by Plesk support. However, such an investigation may take more time. However, it's a specific client to decide what rights are to be provided to Plesk for the investigation.

    Plesk as a company ensures that the process of investigation is transparent and nothing extra is done by support engineers on the server.

    Also, there're instruments to monitor all actions done on the server, for example https://unix.stackexchange.com/questions/84847/is-there-an-easy-way-to-log-all-commands-executed-including-command-line-argume

    0
    Comment actions Permalink

Please sign in to leave a comment.

Have more questions? Submit a request