Und ihr?

Agenda

• Die sterbende Firewall
• Das interessante Backup
• Der “Cybersecurity Incident”
• Lessons Learned

Nicht Thema dieses Vortrags

Netzwerk Sniffen

<M> fw:/tmp # tcpdump -nn -i any -G 15 -W 1 -w debugging.pcap "port not ssh"
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
Maximum file limit reached: 1
<M> fw:/tmp # ls -lah debugging.pcap
-rw-r--r-- 1 root root 321M Mar 13 17:13 debugging.pcap

Viele Retransmits.
“Da hat’s was”.

Bisherige Erkenntnisse

• scheint kein Hardware-Problem zu sein
• IPS, Remote Logging,… scheinen nicht das Problem zu sein
• Reboot/Failover der Firewall behebt das Problem nur kurzfristig
• Problem tritt ab ~8 Uhr in der Früh auf

OpenVPN

Seit 12.03.2024 ist was “anders”:

<M> fw:/var/log # zgrep -c 'Connection terminated' openvpn/2024/03/*
[…]
openvpn/2024/03/openvpn-2024-03-11.log.gz:214
openvpn/2024/03/openvpn-2024-03-12.log.gz:2022
openvpn/2024/03/openvpn-2024-03-13.log.gz:3135
openvpn/2024/03/openvpn-2024-03-14.log.gz:1467
openvpn/2024/03/openvpn-2024-03-15.log.gz:259
openvpn/2024/03/openvpn-2024-03-16.log.gz:42
openvpn/2024/03/openvpn-2024-03-17.log.gz:15
openvpn/2024/03/openvpn-2024-03-18.log.gz:4688

Was macht johndoe?!

<M> fw:/var/log # zgrep -c johndoe openvpn/2024/03/*.log.gz
[…]
openvpn/2024/03/openvpn-2024-03-10.log.gz:0
openvpn/2024/03/openvpn-2024-03-11.log.gz:120
openvpn/2024/03/openvpn-2024-03-12.log.gz:0
openvpn/2024/03/openvpn-2024-03-13.log.gz:0
openvpn/2024/03/openvpn-2024-03-14.log.gz:0
openvpn/2024/03/openvpn-2024-03-15.log.gz:0
openvpn/2024/03/openvpn-2024-03-16.log.gz:0
openvpn/2024/03/openvpn-2024-03-17.log.gz:0
openvpn/2024/03/openvpn-2024-03-18.log.gz:64638

Weitere Accounts identifiziert + deaktiviert. Gemeinsamer Nenner?

Tunnelblick?

Wir erinnern uns

<M> fw:/var/log # zgrep -c 'Connection terminated' openvpn/2024/03/*
[…]
openvpn/2024/03/openvpn-2024-03-11.log.gz:214
openvpn/2024/03/openvpn-2024-03-12.log.gz:2022
openvpn/2024/03/openvpn-2024-03-13.log.gz:3135
openvpn/2024/03/openvpn-2024-03-14.log.gz:1467
openvpn/2024/03/openvpn-2024-03-15.log.gz:259
openvpn/2024/03/openvpn-2024-03-16.log.gz:42
openvpn/2024/03/openvpn-2024-03-17.log.gz:15
openvpn/2024/03/openvpn-2024-03-18.log.gz:4688

Erwünschtes OpenVPN-Verhalten

Exponential backoff:

-connect-retry args
Wait n seconds between connection attempts (default 1).
Repeated reconnection attempts are slowed down after 5 retries
per remote by doubling the wait time after each unsuccessful attempt.

Tatsächliches OpenVPN-Verhalten

• Wir sehen aber 30x/Minute Verbindungsaufbau 🤨
• OpenVPN 2.6 hat grundsätzlich Rate-Limiting
• Sophos UTM-9: OpenVPN 2.3.10 aus 2016 😢

Aber warum killt das die Firewall?

Vieeeeele solcher Einträge für betroffene Accounts in Logs:

<M> fw:/var/log # tail -f confd.log
[…]
a1efc4a36a3696f0510a5ff2d3c46814e" facility="system" client="confd-qrunner.pl" pid="3750" attr_ras_online="1" oldattr_ras_online="1"
2024:03:18-17:42:46 fw-1 confd[3664]: I main::top-level:682() => id="310a" severity="info" sys="System" sub="confd" name="object changed" class="network" type="aaa" ref="REF_NetAaaFoobarUserNetwo" objname="johndoe (User Network)" user="system" […] client="confd-qrunner.pl" pid="3750" attr_addresses="['10.23.42.2']" […]"
<M> fw:/var/log # grep -c johndoe confd.log     # Problemaccount:
9317
<M> fw:/var/log # grep -c synpromika confd.log  # zum Vergleich:
28

HA kommt nicht hinterher 🥹

Open Source FTW

• OpenVPN#525
• Tunnelblick ignorierte “HOLD:Waiting for hold release:$SECONDS”
• Shoutout an Gert Doering, Jonathan K. Bullard + Selva Nair ❤️
• Fixes (commit 1738bb6 + commit a595bfe)
  in Tunnelblick Versionen >=5.0.1beta01 / 6.0

Sophos UTM

• verwendet uraltes OpenVPN 2.3.10
• kein Rate-Limiting für OpenVPN-Verbindungen
• Sync/Replikation kommt im HA-Setup nicht hinterher
• veraltete Cipher-Settings

Lessons learned (1)

• Logs lesen (erschlägt ~90% aller Probleme)
• Upstream-Projekte involvieren zahlt sich aus
• Menschen ignorieren Fehlermeldungen/Probleme
• … oder verstehen sie nicht
• … oder melden sie nicht

Lessons learned (2)

• brauchbare Fehlermeldungen
• Fehlerfälle ausgiebig testen
• Vorwärts- und Rückwärts-Kompatibilität bedenken
• Upgrade-Pfad auch für Konfigurationsänderungen
• Prozess für regelmäßiges Erneuern von VPN-Zertifikaten
• Sicherheitsnetz einbauen (Throttling/Rate-Limiting/…)

BTW

Ansible Playbook

- name: Download client binary
  get_url:
    url: "https://github.com/restic/restic/releases/[…]"
    dest: "/tmp/restic_{{ restic_version }}.bz2"
  delegate_to: localhost
- name: Decompress the binary
  shell: "bzip2 -dc /tmp/restic_{{ restic_version }}.bz2 > /tmp/restic_{{ restic_version }}"
  args:
    creates: "/tmp/restic_{{ restic_version }}"
  delegate_to: localhost
- name: Propagate restic binary
  copy:
    src: "/tmp/restic_{{ restic_version }}"
    dest: "{{ restic_install_path }}/restic"
    mode: '0750'
    owner: root

YAML-to-Shell

BASE_URL=https://github.com/restic/restic/releases/download/
wget "$BASE_URL/v0.18.1/restic_0.18.1_linux_amd64.bz2"
bzip2 -dc restic_0.18.1_linux_amd64.bz2 > /tmp/restic_0.18.1
cp /tmp/restic_0.18.1 /usr/local/bin/restic
chmod 0750 /usr/local/bin/restic
chown root: /usr/local/bin/restic

Quizfrage

- name: Decompress the binary
  shell: "bzip2 -dc /tmp/restic_{{ restic_version }}.bz2 > /tmp/restic_{{ restic_version }}"
  args:
    creates: "/tmp/restic_{{ restic_version }}"
  delegate_to: localhost

- name: Propagate restic binary
  copy:
    src: "/tmp/restic_{{ restic_version }}"
    dest: "{{ restic_install_path }}/restic"
    mode: '0750'
    owner: root

1. Was passiert, wenn bzip2 beim ersten ansible-Lauf nicht existiert?
2. Was passiert, wenn bzip2 beim zweiten ansible-Lauf existiert?

Was passiert beim Backup-Lauf?

% restic backup /srv/samba

Zero-Byte Executables

