[Linux Terminal] VPN Disconnect Leakage Prevention

kaugummi

Junior Member
Hallo,

wie schuetzt ihr euch unter linux vor VPN Disconnect Leakages, wenn ihr mit mit dem Terminal und OpenVPN die Verbindung initiert. Ich habe da einen Guide gefunden der mit "gufw" arbeitet.
http://ubuntuforums.org/showthread.php?t=1496473

Leider funkzioniert die Methode bei mir nicht. Muss man hier vielleicht etwas anderes noch beachten? Ich frage mich zum Beispiel, ob die DNS anfragen nicht auch mit Regeln belegt werden muessten, Aber eigentlich muessten diese ja getunnelt werden (in meinen Augen macht dies auch von der Sicherheit her ja schon Sinn).
 
Die DNS Anfragen werden ja auch getunnelt solange du nicht deinen Router als DNS Server nutzt. Ansonsten hast du unter Linux die iptables mit denen du sämtliche Ports mit Ausnahme der VPN Ports und des DNS Ports blocken kannst.
 
ich komme nur durch das Uninetz rein. ich hab mich mit VPN connected die ip bekommen, die im netz auf myIP seiten gezeigt wird und habe dann alles in ufw abgelehnt, ausser alles was von der ip kommt und als zweite regel alles was von der ip rausgeht auf beliebig.

leider klappt mit den regeln kein VPN mehr. Es sieht mir so aus als ob selbst die DNS Anfrage nichtmal klappt wenn ich z.b. die ip sehen will.

mache ich nen Denkfehler irgendwo?
 
Das waere meine aktuelle iptables, wenn ich den Guide oben richtig verstehe (die IP waere jetzt zur Illustration der Russland Server, von dem ich die unten angegebene IP als shownIP im Netz angezeigt bekomme)

Code:
Chain INPUT (policy ACCEPT)
target  prot opt source  destination  
ACCEPT  all  --  anywhere  192.162.100.241  
DROP  all  --  anywhere  anywhere  

Chain FORWARD (policy ACCEPT)
target  prot opt source  destination  

Chain OUTPUT (policy ACCEPT)
target  prot opt source  destination  
ACCEPT  all  --  192.162.100.241  anywhere  
DROP  all  --  anywhere  anywhere

Bei bestehender VPN Verbindung bricht jede Webseite sofort ab
 
Ich würde das nicht mit Server-IPs machen, da sich diese ja jederzeit mal ändern können, nimm lieber Ports, die bleiben länger erhalten. INPUT und OUTPUT bezieht sich auf deinen Rechner, nicht auf den PP Server, von daher sind beide Regeln falsch. Bei der INPUT Chain akzeptierst du als Quelle alles und als Ziel den PP Server. Das Ziel ist aber bei der INPUT Chain nicht der PP Server, sondern dein Rechner, die Quelle ist der PP Server, also genau andersrum das ganze.

Bei der OUTPUT Chain dasselbe. Ziel ist hier der PP Server und nicht die Quelle. Die Quelle ist hier dein Rechner, da die Pakete von ihm ausgehen mit Ziel PP Server, also wieder andersrum. Dann sollte das klappen.
 
Vielen Dank erst einmal fuer Deine Hilfe!

