SIP (Session Initiation Protocol)

Reading time: 17 minutes

Grundlegende Informationen

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.

Zu den wichtigsten Merkmalen von SIP gehören:

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.

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 Kern-SIP-Methoden, definiert in RFC 3261, umfassen:

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.

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 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 (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 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 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 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 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, 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 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 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 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

SIP INVITE Beispiel

INVITE sip:jdoe@example.com SIP/2.0
Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: John Doe <sip:jdoe@example.com>
From: Jane Smith <sip:jsmith@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:jsmith@pc33.example.com>
User-Agent: ExampleSIPClient/1.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Content-Type: application/sdp
Content-Length: 142

v=0
o=jsmith 2890844526 2890842807 IN IP4 pc33.example.com
s=-
c=IN IP4 pc33.example.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000

SIP REGISTER-Beispiel

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 ein detailliertes Beispiel der SIP-Nachrichten, die an einem REGISTER-Authentifizierungsprozess beteiligt sind:

1. Initiale REGISTER-Anfrage vom UA an den Registrar-Server:

REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
Max-Forwards: 70
From: Alice <sip:alice@example.com>;tag=565656
To: Alice <sip:alice@example.com>
Call-ID: 1234567890@192.168.1.100
CSeq: 1 REGISTER
Contact: <sip:alice@192.168.1.100:5060>;expires=3600
Expires: 3600
Content-Length: 0

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) und die Kontaktadresse des Benutzers (sip:alice@192.168.1.100:5060).

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
Call-ID: 1234567890@192.168.1.100
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 der UA benötigt, um sich zu authentifizieren, wie z. B. den Authentifizierungs-Realm, Nonce und Algorithmus.

3. REGISTER-Anfrage mit Authentifizierungsdaten:

REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
Max-Forwards: 70
From: Alice <sip:alice@example.com>;tag=565656
To: Alice <sip:alice@example.com>
Call-ID: 1234567890@192.168.1.100
CSeq: 2 REGISTER
Contact: <sip:alice@192.168.1.100:5060>;expires=3600
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 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 response berechnet:

import hashlib

def calculate_sip_md5_response(username, password, realm, method, uri, nonce, nc, cnonce, qop):
# 1. Calculate HA1 (concatenation of username, realm, and password)
ha1_input = f"{username}:{realm}:{password}"
ha1 = hashlib.md5(ha1_input.encode()).hexdigest()

# 2. Calculate HA2 (concatenation of method and uri)
ha2_input = f"{method}:{uri}"
ha2 = hashlib.md5(ha2_input.encode()).hexdigest()

# 3. Calculate the final response value (concatenation of h1, stuff and h2)
response_input = f"{ha1}:{nonce}:{nc}:{cnonce}:{qop}:{ha2}"
response = hashlib.md5(response_input.encode()).hexdigest()

return response

# Example usage
username = "alice"
password = "mysecretpassword"
realm = "example.com"
method = "REGISTER"
uri = "sip:example.com"
nonce = "abcdefghijk"
nc = "00000001"
cnonce = "lmnopqrst"
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 Registrar-Server:

SIP/2.0 200 OK
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
Call-ID: 1234567890@192.168.1.100
CSeq: 2 REGISTER
Contact: <sip:alice@192.168.1.100:5060>;expires=3600
Expires: 3600
Content-Length: 0

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.

Call Example

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:

Pentesting VoIP

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:

# 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:

# 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

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):

# 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