II RELATED WORK
The reliable performance of SIP server is critical
under DoS attacks. There has been previous effort to protect VOIP deployments
from DoS threats. An early evaluation of firewalls for VOIP security
was proposed, but it lacked concrete architectural
and implementation aspects. A mitigation strategy for flooding DoS attacks on
media components using a dynamic pinhole filtering device that blocks all
traffic not associated with a legitimate call was previously developed as part
of an earlier phase of this research.
Wu, Y. et al. and Niccolini, S. et al. have applied
intrusion detection and prevention mechanisms to safeguard the SIP
infrastructure, while the work makes use of finite state machines to
achieve similar goals. An interesting approach
involving VOIP “honeypots” was proposed.
Extensive work on detecting DoS attacks on IP
telephony environments has been published. Although promising, none of the
architectures and algorithms proposed so far offer a comprehensive DoS
mitigation strategy that scales up to the performance needs and complexity of
carrier-class VoIP deployments, because they are based on software solutions.
B. Bencsath et al. have empirically evaluated the
SMTP servers against DoS attacks. An important work is reported, which the
authors conceptually discussed the impact of different types of attacks on VOIP
infrastructure. They have conceptually identified exploitable server resources,
such as memory, CPU usage and bandwidth and
presented abstract guidelines to ensure SIP servers’
robustness under different attack scenarios. But
they paid no attention to empirically analyze the performance hit of SIP
servers under attack.
S. McGann et al. summarize the features of vulnerability
analysis tools available for VOIP and suggest using a Virtual Private Network
(VPN) solution to circumvent attacks on a SIP server. The authors did not
discuss how their scheme is resilient against DoS attacks
E. Nahum et al. have experimentally evaluated the
SIP proxy (OpenSER), using micro-benchmarks,and analyzed the performance of
OpenSER as a function of selecting different
configuration modes of the server. They have also
ignored robustness analysis of SIP servers against different types of DoS
III BASIC RESOURCES
The majority of DoS attacks are based on exhausting
some of a server’s resources and causing
the server not to operate properly due to lack of
resources. With SIP servers, there are three resources needed for operation:
memory, CPU and bandwidth.
A SIP server needs to copy each incoming request in
its internal buffers to be able to process the message. The amount of buffered
data and the time period the server is supposed to keep the buffered data
varies depending on whether the server is working in a stateful or stateless
mode. The size of a SIP message might range from a few hundreds of bytes up to
a few thousands.
After receiving a SIP message, the SIP server needs
to parse the message, do some processing (e.g., authentication), and perform
transaction mapping and forward the message. Depending on the content and type
of the message and server policies, the actual amount of CPU resources might
vary. Whereas the CPU capacity of a well engineered and configured proxy should
be able to process SIP messages up to link capacity, there are many server
operations that make servers block.
This involves overloading the access links
connecting a SIP server to the Internet to such a level
as to cause congestion losses. By overloading the
server’s access links, one could cause the loss of SIP
messages which causes longer session setup times or
even the failure of session setups.
ATTACKS AND COUNTER MEASURES
A) Memory Based Attacks:
State maintenance in SIP servers
is one of easier targets for DoS attacks. Measurements indicate that a stateful
server flooded with a continuous stream of requests belonging to different
transactions will run out of memory very quickly. Basic attacks are:
Brute force attacks: The simplest method for
mounting an attack on the memory of a SIP server is to initiate a large number
of SIP sessions with different session identities.
Broken sessions: With brute force attacks, memory
is only consumed for the duration of a transaction and is released afterwards.
To intensify the effects of memory usage, the attackers might infer only parts
of a session.
Monitoring and filtering: Similar to Web and mail
servers, SIP proxies need to maintain lists of suspicious users and deny those
users from establishing sessions. These lists can be established by monitoring
the transactions served by the proxy and logging user behavior.
Authentication: In general, verifying the identity
of a user before forwarding his/her messages would prevent malicious behavior
as the user would be easily traceable. Naturally, this is only true if it is
not possible for an attacker to presume the identity of a valid user.
Like HTTP, SIP uses digest authentication, which
requires state maintenance at the server by storing the issued challenge. This
can be misused for a broken session attack, if attackers ignore or falsely
respond to authentication requests and start another session instead. A
solution to this problem is usage of predictive
nonces that allow for stateless authentication
and introduce limited message
integrity. The construct is based on nonces being
calculated in a way that makes them valid only for validated messages within a
time window. When a challenge-response pair arrives at a server, the nonce is
first verified to be correct, followed by the verification of the response.
This method works without any changes to the protocol.
B) CPU Attacks:
Besides the processing power
needed for parsing incoming SIP messages, CPU resources are required for the
Checks — For verifying the identity of a user, a SIP server needs to
generate a nonce and then check the credentials of the user. This checking uses
hashing schemes such as MD5, which require a low calculation overhead.
with External Servers — As
already indicated a SIP proxy might need to contact an external server to
fetch some information or realize a service. This not only consumes processing
time but also can cause the server to block and reject new incoming messages
while the SIP proxy is awaiting an answer from the contacted server.
Execution — A SIP server might need to execute a certain application (i.e., a CPL or CGI
script or some other kind of application) after receiving a request. The amount
of CPU resources used depends on the application type and its complexity. If
the application server is located on the same hardware platform as the SIP
server, the CPU resources used for execution of the applications is no longer
available for processing SIP messages.
If the application server is located on a different
hardware platform, some form of remote communication between the SIP server and
the application server is needed. Thus, attacks on the application server result
in blocking the SIP server after requesting the execution of an application
until the application server generates a reply.
Server design: The first line of defense against
any DoS attacks is achieved by using well dimensioned hardware with fast CPUs,
and large memory and high-speed network connection. Additionally, the software
itself needs to be designed with security, speed, and attack possibility in
mind. This implies deploying some or all of the following server design options:
(1) Clean and efficient implementation:
Implementers need especially to use efficient and fast memory allocation
schemes, event handling, and parsing mechanisms.
processing: In order to avoid blocking incoming messages while the server is
busy processing a message or while waiting for an answer from an external
server (e.g., AAA) a SIP proxy should be implemented using threads or parallel
processes with each process or thread responsible for processing one message at
Message Parsing Attacks:
In order to figure out how to
handle an incoming message, the server needs to parse at least part of the
message and check its consistency. However, due to the free text format of the
SIP protocol even a perfectly valid SIP message can be constructed in a way to
hamper proper parsing. Here we give a list of possibilities how to complicate
attacker can create unnecessary long messages in a simple way by adding
additional headers (like informative header fields, e.g., Supported) in
conjunction with a large message body. Many SIP messages may include bodies,
even when they are not needed in every message. Instead of only depleting
processor power, longer message
also increase network utilization and memory usage.
implementations can be rendered inoperable by including message bodies of a
size that does not match that indicated in the Content-Length header.
the SIP standard mandates that headers that have multiple values can be
separated into individual header fields so 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 will further complicate
One way to accomplish this is by inserting multiple
informative header fields, e.g. Allow or Supported, before the routing fields.
SIP as defined in RFC 3261 is a refined version of the previous standard as
defined in RFC 2543. Some of the newer design decisions are made to simplify
certain operations. However, any RFC 3261 compliant SIP element must be able to
handle RFC 2543 messages, which can complicate processing. As such, this can be
used by an attacker. Among these modifications are:
fields contain a
branch parameter. If this branch parameter does not
start with the magic cookie “z9hGbK,” the message
is considered to be pre-RFC 3261. This would
indicate a fallback to the more complex RFC 2581 message handling routine.
tag field: Messages
with a To and From header field, but
without a tag field, need to be checked by the UAS against all ongoing
transactions, thus requiring more processing overhead. Parsing attacks can be
countered by an efficient implementation (e.g., by parsing only those parts
needed for its correct functioning).
VOIP has become a popular solution for
voice communication in enterprises of different
VOIP deployment still faces great challenges
regarding malicious attacks, Dos attacks and
numerous countermeasures to migrate these attacks
in existing implementation and future development.
The specific problem like Denial of Service (DoS)
and Service Abuse
are major vulnerabilities
considered during implementation of VOIP systems
in enterprise. Based on the challenges and
on VOIP in this paper, we specified different kinds
attack scenarios and their counter measures.
Technology to handle attacks aiming at specific VOIP
protocols such as SIP protocol is implemented.
Session initiation protocol is used for
possibilities of launching denial of service
SIP servers and proposes preventing ways which
reduce the effects of such attacks.