openvpn - iptables

  • Hey Leute, ich hatte gestern schon mal bzgl. DNS und iptables gefragt, dabei ging es aber nur um das droppen des Input. Wollte nun aber mal testweise den Server ganz dicht machen, also auch den Output kontrollieren. Config sihet derzeit so aus:


    Server läuft, zusätzliche Dienste laufen, VPN läuft, Pi-Hole läuft. Aber egal, ob ich Pi-Hole als DNS intern nutze, oder z.B. den google DNS, ... ich bekomme bei OpenVPN kein DNS Lookup :/

    Droppe ich hingegen nur den Input für den Port 53 und greife per VPN darauf zu,




    ... funktioniert alles ohne Probleme. Scheint also irgendwo am gedropten Output zu liegen. Wäre für jede Idee oder Anregung dankbar!

    Meine Produkte: definitiv zu viele, RS, VPS, Domains, Webhosting, ...

  • Bitte bringe die Regeln in die richtige Reihenfolge ("iptables -nvL"). Das Gewusel mit -A und -I ist unübersichtlich.


    Solltest du eine zustandslose Firewall einsetzen wollen, dann entferne bitte die Regel mit -m state. Connection Tracking (-m state) ohne Connection Tracking (NOTRACK) funktioniert nicht.


    Zitat

    ich bekomme bei OpenVPN kein DNS Lookup


    Du musst die eingehenden DNS-Pakete auch annehmen.

    Code
    #Allow inbound DNS replies
    iptables -A INPUT -p udp --sport 53 -j ACCEPT
    iptables -A INPUT -p tcp --sport 53 -j ACCEPT
  • Danke für die Antwort. Gebe ich damit nicht den Port 53 für alle frei? Also als public DNS? Ziel der Übung war ja gerade, den Zugang zum DNS auf den VPN zu beschränken.


    Bzw. Verstehe ich den Kommentar mit dem Rumgewusel nicht. Macht es eine großen Unterschied?


    Bzw muss ich mir wohl noch mal genauer mit iptables beschäftigen, die Regeln hier sind eher nen Copy&paste bzw. try&error.


    Was für eine Konfiguration macht auf nem VPS sinn? -m state unterscheide ich, ob die Verbindung neu aufgebaut wird, bereits besteht, etc.... ?

    Meine Produkte: definitiv zu viele, RS, VPS, Domains, Webhosting, ...

  • Du kannst eine Regel auch soweit einschränken, dass als source Port 53 nur dann akzeptiert wird, wenn die Pakete gleichzeitig an eine bestimmte IP gehen.


    Müsste dann so heißen:

    Code
    iptables -A INPUT -p tcp --sport 53 -d xx.xx.xx.xx -j ACCEPT
    iptables -A INPUT -p udp --sport 53 -d xx.xx.xx.xx -j ACCEPT

    Matthias Lohr Project Blog: https://mlohr.com/

    PGP: 0x8FC3060F80C31A0A

  • Also wäre es hierbei 127.0.0.1, oder die IP des VPN Client 10.8.0.0/8?


    Bzw. kann ich das nicht für das ganze interface freigeben, also tun0?

    Meine Produkte: definitiv zu viele, RS, VPS, Domains, Webhosting, ...

  • Gebe ich damit nicht den Port 53 für alle frei? Also als public DNS? Ziel der Übung war ja gerade, den Zugang zum DNS auf den VPN zu beschränken.

    Na ja, damit nimmt dein Server alle UDP- und TCP-Pakete an, die von Port 53 aus gesendet wurden. Wenn der (gefälschte) Quellport 53 und der Zielport auch 53 ist, dann nimmt der Server auch diese Pakete an. Dann ist dein Server darüber angreifbar. Nicht manipulierte DNS-Anfragen kommen aber nicht von einem Quellport 53.

    Bzw. Verstehe ich den Kommentar mit dem Rumgewusel nicht. Macht es eine großen Unterschied?

    -A hängt eine Regel an die bestehenden Regeln an, während -I (ohne Regelnummer) eine Regel ganz an den Anfang setzt und alle bestehenden Regeln nach hinten verschiebt. So steht bei dir "-m state" am Ende und dennoch ist es die erste Regel. Also benutze bitte entweder nur -A (das ist der Standard, siehe Ausgabe von iptables-save) oder nur -I (die Regeln muss man dann von unten nach oben lesen).

    -m state unterscheide ich, ob die Verbindung neu aufgebaut wird, bereits besteht, etc.... ?

    Bei einer zustandslosen Firewall gibt es keine Verbindungsverfolgung. Durch "-j NOTRACK" besitzen sämtliche Pakete den Zustand UNTRACKED. RTFM

    Würde es nicht reichen Port 53 auf dem tun interface zu erlauben?

    Ja, aber nur, wenn der Server nicht mit externen DNS-Servern kommunizieren muss. Antworten vom externen DNS-Server z. B. 8.8.8.8 werden oben in der ersten Konfiguration durch "iptables -P INPUT DROP" verworfen.

    Bzw. kann ich das nicht für das ganze interface freigeben, also tun0?

    Wie bitte? tun0 ist doch bereits freigegeben.

    Code
    # Allow everything from within the VPNiptables -I INPUT -i tun0 -j ACCEPTiptables -I OUTPUT -o tun0 -j ACCEPT

    Du kannst über VPN mit dem Server kommunizieren. Dein Problem ist, dass der Server nicht mit externen DNS-Servern kommunizieren kann.


    Was für eine Konfiguration macht auf nem VPS sinn?

    Eine zustandslose Firewall bedeutet mehr Aufwand. Entweder lässt du

    Code
    # Stateless firewalliptables -t raw -I PREROUTING -j NOTRACKiptables -t raw -I OUTPUT -j NOTRACK

    ganz weg oder du verfolgst ausnahmsweise Verbindungen über Port 53

    Code
    #Stateless firewall, but not for DNSiptables -t raw -A PREROUTING -p udp -m udp --sport 53 -j ACCEPTiptables -t raw -A PREROUTING -p tcp -m tcp --sport 53 -j ACCEPTiptables -t raw -A PREROUTING -j NOTRACKiptables -t raw -A OUTPUT -p udp -m udp --dport 53 -j ACCEPTiptables -t raw -A OUTPUT -p tcp -m tcp --dport 53 -j ACCEPTiptables -t raw -A OUTPUT -j NOTRACK

    , dann funktioniert die "-m state"-Regel für die Verbindungen mit externen DNS-Servern.


    Wenn du aus welchen Gründen auch immer auf eine zustandslose Firewall (-j NOTRACK) bestehst, kannst du die Verbindungen mit externen DNS-Servern etwas umständlich mit "-m recent" verfolgen.

  • *grrr* Die Code-Formatierung ist durch die tolle Forumsoftware zerstört worden. (Nur ein formatierter Code pro Beitrag ist erlaubt?!)


    Eine zustandslose Firewall bedeutet mehr Aufwand. Entweder lässt du

    Zitat

    # Stateless firewall

    iptables -t raw -I PREROUTING -j NOTRACK

    iptables -t raw -I OUTPUT -j NOTRACK

    ganz weg oder du verfolgst ausnahmsweise Verbindungen über Port 53

    Code
    #Stateless firewall, but not for DNS
    iptables -t raw -A PREROUTING -p udp -m udp --sport 53 -j ACCEPT
    iptables -t raw -A PREROUTING -p tcp -m tcp --sport 53 -j ACCEPT
    iptables -t raw -A PREROUTING -j NOTRACK
    iptables -t raw -A OUTPUT -p udp -m udp --dport 53 -j ACCEPT
    iptables -t raw -A OUTPUT -p tcp -m tcp --dport 53 -j ACCEPT
    iptables -t raw -A OUTPUT -j NOTRACK

    , dann funktioniert die "-m state"-Regel für die Verbindungen mit externen DNS-Servern.

  • wow! Vielen lieben Dank für die ausführliche Antwort und Erklärungen!


    Ich bin wohl dem Irrglauben erlegen, dass ne stateless Firewall einfacher zu managen ist. Gerade weil nur ne Hand voll Ports auf dem VPS benötigt werden. Anscheinend ist ne statefull aber doch einfacher zu managen.


    Hast du zufällig nen Link zu nem passenden Tutorium parat? Bei google bin ich über 10 verschieden Tutorials gestolpert, die alle von sich behaupten das Bestw zu sein, ... aber sich grundlegend unterscheiden ?


    Hab mich nämlich bist jetzt, außer mit dem manuellen bannen von IPs und fail2ban, nicht wirklich mit iptables beschäftigt. Dachte aber es wäre mal an der Zeit, da ich nen DNS auf dem Server laufen lassen wollte, aber keine Lust habe, dass mein Server für Angriffe missbraucht wird. Da erschien mir fürs erste Sinnig, den DNS nur via VPN erreichbar zu machen.


    Nach der ersten Recherche lässt sich mit ner statefull firewall wohl aber auch nen public DNS gut absichern.


    Man lernt nie aus ?

    Meine Produkte: definitiv zu viele, RS, VPS, Domains, Webhosting, ...

  • Bevor du dich jetzt auf iptables stürzt, solltest du wissen, dass es mit nftables bereits einen Nachfolger gibt. https://wiki.nftables.org/wiki…x.php/What_is_nftables%3F

    Ist mir vorhin auch über den Weg gelaufen. Vielen Dank für den Input! Werde mich da mal am Wochenende durchwühlen. Vielleicht bekomme ich ja damit unkompliziert nen public DNS abgesichter ?

    Meine Produkte: definitiv zu viele, RS, VPS, Domains, Webhosting, ...

  • ich häng mich mal hier mit rein, habe openvpn auf meinen CentOS-Server laufen, mein Desktop macht damit auch anstandslos alles.

    Nu hab ich mein Handy mit ins Spiel bringen wollen, alles hübsch eingerichtet, Openvpn-Verbindung wird auch artig aufgebaut, aber es scheint kein Traffic darüber zu laufen. Ich nutze tatsächlich den firewalld und hab ne extra "Homezone" eingerichtet, in der eben auch mein Desktop hängt. Deshalb wundert mich das jetzt schon n bisschen. Fehler sind im Log nirgendwo auszumachen.