1
Angriffe auf Atlassian-Produkte CVE-2022-26134
Hallo Zusammen,
letztes Jahr gab es mal eine 0-Day-Angriff auf Atlassian-Produkte (Confluence)
Die jeweiligen Patches haben wir damals natürlich installiert.
Trotzdem kann es mal wichtig sein die Systeme auch jetzt unter Überwachung zu halten.
Was sind so eure "best practices" z. B. bei Confluence?
- ich prüfe immer wieder die bestehenden Netzwerkverbindungen auf dem Confluence-Systeme (habe inzw. eine Liste von IP-Adressen)
- ich kontrolliere die FW-Logs auf dieselbe IP hin (Fortigate)
- Ich schaue immer wieder, ob "fremde" Plugins installiert worden sind.
So richtig "vollständig" fühlt sich meine Vorgehensweise nicht an bzw. kostet viel Zeit.
Was macht ihr, wenn ihr kontrollieren möchtet, ob ein scheinbar sauberes und gepatchtes Systeme - durch eine alte Sicherheitslücke - eventuell doch ausgenützt wird?
Wir haben zwar entsprechende IPS Signatures im Fortigate, wir wissen aber nicht, wie zuverlässig dies uns warnen bzw., den Traffic blocken würde.
Ich habe aktuell nur die Idee die bereits bekanntgewordene IP-Adressen der Angreifer im FW pauschal zu sperren.
Habt ihr eine bessere Idee?
JoFla
letztes Jahr gab es mal eine 0-Day-Angriff auf Atlassian-Produkte (Confluence)
Die jeweiligen Patches haben wir damals natürlich installiert.
Trotzdem kann es mal wichtig sein die Systeme auch jetzt unter Überwachung zu halten.
Was sind so eure "best practices" z. B. bei Confluence?
- ich prüfe immer wieder die bestehenden Netzwerkverbindungen auf dem Confluence-Systeme (habe inzw. eine Liste von IP-Adressen)
- ich kontrolliere die FW-Logs auf dieselbe IP hin (Fortigate)
- Ich schaue immer wieder, ob "fremde" Plugins installiert worden sind.
So richtig "vollständig" fühlt sich meine Vorgehensweise nicht an bzw. kostet viel Zeit.
Was macht ihr, wenn ihr kontrollieren möchtet, ob ein scheinbar sauberes und gepatchtes Systeme - durch eine alte Sicherheitslücke - eventuell doch ausgenützt wird?
Wir haben zwar entsprechende IPS Signatures im Fortigate, wir wissen aber nicht, wie zuverlässig dies uns warnen bzw., den Traffic blocken würde.
Ich habe aktuell nur die Idee die bereits bekanntgewordene IP-Adressen der Angreifer im FW pauschal zu sperren.
Habt ihr eine bessere Idee?
JoFla
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 7078675816
Url: https://administrator.de/contentid/7078675816
Ausgedruckt am: 18.12.2024 um 06:12 Uhr
1 Kommentar
Moin,
Organisatorische Sicht:
Gruß,
Dani
Trotzdem kann es mal wichtig sein die Systeme auch jetzt unter Überwachung zu halten.
das sollte immer und für jede Anwendung gelten, unabhängig davon ob aus dem Internet (nicht) erreichbar. Der vermeidliche Angreifer kommt auch gerne aus dem LAN.- ich prüfe immer wieder die bestehenden Netzwerkverbindungen auf dem Confluence-Systeme (habe inzw. eine Liste von IP-Adressen)
- ich kontrolliere die FW-Logs auf dieselbe IP hin (Fortigate)
Nett.... welchen Blumentopf möchtest du damit gewinnen?- ich kontrolliere die FW-Logs auf dieselbe IP hin (Fortigate)
Ich schaue immer wieder, ob "fremde" Plugins installiert worden sind.
Oha, darf sich jeder im App Store austoben?Was sind so eure "best practices" z. B. bei Confluence?
Technische Sicht:- Firewall und WAF
- dedizierten VLAN für die Server
- Outbound Firewalling
- Datenverkehr wird mit Nessus überwacht
- MFA für alle Nutzer und Admins.
Organisatorische Sicht:
- Keine AD Anbindung sondern ausschließlich über AD FS.
- Dedizierte Konten für Admins. Login nur vom Jump Host möglich.
- Apps können ausschließlich manuell installiert, keine Anbindung des Online App Stores.
- Von den Application Files gibt es Hash Tables. Ändert sich eine größere Anzahl von Dateien innerhalb eines bestimmten Zeitraums, wird das Application Team alarmiert.
Was macht ihr, wenn ihr kontrollieren möchtet, ob ein scheinbar sauberes und gepatchtes Systeme - durch eine alte Sicherheitslücke - eventuell doch ausgenützt wird?
Dafür gibt es bei uns SOC Teams. Gruß,
Dani
