Aktives ändern von Logfiles durch User ausschliessen

D

Delta

Well-Known Member
Hallo,

wie kann man es erreichen, das sämtliche Logfiles aktiv ausschliesslich vom System allein verändert werden können, nicht aber von Usern, incl. Superuser?

Vielleicht mit Audit-Pipes zB? Und/oder indem man die Logfiles auf einen entfernten Server auslagert? Allerdings könnte man dann ja einfach lokal die Protokollierung bestimmter Ereignisse stoppen. Was aber widerum zuerst geloggt werden würde, oder?

Ich komme an diesem Punkt einfach nicht weiter, bitte um Hilfe.

Grüsse
 
Was genau möchtest du denn erreichen? Im besten Fall werden die Logs doch durch den User root angelegt oder sehe ich das falsch?

Unter Windows könnte das System als solches welche anlegen...
 
Dem Superuser (root) kannst du nichts verbieten. Dafür ist das ja da. Gib einfach keinem den unbegrenzten Zugang zum Superuser.

sudo erlaubt dir, den Zugang sehr gut zu begrenzen, und keiner muss das root-passwort kennen. Das sollte nur der Administrator wissen (oder auch der nicht, sondern ein zufällig generiertes in einem safe aufbewahren).

Du könntest dir auch mal chflags anschauen, wie du das immutable flag (schg) setzen kannst.
 
Im Endeffekt möchte ich eine Art Protokollserver aufsetzen welcher die Logs von anderen Servern ausliest bzw. bekommt und archiviert.

Sudo war auch mein erster Gedanke. Das Problem daran, in diesem Kontext, stellt sich mir aber wie folgt dar: Der Administrator muss jederzeit vollen Zugriff auf das gesamte System haben, um gegebenenfalls einzugreifen, dafür ist er ja da. Das einzige was er nicht machen darf ist Logfiles zu manipulieren. Ich könnte ihm per Sudo nun gestatten alles zu tun, ausser die Logfiles aktiv zu ändern. Ist aber offensichtlich total lächerlich so weil root das Ganze leicht umgehen kann. Um es auf diese Weise sicher zu gestalten müsste ich ihn so einschränken das er kein Administrator mehr wäre. Und das ist nun überhaupt nicht Sinn und Zweck der Übung. Sondern ausschliesslich eine vom Administrator unabhängige Protokollinstanz.

Und immutable flags kann man so setzen das root sie nicht entfernen kann?

Edit PS: Ich muss die Frage präzisieren. Hat root nicht _immer_ die Möglichkeit auf Securelevel 0 zu kommen und damit schg zu entfernen? Also selbst wenn ich chflags schg /etc/rc.securelevel setze und darin das Securelevel auf 2 setze?
 
Zuletzt bearbeitet:
delta schrieb:
Ich muss die Frage präzisieren. Hat root nicht _immer_ die Möglichkeit auf Securelevel 0 zu kommen und damit schg zu entfernen? Also selbst wenn ich chflags schg /etc/rc.securelevel setze und darin das Securelevel auf 2 setze?
Zum Vergrößern anklicken....
"The kernel runs with five different security levels. Any super-user process can raise the level, but no process can lower it." (aus security(7)). Oder anders gesagt, auch root kann den Securelevel nicht mehr senken, ohne das System komplett neu zu starten.

Was du versuchst zu bauen, ist mit Securelevels aber nur schwer möglich. Oder anders gesagt, das Konzept des Securelevels kommt aus den tiefsten Achtziger, inzwischen hat sich die Welt weiterentwickelt und FreeBSD verfügt über wesentlich potentere Systeme der Rechtevergabe und der Rechteeinschränkung als das klassische Unix-Modell. Securelevels mit Flags mögen noch irgendwo ihren Sinn haben, doch auch das ist nicht mehr so das Wahre. Eines der leistungsfähigsten Subsysteme von FreeBSD ist das zu POSIX.1e konforme und die "Common Criteria for Information Technology Security Evaluation" implementierende MAC-Framework. Leider kennt es kaum einer, obwohl es klassische Sicherheitskonzepte wie zum Beispiel eben die Securelevels drastisch erweitert und anstelle von ACL wie der Name schon sagt auf MAC setzt. Mit MAC kann man verdammt viel machen, was mit klassischen Unix-Konzepten gar nicht oder nur sehr schwer möglich ist.

