Server sendet Spam?!

Wieso erstellt man das im Rescue-System des Providers? Nur damit man es von einem garantiert "sauberen" (vertrauenswürdigen) System macht?
Ich frage, weil es sich doch dann eher anbieten würde, das Ganze automatisiert (nachts) von einem Zweitsystem zu erledigen und so eine Downtime (noch dazu wg. manueller Arbeit zu Bürozeiten!) zu vermeiden.

Wie immer sind diese Tricks auch unter Hacker bekannt.
Einem kompromitierten System kann man grundsätzlich nicht trauen.
Daher erstellt man immer wieder mal eine md5sum durch eine "vertrauenswürdige" Distribution Bootcd etc.
Ein System das mit hoher Wahrscheinlichkeit nicht manipuliert wurde.

-> Tägliche Listen kann man natürlich über das lokale System erstellen.
Aber sobald erhebliche Zweifel bestehen drängt sich eine Gegenprüfung durch eine vertrauenswürdige Umgebung einfach auf.
Täglich würde ich die prod. Umgebung auch nicht im Rescue booten wollen.


Je nach Infrastruktur, ich synce den "kompletten" Storage meines roots per drbd auf einen anderen Host, kann man das auch auf einem anderen nicht produktiven System durchführen.
 
Anmerkung:

Im Gegenzug kann man dieses dann auch mit den Repository Daten auf einer Referenzumgebung gegenprüfen.
-> die Distributionen liefern i.d.R. ebenfalls eine md5sum zur Datei.

Nur für den Fall, dass man ein automatischen Update übersehen hat.
 
Je nach Infrastruktur, ich synce den "kompletten" Storage meines roots per drbd auf einen anderen Host, kann man das auch auf einem anderen nicht produktiven System durchführen.

Spricht etwas dagegen, die md5sums mittels ssh von einem anderen Host (z.B. einem kleinen vServer) zu erledigen und diese dort zu speichern?
Oder wieso benutzt Du drbd?

Vorteil bei "meiner" Vorgehensweise wäre: Man braucht keinen Zweithost, der genausoviel Plattenplatz wie das zu sichernde System hat, denn man speichert auf dem Zweithost ja nur die Prüfsummen. Wenn sich dann eine überraschende Änderung ergibt, kann man ja immernoch schauen, wie und warum das betroffene Binary geändert wurde, bevor man in Panik verfällt. ;)
 
Last edited by a moderator:
Also drbd setzen wir wegen Ausfallsicherheit ein.

Steigt ein System aus, übernimmt das andere den Dienst.
Die Replizierung sieht jedoch vor, dass die Binaries der Distribution in ein eigene Partition der Gegenseite repliziert wird.

Hilft z.B. um einen verstorbenen host schnell wieder auf zu setzen.

Sieh quasi wie folgt aus:

Code:
Host A                               Host B
Partition 1 -> /                   Partition 1 / 
Partition2 -> /daten <----> Partition 2 /daten
Partition3 <- / Part 1 von Host B | Part 1 Host A -> Partition 3

ganz simpel skizziert.

Warum wir das "extren" (bei uns im Haus) und nicht auf einem vHost lager:
Unser Netz ist von extern abgesichert.
Ein Einbruch da 3 DMZ ziemlich unwahrscheinlich.

Bei einem anderen vServer könnte es dank z.B. ssh keys ggf. trotzdem sein, dass der Angreifer, oder sofern gleiche Distribution eingesetzt wird, über die gleiche Lücke das System angreift und auch dort die Daten fälscht.

-> Diese Wahrscheinlichkeit eher gering ein Scriptkiddie wirds übersehen
jemand mit hoher krimineller Energie ggf. nicht.

Bei uns war die Entscheidung schlicht weg die, dass die Daten im eigenen RZ liegen und vor externem Zugriff geschützt sind.
Einen lokalen Rechner hat i.d.R. jeder daher wäre das auch der einfachste Weg und ohne weitere Kosten Verbunden.
 
Wenn sich dann eine überraschende Änderung ergibt, kann man ja immernoch schauen, wie und warum das betroffene Binary geändert wurde, bevor man in Panik verfällt. ;)

