Beiträge von h725rk

Hallo,

ich versuche gerade bei meinem Mailserver (Mailcow) die Firewall umzusetzen.
Ich habe mir die Anleitung von Mailcow zum Thema Firewall angeschaut und hänge aktuell bei einem Problem:
TCP-Einstellungen für konkurrierende Firewall

Leider gibt es nur eine Anleitung für die Konkurrenz, aber ja auch für Netcup gelten.

Bei den TCP-Einstellungen muss Inbound die Ports 1024-65535 mit dem TCP-Flag ack freigegeben.
Bei der Firewall der Konkurrenz, kann ich den TCP-Flag setzen, bei Netcup nicht.
Ich verstehe es jetzt so, wenn ich die Firewall bei netcup mit den TCP-Einstellungen einstelle, dann gebe ich alle Ports Inbound von 1024-65535 mit allen TCP-Flags frei.
Gibt es eine Möglichkeit, dass ich bei der Netcup Firewall nur den TCP-Flag ack freigeben kann?

Den Rest der Einstellungen verstehe ich und kann das auch so umsetzen, nur diesen einen kleinen Abschnitt mit den TCP-Einstellungen nicht.
Wie habt ihr das gelöst, die Mailcow im Einsatz haben?

Schönen Tag,
Rob

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.

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

Das ist eins meiner größten Proboeme gewesen. Bin mit dem DNS auf Cloudflare gewechselt. Musste irgendwann 10min warten für ein Zertifikat.

Größter Vorteil, Let's Encrypt Zertifikate werden innerhalb von 30 Sekunden ausgestellt.

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

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?

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

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 frank_m

Icb kenne die netcup Firewall noch nicht so genau, aber meines Erachtens sind in den Regeln mehrere Dinge falsch.

Inbound:

Hier sollte eine konkrete Zieladresse stehen. Auch wenn man Netzwerke angeben kann: Der Server lauscht ja nur auf einer IP, oder?

Outbound:

Das ist Unsinn: eine Portnummer bei der IP-Adresse. Hier sollte wieder die konkrete Adresse des Servers rein.

Bevor du auf die Idee kommst, hier den offenen UDP-Port von Wireguard einzutragen: Nur weil der Port eingehend offen ist, heißt das noch lange nicht, dass auch die ausgehenden Pakete von diesem Port kommen. Von daher ist "*" vermutlich richtig.

Alles anzeigen

Ich habe das ganze nochmal angepasst:

Beschreibung: Wireguard Inbound IPv4

Typ: EINGEHEND

Aktion: ACCEPT

Protokoll: UDP

Source(s) (IPs / Netzwerke): *

Source Port(s): *

Destination(s) (IPs / Netzwerke): <IPv4-Server>

Destination Port(s): <Port-Wireguard>

Beschreibung: Wireguard Inbound IPv6

Typ: EINGEHEND

Aktion: ACCEPT

Protokoll: UDP

Source(s) (IPs / Netzwerke): *

Source Port(s): *

Destination(s) (IPs / Netzwerke): <IPv6-Server>

Destination Port(s): <Port-Wireguard>

Beschreibung: Wireguard Outbound IPv4

Typ: AUSGEHEND

Aktion: ACCEPT

Protokoll: UDP

Source(s) (IPs / Netzwerke): <IPv4-Server>

Source Port(s): <Port-Wireguard>

Destination(s) (IPs / Netzwerke): *

Destination Port(s): 1024-65535

Beschreibung: Wireguard Outbound IPv6

Typ: AUSGEHEND

Aktion: ACCEPT

Protokoll: UDP

Source(s) (IPs / Netzwerke): <IPv6-Server>

Source Port(s): <Port-Wireguard>

Destination(s) (IPs / Netzwerke): *

Destination Port(s): 1024-65535

Funktioniert mit diesen Einstellungen.

OK, verstanden.
Folgende Regeln habe ich nun festgelegt:

Beschreibung: Wireguard Inbound

Typ: EINGEHEND

Aktion: ACCEPT

Protokoll: UDP

Source(s) (IPs / Netzwerke): *

Source Port(s): *

Destination(s) (IPs / Netzwerke): *

Destination Port(s): 64831

Beschreibung: Wireguard Outbound

Typ: AUSGEHEND

Aktion: ACCEPT

Protokoll: UDP

Source(s) (IPs / Netzwerke): *

Source Port(s): 64831

Destination(s) (IPs / Netzwerke): *

Destination Port(s): 1024-65535

Habe auch ICMP und ICMPv6 freigeschalten. Funktioniert trotzdem nicht. Ich schaue mal weiter.
/edit:
Geht jetzt. War wohl schneller als die Firewall.

Moin,

ich sitze gerade an den Firewallfreigabe für Wireguard und bei mir wird die Firewall nicht freigegeben.
Hier meine Einstellungen:

Beschreibung: Wireguard

Typ: EINGEHEND

Aktion: ACCEPT

Protokoll: UDP

Source(s) (IPs / Netzwerke): *

Source Port(s): *

Destination(s) (IPs / Netzwerke): *

Destination Port(s): 64831

Wenn ich die Defaulteinstellungen der Firewall benutze, dann funktioniert meine Wireguard-Verbindung.
Ist es bei euch genauso?`

Schönen Sonntag,
Rob

Ich schaue es mir erst Wochenende an. Vorher kann ich es nicht testen.

Zitat von -Manu-

Gem. Anlage würde das bspw. bei mir so aussehen...mit dem genannten Verhalten.

Absolut simpelst. Es werden eingehend nur die eingetragenen Kommunikationsbeziehungen zugelassen, ausgehend ist alles erlaubt.

Screenshot 2025-12-14 12.22.17.png

EDIT: Und außer den genannten, eingehend Regeln erwarte ich keinerlei andere, eingehende Anfragen an das System.
Und wenn ich mit diesem simpelsten Regelwerk *random* dann nicht einmal mehr per SSH auf den Server komme....kann mMn ja irgendwas nicht stimmen.

Genau das gleiche Bild habe ich auch.

Spannend bei dir zu sehen ist, das deine implizierte Regel für "Ausgehend" auf Accept steht. Sobald ich eine eigene Regel hinzufüge, wird diese auf Drop gesetzt.

Also ich habe es nochmal getestet.

Die Regeln werden mal angewendet, mal nicht. Und wenn die nicht angewendet werden, steht alles. SSH, WebServer und auch Wireguard.

Ich werde die FW erstmal auf Durchzug schalten und mir das später nochmal anschauen.

/Edit:

Ich habe auch eine Regel, vor den Implizierten erstellt, dass diese nach Außen TCP und UDP freigeben soll. Geht mal oder mal nicht.

Ja, verstehe ich. Aber wenn ich den Traffic generell nach außen öffnen würde, dann müsste man extra eine Regel erstellen, die vor den implizierten Regeln greift.

Ich habe mich gestern auch gewundert, warum die implizierten Regel nach außen von allow zu Drop gewechselt ist.

Nagut, FW geht nicht, aber ich denke, da liegt noch ein Problem in der Firewall.
Sobald ich die meine Regeln einstelle, funktioniert dies 5 Minuten, danach wird alle geschlossen und ich kann nichts mehr machen.
Ich muss dann die Default FW-Regeln aktivieren.

Hallo,

die Mailregeln habe ich noch nicht Testen können, aber ich habe mal eine Verständnisfrage, warum muss ich Wireguard so freigeben?

chrome_wqNCZ1LkmI.png

Somit wird der Traffic durchgelassen. Die ephemeral ports werden gar nicht beachtet. Wenn ich nur die ephemeral port statt 1024-65535, funktioniert auch keine Verbindung.

Wie unsicher ist es, wenn ich es so freigebe?

Edit: Merke gerade, dass bei meinem Mailserver die Firewall noch nicht konfiguirbar ist.
Auf meinem zweiten Server habe ich eine Webserver, Wireguard und SSH freigegeben, dass funktioniert gut. Ich habe auch schon eine Rückmeldung zum Thema Mailcow bekommen und die Ports sehen gut aus.

Ich habe die Freigabe für UDP gelöscht, aber sollte die nun offen sein?

ICMP würde ich noch mit einpflegen, aber das sollte jeder machen wie er es möchte.

Zitat von hoedlmoser

sieht gut aus. die "alles offen" ausgehend brauchst imho nicht, solange Du keine ausgehende regel hast sollte die dazugehörige implizite regele eh auf accept stehen. bin schon neugierig auf Deine erfahrungen mit diesem regelwerk.

wireguard benutzt ephemeral ports.

Ich teste es mal. Aber da ein paar Feature ausgehende Verbindung benötigen, würde ich das trotzdem ausprobieren.

Somit muss ich nur noch 53 TCP entfernen und dann sollte alles funktionieren. Ich teste das ganze am Wochenende.

Screenshot_2025-12-12-11-13-24-04_40deb401b9ffe8e1df2f1cc5ba480b12.jpg

Jetzt kommt das nächste Wireguard, aber mit diesen Erfahrungen aus Mailcow, sollte ich es schaffen.

Zitat von hoedlmoser

ganz genau, es ging um UDP, denn bei TCP muß man dank state-full firewall ja nicht die ports >= 1024 aufmachen.

und bitte entweder mit sudo oder mit dem parameter -e damit man auch gleich die prozesse sieht die da lauschen.

Mit sudo die gleiche Ausgabe

Hier noch die ephemeral Ports bei Debian

 cat /proc/sys/net/ipv4/ip_local_port_range
32768   60999