Für sich dürfte hier vor allem das MLS-Modul des MAC-Frameworks interessant sein. Laut Doku macht es "The mac_mls(4) policy controls access between subjects and objects in the system by enforcing a strict information flow policy." Das Handbuch zu MAC ein umfassendes, großes Kapitel: http://www.freebsd.org/doc/en/books/handbook/mac.html

Vielleicht findest du so einen Ansatzpunkt :)
 
Delta schrieb:
Edit PS: Ich muss die Frage präzisieren. Hat root nicht _immer_ die Möglichkeit auf Securelevel 0 zu kommen und damit schg zu entfernen? Also selbst wenn ich chflags schg /etc/rc.securelevel setze und darin das Securelevel auf 2 setze?
Zum Vergrößern anklicken....
# man security
security(7) schrieb:
Any super-user process can raise the level, but no process can lower it.
Zum Vergrößern anklicken....
Typisches Szenario für einen reinen Logserver.

Edit: 2l8 :)
 
@zuglufttier: Doch schon, so in etwa würde ich es realisieren wollen. Die Problemstellung allerdings besteht auch dann aber immer noch darin die Manipulation der Logs komplett auszuschliessen. Und ich kann mir nicht vorstellen das man das mit den newsyslog(8) permissions allein realisieren kann.

@Yamagi. Was zu Mac im Handbuch steht hab ich jetzt mal quergelesen und MLS & Biba etc. etwas genauer. Ganz schöner Brocken für das was ich ja eigentlich nur realisieren will. Zweifelsfrei hört sich das Klasse an, aber ob das für meine Anforderungen nicht recht viel Overhead ist mir noch nicht ganz klar.

@kazcor Naja, es geht ja hier primär um die zu loggenden Server, nicht um den Logserver als solchen.

@Yamagi & kazcor: Auf diese Frage:

Edit PS: Ich muss die Frage präzisieren. Hat root nicht _immer_ die Möglichkeit auf Securelevel 0 zu kommen und damit schg zu entfernen? Also selbst wenn ich chflags schg /etc/rc.securelevel setze und darin das Securelevel auf 2 setze?
Zum Vergrößern anklicken....

Ist das:

Any super-user process can raise the level, but no process can lower it.
Zum Vergrößern anklicken....

in meinen Augen aber nicht die passende Antwort.

Code: 
kill -TERM -1
etc. und schon ist man von 1 auf 0. In der Praxis. Obs nun ein Super-User Prozess ist oder nicht.
 
Wie ich schrieb. Wenn du die Kiste rebootest oder das System massakrierst (was dem Pseudoprozess -1 eher entspricht), kommst du in einen tieferen Securelevel. Aber wer root ist, hat im klassischen Unix-Modell eh gewonnen. Nichts hindert mich mehr an einem "umount -f /var ; newfs -U -O2 /dev/ufs/var". Und weg sind die wertvollen Logs, trotz schg. Wer sicher gehen will, nimmt noch dd(1) mit dazu. Oder ich zerlege gleich das ganze System: "rm -rf /*". Oder ich werfe mal eben das Tool fsdb(8) oder seinen Bruder clri(8) an und operiere am offenen Herzen...

Unser Gründer sagte mal: "root: gott (whats the difference)" (saintjoe am 4.6.2003)
 
Ja, was wäre die Menschheit ohne ihre Götter. :D

Also mit einer Kombination aus Sudo & schg oder Sudo und mls/Biba liesse es sich doch bewerkstelligen denke ich.

Wenn ich schg auf die Logs setze und unschg für Sudo verbiete ist es ja egal ob das Securelevel sich ändert oder nicht. Sudo kann eh nicht unschg.

Sudo könnte zwar noch die Partition plattmachen, aber dann wäre es ja auch egal weil eh klar ist was läuft. Es geht ja unterm Strich um die Manipulation, nicht ums plattmachen.

