Angemessene Reaktion bei Brute-Force-Attacke

    Quote from Gerhard Fuchs

    ...

    Das Monitoring der Logs stellt mich vor eine Herausforderung. Was mir bei Debian 11 aufgefallen ist, ist dass z.B. fail2ban oder logwatch einen Mail Transfare Agent (MTA) vorschlagen, bzw. sogar fordern.


    Einen MTA wie z.B. exim4 empfinde ich aber übertrieben. Ich bin nicht begeistert, wenn ich deswegen Zugangsdaten eines Mail-Accounts auf dem Asterisk-Server ablegen müsste, damit dessen Monitoring-Werkzeuge autonom Mails versenden können.

    ...

    Ist mir tatsächlich noch nicht aufgefallen.

    Aber mein Server ist ja unter anderem ein Mailserver...

    Quote from Gerhard Fuchs
    ...

    Eigentlich sind diese beiden Programme, für meine Zwecke aber auch noch überdimensioniert. Ich möchte den Asterisk-Server so einfach wie möglich halten. Das SMTP-Protokoll, also das Senden von Mails über ein Netzwerk, muss er nicht können. Mir würde eine Möglichkeit reichen, bei der die Mails lokal z.B. in /var/spool/mail/user abgelegt werden.

    ...

    Generiert der Asterix Server von Hause aus selbst nur lokale Logfiles und hat keine Funktion - z.B. Fehlermeldungen - an ein lokales Mailpostfach wie /var/spool/mail/user zu senden?


    Mir würde da spontan der Voicemail Versand einfallen. Und ob nun ein zusätzliches Modul des Asterix Server oder ein zusätzliches Paket wie msmtp aus dem Repo installiert werden muss. Nimmt sich meiner Meinung nach nicht viel.

    Du kannst einen zweiten, kleineren RS mieten und darauf eine Firewall installieren.

    Die zwei Server dann mit einem internen VLAN verbinden und allen Verkehr durch die Firewall routen lassen.


    Das bietet dir drei Vorteile:

    1. Du kannst bekannte Filterlisten nutzen, um z.B. TOR und bekannte "böse" IPs auszusperren.

    2. Du kannst in der Firewall ein VPN nutzen, um die Firewall und deinen Dienstserver zum Beispiel via SSH zu erreichen.

    3. Du kannst die Firewall Regeln mittels einer übersichtlichen GUI verwalten.


    Am Ende des Tages solltest du aber jeden Server so einrichten, als wäre er direkt dem Internet und allem Bösen dieser Welt exponiert.

    Fail2Ban ist immer Pflicht und in 2 Minuten installiert und eingerichtet für SSH.


    Ich würde in deinem Fall die Firewall nicht in einer VPS installieren. Sprachdaten sollten immer möglichst geringe und gleichbleibende Latenzen haben.

    Solltest du Monitoring betreiben, so könntest du z.B. Grafana und die DB deines Vertrauens ebenfalls hinter der Firewall platzieren. So kommst du mit dem dem gleichen VPN an all deine Dienste. Die Fail2Ban Mails helfen kaum wenn der SSH Port öffentlich zugänglich ist. Von meinem Gefühl her sind die Mails eher dafür gedacht, dass man aufmerksam wird, wenn ein nicht öffentlicher SSH Port angegriffen wird. Wenn man eine Statistik der Fail2Ban Jails will, dann kann man diese Info auch via Telegraf ermitteln und z.B. in eine InfluxDB schicken. Das ist auch der Grund, warum ich anfangs Grafana empfohlen hab: Ich will meine Alarme am liebsten nur von einem einzigen System bekommen und dort die zugehörigen Regeln managen.

    Quote from Homwer

    UFW wäre z.B. erträglich zugänglich und einfach einzurichten.

    Die UFW solltest du immer haben.

    Trotz externer Firewall möchtest du ja deine Server so sicher wie möglich betreiben. Und via UFW kann man ja wurderbar regeln welche Ports auf welchem Interface offen sein dürfen.


    Leider kann die UFW nicht sonderlich viel verglichen mit einer NextGen oder WAP Firewall.

    Oft ist man gedanklich in der Richtung UFW < NextGen < WAP Firewall unterwegs, was aber der Sache nicht gerecht wird.


    NextGen wie PFSense oder OPNSense können Feeds abonieren, um automatisch DNS Einträge oder IPs zu blockieren.

    Das dort enthaltene IDS bzw. IPS ist nur noch als mittelgut anzusehen, da diese Firewalls nicht in den verschjlüsselten Traffic reinschauen können.

    Die werden gerne als Primärfirewalls eingesetzt.


    Einer WAP Firewall hinterlegst du deine Zertifikate, und die prüft den eingehenden Traffic zum Beispiel auf Injections.

    Damit kannst du (hoffentlich) verhindern, dass schwachstellen deiner Anwendung ausgenutzt werden können. WAF überwacht also auf Layer 7 wenn man so möchte. Und natürlich ist das rechenintensiv, daher sollte man nur die wirklich relevante Teilmenge des Traffics analysieren.


    Und natürlich gibts Firewalls die sowohl NextGen wie auch WAP Features haben.

    Quote


    Was spricht gegen eine Firewall direkt auf dem System?

    1. Sicherheit. Eine FW läuft meistens in einer speziell gehärteten Umgebung. Die muss alles aushalten, was ihr das Internet an den Kopf wirft. Du bekommst PfSense und OpnSense nur als Image (oder als SourceCode natürlich)

    2. Zumindest PfSense und OPNSense sind BSD basiert.

    3. Direkt auf dem System wäre ja dann eine "Software Firewall". Die wurden häufig mit Schlangenöl verglichen und haben nicht selten selber kritische Lücken gehabt. Es gibt aber mittlerweiile seriöse FW Systeme, die einen lokal installierten Agent benötigen. Damit kann man dann die FW Regeln zum Beispiel am Benutzer anstatt am System oder der IP festmachen.


    Ansonsten fallen mir ein: Gezielte Skalierung, einfache Installation anhand von ISO Image anstatt als Dienst, erweiterte Features z.B. bei PfSense+ gibts Bootumgebungen mittels ZFS, Trennung der Lasten und damit einfachere Prognosen zur Kapazität, und ganz wichtig: Hat eines der Produkte eine Sicherheitslücke, dann ist nur der eine Dienst gefährdet. Ansonsten gilt: Ist ein Angreifer auf einem Linux Server, egal mit welchen Rechten, dann muss der Server komplett neu installiert werden. Daher lieber einen kleinen extra Server für die FW nehmen, anstatt einen größeren zu Bestellen, auf den man alles drauf packt.


    Der letzte Punkt wäre normalerweise VPN gewesen. Jetzt ist ein Szenario von Wireguard eben auch die Server zu Server kommunikation im RZ abzusichern. Daher ist das eher eine Geschmacksfrage als eine Sinnfrage. Würde ich ein Schutzkonzept erstellen, dann würde ich meine "Admin Verbindung" auf die FW machen und dann von dort aus auf ein zweites WireGuard Netz mit meinen Servern routen, dass in einem internen VLAN läuft.

    Hat man zwei getrennte WG Netzwerke, dann greifen die FW Regeln der Firewall. Sprich man kann mittels der FW Ports einschränken usw.

    Hätte man ein großes WG Netzwerk mit Servern + Admin Clients, dann würde nur WG intern geroutet werden.

    Quote from NieSommer

    1. Sicherheit.

    Die Frage ist, ob dieses Schutzniveau angemessen ist.

    Externe Firewalls setzt man bei sensiblen Daten oder bei Windows ein - weil Windows auf L2 schon recht fragwürdig ist.

    Wenn du keine Staatsgeheimnisse verarbeitest, reicht auch eine integrierte Firewall.



    Quote from NieSommer

    3. Direkt auf dem System wäre ja dann eine "Software Firewall"

    Sowohl OPNSense, als auch PfSense nutzen das pf Feature des OpenBSD Kernels - sind also Software Firewalls.

    Gleiches gilt für nftables unter Linux.



    Quote from NieSommer

    Die wurden häufig mit Schlangenöl verglichen und haben nicht selten selber kritische Lücken gehabt.

    Was?

    OpenBSD Pf: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=openbsd+pf


    Linux nftables: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=nftables

    Linux iptables: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=iptables (nicht alle Suchergebnisse betreffen das Kernelmodul)



    Quote from NieSommer

    Ansonsten gilt: Ist ein Angreifer auf einem Linux Server, egal mit welchen Rechten, dann muss der Server komplett neu installiert werden.

    Das stimmt nicht - selbst wenn es stimmt, ist es gleich für andere POSIX Systeme, wie OpenBSD.

    Wenn jemand nicht priviligiert unterwegs ist, bekomme ich den relativ leicht runter.

    Priviligiert bekomme ich den auch runter, hier ist allerdings eine Neuinstallation empfehlenswert, jedoch keine harte Bedingung

    Du hast recht, ich meinte Personal Firewalls. Es geht also um die Unterscheidung ob die Firewall auf dem zu schützenden System läuft oder auf eigener "Hardware".

    Die Diskussion bzgl. Schlangenöl war ganz besonders ausgeprägt zu den Hochzeiten von ZoneAlarm und Norton. Mehr als die Windows Firewall fordert selbst das BSI nicht mehr auf Heimanwenderseite, sondern spricht Empfehlungen zur Härtung oder ähnlichem aus.


    Externe Firewalls sind nach BSI Ansicht nach ein muss. Es gibt immer mal wieder Dinge, wie zum Beispiel den Ping of Death. Die will man vor dem Server anfangen und nicht auf dem Server. Es gab auch schon Würmer, die es speziell auf verwundbare Personal Firewalls abgesehen hatten. Am bekanntesten ist hier wohl Witty https://de.wikipedia.org/wiki/Witty_(Computerwurm)

    Das BSI macht zudem klare Vorgaben zur Trennung von Internet, Server- und Clientnetzwerken. Und das ist wirklich noch der obligatorische Teil des Grundschutzes für normale Unternehmen.


    Bezüglich der optionalen Neuinstallation hab ich starke Zweifel. Das System wurde geändert, und selbst Forensiker haben Probleme die Änderungen zu erkennen und zu verstehen. Daher ist der Weg über die Neuinstallation (und natürlich neue Passwörter, Token, Schlüssel und Zertifikate) der einzig sinnvolle. Neben den Veränderungen weiß man ja auch nicht sicher, welche Daten extrahiert wurden. Also mir wäre das Risiko deutlich zu groß.

    Ich habe auf unserer PBX einfach ein IPSet mit allen "nicht deutschen" IPs aufgesetzt (100% unserer Nutzer*innen haben die IP eines deutschen Providers). SSH und SIP von nicht deutschen IPs geht direkt in den REJECT. Seitdem sind die Angriffsversuche um mehr als 98% gefallen. Es gibt selbst auf dem Mini-VPS keinerlei Performanceeinbrüche oder Verzögerungen.