SIP Intrusion Detection and Response Architecture for Protecting SIP-based Services

SIP Intrusion Detection and Response Architecture for Protecting SIP-based Services KyoungHee Ko, Hwan-Kuk Kim, JeongWook Kim, Chang-Yong Lee, HyunCheol Jeong Applied Security Technology Team Korea Information Security 78, Garak-Dong, Songpa-Gu, Seoul South Korea Abstract: After 3GPP had selected SIP as the signaling protocol for IMS, it is expected that SIP plays an important role in IP multimedia services. But, since SIP-based services are offered over the internet, there are security threats inherited from the internet environment. There are also new security threats because new techniques have been introduced to deliver multimedia traffic over the internet. In this paper, we propose the SIP intrusion detection and response architecture for protecting SIP-based services. The proposed architecture consists of detection of SIP-based attacks, detection of SIP traffic anomaly, and management of SIP-aware security devices. This is helpful to counter newly introduced SIP-based attacks without degradation of multimedia quality. Key-Words: SIP, VoIP, Internet telephony, IMS, Intrusion detection and response, Traffic anomaly detection, Security event correlation 1 Introduction SIP(Session Initiation Protocol) is a signalling protocol for initiating, managing, and terminating multimedia sessions [1]. SIP-based services are IP multimedia communication services such as VoIP(Voice over Internet Protocol), presence service, instant messaging, and video conferencing. SIP was developed by IETF(the Internet Engineering Task Force) [2]. After 3GPP(The 3rd Generation Partnership Project) had selected SIP as the signaling protocol for IMS(IP Multimedia Core Network Subsystem), many other standards evolved to align with the 3GPP s IMS [3]. Therefore, it is expected that SIP plays an important part in IP multimedia services. For example, in Korea, SIP-based VoIP service begins to gain popularity as the result of the government s promoting policies, service providers marketing strategies, low service charge rates, and various value-added services. But, since SIP-based services are offered over the internet, there are security threats inherited from the internet environment such as virus or worm. There are also new security threats because new techniques have been introduced to deliver multimedia traffic over the internet. In order to counter attacks to SIP-based services, traditional IP-based security solutions have evolved. But they have limitations because countering SIP-based attacks should consider the following characteristics. First, signaling path and media traffic path are separated in SIP-based service. Like other multimedia protocols such as Windows Media Technology [4], Real Media [5], and QuickTime [6], SIP-based services use SIP as the signaling protocol for establishing sessions and RTP(Real-time Transport Protocol) as the media protocol for transferring streaming data. This means it is needed to use cross protocol intrusion detection approach. Cross protocol detection denotes the functionality of matching rules that span multiple protocols, e.g., detecting a pattern in a SIP packet followed by one in a succeeding RTP [11]. Second, SIP-based services are sensitive to network QoS(Quality of Service) such as delay, jitter, and packet loss. This means performance for detection and response are very critical. That is, detection and response should not degrade QoS even if detection mechanism needs deep packet inspection to parse payload of packets in the application layer. This also means it is needed to keep track of network QoS metrics to monitor end-to-end service quality. Therefore, in this paper, we propose SIP intrusion detection and response architecture for protecting SIP-based services. The architecture is proposed to ISSN: 1790-5109 405 ISBN: 978-960-474-028-4

