storagespace - nfs - Port 111

  • Habe eben gerade für einen Server (anderer Anbieter) die übliche Mitteilung von CERT weitergeleitet bekommen, dass Port 111 (nfs) offen wäre.

    Ja, klar, da war die Firewall unten und nfs lief. So weit so gut und nachvollziehbar.


    Aber wieso läuft mein, über nfs eingebundener Storagespace überhaupt auf meinen netcup-Servern, obwohl ich dort Port 111 gar nicht freigegeben habe?

    Wenn ich von außen scanne ist der zu, denn ich hatte völlig vergessen ihn in ufw freizugeben, nachdem ich nfs-common installiert hatte.

    Wieso kann ich trotzdem meinen Storagespace einbinden und mit ihm arbeiten? Verwechsle ich da was?

  • Port 111 ist nicht nfs, sondern der RPC Portmapper, wird allerdings idR für nfs benötigt. Ich nehme an, dass Port 111 auf dem Storagespace offen ist und es daher funktioniert.

    Gruss

  • Wieso kann ich trotzdem meinen Storagespace einbinden und mit ihm arbeiten?

    Weil du ausgehenden Verkehr hast, wenn du mit den Storagespace kommunizierst.

    Der eingehende Verkehr wird wahrscheinlich durch eine "established/related" Regel in deiner Input-Chain erlaubt.

    Soll heißen: Verkehr, der zu einer bestehenden Verbindung gehört ist erlaubt.


    Das sind aber nur Mutmaßungen von mir, da ich deine Firewall Einstellungen nicht kenne (und auch mit nfs nicht so fit bin)

    Meine (Netcup) Produkte: S 1000 G7, VPS 200 G8 Ostern 2019, IPs, Failover..

  • Danke für die Antworten!. Jetzt sehe ich ein wenig klarer

    Port 111 ist nicht nfs, sondern der RPC Portmapper, wird allerdings idR für nfs benötigt.

    Ja, das ist richtig. Habe ich verkürzt dargestellt.

    Ich nehme an, dass Port 111 auf dem Storagespace offen ist und es daher funktioniert.

    Weil du ausgehenden Verkehr hast, wenn du mit den Storagespace kommunizierst.

    Das macht Sinn. Port 111 ist ja auf meinem Client eh offen (weil ich alles raus erlaube) und wenn es auf dem Storagespace-Server eingehend offen ist, klappt es ja prinzipiell schon mal in diese Richtung.

    Der eingehende Verkehr wird wahrscheinlich durch eine "established/related" Regel in deiner Input-Chain erlaubt.

    Soll heißen: Verkehr, der zu einer bestehenden Verbindung gehört ist erlaubt.

    Das sind aber nur Mutmaßungen von mir, da ich deine Firewall Einstellungen nicht kenne...

    Das könnte sein, aber wenn man es genau nimmt, kenne ich meine Firewall-Einstellungen auch nicht genau.

    Denn ich habe mich um eine intensivere Auseinandersetzung mit iptables bisher immer herumgedrückt und das ufw überlassen. ;)

    Wie macht ufw das? Wenn ich über einen Port rausgehe, wird dann automatisch der eingehende Verkehr zu dieser bestehenden Verbindung erlaubt?


    Wobei ich mich nun frage: Braucht es überhaupt eine Freigabe für eingehenden Verkehr auf Port 111 (und 2049 für nfs selbst) in diesem Fall?

  • Wobei ich mich nun frage: Braucht es überhaupt eine Freigabe für eingehenden Verkehr auf Port 111 (und 2049 für nfs selbst) in diesem Fall?

    Wenn du eine Related/Established Regel hast, brauchst du nur eingehende Regeln für Dienste, die du selbst auf dem Server hostest. (SSH, WWW, ...).



    Prüfen kannst du das mit

    Code
    iptables --list --numeric

    Recht weit oben in der INPUT Chain müsste dann folgendes stehen:

    Code
    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED


    Sich mit seinen Firewall regeln zu beschäftigen macht schon sinn :D

    Meine (Netcup) Produkte: S 1000 G7, VPS 200 G8 Ostern 2019, IPs, Failover..

  • Recht weit oben in der INPUT Chain müsste dann folgendes stehen:

    Code
    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED

    Ja, in drei chains (ufw-before-forward, ufw-before-input, ufw-before-output) taucht "ACCEPT ... ctstate RELATED,ESTABLISHED" auf.

    ufw macht das wohl standardmäßig. Gut zu wissen.

    Sich mit seinen Firewall regeln zu beschäftigen macht schon sinn :D

    Da gebe ich dir durchaus recht. Aber jedesmal wenn ich mir die iptables ansehe, finde ich recht schnell wieder einen Grund etwas anderes tun zu müssen, was ja viel wichtiger ist. :whistling:


    (btw. Nix gegen netcup, im Gegenteil, ich bin sehr zufrieden hier, aber die vorgeschaltete externe Firewall, die ich bei einem Server woanders habe, ist schon nicht schlecht. Da muss ich mir dann auch keine Gedanken darum machen, dass evtl. ein gehosteter docker-container ohne mein Zutun in den iptables rumpfuscht.)

  • ufw macht das wohl standardmäßig. Gut zu wissen.

    Dann kannst du ja mal die (wahrscheinlich) unnötigen Regeln entfernen und schauen, ob dann immer noch alles funktioniert :D



    Aber jedesmal wenn ich mir die iptables ansehe, finde ich recht schnell wieder einen Grund etwas anderes tun zu müssen

    Ich wusste anfangs nicht, dass es "was anderes" gibt.. so hab ich meinen Einstieg in iptables gefunden :D



    ein gehosteter docker-container ohne mein Zutun in den iptables rumpfuscht

    Das ist auch mein größter Kritikpunkt an Docker :rolleyes:

    Mein einziger docker-compose zusammenschluss läuft deswegen in einer VM auf meinem eigenen Trägersystem. Und da kontrolliere ich das eben über die Firewall des Trägersystems..

    Wie man das auf einem Standalone-Host gut regelt, weiß ich auch noch nicht.


    Netcup gibt dir ja nur grundlegende Werkzeuge. Sowas wie externe Firewall KANN man damit auch bauen.. wenn man es KANN und WILL.

    Meine (Netcup) Produkte: S 1000 G7, VPS 200 G8 Ostern 2019, IPs, Failover..