The above example is not directly related to ispconfig or the use of ispconfig on a server, this is a general issue on site security for PHP scripts, just to make this clear to other readers.

If a php application allows such queries, then the php app has a bug as php apps should never include or access content that is passed to them as get variable without sanitizing the content. Nevertheless, I'am aware that such apps still exists. In ISPConfig, there is already a open_basedir restriction set for every website that restricts access to the web directory, so opening a file in /proc with php fopen or include / require functions should not be possible in the default configuration.

I just did a small test with this php file:

Code:

<?php
include($_GET['content']);
?>

and the output is as expected:

Code:

Warning: include() [function.include]: open_basedir restriction in effect. File(../../../../../../../../../../../../../../../proc/self/environ\0) is not within the allowed path(s): (/var/www/clients/client1/web1/web:/var/www/clients/client1/web1/tmp:/usr/share/php5) in /var/www/clients/client1/web1/web/test.php on line 2

You can enhance this protection by installing mod_security as you described in your post or add some apache directives and I really recommend that. I'am not sure what the performance impact of using mod_security on a server is, this should be evaluated to make a decision if we should include that in the default perfcet setup install or if its better to make a new general tutorial on techniques to secure php websites where we can explain in detail the pros and cons of the various options.

Modsecurity without rules don't help. It's very good mod. Impact on servers is usually memory, more rules more memory. Base rules are ok and memory use is acceptable. Ispconfig with open base restrictions, fastcgi and some php functions disabled is secure but again rfi, sql inyection, etc in some insecure aplications from any customer can be a disaster and that is because I use modsecurity.