How to setup Litespeed LSWS for a shared environment?

Is there a subject matter expert that can guide me on how to setup LSWS for a secure shared webserver. I know that is a blind request, but let me explain what happened in the past. I host some friends and so forth. We one friend shared his cpanel with his partner whom had his identity stolen. Then this unknown decided to upload some script which allowed him to gain access to the root of the server, and virtually deleted everthing; leaving me with a ton of refunds and headaches for over a month. I was using LSWS at the time, however I don't know why mod_security didn't catch the script.

Please tell me what you need to know to give me the information I need, and I will provide it.

Is there a subject matter expert that can guide me on how to setup LSWS for a secure shared webserver. I know that is a blind request, but let me explain what happened in the past. I host some friends and so forth. We one friend shared his cpanel with his partner whom had his identity stolen. Then this unknown decided to upload some script which allowed him to gain access to the root of the server, and virtually deleted everthing; leaving me with a ton of refunds and headaches for over a month. I was using LSWS at the time, however I don't know why mod_security didn't catch the script.

Please tell me what you need to know to give me the information I need, and I will provide it.

Click to expand...

mod_security defects some malicious scripts but there is a lot of CGI/PHP shells which mod_security couldnt detect, r57 phpshell for example

to secure your shared hosting you have to secure php in parallel of webserver/mod_security

all php shells are based on some malicious functions such as exec, system, passthru, shell, shell_exe, ... which should be disabled for security reasons, so all phpshells would be killed on your server

open_basedir is one of most important options should be set for each VHost which will jail php functions into VH's documentroot, so functions such as fopen, readdir and another file functions would be restricted just to the same VH and not available to another VHs

mod_security defects some malicious scripts but there is a lot of CGI/PHP shells which mod_security couldnt detect, r57 phpshell for example

to secure your shared hosting you have to secure php in parallel of webserver/mod_security

all php shells are based on some malicious functions such as exec, system, passthru, shell, shell_exe, ... which should be disabled for security reasons, so all phpshells would be killed on your server

open_basedir is one of most important options should be set for each VHost which will jail php functions into VH's documentroot, so functions such as fopen, readdir and another file functions would be restricted just to the same VH and not available to another VHs

safe_mode and suhosin are another tricks to increase php security

Click to expand...

Just want to mention that its very hard to escalate nobody prvileges to root using PHP, indeed most of local privilege escalation to root need suitable shell environment such as bash/bin, so you should disable shell access too

i suggest you install http://www.configserver.com/cp/csf.html firewall which is a powerfull firewall compatible with mod_security audits with a lot of security measures
after you installed CSF go and Check your server security, it will tell you your security score and how to increase your server security to highest level

Mod_security audit_log has been implemented in LSWS 4.0 also, you can set your audit_log path in CSF and check for security logs there which is very userfriendly, or set LFD rules in your CSF configuration to block attackers automatically

I suggest you restrict your SSH and WHM daemons only to your own IP addresses if its static, or to your range if dynamic in WHM -> Security Center -> Host Access Control
If you allow your own IP addresses and DENY ALL no one can access into your server even with root pw!

Also upgrade to mysql5 if you are on mysql4, there are vulnerabilities in mysql4 which attacker can bypass open_basedir and access files out of its home, there is a lot of performances in mysql5 either

Now you may upload some phpshells and make sure they are fully killed
common phpshells are available here: www[dot]shellci[dot]biz

I did everything you said and then I had a friend find some of the most common scripts that cause trouble, and we uploaded them to a mock site we setup and they were stopped dead in their tracks. Furthermore, CSF blocked the ip's automatically via LFD. I am truly amazed and overwhelmingly thankful for your help!

Still no luck.
Because fantastico need php_uname, shell_exec, and system are enable on php.ini.
So the c99 can ls, ls -al, and cat accross to other vhost again

Click to expand...

Fantastico should be using cPanel's PHP not the system one. So you should not have to enable those functions for fantastico to work properly. If it's using the system PHP you should run /scripts/makecpphp and it'll rebuild the cpanel php.

I did everything you said and then I had a friend find some of the most common scripts that cause trouble, and we uploaded them to a mock site we setup and they were stopped dead in their tracks. Furthermore, CSF blocked the ip's automatically via LFD. I am truly amazed and overwhelmingly thankful for your help!

Fantastico should be using cPanel's PHP not the system one. So you should not have to enable those functions for fantastico to work properly. If it's using the system PHP you should run /scripts/makecpphp and it'll rebuild the cpanel php.

Click to expand...

Fantastico uses the main php.ini file located /usr/local/lib/php.ini while LS uses LSPATH/lsphpx/lib/php.ini by default

Fantastico should be using cPanel's PHP not the system one. So you should not have to enable those functions for fantastico to work properly. If it's using the system PHP you should run /scripts/makecpphp and it'll rebuild the cpanel php.

Click to expand...

Thank you for explanation.
Could you told me the path for system php.ini?

Fantastico uses the main php.ini file located /usr/local/lib/php.ini while LS uses LSPATH/lsphpx/lib/php.ini by default

Click to expand...

If the user is using cPanel and used the build matching PHP they'd use /usr/local/lib/php.ini which matches the CLI built by cPanel.

cPanel's PHP which would be used by Fantastico since the installer runs within the cPanel system would be /usr/local/cpanel/3rdparty/etc/php.ini . The cPanel PHP can be found at /usr/local/cpanel/3rdparty/bin/php and is used by anything PHP related ran within WHM or cPanel.

But... after I edit /usr/local/lib/php.ini, it always changed for the phpinfo() value on /home/user/public_html/phpinfo.php
Is there something wrong with my installation?
I am still using the old php 5.2.8 from cpanel.

If the user is using cPanel and used the build matching PHP they'd use /usr/local/lib/php.ini which matches the CLI built by cPanel.

cPanel's PHP which would be used by Fantastico since the installer runs within the cPanel system would be /usr/local/cpanel/3rdparty/etc/php.ini . The cPanel PHP can be found at /usr/local/cpanel/3rdparty/bin/php and is used by anything PHP related ran within WHM or cPanel.

But... after I edit /usr/local/lib/php.ini, it always changed for the phpinfo() value on /home/user/public_html/phpinfo.php
Is there something wrong with my installation?
I am still using the old php 5.2.8 from cpanel.

If the user is using cPanel and used the build matching PHP they'd use /usr/local/lib/php.ini which matches the CLI built by cPanel.

cPanel's PHP which would be used by Fantastico since the installer runs within the cPanel system would be /usr/local/cpanel/3rdparty/etc/php.ini . The cPanel PHP can be found at /usr/local/cpanel/3rdparty/bin/php and is used by anything PHP related ran within WHM or cPanel.

Click to expand...

I check for /usr/local/cpanel/3rdparty/etc/php.ini and found that disable_functions are totally empty there.