Server Security

A web server is used to make content available to a wide audience. At the same time, this means that third parties interact with the server. As a rule, there are (mostly automated) attacks on web servers several times a day. The goal here is to obtain protected data by exploiting security vulnerabilities or to abuse the server for criminal purposes.

In addition to attacks from the outside, long-term operation will also confront you with problems that come from within: Users accidentally deleting their survey projects and data, hard disks running full or insufficient computing power.

It has proven to be useful to run a survey server (which often processes personal data) on a separate server or in its own VM. This has two advantages: Firstly, the software (web server application, PHP) can be updated regularly without regard to other software. On the other hand, one avoids the risk that security vulnerabilities in other software (e.g. an unupdated WordPress instance) allow access to the server and thus to survey data. Therefore, the GDPR also explicitly refers to the separation of data processing operations.

To ensure secure server operation, the following points must be observed:

• Secure environment
  • Choice of a reliable hoster or data center (with some hosters the servers are located unprotected in the hallway)
  • Use of secure and different passwords for SSH (here additionally keyfile), MySQL, administrator account in SoSci Survey, server monitoring and so on. – the use of a password manager like KeePass XC offers great advantages here.
• General security functions
  • Firewall (z.B. iptables)
    • Enable ports 80 and 443 (SMTP port 25 only if the server needs to process incoming mail as well)
    • Restrictive IP limitation of SSH port 22
    • MySQL port 3306 only accessible through an SSH tunnel (e.g. via PuTTY)
  • Malware-Scanner (e.g. chkrootkit and rkhunter)
  • Automated security updates (e.g. unattended-upgrades)
    • Additionally weekly or monthly system updates
  • Securing of participation keys (e.g. serial numbers) against brute force attacks (fail2ban for SoSci Survey)
• Use or activate common encryption
  • SSL encryption, so that any access to questionnaires and project administration is only possible via HTTPS
  • Data-at-Rest-Encryption for the database (MariaDB Data-at-Rest Encryption Overview)
    • Alternatively, use an encrypted partition on the server if uploaded files also need to be secured (make sure that the server then restarts automatically after a reboot!)
• Data backup (encrypted) to a backup storage outside the server (e.g. cloud storage using duply).
  • Daily database dump (mysqldump) incl. backup of the dump – here we recommend a retention for 1 month or 12 months if the automatic archiving of survey projects is used (users often notice only after 9 months that their important survey project has been deleted)
  • Incremental file system backup
  • Keep cryptographic keys secure and test whether restoring both backups from another server is actually possible and works * Server stability in long-term operation
  • Server monitoring (e.g. with monit and munin)
  • Automated server restart (e.g. once a week or once a month)