Er kann sie weder umbenennen, verändern noch löschen. Aber ich glaube das sehe ich falsch.
 
Hoi,

der sinnvollste Ansatz ist die Daten direkt übärs Netz an einen zentralen Logserver zu senden, welcher die oifach aufschreibts bei sich. Login per Netzwerk oder sonstiges auf den Logserver verbietet mer oifach total. In dem Moment muss mer physikalisch vor Ort sei oder per IPMI / KVM over IP oder so neikommen wenn mer daran was machen will. Damit die Logfiles ausgewertet werden können lässt mer oifach den Logservbären die z.B. per Mail versenden oder per scp wo hochschubsen. Und scho hast 1 Kiste im Netz wo alle Logfiles sicher hat und von extern ned einfach manipulierbar is. Zur Wartung z.B. kann mer uf IPMI oder KVM over IP etc. setzen, falls mer ned jedesmal vor Ort möchte.

Gruß Bummibär
 
Hey Bummi,

so genau stell ich mir das ja auch vor.

Allerdings dreht sich doch auch dein Ansatz um dem Logserver und nicht um den client, der geloggt werden soll, wenn ich dich richtig verstanden habe.

Aber Beispielsweise newsyslog(8) habe ich so verstanden das es per cron die Logs sendet, alle n Minuten zB. wobei die Logs in dieser Zeit ja auf dem Quellserver leicht verändert werden können.

Und syslogd(8) sendet die Logs Live an den Logserver? Weil zuerst steht ja die Manipulation, die nicht zeitgleich geloggt werden kann, sondern verzögert. Oder ist diese Verzögerung rein theoretischer Natur und die Logs gehen Live auf den Logserver? Dann wäre zwar der client kompromittiert aber es wäre sicher geloggt und auswertbar.

Meinst du das so in etwa?
 
mit syslogd bekommst du jede Zeile instantan in Richtung Logserver gesendet.
Desweiteren wird bereits ein SSH Login, bzw. anderen Arten einer Anmeldung geloggt.

Reicht es dir dann aus dass du ermitteln kannst welcher root (von welcher IP) angemeldet war, als ein Schaden/Manipulation angerichtet wurde?
 
Na klar, so würde das passen. Wichtig ist nur das die Daten bevor sie manipuliert werden können auf der sicheren Seite sind.

Und bei einem reboot, ist es da nicht möglich syslogd zB dauerhaft zu verbieten bestimmte Dinge zu loggen? Bevor die Logs gesendet werden? Ich denke schon. Wenn man nur vom Protokollserver ausgeht. Wenn man sich den zu loggenden Server genau betrachtet, ebenfalls als root, fällt es sicher auf. Oder?
 
Wahrscheinlich kann das niemand mehr hören, aber mein Beitrag als Unbedarfter:
oh, I am root, I can do that!

Geht es hier nicht grundsätzlich darum, dass Leute root sind, denen du nicht trauen kannst?
Das ist mitunter keine Frage für ein Betriebssystem, sondern für einen Psychologen.

Grundsätzlich denke ich, dass Menschen nicht root sein dürfen, denen ich nicht vertrauen kann.
Wenn es vorkommt, dass jemand ein System admisistrien muss kann ich auch andere Nutzer dafür zulassen und ich kann mir auch überlegen, denen bestimmte Namen oder Kennungen zu geben, anhand derer ich die identifizieren kann. Ich kann die sogar root nennen und trotzdem eingeschränkte Rechte vergeben. Insbesondere beim Zugriff auf Netzwerk-Ressourcen.
Also, wenn du der "Master of Disaster" bist, kannst du als Ober-root den Unter-roots Beschränkungen auferlegen.
Wenn du das nicht bist, erfasse ich dein Problem vielleicht vollkommen falsch. Dann kannst du nämlich aus guten Gründen einen fremden root nicht in seinen Möglichkeiten einschränken.
 
