1 / 35

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

abie
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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. Two major changes: - Addition of “error” - handling of 200 msgs INVITE Server Transaction

  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 • 300~699 error messages that can be tolerated per second.

  15. Animated Demo

  16. Session ID Transaction State Pkt count Error count aaa INVITE ST Proceeding 1 0 Normal Anomaly Detecting Device SIP Entity INVITE 600

  17. Session ID Transaction State Pkt count Error count aaa INVITE ST Completed 2 0 Normal Anomaly Detecting Device SIP Entity ACK 600

  18. Session ID Transaction State Pkt count Error count aaa INVITE ST Confirmed 3 0 Normal Anomaly Detecting Device SIP Entity ACK

  19. Scenario 1: Reply Flooding

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

  21. Scenario 2: Random message generation using a fixed session ID

  22. Session ID Transaction State Pkt count Error count aaa INVITE ST Proceeding 1 0 Scenario 2 Anomaly Detecting Device SIP Entity N-INVITE INVITE

  23. Session ID Transaction State Pkt count Error count aaa INVITE ST Error 2 1 Scenario 2 Anomaly Detecting Device SIP Entity Alert

  24. Scenario 3: Identical Request Flooding with a Fixed Session ID

  25. Session ID Transaction State Pkt count Error count aaa INVITE ST Proceeding 1 0 Scenario 3 Anomaly Detecting Device SIP Entity INVITE 600

  26. Session ID Transaction State Pkt count Error count aaa INVITE ST Completed 2 0 Scenario 3 Anomaly Detecting Device SIP Entity 600

  27. Session ID Transaction State Pkt count Error count Scenario 3 Anomaly Detecting Device SIP Entity INVITE INVITE INVITE INVITE aaa INVITE ST Completed … 0

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

  29. Scenario 4:Request Flooding with a Fixed Session ID

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

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

  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

More Related