satisfy the requirements for countering SIP-based attacks. 2 Related Works Related works to protect SIP-based services are divided into three groups. First, there are SIP-aware ALGs(application level gateways) such as SIPAssure [5]. While traditional firewall solutions open a range of ports for supporting RTP, SIP-aware ALGs provide dynamic pinhole filtering which can dynamically open and close media ports for call duration based on negotiations observed in signaling [6]. But this approach is focused on filtering, not detecting SIP-based attacks. Second, traditional IDS(Intrusion Detection System) expands its detection capability to detect SIP-based attacks. There are TippingPoint [7] and SNOCER project [8]. This group can detect malformed SIP messages and SIP DoS(Denial of Service) based on signature based detection scheme. But their signatures are rather limited and they can not detect sophisticated SIP-based attacks such as toll fraud. Third, there are SIP-aware security devices such as Sipera IPCS [9] and VoIP SEAL [10]. Sipera IPCS provides VPN(Virtual Private LAN), IPS(Intrusion Prevention System), and Anti-Spam based on VoIP SBC(Session Border Controller). VoIP SEAL provides solutions to filter spam over internet telephony. Attackers can interrupt call by using SIP message modification and session hijacking between legitimate users.(1) Attackers can also aim at toll fraud through bypassing authentication.(2) In order to block these kinds of attacks, SIP-aware IPS(a) needs to inspect signal and media channels. Attackers can compromise many computers through using malicious programs like worms and trojans. The compromised computers become zombie and obey the master s control. This is one possible scenario for DDoS(Distributed Denial of Service) attack to SIP servers. To detect DDoS attack(3), it is needed to monitor traffic and detect traffic anomaly. SIP-aware IPS can detect DDoS attack, but, traffic analyzing can be a big burden on SIP-aware IPS. Therefore it is reasonable to put traffic monitoring sensors(b) at network choke points. Traffic data gathered by sensors are analyzed by traffic analyzer(c). Security Management System(d) is needed to operate and manage SIP-aware IPS, traffic anomaly detection system, and other SIP servers in a uniform manner. 3 SIP Intrusion Detection and Response Architecture In this section, we will introduce the proposed architecture. Section 3.1 and 3.2 give the rationale for the proposed architecture. From section 3.3 to section 3.5, we will describe the major components of the proposed architecture with more detail. 3.1 Overview Fig.1 shows security threats and security solutions in SIP-based services. In a SIP service provider, there are SIP proxy server, SIP registrar server, SIP redirect server, presence server, and IMS server to provide VoIP, video conferencing, instant messaging, and IPTV service. Traditionally IP-based firewalls are deployed in front of the server farms or at network perimeter. Fig. 1. Security threats and security solutions in SIP-based services 3.2 The Proposed Architecture Based on the considerations in Section 3.1, we propose the SIP intrusion detection and response architecture which is useful to protect SIP-based services and to counter newly introduced SIP-based ISSN: 1790-5109 406 ISBN: 978-960-474-028-4

attacks without degradation of multimedia quality. This architecture is depicted in Fig.2. There are three major components in the architecture: SIPS, STAD, and SSMS. SIPS is an abbreviation for SIP Intrusion Protection System. The goal of SIPS is to detect and respond to known SIP-based attacks. STAD is an abbreviation for SIP Traffic Anomaly Detection system. STAD consists of STAD Sensors and STAD Engine. The goal of STAD is to detect SIP traffic anomaly and unknown SIP attacks. SSMS is an abbreviation for SIP Security Management System. SSMS consists of SSMS Agents and SSMS Manager. The goal of SSMS is to operate other SIP-aware devices. SSMS Agents collect and transfer data from/to SIPS and STAD via network. In this architecture, because SSMS Agents have to control SIPS and STAD, they will be drawn in the same box as SIPS and STAD. The first category is SIP DoS which consumes available system resources or network bandwidth. There are SIP INVITE message flooding, SIP REGISTER message flooding, and RTP flooding attacks in this category. SIP DoS attacks are detected by signature-based detection mechanism. For example, if the amount of INVITE messages from various source URIs(Uniform Resource Identifiers) to specific destination URI per unit time exceeds certain threshold, SIPS detects these messages as flooding attack. In Fig.2, SIP Signature-based Detection and RTP Signature-based Detection subcomponents are responsible for this function. SIP Signature-based Detection subcomponent manages rule table as shown in Fig. 3 for detecting SIP DoS. Fig. 3. Rule table for detecting SIP DoS The second category is SIP service abuse which aims at toll fraud. There are registration hijacking, registration forgery by using SQL injection, InviteReplay attack, FakeBusy attack, ByeDelay attack and ByeDrop attack in this category [20]. SQL injection is detected by signature-based detection mechanism. The other attacks in this category will be detected by using SIP session information and protocol state transition model [11][12]. SIP Signature-based Detection and SIP Protocol State-based Detection subcomponents are responsible for this functionality. Fig. 4 shows SIP session information table managed by SIP Protocol State-based Detection subcomponent. Fig. 2. SIP intrusion detection and response architecture 3.3 SIPS(SIP Intrusion Protection System) In this section, we will describe subcomponents in SIPS. SIPS is designed to be installed on inline mode. In Fig. 2, Packet Bypass/Monitoring subcomponent monitors and captures every packet to/from SIP servers. We divide SIP-based attacks into four categories and employ separate detection mechanisms according to attack categories. Fig. 4. SIP Session Info table for detecting SIP service abuse The third category is call interruption which hinder legitimate users from communicating with each others. There are SIP CANCEL attack, deregistration attack, RTP insertion attack, and SIP-BYE attack in this category. Call disturbance attacks will be detected by protocol state transition model and call setup information. SIPS manages call setup information as shown Fig.5. ISSN: 1790-5109 407 ISBN: 978-960-474-028-4