% touch restic
% chmod 750 ./restic
% ls -la ./restic
-rwxr-x--- 1 mika mika 0 Apr 11 11:42 ./restic
% ./restic
% echo $?
0
% strace -e execve bash -c './restic'
execve("/usr/bin/bash", ["bash", "-c", "./restic"], 0x7ffd0e589d20 /* 64 vars */) = 0
execve("./restic", ["./restic"], 0x55da5f295e40 /* 64 vars */) =
  -1 ENOEXEC (Exec format error)
+++ exited with 0 +++

Das schnelle Backup

[…]
2025-03-31 01:00:04+0200 LOG: Check if repository is ok
2025-03-31 01:00:05+0200 LOG: Create new backup
2025-03-31 01:00:05+0200 LOG: SUCCESS: Backup completed at 2025-03-31_01:00:05 [running 0 seconds]

Lessons Learned

• Kontrollierte Ansible-Ausführung
• … in sauberen + One-Time-Runs-Umgebungen
• Exit-Codes immer überprüfen
• … aber nicht nur darauf verlassen
• Checksummen von Binaries überprüfen
• Backups gehören wie alles wichtige ins Monitoring
• … Checks mit Timestamp-Dateien(!)
• … Laufzeit/Trends beim Backuplauf

Was war damals?

• Security-Incident bei einer Firma in 2023
• Server verhalten sich komisch™
• Produktionsbetrieb stark beeinträchtigt
• Endkunden rennen Support die Bude ein
• Problem verbreitete sich über viele Server
• Kaiten/Tsunami Malware mit C&C-Bot identifiziert
• … + abgewehrt

Identifizierte Probleme - 2023

• Keine Backups
• Kein Monitoring/Übersicht aller Systeme
• Kein Konfigurationsmanagement
• Kein zentrales Logging
• Identisches Passwort für alle root-Logins
• SSH-Logins als root-User
• Uralte, nicht aktuell gehaltene EOL
  Distro-Releases (teilw. Uptimes >900d)

Fast Forward: 2026

Betreff: Brauchen Cybersecurity-Unterstützung

2023 haben Sie uns bei einem Cybersecurity-Problem geholfen. Ich befürchte, wir stehen an einem entscheidendem Punkt mit einer weiteren ernsten Situation. Wir bekämpfen seit […] 2025 böse Akteure, und dachten, wir hätten alles im Griff, aber jetzt ist es wieder da.

Herausforderungen (1)

• drei involvierte Zeitzonen (CET vs PST vs IST) 🥱
• keine konsistenten Zeitzonen auf den Systemen
• … und kein zentrales Logging
• vierstellige Anzahl an Systemen
• … kein IT-Inventory (noch immer)
• … kein Monitoring (noch immer)
• Kommunikation zwischen versch. Kulturen “herausfordernd”

Herausforderungen (2)

• keine Firewalls (weder Perimeter noch “lokal”)
• Logins immer per SSH
• … Accounts von ehemaligen MitarbeiterInnen nicht deaktiviert
• … aber Logins nach wie vor immer nur als root
• viiiiiele öffentliche IPv4-Adressen in Verwendung
• … aber ohne Überblick welche zu wem gehören
• Web-Services laufen als Root
• … geschrieben von ehemaligen Mitarbeitern
• … mit hartkodierten Zugangsdaten im Quellcode

Herausforderungen (3)

• bisherige Rettungsversuche haben Spuren vernichtet
• infizierte Server die nach Absprache ausgeschaltet wurden,
  sind auf einmal wieder online
• Anfrage des IT-Dienstleisters für Freischaltung
  eines weiteren SSH-Keys. Guess what?
• … privater Teil des SSH-Keys wird im JIRA-Ticket geteilt

Herausforderungen (4)

• Passwörter in Shell- und MySQL-History
• … Entropie ist “verbesserungswürdig”
• … es ist eh noch immer fast überall das gleiche in Verwendung
• Es gibt eine Produktions-Datenbank mit XX TB
• … ohne Backup
• … aber wenigstens konsistent, denn:
• Es gibt generell keine Backups (noch immer)
• … aber dafür jede Menge …?

