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

    Zitat von -Manu-
    1. Haue ich eine Policy "TEST" mit Regelsatz X rein....übernimmt er das.
    2. Modifiziere ich nun die Policy "TEST"....geht erstmal augenscheinlich nur die letzte hinzugefügte Regel, aber der Rest nicht (mehr).
    3. Werfe ich die komplette Policy "TEST" raus, füge nun nochmals alle Regeln inklusive der zusätzlichen aus 2......geht alles

    Ich habe das mal nachgestellt und kann es nicht reproduzieren. Bei mir läuft es einwandfrei, wenn ich eine weitere Regel zur Policy hinzufüge. Alle anderen Regeln werden weiterhin beachtet. Raus und wieder rein ist nicht nötig.

    Zitat von Gojira

    Auf meinem ARM G11 VPS konnte ich das auch gerade "aktivieren". Es funktioniert halt nicht. Wie bekomme ich das wieder weg?:)

    Bedeutet dies jetzt, dass die Firewall zwar aktiviert ist bei all meinen VPS, sie aber nicht geht?

    Hatte mich schon gewundert warum es mir angezeigt wurde.

    Aktuell konnte ich es bei

    - VPS 1000 ARM G11 SE NUE BSS24
    - RS 2000 G11 iv
    - RS 2000 G11 SE NUE TTF24
    - VPS 500 ARM G11 OST25

    aktivieren.

    Bei meinen Picos und einem RS G9 ging es nicht. Dort wird die Option nicht angeboten.

    Ohne jetzt da viel gespielt zu haben. DNS ging nicht mehr. Musste dann die Regel anlegen. Ging danach alles wie es soll.

    Beschreibung Typ Aktion Protokoll Source(s) (IPs / Netzwerke) Source Port(s) Destination(s) (IPs / Netzwerke) Destination Port(s)
    DNS EINGEHEND ACCEPT UDP * 53 * 1000-65535

    Mir ist noch aufgefallen, dass in den Protokollen zur Firewall nichts steht.

    Zitat von Knight

    Ohne jetzt da viel gespielt zu haben. DNS ging nicht mehr. Musste dann die Regel anlegen. Ging danach alles wie es soll.

    Beschreibung Typ Aktion Protokoll Source(s) (IPs / Netzwerke) Source Port(s) Destination(s) (IPs / Netzwerke) Destination Port(s)
    DNS EINGEHEND ACCEPT UDP * 53 * 1000-65535

    Mir ist noch aufgefallen, dass in den Protokollen zur Firewall nichts steht.

    Was benutzen deine Server für einen DNS?

    Die von Netcup oder externe?

    Dass die Firewall bei UDP nicht stateful ist, finde ich nicht ganz so optimal. So muss man wirklich darauf achten, für alle Dienste, die eventuell UDP-Anfragen raussenden, auch INGRESS-Regeln anzulegen. Neben DNS fällt mir da z.B. noch NTP ein.

    Dieses Gebäude hat mir die Vorfahrt genommen! *hup*

    Mal zum Verständnis.

    Wenn ich ausgehende Regeln festlegen, dann muss ich bei Sourceport den eigentlichen Port festlegen und bei eingehend den Destinationport. Z. B Bei eingehend nur den Destinationport 80 und Sourceport ist * gehen generell alle Anfragen von außen an 80.

    Wenn ich jetzt, z. B. bei Eingehend den Destinationport auf 8080 setze und den Sourceport auf 80, dann wird der Außenport auf den internen Port 8080 weitergeleitet. Denk ich so richtig?

    Wenn ich eine IP festlegen zum Port 80, dann dürfen nur von dieser IP Anfragen an den Port 80 gesendet werden dürfen.

    Ich möchte das nur verstehen, weil ich noch die GW-Regeln für einen Mailserver einrichten muss.

    Zitat von h725rk

    Wenn ich jetzt, z. B. bei Eingehend den Destinationport auf 8080 setze und den Sourceport auf 80, dann wird der Außenport auf den internen Port 8080 weitergeleitet. Denk ich so richtig?

    Nein, du verwechselt das mit port forwarding. Wenn du einen Dienst auf Port 80 lauschen hast und möchtest, dass dieser von außen erreichbar ist, dann muss der Destinationport auf 80 stehen und im Sourceport am besten ANY. Von welchen Ports sich die Clients zu dir verbinden, ist nämlich sehr unterschiedlich. Siehe ephemeral port.

    Dieses Gebäude hat mir die Vorfahrt genommen! *hup*

    Zitat von Knight
    Beschreibung Typ Aktion Protokoll Source(s) (IPs / Netzwerke) Source Port(s) Destination(s) (IPs / Netzwerke) Destination Port(s)
    DNS EINGEHEND ACCEPT UDP * 53 * 1000-65535

    Danke, über das Problem mit DNS bin ich auch gestolpert. Ein ähnliches Problem gibt es auch bei der Nutzung eines cloudflare tunnels (also cloudflared) mit quic. Da kommen die UDP-Pakete von Port 7844 (siehe Tunnel with firewall) und müssen explizit zugelassen werden.

    wieso nehmt ihr alle einen so komischen portrange für die ephemeral ports? auf einem Linux ist der nur 32768 - 60999 bzw kann man das mit

    Code
    cat /proc/sys/net/ipv4/ip_local_port_range

    nachsehen. alles andere ermöglicht einem beliebigen "angreifer" eure UDP-services oberhalb von port 1000 zu nutzen.

    also ich befürchte, auch wenn firewall-regeln keine raketenwissenschaft ist, daß manche hier eine sehr steile lernkurve haben. noch dazu wenn die firewall state-less ist.

    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

    Dieses Gebäude hat mir die Vorfahrt genommen! *hup*

    Ich habe jetzt mal die Mailcow Regeln erstellt und wollte gerne diskutieren, ob noch was fehlt.

    Zwei Sachen vorweg.

    Mein Mailserver reagiert nur auf Security Ports, also POP3, IMAPS, etc.

    DNS-Server zur Auflösung sind die IPv4- und IPv6-Dns-Server von Netcup.

    Die Ports habe ich nach der offiziellen Dokumentation gebaut

    https://docs.mailcow.email/de/getstarted/prerequisite-system/#eingehende-ports

    https://docs.mailcow.email/de/getstarted/prerequisite-system/#ausgehende-portshosts

    Was meint ihr? Was fehlt?

    Am Ende wurde ich dies gerne an alle als JSON-Regel zur Verfügung stellen, damit dies einfach per API hinzugefügt werden kann.