A SIP Attack Detection / Prevention Architecture

Project no.: COOP-005892 Project full title: Low Cost Tools for Secure and Highly Available

VoIP Communication Services Project Acronym: SNOCER Deliverable no.: D2.2 Title of the deliverable: General Reliability and Security Framework

for VoIP Infrastructures

Contractual Date of Delivery to the CEC: Actual Date of Delivery to the CEC: Author(s): Tasos Dagiuklas (University of Aegean) Dimitris Geneiatakis (University of Aegean) George Kambourakis (University of Aegean) Dorgham Sisalem (Fraunhofer Fokus) Sven Ehlert (Fraunhofer Fokus) Jens Fiedler (Fraunhofer Fokus) Jiří Markl (Nextsoft) Michal Rokos (Nextsoft) Olivier Botron (Telip) Jesus Rodriguez (VozTelecom) Juntong Liu (Embiron) Work package contributing to the deliverable: WP2 Dissemination level: CO Total number of pages: 74 Abstract: In this document we present a general secure and high available software architecture for VoIP infrastructures. Security is achieved through the utilization of Intrusion detection sys-tems enhanced for VoIP traffic plus extended VoIP servers that perform advanced traffic monitoring. Additionally, we propose to increase server throughput through the use of an advanced DNS caching solution. Reliability is achieved trough redundant backup systems that take over operation in case of failure. We also introduce a security testing tool with an according configuration language based on XML.

- 1 -

- 2 -

Table of Contents 1 INTRODUCTION............................................................................................................... 4

1.1 ARCHITECTURE OVERVIEW........................................................................................................ 5 2 SECURITY GOALS ........................................................................................................... 6

2.1 FLOODING ATTACKS .................................................................................................................. 6 2.2 MESSAGE FLOWS ATTACKS ....................................................................................................... 6

2.2.1 The “BYE” Attack ........................................................................................................... 6 2.2.2 The “CANCEL” Attack ................................................................................................... 7 2.2.3 The “REFER” Attack ...................................................................................................... 8 2.2.4 The “Re-INVITE” Attack ................................................................................................ 8 2.2.5 The “UPDATE” Attack................................................................................................... 9 2.2.6 The “INFO” Attack......................................................................................................... 9 2.2.7 Classification of SIP Vulnerabilities ............................................................................. 10

2.3 PARSER ATTACKS..................................................................................................................... 12 2.3.1 The Complexity of SIP Message Parsing ...................................................................... 12 2.3.2 Malformed Messages in SIP.......................................................................................... 12 2.3.3 Mounting the Attack ...................................................................................................... 14 2.3.4 Discover Target’s SIP Capabilities............................................................................... 14 2.3.5 Construction of a Malformed Message ......................................................................... 15 2.3.6 Restrictions, Limitation and Possibilities of the Attack................................................. 15 2.3.7 Countermeasures........................................................................................................... 15 2.3.8 Detection Signatures ..................................................................................................... 16

2.4 DNS BLOCKING ATTACKS ....................................................................................................... 19 2.4.1 Scope ............................................................................................................................. 19 2.4.2 DNS Attack Simulation.................................................................................................. 20

3 TOOLS UTILIZED........................................................................................................... 23 3.1 NETFILTER / IPTABLES.............................................................................................................. 23 3.2 SER........................................................................................................................................... 24 3.3 SNORT....................................................................................................................................... 25

3.3.1 Snort Overview.............................................................................................................. 25 3.3.2 Snort Utilization in VoIP / SIP Environments............................................................... 27 3.3.3 SNORT Drawbacks ....................................................................................................... 27

3.4 PRELUDE IDS............................................................................................................................ 28 3.4.1 Prelude Overview.......................................................................................................... 28 3.4.2 Prelude IDS Architecture Modules ............................................................................... 29 3.4.3 Extensibility for VoIP Environments ............................................................................. 30

3.5 EXISTING ATTACK TOOLS ........................................................................................................ 30 3.5.1 VoIP Vulnerability Scanner (SiVuS) ............................................................................. 30 3.5.2 SIP Forum Test Framework (SFTF) ............................................................................. 31 3.5.3 PROTOS Suite ............................................................................................................... 31 3.5.4 SIP Swiss Army Knife (SIPSAK) ................................................................................... 31 3.5.5 Limitations..................................................................................................................... 32

4 SECURITY ARCHITECTURE DESCRIPTION .......................................................... 33 4.1 ATTACK DESCRIPTION LANGUAGE .......................................................................................... 33

4.1.1 A SIP Attack Description Model ................................................................................... 33 4.1.2 Generally Used XML Attributes .................................................................................... 33 4.1.3 XML Elements to Describe a Single SIP Message ........................................................ 34 4.1.4 XML Elements to Describe SIP Message Flows ........................................................... 34 4.1.5 Example of Flooding Attacks ........................................................................................ 35

- 3 -

4.1.6 Example of Parser Attacks ............................................................................................ 36 4.1.7 Example of SIP Application Attacks.............................................................................. 36

4.2 DEFENCE ARCHITECTURE DESCRIPTION.................................................................................. 37 4.2.1 Snort Bastion Host ........................................................................................................ 38 4.2.2 Extended SIP Proxy....................................................................................................... 39

4.3 ATTACK ARCHITECTURE DESCRIPTION ................................................................................... 43 4.3.1 Attack Tool - General Requirements ............................................................................. 43 4.3.2 Platform Design ............................................................................................................ 44 4.3.3 Implementation Issues ................................................................................................... 49 4.3.4 Restrictions, Limitations and Assumptions ................................................................... 49

5 HIGH AVAILABILITY ................................................................................................... 50 5.1 DESCRIPTION ............................................................................................................................ 50

5.1.1 Doubling the RTP Relay................................................................................................ 51 5.1.2 Doubling the PSTN Gateway ........................................................................................ 52 5.1.3 Doubling the Database.................................................................................................. 52 5.1.4 Doubling the SIP Server................................................................................................ 53 5.1.5 IP Takeover ................................................................................................................... 53

5.2 POSSIBLE EXTENSION: LOAD BALANCING............................................................................... 54 6 TESTING AND QUALITY ASSURANCE..................................................................... 58

6.1 SCOPE OF QUALITY ASSURANCE AND EVALUATION PLAN...................................................... 58 6.2 MANAGEMENT GOALS .............................................................................................................. 58 6.3 QUALITY ASSURANCE AND EVALUATION METHODOLOGY GUIDELINES ................................ 59 6.4 QUALITY ASSURANCE ORGANISATION .................................................................................... 60 6.5 EVALUATION PROCESS MODEL................................................................................................ 61 6.6 SNOCER MODEL QUALITY REQUIREMENT DEFINITION............................................................ 62

6.6.1 Identification of context of use ...................................................................................... 62 6.6.2 Analysis of the Tools ..................................................................................................... 62 6.6.3 Assignment and Ranking of Quality Characteristics to Snocer Services ...................... 62

6.7 SNOCER SYSTEM EVALUATION METRICS ................................................................................ 64 6.7.1 Metrics’ Templates........................................................................................................ 65 6.7.2 Metrics’ Definition ........................................................................................................ 65 6.7.3 Primitive Metrics’ Definition ........................................................................................ 66 6.7.4 Assessment Methodology............................................................................................... 68 6.7.5 Privacy .......................................................................................................................... 68

6.8 SNOCER VIRTUAL COLLABORATIVE TEST BEDS ...................................................................... 69 6.9 TRADE MARK OF THE SNOCER COLLABORATIVE MODEL. ....................................................... 69 6.10 TEST BED SCENARIO................................................................................................................. 70

7 SUMMARY........................................................................................................................ 72 8 REFERENCES .................................................................................................................. 73

- 4 -

1 Introduction In the context of the SNOCER project a set of tools and solutions will be implemented aiming to protect the infrastructures of VoIP providers against malicious use and denial of service attacks on the one hand. On the other hand, we will be further aiming to provide solutions for increasing the availability and reliability of the used VoIP components. In the first deliverable D2.1 [1] we have described possible security threats that a VoIP provider has to face, including threats concerning the SIP proxy, and supporting services including DNS/ENUM, STUN or RTP proxies. We have compared current solutions to handle non-VoIP centric solutions to deal with Denial-of-Service attacks. We have also investigated reasons for VoIP network failure and presented an overview of server backup strategies that can be applied for SIP proxies, including possibilities to transfer authentica-tion information between redundant servers. In this document we will present an overview of a security VoIP infrastructure to address the discussed problem space. For this we give an outline architecture based on established opens-source tools, with the necessary enhancements, refinements or other modifications needed for our goal. In case we have judged available solutions unfitted for our topic, we propose completely new solutions developed from scratch for our particular problem space. This document is structured as follows. In Chapter 2 we will give an overview of attack possibilities on a SIP architecture. This overview consists of malicious message flows with corresponding detection signatures and outlines possibilities of attacks using the DNS sys-tem. This chapter extends our previous attack description as provided in D2.1. Chapter 3 presents an overview of current open source tools which we will utilize to build our defence architecture. This includes firewall, IDS, and SIP server solutions. Further-more we present a list of current attack tools as a building block for an attack tool which will be developed to test the SNOCER architecture. We present a general overview of our Denial-of-Service Architecture in Chapter 4. This includes the specification of an attack description language, the actual two-level-defence architecture consisting of a general Bastion host and a secured SIP server, and finally an attack testing tool. In Chapter 5 we specify a highly available SIP network architecture based on fail-over rep-lication. In the last Chapter we provide general quality assurance rules which will be applied for testing of the SNOCER tools.

1.1 Architecture Overview To secure the VoIP Infrastructure to be resilient against unsolicited traffic and minimize service downtime we propose an architecture as described in Figure 1. The design is based on five key concepts:

• Bastion host: This host acts as a gatekeeper of the operator’s internal VoIP net-work. Its primary task is to detect basic attacks targeted at the VoIP system and deny access for unsolicited traffic.

• Enhanced SIP proxy: We propose to enhance a SIP proxy in two ways. An inte-grated IDS system will be able to detect more sophisticated SIP proxy attacks, which the bastion host might have missed. Further, we optimize the proxy’s per-formance through the addition of a specialized DNS module in order to enhance the throughput capabilities.

• High availability network: Key components of the VoIP network will be secured through an internal high availability network providing failover capabilities to these components.

• Operator console: The status of the enhanced VoIP infrastructure will be con-trolled in a centralized way.

• Attack tools: A set of specially designed attack tools will be utilized to test and improve the defence capabilities of the architecture.

Figure 1: Architecture Overview

- 5 -

2 Security Goals

2.1 Flooding Attacks Flooding attacks has been described in [1] , thus in this section no additional information is provided for these kind of attacks.

2.2 Message Flows Attacks The SIP protocol specification [2] describes methods to end or terminate a session, cancel an invitation, redirect a call and update session parameters. More specifically for each of the previous procedures the following SIP methods are utilized: (a) BYE, (b) CANCEL, (c) REFER and (d) INVITE-UPDATE. It is very likely that the attacker will try to exploit any security vulnerability in the aforementioned methods and cause DoS to the provided service. The main reason that an attacker can launch attacks by employing these messages is the utilization of an improper authentication mechanism. At the perils, current SIP speci-fications do not mandate authentication for all of the aforementioned methods. Moreover, as Internet telephony is considered as a service or application the attacker will try to discover possible security flaws in the applications or take advantage of existing pro-tocol “misconfigurations” similar to attacks launched against Internet applications and ser-vices exploiting vulnerabilities at the signalling application level.

2.2.1 The “BYE” Attack The BYE request is used to terminate an established session as shown in Figure 2. An at-tacker possibly can utilize the BYE request to tear down a session, as depicted in Figure 3. To launch this kind of attack, the attacker needs to learn all necessary session parameters (e.g. Session-ID, RTP Port etc). This can be accomplished either by sniffing the network or performing a man-in-the-middle attack (MITM) to insert a BYE request into the session. The BYE method, as mentioned above, is used to terminate an established media session. However, this attack can be launched successfully only in the case that no authentication mechanism is in place, considering as well the attacker’s ability to discover the current ses-sion parameters.

user 1 user 2proxy

invite

trying

invite

arprequest

arpresponse

ringing

ringing

OK

OK

ACK

ACK

MEDIA

BYEBYE

Figure 2. Normal session termination

- 6 -

Thus, the protection of the session’s critical parameters regarding confidentiality must be considered as mandatory. As discussed already in [1] , either TLS or IPSec can be em-ployed to provide such kind of security services. Moreover, the authenticity of a BYE mes-sage must be ensured by utilizing either HTTP Digest or TLS.

user 1 user 2proxy

invite

trying

invite

arprequest

arpresponse

ringing

ringing

OK

OK

ACK

ACK

MEDIA

attacker

BYE

Figure 3. BYE attack

2.2.2 The “CANCEL” Attack The CANCEL request, as its name implies, is used to cancel a previous request sent by a client. More specifically, it asks the corresponding server to cease processing the request and generate an error response designating that request. This procedure is shown in Figure 4. The attacker may utilize the CANCEL method to cancel an INVITE request generated by a legitimate user as illustrated in Figure 5. A CANCEL request must only be sent to cancel an INVITE request [2] . Thus, when a SIP-proxy receives a CANCEL request for any other message type (than INVITE), it must not process this message, but rather pro-duce an appropriate error response. Moreover, incoming CANCEL requests must not be processed if the original request has already generated a final response. This is because CANCEL has no effect on requests that have already generated a final response.

user 2proxy

invite

tryinginvite

arprequest

arpresponse

ringing

ringing

CANCEL

200 OKNO MORE PENDINGS

user 1

Figure 4. CANCEL request

CANCEL requests are generated in a hop-by-hop fashion and can not be resubmitted. As a result, they can not be challenged by the server in order to get proper credentials in an Au-

- 7 -

thorization header field. Thus, the utilization of any applicable, underlying security mecha-nism, such as IPSec or TLS, is considered mandatory. However, the processing of an in-coming CANCEL message from a different administrative SIP domain is still an open and unresolved issue. Additionally, the monitoring of INVITE messages that have not already generated a final response could possibly help to identify any illegitimate CANCEL re-quests.

user 1 user 2proxy

invite

trying

invite

arprequest

arpresponse

ringing

ringing

attacker

CANCEL

200 OKNO MORE PENDINGS

Figure 5. CANCEL attack

2.2.3 The “REFER” Attack The REFER extension [3] provides a mechanism where one party (the referrer) provides a second party (the referrer) with an arbitrary URI to reference. Assuming that this URI is a SIP URI, the referee will send a SIP request (usually a SIP INVITE), to that URI (the refer target). As a result, REFER can be used to enable many applications, including call trans-fer. RFC 3892 [4] extends this method by allowing the referrer to provide information about the REFER request to the refer target using the referee as an intermediary. The refer target can use this information to decide whether to accept the reverenced request from the referee or not. This scheme enables the referee to act as an eavesdropper, giving him the ability to launch man-in-the-middle attacks. For example, the referee can forge the Re-ferred-By header or/and eavesdrop on the referred-by information. The referee may also copy all the related information into future unrelated requests. Although the specification uses an S/MIME based mechanism to enable the refer target to detect possible manipula-tion of the Referred-By header data, this protection is completely optional.

2.2.4 The “Re-INVITE” Attack Once a dialog-session has been established by initial messaging, subsequent requests can be sent that attempt to modify the parameters of the dialog-session (e.g. address or port modification). Thus, any unauthorized modification with a forged re-INVITE (see Figure 6) of a dialog-session by a potential attacker may cause a DoS.

- 8 -

user 1 user 2proxy

invite

trying

invite

arprequest

arpresponse

ringing

ringing

OK

OK

ACK

ACK

MEDIA

attacker

"re-invite" (invite)user 1

Figure 6. "Re-INVITE" Attack

