Das Client-Server-Modell - Versionsgeschichte

ChristianPayns: /* DHCP: So funktioniert die automatische IP-Vergabe */

2026-04-12T00:38:14Z

DHCP: So funktioniert die automatische IP-Vergabe

← Nächstältere Version		Version vom 12. April 2026, 00:38 Uhr
Zeile 448:		Zeile 448:

	==DHCP: So funktioniert die automatische IP-Vergabe==		==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'''.

			[[Datei:DHCP_So_funktioniert_die_automatische_IP-Vergabe.png\|center\|500px]]

			{{Box
			\|Typ=info
			\|Titel=DORA-Eselsbruecke
			\|
			'''D'''iscover - '''O'''ffer - '''R'''equest - '''A'''cknowledge. 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.
			}}

			{{Box
			\|Typ=warning
			\|Titel=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.
			}}

ChristianPayns: /* Statische vs. Dynamische IP-Adressen */

2026-04-12T00:28:23Z

Statische vs. Dynamische IP-Adressen

← Nächstältere Version		Version vom 12. April 2026, 00:28 Uhr
Zeile 397:		Zeile 397:

	==Statische vs. Dynamische IP-Adressen==		==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.

			{{Box
			\|Typ=info
			\|Titel=
			\|
			[[Datei:Statische_vs._Dynamische_IP-Adressen.png\|center\|500px]]
			}}

			{\| class="wikitable" style="margin: auto;"
			\|-
			! 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
			\|}

			{{Box
			\|Typ=success
			\|Titel=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==		==DHCP: So funktioniert die automatische IP-Vergabe==

ChristianPayns: /* Besondere IPv4-Adressen */

2026-04-12T00:18:05Z

Besondere IPv4-Adressen

@@ Zeile 342: / Zeile 342: @@
 ==Besondere IPv4-Adressen==
 ==Statische vs. Dynamische IP-Adressen==
 ==DHCP: So funktioniert die automatische IP-Vergabe==

ChristianPayns: /* Aufbau einer IPv4-Adresse */

2026-04-12T00:07:52Z

Aufbau einer IPv4-Adresse

← Nächstältere Version		Version vom 12. April 2026, 00:07 Uhr
Zeile 310:		Zeile 310:

	==Aufbau einer IPv4-Adresse==		==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.

			{{Box
			\|Typ=info
			\|Titel=
			\|
			[[Datei:Aufbau_einer_IPv4-Adresse.png\|center\|500px]]
			}}

			{{Box
			\|Typ=info
			\|Titel=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
			}}

			{{Box
			\|Typ=success
			\|Titel=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==		==Besondere IPv4-Adressen==

ChristianPayns: /* Die Geschichte der IP-Adresse */

2026-04-12T00:01:33Z

Die Geschichte der IP-Adresse

← Nächstältere Version		Version vom 12. April 2026, 00:01 Uhr
Zeile 286:		Zeile 286:

	==Die Geschichte der IP-Adresse==		==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.

			{{Box
			\|Typ=info
			\|Titel=
			\|
			[[Datei:Die_Geschichte_der_IP-Adresse.png\|center\|500px]]
			}}

			{{Box
			\|Typ=info
			\|Titel=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==		==Aufbau einer IPv4-Adresse==

ChristianPayns: /* Sicherheitsvergleich auf einen Blick */

2026-04-11T23:55:17Z

Sicherheitsvergleich auf einen Blick

← Nächstältere Version		Version vom 11. April 2026, 23:55 Uhr
Zeile 247:		Zeile 247:

	==Sicherheitsvergleich auf einen Blick==		==Sicherheitsvergleich auf einen Blick==

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

			{\| class="wikitable" style="margin: auto;"
			\|-
			! 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
			\|}

			{{Box
			\|Typ=success
			\|Titel=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 Geschichte der IP-Adresse==

ChristianPayns: /* IT-Sicherheit: Schwachstellen Peer-to-Peer */

2026-04-11T23:48:47Z

IT-Sicherheit: Schwachstellen Peer-to-Peer

← Nächstältere Version		Version vom 11. April 2026, 23:48 Uhr
Zeile 198:		Zeile 198:

	==IT-Sicherheit: Schwachstellen Peer-to-Peer==		==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.

			{\| class="wikitable" style="margin: auto;"
			\|-
			! 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
			\|}

			{{Box
			\|Typ=danger
			\|Titel=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.
			}}

			{{Box
			\|Typ=info
			\|Titel=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==		==Sicherheitsvergleich auf einen Blick==

ChristianPayns: /* IT-Sicherheit: Schwachstellen Client-Server */

2026-04-11T23:25:36Z

IT-Sicherheit: Schwachstellen Client-Server

← Nächstältere Version		Version vom 11. April 2026, 23:25 Uhr
Zeile 151:		Zeile 151:

	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.		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.

			{{Box
			\|Typ=light
			\|Titel=
			\|
			[[Datei:Schwachstellen_Client-Server.png\|center\|500px]]
			}}

	{\| class="wikitable" style="margin: auto;"		{\| class="wikitable" style="margin: auto;"

ChristianPayns: /* IT-Sicherheit: Schwachstellen Client-Server */

2026-04-11T23:22:46Z

IT-Sicherheit: Schwachstellen Client-Server

← Nächstältere Version		Version vom 11. April 2026, 23:22 Uhr
Zeile 149:		Zeile 149:

	==IT-Sicherheit: Schwachstellen Client-Server==		==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.

			{\| class="wikitable" style="margin: auto;"
			\|-
			! 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
			\|}

			{{Box
			\|Typ=danger
			\|Titel=Sicherheitsrisiko: SQL-Injection im Detail
			\|
			Bei einer SQL-Injection schleust ein Angreifer SQL-Befehle ueber Eingabefelder ein. Statt eines Benutzernamens wird z.B.<code> ' OR 1gleich1 --</code> 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==		==IT-Sicherheit: Schwachstellen Peer-to-Peer==

ChristianPayns am 11. April 2026 um 23:14 Uhr

2026-04-11T23:14:11Z

@@ Zeile 1: / Zeile 1: @@
 [[Clients in Netzwerke einbinden|<span class="mw-ui-button mw-ui-progressive">⬅️ Clients in Netzwerke einbinden</span>]]
 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.
@@ Zeile 145: / Zeile 147: @@
 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.
 }}