Ich bin jetzt ehrlich gesagt etwas irritiert. Der Guide (http://ubuntuforums.org/showthread.php?t=1496473) sagt dass ich fuer VPN immer die ShownIP im Netz nehmen soll, was ich bisher nicht so wirklich logisch fand (dein Vorschlag ist mir da deutlich logischer und sinnvoller erscheinend). Ich bin noch recht neu was VPN angeht, und hab mich gerade gefragt, welche IP denn jetzt meine sein muesste, ich bekomme einmal von tun0 (10.7. ... ... ) eine angezeigt, und einmal eine unter enp2s0 (10.0. ... ...).

Dann waeren wir bei der Loesung (mit einer festen PP IP, zum Verstaendnis), wobei 10.0.71.36 durch localhost ersetzt wurde bei der Umsetzung.

Und auch so, klappt leider keine Verbindung.

Code:
Chain INPUT (policy ACCEPT)
target     prot opt source               destination       
ACCEPT     all  --  192.162.100.241      10.0.71.36                     
DROP       all  --  anywhere             anywhere          

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination       

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination       
ACCEPT     all  --  10.0.71.36           192.162.100.241
DROP       all  --  anywhere             anywhere
 
Last edited:
Du benötigst nicht die tun0 IP, das ist die VPN IP, die soll ja frei bleiben. Auch localhost bleibt frei. Du blockst lediglich die lokale IP, die die Kiste von deinem Router zugewiesen bekommen hat. Dieser IP muss aber noch die Kommunikation mit einem DNS Server erlaubt sein, von daher ist die Portvariante halt auch besser. Andernfalls können die PP Hostnamen nicht aufgelöst werden. Oder du aktivierst die Firewall immer erst nach Einwahl zu PP.
 
Das aktivieren der fw war mein vorgehen oben weil ja auch dns getunnelt werden sollte. Leider funkzt nach wie vor die iptables einstellungen wie oben nicht.
 
Code:
-A INPUT -i lo -j ACCEPT
-A INPUT -i wlp2s0 -p udp -m state --state ESTABLISHED -j ACCEPT
-A INPUT -i tun+ -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -d range/24 -o wlp2s0 -p udp -m udp --dport 150 -m state --state NEW,ESTABLISHED -j ACCEPT
-A OUTPUT -d 8.8.8.8/32 -o wlp2s0 -p udp -m udp --dport 53 -j ACCEPT
-A OUTPUT -o tun+ -j ACCEPT

So hab ich das auf meinen Linux Systemen gelöst, wie bereits angemerkt können sich die IP Addressen auch mal ändern, also vielleicht noch den "-d range/24" Parameter bei der zweiten OUTPUT Regel raußnehmen.

Mit diesen Regeln geht nichts raus, außer:
a.) der Traffic ist an den VPN Server, mit der richtigen IP/range und Portkombination adressiert.
b.) Traffic der an einen beliebigen DNS Server, in diesem Fall dem Google DNS 8.8.8.8 mit richtiger Portkombination addressiert ist.

IPv6 Traffic kann und sollte über ip6tables blockiert werden, am besten alles außer Traffic der über das loopback interface ('lo') geht (Kurze Erklärung dazu, einige Login Manager wie z.B. SLIM unter Archlinux schicken da gerne beim Booten ein paar Pakete drüber, wird das blockiert so verlangsamt das den Start des Login Managers um knapp 30 Sekunden, sollte man also nicht blockieren).

Wer all meine Anweisungen befolgt hat, ist Firewalltechnisch schon mal gut abgesichert und kann sich nun um den Rest seines Systems kümmern, bei Linux gibt es viele nette Kernel Patches, z.B. https://grsecurity.net/.
 
@throwaway :

Paar Anmerkungen:
- Man sollte erwähnen, dass deine Policy DROP ist, sonst macht es keinen Sinn nur ACCEPT Regeln zu erstellen. @kaugummi hatte als Policy ACCEPT
- Du erlaubst lediglich einen OpenVPN UDP Port. PP verwendet allerdings 6 UDP Ports, dh für alle anderen Server- Portkombinationen kommt bei dir keine Verbindung zustande
- PP verwendet noch 2 TCP Ports, die man ebenfalls erlauben sollte wenn man OpenVPN via TCP nutzen möchte
- Wenn man nicht unbedingt nur den Google DNS nutzen möchte könnte man den Port 53 einfach mit zu den UDP erlaubten Ports anfügen und erspart sich die extra Regel für DNS
- Die range/24 würde ich, wie du bereits angemerkt hast einfach weglassen, dann gilt das für alle PP OpenVPN Server
 
