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

    Ich bin euch noch einen Auszug meines Mailcow-Server schuldig:

    Ich habs dann mit ss gemacht

    Ss -ulpn

    Code
    State                          Recv-Q                         Send-Q                                                 Local Address:Port                                                  Peer Address:Port                        Process
UNCONN                         0                              0                                                            0.0.0.0:64831                                                      0.0.0.0:*
UNCONN                         0                              0                                                               [::]:64831                                                         [::]:*

    /Edit: Mein Fehler, habe nun die UDP Verbindungen anzeigen lassen.

    Einmal editiert, zuletzt von h725rk (12. Dezember 2025 um 09:46)

    aber im speziellen für mailcow (und auch sonst was man so in container laufen hat) und allgemein würde ich persönlich folgendes setup empfehlen:

    alles was man nicht exponieren will bindet man auf localhost. sieht in der mailcow.conf dann zb so aus:

    Code
    HTTP_BIND=127.0.0.1
HTTPS_BIND=127.0.0.1
POP_PORT=127.0.0.1:110
POPS_PORT=127.0.0.1:995
DOVEADM_PORT=127.0.0.1:19991
SQL_PORT=127.0.0.1:13306
REDIS_PORT=127.0.0.1:7654

    oder für eine nextcloud-aio in der compose.yaml:

    Code
        ports:
      - 127.0.0.1:8047:8080
    environment: 
      APACHE_IP_BINDING: 127.0.0.1

    oder für einen lokalen unbound als resolver in unbound.conf.d/local.conf

    Code
    server:
  interface: ::1

    das ist bei docker sowieso von nöten wenn man zb als firewall ufw verwenden will, denn das docker gedöns greift schon in der nat table und somit vor ufw.

    denn prinzipiell gilt: mach dein system so sicher, daß es keiner firewall bedarf.

    und fürn lokalen rest dann halt zb die eben erwähnte ufw (ich hab hier am host einen nginx für tls-offloading laufen).

    Code
    root@guru:~# ufw status
Status: active

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere                  
80/tcp                     ALLOW       Anywhere                  
443/tcp                    ALLOW       Anywhere

    (IPv6 sieht genauso aus)

    Zitat von h725rk

    Ss -ulpn

    sieht gut aus, das pärchen auf diesen high ports habe ich auch. bei mir noch zusätzlich ein unbound.

    Code
    root@guru:~# ss -ulpen
Failed to open cgroup2 by ID
Failed to open cgroup2 by ID
State  Recv-Q Send-Q   Local Address:Port    Peer Address:Port Process                                             
UNCONN 0      0              0.0.0.0:44746        0.0.0.0:*     ino:15258 sk:1 cgroup:unreachable:ccd <->          
UNCONN 0      0                 [::]:44746           [::]:*     ino:15259 sk:2 cgroup:unreachable:ccd v6only:1 <-> 
UNCONN 0      0                [::1]:53              [::]:*     users:(("unbound",pid=951,fd=3)) ino:15195 sk:3 cgroup:/system.slice/unbound.service v6only:1 <->
root@guru:~#
    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.

    Hallo!

    Frage: Ist es ggf. möglich, die Firewall über den Support deaktivieren zu lassen?

    Ich habe in der FAQ gelesen, dass eine Deaktivierung nicht mgl. ist. Durch die aktuelle Limitierung – bspw. permanente "Implizite Regeln", kein Protokoll "ANY" für mich, für UDP unbrauchbar, keine API (und somit doppelte Administration, wenn sich im OS etwas ändert) … – würde ich die Firewall gern wieder auf OS-Basis (per Software) machen.

    Danke vorab, auch für das eig. ganz gute Feature und Grüße!

    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.

    Einmal editiert, zuletzt von h725rk (13. Dezember 2025 um 21:14)

    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.

    Einmal editiert, zuletzt von h725rk (13. Dezember 2025 um 22:43)

    Kann mir mal jemand erklären, warum ich mich bei der Config vom SSH Zugriff aussperre? Die Firewall fühlt sich unzuverlässig an und ich fühle mich als Betatester.


    Edit: Etwas hier lesen zeigt, wir sind zahlende Betatester. Besten Dank Netcup, auf 3-4 Wochen wäre es nach all den Jahren auch nicht mehr angekommen!