SIP (Session Initiation Protocol)

Reading time: 15 minutes

기본 정보

SIP (Session Initiation Protocol)은 IP 네트워크 상에서 음성, 비디오, 인스턴트 메시징을 포함한 멀티미디어 세션을 설정, 수정 및 종료하는 데 널리 사용되는 신호 및 통화 제어 프로토콜입니다. **Internet Engineering Task Force (IETF)**에서 개발되었으며, SIP는 RFC 3261에 정의되어 VoIP 및 통합 커뮤니케이션의 사실상 표준이 되었습니다.

SIP의 주요 특징은 다음과 같습니다:

1. 텍스트 기반 프로토콜: SIP는 텍스트 기반 프로토콜로 사람이 읽기 쉽고 디버깅하기 용이합니다. HTTP와 유사한 요청-응답 모델을 기반으로 하며, INVITE, ACK, BYE, CANCEL 등의 메서드를 사용해 통화 세션을 제어합니다.
2. 확장성과 유연성: SIP는 높은 확장성을 가지며 소규모 배포부터 대규모 엔터프라이즈 및 통신사업자급 환경까지 사용할 수 있습니다. 새로운 기능으로 쉽게 확장할 수 있어 다양한 사용 사례와 요구사항에 적응할 수 있습니다.
3. 상호운용성: SIP의 광범위한 채택과 표준화는 다양한 장치, 애플리케이션, 서비스 제공자 간의 더 나은 상호운용성을 보장하여 다양한 플랫폼 간의 원활한 통신을 촉진합니다.
4. 모듈형 설계: SIP는 미디어 전송을 위한 RTP (Real-time Transport Protocol) 및 멀티미디어 세션을 설명하기 위한 SDP (Session Description Protocol) 등 다른 프로토콜과 함께 작동합니다. 이 모듈형 설계는 다양한 미디어 유형과 코덱과의 호환성을 높이고 유연성을 제공합니다.
5. 프록시 및 리다이렉트 서버: SIP는 프록시 및 리다이렉트 서버를 사용하여 통화 라우팅을 용이하게 하며, 착신전환, 통화 전달, 음성사서함과 같은 고급 기능을 제공합니다.
6. 프레즌스 및 인스턴트 메시징: SIP는 음성 및 비디오 통신에 국한되지 않습니다. 프레즌스 및 인스턴트 메시징을 지원하여 다양한 통합 커뮤니케이션 애플리케이션을 가능하게 합니다.

많은 장점에도 불구하고, SIP는 NAT 통과 및 방화벽 문제를 다룰 때 특히 구성 및 관리가 복잡할 수 있습니다. 그러나 그 범용성, 확장성 및 업계 전반의 광범위한 지원으로 인해 VoIP 및 멀티미디어 통신에 인기 있는 선택입니다.

SIP 메서드

RFC 3261에 정의된 핵심 SIP 메서드는 다음과 같습니다:

1. INVITE: 새 세션(통화)을 시작하거나 기존 세션을 수정하는 데 사용됩니다. INVITE 메서드는 제안된 세션의 세부사항(일반적으로 SDP 사용)을 전달하여 수신자에게 미디어 유형, 코덱 및 전송 프로토콜과 같은 정보를 알립니다.
2. ACK: INVITE 요청에 대한 최종 응답의 수신을 확인하기 위해 전송됩니다. ACK 메서드는 종단 간 확인을 제공하여 INVITE 트랜잭션의 신뢰성을 보장합니다.
3. BYE: 확립된 세션(통화)을 종료하는 데 사용됩니다. BYE 메서드는 세션의 어느 쪽이든 통화를 종료하려는 의사를 표시하기 위해 전송됩니다.
4. CANCEL: 세션이 성립되기 전에 보류 중인 INVITE 요청을 취소하기 위해 전송됩니다. CANCEL 메서드는 발신자가 마음을 바꾸거나 수신자로부터 응답이 없는 경우 INVITE 트랜잭션을 중단할 수 있게 합니다.
5. OPTIONS: SIP 서버 또는 사용자 에이전트의 기능을 질의하는 데 사용됩니다. OPTIONS 메서드는 실제로 세션을 성립하지 않고도 지원되는 메서드, 미디어 유형 또는 기타 확장에 대한 정보를 요청할 수 있습니다.
6. REGISTER: 사용자 에이전트가 SIP 레지스트라 서버에 현재 위치를 등록하는 데 사용됩니다. REGISTER 메서드는 사용자의 SIP URI와 현재 IP 주소 간의 최신 매핑을 유지하여 통화 라우팅 및 전달을 가능하게 합니다.

