![](/s/cache/2e/bc/2ebc01124e9baa006bb71f23796f18b7.png)
+2
open_basedir on ajeniti V is not working properly
I seem to have an issue with openbasedir restrictions not being in effect. yesterday one of my clients workpress installs got hacked, and overnight every php file in the entire /srv directory for all clients has:
<?php eval(gzinflate(base64_decode('<A bunch of code here>')));?>
in the interest of security and formatting i removed the code after the decode statement.
It seems that they managed to upload a php script which allowed them to edit files and upload files to that directory and it seems they were able to hit files that were outside that web directory as well:
based on this post: http://support.ajenti.org/topic/430340-open_basedir-for-ajenti-v-web-sites/ i know that ajenti SHOULD have properly implimented open_basedir so is there something ive missed here? while i wait for a reply ill be sanitizing a thousand php files by hand -_-
<?php eval(gzinflate(base64_decode('<A bunch of code here>')));?>
in the interest of security and formatting i removed the code after the decode statement.
It seems that they managed to upload a php script which allowed them to edit files and upload files to that directory and it seems they were able to hit files that were outside that web directory as well:
based on this post: http://support.ajenti.org/topic/430340-open_basedir-for-ajenti-v-web-sites/ i know that ajenti SHOULD have properly implimented open_basedir so is there something ive missed here? while i wait for a reply ill be sanitizing a thousand php files by hand -_-
Service d'assistance aux clients par UserEcho
If so, you put in, according to your file structure for PHP .ini values - like: open_basedir = /srv/http/0002:/tmp
firstly i made a list of infected files using this:
Then after unsucessfully using sed for a while i just used this php script which you should run using php5-cli
you should run the first command again after the php script as more than one version of the gzinflatecode may exist on the server and if that is the case repeat the php script placing the next infection string into the findWhat variable.
i did not write this php script myself, i found it online though i dont recall where (probably stack overflow tbh) but whoever the originator was is briliant, as it works great.
The FastCGI is not invoked automatically because sites that are not php based will require parameters for node.js, Python etc... I follow the WordPress procedures prescribed by Ajenti by Myles here on a WordsRack Nginx hardened set up.
it only makes sense, ESPECIALLY with ajenti V. V is designed for hosting. hosting means clients with accounts, those clients wont know better. Heck, I'm the admin and i didn't catch this. it seems unreasonable to allow those clients who don't know, to compromise the security of the rest of the server, including the clients who DO know. is there a value set up stopping open_basedir form leaving the /srv directory at least? if not, you are asking for a whole server to be compromised. anyone with fs access can do just about anything...
open_basedir = /srv/webroot/of/this/site:/tmp;
in the webistes section >> content tab >> php fast cgi >> php >> open_basedir = none;
in the php tab you can enter your php setting for your sites , by default the value of open basedir is none
and its ok, and dont have security problem
but if you need configure it , with your addithional setting , feel free and use it
please clean your meta, and install latest version of rpm
then update your system
sorry for my english, be happy