Wazuh-Alerts global unterdrücken: CDB-Listen, Regelhierarchien und Ingest-Pipelines richtig einsetzen

Einleitung

In produktiven Wazuh-Umgebungen entstehen regelmäßig legitime Ereignisse, die technisch auf Erkennungsregeln passen, aber keinen Sicherheitsvorfall darstellen. Typische Beispiele sind Schwachstellenscanner, Monitoring-Systeme, interne Administrationsserver oder autorisierte Penetrationstests. Solche Quellen sollen häufig von bestimmten Alarmen ausgenommen werden.

Eine Ausnahme in einer einzelnen Wazuh-Regel bedeutet jedoch nicht automatisch, dass das Ereignis vollständig ignoriert wird. Passt dasselbe Ereignis auf weitere Regeln, können weiterhin Alerts entstehen. Der Grund liegt in der Architektur der Wazuh-Analyse-Engine: Ausnahmen wirken innerhalb der jeweiligen Regel beziehungsweise Regelkette und sind keine globale Drop-Anweisung.

Für eine saubere Lösung muss deshalb zuerst geklärt werden, welches Ziel tatsächlich erreicht werden soll:

Nur bestimmte Erkennungsregeln sollen für vertrauenswürdige Quellen nicht auslösen.
Alle relevanten Regeln sollen dieselbe zentral gepflegte Ausnahmeliste berücksichtigen.
Bereits erzeugte Alerts sollen nicht an den Wazuh Indexer übertragen und dort gespeichert werden.
Das Rohereignis soll weiterhin für Forensik und spätere Analysen erhalten bleiben.

Je nach Ziel kommen unterschiedliche Kontrollpunkte innerhalb der Wazuh-Architektur infrage.

Ausgangslage / Problemstellung

Ein Ereignis enthält beispielsweise die Quell-IP-Adresse 192.168.1.10. Für diese Adresse wurde in einer benutzerdefinierten Regel eine Ausnahme definiert. Der betreffende Alert wird dadurch nicht mehr erzeugt.

Trotzdem erscheinen weitere Alerts zum gleichen Ereignis, weil andere Regeln ebenfalls auf dessen Decoder, Felder, Gruppen oder übergeordnete Regel-IDs passen.

Das führt häufig zu der Annahme, eine Whitelist müsse automatisch für alle Regeln gelten. Tatsächlich ist die Ausnahme aber nur dort wirksam, wo sie ausdrücklich in die Erkennungslogik eingebunden wurde.

Die Umgebung besteht typischerweise aus folgenden Komponenten:

Ein Wazuh Agent oder eine agentenlose Datenquelle liefert das Ereignis.
Der Wazuh Server verarbeitet das Ereignis durch Pre-Decoding und Decoding.
wazuh-analysisd gleicht die normalisierten Felder mit dem Ruleset ab.
Ein oder mehrere passende Regeln erzeugen Alerts.
Filebeat beziehungsweise ein anderer Forwarder überträgt die Alert-Dokumente an den Wazuh Indexer.
Der Wazuh Indexer speichert die Dokumente, die anschließend im Dashboard sichtbar werden.

Wird eine Ausnahme erst in einer einzelnen Regel umgesetzt, beeinflusst sie andere unabhängige Regelpfade nicht. Wird ein Dokument dagegen in der Ingest-Pipeline verworfen, ist der Alert bereits durch den Wazuh Server erzeugt worden, wird aber nicht mehr indexiert.

Diese beiden Varianten lösen daher unterschiedliche Probleme.

Technische Analyse

Warum eine Ausnahme in einer Regel nicht global wirkt

Die Wazuh-Datenanalyse erfolgt in mehreren Stufen. Nach dem Pre-Decoding und Decoding bewertet die Analyse-Engine das Ereignis anhand des geladenen Rulesets. Regeln können unter anderem auf folgende Merkmale reagieren:

Decoder-Namen
statische Felder wie srcip, dstip, user oder protocol
dynamische Felder
Ereignisgruppen
vorherige Regel-IDs
Häufigkeiten und Zeitfenster
Inhalte des ursprünglichen Logs
Einträge in CDB-Listen

Regeln können hierarchisch über Elemente wie <if_sid>, <if_group> oder <if_matched_sid> miteinander verbunden sein. Daneben können weitere Regelzweige unabhängig auf dasselbe Ereignis passen.

