Das Client-Server-Modell
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 |
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.
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 |
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 |
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 |
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 |
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.
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 |
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.
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.