Mit Panik hat es weniger zu tun, wenn Du eine zeitnahe Prüfung des Systemes vor nimmst. Um eine Änderung am aktuellen System feststellen zu können, brauchst Du ja auch die md5sum des "jetzt" Zustandes und jenes des zuletzt bekannten "sicheren" Zustandes.

Wenn der Host also ohnehin schon länger wegen Überlast etc. nicht erreichbar ist, dann jucken die 10 -15 Minuten um sich Gewissheit zu verschaffen eigentlich auch nicht mehr wirklich.
 
Eine passende Alternative wäre Tripwire.
Es übernimmt genau diese Funktionalität von md5sum plus Zeitstempel und stats-Informationen pro Datei/Verzeichnis.
Weiteren Mehrwert liefert Tripwire durch seine Konfiguration, genauerer Eingrenzung der überwachten Dateien und unterschiedlichen Report-Funktionen.

Die dahinter stehende Datenbank wird i.d.R. lokal gehalten, ist aber verschlüsselt.
Zur Sicherheit kann dieses dbm-File nochmal zusätzlich mit md5sum überwacht und extern gespeichert werden.

So kann auch ein alleinstehender Server gemütlich und automatisiert auf Veränderungen überwacht werden.

Stichwörter dazu zum googlen:
- Host-basiertes Intrusion Detection-System (HIDS)
- System Integrity Verifier (SIV)

huschi.
 
Eine passende Alternative wäre Tripwire.
Es übernimmt genau diese Funktionalität von md5sum plus Zeitstempel und stats-Informationen pro Datei/Verzeichnis.
Weiteren Mehrwert liefert Tripwire durch seine Konfiguration, genauerer Eingrenzung der überwachten Dateien und unterschiedlichen Report-Funktionen.

Die dahinter stehende Datenbank wird i.d.R. lokal gehalten, ist aber verschlüsselt.

"Standardlösungen" vor allem weit verbreitete bergen das Problem, dass Scripte / Hjack tools diese Werkzeuge als erstes manipulieren.

Bei individuelleren Lösungen muss der Angreifer genauer analysieren und übersieht ggf. etwas. Und sei es nur die "Zerstörung" von den gesammelten Daten damit man den tatsächlich gewählten Weg nicht heraus findet.
In der Hoffnung, dass das neu aufgesetzte System die gleiche Lücke aufweist.

-> Weshalb man eine exakte Strategie der Überwachung im Prinzip so geheim hält wie seine Passworte.

Klinkt sich Tripwir eigentlich ins FS ein sodass Filehandles und Manipulationen in "Echzeit" reportet werden können?
Und wie robust ist die Datenbank? Wie schnell kann es zu korruption kommen bzw. wie robust ist diese bei gelegentlichem Sync auf ein anderes System.
Stell mir folgendes Szenario vor:
Tripwire speichert Daten in dessen Datenbank, da sich Änderungen ergeben haben. Zudem Zeitpunkt läuft jedoch auch ein sync Vorgang / Kopiervorgang.
Typische Datenbankdateien sind hinterher ja meist nicht mehr zu gebrauchen.
 
Last edited by a moderator:
Klinkt sich Tripwir eigentlich ins FS ein sodass Filehandles und Manipulationen in "Echzeit" reportet werden können?
Nein, Tripwire hat keinen Echtzeit-Report. Er wird i.d.R. per cron.daily gestartet und scannt alle in der Policy eingestellten Verzeichnisse und verschickt einen Report per Mail.
Die Policy ist von den jeweiligen Distro-Anbietern an ihr jeweiliges System angepasst und teilweise schon auf "zu scharf" gestellt.
Ein Check kann natürlich auch jederzeit bei Verdacht manuell gestartet werden.

Und wie robust ist die Datenbank?
Tripwire nutzt sie im Cronjob lediglich zum lesen.
Das Schreiben muss manuell angestoßen werden indem man den Report akzeptiert. (Dabei können einzelne Dateien/Verzeichnisse auch nicht akzeptiert werden.)
Die Datenbank ist signiert und nur mit dem passenden Passwort beschreibbar.

Durch ein md5sum und ein Backup der Datenbank hat man eine relative hohe Sicherheit gegen Manipulationen der Datenbank.