Eine Ausnahme in Regel A verändert nicht automatisch die Bedingungen von Regel B. Wurde die vertrauenswürdige IP-Adresse nur in Regel A berücksichtigt, kann Regel B weiterhin einen Alert erzeugen.

Wazuh besitzt innerhalb des klassischen Rulesets keine zentrale Anweisung nach dem Muster:

Wenn srcip in globaler Ausnahmeliste enthalten ist,
beende jede weitere Analyse dieses Ereignisses.

Eine Regel mit Alert-Level 0 kann zwar einen bestimmten Regelpfad unterdrücken oder als logische Baseline innerhalb einer Hierarchie dienen. Sie ist jedoch kein universeller Abbruchmechanismus für sämtliche unabhängigen Regeln, die ebenfalls auf das Ereignis passen.

CDB-Listen als zentrale Quelle für Ausnahmen

Constant Database Lists, kurz CDB-Listen, ermöglichen die zentrale Pflege von Schlüsseln und optionalen Werten. Sie eignen sich beispielsweise für:

IP-Adressen
Benutzernamen
Domains
Dateihashes
Hostnamen
Anwendungskennungen
Asset-Klassen

Der wesentliche Vorteil besteht darin, dass die Ausnahmedaten unabhängig von den Regeln gepflegt werden können. Neue IP-Adressen müssen dann nicht in mehreren XML-Regeln direkt eingetragen werden.

Eine einfache Liste vertrauenswürdiger Quelladressen kann beispielsweise so aussehen:

192.168.1.10:
192.168.1.20:
192.168.1.30:

Die Datei könnte auf dem Wazuh Server unter folgendem Pfad gespeichert werden:

/var/ossec/etc/lists/allowed-source-ips

Anschließend muss die Liste im <ruleset>-Abschnitt der Datei /var/ossec/etc/ossec.conf registriert werden:

<ruleset>
  <list>etc/lists/allowed-source-ips</list>
</ruleset>

CDB-Listen werden beim Start der Wazuh-Analyse-Engine aufgebaut und geladen. Nach dem Erstellen oder Ändern einer Liste ist daher ein Neustart des Wazuh Managers erforderlich.

sudo systemctl restart wazuh-manager

Wichtig ist: Eine CDB-Liste wird nicht allein durch ihre Registrierung zu einer globalen Whitelist. Jede Regel beziehungsweise jeder relevante Regelzweig muss die Liste ausdrücklich abfragen.

Positiv- und Negativlogik bei CDB-Abfragen

Eine Regel kann prüfen, ob ein Feld in einer Liste vorhanden ist:

<list field="srcip" lookup="match_key">
  etc/lists/allowed-source-ips
</list>

Diese Bedingung trifft zu, wenn srcip als Schlüssel in der CDB-Liste vorhanden ist.

Für Whitelisting-Szenarien ist häufig die umgekehrte Logik geeigneter:

<list field="srcip" lookup="not_match_key">
  etc/lists/allowed-source-ips
</list>

Die Regel erzeugt dann nur einen Treffer, wenn die Quell-IP-Adresse nicht in der Liste enthalten ist.

Ein vereinfachtes Beispiel für eine benutzerdefinierte Regel:

<group name="custom_network_detection,">
  <rule id="100500" level="10">
    <if_sid>5710</if_sid>

    <list field="srcip" lookup="not_match_key">
      etc/lists/allowed-source-ips
    </list>

    <description>
      SSH-Anmeldefehler von einer nicht freigegebenen Quelladresse
    </description>
  </rule>
</group>

Die konkrete Parent-ID muss zur eingesetzten Wazuh-Version und zur tatsächlich passenden Regel passen. Eigene Regel-IDs sollten im für benutzerdefinierte Regeln vorgesehenen Bereich liegen und nicht mit bestehenden IDs kollidieren.

Stolperstein: Unterschiedliche Feldnamen für Quell-IP-Adressen

Nicht jede Integration legt eine Quelladresse im statischen Feld srcip ab. Abhängig von Decoder, Datenquelle und Format können beispielsweise folgende Felder auftreten:

srcip
data.srcip
data.src_ip
data.sourceIp
data.client_ip
data.office365.ClientIP
source.ip