Wenn ich mir das anschaue, bleibe ich bei meiner Meinung: auch für einfache setups shorewall zu benutzen. Eure Regeln sind sehr rudimentär und decken nicht alles ab. Logging fehlt, icmp fehlt, tcpflags fehlen etc. Mein iptables -L bringt 177 Einträge für ein ganz einfaches System mit nur wenigen shorewall Konfigzeilen. Würd mir stinken das alles per Hand eingeben zu müssen. Außerdem kann ich mir sicher sein, daß shorewall auch die quirks bei iptables/kernel routing kennt und berücksichtigt.
 
Wenn ich mir das anschaue, bleibe ich bei meiner Meinung: auch für einfache setups shorewall zu benutzen. Eure Regeln sind sehr rudimentär und decken nicht alles ab. Logging fehlt, icmp fehlt, tcpflags fehlen etc. Mein iptables -L bringt 177 Einträge für ein ganz einfaches System mit nur wenigen shorewall Konfigzeilen. Würd mir stinken das alles per Hand eingeben zu müssen. Außerdem kann ich mir sicher sein, daß shorewall auch die quirks bei iptables/kernel routing kennt und berücksichtigt.

Du hast den Sinn von meinen Regeln vielleicht nicht ganz verstanden, also hier nochmal nur für dich: Sinn der Regeln ist es, so rudimentär wie möglich zu sein. Alles was irgendwie lokal geroutet wird (tun, lo) hat freie Bahn, alles was über unser physikalisches Netzwerkinterface fließen soll (ob ankommend oder abgehend), wird stark reglementiert.

Wo muss ich da bitteschön was loggen?
Was hat ICMP damit zu tun?
..und die TCP Flags?

Was du erzählt hast macht so ziemlich keinen Sinn, jedenfalls für den Nutzer der nur seine Kiste gegen IP Leaks absichern will.

Viel mehr macht der VPN Manager unter Windows auch nicht (klar, _dort_ und nur dort kommt noch ICMP dazu da das Tool ja die Server auch irgendwie anpingen muss, wer aber nun unter Linux ein eigenes Setup fährt muss sich darum keine Sorgen zu machen.)

Generell gilt bei mir = so viel blockieren wie nur möglich. Wer auf Nummer sicher gehen will, der schafft sich noch eine kleine Hardware Firewall an und macht dort ebenfalls eine ähnlich restriktive Konfiguration, und schön können selbst tolle Rootkits die unter Root Rechten laufen nicht mehr an eure echte IP Adresse kommen. Solche Firewalls gibts ab 150€, ich persöhnlich hab eine Cisco ASA 5505, die gerade wohl so bei 400€ liegt (allerdings auch noch für andere Anwendungsgebiete, da gibt es sicher günstigerere Alternativen.)
 
Last edited:
Rudimentär wie möglich? Ich dachte so sicher wie möglich - und dazu zählt für mich auch, daß ich gerne sehen möchte, daß traffic den Weg nimmt, den ich will. Wie willst Du das ohne logging hinkriegen? Blind vertrauen - wird schon passen... Tolle Firewall.
Wenn Du ICMP nicht blockierst, können diese Pakete leicht am VPN vorbei und mich interessieren (absichtlich) falsch gesetzte TCP flags sehr, denn damit kann ich ggf. erkennen daß da jemand irgendeinen Mist versucht.
Jedenfalls ist es leichtsinnig hier so eine "one-size-fits-all" Lösung zu präsentieren. Jemand der sich damit auskennt kann das vielleicht auf seine Verhältnisse anpassen, aber viele hier können das eben nicht beurteilen. Da bin ich mit einem IP-tables frontend, welches nichts anderes macht, als menschenlesbare Firewall-Regeln in iptables-lingo zu übersetzen doch wesentlich besser bedient. Das hat deutlich weniger Fehlermöglichkeiten und nimmt Dir eine Reihe von settings bereits automatisch ab.
Code:
...
DROP       all  --  anywhere             anywhere             ADDRTYPE match dst-type BROADCAST
DROP       all  --  anywhere             anywhere             ADDRTYPE match dst-type MULTICAST
DROP       all  --  anywhere             anywhere             ADDRTYPE match dst-type ANYCAST
...
oder 
...
DROP       udp  --  anywhere             anywhere             udp dpt:1900 /* UPnP */
DROP       tcp  --  anywhere             anywhere             tcp flags:!FIN,SYN,RST,ACK/SYN
...
 
..wenn Du ICMP nicht blockierst, können diese Pakete leicht am VPN vorbei..

Stimmt so leider auch nicht, wenn die richtige Policy für OUTPUT gesetzt wurde (DROP) dann geht da auch nur das raus was rausgehen soll, einfach mal ausprobieren:

Code:
ping -I <physikalisches netzwerkinterface> <ip>

Entweder werden durch die geänderte Systemroute die Anfragen über den VPN geleitet, oder aber sie werden komplett verworfen. Beides absolut in Ordnung.
 
Ja, mir mußt Du das nicht erzählen, aber Du hast auf jeden Fall eine statische route zum vpn-server selbst gesetzt. Wird unnötiger traffic nicht durch die Firewall blockiert, geht der zu diesem Server dann auf jeden Fall am VPN vorbei. Das passiert z.B. wenn zwei Leute über den selben VPN-Server die selbe Datei per torrent laden/anbieten. Ist übrigens sehr schön in den "überflüssigen" logs zu sehen.
Ist ja gut und schön, wenn Du im Nachsatz mit vielen "wenns" allerlei Einschränkungen bringst. Die sind entweder völlig überflüssig, weil die eine Usergruppe darüber bestens Bescheid weiß, oder sie verunsichern die zweite Gruppe von Nutzern, denn ursprünglich hieß es ja " wenn Du diese Regeln nimmst bist Du schon mal sicher".
Bei shorewall setzt Du nur policy, zonen und Interfaces. IP-adressen tauchen dort z.B. nicht notwendig auf, sondern werden automatisch ermittelt.
Dann kannst Du noch die Ausnahmen von der policy setzen. Da ist nicht mehr viel Raum für Fehlkonfiguration.
Außerdem ist die Dokumentation einmalig. Selbst für exotische setups werden dort Beispiele genannt, die ich mit native ip-tables so nicht hinbiegen möchte.
 
Ich will dieses oder andere Tools ja nicht grundsätzlich schlechtreden, die haben sicherlich alle ihre Vor- und Nachteile - ich persöhnlich fühle mich mit den nativen iptables allerdings gut beraten und werde diese auch weiterhin für meine Zwecke benutzen anstatt von einem Frontend / Wrapper, man gewöhnt sich nach ein paar Jahren halt doch an die Syntax, etc.
 
Mach was Du willst und kannst, aber heute baut man WebSites ja auch nicht mehr mit einem Text -Editor in HTML oder schreibt Software in Assembler. Oder auch OOP: Java ist doch auch daraus erwachsen, daß Leute bei C zu viele Probleme übersehen haben.
Die Tools sind auch dafür da, um menschliche Fehler weitgehend zu vermeiden.
Shorewall ist nur ein preprocessor, der Dir die ip-tables rules generiert und ist kinderleicht zu konfigurieren. Was soll ich mich mit der ganzen Syntax rumärgern, wenn's ein getestetes und erprobtes script in Perl dafür gibt.
Kannst Dir die rules jederzeit hinterher ansehen, und grübeln warum da viel mehr drin steht, als Du im ersten Anlauf gemacht hättest. Anschließend verbessern, wenn Dir danach ist.
 
und grübeln warum da viel mehr drin steht, als Du im ersten Anlauf gemacht hättest

Danach wurde nicht gefragt. Zur Erstellung der oben geposteten Regeln habe ich den VPN Manager unter Windows als Beispiel genutzt.