Wieso? Er hat doch recht. Wie Bruce Schneier mal schrieb, Sicherheit ist ein Prozess. Etwas Allumfassendes, ähnliches eines Puzzle. Jedes Teil hat das gleiche Gewicht und ist gleich wichtig. Es ist eine Denkweise. Und ganz allgemein gesagt sind sehr viele Administratoren nicht nur ein wenig paranoid, sie sind weit jenseits der Grenze, an welcher eine Art Krankheit beginnt. Das sehe ich doch selbst jeden Tag. Da werden Platten verschlüsselt, nicht selten sogar mehrfach. Da wird tagelang diskutiert, ob Twofish, Serpend oder AES sicherer dafür ist. Was das BKA (ein Witz in sich, wer Ärger mit dem BKA hat, sollte sich andere Sorgen machen) am wenigsten knacken kann. Und was ist das Ende vom Lied? Der Server steht ungeschützt im eingeschalteten Zustand im Büro, Tag und Nacht für jedermann zugänglich. Was pit234a sagen möchte ist, dass ein geschützter Logserver gut und schön ist. Nur wieso sollte root die Logdateien nicht verändern können? Sind sie so wichtig, dass um jeden Preis ihre Konsistenz gewahrt bleiben muss und diese Maßnahme nur die allerletzte Mauer ist, welche nur dann greifen muss, wenn die zehn davor versagt haben? Oder ist es, wie er schreibt, so, dass jemand root ist, dem du nicht trauen kannst? In dem Fall liegt das Problem im Prozess und ist durch keine Sicherheitsmaßnahme der Welt zu lösen. Um noch einen Schritt weiterzugehen. Wer sollte ein Interesse haben, die Logs zu verändern? Mitarbeiter, die Mist gebaut haben? Dann sollte man sich überlegen, ob in der Unternehmung nicht generell etwas falsch läuft. Ein Angreifer? Ja, aber wieso ist der Angreifer dann überhaupt so weit vorgedrungen, dass er Logdateien manipulieren muss? Und ist er dann nicht auch schon wieder so mächtig, dass er jede Schranke umgehen kann? Allerdings nur allgemein gesagt und nicht auf den speziellen Fall bezogen, da ich von dem nichts weitergehendes über seine Hintergründe weiß :)
 
Yamagi stellt meine etwas verunglückte Antwort klar und ich entschuldige mich auch für den flappsigen Passus mit den Psychologen. Das hätte ich vielleicht anders ausdrücken sollen.
Wie aber schon gesagt, kommt mich dein Ansinnen sehr merkwürdig vor. Entweder bist du der Platzhirsch und darfst/kannst die anderen in die Schranken weisen und nennst die einfach nur root, ohne dass sie an dich und deine Rechte herankommen, oder du versuchst etwas, das grunsätzlich nicht gelingen kann, weil du anderen zu viele Rechte eingeräumt hast, bzw, weil du nicht ausreichend weit über denen stehst.
Dann muss natürlich die Frage danach, ob dein Vorhaben überhaupt in Ordnung und abgesprochen ist gestellt werden und auch die Frage danach, ob bei dieser Sachlage nicht generell eine falsche Hirarchie/Strategie bei euch gefahren wird.

Natürlich ist das nicht als Lösung für dein Problem direkt anzusehen und eher ein philosphischer Aspekt. Das ist mir schon klar. Aber ungefähr wie beim gordischen Knoten kann es vielleicht ganz hilfreich sein, sich mal Alternativen vorzustellen die gleich die Lösung des Problems in ihrer Struktur beinhalten, anstatt mit falschen oder schlechten Vorgaben unglaubliche Kunstgriffe zu ersinnen, die doch stets Lückenbüßer bleiben.
Mach es doch lieber gleich richtig und lass die anderen nicht zu root werden.
 
oenone schrieb:
Du könntest dir auch mal chflags anschauen, wie du das immutable flag (schg) setzen kannst.
Zum Vergrößern anklicken....
Für Log-Dateien eine blöde Idee - solange da noch reingeschrieben werden muss, sollte es nur sappnd sein. Die rotierten Logs dürfen dann schg geflaggt sein...