2.2.5 The “UPDATE” Attack The SIP UPDATE method [5] provides the end users with various capabilities such as muting or placing on hold incoming calls, identification of QoS parameters and negotiation for other session attributes like “re-invite”. The only difference is that the “re-invite” can utilized only after a session has been established, while UPDATE is utilized to modify ses-sion parameters before the final response to the initial invitation. So similar to the “re-invite” attack, an attacker may send a forged UPDATE message, as depicted in Figure 7 to modify the initial session parameters to cause a DoS changing parameters like QoS or ini-tial addresses and ports.

user 1 user 2proxy

invite

trying

invite

arprequestarpresponse

ringing

ringing

OK

OK

attacker

updateupdate

Figure 7. UPDATE attack

2.2.6 The “INFO” Attack In many cases, VoIP networks can be used as a mediator to interconnect PSTN carrier. Under this circumstance, SIP for telephones (SIP-T) [6] is used in order to convey PSTN signalling from one PSTN carrier to another and vice versa. Figure 8 depicts an architec-ture in which a SIP network is the bridge between two different PSTN networks.

- 9 -

PSTN Phone A

SG SG

SIP NETWORK

S I P -T

PSTN Phone B

Q.931/ISUPQ.931/ISUP

Figure 8. PSTN and SIP Interconnection

The INFO method is described as a general mechanism to carry application level informa-tion along the SIP signalling path, to allow tunnelling mechanisms [6] . It has been pro-posed, and in fact used, for a wide variety of functions, including: 1. Carrying mid-call PSTN signalling messages between PSTN gateways.

2. Carrying DTMF digits generated during a SIP session.

3. Carrying account balance information.

The message body of INFO message can be encrypted for privacy reasons. However there is no suggestion for any security mechanism to provide integrity and authenticity of INFO method. Thus, it is possible the malicious modification of the INFO method that can cause serious problem to the communication parties like unauthorized access to a call, DoS for the initial invitation, billing errors etc.

2.2.7 Classification of SIP Vulnerabilities The potential threats and attacks that a SIP-based network is facing can be divided into various categories. We categorize the aforementioned SIP attacks, as illustrated in Table 1, in the general following security categories: 1. Passive versus Active Attacks: Passive attacks include the passive monitoring of pack-

ets exchanged among the SIP elements. On the other hand, in the active attacks the at-tacker may disrupt the normal operation of the network by altering, deleting or re-transmitting packets.

2. Internal versus External Attacks: The external attacks regard attacks that stem from nodes, which do not belong to the SIP network. On the other hand, internal attacks re-gard malicious nodes belonging to the network as legitimate entities.

3. Single versus Multi Source(s): Single source attack involves one malicious host (the attacker). On the other hand multi sources involve numerous of usually innocent Inter-net hosts that has been exploited by the attacker.

4. Affected Security Issues: The affected security service whenever an attack is launched are the followings: (1) (C)onfidetiality, (2) (I)ntegrity (3) (Av)ailability, (4) (R)eliability and (5) Authentication.

5. Consequences: This category differentiates the attacks based on the intentions of the intruder:

a. DoS attacks intend to make servers unavailable to accomplish their tasks. - 10 -

b. Unauthorized Access (UnA) as its name implies, intends to give access in the provided service to non-authorized users.

Table 1 SIP Attacks Classification

Activity Location Source Threat/ Attack

(A)ctive/ (P)assive

(I)nternal/ (E)xternal

(S)ingle/ (M)ulti

(D)irect / (I)ndirect

Vulnerability Affected Security Issue

Possible Conse-quences

REGISTRAR FLOODING

A I-E S-M D-I Av-R DoS

PROXY FLOODING

A I-E S-M D-I Av-R DoS

END USER FLOODING

A I-E S-M D-I Lack of authentica-tion

Av-R DoS

ROUTE /RECORD ROUTE ATTACK

A I M I Lack of (1) authentication, (2) integr. checking

I-Av-R DoS

SIP PARSER ATTACK

A I-E S D Implementation errors

Av-R DoS, UnA

BYE AT-TACK

A I-E S D Lack of authentica-tion

Av DoS

CANCEL ATTACK


Av DoS

REFER ATTACK


C-I-Av UnA

RE-INVITE ATTACK


Av-C-R UnA, DoS

UPDATE ATTACK


Av-R DoS

INFO Attack A-P I-E S D Lack of (1) authentication, (2) integr. checking (3)Confidentiality

Av-R-C-I DoS, UnA

SQL INJEC-TION AT-TACK

A I-E S D Lack of integrity checking

I-Au-Av UnA, DoS

In contrast to PSTN, an attacker may easily gain access to VoIP subsystems and al-ter/deteriorate their operation. Thus he/she can easily “discover” any appropriate parame-ters (if an underlying security mechanism is not utilized) needed to launch an “active” or “passive” attack. All the described attacks are active but the attacker in some of them, like CANCEL, BYE need to utilize the passive mode to “learn” the appropriate parameters to execute the attack. Moreover, most of the attacks described here can be executed not only from the internal SIP network but from an external SIP network as well. For instance, the attacker can ex-ploit a trusted SIP proxy to amplify the attack’s hazardous outcomes. As regarding the at-tack sources the application level attacks and SIP parsers’ attacks are launched from a sin-gle host. This is not the case for flooding attacks that can have a distributed form and can utilize innocent hosts to launch the attacks (Indirect attacks). As described [1] one of the main security vulnerabilities that attackers possibly will exploit is the lack of a “complete” authentication scheme, which can protect SIP infrastructure against unauthorized access. One applicable solution to this problem is Peterson’s sugges-tion [8] for the utilization of cryptographic tokens. This solution can be applied also in hop-by-hop fashioned messages like CANCEL, which could not be challenged, and utilize HTTP Digest authentication. The second major problem is the lack of integrity mecha-

- 11 -

- 12 -

nisms. This problem can be fixed with the use of the appropriate integrity schemas like S/MIME, TLS, etc.

2.3 Parser Attacks

2.3.1 The Complexity of SIP Message Parsing A SIP message can be either a request or an acknowledgment to a corresponding request, consisting of the header fields and the message body. The overall structure of a typical SIP message is depicted in Figure 9. SIP messages are text-based and are very similar to the HTTP format, with a highly degree of freedom, thus, an efficient parser is needed which only parses messages up to the point the information is required. However, even a perfectly valid SIP message can be constructed in a way to hamper proper parsing. Here we give a list of possible scenarios that complicate message parsing. An attacker can create extra-long messages, with multiple header (like informative header fields, e.g. Supported) fields and of increased length, plus a big-sized message-body. All SIP messages may include bodies, even when they are not needed in every message. In-stead of only depleting processor power, longer message also increase network utilization. However, only well-formed header fields require decoding power, a parser should ignore other header fields and a server can reject too long messages with a 413 (Request Entity Too Large) message. Also, a parser must only interpret message body with the size as indicated in the content-length header. Proxies have to forward messages even if they do not understand some of the message’s header fields, note that such headers need not to be parsed. Larger messages than 1300 bytes are additionally required to be sent over TCP, which will create additional state even in a stateless proxy. Additionally, RFC 3261 [2] mandates headers, which have multiple values, to be separated into individual header fields so that each only contains one value. If multiple message headers of the same field are included in a message where these headers are spread all over the message, this complicates parsing. Especially the following header fields can be distributed in SIP: Accept-Encoding, Accept-Language, Alert-Info, Allow, Authentication-Info, Call-Info, Contact, Content-Encoding, Content-Language, Er-ror-Info, In-Reply-To, Proxy-Require, Record-Route, Require, Route, Supported, Unsup-ported, User-Agent, Via, and Warning. Some message headers are more vital for process than other. Vital header fields are all routing-specific fields, like To, Via, Route, etc. As an effect, messages which append these fields towards the end of the message are more diffi-cult to parse. One way to accomplish this is by inserting multiple informative header fields before the routing fields, like e.g. Allow or Supported. Several header fields allow other URIs than SIP/SIPS. Using these URIs might also com-plicate processing. Even if a highly optimized parser could handle such attacks, the re-quired processing power requirements would be missing for other SIP related tasks.

2.3.2 Malformed Messages in SIP According to RFC 3261 [2] , all SIP stacks must be capable processing the following stan-dard SIP method - messages: • REGISTER

• INVITE

• ACK

• CANCEL

• BYE

• OPTIONS.

The HTTP-like ASCII presentation of the SIP messages may initially be more attractive to attackers for vulnerability assessment than the rival signalling protocols (e.g. H.323, MGCP, SKINNY) with complex encodings. As a result, a malicious user can take advan-tage of any of the aforementioned SIP method - messages to mount this attack against SIP targets, which can be end-users’ terminals or SIP Proxy Servers. Apart from the standard SIP methods/messages, there are also SIP extensions [9] - [11] for various SIP methods providing several complementary services that can be possibly utilized by potential attack-ers. SIP subsystems have been designed and developed for processing messages that are valid and conformant with the SIP protocol syntax, as described in RFC 3261 [2] . An example of a valid and typical INVITE message that the SIP protocol syntax must be able to gener-ate and process successfully is depicted in Figure 9. However, due to implementation er-rors in some circumstances, taking as well under consideration the complexity of the SIP parser, well formed messages can potentially crash the corresponding SIP server.

INVITE sip:[email protected] SIP/2.0To: Geneiataki Dimitri <[email protected]>From: Karopoulos Georgios<sip:[email protected]>;tag=76341CSeq: 2 INVITEAuthorization: Digest username="gkar",realm="195.251.164.23", algorithm="md5",uri="SIP:195.251.164.23",nonce="41352a56632c7b3d382b39e0179ca5f98b9fa03b",response="a6466dce70e7b098d127880584cd57"Contact: <SIP:195.251.166.73:9384>;>Content-Type: application/sdp

v=0o=Tesla 2890844526 IN IP4 lab.high-voltage.orgc=IN IP4 100.101.102.103t=0 0m=audio 49170 RTP/AVP 0a=rtpmap:0 PCMU/8000

SIPheaders

SessionDescription

(body)

Figure 9. Well formed typical INVITE message

Besides the implementation errors, it is highly likely that the attacker will try various mal-formed message combinations to discover a security problem/flaw towards the SIP-victim subsystem. For example, the INVITE message depicted in Figure 10 is invalid and cannot be generated by the standard SIP protocol syntax, due to the lack of a REQUEST-URI, which must follow the INVITE method [2] .

- 13 -

INVITE (null)To: Geneiataki Dimitri <[email protected]>From: Karopoulos Georgios<sip:[email protected]>;tag=76341CSeq: 2 INVITEAuthorization: Digest username="gkar",realm="195.251.164.23", algorithm="md5",uri="SIP:195.251.164.23",nonce="41352a56632c7b3d382b39e0179ca5f98b9fa03b",response="a6466dce70e7b098d127880584cd57"Contact: <SIP:195.251.166.73:9384>;>Content-Type: application/sdp

v=0o=Tesla 2890844526 IN IP4 lab.high-voltage.orgc=IN IP4 100.101.102.103t=0 0m=audio 49170 RTP/AVP 0a=rtpmap:0 PCMU/8000

SIPheader

SessionDescription

Figure 10. Example of Malformed INVITE message

Any message that either does not conform to or violate SIP’s protocol specifications can cause security flaws in any SIP subsystem, but usually, it is very difficult to distinguish between all possible legal and illegal messages. In a nutshell, possibly there are inputs that might not have been considered properly when implementing the SIP stack installed in each SIP product.

2.3.3 Mounting the Attack Normally, the attacker does not have a standard method for launching an attack. Therefore, in a sense, the behaviour of an attack is unpredictable. This is also true for SIP malformed message type attacks. For example, the attacker may construct malformed messages utiliz-ing a “brute force” attack method, exhaustively trying all possible SIP message combina-tions. Alternatively the attacker can follow a more general procedure, which could be ex-pressed in the following, repeatedly executed, algorithmic steps:

1. Discover the target’s SIP capabilities.

2. Construct the malformed message.

3. Test the derived “crafty” message against the SIP target.

The main “advantage” of such an approach is that the assault cannot be easily identified in its prime stages, as the defence mechanisms in place are not usually able to promptly detect it.

2.3.4 Discover Target’s SIP Capabilities The initial step before an attacker launches a malformed message attack is to discover the SIP “capabilities” of a particular SIP target/subsystem. REGISTER messages and OPTIONS responses can give information about any SIP User Agent’s (UA) capabilities. This sensitive information is included in the Contact header in REGISTER message and Allow header in response of the OPTIONS request. In every case, these messages can be utilized from the attacker in two different ways aiming to dis-cover the User Agent’s (UA’s) capabilities. In the first one, the attacker can simply sniff SIP packets (especially SIP REGISTER packets) while a registration to a SIP registrar server is taking place. The other one merely utilizes the OPTIONS message. Figure 11 depicts the message flow for this method. Un-der these circumstances, the attacker creates an OPTIONS message, which is sent to the SIP victim. The target responds to the OPTIONS message, so the attacker discovers the

- 14 -

SIP target’s implemented methods/messages (capabilities). For instance, the returned ca-pabilities may reveal, among other things, the vendor and the version of the potential SIP target product, which in turn, expose existing vulnerabilities.

attacker targetproxy

OPTIONS

200 OK

OPTIONS

200 OK

Figure 11. Discovering User Agent Server Capabilities

2.3.5 Construction of a Malformed Message The second step towards launching the attack is to construct an appropriate malformed message. Figure 10 presents the structure of a malformed INVITE that we were able to generate. A list of such INVITE malformed messages also exist in the test-suite PROTOS [12] . Moreover, it is very likely for the attacker to send non-implemented (invalid or non-standard) messages provoking eventually the target to crash. Besides that, other imple-mented messages like REGISTER, BYE, CANCEL, and other non-standard messages can be also employed to have this attack compiled much in the same way.

2.3.6 Restrictions, Limitation and Possibilities of the Attack Any malicious user who is located (or not) in the same domain with the victim can launch this attack. There is no real restriction for the attacker to prevent him from launching a malformed message attack, in absence of any underlying security mechanism that protects message integrity, confidentiality and origin authentication. Even though, the existing un-derlying SIP security mechanisms (e.g. Transport Layer Security-TLS, IP Secure-IPsec, Secure MIME-S/MIME) are only able to protect against “outsiders” and not against “insid-ers”, who are normally the legitimate users. However, considering this situation, an out-sider will endeavour to employ his SIP proxy in order to amplify the DoS effects of spe-cially fabricated malformed, invalid or non-standard SIP messages towards the correspond-ing SIP target.

2.3.7 Countermeasures Input validation procedures must be considered vital for the security of VoIP services. The lack of any validation in data input process is responsible for security flaws caused by mal-formed messages. The employment of gateways to filter malicious input at the Internet ap-plication level has also been studied [13] . Current firewall technologies incorporate packet inspection [14] for validating input data. The same techniques can be applied in SIP archi-tectures using the Middlebox Communication approach [15] Moreover, the utilization of underlying security mechanisms (e.g. TLS, IPsec, S/MIME) according to RFC 3261 can substantially restrict or prevent the origination of malformed messages. However, it is always possible for an attacker to utilize another SIP proxy to

- 15 -

amplify the hazardous effects of the malformed messages. Additionally, these mechanisms do not provide any real security against internal-authorized but malicious users. Another possible countermeasure that can restrain this attack is the authentication of the OPTIONS messages. Additionally, the utilization of underlying security mechanisms is considered mandatory to protect the confidentiality of the REGISTER and OPTIONS messages against eavesdroppers. The employment of these countermeasures does not mean that the aggressor cannot launch the attack, but things become more difficult for him.