Eine Regel oder Pipeline, die ausschließlich srcip prüft, erfasst nur Dokumente, bei denen das Feld tatsächlich unter diesem Namen vorliegt.

Vor der Umsetzung einer Ausnahme sollte deshalb ein repräsentativer Alert als JSON geprüft werden. Entscheidend ist nicht der im Dashboard angezeigte Spaltenname, sondern der tatsächliche Feldpfad im Alert-Dokument.

Zusätzlich sollte mit wazuh-logtest kontrolliert werden, welcher Decoder und welche Regeln das ursprüngliche Ereignis verarbeiten:

sudo /var/ossec/bin/wazuh-logtest

Nach dem Einfügen eines Beispielereignisses zeigt das Werkzeug unter anderem:

das Ergebnis des Pre-Decodings
den gewählten Decoder
die extrahierten Felder
die letztlich ausgelöste Regel

Bei komplexen Regelketten sollte der Test für mehrere repräsentative Ereignisvarianten durchgeführt werden.

Globale Unterdrückung durch eine Ingest-Pipeline

Soll ein erzeugter Alert unabhängig von seiner Regel-ID nicht im Wazuh Indexer gespeichert werden, kann eine Drop-Bedingung in der Ingest-Pipeline eingesetzt werden.

Ein entsprechender Prozessor kann konzeptionell so aussehen:

{
  "drop": {
    "description": "Alerts von ausgeschlossenen Quelladressen verwerfen",
    "if": "ctx.srcip != null && (ctx.srcip == '1.2.3.4' || ctx.srcip == '4.3.2.1')"
  }
}

Der Prozessor verwirft jedes durch die Pipeline laufende Dokument, dessen Feld srcip einer der definierten Adressen entspricht.

Dabei ist die Position dieses Filters innerhalb der Architektur entscheidend:

Logquelle
   |
   v
Wazuh Server
Pre-Decoding -> Decoding -> Regelanalyse -> Alert-Erzeugung
                                         |
                                         v
                               alerts.json / alerts.log
                                         |
                                         v
                              Filebeat / Forwarder
                                         |
                                         v
                                  Ingest-Pipeline
                                    Drop-Filter
                                         |
                     +-------------------+-------------------+
                     |                                       |
                  verworfen                              indexiert

Die Ingest-Pipeline verhindert die Indexierung. Sie verhindert nicht rückwirkend die Regelanalyse auf dem Wazuh Server.

Abhängig von der Konfiguration kann der Alert daher weiterhin:

in /var/ossec/logs/alerts/alerts.json vorhanden sein,
in /var/ossec/logs/alerts/alerts.log erscheinen,
Alert-basierte Integrationen beeinflussen,
E-Mail-Benachrichtigungen auslösen,
eine Active Response anstoßen,
in andere konfigurierte Outputs geschrieben werden.

Ein Indexer-Drop ist somit eine globale Filterung für den Indexierungspfad, aber keine globale Unterdrückung innerhalb der Wazuh-Analyse-Engine.

Feldnormalisierung vor dem Drop

Für eine robuste Drop-Logik sollten unterschiedliche Quell-IP-Felder zunächst auf ein gemeinsames Feld normalisiert werden, beispielsweise source.ip.

Ein konzeptionelles Beispiel:

{
  "set": {
    "field": "source.ip",
    "copy_from": "srcip",
    "if": "ctx.srcip != null"
  }
}

Für alternative Feldpfade werden weitere Prozessoren benötigt. Bei verschachtelten Feldern muss die Pipeline-Syntax des eingesetzten Indexers berücksichtigt werden.

Danach kann der Drop-Prozessor nur noch das normalisierte Feld prüfen:

{
  "drop": {
    "description": "Alerts von ausgeschlossenen Quelladressen verwerfen",
    "if": "ctx.source?.ip != null && (ctx.source.ip == '1.2.3.4' || ctx.source.ip == '4.3.2.1')"
  }
}

Vor der produktiven Nutzung muss getestet werden, ob die jeweilige Wazuh- und Indexer-Version die verwendete Skriptsyntax, Null-Prüfung und den jeweiligen Prozessor unterstützt.

