Vorbereitung des Servers I

Warnung: Diese Anleitung ist nicht mehr aktuell!

!

Wichtig: Diese Empfehlungen richten sich an Personen, die SoSci Survey auf einem virtuellen Server (V-Server, VPS) oder einem Root-Server installieren. Hat man nur Webspace gemietet, muss man sich um die Servereinstellungen i.d.R. keine Sorgen machen.

Sofern die Daten unverschlüsselt übertragen werden, können sie an vielen Stellen auf dem Weg durch das Internet abgehört werden. Ein plausibles Szenario wäre hier, dass die IT-Abteilung bei einer Unternehmensbefragung mal einen Blick in die Antworten wirft.

Um dieses Problem sicher zu lösen, kann man die Datenübertragung mittels HTTPS bzw. SSL verschlüsseln. Die Daten werden dann unmittelbar vom Browser verschlüsselt und erst auf dem Server wieder entschlüsselt. Ein SSL-Zertifikat ist ab 50 Euro im Jahr zu haben. Man kann sich Zertifikate zwar auch selbst erstellen, aber so lange diese nicht beglaubigt sind, zeigt der Browser bei jeder Seite eine Warnung an.

um Daten auf den Server zu übermitteln, wir man in aller Regel ein FTP-Programm (z.B. FileZilla) verwenden. Für den Zugriff auf die Datenbank vielleicht ein bequemes SQL-Frontend (z.B. HeidiSQL). Sofern man diese ohne Verschlüsselung verwendet, können die Passwörter allerdings abgehört werden. Auch wenn es wohl eher selten vorkommt: Die Vorstellung, dass Kriminelle über den eigenen Server Spam oder illegale Inhalte verteilen oder Daten abgreifen, ist eher unangenehm.

Sofern man via SSH verschlüsselt auf den Server zugreifen kann, lässt sich da schnell viel Sicherheit erreichen: Einfach statt der Übertragungsmethode FTP die verschlüsselte Variante SFTP auswählen und mit PuTTY (das man vermutlich ohnehin für den Shell-Zugriff zum Server verwendet) einen verschlüsselten SSH-Tunnel für MySQL nutzen. Das bietet auch den Sicherheitsvorteil, dass man den MySQL-Zugriff generell auf den Server (localhost) beschränken kann, also z.B. ein MySQL-Benutzer admin@localhost anstatt admin@%.

Eine detailliere Anleitung für den verschlüsselten MySQL-Zugriff bietet Tsunamihost.

Webserver sind nur so lange sicher, so lange sie auf dem aktuellen Stand sind. Sofern sich um die Updates nicht der Hoster kümmert, kann man das alle paar Wochen bequem selbst erledigen. Per PuTTY auf der Shell einloggen, dann folgende Befehle eingeben:

apt-get update   (Aktualisiert die Software-Listen)
apt-get upgrade  (Installiert die Updates)

Es bleibt natürlich das Restrisiko, dass SoSci Survey auf der neuen Apache- oder PHP-Version irgendwelche Probleme machen könnte. Aber dieses Risiko ist deutlich geringer als die Gefahr durch Sicherheitslöcher in veralteter Software.

Selbst wenn ein Projektleiter die Aufzeichnung von IP-Adressen deaktiviert, ist es prinzipiell möglich, aus Befragungszeitpunkt und Eintrag im Server-Logfile die IP-Adresse zu rekonstruieren. Die praktische Gefahr, darüber einzelne Personen zu identifizieren ist gerade bei Unternehmensbefragungen unter bestimmten Umständen durchaus gegeben. Das Identifizieren einzelner Internetnutzer ist dagegen eher eine hypothetische Gefahr.

