Hi, I am testing ispconfig3 for to decide if it's good solution for my servers. I see some security problems: 1. No limits resources per client (/etc/security/limits.conf). But is not critical because i can add "a check" if new client is added for create new limit config in crontab. 2. Bad permissions: Everybody can see all files of other clients. Yes, if we are using mod_php we can disable functions (exec, system, shell_exec, readfile, passthru, escapeshellcmd, proc_open, posix_uname, posix_getuid, posix_geteuid, posix_getgid, getcwdi, show_source, proc_open) But if we are using suexec, we dont have this limitation and our files aren't secure. 3. open_basedir is not implmented for mod_php option (safe_mod = On, is not useful for my) 4. We have full access to the root filesystem from php. I tried configure chroot on suphp but i didn't have good end. i Think we can configure this enviroment: /var/www/./var/www/<site>/./{bin,etc,lib,user,web,...} Explain: /var/./www/var/www/<site>/./{bin,etc,lib,user,web,...} Root file system. We can to have apache2 + mod_chroot + suexec + mysql here /var/www/./var/www/<site>/./{bin,etc,lib,user,web,...} This is a root chroot system installed by... hand?, debootstrap? /var/www/./var/www/<site>/./{bin,etc,lib,user,web,...} It's the root fs for ssh access. Its working very good For everything work, we must move original dirs from real fs / to chroot fs /var/www/ and after create ln. Example: mv /usr/local/ispconfig /var/www/usr/local/ispconfig ln -s /var/www/usr/local/ispconfig /usr/local/ispconfig The same for apache and php We dont need move mysql dir, but we wont use local scoket connection we must use tcp (127.0.0.1 or your real ip) CAREFUL when you update the system!!! maybe simbolic links will be removed! About the crontab for ispconfig user will work good i think. I didn't test this solution because i am searching solution for point 2 and 4. They are critical for me. Any idea for fix this problems? Thanks
1) This file is not used by ISPConfig and not needed for ISPConfig. If you want to use it for your server, feel free to do it or write a plugin for it. 2) The permissions are firn. If you dont allow reading then the apache server will stop to deliver .html files and images etc. For secure script execution e.g. use suphp with chrooting. Also you can disallow the same functions with suphp by setting a individual php.ini file per vhost. see suphp documentation for details. 3) If you want to add this then simply add it to the vhost template. 4) This is not working for hosting servers with more then a few websites, but if you want to implement this for your server, just write a new plugin. ISPConfig is easy extendable by plugins to enable administrators to configure their enviroment individually.
1) any user can do a while(1){ system("foobar &"); }, and freeze the server 2) Do you think is OK i can do "cat" (or if shell functions are disables include|require) from config.php of other client? It's a a blackhole in the server. FOR EXAMPLE: i checked 1and1 and i see it: hehe i dont understand why apache can read htdocs but it can. Maybe fix with suexec or similar. 3) OK 4) You can check 1and1 for example. I will try configure and post the final solution. i will try use the same binaries for all users (save storage)
1) I dont give untrusetde users SSH access anyway. But as I said, if you need it, feel free to implement it as a plugin and I will be glad to add this to the next ISPConfig release. 2) Its not ok of course. But you can prevent this by strict php settings. 4) I dont know the settings from 1and1. Its always easier to implement something if you just have one platform, ISPConfig supports debian, ubuntu, fedora, centos and suse (plus experimental support for gentoo in svn) so everything implemented here must work with all of these distributions. So implementing something like this as a separate plugin that uses debootstrap is fine but using this as the defualt setup can be a problem. You have to keep in mind that we have to deliver a setup with ispconfig that is secure but it has also to work for users. If you check the forum then you will find e.g. a lot of complaints because we do not set allowoverride to all and so many cms systems will not work without modifying the .htaccess file that comes with them. So if we setup a 100% secure system, it will either get unusable for the users or it will use very much resources e.g. by using a separate vm per client.
1) OK. i will try 2) Can you show me a example for prevent this problem only with php setting please? - suphp's chroot is a chroot for all users no per user. - open_basedir can be disbaled with user's php.ini 4) I understand you but NOW all installations have a very bad blackhole. With a simple LFI in any CMS, forum, blog we can see all configs/user/passwords of all clients of the server and maybe use it. I like can help for close this bug, because i like ISPconfig and i want install in my servers.
2) No, it cant be disabled with users php.ini as users can not set their own php.ini file. Just make a copy of your php.ini file, chown it to root and make it writable for root only and then specify it with 4) You can not see the files of other users if php correctly configured. Also every user can remove the world readable flag from sensible php files. But the world readable setting can not be removed from directories or htnl and image files as apache will not serve the file then.
Enabling exec is a security risk and exec is not needed by any common cms system, thats why you should idsable it in the custom php.ini. Same for things like passthru, popen etc. For custom php.ini, see: http://www.suphp.org/DocumentationView.html?file=apache/CONFIG
aha. my clients need it for bank transaction for example. Some banks provides a binary and must exec with ./binary arg1 arg2 arg3... And if i disable exec function i can use Include and/or require for read files of other clients. Some solution?
No, you cant as you had set open_basedir in the custom php.ini which restrict the access to the web directory of this specific client.
And one additional note: You can also chroot to the client directory: http://www.suphp.org/DocumentationView.html?file=CONFIG Just use the ${HOME} varaible in the chroot path.
Ok, your solution is: 1. Default instalation is VERY VULNERABLE, doesn't apply security for clients can not see files or other clients 2. Protecting: - Edit vhost template and add base_opendir sentence - In php.ini file disable this functions: disable_functions = exec, system, shell_exec, readfile, passthru, escapeshellcmd, proc_open, posix_uname, posix_getuid, posix_geteuid, posix_getgid, getcwdi, show_source, proc_open - Telling users dont use 755 or 644. better 750/640 Ok i think it's not good solution. 1. If i enable exec(), the users can browser everything of the server and private files of other clients 2. If exec is disables but open_basedir is not set, they can use include and/or require for see private files 3. both enables is badder blackhole. Do you have more solutions? Possible solution for ONLY use suphp is: set user:apachegroup and chmod 750/710 the rest of the users will exec php with user != apache, and apache can access to all homes. But i think is not optimal solution, because only can work with suphp no with the rest. ############# Use chroot per client is a crazy idea. We must duplicate all files like (php binaries and dependencies and other libreries). It use a lot of storage and bad for backups.
Try it out yourself and then you will see that it is not working when apache can not read the files. Suexec is only used for scripts, so if you enable suexec, apache is able to read scripts that are only readable by the client but apache will stop to serve html and image files. Sure, but there is no easy and optimal solution for such an setup. The more security you need and want then the slower it will get. Yes, and thats what you suggested... Now you know why I told you that this is not an option for a normal setup.
Ok, Thank you very much. You have a good support in this forum. If i find a good solution i will post here. Thanks
By the way ... Should'nt has the fastcgi starter the immutable bit set like? Code: lsattr php-fcgi-starter ----i------------- php-fcgi-starter At the moment it shows Code: lsattr php-fcgi-starter ------------------ php-fcgi-starter after activating fastcgi.
