Resolved Server Hacked, How to fully secure it to avoid the hacking again?

[ITTECH]

Dears,
Hope you are doing well!

Kindly note that I have Linux server (Centos 7) with Plesk 17 (Onyx) which recently has been hacked.
So, I would like to know the security principle I can apply on the server to avoid the hacking again.

Kindly note that the hacker uses other websites on the server to create symlinks to the rest of the websites and to the root of server, how can we avoid that, please help.

I have disabled perl and python and turned on fail2ban but i didn't have any benefit of it.

best regards,

 

[Bitpalast]

Symlinks can only be created by a system command. This in turn requires that such a command becomes available to a hacker. If you have not disabled functions like exec() or shell_exec() in PHP, it is very easy to create a symlink.
These PHP functions should be disabled: exec, passthru, shell_exec, system, popen, show_source, pcntl_exec, proc_open, proc_terminate, proc_close, pfsockopen

Second, if you provide Perl, Python or other such dangerous things to customer accounts, this can also be abused to hack a server.

Third, execution permissions for the system temporary directory or partition must be disabled, else an attacker can run scripts from there.

Fourth, we have heard from some users that they provide a normal bash SSH shell to their users. Bad idea. SSH shell, if provided at all, must only be the chrooted shell.

Finally, the "FollowSymLinks" option should be disabled via Plesk GUI Apache settings of the subscription (or hosting plan), because this does not check whether the target permits the user. Instead, users should use "Options +SymLinksIfOwnerMatch" in their .htaccess files.

 

[ThomasV1]

oh hey Peter,

sounds really good!

maybe you can also explain how to do all this stuff exactly?

thank you very much
have a nice day
nice greetings from germany
Thoams

 

[ITTECH]

Hello thanks for your replay,
But i would like to know if i have disabled these php functions, would that affect my websites since they are all using PHP as programming language.
And would you please tell me from where i can manage the functions above.

Thanks in advance.
Best regards,

 

[Bitpalast]

Disabling PHP functions that require shell access will likely not affect websites, unless the websites are using these functions and require shell access. Typo3 for example uses imagemagick (the shell software, not the imagick PHP library), so this will not work. Normally websites should not require shell access, so most websites will work. You don't have a choice anyway. If you leave these functions active I guarantee that the server will be hacked, because it makes it super easy for hackers if they can execute shell commands through PHP.

For the other stuff mentioned I would like to leave the "how to" explanation to other forum users. These are all very basic Plesk and Linux administration tasks. Very simple to do, for example disabling FollowSymLinks simply by clicking the "Apache" settings icon in the subscription and choosing the chrooted shell is simply done in the hosting service plan template in GUI. Disabling the PHP functions can be done on the PHP settings page of the hosting service plan ("additonal configuraton directives: disable_functions = exec,passthru,shell_exec,system,popen,show_source,pcntl_exec,proc_open,proc_terminate,proc_close,pfsockopen"). Disabling temporary directory execution permissions is I think explained in the Plesk documentation on the Internet and in many articles online, e.g. Making /tmp non-executable , Mount the /tmp partition with ‘noexec’ and ‘nosuid’ options and Linux Security: Mount /tmp With nodev, nosuid, and noexec Options and others.

 

[learning_curve]

These PHP functions should be disabled: exec, passthru, shell_exec, system, popen, show_source, pcntl_exec, proc_open, proc_terminate, proc_close, pfsockopen

This was a useful list for us. Thx! One domain / e-commerce setup that we manage ourselves however, runs a package that specifically requires exec to be running on the server and popen is also required when called by source files if/when using the PHPMailer library option within the package. Seeing as this domain is under our own control (i.e no users are involved with this setup at all) we didn't see these two requirements being an issue. Your thoughts or any additional comments? @Peter Debik