Die Pipeline-Dateien des Wazuh-Filebeat-Moduls werden außerdem durch Paketupdates ersetzt oder verändert. Lokale Anpassungen müssen deshalb dokumentiert, versioniert und nach Upgrades erneut geprüft beziehungsweise automatisiert ausgerollt werden. Die von Wazuh verwendeten Pipeline-Dateien befinden sich im Filebeat-Modul unter anderem im Bereich alerts/ingest/pipeline.json.

Lösung / Best Practices

Variante 1: Nur bestimmte Detektionen unterdrücken

Diese Variante ist zu bevorzugen, wenn eine Quelle nur für einen klar definierten Anwendungsfall vertrauenswürdig ist.

Beispiel: Ein interner Schwachstellenscanner darf viele fehlgeschlagene Anmeldeversuche erzeugen, soll aber weiterhin Alerts auslösen, falls von seinem System verdächtige Dateiänderungen oder Privilegieneskalationen erkannt werden.

Vorgehen:

Relevante Alerts und Regel-IDs identifizieren.
Die tatsächlich verwendeten IP-Felder prüfen.
Eine zentrale CDB-Liste anlegen.
Die betroffenen benutzerdefinierten Regeln mit not_match_key ergänzen.
Abhängigkeiten zu Parent- und Child-Regeln prüfen.
Konfiguration und Verhalten mit wazuh-logtest testen.
Den Wazuh Manager kontrolliert neu starten.
Erwartete und unerwartete Testereignisse vergleichen.

Beispiel für die CDB-Liste:

10.20.30.40:
10.20.30.41:

Registrierung:

<ruleset>
  <list>etc/lists/allowed-source-ips</list>
</ruleset>

Regelbedingung:

<list field="srcip" lookup="not_match_key">
  etc/lists/allowed-source-ips
</list>

Diese Lösung erhält die Erkennungsfähigkeit für andere Angriffsmuster und reduziert nur die konkret definierten False Positives.

Variante 2: Gemeinsame Ausnahmelogik in mehreren Regeln

Müssen mehrere eigene Regeln dieselbe Ausnahme berücksichtigen, sollte die CDB-Liste als gemeinsame Datenquelle verwendet werden.

Die Liste ist damit zentral, ihre Anwendung bleibt aber regelbezogen:

<group name="custom_application_rules,">

  <rule id="100510" level="8">
    <if_sid>100100</if_sid>
    <list field="srcip" lookup="not_match_key">
      etc/lists/allowed-source-ips
    </list>
    <description>
      Anwendungserkennung A von nicht freigegebener Quelle
    </description>
  </rule>

  <rule id="100511" level="10">
    <if_sid>100101</if_sid>
    <list field="srcip" lookup="not_match_key">
      etc/lists/allowed-source-ips
    </list>
    <description>
      Anwendungserkennung B von nicht freigegebener Quelle
    </description>
  </rule>

</group>

Der Vorteil liegt in der zentralen Pflege der IP-Adressen. Der Nachteil besteht darin, dass jede relevante Regel die Bedingung enthalten muss.

Bei umfangreichen eigenen Rulesets sollte die Ausnahme bereits möglichst weit oben in der selbst kontrollierten Regelhierarchie berücksichtigt werden. Dadurch lässt sich vermeiden, dieselbe Bedingung in vielen Child-Regeln zu wiederholen. Unabhängige Regelzweige müssen dennoch separat betrachtet werden.

Variante 3: Alerts vor der Indexierung global verwerfen

Diese Variante ist geeignet, wenn Alerts mit einer bestimmten Eigenschaft grundsätzlich nicht im Indexer erscheinen sollen.

Vorgehen:

Repräsentative Alert-Dokumente exportieren.
Sämtliche relevanten Feldnamen identifizieren.
Falls erforderlich, Quellfelder auf ein gemeinsames Feld normalisieren.
Einen Drop-Prozessor an das Ende der Normalisierung setzen.
Die Pipeline mit Testdokumenten simulieren.
Nebenwirkungen auf Dashboards, Reports, Retention und Untersuchungen bewerten.
Die geänderte Pipeline kontrolliert in den Indexer laden.
Upgrade- und Rollback-Verfahren dokumentieren.

Ein einfacher Drop-Prozessor:

{
  "drop": {
    "description": "Alerts von global ausgeschlossenen IP-Adressen nicht indexieren",
    "if": "ctx.source?.ip != null && ['1.2.3.4', '4.3.2.1'].contains(ctx.source.ip)"
  }
}

