Hardening a Website and PCI Compliance

  • Hi JoshuaPack

    Well - the question is what you mean by "hardening". I think the most important thing is to think about, which extensions you really need. I am working in a scientific data center and most security-related issues come from badly written plugins.

    So don't use extensions you don't need. Keep your Pagekit-installation updated. Did you know that you can update Pagekit via CLI? You can setup a cronjob and keep the core up to date.

    When it comes to "hardening", a lot of people think it's enough to rename the URL for the admin-backend to /my-custom-admin-backend. Well, that might work for stupid brute-force attacks. But those are not really dangerous. You can use a server-side firewall that counts 401/403-responses and bans IPs. Or you might install mod_security with a set of rules that even recognize common attack patterns.

    If you can't configure your server-side firewall, you might use spqr/security. It does some basic security stuff like banning IPs after X failed login attempts and provides a honeypot (bans IPs that are accessing wp-login.php (that does not exist) and so on).

    Some people do something else: As most attackers try to upload a PHP-shell, they change the ownership of the files and directories.

    E.g.: You are using FastCGI and PHP is executed by system's user "webhosting_account". You could do a chown -R www-data:www-data *in your document root. But in this case, Pagekit isn't able to write anything, so updates or installation of new extensions will fail.

    I think you would need to exclude tmp directories, as Pagekit does some caching and writes files to the tmp-dir.

    But I don't think that this is the best way.

    A really important thing: If you are using NGINX, please make sure that pagekit.db and config.php are not accessible. NGINX, if used as web server and not as reverse proxy "in front" of Apache, does not use the .htaccess rules. So if you are using NGINX, please make sure that these files can not be accessed by anybody.

    My advice is to keep your Pagekit-installation updated and set up a well-configured firewall.

    One more thing: Did you know that Pagekit has a very modern codebase? In some older CMS the devs can do whatever they want to. This is very often the reason for SQL injection vulnerabilities. As Pagekit provides Doctrine, the most common mistakes when it comes to SQL can not be done ;)

  • I think that‘s okay - but a good solution would be to use different vhosts (if you are using Apache) with different document roots and different system users (use FastCGI or FPM). With enabled basedir-restrictions this should be safe enough.

    The most important thing is a good server configuration including good backups.