Konfigurationsänderungen in Echtzeit überwachen

[heisenberg]

Etwas was mir noch aufgefallen ist: Ich möchte ja die Ausführung diverser Befehle verfolgen.

Es gibt eine Klasse von Befehlen, die man nicht verfolgen kann: Shell-Builtins. Da wird genau einmal er Aufruf der Shell protokolliert und das war's dann.

kill ist bei Bash z. B. ein builtin. Natürlich kann man die Builtins per Shell-Konfiguration abschalten. Es hindert den Benutzer aber nicht daran, es wieder einzuschalten.

[heisenberg]

Ich schreib' hier einfach mal etwas weiter, auch wenn ich der einzige bin hier . Vielleicht ist es ja für jemanden nützlich.

Das mit dem git ist dann doch nicht ganz so einfach wie gedacht. Wenn ich ein Verzeichnis aufnehmen möchte, z. B. /var/lib/alternatives, dann reicht es nicht das einfach so ins .gitignore einzutragen:

Code: Alles auswählen

/*
!/etc
!/var/lib/alternatives

Denn so ist das Verzeichnis /var/lib/alternatives immer noch ausgeschlossen. Das doch noch reinzubekommen ist dann etwas frickeliger:

Code: Alles auswählen

/*
!/etc
!/var
/var/*
!/var/lib
/var/lib/*
!/var/lib/alternatives

D. h. auf jeder Verzeichnisebene erst das Verzeichnis einschließen, dann den kompletten Inhalt ausschließen und dann wieder das eine was man möchte ausschließen.

[heisenberg]

Hier ist noch ein Parser, der das Auditlog einliest und als JSON/XML ausgeben kann. Von dem, was ich bisher so dazu gefunden habe, scheint das das beste zu sein.

aushape - https://github.com/Scribery/aushape

Aushape is a tool and a library for converting Linux audit log messages to JSON and XML, allowing both single-shot and streaming conversion. At the moment Aushape can output to stdout, a file, or syslog(3). The latter outputs one document or event per message.

Andere Parser(z. B. fluentd-Plugins) sind da teilweise sehr begrenzt und die setzen das teilweise nur pro Zeile um und nicht pro Event - was ja sehr viele Zeilen umfassen kann - wie aushape.

[eggy]

Ich schreib' hier einfach mal etwas weiter, auch wenn ich der einzige bin hier . Vielleicht ist es ja für jemanden nützlich.

bist nicht alleine, /me liest mit - ist nen interessantes Thema

[heisenberg]

Ich verstehe noch nicht ganz warum man Änderungen in Echtzeit überwachen muss.
Änderungen im Sinne eines Change Managements sind gewollt. Alles Andere ist Missbrauch.

Der Prozess des Change Managements sollte klar regeln wie Änderungen auszusehen haben und durchzuführen sind.
Bei uns war das eine riesen Aufgabe das umzusetzen. Aber wir sind mit dem Ergebniss zufrieden ( ISO 27001, ISAE 3402 Typ 2 )

Ohne Ticket gibt es keinen Change.
Ein Change muss immer klar sein.
Ein Change löst einen Vorgang aus ( bei uns zB werden Änderungen mittels Ansible durchgeführt und müssen zeitweise weitere Prozesse durchlaufen erst PREPROD danch PROD usw )
Die Ansible Scripts werden bei manchen Changes durch 2 verschiedene Personen kontrolliert zwecks 4 Augen Prinzip und erst danach deployed.
Jeder direkte Zugriff auf ein System wird ins SIEM geloggt und alerted. ( Das hat am Anfang den meisten Lerneffekt gebracht. Wieso greift Admin X auf Host Y zu ? und jeder bekommt es mit )

Ich gebe zu das dies alles bei Kleinst und Kleinumgebungen vielleicht mit Kanonen auf Spatzen schiessen ist. Aber gerade der letzte Punkt ist extrem einfach umzusetzen und hat heilende Wirkung

Nochmal ein Nachtrag dazu:

Ganz genauso war die Anforderung in meiner Umgebung auch.

Ich verstehe aber nicht, warum Du mich nicht verstehst.

Also Echtzeit musste da nicht unbedingt sein. Aber wenn ich Restriktionen von adminstrativen Tätigkeiten durchsetzen will, dann muss ich doch auch ganz genau bestimmen können, wann ein Verstoß stattgefunden hat und worin dieser Verstoß bestanden hat. Und das ist alles andere als trivial.

Zum Hintergrund der "Echtzeit-" oder "zeitnah-" Anforderung oder auch die Unterscheidung zwischen zentralem und dezentralem Ansatz:

Eine Möglichkeit wäre es jetzt sofort alles überhaupt nur extern zu protokollieren - also zentraler Ansatz. Im Falle von AuditD(was jetzt nur eine der Datenquellen ist) bist Du dann ganz schnell bei Hundertausenden von Logzeilen pro Minute. Man braucht also einen sehr fetten Cluster für die Logauswertung, wenn man 100 - 1000 Server hast.

Alternative wäre, dass die Logauswertung dezentral stattfindet und die Logdatenmenge vor der Weiterleitung nach extern drastisch reduziert wird. Das ist aber widerrum anfällig gegen Manipulation und man muss genau schauen, dass man welche Angriffsmöglichkeiten es dagegen gibt und die alle erkennen und sicher melden können.

Desweiteren kann man gewisse Dinge beim zentralen Ansatz nur viel schwerer umsetzen als bei der dezentralen Lösung. Z. B. die Änderung von privilegierten Dateizugriffen mit Änderungstext.

Insofern interessiert mich da doch, was Ihr bei Eurem Projekt da so umgesetzt habe und wie Ihr das gemacht habt.

[wanne]

Mich kotzt das ein bisschen an, dass diese Bullshit Lösungen im Linux-Bereich immer mehr um sich greifen.
Immer mehr Leute, die noch nie Malware auseinander genommen haben bekommen grundliegende Sicherheitskonzepte nicht mal angewendet meinen sie könnten das mit irgend welchen Eigenbastellösungen wieder gerade ziehen. Das ist genau das was Windows in den 90ern dahin geführt hat wo es war.
Deswegen passiert gerade sowas hier:
https://www.heise.de/security/meldung/M ... 21393.html
Nicht auf die reihe bekommen regelmäßig Kernel Updates und Intel Patches einzuspielen aber jetzt wild auf Aktionismus gegen Nutzer mit SSH-Keys gehen und so tun als hätte man verstanden, was das passiert ist:
https://www.heise.de/news/Nach-Angriff- ... 70267.html
Jungs der ist root. Wenn der euren SSH manipuliert, dann nicht weil er das muss, sondern weil er es kann. Der braucht auf euren Systemen weder Keys noch Passwörter. Die nimmt der allenfalls mit weil er sie eventuell noch wo anders gebrauchen kann.

Wenn ihr nicht mal euer /usr und /etc ro bekommt und SELinux selbst unter RHEL zu aufwänig ist, dann braucht ihr mit sicherem logging nicht anfangen...
Ne ist nicht. Einfach Quatsch. Nutzt ausgetretene Wege, bevor ihr irgend welchen fancy scheiß erfindet. Das kosten nutzen Verhältnis ist einfach viel besser wenn es irgend wo einen Weg gäbe mit weniger Aufwand mehr zu erreichen hätten das schon andere vor euch gemacht. An Linux Security sind jetzt wirklich schon ein paar mehr Leute mit mehr Ahnung gesessen.

Wenn Malware den auditd killt dann mindestens sicher per signal() malwareentwickler können nämlich im Gegensatz zum standard-admin C. Und dann hat der auditd genau gar nie eine Chance das noch raus zu schreiben bevor er stirbt das ist nicht mal ne race-Condtion der Kernel regelt das explizit, dass signal schneller als das resceduling ist.

Alle ohne 100% Perfektionsanspruch Maßnahmen sind im Security Bereich einfach Quatsch. Wenn ihr selbst ohne Malwareschreiberfahrung auf Anhieb seht, wie man das umgeht, kannst du dich drauf verlassen, dass Metasploit und jeder andere Baukasten das seit mindestens 20 Jahren drin haben und jedes noch so doofe Scriptkiddie das umgeht ohne was davon zu wissen.

Das gilt insbesondere für euren sodo/su Bullshit da steht aus gutem Grund dran, dass diese log-user nur Informativ sind. Damit könnt ihr einen fahrlässigen Admin erwischen. Aber absolut jeder bösartige Nutzer wird seine Aktionen irgend jemand zu schieben, der sich nach ihm einloggt (oder wenigstens einen 2. Login fälschen). Das macht ganz sicher jede Malware, die root-rechte bekommt. Wer root ist, kann auch Dateien ändern ohne inotify zu triggern. (Wobei das wohl weniger verbreitet ist.) Und der wird auch keine netzwerk-Sockets auf machen, die man irgend wo (netstat) sehen könnte sondern halt direkt selbst kommunizieren. Ganz sicher wird er aber den auditd entweder stumm schalten oder mit falschen Nachrichten füttern inklusive des Datums, dass er irgend wann in die Vergangenheit setzt und der der wird auch git fälschen können.

Ernsthaft: Lasst das. Entweder ihr macht es richtig, wie HZB oder ihr lasst es sein. Aber die Aktion hier klingt für mich wieder nach irgend welchem Zeug das gemacht wird, damit man auch irgend was getan hat und im besten Fall nicht schädlich ist. Aber garantiert wird das nicht den Aufwand wert sein der hier getrieben wird.

Aber dieser ganze Quatsch der von dem braven Admin ausgeht, der sich per ssh anmeldet, mit sudo root wird und dann dann mit der bash und vim arbeitet mag ganz nett für die Dokumentation sein. Die triggern schön eure Events wir ihr das wollt. Gegen Angreifer, die praktisch immer eigene Tools mitbringen, die eben gerade darauf getrimmt sind möglichst klein zu sein und eben keine Spuren zu hinterlassen und keine Events zu triggern ist das absolut sinnlos. Die kommen werden eventuell noch irgend wie Standardkonform root und dann sitzen die mit ihren Tools im RAM und laufen und hinterlassen eben keine Spuren mehr insbesondere werden die keine verdächtigen Systemcalls im eigenen Namen machen. Der macht kein execve sondern manipuliert sich selbst. Der läuft nicht im Hintergrund sondern attatched sich an irgend einen eh schon laufenden "harmlosen" Prozess...

[HZB]

Nochmal ein Nachtrag dazu:

Ganz genauso war die Anforderung in meiner Umgebung auch.

Ich verstehe aber nicht, warum Du mich nicht verstehst.

Ich versteh Dich schon, aber mir gefällt der Ansatz und vielleicht die Definitionen noch nicht ganz

Also Echtzeit musste da nicht unbedingt sein. Aber wenn ich Restriktionen von adminstrativen Tätigkeiten durchsetzen will, dann muss ich doch auch ganz genau bestimmen können, wann ein Verstoß stattgefunden hat und worin dieser Verstoß bestanden hat. Und das ist alles andere als trivial.

Per Definition ist es dann schon zu spät. Klar für eine forensische Analyse ist es notwendig. Aber mal ehrlich. Bevor ich mit Forensik herumschlagen muss, bin ich wohl eine zeitlang beschäftigt die Server komplett neu aufzusetzen und zu konfigurieren usw.

Der Ansatz den man vielleicht hier vergleichen kann, ist wie bei einer Firewall Policy.
Eine Möglichkeit ist, alles zu erlauben und nur explizit Dinge zu verbieten.
Die zweite ist alles zu verbieten und nur sehr selektiv die Dinge zu erlauben.

Und auch bei einer Firewall benötigt man die Logs. Aber genauso wie bei exponierten Servern, sollten mmn Logs NIEMALS auf dem betroffenen Gerät gespeichert werden. Zumindest nicht ausschließlich.

Die größte Arbeit hat man also erstmals zu entscheiden wer was darf und diese Policy ( explizit erlauben und ALLES andere verbieten ) durchzusetzen.
Ich will jetzt nicht behaupten das es egal ist wenn dann einer versucht etwas zu machen was nicht erlaubt ist, aber wenn ich getestet habe, dass er nur minimale Rechte hat ist es nicht mehr so zeitkritisch Ihm auf die Finger zu klopfen.

Das Grundprinzip der ganzen Übung sollte also die Erarbeitung der zwei elementaren Grundsätze sein.
Principal of least privilege und segregation of duty.

Wenn das sichergestellt wurde, kannst Du Dir überlegen welche Verstöße Du überhaupt dokumentieren willst und musst.

Der nächste Schritt ist dann die Automatisierung. Alles was man automatisieren kann wird automatisiert. Das minimiert schlicht und ergreifend die Fehlerquote

[heisenberg]

@HZB:

Ich vermute die Anforderungen zwischen Deinem und meinem Szenario unterscheiden sich erheblich. Das, was ich von Dir höre, liest sich fast schon trivial, auch wenn Du nicht wirklich viel Konkretes über Deine Umgebung und Umsetzungsdetails preisgegeben hast, weil das höchstwahrscheinlich alles auch unter Vertraulichkeit fällt.

[fossonly]

Mich kotzt das ein bisschen an, dass diese Bullshit Lösungen im Linux-Bereich immer mehr um sich greifen.

Vielen Dank für diesen Post. Es hatte mir schon wahnsinnig in den Fingern gejuckt dies selbst zu tun, und dann kam endlich mal etwas sinnvolles. Ich erlebe es ständig das Leute mit irgendeinem Gefrickel um die Ecke kommen, anstatt sich mal mit der Systembasis richtig auseinanderzusetzen. Ich würde sogar sagen das viele dieser kuriosen Ideen, ihren Ursprung in einer früheren Nutzung von Windows haben, und die Leute daher dem Irrtum unterliegen es wäre sinnvoll dieses Nutzungsparadigma auf ihr GNU/Linux zu übertragen. Und für mich hat dieses Tracking von Veränderungen, diesen typischen Nachgeschmack den man von Antivirenprogrammen her kennt. Dabei könnte man es via Immutable-Bit oder read-only Volumes so einfach haben, und ist prinzipiell nicht darauf angewiesen nach Manipulationen suchen zu müssen. Und mittels "ptrace_scope" oder noch besser Kernel-Lockdown, ist das Thema "Process-Hijacking" auch wirksam vom Tisch. Die meisten sollten auch exzessiver Gebrauch von Firejail machen, und idealer Weise in Kombination mit AppArmor. Einfacher kann man die Sicherheit kaum steigern. Man kann Firejail selbst als Login-Shell definieren, um wirklich mal von einer Restricted-Shell sprechen zu können, die man nicht mit einfachsten Mitteln umgehen kann. Dazu noch den Kernel-Lockdown scharf stellen, womit die Angriffsfläche im allgemeinen schon dramatisch sinkt. Ein gehärteter Linux-Kernel kommt letztlich dem ganzen Systeme zugute. Nimmt man dann noch einen Wayland-Compositor wie Gnome, der vorhandene Sicherheitsmechanismen nützlich ergänzt und mittels Nautilus, Gnome-Tracker und der neuen Kindersicherung Infektionen vorbeugt, dann wird das ganze Sicherheitskonzept noch zusätzlich abgerundet. Bei den anderen Desktops sehe ich keine echte sicherheitstechnische Weiterentwicklung, mit Ausnahme von KDE und Sway hinsichtlich Wayland.

[HZB]

@HZB:

Ich vermute die Anforderungen zwischen Deinem und meinem Szenario unterscheiden sich erheblich. Das, was ich von Dir höre, liest sich fast schon trivial, auch wenn Du nicht wirklich viel Konkretes über Deine Umgebung und Umsetzungsdetails preisgegeben hast, weil das höchstwahrscheinlich alles auch unter Vertraulichkeit fällt.

Auftraggeber war eine Bank die seitens eines Regulators im Bereich IT geprüft wurde. Auftrag selbst war die Nachvollziehbarkeit von Systemänderungen, speziell bei der Kernbankenapplikation ( Applikationsserver, Oracle Cluster ) und den dazugehörigen Sattelitensystemens ( Meldewesen Software, SFTP Server, Reverse Proxy, Internet Banking, PSD2 Schnittstellen, MQ Series, etc ). Da zu dieser Zeit noch kein Automatisierungstool vorhanden war hat man die Chance gepackt und im Zuge des Projekts Ansible eingeführt. Mit allen Konsequenzen die daraus entanden sind. Zeitweise waren es technische Neueinführungen. Zeitweise war es eine Umstrukturierung von Berechtigungen, oder Abteilungen. Auch wurden Arbeitsschritte neu strukturiert, gestrichen, neue eingeführt. Das klingt vielleicht wirklich alles trivial, aber das war es nicht. Dennoch waren zum Schluss selbst die größten Kritiker des Projekts zufrieden, und seitens des Regulators gab es auch ein OK.

Ob sich das jetzt genau mit Deinen Anforderungen deckt kann ich so nicht beurteilen. Aber es klingt recht ähnlich.
Aus der Ferne betrachtet versuchst Du derzeit alles zu loggen, die Logs zu sammeln und danach Massnahmen zu ergreifen.
Nur welches Ziel verfolgst Du damit ? Zu wissen was passiert ist, wenn der Schaden bereits entstanden ist ? Sorry vielleicht seh ich es noch nicht, aber mir fehlt irgendwie das Gesamtkonzept was Du erreichen möchtest.

[Colttt]

mMn loggt man sich heutzutage nicht mehr auf Server ein, wenn doch macht man was falsch.. Stichwort Infrastructure-as-a-Code .. da kann man dann denjenigen fragen warum er sich denn eingeloggt hat.. sowas sollte man auch scripten können beim login muss er einen Grund angeben was geloggt wird, wenn er nichts einträgt wird er gekickt.

so würde ich es machen, so liegen die Systeme im git und wenn das System krachen geht, ist das System mit der Config innerhalb ein paar minuten wieder da, evtl Daten die er braucht kommen schnell aus dem backup.. durchs git sieht man genau wer was wann geändert hat und warum..

[Colttt]

sooo und nun??
Was ist jetzt daraus geworden?