detecting dos attacks on sip systems eric chen, ph.d. ntt information sharing platform laboratories...

Detecting DoS Attacks on SIP Systems

Eric Chen, Ph.D.NTT Information Sharing Platform Laboratories2006.04.03

Agenda

1. Scope of our research work

2. Our approach

3. Animated demo

4. Related work

5. Conclusion

VoIP Threat Taxonomy (adopted from VOIPSA)

Scope of our research

Refer to http://www.voipsa.org for more details on this taxonomy

Scope of Our Research

Scope of this paper

Our Approach Detect anomalies using

Finite machines for SIP transaction defined in RFC3261 Traffic rate thresholds

Speculate and keep track of transaction states of each SIP entity by looking at Incoming packets Outgoing packets Timer values

May be deployed as in-line or out-of-line network-base IDS

Assumes that data traffic is not encrypted

Transaction Layer

Handles message retransmission and acknowledgement (hide the details from application core)

SIP transaction = request + responses to the request Each UA and proxy has both client transactions (CT) and

server transactions (ST) CT: sends request and receives response ST: receives request and sends response

UAC Core(caller)

Stateful Proxy Core

Stateless Proxy Core

UAS Core(callee)

Client Transaction

Server Transaction

Client Transaction

ServerTransaction

TCP/UDP

IP

Transaction User

Transaction Layer

Transport Layer

Network Layer

SIP Transactions

4 finite machines are defined in RFC3261

Type Request Description

CT INVITE Created when an INVITE request is sent

Non-INVITE Created when a non-INVITE request is sent

ST INVITE Created when an INVITE request is received

Non-INVITE Created when a non-INVITE request is received

Our Approach: State Table

SessionID

Transaction Type Session Start Time

Current State PacketCount

Error Count

aaa INVITE ST 3 Feb 2006 20:40:01 Proceeding 1 0

bbb INVITE CT 3 Feb 2006 20:43:30 Calling 2 0

ccc Non-INVITE ST 3 Feb 2006 20:45:02 Trying 1 0

ddd Non-INVITE CT 3 Feb 2006 20:50:05 Completed 3 0

One table for each SIP entity One entry for each transaction (a request packet with a new session ID

creates a new entry) Session ID

For server transaction: branch parameter + sent-by + method For client transaction: branch parameter + method (for RFC 2543, Request-URI + To + From + Call-ID + CSeq + top Via)

Flowchart

SIP packet arrived

Create a new entry to state table

New session ID?

Error count

Ｙ Request?

NＮ

Update state table

Error?

Ｙ

Ｎ

Count > Threshold?

Attack detected

Ｙ

Ｎ

Y

INVITE Server Transaction

Two major changes:

- Addition of “error”

- handling of 200 msgs

Sets Elements

Rq All request messages

Rs All response messages

I Informational responses (1xx)

S Success response (2xx)

E Error responses (300~699)

Proceeding

Completed

Confirmed

Terminated

INVITEIN

transport err.

Timer H OR transport err.

EOUT

ACKIN

Timer I

Error

(RqÈRs\{ACK})IN

Entry created

Error count

Error count

(RqÈRs\{INVITE})IN

INVITEIN OR IOUT

INVITEIN OR RsOUT

(RqÈRs\{INVITE})IN

Error count

ACKIN ORSOUT

SOUT

INVITE Client Transaction

Sets Elements






Calling

Proceeding

Completed

Terminated

INVITEOUT

Timer B ORTransport error

SIN

IIN

EIN ANDACKOUT

Timer D OR transport error

Error

(RqÈRs\E)IN

Entry created

Error count generated

Error count generated

(RqÈRs)IN

INVITEOUT

IIN

EIN AND ACKOUT

SIN

SIN

Non-INVITE Client Transaction

Trying

Proceeding

Completed

Terminated

(Rq\{INVITE})OUT

Timer F

Timer F

IIN

(SÈE)IN

Timer K

Error

(RqÈRs)IN

Entry created

