This short post reflects the simplest and most important approaches and specific recommendations to help keep your application from being hacked. On any well-configured web server, many of the following methods are implemented to varying degrees and in different ways.
In this way, from the php-code it can be possible to read only the contents of the directory with the site itself. If one site is compromised, this will protect the others from being compromised. It will also protect against the abuse of quite standard tools that can be used by web developers, so that it was impossible to pull the entire contents of the server through one inaccurately filled php-script. In other words: one site - one system user who reads only the directory with the project.
There is a more reliable implementation of the described approach: one site - one virtual machine. This completely isolates the environment and web server software, you can not touch the standard users for the web (usually www-data) and this is clearly a more secure approach. So, if it is possible to put a site in a separate virtual machine - it is better to do so. There are a lot of possibilities to do it now.
A typical way to hack popular CMSs is to pour code as content and then execute it. Prohibiting the writing of scripts largely eliminates the first part of such an attack. Therefore, in the configuration of the web server it's possible to turn off the possibility of recording in all directories, where it is not allowed to do so, and leave open standard directories for upload/files/images and similar - to fill the content.
It is necessary to understand the downside of this method in advance: many CMS for the convenience of users, provide the possibility to overwrite their code. Therefore, a ban on overwriting can significantly complicate the work with the CMS. Here, using different accounts (owner:group) for the web server and for webmasters helps a lot. This approach also works great when using version control systems (git/svn).
Blocking access to upload directories partially eliminates the second part of the attack described in the previous paragraph. Obviously, the script which has been uploaded as content can still be launched from the shell (as well as by other means besides the web), but it will become impossible to pull it from Internet. This makes life very difficult for various uploaded malware.
This elementary protection applies not only to WordPress, but also to almost all other sites in the web. Unfortunately, it is often neglected and thus open that should not open, such as git repositories and svn.
Any open admin panel or other management resource will be broken. In the most typical case, the passwords will be cracked. If you look at the logs of any web-server, a fairly large part of them is just an attempt to recognize the CMS, find the typical vulnerabilities and picking passwords.
Even if you're confident in the strength of your password, do you have the same confidence that webmasters, content people, and others with access to the site have a strong password? Or, that it's not compromised? So, it's better to restrict access to the administrative part by ip-addresses or, as a minimum measure, limit the number of login attempts
When speaking about compromise, we mean any forms where there is valuable data and passwords included - it should be done only over HTTPS.
Update all the software that is on the server, from the operating system, to CMS and plugins for it. And do it in a timely manner. This helps against many possible vulnerabilities that attackers try to find in the software if your plugin/app etc. is outdated, both in the code CMS (primarily), and in the web server software (eg, openssl, and heartbeat attacks). On critical occasions, we advise to put auto-updates.
This point should be a part of the routine. But vulnerabilities in popular CMSs are found all the time, and not always the patch leaves in time. Therefore, there is no guarantee of safety, even with all installed updates.
These solutions require a bit of a technical touch, let us know if you are going to implement security systems on your applications, we are here to help! Contact us on our get a quote page.
Naturally, the above approaches do not exhaust all the possibilities for website security, especially on a popular CMS, but they significantly reduce the possibility of infection and site, app hacking. Analyzing the statistics of infections, we can say for sure that the correct implementation of the above recommendations will save the typical site in more than 95% of possible cases.