2.3.8 Detection Signatures No matter how strong the existing security prevention mechanisms in VoIP Services are, there is always the possibility for a malicious user to manage to by-pass them. So, in case an internal user launches an intrusion attack, it is quite probable that none of the existing prevention mechanisms will trigger an alarm. For example, considering a legitimate SIP user who generates a malformed SIP message and then signs it with his private key. There is no doubt that this attack can be hardly defeated by the usual prevention mechanisms and awake the existing countermeasures. To avoid such situations, the employment of an Intrusion Detection System (IDS) for the provided VoIP services is considered mandatory. On the other hand, in some cases, it is more economical to prevent only the uppermost attacks and detect the rest, than trying to prevent everything in a much higher cost. In addition, a detection system can be considered quite sufficient for protecting VoIP against malformed message attacks. In these systems, any distinct attack is described through some specific static structure, known as the attack’s “signature”. Malformed message attack in SIP architectures can be similarly confronted by identifying, categorizing and prototyping the corresponding signatures. The proposed signatures are based on the SIP message syntax, which is fully specified in RFC 3261 [2] . Since all SIP messages are based on this syntax, it will be attainable to embed a light SIP IDS mecha-nism in a slightly modified SIP protocol stack. The signatures developed are marked out mainly for the most utilized SIP messages that current SIP User Agents implement. The detection signatures are based in the structure depicted in Figure 12 . Each signature is composed by the identified malformed message (SIP-MESSAGES) optionally followed by some additional rules.

SIP-MESSAGE(based in SIP-GRAMMAR) additionall rules

Figure 12. General Form of a Signature The basic idea is to construct a general identification-detection rule that can be easily ap-plied to any SIP message, independently from the SIP-method (INVITE, REGISTER, BYE, etc) used. Figure 13 presents the structure of this general rule. The first line represents the SIP Method, the URI and the corresponding header. This detection rule capitalizes on the fact that any SIP message must have a SIP method with the appropriate destination address fol-lowed by one or more message headers. Note, that not all SIP messages are mandate to have a message body. Moreover, additional rules add an increased security level and can effectively characterize a message as malicious or not. For example in the depicted rule, both the SIP method and the message header are prohibited from having the NULL value.

- 16 -

SIP_METHOD SIP-URI | SIPS-URI MESSAGE HEADER+[MESSAGE_BODY]

additionall rulesSIP_METHOD!=NULLMESSAGE_HEADER!=NULLsize_of(SIP_METHOD)>%constant% e.g 50 bytessize_of(MESSAGE_BODY)>%constant%

Figure 13. General Detection Rule However, there are cases (some very well known malicious messages) that cannot be iden-tified by this generally structured rule. Under these circumstances (exceptions), special rules must be formed for each distinct SIP-method. For example, INVITEs which do not have a specific header (e.g. Content-Type, Call-ID) must be characterized as invalid. Addi-tionally a malicious user will try to evasion the detection system utilizing alternative en-codings values to construct malformed messages. For example, he can utilize HEX values for INVITE (e.g. 0x49,0x4E,…) to construct the malformed message thus evading the de-tection system when appropriate signatures for alternative encodings in the IDS database are not in place. Figure 14 describes a detection signature framework for INVITE messages. Note, that this detection signature is very similar to a valid INVITE message. The main difference is that the message is characterized as “malicious” when any of the mandatory message headers is not in place or any of the additional rules triggers it. For instance, concerning this signa-ture, there are two additional rules, which restrict the value of the Content-Length header. This value must be greater than zero and equal to the size of the MESSAGE_BODY ex-pressed in bytes. If any of these rules is not satisfied or any mandatory header is missing, then the message must be discarded, perhaps giving some feed to the IDS too.

INVITE_METHOD SIP-URI | SIPS-URI MESSAGE HEADER+MESSAGE HEADER =Via | Max-Forwards | From* |To* | Call-Id* |CSeq* | Contact* |User-agent

|Authorization |Event |Content-Length* |Content-type*|Record-RouteINVITE_METHOD="INVITE" | %x49.4E.56.49.54.45MESSAGE_BODYadditionall rules%Content-Length% >0%Content-Length%==size_of(MESSAGE_BODY)(*)mandatory fields

Figure 14. Detection Signature for INVITE messages Another reason that prevents the employment of general structured rules only, is that dif-ferent SIP methods require different message headers. Thus, the combination of general and special targeted rules can establish a robust identification framework to protect from SIP malformed messages. In addition, the administrators of each domain are responsible to utilize the appropriate rules (what is permitted and what is not) depending on the security policy determined beforehand. In the following subsections we present malformed message signatures for the most known SIP implemented methods. The general structure of such signatures is similar to the de-

- 17 -

2.3.8.5 Signature for Malformed SUBSCRIBE SUBSCRIBE_METHOD SIP-URI | SIPS-URI MESSAGE HEADER+MESSAGE HEADER =Via | Max-Forwards* | From* |To* | Call-Id* |CSeq* |Contact

|Expires |User-agent |Authorization |Content-Length*SUBSCRIBE_METHOD ="SUBSCRIBE" | %x53.55.42.53.43.52.49.42.45


Figure 19: Signature for Malformed SUBSCRIBE

2.3.8.6 Signature for Malformed NOTIFY NOTIFY_METHOD SIP-URI | SIPS-URI MESSAGE HEADER+MESSAGE HEADER =Via | Max-Forwards* | From* |To* | Call-Id* |CSeq* |Contact|Record-Route

|Expires |User-agent |Authorization |Content-Length*|Content-TypeNOTIFY_METHOD ="NOTIFY" | %x4e.4f.54.49.46.59MESSAGE_BODY

additionall rules%Content-Length% >0%Content-Length% ==size_of(MESSAGE_BODY)(*)mandatory fields

Figure 20: Signature for Malformed NOTIFY

2.4 DNS Blocking Attacks As already mentioned in the previous deliverable D2.1 [1] , SIP agents are vulnerable to DoS attacks through invalid DNS lookups. The basic concept is as follows: An attacker sends messages including irresolvable host names, forcing the underlying DNS service to perform time-consuming, but unsuccessful host lookups. Generally, while the SIP agent waits for the reply from the DNS subsystem, it cannot process other pending messages, which renders it at this moment highly vulnerable to flooding attacks.

2.4.1 Scope Applications contact the corresponding DNS system whenever the need arises to translate a Fully Qualified Domain Name (FQDN), e.g. www.example.com into the corresponding IP Address (e.g. 154.536.14.5). The operation system provides an interface to this functional-ity, e.g. a Unix-based operating system generally provides the gethostbyname system call for this translation. Whenever the DNS subsystem receives the request, there are – simplistically – two possibilities how it can provide the answer. The DNS resolver is aware of the translation. This can be either through configuration, e.g. some translations are hard-coded into the system or through caching, and previous requests are stored for a certain amount of time at the DNS server in case another request for the same hostname arrives. The DNS resolver isn’t aware of the answer. The DNS server then needs to contact other servers that might know the answer to this request. Because this process might include a recursive search among different servers, response times can be very long. For the second case it is not guaranteed that a successful translation can be detected. Mis-spelled names or non-existent hostnames intentionally provided will lead to an error re-

- 19 -

- 20 -

sponse that this name doesn’t exist. Because this process can take a reasonable amount of time in certain cases, implementations like the DNS subsystem on Linux restrict request processing to certain boundaries, which default to 5 s timeout and 3 possible retry possi-bilities. If after five seconds or three retries no reply is received, the system will assume that the requested address is irresolvable. To measure the impact of DNS resolving issues with a SIP proxy, we have conducted a DNS lookup attack simulation.

2.4.2 DNS Attack Simulation For simulation purposes we have created an attack tool and a target SIP proxy running on the Linux operating system. The attack tool can generate an arbitrary number of SIP IN-VITE messages with a configurable delay between them. The SIP messages contain ran-domly generated SIP URIs. Additionally, multiple message generators can be run in paral-lel to flood a target with such messages. The target was a simple SIP proxy that can handle incoming INVITE messages and resolve the embedded SIP URIs. The SIP proxy can fork multiple child processes for parallel incoming message handling to resemble operation provided by the SIP Express Router (SER). The target SIP proxy has three modes of opera-tion to resolve DNS requests.

• Default synchronous mode. This mode resembles SER’s operation, as it uses the gethostbyname system call with its default parameters (5 s timout, 3 retry limit). Operation is depicted in Figure 21.

• Optimized synchronous mode. This is a modification of the standard gesthost-byname system call with optimized limitation parameters. We have set the timeout value to 1 s and only allow one resolve attempt.

• Asynchronous mode. This mode uses the asynchronous ares DNS resolver library [16] . Asynchronous mode works as follows: The calling application issues a re-solving request to the ares library. This request is acknowledged immediately, even if at this moment no DNS lookup is actually performed. The calling application can continue its work without delay, and will receive the final answer from the ares li-brary through an established callback hook. While this method guarantees a faster processing speed, memory consumption increases, as with every lookup request additional state information has to be stored until the final answer arrives.

For the simulation, we have run attacks on the SIP proxy in all three different operation modes. Attacks have been conducted with three different attacks suites with the following parameters:

1. 100.000 messages sent with a delay of 10 microseconds. The target proxy has 10 sub-processes.

2. 1.000.000 messages sent with a delay of 1 microsecond. The target proxy has 20 sub-processes.

3. 100.000 messages sent by 3 threads with a delay of 1 microsecond, repeated at every 20s for 10 times to a total of 3.000.000 messages (flood scenario). The target proxy has 30 sub-processes.

Initial process

child 1

child N

child 2

read SIP msg

read SIP msg

read SIP msg

gethostbyname

gethost byname

gethost byname

blocks up to 5 seconds

continue work

continue work

continue work

Figure 21: Proxy target default synchronous operation mode

Figure 22 show the message processing capabilities of the target proxy in its different op-eration modes. The Total line denotes the number of total messages sent by the attack tool, while the bars indicate the actual number of messages processed by the proxy. Two main observations can be made: In synchronous mode, the proxy can handle only a fraction of the incoming messages. In optimized synchronous mode this can only alleviated by a certain degree. In the first two testing-suites, the proxy was able to process all incoming requests in asyn-chronous mode; however this was not the case in the message flooding scenario in test suite 3. This is due to memory constraints of the server machine. While we ran tests on a well dimensioned test system with 8 GB of RAM, asynchronous mode needs for every fork some memory to keep its state information. After some time, the whole memory of the sys-tem was consumed (See Figure 23). All other simulations never exceeded a memory con-sumption of 400 MB. From this simulation have seen that message flooding with random domain names can ex-haust the processing capabilities of a SIP proxy, no matter if the proxy resolves DNS re-quest synchronously or asynchronously.

- 21 -

Suite 1 Suite 2 Suite 30

500000

1000000

1500000

2000000

2500000

3000000

Default SyncOpt. SyncAsyncTotal

Tests Suite

# pr

oces

sed

mes

sage

s

Figure 22: Simulation processing capabilities

Figure 23: Memory usage at the SIP proxy in asynchronous mode (Test suite 3)

- 22 -

3 Tools Utilized This section introduces several open source tools that will be employed by Snocer software architecture to deal with certain attacks.

3.1 Netfilter / Iptables Netfilter and iptables are building blocks of a framework inside the Linux 2.4.x and 2.6.x kernel. This framework enables packet filtering, Network Address Translation (NAT) and other packet mangling. Snocer software architecture will employ iptables/netfilter as filter-action-points to block malicious traffic. Once the source of an attack has been identified by Snocer software, specific filter rule(s) will be activated at some filter-action-points by Snocer software, so that the iptables/netfilter can act to prevent the following malicious packets from reach the SIP server by dropping or reject them. Netfilter and iptables are the re-designed and heavily improved successor of the previous Linux 2.2.x ipchains and Linux 2.0.x ipfwadm systems. Netfilter is a set of hooks inside the Linux kernel that allows kernel modules to register callback functions with the network stack. A registered callback function is then called back for every packet that traverses the respective hook within the network stack. Iptables is a generic table structure for the definition of rule sets. Each rule within an IP table consists of a number of classifiers (iptables matches) and one connected action (ipt-ables target) [17] . Following figure illustrates the internal tables and chains and possible table traverse scenarios:

Figure 24: iptabels overview

- 23 -

Netfilter and especially can be accessed trough a custom library, libiptc, which allows the same set of firewall control as the iptables user command.

3.2 SER The SIP Express Router (SER) [18] is an open-source SIP server, published under the GNU Public License. SER’s architecture [19] has been designed for high scalability to serve thousands of calls per seconds, and flexibility due to a modular plugin-approach and a higly configurable routing language. SER is already in widespread use at many VoIP providers. Under Snocer software architecture, as last line of defence, security enhancement modules will be developed to let the SER itself have certain self-defence abilities to deal with cer-tain attacks. A DNS enhancement will also be developed to improve the SER’s DNS query ability so that the risk of service failure caused by DNS DoS attack can be minimized. The SER was designed in a highly modular manner as depicted in Figure 25, SER consists of a highly efficient core that is responsible for receiving, parsing SIP and forwarding mes-sages.

SE R C ore

ParsingH andler

Scrip t In terpreter

M odules

M axfw d

R egistrar

U srloc

SL

R R Jabber

M ySQ L

A uthentication

SIP /SM S

C P L

SE R C ore

ParsingH andler

Scrip t In terpreter

M odules

M axfw dM axfw d

R egistrarR egistrar

U srloc U srloc

SLSL

R RR R JabberJabber

M ySQ LM ySQ L

A uthenticationA uthentication

SIP /SM S

C P LC P L

Figure 25: General Architecture of SER

The core is also responsible for invoking certain procedures that are provided as extension modules. These modules are dedicated to providing certain features. Such modules in-clude:

• Registration and user location: This part is responsible for handling registration requests and managing the user location database.

• Transaction management: When acting in a statefull mode SER must maintain per transaction state, generate replies, match replies to requests and deal with fork-ing.

• User authentication: SIP utilizing HTTP digest for authenticating user requests. This part of SER interacts with the database, which maintains the user’s identity and password and is responsible for checking the credentials of the users.

• SIP handling: While the core deal with the message processing, the transaction management deal with state handling and taking the appropriate SIP actions, this type of modules deals with additional processing logic such as handling of record-route headers, loop detection or support for ENUM.

- 24 -

- 25 -

• Application modules: These modules provide some application level services such as SIP to Jabber translation..

• Application programming modules: To enable external programmers to use the features of functionalities of this class of modules provides a clear and simple to use interface that allows the separation between the SER and the application code.

Each module exports a set of functional procedures and utilizes procedures exported by other modules. The integration between the different modules and the core is realized through a configuration language. The SER Configuration Language (SCL) is a rich and flexible scripting language. In this context SCL is similar to shell languages with support for regular expressions and allowing the administrator to specify certain rules whenever a specific event occurs, in the manner of

If (event) then (action);

In the figure below, the administrator specifies that after receiving a registration request, the core should invoke the authentication module before handing the registration by the registration module

If(method==”REGISTER”) www_challenge(“sip.org”/*realm*/, “0”); break;

To enable the extension of the functionality of SER as well as experimenting with novel ideas and concepts, SER provides an open programming interface to utilize the current and novel functionalities of SER and add novel ones. This is achieved by implementing a new module that provides these new features. Such a new module would use the exported procedures of the other modules as well as functional-ities of the core. The new module in its turn exports new procedures that could be invoked by the core and other modules as well. The SCL is then used for integrating the new functionalities in the general functionality of SER. Using SCL, the administrator of the SER platform can define the exact behaviour of the platform based on available modules and needed actions.

3.3 Snort

3.3.1 Snort Overview Snort is a network-based Intrusion Detection System (IDS) distributed under the GPL li-cense. It performs real-time analysis of packets on the network and triggers alarms when specified conditions are met. To detect attacks on the network, Snort is using a flexible set of rules. Its engine utilizes a modular plugin architecture. The Snort system provides the functionality for the detection of intruder’s attacks covered by the Snort IDS and the functionality for attack prevention provided by Snort’s Intrusion Prevention System (IPS). Besides additional functionalities provided like the Sniffer mode (reads packets from the network and displays them) and the Packet logger mode (logs packets directed from network to disk).

