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
• 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
SIP signaling
Media Stream
Media Stream
Accounting data
• VoIP protocols are vulnerable to attacks Sniffing

– Interruption of Service attacks

(Denial of Service, DoS) (D)DoS
– Attacks against infrastructures attack
and terminals
– Social attacks
(SPam over Internet Telephony, SPIT) SIP
server
– Disturbances and interruptions of work
by ringing phone for unsolicited calls
Accounting
– Interception and Modification & Charging Media
– Conversations may be intercepted server
proxy
(lack of confidentiality)
– Private information can be learnt Wire
tapping
(caller ID, DTMF password/accounts, SIP
Fraud server
etc.)
– Conversations/signaling may be
modified (lack of integrity)
– Abuse of Service (Fraud)
– Unauthorized or unaccountable SPIT
resource utilization, fake identity,
impersonation, session replay (bank
session), etc.
 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
• 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
 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

• Example: Malicious Gateway

MGCP Call Agent
SIP SS7
SIP phone

PSTN

Internet PCM
RTP-
RTCP

Gateway
 VoIP: the need for Event Correlation

• Example: Malicious Gateway

MGCP Call Agent

SIP phone

PSTN

Internet 200 OK DLCX

RTP flow still

received !! Gateway
 VoIP: the need for Event Correlation

• Example: Malicious Gateway

MGCP Call Agent

SIP phone

PSTN

Internet t: “OK is received“

Gateway

ALARM > t: “RTP is still received“

Event Correlation in two layers
 Events : examples
• Log files (e.g. Asterisk) Clid “””mohamed nassar””
• Call log (CDR’s) <mohamed>”

• Message log Src “mohamed”

Dst “1234”
Oct 13 17:41:46 NOTICE[15410]: Dcontex “tutorial”
Registration from ‘”mohamed” Channel “SIP/mohamed-cab2”
<sip:mohamed@1.2.3.4>’ failed for ‘1.2.3.4’
Dstchannel “SIP/radu27a”
Lastapp “Dial”
• Protocol Messages
Lastdata “SIP/radu”
– e.g. RTP
Start “2005-10-13 18:02:42”
Answer
Arrival Time Nov 7 2006 09/06:53
End “2005-10-13 18:03:01”
IP source 192.168.1.106
Duration 19
IP destination 192.168.1.4
Source port 49154 Billsec 0

Destination port 17138 Disposition “Busy”

RTP Header Amaflags “Documentation”

Sq. Number 23086 Account code
Time stamp 0 Uniqueid
SSRC 273598425 Userfield
 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
INVITE INVITE
PairWithWindow PairWithWindow

200 OK 200 OK
event INVITE-200OK event INVITE-200OK

Single PairWithWindow
Cond = INVITE Window = 2s
BYE ACK
event INVITE-200OK-BYE event broken handshaking

Call-ID,
From + To tags
PairWithWindow SingleWithThreshold
Window = 5s Threshold = 10
RTP
Shellcmd notify.sh Shellcmd notify.sh
“broken handshaking DoS” “broken handshaking DoS”
Call-ID,
From + To tags Rule set to detect broken
Rule set to detect BYE-
handshaking flooding
CANCEL Attack
Diagram of SEC Rule sets
 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
• “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
• Holistic security monitoring approach
– VoIP honey pot (supposed to be effective mainly against SPIT,
Vishing)
– Two layers event correlation framework (for misuse detection)
– SEC extensions different from other work in literature
– not only based on the network traffic
– covers a large set of events (log messages, CDRs).
– events can be treated differently based on the priority of the related
agent
– (e.g. : SIP server against phone)
• VoIP IDS / SEC prototype successfully tested in lab
environment
– ready to go to production environment
• Future work:
– Real life tests and performance evaluation
– Investigating network anomaly detection and machine learning
inspired paradigms
– A dynamic threshold adjustment model to resolve the adversary
adaptation and enhance defense against “tester attackers”