Fig. 5. Call setup table for detecting call interruption If incoming packets are RTP packets from an SIP user who doesn t establish any session with other user, this RTP packet will be assumed as an RTP insertion attack. SIP Protocol State-based Detection subcomponent is responsible for this function. The fourth category is fuzzing attacks which lead to system or applications crash. Fuzzing attacks use malformed SIP header formats which are not allowed or not specified by IETF RFC 3261 [2]. Fuzzing attacks will be detected by using syntax checking. SIP Protocol Decoder & Syntax Check and RTP Protocol Decoder & Syntax Check subcomponents are responsible for this function. Patterns for malformed messages can be obtained from SIP torture test messages(ietf RFC 4475) and protocol testing tools like Abacus and ThreatEx [13]. These patterns are organized into rules as shown in Fig. 6 such as routers and switches. In SIP Packets Identification & Classification subcomponent, SIP packets and corresponding RTP packets are identified. SIP Flow Generation subcomponent generates netflow data [14]. By aggregating packets that belong to the identical flow, we can reduce processing overhead in the system [15]. Netflow version 9 provides templates in which user can define the application layer metrics as well as 5-tuple(source IP, source port, destination IP, destination port, protocol). For example, we can collect netflow data such as the number of INVITE messages(sip-invite-count), the number of BYE messages(sip-bye-count), and the number of REGISTER messages(sip-register-count) in addition to metrics as shown in Fig. 7. The collected data in STAD Sensors are transferred into STAD Engine through SIP Flow Transmitter subcomponent. Fig. 6. Rule table for detecting malformed SIP Header When SIPS detects attacks, it drops the corresponding packets, or filters packets according to pre-defined filtering rules. SIP Attack Quarantine and RTP Attack Quarantine subcomponents are responsible for this function. Because SIPS is designed to be installed on inline mode, it is critical to process packets without performance degradation. Additionally there are GUIs(Graphical User Interfaces) and Interface subcomponents. SIPS Management & View GUI subcomponent is used for administrators to monitor and manage SIPS. STAD Interface subcomponent is for transferring intrusion detection data between SIPS and STAD. Client-Side SSMS Interface Library subcomponent is provided by SSMS Agent. Through this interface library, SIPS communicates with SSMS Agent. 3.4 STAD(SIP Traffic Anomaly Detection) In this section, we will describe subcomponents in STAD. STAD is composed of STAD Sensors and STAD Engine. Collecting Raw Packets subcomponent in STAD Sensors monitors traffic data from network devices Fig. 7. nprobe traffic metrics for VoIP [16] After STAD Engine collects netflow data from various sensors through SIP Flow Collector, SIP Traffic Analyzer Engine subcomponent analyzes the netflow data to detect abnormal traffic based on historical patterns. For example, average jitter(rtp_in_jitter) between 6 and 7 pm on Sunday is calculated. The last 3-month average jitter is calculated at the same time on the same day of a week for last 3 months. If current average jitter is 100% higher than last 3-month average, STAD Engine can detect this flow as anomaly. We can profile user behavior or system behavior based on the netflow data [17]. For example, if the number of INVITE messages(sip-invite-count) for a user during a month is used to detect user s abnormal behavior. The number of INVITE messages for all users during a month is used to detect system s abnormal behavior. Profiling-based Detection Engine subcomponent is responsible for this function. STAD Engine alarms the detection data to SIPS or SSMS. After SIPS receives the detection data, it quarantines ISSN: 1790-5109 408 ISBN: 978-960-474-028-4