Das Ergebnis von unseren beiden Lösungen ist letztendlich das selbe = IP Leaks werden verhindert, und das ohne Einbußen was die Sicherheit angeht.
Wenn Shorewall da noch nette Extraregeln erstellen kann bzw. erstellt, super.
Jeder soll verwenden was er will oder was seinen persöhnlichen Anforderungen entspricht.
 
Hallo,
so ich wollte mich auch mal wieder melden, ich habe es jetzt zumindest mit folgendem sh script hinbekommen, dass die Verbindung ueber mein Testbeispiel (Moskau) laeuft und per Disconnect abbricht, ABER

Code:
#!/bin/sh
IPTABLES="/sbin/iptables"

# Flush all
$IPTABLES -F
$IPTABLES -X

# Drop everything by default.
$IPTABLES -P INPUT DROP
$IPTABLES -P FORWARD DROP
$IPTABLES -P OUTPUT DROP

# Already established connections.
$IPTABLES -A INPUT -i enp2s0 -p udp -m state --state ESTABLISHED -j ACCEPT

# Allow traffic to VPN servers.
$IPTABLES -A OUTPUT -o enp2s0 -p udp -d 192.162.100.0/24 -m multiport --dports 149,150,151,1149,1150,1151 -m state --state NEW,E
STABLISHED -j ACCEPT

# Allow traffic on TUN interface.
$IPTABLES -A INPUT -i tun0 -j ACCEPT
$IPTABLES -A OUTPUT -o tun0 -j ACCEPT

# Allow DNS queries.
$IPTABLES -A OUTPUT -o enp2s0 -p udp -d 8.8.8.8 --destination-port 53 -j ACCEPT
$IPTABLES -A OUTPUT -o enp2s0 -p udp -d 8.8.4.4 --destination-port 53 -j ACCEPT

Dennoch frage ich mich ein paar Dinge noch:

1. Soweit ich das nachvollziehen kann, ist der VPN Tunnel, nicht durch die Regeln gefaerdet, wenn er einmal besteht. Ich bau den ja immer zuerst auf und setze dann mein IPTables Script firewall.sh (siehe oben). Waere es generell moeglich, dass ich die Sicherheit meines Tunnels gefaerde, indem ich Regeln falsch setze? Sozusagen dass zwischendrin Daten falsch weitergeleitet werden? Ich wuerde sagen nein, weil ja alles verschluesselt ist und ansonsten eh der Tunnel abbricht. Ist das richtig so?

2. PP wechselt ja von Zeit zu Zeit den DNS Eintrag beim surfen, (siehe: http://whoer.net/). wenn ich da jetzt z.B. ueber ein bestimmtes Land den DNS bekomme, wie etwa England, waere es da nicht auch moeglich, dass man da dann meine IP erfaehrt, oder findet die DNS Anfrage im Tunnel nur ueber die PP IP statt, also die die bei whoer.net gezeigt wird unter dem Eintrag DNS?

3. Wo genau ist eigentlich der Unterschied bei den PP Config Files: openVPN per UDP oder TCP und Server Einzeln oder Group. Hat das Auswirkungen auf die Sicherheit oder auf die Geschwindigkeit?

4. Irgendwie scheinen nicht alle Verbindungen bei mir anzukommen. So z.B. nicht der WebRTC Check, https://www.perfect-privacy.com/webrtc-leaktest/ aber auch einige wenige andere Webseiten. ...

5. Waeren meine Einstellungen so Eurer Meinung nach sicher? Also ich starte VPN ohne IPTABLES, wenn der Tunnel besteht, starte ich meine firewall.sh (Script oben) und dann surfe ich und waere - so soll zumindest meine Vorstellung sein bei einem Tunnelzusammenbruch dennoch sicher, weil alles geblockt wird.

Besten Dank nochmal!
 
Last edited:
Back
Top