3.3.1.1 Intrusion Detection System Snort intrusion detection is based on a simple lightweight description language. Snort iden-tification is based on the analysis of incoming packets and the defined utilized rules. Many

- 26 -

of the fields (mainly in IP, TCP and UDP) can be used to test malicious packets. It exam-ines among other source, destination IP addresses, ports, protocol type and other fields in packet headers. The Snort system also allows analyzing packet payloads and searching the content of a packet for given textual or binary patterns. Thousands of rules are currently included in Snort systems, many of them already covering various types of DoS attacks. Additional rules are available for LAND, teardrop, or smurf attacks. For a complete list of available rules can be found in [20] . Furthermore rules for specialized attacks on SIP, can be easily added.

3.3.1.2 Intrusion Prevention System The snort_inline tool provides snort’s intrusion prevention functionality. Snort_inline obtains packets from iptables instead of the libpcap packet monitoring library [21] and controls iptables to pass or drop packets based on Snort rules. Thus, snort_inline provides the capability to detect and stop malicious packets generated by DoS attempts. There are three actions available to stop undesired traffic with snort_inline: • drop: The drop rule type instructs iptables to drop the packet and log it via usual Snort

means. • reject: The reject rule type instructs iptables to drop the packet, log it via usual Snort

means, and send a TCP reset if the protocol is of type TCP or an “icmp port unreach-able” message if the protocol is of type UDP.

• sdrop: The sdrop rule type instructs iptables to drop the packetThe difference with drop action is that nothing is logged if this type is active.

3.3.1.3 Preprocessors The Snort system uses special modules called preprocessors. They allow Snort’s function-ality to be fairly easily extended by allowing users and programmers to include modular plugins into Snort. Preprocessor module is run before the detection engine is called, but after the packet has been decoded. The packet can be modified or analyzed in an out-of-band manner using this mechanism. For example a portscan detector, telnet decoder, RPC decoder, and HTTP inspector are some known preprocessors available with the existing version of Snort.

- 27 -

3.3.2 Snort Utilization in VoIP / SIP Environments Snort’s functionality based on the rules and preprocessors distributed today with the Snort system allows to detect known attacks. The following ready-to-use VoIP related signatures are currently included in the Snort signature database:

Message WEB-MISC CISCO VoIP DOS ATTEMPT Summary This event is generated when an attempt is made to exploit a

flaw on a Cisco VoIP telephone. Description Description: Certain versions of Cisco's VoIP phones are

vulnerable to an attack that can cause them to reboot when they receive an http request such as http://ciscophoneip/StreamingStatistics?<value> where <value> is an integer value of arbitrary high value, typically a number greater than 32768.

References bugtraq: 4794, cve: 2002-0882, nessus: 11013

1:1814

Impact Denial of Service Message BLEEDINGEDGE Policy Skype VOIP Checking Version

(Startup) 2001595

Rule alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"BLEEDINGEDGE Policy Skype VOIP Checking Version (Startup)"; uricontent:"/ui/"; nocase; uricontent:"/getlatestversion?ver="; nocase; classtype:policyviolation; refer-ence:url,www1.cs.columbia.edu/~library/TRrepository/ re-ports/reports2004/ cucs03904. pdf; flow:to_server,established; sid:2001595; rev:4;)

Message BLEEDINGEDGE Policy Skype VOIP Reporting Install 2001596 Rule alert tcp $HOME_NET any -> $EXTERNAL_NET

$HTTP_PORTS (msg:"BLEEDINGEDGE Policy Skype VOIP Reporting Install"; uricontent:"/ui/"; nocase; uricon-tent:"/installed"; nocase; classtype:policyviolation; refer-ence:url,www1.cs.columbia.edu/~library/TRrepository/ re-ports/reports2004/ cucs03904. pdf; sid:2001596; rev:3;)

Table 2: Snort VoIP signatures The first one is specific to Cisco VoIP phones and the remaining address Skype VoIP cli-ents. However, they do not apply to SIP infrastructures. Snort extensible architecture allows the inclusion of custom rules, allowing the develop-ment of proprietary rules for use in Snort to expand its functionality and to detect identified vulnerabilities in VoIP communication and SIP signalling. Further the development of spe-cialized preprocessor modules for more complex testing of incoming traffic is supported through the use of snort_inline.

3.3.3 SNORT Drawbacks Snort can be used to monitor a SIP based infrastructure network for intrusion attempts, provided that rules for checking VoIP specific traffic are available. Unfortunately Snort does not accurately fit all needs relevant for the detection and prevention of attacks in a

SIP infrastructure. The matching infrastructure provided by Snort is versatile and has been proven to be very effective for dealing with most network based intrusions. However, for VoIP applications, there are some drawbacks to Snort directly: No reassembly functionality is available for grouping UDP packets that belong to a VoIP session. This means malicious patterns that are spread across UDP packets could elude the matching rule in Snort. (The stream4 reassembly module can only reassemble multiple TCP packets which belong to the same session and subsequently apply detection rules. Thus UDP streams, which can also be used for SIP signalization, cannot reliably be tested for malicious patterns, because these patterns can be spread across multiple packets). Snort’s detection is basically session unaware. It does provide stateful detection for some TCP applications like HTTP and FTP. However, there are currently no infrastructures that can help in processing stateful VoIP sessions. This could pose a problem for the detection accuracy and efficiency of detection. Encrypted communication cannot be parsed and malicious patterns cannot be found. This is one of major problems of all network-based IDSs. Moreover Snort is unable to search for malicious events across different protocols (SIP, RTP,etc). Furthermore Snort, does not allow dynamic rule updates, as it only parses its rules during system startup. For this rea-son a VoIP security architecture can not rely only on Snort capabilities, instead, a more so-phisticated application is needed for assistance.

3.4 Prelude IDS

3.4.1 Prelude Overview Prelude [34] is an open source Hybrid IDS distributed under the GPL license. It provides a modular and distributed architecture with different sensors, each of them with different ca-pabilities (e.g., network sensor, host based sensor). Figure 26 depicts the base architecture of the Prelude IDS.

Figure 26: Prelude Architecture

All sensors notify a Prelude manager about intrusion-sensitive events, which then are proc-essed and reported. This allows the concentration of all network related events in one spe-cialized place. This manager with its features (database management, human interaction) runs on dedicated host and thus frees resources the monitored and possibly attacked hosts.

- 28 -

Simple and unified communication possibilities between entities in the Prelude architecture are provided by the LibPrelude library, which exchanges messages based on the IETF standardized Intrusion Detection Message Exchange Format (IDMEF)[22] . Communica-tion between entities is secured through the use of TLS. LibPreludes enables the easy inte-gration of enhancement sensors into the Prelude architecture. In addition there is the possibility to use libprelude library to obtain two way communica-tions. This is not widely used, but it can be useful if we want to take control of counter-measure components from the Prelude Manager.

3.4.2 Prelude IDS Architecture Modules

3.4.2.1 Prelude-NIDS Prelude’s NIDS sensor provides classical capabilities of generic NIDS like a portscan plugin (for the detection of portscans), a Snort-rules plugin (for utilizing Snort signatures within the Prelude system), an IP defragmentation plugin (for reassembling IP fragments prior to signature lookup), and a TCP stream reassembly plugin (for reassembling TCP stream prior to signature lookup comprising several packets).

3.4.2.2 Prelude-LML The Prelude-LML sensor provides the log analysis function. Logs on a local system, as well as logs received from remote hosts over the network (in case the system is configured to accept syslog messages from the network) are processed and analysed in order to dis-cover security anomalies. Prelude-LML’s capability to manage and analyze log messages is based on a plugin system, for example through a Perl Compatible Regular Expression (PCRE) engine called Simple.

3.4.2.3 Prelude Manager Prelude sensors send events to a central manager which is in charge of event processing and reporting. A correlation agent providing more detailed data and better understanding of signalled events complements the manager’s function. Received messages can be stored in a database (MySQL plugin) or browsed and analyzed by a human operator through the Prewikka management console (Figure 27).

Figure 27: Prewikka frontend for Prelude

- 29 -

- 30 -

3.4.3 Extensibility for VoIP Environments The highly distributed and modular designed of Prelude system provides good flexibility and scalability for different environments. The Prelude system uses the LibPrelude library to ensure communication between the sensors and the manager, a powerful tool for provid-ing access to the managed information to the administrator. Making use of the distributed topology of the Prelude system and its hybrid-based IDS ar-chitecture can give additional benefits in comparison with the Snort IDS. It is, for example, possible, to develop billing fraud attack sensors (able to communicate with other sensors like Prelude-NIDS and Prelude-LML), which can be placed on the same device like the billing system.

3.5 Existing Attack Tools In this section we describe the most known utilized VoIP security testing tools or suites that allow users to assess the security of their VoIP infrastructure. The described tools fo-cus mainly in the test of robustness of SIP server implementations. The tools that we de-scribe are: 1. VoIP Vulnerability Scanner (SiVuS)

2. SIP Forum Test Framework (SFTF)

3. PROTOS suite

4. SIP Swiss Army Knife (SIPSAK)

3.5.1 VoIP Vulnerability Scanner (SiVuS) Sip Vulnerability Scanner (SiVuS), [24] is used primarily by developers, administrators, network designers, managers and consultants to verify the robustness and security of their SIP implementations by generating the attacks that are included in the SiVuS database or by crafting their own SIP messages using the SIP Message generator. The SiVuS scanner provides powerful features that allow administrators, developers and consultants to verify the robustness and secure implementation of SIP components such as Proxies, Registrars or phones either hard or soft. The following paragraphs provide additional details on the SiVuS functionality and features: • SIP Message generator: it can be used to send various types of messages to a SIP com-

ponent including SDP content. This feature can be used to test specific issues with SIP or generate various attacks for demonstration purposes (e.g. DoS, registration masquer-ading).

• SIP component discovery: it scans a range of IP addresses to identify hosts which use the SIP protocol and can be used as targets for further analysis. Note, that there is an option in the configuration scanner which allows preliminary discovery of targets prior to an actual scan. The discovery interface is typically used as a precursor to a scan to ensure that the appropriate targets should be scanned. Other uses of this are possible.

• SIP vulnerability Scanner: The scanner provides flexible configuration of several op-tions which can be used to verify the robustness and security of a SIP implementation The checks that are performed are as following: • Analysis of the SIP message headers to identify vulnerabilities such as Buffer over-

flows or DoS attacks. These checks can be selected and configured with variable values, by the user.

- 31 -

• Authentication of signaling messages • Inspection for secure communications (SIPS) and encryption capabilities

At the moment the scanner provides a user friendly report using HTML. Later versions of the scanner will support multiple arrangements and views of the data collected after a scan including maintaining a history of scanning sessions. The user is also provided with the ability to save messages from the activity log that are generated during a scanning session for later analysis.

3.5.2 SIP Forum Test Framework (SFTF) As cited in SFTF’s web page [25] , SIP Forum Test Framework (SFTF) can be utilized to allow SIP device vendors to test their SIP devices for conformance and interoperability with the SIP protocol specifications. More specifically, this test tool has been designed having in mind to identify various SIP interoperability shortcomings, which often appear in immature or hasty developed SIP User Agents (UAs), causing severe problems in existing SIP deployments. However, SFTF has not been used for exhaustive verification of compli-ance with SIP specifications. This test-suite may be additionally employed to identify be-haviours, which although conform to SIP specifications, are considered sub-optimal im-plementation practices. SFTF is written in Python. Consequently, it allows everyone hav-ing little programming knowledge, to write his own tests for SIP devices.

3.5.3 PROTOS Suite PROTOS describes a method to assess the robustness of SIP implementation by describing a general test suite to find vulnerabilities. The test suite set a baseline to determine vulner-abilities in SIP products focusing on SIP parser abilities, and can be used during in-house testing or as part of regression testing. The framework for creating robustness test suites has been based in the PROTOS project [35] . The PROTOS have proven to be efficient in testing for software vulnerabilities by using a black-box testing method based on syntax testing. In syntax testing, test cases are generated from the corresponding input specifica-tion. In the case of SIP had been constructed approximately 4527 malformed SIP-INVITE to test various implementation of SIP servers. The test suite is written in Java and is freely available in [36] . A detailed description about SIP PROTOS testing suite can be founded in [12] .

3.5.4 SIP Swiss Army Knife (SIPSAK) SIPSAK [26] is a tool focusing on developers and administrators of SIP application and servers and can be used as a SIP stress and diagnostic utility. As a stress utility can be util-ized to create either register or invite messages at high pace against to the corresponding SIP network element (registrar or proxy). On the other hand, regarding the behaviour of the tool as a diagnostic tool, a SIP message is sent to the destination in SIP-URI and the reply status is displayed. Generally, the tests that are implemented in the current version are the following: (1) send-ing OPTIONS request, (2) sending text files (which should contain SIP requests), (3) traceroute (see section 11 in RFC3261), (4) user location test, (5) flooding test, (6) random character trashed test, (7) interpret and react on response, (9) authentication with qop sup-ported, (10) short notation supported for receiving (not for sending), (11) string replace-ment in files, (12) can simulate calls in usrloc mode (13) uses symmetric signalling and thus should work behind NAT, (14) can upload any given contact to a registrar, (15) send messages to any SIP destination, (16) search for strings in reply with regular expression,

- 32 -

(17) use multiple processes to create more server load and (18) read SIP message from STDIN. A detailed description about SIPSAK can be found in [26] .

3.5.5 Limitations The main limitation of the tools presented in the previous paragraphs is that they mainly perform testing based on PROTOS suite focusing on assessment of SIP implementations. Although these tools are GPL licensed, a complete documentation to clearly explain the full capabilities of those tools and how they can be extended does not exist. As a result, the utilization of the source code of the aforementioned tools is an extremely hard procedure. Besides that, existing tools fail to cover existing vulnerabilities as described earlier in the previous section and are mainly based on pre-defined tests. Moreover, due to the lack of serious documentation the users are not able to test all the functionalities that the tools pro-vide, as sometimes these suites do not perform what they claim to.

- 33 -

4 Security Architecture Description

4.1 Attack Description Language The difficulty in developing a meta-model for simulation is founded in the different style, categories and implementations of the attacks that can be exist. It is seems to be necessary the definition of an abstract description for the SIP attacks in a computer readable way in-dependent for any platform restrictions. The abstract description defines the parameters for the security test simulation. In these simulation scenarios we will describe among other, source, target and a description of the simulated attack. The purpose of this structure is to provide a common attack description in a computer readable way, corresponding in a set of message exchanges between an attacker and a Proxy server or an end user device. A properly define structure will be able to handle the attacks which has been described in Section 2. Detailed analysis of the scenario structure is presented in the following paragraphs.

4.1.1 A SIP Attack Description Model We suggest the utilization of XML to build these scenarios. XML has been used in previ-ous works [30] [31] to describe SIP message flows, and its use simplifies adding new kinds of security-conformance tests without any modification of the general structure. Our attack description model basically consists of a two-level hierarchy. At the basic level we present XML elements to describe a single SIP message. The elements at this level are relevant parts of the SIP message for unique identification of the corresponding SIP mes-sage and can be utilized for later reference. Additionally, elements will be introduced to describe a message flow of basic SIP messages that will describe a certain kind of attack. Furthermore, to simplify testing, an XML attack description should include all the informa-tion needed, so that from its content

• the SIP IDS is able to detect this attack, and • an attack generator can generate this attack.

The attack description will be slightly different depending on whether it is utilized by the “attack generator” or by the IDS. This distinction is needed because of different points of view between defence and attack.

4.1.2 Generally Used XML Attributes SIP message have a certain structure. Each message contains different header fields and corresponding header values. These header values have to be encoded in predefined ways, e.g. a value might represent a SIP URL or a numeric value. We will introduce special XML attributes and corresponding attribute values for different cases. For example, the attacker needs to declare the range of different URI sources used for the attack while the defender requires a mechanism to associate URLs obtained from different messages with a certain threat.

