I've uploaded to my HestiaCP few popular web shells, and results pretty sad. All sites on Hestia can be hacked. How can we avoid that?

Community Support
1

I’ve uploaded to my HestiaCP a few popular web shells, and the results are pretty sad. All sites on Hestia can be hacked. It does not matter if the website is created on another user or multiple sites and multiple users. So how can we avoid that?

Long story short:
I will not post links to PHP shells. This is because they’re all ± equal in features.
The main idea behind this is that if the hacker somehow can upload a file and execute the file, he probably will get all access over the server/hestiaCP.

Question:
How to prevent that? How can HestiaCP restrict that? How make it harder to inject into the system?
What instruments are offered by Nginx/apache/PHP/MySQL and Linux files systems to restrict the negative side effects of web shells?

Discussion topic: HOW MAKE HESTIACP MORE SECURE OUT THE BOX?

1 Like
2

Let start here:

disable_functions = pcntl_alarm,pcntl_fork,pcntl_waitpid,pcntl_wait,pcntl_wifexited,pcntl_wifstopped,pcntl_wifsignaled,pcntl_wifcontinued,pcntl_wexitstatus,pcntl_wtermsig,pcntl_wstopsig,pcntl_signal,pcntl_signal_get_handler,pcntl_signal_dispatch,pcntl_get_last_error,pcntl_strerror,pcntl_sigprocmask,pcntl_sigwaitinfo,pcntl_sigtimedwait,pcntl_exec,pcntl_getpriority,pcntl_setpriority,pcntl_async_signals,pcntl_unshare,exec,system,passthru,shell_exec,proc_open,popen

3

Should those functions be disabled always by default?

4

“I left my car key plugged in, motor running and went away - now my car got stolen!!”… Hestia is out of the box already really secure and this, what you’ve done, isnt “hacking”. Basicly you’re right, if you place a webshell, you can use it - but first of all you need be able to place that webshell. This is only possible when the website itself got hacked, for example a wordpress installation. But in that case, it’s only possible to access that specific domain or website which got infected, not more, not less.

There are options, as @eris pointed already out, to hardly restrict hestia and make fort knox out of it - but there is always an opposite like compatibility of scripts, cms, and so on which could not run out of the box.

In my personal opinion, hestia is already secure enough for 99% of the use cases. If you want to reach a fort knox status, you can harden it even more - but this is something we should not do by default as explained above.

1 Like
5

If you want to get serious about security, apply the CIS benchmarks: CIS Benchmarks

6

Of course you can use any service without any risk of any hacking, even if it is vulnerable. All you have to do is bind that service to your own IP Address. Thats it.

For example, configure a special non-general port for your service. That service (here phpshell) will use that port. Then allow traffic on that port only for your IP Address. For anyone, that port is closed.

I use this method even for Hestia! I do not care if there are any security holes in Hestia.

I have used VestaCP for many years after it was dead. That script was vulnerable. At the time when many users were reporting that their VestaCP was getting hacked, I did nto even look in my servers, if they were hacked. I did not need to.

For this, I have configured DynDNS. The IP of that DynDNS domain gets entered by CSF. If that fails, I have a background cron running to check if the oldIP and newIP are changed.

So the answer to your question is: YES YOU CAN USE ANY VULNERABLE SCRIPT, PROVIDED YOU SECURE IT!

I have now placed a feature request in a separate thread.