Error count

Error count(RqÈRs)IN

(Rq\{INVITE})OUT

IIN (Rq\{INVITE})OUT

(SÈE)IN (RqÈRs\I)IN

Error count

Sets Elements






Non-INVITE Server Transaction

Trying

Proceeding

Completed

Terminated

(Rq\{INVITE})IN

(SÈE)OUT

transport err.

IOUT

(SÈE)OUT

Timer J or transport err.

Error

(RsÈ{INVITE})IN

Entry created

Error count

Error count(RqÈRs)IN

(Rq\{INVITE})IN ÈRsOUT

(RsÈ{INVITE})IN

Error count

(Rq\{INVITE})IN ÈRsOUT

Sets Elements






Four Thresholds Threshold 1: number of allowed transaction error per second.

Frequent occurrences of unexpected incoming messages

are a strong indication of an attack. Threshold 2: number of allowed packet rate per transaction

Prevents retransmission flooding Threshold 3: number of allowed transactions per node

(easier to configure on UAs) Prevents resource consumption with valid transactions

Threshold 4: number of allowed SIP application error per second 300~699 error messages that can be tolerated per second.

Animated Demo

Normal

Anomaly Detecting Device SIP Entity

InternetINVITE

Session ID Transaction State Pkt count Error count

aaa INVITE ST Proceeding 1 0Proceeding

Completed

Confirmed

INVITEIN

SOUT OR transport err.


EOUT

ACKIN

Timer I

Error

(RqÈRs\{ACK})IN OR N(ACKIN)>T

(Error count)

(Error count)

(RqÈRs\{INVITE})IN

OR N(INVITEIN)>T

INVITEIN OR IOUT

INVITEIN OR IOUT

(RqÈRs\{INVITE, ACK})IN

OR N({INVITE, ACK}IN)>T

(Error count)

ACKIN

600

Normal


Internet


aaa INVITE ST Completed 2 0Proceeding

Completed

Confirmed

INVITEIN



EOUT

ACKIN

Timer I

Error


(Error count)

(Error count)

(RqÈRs\{INVITE})IN

OR N(INVITEIN)>T

INVITEIN OR IOUT

INVITEIN OR IOUT



(Error count)

ACKIN

600ACK

Normal


Internet


aaa INVITE ST Confirmed 3 0Proceeding

Completed

Confirmed

INVITEIN



EOUT

ACKIN

Timer I

Error


(Error count)

(Error count)

(RqÈRs\{INVITE})IN

OR N(INVITEIN)>T

INVITEIN OR IOUT

INVITEIN OR IOUT



(Error count)

ACKIN

ACK

Scenario 1: Reply Flooding

Scenario 1Anomaly Detecting Device SIP Entity

Internet100 OK


Corresponding session ID not found

Alert

100 OK100 OK100 OK

Scenario 2: Random message

generation using a fixed session ID


InternetINVITE



Completed

Confirmed

INVITEIN



EOUT

ACKIN

Timer I

Error


(Error count)

(Error count)

(RqÈRs\{INVITE})IN

OR N(INVITEIN)>T

INVITEIN OR IOUT

INVITEIN OR IOUT



(Error count)

ACKIN

N-INVITE


Internet


aaa INVITE ST Error 2 1Proceeding

Completed

Confirmed

INVITEIN



EOUT

ACKIN

Timer I

Error


(Error count)

(Error count)

(RqÈRs\{INVITE})IN

OR N(INVITEIN)>T

INVITEIN OR IOUT

INVITEIN OR IOUT



(Error count)

ACKIN

Alert

Scenario 3: Identical Request Flooding

with a Fixed Session ID


InternetINVITE



Completed

Confirmed

INVITEIN



EOUT

ACKIN

Timer I

Error


(Error count)

(Error count)

(RqÈRs\{INVITE})IN

OR N(INVITEIN)>T

INVITEIN OR IOUT

INVITEIN OR IOUT



(Error count)

ACKIN

600


Internet



Completed

