Holistic VoIP Intrusion Detection and Prevention System: Holistic VoIP Intrusion Detection and Prevention System Mohamed Nassar, Saverio Niccolini, Radu State, Thilo Ewald joint work of Loria-Inria and NEC Laboratories Europe


VoIP Security: VoIP Security We are experiencing the migration from circuit switched (PSTN) to packet switched (VoIP) telephony Next Generation Networks (NGN) Today’s VoIP is an insecure technology Not sufficiently prepared for defense against attacks New threat models and attacks Security is very important when VoIP gets deployed massively like in Next Generation Networks (NGN) Lack of secure solutions threatens to significantly reduce VoIP business Providing secure solutions is required for continuing strong growth there will not be THE solution


VoIP Security Threats: VoIP Security Threats VoIP protocols are vulnerable to attacks Interruption of Service attacks (Denial of Service, DoS) Attacks against infrastructures and terminals Social attacks (SPam over Internet Telephony, SPIT) Disturbances and interruptions of work by ringing phone for unsolicited calls Interception and Modification Conversations may be intercepted (lack of confidentiality) Private information can be learnt (caller ID, DTMF password/accounts, etc.) Conversations/signaling may be modified (lack of integrity) Abuse of Service (Fraud) Unauthorized or unaccountable resource utilization, fake identity, impersonation, session replay (bank session), etc. SIP server SIP server Media proxy Accounting andamp; Charging server (D)DoS attack Wire tapping Fraud SPIT


Intrusion detection and prevention: Architecture: Intrusion detection and prevention: Architecture Divide and conquer: distributed approach for countering different threats Honey-pot to detect sources of malicious attacks and unsolicited calls Network-based Intrusion Detection System (NIDS) to detect attack patterns Event correlation framework to detect distributed signatures Anomaly detection based on user profiles to detect abuse of services Assembling complementary solutions in one holistic in depth approach


Honey-pot: Honey-pot A Honey-pot is a trap set to detect, deflect or in some manner counteract attempts at unauthorized use of information systems Generally consists of a computer, data or a network site appears to be part of a network but is actually isolated and protected seems to contain information or a resource that would be of value to attackers Honey-pots are used as surveillance and early-warning tools Honey-pots masquerade as systems of the types abused by spammers to send spam. for example, using domain names that attract interest (www.nec-bank.com) or covering all unused IP addresses of a range owned by an enterprise. Ordinary e-mail never comes to a Honey-pot They can categorize the material they trap 100% accurately: it is all illicit, no further checking required Honey-pots are used as attack detection systems and for attack analysis


VoIP Honey-pot: VoIP Honey-pot


How to use Honey-pot: How to use Honey-pot Step 1: make Honey-pot users a target publish virtual SIP URLs and phone numbers at public places that are scanned by address search engines easy to be detected by engines, but invisible for regular users (e.g. white font on white background of a web page) host these published addresses at one or more Honey-pots properly route calls to Honey-pot users Step 2: store all callers using these addresses by calling the Honey-pot Step 3: analyze the received calls/messages to gather more information voice recognition, speaker recognition match caller ID and source IP address (spoofing detection) statistical analysis identification of individual machines or entire bot networks Step 4: use gathered information as input for prevention systems add frequent callers (URL or IP address) to black list increase malicious rating for calls/messages that have properties similar to calls observed at Honeypot


VoIP: the need for Event Correlation: VoIP: the need for Event Correlation Example: Malicious Gateway MGCP Call Agent Gateway SIP phone PSTN Internet SS7 SIP PCM RTP-RTCP


VoIP: the need for Event Correlation: MGCP Call Agent Gateway SIP phone PSTN Internet DLCX 200 OK RTP flow still received !! VoIP: the need for Event Correlation Example: Malicious Gateway


VoIP: the need for Event Correlation: MGCP Call Agent Gateway SIP phone PSTN Internet t: 'OK is received' andgt; t: 'RTP is still received' ALARM VoIP: the need for Event Correlation Example: Malicious Gateway


Event Correlation in two layers: Event Correlation in two layers


Events : examples: Events : examples Log files (e.g. Asterisk) Call log (CDR’s) Message log Oct 13 17:41:46 NOTICE[15410]: Registration from ‘'mohamed' andlt;sip:mohamed@1.2.3.4andgt;’ failed for ‘1.2.3.4’ Protocol Messages e.g. RTP


Events modeling and generation: Events modeling and generation Threading Example 1 : threading signaling messages in one call record Example 2 : threading repeated events in one dense event Temporal restrictions Scheduling restrictions Event A has to occur at time t Inter-arrival time Event B has to occur after Event A in a time window of T VoIP Event correlation done using SEC (Security Event Correlation): Open source and platform independent Lightweight online monitoring tool Middle-way between homegrown and commercial event correlation Proven efficiency in several application domains (network management, intrusion detection, system monitoring, fraud detection) Written in Perl and based on Perl regular expressions thanks to Risto Vaarandi Powerful and extensible with medium effort


Event correlation: Misuse detection: Event correlation: Misuse detection Rule set to detect broken handshaking flooding PairWithWindow PairWithWindow Window = 2s SingleWithThreshold Threshold = 10 Shellcmd notify.sh 'broken handshaking DoS' event INVITE-200OK event broken handshaking INVITE 200 OK ACK PairWithWindow Single Cond = INVITE PairWithWindow Window = 5s Shellcmd notify.sh 'broken handshaking DoS' event INVITE-200OK event INVITE-200OK-BYE INVITE 200 OK BYE Rule set to detect BYE-CANCEL Attack RTP Diagram of SEC Rule sets


Anomaly detection (using events): Anomaly detection (using events) User behavior, Group of users behavior, Software behavior, Traffic model User behavior : Stationary : Bin = one hour (different level of aggregation) Event = call Metric = number of calls, number of different recipients, duration of a call Defining long and short terms Long term profile = one month Short term profile = one day Distance = Euclidean, Quadratic, etc. Non stationary : Comparing changing of a distribution to detect sudden bursts of changes= Distribution of calls over callees, shape of the callee list size over all dialed calls


Implementation: Implementation 'tosec' module in OpenSER server acting as a FIFO queue towards the SEC engine Graphical interface with a round robin database to update traffic shape Implementing misuse detection rule sets of well known signatures Detection of a DoS pitch


Conclusion and Future works: Conclusion and Future works