이 핵심 메서드들 외에도 RFC 등 다른 문서들에 정의된 여러 SIP 확장 메서드가 있습니다:

1. SUBSCRIBE: RFC 6665에 정의된 SUBSCRIBE 메서드는 사용자의 프레즌스나 통화 상태와 같은 특정 리소스의 상태에 대한 알림을 요청하는 데 사용됩니다.
2. NOTIFY: 역시 RFC 6665에 정의된 NOTIFY 메서드는 서버가 구독한 사용자 에이전트에게 모니터링 중인 리소스 상태의 변경을 통지하기 위해 전송합니다.
3. REFER: RFC 3515에 정의된 REFER 메서드는 수신자에게 전달을 수행하거나 제3자를 참조하도록 요청하는 데 사용됩니다. 주로 통화 전달 시나리오에서 사용됩니다.
4. MESSAGE: RFC 3428에 정의된 MESSAGE 메서드는 SIP 사용자 에이전트 간에 인스턴트 메시지를 전송하는 데 사용되어 SIP 프레임워크 내에서 텍스트 기반 통신을 가능하게 합니다.
5. UPDATE: RFC 3311에 정의된 UPDATE 메서드는 기존 대화의 상태에 영향을 주지 않고 세션을 수정할 수 있게 합니다. 이는 진행 중인 통화 중에 코덱이나 미디어 유형과 같은 세션 매개변수를 업데이트하는 데 유용합니다.
6. PUBLISH: RFC 3903에 정의된 PUBLISH 메서드는 사용자 에이전트가 서버에 이벤트 상태 정보를 게시하여 다른 관심 있는 당사자들이 이용할 수 있게 합니다.

SIP 응답 코드

• 1xx (임시 응답): 이러한 응답은 요청이 수신되었고 서버가 계속 처리 중임을 나타냅니다.
• 100 Trying: 요청이 수신되었으며 서버가 작업 중입니다.
• 180 Ringing: 피호출자에게 알림이 가고 있으며 통화를 받을 준비를 하고 있습니다.
• 183 Session Progress: 통화의 진행 상황에 대한 정보를 제공합니다.
• 2xx (성공 응답): 이러한 응답은 요청이 성공적으로 수신, 이해 및 수락되었음을 나타냅니다.
• 200 OK: 요청이 성공적으로 처리되었습니다.
• 202 Accepted: 요청이 처리용으로 수락되었지만 아직 완료되지는 않았습니다.
• 3xx (리다이렉션 응답): 이러한 응답은 요청을 완료하기 위해 추가 조치가 필요함을 나타내며, 일반적으로 다른 리소스에 연락해야 함을 의미합니다.
• 300 Multiple Choices: 사용 가능한 여러 옵션이 있으며 사용자나 클라이언트가 하나를 선택해야 합니다.
• 301 Moved Permanently: 요청된 리소스가 새로운 영구 URI로 할당되었습니다.
• 302 Moved Temporarily: 요청된 리소스가 임시로 다른 URI에서 사용 가능합니다.
• 305 Use Proxy: 요청은 지정된 프록시로 전송되어야 합니다.
• 4xx (클라이언트 오류 응답): 이러한 응답은 요청에 잘못된 구문이 포함되었거나 서버가 요청을 이행할 수 없음을 나타냅니다.
• 400 Bad Request: 요청이 잘못되었거나 유효하지 않습니다.
• 401 Unauthorized: 요청에 사용자 인증이 필요합니다.
• 403 Forbidden: 서버는 요청을 이해했지만 이를 이행하기를 거부합니다.
• 404 Not Found: 요청된 리소스를 서버에서 찾을 수 없습니다.
• 408 Request Timeout: 서버가 기다릴 준비가 된 시간 내에 완전한 요청을 수신하지 못했습니다.
• 486 Busy Here: 피호출자가 현재 바빠서 전화를 받을 수 없습니다.
• 5xx (서버 오류 응답): 이러한 응답은 서버가 유효한 요청을 이행하지 못했음을 나타냅니다.
• 500 Internal Server Error: 서버가 요청을 처리하는 동안 오류가 발생했습니다.
• 501 Not Implemented: 서버가 요청을 이행하는 데 필요한 기능을 지원하지 않습니다.
• 503 Service Unavailable: 서버가 유지보수나 과부하로 인해 현재 요청을 처리할 수 없습니다.
• 6xx (전역 실패 응답): 이러한 응답은 네트워크의 어떤 서버도 요청을 이행할 수 없음을 나타냅니다.
• 600 Busy Everywhere: 통화를 위한 가능한 모든 목적지가 바쁩니다.
• 603 Decline: 피호출자가 통화에 참여하고 싶어하지 않습니다.
• 604 Does Not Exist Anywhere: 요청된 리소스가 네트워크 어디에도 존재하지 않습니다.