P. S. aber wenn es Dir wirklich um den Ultraparanoia-Level geht, solltest Du vielleicht in Betracht ziehen, Logs häufig zu rotieren und die rotierten Logs dann mit GPG oder OpenSSL digital zu signieren - oder einfach mit dem Pubkey zu verschlüsseln. Löschen kann man sie dann zwar immer noch, aber nicht mehr unbemerkt manipulieren...
 
Alles klar pit234a, die nehm ich gern an. Mir rutscht ja auch ab und zu was raus..

@Yamagi: Im Prinzip sehe ich das komplett anders. Was du schilderst sind Deppen, die an einer Flanke alle Truppen konzentrieren während die andere ungeschützt bleibt. Da fehlt dann einfach ein stimmiges Konzept, eine Strategie.

Um mal dein Beispiel mit dem BKA zu nehmen, und darum gehts mir nun wirklich nicht, aber egal. Warum sollte er sich andere Sorgen machen? Welche denn? Sagst du ihm welche Sorgen er sich machen soll? Oder meinste nicht das er, und nur _er_, am besten beurteilen kann, welche Sorgen er sich machen muss? Vielleicht hat er auch schon an alles andere gedacht und will nun den momentan sichersten Verschlüsselungsstandard. Vollverschlüsselung von Laptops ist doch zB extrem wichtig. Oder stellst du erst Möbel in deine Wohnung und n Bett und baust dann irgendwann das Schloss ein? Also ich nicht.. Ob das nun krank ist oder nicht. Ich schliess auch meine Tür 2mal ab, nicht nur einmal. Vielleicht dauert es beim Einbruch dann die entscheidende Minute länger und mein Nachbar kriegt es dadurch mit. Oder vielleicht winkt das BKA bei der einen Verschlüsselung gleich ab weil sie eh wissen das sie es nicht aufbekommen. Sicheres Passwort mal vorausgesetzt. Wer weiss das schon?

Und na klar: Sicherheit ist ein Prozess. Ganz genau so sieht es aus. Aber das Wort Prozess impliziert ja das etwas am laufen ist, in Bewegung, etwas getan wird. Das man beginnt etwas zu tun und dann stetig daran weiterarbeitet, es ausfeilt.

Und auf die Frage: Wieso sollte root die Logs nicht ändern können gibts eine ganz einfache Antwort: Weil ich es so will.

Und ich zitiere jetzt einfach mal aus dem Handbuch, Kapitel 17.1.:

Das FreeBSD-Betriebssystem unterstützt ein feingranuliertes Sicherheits-Auditing. Ereignis-Auditing erlaubt die zuverlässige, feingranulierte und konfigurierbare Aufzeichnung einer Vielzahl von sicherheitsrelevanten Systemereignissen einschliesslich Benutzereingaben, Konfigurationsänderungen sowie Datei- und Netzwerkzugriffen. Diese Log-Datensätze können unschätzbar wertvoll sein für direkte Systemüberwachung, Einbruchserkennung und Post-Mortem-Analyse.
Zum Vergrößern anklicken....

Siehn es doch auch mal unter diesem Aspekt: Systemüberwachung, Einbruchserkennung und Post-Mortem-Analyse.

Sehr häufig verhält es sich doch gerade so, das ein kompromittiertes System eben nicht plattgemacht wird, selbst wenn der Angreifer root erbeuten konnte. Er nistet sich ein, still und leise und nutzt den Server. Möglichst so das es niemandem auffällt. Und natürlich wird er zu diesem Zweck auch die logs anpassen. Weil er es kann. Und weil es zu seiner Tarnung beiträgt. Ich finde das gar nicht so Paranoia oder an den Haaren herbeigezogen.

Wenn es so laufen würde wie ich es mir vorstelle wäre dies nicht möglich.

Ich finde gerade auch unter den genannten Sicherheitsaspekten müsste das von mir gewollte durchführbar sein.

@Ogion: Daran hatte ich auch schon gedacht. Das muss ich mal genau durchdenken aber das wäre auf jeden Fall keine schlechte Variante.

Grüsse und schönes WE euch.
 