Malware

• Kaiten/Tsunami (noch immer)
• CoinMiner
• XMRig
• SSHBrute
• Korkut2
• LD_PRELOAD-Malware
• Python/EBPF-basierte Reverse-Shell
• …

Account Problems

My password is just every Unicode codepoint
concatenated into a single UTF-8 string.

nologin

/etc/passwd eines infizierten Systems:

% grep systemd: /etc/passwd
systemd:x:000:65534:systemd:/:/usr/sbin/nоlоgin

% grep systemd: /etc/passwd | cat -vte
systemd:x:000:65534:systemd:/:/usr/sbin/nM-PM->lM-PM->gin$

% ./busybox ls -la /sbin/nologin /usr/sbin/nоlоgin | ./busybox cat -vte
-rwxr-xr-x    1 root     root        964536 Nov 24  2024 /sbin/nologin$
-rwxr-xr-x    1 root     root        964536 Jan 17  2025 /usr/sbin/n?l?gin$
% ./busybox md5sum /sbin/nologin /usr/sbin/nоlоgin
cfd65bed18a1fae631091c3a4c4dd533  /sbin/nologin
cfd65bed18a1fae631091c3a4c4dd533  /usr/sbin/nologin

Recap

Was 🤡-IT begünstigt (1)

• IT wird nur als Kostenstelle gesehen
• Compliance + Security werden gleichgesetzt
• Fehlendes Interesse an Fortschritt
• Kein Commitment/Engagement (“not my job”)
• Fehlendes Projektmanagement

Was 🤡-IT begünstigt (2)

• Peters-Prinzip: “In einer Hierarchie neigt jede:r Beschäftigte
  dazu, bis zur Stufe der Unfähigkeit aufzusteigen.”
• Truthahn-Illusion: unsere IT läuft doch eh so super!
• Maslows Hammer: vertrautes Werkzeug nutzen,
  obwohl ein anderes besser geeignet wäre
• IKEA-Effekt: selbst gebaute IT erfährt mehr Wertschätzung
• Herdentrieb: Neigung, sich an der Mehrheit
  zu orientieren ($TOOL ist der neue hot sh*t!)
• Status-quo-Verzerrung: Bevorzugung des Status quo
  gegenüber Veränderungen

Was 🤡-IT begünstigt (3)

• Keine Dokumentation
• Kein/mangelndes Feedback
• Keine Entscheidungen (!= nicht schlechte Entscheidungen)
• Rue de la Gack (AKA alles rot im Monitoring)
• Keine Vision wohin es gehen soll
• Veränderungserschöpfung (nach Steffen Mau)
• Keine oder mangelnde Kommunikation
• Schatten-IT

Schatten-IT

• Systeme/Prozesse in Unternehmen, die neben der offiziellen
  IT-Infrastruktur und ohne Wissen des IT-Bereichs existieren
• Passierschein A38
• Datensilos
• Nichts ist permanenter als ein Prototyp
• Deployment ist “leicht”…
• … schwierig ist etwas wieder endgültig loszuwerden
• Schatten-AI

Was macht man gegen 🤡-IT?

• Es braucht Trüffelschweine für 🤡-IT
• Review-Prozesse + externe Audits (gegen Betriebsblindheit)
• Technische Schulden reduzieren
• System lässt sich nicht verbessern bis man
  versteht warum es so funktioniert wie es funktioniert
• Best Practices praktizieren
• Kommunikation, Kommunikation, Kommunikation

People

“The two hardest problems in computer science are:
(i) people, (ii), convincing computer scientists that
the hardest problem in computer science is people, and,
(iii) off by one errors.”

– Jeffrey P. Bigham

Wenn doch der Desaster-Fall eintritt?

• Fatigue-Management: Handgriffe sollen automatisch
  gehen, aber Aufmerksamkeit muss hoch bleiben (Abwechslung!)
• Ruhig bleiben: in größter Hektik muss
  größtmögliche Ruhe vorherrschen
• zuerst Diagnostizieren, dann Therapieren