Beiträge von hoedlmoser

    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.

    503

    ok, das ist Service Unavailable und klingt nach sperre.

    aber gut daß Du noch ins CCP reinkommst! wie gesagt, oben in der zierzeile neben Deinem namen in klammern steht die kundennummer. bzw auch auf den im CCP als pdf abgelegten rechnungen.

    ich hab leider selbst kein webhosting und gar keine erfahrung mit gesperrten produkten, aber nachdem das netcup antwortversprechen schon längst abgelaufen ist würde ich Dir wirklich raten die hotline zu bemühen.

    Du könntest Dich noch im WCP umsehen, ob da irgend etwas auffällig ist bzw ob die einstellungen Deinen erwartungen entsprechen.

    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.

    Es geht gar nichts mehr.

    sagt meine oma auch immer. auf meine erwiderung sie hätte das internet gelöscht wird sie ganz traurig.

    ich komme nicht an den Speicherplatz ran

    genaue fehlermeldung? kannst Du Dich überhaupt ins CCP einloggen? und welches authentifizierungsverfahren hast Du dort in verwendung?

    Ist eine Adresse bei web.de

    ich vermute mal die hast Du im kontaktformular auf https://helpcenter.netcup.com/de/support verwendet. aber in den stammdaten im CCP hast Du eine adresse Deines webhostings hinterlegt. aus der erfahrung hier verwendet netcup nicht die mailadresse aus dem kontaktformular sondern die aus den stammdaten.

    habe meine Kundennummer nicht

    wie hast Du dann überhaupt ein ticket geöffnet? im kontaktformular ist die mandatory und im CCP stehts oben in der zierzeile.

    Ich finde den vorkonfigurierten Mail-Block völlig in Ordnung. Hey. Wir sind alle Serveradmins, da werden wir ja noch ne Firewall konfigurieren können, wenn wir explizit Mailserver betreiben wollen. Wer das ohnehin nicht will, fährt mit dem Block nicht verkehrt.

    eh, nur geht halt von Submission und SMTPS genau keine gefahr aus, also warum blocken? und wenn dann wer mails über einen MTA über die genannten protokolle versenden will nimmt er die ganze policy raus und hoppla ist der schutz von ungewollt ausgehenden SMTP futsch. mehr als suboptimal so!

    Der HelpCenter-Artikel mit einem Überblick,

    Zitat
    Beachte, dass die Aktion REJECT (Verwerfen des Traffics und Rückmeldung an den Absender) nicht unterstützt wird. Implementiere für erweiterte Funktionen wie diese eine eigene Firewall-Lösung.

    kein reject, schade. aber gibts bei H3tzn3r auch nicht.

    Zitat

    Beispiel 1: SSH erlauben

    INGRESS, TCP, destination port 22, accept

    EGRESS, TCP, source port 22, accept (Definiere EGRESS nur, wenn du auch extra EGRESS Regeln für Client-Traffic konfiguriert hast, sonst wird dieser Traffic blockiert (siehe Beispiel 5)).

    falsch! auch bei EGRESS ist für ssh der destination port 22. da ist hier ja schon jemand im thread drübergestolpert. ;)

    selber fehler in 'Beispiel 2' und 'Beispiel 4'. in 'Beispiel 5' wirds dann hingegen richtig dargestellt.

    Port 25 (SMTP) standardmäßig blockiert

    nein, ihr habt da leider mehr blockiert:

    voreingestellt

    hier noch zusätzlich SMTPS und Submission zu blockieren, die beide auf client-authentifizierung basieren, finde ich gefährlich! denn will der kunde als MUA mails loswerden wird er da drüberstolpern und die ganze policy deaktivieren. somit ist er (bzw das ganze netz) wieder durch unkontrollierten ausgehenden verkehr auf dem SMTP port ungeschützt.

    Zeile im Bild in #16 darf nur @ oder den Hostnamen mail enthalten

    nein, "oder" ist da zu hart. wenn er sich für eine sende-domain entschieden hat gehört da drann der TXT/SPF eintrag. ist es die registrierte domain selbst, dann eben @, ist es hingegen eine subdomain oder ein hostname dann eben zb nur "mail".

    wie in meiner erinnerung weiter oben angeführt würde ich beides empfehlen.

    aktuell sehen Deine SPF und MX einträge wie folgt aus.

    pasted-from-clipboard.png

    ich kann mich nur den vorrednern anschließen: such Dir eine mail-domain und da gehören dann mit @ die SPF/TXT und MX einträge drann.

    edit: ich sehe gerade, in meinem mailcow setup habe ich auch auf dem hostnamen vom mailcow-server selbst noch einen SPF eintrag draufkleben (aber keinen MX) und ich weiß aber nicht mehr warum, ich kann mich nur mehr erinnern, daß es einen guten grund hatte.

    edit2: jetzt kann ich mich wieder erinnern: https://docs.mailcow.email/de/post_instal…og_and_bounces/

    Es muss durch den loop gewesen sein, da die Auflösung nicht richtig funktioniert hat.

    Du meinst weil sich die mailcow selbst den MX nicht auflösen hat können hat sie den SMTP port nicht beantwortet bzw ist der postfix nicht gestartet? Dein netstat hat ja nur die docker-proxies am host gezeigt. und den nmap hast ja auf die IP gemacht.

    wann hast Du denn die loop korrigiert? die Zierleiste hat ja gestern schon um 23:07 berichtet, daß sie den SMTP port offen sieht.