Sessionbericht
Teilnehmende: @nik , @krfl9500 , @mwinter , @magicfelix , @pinguin
Was passiert bei …
ping teckids.org
Es werden ECHO-Responses angezeigt. Wie kommt es dazu?
Das ping-Utility findet heraus, welche IP-Adresse zum Namen teckids.org gehört und schickt ECHO-Requests dorthin.
Aktuell genutztes Netzwerkinterface herausfinden
ip route get <IP-Adresse> → dev …
Mit Wireshark Netzwerktraffic anschauen
Netzwerktraffic des eben herausgefundenen Netzwerkinterfaces mitschneiden.
ping ausführen.
Mitschnitt stoppen und nach DNS suchen.
ping fragt nach A-Record für teckids.org
bekommt Antwort
nach ICMP suchen: Wir sehen die ping-Requests und -Responses.
Diese haben jeweils Source- und Destination-Adresse. Nur IP-Adressen, nicht der Name teckids.org
Zusammenfassung: Beim Ausführen von ping passieren 2 Dinge:
Erst wird das DNS befragt, welche IP-Adresse zum Namen teckids.org gehört.
Anschließend wird nur noch diese IP-Adresse verwendet. Die ursprüngliche Information mit teckids.org kommt nicht mehr vor
Das host-Kommando
host teckids.org zeigt mehrere Adressen zu dem Hostnamen an.
Die IPv4-Adresse (A-Record), die IPv6-Adresse (AAAA-Record) und den zuständigen Mail-Server (MX-Record). Jeweils falls vorhanden.
In die andere Richtung abfragen: IP-Adresse zu Hostname.
host aleksis.org → 91.184.37.248
host 91.184.37.248 → pages.edugit.org.
Da man nicht für jede Website einen eigenen Server haben möchte, können mehrere Hostnamen (z.B. aleksis.org und kalle.lol) auf dieselbe IP-Adresse zeigen.
Andersherum darf es pro IP-Adresse nur einen sog. Pointer (PTR-Record) geben, der auf einen Hostnamen verweist – in diesem Fall pages.edugit.org.
Mit dig speziellere DNS-Anfragen machen
dig teckids.org TXT TXT-Records zu teckids.org abfragen.
dig _xmpp-client._tcp.mercurius.teckids.org SRV SRV-Records abfragen
curl https://teckids.org/
Wieder mit Wireshark herausfinden:
Erst wird eine DNS-Abfrage gemacht.
Anschließend wird über die als Antwort erhaltene IP-Adresse mit dem Server kommuniziert.
Da auf dieser Ebene kein Hostname enthalten ist, kann man auf der Netzwerkebene nicht sehen, welche Website angefragt wurde.
Damit man trotzdem die richtige Website angezeigt bekommt, schickt das curl-Kommando über die aufgebaute Netzwerkverbindung, welcher Hostname und welche URL ursprünglich angegeben wurden.
Wenn die Verbindung verschlüsselt wird (HTTPs) wird dieser Inhalt von außen unlesbar. Allerdings muss vor dem Aufbau der Verschlüsselung bekannt sein, welcher Hostname angefragt wird (um das richtige Zertifikat auszuwählen), sodass dies unverschlüsselt geschieht. Alles danach, also z.B. welchen Pfad man anfragt, werden verschlüsselt übertragen.
mail -s Test nik@teckids.org
Eine E-Mail wird versendet. Dabei spielt Authentifizerung ggf. eine wichtige Rolle.
Ausführlicheres zu dem Thema
Woher kommen Antworten auf DNS-Anfragen?
dig +trace ticdesk.teckids.org
Zuerst werden die Root-Nameserver gefragt, dessen IP-Adressen im System hinterlegt sind, wer für org zuständig ist.
Anschließend fragen wir die für org zuständigen Nameserver, wer für teckids.org zuständig ist.
Die Nameserver, die für teckids.org zuständig sind, werden vom Teckids e.V. verwaltet. Für alles ab teckids.org und darunter liefern sie die Antworten aus.
Exkurs Cookies
Websites können Daten im Browser speichern. Ein solcher Cookie ist immer einer Domain zugeordnet und darf nur von dieser, und von Subdomains, wieder ausgelesen werden.
Mit der Option lax dürfen auch nebenliegende Domains, also z.B. forum.teckids.org, einen Cookie von ticdesk.teckids.org auslesen.
Damit das nicht misbraucht wird, gibt es die Public-Suffix-List. Dort kann man Domains eintragen, über dessen Subdomains man keine Kontrolle hat, z.B. weil fremde Leute sich Subdomains registrieren können. Das bewirkt, dass direkte Subdomains der eigetragenen Domain nicht mehr Cookies ihrer Nachbarn auslesen dürfen.
URLs
Aufbau einer URL wie https://teckids.org/projekte/indiedact/verstehbarkeit/
https ist das Scheme (Protokoll https)
teckids.org der Hostname
/projekte/indiedact/verstehbarkeit der Pfad (HTTP-spezifisch)
All diese Informationen, und noch mehr (z.B. der User-Agent und die Client-IP-Adresse) tauchen in den Logs eines Webservers auf.
Verantwortung
Wenn bspw. über einen Mailserver Spam versendet wird, hat man verschiedene Möglichkeiten, Verantwortliche Parteien zu kontaktieren.
Entweder über die Domain (whois <DOMAIN>), oder über die IP-Adresse (whois <IP-Adresse>).
Bei einer Domain gibt es eine Partei, der die Domain gehört, eine Partei, die sie administiert und eine Partei, die für Technisches verantwortlich ist.
Das Telemediengesetz
… ist zwar außer Kraft, aber verständlicher als das neue Digitale-Dienste-Gesetz.
Wenn man eine Website o.Ä. betreibt, ist man Dienstanbieter. Damit geht Verantwortung einher, z.B. für Daten die man überträgt.
Diese Verantwortung kann man erst mit 18 Jahren übernehmen. Daher haben quasi alle Anbieter für Domains diese Altersgrenze in ihren AGB stehen.
Passiert etwas mit einer Domain, die auf irgendeinem Weg jemandem unter 18 Jahre gehört, kann entweder niemand verantwortlich gemacht werden, oder aber die Stelle in der Verantwortungskette, die (bewusst oder durch mangelnde Überprüfung) die 18-Jahre-Grenze nicht eingehalten hat.
Dies ist also das Risiko, wenn man für eine andere Person, die diese Verantwortung per Gesetz noch nicht übernehmen kann, eine Domain registriert.
Record-Typen:
A IPv4-Adresse
AAAA IPv6-Adresse
MX zuständige Mailserver
TXT Textdaten
SRV Netzwerkdienste