Detecting dos attacks on sip systems
This presentation is the property of its rightful owner.
Sponsored Links
1 / 35

Detecting DoS Attacks on SIP Systems PowerPoint PPT Presentation


  • 70 Views
  • Uploaded on
  • Presentation posted in: General

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.

Download Presentation

Detecting DoS Attacks on SIP Systems

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)


Flowchart

Flowchart


Invite server transaction

Two major changes:

- Addition of “error”

- handling of 200 msgs

INVITE Server Transaction


Invite client transaction

INVITE Client Transaction


Non invite client transaction

Non-INVITE Client Transaction


Non invite server transaction

Non-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.


Animated demo

Animated Demo


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 reply flooding

Scenario 1: Reply Flooding


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 random message generation using a fixed session id

Scenario 2: Random message generation using a fixed session ID


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 identical request flooding with a fixed session id

Scenario 3: Identical Request Flooding with a Fixed Session ID


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 request flooding with a fixed session id

Scenario 4:Request Flooding with a Fixed Session ID


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:user@-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


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


  • Login