Detecting DoS Attacks on SIP Systems - PowerPoint PPT Presentation

1 / 35
About This Presentation
Title:

Detecting DoS Attacks on SIP Systems

Description:

Detecting DoS Attacks on SIP Systems. Eric Chen, Ph.D. ... Detects DoS attacks on H.323 gatekeepers with illegitimate RAS (Registration, ... – PowerPoint PPT presentation

Number of Views:131
Avg rating:3.0/5.0
Slides: 36
Provided by: com49
Category:
Tags: dos | sip | attacks | detecting | dos | systems

less

Transcript and Presenter's Notes

Title: 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
Write a Comment
User Comments (0)
About PowerShow.com