1. Firewall Installation
Installing firewall and various other related tools such as CSF, sim. These will prevent unauthorized access to your server and from brute force attacks.
CSF (ConfigServer Firewall) http://www.configserver.com/free/csf/install.txt
LES (Linux Environment Security) R-fx Networks - Internet Security Solutions - Projects » LES
SIM (System Integrity Monitor) R-fx Networks - Internet Security Solutions - Projects » SIM
these do not prevent exploits of services which you run on your VPS server. Also you need to be aware of the installed firewall and you need to open up the additional ports as needed if you add new services/program.
2. Installing Rkhunter (RootKit Hunter)
Rkhunter is a very useful security scanning tool that is used to scan for trojans, rootkits, backdoors, local exploits and other security problems. It can be useful to detect any failures in your layers of defense. It’s a cron job that scans your server for security problems.
You can install rootkit using following steps.
====
a. Login to your server via SSH as root.
[root@support007 ~]# cd /usr/local/src/
b. Download latest RKHunter Version [1.3.2]
[root@support007 ~]# wget rkhunter.1.3.2.tar.gz
c. Extract files
[root@support007 ~]# tar -xzvf rkhunter-1.3.2.tar.gz
d. [root@support007 ~]# cd rkhunter-1.3.2
e. [root@support007 ~]# ./installer.sh
f. Now setup RKHunter to e-mail you daily scan reports.
[root@support007 ~]# pico /etc/cron.daily/rkhunter.sh
Add The Following Lines:
Please refer the following URL for more details on Rootkit Hunter
3. Securing /tmp partition
Most of the attacks and exploits use /tmp to work out of any propagate themselves. By mounting /tmp with noexec and nosuid (meaning executables cannot be run from /tmp nor with escalated privileges), this stops many of these exploits from being able to do any harm.
You can do it by adding following entry in "/etc/fstab"
save the file and reboot the VPS, now vps get mounted with "nosuid" and "noexec"
4. Upgrade Apache/PHP, MySQL to latest version
make sure your running the latest secure versions of commons software components. This is the important step in preventing your server getting cracked by common exploits. There will be no problem in up-gradation, but if you have specific version requirements for particular applications, some upgrades should be made with caution.
5. Installing Mod_Security
ModSecurity is an open source intrusion detection and prevention engine for web applications and helps in preventing attacks on programs that would be vulnerable, it acts as a powerful shielding application from attacks. ModSecurity supports both branches of the Apache web server.
This can be fine tuned, but you may limit some "power" user customers (easily rectified). ModSecurity: Open Source Web Application Firewall
6. Enabling PHP suEXEC
When PHP runs as an Apache Module it executes as the "user/group" of the webserver which is usually "nobody" or "apache". Suexec is a mechanism supplied with Apache that allows to execute CGI scripts as the user they belong to, rather than Apache’s user. This improves security in situations where multiple mutually distrusting users have the possibility to put CGI content on the server.
This means the scripts are executed as the user that created them. If user "supp0rt" uploaded a PHP script, you would see it was "supp0rt" running the script when looking at the running processes on your server. It also provides an additional layer of security where script permissions can’t be set to 777 (read/write/execute at user/group/world level).
Note :-
Switching to the PHP Suexec module on the servers affects the users that depended on the configuration in the .htaccess file are panicking because their site not works anymore. This is not really a reason to be panic, what can you do in this situation is simple. Try to move as much configurations from your .htaccess file to the php.ini file. The php.ini is a simple text file that can be places in every directory from your server. It will affect only that directory and not the entire site. In addition, there could be some performance loss (also known as seeing a higher server load) as a result of all php scripts being ran as a separate CGI instead of as part of the Apache module.
7. Disable dangerous PHP functions
Some PHP functions are termed to be highly dangerous and these PHP functions should be left disabled in the configuration. Using an insecure PHP script as an entry point to a web hosting server can start unleashing dangerous commands and take control over the complete server.
Following is the complete list of such PHP functions which are needed to be disabled, so that it can't be executed from the server.
Locate the php.ini file of your server
Now edit this file,
Search for "disable_functions" [without quote] within that configuration file & modify it from disable_functions = to
Note :- Disabling above mentioned functions may affect your web-applications, it's recommended to recheck your code & find an alternative solution, rather than risking the complete server for a mere application
8. Securing MySQL Database
MySQL is one of the most popular databases on the Internet and it is often used in conjunction with PHP. Besides its undoubted advantages such as easy of use and relatively high performance, MySQL offers simple but very effective security mechanisms. Unfortunately, the default installation of MySQL, and in particular the empty root password and the potential vulnerability to buffer overflow attacks, makes the database an easy target for attacks.
9. Disable non-root access to unsafe binaries.
Many exploits use well known executables already on your system as part of their bag of tools. By allowing only privileges to root to these files, you can avoid many attacks to not function.
You may find some binaries like "wget, lynx, scp" too useful to limit access to root only, despite being useful to crackers too.
10. Changing SSH Port
One common security precaution that system admins use is to set ssh to listen on a non-standard port (e.g. port 9989, 9898, etc). It is common for hackers to attempt ssh daemon exploits that tend to be very specific to the version of openssh that is running. By having sshd listen to a different port, instead, then you are reducing the risk of a general port 22 scan and hack. Changing port is an additional layer of security. Although this is a kin to security by obscurity, it can let you completely avoid many script attacks.
11. Disable SSH root access
Allowing the root user to login directly is a major security issue, because a brute force attack can use the known username ‘root’ and concentrate on password variations. By using a unique username (not something like admin) you can reduce the chance of a successful brute force attack. This will force a hacker to have to guess 2 separate passwords to gain root access (you do have 2 separate passwords for unique user’s and root right)
Reference: http://www.eukhost.com/forums/f29/hardening-php-apache-6466/
Installing firewall and various other related tools such as CSF, sim. These will prevent unauthorized access to your server and from brute force attacks.
CSF (ConfigServer Firewall) http://www.configserver.com/free/csf/install.txt
LES (Linux Environment Security) R-fx Networks - Internet Security Solutions - Projects » LES
SIM (System Integrity Monitor) R-fx Networks - Internet Security Solutions - Projects » SIM
these do not prevent exploits of services which you run on your VPS server. Also you need to be aware of the installed firewall and you need to open up the additional ports as needed if you add new services/program.
2. Installing Rkhunter (RootKit Hunter)
Rkhunter is a very useful security scanning tool that is used to scan for trojans, rootkits, backdoors, local exploits and other security problems. It can be useful to detect any failures in your layers of defense. It’s a cron job that scans your server for security problems.
You can install rootkit using following steps.
====
a. Login to your server via SSH as root.
[root@support007 ~]# cd /usr/local/src/
b. Download latest RKHunter Version [1.3.2]
[root@support007 ~]# wget rkhunter.1.3.2.tar.gz
c. Extract files
[root@support007 ~]# tar -xzvf rkhunter-1.3.2.tar.gz
d. [root@support007 ~]# cd rkhunter-1.3.2
e. [root@support007 ~]# ./installer.sh
f. Now setup RKHunter to e-mail you daily scan reports.
[root@support007 ~]# pico /etc/cron.daily/rkhunter.sh
Add The Following Lines:
Quote:
| #!/bin/bash (/usr/local/bin/rkhunter –update && /usr/local/bin/rkhunter -c –cronjob 2>&1 | mail -s "RKhunter Scan Details" supp0rt@eukhost.com) Replace the e-mail above with your e-mail. It is best to send the e-mail to an e-mail off-site so that if the server is compromised then hacker can’t erase the scan reports. Type: chmod 700 /etc/cron.daily/rkhunter.sh |
3. Securing /tmp partition
Most of the attacks and exploits use /tmp to work out of any propagate themselves. By mounting /tmp with noexec and nosuid (meaning executables cannot be run from /tmp nor with escalated privileges), this stops many of these exploits from being able to do any harm.
You can do it by adding following entry in "/etc/fstab"
Quote:
| none /tmp tmpfs nodev,nosuid,noexec 0 0 |
4. Upgrade Apache/PHP, MySQL to latest version
make sure your running the latest secure versions of commons software components. This is the important step in preventing your server getting cracked by common exploits. There will be no problem in up-gradation, but if you have specific version requirements for particular applications, some upgrades should be made with caution.
5. Installing Mod_Security
ModSecurity is an open source intrusion detection and prevention engine for web applications and helps in preventing attacks on programs that would be vulnerable, it acts as a powerful shielding application from attacks. ModSecurity supports both branches of the Apache web server.
This can be fine tuned, but you may limit some "power" user customers (easily rectified). ModSecurity: Open Source Web Application Firewall
6. Enabling PHP suEXEC
When PHP runs as an Apache Module it executes as the "user/group" of the webserver which is usually "nobody" or "apache". Suexec is a mechanism supplied with Apache that allows to execute CGI scripts as the user they belong to, rather than Apache’s user. This improves security in situations where multiple mutually distrusting users have the possibility to put CGI content on the server.
This means the scripts are executed as the user that created them. If user "supp0rt" uploaded a PHP script, you would see it was "supp0rt" running the script when looking at the running processes on your server. It also provides an additional layer of security where script permissions can’t be set to 777 (read/write/execute at user/group/world level).
Note :-
Switching to the PHP Suexec module on the servers affects the users that depended on the configuration in the .htaccess file are panicking because their site not works anymore. This is not really a reason to be panic, what can you do in this situation is simple. Try to move as much configurations from your .htaccess file to the php.ini file. The php.ini is a simple text file that can be places in every directory from your server. It will affect only that directory and not the entire site. In addition, there could be some performance loss (also known as seeing a higher server load) as a result of all php scripts being ran as a separate CGI instead of as part of the Apache module.
7. Disable dangerous PHP functions
Some PHP functions are termed to be highly dangerous and these PHP functions should be left disabled in the configuration. Using an insecure PHP script as an entry point to a web hosting server can start unleashing dangerous commands and take control over the complete server.
Following is the complete list of such PHP functions which are needed to be disabled, so that it can't be executed from the server.
Locate the php.ini file of your server
Quote:
| [root@support007 ~]# php -i | grep php.ini Configuration File (php.ini) Path => /usr/local/lib Loaded Configuration File => /usr/local/lib/php.ini [root@support007 ~]# |
Quote:
| [root@support007 ~]# pico /usr/local/lib/php.ini |
Quote:
| disable_functions = "system,passthru,exec,popen,proc_close,proc_ge t_st atus,proc_nice,proc_open,proc_terminate,shell_exec ,highlight_file,escapeshellcmd,define_syslog_varia bles,posix_uname,posix_getpwuid,apache_child_termi nate,posix_kill,posix_mkfifo,posix_setpgid,posix_s etsid,posix_setuid,escapeshellarg,posix_uname,ftp_ exec,ftp_connect,ftp_login,ftp_get,ftp_put,ftp_nb_ fput,ftp_raw,ftp_rawlist,ini_alter,ini_restore,inj ect_code,syslog,openlog,define_syslog_variables,ap ache_setenv,mysql_pconnect,eval,phpAds_XmlRpc,phpA ds_remoteInfo,phpAds_xmlrpcEncode,phpAds_xmlrpcDec ode,xmlrpc_entity_decode,fp,fput" |
8. Securing MySQL Database
MySQL is one of the most popular databases on the Internet and it is often used in conjunction with PHP. Besides its undoubted advantages such as easy of use and relatively high performance, MySQL offers simple but very effective security mechanisms. Unfortunately, the default installation of MySQL, and in particular the empty root password and the potential vulnerability to buffer overflow attacks, makes the database an easy target for attacks.
9. Disable non-root access to unsafe binaries.
Many exploits use well known executables already on your system as part of their bag of tools. By allowing only privileges to root to these files, you can avoid many attacks to not function.
You may find some binaries like "wget, lynx, scp" too useful to limit access to root only, despite being useful to crackers too.
10. Changing SSH Port
One common security precaution that system admins use is to set ssh to listen on a non-standard port (e.g. port 9989, 9898, etc). It is common for hackers to attempt ssh daemon exploits that tend to be very specific to the version of openssh that is running. By having sshd listen to a different port, instead, then you are reducing the risk of a general port 22 scan and hack. Changing port is an additional layer of security. Although this is a kin to security by obscurity, it can let you completely avoid many script attacks.
11. Disable SSH root access
Allowing the root user to login directly is a major security issue, because a brute force attack can use the known username ‘root’ and concentrate on password variations. By using a unique username (not something like admin) you can reduce the chance of a successful brute force attack. This will force a hacker to have to guess 2 separate passwords to gain root access (you do have 2 separate passwords for unique user’s and root right)
Reference: http://www.eukhost.com/forums/f29/hardening-php-apache-6466/
