Default configurations of systems, including operating systems and Web servers, are mostly created to demonstrate and highlight their basic or most relevant features, not to be secure or protect them from attacks.
Some common default configurations that may compromise the security are the default administrator accounts created when the database, web server, or CMS was installed, and the default administration pages, default error messages with stack traces, among many others.
In this recipe, we will cover the fifth most critical vulnerability in the OWASP top 10, Security Misconfiguration.
- If possible, delete all the administrative applications such as Joomla's admin, WordPress' admin, PhpMyAdmin, or Tomcat Manager. If that is not possible, make them accessible from the local network only; for example, to deny access from outside networks to PhpMyAdmin in an Apache server, modify the
httpd.conffile (or the corresponding site configuration file):<Directory /var/www/phpmyadmin> Order Deny,Allow Deny from all Allow from 127.0.0.1 ::1 Allow from localhost Allow from 192.168 Satisfy Any </Directory>
This will first deny access from all addresses to the
phpmyadmindirectory; second, it will allow any request from the localhost and addresses beginning with "192.168", which are local network addresses. - Change all administrators' passwords from all CMSs, applications, databases, servers, and frameworks with others that are strong enough. Some examples of these applications are:
- Cpanel
- Joomla
- WordPress
- PhpMyAdmin
- Tomcat manager
- Disable all unnecessary or unused server and application features. On a daily or weekly basis, new vulnerabilities are appearing on CMSs' optional modules and plugins. If your application doesn't require them, there is no need to have them active.
- Always have the latest security patches and updates. In production environments, it may be necessary to set up test environments to prevent failures that leave the site inoperative because of compatibility issues with the updated version or other problems.
- Set up custom error pages that don't reveal tracing information, software versions, programming component names, or any other debugging information. If developers need to keep a record of errors or some identifier is necessary for technical support, create an index with a simple ID and the error's description and show only the ID to the user. So when the error is reported to a support personnel, they will check the index and will know what type of error it was.
- Adopt the "Principle of least privilege". Every user, at every level (operating system, database, or application), should only be able to access the information strictly required for a correct operation, never more.
- Taking into account the previous points, build a security configuration baseline and apply it to every new implementation, update or release, and to current systems.
- Enforce periodic security testing or auditing to help detect misconfigurations or missing patches.
Talking about security and configuration issues, we are correct if we say "The devil is in the detail." The configuration of a web server, a database server, a CMS, or an application should find the point of equilibrium between being completely usable and useful and being secure for both users and owners.
One of the most common misconfigurations in a Web application is that there is some kind of a Web administration site accessible to all of the Internet; this may not seem such a big issue, but we should know that an admin login page is much more attractive to crooks that any web-mail as the former gives access to a much higher privilege level and there are lists of known, common, and default passwords for almost every CMS, database, or site administration tool we can think of. So, our first recommendations are in the sense of not exposing these administrative sites to the world and removing them if possible.
Also, the use of a strong password and changing those that are installed by default (even if they are "strong") is mandatory when publishing an application to the internal company network and much more so to the Internet. Nowadays, when we expose a server to the world, the first traffic it receives is port scans, login page requests, and login attempts; even before the first user knows the application is active.
The use of custom error pages helps the security stance because default error messages in Web servers and Web applications show too much information (from an attacker's point of view) about the error, the programming languages used, the stack trace, the database used, operating systems, and so on. This information should not be exposed because it helps us understand how the application is made and gives names and versions of the software used. With that information an attacker can search for known vulnerabilities and craft a more efficient attack process.
Once we have a server with its resident applications and all services correctly configured, we can make a security baseline and apply it to all new servers to be configured or updated and to the ones that are currently productive with the proper planning and change management process.
This configuration baseline needs to be continually tested in order to keep it improving and protected from newly discovered vulnerabilities consistently.