Das Client-Server-Modell

⬅️ Clients in Netzwerke einbinden

Das Client-Server-Modell

Im Client-Server-Modell gibt es eine klare Rollenverteilung: Ein zentraler Server stellt Dienste bereit, mehrere Clients nehmen diese in Anspruch. Der Server laeuft in der Regel dauerhaft und wartet auf Anfragen.

Merkmal	Beschreibung
Zentrale Steuerung	Der Server verwaltet Daten, Benutzerkonten und Zugriffsrechte zentral
Request-Response	Clients senden Anfragen, der Server verarbeitet sie und liefert Antworten
Skalierbarkeit	Neue Clients koennen ohne Aenderung am Server hinzugefuegt werden
Verfuegbarkeit	Faellt der Server aus, steht der gesamte Dienst still (Single Point of Failure)
Beispiele	Webserver (Apache, Nginx), E-Mail (Exchange), Datenbank (MySQL), Active Directory

Analogie: Restaurant

Ein Client-Server-Netzwerk funktioniert wie ein Restaurant: Die Kueche (Server) bereitet Gerichte zu, und die Gaeste (Clients) bestellen ueber den Kellner. Jeder Gast bekommt sein bestelltes Gericht - aber wenn die Kueche schliesst, gibt es fuer niemanden mehr Essen.

Client-Server im Alltag

Das Client-Server-Modell begegnet uns taeglich - oft ohne dass wir es bewusst wahrnehmen. Nahezu jede Internetanwendung basiert auf diesem Prinzip.

Muster erkennen

Das Schema ist immer gleich: Ein Programm (Client) stellt eine Anfrage an einen Dienst (Server) ueber ein definiertes Protokoll. Wer das Muster einmal verstanden hat, kann jede Client-Server-Anwendung einordnen.

Das Peer-to-Peer-Modell (P2P)

Im Peer-to-Peer-Modell sind alle Teilnehmer gleichberechtigt. Jeder Rechner kann gleichzeitig Client und Server sein - es gibt keine zentrale Instanz, die den Verkehr steuert.

Merkmal	Beschreibung
Gleichberechtigung	Kein zentraler Server - jeder Knoten ist Client und Server zugleich
Ausfallsicherheit	Faellt ein Peer aus, funktioniert das restliche Netz weiter
Ressourcenteilung	Bandbreite, Speicher und Rechenleistung werden gemeinsam genutzt
Verwaltung	Schwer zentral zu administrieren - jeder Peer verwaltet sich selbst
Beispiele	BitTorrent, Bitcoin/Blockchain, AirDrop, LAN-Spiele, IPFS

Analogie: Lerngruppe ohne Lehrer

P2P ist wie eine Lerngruppe ohne Lehrer: Jeder bringt eigenes Wissen mit und teilt es direkt mit den anderen. Niemand hat die Aufsicht oder die alleinige Wahrheit. Wenn jemand fehlt, macht die Gruppe einfach weiter - es fehlt nur ein Stueck Wissen.

Vergleich: Client-Server vs. Peer-to-Peer

Beide Modelle haben klare Staerken und Schwaechen. Die Wahl haengt vom Einsatzzweck, der Netzwerkgroesse und den Sicherheitsanforderungen ab.

Kriterium	Client-Server	Peer-to-Peer
Struktur	Hierarchisch (Server oben, Clients unten)	Flach (alle gleichberechtigt)
Verwaltung	Zentral, professionell administrierbar	Dezentral, jeder Peer eigenverantwortlich
Kosten	Hoehere Anfangsinvestition (Hardware, Lizenzen)	Geringere Einstiegskosten
Skalierung	Gut skalierbar durch Server-Upgrades/Cluster	Skaliert durch neue Peers, wird aber komplexer
Ausfallrisiko	Single Point of Failure (Server)	Kein einzelner Ausfallpunkt
Datensicherheit	Zentrale Backups und Rechteverwaltung	Jeder Peer muss selbst Backups erstellen
Performance	Abhaengig von Server-Leistung	Steigt mit Anzahl der Peers (mehr Quellen)
Typische Groesse	Mittel bis gross (ab ca. 10 Geraete)	Klein (bis ca. 10 Geraete) oder spezialisiert

Analogie: Lerngruppe ohne Lehrer

P2P ist wie eine Lerngruppe ohne Lehrer: Jeder bringt eigenes Wissen mit und teilt es direkt mit den anderen. Niemand hat die Aufsicht oder die alleinige Wahrheit. Wenn jemand fehlt, macht die Gruppe einfach weiter - es fehlt nur ein Stueck Wissen.

IT-Sicherheit: Schwachstellen Client-Server

Die zentrale Architektur des Client-Server-Modells erzeugt spezifische Angriffsvektoren. Der Server ist das primaere Ziel - wer ihn kompromittiert, hat potenziell Zugriff auf alle Daten und Dienste.

Schwachstelle	Beschreibung	Gegenmassnahme
Single Point of Failure	Server-Ausfall legt den gesamten Dienst lahm	Redundanz, Failover-Cluster, Load Balancing
DDoS-Angriff	Massenanfragen ueberlasten den Server	Rate Limiting, CDN, Anti-DDoS-Diensteh
SQL-Injection	Schadcode in Eingabefeldern manipuliert die Datenbank	Prepared Statements, Input-Validierung
Privilegien-Eskalation	Angreifer erlangt erhoehte Rechte auf dem Server	Least-Privilege-Prinzip, regelmaessige Patches
Man-in-the-Middle	Abfangen der Client-Server-Kommunikation	TLS/HTTPS, Zertifikats-Pinning
Fehlkonfiguration	Offene Ports, Standard-Passwoerter, fehlende Updates	Hardening-Checklisten, Vulnerability-Scans

Sicherheitsrisiko: SQL-Injection im Detail

Bei einer SQL-Injection schleust ein Angreifer SQL-Befehle ueber Eingabefelder ein. Statt eines Benutzernamens wird z.B. ' OR 1gleich1 -- eingegeben. Ist die Anwendung verwundbar, wird die gesamte Datenbank ausgelesen. Gegenmittel: Prepared Statements trennen SQL-Logik strikt von Nutzereingaben.

IT-Sicherheit: Schwachstellen Peer-to-Peer

Die dezentrale Struktur von P2P-Netzen erschwert eine einheitliche Sicherheitsstrategie. Jeder Peer ist gleichzeitig potentielles Ziel und potentielle Schwachstelle fuer das gesamte Netz.

Schwachstelle	Beschreibung	Gegenmassnahme
Malware-Verbreitung	Schadsoftware verbreitet sich unkontrolliert ueber geteilte Dateien	Datei-Hashing (SHA-256), Virenscanner auf jedem Peer
Sybil-Angriff	Angreifer erzeugt viele gefaelschte Identitaeten im Netzwerk	Proof-of-Work, Reputations-Systeme, Identitaetspruefung
Datenintegritaet	Keine zentrale Instanz prueft die Echtheit empfangener Daten	Kryptographische Pruefsummen (Hashes)
IP-Offenlegung	Peers sehen gegenseitig ihre echten IP-Adressen	VPN, Tor-Netzwerk, anonyme Overlay-Netze
Fehlende zentrale Patches	Updates muessen individuell auf jedem Peer installiert werden	Auto-Update-Mechanismen in der P2P-Software
Eclipse-Angriff	Angreifer umgibt ein Opfer mit kontrollierten Knoten	Zufaellige Peer-Auswahl, diverse Verbindungen

Sicherheitsrisiko: Sybil-Angriff erklaert

Bei einem 'Sybil-Angriff erstellt ein einzelner Akteur viele gefaelschte Identitaeten, um ueberproportionalen Einfluss auf das Netzwerk zu erlangen. In Blockchain-Netzwerken schuetzt der Proof-of-Work-Mechanismus davor, da jede Identitaet echte Rechenleistung aufbringen muss - gefaelschte Knoten werden dadurch teuer.

Vertiefung: Eclipse-Angriff vs. Sybil-Angriff

Waehrend beim Sybil-Angriff das gesamte Netzwerk mit gefaelschten Knoten geflutet wird, zielt der Eclipse-Angriff auf einen einzelnen Peer: Dessen Verbindungen werden so manipuliert, dass er nur noch mit Angreifer-Knoten kommuniziert. Das Opfer sieht eine verfaelschte Version des Netzwerks.

Sicherheitsvergleich auf einen Blick

Beide Architekturen haben unterschiedliche Angriffsoberflaechen. Die Wahl des Modells beeinflusst direkt, welche Sicherheitsmassnahmen priorisiert werden müssen.

Aspekt	Client-Server	Peer-to-Peer
Hauptziel	Totalausfall bei Server-Kompromittierung	Unkontrollierte Malware-Ausbreitung
Zugriffskontrolle	Zentral steuerbar (ACLs, LDAP, AD)	Jeder Peer entscheidet selbst
Patch-Management	Zentral ausrollbar (WSUS, Ansible, GPO)	Dezentral, oft manuell
Monitoring	Zentrales Logging (SIEM, Syslog)	Kaum moeglich - keine zentrale Instanz
Verschluesselung	TLS zwischen Client und Server	Ende-zu-Ende zwischen Peers noetig

Merksatz fuer die Pruefung

Client-Server -> "Ein Schloss mit einer Zugbruecke" - gut zu verteidigen, aber wenn die Bruecke faellt, ist alles verloren. Peer-to-Peer -> "Eine offene Marktplatzstadt" - schwer komplett einzunehmen, aber auch schwer zu kontrollieren.

Die Geschichte der IP-Adresse

Die IP-Adresse entstand nicht ueber Nacht. Sie ist das Ergebnis jahrzehntelanger Forschung - angefangen bei einem militaerischen Forschungsprojekt bis hin zum globalen Internet.

Vertiefung: Classful Addressing (historisch)

Ursprünglich wurden IPv4-Adressen in Klassen eingeteilt:

• Klasse A (1.0.0.0 - 126.x.x.x): 16,7 Mio. Hosts pro Netz - fuer Grossorganisationen
• Klasse B (128.0.0.0 - 191.x.x.x): 65.534 Hosts pro Netz - fuer mittlere Organisationen
• Klasse C (192.0.0.0 - 223.x.x.x): 254 Hosts pro Netz - fuer kleine Netze

Dieses System war extrem verschwenderisch: Ein Unternehmen mit 300 Hosts brauchte ein Klasse-B-Netz und verschwendete 65.000 Adressen. CIDR (1993) loeste dieses Problem durch flexible Subnetzmasken.

Aufbau einer IPv4-Adresse

Jedes Geraet in einem IP-Netzwerk braucht eine eindeutige Adresse, damit Datenpakete den richtigen Empfaenger finden. Die IPv4-Adresse ist diese Kennung - sie besteht aus 32 Bit, aufgeteilt in 4 Oktette.

Kernpunkte zur IPv4-Adresse

• 4 Oktette, getrennt durch Punkte - jedes Oktett reicht von 0 bis 255
• Der Netzwerk-Anteil identifiziert das Netzwerk (wie eine Postleitzahl)
• Der Host-Anteil identifiziert das Geraet im Netzwerk (wie die Hausnummer)
• Die Aufteilung Netzwerk/Host wird durch die Subnetzmaske bestimmt

Analogie: Postanschrift

Eine IP-Adresse funktioniert wie eine Postanschrift:

• PLZ + Stadt (Netzwerk-Anteil) -> In welche Gegend muss das Paket?
• Strasse + Hausnr. (Host-Anteil) -> Welches genaue Gebaeude?

Ohne Adresse wuesste kein Router, wohin ein Datenpaket soll - genau wie ein Brief ohne Anschrift nicht zugestellt werden kann.

Besondere IPv4-Adressen

Nicht alle IPv4-Adressen sind frei verwendbar. Einige Bereiche sind fuer spezielle Zwecke reserviert - diese begegnen Ihnen taeglich im Netzwerk.

Bereich (CIDR)	Zweck	Beispiel
10.0.0.0/8	Privates Netz (Klasse A) - grosse Unternehmen	10.0.1.50 (interner Server)
172.16.0.0/12	Privates Netz (Klasse B) - mittlere Netze	172.16.0.1 (Schulnetzwerk)
192.168.0.0/16	Privates Netz (Klasse C) - Heimnetze, kleine Bueros	192.168.1.1 (Ihr Router zuhause)
127.0.0.0/8	Loopback - das Geraet spricht mit sich selbst	127.0.0.1 (localhost)
169.254.0.0/16	APIPA - automatische Zuweisung wenn kein DHCP erreichbar	169.254.x.x (Fehlerzustand)
0.0.0.0	Unbekannte Adresse / Standardroute	Default Gateway Route
255.255.255.255	Broadcast - Nachricht an alle im Netz	DHCP Discover Paket

IHK-Pruefungswissen: Private IP-Bereiche

Die drei privaten Bereiche (10.x, 172.16-31.x, 192.168.x) werden in der Pruefung sehr haeufig abgefragt. Merken Sie sich diese drei Bereiche und dass private IPs nicht im Internet geroutet werden - dafuer braucht man NAT (Network Address Translation).

Vertiefung: Warum 127.0.0.1 = localhost?

Der gesamte Bereich 127.0.0.0/8 (ueber 16 Millionen Adressen!) ist fuer Loopback reserviert. Wenn Sie ping 127.0.0.1 ausfuehren, verlassen die Pakete nie den eigenen Rechner - sie werden intern zurueckgeschickt. Entwickler nutzen dies, um lokale Webserver zu testen, ohne eine echte Netzwerkverbindung zu benoetigen.

Statische vs. Dynamische IP-Adressen

IP-Adressen koennen auf zwei Arten vergeben werden: fest zugewiesen (statisch) oder automatisch per DHCP (dynamisch). Beide Verfahren haben ihren Platz.

Kriterium	Statische IP	Dynamische IP (DHCP)
Vergabe	Manuell vom Administrator konfiguriert	Automatisch durch DHCP-Server
Aendert sich?	Nein - bleibt dauerhaft gleich	Ja - kann sich bei Lease-Ablauf aendern
Verwaltungsaufwand	Hoch - jedes Geraet einzeln pflegen	Gering - zentrale automatische Vergabe
Fehleranfaelligkeit	IP-Konflikte bei manuellen Tippfehlern	Server verhindert Doppelvergabe automatisch
Erreichbarkeit	Immer unter derselben Adresse erreichbar	Adresse wechselt - DNS oder Reservierung noetig
Typischer Einsatz	Server, Drucker, Router, Access Points	Arbeitsplatz-PCs, Laptops, Smartphones, Gaeste-WLAN

Best Practice im Unternehmen

• Infrastruktur-Geraete (Server, Router, Drucker, Switches) erhalten statische IPs - sie muessen zuverlaessig erreichbar sein.
• Endgeraete (PCs, Laptops, Smartphones) bekommen dynamische IPs per DHCP. Tipp: Viele DHCP-Server unterstuetzen
• Reservierungen - eine feste IP, die trotzdem zentral verwaltet wird.

DHCP: So funktioniert die automatische IP-Vergabe

Das Dynamic Host Configuration Protocol (DHCP) automatisiert die IP-Vergabe im Netzwerk. Der Ablauf folgt immer demselben Muster - dem DORA-Prinzip.

DORA-Eselsbruecke

Discover - Offer - Request - Acknowledge. Der Client fragt (D), der Server bietet an (O), der Client akzeptiert (R), der Server bestaetigt (A). Die IP-Adresse wird für eine bestimmte Lease-Dauer verliehen - danach muss sie erneuert werden.

Protokoll-Detail: Was passiert beim Lease-Ablauf?

Bei 50% der Lease-Dauer (T1) versucht der Client automatisch, seine IP zu erneuern (Request direkt an den Server). Klappt das nicht, versucht er es bei 87,5% (T2) per Broadcast an jeden DHCP-Server. Laeuft die Lease komplett ab, muss der Client den gesamten DORA-Prozess neu starten.