Diese Konfiguration ist übersichtlicher als eine lange Kette von ||-Vergleichen. Vor dem Einsatz muss jedoch geprüft werden, ob die konkrete Painless-Version und der verwendete Ingest-Kontext diese Schreibweise unterstützen.

Für umfangreiche oder häufig wechselnde IP-Listen ist eine hart codierte Pipeline-Bedingung nur eingeschränkt geeignet. Änderungen an der Liste erfordern dann eine Anpassung und erneute Bereitstellung der Pipeline.

Variante 4: Nicht mehr benötigte eigene Regeln anpassen oder entfernen

Handelt es sich um eine benutzerdefinierte Regel, die fachlich nicht mehr benötigt wird, sollte sie nicht lediglich durch immer mehr Ausnahmen neutralisiert werden.

Vor dem Entfernen sind jedoch Abhängigkeiten zu prüfen:

<if_sid>100500</if_sid>

<if_matched_sid>100500</if_matched_sid>

Auch Gruppenbezüge können betroffen sein:

<if_group>custom_detection</if_group>

Eine Suche nach der Regel-ID sollte sowohl in den eigenen Regeldateien als auch über die Regelverwaltung im Wazuh Dashboard erfolgen. Erst wenn keine benötigten Child-Regeln, Korrelationen oder Active-Response-Abläufe davon abhängen, sollte die Regel deaktiviert oder entfernt werden.

Standardregeln sollten nicht direkt in den mitgelieferten Ruleset-Dateien geändert werden. Solche Änderungen können bei Updates überschrieben werden und erschweren spätere Fehleranalysen. Anpassungen gehören in eigene Regeldateien, typischerweise unter:

/var/ossec/etc/rules/

Entscheidungsmatrix

Anforderung	Empfohlener Ansatz
Einzelne Detektion für bekannte IP ausnehmen	CDB-Liste in der betroffenen Regel
Mehrere eigene Regeln verwenden dieselben Ausnahmen	Gemeinsame CDB-Liste in allen relevanten Regelzweigen
Alert soll nicht im Wazuh Indexer gespeichert werden	Drop-Prozessor in der Ingest-Pipeline
Alert darf keine Active Response oder Integration auslösen	Unterdrückung auf Ebene der Wazuh-Regeln
Rohdaten sollen erhalten bleiben, Alert aber nicht indexiert werden	Indexer-Drop bei weiterhin aktivem Archivierungs- beziehungsweise Rohdatenpfad
Eigene Regel ist fachlich überholt	Abhängigkeiten prüfen und Regel entfernen oder überarbeiten
Alle Ereignisse einer IP sollen vollständig ignoriert werden	Kritisch prüfen; möglichst quellspezifische Filterung vor der Analyse oder gezielte Regelunterdrückung statt pauschaler IP-Freigabe

Lessons Learned / Best Practices

„Global“ muss architektonisch definiert werden

In Wazuh kann globale Unterdrückung unterschiedliche Bedeutungen haben:

keine Regel soll einen Alert erzeugen,
kein Alert soll indexiert werden,
keine Benachrichtigung soll versendet werden,
keine Active Response soll starten,
das Rohereignis soll vollständig verworfen werden.

Diese Ziele liegen an unterschiedlichen Stellen der Verarbeitungskette. Eine Maßnahme am Indexer löst kein Problem auf dem Manager, und eine Regelanpassung entfernt nicht zwangsläufig das ursprüngliche Ereignis aus allen Logpfaden.

CDB-Listen sind zentrale Datenquellen, keine globalen Schalter

CDB-Listen vereinfachen die Pflege von Ausnahmen erheblich. Ihre Existenz beeinflusst jedoch keine Regel automatisch. Die jeweilige Regel muss die Liste explizit abfragen.

Nach jeder Änderung ist außerdem ein Neustart des Wazuh Managers erforderlich, damit die CDB-Liste neu aufgebaut und geladen wird.

Ausnahmen sollten möglichst eng formuliert sein

Eine IP-Adresse pauschal aus allen Security Alerts auszuschließen, kann relevante Angriffe verdecken. Auch vertrauenswürdige Systeme können kompromittiert oder missbraucht werden.

Eine sicherere Ausnahme kombiniert mehrere Bedingungen, beispielsweise:

