Konfigurationsänderungen überwachen

Alles rund um sicherheitsrelevante Fragen und Probleme.
Antworten
Benutzeravatar
heisenberg
Beiträge: 1551
Registriert: 04.06.2015 01:17:27

Konfigurationsänderungen überwachen

Beitrag von heisenberg » 11.10.2019 13:28:47

Hallo zusammen,

ich habe derzeit mit dieser Aufgabe zu tun, die grundsätzlich sehr anspruchsvoll ist:

Die Aufgabe ist, in Echtzeit Änderungen an Konfigurationsdateien zu erkennen mit...
  1. Zeitpunkt der Änderung
  2. integrierter Manipulationssicherheit(ohne 100% Perfektionsanspruch)
  3. Erkennung des Benutzers, der die Änderung durchführt
  4. Inhaltlichem Änderungstext an der Datei
Punkt a) und c) kriege ich durch das Linux-Audit-Log gut raus.

Punkt b) stelle ich mir schwierig vor, wenn es Leute gibt, die grundsätzlich über Root-Berechtigung verfügen. Auch wenn die ursprüngliche User-ID erhalten bleibt(via Linux-Audit), kann man als root natürlich alle Dateien verändern und löschen. Deswegen wäre der Plan hier, die Log-Daten so schnell wie möglich weg vom System zu bekommen(Remote-Audit-Log oder Remote-Syslog). Da kriege ich dann z. B. auch mit, wenn jemand den AuditD per kill abschiesst, bevor er ausgeführt wird, oder wenn Audit-Regeln geändert werden.

Der schwierige Punkt ist d): Da habe ich 2 Fragen, die ich nicht einfach finde:
  1. Wie bekomme ich die Änderungen daran möglichst schnell im Detail(als diff) protokolliert?
  2. Wie bekomme ich die Dateiänderungen zuverlässig den Linux-Audit-Events zugeordnet?
Habt Ihr da Ideen dazu?

Grüße,
h.
Zuletzt geändert von heisenberg am 11.10.2019 13:33:28, insgesamt 2-mal geändert.
Die Welt und die Menschen brauchen Dich! Engagiere Dich für den Klimaschutz!

eggy
Beiträge: 1952
Registriert: 10.05.2008 11:23:50

Re: Konfigurationsänderungen überwachen

Beitrag von eggy » 11.10.2019 13:31:37

etckeeper kennst Du schon? Das könnte man vielleicht entsprechend extern syncen.

Benutzeravatar
heisenberg
Beiträge: 1551
Registriert: 04.06.2015 01:17:27

Re: Konfigurationsänderungen überwachen

Beitrag von heisenberg » 11.10.2019 13:35:07

Ja. etckeeper und auch changetrack kenne ich.
Die Welt und die Menschen brauchen Dich! Engagiere Dich für den Klimaschutz!

Benutzeravatar
heisenberg
Beiträge: 1551
Registriert: 04.06.2015 01:17:27

Re: Konfigurationsänderungen überwachen

Beitrag von heisenberg » 11.10.2019 15:31:11

Sofern ich keinen besseren Weg finde, wie ich die Änderung mit dem verursachenden Benutzer in Verbindung bringen kann, muss ich das wohl über den zeitlichen Zusammenhang regeln.

Ansonsten scheint mir inotifywait eine gute Möglichkeit zu sein.

Hier eine Perl-Demo, die eine audit-message mit dem diff(base64-encoded) erzeugt:

Code: Alles auswählen

#!/usr/bin/perl

#
#       - Track files in /etc
#       - Create audit log message with diff for every changed file
#

use MIME::Base64;

# watch for file changes
open($inotifywait,"inotifywait --recursive --monitor --event modify /etc --format '%T %w%f %e' --timefmt '%s' 2>/dev/null|");

while($line=<$inotifywait>) {


        # exclude irrelevant files
        #       - .git directory (track-loop!)
        #       - .etckeeper file/directory (track-loop!)
        #       - Editor .swap-files

        next if($line =~ /(\/etc\/\.git|\.etckeeper)/);
        next if($line =~ /\.[^\/]+\.swp$/);

        ($time,$fullpath,$event) = split(/[\s]+/,$line);
        ($path,$file)            = $fullpath =~ /(.*)\/([^\/]+)$/;

        $diff = `cd $path && git diff $file`;

        # ignore events with empty diffs
        if($diff ne '') {

                # encode it to base64 to avoid problems with special characters
                $diff = encode_base64($diff);

                #no linebreaks in audit message!
                $diff =~ s/\n/__/g ;

                # commit any changes after detection
                system("cd $path && git commit -m 'auto-commit-".time()."' $file 2>/dev/null >&2");

                # create audit message with encoded diff
                system("auditctl -m 'file_content_tracker $fullpath " .$diff."'");

                print("file change detected: file=$fullpath,time=$time,diff_length=".length($diff)."\n");
        }
}
Kleine Anmerkung: Auf einem System, auf dem man umfassend Linux-Audit einsetzt(also die generelle Kommandoverfolgung davon) sollte man tunlichst nicht zu viele Shellscripte verwenden, da Shellscripte sonst ggf. extrem viele Audit-Meldungen erzeugen(Für jedes: cut,grep,sed,... ca. 6 Zeilen). Das ist einer der Gründe für Perl hier.
Zuletzt geändert von heisenberg am 11.10.2019 16:12:11, insgesamt 1-mal geändert.
Die Welt und die Menschen brauchen Dich! Engagiere Dich für den Klimaschutz!