• Ein einfacher Weg, das Problem zu lösen ist es, die Logfiles ganz zu deaktivieren. Der Nachteil dabei ist aber, dass auch keine Informationen mehr zur Nutzung des Servers vorliegen.
• Wesentlich eleganter ist es, die IP-Adressen selbst zu anonymisieren, indem nur die ersten zwei Bytes (Stellen) der Adresse gespeichert werden. Ein Perl-Script, das diese Aufgabe auf einem Apache-Webserver übernimmt und das man mit wenigen Klicks auf dem eigenen Server installieren kann, bietet ZENDAS.

Damit E-Mails vom Server nicht in Spamfiltern landen oder ganz blockiert werden („connection refused“), bedarf es einiger Einstellungen am Mailserver:

• Zunächst ist es wichtig, dass die From-Adresse (nicht der Absender!) zum Mailserver passt. Diese Adresse wird in der Apache-Konfiguration festgelegt. Normalerweise sollte diese Adresse schon korrekt eingestellt sein.
• Es ist sinnvoll, in den DNS-Einstellungen der Domain einen SPF-Eintrag anzulegen, der festlegt, wer E-Mails von der Domain versenden darf.
• Der Mailserver benötigt einen PTR-Eintrag (Reverse DNS), welcher dem Rechnernamen entsprechend sollte, der beim Mailversand übermittelt wird (z.B. /etc/mailname).
• Weiterhin muss man darauf achten, dass die IP-Adresse des Servers keine Probleme mit Blacklists (RBL) bekommt. Ursachen dafür können sein, dass der reverse DNS (rDNS) Eintrag nicht stimmt. Ein Problem, das nur der Internet Service Provider lösen kann. Auf folgenden Websites kann man zahlreiche RBLs überprüfen:
  • Blacklistalert.org
  • multirbl.valli.org
• Senden Sie eine Serienmail an den Dienst mail tester, um wesentliche Einstellungen des Mailservers schnell zu überprüfen.

SoSci Survey verwendet für die Speicherung der Daten (Daten in SoSci Survey) die Datenbank-Engine InnoDB in einer MySQL-Datenbank (MySQL: Überblick über InnoDB-Tabellen). Dies hat unter anderem den Vorteil, dass verschiedene Konsistenzprüfungen bereits von der Datenbank übernommen werden, z.B. können nicht versehentlich Fragen oder Antworten für ein gelöschtes Projekt gespeichert werden.

Allerdings gibt es einige Unterschiede zwischen der Standard-Enging MyISAM und InnoDB. Diese erfordern unter Umstände eine gesonderte Konfiguration:

• Die InnoDB Engine ist standardmäßig in MySQL aktiviert, wurde aber möglicherweise deaktiviert, um RAM-Speicher zu sparen (MySQL: InnoDB: Startoptionen). Die SoSci Survey Installationsroutine zeigt dieses Problem ggf. an.
• Alle Daten, die MySQL mittels InnoDB speichert, werden standardmäßig in einer (!) großen Datei abgelegt. Wo diese Datei liegt, wird mittels innodb_data_file_path konfiguriert (MySQL: InnoDB Konfiguration). Dies ist für die Serverleistung normalerweise auch sinnvoll. Falls neben SoSci Survey noch andere Software die InnoDB-Engine nutzt, muss man sich aber bewusst sein, dass die Daten im Dateisystem untrennbar verschmolzen sind – ein getrenntes Backup durch Dateisicherung ist dann nicht möglich. Mit der Option innodb_file_per_table kann man die Trennung in einzelne Dateien erzwingen, sollte dies gewünscht sein (MySQL: Using Per-Table Tablespaces).
• InnoDB ist standardmäßig so konfiguriert, dass es nur einen kleinen Teil des RAM-Speichers für das Caching von Indizes verwendet. Falls Sie sehr viele Interviews (etwa ab 500.000) in Ihrer Datenbank vorhalten, ist eine Anpassung der Optionen innodb_buffer_pool_size und dazu passend innodb_log_file_size sinnvoll, damit der Server schnell auf die Daten zugreifen kann (MySQL Performance Blog).