Detecting DoS Attacks on SIP Systems

1
Detecting DoS Attacks on SIP Systems

• Eric Chen, Ph.D.
• NTT Information Sharing Platform Laboratories
• 2006.04.03

2
Agenda

• 1. Scope of our research work
• 2. Our approach
• 3. Animated demo
• 4. Related work
• 5. Conclusion

3
VoIP Threat Taxonomy (adopted from VOIPSA)
Scope of our research
Refer to http//www.voipsa.org for more details
on this taxonomy
4
Scope of Our Research
Scope of this paper
5
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

6
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

7
SIP Transactions

• 4 finite machines are defined in RFC3261

8
Our Approach State Table

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

9
Flowchart
10
INVITE Server Transaction

• Two major changes
• - Addition of error
• - handling of 200 msgs

11
INVITE Client Transaction
12
Non-INVITE Client Transaction
13
Non-INVITE Server Transaction
14
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
• 300699 error messages that can be tolerated per
  second.

15
Animated Demo
16
Normal
Anomaly Detecting Device
SIP Entity
INVITE
600
17
Normal
Anomaly Detecting Device
SIP Entity
600
ACK
18
Normal
Anomaly Detecting Device
SIP Entity
ACK
19
Scenario 1 Reply Flooding
20
Scenario 1
Anomaly Detecting Device
SIP Entity
100 OK
100 OK
100 OK
100 OK
Corresponding session ID not found
Alert
21
Scenario 2 Random message generation using a
fixed session ID
22
Scenario 2
Anomaly Detecting Device
SIP Entity
N-INVITE
INVITE
23
Scenario 2
Anomaly Detecting Device
SIP Entity
Alert
24
Scenario 3 Identical Request Flooding with a
Fixed Session ID
25
Scenario 3
Anomaly Detecting Device
SIP Entity
INVITE
600
26
Scenario 3
Anomaly Detecting Device
SIP Entity
600
27
Scenario 3
Anomaly Detecting Device
SIP Entity
INVITE
INVITE
INVITE
INVITE
aaa
INVITE ST
Completed

0
28
Scenario 3
Anomaly Detecting Device
SIP Entity
aaa
INVITE ST
Completed
50
0
Maximum number of packets/transaction exceeded
Alert
29
Scenario 4 Request Flooding with a Fixed
Session ID
30
Scenario 4
Anomaly Detecting Device
SIP Entity
INVITE
INVITE
INVITE
INVITE
INVITE
INVITE
Maximum number of transactions/node exceeded
Alert
31
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.8brancheez9hG4bk17756
• Integer anomalies
• e.g. Content-Length -1
• Invalid addresses
• e.g. INVITE sipuser_at_-1.-1.-1.-1 SIP/2.0
• Structural anomalies
• e.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

32
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

33
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

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

35
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