Fedora: Die DNS Geschichte trägt Früchte

Wer die Mailingliste von Fedora-Devel gelesen hat, wird es mit bekommen haben: Das Thema systemd-resolved & DNS trenden enorm.

Fedora: Die DNS Geschichte trägt Früchte

Als eine Konsequenz der Diskussion wurde ein Änderungsvorschlag der DNS Gruppe von Michael Catanzaro eingereicht, daß systemd-resolved ab sofort mit einem optimistischen DoT aktiviert wird, also DNS-over-TLS, dem älteren Bruder von DNS-over-HTTPS ( DoH ).

Das meint für den Benutzer, wenn ein eingestellter DNS Server DoT unterstützt, und das findet man leicht mit einem Connectversuch auf den passenden Port 853 heraus, soll automatisch die Verschlüsselung benutzt werden. Das ist natürlich aus Datenschutzgründen zu bevorzugen.

Der Nachteil der Sache ist leider, daß die DNS Anfragen nicht ganz so schnell kommen, wie man das gewohnt ist, weil ja mehr Daten und Verschlüsselung im Spiel sind. Es ist aber ein Weg in die richtige Richtung.

Ein bisschen laut Lachen mußte ich allerdings bei der Passage:

== Benefit to Fedora ==

DNS queries are encrypted and private by default, if the user’s ISP supports DoT. Most probably don’t, but users who manually configure a custom DNS server (e.g. Cloudflare or Google) will automatically benefit from DNS over TLS.

Ausgerechnet die beiden DNS Server zu empfehlen, die das Privatsspährenproblem im systemd-resolved sind, ist schon eine Farce 😀

 

Linux – DNS-DeTracking mit nscd

Das Problem

Wenn man alle seine DNS Anfragen über einen einzigen Anbieter abwickelt, kann der leicht herausbekommen, wofür man sich interessiert, da er ja jede Domain kennt, mit der man „reden“ will.

Wenn man von einem DNS Anbieter, sei es die Deutsche Telekom oder Google, nicht vollumfänglich getrackt werden will, kann man nur seinen eigenen DNS-Cache betreiben, oder laufend den DNS Anbieter wechseln ? Oder gibt es da vielleicht noch eine dritte Möglichkeit ?

Methode 1:

Jeder kann sich einen DNS Cache auf dem eigenen PC installieren. Der Nachteil ist, es ist nicht besonders effizient und bei einigen DSL-Anbietern kann man auch nicht selbst die DNS Auflösung machen. In letzterem Fall solltet Ihr Euch auf jeden Fall einen Tunnel in die freie Welt aufbauen, z.b. per VPN. Einen eigenen Server der dafür ausreicht kann man sich schon für 6,50 € im Monat mieten. Ihr braucht  dann noch sowas : UDP Traffic per SSH tunneln, Die Vorratsdatenspeicherung umgehen oder VDS: Schnell ein VPN aufsetzen . Es geht zwar nicht um die Vermeidung der VDS, aber das Prinzip ist das gleiche. Aber wenn Ihr sowieso schon einen eigenen Server habt, laßt den das DNS Cache übernehmen.

Wieso ist das nicht effektiv ?

Ein DNS Cache macht nur dann Sinn, wenn viele Klienten in einem Netzwerk das Cache benutzen, denn der eigentliche Sinn ist, daß nicht jeder Rechner die Root-DNS kontaktiert, sondern das man möglichst viele Anfragen lokal selbst beantworten kann, weil man bereits einmal danach gefragt hat. Das geht zum einen schneller, zum anderen spart es Traffic ein. Das man seinen Fußabdruck dabei kleiner hält, fällt praktischerweise nebenbei ab. Je mehr einen DNS Cache benutzen, desto mehr gehen auch die eigenen Anfragen in der Masse unter.

Methode 2:

Ein Script, daß laufend die /etc/resolv.conf  neu und die DNS Servernamen in der Reihenfolge zufällig hinein schreibt, ist mit ein bisschen Bash-Foo machbar. Dauer ca. 15 Minuten.

Methode 3:

Schauen wir uns mal die /etc/resolv.conf an, finden wir dort:

; generated by /usr/sbin/dhclient-script
nameserver 9.9.9.9
nameserver 8.8.8.8
nameserver 8.8.4.4

Wenn man nichts weiter auf seinem Rechner installiert hat, wird in genau dieser Reihenfolge ein DNS nach dem Anderen abgefragt, wenn der vorherige DNS nicht rechtzeitig antwortet.

Das Verhalten kann man aber ändern:

options rotate
nameserver 9.9.9.9
nameserver 8.8.8.8
nameserver 8.8.4.4

Jetzt würde ein entsprechend gut programmierter Resolver, das ist der Programmteil, der die DNS Auflösung macht, zufällig aussuchen, welchen der DNS er benutzt. Trägt man hier also viele öffentliche DNS Server in dieser Liste ein, verteilt man alle DNS Anfragen auf diese Server, was jedem einzelnen logischerweise die Möglichkeit nimmt, ein umfangreiches Profil zu erstellen.

Dummerweise juckt diese Anweisung kaum einen Resolver. Das geht sogar soweit, daß der erste in der Liste mal einfach überlesen wird 🙂 Also muß eine Lösung her, die diese Anweisung respektiert: NSCD

dnf install nscd
systemctl start nscd
systemctl enable nscd

Ab jetzt werden DNS Abfragen über den NameserverCacheDämonen abgewickelt, und der fragt zufällig die DNS in der Liste an. Da es sich auch um einen Cache handelt, fragt er im Laufe der Zeit ( TTL eines Eintrags ) nur einmal die Rootserver an ( Kleiner Fußabdruck ) .

Damit wäre das Trackingproblem erledigt, wenn Ihr viele DNS Server zur Verfügung habt.

Einen eigenen DNS Cache auf dem PC zu betreiben, ist nicht weiter wild, man müßte nur den named installieren und starten. Da aber bei DNS Abfragen einiges unterwegs schief gehen kann, ist eine starke DNS Infrastruktur wie bei Google durchaus ein starker Partner.

Welche Methode für Euch die richtige ist, müßt Ihr wissen.

echter Spaß mit DNS – Jenseits des Wahnsinns

Da ich gestern Nacht sehr enttäuscht wurde, weil mir in einem Blogartikel Spaß mit DNS angekündigt wurde, aber gar kein Spaß drin war, dachte ich mir, zeigt den Leuten doch mal was wirklich mit DNS geht 😀

Spaß mit DNS – Jenseits des Wahnsinns

Zunächst mal, man sollte sich mit DNS auskennen um dem Artikel folgen zu können. Wer noch nie Begriffe wie Delegation Nameserver, TTL und TXT-Records gehört hat, liest jetzt bitte erstmal auf der Wikipedia weiter. Das war übrigens kein Vorschlag!

Was macht DNS nochmal ?

Richtig, es löst Namen zu IP Adressen auf ( IN A ) oder IPS zu Namen ( PTR ) … ODER DOCH NICHT ???? 😀

Was brauchen wir ?

Wir brauchen DIG, eine BASH, ein PERLSCRIPT und das Wissen, daß DNS durch praktisch jede Firewall auf diesem Planeten geht, weil es ohne DNS nicht ganz so gut klappt mit dem Surfen. Dazu brauchen wir einen Server, einen Clienten ( das sind wir 😉 ) und einen Domainnamen.

Den Server habe ich einfach mal auf meinem Desktoprechner installiert, der hört dann auf die IP 127.0.0.1 . Als Domainnamen kann was echtes nehmen, ich habe mal test.de genommen.

Jetzt die Abteilung: „Ich hab es Euch vorher gesagt“

WARNUNG:

DAS SCRIPT HAT SICHERHEITSLÜCKEN – NICHT PRODUKTIV EINSETZEN !

WARNING:

WHATEVER GOT YOU HERE, DO NOT USE THIS SCRIPT WITHOUT FURTHER SECURITY IMPROOVEMENTS!  YOU WILL GET HACKED!

 

Wer das jetzt in freier Wildbahn ausprobiert, ist selbst Schuld. Wenn Ihr gehackt werdet, ist das nicht meine Schuld oder mein Problem! Ihr seid gewarnt worden!

#!/usr/bin/perl

use strict;
use warnings;
use Net::DNS::Nameserver;

sub reply_handler {
        my ($qname, $qclass, $qtype, $peerhost,$query,$conn) = @_;
        my ($rcode, @ans, @auth, @add);

        print "Received query from $peerhost to ". $conn->{sockhost}. "\n";
#        $query->print;

        if ($qtype eq "TXT" ) {

        # ACHTUNG  SANITIZING NICHT VERGESSEN 
        my $name = $qname;
        $name =~ s/\.test\.de//;
        my ($cmd,$url) = split(/\./, $name, 2);
        my $payload ="";

        print "cmd=$cmd and url=$url\n";

        if ( $cmd eq "help" ) {
            $payload = "help get ls"  
        }

        if ( $cmd eq "ls" ) {

            $url =~ s/[\\n;\|]//g;

            print "URL = $url\n";

            $payload = readpipe("ls -la $url");
        }

        if ( $cmd eq "get") {
            $payload = readpipe("curl \"http://$url\"");
        }

                my ($ttl, $rdata) = (1, $qname);
                my $rr = new Net::DNS::RR("$qname 1 IN TXT \"$payload\"");
                push @ans, $rr;
                $rcode = "NOERROR";
    }


        # mark the answer as authoritive (by setting the 'aa' flag
        return ($rcode, \@ans, \@auth, \@add, { aa => 1 });
    }

my $ns = new Net::DNS::Nameserver(
        LocalAddr    => "127.0.0.1",
        LocalPort    => 53,
        ReplyHandler => \&reply_handler,
        Verbose      => 1
        ) || die "couldn't create nameserver object\n";

$ns->main_loop;

Herzlichen Dank erstmal an „Shell & Co“, auch wenn der das Beispielscript vom Perlentwickler nur leicht modifiziert hat 🙂 Mit der Vorlage war es kein Problem, daß Serverscript zu schreiben.

Das Script starten wir auf dem Server, also z.b. auf meinem Desktop :

# perl ./perl-nameserver.pl
Creating TCP socket 127.0.0.1#53 – done.
Creating UDP socket 127.0.0.1#53 – done.
Waiting for connections…
Waiting for connections..

Der Server wartet einfach auf Verbindungen und antwortet, wenn ich ein Kommando schicke 🙂

Damit wir Daten zum und vom DNS Server bekommen, müssen wir ihn was fragen, das machen wir mit „dig“. DNS Records haben unterschiedliche Typen, für unterschiedliche Anwendungen. Wenn man TEXTE haben will, sollte man TXT Records benutzen. Das „@127.0.0.1“ das gleich zusehen ist, weist dig an, den localhost zu fragen, also meinen eigenen Server.

Das erste Kommando das ich an den Fake-DNS Server schicke ist „HELP“ :

[marius@eve ~]$ dig TXT help.test.de @127.0.0.1

; <<>> DiG 9.10.4-P2-RedHat-9.10.4-1.P2.fc23 <<>> TXT help.test.de @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28307
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;help.test.de.            IN    TXT

;; ANSWER SECTION:
help.test.de.        1    IN    TXT    "help get ls"

;; Query time: 36 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mi Aug 31 11:33:48 CEST 2016
;; MSG SIZE  rcvd: 58

Wie man sieht, bekommt man eine Antwort „help get ls“. Das sind die Kommandos, die ich meinem DNS Server schicken kann. Probieren wir doch mal „get“ aus 😀

[marius@eve ~]$ dig TXT get.benderirc.de.test.de @127.0.0.1

; <<>> DiG 9.10.4-P2-RedHat-9.10.4-1.P2.fc23 <<>> TXT get.benderirc.de.test.de @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 376
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;get.benderirc.de.test.de.    IN    TXT

;; ANSWER SECTION:
get.benderirc.de.    1    IN    TXT    "<!DOCTYPE HTML PUBLIC " "-//IETF//DTD" "HTML" "2.0//EN" ">\010<html><head>\010<title>302 Found</title>\010</head><body>\010<h1>Found</h1>\010<p>The document has moved <a href=" "https://benderirc.de/" ">here</a>.</p>\010</body></html>\010"

;; Query time: 115 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mi Aug 31 11:34:40 CEST 2016
;; MSG SIZE  rcvd: 274

Jetzt ist das Ganze immer eine sehr lange Ausgabe, mit unnötigen Infos, also kürzen wir das etwas :

[marius@eve ~]$ dig +short TXT get.benderirc.de.test.de @127.0.0.1 | sed -e "s/\\\\010/\n/g"
"<!DOCTYPE HTML PUBLIC " "-//IETF//DTD" "HTML" "2.0//EN" ">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a href=" "https://benderirc.de/" ">here</a>.</p>
</body></html>
"

Schon besser… Leider meint diese Ausgabe, daß ich HTTPS benutzen soll 😀 Äh ja.. Natürlich könnte man den Server so umbauen, daß er auch HTTPS nimmt, aber für das Experiment muß das nicht sein.  Man könnte einfach https eintragen:

        if ( $cmd eq "get") {
            $payload = readpipe("curl --insecure \"https://$url\"");
        }

oder ein eigenes Kommando für HTTPS einbauen 🙂  Wofür man das braucht , diskutieren wir am Ende des Artikels.

[marius@eve ~]$ dig +short TXT ls./tmp.test.de @127.0.0.1 | sed -e "s/\\\\010/\n/g"
"insgesamt 12
drwxrwxrwt  12 root root  260 31. Aug 12:06 .
dr-xr-xr-x. 23 root root 4096  5. Mai 11:40 ..
drwxrwxrwt   2 root root   40  1. Apr 13:07 .font-unix
drwxr-xr-x   2 root root   60 31. Aug 12:13 hsperfdata_root
drwxrwxrwt   2 root root   40  1. " "Apr 13:07 .ICE-unix
drwx------   3 root root   60 31. Aug 03:43 systemd-private-395b74a138f9476e84b5f710a90a117f-dovecot.service-tHODyP
drwx------   3 root root   60 21. Aug 14:01 systemd-private-395b74a138f9476e84b5f710a90a117f-exim.service-hJkbDr
drwx--" "----   3 root root   60 21. Aug 14:01 systemd-private-395b74a138f9476e84b5f710a90a117f-mariadb.service-gPa10y
drwx------   3 root root   60  1. Apr 13:07 systemd-private-395b74a138f9476e84b5f710a90a117f-munin-node.service-AhKKmo
drwxrwxrwt   2 root root  " " 40  1. Apr 13:07 .Test-unix
-rw-r--r--   1 root root 4256 16. Jul 14:35 warning
drwxrwxrwt   2 root root   40  1. Apr 13:07 .X11-unix
drwxrwxrwt   2 root root   40  1. Apr 13:07 .XIM-unix
"

Ich denke mal, weiter müssen wir hier nicht gehen, aber wer etwas Fantasie hat, der kann sich jetzt leicht ausmalen, was man damit noch so treiben könnte !

Jetzt gibt es natürlich eins zu bedenken, daß ich bislang unterschlagen hatte: Das geht nur, wenn Root den DNS Server gestartet hat, weil Port 53 zu den restriktiven Ports gehört, die nur Rootdaemons benutzen dürfen. Wer also bei einem Hack soweit gekommen ist, kann das als RemoteShellzugang benutzen.

Wenn man jetzt die Payload ( Ausgabe ) und die URLS ( Eingabe ) verschlüsselt, kann auch ein NIDS hier nicht mitlesen. Es fallen allenfalls komische DNS Anfragen auf und natürlich der Umstand, daß die Abfragen reinkommen ins Netz, statt rausgehen 😀

Wofür ist das Beispiel dann gut ?

Natürlich hat das alles einen praktischen Nutzen, fangen wir mal mit was ganz legalem an :

Stellen wir uns mal vor, daß das Großbritanien  nicht nur Passwörter für Festplatten und Handies erpresst, sondern einfach mal alles überwacht und zensiert, was geht.. hmm.. vergeßt daß, die machen das ja schon 😀

Wenn ich an freie Informationen kommen will OHNE das ich gleich am Arsch bin, könnte ich TOR nutzen. TOR verschiebt meine Anfrage zu jemand anderem, so daß es für einen Überwacher so aussieht, als wenn ich gar nicht nach der Info gefragt habe. Aus Sicht der Queen ist TOR böse und sie ist not amused, also wird der Macher von TOR geköpft und TOR verboten.  Es muß folglich ein Ersatz her:  das DNS-GATEWAY 😉

Die Leute im freien Internet stellen also nun so einen Server auf, wie wir ihn oben gesehen haben, nur ohne „LS“ 😉

Zeitgleich wird das Script noch verbessert, weil es diverse Probleme hat. z.b. URL Parameter , die müssen alle mit % kodiert werden, die Rückgabe von Bildern, Zusätzliche Header, Kompression usw. könnte ein Problem sei. Da müßte man also etwas mehr Logik einbauen um das alles abzufedern. Nehmen wir mal an, das wäre der Fall (und es geht wirklich, das ist nicht so schwer ). Ein valider per DNS auflösbarer Domainname, ergo registrierter Domainname, ist auch noch nötig. Da gibt es über hundert Millionen von 😉

Was hätten wir jetzt ?

Wir haben eine Proxy, daß Anfragen auf DNS annimmt, in HTTP umwandelt und zum Server X schickt,die Antwort wieder in DNS umwandelt und zurückschickt.

Was wollen wir noch ?

Wir wollen unserem Überwachungsstaat nicht in die Hände spielen, deswegen dürfen wir diese ProxyServer nicht direkt fragen. OK.. Fragen wir doch einfach ein DNS-Cache !

DNS ist cachebar. Also speichern alle Caches die Informationen, die wir bei den ProxyServern angefragt haben und zwar für die Zeit, die im TTL der Antwort angegeben ist. Eine kurze TTL von 1 Sekunde, würde z.b. gleich bedeutend sein mit „Nicht cachen“, weil das DNS Cache nach 1 Sekunden vergessen hätte, was der ProxyServer geschickt hatte und folglich die Anfrage nochmals schickt. Damit kann ich also LIVE Webseiten abfragen! Bietet sich bei GoogleNews an, oder Twitter.

Jetzt könnte man z.B. als Proxyserver einfach zwei Domainnamen haben, der eine für LIVE Anfragen mit kurzer TTL, der andere für langfristige Speicherung, also z.b. Wikipediainhalte usw. .

Da jetzt im ProxyServer Logfile eine IP vom DNS Cache auftaucht, und beim Webserver von dem die Infos stammen, die IP des Proxys steht, kann niemand mehr einen direkten Zusammenhang herstellen. öffentliche DNS-Caches gibt es zu dem wie Sand am Meer in Netz, da stehen hunderttausende rum, deutlich mehr als TOR Nodes existieren. Um Überwacher noch weiter täuschen, kann man auch laufend von einem DNS Cache zum Nächsten wechseln. Außerdem ist DNS nicht zwangsweise TCP Datenverkehr, sondern UDP und UPD kann z.b. nicht mit gefakten FIN Paketen unterbinden/unterbrechen, so wie das die große Firewall in China und anderen Überwachungswahnstaaten tut.

Was bietet das System von Haus auch noch ?

Es kann beliebig skaliert werden, weil es kein Limit für die Anzahl von ProxyServern und ProxyDomainnamen gibt.
Es damit abzuschalten ist fast aussichtslos, da die einzelnen Proxys nicht in einem Land stehen müssen.

;benderirc.de.            IN    NS

;; ANSWER SECTION:
benderirc.de.        86400    IN    NS    ns1.proxyserver.net.
benderirc.de.        86400    IN    NS    ns2.proxyserver.net.
benderirc.de.        86400    IN    NS    ns3.proxyserver.net.
benderirc.de.        86400    IN    NS    ns4.proxyserver.net.
benderirc.de.        86400    IN    NS    ns5.proxyserver.net.
benderirc.de.        86400    IN    NS    ns6.proxyserver.net.
benderirc.de.        86400    IN    NS    ns7.proxyserver.net.
benderirc.de.        86400    IN    NS    ns8.proxyserver.net.

Die Ips der Proxyserver könnten auch gleich noch per RoundRobin bei jeder Auflösung wechseln, es könnten also deutlich mehr Proxies im Spiel sein, als Nameserver ausgegeben werden. Noch ein Pluspunkt 🙂

Für dieses kleine Gedankenspiel soll es nun mal genug sein. Ich bin gespannt ob das einer in die Tat umsetzt 😀

Kann man mit DNS noch mehr machen ????

Ja, na klar. Es gibt doch Subdomains 😀

Obiger Server könnte z.b. MP3 Livestreaming durch DNS umleiten, wäre kein Problem, weil jedes Datensegment eine eigene Subdomain sein könnte. Man fragt einfach genug Sudomains ab, bekommt eine Menge X an Base64 kodierten Daten , dekodiert das, baut es zu einem Stream zusammen, synct das mit dem Datenstrom den man schon hat, kehrt zum Anfang des Loops zurück, und spielt ab, was man bekommen hat. Fertig ist das Livestreaming per DNS 😀

Man muß halt nur Ideen und einen ausgeprägten Spieltrieb haben!

Auf die illegalen Nutzungen des obigen DNS Serverscripts möchte ich verständlicherweise nicht näher eingehen, aber im Prinzip ist es ja deutlich geworden, das DNS für alles benutzt werden kann, weil es einfach wahnsinnig robust und redundant gebaut wurde. Daten von A nach B zu bekommen, ist einfach nur eine Frage von „Was ist die Frage“ und „Was ist eigentlich in der Antwort“ drin.

Und jetzt will ich kreative Lösungen rund um und mit DNS sehen ! DAS WAR KEIN VORSCHLAG, Leser ! 😀

Und von Florian erwarte ich noch viiiiieeelll mehr, als nur einen Artikel, das man DIG irgendwo eintippen kann 🙂

 

UDP Traffic per SSH tunneln

SSH Tunnel sind eine gängige Methode um Traffic sicher von einer Maschine auf die andere umzuleiten, aber SSH kann nur TCP Traffic tunneln. Wie bekommt man jetzt UDP über SSH getunnelt ?

Die Antwort lautet : gar nicht! Man muß TCP Traffic draus machen 🙂

Als ersten Schritt öffnen wir mal den Tunnel:    (alle Befehle als Root ausführen versteht sich)

root# ssh -L 8080:localhost:8080 username@zielserver.de „sleep 10000“

Dies schiebt alle Daten die auf Port 8080 ankommen, an den Port 8080 des Zielserver. Der Einfachheit halber, belassen wir die Port auf Quell- und Zielsystem bei der gleichen Nummer, aber das kann man auch nach Bedarf anpassen.

Als erstes brauchen wir einen FIFO ( First In – First Out ) Speicher auf dem Zielserver. Damit kann man die Daten lesen und schreiben, was bei einer PIPE nicht geht.

root@Ziel# mkfifo /tmp/fifo

Nun leiten wir den UDP Traffic per nc von Port 8080 um :

root@Ziel# nc -l -p 8080 < /tmp/fifo | nc -u ip.des.dns.servers 53 > /tmp/fifo

Alles was wir auf Port 8080 lesen, geht über die PIP an den NC Befehl, der es an den DNS Server schickt. Seine Antwort geht über das FIFO File zurück zum „Server nc Befehl“ .

Das Gleiche, nur anders rum, brauchen wir auf dem lokalen Server:

root@local# mkfifo /tmp/fifo
root@local# nc -l -u -p 53 < /tmp/fifo | nc localhost 8080 > /tmp/fifo

Auf unserem lokalen Server binden wir uns an den Port 53 und schicken alles, was in dem FIFO File steht an den, der sich auf Port 53 verbunden hat, also z.b. der Befehl dig . Alles was von dig an den Port 53 gesendet wird, geht über die PIPE zum zweiten nc und der leitet das an den Startpunkt unseres Tunnels.

Entweder, man trägt jetzt 127.0.0.1 in die /etc/resolv.conf ein :

nameserver 127.0.0.1

oder man fragt mit dig 127.0.0.1 direkt ab:

dig @127.0.0.1 marius.bloggt-in-braunschweig.de

Das wars schon.