nftables basic config + dropped package logging

  • Hallo zusammen,


    bin neu hier und habe seit kurzem einen RS 1000 G 9.5.

    Soll erstmal eine Docker-Spielwiese werden - grundsätzlich aber mal eine saubere/sichere Grundlage für Bitwarden bieten.

    Grundsätzlich ist mein erstes Interesse den Server erstmal so "abzusichern", dass ssh nur von meiner Heim-Adresse erreichbar ist und der Rest erstmal geblockt wird.

    So hab ich Zeit, immer wieder was zu testen und zu konfigurieren und der Server steht nicht tagelang "ungesichert" rum...


    Deshalb, erstmal Root-Passwort in ein deutlich längeres Passwort geändert und nftables.service aktiviert und ein "basic-ruleset" eingespielt.

    Das Ruleset sieht wie folgt aus:

    Die "Live-Logs" hab ich mir dann mal mit "dmesg --follow" angesehen.

    Erhalte beispielsweise folgenden Output:

    Code
    [52927.001733] IN=eth0 OUT= MACSRC=10:0e:7e:XX:XX:XX MACDST=26:87:e1:XX:XX:XX MACPROTO=0800 SRC=24.199.115.205 DST=RS100G9.5-IP LEN=40 TOS=0x00 PREC=0x00 TTL=243 ID=62253 PROTO=TCP SPT=51227 DPT=40369 SEQ=1354948354 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0 
    [52927.329105] IN=eth0 OUT= MACSRC=10:0e:7e:XX:XX:XX MACDST=26:87:e1:XX:XX:XX MACPROTO=0800 SRC=180.108.97.6 DST=RS100G9.5-IP LEN=40 TOS=0x00 PREC=0x00 TTL=50 ID=16818 PROTO=TCP SPT=21992 DPT=23 SEQ=764326302 ACK=0 WINDOW=27344 RES=0x00 SYN URGP=0

    Wenn ich das per iplocation.net prüfe, sind die beiden IPs aus USA und China. andere Logeinträge waren auch aus Russland.


    Meine Frage(n):
    Wie kann ich erkennen, dass die beiden Pakete auch gedropped wurden?

    Kann ich mein nftables Ruleset anpassen, dass nur die gedroppten Pakete geloggt werden und ggf. ein Prefix "NFT Drop-In" (für die Input Chain), "NFT Drop-Out" (für die Output Chain) und "NFT Drop-Fwd" (für die Forward Chain) hinzufügen?

    Kann man dann accepted Pakete auch iwie kennzeichnen?


    Zudem wäre es angenehm, wenn man im nftables Ruleset meine Home-IP anhand des dyndns hostnames auflösen könnte... aber da hab ich noch nichts dazu ergoogeln können. ändert sich zwar selten die IP, aber trotzdem müsste ich mich, aktuell bei Änderung, über das SCP einloggen und via VNC-Konsole die IP im Ruleset ändern.


    Weitere Schritte wären:

    - ggf. cloudflare probieren und davorschalten

    - VPN (openVPN oder Wireguard)

    - nginx proxy manager

    - fail2ban implementieren

    - WAF/Countryblocking


    Vielen Dank fürs Lesen und eure Ratschläge.

  • dass ssh nur von meiner Heim-Adresse erreichbar ist und der Rest erstmal geblockt wird.

    Unnötig. Fail2ban installieren, mit SSH Keys arbeiten und den Passwort Login per ssh deaktivieren.

    So ist die Kiste dann auch sicher. Die IP von dir zuhause wird sich regelmäßig ändern, dann hast du dich selbst ausgesperrt.

    VPS Secret • VPS 200 G8 • 4x VPS piko G11s • 2x RS 1000 G9.5 SE NUE • RS Cyber Quack • VPS 1000 ARM G11 VIE

    c@compi.moe

    Haha 1
  • Meine Frage(n):
    Wie kann ich erkennen, dass die beiden Pakete auch gedropped wurden?

    Kann ich mein nftables Ruleset anpassen, dass nur die gedroppten Pakete geloggt werden und ggf. ein Prefix "NFT Drop-In" (für die Input Chain), "NFT Drop-Out" (für die Output Chain) und "NFT Drop-Fwd" (für die Forward Chain) hinzufügen?

    Kann man dann accepted Pakete auch iwie kennzeichnen?


    Zudem wäre es angenehm, wenn man im nftables Ruleset meine Home-IP anhand des dyndns hostnames auflösen könnte... aber da hab ich noch nichts dazu ergoogeln können. ändert sich zwar selten die IP, aber trotzdem müsste ich mich, aktuell bei Änderung, über das SCP einloggen und via VNC-Konsole die IP im Ruleset ändern.

    Gedroppte Pakete (global) im Syslos loggen, mach ich am Ende der Input chain so:

    Diese im Syslog auftauchenden Einträge kannst Du dann auch mit Fail2ban weiter "verarbeiten".


    DDNS in nftables habe ich mich noch nicht mit befasst, aber accepted Pakete kannst Du über counter listen lassen.

    Beispiel:

    Sieht in nftables dann so aus:

    Code
    # nft list counters
    table inet filter {
        counter cnt_ssh_IN {
            packets 8 bytes 424
        }
    }
  • Ich gebe mal eine Gegenmeinung: Ich habe lange f2b eingesetzt, ich nutze es seit einiger Zeit gar nicht mehr.


    F2B hat nämlich zwei Probleme. Erstens muss deine Applikation sowieso damit klar kommen, was so an Müll hereinkommt, dein SSH muss also auch entsprechend sicher sein. Damit hilft F2B daher nicht viel gegen einen echten verteilten Angriff. Und zweitens müllt es dir im Zweifel nur die Nftables mit IPs voll. Was bei IPv6 richtig lustig werden kann. AFAIK gab es irgendwann die Entscheidung daher ganze /64er Netze zu blocken, immerhin bekomme ich hier auch einfach ein ganzes /64er Netz, viel Spaß, das einzeln zu blockieren. Es zeigt aber die Problematik auf. Die ganzen Mails von F2B erzeugen dazu noch einiges an Noise.


    Daher würde ich einfach den Port von SSH ändern, key-login-only, am besten ohne Root. Und dann ein paar Ratelimits auf kritische Bereiche (login) packen, was dein Apache/Nginx/.. schon kann. Wenn einer dir wirklich böse will, dann wird die F2B vermutlich auch nicht mehr viel bringen, im zweifel ist deine Kiste dann einfach überfordert.

    Deine Sicherheit sollte nicht davon abhängen ob jemand zufällig rechtzeitig von F2B erwischt wird, bevor deine Systeme gehackt sind, und die paar Logins auf SSH sollten auch kein Problem sein. Gerade mit anderem Port.

  • vielen Dank für deine Einschätzung.
    ich bin gerade eher auf dem Gedanken, die "Management-Dienste", also SSH, Portainer-Login etc. alles nur per VPN zu erlauben.
    Die einzigen Dienste welche wirklich "public" verfügbar sein müssen, wären beispielsweise Bitwarden, um halt unterwegs per Handy nicht vom VPN für den Sync abhängig zu sein.
    Alles andere kann eigentlich von Zuhause oder per Laptop etc. per VPN gemacht werden.


    Nichtsdestotrotz stelle ich natürlich einen Unterschied zu meinen früheren "Heimservern" fest.

    Bisher hatte ich immer alles OnPrem - komme was wolle. Nur der Stromverbrauch, Wartungsaufwand und ggf. notwendige Portforwardings oder Konstruktionen mit einer Firewall auf einem VServer und dann per Tunnel die Dienste per WAF vom VServer ins Homelab gesichert - ist mir einfach zu viel Aufwand für den Nutzen und haben mich vieles einstampfen lassen.

    Deshalb war die Idee, etwas "zu verschlanken" und habe sämtliche "just for fun" Dienste abgeschaltet.

    Jetzt, nach Monaten des "Nichtstuns im Homelab" nun die Überlegung, den einen notwendigen Dienst (bitwarden) möglichst sicher auf einem VServer zu betreiben.


    Aber vll. bin ich da auch auf dem Holzweg :D


    Jedenfalls, eine interessante neue Situation für mich, dass der Server, welche die Dienste bereitstellt nun direkt abgesichert werden muss, da er direkt angegriffen wird. Sonst war wie gesagt mindestens ein Router oder eine Firewall davor.

  • das durchprobieren von passwörtern zu verlangsamen

    Hm, aber in der Praxis willst du eigentlich nie eine IP beim login komplett ausschließen. Sonst erschießt du dich selber oder sorgst bei CG-NAT für einige Probleme. Und für echten Login-DoS gibts genug IPs dass dein Filter einfach irgendwann gigantische IP-Mengen in den Tables packen. Da hilft es eher wenn dein System a) lange genug braucht um den Login als Falsch ab zu weisen und b) per Rate-Limiting sehr viel unterschiedliche IPs braucht. Du musst da ja garnicht viel Limitieren, es reicht wenn ich ein paar ms pro Anfrage und viele IPs brauche, dann wirds schon unwahrscheinlich bei guten Passwörtern ein Ergebnis vor dem Hitzetod des Universums zu finden. Sonst nimm echte Captchas, dann hast du das beste aus beiden Welten: Harte Limitierung aber kein Ausschließen von echten Nutzern.

    Persönlich ist mir da die Menge an Log-Parsing und IP-Table befüllen zu viel "Gefühlte Sicherheit". Wenn ich in diese Probleme wirklich fallen sollte, dann packe ich gleich Cloudflare davon, mit 'ner WAF-Rule für "managed captcha" auf "/login".

  • sorgst bei CG-NAT für einige Probleme

    cg-nat ist das problem schon ansich. ist dann halt pech.


    echten Login-DoS

    ist nicht der scope von f2b diesen zu mitigieren.


    lange genug braucht um den Login als Falsch ab zu weisen

    frisst der DoS dann auch noch zusätzlich memory für jeden prozess der da wartet.


    per Rate-Limiting sehr viel unterschiedliche IPs braucht.

    gute idee, sag ich meinen kunden sie mögen bitte nur drei ssh sessions oder drei imap verbindungen pro minute aufmachen. nicht.

    rate-limiting funktioniert da nur bei sehr hohen raten und authentifizierungsfreien diensten wie dns.


    Sonst nimm echte Captchas,

    bei ssh und imap? wie?

  • Und für echten Login-DoS gibts genug IPs dass dein Filter einfach irgendwann gigantische IP-Mengen in den Tables packen.

    Dafür gibts ja ipset. Kann auch mit großen Listen schnell und performant umgehen.


    Die Kombination aus ipset Blocklisten von bekannten Anbietern und dem Verlagern des SSH Ports führt bei mir zu 0, wirklich NULL SSH Login Versuchen. Darüber hinaus ist nur zertifikatsbasierte Anmeldung möglich.

  • Dafür gibts ja ipset. Kann auch mit großen Listen schnell und performant umgehen.


    Die Kombination aus ipset Blocklisten von bekannten Anbietern und dem Verlagern des SSH Ports führt bei mir zu 0, wirklich NULL SSH Login Versuchen. Darüber hinaus ist nur zertifikatsbasierte Anmeldung möglich.

    Blöde Frage.

    Wenn ihr ipset nutzt, dann verwendet ihr aber noch iptables https://www.netfilter.org/projects/ipset/index.html , oder?


    Mit der Verwendung von nftables kann man Listen doch direkt laden/verwenden.

  • Ja, ich nutze noch iptables. Ich hatte noch keine Lust, das Script umzuarbeiten, da da einige Dinge drin sind, die sich nicht so unmittelbar in nftables abbilden ließen. Das geht sicherlich, aber man muss erheblich mehr Zeit reinstecken, als ich damals hatte.

  • da gehts doch nicht um eine lastabwehr sondern das durchprobieren von passwörtern zu verlangsamen bzw erschweren.

    Wenn ich mal so in meine Logs schaue (z.B. Mailports; SSH ist VPN-Only), dann tauchen die meisten IP's dort nur ein einziges Mal auf. Die wechseln quasi im Sekundentakt das Subnetz und ich gehe stark davon aus, dass das die gleichen Bots sind, wenn es immer ums gleiche Postfach geht. Blöd nur, dass sie den falschen Benutzernamen übermitteln. :D

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Einmal editiert, zuletzt von KB19 ()

  • Wenn ich mal so in meine Logs schaue (z.B. Mailports; SSH ist VPN-Only), dann tauchen die meisten IP's dort nur ein einziges Mal auf.

    Das ist bei mir anders. Ich habe ein Script laufen, dass auf Basis verschiedener Ausgaben (iptables, Server Logs etc.) eine Auswertung macht. Die folgenden Blöcke zeigen jeweils die IP-Adresse und wie häufig sie in den letzten 24 Stunden auffällig geworden ist (Hinweis: Ich logge sie erst ab 20 Versuchen).


    IPs von Blacklisten, die direkt beim ersten Aufruf komplett geblockt wurden, unabhängig vom Port, auf den sie zugreifen:

    Code
    69.162.124.236     2518
    46.17.102.6        1465
    89.248.165.197      885
    89.248.163.205      731
    89.248.165.185      682
    212.70.149.134      660
    45.143.200.50       469
    185.156.73.57       456
    45.227.253.98       392
    5.188.87.5          376

    Wie man sieht: Einige können es gar nicht lassen.


    Dann IPs, die nicht auf einer Blacklist standen, aber auf Ports zugegriffen haben, die bei mir zu sind:

    Code
    49.213.187.245       86

    Tatsächlich nur eine in den letzten 24 Stunden. Das sind durchaus auch mal mehr. Allerdings: Wenn sie es übertreiben, werden sie von mir in die Blocklisten aufgenommen.


    Zum Schluss noch die IPs, die auf einen offenen Port zugreifen wollten, aber Unsinn versuchten (PHP, RPC Attacken usw.):

    Code
    81.69.41.123        45

    Tatsächlich auch nur eine in den letzten 24 Stunden.


    Wie gesagt, alle IPs mit weniger als 20 Versuchen tauchen nicht auf.

  • kurze Rückfrage nochmal - hatte endlich etwas Zeit am WE mich mal mit der opnsense zu beschäftigen.
    Also, die opnsense ist soweit installiert und läuft.
    WAN Schnittstelle ist die "public IP" und LAN Schnittstelle aktuell das VLAN free.


    Beim RS1000 hab ich nun unter /etc/network/interfaces.d/ in der Datei "50-cloud-init.cfg":

    - die LAN Schnittstelle (eth1) mit einer manuellen IP konfiguriert

    - die WAN Schnittstelle (eth0) habe ich geändert von "iface eth0 inet static" auf "iface eth0 inet manual" + die Zeilen für Addresse + Gateway auskommentiert.


    Reicht das als "ordentliches deaktivieren" der WAN-Schnittstelle aus? Oder muss ich da lieber iwie mit "ifdown" arbeiten?


    Grundsätzlich scheint es zu funktionieren, denn der ping via public-IP von meinem Rechner aus liefert kein Ergebnis mehr, der Ping von der opnsense aus auf die LAN-IP funktioniert.