예제

SIP INVITE 예제

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 예제

The REGISTER method is used in Session Initiation Protocol (SIP) to allow a user agent (UA), such as a VoIP phone or a softphone, to register its location with a SIP registrar server. This process lets the server know where to route incoming SIP requests destined for the registered user. The registrar server is usually part of a SIP proxy server or a dedicated registration server.

Here's a detailed example of the SIP messages involved in a REGISTER authentication process:

1. Initial REGISTER request from UA to the 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

이 초기 REGISTER 메시지는 UA (Alice)가 레지스트라 서버로 전송합니다. 이 메시지에는 원하는 등록 기간 (Expires), 사용자의 SIP URI (sip:alice@example.com), 그리고 사용자의 연락처 주소 (sip:alice@192.168.1.100:5060)와 같은 중요한 정보가 포함되어 있습니다.

2. 레지스트라 서버로부터의 401 Unauthorized 응답:

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

레지스트라 서버는 "401 Unauthorized" 응답을 반환하며, 이 응답에는 "WWW-Authenticate" 헤더가 포함됩니다. 이 헤더는 UA가 자신을 인증하는 데 필요한 정보를 포함하며, 예를 들어 authentication realm, nonce, and algorithm 등이 있습니다.

3. REGISTER 요청 with authentication credentials:

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

UA는 또 다른 REGISTER 요청을 보냅니다. 이번에는 제공된 정보와 사용자의 비밀번호를 사용해 계산된 사용자 이름(username), realm, nonce 및 응답값(response value)과 같은 필요한 자격 증명을 포함한 "Authorization" header를 포함합니다.

다음은 Authorization response가 계산되는 방법입니다:

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. 성공적인 등록 응답 (레지스트라 서버로부터):

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

등록 서버가 제공된 자격 증명을 확인한 후, 등록이 성공했음을 알리기 위해 "200 OK" 응답을 전송합니다. 응답에는 등록된 contact 정보와 등록의 만료 시간이 포함됩니다. 이 시점에서 user agent (Alice)는 SIP registrar server에 성공적으로 등록되며, Alice로 향하는 들어오는 SIP 요청은 적절한 contact 주소로 라우팅될 수 있습니다.

Call Example

SIP Security and Pentesting Notes

이 섹션은 더 광범위한 VoIP 가이드라인을 중복하지 않으면서 실용적이고 프로토콜에 특화된 팁을 추가합니다. 종단간 VoIP 공격 방법론, 도구 및 시나리오에 대해서는 다음을 참조하십시오:

Pentesting VoIP

Fingerprinting and Discovery