Attribute Purpose Content SIP value types. Possible values are uri, address, int, string type Type of SIP message. Can be request or response

Value Purpose

ANY Indicates any possible value. For the scanner this means that

- 34 -

for a certain Header every possible value should be consid-ered. For the generator this generally means that this value should be generated randomly with respect t the generated field

PREVIOUS Indicates that the value should match to the previous re-ceived message’ header field value

EMPTY Describes an unspecified value

4.1.3 XML Elements to Describe a Single SIP Message We will present SIP Headers that are relevant for distinguishing SIP attack messages. These are the headers that need to be stored in the IDS state machine for further reference and comparison to previous occurrences.

Element Purpose <message> A SIP message. The type attribute defines if it is a request or

a response <Name of a SIP Header> Elements to describe relevant headers of the message have

the same name as the header. For example, elements will have the name <contact>, <from>, <to>. We derive these names from the long SIP header names in an all-lowercase spelling.

<Name of a SIP header parameter>

As above. Example: in a <from> element there can be a <tag> element embedded to describe the SIP tag attribute.

4.1.4 XML Elements to Describe SIP Message Flows In this section we describe the proposed elements which will be utilized to describe SIP message flows. As outlined in section 4.1.1, these elements (tags) will be used by Attacker and IDS to describe the attack. In the following table defined elements are described.

Element Purpose <security_test> The proposed document describes SIP attacks <target> Defines the target of the attack <Request-Line> SIP request line that will be utilized in the attack <headers> The headers that will be utilized in the attack <body> The message that will be utilized in the attack <send> Send a SIP message <message> The SIP message, specified by a type attribute <receive> Receive a request or a response <configuration> The configuration of the attack <source> Defines the source of the attack <parser> Description of the Parser attack <dialog> Unique representation of the relationship between SIP user

agents <trigger> This is the initial message which is possibly the beginning of

an attack <loop> Indicates that inside elements need to occur multiple times

(parameters e.g. infinity loops, threshold, … this could de-

- 35 -

scribe a flooding attack <lifetime> Timeout of an attack – after this time a suspicious flow is

declared to be legal.

4.1.5 Example of Flooding Attacks In this scenario we describe a multi-source flood attack, the duration of such attack is 100 sec and the attack messages are sent with an interval time distance 1 msec

4.1.5.1 Description for the attacker

<security_test> <configuration> <source> 10.10.120.10 </source> <source> 10.10.120.11 </source> <target> 195.251.164.23 </target> </configuration> <trigger> <loop duration=”100sec” interval=”1msec”> <send> <message type=”request”> INVITE <from content =”url”> [email protected]</from> <to content=”url”> [email protected]</to> </message> </send> <receive> <message type=”resposne”> </message> </receive> </loop> </trigger> </security_test>

4.1.5.2 Description for the IDS From the IDS perspective a possible description for the identification of a flooding attack could be the following

<loop threshold=”100 msg per second”> <trigger> <message type=”request”> INVITE <from content=”uri”>ANY</from> </message> </trigger> </loop>

mailto:[email protected]

- 36 -

Another example for a message flow:

<trigger> <message type=”request”> INVITE <from content=”uri”> ANY <tag content=”int”> ANY </tag> </from> message> <trigger> <timeout time=20s /> …

4.1.6 Example of Parser Attacks In this scenario the attacker constructs a malformed message in which the Request URI is missing.


<security_test> <configuration> <source>10.10.120.10</source> <target>195.251.164.23</target> </configuration> <trigger> <send> <message type=”request”> EMPTY <from content=”uri”>

[email protected]/> </from> <to content=”uri”> [email protected]</to> </message> </send> </trigger> </security_test>

4.1.7 Example of SIP Application Attacks In this scenario the attacker constructs a CANCEL message for canceling previous legal INVITE messages


<security_test> <configuration> <source>10.10.120.10</source> <target>195.251.164.23></target> </configuration> <dialog id=”12345678”> <send> <message type=”request”> CANCEL <from content=”uri”>[email protected]</from> <to content=”uri”>”[email protected]</to>



- 37 -

</message </send> </dialog> </security_test>

4.2 Defence Architecture Description The defence architecture is responsible for detecting attacks on the VoIP infrastructure, alerting the network operator of possible attacks and eventually prohibiting these attacks. The main components in this scenario are the Bastion host and the extended SIP proxy (See Figure 28). The main reason to split attack detection between two entities lies in the complexity of SIP attacks. A bastion host is only able to detect attacks based on a simple pattern, albeit with a very low processing overhead. In this case, we can filter already a certain amount of unsolicited messages with a low processing overhead. More advanced attacks also require an increase in processing overhead, so the input flow to the second de-fence entity should be as small as possible. The Bastion host can also host the network’s firewall solution. However, depending on network load it will also be possible to deploy a remotely controlled firewall host which will be remote controlled (e.g. for Snort through the SnortSam plugin [28] ) depending on the attacks detected. Inside the network we will use the Prelude framework as a basis to establish communica-tion between the individual defence entities and the management console.

Figure 28: Security Architecture

The architecture will allow a system administrator to secure its own network sufficiently to prevent the majority of attacks; however this will in general not be the case for the remain-der of other networks constituting the Internet. With the ubiquitous availability of internet access more and more hosts reveal a severe lack of proper security mechanisms. Simply, proper security application usually requires knowledge which the average user rarely has.

- 38 -

Thus, there will always be a plethora of hosts potentially available to malicious users to misuse them, for instance, as client hosts for wielding distributed DoS attacks. The end-to-end nature of the Internet does not allow for proper security enforcements to prohibit basic attack exploits as, e.g. address spoofing [27] . Ingress / egress filtering [29] at the provider level reduces the possibility of spoofed addresses to a certain degree; however, to be effi-cient it is mandatory that every provider utilizes this technique. As long as this is not the case, a system operator has to be prepared for distributed DoS attacks against his own net-work with little chance of tracing back the harmful traffic. Another issue has to be additionally considered. With the deployment of intrusion preven-tion systems (especially in the case of VoIP/SIP environments) some problems with self-inflicted DoS might appear. Take, for instance, the usage of spoofing source IP addresses in packets to force an intrusion prevention system to drop packets from another user. This user then will not able to use services provided by the SIP proxy. This is a classical symp-tom of DoS attacks, but in this case the DoS attack is caused partially due to the reaction of the intrusion prevention system. Because of the possibility of self-inflicted DoS, it is im-portant not to create too strict rules to protect a system. A less restrictive system with high throughput capabilities is likely to provide a more reliable service to the user. For this case, we will also investigate the possibilities to increase the processing capabilities of the target system.

4.2.1 Snort Bastion Host The bastion host is the first host that all traffic has to pass. The bastion host is based on the Snort IDS (see section 3.3) and is primary dedicated to the detection of attacks on the SIP infrastructure. In some specific cases it can be also used to prevent attacks by packet drop-ping. Thus the Snort IDS is able to • detect simple SIP attacks, like

o INVITE flooding, o REGISTER flooding, o Irresolvable DNS attacks, o SQL Injection attacks,

• detect known TCP/IP attacks, including portscans, TCP SYN attacks, and Smurf at-tacks,

• detect known attacks on all relevant infrastructure elements(SER, DNS, STUN), • detect other attacks specific to SIP contributing services like DNS/ENUM, STUN, etc., • prevent from additional attacks through Snort inline, which is designed to initiate

packet dropping based on packet headers and payload analysis. To enable this feature we will utilize available Snort rules and create specialized rules dedicated to our needs. We will also consider extending the Snort software to implant ad-vanced detection possibilities, e.g. network address range checking.

4.2.1.1 Using of Snort-Prelude IDS Snort IDS is used because of its flexibility in the setup phase. We can use the set of cur-rently available rules for detection of known attacks. We can also easily develop new rules for the detection of SIP specific attacks and for the detection of attacks targeted on SIP re-lated services like RTP proxy, STUN etc. Another advantage of using Snort IDS is the possibility to use a specially modified version of Snort IDS extended by the LibPrelude library to realize the communication between Snort Sensor and the Prelude Manager. It means that the Snort IDS can be part of the Prel-

- 39 -

ude system (cf. section 3.4). The deployment of the Snort IDS as part of Prelude brings significant advantages such as a distributed architecture, easy deployment of additional sensors (for example, Snort backup sensors or SER extension modules). The Prelude sys-tem allows concentrating gathered information about detected attacks from different sen-sors on one central point (Prelude Manager). When some attack is detected the Snort bastion host generates an alert and sends it to the Prelude Manager where all alerts are stored and finally presented to the analyst.

4.2.1.2 Placement of Snort Bastion Host The Snort bastion host is placed on a dedicated server due to performance reasons and can be placed before or after the firewall. Both solutions have advantages and disadvantages. The Snort bastion host can be connected to the SPAN (mirrored) port of the switch. Also hubs or special network taps can be used for the connection of the Snort bastion host. All these types of connection are using passive tapping of communication; the packets don’t go through them on the way to their destination, but they are duplicated and sent to the Snort bastion host. In this solution there is no additional delay for the analyzed packets. When the packet flow is mirrored as described the use the Snort inline functions for active intrusion prevention (malicious packet dropping) is inapplicable. Snort bastion host in front of the firewall Advantages

• All attacks directed against the network can be detected. By this way we are able to detect all the attacks the network is exposed to even if those attacks were blocked by the firewall.

Disadvantages • The Snort bastion host is exposed to higher load. • The analyst could be overloaded by a high number of alerts generated by attacks

which are stopped by the firewall anyway. • If the firewall allows NAT, tracking sources originating from the internal network

is difficult. Snort bastion host behind the firewall Advantages

• Only the attacks which get through the firewall are detected. • Less load on the IDS analyst. • Sources of packets from the guarded network can be detected in the case of using

NAT. Disadvantages

• We cannot see all attacks directed against the guarded network thus giving a false sense of safety.

4.2.2 Extended SIP Proxy While the bastion host will be able to act as a first important step to filter simple attacks, more sophisticated attacks on SIP need a more effective barrier. This function should be an inherent part of the SIP proxy for the following benefits:

• Available Infrastructure: Sophisticated attacks are not easy to detect or to be separated from general high traffic loads. To distinguish between an attack and per-fectly legal traffic, the agent needs a profound knowledge of SIP message flows.

The infrastructure is already available in a SIP proxy and can be utilized from it, like the parser capabilities or available storage space for message flagging.

• Redundancy Avoidance: Sophisticated attacks generally cannot be detected by the examination of only a single message. Usually, only a certain message flow in its entirety can indicate a possible attack. It is computationally ineffective to process these messages twice at different locations.

• Speed: As soon as a certain massage flow pattern is detected, the SIP proxy needs to take action to hinder further flooding. A timely response is critical for proper op-eration.

4.2.2.1 Improving Security through an IDS Module The Snort Bastion host will be an effective tool to prevent a large amount of attack traffic from reaching the processing SIP proxy. However, more sophisticated attacks might pass the Bastion host and could thus gain the possibility to attack the SIP proxy itself. To pre-vent this we’ll extend the SER with an advanced attack-detecting tool to handle these types of threats. The attack-detecting tool will be supplied as an external module (See Figure 29).

Traffic

State Storage

SER Processing Logic

Parser

IDS ModuleActions

Timeout / Size

Hooks /Callback

Configuration

Figure 29: SER IDS Module Overview

The core of this defence point will be the actual IDS module, which will be hooked into the standard SER proxy as a module through standard module hooks. As it can be seen from Figure 30, there are different possibilities for an external module to communicate with the core. The assignment of this module is the detection of attacks based on message flows, which will utilize a post-script callback in SER, that is the module will analyze the mes-sage after the normal call flow (parsing, routing decisions). This assures that any incoming message is already properly parsed by the SIP proxy. The defence module will utilize cur-rent functionality of SER’s pike module.

However, the placement at the end of the proxy’s parsing process makes it unfeasible for this module to check for any parsing related attacks, as this would require the re-parsing of

- 40 -

the whole SIP message again. This would induce an additional computing overhead, which would contradict the precondition of having a high-speed proxy.

Module Init:loadmodulemodparammod_init / init_child

Message Parser (receive_msg)● Creation of sip_msg struct● Initial parse (parse_msg )● pre-script module callback

Incoming Message

Routing engine (run_actions )● do_action● Module (unknown command in routing logic) ● on_break handler (only if processing is stopped on error)

post-script callback

Figure 30: SER Module Interaction Other components of the IDS module will be a configuration possibility to extend the module with different kinds of attack flows. For configuration, the XML description as presented in Section 4.1 will be used.

Finally, the module needs a state storage where it can place gathered information about ongoing call flows. Essential characteristics of suspicious call flows will be stored here for a limited amount of time, until either an attack is detected based on call flow, or the suspi-cious call flow has been classified as a legal call flow.

If attacks are detected, further actions have to be taken: An attack alarm has to be sent to the centralized control station, and if the attacker can be identified, the firewall has to be instructed to block further traffic originating from this user. The communication frame-work will be based on the Prelude framework as described in Section 3.4), which will eventually use iptables to block unwanted traffic. We will use our own defined chain called for example DEFENSE in which the rules for dropping packets based on the incoming IP address are inserted. The structure of Iptables chains and placement of our DEFENSE chain is depicted in Figure 31.

- 41 -

INPUT

ROUTINGDECISION

OUTPUT

FORWARDIncoming Outgoing

DEFENSE

Local Processes

SIP Express Router

Other process

Figure 31: Pike Defence module based on Iptables

4.2.2.2 SIP Proxy DNS Protection To remedy DNS blocking attacks (see Section 2.4) we introduce the concept of a dedicated DNS cache for the SIP proxy as depicted in Figure 32. An additional module providing optimized DNS caching for SIP needs enhances the SIP proxy. The SIP DNS cache acts as an interface to handle name resolving requests from the SIP proxy. In regular operation mode, that is no attack is launched against the SIP proxy, the dedi-cated cache receives DNS translation requests from the SIP proxy and resolves these re-quests, possibly even by delegating these requests to the standard network DNS subsystem. Replies are stored in its internal cache for further reference. However, in case of an attack the dedicated DNS cache does not try to resolve any un-known domain names. It never delegates any requests to the underlying subsystem, instead it only returns responses from its internal cache. If no response is available in this cache, an unresolvable host error is returned to the SIP proxy. In this mode it is guaranteed that every request is processed in the shortest possible time, which prevents the server from blocking. While only clients with addresses already available in the cache can be served, this at least allows the operation for this user base. Without this cache, it cannot be guaranteed that the service can be maintained for any user. Optimized caching strategies can increases the pos-sible user base. Successful DNS cache operation relies on two key concepts. • Attack detection. The DNS cache needs to have a reliable way of detecting an attack

on the SIP proxy. As this module will remedy consequences from a DNS blocking at-tack, it needs to detect such attacks. In case of a blocking attack, the SIP proxy is wait-ing for an answer from the DNS resolver. In the case of SER, many parallel processing queues will be in this state at the same time. If the SER proxy has n processing queues launched for message handling, we can state an attack scenario if at any single moment n-x processing queues are blocked by DNS requests. The exact value of x has to be de-termined.

• Caching strategy. General DNS caches store for a certain amount of time host names (A records) for further reference. However, a SIP proxy might query for other DNS re-

- 42 -

cords, especially SRV and NAPTR records [23] . These records need to be additionally stored in a SIP DNS cache, otherwise blocking can still occur if these records are re-quested. Finally, a caching storing and refreshing strategy has to be determined. Gener-ally, a most-frequently-used strategy is likely to be most effective, as there will be a smaller set of hosts (of the most common SIP services providers) which will be con-tacted most often. This will be determined during test runs, together with the optimal Time-to-live value to prevent DNS cache poisoning.

SER Processing Logic

SER DNS Cache

Regular DNS Lookup

Message

AccessControl

Figure 32: Dedicated SIP proxy DNS cache