Quell-IP-Adresse
Zielsystem
Port oder Protokoll
Decoder
Anwendung
konkrete Regelgruppe
Wartungszeitfenster
Agent-ID oder Asset-Gruppe

Statt „alle Alerts von Scanner-IP unterdrücken“ ist eine Bedingung wie „erwartete Login-Fehler des autorisierten Scanners gegen die freigegebene Zielgruppe unterdrücken“ deutlich risikoärmer.

Feldnamen müssen standardisiert oder vollständig berücksichtigt werden

Heterogene Datenquellen verwenden unterschiedliche Feldnamen. Dies betrifft besonders Cloud-Dienste, Netzwerkgeräte und benutzerdefinierte JSON-Logs.

Eine zentrale Feldnormalisierung erleichtert:

CDB-Abfragen
Ingest-Filter
Dashboards
Korrelationen
Threat Hunting
externe Integrationen

Sie sollte jedoch kontrolliert erfolgen, damit keine vorhandenen Felder überschrieben oder semantisch unterschiedliche Adressen zusammengeführt werden.

Regel- und Pipeline-Anpassungen gehören unter Versionskontrolle

Mindestens folgende Dateien und Objekte sollten versioniert werden:

benutzerdefinierte Regeln
benutzerdefinierte Decoder
CDB-Listen
Ingest-Pipelines
Deployment-Skripte
Testereignisse
erwartete wazuh-logtest-Ergebnisse
Rollback-Anweisungen

Damit lassen sich Änderungen nachvollziehen, in Testumgebungen validieren und nach Upgrades reproduzierbar wiederherstellen.

Drop-Filter reduzieren Sichtbarkeit und Datenbasis

Ein verworfener Alert steht im Indexer nicht mehr für folgende Aufgaben zur Verfügung:

Threat Hunting
historische Untersuchungen
Dashboards
Reporting
Compliance-Auswertungen
Korrelation mit späteren Ereignissen
Trend- und Volumenanalysen

Deshalb sollte vor einem Drop geprüft werden, ob eine Herabstufung, Kennzeichnung oder gezielte Regelanpassung ausreicht.

Eine mögliche Alternative besteht darin, vertrauenswürdige Ereignisse nicht zu verwerfen, sondern mit einem zusätzlichen Feld zu markieren und in Dashboards standardmäßig auszublenden. So bleibt die forensische Datenbasis erhalten.

Tests müssen alle nachgelagerten Funktionen einbeziehen

Ein erfolgreicher Test besteht nicht nur darin, dass der Alert nicht mehr im Dashboard erscheint. Zusätzlich muss geprüft werden:

Wird der Alert weiterhin lokal erzeugt?
Wird eine E-Mail versendet?
Startet eine Active Response?
Erhält eine externe Integration das Ereignis?
Bleibt das Rohereignis im Archiv erhalten?
Verhalten sich Cluster-Knoten identisch?
Bleibt die Änderung nach einem Neustart bestehen?
Wird die Anpassung bei einem Upgrade überschrieben?

Nur ein End-to-End-Test bestätigt, dass die Unterdrückung am richtigen Kontrollpunkt umgesetzt wurde.

Fazit

Wazuh bietet im klassischen Ruleset keinen universellen Whitelist-Schalter, der ein Ereignis sofort aus sämtlichen unabhängigen Regelpfaden entfernt. Eine Ausnahme wirkt grundsätzlich dort, wo sie in die Regelhierarchie eingebaut wurde.

Für die meisten Anwendungsfälle ist eine CDB-Liste in Verbindung mit gezielten not_match_key-Bedingungen die sicherste Lösung. Sie trennt die Pflege der Ausnahmedaten von der Erkennungslogik und erhält Alerts für andere sicherheitsrelevante Verhaltensweisen.

Soll ein bereits erzeugter Alert unabhängig von seiner Regel-ID nicht im Wazuh Indexer gespeichert werden, kann ein Drop-Prozessor in der Ingest-Pipeline eingesetzt werden. Diese Maßnahme unterdrückt jedoch nur die Indexierung. Manager-seitige Alerts, Active Responses, Benachrichtigungen und andere Outputs müssen separat betrachtet werden.

Die zentrale Best Practice lautet daher: Ausnahmen so früh wie nötig, so eng wie möglich und am richtigen Punkt der Wazuh-Verarbeitungskette umsetzen.