detecting dos attacks on sip systems
Download
Skip this Video
Download Presentation
Detecting DoS Attacks on SIP Systems

Loading in 2 Seconds...

play fullscreen
1 / 35

Detecting DoS Attacks on SIP Systems - PowerPoint PPT Presentation


  • 91 Views
  • Uploaded on

Detecting DoS Attacks on SIP Systems. Eric Chen, Ph.D. NTT Information Sharing Platform Laboratories 2006.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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Detecting DoS Attacks on SIP Systems' - abie


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
detecting dos attacks on sip systems

Detecting DoS Attacks on SIP Systems

Eric Chen, Ph.D.

NTT Information Sharing Platform Laboratories

2006.04.03

agenda
Agenda

1. Scope of our research work

2. Our approach

3. Animated demo

4. Related work

5. Conclusion

voip threat taxonomy adopted from voipsa
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 Our Research

Scope of this paper

our approach
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
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
sip transactions
SIP Transactions
  • 4 finite machines are defined in RFC3261
our approach state table
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)
invite server transaction
Two major changes:

- Addition of “error”

- handling of 200 msgs

INVITE Server Transaction
four thresholds
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.
normal

Session ID

Transaction

State

Pkt count

Error count

aaa

INVITE ST

Proceeding

1

0

Normal

Anomaly Detecting Device

SIP Entity

INVITE

600

normal1

Session ID

Transaction

State

Pkt count

Error count

aaa

INVITE ST

Completed

2

0

Normal

Anomaly Detecting Device

SIP Entity

ACK

600

normal2

Session ID

Transaction

State

Pkt count

Error count

aaa

INVITE ST

Confirmed

3

0

Normal

Anomaly Detecting Device

SIP Entity

ACK

scenario 1

Session ID

Transaction

State

Pkt count

Error count

Scenario 1

Anomaly Detecting Device

SIP Entity

100 OK

100 OK

100 OK

100 OK

Corresponding session ID not found

Alert

scenario 2

Session ID

Transaction

State

Pkt count

Error count

aaa

INVITE ST

Proceeding

1

0

Scenario 2

Anomaly Detecting Device

SIP Entity

N-INVITE

INVITE

scenario 21

Session ID

Transaction

State

Pkt count

Error count

aaa

INVITE ST

Error

2

1

Scenario 2

Anomaly Detecting Device

SIP Entity

Alert

scenario 3

Session ID

Transaction

State

Pkt count

Error count

aaa

INVITE ST

Proceeding

1

0

Scenario 3

Anomaly Detecting Device

SIP Entity

INVITE

600

scenario 31

Session ID

Transaction

State

Pkt count

Error count

aaa

INVITE ST

Completed

2

0

Scenario 3

Anomaly Detecting Device

SIP Entity

600

scenario 32

Session ID

Transaction

State

Pkt count

Error count

Scenario 3

Anomaly Detecting Device

SIP Entity

INVITE

INVITE

INVITE

INVITE

aaa

INVITE ST

Completed

0

scenario 33

Session ID

Transaction

State

Pkt count

Error count

Scenario 3

Anomaly Detecting Device

SIP Entity

aaa

INVITE ST

Completed

50

0

Maximum number of packets/transaction exceeded

Alert

scenario 4

Session ID

Transaction

State

Pkt count

Error count

xxx

bbb

ccc

aaa

ddd

INVITE ST

INVITE ST

INVITE ST

INVITE ST

INVITE ST

Proceeding

Proceeding

Proceeding

Proceeding

Proceeding

1

1

1

1

1

0

0

0

0

0

Scenario 4

Anomaly Detecting Device

SIP Entity

INVITE

INVITE

INVITE

INVITE

INVITE

INVITE

Maximum number of transactions/node exceeded

Alert

related work 1
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 anomalies

e.g. Content-Length: -1

    • Invalid addresses

e.g. INVITE sip:[email protected] 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
related work 2
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
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
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
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
ad