Ich gebe zu, ich halte nicht viel von Sicherheit. Meine bisherigen Erfahrungen haben mir einfach gezeigt, dass jemand, der wirklich angreifen will diesen Angriff auch durchführen wird. Egal was ich ihm in den Weg stelle. Zum Beispiel schließe ich meine Tür nur ab, weil die Versicherung es will. Ziehe ich sie ins Schloss, ist sie zu. Ein eventueller Einbrecher, der sie in dem Zustand aufbekommt, bekommt den Zylinder auch einmal, zweimal, dreimal oder n-mal herumgedreht. Oder er nimmt die gute, alte Kettensäge (bei einem Kollegen passiert). Oder schlägt das Küchenfenster ein... Solange ich hier in der Gegend bin, schließe ich mein Auto auch nicht ab. Ich nehme nur den Schlüssel mit. In das Fahrzeug einzubrechen ist keine Kunst, hält eine Verriegelung 30 Sekunden stand, ist sie als sicher eingestuft. Die wirkliche Hürde ist, die Karre trotz Wegfahrsperre gestartet zu bekommen. Wer das kann, klaut sie auf jeden Fall, egal ob die Tür abgeschlossen ist oder nicht. Ich lasse allerdings nichts im Auto liegen, was von Wert ist. Da jeder Depp die Frontscheibe einschlagen kann und es mitnehmen.

In der IT sehe ich es ähnlich. Ich mache Industrietechnik und es gibt in dem Bereich eine Art Mafia, die gezielt Industriespionage betreibt und auch liebend gern Daten klauen will und verhökern will. Klar sind meine Systeme entsprechend geschützt, wenn der Kunde es will, können wir auch gern eine Spezialfirma hinzuziehen und sie das ganze prüfen und zertifizieren lassen. Nur, bei allen bisher (nachweisbar, und das sie sind fast alle, da die Daten oder ihre Nutzung irgendwann irgendwo wieder auftaucht) war das nicht der Punkt. Es waren die ganze dummen Angriffe, die erfolgreich waren. Ein Mitarbeiter hat einmal die Daten kopiert, er brauchte für seinen Job Zugriff auf sie. Praktisch unverhinderbar, eher ein Problem der Personalabteilung als der IT. Das Auditing hat funktioniert, man konnte nachweisen, von welchem Account geklaut wurde, aber das Kind war in den Brunnen gefallen, Troja brannte und in Fernost lachte man wahnsinnig. Wir hatten nette Fälle, in denen die guten, alten Hardwarekeylogger eingesetzt wurde. Einmal wurde sogar das verschweißte Rohr mit dem Netzwerkkabel in aller Ruhe durchgeflext, das Netzwerkkabel durchtrennt und so ein nettes Gerät zwischen gehängt. Das System hat's bemerkt, aber bis was passierte waren schon 10 Stunden vergangen und wieder lachte jemand.

Ich hatte es auch schon öfter, dass das LKA hier morgens um 0730 klingelte und mir einen Schrieb vor die Nase hielt. "Firma XYZ wurde was geklaut, Verdacht gegen Sie, dürfen wir mal reinkommen?" Beim ersten Mal ruft man vielleicht noch den Anwalt an, ab dem zweiten Mal bietet man den Herren einen Kaffee an, tippt das Kennwort in die Workstation und lässt sie ihre Arbeit tun. Oder wenn sie es mitnehmen wollen, lässt man sie halt die Kiste mitnehmen, legt Passwort und Schlüsseldatei aber bei, um sie endlicher Zeit wiederzubekommen. Denn am Ende bekommen sie ihren Willen eh, die Frage ist nur, wie viel Ärger es dir macht. Man selbst holt sich dann halt das Backup aus dem sicheren Hafen und macht damit weiter.

Mit anderen Sorgen meinte ich, wenn das BKA/LKA mir wirklich was vorwerfen kann, ist die Festplattenverschlüsselung meine letzte Sorge. Denn wenn sich der Plan für den Bombenanschlag verschlüsselt auf meiner Platte befindet, wäre es schon verdammt dämlich. Einmal davon abgesehen, dass sie in der absoluten Mehrzahl der Fälle eh schon genug gegen mich in der Hand haben dürften, um mich wirklich dran zu bekommen. Es wäre dann nur noch eine Frage von Kooperation oder totaler Verweigerung jeglicher Zusammenarbeit. In Bezug auf das Strafmaß dürfte Ersteres meist lohnenswerter sein.