huschi.
 
Heisst aber im Endeffekt, die Daten werden lokal gelesen und gehalten.
Die Verschlüsselung bzw. Entschlüsselung kann man also heraus finden und im schlimmsten Fall die Datenbank austauschen um möglichst lange unentdeckt zu bleiben. Denn der Angreifer weiss, was man "erwartet".
Beim Backup stellt sich immer die auch die Frage, wohin diese gehen.
Typischerweise auf den FTP Backupspace über lokale Scripte.
Dann kommt man an die Daten i.d.R. ran und kann auch diese manipulieren.
Passwort stehen ja meist in den Scripten.

Da hilft ebenfalls keine Verschlüsselung, wenn das Backup automatisch und nicht manuell ablaufen soll.
Den Schlüssel kennt man dann auch, liegt ja lokal.
Muss man also die Daten bei jedem Schreiben manuell sichern.
Die Frage ist, wie lange geht das gut, bis es der Admin vergisst, keine Lust mehr hat etc.

Ratsam ist es immer unmittelbar nach Prüfung / Erhebung solche Informationen diese in Sicherheit zu bringen sowie die dafür nötigten Binaries auf einem Read Only Medium zur Verfügung zu stellen. Egal welches Tool man einsetzt.
(Read Only eine Partition zu mounten reicht nicht wirklich aus.)
Und um den Admin zu schonen sollte das so automatisch wie möglich ablaufen.

Wenn man die Daten nicht lokal vorhält tut sich ein Einbrecher schwer heraus zu finden, was man zukünftig an md5sums etc. erwartet.
Denn, das Ergenis aus der "md5sum" und "md5sum" müssen ja nicht das gleiche sein.
Allerdings verwendet man unterschiedliche Verfahren, eines das ggf. regelmässig auf dem Host läuft und ein 2. Verfahren dass man ausschliesslich manuell anstösst.

!Diesen 2 Zeiler gibt man in der Console ein und liegt nicht als Script auf dem Host!
Zur automatisierung kann man das ggf. auch per ssh aufruf erledigen. -> danach History leeren!

-> md5sum über Dateiname, md5sum über Vollständigenpfad und Datei, md5sum Datei und Berechtigung usw. usw.
Zur Perfektion legt man noch 2-3 Datein verteilt in Filesystem ab, die sich regelmässig ändern und dessen md5sum man auf der Referenzumgebung rekonstruieren kann. Damit prüft man dann noch ob, der Prüfprozess zuverlässig arbeitet.

Ds ganze kann man als reine Gedankenanregung sehen.
Mit ein bisschen phantasie lässt sich das gut auschmücken und bietet somit einen guten und individuellen Schutz / Prüfung gegen Manipulation von Dateien.

Ich behaupte mal, 2 Zeilen Code die Daten zu generieren, ca. 15-20 Zeilen die Daten auf der "Gegenseite" zu prüfen.
 
Last edited by a moderator:
Zur Sicherheit kann dieses dbm-File nochmal zusätzlich mit md5sum überwacht und extern gespeichert werden.
Überlesen? Hätte Dir ein paar Zeilen gespart.
Alles andere steht so ähnlich und besser ausgeführt in jeden guten Howto zu Tripwire.
Bevor Du noch mehr über Sicherheitsmängel von Tripwire spekulierst, empfehle ich Dir die Docs zu lesen.
Dann weißt Du wenigstens auch worüber Du schreibst.

huschi.
 
Huschi,

2 Posts vorher habe Ich dir eine Frage gestellt, die sowohl eine Frage als auch ein gute Hineis war, wo man die Tools überlistet.
Genau da, wie sie Ihre Daten her holen.

In 99,9% aller Fälle in denen Dir jemand Schadcode unterschiebt und nicht will, dass Du dem auf die schliche kommst, genau da versorgt er Dich schon mit den "richtigen" Informationen.
Die entsprechende Lib austauschen, ist nicht der riesen Aufwand.
Da hilft dann auch das md5sum auf dem lokalen System nicht mehr.

Es wird sich sicherlich keiner die wesentlich höhere Mühe machen,
diese Datenbank zu knacken, wenns auch einfacher und für viele Tools besser geht.

