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. Seit SFOS 20.0 MR1 begrenzt sie die Vorkommen pro Anwendung und Endpoint; ab SFOS 21.0 gibt es zusätzlich eine konfigurierbare, altersbasierte Bereinigung. Dieser Artikel zeigt, wie man die reguläre Aufbewahrung einstellt, ein Fehlerbild sicher eingrenzt und einen nötigen 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 Fusion (ehemals 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 Sophos Fusion hilft zuerst Sophos Firewall mit Sophos Fusion verbinden.

Aufbewahrung und Bereinigung verstehen

Für Synchronized Application Control gelten zwei wichtige Produktvorgaben:

• 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 Vorkommensdaten automatisch. Sophos weist aber darauf hin, dass diese Migrationsbereinigung bei zu wenig freiem Speicher scheitern kann. In diesem Fall soll Sophos Support eingebunden werden.

Daneben kann SFOS Anwendungen löschen, deren letzte Erkennung länger als die konfigurierte Aufbewahrungszeit zurückliegt. Die Firewall prüft dies täglich und löscht jeweils 100 Anwendungen im Abstand von fünf Minuten. Einzelne Zuordnungen in Application Filters werden dabei ebenfalls entfernt.

Bei einer Migration auf SFOS 21.0 oder neuer wird Clean up application database automatisch mit der Standardfrist von 12 Monaten eingeschaltet, sofern Synchronized Application Control aktiv ist. Eine zuvor geänderte Frist bleibt erhalten. Wird Synchronized Application Control ausgeschaltet, bleibt auch die Bereinigung ausgeschaltet.

Damit sind normale Aufbewahrung und Reparatur klar getrennt: Die unterstützte Altersbereinigung wird in der Oberfläche konfiguriert. Direkte Datenbankpflege ist weiterhin keine reguläre Wartungsaufgabe.

Reguläre Bereinigung konfigurieren

Voraussetzungen sind eine Registrierung der Firewall bei Sophos Fusion und eine gültige Web Protection Subscription. Ohne diese Subscription lässt sich Synchronized Application Control zwar konfigurieren, aber nicht verwenden. Ausserdem muss die auf der Firewall angelegte Domain mit der auf dem Endpoint ausgewählten Domain übereinstimmen.

1. System > Sophos Fusion öffnen und prüfen, dass die Firewall registriert und Synchronized Application Control eingeschaltet ist.
2. Clean up application database einschalten.
3. Die Aufbewahrungszeit wählen. 12 Monate sind der Migrationsstandard und ein sinnvoller Ausgangspunkt, wenn es keine eigene Vorgabe gibt. Eine kürzere Frist reduziert Altbestand schneller, entfernt aber auch früher einzeln zugewiesene Anwendungen aus Application Filters.
4. Die Einstellung speichern und den Bestand über die nächsten täglichen Bereinigungsläufe beobachten.

Die Bereinigung ist absichtlich gestaffelt. Eine unveränderte Anzahl unmittelbar nach dem Speichern ist deshalb noch kein Fehler. Als Kontrolle vergleicht man den ältesten sichtbaren Erkennungszeitpunkt und die Anzahl alter Anwendungen vor und nach mindestens einem täglichen Lauf; neue Anwendungen müssen weiterhin erscheinen.

⚠️ Das Ausschalten der Bereinigung stoppt zukünftige Löschungen, stellt aber bereits entfernte Anwendungen oder Filterzuordnungen nicht wieder her. Eine erneut erkannte Anwendung erscheint wieder in der Liste, muss einem Application Filter jedoch bei Bedarf neu zugewiesen werden.

Typische Symptome unterscheiden

Speicherproblem nach Upgrade oder Bereinigung

Mögliche Hinweise sind eine stark belegte Partition, fehlgeschlagene Reports oder Dienste und ein zeitlicher Zusammenhang mit einem Upgrade oder einer ausbleibenden altersbasierten Bereinigung. 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.

Eine Liste nahe der Produktgrenze von 15'000 Anwendungen spricht für ein Kapazitätsproblem in Synchronized Application Control. Eine volle Partition ist dagegen ein separates Speicherproblem. Beide Symptome können gleichzeitig auftreten, belegen aber nicht gegenseitig ihre Ursache und müssen getrennt geprüft werden.

Security Heartbeat funktioniert nicht

Wenn Endpoints keinen Heartbeat-Status melden oder Regeln mit Heartbeat-Bedingungen nicht wie erwartet greifen, sollte man zuerst die Sophos-Fusion-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