ubuntuusers.de

Unter Sicherheit/Anonym Surfen (Abschnitt „Systemweit“) ist eine Anleitung, wie man google & Co systemweit blockt. Wenn ich das richtig verstehe, dürfte es dann beim Browser gar nicht mehr registriert werden. Mein Ghostery-AddOn im Firefox registriert und blockt aber immer noch Tracker von Google-Analytics.

Verstehe ich etwas falsch, oder habe ich etwas falsch gemacht?

Meine hosts-Datei

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

user@pc-kubuntu:~$ cat /etc/hosts
127.0.0.1       localhost
127.0.1.1       pc-kubuntu

127.0.0.2   google-analytics.com google-analytics
127.0.0.3   facebook. fbcdn.

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

MoonKid schrieb:

Mein Ghostery-AddOn im Firefox registriert und blockt aber immer noch Tracker von Google-Analytics.

Verstehe ich etwas falsch, oder habe ich etwas falsch gemacht?

Meine hosts-Datei

user@pc-kubuntu:~$ cat /etc/hosts
127.0.0.2   google-analytics.com google-analytics
127.0.0.3   facebook. fbcdn.

Wie sind die Ausgaben für:

dig google-analytics.com +short

dig facebook.* +short
dig fbcdn.* +short

MoonKid schrieb:

1 2 3 4 5 6

user@pc-kubuntu:~$ dig google-analytics.com +short 173.194.113.179 173.194.113.177 173.194.113.176 173.194.113.178 173.194.113.180

D. h., dein Eintrag in die "/etc/hosts" hat keine Wirkung.

MoonKid schrieb:

user@pc-kubuntu:~$ dig facebook.* +short
user@pc-kubuntu:~$ dig fbcdn.* +short
user@pc-kubuntu:~$

Wie ist die Ausgabe für:

dig facebook.com +short
dig facebook.de +short

?

EDIT:

Schau mal ob dein dnsmasq die hosts-Datei benutzt. Z. B., die Ausgabe von:

ps -fC dnsmasq

Etwa so:

UID        PID  PPID  C STIME TTY          TIME CMD
nobody    xxxx   ###  0 00:00 ?        00:00:00 /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfac

?

1
2
3
4
5
6
7

user@pc-kubuntu:~$ dig facebook.com +short
173.252.110.27
user@pc-kubuntu:~$ dig facebook.de +short
173.252.110.27
user@pc-kubuntu:~$ ps -fC dnsmasq
UID        PID  PPID  C STIME TTY          TIME CMD
nobody    1335  1256  0 Aug22 ?        00:00:01 /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-

dnsmasq scheint die /etc/hosts also nicht zu verwenden.

Laut man-page von dnsmasq existiert die Option --no-hosts aber auch gar nicht.

Mpf!?

In /etc/hosts blockierst du Google-Analytics nicht, sondern du sagst, dass google-analytics.com nach 127.0.0.2 aufgelöst werden soll, so dass Anfragen an Google-Analytics nicht bei Google landen.

Die Links zu Google-Analytics stehen aber weiterhin im Code der Webseiten, und werden dort von Ghostery gefunden und blockiert, noch bevor der Name aufgelöst wird.

diesch schrieb:

In /etc/hosts blockierst du Google-Analytics nicht, sondern du sagst, dass google-analytics.com nach 127.0.0.2 aufgelöst werden soll, so dass Anfragen an Google-Analytics nicht bei Google landen.

Bist Du sicher, dass das bei ihm so ist? dig sagt bei ihm Folgendes:

user@pc-kubuntu:~$ dig google-analytics.com +short
173.194.113.179
173.194.113.177
173.194.113.176
173.194.113.178
173.194.113.180

MoonKid schrieb:

user@pc-kubuntu:~$ dig facebook.com +short
173.252.110.27
user@pc-kubuntu:~$ dig facebook.de +short
173.252.110.27
user@pc-kubuntu:~$ ps -fC dnsmasq
UID        PID  PPID  C STIME TTY          TIME CMD
nobody    1335  1256  0 Aug22 ?        00:00:01 /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-

dnsmasq scheint die /etc/hosts also nicht zu verwenden.

Laut man-page von dnsmasq existiert die Option --no-hosts aber auch gar nicht.

Bei mir zeigt "man dnsmasq" u. a. auch:

-h, --no-hosts
              Don't read the hostnames in /etc/hosts.

dig benutzt nicht den normalen sondern eigenen Code, um DNS-Namen aufzulösen, und benutzt dabei /etc/hosts nicht. Nimm z.B. ping, wenn du wissen willst, wie ein Name lokal tatsächlich aufgelöst wird.

diesch schrieb:

dig benutzt nicht den normalen sondern eigenen Code, um DNS-Namen aufzulösen, und benutzt dabei /etc/hosts nicht. Nimm z.B. ping, wenn du wissen willst, wie ein Name lokal tatsächlich aufgelöst wird.

dig benutzt die "/etc/resolv.conf" und somit dnsmasq:

:~$ dig google-analytics.com

; <<>> DiG 9.8.1-P1 <<>> google-analytics.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 240
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;google-analytics.com.		IN	A

;; ANSWER SECTION:
google-analytics.com.	60	IN	A	193.169.12.12

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Aug 23 21:34:34 2013
;; MSG SIZE  rcvd: 54

:~$ sudo lsof -nPi | grep :53 
dnsmasq  1160 dnsmasq    4u  IPv4  10348      0t0  UDP 127.0.0.1:53 
dnsmasq  1160 dnsmasq    5u  IPv4  10349      0t0  TCP 127.0.0.1:53 (LISTEN)

The dig command uses the resolver library, and that library uses the nameserver entries in /etc/resolv.conf in order, but only on failure. The purpose of multiple entries is for redundancy, in case the primary server fails for some reason. But if the primary server provides a response, whether positive or negative (e.g. NXDOMAIN), then the other nameserver entries are not used. You can have up to three nameservers, for triple redundancy.

Wenn dnsmasq so konfiguriert ist, dass die "/etc/hosts" benutzt wird, dann benutzt auch dig die "/etc/hosts":

# If you don't want dnsmasq to read /etc/hosts, uncomment the
# following line.
#no-hosts

Der von NetworkManager gestartete dnsmasq benutzt /etc/hosts aber nicht.

dig ist hier das falsche Werkzeug, weil es DNS-Namen anders auflöst als der Browser.

Da Ghostery aber die Seite schon vor der DNS-Auflösung analysiert, spielt die DNS-Auflösung für die Frage eigentlich gar keine Rolle.

diesch schrieb:

Die Links zu Google-Analytics stehen aber weiterhin im Code der Webseiten, und werden dort von Ghostery gefunden und blockiert, noch bevor der Name aufgelöst wird.

@MoonKid

Ob eine Verbindung zu "google-analytics.com" (d. h. zu den IP-Adressen: 173.194.113.176-180) hergestellt wird, kannst Du mit:

sudo tcpdump -vn -i <output-interface> dst google-analytics.com

sehen.

diesch schrieb:

Da Ghostery aber die Seite schon vor der DNS-Auflösung analysiert, spielt die DNS-Auflösung für die Frage eigentlich gar keine Rolle.

Das stimmt, aber es ging nicht um Ghostery.

diesch schrieb:

dig ist hier das falsche Werkzeug, weil es DNS-Namen anders auflöst als der Browser.

Ich denke, sein Browser wird auch dnsmasq (mit --no-hosts) benutzen.

sudo tcpdump -vn -i lo dst port 53

Browser:

22:40:15.666458 IP (tos 0x0, ttl 77, id 52058, offset 0, flags [DF], proto UDP (17), length 66)
    127.0.0.1.14570 > 127.0.0.1.53: 29355+ A? google-analytics.com. (38)

tcpdump löst google-analytics.com über /etc/hosts zu 127.0.0.2 auf, und findet dann nie etwas, weil die Pakete an 127.0.0.2 über die Schnittstelle lo geroutet werden. Daher siehst du da auch bei z.B. ping 173.194.113.176 nichts.

Du musst also statt dem Namen die IP-Adressen angeben:

1

sudo tcpdump -vn -i <output-interface> dst 173.194.113.176 or 173.194.113.177 or 173.194.113.178 or 173.194.113.179 or 173.194.113.180

diesch schrieb:

tcpdump löst google-analytics.com über /etc/hosts zu 127.0.0.2 auf, und findet dann nie etwas, ...

Bei mir wird es gefunden 😉

:~$ sudo tcpdump -vn -i wlan0 dst google-analytics.com
tcpdump: listening on wlan0, link-type EN10MB (Ethernet), capture size 65535 bytes
22:14:52.006603 IP (tos 0x0, ttl 77, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.0.100 > 193.169.12.12: ICMP echo request, id 3788, seq 1, length 64
22:14:53.005745 IP (tos 0x0, ttl 77, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.0.100 > 193.169.12.12: ICMP echo request, id 3788, seq 2, length 64