Confirmed

INVITEIN



EOUT

ACKIN

Timer I

Error


(Error count)

(Error count)

(RqÈRs\{INVITE})IN

OR N(INVITEIN)>T

INVITEIN OR IOUT

INVITEIN OR IOUT



(Error count)

ACKIN

600


Internet


aaa INVITE ST Completed … 0Proceeding

Completed

Confirmed

INVITEIN



EOUT

ACKIN

Timer I

Error


(Error count)

(Error count)

(RqÈRs\{INVITE})IN

OR N(INVITEIN)>T

INVITEIN OR IOUT

INVITEIN OR IOUT



(Error count)

ACKIN

INVITEINVITEINVITEINVITE


Internet



Completed

Confirmed

INVITEIN



EOUT

ACKIN

Timer I

Error


(Error count)

(Error count)

(RqÈRs\{INVITE})IN

OR N(INVITEIN)>T

INVITEIN OR IOUT

INVITEIN OR IOUT



(Error count)

ACKIN

Maximum number of packets/transaction exceeded

Alert

Scenario 4: Request Flooding with a

Fixed Session ID


InternetINVITE


aaa INVITE ST Proceeding 1 0

INVITE

bbb INVITE ST Proceeding 1 0

INVITE

ccc INVITE ST Proceeding 1 0

INVITE

ddd INVITE ST Proceeding 1 0

INVITE

xxx INVITE ST Proceeding 1 0

INVITE

Maximum number of transactions/node exceeded

Alert

Related Work 1 PROTOS by Oulu University & SIP Test Tool by Codenomicon Used for fuzzing test (or fuzzing attack if used maliciously) Generate malformed messages against a SIP server or client to test

if the subject is able to endure and handle these messages Overflow

e.g. Via: SIP/2.0/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 192.168.2.8;branch=eez9hG4bk17756

Integer anomaliese.g. Content-Length: -1

Invalid addressese.g. INVITE sip:[email protected] SIP/2.0

Structural anomaliese.g. Cseq: 7038 INVITE a1 a2 a3 a4 a5 a6 a7 a8 a9 a10

Some implementations are reported to crash after receiving these messages Mainly used as a black box testing tool to discover problems before

product delivery

Related Work 2 Geneiatakis D "A Framework for Detecting Malformed

Messages in SIP Networks", 2005 IEEE Workshop on Local and Metropolitan Area Networks

Detect fuzzing attack Adds a set to rules to IDS (e.g. Snort) to verify if each incoming

SIP message is grammatically correct according to the RFC specification

Can discard malformed messages before they reach the destination if deployed in-line

Related Work 3

Melody Moh et al, “Specification-based Intrusion Detection for H.323-based Voice over IP”, 2005 IEEE International Symposium on Signal Processing and Information Technology

Detects DoS attacks on H.323 gatekeepers with illegitimate RAS (Registration, Admission and Status) messages

Looks for unexpected messages by running a finite-state machine

Shares a number of assumptions with our work

Related Work 4 Y. Wu, S. Bagchi, S. Garg, N. Singh and T. Tsai, “SCIDIVE: A Stateful

and Cross Protocol Intrusion Detection Architecture for Voice-over-IP Environments”, DSN'04

Proposes two detection abstractions: Stateful detection

determines the current state of a subject from multiple packets involved in the same session and detects anomaly using a rule-matching engine.

Cross-protocol detection Most VoIP systems use different protocols

for signaling and media sessions inspect anomalies such as inconsistency

between two different protocols involved in the same VoIP session (e.g. caused by a billing fraud)

Conclusion Proposed a method for detecting DoS attacks

invalid SIP messages request flooding

Future work still at the preliminary stage build a prototype to test the concept address possible synchronization problems between detection

device and the monitored SIP entities Packet loss Packet latency (out-of-sync timers)

Study of scalability and overhead Mitigation strategies

detecting dos attacks on sip systems eric chen, ph.d. ntt information sharing platform laboratories...

Documents