콜 성립·미디어 트래픽 전송 과정 보호해야 … VoIP 고유 취약성 공격 방어 시급
조영철
파이오링크 파이오니어랩 이사
jyc@piolink.com
이번 호에서는 VoIP 보안기술은 시스템 측면 혹은 서비스 측면의 VoIP 보안의 취약성에 대하여 알아보고, 이 취약성을 해결하기 위한 방법 및 기술에 대하여 논하고자 한다. 시스템 측면은 고객에게 제공하는 서비스와 관련이 많으므로 이전 연재 내용과 많은 연관이 있다. 앞의 사용자 측면에서의 VoIP 보안 기술과 비교해보면서 살펴보기 바란다. <편집자>
크게 시스템 측면 혹은 서비스 측면의 VoIP 보안 취약성에 대한 내용은 정보의 보안 원칙인 기밀성(confidentiality), 무결성(integrity), 가용성(Availability)의 범주에서 벗어나지 않지만 VoIP만의 특징적인 이슈들은 아래의 6가지로 요약할 수 있다.
- 세션 및 데이터의 암호화(기밀성, 무결성) 문제
- 서비스 거부 공격 (Denial of Services)
- NAT/방화벽 방해(Traversal) 문제
- 토폴로지 숨기기(Topology Hiding) 문제
- SPIT/SPIM의 문제
- 애플리케이션의 취약성
아래 다루는 주요 프로토콜은 SIP(Session Initiation Protocol)지만, 전반적인 내용은 타 VoIP 프로토콜에도 적용될 수 있다.
1. VoIP 기밀성과 무결성 제공
서비스 제공자는 안전한 VoIP 서비스를 위해 VoIP의 기밀성과 무결성을 제공해야 한다. VoIP 트래픽의 보호는 콜 성립과정과 미디어 트래픽 전송과정에서 보호가 필요하다. 그리고, 키의 원활한 공유 및 관리를 위한 키 관리 프로토콜이 필요하다.
<그림 1>은 시그널 트래픽, 미디어 트래픽, 키 교환을 위한 기본 구성을 나타낸다. 시그널 트래픽의 기밀성과 무결성을 제공하기 위해서는 UA ↔ 프록시 ↔ 프록시 ↔ UA 의 데이터의 암호화가 필요하다. 프록시에서는 주소 경로에 대한 판단을 해야 하기 때문에 홉 바이 홉(hop-by-hop) 암호화가 필요하다. 이를 위해 IPSec이나 TLS를 사용할 수 있다. 미디어 트래픽(Media traffic)의 기밀성과 무결성을 제공하기 위해서는 UA <-> UA간의 암호화가 필요하다. 미디어 트래픽은 개인의 사생활에 대한 보호가 요구되므로, 엔드 투 엔드의 암호화가 필요하다. 이를 위해 IPSec이나 SRTP(Secure RTP)를 사용할 수 있다.
키 교환 방식은 VoIP 프로토콜과 상관없이 별도의 메시지를 사용하여 교환(대역외 방식)한다. 혹은 SIP 메시지안에 통합하여 관리하는 방식이 있다. 대역외 방식중의 하나는 IETF에 정의되고 넓게 사용되는 IKE(Internet Key Exchange) 방식이 있다. SIP에서는 RFC3312에서 IKE 동작에 대한 규정하고 있다.
IKE를 SIP과 연동하는 프로토콜의 예는 <그림 2>와 같다. MIKEY(Multimedia Internet KEYing)를 사용할 경우 SIP와 SDP에 하나로 통합돼 사용된다. 특히 SDP의 오퍼-앤서(offer-answer) 모델을 사용하해 키 교환 방식을 구현한다. MIKEY를 SIP과 연동하는 프로토콜의 예는 <그림 3>과 같다.
품질 저하 문제
세션 및 미디어 트래픽을 암호와 복호화하는 기능은 고객에게 보안성을 높이는 효과가 있으나, 서비스 측면에서 많은 품질 저하를 야기할 수 있다. 키 교환과 인크립션(encryption)/디크립션(decryption)이 품질에 영향을 미치는 시간 요소는 아래의 <그림 4>와 같이 표현할 수 있다.
·링잉 딜레이(Ringing Delay) : 인바이트(INVITE)를 보내고 나서 상대방으로부터 링잉 시그널(ringing signal)을 받는데 걸리는 시간.
·미디어 클리핑 딜레이(media clipping delay) : 미디어 데이터를 암호화/복호화 하기위해 필요한 시간.
아래의 테스트에서는 IPSec을 이용해 시그널과 미디어 데이터를 모두 암호화한 예다. 이때, DUT는 VoIP의 세션을 처리하는 프록시 서버다. VoIP의 클라이언트 숫자를 늘리면서, 성능에 대한 측정을 수행해 봤다.
성능치는 IPSec 터널의 개수, 콜 셋업 레이트(calls/s), 쓰루풋(Mb/s), 엔드 투 엔드 딜레이 포 데이터(ms), 패킷 로스, 지터(ms)를 측정한다. 일반적인 실험들에 의하며 아래의 <그림 6>과 같이 IPSec 터널의 숫자가 증가함에 따라, 음성의 품질은 선형적으로 나빠지며, 콜 셋업 래이트는 지속적으로 심각히 나쁜 영향을 미치는 것을 알 수 있다.
2. 서비스 거부 공격
DoS 공격은 사용자나 기관이 인터넷상에서 평소 잘 이용하던 자원에 대한 서비스를 더 이상 받지 못하게 되는 상황을 가리킨다. VoIP 서비스에서 DoS는 일반적으로 전체 인터넷 서비스를 방해하거나 특정 VoIP 음성 서비스가 동작하지 않거나, 네트워크 접속 및 서비스 등이 일시적으로 제 기능을 발휘하지 못하게 하는 것이다. 최악의 경우 수백만 명이 접속하는 인터넷 전화의 동작이 멈추는 경우도 생겨날 수 있다.
VoIP 시스템에서 DoS 공격은 일반 인터넷의 DoS 공격보다 더 취약하다고 할 수 있다. VoIP 시스템에 대한 공격시에도 인터넷의 고전적인 공격방법을 적용할 수 있지만, VoIP시스템 고유의 취약성을 이용한 공격이 더 막기 어렵다고 할 수 있다.
씬 플루딩 공격
만약 VoIP 시스템이 VoIP 서비스에 대한 TCP 콜 셋업을 제공한다면, 씬 어택 TCP의 공격을 이용해 서비스 거부 공격을 수행할 수 있다. 이에 대한 대응으로 TCP 씬 레이트를 제한하는 레이트 리미트(rate limit) 기능을 사용하거나, TCP 쿠키 기술을 사용해 불필요한 씬 세션을 감소시킬 수 있다. 무엇보다 사용하지 않는 TCP 포트를 제거하는 것이 합리적이다.
인바이트 리퀘스트 플루드 공격
TCP 공격이외에 일반적인 UDP 서비스시에도 DoS 공격에 취약하다. 인바이트 리퀘스트 플루드 공격은 UDP/TCP 모든 전송 기반의 공격이다. 인커밍 콜(Incoming call)을 많이 만들면 SIP 프록시의 CPU 자원을 많이 소비시킨다. 엔드 유저에게도 짧은 시간에 많은 리퀘스트를 요구하며 서비스에 지장을 초래한다.
이런 인바이트 플루딩 공격은 UDP에 기반하기 때문에 손쉽고 파괴적으로 공격 패킷을 생성할 수 있어 주의해야 할 대상이다. 인바이트 및 다양한 메소드 리퀘스트(Method Reques)의 처리시에 프록시 서버는 많은 계산량을 필요로 하기 때문에 보안에 취약하다고 할 수 있다. 가령 초당 3천 콜을 처리하는 프록시 서버의 경우 초당 수천개의 UDP 패킷 공격에도 시스템의 서비스에 장애가 발생할 수 있다.
이런 인바이트 리퀘스트 플루드 공격에 대응하기 위해서는 SIP OK를 조사해 콜 액셉트 레벨(call acceptance label)를 모니터링할 필요가 있다. 이는 인바이트 리퀘스트 플루드 공격을 막기 위해 씬이나 ACK의 레이트를 제한하는 방식과 유사하다. 또한, 검증되지 않거나 불법적인 인바이트 패킷에 대한 애플리케이션 레벨의 필터링이 필요하다.
미디어 플루드 공격
미디어 플루드(Media flood) 공격은 불법적으로 RTP를 무차별하게 타깃 시스템에 전송하는 공격이다. 이러한 공격은 세션과 상관없이 별도로 공격이 이뤄 질 수 있다. 또한 RTP 스트림 공격(stream attack)을 막기 위해서는 악성 RTP 혹은 유행 RTP 데이터를 판별해, 허용하지 않는 것이다.
RTP 스트림의 파라미터는 콜의 연결 시간에 모니터링돼 식별될 수 있다. 각각의 스트림에 대해 정책을 수립하고. 대용량의 스트림에 대해서는 통계적인 방식을 이용해 스트림의 입력 통제를 수행할 수 있다. 이는 일반적으로 VoIP 방화벽의 다이내믹 핀홀 기능에 의해 효과를 볼 수 있다.
그 이외에, PSTN망과 관련된 DoS가 있을 수 있다. PSTN을 이용한 공격에는 미디어서버(M/S) 게이트웨이와 PSTN STP 사이의 시그널링 링크(signaling link)가 메시지로 초과하는 공격, M/S 게이트웨이의 음성 포트를 완전 할당하는 방식으로 서비스 거부를 유도할 수 있다.
아래의 <그림 7>은 실제 DoS 공격의 모의 실험 공격을 나타낸 구성도다. 이때, DUT는 VoIP의 세션을 처리하는 프록시 서버다.
공격의 방법에는 아래와 같은 시나리오를 생각할 수 있다.
