Verschiedene Aspekte des Betriebs von DNS wurden bereits mehrfach vom Autor in einer Reihe von Beiträgen im Rahmen des Blogs angesprochen. Dabei lag der Schwerpunkt stets auf der Verbesserung der Sicherheit dieses für das gesamte Internet wichtigen Dienstes.
Bis vor Kurzem, trotz der offensichtlichen Verwundbarkeit des DNS-Traffics, der größtenteils nach wie vor unverschlüsselt übertragen wird, um schädlichen Aktivitäten von Anbietern, die versuchen, ihre Einnahmen durch Werbung im Inhalt zu steigern, staatlichen Sicherheitsbehörden und Zensur sowie einfach von Kriminellen, war der Prozess , trotz der vorhandenen Technologien wie DNSSEC/DANE, DNScrypt, DNS-over-TLS und DNS-over-HTTPS, ins Stocken geraten. Und während die serverseitigen Lösungen, von denen einige schon seit längerer Zeit existieren, weithin bekannt und verfügbar sind, lässt die Unterstützung ihrer Nutzung durch Client-Software stark zu wünschen übrig.
Glücklicherweise ändert sich die Situation. Insbesondere die Entwickler des beliebten Browsers Firefox haben Pläne angekündigt, den Support für (DoH) in naher Zukunft standardmäßig zu aktivieren. Dies sollte helfen, den DNS-Traffic der WWW-Nutzer gegen die oben genannten Bedrohungen zu schützen, könnte jedoch potenziell neue verursachen.
1. Probleme mit DNS-over-HTTPS
Auf den ersten Blick löst die beginnende Massenimplementierung von DNS-over-HTTPS in Internet-Software nur positive Reaktionen aus. Doch der Teufel, wie man so schön sagt, steckt im Detail.
Das erste Problem, das die massenhafte Anwendung von DoH einschränkt, ist seine ausschließliche Ausrichtung auf Webverkehr. Tatsächlich ist das HTTP-Protokoll und seine aktuelle Version HTTP/2, auf der DoH basiert, die Grundlage des WWW. Aber das Internet ist nicht nur das Web. Es gibt viele beliebte Dienste, wie E-Mail, verschiedene Messenger, Dateitransfersysteme, Streaming von Multimedia und andere, die kein HTTP verwenden. So ist DoH, trotz der Wahrnehmung vieler als Allheilmittel, ohne zusätzliche (und auch nicht notwendige) Anstrengungen nicht für etwas anderes als Browsertechnologien anwendbar. Übrigens erscheint DNS-over-TLS für diese Rolle als weitaus würdigerer Kandidat, da es die Kapselung des Standard-DNS-Verkehrs in das sichere Standardprotokoll TLS realisiert.
Das zweite Problem, das potenziell viel bedeutender ist als das erste, besteht im faktischen Verzicht auf die von Natur aus dezentralisierte DNS-Struktur zugunsten der Nutzung eines einzigen DoH-Servers, der in den Browsereinstellungen festgelegt ist. Insbesondere schlägt Mozilla vor, den Dienst von Cloudflare zu verwenden. Einen ähnlichen Dienst haben auch andere bedeutende Akteure im Internet, insbesondere Google, ins Leben gerufen. Das bedeutet, dass die Einführung von DNS-over-HTTPS in der derzeit vorgeschlagenen Form die Abhängigkeit der Endnutzer von den größten Diensten nur erhöht. Es ist kein Geheimnis, dass Informationen, die durch die Analyse von DNS-Anfragen bereitgestellt werden können, in der Lage sind, noch mehr Daten über ihn zu sammeln und deren Genauigkeit und Relevanz zu erhöhen.
In diesem Zusammenhang ist der Autor ein Befürworter der massenhaften Einführung von nicht DNS-over-HTTPS, sondern DNS-over-TLS in Verbindung mit DNSSEC/DANE als universelles, sicheres und nicht zur weiteren Zentralisierung des Internets beitragendes Mittel zur Sicherstellung der Sicherheit des DNS-Verkehrs. Leider ist eine rasche Einführung einer breiten Unterstützung für Alternativen zu DoH aus verständlichen Gründen nicht zu erwarten, und bisher bleibt es Enthusiasten der sicheren Technologien vorbehalten.
Aber da wir nun DoH erhalten, warum nutzen wir es dann nicht, nachdem wir potenzielle Überwachung durch Unternehmen über deren Server auf unseren eigenen DNS-over-HTTPS-Server umgeleitet haben?
2. Das Protokoll DNS-over-HTTPS
Wenn wir den Standard betrachten Wenn man das Protokoll DNS-over-HTTPS beschreibt, sieht man, dass es im Wesentlichen eine Web-API darstellt, die es ermöglicht, das Standard-DNS-Paket in das HTTP/2-Protokoll zu kapseln. Dies geschieht durch spezielle HTTP-Header sowie durch die Konvertierung des binären Formats der übertragenen DNS-Daten (siehe und nachfolgende Dokumente) in ein Format, das den Austausch und die Bearbeitung der erforderlichen Metadaten ermöglicht.
Der Standard unterstützt nur HTTP/2 und sicheres TLS.
Die Übermittlung von DNS-Anfragen kann mit den Standardmethoden GET und POST erfolgen. Im ersten Fall wird die Anfrage in eine base64URL-codierte Zeichenkette umgewandelt, im zweiten Fall erfolgt dies über den Körper der POST-Anfrage in binärer Form. Bei der Anfrage und der Antwort von DNS wird dabei ein spezieller MIME-Datentyp verwendet, application/dns-message.
root@eprove:~ # curl -H 'accept: application/dns-message' 'https://my.domaint/dns-query?dns=q80BAAABAAAAAAAAB2V4YW1wbGUDY29tAAABAAE' -v
* Versuche 2001:100:200:300::400:443...
* TCP_NODELAY gesetzt
* Verbunden mit eprove.net (2001:100:200:300::400) Port 443 (#0)
* ALPN, bietet h2 an
* ALPN, bietet http/1.1 an
* Zertifikatsprüfstandorte erfolgreich festgelegt:
* CAfile: /usr/local/share/certs/ca-root-nss.crt
CApath: none
* TLSv1.3 (OUT), TLS-Handshake, Client hello (1):
* TLSv1.3 (IN), TLS-Handshake, Server hello (2):
* TLSv1.3 (IN), TLS-Handshake, Verschlüsselte Erweiterungen (8):
* TLSv1.3 (IN), TLS-Handshake, Zertifikat (11):
* TLSv1.3 (IN), TLS-Handshake, CERT prüfen (15):
* TLSv1.3 (IN), TLS-Handshake, Abgeschlossen (20):
* TLSv1.3 (OUT), TLS-Wechsel des Chiffrierens, Änderung der Chiffrierspezifikation (1):
* TLSv1.3 (OUT), TLS-Handshake, Abgeschlossen (20):
* SSL-Verbindung unter Verwendung von TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, Server akzeptiert h2
* Serverzertifikat:
* Betreff: CN=my.domain
* Startdatum: 22. Jul. 00:07:13 2019 GMT
* Ablaufdatum: 20. Okt. 00:07:13 2019 GMT
* subjectAltName: Host "my.domain" stimmte mit dem Zertifikat "my.domain" überein
* Aussteller: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
* SSL-Zertifikat wurde erfolgreich geprüft.
* Verwendung von HTTP2, Server unterstützt Mehrfachnutzung
* Verbindungsstatus geändert (HTTP/2 bestätigt)
* Kopiere HTTP/2-Daten im Stream-Puffer in den Verbindungs-Puffer nach dem Upgrade: len=0
* Verwende Stream-ID: 1 (einfache Handhabung 0x801441000)
> GET /dns-query?dns=q80BAAABAAAAAAAAB2V4YW1wbGUDY29tAAABAAE HTTP/2
> Host: eprove.net
> User-Agent: curl/7.65.3
> accept: application/dns-message
>
* TLSv1.3 (IN), TLS-Handshake, Newsession Ticket (4):
* Verbindungsstatus geändert (MAX_CONCURRENT_STREAMS == 100)!
< HTTP/2 200
< server: h2o/2.3.0-beta2
< content-type: application/dns-message
< cache-control: max-age=86274
< date: Thu, 12 Sep 2019 13:07:25 GMT
< strict-transport-security: max-age=15768000; includeSubDomains; preload
< content-length: 45
<
Warnung: Binärausgaben können Ihr Terminal durcheinanderbringen. Verwenden Sie "--output -", um zu veranlassen, dass
Warnung: curl es dennoch in Ihr Terminal ausgibt, oder ziehen Sie "--output
Warnung: " in Betracht, um in eine Datei zu speichern.
* Schreiben des Körpers fehlgeschlagen (0 != 45)
* Pausestream gestoppt!
* Verbindung #0 zum Host eprove.net blieb intaktBeachten Sie auch den Header cache-control: in der Antwort des Webservers. Im Parameter max-age befindet sich der TTL-Wert für den zurückgegebenen DNS-Eintrag (oder der minimale Wert, wenn eine Menge von ihnen zurückgegeben wird).
In Anbetracht des Vorstehenden besteht die Funktionsweise eines DoH-Servers aus mehreren Phasen.
- HTTP-Anfrage erhalten. Wenn es sich um einen GET handelt, das Paket aus der base64URL-Codierung dekodieren.
- Dieses Paket an den DNS-Server senden.
- Antwort vom DNS-Server erhalten.
- Den minimalen TTL-Wert in den erhaltenen Einträgen finden.
- Die Antwort über HTTP an den Client zurückgeben.
3. Eigenen DNS-over-HTTPS-Server
Die einfachste, schnellste und effektivste Möglichkeit, einen eigenen DNS-over-HTTPS-Server zu starten, besteht darin, einen HTTP/2-Webserver zu verwenden. , über den der Autor bereits kurz geschrieben hat (siehe „«).
Für diese Wahl spricht, dass der gesamte Code des eigenen DoH-Servers vollständig mit dem im H2O integrierten Interpreter realisiert werden kann. Zusätzlich zu den Standardbibliotheken ist für den Datenaustausch mit dem DNS-Server die Bibliothek (mrbgem) Socket erforderlich, die erfreulicherweise bereits in der aktuellen Entwickler-Version H2O 2.3.0-beta2 enthalten ist. in den Ports von FreeBSD. Es ist jedoch nicht schwierig, sie auch in eine frühere Version hinzuzufügen, indem das Repository geklont wird. in das Verzeichnis /deps vor der Kompilierung.
root@beta:~ # uname -v
FreeBSD 12.0-RELEASE-p10 GENERIC
root@beta:~ # cd /usr/ports/www/h2o
root@beta:/usr/ports/www/h2o # make extract
===[0m Lizenz MIT BSD2CLAUSE vom Benutzer akzeptiert
===[0m h2o-2.2.6 hängt von der Datei: /usr/local/sbin/pkg - gefunden
===[0m Holen aller benötigten Distanzdateien für den Bau von h2o-2.2.6
===[0m Extrahieren für h2o-2.2.6.
= SHA256 Checksum OK für h2o-h2o-v2.2.6_GH0.tar.gz.
===[0m h2o-2.2.6 hängt von der Datei: /usr/local/bin/ruby26 - gefunden
root@beta:/usr/ports/www/h2o # cd work/h2o-2.2.6/deps/
root@beta:/usr/ports/www/h2o/work/h2o-2.2.6/deps # git clone https://github.com/iij/mruby-socket.git
Klonen in „mruby-socket“…
remote: Objekte werden gezählt: 385, fertig.
remote: Insgesamt 385 (delta 0), wiederverwendet 0 (delta 0), pack-wiederverwendete 385
Holen von Objekten: 100 % (385/385), 98.02 KiB | 647.00 KiB/s, bereit.
Bestimmen von Änderungen: 100 % (208/208), bereit.
root@beta:/usr/ports/www/h2o/work/h2o-2.2.6/deps # ll
total 181
drwxr-xr-x 9 root wheel 18 12 Aug 16:09 brotli/
drwxr-xr-x 2 root wheel 4 12 Aug 16:09 cloexec/
drwxr-xr-x 2 root wheel 5 12 Aug 16:09 golombset/
drwxr-xr-x 4 root wheel 35 12 Aug 16:09 klib/
drwxr-xr-x 2 root wheel 5 12 Aug 16:09 libgkc/
drwxr-xr-x 4 root wheel 26 12 Aug 16:09 libyrmcds/
drwxr-xr-x 13 root wheel 32 12 Aug 16:09 mruby/
drwxr-xr-x 5 root wheel 11 12 Aug 16:09 mruby-digest/
drwxr-xr-x 5 root wheel 10 12 Aug 16:09 mruby-dir/
drwxr-xr-x 5 root wheel 10 12 Aug 16:09 mruby-env/
drwxr-xr-x 4 root wheel 9 12 Aug 16:09 mruby-errno/
drwxr-xr-x 5 root wheel 14 12 Aug 16:09 mruby-file-stat/
drwxr-xr-x 5 root wheel 10 12 Aug 16:09 mruby-iijson/
drwxr-xr-x 5 root wheel 11 12 Aug 16:09 mruby-input-stream/
drwxr-xr-x 6 root wheel 11 12 Aug 16:09 mruby-io/
drwxr-xr-x 5 root wheel 10 12 Aug 16:09 mruby-onig-regexp/
drwxr-xr-x 4 root wheel 10 12 Aug 16:09 mruby-pack/
drwxr-xr-x 5 root wheel 10 12 Aug 16:09 mruby-require/
drwxr-xr-x 6 root wheel 10 12 Sep 16:10 mruby-socket/
drwxr-xr-x 2 root wheel 9 12 Aug 16:09 neverbleed/
drwxr-xr-x 2 root wheel 13 12 Aug 16:09 picohttpparser/
drwxr-xr-x 2 root wheel 4 12 Aug 16:09 picotest/
drwxr-xr-x 9 root wheel 16 12 Aug 16:09 picotls/
drwxr-xr-x 4 root wheel 8 12 Aug 16:09 ssl-conservatory/
drwxr-xr-x 8 root wheel 18 12 Aug 16:09 yaml/
drwxr-xr-x 2 root wheel 8 12 Aug 16:09 yoml/
root@beta:/usr/ports/www/h2o/work/h2o-2.2.6/deps # cd ../../..
root@beta:/usr/ports/www/h2o # make install clean
...Die Konfiguration des Webservers ist insgesamt Standard.
root@beta:/usr/ports/www/h2o # cd /usr/local/etc/h2o/
root@beta:/usr/local/etc/h2o # cat h2o.conf
# diese Beispielkonfiguration gibt Ihnen ein Gefühl dafür, wie h2o verwendet werden kann
# und eine hochsichere Konfiguration für TLS und HTTP-Header
# siehe https://h2o.examp1e.net/ für ausführliche Dokumentation
# und h2o --help für Befehlszeilenoptionen und Einstellungen
# v.20180207 (c)2018 von Max Kostikov http://kostikov.co E-Mail: max@kostikov.co
user: www
pid-file: /var/run/h2o.pid
access-log:
path: /var/log/h2o/h2o-access.log
format: "%h %v %l %u %t "%r" %s %b "%{Referer}i" "%{User-agent}i""
error-log: /var/log/h2o/h2o-error.log
expires: off
compress: on
file.dirlisting: off
file.send-compressed: on
file.index: [ 'index.html', 'index.php' ]
listen:
port: 80
listen:
port: 443
ssl:
cipher-suite: ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
cipher-preference: server
dh-file: /etc/ssl/dhparams.pem
certificate-file: /usr/local/etc/letsencrypt/live/eprove.net/fullchain.pem
key-file: /usr/local/etc/letsencrypt/live/my.domain/privkey.pem
hosts:
"*.my.domain":
paths: &go_tls
"/":
redirect:
status: 301
url: https://my.domain/
"my.domain:80":
paths: *go_tls
"my.domain:443":
header.add: "Strict-Transport-Security: max-age=15768000; includeSubDomains; preload"
paths:
"/dns-query":
mruby.handler-file: /usr/local/etc/h2o/h2odoh.rbDie Ausnahme bildet lediglich der URL-Handler /dns-query für den unser DNS-over-HTTPS-Server verantwortlich ist, der in mruby geschrieben ist und über die Handler-Option aufgerufen wird mruby.handler-file.
root@beta:/usr/local/etc/h2o # cat h2odoh.rb
# H2O HTTP/2-Webserver als DNS-over-HTTP-Dienst
# v.20190908 (c)2018-2019 Max Kostikov https://kostikov.co E-Mail: max@kostikov.co
proc {|env|
if env['HTTP_ACCEPT'] == "application/dns-message"
case env['REQUEST_METHOD']
when "GET"
req = env['QUERY_STRING'].gsub(/^dns=/,'')
# base64URL dekodieren
req = req.tr("-_", "+/")
if !req.end_with?("=") && req.length % 4 != 0
req = req.ljust((req.length + 3) & ~3, "=")
end
req = req.unpack1("m")
when "POST"
req = env['rack.input'].read
else
req = ""
end
if req.empty?
[400, { 'content-type' => 'text/plain' }, [ "Bad Request" ]]
else
# --- Frage den DNS-Server
sock = UDPSocket.new
sock.connect("localhost", 53)
sock.send(req, 0)
str = sock.recv(4096)
sock.close
# --- finde die niedrigste TTL in der Antwort
nans = str[6, 2].unpack1('n') # Anzahl der Antworten
if nans > 0 # kein DNS-Fehler
shift = 12
ttl = 0
while nans > 0
# verarbeite die Domänennamenkompression
if str[shift].unpack1("C") curttl
ttl = curttl
end
nans -= 1
end
cc = 'max-age=' + ttl.to_s
else
cc = 'no-cache'
end
[200, { 'content-type' => 'application/dns-message', 'content-length' => str.size, 'cache-control' => cc }, [ str ] ]
end
else
[415, { 'content-type' => 'text/plain' }, [ "Unsupported Media Type" ]]
end
}Bitte beachten Sie, dass der lokale zwischenspeichernde Server für die Verarbeitung von DNS-Paketen verantwortlich ist, in diesem Fall aus der Standardauslieferung von FreeBSD. Aus sicherheitstechnischer Sicht ist dies die optimale Lösung. Nichts hindert jedoch daran, localhost die Adresse eines anderen DNS zu ersetzen, den Sie wahrscheinlich verwenden möchten.
root@beta:/usr/local/etc/h2o # local-unbound version
usage: local-unbound [options]
startet den unbound-Daemon als DNS-Resolver.
-h diese Hilfe
-c datei Konfigurationsdatei anstelle von /var/unbound/unbound.conf lesen
das Dateiformat wird in unbound.conf(5) beschrieben.
-d nicht im Hintergrund abspalten.
-p keine pid-Datei erstellen.
-v ausführlich (mehrmaliges Erhöhen der Ausführlichkeit)
Version 1.8.1
verlinkte libs: mini-event intern (nutzt select), OpenSSL 1.1.1a-freebsd 20. Nov 2018
verlinkte Module: dns64 respip validator iterator
BSD lizenziert, siehe LICENSE im Quellpaket für Details.
Berichte Bugs an unbound-bugs@nlnetlabs.nl
root@eprove:/usr/local/etc/h2o # sockstat -46 | grep unbound
unbound local-unbo 69749 3 udp6 ::1:53 *:*
unbound local-unbo 69749 4 tcp6 ::1:53 *:*
unbound local-unbo 69749 5 udp4 127.0.0.1:53 *:*
unbound local-unbo 69749 6 tcp4 127.0.0.1:53 *:*Es bleibt, H2O neu zu starten und zu sehen, was dabei herausgekommen ist.
root@beta:/usr/local/etc/h2o # service h2o restart
H2O wird gestoppt.
Warten auf PIDS: 69871.
H2O wird gestartet.
start_server (pid:70532) startet jetzt...4. Testen
Lassen Sie uns die Ergebnisse überprüfen, indem wir eine Testanfrage erneut senden und den Netzwerkverkehr mit dem Tool beobachten. tcpdump.
root@beta/usr/local/etc/h2o # curl -H 'accept: application/dns-message' 'https://my.domain/dns-query?dns=q80BAAABAAAAAAAAB2V4YW1wbGUDY29tAAABAAE'
Warnung: Binärausgabe kann Ihr Terminal durcheinanderbringen. Verwenden Sie "--output -", um
Warnung: curl anzuweisen, es dennoch in Ihr Terminal auszugeben, oder ziehen Sie "--output
Warnung: " in Betracht, um es in einer Datei zu speichern.
...
root@beta:~ # tcpdump -n -i lo0 udp port 53 -xx -XX -vv
tcpdump: hört auf lo0, Linktyp NULL (BSD Loopback), Erfassungsgröße 262144 Bytes
16:32:40.420831 IP (tos 0x0, ttl 64, id 37575, offset 0, flags [none], proto UDP (17), Länge 57, fehlerhafte Prüfziffer 0 (->e9ea)!)
127.0.0.1.21070 > 127.0.0.1.53: [fehlerhafte UDP-Prüfziffer 0xfe38 -> 0x33e3!] 43981+ A? example.com. (29)
0x0000: 0200 0000 4500 0039 92c7 0000 4011 0000 ....E..9....@...
0x0010: 7f00 0001 7f00 0001 524e 0035 0025 fe38 ........RN.5.%.8
0x0020: abcd 0100 0001 0000 0000 0000 0765 7861 .............exa
0x0030: 6d70 6c65 0363 6f6d 0000 0100 01 mple.com.....
16:32:40.796507 IP (tos 0x0, ttl 64, id 37590, offset 0, flags [none], proto UDP (17), Länge 73, fehlerhafte Prüfziffer 0 (->e9cb)!)
127.0.0.1.53 > 127.0.0.1.21070: [fehlerhafte UDP-Prüfziffer 0xfe48 -> 0x43fa!] 43981 q: A? example.com. 1/0/0 example.com. A 93.184.216.34 (45)
0x0000: 0200 0000 4500 0049 92d6 0000 4011 0000 ....E..I....@...
0x0010: 7f00 0001 7f00 0001 0035 524e 0035 fe48 .........5RN.5.H
0x0020: abcd 8180 0001 0001 0000 0000 0765 7861 .............exa
0x0030: 6d70 6c65 0363 6f6d 0000 0100 01c0 0c00 mple.com........
0x0040: 0100 0100 0151 8000 045d b8d8 22 .....Q...].."
^C
2 Pakete erfasst
23 Pakete vom Filter empfangen
0 Pakete vom Kernel verworfenIm Output ist zu sehen, wie die Anfrage zur Auflösung der Adresse example.com empfangen und erfolgreich vom DNS-Server verarbeitet wurde.
Jetzt müssen wir unseren Server im Browser Firefox aktivieren. Dazu sollten auf der Konfigurationsseite einige Einstellungen geändert werden. about:config.
Zunächst ist das die Adresse unserer API, über die der Browser DNS-Informationen anfordert in network.trr.uri. Es wird auch empfohlen, die IP des Domänen aus dieser URL für eine sichere Auflösung in IP direkt im Browser anzugeben, ohne an DNS zu gehen in network.trr.bootstrapAddress. Und schließlich der Parameter network.trr.mode der die Verwendung von DoH aktiviert. Eine Einstellung des Wertes auf "3" zwingt den Browser dazu, ausschließlich DNS-over-HTTPS zur Namensauflösung zu verwenden, während zuverlässiger und sicherer "2" DoH priorisiert und die Standardanfragen an DNS als Reserveoption belässt.
5. PROFIT!
War der Artikel hilfreich? Dann zögern Sie nicht, uns finanziell über das untenstehende Spendenformular zu unterstützen.
Quelle: habr.com