4.3 Attack Architecture Description The limitations of current VoIP testing tools as presented in section 3.5 show the necessity of the development of a new security testing tool. The new SIP attack tool will not only cover already existing security tests but also the presented additional security flaws. In this section we give the architectural description of this tool and its components.

4.3.1 Attack Tool - General Requirements Administrators and developers of SIP services need a tool for the testing of the security level of their SIP infrastructure and for the “measurement” of the protection level offered by the corresponding intrusion detection system. As already described in previous sections the SIP infrastructure is vulnerable to the following attacks:

1. Flooding Attacks

• Single Source Flooding

• Multi Source Flooding

2. Application level attack

• SQL injection

• SIP signalling based attacks

3. Implementation errors and vulnerabilities

• SIP parser attacks

- 43 -

• Other SIP vulnerabilities and implementation errors

The testing tool will be capable of launching attacks as described in the previous section, to test the SIP infrastructure and to provide input to and evaluate any developed intrusion de-tection tool suitable for SIP. The general idea is to build on a black-box approach, so that the tester will not need to know technical issues with respect to the developed platform creating a security test. The tester will be able to describe the attack simply by utilizing the appropriate interface and subsequently executing the corresponding test.

4.3.2 Platform Design As depicted in Figure 33, the tester has to describe the kind of test in which a SIP entity must be evaluated, so that the test will passed in the SIP Security Testing Platform (SSTP) and then will later inform the tester with the corresponding results and behaviour of the SIP testing entity.

Testing SecurityPlatform

(1.0)tester SIP testing Entity

attack-data testing-scenario

testing-resultsresult Figure 33: General Functional Architecture

The attack platform consists of the following independent mandatory parts: 1. Testing Scenarios Module: This module manages the scenarios available for security

testing purposes.

2. Attack Module: This module launches the attack depending on the selected scenario.

3. Result Module: This module administrates the results of the attack.

The “tester” is able to create his own dedicated scenario or to utilize pre-existing scenarios to test the SIP architecture. After selection of the appropriate scenario, the scenario is passed to the attack processing module in order to execute the selected scenario. The corre-sponding responses are passed to the processing result module where they are stored or presented to the user. A detailed description of the aforementioned procedure is depicted in Figure 34.

- 44 -

testing-results

Tests Processing (1.1)

testing-scenarios

tester Attack Processing(1.2) SIP testing Entity

scenariorequests

responses

presented

Process Results(1.3)

results

store

restore

newscenario

scenario

store load

Figure 34: Basic Components of the SSTP

4.3.2.1 Testing Scenario Module This module manages all the security testing. The tester will be able to control the scenar-ios. The functionalities that will be offered to the tester are the followings: 1. Add a new security test.

2. Store a test in the appropriate form.

3. Modify existing scenarios parameters.

4. Load a scenario.

5. Delete a testing scenario.

Figure 35 displays the communication between these functionality entities. For example, the tester will be able to load a pre-existing scenario, modify it and save it to be utilized by the attack module.

- 45 -

modify Test(1.1.3)

tester modification

testing-scenarios

load Test(1.1.4)

selected scenario

scenario

Delete Test(1.1.5)

selected scenario

New Test(1.1.1)

Save Test(1.1.2)

store scenario

described scenario

scenario

scenario

scenario

scenario

Figure 35: Test Scenario Management

4.3.2.2 Attack Module The core of the SIP Testing Security Platform (STSP) is the attack module. Depending on the selected scenario the STSP loads the appropriate attack description to execute the cor-responding security testing. Based on the SIP vulnerability classification the STSP attack module is divided into the following sub-components:

1. Flooding Attack Sub-Component (FAC)

2. Application Attack Sub-Component (AAC)

3. Implementation Checking Sub-Component (ICC)

Note: There is no dependency between these components.

4.3.2.2.1 The Flooding Attack Component Attack tools that cause bandwidth depletion or resource downfall are based on the architec-ture depicted in Figure 36Error! Reference source not found.. The SIP flooding compo-nent is based on the same architecture.

- 46 -

attacker

iM ac

client iM ac

clientiM ac

client

daemon daemon daemon daemon daemon daemon

target

Figure 36: Flooding Attack In order to be able to install a flooding security testing scenario the development of the fol-lowing components is required. 1. Tester: First of all, the tester must install all clients needed for the test execution, and

choose the testing system (target). After that the attacker has to choose the type of flooding scenario sending the appropriate commands to the corresponding clients. The following commands are available:

• F_REG: REGISTER flooding

• F_INV: INVITE flooding

• F_KILL: Stop the flooding attack

2. Client: The clients are responsible for the activation of the corresponding daemons. The clients direct the daemons to flood the target with the selected SIP method and subsequent collect the results (returned from the daemons) and forward them to the at-tacker (tester).

3. Daemons are in charge of flooding the network using the selected SIP method as gen-erated by the corresponding clients.

- 47 -

4.3.2.2.2 The Application Attack Component This module will be able to launch any of the attacks as described in Section 2. The appli-cation attack component is divided into the following sub-components: 1. SIP signalling attack module: This module’s task is to launch the SIP signalling attacks

described in Section 2.2 In addition the test platform must be able to read and handle the appropriate values from the network under real time constraints.

2. SQL injection attack module: This module assesses the capability of an attacker to cause damages to different parts of the corresponding database.

4.3.2.2.3 Implementation Checking Component The HTTP-like ASCII presentation of the SIP messages may initially be more attractive to attackers for vulnerability assessment than the complex encoding rival signalling protocols (e.g. H.323, MGCP, SKINNY). As a result, a malicious user can easily construct mal-formed messages to mount an attack against SIP parsers. This attack module is specifically designed to construct and load such messages to test the robustness of the SIP parsers against this kind of messages.

4.3.2.3 Result Module During the attack testing, the SIP testing entity will generate responses that must be proc-essed and presented to the tester. All the responses gathered after the corresponding proc-essing are stored for later analysis (by the tester or any other external module) and presen-tation.

Store Results(1.2.1.2)

Present Resutls(1.2.1.1) SIP testing Entitytester

testing-results

Open ExistingResutls(1.2.1.3)

request existingresults

present

present responses

responses

request existingresults

resultsresults

Figure 37: Result Processing

Note: The results will be stored in HTML format.

4.3.2.4 Graphical User Interface The Graphical User Interface (GUI) provides a user-friendly environment to the SIP tester to execute security tests for evaluating SIP servers. The general structure of the GUI is de-picted in Figure 38.

- 48 -

U S IN G S C E N A R IO 1

S S T PS C E N A R IO S R E P O R T S Q U IT

A A C IC CF A C

L o a d e d S c e n a r io

Figure 38: SSTP GUI

4.3.3 Implementation Issues It is our intention to use the C or C++ programming language for the implementation of the attacker module. Additionally, if the use of any script language is required, PYTHON is preferred, as it can be easily embedded in C and C++ programs and some libraries for SIP based on PYTHON already exist. OSIP is the proposed API for SIP. The favoured devel-opment operating system is Linux. The use of Qt [33] is recommended for the GUI devel-opment.

4.3.4 Restrictions, Limitations and Assumptions The attacker design will be based mainly on internal security testing procedures. The communication between attacker, client and daemons will be based on standard proto-cols such as TCP or UDP.

- 49 -

5 High Availability

5.1 Description VoIP faces a direct comparison to existing PSTN services, which feature a very high avail-ability. Thus, VoIP services are required to be available at a possible maximum time. SIP based VoIP services are realized by server processes on Internet based computers, which serve the different purposes needed to provide a service. Figure 39 depicts a typical server architecture and communications relations for a normal SIP phone service.

SIP Server

RTPRelay

Database

STUNServer

Phone

PSTNGW

Figure 39: SIP server architecture

The SIP server acts as SIP proxy and registrar. It accepts messages from phones and proc-esses them. The RTP relay is needed in case that the client (phone) is behind a NAT. It is controlled by the SIP server which requests mappings for NATed users whenever they make a call. The STUN server acts as a stand-alone service and is not involved in SIP mes-sage processing. In fact phones which are located behind a NAT can also do without a STUN server. The PSTN gateway acts like a normal SIP phone to the Internet and as an ISDN phone to the PSTN. It is used to allow Internet located VoIP users to initiate calls to the PSTN. Because these calls cause costs, this gateway is usually configured to accept SIP messages only from a dedicated IP address, which is the SIP proxy of the provider. The Database is used to store any persistent information. The most important persistent infor-mation is the following:

• User location A table holding the association between the users world wide unique SIP URI and its current location, i.e. IP address and port where he registered.

• Subscriber data. A list of subscribers with their authorization information, prefer-ences and rights.

- 50 -

• Accounting information. The start and duration of calls which were initiated by the user. This information builds the base for generating call detail records (CDR) to charge the subscriber.

In order to achieve a higher availability of the services, each component must be designed redundantly. This is done differently in detail for each component. Basically each compo-nent is doubled.

RTPRelay(main)

Database

STUNServer

Phone

PSTNGW1

(main)RTPRelay

(backup)

Database

PSTNGW2

(backup)

SIPserver(main)

SIPserver

(backup)

Figure 40: SIP HA server architecture

5.1.1 Doubling the RTP Relay The SIP server installs mappings to the RTP relay and receives the mapping result from it. The software used as RTP relay is the “SIP RTP relay” (SRR). The basic idea here is to make the backup server take over the IP address from the main server in case of failure. In order to continue work properly, the backup server must have the same runtime informa-tion as the main system. The SRR-HAD (SRR High Availability Daemon) is responsible for this. The SRR-HAD hooks into the message flow between the SRR and the SIP server and replicates all information to its backup instance. It also sends periodic heartbeats to the backup system. The backup system feeds its local SRR with the mapping information it has received from the main system. In case of failure (missed heartbeats) the backup SRR-HAD activates the public IP address by which the RTP relay is known at its public interface. This directs all traffic to the backup system, which behaves as main system from then. Figure 41 depicts the relation between the components.

- 51 -

srr

srr had srr had

srr

RTP relay (main) RTP relay (backup)

state replicationheartbeat

SIP server

Figure 41: SRR replication

This technique introduces some changes to the SRR software. It must be enabled to install foreign mappings while in backup mode. This means that it will not decide about the port numbers it maps by itself but accept the mappings as they come from the SRR-HAD.

5.1.2 Doubling the PSTN Gateway The PSTN gateway is doubled by simply adding another one with a different IP address. There is no service side take over provided by the gateways. PSTN gateways are usually closed boxes where it is not possible to add custom software components. Thus the SIP server will be responsible to address the correct, means working, PSTN gateway. The SIP server must periodically test the main PSTN gateway if it is still alive.

5.1.3 Doubling the Database In order to make the database not a single point of failure, it must be designed redundantly. For this a variety of solutions already exist. In this case the MYSQL -cluster from mysql.com will be used. It provides a network storage engine which offers the possibility to construct redundancy groups, where the storage engine takes care of any data replication in real time. A typical MYSQL cluster node layout is depicted in Figure 42.

storage0

storage1

storage2

storage3

manager

group0 group1

db clientapplication

db clientapplication

Figure 42: MySQL cluster (2x2)

In this scenario there are two redundancy groups with two storage nodes per group. Thus two nodes, one in each group, may fail without service interruption.

- 52 -

5.1.4 Doubling the SIP Server The effort to double the SIP server is comparable to doubling the RTP relay. If the main server fails, the backup server is expected to take over the service immediately. In order to do so, it must take over the IP address from the main system and have the same informa-tion state as it right before the crash. This implies that there must be some kind of informa-tion interchange during normal operation, to keep the backup system informed. This in-formation, which must be shared, is the transaction state. Every incoming SIP message ei-ther creates a new transaction or belongs to an existing transaction. The list of existing transactions must be shared in order to allow service take over. Also some meta informa-tion must be shared, like the address of the main PSTN gateway. The sip server software to use will be SER.

ser

SIP server (main)

ser-hadhadcon

ser

hadcon

ser-had

SIP server (backup)

Figure 43: SIP server HA architecture

Figure 43 shows the components needed to make SER instances interact in the desired way. It introduces two new components, the SER-HAD and the ser part of it, the HAD-CON (HAD-connector). The SER-HAD sends and checks heartbeats to and from the other instance, interchanges state information (transaction state, meta data, etc.) and periodically pings the PSTN gate-way with ICMP echo request messages to check whether it is still alive. It will inform the HAD-CON part of SER upon any failure situation, like an unavailable PSTN gateway or missing heartbeat from the other SIP server. The HAD-CON is the hooking code inside SER that allows intercepting transaction state changes. It communicates with the ser-had which then does the replication to the other in-stance. The HAD-CON also provides a ser module that has functions to look up the cur-rently available PSTN gateway from the ser configuration script.

5.1.5 IP Takeover The method to take over the IP address is very similar to the method described in the Vir-tual Router Redundancy Protocol (VRRP). Both machines have an interface connected to the same network. Each interface has two addresses, one of them is shared. The shared ad-dress is the public address by which the service is addressed by others (e.g. phones), while the private addresses must be different. They are used for communication between the main and backup system (e.g. heartbeats, state transfer). Thus the shared IP address would normally appear twice on the same network, which would cause severe trouble. So only the main system sends out Address Resolution Protocol (ARP) messages that announce this IP address to the network, while the backup system does not do so, although it has the address assigned to the interface. In case of IP takeover, the backup system simply starts sending out ARP messages to announce the public address.

- 53 -

The underlying operating system (LINUX) provides a mechanism to filter network pack-ets. In our scenario it will be used to block outgoing ARP messages for the shared IP ad-dress on the backup system. In case of IP takeover this filtering rule will then simply be removed. It is necessary to have the public address already assigned to the network interface, be-cause processes explicitly bind to an IP address on startup. Thus it not possible to add the IP address to the interface incase of takeover.

134.23.17.6192.168.24.5 sending ARP responses

for both IP addresses

ProcessProcess Process

Main host

134.23.17.6192.168.24.6 sending ARP resp

NOT sending ARP resp

ProcessProcess Process

Backup host

Local network

Figure 44: IP address takeover

5.2 Possible Extension: Load Balancing Through the previously described solution, a highly reliable VoIP network can be estab-lished. However, to further improve the efficiency of the network, additional enhancements might be added to the network. This could be e.g. a load balancing solution. As shown in the following figure, for each SIP domain there are multiple SIP servers in order to serve SIP transactions requested by SIP clients. This means that for each SIP do-main, the DNS server has multiple SRV records corresponding to SIP proxies attached to it. According to our method depicted in, when a SIP client requests to initiate a SIP call, the proposed entity called “SIP Balancer”, will perform a selection of the most appropriate SIP server, based: (a) on the DNS SRV records of the available SIP servers and (b) on various workload metrics collected from the existing SIP proxy servers, such as locations of the client and SIP server, SIP server load in terms of processing transactions, overall workload in each SIP server, etc.

- 54 -

C B

SIP Proxy A

D

SIP proxy with workload-balancing capabilities

“Balancer”

SIP Client

DNS

Req uest fo r SR

V for a vailab le

SIP

proxie s

Workload data

SIPDomain

Communication when Balancer is offline

Figure 45: General SIP load balancing architecture

More specifically, the SIP Balancer is an add-on entity which is responsible to query DNS and maintain SRV records of all the available SIP proxy servers in the corresponding do-main and for each SIP client request to return the most appropriate SIP proxy, in terms of workload, to serve that request. In other words, SIP clients firstly communicate with the Balancer to find out the best SIP proxy available. If the Balancer is not responding the SIP client can communicate directly with the DNS to retrieve all the available SRV records corresponding to SIP servers in the domain and select one. However, having in mind that until now SIP clients do not support DNS direct transactions, another solution for the SIP client is to communicate directly with another available SIP proxy in same domain. The IP addresses of the Balancer and the backup SIP proxies can be pre-configured in the SIP cli-ent device. As a result, the IP address of the most appropriate SIP server is selected by the Balancer and while the first message (e.g. INVITE) goes through the Balancer the conse-quent messages for the same session go directly to the selected by the balancer SIP proxy. This is possible using the information in the Via Header.

