Translated ['src/network-services-pentesting/pentesting-voip/basic-voip-

src/network-services-pentesting/pentesting-voip/basic-voip-protocols/sip-session-initiation-protocol.md

@@ -2,74 +2,74 @@
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-## Grundinformationen
+## Grundlegende Informationen
 
-SIP (Session Initiation Protocol) ist ein **Signalisierungs- und Anrufsteuerungsprotokoll**, das weit verbreitet ist, um Multimedia-Sitzungen, einschließlich Sprache, Video und Instant Messaging, über IP-Netzwerke zu etablieren, zu modifizieren und zu beenden. Entwickelt von der **Internet Engineering Task Force (IETF)**, ist SIP in **RFC 3261** definiert und hat sich zum De-facto-Standard für VoIP und einheitliche Kommunikation entwickelt.
+SIP (Session Initiation Protocol) ist ein **Signalisierungs- und Anrufsteuerungsprotokoll**, das weit verbreitet für das Einrichten, Ändern und Beenden von Multimedia-Sitzungen, einschließlich Sprache, Video und Instant Messaging, über IP-Netzwerke verwendet wird. Entwickelt von der **Internet Engineering Task Force (IETF)**, ist SIP in **RFC 3261** definiert und zum de-facto Standard für VoIP und Unified Communications geworden.
 
-Einige wichtige Merkmale von SIP sind:
+Zu den wichtigsten Merkmalen von SIP gehören:
 
-1. **Textbasiertes Protokoll**: SIP ist ein textbasiertes Protokoll, das es menschenlesbar und einfacher zu debuggen macht. Es basiert auf einem Anfrage-Antwort-Modell, ähnlich wie HTTP, und verwendet Methoden wie INVITE, ACK, BYE und CANCEL zur Steuerung von Anruf-Sitzungen.
-2. **Skalierbarkeit und Flexibilität**: SIP ist hoch skalierbar und kann sowohl in kleinen als auch in großen Unternehmens- und Carrier-Umgebungen eingesetzt werden. Es kann leicht mit neuen Funktionen erweitert werden, was es anpassungsfähig für verschiedene Anwendungsfälle und Anforderungen macht.
-3. **Interoperabilität**: Die weit verbreitete Annahme und Standardisierung von SIP gewährleisten eine bessere Interoperabilität zwischen verschiedenen Geräten, Anwendungen und Dienstanbietern und fördern nahtlose Kommunikation über verschiedene Plattformen hinweg.
-4. **Modulares Design**: SIP arbeitet mit anderen Protokollen wie **RTP (Real-time Transport Protocol)** für die Medienübertragung und **SDP (Session Description Protocol)** zur Beschreibung von Multimedia-Sitzungen. Dieses modulare Design ermöglicht eine größere Flexibilität und Kompatibilität mit verschiedenen Medientypen und Codecs.
-5. **Proxy- und Weiterleitungsserver**: SIP kann Proxy- und Weiterleitungsserver verwenden, um die Anrufweiterleitung zu erleichtern und erweiterte Funktionen wie Anrufweiterleitung, Anrufübertragung und Voicemail-Dienste bereitzustellen.
-6. **Präsenz und Instant Messaging**: SIP ist nicht auf Sprach- und Video-Kommunikation beschränkt. Es unterstützt auch Präsenz und Instant Messaging, was eine breite Palette von Anwendungen für einheitliche Kommunikation ermöglicht.
+1. **Text-based Protocol**: SIP ist ein textbasiertes Protokoll, wodurch es menschenlesbar und leichter zu debuggen ist. Es basiert auf einem Request-Response-Modell, ähnlich HTTP, und verwendet Methoden wie INVITE, ACK, BYE und CANCEL zur Steuerung von Anruf-Sitzungen.
+2. **Scalability and Flexibility**: SIP ist hoch skalierbar und kann in kleinen Installationen ebenso wie in großen Unternehmens- und Carrier-Umgebungen eingesetzt werden. Es lässt sich leicht mit neuen Funktionen erweitern, was es an verschiedene Anwendungsfälle und Anforderungen anpassbar macht.
+3. **Interoperability**: Die weit verbreitete Nutzung und Standardisierung von SIP sorgt für bessere Interoperabilität zwischen verschiedenen Geräten, Anwendungen und Dienstanbietern und fördert nahtlose Kommunikation über unterschiedliche Plattformen.
+4. **Modular Design**: SIP arbeitet mit anderen Protokollen wie **RTP (Real-time Transport Protocol)** für die Medienübertragung und **SDP (Session Description Protocol)** zur Beschreibung von Multimedia-Sitzungen. Dieses modulare Design ermöglicht größere Flexibilität und Kompatibilität mit verschiedenen Medientypen und Codecs.
+5. **Proxy and Redirect Servers**: SIP kann Proxy- und Redirect-Server verwenden, um die Anrufweiterleitung zu erleichtern und erweiterte Funktionen wie Call Forwarding, Call Transfer und Voicemail-Dienste bereitzustellen.
+6. **Presence and Instant Messaging**: SIP ist nicht auf Sprach- und Videokommunikation beschränkt. Es unterstützt auch Presence und Instant Messaging und ermöglicht eine breite Palette von Unified-Communication-Anwendungen.
 
-Trotz seiner vielen Vorteile kann SIP komplex zu konfigurieren und zu verwalten sein, insbesondere bei der Behandlung von NAT-Traversal und Firewall-Problemen. Dennoch machen seine Vielseitigkeit, Skalierbarkeit und umfassende Unterstützung in der Branche es zu einer beliebten Wahl für VoIP und Multimedia-Kommunikation.
+Obwohl SIP viele Vorteile bietet, kann es komplex zu konfigurieren und zu verwalten sein, insbesondere beim Umgang mit NAT-Traversal und Firewall-Problemen. Dennoch machen seine Vielseitigkeit, Skalierbarkeit und die breite Unterstützung in der Branche SIP zu einer beliebten Wahl für VoIP- und Multimedia-Kommunikation.
 
 ### SIP-Methoden
 
-Die grundlegenden SIP-Methoden, die in **RFC 3261** definiert sind, umfassen:
+Die Kern-SIP-Methoden, definiert in **RFC 3261**, umfassen:
 
-1. **INVITE**: Wird verwendet, um eine **neue Sitzung (Anruf)** zu initiieren oder eine bestehende zu modifizieren. Die INVITE-Methode trägt die Sitzungsbeschreibung (typischerweise unter Verwendung von SDP), um den Empfänger über die Einzelheiten der vorgeschlagenen Sitzung zu informieren, wie Medientypen, Codecs und Transportprotokolle.
-2. **ACK**: Wird gesendet, um den **Erhalt** einer endgültigen Antwort auf eine INVITE-Anfrage zu **bestätigen**. Die ACK-Methode gewährleistet die Zuverlässigkeit von INVITE-Transaktionen, indem sie eine End-to-End-Bestätigung bereitstellt.
-3. **BYE**: Wird verwendet, um eine **etablierte Sitzung (Anruf)** zu beenden. Die BYE-Methode wird von einer der Parteien in der Sitzung gesendet, um anzuzeigen, dass sie die Kommunikation beenden möchte.
-4. **CANCEL**: Wird gesendet, um eine **ausstehende INVITE**-Anfrage abzubrechen, bevor die Sitzung etabliert wird. Die CANCEL-Methode ermöglicht es dem Absender, eine INVITE-Transaktion abzubrechen, wenn er seine Meinung ändert oder wenn keine Antwort vom Empfänger erfolgt.
-5. **OPTIONS**: Wird verwendet, um die **Fähigkeiten eines SIP-Servers oder Benutzeragenten** abzufragen. Die OPTIONS-Methode kann gesendet werden, um Informationen über unterstützte Methoden, Medientypen oder andere Erweiterungen anzufordern, ohne tatsächlich eine Sitzung zu etablieren.
-6. **REGISTER**: Wird von einem Benutzeragenten verwendet, um seinen aktuellen Standort bei einem SIP-Registrar-Server zu **registrieren**. Die REGISTER-Methode hilft, eine aktuelle Zuordnung zwischen der SIP-URI eines Benutzers und seiner aktuellen IP-Adresse aufrechtzuerhalten, was die Anrufweiterleitung und -zustellung ermöglicht.
+1. **INVITE**: Wird verwendet, um eine **neue Sitzung (Anruf) zu initiieren** oder eine bestehende zu ändern. Die INVITE-Methode trägt die Sitzungsbeschreibung (typischerweise mit SDP), um den Empfänger über die Details der vorgeschlagenen Sitzung zu informieren, wie Medientypen, Codecs und Transportprotokolle.
+2. **ACK**: Wird gesendet, um den Erhalt einer endgültigen Antwort auf eine INVITE-Anfrage zu **bestätigen**. Die ACK-Methode stellt die Zuverlässigkeit von INVITE-Transaktionen sicher, indem sie eine Ende-zu-Ende-Bestätigung liefert.
+3. **BYE**: Wird verwendet, um eine **etablierte Sitzung (Anruf) zu beenden**. Die BYE-Methode wird von einer der Parteien in der Sitzung gesendet, um anzuzeigen, dass sie die Kommunikation beenden möchte.
+4. **CANCEL**: Wird gesendet, um eine **ausstehende INVITE**-Anfrage zu stornieren, bevor die Sitzung etabliert ist. Die CANCEL-Methode ermöglicht dem Sender, eine INVITE-Transaktion abzubrechen, wenn er seine Meinung ändert oder keine Antwort vom Empfänger erfolgt.
+5. **OPTIONS**: Wird verwendet, um die **Fähigkeiten eines SIP-Servers oder User Agents abzufragen**. Die OPTIONS-Methode kann gesendet werden, um Informationen über unterstützte Methoden, Medientypen oder andere Erweiterungen anzufordern, ohne tatsächlich eine Sitzung zu etablieren.
+6. **REGISTER**: Wird von einem User Agent verwendet, um seinen aktuellen Standort bei einem SIP-Registrar-Server **zu registrieren**. Die REGISTER-Methode hilft dabei, eine aktuelle Zuordnung zwischen der SIP-URI eines Benutzers und seiner aktuellen IP-Adresse zu pflegen, was Anrufweiterleitung und Zustellung ermöglicht.
 
 > [!WARNING]
-> Beachten Sie, dass es **nicht notwendig ist, die REGISTER**-Methode zu verwenden, um jemanden anzurufen.\
-> Es ist jedoch möglich, dass der Anrufer sich zuerst **authentifizieren** muss, um eine **INVITE** durchzuführen, oder er erhält eine **`401 Unauthorized`**-Antwort.
+> Beachte, dass es **nicht notwendig ist, REGISTER für einen Anruf zu verwenden**.\
+> Es ist jedoch möglich, dass der Anrufer sich vor einem **INVITE** zuerst **authentifizieren** muss, sonst erhält er eine **`401 Unauthorized`**-Antwort.
 
-Neben diesen Kernmethoden gibt es **mehrere SIP-Erweiterungsmethoden**, die in anderen RFCs definiert sind, wie zum Beispiel:
+Zusätzlich zu diesen Kernmethoden gibt es **mehrere SIP-Erweiterungsmethoden**, die in anderen RFCs definiert sind, wie zum Beispiel:
 
-1. **SUBSCRIBE**: In RFC 6665 definiert, wird die SUBSCRIBE-Methode verwendet, um **Benachrichtigungen** über den Status einer bestimmten Ressource, wie z.B. die Präsenz oder den Anrufstatus eines Benutzers, anzufordern.
-2. **NOTIFY**: Ebenfalls in RFC 6665 definiert, wird die NOTIFY-Methode von einem Server gesendet, um einen **abonnierten Benutzeragenten** über Änderungen im Status einer überwachten Ressource zu informieren.
-3. **REFER**: In RFC 3515 definiert, wird die REFER-Methode verwendet, um **anzufordern, dass der Empfänger eine Übertragung durchführt oder an eine dritte Partei verweist**. Dies wird typischerweise für **Anrufübertragung**-Szenarien verwendet.
-4. **MESSAGE**: In RFC 3428 definiert, wird die MESSAGE-Methode verwendet, um **Instant Messages zwischen SIP-Benutzeragenten** zu senden, was textbasierte Kommunikation innerhalb des SIP-Rahmens ermöglicht.
-5. **UPDATE**: In RFC 3311 definiert, ermöglicht die UPDATE-Methode, eine **Sitzung zu modifizieren, ohne den Status des bestehenden Dialogs zu beeinflussen**. Dies ist nützlich, um Sitzungsparameter wie Codecs oder Medientypen während eines laufenden Anrufs zu aktualisieren.
-6. **PUBLISH**: In RFC 3903 definiert, wird die PUBLISH-Methode von einem Benutzeragenten verwendet, um **Ereignisstatusinformationen an einen Server zu veröffentlichen**, die anderen interessierten Parteien zur Verfügung stehen.
+1. **SUBSCRIBE**: In RFC 6665 definiert, wird die SUBSCRIBE-Methode verwendet, um **Benachrichtigungen anzufordern** über den Zustand einer bestimmten Ressource, wie z. B. die Presence oder den Anrufstatus eines Benutzers.
+2. **NOTIFY**: Ebenfalls in RFC 6665 definiert, wird die NOTIFY-Methode von einem Server gesendet, um einen abonnierten User Agent über Änderungen im Zustand einer überwachten Ressource **zu informieren**.
+3. **REFER**: In RFC 3515 definiert, wird die REFER-Methode verwendet, um zu **verlangen, dass der Empfänger eine Weiterleitung durchführt oder an eine Drittpartei verweist**. Dies wird typischerweise für Call-Transfer-Szenarien verwendet.
+4. **MESSAGE**: In RFC 3428 definiert, wird die MESSAGE-Methode verwendet, um **Instant Messages zwischen SIP-User Agents zu senden**, wodurch textbasierte Kommunikation innerhalb des SIP-Frameworks ermöglicht wird.
+5. **UPDATE**: In RFC 3311 definiert, erlaubt die UPDATE-Methode, eine Sitzung zu **ändern, ohne den Zustand des bestehenden Dialogs zu beeinflussen**. Dies ist nützlich, um Sitzungsparameter wie Codecs oder Medientypen während eines laufenden Anrufs zu aktualisieren.
+6. **PUBLISH**: In RFC 3903 definiert, wird die PUBLISH-Methode von einem User Agent verwendet, um Ereignisstatusinformationen an einen Server zu **veröffentlichen**, die anderen interessierten Parteien zur Verfügung gestellt werden.
 
 ### SIP-Antwortcodes
 
-- **1xx (Provisorische Antworten)**: Diese Antworten zeigen an, dass die Anfrage empfangen wurde und der Server weiterhin daran arbeitet.
+- **1xx (Vorläufige Antworten)**: Diese Antworten zeigen an, dass die Anfrage empfangen wurde und der Server die Verarbeitung fortsetzt.
 - 100 Trying: Die Anfrage wurde empfangen, und der Server arbeitet daran.
-- 180 Ringing: Der Angerufene wird benachrichtigt und wird den Anruf annehmen.
-- 183 Session Progress: Bietet Informationen über den Fortschritt des Anrufs.
+- 180 Ringing: Der Angerufene wird benachrichtigt und wird den Anruf entgegennehmen.
+- 183 Session Progress: Liefert Informationen über den Fortschritt des Anrufs.
 - **2xx (Erfolgreiche Antworten)**: Diese Antworten zeigen an, dass die Anfrage erfolgreich empfangen, verstanden und akzeptiert wurde.
-- 200 OK: Die Anfrage war erfolgreich, und der Server hat sie erfüllt.
-- 202 Accepted: Die Anfrage wurde zur Bearbeitung angenommen, aber noch nicht abgeschlossen.
-- **3xx (Umleitungsantworten)**: Diese Antworten zeigen an, dass weitere Maßnahmen erforderlich sind, um die Anfrage zu erfüllen, typischerweise durch Kontaktaufnahme mit einer alternativen Ressource.
+- 200 OK: Die Anfrage war erfolgreich und der Server hat sie erfüllt.
+- 202 Accepted: Die Anfrage wurde zur Verarbeitung akzeptiert, wurde aber noch nicht abgeschlossen.
+- **3xx (Umleitungsantworten)**: Diese Antworten zeigen an, dass weitere Aktionen erforderlich sind, um die Anfrage zu erfüllen, typischerweise durch Kontaktaufnahme mit einer alternativen Ressource.
 - 300 Multiple Choices: Es stehen mehrere Optionen zur Verfügung, und der Benutzer oder Client muss eine auswählen.
-- 301 Moved Permanently: Die angeforderte Ressource hat eine neue permanente URI erhalten.
+- 301 Moved Permanently: Die angeforderte Ressource wurde dauerhaft einer neuen URI zugewiesen.
 - 302 Moved Temporarily: Die angeforderte Ressource ist vorübergehend unter einer anderen URI verfügbar.
-- 305 Use Proxy: Die Anfrage muss an einen bestimmten Proxy gesendet werden.
+- 305 Use Proxy: Die Anfrage muss an einen angegebenen Proxy gesendet werden.
 - **4xx (Client-Fehlerantworten)**: Diese Antworten zeigen an, dass die Anfrage fehlerhafte Syntax enthält oder vom Server nicht erfüllt werden kann.
 - 400 Bad Request: Die Anfrage war fehlerhaft oder ungültig.
 - 401 Unauthorized: Die Anfrage erfordert eine Benutzer-Authentifizierung.
-- 403 Forbidden: Der Server hat die Anfrage verstanden, lehnt jedoch die Erfüllung ab.
+- 403 Forbidden: Der Server hat die Anfrage verstanden, weigert sich jedoch, sie zu erfüllen.
 - 404 Not Found: Die angeforderte Ressource wurde auf dem Server nicht gefunden.
-- 408 Request Timeout: Der Server hat innerhalb der Zeit, die er bereit war zu warten, keine vollständige Anfrage erhalten.
+- 408 Request Timeout: Der Server hat innerhalb der vorgesehenen Zeit keine vollständige Anfrage erhalten.
 - 486 Busy Here: Der Angerufene ist derzeit beschäftigt und kann den Anruf nicht annehmen.
-- **5xx (Server-Fehlerantworten)**: Diese Antworten zeigen an, dass der Server nicht in der Lage war, eine gültige Anfrage zu erfüllen.
-- 500 Internal Server Error: Der Server hat einen Fehler bei der Bearbeitung der Anfrage festgestellt.
-- 501 Not Implemented: Der Server unterstützt die Funktionalität, die zur Erfüllung der Anfrage erforderlich ist, nicht.
-- 503 Service Unavailable: Der Server kann die Anfrage aufgrund von Wartungsarbeiten oder Überlastung derzeit nicht bearbeiten.
+- **5xx (Server-Fehlerantworten)**: Diese Antworten zeigen an, dass der Server eine gültige Anfrage nicht erfüllen konnte.
+- 500 Internal Server Error: Der Server ist beim Verarbeiten der Anfrage auf einen Fehler gestoßen.
+- 501 Not Implemented: Der Server unterstützt die erforderliche Funktionalität zur Erfüllung der Anfrage nicht.
+- 503 Service Unavailable: Der Server kann die Anfrage derzeit aufgrund von Wartung oder Überlastung nicht bearbeiten.
 - **6xx (Globale Fehlerantworten)**: Diese Antworten zeigen an, dass die Anfrage von keinem Server erfüllt werden kann.
-- 600 Busy Everywhere: Alle möglichen Ziele für den Anruf sind beschäftigt.
-- 603 Decline: Der Angerufene möchte nicht am Anruf teilnehmen.
-- 604 Does Not Exist Anywhere: Die angeforderte Ressource ist im Netzwerk nirgendwo verfügbar.
+- 600 Busy Everywhere: Alle möglichen Ziele für den Anruf sind besetzt.
+- 603 Decline: Der Angerufene möchte nicht an dem Anruf teilnehmen.
+- 604 Does Not Exist Anywhere: Die angeforderte Ressource ist nirgendwo im Netzwerk verfügbar.
 
 ## Beispiele
 
@@ -94,43 +94,43 @@ s=-
 c=IN IP4 pc33.example.com
 t=0 0
 m=audio 49170 RTP/AVP 0
-a=rtpmap:0 PCMU/8000te
+a=rtpmap:0 PCMU/8000
 ```
 <details>
 
 <summary>Jeder Parameter erklärt</summary>
 
-1. **Request-Line**: `INVITE sip:jdoe@example.com SIP/2.0` - Diese Zeile gibt die Methode (INVITE), die Anfrage-URI (sip:[jdoe@example.com](mailto:jdoe@example.com)) und die SIP-Version (SIP/2.0) an.
-2. **Via**: `Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds` - Der Via-Header gibt das Transportprotokoll (UDP) und die Adresse des Clients (pc33.example.com) an. Der "branch"-Parameter wird zur Schleifenvermeidung und Transaktionszuordnung verwendet.
-3. **Max-Forwards**: `Max-Forwards: 70` - Dieses Header-Feld begrenzt die Anzahl der Weiterleitungen der Anfrage durch Proxys, um unendliche Schleifen zu vermeiden.
+1. **Request-Line**: `INVITE sip:jdoe@example.com SIP/2.0` - Diese Zeile gibt die Methode (INVITE), die Request-URI (sip:[jdoe@example.com](mailto:jdoe@example.com)) und die SIP-Version (SIP/2.0) an.
+2. **Via**: `Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds` - Der Via-Header legt das Transportprotokoll (UDP) und die Adresse des Clients (pc33.example.com) fest. Der "branch"-Parameter wird zur Schleifenerkennung und zur Zuordnung von Transaktionen verwendet.
+3. **Max-Forwards**: `Max-Forwards: 70` - Dieses Header-Feld begrenzt, wie oft die Anfrage von Proxies weitergeleitet werden kann, um Endlosschleifen zu vermeiden.
 4. **To**: `To: John Doe <sip:jdoe@example.com>` - Der To-Header gibt den Empfänger des Anrufs an, einschließlich seines Anzeigenamens (John Doe) und der SIP-URI (sip:[jdoe@example.com](mailto:jdoe@example.com)).
-5. **From**: `From: Jane Smith <sip:jsmith@example.org>;tag=1928301774` - Der From-Header gibt den Absender des Anrufs an, einschließlich seines Anzeigenamens (Jane Smith) und der SIP-URI (sip:[jsmith@example.org](mailto:jsmith@example.org)). Der "tag"-Parameter wird verwendet, um die Rolle des Absenders im Dialog eindeutig zu identifizieren.
-6. **Call-ID**: `Call-ID: a84b4c76e66710` - Der Call-ID-Header identifiziert eine Anrufsession zwischen zwei Benutzeragenten eindeutig.
-7. **CSeq**: `CSeq: 314159 INVITE` - Der CSeq-Header enthält eine Sequenznummer und die in der Anfrage verwendete Methode. Er wird verwendet, um Antworten auf Anfragen abzugleichen und Nachrichten in falscher Reihenfolge zu erkennen.
-8. **Contact**: `Contact: <sip:jsmith@pc33.example.com>` - Der Contact-Header bietet eine direkte Route zum Absender, die für nachfolgende Anfragen und Antworten verwendet werden kann.
+5. **From**: `From: Jane Smith <sip:jsmith@example.org>;tag=1928301774` - Der From-Header gibt den Absender des Anrufs an, einschließlich seines Anzeigenamens (Jane Smith) und der SIP-URI (sip:[jsmith@example.org](mailto:jsmith@example.org)). Der "tag"-Parameter dient zur eindeutigen Identifizierung der Rolle des Absenders im Dialog.
+6. **Call-ID**: `Call-ID: a84b4c76e66710` - Der Call-ID-Header identifiziert eine Gesprächssitzung zwischen zwei User Agents eindeutig.
+7. **CSeq**: `CSeq: 314159 INVITE` - Der CSeq-Header enthält eine Sequenznummer und die im Request verwendete Methode. Er wird verwendet, um Antworten Requests zuzuordnen und Nachrichten außerhalb der Reihenfolge zu erkennen.
+8. **Contact**: `Contact: <sip:jsmith@pc33.example.com>` - Der Contact-Header bietet eine direkte Route zum Absender, die für nachfolgende Requests und Antworten genutzt werden kann.
 9. **User-Agent**: `User-Agent: ExampleSIPClient/1.0` - Der User-Agent-Header liefert Informationen über die Software oder Hardware des Absenders, einschließlich Name und Version.
-10. **Allow**: `Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO` - Der Allow-Header listet die vom Absender unterstützten SIP-Methoden auf. Dies hilft dem Empfänger zu verstehen, welche Methoden während der Kommunikation verwendet werden können.
+10. **Allow**: `Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO` - Der Allow-Header listet die vom Absender unterstützten SIP-Methoden auf. Das hilft dem Empfänger zu verstehen, welche Methoden während der Kommunikation verwendet werden können.
 11. **Content-Type**: `Content-Type: application/sdp` - Der Content-Type-Header gibt den Medientyp des Nachrichtenkörpers an, in diesem Fall SDP (Session Description Protocol).
-12. **Content-Length**: `Content-Length: 142` - Der Content-Length-Header gibt die Größe des Nachrichtenkörpers in Bytes an.
-13. **Message Body**: Der Nachrichtenkörper enthält die SDP-Sitzungsbeschreibung, die Informationen über die Medientypen, Codecs und Transportprotokolle für die vorgeschlagene Sitzung enthält.
+12. **Content-Length**: `Content-Length: 142` - Der Content-Length-Header zeigt die Größe des Nachrichtenkörpers in Bytes an.
+13. **Message Body**: Der Nachrichtenkörper enthält die SDP-Session-Beschreibung, die Informationen über Medientypen, Codecs und Transportprotokolle für die vorgeschlagene Sitzung enthält.
 
 - `v=0` - Protokollversion (0 für SDP)
-- `o=jsmith 2890844526 2890842807 IN IP4 pc33.example.com` - Ursprung und Sitzungsidentifikator
-- `s=-` - Sitzungsname (ein einzelner Bindestrich bedeutet keinen Sitzungsnamen)
+- `o=jsmith 2890844526 2890842807 IN IP4 pc33.example.com` - Originator und Sitzungskennzeichner
+- `s=-` - Sitzungsname (ein einzelner Bindestrich bedeutet kein Sitzungsname)
 - `c=IN IP4 pc33.example.com` - Verbindungsinformationen (Netzwerktyp, Adresstyp und Adresse)
-- `t=0 0` - Zeitinformationen (Start- und Stoppzeiten, 0 0 bedeutet, dass die Sitzung nicht begrenzt ist)
-- `m=audio 49170 RTP/AVP 0` - Medienbeschreibung (Medientyp, Portnummer, Transportprotokoll und Formatliste). In diesem Fall wird ein Audiostream unter Verwendung von RTP/AVP (Real-time Transport Protocol / Audio Video Profile) und Format 0 (PCMU/8000) angegeben.
+- `t=0 0` - Zeitinformationen (Start- und Stoppzeiten, 0 0 bedeutet, die Sitzung ist nicht begrenzt)
+- `m=audio 49170 RTP/AVP 0` - Mediabeschreibung (Medientyp, Portnummer, Transportprotokoll und Formatliste). In diesem Fall spezifiziert es einen Audiostream über RTP/AVP (Real-time Transport Protocol / Audio Video Profile) und Format 0 (PCMU/8000).
 - `a=rtpmap:0 PCMU/8000` - Attribut, das das Format (0) dem Codec (PCMU) und seiner Abtastrate (8000 Hz) zuordnet.
 
 </details>
 
-### SIP REGISTER Beispiel
+### SIP REGISTER-Beispiel
 
-Die REGISTER-Methode wird im Session Initiation Protocol (SIP) verwendet, um einem Benutzeragenten (UA), wie einem VoIP-Telefon oder einem Softphone, zu ermöglichen, **seinen Standort bei einem SIP-Registrar-Server zu registrieren**. Dieser Prozess informiert den Server, **wo eingehende SIP-Anfragen, die an den registrierten Benutzer gerichtet sind, weitergeleitet werden sollen**. Der Registrar-Server ist normalerweise Teil eines SIP-Proxy-Servers oder eines dedizierten Registrierungsservers.
+Die REGISTER-Methode wird im Session Initiation Protocol (SIP) verwendet, damit ein User Agent (UA), wie z. B. ein VoIP-Telefon oder ein Softphone, **seinen Standort bei einem SIP-Registrar-Server registrieren** kann. Dieser Vorgang teilt dem Server **mit, wohin eingehende SIP-Anfragen für den registrierten Benutzer geroutet werden sollen**. Der Registrar-Server ist normalerweise Teil eines SIP-Proxy-Servers oder ein dedizierter Registrierungsserver.
 
-Hier ist ein detailliertes Beispiel der SIP-Nachrichten, die an einem REGISTER-Authentifizierungsprozess beteiligt sind:
+Hier ein detailliertes Beispiel der SIP-Nachrichten, die an einem REGISTER-Authentifizierungsprozess beteiligt sind:
 
-1. Erste **REGISTER**-Anfrage vom UA an den Registrar-Server:
+1. Initiale **REGISTER**-Anfrage vom UA an den Registrar-Server:
 ```yaml
 REGISTER sip:example.com SIP/2.0
 Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
@@ -143,11 +143,11 @@ Contact: <sip:alice@192.168.1.100:5060>;expires=3600
 Expires: 3600
 Content-Length: 0
 ```
-Diese anfängliche REGISTER-Nachricht wird vom UA (Alice) an den Registrierungsserver gesendet. Sie enthält wichtige Informationen wie die gewünschte Registrierungsdauer (Expires), die SIP-URI des Benutzers (sip:[alice@example.com](mailto:alice@example.com)) und die Kontaktadresse des Benutzers (sip:alice@192.168.1.100:5060).
+Diese initiale REGISTER-Nachricht wird vom UA (Alice) an den Registrar-Server gesendet. Sie enthält wichtige Informationen wie die gewünschte Registrierungsdauer (Expires), die SIP-URI des Benutzers (sip:[alice@example.com](mailto:alice@example.com)) und die Kontaktadresse des Benutzers (sip:alice@192.168.1.100:5060).
 
-2. **401 Unauthorized** Antwort vom Registrierungsserver:
-```css
-cssCopy codeSIP/2.0 401 Unauthorized
+2. **401 Unauthorized**-Antwort vom Registrar-Server:
+```
+SIP/2.0 401 Unauthorized
 Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
 From: Alice <sip:alice@example.com>;tag=565656
 To: Alice <sip:alice@example.com>;tag=7878744
@@ -156,7 +156,7 @@ CSeq: 1 REGISTER
 WWW-Authenticate: Digest realm="example.com", nonce="abcdefghijk", algorithm=MD5, qop="auth"
 Content-Length: 0
 ```
-Der Registrar-Server antwortet mit einer "401 Unauthorized"-Nachricht, die einen "WWW-Authenticate"-Header enthält. Dieser Header enthält Informationen, die erforderlich sind, damit sich der UA authentifizieren kann, wie z.B. den **Authentifizierungsbereich, Nonce und Algorithmus**.
+Der Registrar-Server antwortet mit einer "401 Unauthorized"-Nachricht, die einen "WWW-Authenticate"-Header enthält. Dieser Header enthält Informationen, die der UA benötigt, um sich zu authentifizieren, wie z. B. den **Authentifizierungs-Realm, Nonce und Algorithmus**.
 
 3. REGISTER-Anfrage **mit Authentifizierungsdaten**:
 ```vbnet
@@ -172,9 +172,9 @@ Expires: 3600
 Authorization: Digest username="alice", realm="example.com", nonce="abcdefghijk", uri="sip:example.com", response="65a8e2285879283831b664bd8b7f14d4", algorithm=MD5, cnonce="lmnopqrst", qop=auth, nc=00000001
 Content-Length: 0
 ```
-Der UA sendet eine weitere REGISTER-Anfrage, diesmal mit dem **"Authorization"-Header, der die erforderlichen Anmeldeinformationen wie den Benutzernamen, das Realm, die Nonce und einen Antwortwert** enthält, der mit den bereitgestellten Informationen und dem Passwort des Benutzers berechnet wurde.
+Der UA sendet eine weitere REGISTER-Anfrage, diesmal inklusive des **"Authorization" header mit den notwendigen Anmeldeinformationen, wie username, realm, nonce und einem response value**, der mithilfe der bereitgestellten Informationen und des Passworts des Benutzers berechnet wird.
 
-So wird die **Authorization-Antwort** berechnet:
+So wird die **Authorization response** berechnet:
 ```python
 import hashlib
 
@@ -207,7 +207,7 @@ qop = "auth"
 response = calculate_sip_md5_response(username, password, realm, method, uri, nonce, nc, cnonce, qop)
 print(f"MD5 response value: {response}")
 ```
-4. **Erfolgreiche Registrierung** Antwort vom Registrierungsserver:
+4. **Erfolgreiche Registrierung** Antwort vom Registrar-Server:
 ```yaml
 SIP/2.0 200 OK
 Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
@@ -219,13 +219,98 @@ Contact: <sip:alice@192.168.1.100:5060>;expires=3600
 Expires: 3600
 Content-Length: 0
 ```
-Nachdem der Registrar-Server die bereitgestellten Anmeldeinformationen überprüft hat, **sendet er eine "200 OK"-Antwort, um anzuzeigen, dass die Registrierung erfolgreich war**. Die Antwort enthält die registrierten Kontaktinformationen und die Ablaufzeit für die Registrierung. An diesem Punkt ist der Benutzeragent (Alice) erfolgreich beim SIP-Registrar-Server registriert, und eingehende SIP-Anfragen für Alice können an die entsprechende Kontaktadresse weitergeleitet werden.
+Nachdem der Registrar-Server die angegebenen Zugangsdaten überprüft hat, **sendet er eine "200 OK"-Antwort, um anzuzeigen, dass die Registrierung erfolgreich war**. Die Antwort enthält die registrierten Kontaktinformationen und die Ablaufzeit der Registrierung. Zu diesem Zeitpunkt ist der User Agent (Alice) erfolgreich beim SIP-Registrar-Server registriert, und eingehende SIP-Anfragen für Alice können an die passende Kontaktadresse weitergeleitet werden.
 
-### Anrufbeispiel
+### Call Example
 
 <figure><img src="../../../images/image (1101).png" alt=""><figcaption></figcaption></figure>
 
-> [!NOTE]
-> Es wird nicht erwähnt, aber Benutzer B muss eine **REGISTER-Nachricht an Proxy 2** gesendet haben, bevor er Anrufe empfangen kann.
+> [!TIP]
+> Es wird nicht erwähnt, aber User B muss eine **REGISTER message to Proxy 2** gesendet haben, bevor er Anrufe empfangen kann.
 
+
+
+---
+
+## SIP-Sicherheit und Pentesting-Hinweise
+
+Dieser Abschnitt fügt praktische, protokoll-spezifische Tipps hinzu, ohne die allgemeine VoIP-Anleitung zu duplizieren. Für End-to-End-VoIP-Angriffs-Methodik, Tools und Szenarien siehe:
+
+{{#ref}}
+../README.md
+{{#endref}}
+
+### Fingerprinting und Discovery
+
+- Sende eine OPTIONS-Anfrage und prüfe die Header `Allow`, `Supported`, `Server` und `User-Agent`, um Geräte und Stacks zu fingerprinten:
+
+```bash
+# nmap NSE (UDP 5060 by default)
+sudo nmap -sU -p 5060 --script sip-methods <target>
+
+# Minimal raw OPTIONS over UDP
+printf "OPTIONS sip:<target> SIP/2.0\r\nVia: SIP/2.0/UDP attacker;branch=z9\r\nFrom: <sip:probe@attacker>;tag=1\r\nTo: <sip:probe@<target>>\r\nCall-ID: 1@attacker\r\nCSeq: 1 OPTIONS\r\nMax-Forwards: 70\r\nContact: <sip:probe@attacker>\r\nContent-Length: 0\r\n\r\n" | nc -u -w 2 <target> 5060
+```
+
+### Username/Extension-Enumeration-Verhalten
+
+- Enumeration nutzt typischerweise Unterschiede zwischen `401/407` vs `404/403` bei `REGISTER`/`INVITE` aus. Härte Server so ab, dass sie einheitlich antworten.
+- Asterisk chan_sip: setze `alwaysauthreject=yes` (global), um die Offenlegung gültiger Benutzer zu vermeiden. In neueren Asterisk-Versionen (PJSIP) ist Guest-Calling deaktiviert, sofern kein `anonymous`-Endpoint definiert ist, und ein ähnliches "always auth reject"-Verhalten ist standardmäßig aktiv; trotzdem Netzwer k-ACLs und fail2ban am Perimeter durchsetzen.
+
+### SIP Digest Authentication: Algorithmen und cracking
+
+- SIP verwendet häufig HTTP-Digest-artige Authentifizierung. Historisch sind MD5 (und MD5-sess) verbreitet; neuere Stacks unterstützen SHA-256 und SHA-512/256 gemäß RFC 8760. Bevorzuge diese stärkeren Algorithmen in modernen Deployments und deaktiviere MD5, wenn möglich.
+- Offline-cracking aus einem pcap ist für MD5-Digests trivial. Nach dem Extrahieren von Challenge/Response kannst du hashcat Mode 11400 (SIP digest, MD5) verwenden:
+
+```bash
+# Example hash format (single line)
+# username:realm:method:uri:nonce:cnonce:nc:qop:response
+echo 'alice:example.com:REGISTER:sip:example.com:abcdef:11223344:00000001:auth:65a8e2285879283831b664bd8b7f14d4' > sip.hash
+
+# Crack with a wordlist
+hashcat -a 0 -m 11400 sip.hash /path/to/wordlist.txt
+```
+
+> [!NOTE]
+> RFC 8760 definiert SHA-256 und SHA-512/256 für HTTP Digest (wird auch von SIP Digest verwendet). Die Adoption ist uneinheitlich; stelle sicher, dass deine Tools diese unterstützen, wenn du moderne PBX-Systeme anvisierst.
+
+### SIP über TLS (SIPS) und über WebSockets
+
+- Signalisierungsverschlüsselung:
+- `sips:`-URIs und TCP/TLS typischerweise auf Port 5061. Überprüfe die Zertifikatsvalidierung an den Endpunkten; viele akzeptieren self-signed- oder wildcard-Zertifikate, was in schwachen Deployments MitM ermöglicht.
+- WebRTC-Softphones verwenden oft SIP über WebSocket gemäß RFC 7118 (`ws://` oder `wss://`). Wenn die PBX WSS exposiert, teste Authentifizierung und CORS und stelle sicher, dass Rate-Limits auch am HTTP-Frontend durchgesetzt werden.
+
+### DoS-Schnellchecks (Protokollebene)
+
+- Flooding mit INVITE, REGISTER oder fehlerhaften Nachrichten kann die Transaktionsverarbeitung erschöpfen.
+- Einfaches Rate-Limiting-Beispiel für UDP/5060 (Linux iptables hashlimit):
+
+```bash
+# Limit new SIP packets from a single IP to 20/s with burst 40
+iptables -A INPUT -p udp --dport 5060 -m hashlimit \
+--hashlimit-name SIP --hashlimit 20/second --hashlimit-burst 40 \
+--hashlimit-mode srcip -j ACCEPT
+iptables -A INPUT -p udp --dport 5060 -j DROP
+```
+
+### Kürzliche, relevante SIP-Stack-CVEs (Asterisk PJSIP)
+
+- CVE-2024-35190 (veröffentlicht 17. Mai 2024): In bestimmten Asterisk-Releases konnte `res_pjsip_endpoint_identifier_ip` unautorisierte SIP-Anfragen fälschlich als lokalen Endpoint identifizieren, was möglicherweise unautorisierte Aktionen oder Informationsausgabe ermöglichte. Behoben in 18.23.1, 20.8.1 und 21.3.1. Validieren Sie Ihre PBX-Version beim Testen und melden Sie verantwortungsvoll.
+
+### Härtungs-Checkliste (SIP-spezifisch)
+
+- Bevorzuge TLS für Signalisierung und SRTP/DTLS-SRTP für Media; deaktivere Cleartext, wo möglich.
+- Erzwinge starke Passwörter und Digest-Algorithmen (SHA-256/512-256 wo unterstützt; vermeide MD5).
+- Für Asterisk:
+- chan_sip: `alwaysauthreject=yes`, `allowguest=no`, per-endpoint `permit`/`deny` CIDR-ACLs.
+- PJSIP: Erstelle keinen `anonymous`-Endpoint, wenn nicht erforderlich; erzwinge Endpoint-`acl`/`media_acl`; aktiviere fail2ban oder ein Äquivalent.
+- Topology hiding auf SIP-Proxys (z. B. outbound proxy/edge SBC), um information leak zu reduzieren.
+- Striktes `OPTIONS`-Handling und Rate-Limits; deaktiviere ungenutzte Methoden (z. B. `MESSAGE`, `PUBLISH`), wenn sie nicht benötigt werden.
+
+
+
+## Referenzen
+
+- RFC 8760 – Using SHA-256 and SHA-512/256 for HTTP Digest (applies to SIP Digest too): https://www.rfc-editor.org/rfc/rfc8760
+- Asterisk GHSA advisory for CVE-2024-35190: https://github.com/asterisk/asterisk/security/advisories/GHSA-qqxj-v78h-hrf9
 {{#include ../../../banners/hacktricks-training.md}}