phpBB.de

in letzter zeit stelle ich vermehrt fest, dass nach dem massiven preisverfall bei (v)root servern mehr und mehr leute die serveradministration selber in die hand nehmen, ohne allerdings wirklich etwa davon zu verstehen. von daher zuerst einmal der hinweis auf einen WICHTIGEN LESETIPP: Ist ein dedizierter Server das Richtige für mich?

das die kombination 'keine ahnung' und 'rootserver' in aller regel nach kurzer zeit zu einem defacement der seite bzw. hack eines servers führt wäre ja per se nicht weiter schlimm - inzwischen läuft aber eine vielzahl der angriffszenarien darauf hinaus, die maschinen 'nur' zu kapern und für weitere angriffe als zombie/relay einzusetzen. während früher die klassischen scans nach schwachstellen in aller regel aus brasilien, russland, türkei kamen sind nun mehr und mehr deutsche server daran beteiligt - und meistens ohne das die eigentümer etwas davon wissen bzw. merken.

und weil's so schön passt eine konversation aus meinem PN archiv:

Aber nun ist es geschehen, mein Board wurde gestern Abend vom Hacker heimgesucht und das wo es jetzt prima angelaufen ist.

wie schon angesprochen - gerade wenn man einen eigenen server einsetzt, ist man nun einmal auch für die konfiguration und vor allen dingen auch sicherheit verantwortlich (aus diesem grund setze ich beispielsweise in meinen projekten auf managed server, bei denen kann ich zwar bestimmen, was drauf kommt, trotzdem steht ein ganzes admin team dahinter).

Hast Du eventuell noch ein Tip was ich Sicher machen kann?

zuerst einmal aktuelle versionen einsetzen - nicht nur das phpbb sondern sowohl apache als auch php (und mit einschränkungen mysql) sollten immer auf dem 'latest stable build' laufen. danach kannst du mit einer brauchbaren server konfiguration schon einmal ein plus an sicherheit erreichen, einige dinge habe ich unter php konfiguration zusammengefasst, einen schnellen überblick über die grundlegenden einstellungen liefert auch phpsecinfo.
darüberhinaus solltest du dir auch gedanken um z.b. den einsatz von modsecurity (ein zusatzmodul für den apache) machen - damit kannst du bestimmte angriffsmuster direkt auf serverebene blocken. ich habe ein entsprechendes ruleset vor einiger zeit schon einmal hier im forum gepostet.
danach gilt es dann natürlich noch ein entsprechendes backup-szenario zu entwickeln, z.b. automatisches datenbank-dump via cronjob und sicherung der ftp-daten via fullsync o.ä. damit man auch im falle eines falles (neben hack-angriffen gibt es ja z.b. auch hd-crashs) nicht mit leeren händen dasteht.

prinzipiell allerdings gilt: wer keine ahnung von serveradministration hat, sollte auch die finger davon lassen - man schadet oftmals nicht nur sich selbst sondern auch anderen!

edit: phpsecinfo hinzugefügt

Hallo,

da das ganze mit Sicherheit ein mehr als "Wichtiges" Thema ist habe ich den Beitrag entsprechend editiert und als "Wichtig" gekennzeichnet

Danke an Larsneo

Markus

Zusätzlich empfehle ich (im Falle eines Linux-Servers) auch den Kernel im Auge zu behalten. Heise Online berichtet recht zuverlässig über Sicherheitslücken im Kernel, ist also ganz ratsam dort mal drauf zu achten.

Eigentlich gehört es zur Pflicht eines System-Administrators (ein jeder Root-Server Besitzer ist einer!) zumindest die Security-Mailingliste seiner Distribution zu lesen.

Weiterhin ist es auch recht empfehlenswert zumindestens ein mal pro Monat einen Check mittels chkrootkit durchzuführen.

prinzipiell allerdings gilt: wer keine ahnung von serveradministration hat, sollte auch die finger davon lassen - man schadet oftmals nicht nur sich selbst sondern auch anderen!

Und falls das nicht Abschreckung genug ist, für die Schäden des anderen kann man ordentlich zur Kasse gebeten werden, falls man das Geld nicht hat (was mal durchaus viele tausend Euros sein können), folgt das übliche Spiel aus Eidesstattlicher Versicherung und vielen versauten Jahren der beschränkten Geschäftsfähigkeit - was so in der Praxis bei heutigen Kunden schon des öfteren vorgekommen ist.

Hier ein Beitrag der helfen kann wie man mod_security überhaupt installiert. Dieses Installationsbeispiel gilt für das Betriebssystem Suse Linux und den Apache2.

Mittels Yast lässt sich mod_security nicht installieren und muss selbst kompiliert werden. Als ersten muss mod_security in seiner aktuellsten stabilen Version von http://www.modsecurity.org/download/index.html herunter geladen werden.

# wget http://www.modsecurity.org/download/mod ... 9.4.tar.gz

Das Archiv entpacken und ins entsprechende Verzeichnis wechseln. Es gilt zu beachten das es für den Apache 1.3 und für Apache 2.x eine jeweilige Version gibt.