Ebenso mein Notebook. Klar, es ist verschlüsselt. Aber muss es das sein? Nö, es ist nur gegen Dummen, um sie ein wenig zu ärgern. Ein mobiles Gerät kann entwendet werden, darauf haben also persönliche Daten, Bankdaten und der zugehörige Login, SSH-Schlüssel, Privatporn oder was weiß ich gar nicht zu suchen. Wer solche Dinge darauf lagert, geht bewusst ein Risiko ein und muss dann halt auch mit eventuellen Konsequenzen leben.

Das soll nun nicht heißen, dass jede Form der Sicherheit sinnlos ist. Ich verschlüssele meine Platten, ich verschlüssele mein Laptop. Aber vor allem, damit ein Einbrecher meine Daten nicht bei Ebay verhökert. Aber ich erwarte gar nicht, dass die Verschlüsselung mich im Zweifel gegen den Staat schützt. Das tut sie nämlich nicht. Genauso verbaue ich tolle Sicherheitssysteme, seitens der Hardware und der Software. Aber ich sage meinen Kunden auch klipp und klar, dass der wahre Schwachpunkt woanders liegt und das eine zusätzliche Maßnahme A ebenso wie ihre Alternativen B und C vielleicht die gefühlte Sicherheit erhöhen, aber die reale Sicherheit kaum.

Zu den Logs: Wie ich sagte, ich sehe es so. Wer root ist, hat gewonnen. Basta. Wenn ich durch das System selbst nicht mehr herankomme, gibt es im System Möglichkeiten es zu umgehen. Den Dateidebugger, um einen Weg zu nennen. Also würde ICH mir die Frage wie ich root am Manipulieren der Logs hindern kann niemals stellen. Ich würde stattdessen verhindern, dass eventuelle Angreifer überhaupt root erlangen.
 
Schöne Zusammenfassung von dem, was Yamagi schreibt: http://xkcd.com/538/

Allerdings gibt es den ein oder anderen Punkt, mit dem ich nicht ganz einverstanden bin. Natürlich muss es oberste Priorität bleiben, Eindringlinge so früh wie möglich abzufangen. Je nachdem wie exponiert ein System ist, muss ich aber damit rechnen, dass die äußeren Schilde schon mal durchbrochen werden. Dann sollte es weitere Verteidigungsringe geben, die vor allem bei der Schadensbegrenzung unterstützen sollen (z. B. verhindern, dass ein gekaperter httpd-Prozess root-Rechte erlangt, Zugriff auf andere Teile des Systems bekommt, o. ä.). Nur die Tür zuziehen, wenn der Monatslohn dann in Bar auf dem Küchentisch liegt, ist halt doch ein Risiko, das ich nicht unbedingt eingehen würde...

Auf Log-Dateien lege ich dabei ein besonderes Augenmerk, denn sie sind oft die einzige Möglichkeit, überhaupt zu bemerken, dass man ungebetene Gäste im System hat. Insofern ist es schon eine Überlegung wert, Logdateien in besonderem Maße vor Manipulation zu schützen - allerdings macht das natürlich nur dann sinn, wenn man Logs auch regelmäßig auswertet und entsprechend reagiert. Securelevels retten einen dabei nicht unbedingt - wie Yamagi schon schreibt, wer root ist, kann auch diese irgendwie außer Gefecht setzen oder umgehen. Wenn Systeme aber so hochsensibel sind, dann muss man eben in den sauren Apfel beißen und Logs auf einen entsprechend abgeschotteten Protokollserver übertragen oder sogar per Endlosdrucker auf Papier bannen.
 
Das war auch durchaus nicht als Witz gemeint. Bei uns in der Firma wird auch noch "analog" archiviert - bei einer erwarteten Produktlebensdauer von 30-50 Jahren und scharfen Dokumentations- und Nachweispflichten ist Microfilm immer noch die sicherste Methode der Aufbewahrung...
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben