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.