MSfree
Beiträge: 4655
Registriert: 25.09.2007 19:59:30

Re: Konfigurationsänderungen überwachen

Beitrag von MSfree » 11.10.2019 15:57:10

Ich werfe hier mal Debiantripwire ein. Allerdings dürfte das nicht ganz deinen Anforderngen entsprechen. Tripwire erkennt Änderungen an Dateien nur anhand von Prüfsummen.

Benutzeravatar
heisenberg
Beiträge: 1551
Registriert: 04.06.2015 01:17:27

Re: Konfigurationsänderungen überwachen

Beitrag von heisenberg » 11.10.2019 16:41:15

@MSfree: Danke für den Hinweis! Tripwire,Suricata,OSSEC,... sind mir zumindest von Namen und Funktion auch ungefähr bekannt.

Das ist in der Tat nicht so das was ich suche. Es geht mir eher um Ideen wie man die beiden Ereignisse(Änderungsinhalt und Änderungs-Audit-Event) zuverlässig zusammenführen kann. Ich weiss nicht, ob das überhaupt möglich ist.
Die Welt und die Menschen brauchen Dich! Engagiere Dich für den Klimaschutz!

eggy
Beiträge: 1952
Registriert: 10.05.2008 11:23:50

Re: Konfigurationsänderungen überwachen

Beitrag von eggy » 11.10.2019 17:03:49

heisenberg hat geschrieben: ↑ zum Beitrag ↑
11.10.2019 16:41:15
Es geht mir eher um Ideen wie man die beiden Ereignisse(Änderungsinhalt und Änderungs-Audit-Event) zuverlässig zusammenführen kann. Ich weiss nicht, ob das überhaupt möglich ist.
Deswegen dachte ich an etckeeper, damit hättest Du ja den git hash der Objekte und die Zeitstempel. Lies dich mal ein welche Formatierungsmöglichkeiten git log bietet, damit bekommst Du bestimmt ne ausreichend schöne Ausgabe für Deine Dokumentation erzeugt.
Das Einchecken von Änderungen solltest Du auch über inotify triggern können.

Benutzeravatar
heisenberg
Beiträge: 1551
Registriert: 04.06.2015 01:17:27

Re: Konfigurationsänderungen überwachen

Beitrag von heisenberg » 11.10.2019 18:12:34

Deswegen dachte ich an etckeeper, damit hättest Du ja den git hash der Objekte und die Zeitstempel.
Ich glaube da reden wir aneinander vorbei. Den Zeitstempel habe ich bereits. Das Objekt(die Datei) habe ich auch. Ich möchte wissen wer sie geändert hat bzw. ob der Benutzer tatsächlich den gezogenen diff verursacht hat. Wenn zwei Benutzer die Datei in einem Zeitabschnitt geändert haben, dann möchte ich gerne wissen, wer welche Änderungen vorgenommen hat. Das mit dem zeitlichen Zusammenhang könnte funktionieren. Aber es scheint mir ohne exakten Zusammenhang eher Glückssache zu sein.

Als Hintergrund und vielleicht zum allgemeinen Interesse etwas Erläuterung zum Thema Linux-Audit

Die Regeln

Code: Alles auswählen

auditctl -l

-a always,exit -F arch=b32 -S execve -F key=auditcmd
-a always,exit -F arch=b64 -S execve -F key=auditcmd
-w /etc/wichtig.txt -p w -k log-configuration-change
Die ersten beiden Regeln besagen, dass der Aufruf von 32-Bit und 64-Bit Programmen bitte protokolliert werden soll mit dem Schlüsselwort auditcmd. Die 3. Regel besagt, dass der Schreibzugriff auf die Datei /etc/wichtig.txt mit dem Schlüsselwort log-configuration-change protokolliert werden soll.

Der Zugriff

Wenn ich jetzt mit dem vi die /etc/wichtig.txt editiere und speichere, bekomme ich zwei Events mit diversen logzeilen.

Das Log

Code: Alles auswählen

 1 type=SYSCALL msg=audit(1570812463.716:155703): arch=c000003e syscall=59 success=yes exit=0 a0=250dba0 a1=2503db0 a2=24d65a0 a3=7fffe3976ee0 items=2 ppid=3257 pid=3273 auid=1003 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=6017 comm="vi" exe="/usr/bin/vi" key="auditcmd"
 2 type=EXECVE msg=audit(1570812463.716:155703): argc=2 a0="vi" a1="/etc/wichtig.txt"
 3 type=CWD msg=audit(1570812463.716:155703):  cwd="/root"
 4 type=PATH msg=audit(1570812463.716:155703): item=0 name="/bin/vi" inode=924844 dev=fd:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 objtype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
 5 type=PATH msg=audit(1570812463.716:155703): item=1 name="/lib64/ld-linux-x86-64.so.2" inode=917409 dev=fd:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 objtype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
 6 type=PROCTITLE msg=audit(1570812463.716:155703): proctitle=7669002F6574632F776963687469672E747874
 7 type=CONFIG_CHANGE msg=audit(1570812465.091:155704): auid=1003 ses=6017 op=updated_rules path="/etc/wichtig.txt" key="log-configuration-audit" list=4 res=1
 8 type=SYSCALL msg=audit(1570812465.091:155705): arch=c000003e syscall=82 success=yes exit=0 a0=219f9d0 a1=219e1a0 a2=fffffffffffffe80 a3=7fff4af2ddd0 items=4 ppid=3257 pid=3273 auid=1003 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=6017 comm="vi" exe="/usr/bin/vi" key="log-configuration-audit"
 9 type=CWD msg=audit(1570812465.091:155705):  cwd="/root"
10 type=PATH msg=audit(1570812465.091:155705): item=0 name="/etc/" inode=130569 dev=fd:01 mode=040755 ouid=0 ogid=0 rdev=00:00 objtype=PARENT cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
11 type=PATH msg=audit(1570812465.091:155705): item=1 name="/etc/" inode=130569 dev=fd:01 mode=040755 ouid=0 ogid=0 rdev=00:00 objtype=PARENT cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
12 type=PATH msg=audit(1570812465.091:155705): item=2 name="/etc/wichtig.txt" inode=137950 dev=fd:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 objtype=DELETE cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
13 type=PATH msg=audit(1570812465.091:155705): item=3 name="/etc/wichtig.txt~" inode=137950 dev=fd:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 objtype=CREATE cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
14 type=PROCTITLE msg=audit(1570812465.091:155705): proctitle=7669002F6574632F776963687469672E747874
15 type=CONFIG_CHANGE msg=audit(1570812465.091:155706): auid=1003 ses=6017 op=updated_rules path="/etc/wichtig.txt" key="log-configuration-audit" list=4 res=1
16 type=SYSCALL msg=audit(1570812465.091:155707): arch=c000003e syscall=2 success=yes exit=3 a0=219f9d0 a1=241 a2=1a4 a3=0 items=2 ppid=3257 pid=3273 auid=1003 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=6017 comm="vi" exe="/usr/bin/vi" key="log-configuration-audit"
17 type=CWD msg=audit(1570812465.091:155707):  cwd="/root"
18 type=PATH msg=audit(1570812465.091:155707): item=0 name="/etc/" inode=130569 dev=fd:01 mode=040755 ouid=0 ogid=0 rdev=00:00 objtype=PARENT cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
19 type=PATH msg=audit(1570812465.091:155707): item=1 name="/etc/wichtig.txt" inode=139512 dev=fd:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 objtype=CREATE cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
20 type=PROCTITLE msg=audit(1570812465.091:155707): proctitle=7669002F6574632F776963687469672E747874
In Zeile 8 habe ich also einen Eintrag mit dem Schlüsselwort "log-configuration-audit". D. h. da hat meine obige Regel gegriffen. In der Zeile steht, dass der Benutzer die id 1003 hatte, als er sich angemeldet hat(=auid) und jetzt mit der id 0 (=root) unterwegs ist und dass da vi ausgeführt wurde.

Wenn ich möchte, kann ich mir jetzt noch über die in Zeile 8 enthaltene PID(pid=3273) den passenden SYSCALL der Befehlsausführung im Eintrag aus Zeile 1 heraussuchen und von diesem mit der audit-id 1570812463.716:155703 auf den EXECVE Call in der Zeile 2 gehen in dem alle Befehlsparameter stehen. Damit habe ich den kompletten Befehl der Änderung.
Zuletzt geändert von heisenberg am 12.10.2019 18:39:35, insgesamt 7-mal geändert.
Die Welt und die Menschen brauchen Dich! Engagiere Dich für den Klimaschutz!

MSfree
Beiträge: 4655
Registriert: 25.09.2007 19:59:30

Re: Konfigurationsänderungen überwachen

Beitrag von MSfree » 11.10.2019 18:22:43

heisenberg hat geschrieben: ↑ zum Beitrag ↑
11.10.2019 18:12:34
Ich möchte wissen wer sie geändert hat.
Ich fürchte, das wirst du nicht mit letzter Gewissheit herausbekommen. Unter /etc braucht man root-Rechte für die meisten Dateien, also ist derjenige, der die Datei geändert hat, root. Das kann durch ein echtes Login, su oder sudo passiert sein. Die Verwendung von su und sudo wird zwar gelogt, zwischen dem Aufruf von su(do) und der Dateiänderung kann aber eine eine gewisse Zeit vergehen, sodaß die Zuordnung des Zeitstempels des su(do)-Aufrufes und der Dateiänderung nicht direkt miteinander korrelieren. Wenn sich der Delinquent direkt als root einlogt, hast du überhaupt keine Information, wer der Verursacher war.

Benutzeravatar
heisenberg
Beiträge: 1551
Registriert: 04.06.2015 01:17:27

Re: Konfigurationsänderungen überwachen

Beitrag von heisenberg » 11.10.2019 18:58:02

Ich habe oben nochmal was zu Audit geschrieben, weil das wer nicht wirklich das Problem ist.

Direkte Anmeldung mit root ist nicht erlaubt(Per SSH-Konfiguration unterbunden. Lokale Root-Logins werden alarmiert). Nur für berechtigte Personen sudo/su - eben aus dem Grund der Nachvollziehbarkeit.

Mit der Info ses=6017 in der Zeile 8 kann man sich z. B. auch alle Befehle dieser Shell-Sitzung heraussuchen.
Die Welt und die Menschen brauchen Dich! Engagiere Dich für den Klimaschutz!

Benutzeravatar
ThorstenS
Beiträge: 2830
Registriert: 24.04.2004 15:33:31

Re: Konfigurationsänderungen überwachen

Beitrag von ThorstenS » 12.10.2019 06:30:29

wow, ein sehr interessanter thread - danke dafür!
Ich tracke bisher ausschließlich mit etckeeper. Über einen hook pushe ich manuell/stündlich die Configänderungen ins gitlab, jeweils in einen branch pro host. Mich hat bisher geärgert, dass ich nicht exakt sehe, WER und WANN die Änderungen vorgenommen hat.

Benutzeravatar
HZB
Beiträge: 414
Registriert: 22.10.2003 11:52:15
Wohnort: Wien

Re: Konfigurationsänderungen überwachen

Beitrag von HZB » 13.10.2019 10:27:38

heisenberg hat geschrieben: ↑ zum Beitrag ↑
11.10.2019 13:28:47
Hallo zusammen,

ich habe derzeit mit dieser Aufgabe zu tun, die grundsätzlich sehr anspruchsvoll ist:

Die Aufgabe ist, in Echtzeit Änderungen an Konfigurationsdateien zu erkennen mit...

Habt Ihr da Ideen dazu?

Grüße,
h.
Ich hoffe Du nimmst es mir nicht böse und verstehst mich nicht falsch, aber was soll das Ergebins sein, bzw was willst Du erreichen ?

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 ;-)

Benutzeravatar
heisenberg
Beiträge: 1551
Registriert: 04.06.2015 01:17:27

Re: Konfigurationsänderungen überwachen

Beitrag von heisenberg » 13.10.2019 17:12:44

@HZB:

Die Beschreibung Deiner Umgebung trifft die Umgebung, die ich hier habe auch recht genau.

Bzgl. des Betriebes der Serverlandschaft ist man hier allerdings noch nicht so weit. Hier ist es noch Tagesgeschäft, dass man oft mit root eingreifen muss. Die Situation, die Du beschreibst ist auch die Zielvorstellung hier.

Was das Echtzeitalarmieren betrifft: Echtzeit heisst vielleicht eher zeitnah. Und was dann alarmiert wird und was nicht, dass ist dann nochmal eine weitere Entscheidung, die ich nicht zu treffen habe. Das SIEM (Security Information and Event Management) ist hier momentan im Aufbau. Meine Vorgabe ist zeitnahe Erkennung von diversen Ereignissen, die in dieses SIEM als Datenquellen einfließen.

Meine persönliche Meinung ist, dass man gewisse Ereignisse, wie z. B. jemand ändert Einstellungen am Audit-System schon auch direkt wissen will und das finde ich jetzt auch so nicht grundfalsch. Es soll halt schon erkannt werden, wenn jemand sicherheitsrelevante Einstellungen vornimmt, so dass es bemerkt wird, bevor da z. B. sensible Daten abgezogen werden.
Die Welt und die Menschen brauchen Dich! Engagiere Dich für den Klimaschutz!

Antworten