Klicktafel · Informatik · Oberstufe und Fortbildung

Vom Klick zur Webseite

Wie ein eigener Server sicher läuft und wie man mit KI daran arbeitet. Eine Rundfahrt durch den Hafen hinter lernwerft.example: vom Telefonbuch über den Pförtner bis zum Depot hinter dem Deich.

Der Kern in einem SatzJedes Bauteil hat eine Aufgabe. Wer weiß, was ohne es schiefginge, versteht den ganzen Server.

Deine Aufgabe: Verfolge eine Anfrage an lernwerft.example durch den ganzen Hafen. Halte für jedes Bauteil fest: Was macht es? Warum gibt es das? Was ginge schief ohne? Befehle auswendig lernen musst du nicht.

Alle Namen sind erfunden: lernwerft.example ist eine reservierte Beispieladresse; NamensAmt (Domain und DNS), ServerHafen (gemieteter virtueller Server, VPS), DeichDepot (Backup-Speicher) und CodeLotse (Coding-KI) gibt es nicht. Echt sind die Techniken und Werkzeuge: DNS, SSH, Firewall, Caddy, Docker, GitHub, Tailscale, restic, Time Machine.

DNSIP-AdressePortFirewallHTTPSContainerSSH-SchlüsselBackupPull RequestReverse ProxyUIDACMEAVV

Einstieg

Ein Klick – und wer ist alles dabei?

Der Server ruht nie. Nächstes nächtliches Backup in

--:--:--

03:30 Uhr Der Server bei ServerHafen sichert sich verschlüsselt ins DeichDepot. Die Uhr zählt nach der Uhrzeit dieses Geräts.

Du tippst lernwerft.example ein. Wer ist alles beteiligt, bis die Seite erscheint?

Auftrag: Tippt alle an, die ihr für beteiligt haltet. Dann „Auflösen“.

Überblick · Der Hafenplan

Sechs Bauteile, ein Hafen

Hafenbild: der ganze Hafen · Fachbegriff: Architektur

Auftrag: Baut den Hafen Schritt für Schritt auf. Vermutet bei jedem Bauteil zuerst: Was ginge schief ohne? Dann aufdecken.

Internet Browser Schul-iPad DNS bei NamensAmt lernwerft.example → 203.0.113.42 Server (VPS) bei ServerHafen 22 80 443 SSH-Zugang Pförtner Caddy einfache Seiten /srv/lernwerft nur intern: 127.0.0.1 Quiz-App :3000 Quiz-DB Daten Kalender-App :3001 Kalender-DB Daten DeichDepot anderer Anbieter nachts 03:30, restic + Schnappschüsse Laptop holt wöchentlich, Zugang nur lesen Time Machine Platte A zu Hause Platte B anderes Gebäude Farbcode draußen Schutz nur drinnen Sicherung KI (Station 6)

 

Anfrage schicken:

Bauteil 1 von 6

draußen

Browser

Was macht es?
Warum gibt es das?
Was ginge schief ohne?

Station 1 · Der Weg einer Anfrage

Wo wohnt lernwerft.example – und welche Tür ist offen?

Telefonbuch = DNS · Hafenmauer = Firewall · Tür = Port

Auftrag: Schlagt die Adresse nach. Begründet dann für jede Tür: offen oder zu? Achtung bei 3000: Dort läuft doch die Quiz-App!

1 · Im Telefonbuch nachschlagen

BrowserWelche IP-Adresse hat lernwerft.example?
DNSEintrag bei NamensAmt

Noch nicht nachgeschlagen.

Namen sind für Menschen, Nummern für Computer. Zieht der Server um, ändert man nur den Eintrag. Wer ihn ändern kann, lenkt alle Besucher um.

Name und Nummer sind für Beispiele reserviert, im echten Internet gibt es sie nicht.

Bei einer echten Domain (z. B. .de): Resolver → Root → Nameserver für .de → NamensAmt; Antworten werden zwischengespeichert (TTL). Reserviert: RFC 2606, 5737.

2 · Klopft an die Türen der Hafenmaueroffen gefunden: 0

Tippt eine Tür an.

Ein Server hat 65 535 Türen (Ports), je für TCP und UDP.

Firewall z. B. ufw oder nftables. Achtung Docker: Von Docker veröffentlichte Ports umgehen ufw. Darum Apps nur an 127.0.0.1 binden: "127.0.0.1:3000:3000" (zuverlässig ab Docker 28).

Station 1 · Der Weg einer Anfrage

Der Pförtner: Welche Anfrage geht wohin?

Pförtner = Caddy · Fachbegriff: Webserver, Reverse Proxy

Auftrag: Wählt eine Adresse. Sagt voraus, was der Pförtner damit macht. Dann tippt sie an.

Ins Adressfeld getippt

Wählt eine Adresse.

zurück: „Bitte über https://“ Anfrageaus dem Netz 80 443 3000 PförtnerCaddy einfache Seiten/srv/lernwerft Quiz-App im Container127.0.0.1:3000 Kalender-App im Container127.0.0.1:3001

Das Zertifikat: Ohne Zertifikat kein HTTPS. Caddy holt es sich selbst und erneuert es rechtzeitig.

Per ACME von einer Zertifizierungsstelle; Prüfung über Port 80 (HTTP-01) oder 443 (TLS-ALPN-01). Rechts: Ausschnitt aus der Konfiguration.

lernwerft.example {
  handle_path /quiz/* {
    reverse_proxy 127.0.0.1:3000
  }
  handle {
    root * /srv/lernwerft
    file_server
  }
}

Station 2 · Docker

Jede App in ihrem eigenen Container

Schiffscontainer = Docker-Container

Auftrag: Spielt ein paar Quizrunden. Vermutet dann: Was passiert mit den Ergebnissen, wenn die Container neu gebaut werden? Probiert beide Varianten.

Die Ergebnisse liegen
Quiz-AppContainer
Quiz-DBContainer
Kalender-AppContainer
Kalender-DBContainer
LagerDaten außerhalb (Volume oder Ordner)

Gespeicherte Quiz-Ergebnisse: 3

Wie ein Schiffscontainer

  • genormtBringt alles mit, was die App braucht. Läuft darum auf jedem Linux-Server mit Docker gleich.
  • abgeschlossenEigene Programme, eigene Datenbank. Apps kommen sich kaum in die Quere.
  • austauschbarFür ein Update wegwerfen und neu bauen. Darum gehören die Daten nach draußen.

Aber: Abgeschlossen heißt nicht dicht. Alle Container teilen sich den Kern des Betriebssystems (Kernel).

Container ≠ virtuelle Maschine: gemeinsamer Linux-Kernel, Abschottung über Namespaces, Grenzen für Rechenzeit und Speicher über cgroups. Daten in Volumes oder Bind Mounts, z. B. ./quiz-daten:/data.

Station 2 · Docker

Wer ist der Container, wenn er ausbricht?

Fachbegriff: Benutzernummer (UID)

Auftrag: Wählt eine Benutzernummer für den Quiz-Container. Vermutet: Was erbeutet ein Angreifer, der ausbricht? Dann „Ausbruch!“.

Der Quiz-Container läuft als …

Echter Fund:Bei einer Überprüfung lief ein Container mit derselben Nummer wie der hafenmeister, der Admin-Benutzer.

Ganzer ServerProgramme, Firewall, alle Benutzer–
hafenmeisterseine Dateien, Liste der erlaubten Schlüssel–
werkstattEntwicklungsordner–
Quiz-Datengehören dem Quiz-Container–
Kalender-Datengehören dem Kalender-Container–

Linux erkennt Benutzer an der Nummer, nicht am Namen. Ohne Zusatzschutz ist Nummer 1000 im Container dieselbe wie 1000 auf dem Server.

In Docker Compose: user: "10001:10001". Viele fertige Images bringen Benutzer 1000 mit; 1000 ist unter Linux oft der erste angelegte Mensch. Zusatzschutz: User Namespaces (userns-remap) oder rootless Docker.

Station 3 · Rollen und Rechte

Jeder bekommt nur die Rechte, die er braucht

Hafenmeister, Werkstatt = Benutzer · Fachbegriff: Prinzip der minimalen Rechte

Auftrag: Tippt die Felder an: Wer darf was? (einmal = ✓ darf, noch einmal = ✗ darf nicht). Dann vergleicht mit der Lösung.

sich per SSH anmeldenTestserver startenApps veröffentlichenServer verwaltenechte Quiz-Daten ändern
hafenmeisterAdmin
werkstattEntwicklung
Dienst „quiz“die Quiz-App

Faustregel

Jeder bekommt nur die Rechte, die er wirklich braucht. Das gilt für Menschen, Dienste und Container.

Mitglied der Gruppe docker zu sein, wirkt wie Administrator-Rechte (Docker-Doku); werkstatt gehört nicht hinein. Dienstbenutzer mit Shell /usr/sbin/nologin; SSH nur für AllowUsers hafenmeister werkstatt. Grundsatz nach Saltzer und Schroeder (1975): „least privilege“.

Station 4 · Sicherer Zugang

Schlüssel statt Passwort – einer pro Gerät

Schloss am Server, Schlüssel in der Tasche = SSH-Schlüsselpaar

Auftrag: Das iPad geht verloren. Was müsst ihr tun? Vermutet für beide Varianten, dann tippt „iPad verloren“.

Server: erlaubte Schlösser

Der öffentliche Schlüssel ist das Schloss am Server; ihn darf jeder sehen. Der private Schlüssel bleibt auf dem Gerät, geschützt durch eine Passphrase.

Drei Regeln für die Tür 22

  • 1Anmelden nur mit Schlüssel. Passwörter lassen sich durchprobieren.
  • 2Nie direkt als root. Den Namen root kennt jeder, und root hat sofort alles. Man meldet sich als hafenmeister oder werkstatt an.
  • 3Beim ersten Verbinden den Fingerabdruck des Servers prüfen. Sonst merkt man nicht, wenn sich jemand dazwischenschiebt.

Technisch: Das Gerät unterschreibt mit dem privaten Schlüssel eine Kennung, die nur für diese Verbindung gilt; der Server prüft mit dem öffentlichen (RFC 4252). In sshd_config: PasswordAuthentication no, KbdInteractiveAuthentication no, PermitRootLogin no; prüfen mit sudo sshd -T.

Station 4 · Sicherer Zugang

Drei Situationen: Was tut ihr?

Fachbegriffe: Fingerabdruck, Zwei-Faktor, Tunnel

Auftrag: Lest die Situation, entscheidet gemeinsam, dann „Auflösen“.

Beim ersten Verbinden zeigt SSH einen Fingerabdruck des Servers, den ihr nicht kennt.

Das Passwort eures Kontos bei ServerHafen taucht in einem Datenleck auf.

Im Schul-WLAN kommt keine SSH-Verbindung zum Server zustande, zu Hause klappt sie.

Station 5 · Backup

Drei Kopien, zwei Medien, eine außer Haus

DeichDepot = Backup bei einem anderen Anbieter · Fachbegriff: 3-2-1-Regel

Auftrag: Wählt ein Unglück. Vermutet zuerst: Welche Kopie rettet uns?

3 Kopien (hier sogar 5)2 Medien (Netzspeicher, Festplatten)1 außer Haus

Server–

bei ServerHafen, das Original

jede Nacht 03:30

DeichDepot–

mit restic: verschlüsselt, versioniert; dazu eigene Schnappschüsse

wöchentlich, Zugang nur lesen

Laptop–

holt sich eine Kopie

Time Machine

Platte A–

verschlüsselt, zu Hause

Platte B–

verschlüsselt, anderes Gebäude

Gezählt: Server, Depot, Laptop, Platte A und B. restic: AES-256, Snapshots; der Server darf nur hinzufügen (append-only), aufgeräumt wird von anderswo (forget --prune). Passwort auch außerhalb des Servers aufbewahren.

Was passiert, wenn …

Wählt ein Unglück.

Station 5 · Backup

Drei Merksätze, die Backups retten

Fachbegriffe: Synchronisation, Wiederherstellung, Totmannschalter

Auftrag: Probiert jeden Kasten aus. Formuliert danach jeden Merksatz in eigenen Worten.

1 · Sync ist kein Backup

Sync
Laptop
    Cloud
      Backup
      Server
        Depot, Stand gestern

          Sync spiegelt jede Änderung, auch Löschen und Verschlüsseln.

          2 · Erst die Wiederherstellung zählt

          1. ✓Sicherung von letzter Nacht auswählen
          2. ✓mit dem Passwort entschlüsseln
          3. ✓auf einen Testrechner zurückspielen
          4. ✓App starten, Daten prüfen

          Ein Backup gilt erst, wenn die Wiederherstellung getestet ist. Ohne Passwort ist die verschlüsselte Sicherung wertlos.

          Datenbanken vorher als Dump sichern; der Test zeigt, ob es klappt.

          3 · Der Totmannschalter

          Nach jedem Backup schickt der Server eine Erfolgsmeldung an einen Alarmdienst. Bleibt sie aus, meldet sich der Dienst.

          Station 6 · Arbeiten mit KI

          KI hilft – ein Mensch entscheidet

          Lotse = Coding-KI · Repository = Projektordner mit allen Versionen

          Auftrag: Tippt die Wege an. Wo entscheidet ein Mensch? Wer kommt nicht an den Server?

          abgeschottete Cloud-Umgebung planen, mitprüfen tippt selbst Pull Request prüft,übernimmt holt ab (Pull) ✗ kein Zugang zum Server Chat-KIplanen, erklären,Befehle vorbereiten Menschprüft und entscheidet Servereinfache Seiten: holt selbstApps: von Hand CodeLotsearbeitet am Code, auchwenn der Laptop zu ist GitHubDrehscheibe undGedächtnis des Codes

          Tippt einen Weg an.

          Wie ein Lotse berät die KI; entscheiden muss ein Mensch. Ihre Vorschläge klingen überzeugend und können trotzdem falsch sein. GitHub ist Drehscheibe und Gedächtnis: Frühere Versionen bleiben gespeichert, jede Änderung ist nachvollziehbar.

          Station 6 · Arbeiten mit KI

          Wie weit kommt ein Fehler?

          Fachbegriffe: Pull statt Push, Reichweite eines Schadens

          Auftrag: Wählt einen Fall. Vermutet zuerst, wie weit der Schaden reicht. Beim GitHub-Fall: Schaltet zwischen Pull und Push um.

          Der Fall

          Veröffentlichen per

          Wählt einen Fall.

          Nicht verwechseln: Ein Pull Request ist ein Änderungsvorschlag. „Pull“ beim Veröffentlichen heißt: Der Server holt ab.

          Reichweite des Schadensunten klein, oben groß

          1ein VorschlagPull Request oder Befehl im Chat, noch nicht umgesetzt–
          2der Code bei GitHubfrühere Versionen lassen sich meist zurückholen–
          3die einfachen Seitenholt der Server automatisch–
          4Apps und ihre Datenveröffentlicht der hafenmeister von Hand–
          5der ganze Serveralle Einstellungen, alle Daten–

          Push-Deployment, z. B. über GitHub Actions mit einem SSH-Schlüssel als Secret: Wer Schreibrechte am Repository hat, kann die Secrets benutzen. Einschränken lässt sich das, ganz ohne Schlüssel ist es sicherer.

          Station 7 · Datenschutz

          Wer erfährt, dass du die Seite besuchst?

          Fachbegriffe: personenbezogene Daten, Auftragsverarbeitung

          Auftrag: Schaltet die fremden Server an und aus. Zählt: Wer bekommt eure IP-Adresse?

          Dein Browseröffnet lernwerft.example
          lernwerft.exampleder Server, den du besuchen willst
          fremder Schriftenserverbekommt IP-Adresse, Uhrzeit, besuchte Website
          fremder Bibliotheksserverbekommt IP-Adresse, Uhrzeit, besuchte Website

          Webserver, die deine IP-Adresse bekommen: 2 davon 1 fremder

          Das Netz und das DNS sehen sie ohnehin (Station 1).

          LG München I, 20.01.2022: Eine Website ließ Google Fonts von Google-Servern laden. So ging die IP-Adresse eines Besuchers ohne Einwilligung an Google. Rechtswidrig, weil man die Schrift auch auf dem eigenen Server einbinden kann: 100 € Schadensersatz.

          Vier Regeln für den eigenen Server

          • 1Schriften und Bibliotheken selbst hosten: Sie liegen auf dem eigenen Server.
          • 2Vertrag zur Auftragsverarbeitung (AVV) mit ServerHafen und DeichDepot: Sie verarbeiten Daten in unserem Auftrag.
          • 3Logs nur begrenzt aufheben. Auch sie enthalten IP-Adressen.
          • 4Nur so viele Daten wie nötig. Was man nicht speichert, kann nicht verloren gehen.

          DSGVO: Art. 28 (Auftragsverarbeitung), Art. 5 Abs. 1 lit. c (Datenminimierung) und lit. e (Speicherbegrenzung). Urteil: Az. 3 O 17493/20, Art. 82 DSGVO. IP-Adressen können personenbezogen sein (EuGH, 19.10.2016, C-582/14, Breyer). Diese Klicktafel lädt ihre Schriften aus dem eigenen Ordner schriften/.

          Station 8 · Was die Überprüfung fand

          Vier echte Funde – und was sie lehren

          Fachbegriff: Bestandsaufnahme (Audit)

          Auftrag: Lest einen Fund. Was kann passieren? Welche Station hätte ihn verhindert? Erst überlegen, dann aufdecken.

          1

          Sicherungskopien lagen im öffentlichen Webordner und waren abrufbar.

          2

          Eine Verwaltungsschnittstelle des Webservers war für jeden Benutzer auf dem Server erreichbar.

          3

          Alte Testserver liefen wochenlang weiter und belegten fast die Adresse einer echten App.

          4

          Es gab kein externes Backup, nur Kopien auf derselben Festplatte.

          Eine Infrastruktur wächst nach und nach. Regelmäßig mit einer Bestandsaufnahme prüfen, statt der alten Doku zu glauben.

          Bestandsaufnahme z. B. mit ss -tlnp, docker ps -a, systemctl list-timers, Blick in den Webordner. Fund 2 bei Caddy: Admin-API auf localhost:2019; besser als Unix-Socket mit Dateirechten (admin unix//…).

          Abschluss

          Welches Bauteil hilft bei welchem Problem?

          Auftrag: Tippt erst ein Problem an, dann das passende Bauteil (oder umgekehrt). Jedes Bauteil passt genau einmal.

          Zu A: Ports, die Docker veröffentlicht, umgehen ufw. Darum Apps zusätzlich nur an 127.0.0.1 binden (Station 1).

          Hinweise für Lehrkräfte

          Zielgruppe

          Lehrkräftefortbildung, Lehramtsstudierende (z. B. Informatik, Technik, Medienbildung) und interessierte Oberstufe; auch zum Selbstlernen. Vorwissen: keins nötig; hilfreich ist eine Vorstellung davon, was ein Server ist. Der Umschalter Fortbildung blendet Konfigurationszeilen, Rechtsquellen und technische Details ein.

          Ziel ist die Gesamtarchitektur, nicht das Auswendiglernen von Befehlen. Zu jedem Bauteil drei Fragen: Was macht es? Warum gibt es das? Was ginge schief ohne?

          Zeitbedarf

          90 Minuten (Fortbildungsblock oder Doppelstunde) für alle Stationen. 45 Minuten als Kurzfassung mit Einstieg, Hafenplan und den Stationen 1, 2, 5 und 6. Alternativ zwei Einzelstunden: Einstieg bis Station 3 (41′, Rest für Fragen), dann Stationen 4 bis 8 (44′); die Zuordnung zu Beginn der Folgestunde. Zum Selbstlernen alle Stationen im eigenen Tempo.

          Ablauf in 90 Minuten

          1. 5′ Einstieg: Countdown laufen lassen. Die Gruppe tippt alle Beteiligten an, dann „Auflösen“.
          2. 10′ Hafenplan: Bauteil für Bauteil aufbauen, jeweils erst vermuten „Was ginge schief ohne?“. Danach beide Anfragen losschicken.
          3. 10′ Station 1: DNS nachschlagen, Türen raten und prüfen; dann die vier Adressen beim Pförtner vorhersagen.
          4. 10′ Station 2: Container mit Daten innen und außen neu bauen; Benutzernummer wählen und „Ausbruch!“.
          5. 6′ Station 3: Rechte-Tabelle in Partnerarbeit ausfüllen, vergleichen.
          6. 10′ Station 4: iPad verloren in beiden Varianten; drei Situationen entscheiden.
          7. 12′ Station 5: Unglücke durchspielen; drei Merksätze ausprobieren und formulieren.
          8. 12′ Station 6: Wege tippen, Fälle mit Pull und Push vergleichen. In Fortbildungen: eigene KI-Nutzung einordnen.
          9. 5′ Station 7: Fremde Server an- und ausschalten, vier Regeln.
          10. 5′ Station 8: Funde in Gruppen aufdecken, Station zuordnen.
          11. 5′ Abschluss: Zuordnung an der Tafel.

          Kurzfassung in 45 Minuten

          1. 5′ Einstieg.
          2. 10′ Hafenplan.
          3. 8′ Station 1, beide Tafeln.
          4. 7′ Station 2: kurz „neu bauen“, dann „Ausbruch!“ mit Nummer 1000 und 10001.
          5. 8′ Station 5: zwei Unglücke (Trojaner, Konto gesperrt), Merksatz „Sync ist kein Backup“.
          6. 7′ Station 6: Wege 3 bis 5 antippen (Pull Request, ein Mensch prüft, Server holt ab), dann der GitHub-Fall mit Pull und Push.

          Stationen 3, 4, 7 und 8 sowie die Zuordnung zum Nacharbeiten oder in einer zweiten Stunde.

          Lernziele

          • Den Weg einer Anfrage beschreiben: Name, DNS, IP-Adresse, Port, Firewall, Pförtner (Reverse Proxy), App im Container.
          • Für jedes Bauteil Aufgabe, Grund und die Folgen seines Fehlens nennen.
          • Das Prinzip der minimalen Rechte auf Menschen, Dienste und Container anwenden.
          • Die 3-2-1-Regel erklären und Synchronisation von Backup unterscheiden.
          • KI-Werkzeuge mit klaren Grenzen einordnen: Vorschläge prüft ein Mensch, die KI hat keinen Serverzugang.
          • Datenschutzfolgen technischer Entscheidungen erkennen: fremde Server, Verträge, Logs.

          Typische Fehlvorstellungen

          • „Ein Container ist wie ein eigener Rechner.“ Container teilen sich den Kern des Betriebssystems (Kernel); ein Ausbruch ist selten, aber möglich.
          • „Der Pförtner kontrolliert die Besucher.“ Caddy verteilt Anfragen nach Adresse und verschlüsselt; wer sich anmelden darf, regelt die App.
          • „HTTPS heißt: Die Seite ist vertrauenswürdig.“ HTTPS verschlüsselt die Verbindung und bestätigt den Namen, nicht den Inhalt.
          • „Die Firewall schützt vor allem.“ Hinter offenen Türen (22, 443) muss es weitere Schutzschichten geben.
          • „Der öffentliche Schlüssel muss geheim bleiben.“ Nein, geheim ist nur der private.
          • „Ein Cloud-Ordner ist mein Backup.“ Sync spiegelt auch Löschen und Verschlüsseln.
          • „Die KI arbeitet am Server.“ Hier nicht: Sie schlägt vor, der Mensch entscheidet und führt aus.
          • „Was die KI vorschlägt, stimmt.“ Nein: Sie erzeugt wahrscheinliche, überzeugend klingende Antworten, keine geprüften.
          • „Pull Request und Pull sind dasselbe.“ Ein Pull Request ist ein Änderungsvorschlag; „Pull“ beim Veröffentlichen heißt, der Server holt ab.
          • Vereinfachung: „Schloss und Schlüssel“ bei SSH ist ein Modell. Technisch unterschreibt das Gerät eine Kennung der Verbindung. Grenze des Bildes: Aus dem „Schloss“ lässt sich der Schlüssel nicht nachbauen, anders als bei echten Schlössern.

          An der Tafel

          Tafelmodus über den Knopf oben oder direkt über die Adresse: vom-klick-zur-webseite/index.html#tafel, #tafel-3 öffnet die dritte Tafel. Weiter mit → oder Bild↓ (auch Präsentations-Klicker), zurück mit ← oder Bild↑, Esc beendet. Die Stationen 1, 2, 4, 5 und 6 sind an der Tafel auf je zwei Bilder verteilt; insgesamt 16 Tafeln.

          Zum Ausdrucken

          Der Knopf Arbeitsblätter oben erzeugt A4-Blätter in Graustufen: im Schulmodus ein Arbeitsblatt (Lernweg als Lückentext, Quiz mit fünf Fragen, Kernaufgabe „Ein Server mit Lecks“: drei Fehler erklären und verbessern, dann den Weg einer Anfrage zeichnen), ein Infoblatt mit dem Hafenplan und die Lösung, im Fortbildungsmodus ein Handout. Drucken oder im Druckdialog als PDF sichern. Das Arbeitsblatt braucht etwa 25 Minuten und passt in keinen der beiden Abläufe: als Hausaufgabe oder in der Folgestunde. Das Infoblatt erst danach austeilen, denn es beantwortet mehrere Quizfragen.

          In der Kurzfassung fehlen die Stationen 3, 4, 7 und 8: Ihre Lernweg-Wörter stehen im Wortspeicher getrennt unter „Zusatz“. Diese Zeilen streichen oder mit der Internetseite nacharbeiten lassen. Die Kernaufgabe braucht nur die Stationen 1, 5 und 6 (mit Teil 1). Quizfrage 5 (Schriften) setzt Station 7 voraus; in der Kurzfassung streichen oder als Ausblick besprechen.

          Hinweise

          Alle Namen sind erfunden; .example und 203.0.113.42 sind für Beispiele reserviert. Die vier Funde in Station 8 und der Container mit derselben Nummer wie der hafenmeister stammen aus einer echten Überprüfung.

          Tailscale im Schulnetz nur, wenn die Nutzungsordnung es erlaubt. Keine Passwörter, Schlüssel, personenbezogenen Daten oder Logs mit IP-Adressen in eine Chat-KI kopieren.

          Technisches für Fragen aus der Fortbildung

          • Caddy: handle_path /quiz/* passt nicht auf /quiz ohne Schrägstrich; oft ergänzt man redir /quiz /quiz/. Ist der Webordner ein Git-Checkout, den Ordner .git nicht ausliefern (z. B. hide .git) oder außerhalb halten.
          • Viele Browser versuchen bei http:// inzwischen selbst zuerst HTTPS; die Umleitung durch Caddy sieht man dann seltener.
          • Backup: Die Schnappschüsse des Backup-Anbieters schützen vor einem Trojaner nur, wenn der Zugang des Servers sie nicht verwalten darf und sie weit genug zurückreichen. restic kann der Server „append-only“ beschreiben; der Laptop holt z. B. mit restic copy ab (fügt hinzu, spiegelt nicht).
          • Coding-KI: Versteckte Anweisungen in Dateien oder Webseiten (Prompt Injection) können zu schädlichen Vorschlägen führen; ein Grund mehr, jeden Pull Request zu prüfen.
          • LG München I: Das Gericht wertete auch die Übermittlung in die USA. Dafür gibt es seit 10.07.2023 einen Angemessenheitsbeschluss (EU-US Data Privacy Framework); die Hauptbegründung (lokal einbinden ist möglich) bleibt.