Re: Debian in DMZ absichern
Am Donnerstag, 20. März 2014, 12:57:13 schrieb Ralf Prengel:
> Zitat von Christoph Schmees <cjws@gmx.net>:
> >> Hallo,
> >>
> >> Ich teste das gerade mit dem Thema Live-CD. Dazu hatte ich ja
> >> vorgestern nachgefragt. Das sieht soweit gut aus. Wenn wir es
> >> hinbekommen da unser Typo3 mitspielt wird das System jede Nacht
> >> gebootet und sozusagen frisch gemacht. Die Typo3 Installation muss
> >> sich dann seine Daten von einer verfügbaren Festplatte ziehen und
> >> damit arbeiten.
> >> Systemkonfiguration zu ändern wird dann aufwändiger, ist aber
> >> beherrschbar.
> >
> > <http://www.heise.de/newsticker/meldung/Hunderte-Typo3-Webseiten-gehackt-2
> > 148372.html?wt_mc=nl.ho>
> Hallo,
> genau das ist der Anlass.
> Wir haben aktuell kein Problem aber ich möchte sicher stellen das wir
> nicht dochmal irgendwann einen Treffer über welche Lücke auch immer
> bekommen.
Willkommen im Internet, Ralf!
Davor bekommt ihr keinen Schutz.
Ich gehe noch weiter: Davor *gibt* es keinen Schutz. Solange ihr komplexe
Software auf dem Server einsetzt, kann diese Software auch Fehler enthalten
und keine wie auch immer geartete Maßnahme kann euch vollkommen davon
abschirmen. Wobei hier meines Wissens nicht mal klar ist, ob es wirklich ein
Fehler in Typo3 ist[1].
Es ist also offenbar nicht mal bekannt, was der Einbruchsweg ist, und Du
möchtest Systeme dagegen schützen?
Ein Rücksetzen des Systems alle 24 Stunden bewirkt genau das. Es entfernt den
Befall, nicht die Lücke. Am nächsten Tag kann das System dann wieder befallen
werden. Ein Hacker könnte sogar einen Cron-Job dafür einrichten, der jeden
Morgen das System wieder neu befällt.
Ein weiterer Nachteil ist, dass Aktualisierungen aufwändiger werden. Genau das
ist jedoch wichtig, um Fixes für Sicherheitslücken, also Fixes für die
eigentliche Ursache schnellstmöglich zu bekommen.
Der einzige präventive Schutz aus meiner Sicht ist, das System weitgehend nur-
lesbar zu machen. Oder gleich ganz vom Internet zu trennen. Oder einen
statischen Webseiten-Generator einzusetzen und PHP vom Server zu verbannen.
Für praktikabler halte ich, das System zunächst einmal aktuell zu halten,
durchaus auch zu überwachen, und eben alle relevanten Mailinglisten zu
Sicherheitslücken, die den Server betreffen können zu abonnieren und ggf. auf
Zack zu sein, falls eine bekannt wird. Falls ich so einen Artikel lese, teste
ich in der Regel gleich, ob die Systeme, die ich betreue, betroffen sind. Zum
Glück kann ich das diesmal wieder verneinen.
Das Überwachen ist jedoch schwierig. Ein Intrusion Detection System oder
besser Prevention System erkennt auch nur das, an das die Entwickler gedacht
haben. mod_security könnte auch helfen. So oder so haben solche Systeme eine
steile Lernkurve.
Für das Erkennen von Datei-Änderungen gibt es diverse Systeme, inklusive
rkhunter und chkrootkit, aber auch als Bestandteil von IDS. Allerdings ist
auch hier das Problem: Welche Dateien dürfen sich ändern, welche nicht? Das
kann schnell in Gespenster-Jagd ausarten.
So oder so aber gilt: Je mehr Aufwand ich für die Sicherung des Systems
betreibe, desto unhandhabbarer wird es. Ich bin da eher für einige einfache
und klare Maßnahmen und die Reduktion auf das Wesentliche. Am ehesten würde
ich noch PHP-basierte Software entsorgen… auch wenn das mitunter nicht einfach
ist. Ich hab zur Zeit auch ein Wordpress drauf.
Und wenn was bekannt wird, dann dem System halt auch mal auf die Finger
schauen, was es für Netzwerk-Traffic macht.
Als 100%-ige Schutzmaßnahme sehe ich nur, das System vom Netz zu trennen.
[1] http://www.heise.de/newsticker/meldung/Hintergruende-des-Typo3-Hacks-weiter-im-Dunkeln-2149176.html
Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Reply to: