Timbre – was auf deinem System normal ist

Wie NODE64 deinen Server mit sich selbst vergleicht – und wie du einen Alarm gefahrlos selbst auslöst.

Jeder andere Teil von NODE64 prüft gegen einen Massstab, der überall gilt: Diese Version hat eine Lücke, diese Einstellung ist falsch, dieses Rahmenwerk verlangt jenes. Timbre kennt nur einen Massstab – deinen Server, gestern.

Der Name kommt aus der Musik. Timbre ist das, was zwei Instrumente unterscheidet, die denselben Ton spielen: gleiche Tonhöhe, gleiche Lautstärke, und man hört trotzdem sofort, ob Geige oder Klarinette. Bei Servern ist es genauso. Zwei Maschinen mit derselben Software verhalten sich verschieden, weil auf der einen ein Shop läuft und auf der anderen ein Backup-Ziel.

Deshalb gibt es keine allgemeingültige Normalität, die man einbauen könnte. Fünfhundert geänderte Dateien sind auf einem Bauserver der Alltag und auf einem Mailserver ein Vorfall.

Wo du es findest #

Beim Gerät, im Reiter Timbre. Und schon davor: In der Übersicht des Geräts steht Timbre in der ersten Zeile, und in der Geräteliste steht auf jeder Kachel ein Satz dazu – „Timbre erkennt aktuell keine Auffälligkeit" oder „Timbre sieht 3 auffällige Merkmale in 2 Bereichen gleichzeitig". Das ist Absicht: Wer einen Befund liest, ohne zu wissen, was auf diesem System normal ist, kann ihn nicht einordnen.

Warum bei mir noch kein Urteil steht #

Das ist die häufigste Frage, und die Antwort ist unspektakulär: Timbre braucht eine Geschichte, und die entsteht erst.

Jeder Lauf des Agenten ist eine Messung. Für ein Urteil braucht ein Merkmal mindestens zwanzig davon – bei den Zählwerten der Prüfverfahren reichen acht. Bis dahin steht dort ausdrücklich „noch kein Urteil möglich" mit der Zahl der bisherigen Messungen daneben.

Das ist keine Entwarnung. Eine Null an dieser Stelle wäre die Behauptung, es sei nachgesehen worden und nichts gefunden. Grau heisst: Es wird gesammelt, aber es ist noch nichts zu sagen.

Das Vergleichsfenster zählt in Läufen, nicht in Stunden. Deshalb steht in jedem Beleg dabei, welchen Zeitraum die Messungen abdecken – sonst bedeutete dieselbe Zahl in zwei Tarifen etwas Verschiedenes.

Wie ein Merkmal zu lesen ist #

Eine Zeile sieht so aus:

laufende Dienste        44     44 statt sonst 40, aus 96 Messungen über 4 Tage

Links steht der aktuelle Wert, rechts der Beleg: der auf diesem Gerät übliche Wert, die Zahl der Messungen und der Zeitraum. Damit lässt sich jedes Urteil nachrechnen – und widerlegen. Genau deshalb gibt es keine Gesamtnote: Eine Zahl von 0 bis 100 könnte man weder nachrechnen noch widerlegen.

Die Verlässlichkeit daneben beantwortet die Frage „wie ernst darf ich das nehmen". Sie wächst mit der Zahl der Messungen und steht bewusst neben jedem Urteil statt in einer Fussnote.

Funktioniert das bei mir? #

Ein Sicherheitswerkzeug, das man nicht ausprobieren kann, muss man glauben. Und niemand glaubt einem Alarm, den er nie hat auslösen sehen.

Die folgenden vier Befehle lösen jeweils genau einen Sofortindikator aus. Sie sind in Sekunden wieder rückgängig, sie richten keinen Schaden an, und sie hinterlassen nichts. Führe sie auf einem Gerät aus, dessen Agent läuft – der Alarm sollte in unter einer Minute bei dir sein.

1 · Shell unter dem Webserver #

Der aussagekräftigste Test. Er sieht einer echten Web-Shell zum Verwechseln ähnlich – das ist gewollt, denn genau das soll erkannt werden.

Der Benutzer, unter dem der Webserver läuft, heisst je nach Distribution anders:

Wenn du die falsche Zeile erwischst, bekommst du „unbekannter Benutzer" und sonst nichts. Kein Alarm heisst dann nicht, dass Timbre nicht funktioniert – nur, dass der Befehl nie gelaufen ist.

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. /tmp ist für jeden beschreibbar und damit der erste Ort, an dem etwas landet, das von aussen kommt.

3 · Muster einer Rückwärtsverbindung #

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

Dieser Befehl 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.

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 Kryptowährungs-Schürfers aussieht. Es wird nichts gerechnet und nichts verbunden.

Einzeln ausführen, nicht alle auf einmal #

Führe die Befehle nacheinander aus, jeden in einer eigenen Zeile. Setzt du sie zusammen ab, enthält die Kommandozeile deiner eigenen Shell alle Muster gleichzeitig – und dann meldet Timbre nicht vier Vorgänge, sondern acht: die vier Testprogramme und die Shell, die sie gestartet hat.

Das ist kein Fehler, sondern richtig: Eine Shell, deren Aufrufzeile stratum+tcp:// und /dev/tcp/ enthält, ist genau das, was erkannt werden soll. Beim Testen ist es nur verwirrend.

Was dabei passiert – und was nicht #

Der Agent stellt diese vier Dinge selbst fest; er braucht dafür keine Vorgeschichte. Er fällt aber kein Urteil darüber, ob es ungewöhnlich ist – das entscheidet die Plattform, weil nur sie weiss, was auf diesem System normal ist.

Was der Agent überträgt, ist der Vorgang in seiner kürzesten Form: 20114:php-fpm>sh. Die Aufrufzeile selbst verlässt deinen Server nicht – in ihr stehen regelmässig Kennwörter, und der Agent kann nicht unterscheiden, wann.

Ist die Verbindung zur Plattform gerade unterbrochen, schreibt er die Feststellung sofort ins Systemprotokoll deines Systems (journalctl) und meldet sie, sobald er wieder kann.

Woraus Timbre ein Bild macht #

Bis Phase 70 zählte Timbre vor allem: wie viele Dienste, wie viele Ports, wie viele Konten. Das findet ein System, das sich verändert – und verfehlt vieles, was sich innerhalb der gleichen Zahlen abspielt. Vier Dimensionen sind seither dazugekommen.

Das Netz #

Seit Phase 62 weiss NODE64, welches Programm mit welchem Zielnetz auf welchem Port spricht. Drei Grössen kommen jetzt dazu:

Das Datenvolumen je einzelner Verbindung fehlt in aller Regel, und das steht auch so da statt als Null. Der Kernel zählt es nur, wenn net.netfilter.nf_conntrack_acct eingeschaltet ist – und das ist ab Werk aus, auf jeder Distribution. NODE64 schaltet es nicht ein: Der Agent verändert nichts an deinem System. Wer es will, schaltet es selbst ein:

sysctl -w net.netfilter.nf_conntrack_acct=1

Der seltene Zielport ist übrigens beschreibend, nicht anklagend. Ein seltener Port ist ein seltener Port – ob er ein Problem ist, entscheidet erst, was gleichzeitig sonst noch auffällt.

Die Tageszeit #

Ein Sicherungsdienst spricht um drei Uhr nachts mit dem Sicherungsziel. Tut er es mittags, ist das bemerkenswert – und war bis dahin unsichtbar, weil jeder Vergleich gegen den Durchschnitt über alle Stunden lief.

Timbre führt deshalb vierundzwanzig Körbe statt einem, einen je Stunde des Tages. Verglichen wird gegen das, was diese Achse zu dieser Stunde sonst tut.

Im Free-Tarif kann der Tagesgang nie urteilen, und die Rechnung steht dabei:

15-Minuten-Takt   4 Proben je Stunde und Tag  →  20 Proben nach  5 Tagen
60-Minuten-Takt   1 Probe  je Stunde und Tag  →  20 Proben nach 20 Tagen

Free-Tarif        60-min-Takt · 7 Tage Aufbewahrung  →  kommen nie zusammen

Statt dir dauerhaft „sammelt noch" anzuzeigen, sagt das Dashboard, warum.

Für Anmeldungen gibt es keinen Tagesgang, und das bleibt so. Wer wann wie lange auf seinem eigenen Server war, ist keine Sicherheitsfrage – es ist eine Anwesenheitskontrolle. Der Unterschied ist, wer handelt: Ein Dienst, der um drei Uhr sichert, ist eine Maschine mit einem Zeitplan. Ein Mensch, der sich um drei Uhr anmeldet, ist ein Mensch. Ein Test in unserem Bauprozess stellt sicher, dass niemand das versehentlich ändert.

Eine Folge über mehrere Läufe #

Ein Einbruch verteilt sich über Stunden: erst die Anmeldung, dann das neue Konto, später das fremde Netzziel, am Abend die Dateien. Vier Läufe, vier einzelne Ausschläge, in jedem einzelnen zu wenig für einen Befund.

Timbre fasst das zusammen – mit Reihenfolge, denn die Reihenfolge ist die Aussage:

Konten → Netz → Dateien     ein Einbruch
Dateien → Netz → Konten     eine Wiederherstellung aus der Sicherung

Dieselben Bausteine, gegenteilige Bedeutung. Wer sie als Menge behandelt, kann die beiden nicht auseinanderhalten.

Jedes Programm für sich #

Bis dahin beschrieb eine Grundlinie immer das ganze System: „dieser Server öffnet sonst 22 Verbindungen". Das verfehlt das Programm, das sich verändert, solange der Rest des Systems die Zahl deckt.

Timbre führt deshalb eine Grundlinie je Programm. Dabei gibt es ausdrücklich keine Liste bekannter Software: Ein selbstgeschriebener Dienst unter /opt/firma/server bekommt dieselbe Behandlung wie nginx – nämlich gar keine besondere. Jede Liste bekannter Programme kennt genau das nicht, was du selbst gebaut hast.

Ein Programm braucht acht Messungen, bevor über es geurteilt wird. Was einmal die Woche läuft, hat nach einem Monat vier – und über so etwas urteilt Timbre nicht, sondern schweigt.

Der Auslieferungszustand #

Deine Paketverwaltung führt mit, welche Prüfsumme jede Datei bei der Auslieferung hatte. Diese Liste liegt auf deinem Server, kostet nichts und wurde bis dahin nicht gelesen – auf einem gewöhnlichen Debian sind es über sechzigtausend Dateien.

Das beantwortet eine andere Frage als die Integritätsprüfung:

Die erste ist die interessante, wenn ein Server schon bei der Installation verändert war: Dann hat die eigene Bestätigung die Veränderung als Normalzustand aufgenommen.

Geprüft werden die überwachten Pfade plus alle Programme mit gesetztem setuid- oder setgid-Bit – dort bedeutet eine Veränderung am meisten, weil sie mit fremden Rechten läuft. Nicht geprüft wird, was sich ändern darf: Konfigurationsdateien, Dokumentation und Dateien, die es auf der Platte gar nicht gibt.

Ohne Paketverwaltung steht „nicht anwendbar" – nicht „keine Abweichung". Das ist derselbe Unterschied wie überall in Timbre: nicht gemessen ist nicht dasselbe wie nichts gefunden. Und es geht dafür kein einziger Aufruf nach draussen: Die Liste liegt bei dir.

Kenne ich diese Lage schon? #

Aus allem zusammen entsteht je Lauf eine Zahlenreihe – das Timbre deines Systems. Zwei Läufe mit derselben Reihe sind dieselbe Lage, auch wenn sie Wochen auseinanderliegen und niemand sich erinnert.

Damit lässt sich fragen, was vorher niemand fragen konnte: Kenne ich das schon? Und wenn nicht, sagt NODE64 das, statt den ähnlichsten Treffer als Treffer auszugeben. Weil der ähnlichste Treffer immer irgendeiner ist, fiele der Unterschied sonst nie auf.

Die Zahlenreihe enthält keine Pfade, keine Programmnamen, keine Adressen – nur dimensionslose Grössen: wie weit weg vom Gewohnten, wie neu, wie selten.

Was Timbre nicht tut #

• Keine Signaturdatenbank im Agenten. Er trägt keine Liste bekannter Schadsoftware mit sich und lädt keine nach.
• Kein neuronales Netz. Median, Streuung, Perzentil – Verfahren, die du nachrechnen kannst.
• Keine Gegenmassnahmen. Timbre löscht nichts, beendet keinen Prozess, sperrt keine Verbindung. Es erkennt und erklärt.
• Keine Dateiinhalte, keine Kommandozeilen. Beides bleibt auf deinem Server.
• Keine Gesamtnote. Es gab einmal eine Punktzahl; sie ist gestrichen, weil niemand sagen konnte, was 73 bedeutet.
• Kein Urteil ohne Grundlage. Wo die Geschichte nicht reicht, steht das da.

Was gilt, wenn die Verbindung ausfällt #

Der Agent läuft weiter und schickt später nach – aber nicht alles kann er ohne Plattform beantworten. „Funktioniert ohne Backend" wäre eine Überschrift, die diese Tabelle widerlegt, und eine Zusage, die jemand im Ernstfall glaubt, ist schlimmer als keine.

Warum die Zeile „Indikator" heisst und nicht „Befund": Ein Befund ist ein Urteil, und dafür braucht es den Vergleich mit dem, was auf diesem System gewohnt ist. Der Agent hat diesen Vergleich nicht – er stellt fest, dass etwas passiert ist.

So sieht so eine Zeile aus:

Aug 21 12:34:56 server node64-agent[1234]: NODE64 Indikator: shell-unter-webserver

Was danach passiert. Ist die Verbindung länger weg, als die Warteschlange hält, verwirft der Agent die ältesten Stände – und hinterlässt eine Marke. Beim nächsten Bericht steht sie in jedem Beleg:

44 statt sonst 40, aus 96 Messungen über 4 Tage
— mit einer Lücke von 12 Läufen, die nie ankamen

Ohne diese Marke sähe die Reihe danach aus wie eine lückenlose Messung. Sie ist es nicht, und eine Zahl, die genauer aussieht als sie ist, ist schlimmer als eine, die ihre Grenzen nennt.

Wenn es ernst wird: die Eilmeldung #

Erkennt die Prozesswache einen der vier Sofortindikatoren, wartet der Agent nicht auf den nächsten Meldetakt. Er zieht den nächsten vollständigen Lauf vor und kennzeichnet ihn als eilig; die Plattform wertet dann zuerst die Anomalien aus und verschickt den Alarm, bevor sie den teuren Abgleich gegen die Schwachstellendatenbank beginnt.

Kernel-Ereignis → Wache            unter 1 ms
Sammelfenster                      30 s
vorgezogener Lauf                  ~3 s
Upload + vorrangige Verarbeitung   ~5 s
Alarmversand                       sofort danach
                                   ─────────
statt bis zu 15 bzw. 60 Minuten:   unter einer Minute

Damit ein Angreifer darüber nicht den Takt bestimmt, ist die Eilmeldung gedeckelt: höchstens eine je fünf Minuten, höchstens sechs je Stunde. Was die Grenzen abweisen, geht nicht verloren – es kommt mit dem regulären Lauf.

Was andere Installationen sehen #

Neben jedem Bereich steht seit Phase 85 eine zweite Aussage: Wie gewöhnlich ist das, was hier gerade passiert, auf anderen Installationen?

Lokal auffällig · global zu 0,94 ähnlich zu Muster P-1827
· auf 431 unabhängigen Installationen gesehen · Trend steigend

Sie steht bewusst getrennt. Das übergreifende Wissen ersetzt die Grundlinie dieses Geräts nicht — ein Server ohne Verbindung erkennt genau so viel wie mit. Was fehlt, fehlt der Einordnung, nicht der Erkennung.

Und eine übergreifende Aussage allein erzeugt nie einen Befund. Ein Muster, das auf 431 Installationen gesehen wurde, ist gewöhnlich — eher ein Grund zur Entwarnung als zum Alarm. Ob etwas auf deinem Server ein Problem ist, entscheidet deine eigene Geschichte.

Weiss die Wissensbasis nichts, steht dort nichts. Nicht „unbekanntes Muster", nicht „0 Installationen".

Verwandte Seiten #

• Befunde verstehen – was ein Befund ist und was du damit tust
• Integrität – die Prüfsummen der Systemdateien
• Welche Daten gesammelt werden – vollständig, Merkmal für Merkmal