Synchronized Application Control: Datenbankproblem sicher prüfen

Wenn Synchronized Application Control keine neuen Anwendungen mehr erfasst, heartbeatd.log Fehler meldet oder eine Firewall nach einem Upgrade unter sehr knappem Speicher leidet, kann die interne Anwendungsdatenbank betroffen sein. Das ist jedoch kein Fall für allgemeine PostgreSQL-Befehle aus einem Forum oder einer alten Supportnotiz.

Sophos Firewall verwaltet diese Daten intern und hat das Aufbewahrungsverhalten seit SFOS 20.0 MR1 geändert. Scheitert die automatische Bereinigung wegen zu wenig Speicherplatz, verweist die aktuelle Sophos-Dokumentation ausdrücklich an den Support. Dieser Artikel zeigt deshalb, wie man das Fehlerbild sicher eingrenzt, die richtigen Daten sammelt und einen Supporteingriff kontrolliert begleitet.

Das Problem richtig einordnen

Synchronized Application Control nutzt Informationen von Endpoints, die über Security Heartbeat mit der Firewall verbunden sind. Die Firewall erkennt damit Anwendungen, die klassische Signaturen nicht eindeutig zuordnen können, und stellt sie unter Applications > Synchronized Application Control zur Verwaltung bereit.

Die Begriffe sollten nicht vermischt werden:

• Security Heartbeat übermittelt Gesundheits- und Sicherheitsstatus zwischen Endpoint, Firewall und Sophos Central.
• Synchronized Application Control erfasst Anwendungen und ihre Fundstellen auf verbundenen Endpoints.
• Missing heartbeat beschreibt einen fehlenden Endpoint-Status und lässt sich über unterstützte Device-Console-Befehle verwalten.
• Ein App-ID- oder Datenbankproblem betrifft die interne Speicherung der erkannten Anwendungen und benötigt eine eigene Diagnose.

Eine fehlende Heartbeat-Anzeige, ein roter Endpoint oder eine nicht passende Firewall-Regel ist deshalb nicht automatisch ein Datenbankfehler. Für die Verbindung zwischen Firewall und Central hilft zuerst Sophos Firewall mit Sophos Central verbinden.

Was SFOS automatisch bereinigt

Die aktuelle Sophos-Dokumentation zu Synchronized Application Control nennt zwei wichtige Grenzen:

• Synchronized Application Control unterstützt bis zu 15'000 Anwendungen.
• Seit SFOS 20.0 MR1 speichert die Firewall nur noch die letzten fünf Vorkommen jeder Anwendung pro Endpoint.

Bei einer Migration auf SFOS 20.0 MR1 oder neuer behält die Firewall die fünf aktuellsten Vorkommen und entfernt ältere Anwendungsdaten automatisch. Sophos weist aber darauf hin, dass diese Bereinigung bei zu wenig freiem Speicher scheitern kann. In diesem Fall soll Sophos Support eingebunden werden.

Das bedeutet für den Betrieb: Eine aktuelle Firewall benötigt normalerweise keine manuelle Datenbankpflege für diese Daten. Wiederkehrendes Wachstum, fehlgeschlagene Migration oder ein erschöpfter App-ID-Bereich sind Fehlerbilder, keine reguläre Wartungsaufgabe.

Typische Symptome unterscheiden

Speicherproblem nach Upgrade

Mögliche Hinweise sind eine stark belegte Partition, fehlgeschlagene Reports oder Dienste und ein zeitlicher Zusammenhang mit einem Upgrade auf SFOS 20.0 MR1 oder neuer. Das allein beweist noch nicht, dass Synchronized Application Control die Ursache ist.

Zuerst sollten Reports, Debug-Logs, Supportarchive, Mailqueue, Quarantäne und die Grösse einer virtuellen Disk geprüft werden. Der Ablauf steht in Sophos Firewall Speicherplatz prüfen und Reports verwalten.

App-ID-Bereich erschöpft

Ein anderes Fehlerbild ist eine Meldung wie:

Cannot create ID for application, because appId range is exhausted.
Application will be ignored.

Die Firewall kann dabei vorhandene Anwendungen weiterhin anzeigen, neue Anwendungen aber nicht mehr sauber erfassen. Diese Meldung weist auf Synchronized Application Control hin, nicht auf eine allgemeine Report- oder Logdatenbank.

Security Heartbeat funktioniert nicht

Wenn Endpoints keinen Heartbeat-Status melden oder Regeln mit Heartbeat-Bedingungen nicht wie erwartet greifen, sollte man zuerst Central-Registrierung, Endpoint-Kommunikation, betroffene Zonen und die Firewall-Regel prüfen. Eine direkte Datenbankbereinigung ist dafür nicht der richtige Ansatz.

Diagnose vor dem Supportfall

1. Firmware und Kontext dokumentieren

Folgende Angaben gehören in die Fallnotizen:

• Firewallmodell, Seriennummer und vollständige SFOS-Version inklusive Build
• Standalone, HA Primary oder HA Auxiliary
• Datum des letzten Upgrades und vorherige SFOS-Version
• Zeitpunkt, seit dem das Problem sichtbar ist
• Betroffene Dienste und konkrete Auswirkung

Bei HA muss eindeutig sein, auf welchem Node das Symptom auftritt. Lokale Logs und Speicherbelegung können sich zwischen Primary und Auxiliary unterscheiden.

2. Anwendungsansicht prüfen

Unter Applications > Synchronized Application Control prüft man:

• Werden neue Anwendungen noch erfasst?
• Ist die Liste nahe an der Grenze von 15'000 Anwendungen?
• Tritt das Problem nur bei neuen Anwendungen oder auch bei vorhandenen Einträgen auf?
• Lassen sich Anwendungen suchen, öffnen und verwalten?
• Werden gelöschte Anwendungen nach erneuter Erkennung erwartungsgemäss wieder angelegt?

Das Löschen einzelner Anwendungen in der Oberfläche ist eine unterstützte Funktion, entfernt sie aber auch aus Application Filters. Erkennt die Firewall die Anwendung erneut, erscheint sie wieder. Diese UI-Funktion ist daher keine Datenbankreparatur.

3. Speicherlage getrennt prüfen

Die Speicherbelegung sollte vor weiteren Massnahmen dokumentiert werden. Dabei ist wichtig, die betroffene Partition und den zeitlichen Verlauf festzuhalten, nicht nur einen einzelnen Prozentwert.

Wenn parallel Reports, Logs oder Supportarchive gelöscht werden, lässt sich später nicht mehr zuordnen, welche Massnahme tatsächlich geholfen hat. Deshalb zuerst Beweise sichern und anschliessend nur eine Änderung nach der anderen durchführen.

4. Logs und Troubleshooting-Bericht sichern

Für Synchronized Application Control und Security Heartbeat ist insbesondere heartbeatd.log relevant. Zusätzlich sollten der genaue Fehlerzeitpunkt und ein Troubleshooting-Bericht gesichert werden.

Die passenden Dateien und Erfassungswege stehen in Sophos Firewall Troubleshooting: Services und Logs und Sophos Firewall Logs für externe Analyse sichern.

Keine öffentlichen Datenbankbefehle übernehmen

Im Internet kursieren verschiedene psql-, DELETE-, VACUUM FULL- und Service-Restart-Befehle für ältere SFOS-Versionen und unterschiedliche Heartbeat-Fehlerbilder. Diese Abläufe sind nicht austauschbar:

• Ein VACUUM FULL gibt Speicher einer Tabelle frei, löscht aber nicht automatisch die Ursache ihres Wachstums.
• Ein DELETE kann Zuordnungen von Anwendungen, Endpoints oder live authentifizierten Benutzern verändern.
• Tabellen und Supportabläufe können sich zwischen SFOS-Versionen unterscheiden.
• In HA hängt der Ablauf zusätzlich von Node, Synchronisationsstatus und Supportanweisung ab.

⚠️ Ohne aktuelle, fallbezogene Anweisung von Sophos Support sollten keine direkten Änderungen an der internen PostgreSQL-Datenbank ausgeführt werden. Eine Konfigurationssicherung ist wichtig, stellt aber keinen vollständigen Rollback der internen Datenbank bereit.

Auch Befehle aus einem früheren Ticket sollten nicht ungeprüft auf eine andere Firewall, Firmware oder HA-Rolle übertragen werden. Die exakte Anweisung gehört in den aktuellen Supportfall und muss den betroffenen Node sowie die erwartete Wirkung nennen.

Supportfall vollständig vorbereiten

Ein gut vorbereiteter Fall beschleunigt die Analyse und verhindert Rückfragen. Beigefügt werden sollten:

• vollständige SFOS-Version und Firewallmodell
• Seriennummer und HA-Rolle des betroffenen Nodes
• Zeitpunkt und Wortlaut der Fehlermeldung
• Screenshot von Applications > Synchronized Application Control
• Speicherbelegung vor eigenen Bereinigungen
• heartbeatd.log und Troubleshooting-Bericht für den passenden Zeitraum
• Datum und Pfad des letzten Firmware-Upgrades
• Beschreibung, ob neue Anwendungen fehlen, der Speicher knapp ist oder beides auftritt

Vor einem Supporteingriff sollte eine aktuelle Konfigurationssicherung der Firewall vorhanden sein. Wie man den Fall eröffnet, beschreibt Sophos Supportticket eröffnen.

Wenn Support einen Datenbankeingriff anordnet, sollten Ticketnummer, freigegebene Befehle, Zielnode, Wartungsfenster, erwartete Ausgabe und Abbruchkriterien im Change festgehalten werden. Abweichende Fehlermeldungen werden dokumentiert und zurückgemeldet, statt mit ähnlichen Befehlen weiterzuexperimentieren.

Nach der Supportmassnahme prüfen

Nach der freigegebenen Massnahme sind nicht nur freier Speicher oder eine erfolgreiche Befehlsausgabe relevant. Man prüft den gesamten Funktionspfad:

1. Applications > Synchronized Application Control öffnen und vorhandene Einträge kontrollieren.
2. Mit einem Testendpoint eine neue, bisher nicht erfasste Anwendung starten.
3. Prüfen, ob die Anwendung neu erscheint und verwaltet werden kann.
4. Security-Heartbeat-Status des Testendpoints kontrollieren.
5. Firewall-Regeln mit Heartbeat- oder Application-Control-Bedingungen testen.
6. heartbeatd.log auf neue Fehler im Testzeitraum prüfen.
7. Speicherbelegung über mehrere Stunden oder Tage beobachten.

Wenn der Fehler oder das Wachstum schnell zurückkehrt, war die Bereinigung nur eine kurzfristige Entlastung. Dann benötigt Sophos Support den neuen Zeitverlauf, aktuelle Logs und die Information, nach welcher Aktion das Problem wieder auftrat.

FAQ