# 10. OSI-Schicht 7 – Anwendungsschicht # 10.1 OSI-Schicht 7 – Anwendungsschicht Die Anwendungsschicht ist Schicht 7 des OSI-Modells. Sie ist die oberste Schicht. Die Hauptaufgabe von Schicht 7 ist: Netzwerkdienste für Anwendungen bereitstellen. Dabei geht es vor allem um Protokolle und Dienste, die direkt von Anwendungen genutzt werden. Typische Beispiele: - HTTP - HTTPS - DNS - DHCP - SMTP - IMAP - POP3 - FTP - SSH - SMB - LDAP - SNMP - NTP Merksatz: Schicht 7 = Netzwerkdienste für Anwendungen. --- **Grundidee von Schicht 7** Schicht 7 ist die Schicht, mit der Anwendungen direkt arbeiten. Beispiele: Webbrowser nutzt HTTP oder HTTPS. Mailprogramm nutzt SMTP, IMAP oder POP3. Betriebssystem nutzt DNS zur Namensauflösung. Client nutzt DHCP zur automatischen IP-Konfiguration. Administrator nutzt SSH zur Fernverwaltung. Wichtig: Die Anwendungsschicht ist nicht die Anwendung selbst, sondern die Netzwerkschnittstelle beziehungsweise das Protokoll, das die Anwendung nutzt. Merksatz: Schicht 7 beschreibt Dienste und Protokolle, die Anwendungen für Netzwerkkommunikation verwenden. --- **Einordnung im OSI-Modell** | OSI-Schicht | Name | Aufgabe | |---:|---|---| | 7 | Anwendungsschicht | Netzwerkdienste für Anwendungen | | 6 | Darstellungsschicht | Darstellung, Codierung, Verschlüsselung | | 5 | Sitzungsschicht | Sitzungen aufbauen, verwalten und beenden | | 4 | Transportschicht | TCP, UDP, Ports | | 3 | Vermittlungsschicht / Netzwerkschicht | IP, Routing | | 2 | Sicherungsschicht | Frames, MAC, VLAN | | 1 | Bitübertragungsschicht | Bits, Signale | Merksatz: Schicht 7 ist die oberste OSI-Schicht. --- **Schicht 7 ist nicht einfach „das Programm“** Ein häufiger Fehler ist: Browser = Schicht 7 Besser formuliert: Der Browser ist eine Anwendung. Der Browser nutzt Protokolle der Anwendungsschicht, zum Beispiel HTTP oder HTTPS. Beispiel: Firefox, Chrome oder Safari = Anwendung HTTP, HTTPS = Protokolle der Anwendungsschicht Merksatz: Programm nutzt Schicht 7, ist aber nicht automatisch selbst die Schicht. --- **Was macht die Anwendungsschicht?** Die Anwendungsschicht stellt Funktionen bereit wie: - Webseiten abrufen - Namen in IP-Adressen auflösen - E-Mails senden und empfangen - Dateien übertragen - Zeit synchronisieren - Netzwerkgeräte überwachen - Verzeichnisdienste abfragen - automatische IP-Konfiguration anstoßen - entfernte Systeme verwalten Merksatz: Schicht 7 stellt konkrete Netzwerkdienste bereit. --- **Schicht 7 und Ports** Viele Anwendungsschicht-Protokolle nutzen Ports auf Schicht 4. Beispiele: | Anwendungsschicht-Protokoll | Transport | typischer Port | |---|---|---:| | HTTP | TCP | 80 | | HTTPS | TCP | 443 | | DNS | UDP / TCP | 53 | | DHCP | UDP | 67 / 68 | | SSH | TCP | 22 | | SMTP | TCP | 25 | | IMAP | TCP | 143 | | POP3 | TCP | 110 | | NTP | UDP | 123 | Wichtig: Port gehört zu Schicht 4. Dienstprotokoll gehört zu Schicht 7. Merksatz: Port = Schicht 4. Protokoll/Dienst = Schicht 7. --- **HTTP** HTTP steht für: Hypertext Transfer Protocol HTTP wird verwendet, um Webseiten und Webdaten zu übertragen. Typischer Port: TCP 80 HTTP ist unverschlüsselt. Beispiele für HTTP-Kommunikation: Browser ruft Webseite ab. Webanwendung liefert HTML. API sendet Daten. Client lädt Dateien von einem Webserver. Merksatz: HTTP = Webprotokoll ohne TLS-Verschlüsselung. --- **HTTPS** HTTPS steht für: Hypertext Transfer Protocol Secure HTTPS ist: HTTP über TLS Typischer Port: TCP 443 HTTPS schützt die Übertragung durch TLS. Schutzziele: - Vertraulichkeit - Integrität - Authentizität Merksatz: HTTPS = HTTP mit TLS-Schutz. --- **HTTP und HTTPS unterscheiden** | Merkmal | HTTP | HTTPS | |---|---|---| | Verschlüsselung | nein | ja, TLS | | typischer Port | TCP 80 | TCP 443 | | Zertifikat nötig | nein | ja | | Schutz vor Mitlesen | nein | ja | | Schutz vor Manipulation | nein | ja | Merksatz: HTTP ist unverschlüsselt. HTTPS ist verschlüsselt. --- **DNS** DNS steht für: Domain Name System DNS löst Namen in IP-Adressen auf. Beispiel: www.example.com → 93.184.216.34 DNS wird benötigt, damit Benutzer und Anwendungen mit Namen arbeiten können, statt sich IP-Adressen merken zu müssen. Typischer Port: UDP 53 TCP 53 Merksatz: DNS = Name zu IP-Adresse. --- **A-Record und AAAA-Record** DNS kann verschiedene Einträge liefern. Wichtige Einträge: | DNS-Record | Bedeutung | |---|---| | A | Name zu IPv4-Adresse | | AAAA | Name zu IPv6-Adresse | | CNAME | Alias auf anderen Namen | | MX | Mailserver einer Domain | | TXT | Textinformationen, oft für Prüfungen | | NS | zuständiger Nameserver | Merksatz: A = IPv4. AAAA = IPv6. MX = Mailserver. --- **DNS und Schicht 7** DNS ist ein Anwendungsschicht-Protokoll, obwohl es UDP oder TCP auf Schicht 4 nutzt. Wichtig: DNS-Port 53 gehört zu Schicht 4. DNS-Protokoll gehört zu Schicht 7. Merksatz: DNS nutzt Ports, ist aber ein Dienst der Anwendungsschicht. --- **DHCP** DHCP steht für: Dynamic Host Configuration Protocol DHCP vergibt automatisch Netzwerkkonfigurationen. Ein Client kann per DHCP erhalten: - IP-Adresse - Subnetzmaske - Standard-Gateway - DNS-Server - Lease-Zeit - weitere Optionen Typische Ports: DHCP-Server: UDP 67 DHCP-Client: UDP 68 Merksatz: DHCP = automatische IP-Konfiguration. --- **DHCP und Schicht 7** DHCP ist ein Anwendungsschicht-Protokoll, auch wenn es IP-Konfigurationen für Schicht 3 bereitstellt. Das ist wichtig: DHCP vergibt IP-Daten, aber das DHCP-Protokoll selbst gehört zur Anwendungsschicht. Merksatz: DHCP liefert Schicht-3-Konfiguration, ist aber ein Schicht-7-Protokoll. --- **SMTP** SMTP steht für: Simple Mail Transfer Protocol SMTP wird für das Senden und Weiterleiten von E-Mails verwendet. Typischer Port: TCP 25 Weitere häufige Ports: TCP 587 für Mail Submission TCP 465 für SMTPS Merksatz: SMTP = E-Mail senden und transportieren. --- **POP3** POP3 steht für: Post Office Protocol Version 3 POP3 wird zum Abrufen von E-Mails verwendet. Typischer Port: TCP 110 Verschlüsselte Variante: POP3S über TCP 995 POP3 lädt E-Mails häufig vom Server herunter. Merksatz: POP3 = E-Mail abrufen. --- **IMAP** IMAP steht für: Internet Message Access Protocol IMAP wird zum Abrufen und Verwalten von E-Mails verwendet. Typischer Port: TCP 143 Verschlüsselte Variante: IMAPS über TCP 993 IMAP lässt E-Mails häufig auf dem Server und synchronisiert sie zwischen Geräten. Merksatz: IMAP = E-Mail verwalten und synchronisieren. --- **SMTP, POP3 und IMAP unterscheiden** | Protokoll | Hauptaufgabe | typischer Port | |---|---|---:| | SMTP | E-Mail senden / transportieren | TCP 25 | | POP3 | E-Mail abrufen | TCP 110 | | IMAP | E-Mail abrufen und verwalten | TCP 143 | Merksatz: SMTP sendet. POP3 und IMAP empfangen. --- **FTP** FTP steht für: File Transfer Protocol FTP dient zur Dateiübertragung. Typischer Port: TCP 21 Wichtig: Klassisches FTP ist unverschlüsselt. Sicherere Alternativen sind zum Beispiel: - SFTP - FTPS Merksatz: FTP = Dateiübertragung, klassisch unverschlüsselt. --- **SFTP und FTPS unterscheiden** SFTP und FTPS werden oft verwechselt. | Begriff | Bedeutung | |---|---| | SFTP | Dateiübertragung über SSH | | FTPS | FTP mit TLS-Schutz | Typische Einordnung: SFTP nutzt SSH. FTPS nutzt TLS. Merksatz: SFTP ist nicht dasselbe wie FTPS. --- **SSH** SSH steht für: Secure Shell SSH dient zur sicheren Fernverwaltung. Typischer Port: TCP 22 SSH wird genutzt für: - sichere Shell - Serveradministration - SFTP - Tunnel - sichere Befehlsausführung Merksatz: SSH = sicherer Fernzugriff. --- **Telnet** Telnet ist ein älteres Fernzugriffsprotokoll. Typischer Port: TCP 23 Problem: Telnet ist unverschlüsselt. Benutzernamen, Passwörter und Eingaben können mitgelesen werden. Heute sollte man für Administration SSH verwenden. Merksatz: Telnet ist unsicher, SSH ist die sichere Alternative. --- **SMB** SMB steht für: Server Message Block SMB wird häufig für Datei- und Druckerfreigaben verwendet. Typischer Port: TCP 445 Typische Nutzung: - Windows-Dateifreigaben - Netzlaufwerke - Druckerfreigaben - Dateiablage im LAN Merksatz: SMB = Datei- und Freigabedienst. --- **LDAP** LDAP steht für: Lightweight Directory Access Protocol LDAP dient zur Abfrage und Verwaltung von Verzeichnisdiensten. Typische Nutzung: - Benutzerverzeichnisse - Gruppen - Authentifizierungsinformationen - zentrale Identitätsverwaltung Typische Ports: LDAP: TCP/UDP 389 LDAPS: TCP 636 Merksatz: LDAP = Zugriff auf Verzeichnisdienste. --- **SNMP** SNMP steht für: Simple Network Management Protocol SNMP wird für Überwachung und Verwaltung von Netzwerkgeräten genutzt. Typische Nutzung: - Switches überwachen - Router überwachen - Drucker überwachen - Serverwerte abfragen - Monitoring-Systeme anbinden Typische Ports: UDP 161 für Abfragen UDP 162 für Traps Merksatz: SNMP = Netzwerkgeräte überwachen. --- **NTP** NTP steht für: Network Time Protocol NTP synchronisiert die Uhrzeit von Systemen. Typischer Port: UDP 123 Korrekte Zeit ist wichtig für: - Zertifikate - Kerberos - Logs - Monitoring - Fehlersuche - Authentifizierung Merksatz: NTP = Zeitsynchronisation. --- **RDP** RDP steht für: Remote Desktop Protocol RDP wird für grafischen Fernzugriff verwendet, besonders bei Windows-Systemen. Typischer Port: TCP 3389 Wichtig: RDP sollte nicht ungeschützt direkt ins Internet geöffnet werden. Besser: - VPN - Zugriffsbeschränkung - Multi-Faktor-Authentifizierung - Remote Desktop Gateway - starke Passwörter Merksatz: RDP = grafischer Fernzugriff, sorgfältig absichern. --- **Anwendungsschicht und Benutzer** Schicht 7 ist die OSI-Schicht, die am nächsten an der Benutzeranwendung liegt. Beispiele: Browser lädt Webseite. Mailprogramm ruft E-Mails ab. Datei-Explorer öffnet Netzfreigabe. Monitoring fragt Gerätedaten ab. Admin verbindet sich per SSH. Wichtig: Der Benutzer sieht oft nur die Anwendung. Technisch arbeitet die Anwendung mit Schicht-7-Protokollen. Merksatz: Schicht 7 ist die benutzernahe Netzwerkschicht. --- **Client und Server** Viele Anwendungsschicht-Protokolle arbeiten nach dem Client-Server-Prinzip. Client: stellt Anfrage Server: liefert Antwort oder Dienst Beispiel HTTP: Browser = Client Webserver = Server Beispiel DNS: DNS-Resolver = Client DNS-Server = Server Merksatz: Client fragt an, Server antwortet. --- **Request und Response** Viele Anwendungsschicht-Protokolle arbeiten mit Anfrage und Antwort. Beispiel HTTP: Request: Client fordert eine Webseite an. Response: Server liefert die Webseite zurück. Beispiel DNS: Request: Client fragt nach IP-Adresse. Response: DNS-Server liefert Adresse zurück. Merksatz: Request = Anfrage. Response = Antwort. --- **HTTP-Methoden** HTTP nutzt Methoden, um die Art einer Anfrage zu beschreiben. Wichtige Methoden: | Methode | Bedeutung | |---|---| | GET | Daten abrufen | | POST | Daten senden / erstellen | | PUT | Daten ersetzen | | PATCH | Daten teilweise ändern | | DELETE | Daten löschen | | HEAD | nur Kopfzeilen abrufen | Merksatz: GET liest. POST sendet. DELETE löscht. --- **HTTP-Statuscodes** HTTP-Statuscodes zeigen das Ergebnis einer Anfrage. Wichtige Bereiche: | Bereich | Bedeutung | |---|---| | 1xx | Information | | 2xx | Erfolg | | 3xx | Weiterleitung | | 4xx | Clientfehler | | 5xx | Serverfehler | Beispiele: | Statuscode | Bedeutung | |---:|---| | 200 | OK | | 301 | dauerhaft weitergeleitet | | 302 | vorübergehend weitergeleitet | | 400 | fehlerhafte Anfrage | | 401 | nicht authentifiziert | | 403 | verboten | | 404 | nicht gefunden | | 500 | interner Serverfehler | | 502 | Bad Gateway | | 503 | Dienst nicht verfügbar | Merksatz: 2xx gut, 4xx Clientproblem, 5xx Serverproblem. --- **API** API steht für: Application Programming Interface Eine API ist eine Schnittstelle, über die Anwendungen miteinander kommunizieren. Im Netzwerkumfeld sind Web-APIs häufig. Sie nutzen oft: - HTTP oder HTTPS - JSON - XML - Tokens - Statuscodes Merksatz: API = Schnittstelle zwischen Anwendungen. --- **REST kurz erklärt** REST ist ein Architekturstil für Web-APIs. Typisch: Ressourcen werden über URLs angesprochen. HTTP-Methoden beschreiben die Aktion. Daten werden häufig als JSON übertragen. Beispiel: GET /users bedeutet sinngemäß: Benutzerliste abrufen. Merksatz: REST nutzt HTTP-Ideen für APIs. --- **Anwendungsschicht und Authentifizierung** Viele Dienste müssen prüfen: Wer bist du? Das nennt man: Authentifizierung Beispiele: - Benutzername und Passwort - SSH-Schlüssel - Zertifikat - Token - Multi-Faktor-Authentifizierung Merksatz: Authentifizierung prüft Identität. --- **Anwendungsschicht und Autorisierung** Autorisierung bedeutet: Was darfst du? Beispiel: Benutzer ist angemeldet, darf aber keine Adminseite öffnen. Authentifizierung und Autorisierung unterscheiden: Authentifizierung: Wer bist du? Autorisierung: Was darfst du? Merksatz: Authentifizierung = Identität. Autorisierung = Rechte. --- **Cookies und Sessions** Webanwendungen nutzen oft Cookies, um Sitzungen wiederzuerkennen. Beispiel: Benutzer meldet sich an. Server setzt Session-Cookie. Browser sendet Cookie bei weiteren Anfragen mit. Server erkennt Benutzer wieder. Schichtbezug: Session = Schicht 5 / 7-Bezug Cookie = Anwendungsschicht HTTP = Anwendungsschicht Merksatz: Cookies helfen Webanwendungen, Sitzungen wiederzuerkennen. --- **Anwendungsschicht und Datenformate** Schicht 7 arbeitet oft mit Datenformaten aus Schicht 6. Beispiele: HTTP überträgt HTML. API überträgt JSON. Mail enthält MIME-Strukturen. Webserver liefert CSS, JavaScript, Bilder. Darum sind Schicht 6 und 7 in der Praxis eng verbunden. Merksatz: Schicht 7 nutzt häufig Datenformate aus Schicht 6. --- **Anwendungsschicht und DNS-Probleme** DNS-Probleme wirken oft wie Internetprobleme. Beispiel: ping 8.8.8.8 funktioniert. ping www.example.com funktioniert nicht. Dann ist IP-Kommunikation grundsätzlich möglich, aber Namensauflösung funktioniert nicht. Mögliche Ursachen: - falscher DNS-Server - DNS-Server nicht erreichbar - falscher DNS-Eintrag - DNS-Cache fehlerhaft - Firewall blockiert DNS - Domain nicht vorhanden Merksatz: IP geht, Name nicht: DNS prüfen. --- **Anwendungsschicht und HTTP-Fehler** Wenn TCP 443 erreichbar ist, aber die Webseite Fehler zeigt, liegt das Problem oft höher als Schicht 4. Beispiele: 404 Not Found: Ressource nicht gefunden. 500 Internal Server Error: Anwendung oder Serverfehler. 502 Bad Gateway: Proxy oder Gateway bekommt keine passende Antwort. 503 Service Unavailable: Dienst nicht verfügbar. Merksatz: HTTP-Statuscodes helfen bei Schicht-7-Fehlersuche. --- **Anwendungsschicht und E-Mail-Fehler** E-Mail-Probleme können viele Ursachen haben. Mögliche Prüfpunkte: - SMTP-Server erreichbar? - IMAP/POP3 erreichbar? - Benutzer angemeldet? - DNS MX-Record korrekt? - Spamfilter blockiert? - TLS korrekt? - Authentifizierung korrekt? - Mailbox voll? - Sender oder Empfänger falsch? Merksatz: E-Mail-Fehler betreffen oft DNS, Authentifizierung, TLS und Mailprotokolle. --- **Anwendungsschicht und DHCP-Fehler** Wenn ein Client keine IP-Adresse erhält, denkt man oft zuerst an Schicht 3. Aber DHCP selbst ist ein Anwendungsschicht-Protokoll. Mögliche Ursachen: - DHCP-Server nicht aktiv - DHCP-Bereich erschöpft - DHCP-Relay fehlt - falsches VLAN - Firewall blockiert UDP 67/68 - falsche DHCP-Optionen - Dienstfehler am DHCP-Server Merksatz: DHCP vergibt IP-Daten, ist aber ein Dienstprotokoll. --- **Anwendungsschicht und Sicherheit** Schicht 7 ist besonders wichtig für Sicherheit, weil dort konkrete Dienste und Benutzerinteraktion stattfinden. Typische Risiken: - schwache Passwörter - fehlende MFA - unsichere Webanwendungen - fehlerhafte API-Berechtigungen - unsichere Dateifreigaben - veraltete Dienste - Standardpasswörter - offene Verwaltungsdienste Merksatz: Viele Angriffe zielen direkt auf Anwendungsschicht-Dienste. --- **Typische Schutzmaßnahmen auf Schicht 7** Beispiele: - starke Authentifizierung - Multi-Faktor-Authentifizierung - sichere Passwörter - Rechte nach Minimalprinzip - Updates - sichere Konfiguration - Protokollierung - Eingabevalidierung - Web Application Firewall - sichere API-Tokens - nicht benötigte Dienste deaktivieren Merksatz: Schicht-7-Sicherheit schützt konkrete Dienste und Anwendungen. --- **Was Schicht 7 nicht macht** Schicht 7 macht nicht: - Bits als elektrische oder optische Signale übertragen - MAC-Adressen im LAN verwenden - IP-Pakete routen - TCP-Verbindungen aufbauen - Ports bereitstellen - reine Verschlüsselungsschicht ersetzen Diese Aufgaben liegen auf unteren Schichten. Merksatz: Schicht 7 nutzt die unteren Schichten, ersetzt sie aber nicht. --- **Einordnung typischer Begriffe** | Begriff | Schicht | |---|---:| | HTTP | 7 | | HTTPS | 7 mit TLS-Bezug | | DNS | 7 | | DHCP | 7 | | SMTP | 7 | | IMAP | 7 | | POP3 | 7 | | FTP | 7 | | SSH | 7 | | SMB | 7 | | LDAP | 7 | | SNMP | 7 | | NTP | 7 | | TCP-Port | 4 | | IP-Adresse | 3 | | MAC-Adresse | 2 | Merksatz: Dienstprotokolle wie HTTP, DNS und SMTP gehören zu Schicht 7. --- **Schicht 7 und Fehlersuche** Typische Fragen bei Schicht-7-Problemen: Funktioniert IP-Erreichbarkeit? Ist der Port erreichbar? Läuft der Dienst? Stimmt der DNS-Name? Antwortet die Anwendung? Gibt es HTTP-Statuscodes? Funktioniert die Anmeldung? Sind Rechte korrekt? Ist TLS gültig? Stimmen Datenformat und API-Anfrage? Gibt es Fehlermeldungen in Logs? Merksatz: Bei Schicht 7 prüft man Dienst, Inhalt, Anmeldung und Anwendung. --- **Fehlerbild: Webseite öffnet nicht** Mögliche Ursachen auf verschiedenen Schichten: Schicht 3: keine Route, falsches Gateway Schicht 4: TCP 80 oder 443 blockiert Schicht 6: TLS-Zertifikat fehlerhaft Schicht 7: Webserverfehler, falscher Pfad, HTTP 500 Merksatz: Webfehler können mehrere Schichten betreffen. --- **Fehlerbild: Login funktioniert nicht** Mögliche Ursachen: - falscher Benutzername - falsches Passwort - Konto gesperrt - MFA fehlt - Session-Cookie blockiert - Zeitproblem bei Tokens - Berechtigung fehlt - Authentifizierungsdienst nicht erreichbar - LDAP oder Verzeichnisdienst gestört Merksatz: Loginfehler sind meist Anwendung, Authentifizierung oder Sitzung. --- **Fehlerbild: API antwortet mit Fehler** Mögliche Ursachen: - falsche URL - falsche HTTP-Methode - fehlender Token - falsche Berechtigung - ungültiges JSON - falscher Content-Type - Serverfehler - Rate Limit - falsche API-Version Merksatz: API-Fehler betreffen oft Methode, Datenformat, Token oder Rechte. --- **Fehlerbild: DNS löst falsch auf** Mögliche Ursachen: - falscher A-Record - falscher AAAA-Record - alter DNS-Cache - falscher DNS-Server - Split-DNS-Konfiguration - Tippfehler im Namen - Zone nicht aktualisiert - TTL noch nicht abgelaufen Merksatz: Falscher DNS-Eintrag kann zum falschen Server führen. --- **Fehlerbild: E-Mail kommt nicht an** Mögliche Ursachen: - falscher MX-Record - SMTP blockiert - Spamfilter - SPF, DKIM oder DMARC fehlerhaft - Mailbox voll - Empfängeradresse falsch - TLS-Problem - Authentifizierung fehlerhaft - Blacklisting Merksatz: Mailzustellung hängt stark von DNS, SMTP und Sicherheitsprüfungen ab. --- **Schicht 7 und Logs** Logs sind bei Schicht-7-Fehlern besonders wichtig. Typische Logs: - Webserver-Log - Anwendungslog - Authentifizierungslog - Mailserver-Log - DNS-Log - Proxy-Log - API-Log - Firewall-Log Logs zeigen oft: - konkrete Fehlermeldungen - Statuscodes - Benutzer - Zeitpunkt - Quelle - Anfragepfad - Antwortcode Merksatz: Schicht-7-Fehler findet man oft in Anwendungs- und Dienstlogs. --- **Typische IHK-Fragen** In AP1 und AP2 kann zum Beispiel gefragt werden: - Welche Aufgabe hat die Anwendungsschicht? - Welche Protokolle gehören zur Anwendungsschicht? - Was ist der Unterschied zwischen HTTP und HTTPS? - Was macht DNS? - Was ist der Unterschied zwischen A- und AAAA-Record? - Was macht DHCP? - Warum ist DHCP trotz IP-Bezug ein Anwendungsschicht-Protokoll? - Welche Mailprotokolle gibt es? - Was ist der Unterschied zwischen SMTP, POP3 und IMAP? - Was macht SMB? - Was macht LDAP? - Was macht SNMP? - Was bedeuten HTTP-Statuscodes? - Warum reicht ein erfolgreicher Ping nicht für einen funktionierenden Dienst? - Warum können Schicht-7-Fehler trotz offener Ports auftreten? --- **Typische Prüfungsfallen** Schicht 7 heißt Anwendungsschicht. Schicht 7 ist nicht einfach das Programm selbst. Anwendungen nutzen Schicht-7-Protokolle. HTTP gehört zu Schicht 7. HTTPS gehört zu Schicht 7, nutzt aber TLS. DNS gehört zu Schicht 7. DHCP gehört zu Schicht 7, obwohl es IP-Konfiguration vergibt. Port gehört zu Schicht 4. Dienstprotokoll gehört zu Schicht 7. TCP 443 offen bedeutet nicht automatisch, dass die Webseite funktioniert. HTTP-Statuscode 404 ist ein Anwendungsschicht-Hinweis. HTTP-Statuscode 500 deutet auf Server- oder Anwendungsproblem hin. SMTP sendet E-Mails. POP3 und IMAP empfangen E-Mails. SFTP ist nicht FTPS. Telnet ist unverschlüsselt. SSH ist sicherer als Telnet. --- **Wichtige Begriffe kurz erklärt** | Begriff | Kurze Erklärung | |---|---| | Anwendungsschicht | OSI-Schicht 7 | | HTTP | Webprotokoll | | HTTPS | HTTP über TLS | | DNS | Namensauflösung | | DHCP | automatische IP-Konfiguration | | SMTP | E-Mail senden | | POP3 | E-Mail abrufen | | IMAP | E-Mail abrufen und verwalten | | FTP | Dateiübertragung | | SFTP | Dateiübertragung über SSH | | FTPS | FTP mit TLS | | SSH | sicherer Fernzugriff | | SMB | Datei- und Druckerfreigaben | | LDAP | Verzeichnisdienstzugriff | | SNMP | Netzwerkmanagement | | NTP | Zeitsynchronisation | | API | Schnittstelle zwischen Anwendungen | | REST | Architekturstil für Web-APIs | | Request | Anfrage | | Response | Antwort | | Statuscode | Ergebnis einer HTTP-Anfrage | | Authentifizierung | Identität prüfen | | Autorisierung | Rechte prüfen | --- **IHK-sichere Kurzformulierung** Die Anwendungsschicht ist Schicht 7 des OSI-Modells. Sie stellt Netzwerkdienste für Anwendungen bereit. Typische Protokolle der Anwendungsschicht sind HTTP, HTTPS, DNS, DHCP, SMTP, POP3, IMAP, FTP, SSH, SMB, LDAP, SNMP und NTP. Die Anwendungsschicht ist nicht einfach das Programm selbst, sondern umfasst die Protokolle und Dienste, die Anwendungen für die Netzwerkkommunikation verwenden. Ports gehören zur Transportschicht, während die eigentlichen Dienstprotokolle zur Anwendungsschicht gehören. Fehler auf Schicht 7 betreffen häufig Dienste, Anmeldungen, DNS, HTTP-Statuscodes, APIs, Datenformate oder Berechtigungen. --- **Merksätze** Schicht 7 = Anwendungsschicht. Schicht 7 = Netzwerkdienste für Anwendungen. Anwendung nutzt Schicht-7-Protokoll. Browser ist Anwendung, HTTP ist Protokoll. Port gehört zu Schicht 4. Dienstprotokoll gehört zu Schicht 7. HTTP = Webprotokoll. HTTPS = HTTP über TLS. DNS = Name zu IP-Adresse. A-Record = IPv4. AAAA-Record = IPv6. MX = Mailserver. DHCP = automatische IP-Konfiguration. DHCP ist trotz IP-Bezug Schicht 7. SMTP sendet E-Mails. POP3 ruft E-Mails ab. IMAP verwaltet E-Mails auf dem Server. FTP ist klassische Dateiübertragung. SFTP ist Dateiübertragung über SSH. FTPS ist FTP mit TLS. SSH = sicherer Fernzugriff. SMB = Datei- und Druckerfreigaben. LDAP = Verzeichnisdienst. SNMP = Netzwerküberwachung. NTP = Zeitsynchronisation. 2xx = Erfolg. 4xx = Clientfehler. 5xx = Serverfehler. Offener Port heißt nicht automatisch: Anwendung funktioniert. Schicht 7 prüft Dienst, Inhalt, Anmeldung und Berechtigung. # 10.2 HTTP, HTTPS und Webkommunikation HTTP und HTTPS gehören zu den wichtigsten Protokollen der Anwendungsschicht. Sie werden vor allem für Webseiten, Webanwendungen und APIs verwendet. HTTP steht für: Hypertext Transfer Protocol HTTPS steht für: Hypertext Transfer Protocol Secure Der wichtigste Unterschied: HTTP ist unverschlüsselt. HTTPS nutzt TLS-Verschlüsselung. Merksatz: HTTP = Webkommunikation ohne TLS. HTTPS = Webkommunikation mit TLS. --- **Grundidee von HTTP** HTTP ist ein Protokoll zur Übertragung von Webinhalten. Ein Client stellt eine Anfrage. Ein Server liefert eine Antwort. Beispiel: Browser fordert Webseite an. Webserver liefert HTML, CSS, JavaScript, Bilder oder Daten zurück. Typische Inhalte: - Webseiten - Bilder - CSS-Dateien - JavaScript-Dateien - JSON-Daten - API-Antworten - Downloads Merksatz: HTTP arbeitet mit Anfrage und Antwort. --- **Client und Server bei HTTP** Bei HTTP gibt es meistens: Client Server Client: stellt Anfrage Server: verarbeitet Anfrage und sendet Antwort Beispiel: Browser = Client Webserver = Server Merksatz: Client fragt an, Server antwortet. --- **Request und Response** Eine HTTP-Kommunikation besteht aus: Request Response Request bedeutet: Anfrage des Clients Response bedeutet: Antwort des Servers Beispiel: Request: Browser fordert /index.html an. Response: Server liefert die Datei index.html zurück. Merksatz: Request = Anfrage. Response = Antwort. --- **HTTP-Request** Ein HTTP-Request enthält unter anderem: - Methode - Pfad oder URL - Header - optionalen Body Beispiel vereinfacht: GET /index.html HTTP/1.1 Host: example.com Bedeutung: Client möchte die Datei /index.html vom Host example.com abrufen. Merksatz: HTTP-Request beschreibt, was der Client vom Server möchte. --- **HTTP-Response** Eine HTTP-Response enthält unter anderem: - Statuscode - Header - optionalen Body Beispiel vereinfacht: HTTP/1.1 200 OK Content-Type: text/html ... Bedeutung: Server antwortet erfolgreich mit HTML-Inhalt. Merksatz: HTTP-Response enthält Ergebnis und Inhalt. --- **URL** URL steht für: Uniform Resource Locator Eine URL beschreibt, wo eine Ressource erreichbar ist. Beispiel: https://www.example.com:443/docs/index.html?seite=1 Bestandteile: | Bestandteil | Beispiel | Bedeutung | |---|---|---| | Schema | https | Protokoll | | Hostname | www.example.com | Servername | | Port | 443 | Dienst-Port | | Pfad | /docs/index.html | Ressource | | Query | ?seite=1 | zusätzliche Parameter | Merksatz: URL = Adresse einer Ressource. --- **Schema** Das Schema steht am Anfang einer URL. Beispiele: http:// https:// Das Schema sagt dem Client, welches Protokoll verwendet werden soll. Beispiel: http://example.com nutzt HTTP. https://example.com nutzt HTTPS. Merksatz: Schema zeigt das verwendete Protokoll. --- **Hostname** Der Hostname ist der Name des Servers. Beispiel: www.example.com Der Hostname muss meist per DNS in eine IP-Adresse aufgelöst werden. Ablauf vereinfacht: Browser kennt Namen. DNS liefert IP-Adresse. Browser verbindet sich zur IP-Adresse. Merksatz: Hostname wird über DNS zur IP-Adresse. --- **Port bei HTTP und HTTPS** HTTP nutzt typischerweise: TCP 80 HTTPS nutzt typischerweise: TCP 443 Wenn kein Port angegeben wird, nutzt der Client den Standardport des Schemas. Beispiele: http://example.com → TCP 80 https://example.com → TCP 443 Merksatz: HTTP = TCP 80. HTTPS = TCP 443. --- **Pfad** Der Pfad zeigt, welche Ressource auf dem Server angefordert wird. Beispiele: / /index.html /produkte /api/users /bilder/logo.png Der Server entscheidet, welcher Inhalt zu diesem Pfad geliefert wird. Merksatz: Pfad zeigt die gewünschte Ressource auf dem Server. --- **Query-Parameter** Query-Parameter stehen nach einem Fragezeichen. Beispiel: /suche?q=netzwerk&page=2 Bedeutung: q=netzwerk page=2 Query-Parameter übergeben zusätzliche Informationen an den Server. Typisch bei: - Suchfunktionen - Filtern - Seitennummern - API-Abfragen Merksatz: Query-Parameter geben Zusatzinformationen mit. --- **HTTP-Methoden** HTTP-Methoden beschreiben, was der Client tun möchte. Wichtige Methoden: | Methode | Bedeutung | |---|---| | GET | Daten abrufen | | POST | Daten senden oder erstellen | | PUT | Ressource vollständig ersetzen | | PATCH | Ressource teilweise ändern | | DELETE | Ressource löschen | | HEAD | nur Kopfzeilen abrufen | | OPTIONS | unterstützte Möglichkeiten abfragen | Merksatz: GET liest. POST sendet. PUT ersetzt. PATCH ändert teilweise. DELETE löscht. --- **GET** GET wird verwendet, um Daten abzurufen. Beispiele: Webseite laden Bild abrufen API-Daten lesen GET sollte normalerweise keine Daten verändern. Beispiel: GET /artikel/10 Bedeutung: Artikel 10 abrufen. Merksatz: GET = Daten abrufen. --- **POST** POST wird verwendet, um Daten an den Server zu senden. Beispiele: Formular absenden Benutzer erstellen Datei hochladen API-Daten senden Beispiel: POST /login Bedeutung: Login-Daten werden an den Server gesendet. Merksatz: POST = Daten an Server senden. --- **PUT** PUT ersetzt eine Ressource vollständig. Beispiel: PUT /users/5 Bedeutung: Benutzer 5 wird vollständig mit den gesendeten Daten ersetzt. Merksatz: PUT = vollständig ersetzen. --- **PATCH** PATCH ändert eine Ressource teilweise. Beispiel: PATCH /users/5 Bedeutung: Bei Benutzer 5 wird nur ein Teil geändert, zum Beispiel die E-Mail-Adresse. Merksatz: PATCH = teilweise ändern. --- **DELETE** DELETE löscht eine Ressource. Beispiel: DELETE /users/5 Bedeutung: Benutzer 5 löschen. Merksatz: DELETE = Ressource löschen. --- **HTTP-Header** HTTP-Header enthalten Zusatzinformationen zur Anfrage oder Antwort. Beispiele: | Header | Bedeutung | |---|---| | Host | angefragter Hostname | | User-Agent | Client-Information | | Accept | gewünschte Antwortformate | | Content-Type | Format des gesendeten Inhalts | | Authorization | Authentifizierungsdaten | | Cookie | Cookie-Daten | | Set-Cookie | Server setzt Cookie | | Cache-Control | Cache-Verhalten | | Location | Weiterleitungsziel | Merksatz: Header enthalten Zusatzinformationen. --- **Content-Type** Content-Type beschreibt, welches Datenformat im Body enthalten ist. Beispiele: | Content-Type | Bedeutung | |---|---| | text/html | HTML-Webseite | | application/json | JSON-Daten | | application/xml | XML-Daten | | text/plain | einfacher Text | | image/png | PNG-Bild | | application/pdf | PDF-Dokument | Merksatz: Content-Type sagt, welches Format der Inhalt hat. --- **Accept-Header** Der Accept-Header sagt dem Server, welche Antwortformate der Client akzeptiert. Beispiel: Accept: application/json Bedeutung: Client möchte JSON als Antwort erhalten. Merksatz: Accept sagt, was der Client empfangen möchte. --- **Authorization-Header** Der Authorization-Header wird für Authentifizierung verwendet. Beispiele: Bearer Token Basic Authentication API-Key-Verfahren Beispiel vereinfacht: Authorization: Bearer eyJ... Wichtig: Solche Daten müssen geschützt übertragen werden. Deshalb sollte dafür HTTPS genutzt werden. Merksatz: Authorization-Header enthält Zugriffsinformationen. --- **Cookies** Cookies sind kleine Daten, die der Server im Browser speichern lassen kann. Der Server sendet: Set-Cookie Der Browser sendet später: Cookie Typische Nutzung: - Sitzung wiedererkennen - Login-Status - Spracheinstellung - Warenkorb - Tracking Merksatz: Cookies helfen, Zustand über mehrere HTTP-Anfragen zu merken. --- **HTTP ist zustandslos** HTTP ist grundsätzlich zustandslos. Das bedeutet: Jede Anfrage ist zunächst unabhängig. Ohne Cookies, Tokens oder andere Mechanismen wüsste der Server nicht automatisch, dass mehrere Anfragen zum gleichen Benutzer gehören. Beispiel: Anfrage 1: Login Anfrage 2: Dashboard öffnen Der Server braucht einen Mechanismus, um die Sitzung wiederzuerkennen. Merksatz: HTTP ist zustandslos, Sitzungen schaffen Zusammenhang. --- **Session-Cookie** Ein Session-Cookie kann eine Session-ID enthalten. Damit erkennt der Server: Diese Anfrage gehört zu einer bestimmten Sitzung. Beispiel: Benutzer meldet sich an. Server setzt Session-Cookie. Browser sendet Cookie bei weiteren Anfragen mit. Server erkennt Benutzer wieder. Merksatz: Session-Cookie verbindet mehrere HTTP-Anfragen zu einer Sitzung. --- **HTTPS** HTTPS ist HTTP über TLS. Dabei werden HTTP-Daten verschlüsselt übertragen. Schutz durch TLS: - Schutz vor Mitlesen - Schutz vor unbemerkter Veränderung - Prüfung der Serveridentität über Zertifikat Merksatz: HTTPS schützt HTTP-Kommunikation mit TLS. --- **Ablauf bei HTTPS vereinfacht** Bei HTTPS passiert vereinfacht: 1. DNS löst den Namen auf. 2. TCP-Verbindung zu Port 443 wird aufgebaut. 3. TLS-Handshake findet statt. 4. Zertifikat wird geprüft. 5. HTTP-Anfrage wird verschlüsselt gesendet. 6. HTTP-Antwort wird verschlüsselt empfangen. Merksatz: Bei HTTPS kommt vor HTTP zuerst TCP und TLS. --- **HTTP und TLS unterscheiden** | Thema | Einordnung | |---|---| | HTTP | Anwendungsschicht-Protokoll | | HTTPS | HTTP über TLS | | TLS | Verschlüsselungs- und Schutzschicht | | TCP 443 | Transportverbindung | | Zertifikat | Vertrauensnachweis bei TLS | Merksatz: HTTP spricht die Anwendung. TLS schützt die Verbindung. TCP transportiert. --- **HTTP-Versionen** Es gibt verschiedene HTTP-Versionen. Wichtige Versionen: | Version | Kurzidee | |---|---| | HTTP/1.1 | klassisch, weit verbreitet | | HTTP/2 | effizientere Übertragung über eine Verbindung | | HTTP/3 | nutzt QUIC über UDP | Wichtig für die Prüfung: HTTP/3 nutzt QUIC über UDP. Klassisches HTTPS nutzt häufig TCP 443. Merksatz: HTTP/3 nutzt QUIC über UDP. --- **HTTP/1.1** HTTP/1.1 ist eine klassische und weit verbreitete Version. Typische Merkmale: - Request/Response - Header - Host-Header wichtig für virtuelle Hosts - mehrere Anfragen möglich - sehr verbreitet Merksatz: HTTP/1.1 ist die klassische Webkommunikation. --- **HTTP/2** HTTP/2 verbessert die Effizienz der Webkommunikation. Vorteile: - mehrere Streams über eine Verbindung - bessere Nutzung einer Verbindung - Header-Kompression - geringere Ladezeiten möglich Für die Prüfung reicht meist: HTTP/2 ist moderner und effizienter als HTTP/1.1. Merksatz: HTTP/2 kann mehrere Übertragungen effizienter bündeln. --- **HTTP/3** HTTP/3 basiert auf QUIC. QUIC nutzt UDP. Typisch: UDP 443 Vorteile: - schnellerer Verbindungsaufbau - bessere Leistung bei Paketverlust - moderne Webkommunikation Prüfungsfalle: HTTPS bedeutet nicht immer nur TCP 443, bei HTTP/3 kann UDP 443 relevant sein. Merksatz: HTTP/3 = HTTP über QUIC über UDP. --- **Statuscodes** HTTP-Statuscodes zeigen das Ergebnis einer Anfrage. Sie stehen in der HTTP-Antwort. Beispiel: 200 OK Bedeutung: Anfrage erfolgreich. Merksatz: Statuscode zeigt, wie der Server die Anfrage beantwortet hat. --- **Statuscode-Bereiche** | Bereich | Bedeutung | |---|---| | 1xx | Information | | 2xx | Erfolg | | 3xx | Weiterleitung | | 4xx | Clientfehler | | 5xx | Serverfehler | Merksatz: 2xx = Erfolg. 3xx = Weiterleitung. 4xx = Clientfehler. 5xx = Serverfehler. --- **Wichtige HTTP-Statuscodes** | Statuscode | Bedeutung | |---:|---| | 200 | OK | | 201 | Created | | 301 | dauerhaft weitergeleitet | | 302 | vorübergehend weitergeleitet | | 304 | nicht verändert | | 400 | fehlerhafte Anfrage | | 401 | nicht authentifiziert | | 403 | verboten | | 404 | nicht gefunden | | 405 | Methode nicht erlaubt | | 429 | zu viele Anfragen | | 500 | interner Serverfehler | | 502 | Bad Gateway | | 503 | Dienst nicht verfügbar | | 504 | Gateway Timeout | Merksatz: 404 = nicht gefunden. 500 = Serverfehler. 502 = Gateway-Problem. 503 = Dienst nicht verfügbar. --- **401 und 403 unterscheiden** 401 bedeutet: nicht authentifiziert Der Benutzer ist nicht oder nicht gültig angemeldet. 403 bedeutet: verboten Der Benutzer ist zwar eventuell bekannt, hat aber keine Berechtigung. Merksatz: 401 = wer bist du? 403 = du darfst das nicht. --- **404 Not Found** 404 bedeutet: Ressource nicht gefunden Mögliche Ursachen: - falscher Pfad - Datei fehlt - Route in Anwendung fehlt - Link falsch - Ressource wurde gelöscht - Rewrite-Regel falsch Merksatz: 404 = angeforderte Ressource existiert dort nicht. --- **500 Internal Server Error** 500 bedeutet: interner Serverfehler Mögliche Ursachen: - Fehler in Anwendung - Datenbankfehler - Programmierfehler - falsche Konfiguration - fehlende Rechte - Dienstproblem Merksatz: 500 = Server oder Anwendung hat intern ein Problem. --- **502 Bad Gateway** 502 tritt häufig bei Proxys oder Gateways auf. Bedeutung: Ein Gateway oder Proxy hat keine gültige Antwort vom Backend erhalten. Mögliche Ursachen: - Backend-Dienst down - falscher Backend-Port - Reverse Proxy falsch konfiguriert - Verbindung zum Backend scheitert - Backend antwortet ungültig Merksatz: 502 = Proxy erreicht Backend nicht sauber. --- **503 Service Unavailable** 503 bedeutet: Dienst nicht verfügbar Mögliche Ursachen: - Server überlastet - Wartungsmodus - Anwendung nicht gestartet - Backend nicht verfügbar - Ressourcenmangel Merksatz: 503 = Dienst aktuell nicht verfügbar. --- **504 Gateway Timeout** 504 bedeutet: Gateway Timeout Ein Proxy oder Gateway wartet zu lange auf Antwort vom Backend. Mögliche Ursachen: - Backend langsam - Backend hängt - Netzwerkproblem zum Backend - Timeout zu kurz eingestellt - Datenbankantwort dauert zu lange Merksatz: 504 = Gateway wartet zu lange auf Backend. --- **Weiterleitungen** Weiterleitungen gehören zu den 3xx-Statuscodes. Beispiele: 301 302 301 bedeutet: dauerhaft weitergeleitet 302 bedeutet: vorübergehend weitergeleitet Der neue Ort steht häufig im Header: Location Merksatz: 3xx bedeutet: Client soll woanders hin. --- **Cache** Caching bedeutet: Inhalte werden zwischengespeichert. Ziel: schnellere Ladezeiten weniger Serverlast weniger Datenverkehr Caches können existieren bei: - Browser - Proxy - CDN - Anwendung - DNS Merksatz: Cache speichert Daten, um spätere Anfragen schneller zu beantworten. --- **Cache-Control** Cache-Control ist ein HTTP-Header. Er steuert, wie Inhalte zwischengespeichert werden dürfen. Beispiele: Cache-Control: no-cache Cache-Control: no-store Cache-Control: max-age=3600 Merksatz: Cache-Control steuert HTTP-Caching. --- **API und HTTP** Viele APIs nutzen HTTP oder HTTPS. Typisch: URL beschreibt Ressource. HTTP-Methode beschreibt Aktion. Header enthalten Zusatzinformationen. Body enthält Daten. Statuscode zeigt Ergebnis. Beispiel: GET /api/users Bedeutung: Benutzer abrufen. Merksatz: Web-APIs nutzen HTTP als Kommunikationsgrundlage. --- **REST und HTTP** REST nutzt HTTP-Ideen für APIs. Typisch: | Aktion | HTTP-Methode | Beispiel | |---|---|---| | lesen | GET | GET /users | | erstellen | POST | POST /users | | ersetzen | PUT | PUT /users/5 | | teilweise ändern | PATCH | PATCH /users/5 | | löschen | DELETE | DELETE /users/5 | Merksatz: REST ordnet Aktionen oft HTTP-Methoden zu. --- **JSON bei APIs** Viele APIs nutzen JSON als Datenformat. Beispiel: { "id": 5, "name": "Felix", "rolle": "admin" } Wichtig: JSON gehört als Datenformat eher zu Schicht 6, wird aber häufig in Schicht-7-APIs genutzt. Merksatz: APIs nutzen oft JSON für strukturierte Daten. --- **Content-Type bei APIs** Bei APIs ist Content-Type besonders wichtig. Beispiel: Content-Type: application/json Bedeutung: Der Body enthält JSON. Wenn Content-Type falsch ist, kann der Server die Daten falsch interpretieren oder ablehnen. Merksatz: Falscher Content-Type kann API-Fehler verursachen. --- **Authentifizierung bei Webdiensten** Webdienste können unterschiedliche Authentifizierungsarten nutzen. Beispiele: - Benutzername und Passwort - Session-Cookie - Bearer Token - API-Key - Client-Zertifikat - OAuth - OpenID Connect - Multi-Faktor-Authentifizierung Merksatz: Webdienste müssen oft Benutzer oder Clients prüfen. --- **Bearer Token** Ein Bearer Token ist ein Zugriffstoken. Es wird häufig im Authorization-Header gesendet. Beispiel: Authorization: Bearer Wichtig: Wer den Token besitzt, kann ihn oft verwenden. Deshalb muss er geschützt werden. Merksatz: Bearer Token wie ein Passwort schützen. --- **CORS kurz erklärt** CORS steht für: Cross-Origin Resource Sharing CORS regelt, ob ein Browser eine Webseite von einer Herkunft auf Ressourcen einer anderen Herkunft zugreifen lässt. Beispiel: Webseite von app.firma.de ruft API von api.firma.de auf Wenn CORS nicht passend konfiguriert ist, blockiert der Browser die Anfrage. Merksatz: CORS ist eine Browser-Sicherheitsregel für Webanfragen. --- **Same-Origin Policy** Die Same-Origin Policy ist eine wichtige Browser-Sicherheitsregel. Sie begrenzt, wie Webseiten auf Daten anderer Herkunft zugreifen dürfen. Herkunft besteht aus: - Schema - Host - Port Beispiel: https://app.firma.de:443 Merksatz: Gleiche Herkunft = Schema, Host und Port passen. --- **Mixed Content** Mixed Content bedeutet: Eine HTTPS-Seite lädt Inhalte über HTTP nach. Beispiel: Hauptseite: https://wiki.firma.de eingebundenes Script: http://example.com/script.js Browser blockieren solche Inhalte oft oder warnen. Merksatz: HTTPS-Seiten sollten keine HTTP-Inhalte nachladen. --- **Reverse Proxy** Ein Reverse Proxy steht vor einem oder mehreren internen Diensten. Ablauf: Client → Reverse Proxy → Backend-Server Typische Aufgaben: - TLS beenden - Anfragen weiterleiten - mehrere Dienste über eine Domainstruktur bereitstellen - Lastverteilung - Zugriffsschutz - Header setzen - Weiterleitungen durchführen Merksatz: Reverse Proxy nimmt Anfragen an und leitet sie intern weiter. --- **Backend** Backend bezeichnet den Dienst, der hinter einem Reverse Proxy arbeitet. Beispiel: Client ruft https://wiki.firma.de auf. Reverse Proxy nimmt Anfrage an. Backend ist der interne Webdienst. Mögliche Fehler: - Backend läuft nicht - falscher Backend-Port - falsches Protokoll HTTP/HTTPS - Firewall blockiert intern - falscher Pfad Merksatz: Backend = eigentlicher Dienst hinter Proxy oder Anwendung. --- **Host-Header** Der Host-Header sagt dem Webserver, welcher Hostname angefragt wurde. Beispiel: Host: wiki.firma.de Das ist wichtig, wenn mehrere Webseiten auf derselben IP-Adresse laufen. Der Server entscheidet anhand des Host-Headers, welche Webseite ausgeliefert wird. Merksatz: Host-Header ermöglicht mehrere Webseiten auf einer IP. --- **Virtueller Host** Ein virtueller Host erlaubt, mehrere Webseiten oder Dienste auf einem Server zu betreiben. Beispiel: wiki.firma.de cloud.firma.de shop.firma.de Alle können auf dieselbe IP zeigen, aber unterschiedliche Inhalte liefern. Merksatz: Virtuelle Hosts unterscheiden Webseiten über Hostnamen. --- **Fehlerbild: Webseite nicht erreichbar** Mögliche Ursachen nach Schichten: Schicht 3: IP, Gateway oder Routing falsch Schicht 4: TCP 80 oder 443 nicht erreichbar Schicht 6: TLS-Zertifikat fehlerhaft Schicht 7: HTTP-Fehler, Anwendung, Pfad oder Backend Merksatz: Webfehler systematisch nach Schichten prüfen. --- **Fehlerbild: HTTP 404** Mögliche Ursachen: - falscher Pfad - Datei existiert nicht - Route in Anwendung fehlt - Reverse Proxy leitet falsch weiter - falsche Base-URL - Anwendung erwartet anderen Pfad Merksatz: 404 = Ressource unter diesem Pfad nicht gefunden. --- **Fehlerbild: HTTP 500** Mögliche Ursachen: - Fehler in Anwendung - Datenbank nicht erreichbar - falsche Rechte - Konfigurationsfehler - Abhängigkeit fehlt - Programmfehler - Speicher- oder Ressourcenproblem Merksatz: 500 = Anwendung oder Server hat intern ein Problem. --- **Fehlerbild: HTTP 502** Mögliche Ursachen: - Reverse Proxy erreicht Backend nicht - Backend-Port falsch - Backend-Protokoll falsch - Backend abgestürzt - Firewall blockiert intern - falscher Container-Name oder DNS-Name - Timeout oder ungültige Backend-Antwort Merksatz: 502 = Proxy-zu-Backend prüfen. --- **Fehlerbild: Login-Schleife** Eine Login-Schleife bedeutet: Benutzer meldet sich an, landet aber wieder auf Login-Seite. Mögliche Ursachen: - Session-Cookie wird nicht gespeichert - Cookie-Domain falsch - Cookie-Pfad falsch - HTTP/HTTPS-Wechsel - SameSite-Problem - Server verliert Session-State - falsche Systemzeit - Token ungültig Merksatz: Login-Schleifen sind oft Cookie-, Session- oder Token-Probleme. --- **Fehlerbild: API lehnt Anfrage ab** Mögliche Ursachen: - falsche HTTP-Methode - falsche URL - fehlender Authorization-Header - Token ungültig - falscher Content-Type - ungültiges JSON - fehlende Pflichtfelder - fehlende Berechtigung - Rate Limit erreicht Merksatz: API-Fehler mit Methode, URL, Header, Body und Statuscode prüfen. --- **Fehlersuche bei Webkommunikation** Eine sinnvolle Reihenfolge: 1. DNS-Name wird korrekt aufgelöst? 2. Ziel-IP erreichbar? 3. TCP-Port 80 oder 443 erreichbar? 4. TLS-Zertifikat gültig? 5. HTTP-Statuscode prüfen. 6. Weiterleitungen prüfen. 7. Header prüfen. 8. Cookies und Session prüfen. 9. Reverse Proxy prüfen. 10. Backend und Anwendungslogs prüfen. Merksatz: Bei Webfehlern erst Verbindung, dann TLS, dann HTTP, dann Anwendung prüfen. --- **HTTP-Logs** HTTP-Logs helfen bei der Fehlersuche. Typische Informationen: - Client-IP - Zeit - Methode - Pfad - Statuscode - Antwortgröße - User-Agent - Referer - Bearbeitungszeit Beispiele für wichtige Fragen: Kommt die Anfrage beim Server an? Welcher Pfad wird aufgerufen? Welcher Statuscode wird geliefert? Ist der Fehler nur bei bestimmten Clients? Merksatz: HTTP-Logs zeigen, was der Webserver tatsächlich beantwortet. --- **Reverse-Proxy-Logs** Reverse-Proxy-Logs sind wichtig, wenn ein Proxy zwischen Client und Backend steht. Sie zeigen oft: - eingehende Anfrage - gewähltes Backend - Statuscode - Upstream-Fehler - Timeout - TLS-Informationen - Weiterleitungsprobleme Merksatz: Bei 502, 503 und 504 zuerst Proxy und Backend prüfen. --- **Sicherheit bei HTTP und HTTPS** Wichtige Sicherheitsregeln: - HTTPS statt HTTP verwenden - Zertifikate aktuell halten - sichere Cookies setzen - sensible Daten nicht in URLs schreiben - Eingaben prüfen - Authentifizierung schützen - Rechte sauber prüfen - unnötige Header vermeiden - nicht benötigte Dienste abschalten - Logs datenschutzbewusst behandeln Merksatz: Websicherheit betrifft Transport, Anwendung und Benutzerzugriff. --- **Sensible Daten nicht in URLs** Sensible Daten sollten nicht in Query-Parametern stehen. Problem: URLs können in Logs, Browserhistorie, Proxys oder Referer-Headern auftauchen. Schlecht: /login?password=geheim Besser: sensible Daten im Body übertragen und HTTPS verwenden. Merksatz: Passwörter und Tokens gehören nicht in URLs. --- **HTTP und Datenschutz** HTTP-Logs können personenbezogene Daten enthalten. Beispiele: - IP-Adressen - Benutzerkennungen - Pfade - Suchbegriffe - Tokens in URLs - Zeitstempel Deshalb wichtig: Logs schützen, Aufbewahrung begrenzen, sensible Daten vermeiden. Merksatz: Weblogs können sensible Informationen enthalten. --- **Einordnung in das OSI-Modell** | Thema | Schicht | |---|---:| | IP-Adresse | 3 | | TCP 80 / TCP 443 | 4 | | TLS | 6 mit Bezug zu 4 und 7 | | HTTP | 7 | | HTTPS | 7 über TLS | | URL | 7 | | HTTP-Header | 7 | | HTTP-Methode | 7 | | HTTP-Statuscode | 7 | | Cookie | 7 mit Sitzungsbezug | | JSON-Format | 6 / 7-Bezug | | Reverse Proxy | 7 mit Bezug zu 4 und 6 | Merksatz: HTTP ist Schicht 7. TLS schützt darunter. TCP transportiert darunter. --- **Typische IHK-Fragen** In AP1 und AP2 kann zum Beispiel gefragt werden: - Was ist HTTP? - Was ist HTTPS? - Was ist der Unterschied zwischen HTTP und HTTPS? - Welche Ports nutzen HTTP und HTTPS? - Was ist ein HTTP-Request? - Was ist eine HTTP-Response? - Was ist eine URL? - Was bedeuten GET, POST, PUT, PATCH und DELETE? - Was ist ein HTTP-Header? - Was bedeutet Content-Type? - Was ist ein Cookie? - Warum ist HTTP zustandslos? - Was bedeuten HTTP-Statuscodes? - Was ist der Unterschied zwischen 401 und 403? - Was bedeuten 404, 500, 502, 503 und 504? - Was ist ein Reverse Proxy? - Warum kann eine Webseite trotz offenem Port Fehler anzeigen? --- **Typische Prüfungsfallen** HTTP gehört zu Schicht 7. HTTPS gehört zu Schicht 7, nutzt aber TLS. HTTP nutzt typischerweise TCP 80. HTTPS nutzt typischerweise TCP 443. HTTP/3 nutzt QUIC über UDP. Port gehört zu Schicht 4. HTTP-Methode gehört zu Schicht 7. HTTP-Statuscode gehört zu Schicht 7. TLS-Zertifikatsfehler sind nicht einfach HTTP-Fehler. HTTP ist grundsätzlich zustandslos. Cookies helfen bei Sitzungen. GET sollte Daten abrufen. POST sendet Daten an den Server. 401 bedeutet nicht authentifiziert. 403 bedeutet verboten. 404 bedeutet nicht gefunden. 500 bedeutet interner Serverfehler. 502 deutet häufig auf Proxy-Backend-Problem. 503 bedeutet Dienst nicht verfügbar. 504 bedeutet Gateway Timeout. Offener TCP-Port 443 heißt nicht, dass die Webanwendung korrekt funktioniert. --- **Wichtige Begriffe kurz erklärt** | Begriff | Kurze Erklärung | |---|---| | HTTP | Webprotokoll | | HTTPS | HTTP über TLS | | Request | Anfrage des Clients | | Response | Antwort des Servers | | URL | Adresse einer Ressource | | Schema | Protokollteil einer URL | | Hostname | Name des Servers | | Pfad | angeforderte Ressource | | Query | Zusatzparameter in URL | | Methode | Aktion einer HTTP-Anfrage | | Header | Zusatzinformationen | | Body | Nutzdaten einer Anfrage oder Antwort | | Content-Type | Format des Inhalts | | Cookie | gespeicherte Webinformation | | Session-Cookie | Cookie zur Sitzungszuordnung | | Statuscode | Ergebnis einer HTTP-Anfrage | | Redirect | Weiterleitung | | Cache | Zwischenspeicher | | API | Anwendungsschnittstelle | | REST | API-Architekturstil | | Bearer Token | Zugriffstoken | | CORS | Browser-Regel für fremde Herkunft | | Reverse Proxy | vorgelagerter Webserver | | Backend | interner Ziel-Dienst | --- **IHK-sichere Kurzformulierung** HTTP ist ein Anwendungsschicht-Protokoll zur Übertragung von Webinhalten. Es arbeitet mit Requests und Responses. Ein Client fordert eine Ressource über eine URL an, der Server antwortet mit Headern, einem Statuscode und optionalem Inhalt. HTTPS ist HTTP über TLS und schützt die Übertragung durch Verschlüsselung, Integrität und Serverauthentifizierung. HTTP nutzt typischerweise TCP-Port 80, HTTPS typischerweise TCP-Port 443. HTTP-Methoden wie GET, POST, PUT, PATCH und DELETE beschreiben die gewünschte Aktion. HTTP-Statuscodes zeigen das Ergebnis einer Anfrage an. Fehler wie 404, 500, 502, 503 oder 504 helfen bei der Fehlersuche auf Anwendungsschicht. --- **Merksätze** HTTP = Hypertext Transfer Protocol. HTTPS = HTTP über TLS. HTTP gehört zu Schicht 7. HTTPS gehört zu Schicht 7 mit TLS-Bezug. HTTP nutzt typischerweise TCP 80. HTTPS nutzt typischerweise TCP 443. HTTP/3 nutzt QUIC über UDP. Client stellt Request. Server sendet Response. URL zeigt Ressource. Hostname wird per DNS aufgelöst. GET ruft Daten ab. POST sendet Daten. PUT ersetzt vollständig. PATCH ändert teilweise. DELETE löscht. Header enthalten Zusatzinformationen. Content-Type beschreibt das Datenformat. Cookie hilft bei Sitzungen. HTTP ist zustandslos. HTTPS schützt HTTP mit TLS. Erst TCP, dann TLS, dann HTTP. 2xx = Erfolg. 3xx = Weiterleitung. 4xx = Clientfehler. 5xx = Serverfehler. 401 = nicht authentifiziert. 403 = verboten. 404 = nicht gefunden. 500 = interner Serverfehler. 502 = Bad Gateway. 503 = Dienst nicht verfügbar. 504 = Gateway Timeout. Offener Port heißt nicht: Webanwendung funktioniert. Bei Webfehlern DNS, IP, Port, TLS, HTTP und Anwendung prüfen. # 10.3 DNS und Namensauflösung DNS gehört zur OSI-Schicht 7. DNS steht für: Domain Name System Die Hauptaufgabe von DNS ist: Namen in IP-Adressen auflösen. Beispiel: www.example.com → 93.184.216.34 Menschen merken sich Namen leichter als IP-Adressen. Computer benötigen aber IP-Adressen, um über das Netzwerk zu kommunizieren. Merksatz: DNS = Name zu IP-Adresse. --- **Warum braucht man DNS?** Ohne DNS müsste man sich IP-Adressen merken. Beispiel ohne DNS: 93.184.216.34 Beispiel mit DNS: www.example.com DNS macht Netzwerke benutzerfreundlicher und flexibler. Wenn sich die IP-Adresse eines Servers ändert, kann der DNS-Eintrag angepasst werden, ohne dass sich der Name ändern muss. Merksatz: DNS trennt Namen von IP-Adressen. --- **DNS im OSI-Modell** DNS ist ein Anwendungsschicht-Protokoll. Es nutzt Transportprotokolle aus Schicht 4. Typisch: UDP 53 TCP 53 Wichtig: DNS-Port 53 gehört zu Schicht 4. DNS-Protokoll gehört zu Schicht 7. Merksatz: DNS nutzt Ports, ist aber ein Dienst der Anwendungsschicht. --- **DNS und IP-Kommunikation** DNS ist nicht nötig, wenn direkt mit einer IP-Adresse kommuniziert wird. Beispiel: ping 8.8.8.8 Hier wird kein DNS-Name benötigt. DNS wird benötigt bei: ping www.example.com Denn der Name muss zuerst in eine IP-Adresse aufgelöst werden. Merksatz: IP-Adresse direkt = kein DNS nötig. Name verwenden = DNS nötig. --- **Typischer Ablauf einer Namensauflösung** Vereinfacht: 1. Benutzer gibt Namen ein. 2. Client prüft lokalen Cache. 3. Client fragt DNS-Resolver. 4. Resolver sucht die passende Antwort. 5. Resolver liefert IP-Adresse zurück. 6. Client verbindet sich zur IP-Adresse. Beispiel: Browser: www.example.com öffnen DNS: www.example.com = 93.184.216.34 Browser: Verbindung zu 93.184.216.34 aufbauen Merksatz: Erst Name auflösen, dann Verbindung zur IP-Adresse aufbauen. --- **DNS-Client** Der DNS-Client ist das System, das eine DNS-Anfrage stellt. Beispiele: - PC - Smartphone - Server - Browser - Anwendung - Betriebssystem Der Client fragt normalerweise nicht direkt alle DNS-Server im Internet, sondern nutzt einen eingetragenen DNS-Resolver. Merksatz: DNS-Client stellt die Anfrage. --- **DNS-Resolver** Ein DNS-Resolver beantwortet DNS-Anfragen für Clients. Er kann: - Antworten aus Cache liefern - andere DNS-Server fragen - rekursive Auflösung durchführen - lokale DNS-Zonen kennen Beispiele für Resolver: - Router im Heimnetz - interner DNS-Server - Provider-DNS - öffentlicher DNS-Dienst Merksatz: Resolver sucht die Antwort für den Client. --- **Rekursive DNS-Abfrage** Bei einer rekursiven Abfrage erwartet der Client vom Resolver eine fertige Antwort. Der Client fragt: Welche IP hat www.example.com? Der Resolver kümmert sich darum, die Antwort zu finden. Der Client erhält am Ende: IP-Adresse oder Fehler Merksatz: Rekursiv = Resolver erledigt die Suche für den Client. --- **Iterative DNS-Abfrage** Bei einer iterativen Abfrage liefert ein DNS-Server nicht unbedingt die endgültige Antwort. Er kann stattdessen sagen: Frag den nächsten zuständigen Server. Das passiert typischerweise zwischen DNS-Servern bei der Auflösung. Merksatz: Iterativ = Server verweist auf nächsten zuständigen Server. --- **DNS-Hierarchie** DNS ist hierarchisch aufgebaut. Vereinfacht: Root Top-Level-Domain Domain Subdomain Hostname Beispiel: www.example.com Aufteilung: | Teil | Bedeutung | |---|---| | . | Root | | com | Top-Level-Domain | | example | Domain | | www | Hostname oder Subdomain | Merksatz: DNS ist wie ein Baum aufgebaut. --- **Root-DNS-Server** Root-DNS-Server stehen ganz oben in der DNS-Hierarchie. Sie kennen nicht jede einzelne Domain, aber sie wissen, welche Nameserver für Top-Level-Domains zuständig sind. Beispiel: Für .de frage diese Nameserver. Für .com frage diese Nameserver. Merksatz: Root-Server verweisen auf TLD-Nameserver. --- **Top-Level-Domain** Eine Top-Level-Domain ist der rechte Teil eines Domainnamens. Beispiele: .de .com .org .net .edu Bei: www.example.com ist: .com die Top-Level-Domain. Merksatz: TLD = oberster Domainbereich wie .de oder .com. --- **Authoritative DNS-Server** Ein authoritative DNS-Server ist für eine DNS-Zone zuständig. Er enthält verbindliche Informationen für eine Domain. Beispiel: Der authoritative DNS-Server für example.com kennt Einträge wie: www.example.com mail.example.com api.example.com Merksatz: Authoritative DNS-Server liefern verbindliche Antworten für eine Zone. --- **DNS-Zone** Eine DNS-Zone ist ein verwalteter Bereich im DNS. Beispiel: example.com In dieser Zone können Einträge liegen wie: www.example.com mail.example.com api.example.com Eine Zone wird von zuständigen DNS-Servern verwaltet. Merksatz: DNS-Zone = verwalteter Namensbereich. --- **Forward Lookup** Forward Lookup bedeutet: Name zu IP-Adresse Beispiel: www.example.com → 93.184.216.34 Das ist die häufigste DNS-Nutzung. Merksatz: Forward Lookup = Name zu IP. --- **Reverse Lookup** Reverse Lookup bedeutet: IP-Adresse zu Name Beispiel: 93.184.216.34 → www.example.com Dafür werden spezielle DNS-Zonen verwendet. Bei IPv4: in-addr.arpa Bei IPv6: ip6.arpa Merksatz: Reverse Lookup = IP zu Name. --- **DNS-Records** DNS speichert Informationen in Records. Ein Record ist ein DNS-Eintrag. Wichtige Record-Typen: | Record | Bedeutung | |---|---| | A | Name zu IPv4-Adresse | | AAAA | Name zu IPv6-Adresse | | CNAME | Alias auf anderen Namen | | MX | Mailserver einer Domain | | NS | zuständiger Nameserver | | TXT | Textinformationen | | PTR | Reverse-DNS-Eintrag | | SRV | Dienststandort | | SOA | Start of Authority | Merksatz: DNS-Records speichern verschiedene Namensinformationen. --- **A-Record** Ein A-Record ordnet einen Namen einer IPv4-Adresse zu. Beispiel: www.example.com → 93.184.216.34 A steht für: Address Merksatz: A-Record = Name zu IPv4. --- **AAAA-Record** Ein AAAA-Record ordnet einen Namen einer IPv6-Adresse zu. Beispiel: www.example.com → 2001:db8::10 Warum AAAA? IPv6-Adressen sind 128 Bit groß. IPv4-Adressen sind 32 Bit groß. 128 Bit sind viermal so groß wie 32 Bit. Merksatz: AAAA-Record = Name zu IPv6. --- **CNAME-Record** Ein CNAME ist ein Alias. CNAME steht für: Canonical Name Beispiel: shop.example.com → webserver.example.com Der Name shop.example.com zeigt also auf einen anderen Namen. Wichtig: Ein CNAME zeigt auf einen Namen, nicht direkt auf eine IP-Adresse. Merksatz: CNAME = Alias auf anderen DNS-Namen. --- **MX-Record** MX steht für: Mail Exchanger Ein MX-Record gibt an, welche Mailserver für eine Domain zuständig sind. Beispiel: example.com MX 10 mail.example.com Die Zahl ist die Priorität. Kleinere Zahl bedeutet: höhere Priorität Merksatz: MX = zuständiger Mailserver einer Domain. --- **NS-Record** NS steht für: Name Server Ein NS-Record gibt an, welche Nameserver für eine Zone zuständig sind. Beispiel: example.com NS ns1.example.com example.com NS ns2.example.com Merksatz: NS = zuständiger Nameserver. --- **TXT-Record** TXT-Records speichern Textinformationen. Typische Nutzung: - SPF - DKIM - DMARC - Domain-Verifizierung - Sicherheitsinformationen - Dienstnachweise Beispiel: v=spf1 include:example.net -all Merksatz: TXT-Record = Textinformationen im DNS. --- **PTR-Record** PTR steht für: Pointer Ein PTR-Record wird für Reverse Lookup verwendet. Er ordnet eine IP-Adresse einem Namen zu. Beispiel: 93.184.216.34 → server.example.com PTR-Records sind besonders bei Mailservern relevant. Merksatz: PTR = Reverse-DNS-Eintrag. --- **SRV-Record** SRV steht für: Service Ein SRV-Record beschreibt, wo ein bestimmter Dienst erreichbar ist. Er kann enthalten: - Dienst - Protokoll - Zielhost - Port - Priorität - Gewichtung Typische Nutzung: - Verzeichnisdienste - VoIP - Microsoft-Dienste - XMPP Merksatz: SRV zeigt, wo ein Dienst erreichbar ist. --- **SOA-Record** SOA steht für: Start of Authority Der SOA-Record enthält Verwaltungsinformationen einer DNS-Zone. Dazu gehören zum Beispiel: - primärer Nameserver - verantwortliche Kontaktadresse - Seriennummer - Aktualisierungszeiten - Ablaufzeiten Merksatz: SOA enthält Verwaltungsdaten einer DNS-Zone. --- **TTL** TTL steht bei DNS für: Time To Live Die TTL gibt an, wie lange ein DNS-Eintrag zwischengespeichert werden darf. Beispiel: TTL 3600 Bedeutung: Eintrag darf 3600 Sekunden, also eine Stunde, gecacht werden. Merksatz: DNS-TTL bestimmt, wie lange eine Antwort im Cache bleiben darf. --- **DNS-Cache** Ein DNS-Cache speichert Antworten vorübergehend. Caches gibt es zum Beispiel bei: - Betriebssystem - Browser - DNS-Resolver - Router - Provider - Anwendungen Vorteil: schnellere Antworten weniger Last auf DNS-Servern Nachteil: Änderungen werden nicht sofort überall sichtbar. Merksatz: DNS-Cache macht DNS schneller, kann Änderungen aber verzögern. --- **Warum DNS-Änderungen dauern können** DNS-Änderungen sind nicht immer sofort überall sichtbar. Grund: alte Antworten können noch in Caches liegen. Die Dauer hängt stark von der TTL ab. Beispiel: TTL 86400 bedeutet: Antwort darf bis zu 24 Stunden gecacht werden. Merksatz: DNS-Änderungen brauchen wegen Caching Zeit. --- **DNS und DHCP** Clients erhalten DNS-Server häufig per DHCP. DHCP kann dem Client mitteilen: - IP-Adresse - Subnetzmaske - Gateway - DNS-Server - Domain-Suffix Wenn der falsche DNS-Server per DHCP verteilt wird, funktioniert Namensauflösung möglicherweise falsch. Merksatz: DHCP verteilt oft die DNS-Serveradresse. --- **DNS-Suffix** Ein DNS-Suffix kann bei unvollständigen Namen ergänzt werden. Beispiel: eingegeben: server01 DNS-Suffix: firma.local Abfrage wird zu: server01.firma.local Typisch in Unternehmensnetzen. Merksatz: DNS-Suffix ergänzt kurze Namen. --- **FQDN** FQDN steht für: Fully Qualified Domain Name Ein FQDN ist ein vollständiger DNS-Name. Beispiel: server01.firma.local Er beschreibt den Namen eindeutig innerhalb der DNS-Hierarchie. Merksatz: FQDN = vollständiger DNS-Name. --- **Hostname und Domainname** Hostname: Name eines Geräts oder Dienstes Domainname: Namensbereich Beispiel: server01.firma.local Dabei ist: server01 = Hostname firma.local = Domain Merksatz: Hostname ist der einzelne Name, Domain ist der Namensbereich. --- **Split DNS** Split DNS bedeutet: Ein Name kann intern und extern unterschiedlich aufgelöst werden. Beispiel: wiki.firma.de intern: 192.168.10.50 extern: 93.184.100.10 Das ist häufig sinnvoll, wenn interne Clients interne Adressen verwenden sollen. Merksatz: Split DNS liefert je nach Standort unterschiedliche Antworten. --- **Interne und externe DNS-Zonen** Unternehmen nutzen oft interne und externe DNS-Zonen. Extern sichtbar: www.firma.de mail.firma.de Intern zusätzlich: server01.firma.local db01.intern.firma.de printer01.firma.local Wichtig: Interne Namen sollten nicht unkontrolliert öffentlich sichtbar sein. Merksatz: Interne DNS-Zonen dienen interner Namensauflösung. --- **DNS und Active Directory** In Windows-Domänen ist DNS besonders wichtig. Active Directory nutzt DNS für: - Domänencontroller finden - Dienste finden - LDAP finden - Kerberos finden - Anmeldung unterstützen Dafür werden unter anderem SRV-Records verwendet. Merksatz: Active Directory braucht funktionierendes DNS. --- **DNS und E-Mail** DNS ist für E-Mail sehr wichtig. Wichtige Records: | Record | Zweck | |---|---| | MX | zuständiger Mailserver | | A / AAAA | IP-Adresse des Mailservers | | PTR | Reverse-DNS für Mailserver | | TXT | SPF, DKIM, DMARC | Ohne korrekte DNS-Einträge kann E-Mail-Zustellung scheitern. Merksatz: Mailzustellung hängt stark von DNS ab. --- **SPF** SPF steht für: Sender Policy Framework SPF wird über TXT-Records im DNS veröffentlicht. SPF legt fest, welche Server für eine Domain E-Mails senden dürfen. Merksatz: SPF sagt, welche Server für eine Domain senden dürfen. --- **DKIM** DKIM steht für: DomainKeys Identified Mail DKIM nutzt digitale Signaturen, um E-Mails einer Domain zuzuordnen und Manipulationen erkennbar zu machen. Der öffentliche Schlüssel steht im DNS als TXT-Record. Merksatz: DKIM signiert E-Mails kryptografisch. --- **DMARC** DMARC steht für: Domain-based Message Authentication, Reporting and Conformance DMARC baut auf SPF und DKIM auf. Es legt fest, wie Empfänger mit verdächtigen E-Mails umgehen sollen. Beispiele: - nur berichten - in Quarantäne verschieben - ablehnen Merksatz: DMARC sagt, wie mit SPF-/DKIM-Fehlern umzugehen ist. --- **DNS und Webseiten** Für Webseiten sind häufig wichtig: A-Record AAAA-Record CNAME TXT für Domainprüfung Beispiel: www.firma.de → A-Record oder CNAME Wenn DNS auf die falsche IP zeigt, landet der Browser auf dem falschen Server. Merksatz: Falsches DNS kann falsche Webseite oder falsches Zertifikat bedeuten. --- **DNS und Zertifikate** TLS-Zertifikate müssen zum aufgerufenen Namen passen. Wenn DNS auf einen falschen Server zeigt, kann dieser ein falsches Zertifikat ausliefern. Beispiel: DNS für wiki.firma.de zeigt auf Server A. Server A liefert Zertifikat für cloud.firma.de. Folge: Browser zeigt Zertifikatswarnung. Merksatz: DNS und Zertifikate müssen zusammenpassen. --- **DNS und Reverse Proxy** Bei einem Reverse Proxy zeigen DNS-Einträge häufig auf den Proxy. Beispiel: wiki.firma.de cloud.firma.de git.firma.de zeigen alle auf: Reverse Proxy Der Proxy entscheidet anhand des Hostnamens, an welches interne Backend weitergeleitet wird. Merksatz: DNS zeigt oft zum Proxy, der Proxy leitet zum Backend. --- **DNS-Fehlersuche** Typische Fragen: Welcher DNS-Server wird verwendet? Wird der Name korrekt aufgelöst? Gibt es A- oder AAAA-Records? Gibt es einen falschen CNAME? Ist der Cache veraltet? Ist die TTL noch aktiv? Wird intern anders aufgelöst als extern? Stimmt der MX-Record? Stimmt der PTR-Record? Gibt es Tippfehler im Namen? Merksatz: DNS-Fehlersuche prüft Server, Record, Cache und Sichtweise. --- **Fehlerbild: IP funktioniert, Name nicht** Beispiel: ping 8.8.8.8 funktioniert. ping www.example.com funktioniert nicht. Dann ist IP-Kommunikation grundsätzlich möglich. Mögliche Ursachen: - DNS-Server falsch - DNS-Server nicht erreichbar - DNS-Dienst gestört - Firewall blockiert DNS - falscher Domainname - DNS-Cache fehlerhaft Merksatz: IP geht, Name nicht: DNS prüfen. --- **Fehlerbild: Name zeigt auf falsche IP** Mögliche Ursachen: - falscher A-Record - falscher AAAA-Record - falscher CNAME - alter Cache - falsche DNS-Zone - Split-DNS falsch - falscher DNS-Server wird gefragt Merksatz: Falsche IP bei DNS: Record und verwendeten DNS-Server prüfen. --- **Fehlerbild: Intern geht, extern nicht** Mögliche Ursachen: - interne DNS-Zone anders als externe - externer DNS-Eintrag fehlt - Firewall blockiert extern - NAT oder Portweiterleitung fehlt - Zertifikat gilt nur intern - öffentliche IP falsch - Split DNS falsch geplant Merksatz: Intern und extern getrennt prüfen. --- **Fehlerbild: Extern geht, intern nicht** Mögliche Ursachen: - interner DNS-Server liefert falsche Adresse - Hairpin NAT fehlt - Split DNS fehlt - interne Firewall blockiert - interner Proxy falsch - interne Zone überschreibt externe Zone Merksatz: Extern erreichbar heißt nicht automatisch intern erreichbar. --- **Fehlerbild: DNS-Änderung greift nicht** Mögliche Ursachen: - DNS-Cache noch aktiv - TTL noch nicht abgelaufen - falscher DNS-Server wird gefragt - Änderung in falscher Zone gemacht - autoritativer Nameserver nicht aktualisiert - Browser oder Betriebssystem cachet noch Merksatz: DNS-Änderungen brauchen Zeit wegen TTL und Cache. --- **Fehlerbild: Webseite zeigt falsches Zertifikat** Mögliche Ursachen: - DNS zeigt auf falsche IP - Reverse Proxy liefert falsches Zertifikat - Host-Header passt nicht - falscher virtueller Host - CNAME zeigt unerwartet weiter - interne und externe DNS-Antwort unterscheiden sich Merksatz: Falsches Zertifikat kann DNS- oder Proxy-Ursache haben. --- **DNS-Tools** Typische Werkzeuge zur DNS-Prüfung: | Werkzeug | Zweck | |---|---| | nslookup | DNS-Abfragen durchführen | | dig | detaillierte DNS-Abfragen | | host | einfache DNS-Abfrage | | ping | zeigt oft aufgelöste IP, prüft aber ICMP | | ipconfig /displaydns | DNS-Cache unter Windows anzeigen | | ipconfig /flushdns | DNS-Cache unter Windows leeren | | resolvectl | DNS-Informationen unter vielen Linux-Systemen | | scutil --dns | DNS-Informationen unter macOS | Merksatz: DNS prüft man mit DNS-Werkzeugen, nicht nur mit Ping. --- **Ping ist kein DNS-Test allein** Ping kann einen Namen auflösen, aber Ping prüft zusätzlich ICMP. Beispiel: ping www.example.com Dabei passieren zwei Dinge: 1. DNS-Auflösung 2. ICMP-Test Wenn Ping fehlschlägt, muss man unterscheiden: DNS-Auflösung fehlgeschlagen? Oder ICMP blockiert? Merksatz: Ping mit Name vermischt DNS und ICMP. --- **DNS und UDP/TCP 53** DNS nutzt häufig UDP 53. DNS kann aber auch TCP 53 verwenden. TCP 53 ist wichtig bei: - großen Antworten - Zonentransfers - bestimmten DNSSEC-Fällen Prüfungsfalle: DNS ist nicht nur UDP. Merksatz: DNS nutzt UDP 53 häufig, TCP 53 ebenfalls möglich. --- **Zonentransfer** Ein Zonentransfer überträgt DNS-Zonendaten zwischen DNS-Servern. Typisch: primärer DNS-Server → sekundärer DNS-Server Zonentransfers sollten nicht öffentlich für jeden erlaubt sein. Warum? Sonst könnten interne DNS-Strukturen sichtbar werden. Merksatz: Zonentransfer nur für berechtigte DNS-Server erlauben. --- **DNSSEC kurz erklärt** DNSSEC steht für: Domain Name System Security Extensions DNSSEC schützt DNS-Antworten durch digitale Signaturen. Ziel: Manipulation von DNS-Antworten erkennbar machen. Wichtig: DNSSEC verschlüsselt DNS-Anfragen nicht automatisch. Es schützt vor allem die Integrität und Authentizität der DNS-Daten. Merksatz: DNSSEC signiert DNS-Daten, verschlüsselt sie aber nicht. --- **DNS over HTTPS und DNS over TLS** Es gibt auch verschlüsselte DNS-Varianten. Beispiele: DoH = DNS over HTTPS DoT = DNS over TLS Ziel: DNS-Anfragen besser vor Mitlesen oder Manipulation auf dem Transportweg schützen. Wichtig: In Unternehmensnetzen kann das Auswirkungen auf Filterung und Monitoring haben. Merksatz: DoH und DoT verschlüsseln DNS-Transport. --- **Was DNS nicht macht** DNS macht nicht: - Webseiten ausliefern - TCP-Verbindungen aufbauen - IP-Pakete routen - Zertifikate ausstellen - Dienste automatisch starten - Firewall-Regeln setzen - Benutzer authentifizieren DNS liefert Namen und zugehörige Informationen. Merksatz: DNS sagt, wohin ein Name zeigt, nicht ob der Dienst funktioniert. --- **Einordnung in das OSI-Modell** | Thema | Schicht | |---|---:| | DNS-Protokoll | 7 | | DNS-Record | 7 | | A / AAAA / MX / TXT | 7 | | UDP 53 / TCP 53 | 4 | | IP-Adresse | 3 | | Reverse Lookup | 7 | | DNSSEC | 7 mit Sicherheitsbezug | | DoH / DoT | 7 über TLS/HTTPS | | DHCP verteilt DNS-Server | 7 mit Schicht-3-Bezug | Merksatz: DNS gehört zu Schicht 7, nutzt aber Schicht 4 und Schicht 3 darunter. --- **Typische IHK-Fragen** In AP1 und AP2 kann zum Beispiel gefragt werden: - Was macht DNS? - Wofür steht DNS? - Warum braucht man DNS? - Was ist ein DNS-Resolver? - Was ist ein authoritative DNS-Server? - Was ist eine DNS-Zone? - Was ist der Unterschied zwischen Forward und Reverse Lookup? - Was ist ein A-Record? - Was ist ein AAAA-Record? - Was ist ein CNAME? - Was ist ein MX-Record? - Was ist ein TXT-Record? - Was ist ein PTR-Record? - Was bedeutet TTL? - Warum dauern DNS-Änderungen manchmal? - Warum funktioniert IP, aber Name nicht? - Warum kann falsches DNS ein Zertifikatsproblem verursachen? - Warum nutzt DNS UDP und TCP 53? --- **Typische Prüfungsfallen** DNS gehört zu Schicht 7. DNS-Port 53 gehört zu Schicht 4. DNS löst Namen in IP-Adressen auf. A-Record = IPv4. AAAA-Record = IPv6. CNAME = Alias auf anderen Namen. MX = Mailserver. TXT = Textinformationen. PTR = Reverse Lookup. NS = zuständiger Nameserver. TTL steuert DNS-Caching. DNS-Änderungen können wegen Cache dauern. IP geht, Name nicht: DNS prüfen. Ping mit Name ist nicht nur DNS-Test, sondern auch ICMP-Test. DNS ist nicht nur UDP, sondern kann auch TCP 53 nutzen. DNSSEC verschlüsselt DNS nicht automatisch. DNS sagt nicht, ob der Dienst läuft. --- **Wichtige Begriffe kurz erklärt** | Begriff | Kurze Erklärung | |---|---| | DNS | Domain Name System | | Namensauflösung | Name wird zu IP-Adresse aufgelöst | | Resolver | DNS-Server, der Antworten für Clients sucht | | authoritative DNS | zuständiger DNS-Server einer Zone | | DNS-Zone | verwalteter Namensbereich | | Record | DNS-Eintrag | | A | Name zu IPv4 | | AAAA | Name zu IPv6 | | CNAME | Alias auf anderen Namen | | MX | Mailserver | | NS | Nameserver | | TXT | Textinformation | | PTR | Reverse-DNS-Eintrag | | SRV | Dienststandort | | SOA | Verwaltungsdaten einer Zone | | TTL | Cache-Lebensdauer | | FQDN | vollständiger DNS-Name | | Split DNS | unterschiedliche interne und externe Antworten | | Reverse Lookup | IP-Adresse zu Name | | DNSSEC | signierte DNS-Daten | | DoH | DNS über HTTPS | | DoT | DNS über TLS | --- **IHK-sichere Kurzformulierung** DNS steht für Domain Name System und gehört zur Anwendungsschicht des OSI-Modells. DNS löst Namen in IP-Adressen auf, damit Anwendungen mit verständlichen Namen arbeiten können. Ein Client fragt einen DNS-Resolver, der die passende Antwort liefert oder weitere DNS-Server abfragt. DNS ist hierarchisch aufgebaut und arbeitet mit Records wie A für IPv4, AAAA für IPv6, CNAME für Aliase, MX für Mailserver, NS für Nameserver, TXT für Textinformationen und PTR für Reverse Lookup. DNS nutzt typischerweise UDP-Port 53, kann aber auch TCP-Port 53 verwenden. DNS-Caching wird durch die TTL gesteuert. --- **Merksätze** DNS = Domain Name System. DNS gehört zu Schicht 7. DNS löst Namen in IP-Adressen auf. Name zu IP = Forward Lookup. IP zu Name = Reverse Lookup. Resolver sucht Antwort für Client. Authoritative DNS liefert verbindliche Antwort. DNS-Zone = verwalteter Namensbereich. A = IPv4. AAAA = IPv6. CNAME = Alias. MX = Mailserver. NS = Nameserver. TXT = Textinformation. PTR = Reverse Lookup. SRV = Dienststandort. SOA = Zonendaten. TTL = Cache-Zeit. DNS-Cache beschleunigt, verzögert aber Änderungen. FQDN = vollständiger DNS-Name. Split DNS = intern und extern unterschiedliche Antworten. DNS-Port = UDP/TCP 53. DNS ist nicht nur UDP. IP geht, Name nicht: DNS prüfen. Ping mit Name vermischt DNS und ICMP. DNSSEC signiert, verschlüsselt aber nicht automatisch. DoH und DoT verschlüsseln DNS-Transport. DNS sagt, wohin ein Name zeigt, nicht ob der Dienst funktioniert. # 10.4 DHCP und automatische IP-Konfiguration* DHCP gehört zur OSI-Schicht 7. DHCP steht für: Dynamic Host Configuration Protocol Die Hauptaufgabe von DHCP ist: Netzwerkkonfiguration automatisch an Clients verteilen. Ein Client kann per DHCP zum Beispiel erhalten: - IP-Adresse - Subnetzmaske - Standard-Gateway - DNS-Server - Domain-Suffix - Lease-Zeit - weitere DHCP-Optionen Merksatz: DHCP = automatische IP-Konfiguration. --- **Warum braucht man DHCP?** Ohne DHCP müsste jedes Gerät manuell konfiguriert werden. Das wäre aufwendig und fehleranfällig. Man müsste manuell eintragen: - IP-Adresse - Subnetzmaske - Gateway - DNS-Server - weitere Einstellungen DHCP automatisiert diese Vergabe. Vorteile: - weniger manuelle Arbeit - weniger Tippfehler - zentrale Verwaltung - flexible Adressvergabe - einfache Änderung von DNS oder Gateway - bessere Übersicht über vergebene Adressen Merksatz: DHCP verhindert viele manuelle IP-Konfigurationsfehler. --- **DHCP im OSI-Modell** DHCP ist ein Anwendungsschicht-Protokoll. Es gehört zu: OSI-Schicht 7 Aber DHCP verteilt Informationen, die für Schicht 3 wichtig sind. Beispiel: IP-Adresse Subnetzmaske Gateway Wichtig: DHCP-Protokoll = Schicht 7 IP-Adresse und Gateway = Schicht 3 Merksatz: DHCP ist Schicht 7, liefert aber Schicht-3-Konfiguration. --- **DHCP und Ports** DHCP nutzt UDP. Wichtige Ports: | Rolle | Protokoll | Port | |---|---|---:| | DHCP-Server | UDP | 67 | | DHCP-Client | UDP | 68 | Warum UDP? Ein Client hat am Anfang oft noch keine vollständige IP-Konfiguration. DHCP muss bereits funktionieren, bevor der Client normal im IP-Netz arbeiten kann. Merksatz: DHCP nutzt UDP 67 und UDP 68. --- **DHCP-Client** Ein DHCP-Client ist ein Gerät, das automatisch eine Netzwerkkonfiguration anfordert. Beispiele: - PC - Notebook - Smartphone - Drucker - IP-Telefon - Server - virtuelle Maschine - IoT-Gerät Der Client fragt: Gibt es einen DHCP-Server, der mir eine IP-Konfiguration geben kann? Merksatz: DHCP-Client fordert IP-Konfiguration an. --- **DHCP-Server** Ein DHCP-Server vergibt IP-Konfigurationen an Clients. Er verwaltet unter anderem: - Adressbereiche - Leases - Reservierungen - DHCP-Optionen - verfügbare und vergebene IP-Adressen Beispiele für DHCP-Server: - Router - Windows Server - Linux-Server - Firewall - Netzwerk-Appliance Merksatz: DHCP-Server verteilt Netzwerkkonfiguration. --- **DHCP-Bereich** Ein DHCP-Bereich wird auch genannt: DHCP-Scope Er beschreibt, welche IP-Adressen ein DHCP-Server vergeben darf. Beispiel: Netz: 192.168.10.0/24 DHCP-Bereich: 192.168.10.100 bis 192.168.10.200 Der DHCP-Server vergibt dann Adressen aus diesem Bereich. Merksatz: DHCP-Scope = Adressbereich für automatische Vergabe. --- **DHCP-Lease** Eine per DHCP vergebene Adresse wird nicht dauerhaft vergeben, sondern für eine bestimmte Zeit. Diese Zeit heißt: Lease-Zeit Beispiel: Client erhält 192.168.10.120 für 8 Stunden. Nach Ablauf muss der Client die Adresse erneuern oder eine neue Konfiguration erhalten. Merksatz: Lease = zeitlich begrenzte Adresszuweisung. --- **Warum gibt es Leases?** Leases sorgen dafür, dass IP-Adressen wieder frei werden können. Beispiel: Ein Notebook war im WLAN. Es verlässt das Netzwerk. Nach Ablauf der Lease kann die Adresse wieder vergeben werden. Das ist besonders nützlich bei: - WLANs - Gastnetzen - Schulen - Unternehmen - wechselnden Geräten - mobilen Clients Merksatz: Lease-Zeit verhindert dauerhaft blockierte IP-Adressen. --- **DHCP-Ablauf: DORA** Der klassische DHCP-Ablauf wird oft mit DORA beschrieben. DORA steht für: Discover Offer Request Acknowledge Die vier Schritte: | Schritt | Richtung | Bedeutung | |---:|---|---| | 1 | Client → Netzwerk | Discover | | 2 | Server → Client | Offer | | 3 | Client → Server | Request | | 4 | Server → Client | Acknowledge | Merksatz: DHCP-Ablauf = DORA. --- **DHCP Discover** Beim DHCP Discover sucht der Client nach einem DHCP-Server. Der Client hat zu diesem Zeitpunkt oft noch keine gültige IP-Adresse. Deshalb wird die Anfrage als Broadcast gesendet. Vereinfacht sagt der Client: Gibt es hier einen DHCP-Server? Merksatz: Discover = Client sucht DHCP-Server. --- **DHCP Offer** Beim DHCP Offer bietet der DHCP-Server dem Client eine Konfiguration an. Das Angebot enthält zum Beispiel: - IP-Adresse - Subnetzmaske - Gateway - DNS-Server - Lease-Zeit Vereinfacht sagt der Server: Du kannst diese Adresse verwenden. Merksatz: Offer = Server bietet Konfiguration an. --- **DHCP Request** Beim DHCP Request nimmt der Client ein Angebot an. Vereinfacht sagt der Client: Ich möchte diese angebotene IP-Adresse verwenden. Wenn mehrere DHCP-Server geantwortet haben, wählt der Client normalerweise ein Angebot aus. Merksatz: Request = Client fordert angebotene Adresse an. --- **DHCP Acknowledge** Beim DHCP Acknowledge bestätigt der Server die Vergabe. Vereinfacht sagt der Server: Die Adresse ist für dich reserviert. Danach kann der Client die erhaltene IP-Konfiguration verwenden. Merksatz: Acknowledge = Server bestätigt die Vergabe. --- **DORA als Ablaufbild** Der Ablauf vereinfacht: Client → Broadcast: DHCP Discover Server → Client: DHCP Offer Client → Server: DHCP Request Server → Client: DHCP Acknowledge Merksatz: Discover, Offer, Request, Acknowledge. --- **Broadcast bei DHCP** DHCP nutzt am Anfang Broadcast, weil der Client noch nicht weiß: welche IP-Adresse er selbst hat welche IP-Adresse der DHCP-Server hat welches Gateway zuständig ist Broadcast bedeutet: Nachricht an alle Geräte im lokalen Netz. Wichtig: Router leiten Broadcasts normalerweise nicht einfach in andere Netze weiter. Merksatz: DHCP startet häufig mit Broadcast im lokalen Netz. --- **DHCP und VLANs** In der Praxis gibt es häufig pro VLAN ein eigenes IP-Subnetz. Beispiel: | VLAN | Subnetz | DHCP-Bereich | |---:|---|---| | VLAN 10 | 192.168.10.0/24 | 192.168.10.100–200 | | VLAN 20 | 192.168.20.0/24 | 192.168.20.100–200 | | VLAN 30 | 192.168.30.0/24 | 192.168.30.100–200 | Ein Client im VLAN 20 soll eine Adresse aus dem VLAN-20-Bereich bekommen. Merksatz: Jedes VLAN braucht passende DHCP-Konfiguration. --- **DHCP-Relay** Ein DHCP-Relay wird benötigt, wenn DHCP-Client und DHCP-Server in unterschiedlichen Netzen liegen. Problem: DHCP Discover ist Broadcast. Router leiten Broadcasts normalerweise nicht weiter. Lösung: DHCP-Relay nimmt die Anfrage entgegen und leitet sie gezielt an den DHCP-Server weiter. Bei Cisco wird dafür oft der Begriff verwendet: IP Helper Address Merksatz: DHCP-Relay bringt DHCP-Anfragen über Router-Grenzen. --- **Beispiel DHCP-Relay** Situation: Client im VLAN 20 DHCP-Server im Servernetz VLAN 100 Ohne DHCP-Relay: DHCP Discover bleibt im VLAN 20. DHCP-Server sieht die Anfrage nicht. Mit DHCP-Relay: Router oder Layer-3-Switch leitet die Anfrage an den DHCP-Server weiter. Merksatz: DHCP-Server muss nicht in jedem VLAN stehen, wenn DHCP-Relay korrekt eingerichtet ist. --- **DHCP-Optionen** DHCP kann neben der IP-Adresse weitere Informationen liefern. Wichtige Optionen: | Option | Bedeutung | |---|---| | Subnetzmaske | Netzgröße | | Router / Gateway | Standard-Gateway | | DNS-Server | Server für Namensauflösung | | Domainname | DNS-Suffix | | NTP-Server | Zeitserver | | Lease-Zeit | Gültigkeitsdauer | | PXE-Boot-Optionen | Netzwerkstart | Merksatz: DHCP liefert mehr als nur IP-Adressen. --- **Standard-Gateway per DHCP** DHCP kann das Standard-Gateway an den Client verteilen. Das Gateway wird benötigt, wenn der Client andere Netze erreichen soll. Beispiel: Client: 192.168.10.120/24 Gateway: 192.168.10.1 Wichtig: Das Gateway muss zum Subnetz des Clients passen. Merksatz: Falsches Gateway per DHCP erzeugt Routing-Probleme. --- **DNS-Server per DHCP** DHCP verteilt oft auch DNS-Server. Beispiel: DNS-Server: 192.168.10.10 Wenn hier ein falscher DNS-Server eingetragen ist, funktioniert IP-Kommunikation möglicherweise, aber Namensauflösung nicht. Fehlerbild: ping 8.8.8.8 funktioniert ping www.example.com funktioniert nicht Merksatz: Falscher DNS per DHCP verursacht Namensprobleme. --- **DHCP-Reservierung** Eine DHCP-Reservierung ordnet einem bestimmten Gerät immer dieselbe IP-Adresse zu. Typische Grundlage: MAC-Adresse des Clients Beispiel: Drucker-MAC: AA:BB:CC:11:22:33 reservierte IP: 192.168.10.50 Der Drucker bekommt dann per DHCP immer dieselbe Adresse. Merksatz: DHCP-Reservierung = gleiche IP für bestimmtes Gerät. --- **Reservierung und statische IP unterscheiden** | Variante | Bedeutung | |---|---| | statische IP | direkt am Gerät manuell eingetragen | | DHCP-Reservierung | zentral am DHCP-Server festgelegt | Vorteil der Reservierung: zentrale Verwaltung weniger Fehler am Gerät DNS und Optionen bleiben konsistent Typisch für: - Drucker - Server - Netzwerkgeräte - Kameras - Spezialgeräte Merksatz: Reservierung ist zentraler als manuelle statische IP. --- **Ausschlussbereich** Ein Ausschlussbereich enthält IP-Adressen, die der DHCP-Server nicht automatisch vergeben soll. Beispiel: Netz: 192.168.10.0/24 DHCP-Bereich: 192.168.10.10 bis 192.168.10.250 ausgeschlossen: 192.168.10.1 bis 192.168.10.20 Warum? Diese Adressen sind vielleicht für Gateway, Server oder Drucker reserviert. Merksatz: Ausschlussbereiche verhindern doppelte Vergabe wichtiger Adressen. --- **Adresskonflikt** Ein Adresskonflikt entsteht, wenn zwei Geräte dieselbe IP-Adresse verwenden. Mögliche Ursachen: - statische IP liegt im DHCP-Bereich - DHCP-Reservierung doppelt - zwei DHCP-Server vergeben gleiche Bereiche - manuelle Fehlkonfiguration - Gerät verwendet alte Adresse weiter Folgen: - instabile Verbindung - wechselnde Erreichbarkeit - ARP-Probleme - Verbindungsabbrüche Merksatz: Doppelte IP-Adressen verursachen instabile Netzprobleme. --- **DHCP und APIPA** Wenn ein Windows-Client keine DHCP-Adresse erhält, kann er sich selbst eine APIPA-Adresse geben. APIPA-Bereich: 169.254.0.0/16 Beispiel: 169.254.23.80 Das bedeutet häufig: DHCP-Server nicht erreichbar oder DHCP-Vergabe fehlgeschlagen Merksatz: 169.254.x.x weist oft auf DHCP-Probleme hin. --- **DHCP und DNS-Dynamik** In manchen Netzwerken werden DNS-Einträge automatisch mit DHCP aktualisiert. Beispiel: Client erhält per DHCP: 192.168.10.120 DNS wird aktualisiert: client01.firma.local → 192.168.10.120 Das ist besonders in Windows- und Active-Directory-Umgebungen verbreitet. Merksatz: DHCP kann mit DNS zusammenarbeiten. --- **DHCP und Active Directory** In Windows-Umgebungen ist DHCP oft eng mit DNS und Active Directory verbunden. Wichtig: Clients brauchen richtigen DNS-Server, um Domänencontroller zu finden. Wenn per DHCP ein externer DNS-Server verteilt wird, kann die Domänenanmeldung fehlschlagen. Merksatz: In AD-Netzen muss DHCP den internen DNS-Server verteilen. --- **DHCP-Snooping** DHCP-Snooping ist eine Sicherheitsfunktion auf Switches. Ziel: Schutz vor unerlaubten DHCP-Servern. Der Switch unterscheidet: vertrauenswürdige Ports nicht vertrauenswürdige Ports DHCP-Antworten dürfen nur von vertrauenswürdigen Ports kommen. Merksatz: DHCP-Snooping schützt vor Rogue-DHCP-Servern. --- **Rogue-DHCP-Server** Ein Rogue-DHCP-Server ist ein unerlaubter DHCP-Server im Netzwerk. Er kann falsche Informationen verteilen: - falsches Gateway - falscher DNS-Server - falsche IP-Adressen - falsches Subnetz Folgen: - Clients verlieren Netzwerkzugriff - Datenverkehr wird umgeleitet - Namensauflösung wird manipuliert - Sicherheitsrisiko Merksatz: Unerlaubter DHCP-Server kann ein ganzes Netz stören. --- **DHCP-Starvation** DHCP-Starvation ist ein Angriff, bei dem sehr viele DHCP-Anfragen gestellt werden. Ziel: DHCP-Adressbereich erschöpfen. Folge: echte Clients bekommen keine IP-Adresse mehr. Schutzmaßnahmen: - Port Security - DHCP-Snooping - Netzwerkzugangskontrolle - Monitoring - ausreichend Segmentierung Merksatz: DHCP-Starvation leert den DHCP-Adresspool. --- **DHCP und IPv6** Bei IPv6 gibt es mehrere Möglichkeiten zur Adresskonfiguration. Wichtige Begriffe: - SLAAC - DHCPv6 - Router Advertisements SLAAC bedeutet: Client bildet IPv6-Adresse selbst anhand von Router Advertisements. DHCPv6 kann zusätzliche Informationen liefern, zum Beispiel DNS-Server. Merksatz: IPv6 nutzt nicht einfach DHCPv4, sondern SLAAC, RA und DHCPv6. --- **DHCPv4 und DHCPv6 unterscheiden** | Thema | DHCPv4 | DHCPv6 | |---|---|---| | Protokollfamilie | IPv4 | IPv6 | | Adressvergabe | häufig zentral per DHCP | möglich, aber auch SLAAC | | Broadcast | ja | nein, IPv6 nutzt Multicast | | Gateway-Verteilung | per DHCP möglich | meist über Router Advertisements | | DNS-Verteilung | per DHCP | per DHCPv6 oder RA-Optionen | Merksatz: DHCPv6 funktioniert anders als DHCPv4. --- **DHCP-Fehlersuche** Typische Fragen: Hat der Client überhaupt Link? Ist der Client im richtigen VLAN? Gibt es einen DHCP-Server? Ist der DHCP-Bereich aktiv? Sind noch freie Adressen vorhanden? Funktioniert DHCP-Relay? Werden UDP 67 und 68 blockiert? Gibt es einen Rogue-DHCP-Server? Ist die erhaltene IP im richtigen Subnetz? Stimmen Gateway und DNS? Merksatz: DHCP-Fehlersuche beginnt bei Link, VLAN und DHCP-Server. --- **Fehlerbild: Client bekommt keine IP-Adresse** Mögliche Ursachen: - kein Link - falsches VLAN - DHCP-Server nicht erreichbar - DHCP-Dienst gestoppt - DHCP-Bereich erschöpft - DHCP-Relay fehlt - Firewall blockiert UDP 67/68 - Rogue-DHCP oder Schutzfunktion stört - Netzwerkkarte deaktiviert - Clientproblem Merksatz: Keine IP-Adresse: Link, VLAN, DHCP und Relay prüfen. --- **Fehlerbild: Client bekommt falsche IP-Adresse** Mögliche Ursachen: - Client ist im falschen VLAN - falscher DHCP-Bereich aktiv - Rogue-DHCP-Server - falsche SSID-VLAN-Zuordnung - falscher Switch-Port - fehlerhafte Reservierung - falscher DHCP-Relay-Kontext Merksatz: Falsche DHCP-Adresse deutet oft auf falsches VLAN oder Rogue-DHCP hin. --- **Fehlerbild: Client bekommt IP, aber kein Internet** Mögliche Ursachen: - falsches Gateway per DHCP - Gateway nicht erreichbar - DNS falsch - Routing fehlt - NAT fehlt - Firewall blockiert - falsche Subnetzmaske - Client im falschen VLAN Merksatz: DHCP-Erfolg heißt nicht automatisch: Internet funktioniert. --- **Fehlerbild: IP funktioniert, Name nicht** Mögliche Ursachen: - falscher DNS-Server per DHCP verteilt - DNS-Server nicht erreichbar - DNS-Dienst gestört - falsches DNS-Suffix - Firewall blockiert DNS - externer DNS statt interner DNS Merksatz: DHCP kann DNS-Probleme verursachen, wenn falsche DNS-Optionen verteilt werden. --- **Fehlerbild: Manche Clients bekommen IP, andere nicht** Mögliche Ursachen: - DHCP-Pool fast erschöpft - bestimmte Switch-Ports in falschem VLAN - WLAN-SSID falsch zugeordnet - DHCP-Snooping blockiert bestimmte Ports - MAC-Filter - Reservierungen fehlerhaft - Relay nur für manche VLANs eingerichtet Merksatz: Teilweise DHCP-Probleme nach Standort, VLAN und Port eingrenzen. --- **Fehlerbild: Nach Umzug in anderes VLAN keine IP** Mögliche Ursachen: - DHCP-Bereich für neues VLAN fehlt - DHCP-Relay im neuen VLAN fehlt - VLAN nicht auf Trunk erlaubt - Access-Port falsch - Firewall blockiert DHCP-Relay - Gateway-Schnittstelle im VLAN fehlt Merksatz: Neues VLAN braucht passenden DHCP-Bereich und Relay. --- **DHCP-Tools** Typische Werkzeuge und Prüfungen: | Werkzeug / Prüfung | Nutzen | |---|---| | IP-Konfiguration anzeigen | erhaltene Adresse prüfen | | Lease erneuern | neue DHCP-Anfrage auslösen | | DHCP-Server-Konsole | Bereich, Leases, Reservierungen prüfen | | DHCP-Logs | Vergaben und Fehler prüfen | | Switch-Port prüfen | VLAN und Link kontrollieren | | Packet Capture | DORA-Ablauf sichtbar machen | | Firewall-Logs | UDP 67/68 prüfen | | ARP-Tabelle | Adresskonflikte erkennen | Merksatz: DHCP prüft man am Client, am Server und am Netzwerk dazwischen. --- **DHCP-Ablauf im Mitschnitt** In einem Paketmitschnitt erkennt man den DHCP-Ablauf: Discover Offer Request Acknowledge Typische Fragen: Sendet der Client Discover? Kommt ein Offer zurück? Sendet der Client Request? Kommt ein Acknowledge? Welche IP wird angeboten? Welcher Server antwortet? Merksatz: Im Mitschnitt sieht man, an welchem DORA-Schritt es scheitert. --- **DHCP und Firewall** DHCP kann durch Firewall-Regeln gestört werden. Besonders relevant: UDP 67 UDP 68 Bei DHCP-Relay kann auch Verkehr zwischen Relay und DHCP-Server betroffen sein. Wichtig: DHCP im gleichen LAN nutzt Broadcast. DHCP über Relay muss gezielt erlaubt sein. Merksatz: Firewall kann DHCP verhindern, wenn UDP 67/68 blockiert wird. --- **DHCP und Dokumentation** DHCP sollte sauber dokumentiert werden. Wichtige Angaben: - Subnetz - VLAN - DHCP-Bereich - Ausschlüsse - Reservierungen - Gateway - DNS-Server - Lease-Zeit - DHCP-Relay-Adresse - zuständiger Server Merksatz: Gute DHCP-Dokumentation verhindert Fehlvergaben. --- **Was DHCP nicht macht** DHCP macht nicht: - Kabelverbindung herstellen - VLAN automatisch richtig setzen - Routing garantieren - NAT einrichten - DNS-Namen zwingend korrekt auflösen - Dienste starten - Benutzer authentifizieren - Firewall-Regeln ersetzen DHCP liefert Konfigurationsdaten, aber andere Netzfunktionen müssen trotzdem korrekt eingerichtet sein. Merksatz: DHCP vergibt Konfiguration, garantiert aber keine vollständige Erreichbarkeit. --- **Einordnung in das OSI-Modell** | Thema | Schicht | |---|---:| | DHCP-Protokoll | 7 | | DHCP-Optionen | 7 mit Schicht-3-Bezug | | UDP 67 / 68 | 4 | | IP-Adresse | 3 | | Subnetzmaske | 3 | | Standard-Gateway | 3 | | DNS-Server-Adresse | 3 / 7-Bezug | | VLAN | 2 | | Broadcast | 2 / 3-Bezug | | DHCP-Relay | 3 / 7-Bezug | | DHCP-Snooping | 2-Sicherheitsfunktion | Merksatz: DHCP gehört zu Schicht 7, wirkt aber stark auf Schicht 3. --- **Typische IHK-Fragen** In AP1 und AP2 kann zum Beispiel gefragt werden: - Wofür steht DHCP? - Welche Aufgabe hat DHCP? - Warum ist DHCP sinnvoll? - Welche Informationen kann DHCP verteilen? - Welche Ports nutzt DHCP? - Welches Transportprotokoll nutzt DHCP? - Was bedeutet DORA? - Was passiert bei DHCP Discover? - Was passiert bei DHCP Offer? - Was passiert bei DHCP Request? - Was passiert bei DHCP Acknowledge? - Was ist ein DHCP-Scope? - Was ist eine Lease? - Was ist eine DHCP-Reservierung? - Was ist ein DHCP-Relay? - Warum braucht man DHCP-Relay bei mehreren VLANs? - Was bedeutet APIPA? - Was ist ein Rogue-DHCP-Server? - Warum kann ein Client eine falsche IP-Adresse bekommen? --- **Typische Prüfungsfallen** DHCP gehört zu Schicht 7. DHCP nutzt UDP. DHCP-Server nutzt UDP 67. DHCP-Client nutzt UDP 68. DHCP vergibt nicht nur IP-Adressen. DHCP kann auch Gateway und DNS verteilen. DHCP-Ablauf = DORA. Discover sucht DHCP-Server. Offer bietet Konfiguration an. Request fordert Angebot an. Acknowledge bestätigt Vergabe. DHCP startet häufig mit Broadcast. Router leiten Broadcasts normalerweise nicht einfach weiter. DHCP-Relay ist für DHCP über Netzgrenzen nötig. Falsches VLAN führt oft zu falscher DHCP-Adresse. APIPA 169.254.x.x deutet oft auf DHCP-Problem hin. DHCP-Erfolg heißt nicht automatisch, dass DNS oder Internet funktionieren. Rogue-DHCP kann falsche Konfiguration verteilen. DHCPv6 funktioniert anders als DHCPv4. --- **Wichtige Begriffe kurz erklärt** | Begriff | Kurze Erklärung | |---|---| | DHCP | Dynamic Host Configuration Protocol | | DHCP-Client | Gerät, das Konfiguration anfordert | | DHCP-Server | Server, der Konfiguration vergibt | | DHCP-Scope | Adressbereich für DHCP | | Lease | zeitlich begrenzte Adressvergabe | | DORA | Discover, Offer, Request, Acknowledge | | Discover | Client sucht DHCP-Server | | Offer | Server bietet Konfiguration an | | Request | Client fordert Angebot an | | Acknowledge | Server bestätigt Vergabe | | DHCP-Option | zusätzliche Konfigurationsinformation | | DHCP-Relay | Weiterleitung von DHCP-Anfragen in andere Netze | | IP Helper | Begriff für DHCP-Relay bei manchen Herstellern | | Reservierung | feste IP-Zuordnung über DHCP | | Ausschlussbereich | Adressen, die nicht automatisch vergeben werden | | APIPA | automatische 169.254.x.x-Adresse bei DHCP-Problem | | Rogue-DHCP | unerlaubter DHCP-Server | | DHCP-Snooping | Schutzfunktion gegen Rogue-DHCP | | DHCP-Starvation | Angriff auf DHCP-Adresspool | | DHCPv6 | DHCP für IPv6 | --- **IHK-sichere Kurzformulierung** DHCP steht für Dynamic Host Configuration Protocol und gehört zur Anwendungsschicht des OSI-Modells. Es dient dazu, Clients automatisch mit Netzwerkkonfigurationen zu versorgen. Dazu gehören IP-Adresse, Subnetzmaske, Standard-Gateway, DNS-Server und weitere Optionen. DHCP nutzt UDP, der Server verwendet Port 67 und der Client Port 68. Der klassische DHCP-Ablauf wird mit DORA beschrieben: Discover, Offer, Request und Acknowledge. Befindet sich der DHCP-Server in einem anderen Netz als der Client, wird ein DHCP-Relay benötigt, weil DHCP-Anfragen anfangs häufig als Broadcast gesendet werden und Router Broadcasts nicht einfach weiterleiten. --- **Merksätze** DHCP = Dynamic Host Configuration Protocol. DHCP gehört zu Schicht 7. DHCP vergibt automatische Netzwerkkonfiguration. DHCP liefert IP-Adresse, Subnetzmaske, Gateway und DNS-Server. DHCP nutzt UDP. DHCP-Server = UDP 67. DHCP-Client = UDP 68. DHCP-Ablauf = DORA. Discover = Client sucht Server. Offer = Server bietet Konfiguration an. Request = Client fordert Angebot an. Acknowledge = Server bestätigt. DHCP startet häufig mit Broadcast. Router leiten Broadcasts normalerweise nicht weiter. DHCP-Relay leitet DHCP über Netzgrenzen. DHCP-Scope = Adressbereich. Lease = zeitlich begrenzte Vergabe. Reservierung = feste IP per DHCP. Ausschlussbereich = nicht automatisch vergeben. 169.254.x.x = häufig DHCP-Problem. Falsches VLAN kann falsche DHCP-Adresse verursachen. Rogue-DHCP = unerlaubter DHCP-Server. DHCP-Snooping schützt vor Rogue-DHCP. DHCPv6 ist nicht einfach DHCPv4 mit IPv6. DHCP-Erfolg bedeutet nicht automatisch: Internet funktioniert. # 10.5 E-Mail-Protokolle: SMTP, POP3 und IMAP E-Mail-Kommunikation gehört zur OSI-Schicht 7. Dabei arbeiten mehrere Protokolle zusammen. Die wichtigsten E-Mail-Protokolle sind: - SMTP - POP3 - IMAP Sie haben unterschiedliche Aufgaben. SMTP wird verwendet für: E-Mails senden und transportieren. POP3 und IMAP werden verwendet für: E-Mails abrufen. Merksatz: SMTP sendet. POP3 und IMAP empfangen. --- **Grundidee von E-Mail-Kommunikation** E-Mail ist kein einzelner einfacher Vorgang. Beim Senden und Empfangen arbeiten mehrere Bestandteile zusammen: - E-Mail-Client - Mailserver - DNS - SMTP - POP3 oder IMAP - Authentifizierung - TLS - Spam- und Sicherheitsprüfungen Beispiel: Benutzer schreibt E-Mail im Mailprogramm. Mailprogramm sendet E-Mail an Mailserver. Mailserver transportiert E-Mail weiter. Empfänger ruft E-Mail vom eigenen Mailserver ab. Merksatz: E-Mail nutzt mehrere Protokolle und Dienste zusammen. --- **E-Mail im OSI-Modell** E-Mail-Protokolle gehören zur Anwendungsschicht. | Thema | Schicht | |---|---:| | SMTP | 7 | | POP3 | 7 | | IMAP | 7 | | DNS MX-Record | 7 | | TLS | 6 mit Schicht-7-Bezug | | TCP-Port | 4 | | IP-Adresse | 3 | Wichtig: Die Protokolle SMTP, POP3 und IMAP gehören zu Schicht 7. Die zugehörigen Ports gehören zu Schicht 4. Merksatz: Mailprotokoll = Schicht 7. Mailport = Schicht 4. --- **SMTP** SMTP steht für: Simple Mail Transfer Protocol SMTP wird verwendet für: - E-Mails senden - E-Mails zwischen Mailservern transportieren - E-Mails an den nächsten Mailserver weitergeben Typischer Port: TCP 25 Weitere häufige Ports: TCP 587 TCP 465 Merksatz: SMTP = E-Mail senden und weiterleiten. --- **SMTP zwischen Mailservern** Wenn ein Mailserver eine E-Mail an eine andere Domain zustellen möchte, nutzt er SMTP. Beispiel: absender@firma-a.de sendet an empfaenger@firma-b.de Der Mailserver von firma-a.de fragt per DNS, welcher Mailserver für firma-b.de zuständig ist. Danach wird die E-Mail per SMTP an diesen Mailserver übertragen. Merksatz: Mailserver transportieren E-Mails untereinander mit SMTP. --- **SMTP Submission** SMTP Submission bedeutet: Ein Mailclient übergibt eine ausgehende E-Mail an den eigenen Mailserver. Typischer Port: TCP 587 Dabei wird normalerweise Authentifizierung verwendet. Beispiel: Mailprogramm meldet sich am Mailserver an und sendet die E-Mail über Port 587. Merksatz: Port 587 ist typisch für authentifiziertes Senden durch Clients. --- **SMTPS** SMTPS bezeichnet SMTP mit direkter TLS-Verschlüsselung. Typischer Port: TCP 465 Wichtig: TCP 465 startet normalerweise direkt mit TLS. Bei STARTTLS dagegen beginnt die Verbindung zunächst unverschlüsselt und wird dann auf TLS umgestellt. Merksatz: SMTPS = SMTP direkt über TLS. --- **SMTP-Port 25, 587 und 465 unterscheiden** | Port | Zweck | Kurz erklärt | |---:|---|---| | 25 | SMTP | Mailserver zu Mailserver | | 587 | Submission | Client sendet authentifiziert an Mailserver | | 465 | SMTPS | SMTP direkt über TLS | Prüfungsfalle: Port 25 ist nicht der typische Port, über den moderne Mailclients ihre E-Mails authentifiziert einreichen. Merksatz: 25 Servertransport, 587 Client-Abgabe, 465 SMTP über TLS. --- **POP3** POP3 steht für: Post Office Protocol Version 3 POP3 wird verwendet zum: Abrufen von E-Mails vom Mailserver. Typischer Port: TCP 110 Verschlüsselte Variante: POP3S: TCP 995 POP3 lädt E-Mails häufig vom Server herunter. Je nach Einstellung können sie danach vom Server gelöscht werden. Merksatz: POP3 = E-Mails einfach abrufen. --- **POP3-Grundidee** POP3 ist eher einfach aufgebaut. Typischer Ablauf: Client verbindet sich mit Mailserver. Client meldet sich an. Client ruft E-Mails ab. E-Mails werden lokal gespeichert. E-Mails können vom Server gelöscht werden. POP3 eignet sich weniger gut, wenn mehrere Geräte dieselbe Mailbox synchron nutzen sollen. Merksatz: POP3 ist einfach, aber weniger gut für moderne Mehrgeräte-Synchronisation. --- **IMAP** IMAP steht für: Internet Message Access Protocol IMAP wird verwendet zum: Abrufen und Verwalten von E-Mails auf dem Server. Typischer Port: TCP 143 Verschlüsselte Variante: IMAPS: TCP 993 IMAP lässt E-Mails normalerweise auf dem Server und synchronisiert den Zustand zwischen mehreren Geräten. Merksatz: IMAP = E-Mails auf dem Server verwalten und synchronisieren. --- **IMAP-Grundidee** Bei IMAP bleiben E-Mails meist auf dem Mailserver. Der Client synchronisiert: - Posteingang - Ordner - gelesen / ungelesen - gelöscht - verschoben - gesendet - Markierungen Das ist praktisch bei mehreren Geräten. Beispiel: E-Mail auf dem Smartphone gelesen. Am Notebook ist sie ebenfalls als gelesen markiert. Merksatz: IMAP eignet sich gut für mehrere Geräte. --- **POP3 und IMAP vergleichen** | Merkmal | POP3 | IMAP | |---|---|---| | Hauptzweck | E-Mails abrufen | E-Mails abrufen und verwalten | | Speicherort | oft lokal beim Client | meist auf dem Server | | Synchronisation | eingeschränkt | gut | | mehrere Geräte | weniger geeignet | gut geeignet | | Ordnerverwaltung | begrenzt | umfangreicher | | typischer Port | TCP 110 | TCP 143 | | verschlüsselt | TCP 995 | TCP 993 | Merksatz: POP3 lädt eher herunter. IMAP synchronisiert mit dem Server. --- **SMTP, POP3 und IMAP direkt vergleichen** | Protokoll | Aufgabe | typischer Port | |---|---|---:| | SMTP | E-Mail senden / transportieren | TCP 25 | | Submission | E-Mail vom Client einreichen | TCP 587 | | SMTPS | SMTP direkt über TLS | TCP 465 | | POP3 | E-Mail abrufen | TCP 110 | | POP3S | POP3 über TLS | TCP 995 | | IMAP | E-Mail abrufen und verwalten | TCP 143 | | IMAPS | IMAP über TLS | TCP 993 | Merksatz: SMTP raus. POP3/IMAP rein. --- **E-Mail-Client** Ein E-Mail-Client ist ein Programm oder eine App, mit der Benutzer E-Mails senden und empfangen. Beispiele: - Outlook - Thunderbird - Apple Mail - Smartphone-Mail-App - Webmail im Browser Der Client nutzt je nach Einrichtung: SMTP zum Senden IMAP oder POP3 zum Empfangen Merksatz: Mailclient nutzt SMTP zum Senden und IMAP/POP3 zum Empfangen. --- **Mailserver** Ein Mailserver nimmt E-Mails an, speichert sie und leitet sie weiter. Typische Aufgaben: - E-Mails von Clients annehmen - E-Mails von anderen Mailservern empfangen - E-Mails an andere Mailserver weiterleiten - Postfächer bereitstellen - Spamprüfung durchführen - Virenprüfung durchführen - TLS und Authentifizierung nutzen Merksatz: Mailserver transportiert und verwaltet E-Mails. --- **Webmail** Webmail bedeutet: E-Mails werden über eine Webseite genutzt. Beispiel: Benutzer öffnet Mailbox im Browser. Dabei nutzt der Browser: HTTP oder HTTPS Der Webmail-Server selbst kann intern trotzdem mit Maildiensten, Datenbanken oder IMAP arbeiten. Merksatz: Webmail nutzt im Browser HTTP/HTTPS, Mailserver dahinter nutzen Mailprotokolle. --- **DNS und E-Mail** DNS ist für E-Mail sehr wichtig. Wichtige DNS-Records: | Record | Zweck | |---|---| | MX | zuständiger Mailserver einer Domain | | A / AAAA | IP-Adresse des Mailservers | | PTR | Reverse-DNS | | TXT | SPF, DKIM, DMARC | Ohne korrekte DNS-Einträge kann E-Mail-Zustellung scheitern. Merksatz: E-Mail-Zustellung hängt stark von DNS ab. --- **MX-Record** MX steht für: Mail Exchanger Ein MX-Record sagt, welcher Mailserver für eine Domain zuständig ist. Beispiel: firma.de MX 10 mail.firma.de Die Zahl ist die Priorität. Kleinere Zahl bedeutet: höhere Priorität Merksatz: MX zeigt auf zuständigen Mailserver. --- **Mailzustellung mit MX vereinfacht** Ablauf: 1. Absender-Mailserver erhält E-Mail an benutzer@firma.de. 2. Er fragt DNS nach MX-Record für firma.de. 3. DNS liefert zuständigen Mailserver. 4. Absender-Mailserver verbindet sich per SMTP. 5. Empfänger-Mailserver nimmt E-Mail an. 6. Empfänger ruft E-Mail per IMAP, POP3 oder Webmail ab. Merksatz: MX sagt, wohin E-Mail für eine Domain geliefert werden soll. --- **PTR und Reverse DNS bei E-Mail** PTR-Records sind bei Mailservern wichtig. Ein PTR-Record ordnet eine IP-Adresse einem Namen zu. Viele empfangende Mailserver prüfen, ob der sendende Mailserver einen sinnvollen Reverse-DNS-Eintrag hat. Fehlender oder falscher PTR kann die Zustellbarkeit verschlechtern. Merksatz: Reverse DNS ist bei Mailservern wichtig für Vertrauenswürdigkeit. --- **SPF** SPF steht für: Sender Policy Framework SPF wird als TXT-Record im DNS veröffentlicht. SPF legt fest, welche Server für eine Domain E-Mails senden dürfen. Beispiel sinngemäß: Nur diese Mailserver dürfen E-Mails für firma.de senden. Merksatz: SPF sagt, welche Server für eine Domain senden dürfen. --- **DKIM** DKIM steht für: DomainKeys Identified Mail DKIM signiert E-Mails kryptografisch. Der öffentliche Schlüssel wird im DNS als TXT-Record veröffentlicht. Empfangende Mailserver können prüfen: Wurde die E-Mail wirklich passend signiert? Wurde sie unterwegs verändert? Merksatz: DKIM signiert E-Mails und hilft bei Integritätsprüfung. --- **DMARC** DMARC steht für: Domain-based Message Authentication, Reporting and Conformance DMARC baut auf SPF und DKIM auf. DMARC legt fest, wie Empfänger mit E-Mails umgehen sollen, wenn SPF oder DKIM nicht passen. Mögliche Richtlinien: - nur berichten - Quarantäne - ablehnen Merksatz: DMARC steuert den Umgang mit SPF-/DKIM-Fehlern. --- **SPF, DKIM und DMARC unterscheiden** | Verfahren | Hauptaufgabe | |---|---| | SPF | erlaubt sendende Server | | DKIM | signiert E-Mails | | DMARC | legt Umgang mit Prüfungsfehlern fest | Merksatz: SPF erlaubt. DKIM signiert. DMARC entscheidet. --- **STARTTLS bei E-Mail** STARTTLS bedeutet: Eine Verbindung beginnt zunächst unverschlüsselt und wird dann auf TLS umgestellt. STARTTLS wird häufig bei Mailprotokollen verwendet. Beispiele: - SMTP - IMAP - POP3 Wichtig: STARTTLS ist nicht dasselbe wie ein von Anfang an verschlüsselter eigener TLS-Port. Merksatz: STARTTLS startet unverschlüsselt und schaltet dann auf TLS um. --- **E-Mail und TLS** TLS schützt E-Mail-Verbindungen beim Transport. Beispiele: - SMTP mit STARTTLS - SMTPS - IMAPS - POP3S Wichtig: TLS schützt die Verbindung zwischen zwei Kommunikationspunkten. Das ist nicht automatisch Ende-zu-Ende-Verschlüsselung des E-Mail-Inhalts. Merksatz: TLS schützt die Mailverbindung, aber nicht automatisch den Inhalt bis zum endgültigen Empfänger. --- **Ende-zu-Ende-Verschlüsselung bei E-Mail** Ende-zu-Ende-Verschlüsselung bedeutet: Der Inhalt bleibt vom Absender bis zum Empfänger geschützt. Beispiele: - S/MIME - OpenPGP Dabei können Zwischenserver die Inhalte nicht einfach lesen. Unterschied zu TLS: TLS schützt die Verbindung. Ende-zu-Ende-Verschlüsselung schützt den Inhalt selbst. Merksatz: TLS ist Transportverschlüsselung. S/MIME oder OpenPGP schützen den Mailinhalt Ende-zu-Ende. --- **E-Mail-Adresse** Eine E-Mail-Adresse besteht aus: lokaler Teil @ Domain Beispiel: felix@firma.de Dabei ist: felix = lokaler Teil firma.de = Domain Für die Domain wird per DNS der zuständige Mailserver gesucht. Merksatz: Rechts vom @ steht die Maildomain. --- **Postfach und Alias** Ein Postfach ist ein echter Speicherbereich für E-Mails. Ein Alias ist eine zusätzliche Adresse, die auf ein Postfach oder eine Gruppe zeigen kann. Beispiel: Postfach: felix@firma.de Alias: support@firma.de E-Mails an support@firma.de landen im Postfach oder bei einer Gruppe. Merksatz: Postfach speichert. Alias leitet zu. --- **Verteilergruppe** Eine Verteilergruppe sendet eine E-Mail an mehrere Empfänger weiter. Beispiel: it-team@firma.de geht an: admin1@firma.de admin2@firma.de support@firma.de Merksatz: Verteilergruppe verteilt an mehrere Empfänger. --- **Shared Mailbox** Eine Shared Mailbox ist ein gemeinsames Postfach. Beispiel: support@firma.de Mehrere Benutzer können Zugriff haben. Typische Nutzung: - Support - Info-Adresse - Team-Postfach - Bewerbungen - Rechnungen Merksatz: Shared Mailbox = gemeinsames Postfach für mehrere Benutzer. --- **Postfachgröße** Ein Postfach kann eine Größenbegrenzung haben. Wenn das Postfach voll ist, können Probleme auftreten. Mögliche Folgen: - neue E-Mails werden abgewiesen - Benutzer kann nicht senden - Synchronisation schlägt fehl - Warnungen im Mailclient Merksatz: Volles Postfach kann Mailprobleme verursachen. --- **Spamfilter** Spamfilter prüfen eingehende E-Mails auf unerwünschte oder gefährliche Inhalte. Kriterien können sein: - Absenderreputation - Inhalt - Links - Anhänge - SPF - DKIM - DMARC - bekannte Schadsoftware - ungewöhnliches Verhalten Merksatz: Spamfilter entscheiden, ob E-Mails zugestellt, markiert oder blockiert werden. --- **Quarantäne** Quarantäne bedeutet: Eine E-Mail wird nicht direkt zugestellt, sondern zurückgehalten. Gründe: - Spamverdacht - Malwareverdacht - gefährlicher Anhang - Phishingverdacht - Richtlinienverstoß Administrator oder Benutzer können je nach System prüfen, ob die Mail freigegeben werden soll. Merksatz: Quarantäne hält verdächtige Mails zurück. --- **Phishing** Phishing ist der Versuch, Benutzer zur Preisgabe sensibler Informationen zu bringen. Beispiele: - gefälschte Login-Seite - angebliche Paketbenachrichtigung - falsche Rechnung - gefälschte Bank-Mail - angeblicher IT-Support Ziel: Zugangsdaten, Zahlungsdaten oder Zugriff auf Systeme Merksatz: Phishing täuscht Benutzer, um Daten oder Zugriff zu erhalten. --- **Anhänge und Sicherheit** E-Mail-Anhänge können gefährlich sein. Risiken: - Schadsoftware - Makros - manipulierte Dokumente - Archive mit Malware - ausführbare Dateien - Phishing-Dokumente Schutzmaßnahmen: - Anhänge prüfen - Makros einschränken - Antivirus - Sandboxing - Schulung der Benutzer - Dateitypen filtern Merksatz: E-Mail-Anhänge sind ein häufiger Angriffsweg. --- **E-Mail-Header** E-Mail-Header enthalten technische Informationen. Beispiele: - Absender - Empfänger - Betreff - Versandzeit - Mailserver-Wege - Message-ID - SPF/DKIM/DMARC-Ergebnisse - Received-Zeilen Header helfen bei der Fehlersuche und Sicherheitsanalyse. Merksatz: Mail-Header zeigen technische Zustellinformationen. --- **Received-Header** Received-Header zeigen, über welche Mailserver eine E-Mail gelaufen ist. Jeder Mailserver fügt typischerweise eine Received-Zeile hinzu. Damit kann man den Weg einer E-Mail nachvollziehen. Merksatz: Received-Header zeigen den Mailtransportweg. --- **Bounce-Mail** Eine Bounce-Mail ist eine automatische Fehlermeldung, wenn eine E-Mail nicht zugestellt werden konnte. Mögliche Gründe: - Empfänger existiert nicht - Postfach voll - Domain existiert nicht - Mailserver nicht erreichbar - Nachricht wurde abgelehnt - Spamprüfung fehlgeschlagen Merksatz: Bounce-Mail informiert über Zustellfehler. --- **NDR** NDR steht für: Non-Delivery Report Das ist eine Nichtzustellbarkeitsmeldung. Sie enthält häufig: - Fehlercode - Grund der Ablehnung - Zieladresse - Zeit - beteiligter Mailserver Merksatz: NDR = Meldung über nicht zugestellte E-Mail. --- **Typische SMTP-Fehlercodes** SMTP nutzt Antwortcodes. Grobe Einordnung: | Bereich | Bedeutung | |---|---| | 2xx | Erfolg | | 4xx | temporärer Fehler | | 5xx | dauerhafter Fehler | Beispiele: | Code | Bedeutung | |---:|---| | 250 | OK | | 421 | Dienst nicht verfügbar | | 450 | Mailbox vorübergehend nicht verfügbar | | 550 | Mailbox nicht gefunden oder abgelehnt | | 554 | Nachricht abgelehnt | Merksatz: 4xx kann später erneut versucht werden. 5xx ist meist dauerhaft. --- **E-Mail-Fehlersuche: Senden** Wenn E-Mail-Senden nicht funktioniert, prüft man: - SMTP-Server korrekt? - richtiger Port? - Authentifizierung korrekt? - TLS erforderlich? - Benutzer darf senden? - Absenderadresse erlaubt? - DNS korrekt? - Firewall blockiert? - Mailserver-Logs? - Fehlermeldung oder NDR? Merksatz: Beim Senden SMTP, Authentifizierung, TLS und DNS prüfen. --- **E-Mail-Fehlersuche: Empfangen** Wenn E-Mail-Empfang nicht funktioniert, prüft man: - MX-Record korrekt? - Mailserver erreichbar? - Postfach vorhanden? - Postfach voll? - Spamfilter oder Quarantäne? - POP3/IMAP erreichbar? - Client korrekt konfiguriert? - TLS und Anmeldung korrekt? - Mailserver-Logs? Merksatz: Beim Empfangen MX, Postfach, Spamfilter und Abrufprotokoll prüfen. --- **Fehlerbild: Mail kommt nicht an** Mögliche Ursachen: - falsche Empfängeradresse - MX-Record falsch - Mailserver nicht erreichbar - Spamfilter blockiert - Quarantäne - Postfach voll - SPF/DKIM/DMARC-Fehler - Absender blockiert - Domain falsch - NDR beachten Merksatz: Nicht zugestellte Mail immer mit NDR und Logs prüfen. --- **Fehlerbild: Mail landet im Spam** Mögliche Ursachen: - schlechter Absender-Ruf - SPF fehlt oder falsch - DKIM fehlt oder falsch - DMARC fehlt oder streng - Inhalt wirkt verdächtig - Links sind auffällig - Anhänge sind verdächtig - fehlender PTR-Record - neue oder schlecht bewertete Domain Merksatz: Spamprobleme oft mit DNS-Authentifizierung und Inhalt prüfen. --- **Fehlerbild: Mailclient kann nicht senden** Mögliche Ursachen: - falscher SMTP-Server - falscher Port - Authentifizierung falsch - TLS-Einstellung falsch - Passwort falsch - Benutzer darf nicht senden - Firewall blockiert - Provider blockiert Port 25 - Konto gesperrt Merksatz: Sendeprobleme am Client betreffen oft SMTP, Port, TLS und Login. --- **Fehlerbild: Mailclient kann nicht empfangen** Mögliche Ursachen: - falscher IMAP- oder POP3-Server - falscher Port - falsches Passwort - TLS-Einstellung falsch - Postfach voll - Konto gesperrt - Firewall blockiert - Serverdienst gestört - Zertifikatsfehler Merksatz: Empfangsprobleme am Client betreffen IMAP/POP3, Port, TLS und Login. --- **Fehlerbild: Zertifikatswarnung im Mailclient** Mögliche Ursachen: - Zertifikat abgelaufen - Name passt nicht zum Zertifikat - falscher Mailserver eingetragen - interne CA nicht vertraut - Zwischenzertifikat fehlt - falsche Systemzeit - Proxy oder Sicherheitssoftware greift ein Merksatz: Mail-Zertifikatsfehler wie HTTPS-Zertifikatsfehler prüfen. --- **Fehlerbild: E-Mail verzögert** Mögliche Ursachen: - Greylisting - temporärer SMTP-Fehler - überlasteter Mailserver - DNS-Probleme - Spamprüfung dauert - Zielserver nicht erreichbar - Warteschlange auf Mailserver - Rate Limits Merksatz: Verzögerte Mail kann durch temporäre Fehler oder Warteschlangen entstehen. --- **Greylisting** Greylisting ist eine Anti-Spam-Technik. Dabei lehnt der empfangende Server eine Mail zunächst temporär ab. Ein seriöser Mailserver versucht später erneut zuzustellen. Viele Spam-Systeme versuchen das nicht. Merksatz: Greylisting verzögert E-Mails absichtlich zur Spamabwehr. --- **Was E-Mail-Protokolle nicht machen** E-Mail-Protokolle machen nicht automatisch: - DNS korrekt konfigurieren - Benutzer sicher schulen - Phishing vollständig verhindern - Anhänge automatisch ungefährlich machen - Postfachgrößen unbegrenzt machen - Ende-zu-Ende-Verschlüsselung erzwingen - SPF/DKIM/DMARC automatisch korrekt setzen Merksatz: E-Mail braucht Protokolle, DNS, Sicherheit und Administration zusammen. --- **Einordnung in das OSI-Modell** | Thema | Schicht | |---|---:| | SMTP | 7 | | POP3 | 7 | | IMAP | 7 | | DNS MX | 7 | | SPF/DKIM/DMARC | 7 mit Sicherheitsbezug | | TLS bei Mail | 6 mit Schicht-7-Bezug | | TCP-Port 25/587/465/110/143/993/995 | 4 | | IP-Adresse des Mailservers | 3 | | MAC-Adresse | 2 | Merksatz: Mailprotokolle gehören zu Schicht 7, ihre Ports zu Schicht 4. --- **Typische IHK-Fragen** In AP1 und AP2 kann zum Beispiel gefragt werden: - Welche Protokolle werden für E-Mail verwendet? - Wofür wird SMTP genutzt? - Wofür wird POP3 genutzt? - Wofür wird IMAP genutzt? - Was ist der Unterschied zwischen POP3 und IMAP? - Welche Ports nutzen SMTP, POP3 und IMAP? - Was ist SMTP Submission? - Was ist STARTTLS? - Was ist ein MX-Record? - Warum ist DNS für E-Mail wichtig? - Was machen SPF, DKIM und DMARC? - Was ist ein NDR? - Warum landet eine Mail im Spam? - Warum ist TLS bei Mail nicht automatisch Ende-zu-Ende-Verschlüsselung? --- **Typische Prüfungsfallen** SMTP sendet E-Mails. POP3 ruft E-Mails ab. IMAP ruft E-Mails ab und verwaltet sie auf dem Server. SMTP zwischen Mailservern nutzt häufig TCP 25. SMTP Submission nutzt häufig TCP 587. SMTPS nutzt häufig TCP 465. POP3 nutzt TCP 110. POP3S nutzt TCP 995. IMAP nutzt TCP 143. IMAPS nutzt TCP 993. SMTP ist nicht zum Abrufen von E-Mails gedacht. POP3 ist weniger gut für mehrere Geräte. IMAP ist besser für Synchronisation. MX-Record zeigt zuständigen Mailserver. SPF erlaubt sendende Server. DKIM signiert E-Mails. DMARC legt Umgang mit Fehlern fest. TLS schützt Verbindung, aber nicht automatisch Ende-zu-Ende den Inhalt. Mailprobleme können DNS-, TLS-, Spamfilter- oder Postfachprobleme sein. --- **Wichtige Begriffe kurz erklärt** | Begriff | Kurze Erklärung | |---|---| | SMTP | Protokoll zum Senden und Weiterleiten von E-Mails | | POP3 | Protokoll zum einfachen Abrufen von E-Mails | | IMAP | Protokoll zum Abrufen und Verwalten von E-Mails | | Submission | authentifiziertes Einreichen von E-Mails | | SMTPS | SMTP direkt über TLS | | POP3S | POP3 über TLS | | IMAPS | IMAP über TLS | | MX | DNS-Eintrag für zuständigen Mailserver | | PTR | Reverse-DNS-Eintrag | | SPF | legt erlaubte sendende Server fest | | DKIM | kryptografische Signatur für E-Mails | | DMARC | Richtlinie für SPF-/DKIM-Auswertung | | STARTTLS | Umschalten auf TLS innerhalb einer Verbindung | | S/MIME | Ende-zu-Ende-Verschlüsselung und Signatur für E-Mail | | OpenPGP | Ende-zu-Ende-Verschlüsselung für E-Mail | | Postfach | Speicherbereich für E-Mails | | Alias | zusätzliche Adresse für ein Postfach | | Shared Mailbox | gemeinsames Postfach | | Spamfilter | Filter gegen unerwünschte E-Mails | | Quarantäne | zurückgehaltene verdächtige E-Mail | | NDR | Nichtzustellbarkeitsmeldung | | Bounce | automatische Fehlermeldung bei Zustellproblem | --- **IHK-sichere Kurzformulierung** E-Mail-Kommunikation gehört zur Anwendungsschicht des OSI-Modells und nutzt mehrere Protokolle. SMTP dient dem Senden und Weiterleiten von E-Mails, POP3 und IMAP dienen dem Abrufen von E-Mails. POP3 lädt E-Mails eher einfach ab, während IMAP E-Mails auf dem Server verwaltet und zwischen mehreren Geräten synchronisiert. DNS ist für E-Mail wichtig, insbesondere durch MX-Records für zuständige Mailserver sowie TXT-Records für SPF, DKIM und DMARC. TLS kann Mailverbindungen schützen, ist aber nicht automatisch Ende-zu-Ende-Verschlüsselung des Mailinhalts. --- **Merksätze** E-Mail gehört zu Schicht 7. SMTP sendet E-Mails. POP3 ruft E-Mails ab. IMAP ruft E-Mails ab und verwaltet sie. SMTP = Simple Mail Transfer Protocol. POP3 = Post Office Protocol Version 3. IMAP = Internet Message Access Protocol. SMTP Port 25 = Mailserver zu Mailserver. Submission Port 587 = Client sendet authentifiziert. SMTPS Port 465 = SMTP direkt über TLS. POP3 Port 110 = Abruf unverschlüsselt. POP3S Port 995 = POP3 über TLS. IMAP Port 143 = Abruf und Verwaltung. IMAPS Port 993 = IMAP über TLS. MX = zuständiger Mailserver. PTR = Reverse DNS. SPF sagt, wer senden darf. DKIM signiert E-Mails. DMARC legt Umgang mit Prüfungsfehlern fest. POP3 lädt eher herunter. IMAP synchronisiert besser. STARTTLS schaltet auf TLS um. TLS schützt Mailverbindung, aber nicht automatisch Ende-zu-Ende den Inhalt. S/MIME und OpenPGP schützen Inhalte Ende-zu-Ende. NDR = Nichtzustellbarkeitsmeldung. Mailprobleme mit DNS, Ports, TLS, Authentifizierung, Spamfilter und Logs prüfen. # 10.6 Datei- und Freigabeprotokolle: FTP, SFTP, FTPS und SMB Datei- und Freigabeprotokolle gehören zur OSI-Schicht 7. Sie werden genutzt, um Dateien über ein Netzwerk bereitzustellen, zu übertragen oder gemeinsam zu verwenden. Wichtige Protokolle sind: - FTP - SFTP - FTPS - SMB Diese Protokolle haben unterschiedliche Aufgaben und Sicherheitsmerkmale. Merksatz: Dateiübertragung und Dateifreigaben gehören zur Anwendungsschicht. --- **Grundidee von Dateiübertragung** Bei der Dateiübertragung werden Dateien von einem System zu einem anderen übertragen. Beispiele: - Datei auf Server hochladen - Datei von Server herunterladen - Backup übertragen - Konfigurationsdatei kopieren - Webseite auf Webserver hochladen - Dokumente zwischen Systemen austauschen Dabei muss geregelt werden: - wer zugreifen darf - welche Dateien übertragen werden - ob verschlüsselt wird - welcher Port genutzt wird - ob nur Dateiübertragung oder echte Freigabe gewünscht ist Merksatz: Dateiübertragung bedeutet: Dateien gezielt zwischen Systemen bewegen. --- **Grundidee von Dateifreigaben** Eine Dateifreigabe stellt Dateien im Netzwerk bereit. Dabei sieht ein Benutzer oder Client einen Ordner auf einem entfernten System. Beispiele: - Netzlaufwerk im Unternehmen - gemeinsamer Projektordner - Druckerfreigabe - zentrale Dateiablage - Home-Laufwerk eines Benutzers - NAS-Freigabe Typisch hierfür ist: SMB Merksatz: Dateifreigabe bedeutet: Dateien werden im Netzwerk gemeinsam bereitgestellt. --- **Dateiübertragung und Dateifreigabe unterscheiden** | Thema | Dateiübertragung | Dateifreigabe | |---|---|---| | Grundidee | Datei von A nach B kopieren | Ordner im Netzwerk gemeinsam nutzen | | typische Protokolle | FTP, SFTP, FTPS | SMB | | Nutzung | Upload, Download, Transfer | Netzlaufwerk, Freigabe, gemeinsames Arbeiten | | Zugriff | meist gezielte Übertragung | fortlaufender Zugriff auf entfernte Dateien | | Beispiel | Datei auf Server hochladen | Laufwerk `\\server\share` öffnen | Merksatz: FTP/SFTP/FTPS übertragen Dateien. SMB stellt Freigaben bereit. --- **Einordnung im OSI-Modell** | Thema | Schicht | |---|---:| | FTP | 7 | | SFTP | 7, nutzt SSH | | FTPS | 7, nutzt TLS | | SMB | 7 | | TCP-Port | 4 | | IP-Adresse | 3 | | MAC-Adresse | 2 | | TLS | 6 mit Schicht-7-Bezug | | SSH | 7 mit Sicherheitsbezug | Merksatz: Protokoll = Schicht 7. Port = Schicht 4. --- **FTP** FTP steht für: File Transfer Protocol FTP dient zur Dateiübertragung. Typischer Port: TCP 21 FTP wird klassisch verwendet für: - Dateien hochladen - Dateien herunterladen - Verzeichnisse auflisten - Dateien löschen oder umbenennen - einfache Server-Dateiverwaltung Wichtig: Klassisches FTP ist unverschlüsselt. Merksatz: FTP = Dateiübertragung über TCP 21, aber klassisch unverschlüsselt. --- **FTP ist unverschlüsselt** Klassisches FTP überträgt Daten unverschlüsselt. Das betrifft besonders: - Benutzername - Passwort - Befehle - Dateiinhalte Wenn jemand den Netzwerkverkehr mitlesen kann, können sensible Informationen sichtbar werden. Deshalb sollte klassisches FTP heute möglichst vermieden werden. Merksatz: FTP ohne Schutz ist unsicher. --- **FTP-Steuerverbindung und Datenverbindung** FTP arbeitet mit zwei Verbindungsarten: Steuerverbindung Datenverbindung Steuerverbindung: Befehle und Anmeldung Datenverbindung: Dateiinhalt und Verzeichnislisten Typisch: TCP 21 für Steuerverbindung Die Datenverbindung hängt vom Modus ab. Merksatz: FTP nutzt Steuerverbindung und Datenverbindung. --- **Aktiver FTP-Modus** Beim aktiven FTP-Modus baut der Server eine Datenverbindung zurück zum Client auf. Problem: Firewalls und NAT können das erschweren, weil der Server von außen zum Client verbinden möchte. Typische Schwierigkeit: Client sitzt hinter NAT oder Firewall. Merksatz: Aktives FTP kann mit NAT und Firewalls Probleme machen. --- **Passiver FTP-Modus** Beim passiven FTP-Modus baut der Client beide Verbindungen zum Server auf. Das ist heute häufig praktischer, weil Clients oft hinter NAT oder Firewalls sitzen. Der Server teilt dem Client einen Datenport mit, zu dem der Client sich verbindet. Wichtig: Die passiven Portbereiche müssen auf Firewall und Server korrekt erlaubt sein. Merksatz: Passives FTP ist NAT-freundlicher, braucht aber passende Firewall-Regeln. --- **FTP und Firewall-Probleme** FTP kann bei Firewalls schwieriger sein als einfache Protokolle. Warum? FTP nutzt nicht nur eine einzelne Verbindung. Typische Fehler: - Login funktioniert, aber Verzeichnisliste lädt nicht - Verbindung funktioniert, aber Dateiübertragung schlägt fehl - passiver Portbereich nicht freigegeben - NAT übersetzt falsche Adresse Merksatz: Bei FTP müssen Steuer- und Datenverbindung funktionieren. --- **SFTP** SFTP steht für: SSH File Transfer Protocol SFTP ist Dateiübertragung über SSH. Typischer Port: TCP 22 SFTP ist nicht dasselbe wie FTP. SFTP nutzt SSH als sichere Grundlage. Dadurch werden Anmeldung und Daten verschlüsselt übertragen. Merksatz: SFTP = Dateiübertragung über SSH. --- **SFTP und SSH** SFTP läuft über SSH. SSH bietet: - Verschlüsselung - Authentifizierung - sichere Verbindung - Zugriff über Benutzerkonto oder Schlüssel SFTP nutzt diese sichere Verbindung, um Dateien zu übertragen. Typische Nutzung: - Serveradministration - Datei-Upload auf Server - sichere Dateiübertragung - Automatisierung mit Schlüsseln Merksatz: Wer SFTP nutzt, nutzt technisch SSH als Grundlage. --- **SFTP ist nicht FTP über TLS** Ein häufiger Fehler ist: SFTP = sicheres FTP Besser: SFTP ist ein eigenes Protokoll über SSH. Es ist nicht: klassisches FTP mit Verschlüsselung Das wäre eher: FTPS Merksatz: SFTP ist nicht FTPS. --- **FTPS** FTPS bedeutet: FTP mit TLS-Schutz FTPS basiert auf FTP, nutzt aber TLS zur Verschlüsselung. Es gibt zwei typische Varianten: explizites FTPS implizites FTPS Merksatz: FTPS = FTP mit TLS. --- **Explizites FTPS** Explizites FTPS startet zunächst auf dem klassischen FTP-Port. Typischer Port: TCP 21 Dann wird mit einem Befehl auf TLS umgestellt. Das ist ähnlich zur Idee von STARTTLS. Merksatz: Explizites FTPS startet auf TCP 21 und schaltet auf TLS um. --- **Implizites FTPS** Implizites FTPS startet direkt mit TLS. Typischer Port: TCP 990 Dabei wird von Beginn an verschlüsselt kommuniziert. Merksatz: Implizites FTPS nutzt typischerweise TCP 990. --- **SFTP und FTPS vergleichen** | Merkmal | SFTP | FTPS | |---|---|---| | Grundlage | SSH | FTP + TLS | | typischer Port | TCP 22 | TCP 21 oder TCP 990 | | Protokollfamilie | SSH-basiert | FTP-basiert | | Verschlüsselung | durch SSH | durch TLS | | Firewall-Aufwand | meist einfacher | oft aufwendiger wegen FTP-Datenkanälen | | nicht verwechseln mit | FTPS | SFTP | Merksatz: SFTP = SSH. FTPS = FTP mit TLS. --- **FTP, SFTP und FTPS vergleichen** | Protokoll | Verschlüsselung | typischer Port | Kurzidee | |---|---|---:|---| | FTP | nein | TCP 21 | klassische Dateiübertragung | | SFTP | ja, SSH | TCP 22 | Dateiübertragung über SSH | | FTPS explizit | ja, TLS | TCP 21 | FTP startet und schaltet auf TLS | | FTPS implizit | ja, TLS | TCP 990 | FTP direkt über TLS | Merksatz: FTP unverschlüsselt. SFTP über SSH. FTPS über TLS. --- **SMB** SMB steht für: Server Message Block SMB wird für Datei- und Druckerfreigaben verwendet. Typischer Port: TCP 445 Typische Nutzung: - Windows-Dateifreigaben - Netzlaufwerke - Druckerfreigaben - zentrale Dateiablagen - Zugriff auf NAS-Freigaben - Freigaben in Unternehmensnetzen Merksatz: SMB = Datei- und Druckerfreigaben im Netzwerk. --- **SMB-Freigabe** Eine SMB-Freigabe ist ein freigegebener Ordner im Netzwerk. Beispiel Windows-Schreibweise: \\server01\daten Dabei ist: server01 = Servername daten = Freigabename Benutzer können diese Freigabe als Netzlaufwerk verbinden. Merksatz: SMB-Freigabe = Netzwerkordner. --- **UNC-Pfad** UNC steht für: Universal Naming Convention Ein UNC-Pfad beschreibt eine Netzwerkfreigabe. Beispiel: \\server01\freigabe\ordner\datei.txt Bestandteile: Servername Freigabename Pfad innerhalb der Freigabe Merksatz: UNC-Pfad zeigt auf eine Netzwerkfreigabe. --- **Netzlaufwerk** Ein Netzlaufwerk ist eine eingebundene Netzwerkfreigabe. Beispiel: Laufwerk Z: zeigt auf \\server01\projekte Vorteil: Benutzer kann die Freigabe wie ein Laufwerk verwenden. Merksatz: Netzlaufwerk = eingebundene SMB-Freigabe. --- **SMB und Berechtigungen** Bei SMB gibt es meist zwei Berechtigungsebenen: Freigabeberechtigungen Dateisystemberechtigungen In Windows-Umgebungen sind Dateisystemberechtigungen oft NTFS-Berechtigungen. Wichtig: Es gilt am Ende die wirksam einschränkendere Berechtigung. Merksatz: SMB-Zugriff hängt von Freigabe- und Dateisystemrechten ab. --- **Freigabeberechtigungen** Freigabeberechtigungen gelten auf Ebene der Netzwerkfreigabe. Beispiele: Lesen Ändern Vollzugriff Sie steuern, was Benutzer über die Freigabe grundsätzlich dürfen. Merksatz: Freigaberechte gelten am Netzwerkzugriffspunkt. --- **Dateisystemberechtigungen** Dateisystemberechtigungen gelten auf dem Dateisystem selbst. Beispiele: Lesen Schreiben Ändern Löschen Ausführen Vollzugriff Sie gelten oft auch lokal auf dem Server, nicht nur über das Netzwerk. Merksatz: Dateisystemrechte schützen Dateien und Ordner direkt. --- **Effektive Berechtigung** Wenn Freigaberechte und Dateisystemrechte zusammenkommen, zählt die effektiv erlaubte Berechtigung. Beispiel: Freigabe: Vollzugriff Dateisystem: Lesen Ergebnis: Benutzer kann nur lesen. Merksatz: Die strengere Berechtigung begrenzt den Zugriff. --- **Gruppen statt Einzelbenutzer** In Unternehmensnetzen vergibt man Rechte möglichst über Gruppen. Beispiel: Gruppe: Projekt_A_Lesen Gruppe: Projekt_A_Aendern Benutzer werden in Gruppen aufgenommen, statt direkt auf einzelne Ordner berechtigt zu werden. Vorteile: - bessere Übersicht - einfachere Verwaltung - weniger Fehler - leichteres Entfernen von Rechten Merksatz: Berechtigungen über Gruppen vergeben. --- **Least Privilege** Least Privilege bedeutet: Benutzer erhalten nur die Rechte, die sie wirklich benötigen. Beispiel: Praktikant braucht Leserechte, aber keine Löschrechte. Dieses Prinzip reduziert Sicherheitsrisiken. Merksatz: Nur so viele Rechte wie nötig, so wenige wie möglich. --- **SMB und Active Directory** In Windows-Umgebungen wird SMB häufig mit Active Directory kombiniert. Active Directory liefert: Benutzerkonten Gruppen Authentifizierung Richtlinien SMB nutzt diese Informationen, um Freigabezugriffe zu erlauben oder abzulehnen. Merksatz: SMB-Freigaben nutzen oft AD-Benutzer und Gruppen. --- **SMB und DNS** SMB-Zugriff nutzt häufig Servernamen. Beispiel: \\fileserver01\projekte Dafür muss Namensauflösung funktionieren. Mögliche Namensauflösung: - DNS - lokale Namensauflösung - ältere NetBIOS-Mechanismen In modernen Netzwerken ist DNS besonders wichtig. Merksatz: SMB-Probleme können DNS-Probleme sein. --- **SMB-Versionen** Es gibt verschiedene SMB-Versionen. Wichtig: SMBv1 ist veraltet und unsicher. Moderne Systeme sollten SMBv2 oder SMBv3 verwenden. SMBv3 unterstützt unter anderem bessere Sicherheitsfunktionen und kann Verschlüsselung unterstützen. Merksatz: SMBv1 vermeiden. SMBv2 oder SMBv3 verwenden. --- **SMB und Sicherheit** SMB sollte sorgfältig abgesichert werden. Wichtige Punkte: - SMBv1 deaktivieren - Zugriff nur intern oder über VPN - keine SMB-Freigaben direkt ins Internet öffnen - Berechtigungen sauber setzen - Gruppen verwenden - Protokollierung aktivieren - Updates einspielen - Gastzugriff vermeiden - starke Authentifizierung nutzen Merksatz: SMB gehört nicht ungeschützt ins Internet. --- **SMB und Druckerfreigaben** SMB kann auch für Druckerfreigaben verwendet werden. Beispiel: \\printserver01\drucker01 Clients verbinden sich mit der Freigabe und senden Druckaufträge an den Druckserver. Merksatz: SMB kann Dateien und Drucker freigeben. --- **FTP oder SMB?** | Anwendungsfall | eher passend | |---|---| | einzelne Datei auf Server hochladen | SFTP oder FTPS | | Webseite per Dateiübertragung aktualisieren | SFTP | | gemeinsames Netzlaufwerk im Unternehmen | SMB | | NAS-Freigabe im LAN | SMB | | automatisierter sicherer Dateitransfer | SFTP | | klassische unverschlüsselte Übertragung | FTP vermeiden | Merksatz: SMB für Freigaben. SFTP/FTPS für Dateiübertragung. --- **Sicherheit: FTP vermeiden** Klassisches FTP sollte möglichst vermieden werden, weil es unverschlüsselt ist. Bessere Alternativen: - SFTP - FTPS - HTTPS-Upload - VPN plus interne Freigabe - sichere Cloud- oder Filesharing-Lösung Merksatz: FTP ohne Verschlüsselung ist nicht mehr zeitgemäß. --- **Sicherheit: SFTP bevorzugen** SFTP ist oft eine gute Wahl für sichere Dateiübertragung. Vorteile: - nur ein typischer Port - SSH-Verschlüsselung - Schlüsselbasierte Anmeldung möglich - gut automatisierbar - häufig auf Servern verfügbar Merksatz: SFTP ist für sichere Dateiübertragung oft einfacher als FTPS. --- **Dateiübertragung und Datenschutz** Bei Dateiübertragung können sensible Daten betroffen sein. Beispiele: - Kundendaten - Rechnungen - Bewerbungen - personenbezogene Daten - Zugangsdaten - interne Dokumente - Backups Deshalb wichtig: - verschlüsselte Übertragung - Zugriffsschutz - Protokollierung - Berechtigungskonzept - Aufbewahrungsregeln - sichere Löschung bei Bedarf Merksatz: Dateiübertragung muss Datenschutz und Zugriffsschutz beachten. --- **Fehlerbild: FTP-Login geht, Dateiübertragung nicht** Mögliche Ursachen: - passiver Portbereich nicht freigegeben - aktiver Modus scheitert an NAT - Firewall blockiert Datenverbindung - Server gibt falsche externe IP aus - TLS-Modus passt nicht - Berechtigungen fehlen Merksatz: Bei FTP kann Login funktionieren, obwohl Datenübertragung scheitert. --- **Fehlerbild: SFTP-Verbindung scheitert** Mögliche Ursachen: - SSH-Dienst läuft nicht - TCP 22 blockiert - falscher Benutzer - falscher Schlüssel - Passwortlogin deaktiviert - Benutzer hat keine SFTP-Berechtigung - falscher Hostname - Firewall blockiert - Host-Key-Warnung Merksatz: SFTP-Probleme wie SSH-Probleme prüfen. --- **Fehlerbild: FTPS-Zertifikatsfehler** Mögliche Ursachen: - Zertifikat abgelaufen - Name passt nicht zum Zertifikat - CA nicht vertrauenswürdig - Zwischenzertifikat fehlt - Client unterstützt TLS-Version nicht - falscher FTPS-Modus Merksatz: FTPS-Zertifikatsfehler wie TLS-Probleme prüfen. --- **Fehlerbild: SMB-Freigabe nicht erreichbar** Mögliche Ursachen: - Servername wird nicht aufgelöst - TCP 445 blockiert - Serverdienst läuft nicht - Firewall blockiert SMB - falscher Freigabename - Benutzer hat keine Rechte - falsche Domänenanmeldung - SMB-Version nicht kompatibel - Netzwerkprofil blockiert Freigaben Merksatz: SMB-Probleme mit DNS, TCP 445, Dienst und Berechtigungen prüfen. --- **Fehlerbild: Zugriff verweigert bei SMB** Mögliche Ursachen: - Benutzer nicht berechtigt - Gruppe fehlt - Freigabeberechtigung zu streng - NTFS-Berechtigung zu streng - Vererbung falsch - falsches Konto verwendet - gespeicherte alte Anmeldedaten - Datei durch anderen Prozess gesperrt Merksatz: Zugriff verweigert heißt oft: Berechtigungen oder Anmeldung prüfen. --- **Fehlerbild: Netzlaufwerk verbindet nicht** Mögliche Ursachen: - Server nicht erreichbar - DNS-Name falsch - Freigabe existiert nicht - Benutzer nicht berechtigt - falsche gespeicherte Zugangsdaten - VPN nicht verbunden - SMB-Port blockiert - Offline-Dateien oder Cache-Problem - Gruppenrichtlinie greift nicht Merksatz: Netzlaufwerkprobleme mit Pfad, DNS, Port, Anmeldung und Rechten prüfen. --- **Fehlerbild: Datei lässt sich nicht speichern** Mögliche Ursachen: - keine Schreibrechte - Speicherplatz voll - Quota erreicht - Datei gesperrt - Pfad zu lang - Dateiname ungültig - Netzwerkunterbrechung - Synchronisationsproblem - Antivirus blockiert Merksatz: Speichern auf Freigaben braucht Rechte, Platz und stabile Verbindung. --- **Fehlerbild: Datei ist gesperrt** Eine Datei kann durch einen Benutzer oder Prozess gesperrt sein. Mögliche Ursachen: - Datei ist geöffnet - Anwendung hält Sperre - vorherige Sitzung nicht sauber beendet - Synchronisationsdienst greift zu - Backup oder Antivirus scannt Datei Merksatz: Dateisperren verhindern gleichzeitige unsichere Änderungen. --- **Fehlersuche bei Datei- und Freigabeproblemen** Eine sinnvolle Reihenfolge: 1. Name oder IP erreichbar? 2. Richtiger Port erreichbar? 3. Richtiger Dienst läuft? 4. Richtiges Protokoll verwendet? 5. Authentifizierung korrekt? 6. Berechtigungen korrekt? 7. Verschlüsselung oder Zertifikat korrekt? 8. Firewall oder NAT im Weg? 9. Serverlogs prüfen. 10. Clientlogs oder Fehlermeldung prüfen. Merksatz: Erst Verbindung, dann Protokoll, dann Anmeldung, dann Rechte. --- **Nützliche Prüfpunkte** | Prüffrage | Bedeutung | |---|---| | Ist der Server erreichbar? | Schicht 3 prüfen | | Ist der Port erreichbar? | Schicht 4 prüfen | | Läuft der Dienst? | Schicht 7 prüfen | | Stimmt der Benutzer? | Authentifizierung prüfen | | Hat der Benutzer Rechte? | Autorisierung prüfen | | Ist die Verbindung verschlüsselt? | Sicherheit prüfen | | Gibt es Logs? | Ursache genauer finden | Merksatz: Datei-Probleme sauber nach Schichten eingrenzen. --- **Was Datei- und Freigabeprotokolle nicht machen** Sie machen nicht automatisch: - Benutzer korrekt berechtigen - Daten verschlüsselt speichern - Backups erstellen - Malware verhindern - Datenschutz automatisch erfüllen - Versionierung bereitstellen - Konflikte automatisch sinnvoll lösen - defekte Dateien reparieren Merksatz: Dateiübertragung ersetzt kein Berechtigungs-, Backup- oder Sicherheitskonzept. --- **Typische Ports** | Protokoll | Port | Hinweis | |---|---:|---| | FTP | TCP 21 | Steuerverbindung | | SFTP | TCP 22 | über SSH | | FTPS explizit | TCP 21 | FTP mit TLS-Umschaltung | | FTPS implizit | TCP 990 | direkt TLS | | SMB | TCP 445 | Datei- und Druckerfreigaben | Merksatz: FTP 21, SFTP 22, FTPS 990, SMB 445. --- **Einordnung in das OSI-Modell** | Thema | Schicht | |---|---:| | FTP | 7 | | SFTP | 7 | | FTPS | 7 mit TLS-Bezug | | SMB | 7 | | TLS bei FTPS | 6 | | SSH bei SFTP | 7 mit Sicherheitsbezug | | TCP-Port 21 / 22 / 445 / 990 | 4 | | IP-Adresse des Servers | 3 | | DNS-Name des Servers | 7 | | SMB-Berechtigungen | 7 / Betriebssystembezug | Merksatz: Datei- und Freigabeprotokolle sind Schicht 7, nutzen aber Schicht 4-Ports. --- **Typische IHK-Fragen** In AP1 und AP2 kann zum Beispiel gefragt werden: - Wofür wird FTP genutzt? - Warum ist klassisches FTP unsicher? - Was ist der Unterschied zwischen FTP, SFTP und FTPS? - Welcher Port wird typischerweise für SFTP genutzt? - Was ist SMB? - Wofür wird SMB verwendet? - Welcher Port wird für SMB verwendet? - Was ist eine SMB-Freigabe? - Was ist ein UNC-Pfad? - Was ist der Unterschied zwischen Dateiübertragung und Dateifreigabe? - Warum sollte SMB nicht direkt ins Internet geöffnet werden? - Warum kann FTP trotz erfolgreichem Login bei der Dateiübertragung scheitern? - Welche Rolle spielen Berechtigungen bei SMB? - Warum sollte man Berechtigungen über Gruppen vergeben? --- **Typische Prüfungsfallen** FTP ist klassisch unverschlüsselt. FTP nutzt typischerweise TCP 21. FTP kann Steuer- und Datenverbindung nutzen. FTP kann mit NAT und Firewall schwierig sein. SFTP ist Dateiübertragung über SSH. SFTP nutzt typischerweise TCP 22. SFTP ist nicht FTPS. FTPS ist FTP mit TLS. Implizites FTPS nutzt häufig TCP 990. SMB nutzt typischerweise TCP 445. SMB ist für Datei- und Druckerfreigaben. SMBv1 ist veraltet und unsicher. UNC-Pfad sieht aus wie `\\server\freigabe`. Freigaberechte und Dateisystemrechte zusammen beachten. Strengere Berechtigung begrenzt den Zugriff. Berechtigungen möglichst über Gruppen vergeben. SMB gehört nicht ungeschützt ins Internet. --- **Wichtige Begriffe kurz erklärt** | Begriff | Kurze Erklärung | |---|---| | FTP | klassisches Dateiübertragungsprotokoll | | SFTP | Dateiübertragung über SSH | | FTPS | FTP mit TLS | | SMB | Datei- und Druckerfreigabeprotokoll | | Steuerverbindung | FTP-Verbindung für Befehle | | Datenverbindung | FTP-Verbindung für Dateiinhalt | | aktiver FTP-Modus | Server baut Datenverbindung zum Client auf | | passiver FTP-Modus | Client baut Datenverbindung zum Server auf | | SMB-Freigabe | freigegebener Netzwerkordner | | UNC-Pfad | Pfad zu einer Netzwerkfreigabe | | Netzlaufwerk | eingebundene Netzwerkfreigabe | | Freigabeberechtigung | Recht auf Netzwerkfreigabeebene | | Dateisystemberechtigung | Recht auf Datei- oder Ordnerebene | | effektive Berechtigung | tatsächlich wirkendes Recht | | Least Privilege | nur notwendige Rechte vergeben | | SMBv1 | veraltete unsichere SMB-Version | --- **IHK-sichere Kurzformulierung** FTP, SFTP, FTPS und SMB sind Protokolle der Anwendungsschicht. FTP dient der klassischen Dateiübertragung, ist ohne Zusatzschutz jedoch unverschlüsselt und nutzt typischerweise TCP-Port 21. SFTP ist Dateiübertragung über SSH und nutzt typischerweise TCP-Port 22. FTPS ist FTP mit TLS-Schutz und nutzt je nach Variante TCP-Port 21 oder 990. SMB wird für Datei- und Druckerfreigaben verwendet und nutzt typischerweise TCP-Port 445. Bei SMB sind Freigabeberechtigungen und Dateisystemberechtigungen zu unterscheiden. Moderne Systeme sollten SMBv1 vermeiden und SMB-Freigaben nicht ungeschützt aus dem Internet erreichbar machen. --- **Merksätze** Dateiübertragung und Freigaben gehören zu Schicht 7. FTP = File Transfer Protocol. FTP nutzt typischerweise TCP 21. FTP ist klassisch unverschlüsselt. FTP nutzt Steuer- und Datenverbindung. Passives FTP ist NAT-freundlicher. SFTP = SSH File Transfer Protocol. SFTP nutzt typischerweise TCP 22. SFTP ist Dateiübertragung über SSH. FTPS = FTP mit TLS. FTPS ist nicht SFTP. Implizites FTPS nutzt häufig TCP 990. SMB = Server Message Block. SMB nutzt typischerweise TCP 445. SMB = Datei- und Druckerfreigaben. SMB-Freigabe = Netzwerkordner. UNC-Pfad = `\\server\freigabe`. Netzlaufwerk = eingebundene Freigabe. Freigaberechte und Dateisystemrechte zusammen prüfen. Die strengere Berechtigung begrenzt den Zugriff. Rechte möglichst über Gruppen vergeben. Least Privilege beachten. SMBv1 vermeiden. SMB nicht ungeschützt ins Internet öffnen. Datei-Probleme mit DNS, Port, Dienst, Anmeldung und Berechtigungen prüfen. # 10.7 Verzeichnisdienste, Netzwerkmanagement und Zeitdienste: LDAP, SNMP und NTP LDAP, SNMP und NTP gehören zur OSI-Schicht 7. Sie erfüllen unterschiedliche Aufgaben in Netzwerken: LDAP: Verzeichnisdienste abfragen und verwalten SNMP: Netzwerkgeräte überwachen und verwalten NTP: Uhrzeit synchronisieren Diese Dienste sind besonders in Unternehmensnetzwerken wichtig. Merksatz: LDAP verwaltet Verzeichnisinformationen. SNMP überwacht Geräte. NTP synchronisiert Zeit. --- **Grundidee** In Netzwerken müssen nicht nur Daten übertragen werden. Es müssen auch Dienste bereitstehen für: - Benutzerinformationen - Gruppen - Geräteinformationen - zentrale Anmeldung - Monitoring - Zustandsabfragen - Zeitabgleich - Protokollierung - Authentifizierung LDAP, SNMP und NTP unterstützen genau solche Verwaltungsaufgaben. Merksatz: Schicht 7 enthält viele Verwaltungs- und Infrastrukturprotokolle. --- **Einordnung im OSI-Modell** | Thema | Schicht | |---|---:| | LDAP | 7 | | SNMP | 7 | | NTP | 7 | | TCP-/UDP-Port | 4 | | IP-Adresse | 3 | | TLS bei LDAPS | 6 mit Schicht-7-Bezug | | Benutzer- und Gruppendaten | 7 / Verzeichnisdienst | | Monitoringdaten | 7 / Managementdienst | Merksatz: Dienstprotokoll = Schicht 7. Port = Schicht 4. --- **LDAP** LDAP steht für: Lightweight Directory Access Protocol LDAP dient dazu, Informationen aus einem Verzeichnisdienst abzufragen oder zu verwalten. Typische Informationen: - Benutzer - Gruppen - Computer - Organisationseinheiten - E-Mail-Adressen - Telefonnummern - Rollen - Berechtigungsbezüge Merksatz: LDAP = Zugriff auf Verzeichnisdienste. --- **Was ist ein Verzeichnisdienst?** Ein Verzeichnisdienst speichert strukturierte Informationen über Objekte in einer Organisation. Beispiele für Objekte: - Benutzerkonto - Gruppe - Computer - Drucker - Dienstkonto - Kontakt - Organisationseinheit Der Verzeichnisdienst ermöglicht zentrale Verwaltung. Merksatz: Verzeichnisdienst = zentrale Datenbank für Identitäten und Objekte. --- **Typische Verzeichnisdienste** Typische Verzeichnisdienste sind: - Microsoft Active Directory - OpenLDAP - FreeIPA - Samba AD - cloudbasierte Identitätsdienste mit LDAP-Anbindung Besonders wichtig im FISI-Umfeld ist: Active Directory Merksatz: Active Directory ist ein sehr verbreiteter Verzeichnisdienst. --- **LDAP und Active Directory** Active Directory nutzt LDAP für viele Abfragen. Beispiele: Benutzer anmelden Gruppenmitgliedschaften prüfen Benutzerobjekte suchen Computerobjekte verwalten Verzeichnisinformationen abfragen Wichtig: Active Directory besteht nicht nur aus LDAP. Es nutzt auch DNS, Kerberos, Gruppenrichtlinien und weitere Dienste. Merksatz: LDAP ist ein wichtiger Teil von Active Directory, aber nicht das ganze Active Directory. --- **LDAP-Ports** Wichtige LDAP-Ports: | Dienst | Protokoll | Port | |---|---|---:| | LDAP | TCP / UDP | 389 | | LDAPS | TCP | 636 | LDAP über Port 389 kann zusätzlich mit STARTTLS abgesichert werden. LDAPS nutzt direkt TLS. Merksatz: LDAP = 389. LDAPS = 636. --- **LDAP und LDAPS unterscheiden** | Begriff | Bedeutung | |---|---| | LDAP | Verzeichniszugriff, klassisch Port 389 | | LDAPS | LDAP über TLS, klassisch Port 636 | | LDAP mit STARTTLS | startet auf 389 und schaltet auf TLS um | Wichtig: Für Anmeldedaten und sensible Informationen sollte verschlüsselte Kommunikation genutzt werden. Merksatz: LDAPS schützt LDAP-Kommunikation mit TLS. --- **LDAP-Baumstruktur** LDAP-Daten sind hierarchisch organisiert. Man kann sich das wie einen Baum vorstellen. Beispiel: Firma ├── Benutzer ├── Gruppen ├── Computer └── Drucker Jedes Objekt hat eine Position im Verzeichnisbaum. Merksatz: LDAP ist hierarchisch aufgebaut. --- **Distinguished Name** Ein Distinguished Name beschreibt die eindeutige Position eines Objekts im LDAP-Verzeichnis. Kurz: DN Beispiel: CN=Felix Ulrich,OU=Benutzer,DC=firma,DC=local Bedeutung: CN = Common Name OU = Organizational Unit DC = Domain Component Merksatz: DN = eindeutiger LDAP-Pfad eines Objekts. --- **Common Name** CN steht für: Common Name CN bezeichnet häufig den Namen eines Objekts. Beispiel: CN=Felix Ulrich Merksatz: CN = Name eines LDAP-Objekts. --- **Organizational Unit** OU steht für: Organizational Unit Eine OU ist eine Organisationseinheit. Beispiel: OU=Benutzer OU=Computer OU=Berlin OU=Ausbildung OUs helfen, Objekte zu strukturieren und zu verwalten. Merksatz: OU = Organisationseinheit im Verzeichnis. --- **Domain Component** DC steht für: Domain Component DC bildet Teile des Domänennamens ab. Beispiel: firma.local wird zu: DC=firma,DC=local Merksatz: DC bildet den Domänennamen im LDAP-Pfad ab. --- **LDAP-Attribute** LDAP-Objekte haben Attribute. Beispiele für Benutzerattribute: - cn - givenName - sn - mail - telephoneNumber - memberOf - userPrincipalName - sAMAccountName Diese Attribute beschreiben das Objekt genauer. Merksatz: LDAP-Attribute speichern Eigenschaften eines Objekts. --- **LDAP-Suche** Eine LDAP-Suche fragt Objekte aus dem Verzeichnis ab. Typische Suchfragen: Gibt es diesen Benutzer? Welche Gruppen hat der Benutzer? Welche E-Mail-Adresse hat der Benutzer? Welche Computer gehören zu einer OU? Welche Benutzer sind deaktiviert? Merksatz: LDAP-Suche findet Objekte und Attribute im Verzeichnis. --- **LDAP-Filter** LDAP-Filter grenzen Suchergebnisse ein. Beispiel sinngemäß: Suche Benutzer mit bestimmtem Namen. Oder: Suche alle Benutzer in einer bestimmten Gruppe. Filter sind wichtig, damit Abfragen gezielt und effizient sind. Merksatz: LDAP-Filter bestimmen, welche Objekte gesucht werden. --- **Bind** Bind bedeutet bei LDAP: Anmeldung oder Authentifizierung am Verzeichnisdienst. Ein Client verbindet sich mit dem LDAP-Server und authentifiziert sich. Mögliche Varianten: - anonym - Benutzername und Passwort - Dienstkonto - Kerberos in AD-Umgebungen Merksatz: LDAP Bind = Anmeldung am Verzeichnisdienst. --- **LDAP und Authentifizierung** Viele Anwendungen nutzen LDAP, um Benutzer gegen ein zentrales Verzeichnis zu prüfen. Beispiel: Benutzer meldet sich an Anwendung an. Anwendung prüft Benutzer über LDAP. LDAP bestätigt oder lehnt ab. Anwendung prüft zusätzlich Gruppen oder Rollen. Merksatz: LDAP kann zentrale Anmeldung und Gruppenprüfung unterstützen. --- **LDAP und Autorisierung** LDAP kann Gruppeninformationen liefern. Beispiel: Benutzer ist Mitglied der Gruppe: IT-Admins Eine Anwendung kann daraus ableiten: Benutzer darf Adminbereich öffnen. Wichtig: LDAP liefert Informationen. Die Anwendung entscheidet oft, welche Rechte daraus entstehen. Merksatz: LDAP liefert Identitäts- und Gruppeninformationen. --- **Typische LDAP-Fehler** Typische Fehler sind: - falscher LDAP-Server - falscher Port - DNS-Name nicht auflösbar - falscher Bind-Benutzer - falsches Passwort - Benutzer nicht gefunden - falscher Base-DN - falscher Suchfilter - TLS-Zertifikatsfehler bei LDAPS - Firewall blockiert Port 389 oder 636 Merksatz: LDAP-Fehler betreffen oft Server, Port, Bind, Base-DN oder Zertifikat. --- **Fehlerbild: Anmeldung über LDAP funktioniert nicht** Mögliche Ursachen: - Benutzername falsch - Passwort falsch - Benutzerkonto gesperrt - LDAP-Server nicht erreichbar - falscher LDAP-Port - falscher Base-DN - falscher Suchfilter - Gruppe fehlt - LDAPS-Zertifikat ungültig - Anwendung nutzt falsches Dienstkonto Merksatz: LDAP-Anmeldefehler mit Konto, Server, Suche und Gruppen prüfen. --- **SNMP** SNMP steht für: Simple Network Management Protocol SNMP wird zur Überwachung und Verwaltung von Netzwerkgeräten genutzt. Typische Geräte: - Switches - Router - Firewalls - Drucker - Server - USV-Anlagen - Access Points - NAS-Systeme Merksatz: SNMP = Netzwerkgeräte überwachen und verwalten. --- **Was kann man mit SNMP abfragen?** Mit SNMP kann man viele Geräteinformationen abfragen. Beispiele: - Gerätename - Uptime - CPU-Auslastung - RAM-Auslastung - Interface-Status - Traffic pro Port - Fehlerzähler - Temperatur - Tonerstand - Lüfterstatus - Seriennummer Merksatz: SNMP liefert Messwerte und Zustandsinformationen. --- **SNMP-Manager und SNMP-Agent** Bei SNMP gibt es meist: SNMP-Manager SNMP-Agent SNMP-Manager: Monitoring-System, das Werte abfragt. SNMP-Agent: Dienst auf dem überwachten Gerät, der Informationen bereitstellt. Beispiel: Monitoring-Server fragt Switch ab. Switch-Agent liefert Interface-Daten. Merksatz: Manager fragt. Agent antwortet. --- **SNMP-Ports** Wichtige SNMP-Ports: | Funktion | Protokoll | Port | |---|---|---:| | SNMP-Abfragen | UDP | 161 | | SNMP-Traps | UDP | 162 | Merksatz: SNMP-Abfrage = UDP 161. SNMP-Trap = UDP 162. --- **SNMP-Abfrage** Bei einer SNMP-Abfrage fragt der Manager gezielt einen Wert ab. Beispiel: Wie hoch ist die CPU-Auslastung? Ist Port 5 am Switch aktiv? Wie viele Fehler gab es auf Interface 1? Der Agent antwortet mit dem passenden Wert. Merksatz: SNMP-Abfrage = Manager fragt Gerät nach Wert. --- **SNMP-Trap** Ein SNMP-Trap ist eine Meldung, die ein Gerät von sich aus an den Manager sendet. Beispiele: Link down Lüfter ausgefallen Temperatur zu hoch USV läuft auf Batterie Gerät startet neu Merksatz: Trap = Gerät meldet Ereignis selbstständig. --- **MIB** MIB steht für: Management Information Base Die MIB beschreibt, welche Informationen ein Gerät per SNMP bereitstellt. Sie enthält eine strukturierte Sammlung von verwaltbaren Objekten. Merksatz: MIB beschreibt verfügbare SNMP-Informationen. --- **OID** OID steht für: Object Identifier Eine OID ist eine eindeutige Nummer für einen bestimmten SNMP-Wert. Beispiel sinngemäß: OID für Gerätenamen OID für Interface-Traffic OID für CPU-Auslastung Merksatz: OID = eindeutige Kennung eines SNMP-Werts. --- **SNMP-Versionen** Wichtige SNMP-Versionen: | Version | Kurzinfo | |---|---| | SNMPv1 | alt, einfach | | SNMPv2c | verbreitet, Community-String | | SNMPv3 | sicherer mit Authentifizierung und Verschlüsselung | Für moderne Umgebungen ist SNMPv3 vorzuziehen. Merksatz: SNMPv3 ist sicherer als SNMPv1/v2c. --- **Community-String** Bei SNMPv1 und SNMPv2c wird ein Community-String verwendet. Er wirkt wie ein einfaches Passwort. Beispiele: public private Problem: Community-Strings werden bei alten SNMP-Versionen nicht sicher geschützt. Merksatz: Community-String ist kein starker Schutz. --- **SNMPv3** SNMPv3 bietet bessere Sicherheitsfunktionen. Dazu gehören: - Authentifizierung - Verschlüsselung - Benutzerkonzept - Integritätsschutz Damit ist SNMPv3 deutlich sicherer als ältere Varianten. Merksatz: SNMPv3 für sichere Überwachung bevorzugen. --- **SNMP und Monitoring** Monitoring-Systeme nutzen SNMP, um Geräte regelmäßig abzufragen. Beispiele für Monitoring: - Ist Gerät erreichbar? - Ist ein Port down? - Wie hoch ist die Auslastung? - Gibt es Fehler auf Interfaces? - Wird Speicher knapp? - Gibt es Temperaturprobleme? Merksatz: SNMP ist wichtig für Netzwerkmonitoring. --- **Typische SNMP-Fehler** Typische Fehler sind: - SNMP-Agent deaktiviert - falsche SNMP-Version - falscher Community-String - falsche SNMPv3-Zugangsdaten - Firewall blockiert UDP 161 oder 162 - Monitoring-Server nicht erlaubt - Gerät unterstützt OID nicht - MIB fehlt im Monitoring-System - ACL auf Gerät blockiert Zugriff Merksatz: SNMP-Fehler betreffen oft Version, Zugangsdaten, Firewall oder OID. --- **Fehlerbild: Monitoring zeigt Gerät als down** Mögliche Ursachen: - Gerät wirklich offline - IP-Adresse falsch - DNS falsch - ICMP blockiert - SNMP-Agent aus - Firewall blockiert - falsche SNMP-Zugangsdaten - falsche SNMP-Version - Monitoring fragt falsche Schnittstelle Merksatz: Monitoring-Fehler erst mit Erreichbarkeit und SNMP prüfen. --- **NTP** NTP steht für: Network Time Protocol NTP dient zur Zeitsynchronisation von Systemen. Typischer Port: UDP 123 Korrekte Zeit ist in IT-Systemen sehr wichtig. Merksatz: NTP = Zeitsynchronisation über Netzwerk. --- **Warum ist korrekte Zeit wichtig?** Korrekte Zeit wird benötigt für: - Zertifikate - Kerberos - Active Directory - Logs - Fehlersuche - Backup-Zeitpunkte - Monitoring - Dateisynchronisation - Datenbanktransaktionen - Sicherheitsereignisse Schon wenige Minuten Abweichung können Probleme verursachen. Merksatz: Falsche Uhrzeit kann viele IT-Probleme verursachen. --- **NTP-Client und NTP-Server** Bei NTP gibt es: NTP-Client NTP-Server NTP-Client: fragt Zeit ab. NTP-Server: liefert Zeitinformationen. In Unternehmen synchronisieren Clients oft gegen interne Zeitserver. Merksatz: NTP-Client fragt Zeit vom NTP-Server ab. --- **NTP-Stratum** NTP nutzt sogenannte Stratum-Werte. Sie beschreiben die Entfernung zur ursprünglichen Zeitquelle. Beispiel: Stratum 0: direkte Zeitquelle, zum Beispiel Atomuhr oder GPS Stratum 1: Server direkt an Stratum-0-Quelle Stratum 2: Server synchronisiert von Stratum 1 Je kleiner der Stratum-Wert, desto näher an der ursprünglichen Zeitquelle. Merksatz: Stratum beschreibt die Nähe zur Zeitquelle. --- **NTP und Active Directory** In Active-Directory-Umgebungen ist Zeit besonders wichtig. Grund: Kerberos ist empfindlich gegenüber Zeitabweichungen. Wenn Client und Domänencontroller zu stark unterschiedliche Zeiten haben, kann Anmeldung fehlschlagen. Merksatz: AD und Kerberos brauchen korrekte Zeit. --- **NTP und Zertifikate** Zertifikate haben Gültigkeitszeiträume. Wenn die Systemzeit falsch ist, kann ein eigentlich gültiges Zertifikat als ungültig erscheinen. Beispiel: Client-Uhr geht ein Jahr falsch. Browser meldet Zertifikatsfehler. Merksatz: Falsche Uhrzeit kann Zertifikatswarnungen verursachen. --- **NTP und Logs** Logs sind nur sinnvoll, wenn Zeitstempel stimmen. Bei Fehlersuche muss man Ereignisse zeitlich zusammenbringen können. Beispiele: Firewall-Log Server-Log Anwendungslog Authentifizierungslog Wenn Systeme unterschiedliche Uhrzeiten haben, wird die Analyse erschwert. Merksatz: Ohne korrekte Zeit sind Logs schwer auswertbar. --- **NTP und Sicherheit** NTP sollte sicher und sinnvoll konfiguriert werden. Wichtige Punkte: - vertrauenswürdige Zeitquellen nutzen - interne Zeitserver verwenden - keine unnötig offenen NTP-Server betreiben - Firewall-Regeln kontrollieren - Zeitabweichungen überwachen - Manipulation vermeiden Merksatz: Zeit ist sicherheitsrelevant. --- **Typische NTP-Fehler** Typische Fehler sind: - NTP-Server nicht erreichbar - UDP 123 blockiert - falscher Zeitserver eingetragen - große Zeitabweichung - falsche Zeitzone - Systemzeit driftet - virtuelle Maschinen synchronisieren falsch - mehrere Zeitquellen widersprechen sich - DNS-Name des Zeitservers nicht auflösbar Merksatz: NTP-Fehler betreffen Zeitserver, UDP 123, DNS oder Systemkonfiguration. --- **Fehlerbild: Zertifikate wirken ungültig** Mögliche Ursache: Systemzeit ist falsch. Prüfung: Datum prüfen. Uhrzeit prüfen. Zeitzone prüfen. NTP-Status prüfen. Zeitquelle prüfen. Merksatz: Bei vielen Zertifikatsfehlern auch Uhrzeit prüfen. --- **Fehlerbild: Anmeldung an Domäne schlägt fehl** Mögliche Ursache: Zeitabweichung zwischen Client und Domänencontroller. Besonders relevant: Kerberos Prüfung: Clientzeit prüfen. Domänencontrollerzeit prüfen. NTP-Konfiguration prüfen. Zeitzone prüfen. Merksatz: Domänenanmeldung braucht passende Zeit. --- **Fehlerbild: Logs passen zeitlich nicht zusammen** Mögliche Ursachen: - falsche Systemzeit - falsche Zeitzone - NTP gestört - Zeitquelle falsch - Sommerzeitproblem - Container oder VM nutzt falsche Zeitbasis Merksatz: Log-Auswertung braucht synchronisierte Zeit. --- **LDAP, SNMP und NTP vergleichen** | Protokoll | Hauptaufgabe | typischer Port | |---|---|---:| | LDAP | Verzeichnisdienstzugriff | TCP/UDP 389 | | LDAPS | LDAP über TLS | TCP 636 | | SNMP | Netzwerkmanagement | UDP 161 | | SNMP-Trap | Ereignismeldung | UDP 162 | | NTP | Zeitsynchronisation | UDP 123 | Merksatz: LDAP 389/636, SNMP 161/162, NTP 123. --- **Sicherheitsvergleich** | Protokoll | Sicherheitsaspekt | |---|---| | LDAP | Anmeldedaten schützen, LDAPS oder STARTTLS nutzen | | SNMP | SNMPv3 bevorzugen, Community-Strings schützen | | NTP | vertrauenswürdige Zeitquellen und Zugriffsbeschränkung | | LDAPS | Zertifikate korrekt prüfen | | SNMPv1/v2c | möglichst vermeiden oder stark einschränken | Merksatz: Infrastrukturprotokolle müssen ebenfalls abgesichert werden. --- **Fehlersuche allgemein** Eine sinnvolle Reihenfolge: 1. Namensauflösung prüfen. 2. IP-Erreichbarkeit prüfen. 3. Port prüfen. 4. Dienst läuft? 5. Zugangsdaten korrekt? 6. Verschlüsselung oder Zertifikat korrekt? 7. Berechtigungen korrekt? 8. Logs prüfen. Merksatz: Auch Verwaltungsdienste nach Schichten prüfen. --- **Was LDAP, SNMP und NTP nicht machen** LDAP macht nicht automatisch: Berechtigungen in jeder Anwendung korrekt. SNMP macht nicht automatisch: Fehlerbehebung, sondern liefert Informationen. NTP macht nicht automatisch: Zeitzonenlogik oder Zertifikatsverwaltung korrekt. Alle drei Dienste brauchen korrekte Konfiguration und passende Sicherheit. Merksatz: Infrastrukturprotokolle unterstützen Administration, ersetzen aber keine saubere Konfiguration. --- **Einordnung in typische Unternehmensnetze** In Unternehmen sieht man häufig: LDAP / AD: zentrale Benutzer und Gruppen SNMP: Monitoring von Switches, Routern und Servern NTP: einheitliche Zeit für Clients, Server und Logs Diese Dienste sind nicht immer sichtbar für Benutzer, aber wichtig für stabilen Betrieb. Merksatz: LDAP, SNMP und NTP sind Grundlagen für Betrieb und Verwaltung. --- **Typische IHK-Fragen** In AP1 und AP2 kann zum Beispiel gefragt werden: - Wofür steht LDAP? - Wofür wird LDAP verwendet? - Was ist ein Verzeichnisdienst? - Was ist LDAPS? - Welche Ports nutzen LDAP und LDAPS? - Was ist ein Distinguished Name? - Was ist ein LDAP Bind? - Wofür steht SNMP? - Wofür wird SNMP verwendet? - Was sind SNMP-Manager und SNMP-Agent? - Was ist ein SNMP-Trap? - Welche Ports nutzt SNMP? - Warum ist SNMPv3 sicherer? - Wofür steht NTP? - Warum ist korrekte Zeit wichtig? - Welche Probleme können durch falsche Uhrzeit entstehen? --- **Typische Prüfungsfallen** LDAP gehört zu Schicht 7. LDAP ist nicht das gesamte Active Directory. LDAP nutzt typischerweise Port 389. LDAPS nutzt typischerweise Port 636. DN ist der eindeutige LDAP-Pfad. Bind bedeutet LDAP-Anmeldung. SNMP gehört zu Schicht 7. SNMP nutzt UDP. SNMP-Abfragen nutzen UDP 161. SNMP-Traps nutzen UDP 162. SNMPv1/v2c mit Community-String sind unsicherer. SNMPv3 ist sicherer. NTP gehört zu Schicht 7. NTP nutzt UDP 123. Falsche Zeit kann Zertifikatsfehler verursachen. Falsche Zeit kann Kerberos-Probleme verursachen. Logs brauchen synchronisierte Zeit. --- **Wichtige Begriffe kurz erklärt** | Begriff | Kurze Erklärung | |---|---| | LDAP | Protokoll für Verzeichnisdienste | | LDAPS | LDAP über TLS | | Verzeichnisdienst | zentrale Verwaltung von Identitäten und Objekten | | Active Directory | verbreiteter Microsoft-Verzeichnisdienst | | DN | eindeutiger LDAP-Pfad | | CN | Common Name eines Objekts | | OU | Organisationseinheit | | DC | Domain Component | | Attribut | Eigenschaft eines LDAP-Objekts | | Bind | Anmeldung am LDAP-Server | | SNMP | Protokoll für Netzwerkmanagement | | SNMP-Manager | fragt Gerätewerte ab | | SNMP-Agent | liefert Gerätewerte | | Trap | Gerät sendet Ereignis selbstständig | | MIB | Beschreibung verfügbarer SNMP-Werte | | OID | eindeutige Kennung eines SNMP-Werts | | Community-String | einfacher Zugriffstext bei SNMPv1/v2c | | SNMPv3 | sicherere SNMP-Version | | NTP | Protokoll zur Zeitsynchronisation | | Stratum | Nähe zur Zeitquelle | | Zeitserver | Server, der Uhrzeit bereitstellt | --- **IHK-sichere Kurzformulierung** LDAP, SNMP und NTP sind Protokolle der Anwendungsschicht. LDAP steht für Lightweight Directory Access Protocol und dient dem Zugriff auf Verzeichnisdienste wie Active Directory. Es wird zum Suchen und Verwalten von Benutzern, Gruppen und anderen Objekten verwendet. SNMP steht für Simple Network Management Protocol und wird zur Überwachung von Netzwerkgeräten genutzt. Dabei fragt ein SNMP-Manager Werte von einem SNMP-Agenten ab oder empfängt Traps. NTP steht für Network Time Protocol und synchronisiert die Uhrzeit von Systemen. Korrekte Zeit ist wichtig für Zertifikate, Kerberos, Logs und Fehlersuche. --- **Merksätze** LDAP = Lightweight Directory Access Protocol. LDAP gehört zu Schicht 7. LDAP greift auf Verzeichnisdienste zu. Active Directory nutzt LDAP, ist aber mehr als LDAP. LDAP = Port 389. LDAPS = Port 636. DN = eindeutiger LDAP-Pfad. Bind = Anmeldung am LDAP-Server. SNMP = Simple Network Management Protocol. SNMP gehört zu Schicht 7. SNMP überwacht Netzwerkgeräte. SNMP-Manager fragt. SNMP-Agent antwortet. SNMP-Abfrage = UDP 161. SNMP-Trap = UDP 162. MIB beschreibt verfügbare Werte. OID kennzeichnet einen SNMP-Wert. SNMPv3 ist sicherer als SNMPv1/v2c. NTP = Network Time Protocol. NTP gehört zu Schicht 7. NTP nutzt UDP 123. NTP synchronisiert Uhrzeit. Korrekte Zeit ist wichtig für Zertifikate. Korrekte Zeit ist wichtig für Kerberos. Korrekte Zeit ist wichtig für Logs. Infrastrukturprotokolle müssen ebenfalls abgesichert werden. # 10.8 Remotezugriff und Fernadministration: SSH, RDP und Telnet Remotezugriff gehört zur OSI-Schicht 7. Remotezugriff bedeutet: Ein Benutzer oder Administrator greift aus der Ferne auf ein anderes System zu. Typische Protokolle sind: - SSH - RDP - Telnet Sie dienen dazu, entfernte Systeme zu bedienen, zu verwalten oder zu konfigurieren. Merksatz: Remotezugriff = entfernte Systeme über das Netzwerk bedienen. --- **Grundidee von Remotezugriff** Bei Remotezugriff sitzt der Benutzer nicht direkt vor dem Zielsystem. Stattdessen erfolgt der Zugriff über das Netzwerk. Beispiele: Administrator verbindet sich per SSH auf einen Linux-Server. Benutzer verbindet sich per RDP auf einen Windows-Rechner. Techniker greift auf eine Firewall-Konsole zu. Support meldet sich auf einem Terminalserver an. Ein Server wird aus der Ferne konfiguriert. Merksatz: Remotezugriff ermöglicht Administration ohne direkten physischen Zugriff. --- **Remotezugriff im OSI-Modell** Remotezugriffsprotokolle gehören zur Anwendungsschicht. | Thema | Schicht | |---|---:| | SSH | 7 | | RDP | 7 | | Telnet | 7 | | TCP-Port | 4 | | IP-Adresse | 3 | | Verschlüsselung | 6 / Sicherheitsbezug | | Benutzeranmeldung | 7 / Authentifizierung | Wichtig: SSH, RDP und Telnet sind Anwendungsschicht-Protokolle. Die verwendeten Ports gehören zur Transportschicht. Merksatz: Protokoll = Schicht 7. Port = Schicht 4. --- **SSH** SSH steht für: Secure Shell SSH wird für sicheren Fernzugriff auf Kommandozeilen verwendet. Typischer Port: TCP 22 SSH wird häufig genutzt bei: - Linux-Servern - Netzwerkgeräten - Firewalls - NAS-Systemen - Routern - Switches - Automatisierung - Dateiübertragung über SFTP Merksatz: SSH = sicherer Fernzugriff auf die Shell. --- **Warum ist SSH wichtig?** SSH ermöglicht sichere Administration über ein Netzwerk. SSH bietet: - verschlüsselte Verbindung - Authentifizierung - Integritätsschutz - sichere Befehlsausführung - sichere Dateiübertragung über SFTP - Portweiterleitungen und Tunnel Im Gegensatz zu Telnet überträgt SSH Daten nicht einfach im Klartext. Merksatz: SSH schützt Fernadministration durch Verschlüsselung. --- **SSH-Verbindung vereinfacht** Ablauf vereinfacht: 1. Client verbindet sich mit Server auf TCP 22. 2. Server präsentiert seinen Host-Key. 3. Client prüft den Host-Key. 4. Verschlüsselung wird ausgehandelt. 5. Benutzer authentifiziert sich. 6. Shell oder Dienst wird bereitgestellt. Merksatz: SSH prüft Server, verschlüsselt Verbindung und authentifiziert Benutzer. --- **SSH-Client und SSH-Server** SSH-Client: Programm, das die Verbindung startet. SSH-Server: Dienst auf dem Zielsystem, der SSH-Verbindungen annimmt. Beispiele: Client: Terminal, PuTTY, OpenSSH-Client Server: OpenSSH-Server auf Linux, SSH-Dienst auf Netzwerkgerät Merksatz: SSH-Client verbindet sich zum SSH-Server. --- **SSH-Host-Key** Der SSH-Host-Key identifiziert den SSH-Server. Beim ersten Verbindungsaufbau speichert der Client häufig den Host-Key. Bei späteren Verbindungen prüft der Client: Ist es derselbe Server wie vorher? Wenn sich der Host-Key plötzlich ändert, erscheint eine Warnung. Mögliche Ursachen: - Server wurde neu installiert - Host-Key wurde geändert - DNS zeigt auf anderen Server - IP-Adresse wurde neu vergeben - möglicher Man-in-the-Middle-Angriff Merksatz: SSH-Host-Key schützt vor unbemerktem Serverwechsel. --- **SSH-Authentifizierung mit Passwort** Bei Passwortauthentifizierung meldet sich der Benutzer mit Benutzername und Passwort an. Vorteil: einfach einzurichten Nachteile: - anfällig gegen schwache Passwörter - Brute-Force-Angriffe möglich - Passwort kann bei schlechter Verwaltung kompromittiert werden Merksatz: Passwortlogin ist einfach, aber stärker abzusichern. --- **SSH-Authentifizierung mit Schlüssel** Bei Schlüsselanmeldung wird ein Schlüsselpaar verwendet. Es besteht aus: privatem Schlüssel öffentlichem Schlüssel Der öffentliche Schlüssel liegt auf dem Server. Der private Schlüssel bleibt beim Benutzer. Wichtig: Der private Schlüssel darf nicht weitergegeben werden. Merksatz: SSH-Schlüssel bestehen aus öffentlichem und privatem Schlüssel. --- **Vorteile von SSH-Schlüsseln** SSH-Schlüssel haben mehrere Vorteile: - keine Passwortübertragung - gut für Automatisierung - stärker als einfache Passwörter - Zugriff kann pro Schlüssel verwaltet werden - private Schlüssel können zusätzlich mit Passphrase geschützt werden Merksatz: SSH-Schlüssel sind für sichere Administration sehr wichtig. --- **SSH-Passphrase** Eine Passphrase schützt den privaten SSH-Schlüssel. Wenn jemand die Schlüsseldatei kopiert, kann er sie ohne Passphrase nicht sofort verwenden. Merksatz: Passphrase schützt den privaten Schlüssel zusätzlich. --- **SSH-Agent** Ein SSH-Agent kann private Schlüssel temporär im Speicher verwalten. Vorteil: Benutzer muss die Passphrase nicht bei jeder Verbindung neu eingeben. Wichtig: SSH-Agent-Weiterleitung muss vorsichtig verwendet werden, weil sie Sicherheitsrisiken erzeugen kann. Merksatz: SSH-Agent erleichtert Schlüsselanmeldung, muss aber sicher genutzt werden. --- **Root-Login über SSH** Direkter Root-Login über SSH sollte in vielen Umgebungen deaktiviert werden. Besser: normaler Benutzer meldet sich an und nutzt bei Bedarf sudo oder administrative Rechte. Vorteile: - bessere Nachvollziehbarkeit - weniger Risiko bei Brute-Force-Angriffen - gezieltere Rechtevergabe Merksatz: Direktes Root-Login möglichst vermeiden. --- **SSH und SFTP** SFTP steht für: SSH File Transfer Protocol SFTP nutzt SSH als Grundlage. Typischer Port: TCP 22 SFTP ist nicht FTP mit Verschlüsselung, sondern ein eigenes Dateiübertragungsprotokoll über SSH. Merksatz: SFTP läuft über SSH. --- **SSH-Tunnel** Mit SSH können Tunnel aufgebaut werden. Ein SSH-Tunnel leitet Netzwerkverkehr sicher durch eine SSH-Verbindung. Typische Nutzung: - internen Dienst sicher erreichen - temporäre Portweiterleitung - Administration über abgesicherte Verbindung - Zugriff auf Datenbank oder Webdienst über SSH Merksatz: SSH-Tunnel leitet Verkehr verschlüsselt weiter. --- **SSH-Portforwarding** SSH-Portforwarding bedeutet: Ein lokaler oder entfernter Port wird über SSH weitergeleitet. Beispiel sinngemäß: lokaler Port 8080 → durch SSH → interner Webdienst auf Server Das kann nützlich sein, muss aber kontrolliert werden, weil dadurch Sicherheitsgrenzen umgangen werden können. Merksatz: SSH-Portforwarding kann hilfreich, aber sicherheitskritisch sein. --- **SSH-Sicherheitsmaßnahmen** Wichtige Maßnahmen: - starke Passwörter oder Schlüssel verwenden - Root-Login deaktivieren - Passwortlogin nach Möglichkeit einschränken - nur notwendige Benutzer erlauben - Firewall-Regeln setzen - Zugriff per VPN begrenzen - Fail2ban oder ähnliche Schutzmechanismen nutzen - Logs prüfen - alte Schlüssel entfernen - Schlüssel mit Passphrase schützen Merksatz: SSH muss trotz Verschlüsselung sauber abgesichert werden. --- **Typische SSH-Fehler** Typische Fehler sind: - TCP 22 blockiert - SSH-Dienst läuft nicht - falscher Hostname - falsche IP-Adresse - falscher Benutzername - falsches Passwort - falscher privater Schlüssel - Rechte auf Schlüsseldatei falsch - Benutzer nicht erlaubt - Host-Key-Warnung - Firewall blockiert Zugriff Merksatz: SSH-Fehler mit Port, Dienst, Benutzer, Schlüssel und Firewall prüfen. --- **Fehlerbild: SSH-Verbindung Timeout** Mögliche Ursachen: - Zielhost nicht erreichbar - TCP 22 durch Firewall blockiert - Routingproblem - falsche IP-Adresse - SSH-Dienst lauscht auf anderem Port - NAT oder Portweiterleitung falsch - Server offline Merksatz: SSH-Timeout deutet oft auf Netzwerk, Firewall oder falschen Port hin. --- **Fehlerbild: SSH Connection Refused** Connection refused bedeutet: Zielsystem ist erreichbar, aber der Dienst auf dem Zielport nimmt keine Verbindung an. Mögliche Ursachen: - SSH-Dienst läuft nicht - SSH lauscht nicht auf diesem Port - Port falsch - Dienst nur auf bestimmter IP gebunden - lokale Firewall lehnt aktiv ab Merksatz: Connection refused heißt: Host erreichbar, Dienst nimmt nicht an. --- **Fehlerbild: SSH Permission Denied** Permission denied bedeutet: Anmeldung wurde abgelehnt. Mögliche Ursachen: - falscher Benutzer - falsches Passwort - falscher Schlüssel - öffentlicher Schlüssel fehlt auf Server - Benutzer darf sich nicht anmelden - Konto gesperrt - Schlüsselrechte falsch - Loginmethode deaktiviert Merksatz: Permission denied = Authentifizierung oder Berechtigung prüfen. --- **Fehlerbild: SSH Host-Key-Warnung** Eine Host-Key-Warnung bedeutet: Der Server-Schlüssel passt nicht zu dem, was der Client gespeichert hat. Mögliche Ursachen: - Server neu installiert - anderer Server unter gleicher IP - DNS zeigt auf anderes Ziel - Load Balancer oder Proxy - möglicher Angriff Wichtig: Warnung nicht blind ignorieren. Merksatz: Host-Key-Warnung immer prüfen. --- **RDP** RDP steht für: Remote Desktop Protocol RDP wird für grafischen Fernzugriff verwendet. Typischer Port: TCP 3389 RDP ist besonders verbreitet bei Windows-Systemen. Typische Nutzung: - Windows-Server administrieren - Terminalserver nutzen - Remote-Arbeitsplatz - grafische Programme aus der Ferne bedienen Merksatz: RDP = grafischer Fernzugriff. --- **RDP-Grundidee** Bei RDP wird eine grafische Sitzung über das Netzwerk übertragen. Der Benutzer sieht: Desktop Fenster Programme Mauszeiger Tastatureingaben Die Anwendung läuft auf dem entfernten System. Der Benutzer bedient sie aus der Ferne. Merksatz: RDP überträgt eine entfernte Benutzeroberfläche. --- **RDP-Client und RDP-Server** RDP-Client: startet die Verbindung RDP-Server: nimmt Remote-Desktop-Verbindungen an Beispiel: Benutzer startet Remote Desktop Client. Client verbindet sich zu Windows-Server. Server zeigt grafische Sitzung. Merksatz: RDP-Client verbindet sich zum RDP-Server. --- **RDP und Benutzeranmeldung** Für RDP wird normalerweise ein Benutzerkonto benötigt. Dabei können relevant sein: - Benutzername - Passwort - Domänenkonto - lokale Benutzergruppe - Remote-Desktop-Berechtigung - Multi-Faktor-Authentifizierung - Richtlinien Nicht jeder Benutzer darf sich automatisch per RDP anmelden. Merksatz: RDP braucht Anmeldung und passende Berechtigung. --- **RDP und Sicherheit** RDP sollte besonders sorgfältig abgesichert werden. Warum? RDP ist ein beliebtes Ziel für Angriffe, besonders wenn es direkt aus dem Internet erreichbar ist. Risiken: - Brute-Force-Angriffe - gestohlene Zugangsdaten - ungepatchte Schwachstellen - Ransomware-Angriffe - unberechtigter Zugriff Merksatz: RDP niemals leichtfertig ins Internet öffnen. --- **RDP sicher betreiben** Sinnvolle Maßnahmen: - Zugriff nur über VPN - Remote Desktop Gateway nutzen - starke Passwörter - Multi-Faktor-Authentifizierung - Network Level Authentication aktivieren - Firewall-Regeln einschränken - nur notwendige Benutzer erlauben - Logs überwachen - Systeme aktuell halten - Kontosperrungsrichtlinien nutzen Merksatz: RDP nur geschützt und kontrolliert bereitstellen. --- **Network Level Authentication** Network Level Authentication wird kurz genannt: NLA NLA verlangt, dass sich der Benutzer bereits vor dem vollständigen Aufbau der grafischen Sitzung authentifiziert. Vorteil: weniger Angriffsfläche bessere Absicherung vor unerwünschten Sitzungsaufbauten Merksatz: NLA verbessert die Sicherheit bei RDP. --- **Remote Desktop Gateway** Ein Remote Desktop Gateway stellt RDP nicht direkt offen bereit, sondern vermittelt den Zugriff über einen Gateway-Dienst. Vorteile: - zentraler Zugriffspunkt - bessere Kontrolle - Authentifizierung - Protokollierung - Zugriff über HTTPS möglich - weniger direkte RDP-Exposition Merksatz: RD Gateway schützt und bündelt RDP-Zugriffe. --- **RDP und VPN** Ein VPN kann verwendet werden, damit RDP nur intern erreichbar ist. Ablauf: Benutzer baut VPN auf. Benutzer greift per RDP auf internes System zu. Vorteil: RDP-Port muss nicht direkt öffentlich erreichbar sein. Merksatz: RDP besser über VPN als direkt aus dem Internet. --- **Typische RDP-Fehler** Typische Fehler sind: - TCP 3389 blockiert - Remote Desktop deaktiviert - Benutzer nicht berechtigt - falsches Passwort - Konto gesperrt - NLA-Problem - Lizenzproblem bei Terminalserver - Firewall blockiert - DNS-Name falsch - Zielsystem ausgeschaltet - maximale Sitzungsanzahl erreicht Merksatz: RDP-Fehler mit Erreichbarkeit, Dienst, Anmeldung und Berechtigung prüfen. --- **Fehlerbild: RDP verbindet nicht** Mögliche Ursachen: - Zielsystem offline - falscher Hostname - DNS falsch - TCP 3389 blockiert - Remote Desktop nicht aktiviert - Firewall blockiert - VPN nicht verbunden - NAT oder Portweiterleitung falsch Merksatz: RDP-Verbindungsfehler zuerst mit Netzwerk und Port prüfen. --- **Fehlerbild: RDP Anmeldung wird abgelehnt** Mögliche Ursachen: - Benutzername falsch - Passwort falsch - Benutzer nicht in erlaubter Gruppe - Konto gesperrt - Passwort abgelaufen - Anmeldung per RDP verboten - NLA-Kompatibilitätsproblem - Domänencontroller nicht erreichbar Merksatz: RDP-Anmeldefehler mit Konto und Berechtigung prüfen. --- **Fehlerbild: RDP ist langsam** Mögliche Ursachen: - geringe Bandbreite - hohe Latenz - Paketverlust - hohe Bildschirmauflösung - viele Grafikeffekte - Drucker- oder Laufwerksumleitung - Server überlastet - VPN langsam Merksatz: RDP-Leistung hängt von Netzwerk, Grafik und Serverlast ab. --- **Telnet** Telnet ist ein älteres Protokoll für Fernzugriff auf eine Kommandozeile. Typischer Port: TCP 23 Problem: Telnet ist unverschlüsselt. Das bedeutet: Benutzername, Passwort und Befehle können im Klartext übertragen werden. Merksatz: Telnet ist unsicher, weil es unverschlüsselt überträgt. --- **Warum Telnet heute vermeiden?** Telnet sollte für Administration möglichst nicht mehr verwendet werden. Gründe: - keine Verschlüsselung - Passwörter im Klartext - Befehle im Klartext - leicht mitzulesen - keine moderne Sicherheit - hohes Risiko in unsicheren Netzwerken Bessere Alternative: SSH Merksatz: Telnet durch SSH ersetzen. --- **Telnet als Testwerkzeug** Obwohl Telnet als Administrationsprotokoll unsicher ist, wurde es früher oft als einfaches Testwerkzeug verwendet. Beispiel: Kann ich TCP-Port 25 erreichen? Kann ich TCP-Port 80 erreichen? Heute nutzt man dafür besser geeignete Werkzeuge. Beispiele: - nc - Test-NetConnection - openssl s_client - curl Merksatz: Telnet nicht für sichere Administration verwenden. --- **SSH, RDP und Telnet vergleichen** | Protokoll | Zweck | Port | Sicherheit | |---|---|---:|---| | SSH | sichere Shell / Administration | TCP 22 | verschlüsselt | | RDP | grafischer Fernzugriff | TCP 3389 | absichern, nicht offen ins Internet | | Telnet | alte Shell / Fernzugriff | TCP 23 | unverschlüsselt, vermeiden | Merksatz: SSH für sichere Shell. RDP für grafischen Zugriff. Telnet vermeiden. --- **Remotezugriff und Authentifizierung** Remotezugriff braucht sichere Authentifizierung. Möglichkeiten: - Benutzername und Passwort - SSH-Schlüssel - Zertifikate - Multi-Faktor-Authentifizierung - Domänenkonto - zentrale Identitätsdienste Wichtig: Je mächtiger der Zugriff, desto stärker sollte die Absicherung sein. Merksatz: Fernzugriff braucht starke Authentifizierung. --- **Remotezugriff und Autorisierung** Nicht jeder angemeldete Benutzer darf automatisch alles. Autorisierung bedeutet: Welche Rechte hat der Benutzer? Beispiele: - darf sich per RDP anmelden - darf sudo verwenden - darf Server konfigurieren - darf Dateien ändern - darf Dienste neu starten Merksatz: Anmeldung ist nicht gleich Berechtigung. --- **Remotezugriff und Protokollierung** Remotezugriffe sollten protokolliert werden. Wichtige Informationen: - wer hat sich angemeldet - wann wurde zugegriffen - von welcher IP-Adresse - welcher Dienst wurde genutzt - war die Anmeldung erfolgreich - welche Fehler sind aufgetreten Logs helfen bei: - Fehlersuche - Sicherheitsanalyse - Nachvollziehbarkeit - Angriffserkennung Merksatz: Remotezugriffe müssen nachvollziehbar sein. --- **Remotezugriff und Firewall** Remotezugriffe sollten durch Firewalls eingeschränkt werden. Beispiele: SSH nur von Admin-Netz erlauben. RDP nur über VPN erlauben. Telnet blockieren. Zugriff auf bestimmte IP-Adressen begrenzen. Merksatz: Remotezugriff nur für notwendige Quellen erlauben. --- **Remotezugriff und VPN** VPN ist eine wichtige Schutzmaßnahme für Remotezugriff. Ablauf: Benutzer verbindet sich per VPN ins interne Netz. Danach nutzt er interne Dienste wie SSH oder RDP. Vorteil: Administrative Dienste müssen nicht direkt öffentlich erreichbar sein. Merksatz: VPN schützt interne Verwaltungszugänge. --- **Remotezugriff und Zero Trust** Zero Trust bedeutet vereinfacht: keinem Zugriff automatisch vertrauen. Auch interne Zugriffe werden geprüft. Wichtige Prinzipien: - Identität prüfen - Gerät prüfen - Rechte begrenzen - Zugriff protokollieren - nur notwendige Dienste freigeben - MFA nutzen Merksatz: Zero Trust prüft jeden Zugriff bewusst. --- **Remotezugriff und Least Privilege** Auch beim Remotezugriff gilt: nur notwendige Rechte vergeben. Beispiel: Ein Benutzer darf sich per SSH anmelden, aber nicht automatisch Root-Rechte haben. Oder: Ein Support-Benutzer darf RDP nutzen, aber keine Serverrollen ändern. Merksatz: Fernzugriff nur mit notwendigen Rechten erlauben. --- **Remotezugriff und Brute Force** Brute Force bedeutet: Angreifer probiert viele Passwörter aus. Besonders gefährdet: öffentlich erreichbare SSH- oder RDP-Dienste. Schutzmaßnahmen: - starke Passwörter - MFA - Kontosperrung - Fail2ban - Rate Limiting - VPN - IP-Einschränkungen - keine Standardbenutzer Merksatz: Öffentliche Remotezugänge sind Brute-Force-Ziele. --- **Remotezugriff und Updates** Remotezugriffsprotokolle und Zielsysteme müssen aktuell gehalten werden. Warum? Schwachstellen in Remotezugriffsdiensten können besonders kritisch sein. Beispiele für Risiken: - unautorisierter Zugriff - Rechteausweitung - Remote Code Execution - Ransomware-Einstieg Merksatz: Remotezugriffsdienste müssen regelmäßig gepatcht werden. --- **Fehlersuche bei Remotezugriff** Eine sinnvolle Reihenfolge: 1. Zielname richtig? 2. DNS-Auflösung korrekt? 3. Ziel-IP erreichbar? 4. Richtiger Port erreichbar? 5. Dienst läuft? 6. Firewall erlaubt Zugriff? 7. Benutzer darf sich anmelden? 8. Authentifizierung korrekt? 9. Berechtigungen korrekt? 10. Logs prüfen. Merksatz: Remotezugriff nach DNS, IP, Port, Dienst, Anmeldung und Rechten prüfen. --- **Typische Prüfpunkte nach Protokoll** | Protokoll | Prüfpunkte | |---|---| | SSH | TCP 22, SSH-Dienst, Benutzer, Schlüssel, Host-Key, Firewall | | RDP | TCP 3389, Remote Desktop aktiv, Benutzerrechte, NLA, VPN, Firewall | | Telnet | TCP 23, Dienst aktiv, aber möglichst vermeiden | | SFTP | TCP 22, SSH-Zugang, SFTP-Rechte | | RD Gateway | HTTPS-Zugriff, Richtlinien, Zertifikat, Benutzerrechte | Merksatz: Jedes Remoteprotokoll hat eigene typische Fehlerquellen. --- **Was Remotezugriffsprotokolle nicht machen** Remotezugriffsprotokolle machen nicht automatisch: - Benutzer sicher berechtigen - Angriffe verhindern - Updates einspielen - Logs auswerten - MFA erzwingen - Firewall korrekt konfigurieren - unsichere Passwörter verhindern - Datenschutz automatisch sicherstellen Remotezugriff braucht immer ein Sicherheitskonzept. Merksatz: Remotezugriff ist mächtig und muss bewusst abgesichert werden. --- **Einordnung in das OSI-Modell** | Thema | Schicht | |---|---:| | SSH | 7 | | RDP | 7 | | Telnet | 7 | | SFTP | 7 über SSH | | TCP 22 | 4 | | TCP 23 | 4 | | TCP 3389 | 4 | | IP-Adresse | 3 | | DNS-Name | 7 | | Verschlüsselung bei SSH | Sicherheits-/Darstellungsbezug | | Benutzeranmeldung | 7 | Merksatz: SSH, RDP und Telnet sind Schicht-7-Protokolle, ihre Ports liegen auf Schicht 4. --- **Typische Ports** | Protokoll | Port | Zweck | |---|---:|---| | SSH | TCP 22 | sichere Shell / Administration | | SFTP | TCP 22 | Dateiübertragung über SSH | | Telnet | TCP 23 | alte unverschlüsselte Shell | | RDP | TCP 3389 | grafischer Fernzugriff | | RD Gateway | TCP 443 | RDP über Gateway / HTTPS | Merksatz: SSH 22, Telnet 23, RDP 3389. --- **Typische IHK-Fragen** In AP1 und AP2 kann zum Beispiel gefragt werden: - Wofür steht SSH? - Wofür wird SSH verwendet? - Welchen Port nutzt SSH typischerweise? - Warum ist SSH sicherer als Telnet? - Was ist ein SSH-Host-Key? - Was ist SSH-Schlüsselauthentifizierung? - Wofür steht RDP? - Wofür wird RDP genutzt? - Welchen Port nutzt RDP typischerweise? - Warum sollte RDP nicht offen im Internet stehen? - Was ist NLA? - Wofür steht Telnet? - Warum gilt Telnet als unsicher? - Welche Sicherheitsmaßnahmen sind bei Remotezugriff sinnvoll? - Wie grenzt man Remotezugriffsfehler systematisch ein? --- **Typische Prüfungsfallen** SSH gehört zu Schicht 7. SSH nutzt typischerweise TCP 22. SSH ist verschlüsselt. SFTP läuft über SSH. SSH-Host-Key identifiziert den Server. Privater SSH-Schlüssel muss geheim bleiben. RDP gehört zu Schicht 7. RDP nutzt typischerweise TCP 3389. RDP ist grafischer Fernzugriff. RDP sollte nicht direkt offen ins Internet. VPN oder RD Gateway sind bessere Schutzmaßnahmen. NLA verbessert RDP-Sicherheit. Telnet gehört zu Schicht 7. Telnet nutzt typischerweise TCP 23. Telnet ist unverschlüsselt. Telnet sollte durch SSH ersetzt werden. Port erreichbar heißt nicht automatisch: Anmeldung erlaubt. Anmeldung erfolgreich heißt nicht automatisch: ausreichende Rechte vorhanden. --- **Wichtige Begriffe kurz erklärt** | Begriff | Kurze Erklärung | |---|---| | Remotezugriff | Zugriff auf ein entferntes System | | Fernadministration | Verwaltung eines Systems aus der Ferne | | SSH | Secure Shell | | SSH-Client | startet SSH-Verbindung | | SSH-Server | nimmt SSH-Verbindung an | | Host-Key | identifiziert SSH-Server | | SSH-Schlüssel | Schlüsselpaar zur Anmeldung | | privater Schlüssel | geheimer Teil des Schlüssels | | öffentlicher Schlüssel | Teil, der auf dem Server liegen darf | | Passphrase | Schutz für privaten Schlüssel | | SSH-Tunnel | verschlüsselte Weiterleitung über SSH | | SFTP | Dateiübertragung über SSH | | RDP | Remote Desktop Protocol | | NLA | Network Level Authentication | | RD Gateway | Gateway für RDP-Zugriffe | | Telnet | altes unverschlüsseltes Fernzugriffsprotokoll | | Brute Force | massenhaftes Ausprobieren von Passwörtern | | Least Privilege | nur notwendige Rechte vergeben | | MFA | Multi-Faktor-Authentifizierung | --- **IHK-sichere Kurzformulierung** SSH, RDP und Telnet sind Protokolle der Anwendungsschicht für Remotezugriff und Fernadministration. SSH steht für Secure Shell, nutzt typischerweise TCP-Port 22 und ermöglicht verschlüsselten Zugriff auf eine Kommandozeile sowie Dateiübertragung über SFTP. RDP steht für Remote Desktop Protocol, nutzt typischerweise TCP-Port 3389 und ermöglicht grafischen Fernzugriff, besonders auf Windows-Systeme. Telnet nutzt typischerweise TCP-Port 23, überträgt Daten unverschlüsselt und sollte für Administration durch SSH ersetzt werden. Remotezugriffe müssen durch starke Authentifizierung, passende Berechtigungen, Firewall-Regeln, VPN oder Gateway-Lösungen und Protokollierung abgesichert werden. --- **Merksätze** Remotezugriff gehört zu Schicht 7. SSH = Secure Shell. SSH nutzt typischerweise TCP 22. SSH ist verschlüsselt. SSH dient sicherer Fernadministration. SFTP läuft über SSH. SSH-Host-Key identifiziert den Server. Privater SSH-Schlüssel bleibt geheim. RDP = Remote Desktop Protocol. RDP nutzt typischerweise TCP 3389. RDP = grafischer Fernzugriff. RDP nicht direkt ungeschützt ins Internet öffnen. RDP besser über VPN oder Gateway nutzen. NLA verbessert RDP-Sicherheit. Telnet nutzt typischerweise TCP 23. Telnet ist unverschlüsselt. Telnet durch SSH ersetzen. Port offen heißt nicht: Anmeldung erfolgreich. Anmeldung erfolgreich heißt nicht: ausreichende Rechte. Remotezugriff braucht starke Authentifizierung. Remotezugriff braucht Least Privilege. Remotezugriff braucht Logs. Remotezugriff braucht Firewall-Regeln. Remotezugriff ist mächtig und sicherheitskritisch.v # 10.9 Authentifizierung, Autorisierung und Anwendungssicherheit Authentifizierung und Autorisierung gehören zu den wichtigsten Sicherheitsgrundlagen auf der Anwendungsschicht. Die Anwendungsschicht ist OSI-Schicht 7. Hier arbeiten viele Dienste direkt mit Benutzern, Anmeldungen, Rollen, Rechten und Anwendungen. Wichtige Begriffe sind: - Authentifizierung - Autorisierung - Identität - Benutzerkonto - Passwort - Token - Session - Rolle - Rechte - Multi-Faktor-Authentifizierung - Single Sign-on - Least Privilege Merksatz: Authentifizierung prüft, wer jemand ist. Autorisierung prüft, was jemand darf. --- **Warum ist das wichtig?** Viele Netzwerkdienste müssen entscheiden: Wer greift zu? und: Was darf diese Person oder dieses System tun? Beispiele: Benutzer meldet sich an einer Webanwendung an. Administrator verbindet sich per SSH. Mitarbeiter öffnet eine SMB-Freigabe. Anwendung ruft eine API mit Token auf. Benutzer meldet sich an einem E-Mail-Postfach an. Client greift auf einen Verzeichnisdienst zu. Ohne saubere Authentifizierung und Autorisierung können unberechtigte Zugriffe entstehen. Merksatz: Anmeldung allein reicht nicht. Rechte müssen ebenfalls geprüft werden. --- **Authentifizierung** Authentifizierung bedeutet: Die Identität wird überprüft. Frage: Wer bist du? Beispiele: - Benutzername und Passwort - SSH-Schlüssel - Zertifikat - Smartcard - Fingerabdruck - Einmalcode - Hardware-Token - App-Bestätigung Merksatz: Authentifizierung = Identität prüfen. --- **Autorisierung** Autorisierung bedeutet: Es wird geprüft, welche Rechte eine authentifizierte Identität hat. Frage: Was darfst du? Beispiele: - Datei lesen - Datei ändern - Benutzer anlegen - Server verwalten - Adminbereich öffnen - API-Daten abrufen - Bestellung freigeben - Konfiguration ändern Merksatz: Autorisierung = Rechte prüfen. --- **Authentifizierung und Autorisierung unterscheiden** | Begriff | Frage | Beispiel | |---|---|---| | Authentifizierung | Wer bist du? | Benutzer meldet sich an | | Autorisierung | Was darfst du? | Benutzer darf nur bestimmte Ordner öffnen | Beispiel: Felix meldet sich erfolgreich an. Das ist: Authentifizierung Danach prüft das System: Darf Felix diese Datei löschen? Das ist: Autorisierung Merksatz: Erst Identität, dann Rechte. --- **Typischer Fehler** Ein häufiger Denkfehler ist: Wenn ein Benutzer angemeldet ist, darf er automatisch alles. Das ist falsch. Ein Benutzer kann korrekt angemeldet sein, aber trotzdem keine Berechtigung für eine bestimmte Aktion haben. Beispiel: Benutzer ist angemeldet, darf aber keine Adminseite öffnen. Merksatz: Angemeldet bedeutet nicht automatisch berechtigt. --- **Identität** Eine Identität beschreibt, wer eine Person, ein Dienst oder ein System ist. Beispiele: - Benutzerkonto - Dienstkonto - Computerobjekt - API-Client - Zertifikat - SSH-Schlüssel - Anwendungskonto Identitäten müssen eindeutig verwaltet werden. Merksatz: Identität beschreibt, wer oder was zugreift. --- **Benutzerkonto** Ein Benutzerkonto ist eine digitale Identität für eine Person. Es enthält oft: - Benutzername - Kennwort-Hash - Gruppenmitgliedschaften - Profilinformationen - Berechtigungen - Status des Kontos - Anmelderichtlinien Benutzerkonten können lokal oder zentral verwaltet werden. Beispiele: - lokales Windows-Konto - Active-Directory-Konto - LDAP-Konto - Cloud-Konto - Anwendungskonto Merksatz: Benutzerkonto = digitale Identität eines Benutzers. --- **Dienstkonto** Ein Dienstkonto wird nicht direkt von einem normalen Benutzer verwendet, sondern von einem Dienst oder einer Anwendung. Beispiele: - Datenbankzugriff einer Webanwendung - Backup-Dienst - Monitoring-Dienst - LDAP-Abfragekonto - API-Integration Wichtig: Dienstkonten sollten nur die Rechte haben, die sie wirklich benötigen. Merksatz: Dienstkonto = Konto für einen Dienst, nicht für normale Benutzerarbeit. --- **Passwort** Ein Passwort ist ein geheimer Nachweis, mit dem sich ein Benutzer authentifizieren kann. Sichere Passwörter sollten: - ausreichend lang sein - nicht leicht zu erraten sein - nicht mehrfach verwendet werden - nicht im Klartext gespeichert werden - bei Verdacht geändert werden Wichtig: Länge ist oft wichtiger als komplizierte Sonderzeichen-Regeln. Merksatz: Passwort = geheimer Identitätsnachweis. --- **Passwort-Hash** Passwörter sollten nicht im Klartext gespeichert werden. Stattdessen speichert man einen Passwort-Hash. Ein Hash ist ein Einweg-Prüfwert. Bei der Anmeldung wird das eingegebene Passwort erneut gehasht und mit dem gespeicherten Hash verglichen. Merksatz: Passwörter nicht im Klartext speichern, sondern sicher hashen. --- **Salt** Ein Salt ist ein zusätzlicher zufälliger Wert beim Passwort-Hashing. Ziel: gleiche Passwörter sollen nicht automatisch gleiche Hashes erzeugen. Beispiel: Zwei Benutzer haben dasselbe Passwort. Durch unterschiedliche Salts entstehen trotzdem unterschiedliche Hashes. Merksatz: Salt schützt gegen einfache Hash-Vergleiche und vorberechnete Tabellen. --- **Multi-Faktor-Authentifizierung** Multi-Faktor-Authentifizierung wird kurz genannt: MFA Dabei werden mehrere Faktoren kombiniert. Typische Faktoren: | Faktor | Beispiel | |---|---| | Wissen | Passwort | | Besitz | Smartphone, Token, Smartcard | | Sein | Fingerabdruck, Gesichtserkennung | Beispiel: Passwort plus Einmalcode aus App Merksatz: MFA kombiniert mehrere Nachweise. --- **Warum ist MFA wichtig?** Wenn ein Passwort gestohlen wird, kann ein Angreifer sich ohne zweiten Faktor nicht so einfach anmelden. MFA schützt besonders bei: - Cloud-Konten - VPN-Zugängen - Admin-Konten - E-Mail-Konten - Remotezugriff - kritischen Anwendungen Merksatz: MFA reduziert das Risiko durch gestohlene Passwörter. --- **Einmalpasswort** Ein Einmalpasswort wird auch genannt: OTP OTP steht für: One-Time Password Es ist nur einmal oder nur kurzzeitig gültig. Beispiele: - Code aus Authenticator-App - Hardware-Token - SMS-Code - E-Mail-Code Merksatz: OTP = zeitlich oder einmalig gültiger Code. --- **Token** Ein Token ist ein digitaler Nachweis für Zugriff. Ein Token kann enthalten: - Benutzerinformationen - Ablaufzeit - Berechtigungen - Aussteller - Signatur - Sitzungsbezug Tokens werden häufig bei Webanwendungen und APIs verwendet. Merksatz: Token = digitaler Zugriffsnachweis. --- **Bearer Token** Ein Bearer Token wird häufig bei APIs genutzt. Er wird oft im HTTP-Header übertragen: Authorization: Bearer Wichtig: Wer den Bearer Token besitzt, kann ihn oft verwenden. Deshalb muss er wie ein Passwort geschützt werden. Merksatz: Bearer Token wie ein Passwort behandeln. --- **Session** Eine Session ist eine Sitzung zwischen Client und Anwendung. Beispiel: Benutzer meldet sich an. Server erstellt Session. Browser erhält Session-Cookie. Weitere Anfragen werden dieser Session zugeordnet. Sessions helfen, einen Benutzer über mehrere Anfragen hinweg wiederzuerkennen. Merksatz: Session verbindet mehrere Anfragen zu einer Sitzung. --- **Session-Cookie** Ein Session-Cookie enthält häufig eine Session-ID. Der Browser sendet dieses Cookie bei weiteren Anfragen mit. Dadurch weiß der Server: Diese Anfrage gehört zu dieser Sitzung. Wichtig: Session-Cookies müssen geschützt werden. Merksatz: Session-Cookie hält die Anmeldung über mehrere Anfragen fest. --- **Sichere Cookie-Eigenschaften** Wichtige Cookie-Sicherheitsattribute: | Attribut | Bedeutung | |---|---| | Secure | Cookie nur über HTTPS senden | | HttpOnly | Cookie nicht per JavaScript auslesbar | | SameSite | Schutz gegen bestimmte Cross-Site-Angriffe | | Expires / Max-Age | Ablaufzeit des Cookies | Merksatz: Sichere Cookies schützen Sitzungen. --- **Session Hijacking** Session Hijacking bedeutet: Ein Angreifer übernimmt eine gültige Sitzung. Das kann passieren, wenn ein Session-Cookie gestohlen wird. Mögliche Ursachen: - unsichere Verbindung - XSS-Schwachstelle - unsichere Cookies - gestohlener Token - Malware auf Client - unsichere Speicherung Merksatz: Wer eine Session übernimmt, kann oft wie der Benutzer handeln. --- **Session Timeout** Ein Session Timeout beendet eine Sitzung nach einer bestimmten Zeit. Gründe: - Schutz bei vergessener Abmeldung - Begrenzung gestohlener Sessions - Ressourcen sparen - Sicherheitsrichtlinie erfüllen Beispiel: Benutzer ist 30 Minuten inaktiv. Anwendung meldet ihn ab. Merksatz: Timeout begrenzt die Lebensdauer einer Sitzung. --- **Single Sign-on** Single Sign-on wird kurz genannt: SSO SSO bedeutet: Ein Benutzer meldet sich einmal an und kann danach mehrere Dienste nutzen. Beispiele: - Anmeldung über Microsoft Entra ID - Anmeldung über Active Directory - Anmeldung über Google Workspace - Anmeldung über zentralen Identitätsanbieter Vorteil: weniger separate Passwörter zentrale Verwaltung bessere Benutzerfreundlichkeit Merksatz: SSO = einmal anmelden, mehrere Dienste nutzen. --- **Identity Provider** Ein Identity Provider wird kurz genannt: IdP Ein IdP stellt Identitäten bereit und bestätigt Anmeldungen. Beispiele: - Active Directory - Microsoft Entra ID - Keycloak - Okta - Google Workspace Eine Anwendung kann dem IdP vertrauen, statt eigene Benutzer vollständig selbst zu verwalten. Merksatz: IdP bestätigt die Identität für Anwendungen. --- **Service Provider** Ein Service Provider ist die Anwendung oder der Dienst, der Zugriff gewährt. Beispiel: Benutzer meldet sich über IdP an. Webanwendung vertraut dem IdP. Webanwendung lässt Benutzer hinein. Merksatz: Service Provider nutzt Identitätsinformationen vom IdP. --- **OAuth 2.0** OAuth 2.0 ist ein Autorisierungsframework. Es wird häufig verwendet, damit Anwendungen Zugriff auf bestimmte Ressourcen erhalten können, ohne direkt das Passwort des Benutzers zu kennen. Beispiel: Eine App darf auf Kalenderdaten zugreifen, aber nicht auf das Passwort des Benutzers. Merksatz: OAuth 2.0 regelt delegierten Zugriff. --- **OpenID Connect** OpenID Connect baut auf OAuth 2.0 auf. Es wird für Authentifizierung verwendet. Kurz: OAuth 2.0: Zugriff erlauben OpenID Connect: Identität bestätigen Merksatz: OpenID Connect ergänzt OAuth um Anmeldung und Identität. --- **SAML** SAML steht für: Security Assertion Markup Language SAML wird häufig für Single Sign-on in Unternehmen verwendet. Dabei tauschen Identitätsanbieter und Anwendung Anmeldeinformationen aus. Typisch bei: - Unternehmensanwendungen - Cloud-Diensten - älteren SSO-Umgebungen Merksatz: SAML ist ein verbreiteter SSO-Standard. --- **Rollen** Rollen bündeln Berechtigungen. Beispiele: - Benutzer - Administrator - Support - Prüfer - Projektleitung - Gast Ein Benutzer erhält eine Rolle, und die Rolle enthält Rechte. Merksatz: Rolle = Sammlung von Berechtigungen. --- **Rechte** Rechte beschreiben konkrete erlaubte Aktionen. Beispiele: - lesen - schreiben - ändern - löschen - ausführen - freigeben - verwalten - Benutzer anlegen Merksatz: Recht = konkrete erlaubte Aktion. --- **Gruppen** Gruppen bündeln Benutzer. Beispiel: Gruppe: IT-Support Mitglieder: Felix Maria Jonas Rechte werden häufig Gruppen zugewiesen, nicht einzelnen Benutzern. Vorteil: einfacher zu verwalten übersichtlicher weniger Fehler Merksatz: Benutzer in Gruppen, Rechte an Gruppen. --- **RBAC** RBAC steht für: Role-Based Access Control Das bedeutet: Zugriff wird über Rollen gesteuert. Beispiel: Rolle Administrator: darf Benutzer verwalten Rolle Leser: darf Inhalte lesen Rolle Bearbeiter: darf Inhalte ändern Merksatz: RBAC = Rechte über Rollen verwalten. --- **Least Privilege** Least Privilege bedeutet: Benutzer und Dienste erhalten nur die Rechte, die sie wirklich benötigen. Beispiel: Ein Dienst braucht nur Leserechte. Dann bekommt er keine Schreibrechte. Ziel: Schaden begrenzen, falls ein Konto missbraucht wird. Merksatz: Nur so viele Rechte wie nötig, so wenige wie möglich. --- **Need-to-know-Prinzip** Need-to-know bedeutet: Zugriff nur auf Informationen, die für die Aufgabe benötigt werden. Beispiel: Personalabteilung darf Personaldaten sehen. Andere Abteilungen nicht. Merksatz: Zugriff nur, wenn er fachlich notwendig ist. --- **Privileged Access** Privileged Access bedeutet: besonders mächtiger Zugriff. Beispiele: - Administratorrechte - Domain-Admin - Root-Zugriff - Datenbankadministrator - Cloud-Administrator - Firewall-Administrator Solche Zugriffe müssen besonders geschützt werden. Merksatz: Adminrechte sind besonders kritisch. --- **Schutz für Admin-Konten** Admin-Konten sollten besonders abgesichert werden. Maßnahmen: - MFA - getrennte Admin-Konten - kein tägliches Arbeiten mit Admin-Konto - starke Protokollierung - Zugriffsbeschränkung - Least Privilege - regelmäßige Prüfung - keine geteilten Konten Merksatz: Admin-Konten besonders schützen und überwachen. --- **Geteilte Konten** Geteilte Konten sind Konten, die von mehreren Personen genutzt werden. Problem: Aktionen sind schwer einer Person zuzuordnen. Beispiel: Alle nutzen admin. Besser: persönliche Konten plus gezielte Adminrechte Merksatz: Geteilte Konten vermeiden, weil Nachvollziehbarkeit fehlt. --- **Protokollierung** Sicherheitsrelevante Anmeldungen und Zugriffe sollten protokolliert werden. Wichtige Informationen: - Benutzer - Zeitpunkt - Quelle - Zielsystem - erfolgreiche Anmeldung - fehlgeschlagene Anmeldung - Rechteänderung - kritische Aktion Merksatz: Ohne Logs keine saubere Nachvollziehbarkeit. --- **Brute-Force-Angriff** Brute Force bedeutet: viele Passwörter werden ausprobiert. Ziel: ein gültiges Passwort finden. Gefährdet sind besonders: - Weblogin - SSH - RDP - VPN - E-Mail - Cloud-Konten Schutzmaßnahmen: - MFA - Kontosperrung - Rate Limiting - starke Passwörter - Monitoring - IP-Beschränkung - Fail2ban Merksatz: Brute Force wird durch Begrenzung und MFA erschwert. --- **Phishing** Phishing bedeutet: Benutzer werden getäuscht, um Zugangsdaten oder Tokens preiszugeben. Beispiele: - gefälschte Login-Seite - angebliche Passwortänderung - falsche Paketbenachrichtigung - gefälschte Rechnung - angeblicher IT-Support Schutzmaßnahmen: - Schulung - MFA - sichere Mailfilter - Domainprüfung - Passwortmanager - Meldewege für verdächtige Mails Merksatz: Phishing greift den Menschen und die Anmeldung an. --- **Credential Stuffing** Credential Stuffing bedeutet: Angreifer verwenden bekannte Zugangsdaten aus Datenlecks bei anderen Diensten erneut. Problem: Viele Benutzer verwenden gleiche Passwörter mehrfach. Schutzmaßnahmen: - keine Passwortwiederverwendung - MFA - Passwortmanager - Überwachung verdächtiger Logins Merksatz: Wiederverwendete Passwörter sind ein großes Risiko. --- **Passwortspraying** Beim Passwortspraying probiert ein Angreifer ein häufiges Passwort gegen viele Benutzerkonten. Beispiel: Sommer2026! gegen viele Konten. Ziel: Kontosperrungen vermeiden, aber trotzdem Treffer finden. Merksatz: Passwortspraying testet wenige Passwörter gegen viele Konten. --- **Account Lockout** Account Lockout bedeutet: Ein Konto wird nach mehreren Fehlversuchen gesperrt. Ziel: Brute-Force-Angriffe erschweren. Wichtig: Sperrregeln müssen sinnvoll eingestellt sein, damit Angriffe erschwert werden, aber Benutzer nicht unnötig blockiert werden. Merksatz: Kontosperrung begrenzt Passwortversuche. --- **Rate Limiting** Rate Limiting begrenzt, wie viele Anfragen in einer bestimmten Zeit erlaubt sind. Beispiel: maximal 5 Loginversuche pro Minute Ziel: automatisierte Angriffe erschweren Merksatz: Rate Limiting bremst massenhafte Versuche. --- **CAPTCHA** CAPTCHA soll prüfen, ob ein Benutzer wahrscheinlich ein Mensch ist. Typische Nutzung: - Login - Registrierung - Formular - Passwortzurücksetzung CAPTCHA kann automatisierte Angriffe erschweren, ersetzt aber keine starke Authentifizierung. Merksatz: CAPTCHA erschwert Bots, ersetzt aber keine Sicherheit. --- **Passwortmanager** Ein Passwortmanager speichert Passwörter verschlüsselt. Vorteile: - lange zufällige Passwörter - weniger Passwortwiederverwendung - einfacheres Verwalten vieler Konten - Schutz vor Tippfehlern - teilweise Schutz gegen Phishing durch Domainprüfung Merksatz: Passwortmanager helfen bei starken eindeutigen Passwörtern. --- **Sichere Passwortregeln** Sinnvolle Regeln: - lange Passwörter erlauben - Passwortmanager unterstützen - bekannte kompromittierte Passwörter blockieren - MFA nutzen - keine unnötig kurzen Ablaufintervalle ohne Grund - Passwortwiederverwendung vermeiden Merksatz: Lange eindeutige Passwörter plus MFA sind sehr stark. --- **Anwendungssicherheit** Anwendungssicherheit bedeutet: Anwendungen so entwickeln, konfigurieren und betreiben, dass Missbrauch erschwert wird. Typische Themen: - sichere Anmeldung - Rechteprüfung - Eingabevalidierung - Schutz vor SQL-Injection - Schutz vor XSS - sichere Sessions - sichere APIs - Logging - Updates - sichere Konfiguration Merksatz: Anwendungssicherheit schützt Dienste auf Schicht 7. --- **SQL-Injection** SQL-Injection ist ein Angriff, bei dem schädliche Daten in eine Datenbankabfrage eingeschleust werden. Beispiel sinngemäß: Eingabefeld wird nicht geprüft. Angreifer fügt SQL-Befehl ein. Datenbank führt unerwünschte Abfrage aus. Schutzmaßnahmen: - parametrisierte Abfragen - Eingabevalidierung - minimale Datenbankrechte - Fehlermeldungen nicht offenlegen Merksatz: SQL-Injection nutzt unsichere Datenbankeingaben aus. --- **Cross-Site Scripting** Cross-Site Scripting wird kurz genannt: XSS Dabei wird schädlicher Code in eine Webseite eingeschleust. Ziel: im Browser anderer Benutzer ausgeführt werden. Mögliche Folgen: - Session-Cookie stehlen - Inhalte manipulieren - Benutzeraktionen auslösen - Phishing innerhalb der Anwendung Schutzmaßnahmen: - Ausgaben korrekt escapen - Eingaben prüfen - Content Security Policy - HttpOnly-Cookies - sichere Frameworks nutzen Merksatz: XSS greift Benutzer über die Webseite an. --- **CSRF** CSRF steht für: Cross-Site Request Forgery Dabei wird ein angemeldeter Benutzer dazu gebracht, unbeabsichtigt eine Aktion in einer Webanwendung auszuführen. Beispiel: Benutzer ist angemeldet. Angreifer bringt Browser dazu, eine unerwünschte Anfrage zu senden. Schutzmaßnahmen: - CSRF-Token - SameSite-Cookies - Prüfung von Origin oder Referer - kritische Aktionen bestätigen lassen Merksatz: CSRF missbraucht eine bestehende Anmeldung. --- **Unsichere direkte Objektreferenz** Eine unsichere direkte Objektreferenz entsteht, wenn eine Anwendung nur eine ID prüft, aber nicht die Berechtigung. Beispiel: /rechnung/1001 Benutzer ändert URL zu: /rechnung/1002 Wenn die Anwendung nicht prüft, ob Benutzer Rechnung 1002 sehen darf, entsteht ein Sicherheitsproblem. Merksatz: Jede Ressource braucht Berechtigungsprüfung. --- **Sichere APIs** APIs müssen besonders sauber geschützt werden. Wichtige Punkte: - Authentifizierung - Autorisierung - sichere Tokens - HTTPS - Rate Limiting - Eingabevalidierung - saubere Fehlercodes - keine geheimen Daten in Antworten - Logging - Versionierung Merksatz: API-Sicherheit ist Anwendungssicherheit auf Schnittstellenebene. --- **Fehlermeldungen** Fehlermeldungen sollten hilfreich, aber nicht zu verräterisch sein. Schlecht: Datenbankfehler mit Tabellenname und SQL-Abfrage wird angezeigt. Besser: Allgemeine Fehlermeldung für Benutzer. Details nur im geschützten Serverlog. Merksatz: Interne Details gehören in Logs, nicht in öffentliche Fehlermeldungen. --- **Updates und Patches** Anwendungen und Abhängigkeiten müssen aktuell gehalten werden. Risiken bei veralteter Software: - bekannte Schwachstellen - unsichere Bibliotheken - veraltete Authentifizierungsverfahren - fehlende Sicherheitsupdates - Angriffe über bekannte Exploits Merksatz: Veraltete Anwendungen sind ein Sicherheitsrisiko. --- **Sichere Konfiguration** Auch sichere Software kann unsicher betrieben werden, wenn sie falsch konfiguriert ist. Beispiele: - Standardpasswörter - Debug-Modus aktiv - offene Adminbereiche - zu viele Rechte - unsichere CORS-Regeln - veraltete TLS-Versionen - unnötige Dienste aktiv - Verzeichnislisting aktiv Merksatz: Falsche Konfiguration kann sichere Software unsicher machen. --- **Fehlersuche bei Anmeldung und Rechten** Eine sinnvolle Reihenfolge: 1. Benutzer existiert? 2. Passwort oder Schlüssel korrekt? 3. Konto aktiv? 4. MFA korrekt? 5. Gruppe oder Rolle vorhanden? 6. Rechte korrekt? 7. Session oder Token gültig? 8. Zeit korrekt? 9. Dienst erreichbar? 10. Logs prüfen. Merksatz: Bei Loginproblemen Identität, Faktor, Rolle und Logs prüfen. --- **Fehlerbild: Anmeldung schlägt fehl** Mögliche Ursachen: - falsches Passwort - Benutzername falsch - Konto gesperrt - Konto deaktiviert - Passwort abgelaufen - MFA fehlt - falscher Identity Provider - LDAP oder AD nicht erreichbar - Zeitabweichung - Token ungültig Merksatz: Loginfehler sind nicht immer nur Passwortfehler. --- **Fehlerbild: Zugriff verweigert** Mögliche Ursachen: - Benutzer ist nicht in richtiger Gruppe - Rolle fehlt - Berechtigung fehlt - Ressource gehört anderem Benutzer - Richtlinie blockiert - Token enthält falsche Rechte - Anwendung prüft Rechte fehlerhaft - alte Session enthält alte Rechte Merksatz: Zugriff verweigert = Autorisierung prüfen. --- **Fehlerbild: Benutzer ist angemeldet, sieht aber nichts** Mögliche Ursachen: - keine Gruppenmitgliedschaft - falsche Rolle - fehlende Lizenz - falscher Mandant - Berechtigungen nicht synchronisiert - Anwendung filtert Daten nach Rechten - Session muss erneuert werden Merksatz: Erfolgreiche Anmeldung bedeutet noch keine sichtbaren Berechtigungen. --- **Fehlerbild: MFA funktioniert nicht** Mögliche Ursachen: - falsches Gerät registriert - Uhrzeit falsch - Token abgelaufen - Benutzer hat neues Smartphone - Push-Benachrichtigung blockiert - Konto nicht korrekt für MFA registriert - Netzwerkverbindung fehlt Merksatz: MFA-Probleme mit Gerät, Zeit, Registrierung und Konto prüfen. --- **Fehlerbild: Token abgelaufen** Mögliche Ursachen: - Ablaufzeit erreicht - Benutzer wurde abgemeldet - Refresh Token ungültig - Systemzeit falsch - Token wurde widerrufen - Session wurde beendet Merksatz: Tokens haben Lebensdauer und können widerrufen werden. --- **Einordnung in das OSI-Modell** | Thema | Schicht | |---|---:| | Loginformular | 7 | | API-Token | 7 | | Session-Cookie | 7 mit Schicht-5-Bezug | | LDAP-Anmeldung | 7 | | OAuth / OpenID Connect | 7 | | SAML | 7 | | TLS-Schutz | 6 mit Schicht-7-Bezug | | TCP-Port | 4 | | IP-Adresse | 3 | | Benutzerrechte | 7 / Anwendungsebene | Merksatz: Anmeldung und Rechte sind typische Schicht-7-Themen. --- **Typische IHK-Fragen** In AP1 und AP2 kann zum Beispiel gefragt werden: - Was bedeutet Authentifizierung? - Was bedeutet Autorisierung? - Was ist der Unterschied zwischen Authentifizierung und Autorisierung? - Was ist MFA? - Warum ist MFA sinnvoll? - Was ist ein Token? - Was ist eine Session? - Was ist ein Session-Cookie? - Was bedeutet Single Sign-on? - Was ist ein Identity Provider? - Was ist Least Privilege? - Warum sollten Rechte über Gruppen vergeben werden? - Warum sind geteilte Admin-Konten problematisch? - Was ist Brute Force? - Was ist Phishing? - Was ist SQL-Injection? - Was ist XSS? - Warum sind sichere Fehlermeldungen wichtig? --- **Typische Prüfungsfallen** Authentifizierung ist nicht Autorisierung. Anmeldung bedeutet nicht automatisch Zugriff. Rechte müssen pro Ressource geprüft werden. MFA erhöht die Sicherheit deutlich. Token müssen wie Passwörter geschützt werden. Session-Cookies müssen sicher gesetzt werden. HTTPS ist wichtig für Login und Tokens. Bearer Token kann von jedem genutzt werden, der ihn besitzt. Geteilte Konten erschweren Nachvollziehbarkeit. Adminrechte besonders schützen. Least Privilege immer beachten. Gruppen erleichtern Rechteverwaltung. Phishing greift oft Zugangsdaten an. SQL-Injection betrifft unsichere Datenbankeingaben. XSS betrifft unsichere Ausgaben im Browser. CSRF missbraucht bestehende Sitzungen. Fehlermeldungen dürfen keine internen Details verraten. --- **Wichtige Begriffe kurz erklärt** | Begriff | Kurze Erklärung | |---|---| | Authentifizierung | Identität prüfen | | Autorisierung | Rechte prüfen | | Identität | Benutzer, Dienst oder System | | Benutzerkonto | digitale Identität eines Benutzers | | Dienstkonto | Konto für Anwendungen oder Dienste | | Passwort | geheimer Identitätsnachweis | | Passwort-Hash | Einweg-Prüfwert eines Passworts | | Salt | zusätzlicher Zufallswert beim Hashing | | MFA | Multi-Faktor-Authentifizierung | | OTP | Einmalpasswort | | Token | digitaler Zugriffsnachweis | | Bearer Token | nutzbarer Zugriffstoken | | Session | Sitzung zwischen Client und Anwendung | | Session-Cookie | Cookie zur Sitzungszuordnung | | SSO | Single Sign-on | | IdP | Identity Provider | | RBAC | rollenbasierte Zugriffskontrolle | | Least Privilege | nur notwendige Rechte | | Brute Force | massenhaftes Passwortprobieren | | Phishing | Täuschung zur Datenerbeutung | | SQL-Injection | Einschleusen von SQL-Befehlen | | XSS | Einschleusen von Code in Webseiten | | CSRF | Missbrauch bestehender Anmeldung | --- **IHK-sichere Kurzformulierung** Authentifizierung und Autorisierung sind zentrale Sicherheitskonzepte auf der Anwendungsschicht. Authentifizierung prüft die Identität eines Benutzers, Dienstes oder Systems. Autorisierung prüft anschließend, welche Rechte diese Identität besitzt. Eine erfolgreiche Anmeldung bedeutet daher nicht automatisch, dass ein Benutzer alle Aktionen durchführen darf. Multi-Faktor-Authentifizierung erhöht die Sicherheit, weil neben dem Passwort ein weiterer Faktor benötigt wird. Rechte sollten möglichst über Gruppen oder Rollen vergeben werden und dem Least-Privilege-Prinzip folgen. Tokens, Session-Cookies und Passwörter müssen geschützt werden, da sie Zugriff auf Anwendungen und Dienste ermöglichen können. --- **Merksätze** Authentifizierung = Wer bist du? Autorisierung = Was darfst du? Erst Identität, dann Rechte. Anmeldung ist nicht gleich Berechtigung. Benutzerkonto = digitale Identität. Dienstkonto = Konto für Dienste. Passwörter nicht im Klartext speichern. Passwort-Hash schützt gespeicherte Passwörter. Salt macht Hashes robuster. MFA kombiniert mehrere Faktoren. OTP = Einmalpasswort. Token = digitaler Zugriffsnachweis. Bearer Token wie Passwort schützen. Session verbindet mehrere Anfragen. Session-Cookie schützt Anmeldung. Secure, HttpOnly und SameSite schützen Cookies. SSO = einmal anmelden, mehrere Dienste nutzen. IdP bestätigt Identität. OAuth regelt delegierten Zugriff. OpenID Connect ergänzt Anmeldung. RBAC verwaltet Rechte über Rollen. Least Privilege = nur notwendige Rechte. Admin-Konten besonders schützen. Geteilte Konten vermeiden. Brute Force probiert Passwörter. Phishing täuscht Benutzer. SQL-Injection nutzt unsichere Eingaben. XSS greift Benutzer im Browser an. CSRF missbraucht bestehende Sitzungen. Anwendungssicherheit ist Schicht-7-Sicherheit. # 10.10 Fehlersuche auf OSI-Schicht 7 OSI-Schicht 7 ist die Anwendungsschicht. Auf dieser Schicht prüft man nicht mehr nur: Kommt eine Verbindung zustande? Sondern zusätzlich: Funktioniert der konkrete Dienst? Antwortet die Anwendung korrekt? Stimmen Anmeldung, Rechte, Daten und Protokoll? Typische Schicht-7-Dienste sind: - HTTP / HTTPS - DNS - DHCP - SMTP - IMAP - POP3 - FTP - SFTP - SMB - LDAP - SNMP - NTP - SSH - RDP - APIs Merksatz: Schicht 7 prüft den Dienst, nicht nur die Verbindung. --- **Grundidee der Schicht-7-Fehlersuche** Bei Schicht 7 geht es um die konkrete Anwendungskommunikation. Ein Port kann erreichbar sein, aber der Dienst kann trotzdem nicht richtig funktionieren. Beispiel: TCP 443 ist offen, aber die Webseite zeigt HTTP 500. Oder: DNS-Server ist erreichbar, aber der Name wird falsch aufgelöst. Oder: SMB-Port 445 ist erreichbar, aber der Benutzer hat keine Berechtigung. Merksatz: Offener Port bedeutet nicht automatisch: Anwendung funktioniert. --- **Schicht 7 erst prüfen, wenn die unteren Schichten passen** Vor der Schicht-7-Fehlersuche sollte man prüfen: Schicht 1: physische Verbindung vorhanden? Schicht 2: richtige MAC-Kommunikation, VLAN, Switch? Schicht 3: IP-Adresse, Subnetz, Gateway, Routing? Schicht 4: TCP- oder UDP-Port erreichbar? Erst danach prüft man genauer: Dienst, Protokoll, Anmeldung, Antwort, Daten, Rechte, Logs. Merksatz: Erst unten prüfen, dann oben analysieren. --- **Typische Abgrenzung nach Schichten** | Fehlerbild | wahrscheinliche Schicht | |---|---:| | Kein Link | 1 | | Falsches VLAN | 2 | | Kein Gateway erreichbar | 3 | | Port nicht erreichbar | 4 | | Zertifikatswarnung | 6 | | HTTP 404 oder 500 | 7 | | Login funktioniert nicht | 7 | | Zugriff verweigert | 7 | | DNS löst falsch auf | 7 | | Mail landet im Spam | 7 | | API lehnt Anfrage ab | 7 | Merksatz: Schicht-7-Fehler betreffen Inhalt, Dienst, Anmeldung oder Berechtigung. --- **Wichtige Prüffragen auf Schicht 7** Bei Anwendungsschichtproblemen stellt man Fragen wie: Läuft der Dienst? Antwortet der Dienst korrekt? Wird das richtige Protokoll verwendet? Wird der richtige Hostname verwendet? Ist die URL korrekt? Ist die Anmeldung korrekt? Hat der Benutzer die nötigen Rechte? Sind Zertifikate gültig? Stimmen Header, Methode und Datenformat? Gibt es Logs? Gibt es eine Fehlermeldung? Betrifft es alle Benutzer oder nur einzelne? Merksatz: Schicht 7 fragt: Was macht der Dienst genau? --- **Dienst läuft oder läuft nicht** Ein häufiger Fehler ist: Netzwerk funktioniert, aber Dienst läuft nicht. Beispiele: Webserver gestoppt Datenbank nicht erreichbar SSH-Dienst deaktiviert Maildienst gestört DNS-Dienst nicht gestartet Backend-Container nicht aktiv Anwendung abgestürzt Typisches Fehlerbild: Host erreichbar, aber Dienst antwortet nicht richtig. Merksatz: Erreichbarer Server heißt nicht: Dienst läuft. --- **Falsches Protokoll** Manchmal wird das falsche Protokoll verwendet. Beispiele: http:// statt https:// FTP statt SFTP LDAP statt LDAPS IMAP statt POP3 SMB-Pfad statt SFTP-Zugriff HTTPS zum Backend, obwohl Backend nur HTTP spricht Merksatz: Falsches Protokoll kann wie ein Verbindungsfehler aussehen. --- **Falscher Port** Ein Dienst kann auf einem anderen Port laufen als erwartet. Beispiele: Webserver läuft auf TCP 8080 statt TCP 80. Adminoberfläche läuft auf TCP 8443 statt TCP 443. SSH läuft auf anderem Port als TCP 22. Anwendung läuft intern auf Port 3000, extern aber über Reverse Proxy auf 443. Merksatz: Immer prüfen: Welcher Dienst lauscht auf welchem Port? --- **Falscher Hostname** Bei vielen Diensten ist der Hostname wichtig. Beispiele: HTTPS-Zertifikat muss zum Hostnamen passen. Reverse Proxy entscheidet über Host-Header. Virtuelle Hosts liefern je nach Hostname andere Inhalte. DNS kann intern und extern unterschiedlich auflösen. Fehlerbild: IP ist erreichbar, aber falsche Webseite oder falsches Zertifikat erscheint. Merksatz: Hostname ist auf Schicht 7 oft entscheidend. --- **DNS-Fehler auf Schicht 7** DNS-Probleme sind typische Schicht-7-Probleme. Fehlerbilder: Name löst nicht auf. Name löst auf falsche IP auf. Interne und externe Antwort unterscheiden sich. DNS-Cache ist veraltet. MX-Record fehlt. CNAME zeigt falsch. AAAA-Record zeigt auf nicht erreichbares IPv6-Ziel. Prüffragen: Welcher DNS-Server wird gefragt? Welche Antwort liefert er? Ist die Antwort intern und extern gleich? Ist der Cache noch aktiv? Stimmt die TTL? Merksatz: IP geht, Name nicht: DNS prüfen. --- **HTTP-Fehler auf Schicht 7** Bei Webdiensten sind HTTP-Statuscodes sehr hilfreich. Wichtige Beispiele: | Statuscode | Bedeutung | |---:|---| | 200 | OK | | 301 / 302 | Weiterleitung | | 400 | fehlerhafte Anfrage | | 401 | nicht authentifiziert | | 403 | verboten | | 404 | nicht gefunden | | 405 | Methode nicht erlaubt | | 429 | zu viele Anfragen | | 500 | interner Serverfehler | | 502 | Bad Gateway | | 503 | Dienst nicht verfügbar | | 504 | Gateway Timeout | Merksatz: HTTP-Statuscodes sind wichtige Schicht-7-Hinweise. --- **401 und 403 bei der Fehlersuche** 401 bedeutet: Benutzer ist nicht authentifiziert. Typische Ursachen: - nicht angemeldet - Token fehlt - Token ungültig - Session abgelaufen - falsche Zugangsdaten 403 bedeutet: Benutzer ist bekannt, aber nicht berechtigt. Typische Ursachen: - Rolle fehlt - Gruppe fehlt - Zugriff verboten - Richtlinie blockiert - Ressource nicht erlaubt Merksatz: 401 = Anmeldung fehlt. 403 = Rechte fehlen. --- **404 bei der Fehlersuche** 404 bedeutet: Ressource nicht gefunden. Mögliche Ursachen: - falscher Pfad - falsche URL - Route fehlt - Datei existiert nicht - Reverse Proxy leitet falsch weiter - Anwendung erwartet anderen Basis-Pfad - Tippfehler im Link Merksatz: 404 heißt: Unter diesem Pfad wurde nichts gefunden. --- **500 bei der Fehlersuche** 500 bedeutet: interner Serverfehler. Mögliche Ursachen: - Fehler in der Anwendung - Datenbank nicht erreichbar - Konfigurationsfehler - fehlende Rechte - Programmfehler - Speicherproblem - Abhängigkeit nicht verfügbar Merksatz: 500 ist meist ein Problem der Anwendung oder des Servers. --- **502, 503 und 504 bei Reverse Proxys** Diese Fehler treten häufig bei Reverse Proxys auf. | Statuscode | typische Bedeutung | |---:|---| | 502 | Proxy bekommt keine gültige Antwort vom Backend | | 503 | Dienst aktuell nicht verfügbar | | 504 | Gateway wartet zu lange auf Backend | Typische Ursachen: - Backend läuft nicht - falscher Backend-Port - falsches Protokoll zum Backend - Backend überlastet - Timeout - falscher Container-Name - internes DNS-Problem - Firewall blockiert intern Merksatz: Bei 502, 503 und 504 Proxy und Backend prüfen. --- **API-Fehler auf Schicht 7** APIs haben typische Fehlerquellen. Prüfpunkte: - richtige URL? - richtige HTTP-Methode? - richtiger Content-Type? - gültiges JSON? - Authorization-Header vorhanden? - Token gültig? - Berechtigung vorhanden? - API-Version korrekt? - Rate Limit erreicht? - Pflichtfelder vorhanden? Typische Fehler: 400 Bad Request 401 Unauthorized 403 Forbidden 404 Not Found 405 Method Not Allowed 429 Too Many Requests 500 Internal Server Error Merksatz: API-Fehler mit Methode, Header, Body, Token und Statuscode prüfen. --- **Datenformatfehler** Schicht 7 ist oft eng mit Schicht 6 verbunden. Fehler können entstehen durch: - ungültiges JSON - ungültiges XML - falscher Content-Type - falsche Zeichencodierung - fehlende Pflichtfelder - falsches Datumsformat - falscher Dezimaltrenner - falsche Groß- und Kleinschreibung - unerwartete Sonderzeichen Merksatz: Anwendung versteht Daten nur, wenn Format und Inhalt passen. --- **Authentifizierungsfehler** Authentifizierung prüft: Wer bist du? Typische Fehler: - falscher Benutzername - falsches Passwort - Konto gesperrt - Konto deaktiviert - Passwort abgelaufen - MFA fehlt - Token ungültig - Zertifikat ungültig - falscher Identity Provider - Zeitabweichung Merksatz: Loginfehler sind nicht immer nur Passwortfehler. --- **Autorisierungsfehler** Autorisierung prüft: Was darfst du? Typische Fehler: - Benutzer nicht in richtiger Gruppe - Rolle fehlt - Berechtigung fehlt - Freigaberecht fehlt - Dateisystemrecht fehlt - API-Scope fehlt - Richtlinie blockiert - Mandant falsch - alte Session enthält alte Rechte Merksatz: Zugriff verweigert bedeutet: Rechte prüfen. --- **Session-Fehler** Sessions verbinden mehrere Anfragen zu einer Sitzung. Typische Fehlerbilder: Benutzer wird ständig ausgeloggt. Login-Schleife. Warenkorb wird vergessen. Session läuft sofort ab. Benutzer sieht falschen Zustand. Zugriff funktioniert nur in einem Browser. Mögliche Ursachen: - Cookie wird blockiert - Cookie-Domain falsch - Cookie-Pfad falsch - SameSite-Problem - Secure-Flag fehlt oder passt nicht - Zeitabweichung - Session-Speicher gestört - Load Balancer ohne Session-Stickiness Merksatz: Login-Schleifen sind oft Cookie- oder Session-Probleme. --- **TLS- und Zertifikatsfehler** Auch wenn TLS eher Schicht 6 zugeordnet wird, wirkt es stark auf Schicht 7. Typische Fehler: - Zertifikat abgelaufen - Name passt nicht - CA nicht vertrauenswürdig - Zwischenzertifikat fehlt - falsche Systemzeit - TLS-Version zu alt - Cipher Suite passt nicht - Reverse Proxy liefert falsches Zertifikat Merksatz: HTTPS-Probleme immer mit Zertifikat, Name und Zeit prüfen. --- **Mailprobleme auf Schicht 7** E-Mail nutzt mehrere Anwendungsschichtprotokolle. Typische Fehlerbilder: Mail kann nicht gesendet werden. Mail kann nicht empfangen werden. Mail landet im Spam. Mail kommt verzögert an. Mailclient kann sich nicht anmelden. Zertifikatswarnung im Mailclient. NDR wird erzeugt. Prüfpunkte: SMTP IMAP POP3 MX SPF DKIM DMARC TLS Authentifizierung Spamfilter Postfachgröße Mailserver-Logs Merksatz: Mailfehler mit Protokoll, DNS, Authentifizierung und Logs prüfen. --- **SMB-Fehler auf Schicht 7** SMB wird für Datei- und Druckerfreigaben genutzt. Typische Fehler: Freigabe nicht erreichbar. Zugriff verweigert. Netzlaufwerk verbindet nicht. Datei kann nicht gespeichert werden. Datei ist gesperrt. Benutzer sieht Freigabe nicht. Prüfpunkte: DNS-Name TCP 445 SMB-Dienst Freigabename Benutzerkonto Gruppe Freigaberecht Dateisystemrecht gespeicherte Anmeldedaten SMB-Version Merksatz: SMB-Fehler oft mit Name, Port, Anmeldung und Rechten prüfen. --- **LDAP-Fehler auf Schicht 7** LDAP wird für Verzeichnisdienste genutzt. Typische Fehler: Benutzer wird nicht gefunden. Anmeldung schlägt fehl. Gruppen werden nicht erkannt. Anwendung kann LDAP nicht verbinden. LDAPS-Zertifikat wird abgelehnt. Prüfpunkte: LDAP-Server Port 389 oder 636 Base-DN Bind-Benutzer Passwort Suchfilter Gruppenpfad Zertifikat bei LDAPS Firewall DNS Merksatz: LDAP-Fehler mit Bind, Base-DN, Filter und Zertifikat prüfen. --- **SNMP-Fehler auf Schicht 7** SNMP wird für Monitoring genutzt. Typische Fehler: Gerät wird als down angezeigt. Werte werden nicht gelesen. Interface-Daten fehlen. Traps kommen nicht an. Monitoring zeigt falsche Werte. Prüfpunkte: SNMP-Agent aktiv? richtige SNMP-Version? Community-String korrekt? SNMPv3-Benutzer korrekt? UDP 161 erlaubt? UDP 162 für Traps erlaubt? OID vorhanden? MIB korrekt? Zugriff vom Monitoring-Server erlaubt? Merksatz: SNMP-Fehler mit Version, Zugangsdaten, Port und OID prüfen. --- **NTP-Fehler auf Schicht 7** NTP synchronisiert Zeit. Typische Fehlerbilder: Systemzeit falsch. Zertifikate wirken ungültig. Kerberos-Anmeldung schlägt fehl. Logs passen zeitlich nicht zusammen. Monitoring-Zeitstempel stimmen nicht. Prüfpunkte: NTP-Server erreichbar? UDP 123 erlaubt? DNS-Name des Zeitservers korrekt? Zeitzone korrekt? Zeitquelle vertrauenswürdig? Zeitabweichung zu groß? VM-Zeitquelle korrekt? Merksatz: Falsche Zeit kann viele scheinbar andere Fehler verursachen. --- **SSH-Fehler auf Schicht 7** SSH dient sicherem Fernzugriff. Typische Fehler: Timeout Connection refused Permission denied Host-Key-Warnung falscher Schlüssel Benutzer darf nicht anmelden Dienst läuft nicht Prüfpunkte: TCP 22 erreichbar? SSH-Dienst aktiv? richtiger Benutzer? richtiger Schlüssel? richtige Dateirechte? Host-Key plausibel? Firewall erlaubt Zugriff? Loginmethode erlaubt? Merksatz: SSH-Fehler mit Port, Dienst, Benutzer, Schlüssel und Host-Key prüfen. --- **RDP-Fehler auf Schicht 7** RDP dient grafischem Fernzugriff. Typische Fehler: Verbindung nicht möglich. Anmeldung abgelehnt. RDP ist langsam. Sitzung wird getrennt. NLA-Fehler. Benutzer hat keine Berechtigung. Prüfpunkte: TCP 3389 erreichbar? Remote Desktop aktiviert? Benutzer berechtigt? NLA kompatibel? VPN verbunden? Firewall erlaubt Zugriff? Konto gesperrt? Server überlastet? Merksatz: RDP-Fehler mit Verbindung, Anmeldung, Berechtigung und Richtlinien prüfen. --- **DHCP-Fehler auf Schicht 7** DHCP ist ein Anwendungsschichtprotokoll, liefert aber Schicht-3-Konfiguration. Typische Fehler: Client bekommt keine IP. Client bekommt falsche IP. Client bekommt 169.254.x.x. Gateway ist falsch. DNS ist falsch. Manche VLANs funktionieren nicht. Prüfpunkte: DHCP-Server aktiv? DHCP-Scope vorhanden? Adressen frei? DHCP-Relay korrekt? VLAN korrekt? UDP 67/68 erlaubt? Rogue-DHCP vorhanden? DHCP-Optionen korrekt? Merksatz: DHCP-Fehler mit VLAN, Scope, Relay und Optionen prüfen. --- **Logs sind auf Schicht 7 besonders wichtig** Auf Schicht 7 liefern Logs oft die beste Information. Wichtige Logs: - Webserver-Logs - Anwendungslogs - Authentifizierungslogs - Mailserver-Logs - DNS-Logs - DHCP-Logs - LDAP-Logs - Reverse-Proxy-Logs - Firewall-Logs - Monitoring-Logs - Systemlogs Logs zeigen oft: - Statuscode - Fehlermeldung - Benutzer - Zeit - Quelle - Ziel - Pfad - angefragte Ressource - Authentifizierungsgrund - Backend-Fehler Merksatz: Ohne Logs bleibt Schicht-7-Fehlersuche oft ungenau. --- **Fehlermeldungen richtig lesen** Fehlermeldungen liefern wichtige Hinweise. Beispiele: | Meldung | mögliche Bedeutung | |---|---| | Unauthorized | nicht angemeldet oder Token ungültig | | Forbidden | keine Berechtigung | | Not Found | Ressource oder Pfad fehlt | | Bad Gateway | Proxy erreicht Backend nicht sauber | | Connection refused | Dienst nimmt Verbindung nicht an | | Timeout | keine Antwort innerhalb der Zeit | | Invalid credentials | Zugangsdaten falsch | | Certificate expired | Zertifikat abgelaufen | | Name mismatch | Zertifikat passt nicht zum Namen | Merksatz: Fehlermeldung nicht ignorieren, sondern technisch einordnen. --- **Fehler nur bei einem Benutzer** Wenn ein Problem nur bei einem Benutzer auftritt, prüft man eher: - Benutzerkonto - Passwort - MFA - Gruppenmitgliedschaften - Rollen - Berechtigungen - Session - gespeicherte Anmeldedaten - Clientprofil - Browsercache - lokale Einstellungen Merksatz: Einzelner Benutzer betroffen: Konto und Rechte prüfen. --- **Fehler bei allen Benutzern** Wenn alle Benutzer betroffen sind, prüft man eher: - Dienst läuft? - Server erreichbar? - DNS korrekt? - Zertifikat gültig? - Datenbank erreichbar? - Backend verfügbar? - zentrale Authentifizierung erreichbar? - Reverse Proxy korrekt? - Lizenz oder Ressourcenproblem? - allgemeine Störung? Merksatz: Alle betroffen: Dienst, Server oder zentrale Infrastruktur prüfen. --- **Fehler nur intern oder nur extern** Wenn ein Dienst intern funktioniert, extern aber nicht, prüft man: - externes DNS - Firewall - NAT - Reverse Proxy - Zertifikat - öffentliche IP - Portweiterleitung - Geo- oder Zugriffsbeschränkung Wenn ein Dienst extern funktioniert, intern aber nicht, prüft man: - internes DNS - Split DNS - Hairpin NAT - interne Firewall - Proxy-Einstellungen - Routing intern - Zertifikat und Hostname intern Merksatz: Intern und extern getrennt prüfen. --- **Fehler nur in einem Browser** Mögliche Ursachen: - Browsercache - Cookies - gespeicherte Zugangsdaten - Erweiterungen - CORS-Verhalten - alte Session - Zertifikatsspeicher - Proxy-Einstellungen - HSTS-Eintrag Merksatz: Browserabhängige Fehler oft mit Cache, Cookies und Erweiterungen prüfen. --- **Fehler nur auf einem Client** Mögliche Ursachen: - falsche DNS-Einstellung - falsche Systemzeit - veraltetes Zertifikat - lokale Firewall - Proxy-Einstellung - VPN aktiv oder inaktiv - falsche gespeicherte Anmeldedaten - veraltete Anwendung - defektes Profil Merksatz: Einzelner Client betroffen: lokale Einstellungen prüfen. --- **Fehler nach Änderung** Nach Änderungen prüft man zuerst, was geändert wurde. Beispiele: DNS geändert Zertifikat erneuert Passwort geändert Gruppe geändert Firewall angepasst Anwendung aktualisiert Reverse Proxy geändert Datenbank verschoben Container neu gestartet Port geändert Lizenz geändert Merksatz: Nach Änderung zuerst Änderung prüfen. --- **Systematische Schicht-7-Fehlersuche** Eine sinnvolle Reihenfolge: 1. Fehlermeldung genau lesen. 2. Betroffene Benutzer und Systeme eingrenzen. 3. Dienst und Protokoll bestimmen. 4. DNS und Hostname prüfen. 5. IP-Erreichbarkeit prüfen. 6. Port prüfen. 7. TLS oder Zertifikat prüfen. 8. Anwendung oder Dienst prüfen. 9. Anmeldung prüfen. 10. Berechtigung prüfen. 11. Datenformat oder Anfrage prüfen. 12. Logs prüfen. 13. letzte Änderungen prüfen. Merksatz: Erst eingrenzen, dann Schicht für Schicht prüfen. --- **Typische Werkzeuge** | Werkzeug | Zweck | |---|---| | Browser-Entwicklertools | HTTP-Status, Header, Cookies, Netzwerk | | curl | HTTP/API testen | | nslookup | DNS einfach prüfen | | dig | DNS detailliert prüfen | | ping | IP-Erreichbarkeit grob prüfen | | traceroute / tracert | Weg zum Ziel prüfen | | telnet / nc | TCP-Port testen | | openssl s_client | TLS-Zertifikat prüfen | | ssh -v | SSH-Verbindung detailliert prüfen | | Ereignisanzeige | Windows-Logs prüfen | | journalctl | Linux-Systemlogs prüfen | | Webserver-Logs | HTTP-Anfragen prüfen | | Mailserver-Logs | E-Mail-Zustellung prüfen | Merksatz: Das richtige Werkzeug hängt vom Dienst ab. --- **curl für Webfehler** curl kann HTTP-Antworten prüfen. Typische Prüfpunkte: - Statuscode - Header - Weiterleitung - TLS-Fehler - Antwortinhalt - API-Antwort Beispielgedanke: Was antwortet der Server wirklich? Merksatz: curl zeigt, was ein Webdienst tatsächlich zurückgibt. --- **Browser-Entwicklertools** Browser-Entwicklertools helfen bei Webproblemen. Sie zeigen unter anderem: - HTTP-Requests - HTTP-Responses - Statuscodes - Header - Cookies - Ladezeiten - CORS-Fehler - JavaScript-Fehler - blockierte Inhalte Merksatz: Browser-Entwicklertools sind wichtig für Web-Schicht-7-Fehler. --- **openssl s_client** Mit openssl s_client kann man TLS-Verbindungen prüfen. Typische Informationen: - Zertifikat - Zertifikatskette - TLS-Version - Cipher - Name und Zertifikat - Ablaufdatum Besonders hilfreich bei: - HTTPS - LDAPS - IMAPS - SMTPS - POP3S Merksatz: TLS-Probleme mit Zertifikat und Kette prüfen. --- **Paketmitschnitt auf Schicht 7** Ein Paketmitschnitt kann helfen, wenn Logs nicht ausreichen. Man kann sehen: - DNS-Anfragen - DHCP-DORA - TCP-Verbindungsaufbau - TLS-Handshake - unverschlüsselte Protokollinhalte - Fehlercodes - Wiederholungen - Timeouts Wichtig: Bei verschlüsselten Verbindungen sieht man Inhalte nicht einfach im Klartext. Merksatz: Mitschnitt zeigt Verkehr, aber TLS schützt Inhalte. --- **Schicht-7-Fehler und Sicherheit** Viele Schicht-7-Fehler haben Sicherheitsbezug. Beispiele: - falsche Rechte - schwache Authentifizierung - unsichere Cookies - offene Adminbereiche - veraltete Webanwendung - unsicheres FTP - Telnet statt SSH - fehlende MFA - falsche CORS-Konfiguration - Tokens in URLs - zu genaue Fehlermeldungen Merksatz: Anwendungsschicht ist häufig Angriffsziel. --- **Was Schicht-7-Fehlersuche nicht ersetzt** Schicht-7-Fehlersuche ersetzt nicht: - Prüfung der Verkabelung - VLAN-Prüfung - Routing-Prüfung - Firewall-Prüfung - Portprüfung - Zertifikatsprüfung - Berechtigungskonzept - Sicherheitskonzept - Backup-Konzept - Monitoring Sie ergänzt diese Prüfungen. Merksatz: Schicht 7 ist nur ein Teil der gesamten Fehlersuche. --- **Typische IHK-Fragen** In AP1 und AP2 kann zum Beispiel gefragt werden: - Warum reicht ein erfolgreicher Ping nicht aus? - Warum reicht ein offener Port nicht aus? - Was prüft man bei HTTP 404? - Was prüft man bei HTTP 500? - Was bedeutet HTTP 401? - Was bedeutet HTTP 403? - Warum kann ein DNS-Fehler wie ein Internetproblem wirken? - Warum kann ein falsches Zertifikat durch DNS entstehen? - Wie grenzt man Anmeldeprobleme ein? - Wie grenzt man Berechtigungsprobleme ein? - Warum sind Logs bei Schicht-7-Problemen wichtig? - Welche Rolle spielt der Reverse Proxy bei Webfehlern? - Warum kann ein Dienst trotz erreichbarem Server nicht funktionieren? --- **Typische Prüfungsfallen** Ping prüft nicht die Anwendung. Offener Port heißt nicht, dass der Dienst korrekt funktioniert. HTTP-Statuscodes gehören zur Anwendungsschicht. 401 bedeutet nicht authentifiziert. 403 bedeutet nicht berechtigt. 404 bedeutet Ressource nicht gefunden. 500 bedeutet interner Serverfehler. 502 deutet oft auf Proxy-Backend-Problem. DNS gehört zu Schicht 7. DHCP gehört zu Schicht 7, auch wenn es IP-Konfiguration verteilt. Mailprobleme sind oft DNS-, TLS- oder Spamfilterprobleme. SMB-Probleme sind oft Rechte- oder Anmeldeprobleme. LDAP-Probleme sind oft Base-DN-, Bind- oder Filterprobleme. NTP-Probleme können Zertifikats- und Loginfehler verursachen. Schicht 7 braucht Logs. --- **Wichtige Begriffe kurz erklärt** | Begriff | Kurze Erklärung | |---|---| | Schicht-7-Fehler | Fehler im Dienst oder Anwendungsprotokoll | | Dienst | bereitgestellte Netzwerkfunktion | | Statuscode | Antwortcode eines Protokolls | | HTTP 401 | nicht authentifiziert | | HTTP 403 | nicht berechtigt | | HTTP 404 | Ressource nicht gefunden | | HTTP 500 | interner Serverfehler | | HTTP 502 | Bad Gateway | | Backend | interner Ziel-Dienst | | Reverse Proxy | vorgelagerter Webserver | | Authentifizierung | Identität prüfen | | Autorisierung | Rechte prüfen | | Session | Sitzung zwischen Client und Anwendung | | Token | digitaler Zugriffsnachweis | | Log | Protokolldatei mit Ereignissen | | API | Schnittstelle zwischen Anwendungen | | Content-Type | Datenformat im HTTP-Body | | DNS-Cache | zwischengespeicherte DNS-Antwort | --- **IHK-sichere Kurzformulierung** Fehlersuche auf OSI-Schicht 7 betrifft die Anwendungsschicht und damit konkrete Dienste und Protokolle wie HTTP, DNS, DHCP, SMTP, SMB, LDAP, SNMP, NTP, SSH, RDP und APIs. Dabei reicht es nicht aus, nur IP-Erreichbarkeit oder offene Ports zu prüfen. Ein Dienst kann trotz erreichbarem Server und offenem Port fehlerhaft antworten. Deshalb prüft man auf Schicht 7 insbesondere Dienststatus, Protokoll, Hostname, URL, HTTP-Statuscodes, Anmeldung, Berechtigungen, Datenformat, Zertifikate, Reverse Proxy, Backend und Logs. Schicht-7-Fehler zeigen sich häufig als falsche DNS-Antworten, HTTP-Fehler, Loginprobleme, Zugriff verweigert, Mailprobleme oder fehlerhafte API-Antworten. --- **Merksätze** Schicht 7 = Anwendungsschicht. Schicht 7 prüft den konkreten Dienst. Ping prüft nicht die Anwendung. Offener Port heißt nicht: Anwendung funktioniert. Dienst läuft nicht immer, nur weil Server erreichbar ist. Falsches Protokoll erzeugt Fehler. Falscher Hostname kann falsches Zertifikat liefern. DNS-Probleme sind Schicht-7-Probleme. HTTP-Statuscodes helfen bei Webfehlern. 401 = nicht authentifiziert. 403 = nicht berechtigt. 404 = nicht gefunden. 500 = interner Serverfehler. 502 = Proxy-Backend-Problem. 503 = Dienst nicht verfügbar. 504 = Gateway Timeout. API-Fehler mit Methode, Header, Body und Token prüfen. Loginfehler = Authentifizierung prüfen. Zugriff verweigert = Autorisierung prüfen. Login-Schleife = Session und Cookies prüfen. Mailfehler mit DNS, SMTP, IMAP, TLS und Spamfilter prüfen. SMB-Fehler mit Name, Port, Anmeldung und Rechten prüfen. LDAP-Fehler mit Bind, Base-DN und Filter prüfen. SNMP-Fehler mit Version, Zugangsdaten und OID prüfen. NTP-Fehler können viele Folgefehler erzeugen. Logs sind bei Schicht 7 besonders wichtig. Erst eingrenzen, dann Schicht für Schicht prüfen. # 10.11 Merksätze und Prüfungswissen zu OSI-Schicht 7 Diese Seite fasst die wichtigsten Inhalte zur OSI-Schicht 7 zusammen. OSI-Schicht 7 heißt: Anwendungsschicht Die Hauptaufgabe von Schicht 7 ist: Netzwerkdienste für Anwendungen bereitstellen. Typische Protokolle und Dienste sind: - HTTP - HTTPS - DNS - DHCP - SMTP - POP3 - IMAP - FTP - SFTP - FTPS - SMB - LDAP - SNMP - NTP - SSH - RDP - Telnet - APIs Merksatz: Schicht 7 = Netzwerkdienste für Anwendungen. --- **Grundidee von Schicht 7** Schicht 7 ist die oberste Schicht des OSI-Modells. Sie ist die Schicht, die Anwendungen am nächsten ist. Wichtig: Die Anwendungsschicht ist nicht einfach das Programm selbst. Besser: Anwendungen nutzen Protokolle der Anwendungsschicht. Beispiel: Browser = Anwendung HTTP / HTTPS = Protokolle der Anwendungsschicht Merksatz: Schicht 7 beschreibt Protokolle und Dienste, die Anwendungen für Netzwerkkommunikation verwenden. --- **Schicht 7 im OSI-Modell** | Schicht | Name | Kerngedanke | |---:|---|---| | 7 | Anwendungsschicht | Netzwerkdienste für Anwendungen | | 6 | Darstellungsschicht | Daten darstellen, codieren, komprimieren, verschlüsseln | | 5 | Sitzungsschicht | Sitzungen aufbauen, verwalten und beenden | | 4 | Transportschicht | TCP, UDP, Ports | | 3 | Vermittlungsschicht / Netzwerkschicht | IP, Routing | | 2 | Sicherungsschicht | Frames, MAC-Adressen, VLAN | | 1 | Bitübertragungsschicht | Bits, Signale, Medien | Merksatz: Schicht 7 nutzt alle darunterliegenden Schichten. --- **Schicht 7 und Schicht 4 unterscheiden** Ein häufiger Prüfungsfehler ist, Ports und Protokolle zu vermischen. Beispiel: TCP 443 = Schicht 4 HTTPS = Schicht 7 mit TLS-Bezug Oder: UDP 53 / TCP 53 = Schicht 4 DNS = Schicht 7 Merksatz: Port = Schicht 4. Dienstprotokoll = Schicht 7. --- **Wichtige Standardports** | Dienst | Protokoll | typischer Port | |---|---|---:| | HTTP | TCP | 80 | | HTTPS | TCP | 443 | | DNS | UDP / TCP | 53 | | DHCP-Server | UDP | 67 | | DHCP-Client | UDP | 68 | | SMTP | TCP | 25 | | Submission | TCP | 587 | | SMTPS | TCP | 465 | | POP3 | TCP | 110 | | POP3S | TCP | 995 | | IMAP | TCP | 143 | | IMAPS | TCP | 993 | | FTP | TCP | 21 | | SFTP | TCP | 22 | | SSH | TCP | 22 | | Telnet | TCP | 23 | | SMB | TCP | 445 | | LDAP | TCP / UDP | 389 | | LDAPS | TCP | 636 | | SNMP | UDP | 161 | | SNMP-Trap | UDP | 162 | | NTP | UDP | 123 | | RDP | TCP | 3389 | Merksatz: Standardports helfen bei Prüfung und Fehlersuche, gehören aber zur Transportschicht. --- **HTTP und HTTPS** HTTP steht für: Hypertext Transfer Protocol HTTPS steht für: Hypertext Transfer Protocol Secure HTTP wird für Webkommunikation genutzt. HTTPS ist: HTTP über TLS Typische Ports: HTTP: TCP 80 HTTPS: TCP 443 Merksatz: HTTP = Web ohne TLS. HTTPS = Web mit TLS. --- **HTTP-Request und HTTP-Response** HTTP arbeitet mit: Request Response Request: Anfrage des Clients Response: Antwort des Servers Beispiel: Browser fordert Webseite an. Webserver liefert Antwort. Merksatz: HTTP arbeitet mit Anfrage und Antwort. --- **HTTP-Methoden** Wichtige HTTP-Methoden: | Methode | Bedeutung | |---|---| | GET | Daten abrufen | | POST | Daten senden oder erstellen | | PUT | Ressource vollständig ersetzen | | PATCH | Ressource teilweise ändern | | DELETE | Ressource löschen | | HEAD | nur Kopfzeilen abrufen | | OPTIONS | Möglichkeiten abfragen | Merksatz: GET liest. POST sendet. PUT ersetzt. PATCH ändert teilweise. DELETE löscht. --- **HTTP-Statuscodes** HTTP-Statuscodes zeigen das Ergebnis einer Anfrage. | Bereich | Bedeutung | |---|---| | 1xx | Information | | 2xx | Erfolg | | 3xx | Weiterleitung | | 4xx | Clientfehler | | 5xx | Serverfehler | Wichtige Beispiele: | Statuscode | Bedeutung | |---:|---| | 200 | OK | | 301 | dauerhaft weitergeleitet | | 302 | vorübergehend weitergeleitet | | 400 | fehlerhafte Anfrage | | 401 | nicht authentifiziert | | 403 | verboten | | 404 | nicht gefunden | | 500 | interner Serverfehler | | 502 | Bad Gateway | | 503 | Dienst nicht verfügbar | | 504 | Gateway Timeout | Merksatz: 2xx = Erfolg. 4xx = Clientproblem. 5xx = Serverproblem. --- **401 und 403 unterscheiden** 401 bedeutet: nicht authentifiziert Der Benutzer ist nicht angemeldet oder die Anmeldung ist ungültig. 403 bedeutet: verboten Der Benutzer ist möglicherweise angemeldet, hat aber keine Berechtigung. Merksatz: 401 = Wer bist du? 403 = Du darfst das nicht. --- **DNS** DNS steht für: Domain Name System DNS löst Namen in IP-Adressen auf. Beispiel: www.example.com → IP-Adresse DNS gehört zur Anwendungsschicht, nutzt aber UDP oder TCP auf Port 53. Merksatz: DNS = Name zu IP-Adresse. --- **Wichtige DNS-Records** | Record | Bedeutung | |---|---| | A | Name zu IPv4-Adresse | | AAAA | Name zu IPv6-Adresse | | CNAME | Alias auf anderen Namen | | MX | Mailserver einer Domain | | NS | zuständiger Nameserver | | TXT | Textinformationen | | PTR | Reverse-DNS-Eintrag | | SRV | Dienststandort | | SOA | Verwaltungsdaten einer Zone | Merksatz: A = IPv4. AAAA = IPv6. MX = Mailserver. PTR = Reverse Lookup. --- **Forward Lookup und Reverse Lookup** Forward Lookup bedeutet: Name zu IP-Adresse Beispiel: server01.firma.local → 192.168.10.20 Reverse Lookup bedeutet: IP-Adresse zu Name Beispiel: 192.168.10.20 → server01.firma.local Merksatz: Forward = Name zu IP. Reverse = IP zu Name. --- **DNS-TTL** TTL steht für: Time To Live Die TTL gibt an, wie lange ein DNS-Eintrag zwischengespeichert werden darf. Folge: DNS-Änderungen sind nicht immer sofort überall sichtbar. Merksatz: TTL steuert DNS-Caching. --- **DHCP** DHCP steht für: Dynamic Host Configuration Protocol DHCP verteilt automatisch Netzwerkkonfigurationen. Ein Client kann erhalten: - IP-Adresse - Subnetzmaske - Standard-Gateway - DNS-Server - Domain-Suffix - Lease-Zeit DHCP gehört zur Anwendungsschicht, liefert aber wichtige Schicht-3-Konfiguration. Merksatz: DHCP = automatische IP-Konfiguration. --- **DHCP-DORA** Der klassische DHCP-Ablauf heißt: DORA DORA steht für: Discover Offer Request Acknowledge Ablauf: Client sucht DHCP-Server. Server bietet Konfiguration an. Client fordert Angebot an. Server bestätigt Vergabe. Merksatz: DHCP-Ablauf = DORA. --- **DHCP-Relay** DHCP startet häufig mit Broadcast. Router leiten Broadcasts normalerweise nicht einfach weiter. Wenn DHCP-Client und DHCP-Server in verschiedenen Netzen liegen, braucht man: DHCP-Relay Bei manchen Herstellern heißt das: IP Helper Address Merksatz: DHCP-Relay bringt DHCP-Anfragen über Netzgrenzen. --- **APIPA** Wenn ein Windows-Client keine DHCP-Adresse erhält, kann er sich selbst eine Adresse aus diesem Bereich geben: 169.254.0.0/16 Das nennt man: APIPA Typisches Fehlerbild: Client hat 169.254.x.x Mögliche Ursache: DHCP fehlgeschlagen Merksatz: 169.254.x.x deutet oft auf DHCP-Probleme hin. --- **E-Mail-Protokolle** Die wichtigsten E-Mail-Protokolle sind: SMTP POP3 IMAP Grundregel: SMTP sendet. POP3 und IMAP empfangen. Merksatz: SMTP raus. POP3/IMAP rein. --- **SMTP** SMTP steht für: Simple Mail Transfer Protocol SMTP wird verwendet für: - E-Mail senden - E-Mail zwischen Mailservern weiterleiten Typische Ports: TCP 25: Mailserver zu Mailserver TCP 587: Submission, also authentifiziertes Einreichen durch Clients TCP 465: SMTPS, also SMTP direkt über TLS Merksatz: SMTP = E-Mail senden und transportieren. --- **POP3** POP3 steht für: Post Office Protocol Version 3 POP3 dient zum Abrufen von E-Mails. Typische Ports: POP3: TCP 110 POP3S: TCP 995 POP3 lädt E-Mails eher einfach ab und ist weniger gut für mehrere Geräte geeignet. Merksatz: POP3 = E-Mail abrufen. --- **IMAP** IMAP steht für: Internet Message Access Protocol IMAP dient zum Abrufen und Verwalten von E-Mails auf dem Server. Typische Ports: IMAP: TCP 143 IMAPS: TCP 993 IMAP eignet sich gut für mehrere Geräte, weil E-Mails und Ordner synchronisiert werden. Merksatz: IMAP = E-Mails auf dem Server verwalten und synchronisieren. --- **SPF, DKIM und DMARC** Diese Verfahren helfen bei E-Mail-Sicherheit. | Verfahren | Hauptaufgabe | |---|---| | SPF | legt erlaubte sendende Server fest | | DKIM | signiert E-Mails kryptografisch | | DMARC | legt Umgang mit SPF-/DKIM-Fehlern fest | Merksatz: SPF erlaubt. DKIM signiert. DMARC entscheidet. --- **FTP, SFTP und FTPS** Diese Protokolle dienen der Dateiübertragung. | Protokoll | Bedeutung | Sicherheit | |---|---|---| | FTP | File Transfer Protocol | klassisch unverschlüsselt | | SFTP | SSH File Transfer Protocol | über SSH verschlüsselt | | FTPS | FTP mit TLS | über TLS geschützt | Typische Ports: FTP: TCP 21 SFTP: TCP 22 FTPS implizit: TCP 990 Merksatz: FTP unverschlüsselt. SFTP über SSH. FTPS über TLS. --- **SFTP und FTPS nicht verwechseln** SFTP ist: Dateiübertragung über SSH FTPS ist: FTP mit TLS Das sind unterschiedliche Protokolle. Merksatz: SFTP ist nicht FTPS. --- **SMB** SMB steht für: Server Message Block SMB dient für: - Datei-Freigaben - Drucker-Freigaben - Netzlaufwerke - NAS-Freigaben - Windows-Freigaben Typischer Port: TCP 445 Beispiel für einen UNC-Pfad: \\server01\freigabe Merksatz: SMB = Datei- und Druckerfreigaben. --- **SMB-Berechtigungen** Bei SMB sind meist zwei Ebenen wichtig: Freigabeberechtigungen Dateisystemberechtigungen Beispiel: Freigabe erlaubt Vollzugriff. Dateisystem erlaubt nur Lesen. Ergebnis: Benutzer kann nur lesen. Merksatz: Die strengere Berechtigung begrenzt den Zugriff. --- **LDAP** LDAP steht für: Lightweight Directory Access Protocol LDAP dient dem Zugriff auf Verzeichnisdienste. Typische Nutzung: - Benutzer suchen - Gruppen prüfen - Anmeldungen unterstützen - zentrale Identitätsinformationen abfragen Wichtige Ports: LDAP: TCP/UDP 389 LDAPS: TCP 636 Merksatz: LDAP = Zugriff auf Verzeichnisdienste. --- **Active Directory und LDAP** Active Directory nutzt LDAP, ist aber nicht nur LDAP. Active Directory nutzt außerdem unter anderem: - DNS - Kerberos - Gruppenrichtlinien - Verzeichnisdatenbank - Replikation Merksatz: LDAP ist ein wichtiger Teil von Active Directory, aber nicht das ganze Active Directory. --- **SNMP** SNMP steht für: Simple Network Management Protocol SNMP dient zur Überwachung und Verwaltung von Netzwerkgeräten. Typische Geräte: - Switches - Router - Firewalls - Drucker - Server - USV - Access Points Wichtige Ports: SNMP-Abfrage: UDP 161 SNMP-Trap: UDP 162 Merksatz: SNMP = Netzwerkgeräte überwachen. --- **SNMPv3** SNMPv3 ist sicherer als ältere SNMP-Versionen. SNMPv3 kann bieten: - Authentifizierung - Verschlüsselung - Integritätsschutz - Benutzerkonzept Ältere Varianten mit Community-String sind weniger sicher. Merksatz: SNMPv3 bevorzugen. --- **NTP** NTP steht für: Network Time Protocol NTP synchronisiert die Uhrzeit von Systemen. Typischer Port: UDP 123 Korrekte Zeit ist wichtig für: - Zertifikate - Kerberos - Logs - Monitoring - Fehlersuche - Backups - Authentifizierung Merksatz: NTP = Zeitsynchronisation. --- **SSH** SSH steht für: Secure Shell SSH dient sicherer Fernadministration über eine Kommandozeile. Typischer Port: TCP 22 SSH wird häufig genutzt für: - Linux-Server - Netzwerkgeräte - Firewalls - NAS-Systeme - SFTP - Automatisierung Merksatz: SSH = sicherer Fernzugriff auf die Shell. --- **RDP** RDP steht für: Remote Desktop Protocol RDP dient grafischem Fernzugriff. Typischer Port: TCP 3389 RDP ist besonders bei Windows-Systemen verbreitet. Wichtig: RDP sollte nicht ungeschützt direkt aus dem Internet erreichbar sein. Merksatz: RDP = grafischer Fernzugriff. --- **Telnet** Telnet ist ein älteres Fernzugriffsprotokoll. Typischer Port: TCP 23 Problem: Telnet ist unverschlüsselt. Benutzername, Passwort und Befehle können im Klartext übertragen werden. Merksatz: Telnet vermeiden. SSH verwenden. --- **Authentifizierung** Authentifizierung bedeutet: Identität prüfen. Frage: Wer bist du? Beispiele: - Benutzername und Passwort - SSH-Schlüssel - Zertifikat - Smartcard - MFA-Code - Token Merksatz: Authentifizierung = Identität prüfen. --- **Autorisierung** Autorisierung bedeutet: Rechte prüfen. Frage: Was darfst du? Beispiele: - Datei lesen - Datei ändern - Adminbereich öffnen - API verwenden - Benutzer anlegen - Server verwalten Merksatz: Autorisierung = Rechte prüfen. --- **Authentifizierung und Autorisierung unterscheiden** | Begriff | Frage | Beispiel | |---|---|---| | Authentifizierung | Wer bist du? | Benutzer meldet sich an | | Autorisierung | Was darfst du? | Benutzer darf bestimmten Ordner öffnen | Merksatz: Angemeldet bedeutet nicht automatisch berechtigt. --- **MFA** MFA steht für: Multi-Faktor-Authentifizierung Dabei werden mehrere Faktoren kombiniert. Beispiele: - Passwort - Smartphone-App - Hardware-Token - Fingerabdruck - Smartcard Merksatz: MFA schützt zusätzlich, wenn ein Passwort gestohlen wurde. --- **SSO** SSO steht für: Single Sign-on SSO bedeutet: Einmal anmelden, mehrere Dienste nutzen. Typische Bestandteile: - Identity Provider - Service Provider - Token - zentrale Identität Merksatz: SSO = einmal anmelden, mehrere Dienste nutzen. --- **Token und Session** Token: digitaler Zugriffsnachweis Session: Sitzung zwischen Client und Anwendung Session-Cookie: Cookie zur Zuordnung einer Sitzung Wichtig: Tokens und Session-Cookies müssen geschützt werden, weil sie Zugriff ermöglichen können. Merksatz: Token und Session-Cookie wie Zugangsdaten schützen. --- **Least Privilege** Least Privilege bedeutet: Benutzer und Dienste erhalten nur die Rechte, die sie wirklich benötigen. Beispiel: Dienst braucht nur Leserechte. Dann bekommt er keine Schreibrechte. Merksatz: Nur so viele Rechte wie nötig, so wenige wie möglich. --- **Typische Schicht-7-Fehler** Typische Fehler auf Schicht 7 sind: - DNS löst falsch auf - HTTP 404 - HTTP 500 - HTTP 502 - Login funktioniert nicht - Zugriff verweigert - API lehnt Anfrage ab - falscher Content-Type - ungültiges JSON - Mail kommt nicht an - Mail landet im Spam - SMB-Freigabe verweigert Zugriff - LDAP-Bind schlägt fehl - SNMP-Werte fehlen - NTP synchronisiert nicht - SSH Permission Denied - RDP-Anmeldung abgelehnt Merksatz: Schicht-7-Fehler betreffen Dienst, Inhalt, Anmeldung oder Rechte. --- **Fehlersuche auf Schicht 7** Eine sinnvolle Reihenfolge: 1. Fehlermeldung genau lesen. 2. Betroffene Benutzer und Systeme eingrenzen. 3. Dienst und Protokoll bestimmen. 4. DNS und Hostname prüfen. 5. IP-Erreichbarkeit prüfen. 6. Port prüfen. 7. TLS oder Zertifikat prüfen. 8. Dienststatus prüfen. 9. Anmeldung prüfen. 10. Berechtigung prüfen. 11. Datenformat prüfen. 12. Logs prüfen. 13. letzte Änderungen prüfen. Merksatz: Erst eingrenzen, dann Schicht für Schicht prüfen. --- **Wichtigste Abgrenzung zu unteren Schichten** | Aussage | Einordnung | |---|---| | Kabel steckt nicht | Schicht 1 | | VLAN falsch | Schicht 2 | | Gateway falsch | Schicht 3 | | Port blockiert | Schicht 4 | | TLS-Zertifikat ungültig | Schicht 6 | | HTTP 404 | Schicht 7 | | Login falsch | Schicht 7 | | Rechte fehlen | Schicht 7 | | DNS-Record falsch | Schicht 7 | Merksatz: Schicht 7 beginnt dort, wo der konkrete Dienstinhalt geprüft wird. --- **Typische Prüfungsfallen** Schicht 7 heißt Anwendungsschicht. Schicht 7 ist nicht einfach das Programm selbst. Anwendungen nutzen Schicht-7-Protokolle. Port gehört zu Schicht 4. Dienstprotokoll gehört zu Schicht 7. DNS gehört zu Schicht 7. DHCP gehört zu Schicht 7, obwohl es IP-Konfiguration verteilt. HTTP gehört zu Schicht 7. HTTPS ist HTTP über TLS. SMTP sendet E-Mails. POP3 und IMAP empfangen E-Mails. POP3 lädt eher herunter. IMAP synchronisiert besser. FTP ist klassisch unverschlüsselt. SFTP ist nicht FTPS. SMB nutzt TCP 445. LDAP ist nicht das ganze Active Directory. SNMPv3 ist sicherer als SNMPv1/v2c. NTP-Probleme können Zertifikats- und Loginprobleme verursachen. SSH ist sicherer als Telnet. RDP nicht ungeschützt ins Internet öffnen. Authentifizierung ist nicht Autorisierung. Anmeldung bedeutet nicht automatisch Berechtigung. Offener Port bedeutet nicht automatisch, dass die Anwendung funktioniert. --- **Wichtige Begriffe kurz erklärt** | Begriff | Kurze Erklärung | |---|---| | Anwendungsschicht | OSI-Schicht 7 | | Dienst | Netzwerkfunktion für Anwendungen | | Protokoll | Regelwerk für Kommunikation | | HTTP | Webprotokoll | | HTTPS | HTTP über TLS | | DNS | Namensauflösung | | DHCP | automatische IP-Konfiguration | | SMTP | E-Mail senden | | POP3 | E-Mail abrufen | | IMAP | E-Mail abrufen und verwalten | | FTP | klassische Dateiübertragung | | SFTP | Dateiübertragung über SSH | | FTPS | FTP mit TLS | | SMB | Datei- und Druckerfreigaben | | LDAP | Verzeichnisdienstzugriff | | SNMP | Netzwerkmanagement | | NTP | Zeitsynchronisation | | SSH | sicherer Shell-Zugriff | | RDP | grafischer Fernzugriff | | Telnet | altes unverschlüsseltes Fernzugriffsprotokoll | | API | Schnittstelle zwischen Anwendungen | | Authentifizierung | Identität prüfen | | Autorisierung | Rechte prüfen | | MFA | Multi-Faktor-Authentifizierung | | SSO | Single Sign-on | | Token | digitaler Zugriffsnachweis | | Session | Sitzung zwischen Client und Anwendung | | Least Privilege | nur notwendige Rechte vergeben | --- **IHK-sichere Gesamtformulierung** Die Anwendungsschicht ist Schicht 7 des OSI-Modells. Sie stellt Netzwerkdienste für Anwendungen bereit. Typische Protokolle sind HTTP, HTTPS, DNS, DHCP, SMTP, POP3, IMAP, FTP, SFTP, FTPS, SMB, LDAP, SNMP, NTP, SSH, RDP und Telnet. Die Anwendungsschicht ist nicht das Programm selbst, sondern beschreibt die Protokolle und Dienste, die Anwendungen zur Kommunikation verwenden. Ports gehören zur Transportschicht, während die eigentlichen Dienstprotokolle zur Anwendungsschicht gehören. Fehler auf Schicht 7 betreffen häufig DNS, HTTP-Statuscodes, Anmeldungen, Berechtigungen, APIs, Datenformate, Maildienste, Dateifreigaben oder Dienstlogs. --- **Wichtigste Merksätze** Schicht 7 = Anwendungsschicht. Schicht 7 = Netzwerkdienste für Anwendungen. Anwendung nutzt Protokoll. Protokoll gehört zu Schicht 7. Port gehört zu Schicht 4. HTTP = Webprotokoll. HTTPS = HTTP über TLS. DNS = Name zu IP-Adresse. DHCP = automatische IP-Konfiguration. SMTP sendet. POP3 ruft ab. IMAP synchronisiert. FTP ist klassisch unverschlüsselt. SFTP läuft über SSH. FTPS nutzt TLS. SMB = Datei- und Druckerfreigaben. LDAP = Verzeichnisdienstzugriff. SNMP = Netzwerküberwachung. NTP = Zeitsynchronisation. SSH = sicherer Fernzugriff. RDP = grafischer Fernzugriff. Telnet ist unsicher. Authentifizierung = Wer bist du? Autorisierung = Was darfst du? Anmeldung ist nicht gleich Berechtigung. MFA erhöht die Sicherheit. Least Privilege immer beachten. Offener Port heißt nicht: Anwendung funktioniert. Schicht-7-Fehler mit Dienst, Protokoll, Anmeldung, Rechten, Daten und Logs prüfen.