Most web applications are fast installed and ready to use. But how do I protect the installation so that it is protected from possible attackers? Unfortunately, very few ask this question and are usually only confronted with the topic after their project has been hacked.
First of all, I would like to point out that 100% security will never exist. The board manufacturer can only stuff security holes that are known to him. But what about the security holes that are unknown to him? There are preventive measures, but there is always a certain security risk.
It should always be remembered that safety is only as valuable as the weakest link in the chain.
Safety also has its price:
high expenditure of time (import updates, do research, etc.)
Often it also affects performance (more database queries or PHP modules like modsecurity or Suhosin)
No matter how many security measures you have taken against potential attackers, the most important thing is always to have an up-to-date backup in case of an emergency. There are many backup solutions, but you should make sure that the backup is automated (who makes regular backups manually, especially in stressful situations, you will not take the time.)
Many webmasters still follow the motto "Never change a running system". If you operate your server project after this setting, sooner or later you will fall victim to a hacker.
Furthermore, it is also a mistake to rely on techniques according to the motto Security through obscurity . This includes, for example, that you hide the version number of the software or that you rename directories or files, so they are not found. These tactics do not really add to the security, but you make the attacker only the scouting the attacking computer. If additional correct security measures are taken, however, one can not object to these measures.
Ok, the hints below are for projects implemented with PHP. Therefore, these tips apply to many applications, such as vBulletin, Drupal, phpBB, OSCommerce and whatever they are called.
Then I will give further recommendations for certain applications.
Firewall
For some reason, even experienced administrators think that a firewall is superfluous. Their reasoning is usually that you should only run the services that you also need and therefore other ports are closed anyway.
So far that's true, but a firewall offers much more options than simply closing one port. For example, you can distinguish between an ICMP, UDP, or TCP request, you can also restrict outgoing connections, or define specific policies for well-defined applications. Another advantage of using a firewall is logging. It is very important that you can understand what's going on on the server. On the one hand, these log files can be used for further preventative measures, and on the other hand, they can be very helpful in finding out how an intruder got into the system.
There is no real reason not to use a firewall (except maybe laziness;).
The most recent version of PHP
It is particularly important to use the most recent version of PHP, since in all versions of PHP security vulnerabilities have been closed. Before that, however, you should make sure that all applications run flawlessly.
The latest MySQL version
Even with the database, you should use the latest version.
Operating system updates
The safest web server / database uses nothing if the underlying system contains security holes. Normally every Linux distribution offers more or less comfortable update mechanisms, like Yast, apt or emerge. It should be checked at regular intervals, if operating system updates are available and then they are also loaded.
Avoid multi-hosting systems, always prefer a dedicated server (or if you are not a Linux expert, a managed server ). The reason is quite simply that other users on the server can also be potential attackers and that you have to set the security settings looser on a multi-hosting system, because you must ensure that as many different applications to cope with it. If you use a server specifically for a specific purpose, you can optimize it especially for these requirements - this applies to both security-specific and performance-acting settings.
Improvement of PHP core security by Suhosin . Suhosin was designed to protect the server and users from known and unknown errors in PHP applications and the PHP core.
Reinforcement of PHP security to prevent malfunctioning or badly programmed programs by modsecurity (less suitable for multi-hosting systems). Furthermore, modsecurity provides excellent logging capabilities. The use of modsecurity will affect the performance of the server, which is why it is advisable to use a caching system such as APC or eAccelerator .
Disabling unnecessary services
All services (daemons) running on the server that are not in use should be disabled. If it is possible, you should also uninstall it immediately. Each additional service running on the server is another point of attack (unnecessary open ports!).
By default, MySQL ships with the mysql_secure_installation script, which allows you to automatically set some of the settings below.
Set password for root user
MySQL comes with the root account , which can be used without a password. This account should be assigned a password as soon as possible.
For example, you can assign the password as follows (you must be logged in as root for this example:
mysql mysql
UPDATE user SETPassword = PASSWORD ('secret') WHERE User = 'root';
FLUSH PRIVILEGES;
quit
It should of course be used for secret another password;)
Administrators Only allow accounts from localhost
All accounts that have rights to several or all databases (Admin Accounts) should only be able to be used via the host localhost .
Preventing database access from external computers If you do not need external access to the database and the database can be accessed via sockets, you can switch off the entire network functionality of the MySQL daemon under the section [mysqld] in the my.cnf file under the following statement:
skip-networking
If you need to allow external database access (which always poses a certain risk, since the server can be attacked by a brute force attack, for example), you should bind the server to a fixed IP address with the following statement (this is also in the section [ mysqld] in my.cnf):
bind-address = 192.168.0.1
Of course you have to use an IP of your server here. With the use of an external database, I recommend using an SSL connection, VPN or an SSH tunnel to encrypt the data.
If 127.0.0.1 is used as the IP (ie the local host), you can deactivate the name resolution with the following statement:
skip-name-resolve
Note: If skip networking is set, only one socket connection to the server is possible. If this option is not set and the IP address is bound to 127.0.0.1, a TCP / IP and a socket connection to the database server is possible (but only from localhost)
Limit erroneous queries If there is an error in the programming of a PHP script (eg wrong join), the database can work until it is dropped, and it will not be able to handle the request. To limit the number of results of a join, set the following option:
max_join_size = 20000000
This causes MySQL to break off the request after 20 million lines, preventing the server from wasting unnecessary resources.
Disabling all modules that are not needed
Each Apache module is another point of attack. Therefore, it is recommended that you do not load any modules that you do not need anyway.
If the server only hosts PHP applications, then you do not need to load a Perl module, for example. Modules that provide the attacker with information should generally be deactivated - this includes, for example, the status and info module. If only PHP comes from module to use, and also no Perl is needed, one can also use the modules cgi and perlfrom the configuration. The configuration is very different between the different Linux distributions. For example, SuSE uses the / etc / sysconfig / apache2 file to control the Apache configuration. Within this file, the APACHE_MODULES variable determines which Apache modules are to be loaded.
Hide information about the web server
By default, the web server sends information about the software used and its version number in the header of each output page.
For example, this information might look like this:
Server: Apache / 1.3.37 (Unix) PHP / 4.4.4 with Suhosin patch FrontPage / 5.0.2.4803 mod_fastcgi / mod_fastcgi-SNAP-0404142202 mod_ssl / 2.8.28 OpenSSL / 0.9.6i
To limit the output to "Server: Apache", set the following instruction in httpd.conf:
ServerTokens Prod
But again there are different possibilities of configuration. In SuSE you should set eg in the file / etc / sysconfig / apache the following setting, instead of manually editing the httpd.conf.
APACHE_SERVERTOKENS = "prod"
Security-
relevant settings do not belong in the .htaccess All security-relevant attitude should be integrated directly into the httpd.conf. The .htaccess files are very popular because you have activated the settings immediately without a web server restart. The danger here is that this file can also be manipulated by attackers or created / removed. On the other hand, the .htaccess file may be mistakenly easily overwritten during a project update - possibly without being noticed.
In current PHP versions, the security settings are already relatively well preset. Settings such as Register_Globals = On or similar are no longer the default settings. But you have to be careful with PHP packages that come with the Linux distributions. Here you should definitely compare the settings with the original php.ini-production .
In addition, the following changes should be made in the php.ini:
expose_php = Off
This means that the following line is not sent in the HTTP header:
X-Powered-By: PHP / 5.1.6-pl8-gentoo
This is not really a security setting, but you do not have to tell the attacker which php version to use. As you can see in this example, you can also see which Linux distribution is being used - information that is very useful to attackers.
display_errors = Off
This setting will no longer issue error messages about the web server. Instead, you can have all error messages written to a log file and this can be reviewed by the admin of the system from time to time.
To log the error messages to a file, the following two statements must be set:
log_errors = On
error_log = / var / log / php_error
The error message will be logged in the file / var / log / php_error.
Why is it a security issue when issuing error messages via the web server?
Quite simply, these error messages tell the attacker a lot of information about the server and also about the PHP application (eg the absolute path of the PHP script, from which you can possibly close again, where other files can be found on the server)
enable_dl = Off This setting prevents PHP scripts from loading modules automatically.
allow_url_include = Off This prohibits the use of URLs (such as http: // or ftp: //) in conjunction with include or required statements.
disable_functions = system, shell_exec, popen, pclose, proc_open, proc_close, proc_get_status, proc_nice, proc_terminate, exec, passthru, show_source, readfile, escapeshellcmd, escapeshellarg
All functions listed here are deactivated and can therefore no longer be used in PHP scripts. However, one must be careful here, since many scripts require some of these functions. So you should do tests, if the PHP applications are still working, if you exclude these functions.
Why should one exclude these functions?
Because this can circumvent the limitation of open_basedir.
open_basedir = "/ path / to / my / php / project"
Here you can specify which directories within a PHP script may be accessed. Caution is advised as certain functions do not comply with this restriction (see disable_functions). In this case, especially the extension curl called!
In future PHP versions, open_basedir and also safe_mode should be completely deleted from the feature list, since these can only be used to a limited extent as security measures. PHP security parameters will never be able to replace a web server jail root environment, these are / were just more convenient for the webmaster to implement.
Disabling PHP extensions
Most Linux distributions offer PHP extensions as additional packages that can be uninstalled at any time (shared libraries). Unfortunately, more modules are usually installed / activated than needed. Again, every unnecessary extension represents an unnecessary security risk.
So you should limit the number of required PHP extensions to a minimum.
Always use the latest (stable) software from the manufacturer.
Almost every software update also closes security holes. These security holes are also very often exploits, which also make it very easy for non-professionals to exploit vulnerabilities.
Use current extensions.
Many people seem to be unaware that if you install a mod / extension into your board, for example, this extension can pose a potential security hole. So it's just as important as the basic software to keep each extension up-to-date!
If the admin area is separated from the actual output area, you should protect the admin area with a .htaccess protection.
Backup files are not in the DOCUMENT_ROOT directory !!
The safest configuration becomes superfluous if one puts his backup files into the web directory, over which theoretically each user from the Internet could download these files. Since in the backup data in addition to the valuable data and the source files of the scripts are available, the hacker has everything he needs to launch an attack. The database password is well known in a configuration file, which the attacker has thus received.
Mostly backup.sql or backup.zip (or similar names) are used for the backup files, which is almost negligent.
You do it right by storing the backup files on another server or an external backup medium. Many server hosting providers have already integrated an external storage medium in the package bundle. If you really want to store the data on the same server, then this data must be stored outside the DOCUMENT_ROOT directory. So in a directory, which is not accessible via the web server.
Using phpMyAdmin with Password Protection
If you use phpMyAdmin for database management, make sure to use password protection. phpMyAdmin offers several authentication methods: config, http, HTTP, signon or cookie.
Using different passwords
You should use different passwords for each project, which is especially important when dealing with administrative accounts. Also, you should choose a different password for .htaccess protection than for normal login. As a password you should only use strong passwords to avoid brute force attacks (at least you can reduce the chance of guessing many times over). Passwords like phone number, dictionary entries or date of birth should not be used - but unfortunately this is still the norm among many users.
Minimize user access for admin access
Anyone who has access to the administration area of an application increases the security risk. This is not because you do not trust these users, but because human errors (such as social engineering) can occur. Since every admin user (as well as all other users) could have a Trojan on their PC who is busy logging everything that the user types in, one should really try to keep the group of people to a minimum.