• OPTIONS 요청을 전송하고 Allow, Supported, Server 및 User-Agent 헤더를 검토하여 장치와 스택을 fingerprint 합니다:

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

• 열거는 일반적으로 REGISTER/INVITE에서 401/407 대 404/403의 차이를 악용합니다. 서버가 균일하게 응답하도록 하여 노출을 방지하세요.
• Asterisk chan_sip: 일반 설정으로 alwaysauthreject=yes 를 설정하여 유효한 사용자를 노출하지 않도록 하세요. 최신 Asterisk(PJSIP)에서는 anonymous endpoint가 정의되지 않는 한 guest calling이 비활성화되어 있고 유사한 "always auth reject" 동작이 기본이지만, 여전히 네트워크 ACL과 perimeter에서의 fail2ban 적용을 강제하세요.

SIP Digest Authentication: algorithms and cracking

• SIP는 일반적으로 HTTP-Digest 스타일 인증을 사용합니다. 역사적으로 MD5(및 MD5-sess)가 널리 사용되었고; 최신 스택은 RFC 8760에 따라 SHA-256 및 SHA-512/256을 지원합니다. 최신 배포에서는 이러한 더 강력한 알고리즘을 우선 사용하고 가능한 경우 MD5를 비활성화하세요.
• pcap에서의 오프라인 크래킹은 MD5 다이제스트에 대해 매우 쉽습니다. challenge/response를 추출한 후 hashcat 모드 11400 (SIP digest, MD5)을 사용할 수 있습니다:

# 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 over TLS (SIPS) and over WebSockets

• Signaling encryption:
• sips: URI와 TCP/TLS는 일반적으로 포트 5061을 사용합니다. 엔드포인트에서의 인증서 검증을 확인하세요; 많은 장비가 self-signed 또는 wildcard cert를 허용하여 약한 배포에서는 MitM이 가능해집니다.
• WebRTC softphones는 종종 RFC 7118에 따라 SIP over WebSocket (ws:// 또는 wss://)을 사용합니다. PBX가 WSS를 노출하는 경우 인증 및 CORS를 테스트하고 HTTP 프론트엔드에서도 rate limit이 적용되는지 확인하세요.

DoS quick checks (protocol level)

• INVITE, REGISTER 또는 malformed 메시지 플러딩은 트랜잭션 처리를 소모시킬 수 있습니다.
• UDP/5060에 대한 간단한 rate-limiting 예시(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

Recent, relevant SIP-stack CVE to watch (Asterisk PJSIP)

• CVE-2024-35190 (published May 17, 2024): 특정 Asterisk 릴리스에서 res_pjsip_endpoint_identifier_ip가 무단 SIP 요청을 로컬 엔드포인트로 잘못 식별할 수 있어 무단 동작 또는 정보 노출을 초래할 수 있습니다. 18.23.1, 20.8.1 및 21.3.1에서 수정되었습니다. 테스트 시 PBX 버전을 검증하고 책임감 있게 보고하세요.

Hardening checklist (SIP-specific)

• 신호(Signaling)는 TLS를 우선 사용하고 미디어에는 SRTP/DTLS-SRTP를 사용하세요; 가능한 경우 평문(cleartext)을 비활성화하세요.
• 강력한 비밀번호와 다이제스트 알고리즘(SHA-256/512-256 지원 시; MD5는 피함)을 적용하세요.
• Asterisk의 경우:
• chan_sip: alwaysauthreject=yes, allowguest=no, 엔드포인트별 permit/deny CIDR ACL 설정.
• PJSIP: 필요하지 않다면 anonymous endpoint를 생성하지 마세요; endpoint acl/media_acl을 강제하고 fail2ban 또는 동등한 것을 활성화하세요.
• 정보 누출(leak)을 줄이기 위해 SIP 프록시(예: outbound proxy/edge SBC)에서 토폴로지 숨기기(topology hiding)를 적용하세요.
• 엄격한 OPTIONS 처리 및 rate limit; 필요하지 않은 메서드(예: MESSAGE, PUBLISH)는 비활성화하세요.

References

• 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