Ab sofort: Firewall für netcup vServer verfügbar

    Meine unter #106 eingepflegten Regeln haben einwandfrei funktioniert....jetzt plötzlich nicht mehr.

    • Ausgehender HTTPS-Traffic wird blockiert
      • Ich nutze u.a. DoH über einen Proxy auf Adguard Home, welcher dann per DoH bei Cloudflare abfragt
      • Adguard hat so ziemlich genau um 04:00 aufgehört zu funktionieren (ausgehender HTTPS Traffic, keine Auflösung der Queries mehr möglich)
    • Auf meinen geänderten SSH-Port komme ich auch nicht mehr

    Kaum schmeiße ich meine einzige Policy raus (dann wird automatisch die ACCEPT ALL für IN/OUTGOING gesetzt) -> alles wieder funktional.


    Gleichzeitig erhalte ich beim editieren ab und an das hier:
    Screenshot 2025-12-11 11.23.43.png

    EDIT: Und ganz im Ernst, das Regelwerk hat gestern bis ich ins Bett bin einwandfrei funktioniert.

    Einmal editiert, zuletzt von -Manu- (11. Dezember 2025 um 11:29)

    Zitat von h725rk

    diskutieren

    vergiss bei TCP die source ports, clients verwenden immer ephemeral ports! ausserdem ist die firewall für TCP eh state-full, wir müssen uns also um die rückrichtung nicht kümmern. und der server port ist immer bei destination port anzugeben.

    ich vesuch das mal aufzumalen.

    Code
    your host |                          | remote host
client    |-->> outgoing/egress >>---| server
scr port  |                          | dst port