Hör doch bitte mal auf, permanent Recht haben zu wollen,
wo es erstmal viel simplere und zuverlässigere Methoden gibt, auch wenn das eine oder andere Schnörckelchen dran fehlt.

Bevor Du noch mehr über Sicherheitsmängel von Tripwire spekulierst, empfehle ich Dir die Docs zu lesen.

Muss ich nicht. 2 Essentiele Teile davon stammen aus meiner Feder. ;-)
Deshalb weiss ich auch, wo die Schwachstelle steckt und das eine forensischer Untersuchung immer von einem zuverlässig geprüften System aus geschehen muss.
Für Rootserverbenutzer bleibt nur der Kompromiss dem Rettungsystem des Providers zu vertrauen.

Und für alle Fälle, in denen mir eine "Entdeckung" per se egal ist, vernichte ich alle Spuren die zu mir führen oder den Weg wie ich ins System gekommen bin.

Könnten wir also die "herablassende" Formulierungen aka "Ich habe die Doku verstanden Du auch?" lassen?
Denn sonst müsste ich Dir erklären, dass ich 2-3 Tage / Monat in Dortmund bin und weitere 2-3 Tage in Wiesbaden.
Beides mal in staatlichen Organisationen zum Thema Forensik. Und nicht um mich durch dritte berieseln zu lassen.

Noch allgemein:
In den letzten 20 Jahren habe ich meine Erfahrungen gesammelt, die mich dazu verleiten Empfehlungen zu einem vorgehen zu geben. Diese Erfahrungen decken sich mit hoher Sicherheit nicht mit Deinen, weshalb es legitim ist dass andere Herangehensweisen, Lösungswege sowie Meinungen bestehen.
Und trotzdem schaffen es die meisten die es dann besser Wissen wie ich, sachlich und höfflich zu bleiben.

Google hilft Dir bei der weiteren Recherche.
Diskussions Ende.
Und meinetwegen kannst Du Dich nun wieder über den ungehobelten Ton des RF Users beschweren.
Weil die RF User es pflegen gelegentlich einer Sache auf den Grund zu gehen und es i.d.R. nicht bei der oberflächlichen Betrachtung einer Doku belassen.
 
Last edited by a moderator:
Da bläht sich jetzt aber jemand wie ein Gockel auf!
Muss ich nicht. 2 Essentiele Teile davon stammen aus meiner Feder.
Du warst also 1992 an der Purdue University in der USA? Als Dozent oder als Student?
Bogbogbogbogboooog!

Hör doch bitte mal auf, permanent Recht haben zu wollen,
Sehr dickes DITO! Das ist nämlich unser eigentliches Problem hier.


Dennoch um wieder Sachlich zu werden:
Tripwire hatte ich genannt um eine alte und bewährte Standartsoftware zu nennen für User die nicht ständig ihren Server in den Rescue fahren wollen nur um einen md5-Check zu machen.
Das sich auch dieses System umgehen lässt, stelle ich gar nicht in Frage.
Was Du nicht gemerkt hast, ist, dass Du mit Deiner Argumentation gegen Tripwire Dein von Dir als einfach, simple und wirkungsvoll angepriesene System ad absurdum geführt hast.
Traurig aber wahr: Das wirst Du wiederum nicht einsehen wollen. :(

Diskussions Ende.
Nochmals Dito!

huschi.
 
Vielen Dank,

Eure Diskussion war vielleicht etwas hitzig, aber doch sehr aufschlussreich.
Auch wenn man über "Selbstbau-IDS" nicht reden sollte, tu ichs doch mal:
Ich hab die Idee, meinen vServer S1 mittels eines kleineren vServers S2 abzusichern. Und zwar berechnet S2 die md5sums der Binaries von S1. Die Prüfsummen werden lokal nur auf S2 gespeichert. Der Zugriff von S2 auf S1 erfolgt per SSH, und vor einem neuen "Prüflauf" wird ein statistisch gelinktes md5sum-Binary von S2 auf S1 in ein temporäres Verzeichnis auf S1 kopiert und dort ausgeführt.
Was haltet ihr von dieser Idee?
 
Jetzt da der Angreifer weiss wie du die Ueberpruefung durchfuehrst -sofern er SSF mitliest :) - ist deine Methode schon kompromittiert.
Der einzige Vorteil einer solchen Loesung ist "security by obscurity" indem der Angreifer nicht weiss welche Sicherheitsmassnahmen eingebaut sind und ob er schon ueber eine Alarmglocke gestolpert ist.