- 55 -

SIP Client

Is Balanceravailable?

Next available SIP proxy

SIPBalancer

dataDecision (OR)

DNS Query

OR

SIP Balancer

SIP Proxy C

SIP Proxy B

SIP Proxy A

Direct communication with the selected by the Balancer Proxy

(Use the Via Header)

Figure 46: Decision flowchart

There are different ways to calculate the SIP servers’ workload and different schemes to deal with it. Some of the well-known solutions include the following: Round Robin: Upon to a new SIP request, the SIP Balancer selects the next IP address re-cord for the specific SIP server alias name as stored in the DNS. This solution does not re-quire from the Balancer to maintain and update workload information from the available SIP servers in the domain. Dynamic Weighting (Least Connections): This means that it is selected the server which currently handles the least number of SIP transactions or it has the minimum overall work-load. This can be accomplished in the following ways: The Balancer module at fixed time intervals (e.g. 5 minutes) requests the current number of SIP servers (SRV records) available within the DNS server and resolves their FQDNs. Af-ter that, the Balancer at predefined or dynamically assigned intervals (say 120 seconds) queries all the available SIP proxies for information like CPU usage percentage and mem-ory consumption. Based on the returned data, the Balancer generates a SIP proxy prefer-ence list from the least to the most utilized. As an alternative or orthogonal to the previous method, any SIP proxy can dynamically inform at any time the Balancer when some workload parameters (e.g. concurrent number of SIP transactions) exceed a specified threshold. Of course, this requires the installation of an appropriate daemon or module in each SIP proxy to monitor the corresponding work-load metrics. In case that all available SIP servers are overloaded, it is selected the one with the least current overload. Summarizing the above paragraphs, our solution is DNS independent, so it does not re-quire any modification or extension to existing DNS records or mechanisms. The only req-uisitions are: (a) the addition of the Balancer independent machine, (b) a daemon or proc-ess running in each SIP proxy to collect workload metrics and handle the incoming queries from the Balancer and optionally (c) inform in an asynchronous fashion the Balancer when a certain threshold is violated. Moreover, the exchanged messages are lightweight having minimum impact on SIP proxy servers’ performance. In addition, for security reasons, the exchanged messages between the Balancer and the SIP proxies can be signed using sym-

- 56 -

metric or asymmetric key technology to protect against replay attacks, tampering and man-in-the-middle attacks.

SIP ProxyBalancer

Request (workload metrics)

Msg_Sequence _Number: (Small_Integer)CPU_Usage : (percent )Memory_Consumption : (percent )Concurent_SIP_Transactions: (Integer)

ACK Figure 47. Communication protocol between the Balancer and SIP proxies (in case

the SIP proxy initiates the communication only the last two arrows are present)

- 57 -

- 58 -

6 Testing and Quality Assurance

6.1 Scope of Quality Assurance and Evaluation Plan The Snocer Quality Assurance (QA) plan has the purpose and intention to define all the procedures, techniques and tools to be developed, evaluated and implemented allowing and ensuring the highest quality in a persistent way. In general the Snocer QA plan has the in-tention to cover all the phases of the project and assure that the concepts, solutions and tools being developed comply with the definitions and requirements set up by the consor-tium partners. A parallel activity of Snocer QA will be the verification and validation (V&V) of Snocer components. The V&V activities are closely associated with QA and are carried out through the whole development life cycle. An independent subdocument docu-ment (V&V Plan) can to be triggered to cover these needs after the finalisation and devel-opment of Snocer tools, solutions and concepts. However, a clear distinction should be made: QA is mostly a management function, whereas V&V are technical development processes. V&V are concerned with fault detection, but QA has a broader remit: It is concerned with system/ concept /solution reliability as well as other attributes such as maintainability, portability and readability. It is obvious that quality does not just accidentally happen. It should be engineered into the system under design through a conscious process of specification of quality, design for quality, and assurance of quality by means such as the use of standards, inspection, and cross-checking against those standards. Quality planning should begin at an early stage in the development process. Experience has shown that, in the development of large software systems, most errors occur in the specifi-cation and design stages. The sooner an error is detected the lower the cost of fixing it. In the next sections of the quality plan it is clearly stated which quality attributes are most significant for the product being developed. Procedures and metrics are defined to check each end product against its quality specifications to see if the desired quality has been at-tained. Each aspect of quality is assessed, by some kind of metric (measure).

6.2 Management goals SNOCER Quality Assurance Evaluation Plan process has two distinctive management goals: • Prove that the functionality specified in the DoS detection and handling strategies and

reliability mechanisms for VOIP infrastructures is actually delivered by the system; and accomplished through a V&V Plan of the tools and components,

• Assess the quality attributes of the system at the implementation, integration and test-ing and mainly at the running phase of the system; accomplished through the Continu-ous Quality Evaluation.

While the V&V Plan aims to prove that the functionality, delivered by the development team, is as specified. A detailed plan will be prepared at the end of the design phase and it will consist of: • The several test phases, namely: functional testing, integration testing, performance

testing, multi testing, system Testing, business Acceptance test.

• A time plan associated with the test phases • Description of testing environment • Identification of tools to be used, if any • Identification of resources • Description of data to be used In the Snocer QA, the attributes followed will form the metrics, along with the assessment methodology of the Continuous Quality Evaluation to be defined. It is very important to note that the overall assessment of Snocer quality should be based on both these components. This means that the V&V Plan together with the Continuous Quality Evaluation cover all quality aspects of the system and their positive outcome guar-antees that: • The functionality of the system is as specified. • The system/tools is of high quality; the software implements/supports the intended

business functions and achieves the standards required by the company. • The delivered interfaces work correctly with existing systems. The above-mentioned procedure is graphically depicted in the following figure.

Figure 48: QA and Evaluation process

The quality assurance mechanisms will involve feedback (external control) and the inter-nal auditing performed automatically in predefined intervals. These two mechanisms will operate in parallel, both of them logged explicitly so that the quality assurance mecha-nism can itself be checked.

6.3 Quality Assurance and Evaluation Methodology Guidelines The methodology proposed follows the basic guidelines contained in a number of relevant standards and practice guidelines, namely:

- 59 -

- 60 -

McCall’s quality model is one of the earliest quality models, suggested by Jim McCall and colleagues [37] . The model defines software-product qualities as a hierarchy of fac-tors, criteria and metrics. A quality factor represents a behavioural characteristic of the sys-tem. A quality criterion is an attribute of a quality factor that is related to software produc-tion and design. A quality metric is a measure that captures some aspect of a quality crite-rion. ISO 9126 is a more specific standard for quality assurance of software products and ser-vices [38] . It proposes a framework for the evaluation of software/service quality. A number of other relevant standards exist, applying to specific aspects of S/W quality. The ISO 9241 series [39] incorporate a number of standards on usability. The IEEE-standards [40] apply to particular aspects relating to recommended practice for software design, software quality assurance planning and software requirement specification. ISO 10006, which is a widely accepted standard and concerns quality management in pro-jects [41] . This standard gives guidance on those quality system elements, concepts and practices for which the implementation is important to and has an impact on the practice of project management. These guidelines use project management processes to serve as a framework for the development of any applications or services. Rational Unified Process, which is a Software Engineering Process. It provides a disci-plined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high-quality software that meets the needs of its end users, within a predictable schedule and budget. All of the above standards have been considered when developing this quality assurance and evaluation plan. Particularly however the ISO 9126 and the Rational Unified Process have been particularly considered for the establishment of the general framework of the proposed methodology. More specifically ISO 9126 model reflects better a user view, while other models, for example the McCall, reflect more of a product/service view. Ra-tional Unified Process captures many of the best practices in modern software develop-ment in a form that can be tailorable for a wide range of projects and organizations.

6.4 Quality Assurance Organisation The quality assurance is carried out and administered by a team that reports directly to the project management level. The QA team should be populated from all the administrators of the system and also from an external body (e.g. the QA department of the enterprise). Responsibilities of the team include: • Ensure consistency of processes and compliance with procedures across the several

groups and domains involved in the project; • Analyse auditing and feedback data and report results to the management; • Propose actions to maintain and possibly increase quality. The following figure shows the proposed management structure that is needed in order to ensure quality. Specific responsibilities of each team member are assigned in the definition of higher-level metrics.

ProjectManager

SW DevelopmentTeam

System Administrator

SecurityAdministrator

DatabaseAdministrator

ContentAdministrator

Quality AssuranceDepartment

Figure 49. Snocer QA organization for the deployment phase

6.5 Evaluation Process Model For the purposes of the evaluation of the Snocer models, Tools, Solutions, emphasis has been placed on addressing quality from the SME's requirements point of view. The evaluation process model consists of three stages (adapted from ISO 9126) as in the fol-lowing table.

Table 3: The three stages of the Process Model Stage Description Role

1

Quality Re-quirement Definition

Specify requirements in terms of quality attributes (characteris-tics) and possible sub-characteristics. Requirements express the demand of the environment for the services under considera-tion, and normally must be defined prior to the development. As a software product, concept, tools or service is decomposed into major components, the requirements derived from the overall product may differ for those of the various components.

2

Evaluation Preparation

Prepare the basis/goals for evaluation, which include the qual-ity metric selection, the rating level definition and the as-sessment of this criteria definition. Every quantifiable feature of software and every quantifiable interaction of software and service with its environment can be used as a metric that corre-lates with a characteristic.

3

Quality

Evaluation Procedures

This step is refined into three steps, namely: • Monitoring/measurement, • Rating and • Assessment. For measurement, the selected metrics are applied to the Snocer tool, solutions concept or service. After this, the rating level is determined for a measured value. Assessment is the final step

- 61 -

- 62 -

where a set of rated levels is summarised. The result is a statement of the quality in the tool, solutions concept or ser-vice.

6.6 Snocer model Quality Requirement Definition In this stage, quality-requirements for the Snocer system will be specified. Definition of the quality requirements is a process that aims to deliver a set of quality evaluation charac-teristics that are critical for the particular application. This is carried out in a systematic way, while maintaining a close reference to the context of use for the system. The follow-ing four steps, towards the definition of the requirements, have been formulated;

• Identification of context of use, • Analysis of the system, and the solutions • Assignment of quality evaluation characteristics, • Assignment of criticality.

6.6.1 Identification of context of use The Requirements express the demand of the environment for the tool, solutions concept or service under consideration (they are defined prior to the development). During the re-quirement analysis and pilot design phase, the usage of the system has been described. The general context of use of the system has been also derived on the basis of a more detailed investigation of the aspects relating to the usage of the services.

6.6.2 Analysis of the Tools On the basis of the context of use analysis, the Snocer system tools, solutions and concept is decomposed into services (sub-systems). This breakdown has been based on the differ-ent contexts of use for each one of the services and is characterised by differing tasks, us-ers and environment of use. The Services will provide information dissemination, informa-tion retrieval, information exchange, information advisory on products and functions, etc.

6.6.3 Assignment and Ranking of Quality Characteristics to Snocer Services

According to ISO 9126, six main quality-characteristics (functionality, reliability, usabil-ity, efficiency, maintainability and portability) of software are identified, which are further broken down into a total of 23 sub-characteristics. Some of the quality characteristics, such as functionality, usability and efficiency, relate to aspects that mainly concern the interac-tion of the system with the user. Accordingly, acceptability and reliability are important for the exploitation and marketing of the system. Based on the ISO standard and with respect to the specific services and domain of Snocer, all the main characteristics are considered. As for the sub-characteristics, those that are more relevant are also considered. The following table lists the Snocer quality characteristics and indicates those that are rele-vant to each of the sub-systems, as they have been interpreted from the Strategies, mecha-nisms and infrastructure. The degree of criticality of each characteristic relates to the particular features that will guarantee a successful penetration of the concept into the target service domain and will

- 63 -

further provide the competitive advantages over similar services. The table below provides the relevant characteristics, which are now depicted in terms of their criticality index.

QUALITY

CHARACTERISTICS Criticality Evaluation

Main Attributes In-dex

Comments

Suitability 1 Strategies/Infrastructure should be fulfilled.

Accuracy 1 Accuracy in the information exchange processes is crucial.

Interoperability 1 Information exchange takes place between a number of different OS and types of tools.

Functionality

Security 1 The most critical components described in detail.

Maturity 3 Maturity comes with time and should not be a first priority target for the prototype solutions

Fault tolerance 1 Fault tolerance is important since information ex-change is in the critical path of the development processes

Reliability

Recoverability 2 For the test bed is important since evaluation of tools are to be defined between sites.

Understandabil-ity

1 Operation of the concepts, solution, tools should be straightforward for people having introductory train-ing

Learnability 1 Both on-line and off-line resources for easy learning of the system should be available.

Usability

Operability 2 According to predefined specifications.

Time Behaviour 2 Time behaviour is important and specific limits ac-quires in the project. For the Test bed demonstration it is important to set-up the proper mechanisms to measure relevant key indicators and efficiency.

Efficiency

Resource Be-haviour

2 Since the architecture of the Snocer concept is cen-tralized, the resources behaviour is not critical. Due to the fact that a large number of sites will use the services, the related parameters should be monitored.

Analysability 2 Analysis and traceability of the Snocer tools, solu-tions is critical for the maintenance and upgrade phase

Changeability 2 The cost to change the system should be kept mini-mal (Low cost).

Maintainability

Stability 2 For the test bed demonstrations, stability is a critical key factor

- 64 -

QUALITY CHARACTERISTICS

Criticality Evaluation

Main Attributes In-dex

Comments

Testability 1 Effort to verify the system should be minimal Localizability 1 Localised User Interfaces and services are of critical

importance for the acceptance of Snocer tools/solution/concept

Adaptability

1 Snocer Solutions should be adapted in every com-mercially used environment. Snocer servers should be adapted in Unix environ-ments.

Client Installa-bility

1 Client installation should be straightforward and im-plemented by non-experts.

Server Installa-bility

3 Server installation is not required to be straightfor-ward since it will be carried out by experts.

Conformance 1 Snocer should be compliant to standards’ at the maximum degree

Portability

Replaceability 2 Snocer system will replace mainly existing low se-cured customised solutions for information ex-change, providing a standardised approach.

Table 4: The criticality index of the quality characteristics related to Snocer system

Index Meaning 1 Critical quality characteristic 2 Important quality characteristic 3 Less important quality characteristic

Table 5: Index explanation

6.7 Snocer System Evaluation Metrics In order to define a valuable assessment methodology the Snocer concept will formulate a metric definition for each quality characteristic to be constructed. Due to the highly dy-namic nature of Secured VOIP environment, in order to assure quality, it is important to adaptively redefine rating levels to present a true measure of quality. The preliminary rat-ing that is presented is based on experience from similar services by the respective consor-tium partners. These ratings will be fine-tuned after the design and initial tests of the solu-tions. Based on the results, the final QA Plan for the end concept will be defined where also the intervals that the various tests should be contacted will be defined. These metrics will be defined for each partner at a later stage.

- 65 -

6.7.1 Metrics’ Templates In the following table a template for the definition of the metrics is presented. These met-rics are considered as higher level and are calculated using the primitive metrics. Name Name of the metric and any known synonyms

Definition The attributes of the entities that are measured using this metric, how the metric is calculated, and which primitive metrics it is calculated from.

Goals List of goals and questions related to this metric. Also some explanation as to why the metric is being collected.

Analysis procedure How the metric is intended to be used. Preconditions for the interpretation of the metric (e.g., valid range of other metrics). Target values or trends. Models of analysis techniques and tools to be used. Implicit assumptions (e.g., of the envi-ronment or models). Calibration procedures. Storage.

Responsibilities Who will collect and aggregate measurement data, prepare the reports and analyze the data.

Table 6: Metrics’ template definition In this section the primitive metrics that are collected, automatically or manually, to com-pute the metrics are enumerated. In the following table a template for a primitive metric is presented. Name Name of the primitive metric

