----------------------------------------
This article is provided free by
Stealth IT Solutions Limited
It is free for non-distribution only.
Due to the nature of this data it may
not be edited, no data may be removed
including this text.
With thanks to admin0
myshashi2010@yahoo.com
No responsibility is accepted or implied
Proceed at your own risk
------http://www.stealthhosts.com-------
#securing php and cgi
We all offer CGI and PHP and these powerful scripts are often mis-used to do an internal scanning of the server, read files here and there, write and compile exploits and execute those. Though there are a lot of options available, I will just mention an overall easy steps that everyone can follow:
PHP
login to your WHM
again,
and build your apache. You will be pretty safe with phpsuexec and open_base_dir restriction for php.
Additional Option :
However, if you want to restrict PHP even more, edit your php.ini and put the following lines:
which will disable the mentioned commands and any other command that you want to disable as mentioned in that line.
You can disable any command such way.
CGI
Perl is a very powerful language. C is called the grand-mother of all languages while Perl is regarded as the god-mother of all languages, which means, if there is anything not possible or easy to do with any other language, you can do it in perl. Thus, offering cgi-bin to your customers means giving them the power of perl.
Let me give you a real world practical example:
any one of your user in the cpanel server can upload the cgi-telnet script (http://www.rohitab.com/cgiscripts/cgitelnet.html) in any directory of his /home/username/www/*anywhere and walk your whole system. He can view/download files like /etc/passwd, /usr/local/apache/conf/httpd.conf and a lot of other things that we don't want them to know, and sometimes in some systems view /home/someone/public_html/forum/include/connect.php given that he knows the path for the file.
Though there is no fixed procedure as in the above case like php, however, there are ways to restrict the use of cgi.
first, we backup our apache.conf file
Download mod_security from
http://www.modsecurity.org/
then,
edit /usr/local/apche/conf/httpd.conf and insert the following:
You can include that anywhere. In case of my servers, I put those right above the <IfModule mod_setenvif.c>
after that,
Now, everything that we include after SecFilter is filtered by mod_security.
Thus, the first SecFilter /boot will prevent any cgi from doing ls /boot or cd /boot etc and the second /boot/ will prevent anyone from doing ls /boot/vmlinuz* .
Note:
Please not that I have not included /bin/ and /usr/. Since some valid users need cgi to do most of their things like creating files, moving files, deleting files etc, basic commands like mv, touch, rm, cp etc reside in /bin and some tools in /usr/bin. Thus, putting /usr/ and /bin/ in SecFilter will prevent legitimate users. Also /home/ is not included. You know the reason why now, don't you?
Please play around with your setting and use those that you need. The above is just an example of a typical system. Copy/Paste of the above might NOT work as expected for your users. Please visit
http://modsecurity.org/ for more information
Conclusion
With PHP and CGI secured, you have made your system a lot more secure. Securing PHP and CGI will prevent hacking from using cgi and php. Though this does not offer 100% protection from CGI/Perl, it gives you more than enough control over what cgi can do and what it cannot do.
This article is provided free by
Stealth IT Solutions Limited
It is free for non-distribution only.
Due to the nature of this data it may
not be edited, no data may be removed
including this text.
With thanks to admin0
myshashi2010@yahoo.com
No responsibility is accepted or implied
Proceed at your own risk
------http://www.stealthhosts.com-------
#securing php and cgi
We all offer CGI and PHP and these powerful scripts are often mis-used to do an internal scanning of the server, read files here and there, write and compile exploits and execute those. Though there are a lot of options available, I will just mention an overall easy steps that everyone can follow:
PHP
login to your WHM
HTML:
Click Tweak Security [server setup group]
Click php open_basedir tweak
and select Enable php open_basedir Protectionagain,
HTML:
Click Update Apache [software group]
select PHP suEXEC Supportand build your apache. You will be pretty safe with phpsuexec and open_base_dir restriction for php.
Additional Option :
However, if you want to restrict PHP even more, edit your php.ini and put the following lines:
Code:
disable_functions = phpinfo ,system, include, chown, chmod, exec, passthru, mail, readfile , dir , read, readdirwhich will disable the mentioned commands and any other command that you want to disable as mentioned in that line.
You can disable any command such way.
CGI
Perl is a very powerful language. C is called the grand-mother of all languages while Perl is regarded as the god-mother of all languages, which means, if there is anything not possible or easy to do with any other language, you can do it in perl. Thus, offering cgi-bin to your customers means giving them the power of perl.
Let me give you a real world practical example:
any one of your user in the cpanel server can upload the cgi-telnet script (http://www.rohitab.com/cgiscripts/cgitelnet.html) in any directory of his /home/username/www/*anywhere and walk your whole system. He can view/download files like /etc/passwd, /usr/local/apache/conf/httpd.conf and a lot of other things that we don't want them to know, and sometimes in some systems view /home/someone/public_html/forum/include/connect.php given that he knows the path for the file.
Though there is no fixed procedure as in the above case like php, however, there are ways to restrict the use of cgi.
first, we backup our apache.conf file
Code:
cp /usr/local/apache/conf/httpd.conf /usr/local/apache/conf/httpd-backup.confDownload mod_security from
http://www.modsecurity.org/
Code:
tar zxvf mod_security-*.*.*.tar.gz
cd mod_security-*.*.*/
cd apache1/ (or apache2/
/usr/local/apache/bin/apxs -cia mod_security.cthen,
edit /usr/local/apche/conf/httpd.conf and insert the following:
Code:
<IfModule mod_security.c>
SecFilterEngine On
SecFilterCheckURLEncoding On
SecFilterForceByteRange 0 255
SecAuditEngine RelevantOnly
SecAuditLog logs/audit_log
SecFilterDebugLog logs/modsec_debug_log
SecFilterDebugLevel 0
SecFilterScanPOST On
SecFilterDefaultAction "deny,log,status:406"
SecFilter /boot
# SecFilter /bin
SecFilter /dev
SecFilter /etc
SecFilter /initrd
SecFilter /lib
SecFilter /lost+found
SecFilter /misc
SecFilter /mnt
SecFilter /proc
SecFilter /root
SecFilter /sbin
SecFilter /scripts
SecFilter /tmp
# SecFilter /usr
SecFilter /usr/local/apache
SecFilter /usr/local/cpanel
SecFilter /usr/local/mysql
SecFilter /var
SecFilter /boot/
# SecFilter /bin/
SecFilter /dev/
SecFilter /etc/
SecFilter /initrd/
SecFilter /lib/
SecFilter /lost+found/
SecFilter /misc/
SecFilter /mnt/
SecFilter /proc/
SecFilter /root/
SecFilter /sbin/
SecFilter /scripts/
SecFilter /tmp/
# SecFilter /usr/
SecFilter /usr/local/apache/
SecFilter /usr/local/cpanel/
SecFilter /usr/local/mysql/
SecFilter /var/
SecFilter /bin/cc
SecFilter /bin/gcc
SecFilter "\.\./"
SecFilter "<[[:space:]]*script"
SecFilter "<(.|\n)+>"
SecFilter "delete[[:space:]]+from"
SecFilter "insert[[:space:]]+into"
SecFilter "select.+from"
#SecFilterSelective "HTTP_USER_AGENT|HTTP_HOST" "^$"
</IfModule>after that,
Code:
/scripts/restartsrv httpdThus, the first SecFilter /boot will prevent any cgi from doing ls /boot or cd /boot etc and the second /boot/ will prevent anyone from doing ls /boot/vmlinuz* .
Note:
Please not that I have not included /bin/ and /usr/. Since some valid users need cgi to do most of their things like creating files, moving files, deleting files etc, basic commands like mv, touch, rm, cp etc reside in /bin and some tools in /usr/bin. Thus, putting /usr/ and /bin/ in SecFilter will prevent legitimate users. Also /home/ is not included. You know the reason why now, don't you?
Please play around with your setting and use those that you need. The above is just an example of a typical system. Copy/Paste of the above might NOT work as expected for your users. Please visit
http://modsecurity.org/ for more information
Conclusion
With PHP and CGI secured, you have made your system a lot more secure. Securing PHP and CGI will prevent hacking from using cgi and php. Though this does not offer 100% protection from CGI/Perl, it gives you more than enough control over what cgi can do and what it cannot do.