your host |                          | remote host
server    |--<< incoming/ingress <<--| client
dst port  |                          | src port

    beispiel:

    lokaler web-server

    richtung: INcoming/INgress

    proto: TCP

    destination port: 80 und 443

    ich führe es hier zwar an, aber sich im hobby umfeld mit outgoing rules künstlich einzuschränken grenzt an masochismus, vor allem wenn man dann eh erst recht auf alle web server zugriff gewährt.

    remote web-server

    richtung: outgoing/egress

    proto: TCP

    destination IP: 144.208.213.156 (debian mirror debian.anexia.at)

    destination port: 443


    also Deine eingehenden TCP regeln passen, die ausgehenden sind falsch, da gehört der port in den destination port, also unter der annahme Du willst *alle* http/s, smtp, ... server da draussen im netz erreichen, da kannst die outgoung regeln aber gleich ganz lassen imho.

    zu UDP etwas später.

    bei UDP müssen wir hier bei der netcup firewall, da state-less, auch die rückrichtung der packerle betrachten.

    zur erinnerung, clients verwenden auch bei UDP fast immer einen ephemeral port, der server port hingegen ist fix und vom service abhängig (zb 53 für DNS oder 123 für NTP).

    und auch hier nochmal der hinweis, outgoing rules definieren zu wollen grenzt an masochismus, bei state-less noch viel mehr, da spürt man die schmerzen schon alleine durchs lesen.

    beispiel:

    spezifischer remote NTP-server

    regel 1

    richtung: outgoing/egress

    proto: UDP

    destination IP: 178.251.64.52 (time.nobody.at)

    destination port: 123

    regel 2 für die antwort

    richtung: INcoming/INgress

    proto: UDP

    source IP: 178.251.64.52 (time.nobody.at)

    source port: 123

    destination port: 32768 - 60999 (Linux ephemeral port range)

    will man alle NTP-server da draussen ansprechen, weil man zb einen pool wie pool.ntp.org abfrägt, sind einfach die IPs wegzulassen.


    lokaler NTP-server

    regel 1

    richtung: INcoming/ingress

    proto: UDP

    destination port: 123

    regel 2 für die antwort

    richtung: outgoing/egress

    proto: UDP

    source port: 123

    hier ist eine einschränkung auf die ephemeral ports nicht möglich, da der range je nach client implementierung anders ist, vergleiche dazu https://en.wikipedia.org/wiki/Ephemeral_port#Range

    das beispiel ist 1:1 für DNS anzuwenden.


    Deine UDP regeln mußt Du also unbedingt überarbeiten.


    aja, ICMP würde ich nicht einschränken. ja, ping verwendet ICMP, aber ICMP wird auch für ganz viele andere, essentielle dinge verwendet, vor allem bei IPv6.

    h725rk

    Wie eben beschrieben: tue dir das nicht an....das ist Selbstgeißelung hoch 10x3000 (im genannten Privat/Hobby-Bereich)

    Das wird im dümmsten Fall ein absolutes Loch im Boden, bis da alles so läuft wie es soll. Wir haben das bspw. in unseren Umgebungen (Arbeit) für alle Kommunikationsbeziehungen....du wirst einfach nur irre und bedarf einer absolut saubersten Dokumentation.

    Man sieht u.a. auch in den genannten Beispielen sehr schön, wie die Ephemeral port range aufgeführt wird, die werden dynamisch genutzt.

    D.h. im Prinzip muss man immer die komplette Range öffnen, da nur wenige Services es überhaupt erlauben hier entsprechend einzuschränken oder konkret zu definieren.

    Ich denke für den Privatgebrauch ist es am sinnvollsten:
    Eingehende Kommunikationsbeziehungen klar definieren

    Ausgehende erlauben

    Zitat von h725rk

    Sieht das jetzt besser aus?

    Du wirst noch eingehend dst TCP 80 und 443 für http/s öffnen wollen.

    die idee bei ausgehend TCP auf any zu setzen ist nicht schlecht, bewahrt Dich aber nicht davor, daß Deine UDP regeln falsch sind. das mit source und destination port ist keine oder-relation. und nein, weder rspamd noch dns (in ausnahmefällen) kommunizieren mit dem selben src und dst port.

    bitte, vergiss das mit den outgoing regeln.

    es ist da schon kompliziert genug die inbound für Deine UDP clients richtig zu machen, die müssen für DNS wie folgt aussehen:

    richtung: INcoming/INgress

    proto: UDP

    source port: 53

    destination port: 32768 - 60999 (Linux ephemeral port range)

    vor allem fürn unbound, der ja alle DNS server da draussen im netz abfragt.

    fürn rspamd könnte man es noch auf die source IP eingrenzen, hat aber den nachteil, wenn die mal die IP von zb fuzzy.mailcow.email ändern mußt das manuell in der firewall nachziehen, also auch hier genau das selbe wie beim DNS.

    richtung: INcoming/INgress

    proto: UDP

    source port: 11445, 11335

    destination port: 32768 - 60999 (Linux ephemeral port range)

    Zitat von hoedlmoser

    unbound

    oida.

    kinder, vergessts das mit einer state-less firewall. investierts eure zeit lieber in eine lokale state-full firewall und verwendets die von netcup nur um die phösen burschen wegzublocken.

    https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound.conf.html#unbound-conf-outgoing-port-permit

    Zitat

    By default only ports above 1024 that have not been assigned by IANA are used.

    also nix mit standard ephemeral port range.

    richtung: INcoming/INgress

    proto: UDP

    source port: 53

    destination port: 1024 - 65535

    hihi, steht aber eh auch in dem von Dir genannten link https://docs.mailcow.email/de/getstarted/prerequisite-system/ unter 'Wichtig für H3tzn3r Firewalls'

    Zitat von Virinum

    Hab noch einen Bug entdeckt: Wenn man im SCP auf Optionen klickt, lautet der Titel der Webseite SCP - Kundendaten (Optionen). Klickt man anschließend auf Firewall Policys, wählt irgendeine Firewall Policy aus und klickt dann z.B. auf SSH Keys, lautet der Titel SCP - SSH Keys (undefined)  Moderatoren

    Hallo Virinum

    herzlichen Dank für deinen Hinweis! :)
    Wir haben ihn intern an die entsprechende Stelle weitergegeben.

    Liebe Grüße
    Sarah & das netcup-Team

    Ok, nochmal angepasst.

    TCP und UDP Traffic nach außen ist offen.

    Unbound und RSPAMD nochmals angepasst und HTTP/HTTPS hinzugefügt

    Ich schaue nachher nochmal nach wie bei Debian 13 die internen Ports definiert sind. Aber nun sollte es in Ordnung sein.

    Mit TCP hatte ich das schon verstanden. Aber UDP war noch ein bisschen schwer.

    Verstehe es aber nun

    fürn unbound brauchst keine TCP rule, TCP ist ja eh state-full.

    aber mit der Unbound UDP rule besteht halt das problem, wie ich weiter oben schon mal erwähnt habe, daß ich alle Deine UDP services mit port >= 1204 nutzen kann (wenn ich den src port 53 benutze). also sehr suboptimal!

    bevor aber panik ausbricht, schau mal was da bei Dir an UDP ports überhaupt so offen ist.

    Code
    netstat -ulpn
    Zitat von -Manu-
    Code
    sudo apt install net-tools

    Bei "Minimal"-Versionen (egal welche Distribution) fehlen bewusst viele Anteile an Standardkomponenten.

    Das ist keine Standardkomponente mehr. Gibt es natürlich noch und man kann es auch installieren. Aber es ist mttlerweile deprecated seit einigen Jahren. Kannst auch mal schauen ob eventuell ss installiert ist. Das kann das alles auch anzeigen. Das ist der ofizielle "Ersatz" für netstat, zumindest seit Debian Bullseye, eher sogar seit ca 2011.

    Auch ich bin alt genug, um zumindest die deutsche Bedeutung von "SS" zu kennen und den Namen des Befehls nicht unbedingt als glücklich anzusehen. Und ich habe auch oft genug netstat nachinstalliert. Fakt ist aber, schon seit einiger Zeit ist netstat zumindest in den Minimalversionen von Debian nicht mehr installiert, ss aber wohl.

    Ich wäre ja froh, wenn sie zumindest dauerhaft das machen würde, was ich ihr als Policy mit Regelwerk vorgebe....aber die überlegt sich das bei mir mittendrin dann anders :)

    Wie oben beschrieben, bin ich ja auch augenscheinlich der einzige mit der "Huch, das sollte nicht passieren"-Fehlermeldung :)

    Vielleicht ein Einzelschicksal, ich lass das Ganze noch etwas reifen...