Definition Unambiguous description of the metric in terms of the project’s environment

Collection procedure Description of the collection procedure. Data collection tool and form to be used. Points in the lifecycle when data are collected. Verification procedure to be used. Where will the data be stored, format, precision.

Responsibilities Who is responsible for collecting the data. For verifying the data.

Table 7. Template for a Primitive Metric

6.7.2 Metrics’ Definition In the following table the major Snocer metrics are defined. It should be emphasised that this approach is according to the current status of project’s development. Metrics’ defini-tion will be reviewed and made more specific after finalisation of the development Name Definition Goals Analysis pro-

cedure1 Responsibilities

Service rat-ing

Definition: Service rating based on statistics of access to the Snocer solutions during predefined periods (typically on a monthly basis). Entities measured: suitability, ac-cessibility Calculation: per ser-vice/section/user Primitives: “TBD” ex.”SL_AccCounters”.

Assess mean and max response time to execute each task

Rate the solutions based on usage/trials

Discover difficulties in the UI

Chart the ac-cess on a monthly basis.

Analysis: QA Manager

Security Assessment

Definition: Security assessment based on analysis of statistics of security auditing of the Snocer

Assess security at-tacks and misuse of system and its re-

Chart the un-successful at-tacks

Analysis: Secu-rity Manager

1 Evaluation of results depends on the phase of the project.

- 66 -

Name Definition Goals Analysis pro-cedure1

Responsibilities

tools during predefined periods (typically on a monthly basis). Entities measured: security, toler-ance, attacs Calculation: per ser-vice/section/user/connection Primitives: “To be defined”

sources Rate the solutions

based on ease of ac-cess (due to security constraints)

Assess usage of sys-tem based on quota consumption

/attempts/ log-ins on an hourly basis. Chart the de-nial of access events on an hourly basis. Chart the quota usage per user and time.

Comments Log Analy-sis

Definition: Normalized number of comments per section per month per 10 site. Entities measured: accuracy, learn-ability, operability, understandabil-ity, maturity, documentation, qual-ity of services Calculation: per ser-vice/section/user Primitives: Comments Log

Assess overall part-ner’s feeling regard-ing solution’s value and quality

Pinpoint areas of poor quality and poor functionality

Charting of negative and positive com-ments per ser-vice, section and quality parameter.

Analysis: QA Manager

Compliance with stan-dards

Definition: Assessment of system's compliance with international standards. Entities measured: compatibility Calculation: Assessment Primitives: None.

Assess compliance with standards

Pinpoint areas of po-tential usage of stan-dards

Qualitative assessment of compliance

Input: All part-ners Analysis: Pro-ject Manager

Table 8: Snocer metrics’ definition

6.7.3 Primitive Metrics’ Definition In the following table the primitive metrics’ are defined Name Definition2 Collection proce-

dure

Responsibilities

SL_AccCounters Count the access and, if possible, the path that the user follows to access each specific service. Data should contain key id. “response_time”

Collection proce-dure will be inte-grated in the Snocer solutions as a dedicated process.

Data collection: System Admin-istrator

SL_NonRecFaults No of System failures (non-recoverable) System Log query Data collection: System Admin-istrator

SL_RecFaults No of Recoverable faults System Log query Data collection: System Admin-istrator

SL_OperData Operation data. Periods that system is in one of the following states: operational, set-up state and out of order.

System Log query Data collection: System Admin-istrator

SL_X_Response Response time for <X> operation. All operations that are critical will be profiled

System Log query Data collection: System Admin-

2 Specific implementation will be updated after conclusion of the Design Phase.

Name Definition2 Collection proce-dure

Responsibilities

using this metric. istrator

SL_ServerInstall Required time for server installation. System Log query Data collection: System Admin-istrator

UF_InfoAccuracy Number of user answers regarding information accuracy. Three levels will be used: Accurate, Non-accurate, No assessment.

User feedback query


UF_EaseOfUse Number of user answers regarding ease of use. Three levels will be used: Easy, Difficult, and Normal.

User feedback query


UF_HelpDeskReq Frequency of help desk requests per item, service and user.

Help desk log query


SC_UNSEVLOG Frequency of not successful login events. Analy-sis per user_id, connection. Time period will be used-specified (e.g. 10 min)

Security event log query

Data collection: Security Ad-ministrator

SC_ACCESDEN Frequency of access denied events due to secu-rity reasons. Analysis per user_id, connection. Time period will be used-specified (e.g. 10 min)



SC_QUOTOVER Frequency of quota-overrun events due to secu-rity reasons. Analysis per user_id, connection. Time period will be used-specified (e.g. 10 min)



HL_OnlineFreq Frequency of on-line help request per item, ser-vice and user.

Counters embed-ded in the On-line help system.


ML_Diagnosis Time to diagnose cause of deficiencies or system failures

Maintenance log query


ML_DeficFix Time to fix deficiencies. Maintenance log query


ML_Stability Number of unexpected side-effects from modifi-cations



ML_TestEffort Effort in person-days needed to validate Snocer system after modifications



Table 9: Primitive metrics’ definition

- 67 -

6.7.4 Assessment Methodology The assessment will be based on the analysis of on-line feedback from partner sites and of a scheduled system log. • On-line feedback. The following types of feedback will be employed:

Smart-mode feedback: where a single multiple-choice question will be presented to the user. Typical example includes questions of the type "Did the information provided help you?" with possible answers "Yes/No". This mode will be primarily used in the deployment phase of the project.

Questionnaire-mode feedback: where a full questionnaire is presented to the user. This mode will be primarily used in the validation phase of the project. Emphasis will be put on suggestions for improving the services and motivate the users to express what they like or dislike. Multiple-choice answers will be presented for each question in order to guide the user in expressing his point of view. Free text forms will be available as well.

Crosschecking questionnaires: addressed to sampled users via e-mail. The main role is to monitor and test the satisfaction and perception of system’s quality.

Feedback through Snocer help desk: A dedicated help desk for Snocer sites will be established to support the Snocer system, facilitate gathering of users' comments, problems and questions and provide a means of communication between the de-velopers and the end-users. The help desk will be implemented as an Internet newsgroup.

• Log Analysis. For all the critical modules and services, logs will be maintained in order to provide the data to analyse.

6.7.5 Privacy As a general note, evaluation information will also be requested from the user. In any case the users will be alerted of the collection, dissemination and use of their informa-tion. The purpose of gathering the information will be described in detail and presented to the user.

- 68 -

6.8 Snocer Virtual Collaborative Test beds The defined Snocer testing models as predicted by the patners, will be a set of semiau-tonomous or autonomous testing environments co-ordinated by Voztelecom, the test beds as defined will allow both local as well as multiple interactions between the set up sites. The complex / intimate many-to-many concurrent interactions as the figure illustrates even if the test are done locally, has the purpose of evaluate the solutions and tolls to its fully extent giving the Snocer solutions its highest availability credentials towards a mar-ket route. The Snocer Virtual collaborative model supports discrete, short term activities between the partner teams working across enterprise boundaries —for example, collaborating on individual activities or participating in isolated processes. The Snocer team will hold a persistent state of their platform, providing partial/fully visibility to others. The selected scenario is a typical example of virtual enterprise integration, only that in this case the enterprise in not a single legal entity but rather several defined legal entities, cooperating towards the same goal. The Snocer Virtual Collaborative model also presents the diffi-culty of common co-existence and co-operation and competition – but the Snocer group will certainly achieve more as a group than the participants could do individually

Snocer Partners

VAR

VOZT

Aegea

NextS

Fokus SUBC

Telip

EMB

6.9 Trade mark of the Snocer Collaborative Model. The Snocer Collaborative model as distinguished from more ‘traditional’ ways of inter-organisational collaboration (e.g. joint ventures, strategic alliances, R&D consortiums, outsourcing) emphasises on equal positions of partners and trust (low control), organisa-

- 69 -

tional flexibility (changing participants), pooling of resources, and the use of electronic communication (geographical dispersion). Allowing the partners to define the;

− Local, intimate concurrent interactions

− Discrete, Short and long Term Activities between involved teams across enterprise bounda-ries

− − Shared knowledge, between defined test trials, evaluation, feedback, etc.

But above all a High level of trust since main goal is towards a common Cooperative markets −

haring and benefiting on all levels of integration. S

Inward FocusedCore

Customers

Suppliers

Distributors

Partners

SNOCER

Development

R&D& Engineering

ProcurementDistribution

Supply ChainLogistics

MarketingAdvertising

SalesCustomer Care

Finance &Management

6.10 Test Bed scenario The intention will be to locally test the core Snocer tools and functionalities as well as the concepts proven and developed during the project, but certain extensions such as support-ing company specific interfaces, providing local language support, integrating the results in the platforms and products of the involved partners will be defined by each specific rganisation and tested to its full functionality in a real life scenario. o

- 70 -

Sweden

Snocer implementation platformCorporate

Users

France

Corporate

Users

Common Snocer Platform

Spain

Corporate

Users

Czech

VoztelecomLocation IP Architecture Tools/service

Lab Simulated Trials Envi

Testing

Solutions

Focus

Aegean

Figure 50: Virtual Testbed

- 71 -

7 Summary In this document we have defined a general secure and highly available VoIP architec-ture. We achieve reliability through the proposal of failover mechanisms of the entities in a VoIP network. The security architecture is based on a threat analysis on current VoIP solutions based on the SIP VoIP standard. Attacks can target the SIP proxy through special crafted mes-sages, the DNS subsystem or the Database system through special SQL statements. The proposed architecture utilizes standard open source tools like the Snort IDS system, SER SIP proxy or the iptables firewall as a basis to enhance security. Additionally, exten-sions are proposed that implement countermeasures to the identified attacks. The archi-tecture can be configured through a proposed configuration language and tested with a dedicated attack tool. The attack tool can be utilized in accordance to a quality assurance plan to ensure the correct operation of the tools. Following the general specification of the VoIP infrastructure we will define the architec-ture in full detail, including interface definition and use cases.

- 72 -

8 References [1] Sisalem D., Ehlert S., Geneiatakis D., Kambourakis G., Dagiuklas T., Markl J.,Rokos M.,

Botron O.,Rodriguez J., Liu J., Towards a Secure and Reliable VoIP, http://www.snocer.org, May 2005

[2] Rosenberg J., Schulzrinne H., Camarillo G., Johnston A., Peterson J., Spark R., Handley M., Schooler E., “Session Initiation Protocol”, RFC 3261, June 2002.

[3] Sparks R., The Session Initiation Protocol (SIP) Refer Method, RFC 3515, April 2003

[4] Sparks R., The Session Initiation Protocol (SIP) Referred-By Mechanism, RFC 3892, Sep-tember 2004

[5] Rosenberg J., The Session Initiation Protocol (SIP) UPDATE Method, RFC 3311, Septem-ber 2002

[6] Vemuri A., Peterson J., Session Initiation Protocol for Telephones (SIP-T): Context and Architectures, RFC 3372 September 2002

[7] Donovan S., The SIP INFO Method, RFC 2976, October 2000

[8] Peterson, J., Enhancements for authenticated identity management in the session initiation protocol , Internet-Draft, February 2003

[9] Donovan S. , “The SIP INFO Method”, RFC 2976, October 2000.

[10] Rosenberg J., “The Session Initiation Protocol (SIP) UPDATE Method”, RFC 3311, Sep-tember 2002.

[11] Spark R., “The Session Initiation Protocol (SIP) Refer Method”, RFC 3515, April 2003.

[12] Wieser C, Laakso M, Schulzrinne H , “Security testing of SIP implementations”, http://compose.labri.fr/documentation/sip/Documentation/Papers/Security/Papers/462.pdf, 2003

[13] Scott D. and Sharp R., “Abstracting Application-Level Web Security,” Proc. 11th Int’l World Wide Web Conf., ACM Press, New York, May 2002, pp. 396-407

[14] Dharmapurikar S., Krishnamurthy P., Sproull T., and Lockwood J., “Deep Packet Inspec-tion Using Parallel Bloom Filters.” In Proceedings 11th Symposium of High Performance Interconnects (HOTI’03), pages 44-71, 2003.

[15] Srisuresh P., Kuthan J., Rosenberg J., Molitor A. and Rayan A: “Middlebox Communica-tion Architecture and framework”, IETF, RFC 3303, August 2002.

[16] MIT ARES library, ftp://athena-dist.mit.edu/pub/ATHENA/ares

[17] Netfilter / Iptables Web Page, http://www.netfilter.org/

[18] SER Web Page, http://www.iptel.org/ser

[19] Rebahi Y., Sisalem, D., Kuthan, J., Pelinescu-Oncicul, A., Iancu, B., Janak, J., Mierla, D.C.: The SIP Express Router – An Open Source SIP Platform, Evolute Workshop 2003, Guildford, UK

[20] Snort rules database, http://www.snort.org/snort-db/

[21] Tcpdump / libpcap Project Web Page, http://www.tcpdump.org/

- 73 -

http://www.snocer.org/

ftp://athena-dist.mit.edu/pub/ATHENA/ares

http://www.netfilter.org/

http://www.iptel.org/ser

http://www.snort.org/snort-db/

http://www.tcpdump.org/

[22] IETF Intrusion Detection Exchange Format Working Group, http://www.ietf.org/html.charters/idwg-charter.html

[23] Rosenbberg, J., Schulzrinne, H., “Session Initiation Protocol (SIP): Locating SIP Servers”, RFC 3263, Sep. 2002

[24] SiVus, http://www.vopsecurity.org/html/sivus.html

[25] SIPFoundry SIP Forum Test Framework, http://www.sipfoundry.org/sftf/index.html

[26] http://sipsak.org/

[27] Mirkovic, A., Dietrich, S., Dittrich, D., and Reiher, P.: Internet Denial of Service – Attack and Defense Mechanisms, Prentice Hall Professional Technical Reference, Dec. 2004

[28] SnortSam Web Page – http://www.snortsam.net

[29] Ferguson, P., Senie, D., “Network Ingress Filtering”, RFC 2827

[30] http://sipp.sourceforge.net/

[31] Ranganathan, M., Deruelle, O., Montgomery, D., “Testing SIP Call Flows Using XML Templates, presented at TestCom 2003, Sophia Antipolis, May 2003, http://www-x.antd.nist.gov/proj/iptel/

[32] Network Mapper Web Page, http://www.insecure.org/nmap/

[33] http://www.trolltech.com/

[34] Prelude Web Page, http://prelude-ids.org

[35] http://www.ee.oulu.fi/research/ouspg/protos

[36] http://www.ee.oulu.fi/research/ouspg/protos/testing/c07/sip/index.html

[37] J.A. McCall, P.K. Richards, and G.F. Walters, Factors in Software Quality, Vol. 1,2 and 3, AD/A-049-014/015/055, Nat’l Tech. Information Service, Springfield, Va., 1977.

[38] ISO 9126: “Information technology - Software product evaluation - Quality characteristics and guidelines for their use”, International Standard Organisation (ISO) and the Interna-tional Electrotechnical Commission (IEC), Geneve, Switzerland, 1991.

[39] ISO 9241: “Ergonomic requirements for office work with visual display terminals (VDTs), International Standard Organisation, Geneve, Switzerland, 1996.

[40] IEEE Standards Collections: “Software Engineering”, IEEE, New York, USA, 1995.

[41] ISO/DIS 10006: “Quality management - Guidelines to quality in project management, International Stan-dard Organisation, Geneve, Switzerland, 06-06-1996.

- 74 -

http://www.ietf.org/html.charters/idwg-charter.html

http://www.sipp.org/

http://www.insecure.org/nmap/

http://prelude-ids.org/

http://www.ee.oulu.fi/research/ouspg/protos

http://www.ee.oulu.fi/research/ouspg/protos/testing/c07/sip/index.html

A SIP Attack Detection / Prevention Architecture

Documents

Transcript of A SIP Attack Detection / Prevention Architecture