Es waere dem Angreifer moeglich deiner Software eine saubere Umgebung vor zu tauschen indem er die SCP abfaengt und die Ausgabe entweder in einer Chroot-Jail generiert (sofern das nicht erkannt wird) oder einen vorherigen Inhalt zurueckschickt.

Allerdings reden wir hier von vServer, also von System wo wahrscheinlich das Hostsystem weniger paranoid abgesichert ist als dein eigener Server (oder das Control-Panel Einstiegsluecken bietet) und der Anbieter selbst direkten Zugriff auf deine Partition hat.

Ein sichereres (sicherer, nicht sicher!) System waere eine vollstaendig verschluesselte Festplatte welche beim Systemstartup nach KOntrolle durch externe Tools durch einen Key des externen Servers freigegeben wird. ;)
 
Ein sichereres (sicherer, nicht sicher!) System waere eine vollstaendig verschluesselte Festplatte welche beim Systemstartup nach KOntrolle durch externe Tools durch einen Key des externen Servers freigegeben wird. ;)
Was ist an einer entschlüsselt gemounteter verschlüsselter Partition/Festplatte nun sicherer als bei einer normalen Partition/Festplatte? Nichts.
 
Dass es einer Person mit physischem Zugang (oder Rescue-Console) nur moeglich ist die Boot-Partition zu kompromittieren.

Allerdings schuetzt dies allein nicht vor Kon-Boot :)
 
Solange die Kiste läuft, liegt die Partition/Festplatte offen, da hilft die Verschlüsselung absolut gar nichts. Und ausgeschaltet nutzt einem der Server nichts. Wozu also den unnötigen Overhead der Verschlüsselung?
 
Wenn eingeschaltet sollte der Zugriff auf den Server nur durch ein Passwort moeglich sein welches ein Angreifer nicht kennt.
Im ausgeschalteten Zustand ist die Partition nicht gemounted und somit koennen selbst beim Boot in eine Rescue-Konsole die kritischen Softwareteile nicht infiziert werden (ausser natuerlich das Boot-System)

Da der Key erst nach dem Boot und nach Ueberpruefung durch Server 2 (welcher lokal gehostet werden sollte) an Server 1 verschluesselt uebermittelt wird ist die einzige Hoffnung fuer den Angreifer das Austricksen der Validierungssoftware um an den Decrpyption-Key und somit die Daten zu kommen.
 
Wir reden hier über einen Server nicht über einen Laptop oder eine Workstation, welche man gegen Manipulationen durch physikalischen Zugriff und/oder Diebstahl schützen möchte.
Somit liegt der Hauptangriffsvektor nicht beim Rescuesystem oder dem physikalischen Zugriff durch das RZ-Personal, sondern im Remote-Zugriff eines Crackers auf das laufende System. Und wie wir wissen, sind in diesem Fall sowohl die verschlüsselten Partitionen bereits entschlüsselt gemountet, als auch der Hauptangriffsvektor ein ganz Anderer, nämlich unsichere Software, insbesondere WebApps.

Irgendwie erschliesst sich mir der Sinn Deines Vorschlags nach wie vor nicht...
 
Wenn man beim Systemstart nicht von einem sicheren System ausgehen kann sind alle IDS-Systeme bereits von vornerein zum Untergang verdammt.
Schliesslich kann das System nicht erkennen was bereits vor seiner Laufzeit gestartet wurde ;)

Wenn der Systemstart selbst als sicher bestaetigt werden kann muss die Sicherungssoftware nur noch die weiteren Daten und Aktionen validieren.

Sollte das System ueber aehnlich wie redpill/bluepill aufgebaute Software infiziert sein -also integral in eine virtuelle Machine verschoben worden sein- kann selbst auf Kernelebene keine SIcherheit mehr erfolgen.

Allerdings fange ich an damit ein bisschen uebers Ziel raus zu schiessen *hust*
 
Back
Top