Ausgehender Traffic

    Hallo,

    mal eine kleine Frage.
    Wie habt ihr eure Firewall für ausgehenden Traffic konfiguriert?
    Aktuell habe ich die Regel, dass alles was nach außen gehen soll, auch darf, also

    #BeschreibungRichtungProtokollAktionQuellenSrc PortsZieleDst PortsAktionen
    1Ausgehend TCP offenAUSGEHENDTCPACCEPTbeliebigbeliebigbeliebigbeliebig
    2Ausgehend UDP offenAUSGEHENDUDPACCEPTbeliebigbeliebigbeliebigbeliebig

    Macht ihr das auch mit euren Servern oder gebt ihr einzelne Dinge nach außen einzeln frei?
    Mir ist auch klar, dass bei einer Kompromitierung der Traffic, ohne Blocking nach draußen geht.

    Ich frage nur nach, da ich aktuell Probleme mit apt bei debian hatte. Ich hatte zwischendurch Port 80 und 443 nach draußen freigeben und es ging.
    Mal aus andere Sicht, welche Ports sollten bei einer Standarddebian-Installation nach draußen gehen?

    Schönen Sonntag,
    Rob

    Zitat von h725rk

    Aktuell habe ich die Regel, dass alles was nach außen gehen soll, auch darf, (...)

    Solange du nur ACCEPT Regeln hast und nicht wenigstens einen DROP ist alles erlaubt, bis auf die impliziten Regeln z.B. für SMTP von netcup selbst.
    Erst mit der ersten netcup Firewall Policy also Richtlinie, die auch was verbietet, wird automatisch auch der Rest auf nicht erlaubt gesetzt.

    Auf einem vServer oder Root-Server, der vielleicht nur Web serviert, wären Port 80 und 443 eingehend freizugeben. Schau Dir mal die wirklich gute Anleitung der Serverkuchl an, die sehr schön erklärt wie man das mit Policies / Richtlinien umsetzt: netcup-Firewall im SCP einrichten (mit stateless-UDP-Kniff) · Serverküche <3:!:

    WH1000 SE OST22 OST23 OST24 | WH1000 SE ADV25 | WH 🥚🧶🥛🐖 | 🦆 VPS 200 🇺🇦🕊️ ➡️ VPS nano G11s

    Zitat von Copro

    Solange du nur ACCEPT Regeln hast und nicht wenigstens einen DROP ist alles erlaubt, bis auf die impliziten Regeln z.B. für SMTP von netcup selbst.
    Erst mit der ersten netcup Firewall Policy also Richtlinie, die auch was verbietet, wird automatisch auch der Rest auf nicht erlaubt gesetzt.

    Auf einem vServer oder Root-Server, der vielleicht nur Web serviert, wären Port 80 und 443 eingehend freizugeben. Schau Dir mal die wirklich gute Anleitung der Serverkuchl an, die sehr schön erklärt wie man das mit Policies / Richtlinien umsetzt: netcup-Firewall im SCP einrichten (mit stateless-UDP-Kniff) · Serverküche <3:!:

    Das mit den Regeln habe ich verstanden, aber ich habe mal die Anleitung von Serverküche durchgearbeitet und da war leider das Problem mit apt. Die Regeln werden dort nur als Eingehend definiert, aber eine ausgehende Regel gibt es nicht. Da apt Port 80 und 443 benötigt, müsste mindestens ausgehend 80/tcp und 443/tcp extra eingerichtet werden oder übersehe ich da was?

    Daher rührt auch meine Frage, wie ihr den Traffic nach außen definiert. Komplett oder doch restriktiv?

    Ich habe meine SCP-Firewalls für ausgehenden Traffic ebenfalls komplett offen.

    Welches Problem genau hattest Du mit apt? Vielleicht wird auch DNS over TCP benötigt, d. h. neben Port 80 (wird der wirklich noch benötigt?) und 443 könntest Du versuchsweise auch Port 53 für TCP ausgehend öffnen.

    Ich habe jetzt nach außen alles frei gemacht, damit der Server ohne Probleme kommunizieren kann.

    53/udp habe ich nur nach innen geöffnet.

    Aktuell habe ich noch ufw mit der Erweiterung ufw-docker drauf. Das werde ich wohl bald deaktivieren und deinstallieren. Dann steuer ich alles über die netcup-FW

    Zitat von h725rk

    (...) das Problem mit apt. Die Regeln werden dort nur als Eingehend definiert, aber eine ausgehende Regel gibt es nicht. Da apt Port 80 und 443 benötigt, müsste mindestens ausgehend 80/tcp und 443/tcp extra eingerichtet werden oder übersehe ich da was?

    Warum willst du den Server ausgehend auf der netcup seitigen Firewall unbedingt einschränken. Speziell die Firewall sieht ja gar nicht mehr, dass es hier z.B. um apt geht und nicht um z.B. einen Shell Trojaner, den du dir eingefangen hast. Das geht zwar auch nicht mit iptables / ufw aber ich würde mich trotzdem nicht nur auf die netcup Firewall verlassen und im besten Fall beide Seiten sinnvoll konfigurieren.

    Wenn du so große Angst davor hast, dass apt etwas böses macht, solltest du Richtung Sandbox Umgebungen wie firejail oder AppArmor / SELinux schauen ...

    apt würde neben TCP 80 und 443 sicher auch DNS Abfragen abschicken müssen und bräuchte mindestens auch ausgehend UDP 53, wie Zierleiste schon angemerkt hat und schneller war beim Fragen, warum so misstrauisch bei speziell apt :rolleyes:

    WH1000 SE OST22 OST23 OST24 | WH1000 SE ADV25 | WH 🥚🧶🥛🐖 | 🦆 VPS 200 🇺🇦🕊️ ➡️ VPS nano G11s

    Einmal editiert, zuletzt von Copro (19. Juli 2026 um 19:41) aus folgendem Grund: ufw / iptables also die serverseitige FW auch erwähnt.

    Ich habe keine Angst. Ich wollte nur mal fragen, wie ihr das handhabt. Des Weiteren war das mit apt nur ein Test, um mal die Firewall zu testen.

    Angst habe ich nicht, aber mal ein paar Tipps zu holen, spricht doch nichts dagegen. Und meine Erfahrung mitzuteilen steht mir doch auch frei.

    Zitat von Copro

    Warum willst du den Server ausgehend auf der netcup seitigen Firewall unbedingt einschränken. Speziell die Firewall sieht ja gar nicht mehr, dass es hier z.B. um apt geht und nicht um z.B. einen Shell Trojaner, den du dir eingefangen hast. Das geht zwar auch nicht mit iptables / ufw aber ich würde mich trotzdem nicht nur auf die netcup Firewall verlassen und im besten Fall beide Seiten sinnvoll konfigurieren.

    Natürlich geht das mit iptables/nftables? Einfach nach der UID filtern, gerade bei APT läuft dies i.d.R. im Hintergrund über einen eigenen User.

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

    Zitat von Copro

    Solange du nur ACCEPT Regeln hast und nicht wenigstens einen DROP ist alles erlaubt, bis auf die impliziten Regeln z.B. für SMTP von netcup selbst.
    Erst mit der ersten netcup Firewall Policy also Richtlinie, die auch was verbietet, wird automatisch auch der Rest auf nicht erlaubt gesetzt.

    Die implizite Regel wird auf DROP gesetzt, sobald man eine eigene Regel für die entsprechende Richtung hinzufügt - egal, ob die Regel ACCEPT oder DROP verwendet.

    So steht's in der Hilfe:

    Zitat

    Die impliziten Regeln können weder entfernt noch bearbeitet werden. Standardmäßig sind sie auf ACCEPT ANY eingestellt. Sobald du jedoch eine eigene eingehende Regel anlegst, ändert sich die implizite eingehende Regel automatisch auf DROP. Das gleiche Verhalten gilt für ausgehende Regeln. Hintergrund: Ohne diese automatische Umstellung würden trotz definierter Regeln weiterhin sämtliche Verbindungen erlaubt, sodass die Firewall-Regeln wirkungslos wären.

    Zitat von h725rk

    Wie habt ihr eure Firewall für ausgehenden Traffic konfiguriert?

    Ich versuche immer alles soweit wie möglich dicht zu machen. Daher habe ich je nach Server-Profil verschiedene Policies für ausgehenden Traffic.
    Beipiel: Alle Server dürfen die (IP-Adressen der) verwendeten Update-Mirror via HTTPS erreichen. Für andere HTTP(S)-Ziele gibt es bei Bedarf weitere Policies für einzelne Server.
    Der DNS-Port ist z. B. nur für meinen eigenen rekursiven DNS-Resolver für beliebige Zieladressen freigegeben. Andere Server benötigen diese Policy nicht und können den Port daher nicht anfunken bzw. nur für die konfigurierten DNS-Resolver (die von netcup können ja sowieso immer erreicht werden).