Beantwortet: DNS Leak Ubuntu 17.04

noloip

New Member
Hallo

Ich habe mich für ein Abo bei PP entschieden und möchte die VPN Verbindung gerne auf meinem Kubuntu 17.04 nutzen.

Ich habe den PP Manager für Linux runter geladen und bin dann den Thread zu den iptables durchgegangen:
https://board.perfect-privacy.com/threads/linux-absichern-mit-den-iptables.343/
https://board.perfect-privacy.com/threads/linux-absichern-mit-den-iptables.343/
Was habe ich gemacht?
Mit iptables-persistent folgendes unter /etc/iptables/rules.v4 abgepeichert:
Code:
# Generated by iptables-save v1.6.0 on Sat Aug 26 19:35:07 2017
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i eno1 -p udp -m multiport --sports 1149,1150,1151,53,149,150,151 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eno1 -p tcp -m multiport --sports 152,1152 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -s 192.168.0.0/16 -j ACCEPT
-A INPUT -s 10.0.0.0/8 -j ACCEPT
-A INPUT -s 172.16.0.0/12 -j ACCEPT
-A INPUT -i eno1 -j DROP
-A OUTPUT -o eno1 -p udp -m multiport --dports 1149,1150,1151,53,149,150,151 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -o eno1 -p tcp -m multiport --dports 152,1152 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -d 192.168.0.0/16 -j ACCEPT
-A OUTPUT -d 10.0.0.0/8 -j ACCEPT
-A OUTPUT -d 172.16.0.0/12 -j ACCEPT
-A OUTPUT -o eno1 -j DROP
COMMIT
# Completed on Sat Aug 26 19:35:07 2017

Das Funktioniert soweit also wenn keine VPN Verbindung besteht komme ich auch nicht ins Internet. Jedoch habe ich trotzdem einen DNS Leak.

Im oben genannten Thread beschreibt JackCarver folgendes:
https://board.perfect-privacy.com/threads/linux-absichern-mit-den-iptables.343/page-2#post-3826

in der Datei /etc/resolv.conf steht bei mir jedoch ohne VPN Verbindung nur:
Code:
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.

nameserver 127.0.0.53

Wie ich dann gelesen habe wurde unter Ubuntu 17.04 der DNS Resolver gewechselt:
https://wiki.ubuntu.com/ZestyZapus/ReleaseNotes#Networking
https://wiki.ubuntu.com/ZestyZapus/ReleaseNotes#Networking
Unter 127.0.0.53 ist nun der Dienst systemd-resolv dieser soll unter /etc/systemd/network eine Konfigurationsdatei liegen haben, der Ordner ist jedoch bei mir leer.

Ich kann mir nicht mehr selber weiter helfen und hoffe hier auf Hilfe..
Kommt der DNS Leak bei mir nun deswegen? Hat jemand einen Ansatz wie ich das Problem lösen kann?
 
Solution
ich hatte auch mal das problem mit dem DNS Leak allerdings unter Debian 9 mit xfce als oberfläche und mir wurde
folgende notlösung gegeben:

1. Öffne eine root-console

2. Lösche die Datei /etc/resolv.conf

rm /etc/resolv.conf

3. Lege eine neue Textdazei /etc/resolv.conf an, mit einem editor deiner
Wahl, z.B.

nano /etc/resolv.conf

4. Setze entweder Google- oder OpenNIC-Nameserver in der Datei, zu,
Beispiel:

nameserver 8.8.8.8
nameserver 8.8.4.4

5. Setze die Datei auf "immutable" damit der Network Manager diese nicht
mehr verändert, mit folgendem Befehl:

chattr +i /etc/resolv.conf

Bei mir hilft es um einen DNS Leak zu verhindern.
Du musst im Network-Manager zu "Verbindungen bearbeiten" gehen
Dann die Verbindung auswählen
(muss für jede Verbindung einzeln geändert werden - nervig ... Außerdem vergisst man es schnell, wenn man mal eine neue Verbindung, zb anderes Wlan benutzt)
bearbeiten, unter "IPv4-Einstellungen" als Methode: "Automatisch (DHCP), nur Adressen" auswählen

Danach hast du mit VPN keinen IP-Leak mehr. Ohne VPN Verbindung benutzt er dann die Google DNS Server.
Das ist wohl der Default Fallback unter Ubuntu.

Nebeneffekt, man kann sich zb nicht mehr mit "fritz.box" verbinden, sondern muss 192.168.178.1 aufrufen.
 
Hallo erst mal danke für die Antworten.

Die Datei /etc/resolv.conf ist nur noch für die Abwärtskompatibilität. Unter 17.04 regelt das nun systemd-resolved unter
/var/run/systemd/resolve/resolv.conf
https://wiki.ubuntuusers.de/systemd/networkd/#systemd-resolved

Da drin ist Standardmässig bei mir:
Code:
# This file is managed by systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known DNS servers.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 192.168.0.1
nameserver fe80::1
Also die IPv4 und IPv6 Netzwerkadresse meines Routers.

Wenn ich nun im Netzwerkmanager nur bei IPv4 Methode: Automatisch (nur Adressen) wähle, bleibt die IPv6 Adresse meines Routers in der resolv.conf und der DNS Leak besteht weiterhin, erst wenn ich auch bei IPv6 Automatisch (nur Adressen) wähle steht dann in der resolv.conf:
Code:
# This file is managed by systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known DNS servers.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 2001:4860:4860::8888
# Too many DNS servers configured, the following entries may be ignored.
nameserver 2001:4860:4860::8844

Jedoch geht so auch bei aktiver VPN Verbindung der DNS nicht über PP sonder nur über google.
Ich nehme an die Einstellungen des PP Managers ändert die DNS immer noch unter /etc/resolv.conf? daher geht das wohl nicht..

Test Verbunden mit Frankfurt:
Code:
74.125.73.73        GOOGLE    BE
74.125.47.8        GOOGLE    BE
74.125.73.84        GOOGLE    BE
74.125.73.77        GOOGLE    BE
74.125.47.145        GOOGLE    BE
74.125.47.9        GOOGLE    BE
74.125.47.146        GOOGLE    BE
74.125.73.69        GOOGLE    BE
74.125.73.87        GOOGLE    BE
74.125.181.11        GOOGLE    BE
74.125.47.12        GOOGLE    BE
74.125.73.83        GOOGLE    BE
74.125.73.71        GOOGLE    BE
74.125.47.133        GOOGLE    BE
74.125.181.6        GOOGLE    BE
74.125.73.74        GOOGLE    BE
74.125.73.66        GOOGLE    BE
74.125.47.7        GOOGLE    BE
74.125.181.15        GOOGLE    BE
74.125.73.89        GOOGLE    BE
74.125.73.82        GOOGLE    BE
 
ich hatte auch mal das problem mit dem DNS Leak allerdings unter Debian 9 mit xfce als oberfläche und mir wurde
folgende notlösung gegeben:

1. Öffne eine root-console

2. Lösche die Datei /etc/resolv.conf

rm /etc/resolv.conf

3. Lege eine neue Textdazei /etc/resolv.conf an, mit einem editor deiner
Wahl, z.B.

nano /etc/resolv.conf

4. Setze entweder Google- oder OpenNIC-Nameserver in der Datei, zu,
Beispiel:

nameserver 8.8.8.8
nameserver 8.8.4.4

5. Setze die Datei auf "immutable" damit der Network Manager diese nicht
mehr verändert, mit folgendem Befehl:

chattr +i /etc/resolv.conf

Bei mir hilft es um einen DNS Leak zu verhindern.
 
Solution
Hallo
So geht es jetzt, vielen Dank.
Sorry ich dachte echt es liegt an systemd-resolved.

Falls der DNS doch mal auf Google zurückfallen sollte bin ich trotzdem noch safe da die Anfrage an Google DNS erst durch das VPN gehen oder?

Jetzt habe ich ja nur IPv4 dicht gemacht mit iptables, ein ping6 2001:4860:4860::8888 geht trotzdem noch raus bei deaktiviertem VPN. Ich kenne mich mit IPv6 nicht aus, hat das auch Ports? sind das die selben wie bei IPv4 die offen gelassen werden sollen?
 
Danke.

Jetzt ist natürlich ganz zu. Ist das sinnvoll IPv6 zu blocken? Also bringt es keinen Nutzen?

Wenn ich IPv6 durch das VPN zulassen möchte müsste ich in den Regeln zu IPv4 nur iptables durch ip6tables ersetzen?
Also:
Code:
ip6tables -t filter -A OUTPUT -o eno1 -p udp -m multiport --dports 1149,1150,1151,53,149,150,151 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
ip6tables -t filter -A OUTPUT -o eno1 -p tcp -m multiport --dports 152,1152 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
ip6tables -t filter -A INPUT -i eno1 -p udp -m multiport --sports 1149,1150,1151,53,149,150,151 -m state --state ESTABLISHED,RELATED -j ACCEPT
ip6tables -t filter -A INPUT -i eno1 -p tcp -m multiport --sports 152,1152 -m state --state ESTABLISHED,RELATED -j ACCEPT
ip6tables -t filter -A OUTPUT --dst 192.168.0.0/16 -j ACCEPT
ip6tables -t filter -A INPUT --src 192.168.0.0/16 -j ACCEPT
ip6tables -t filter -A OUTPUT --dst 10.0.0.0/8 -j ACCEPT
ip6tables -t filter -A INPUT --src 10.0.0.0/8 -j ACCEPT
ip6tables -t filter -A OUTPUT --dst 172.16.0.0/12 -j ACCEPT
ip6tables -t filter -A INPUT --src 172.16.0.0/12 -j ACCEPT

ip6tables -t filter -A OUTPUT -o eno1 -j DROP
ip6tables -t filter -A INPUT -i eno1 -j DROP
 
Hey,

theoretisch schon habe es aber noch nie getestet.

Wie sieht den dein iptables Standart(policy) aus für IPv4 ich vermute das der auf ACCEPT steht?

Gruß
 
Ja genau.
Code:
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     udp  --  anywhere             anywhere             multiport sports 1149,1150,1151,domain,149,150,151 state RELATED,ESTABLISHED
ACCEPT     tcp  --  anywhere             anywhere             multiport sports 152,1152 state RELATED,ESTABLISHED
ACCEPT     all  --  192.168.0.0/16       anywhere           
ACCEPT     all  --  10.0.0.0/8           anywhere           
ACCEPT     all  --  172.16.0.0/12        anywhere           
DROP       all  --  anywhere             anywhere           

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     udp  --  anywhere             anywhere             multiport dports 1149,1150,1151,domain,149,150,151 state NEW,RELATED,ESTABLISHED
ACCEPT     tcp  --  anywhere             anywhere             multiport dports 152,1152 state NEW,RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             192.168.0.0/16     
ACCEPT     all  --  anywhere             10.0.0.0/8         
ACCEPT     all  --  anywhere             172.16.0.0/12       
DROP       all  --  anywhere             anywhere
 
Hey,

okay das ist gefährlich mir ist ein Leak dadurch entstanden und das folgendermaßen:

Ich hab einen neuen Rechner besorgt und dort die Linux Platte angestöpselt.
Dadurch hat sich mein netzwerkadapter name geändert das wurde durch das:

iptables -t filter -A OUTPUT -o eno1 -j DROP
iptables -t filter -A INPUT -i eno1 -j DROP

nicht mehr abgefangen ohne tunnel war mein Internet offen ich habe es folgendermaßen gelöst:

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

dann noch

iptables -t filter -A OUTPUT -o lo -j ACCEPT
iptables -t filter -A INPUT -i lo -j ACCEPT

und

iptables -t filter -A OUTPUT -o tun0 -j ACCEPT
iptables -t filter -A INPUT -i tun0 -j ACCEPT

lo ist für locale Programme die brauchen das um Kominzieren zu können

tun0 ist so anzupassen wie dein PP Tunnel heißt wenn die Verbindung aktiv ist

Hoffe es Hilft

Gruß
 
Ok danke für den Hinweis.

Code:
-A OUTPUT -o eno1 -p udp -m multiport --dports 1149,1150,1151,53,149,150,151 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -o eno1 -p tcp -m multiport --dports 152,1152 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eno1 -p udp -m multiport --sports 1149,1150,1151,53,149,150,151 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eno1 -p tcp -m multiport --sports 152,1152 -m state --state RELATED,ESTABLISHED -j ACCEPT
Brauch ich dann aber auch noch oder?

Oder wie gebe ich die Ports dann frei?
 
So müssten deine iptables stimmen so hab ich die auch aufgebaut ( nur halt andere Adapternamen)



iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP
ip6tables -P INPUT DROP
ip6tables -P FORWARD DROP
ip6tables -P OUTPUT DROP

iptables -t filter -A OUTPUT -o eno1 -p udp -m multiport --dports 1149,1150,1151,53,149,150,151 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -t filter -A OUTPUT -o eno1 -p tcp -m multiport --dports 152,1152 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -t filter -A INPUT -i eno1 -p udp -m multiport --sports 1149,1150,1151,53,149,150,151 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -t filter -A INPUT -i eno1 -p tcp -m multiport --sports 152,1152 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -t filter -A OUTPUT --dst 192.168.0.0/16 -j ACCEPT
iptables -t filter -A INPUT --src 192.168.0.0/16 -j ACCEPT
iptables -t filter -A OUTPUT --dst 10.0.0.0/8 -j ACCEPT
iptables -t filter -A INPUT --src 10.0.0.0/8 -j ACCEPT
iptables -t filter -A OUTPUT --dst 172.16.0.0/12 -j ACCEPT
iptables -t filter -A INPUT --src 172.16.0.0/12 -j ACCEPT

iptables -t filter -A OUTPUT -o lo -j ACCEPT
iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A OUTPUT -o tun0 -j ACCEPT
iptables -t filter -A INPUT -i tun0 -j ACCEPT

iptables -t filter -A OUTPUT -o eno1 -j DROP
iptables -t filter -A INPUT -i eno1 -j DROP

Ich sehe aber in dem aufbau trotzdem noch eine gefahr. So kommt nur der tunnel durch AUßER ein programm kominiziert mit irgend einer IP auf
den Ports die frei gegeben wurden das liegt daran das iptables von oben nach unten abgearbeitet werden jetzt wird eine verbindung aufgebaut auf einem
der freigegebenen Ports dann wird das Packet durchgelassen( zumindest rein Theoretisch habs nicht getestet ) das zu verhindern müssten rein die
IPs von PP freigegeben werden und da entwickel ich momentan etwas um zu schauen ob das funktioniert :D
 
Back
Top