# mv modsecurity-apache_1.9..4.tar.gz /usr/src/packages/sources
# cd /usr/src/packages/sources
# gunzip modsecurity-apache_1.9.4.tar.gz
# tar -xf modsecurity-apache_1.9.4.tar
# cd modsecurity-apache_1.9.4/apache2

Nun müssen die .so Dateien für den Apache2 erzeugt werden.
Eine anschliessende evtl. Fehlermeldung httpd2-prefork.conf ist nicht vorhanden kann/sollte ignoriert werden.

# apxs2 -cia mod_security.c

Nun muss das Modul mod_security auch aktiviert werden. Unter Suse werden alle Module des Apache2 über ein Skript in die Datei /etc/apache2/sysconfig.d/loadmodule.conf geschrieben. Damit man bei einem Neustart des Servers die Datei nicht verliert, muss sie in die sysconfig Datei eingetragen werden.

# vi /etc/sysconfig/apache2

Das neue Modul wird in der Datei loadmodul.conf ungefähr in der Zeile 133 hinzugefügt. Dazu einfach security zu der Liste der bereits vorhandenen Module hinzufügen. Nun werden die notwendigen Konfigurationen für mod_security benötigt, die sogenannten Rules. Unter Suse kann man sie unter /etc/apache2/conf.d ablegen. Hier eine Beispielkonfiguration (Rules) welche larsneo hier gepostet hat.

# cd /etc/apache2/conf.d
# vi security.conf

larsneo hat geschrieben:# mod_security rules
SecFilterEngine On
# Some sane defaults
SecFilterScanPOST On
SecFilterCheckURLEncoding On
SecFilterCheckCookieFormat On
SecFilterCheckUnicodeEncoding Off
#PHP defenses
SecFilterSelective ARG_PHPSESSID "!^[0-9a-z]*$"
SecFilterSelective COOKIE_PHPSESSID "!^[0-9a-z]*$"
SecFilterSelective COOKIE_sessionid "!^[0-9a-z\.]*$"
# Accept almost all byte values
SecFilterForceByteRange 1 255
[...]

Der Apache muss nun neu gestartet werden damit das neue Modul auch eingebunden wird. Bitte kein rcapache2 reload verwenden, es könnte Probleme damit geben.

# rcapache2 stop
# rcapache2 start

Das war´s.

danke für die info, konnte ich gut gebrauchen

Also, wieso immer rootserver? Ich denke, für viele kleinere Foren reicht ein Dedizierter Server aus! Nur mal so ein Tipp, für alle, die jetzt wie wahnsinnig einen Root wollen^^

Lakei hat geschrieben:Also, wieso immer rootserver? Ich denke, für viele kleinere Foren reicht ein Dedizierter Server aus! Nur mal so ein Tipp, für alle, die jetzt wie wahnsinnig einen Root wollen^^

Ein dedizierter Server ist ein Root-Server.

Nur mal so als Tipp, für alle die glauben immer etwas besser wissen zu müssen

jensemann hat geschrieben:

Lakei hat geschrieben:Also, wieso immer rootserver? Ich denke, für viele kleinere Foren reicht ein Dedizierter Server aus! Nur mal so ein Tipp, für alle, die jetzt wie wahnsinnig einen Root wollen^^

Ein dedizierter Server ist ein Root-Server.

Nur mal so als Tipp, für alle die glauben immer etwas besser wissen zu müssen

@ Lakei
Du meinst vermutlich einen dedizierten "managed" Server wo man Pseudo-Root ist...

Ich schwöre auf Managed. Alleine die Zeit die man dadurch spart holt die Kosten schnell wieder rein.

Außerdem ist die Schuldfrage schnell gefunden. Mangelnde Sicherheit ist dann das Problem des "Managers".

Gruß

mgutt hat geschrieben:Ich schwöre auf Managed. Alleine die Zeit die man dadurch spart holt die Kosten schnell wieder rein.

Außerdem ist die Schuldfrage schnell gefunden. Mangelnde Sicherheit ist dann das Problem des "Managers".

Ich möchte das jetzt nicht als Werbung für einen Teil meiner beruflichen Tätigkeit verstanden wissen, das vorab

Ich denke das Problem der Managed Server ist, das Anbieter und Server-Manager, nennen wir das Tier ruhig Admin (*g*) ein und die selbe Firma sind. Eine Firma ist auf Gewinnmaximierung aus. Für den Server-Anbieter heisst die Gewinnmaximierung weitere Server zu verkaufen, für den Admin (wenn er denn extern wäre) ist die Gewinnmaximierung ein zufriedener Kunde der dadurch entsteht, das er sich durch geschickte Server-Einstellungen weitere Server oder Upgrades auf dickere Maschinen sparen kann. Merke: Der Admin sollte helfen dem Kunden Geld zu sparen. Für kleine bis mittlere Webseiten, ist das kein Problem. Für dickere Webseiten, kann dieser Interessenskonflikt zwischen Server-Anbieter und Kunden aber durchaus zum Problem werden.

Ich möchte damit nicht sagen das Managed-Server Mist sind, aber das ist etwas das man bedenken sollte, vorallem dann, wenn der Anbieter einem nach Lastschwierigkeiten ein Upgrade nahe legt.