the following connections which have the same origins and destinations. STAD also has GUIs and Interface subcomponents additionally. STAD Management & View GUI subcomponent is used for administrators to monitor and manage STAD. SIPS Interface subcomponent is for transferring abnormal traffic data between STAD and SIPS. Client-Side SSMS Interface Library subcomponent is provided for communicating with SSMS Agent. 3.5 SSMS(SIP Security Management System) In this section, we will describe subcomponents in SSMS. SSMS is composed of SSMS Agents and SSMS Manager. SSMS Agents collect security events, system resource information, call statistics, and traffic statistics from SIPS, STAD, and other SIP-aware network devices such as SIP proxy and SBC(Session Border Controller). In order to collect various data and to control heterogeneous systems, format and method for exchanging messages should be defined. Many standards have been proposed such as IETF RFC 4765 [18] and OPSEC [19] for this purpose. Client and Server-side SSMS Interface Library subcomponents in SSMS Agent provide APIs for this purpose. In Normalization and Aggregation subcomponents, security events are normalized and aggregated for using later. Transceiver subcomponents in SSMS Agent and Manager are used for communicating with each other. SSMS manager has Security Event Correlation Engine subcomponent which is responsible for correlating collected events according to pre-defined rules and attack scenarios. For example, it suppresses multiple instances of same events. This prohibits too many alerts from bothering security administrators. If SSMS receives traffic abnormal events from STAD and at the same time, it receives RTP flooding attack events from SIPS, SSMS determines the network is under attack with more confidence. Fig. 8 shows the part of alert message for this example [18]. Fig. 8. The part of alert message for security event correlation Management Control subcomponent is responsible for operating various devices. It translates user s control commands into predefined management message format. Control messages are used to enforce security policy. For example, SIPS should block certain source URI. Control messages are also used to start or stop SIPS or STAD depending on the condition that SIPS or STAD expressed explicitly acceptance of control messages from SSMS. After SIPS or STAD run commands from SSMS, the results of running commands are transferred to Management Control subcomponent through SSMS Agent. SSMS has GUIs for monitoring and managing various devices and SSMS itself. 4 Conclusion In this paper, we introduced SIP intrusion detection and response architecture. In the proposed architecture, there are three major components. SIPS is responsible for detecting SIP-based attacks. STAD is responsible for detecting traffic anomaly based on netflow data. SSMS is used for operating SIPS and STAD in a uniform manner. SSMS collects security events and correlates the events based on predefined rules to overcome each device s detection capabilities.. We are now developing the system based on the proposed architecture. This system intends to be used for middle or small-sized service providers, so the final product for SIPS will be an appliance. Acknowledgement This work was supported by the IT R&D program of MKE/IITA. [2008-S-028-01, The Development of ISSN: 1790-5109 409 ISBN: 978-960-474-028-4

SIP-Aware Intrusion Prevention Technique for protecting SIP-base Application Services] References: [1] SIP: Protocol Overview, Radvision Ltd., 2001 [2] IETF RFC 3261, SIP: Session Initiation Protocol, 2002 [3] IETF Internet-Draft, 3GPP R5 requirements on SIP, 2002 [4] http://www.microsoft.com [3] http://www.realnetworks.com [4] http://www.apple.com/quicktime [5] http://www.borderware.com/products/sipassure [6] Shrikant Latkar, VoIP Security, Juniper Networks, 2007 [7] http://www.tippingpoint.com [8] http:// www.snocer.org [9] http://www.sipera.com [10] http://www.neceurope.com [11] Yu-Sung Wu, et. al., SCIDIVE: A Stateful and Cross Protocol Intrusion Detection Architecture for Voice-over-IP Environments, International Conference on Dependable Systems and Networks, 2004 [12] Hemant Sengar, et. al., Securing VoIP and PSTN from Integrated Signaling Network Vulnerabilities, The 1st IEEE Workshop on VoIP Management and Security, 2007 [13] http://www.spirent.com [14] http://www.cisco.com [15] Myung-Sup Kim, et. al., A Flow-based Method for Abnormal Network Traffic Detection, The Asia-Pacific Network Operations and Management Symposium, 2003 [16] Luca Deri, Open Source VoIP Traffic Monitoring, available at http://luca.ntop.org/ [17] Hun Jeong Kang, et al., SIP-based VoIP Traffic Behavior Profiling and Its Applications, the 3rd annual ACM workshop on Mining network data, 2007 [18] IETF RFC 4765, The Intrusion Detection Message Exchange Format(IDMEF), 2007 [19] http://www.opsec.com/ [20] Ruishan Zhang, et. al., Billing Attacks on SIP-Based VoIP Systems, The First USENIX Workshop on Offensive Technologies, 2007 ISSN: 1790-5109 410 ISBN: 978-960-474-028-4