Question

1- Perform research on the Web and find how Cisco routers and switches can protect against DDOS. Give a specific example of a Cisco device model. Show the Cisco CLI commands that are used for this purpose

2- The Session Initiation Protocol (SIP) is an important protocol used in Voice over IP phones over the net. Give ONE detailed example of a security attack type of SIP. Explain how we can prevent or mitigate this specific type of attack.

Can anyone please help me out with these questions? Also, please be as detailed as possible, and also provide the source of information (website links). Thank you.

Answer 1

I have done all the research as per your request. Please comment if anything needed.

1. DDoS attacks have become a "Swiss army knife" for hacktivists, cyber criminals, and cyber terrorists, and in some cases used in nation-state attacks.

These attackers and their campaigns are becoming sophisticated. Attackers are using evasion techniques outside of the typical volume-based attacks to avoid detection and mitigation, including "low and slow" attack techniques and SSL-based attacks. They are deploying multivulnerability attack campaigns that target every layer of the victim's infrastructure, including the network infrastructure devices, firewalls, servers, and applications.

There are three different general categories of DDoS attacks:

• Volume-based DDoS attacks
• Application DDoS attacks
• Low-rate DoS (LDoS) attacks

Volume-Based DDoS Attacks

In volume-based (or volumetric) DDoS attacks, the attackers typically flood the victim with a high volume of packets or connections, overwhelming networking equipment, servers, or bandwidth resources. These are the most typical DDoS attacks. In the past, volumetric attacks were carried out by numerous compromised systems that were part of a botnet; now hacktivists not only use conventional attack methodologies, but also recruit volunteers to launch these attacks from their own machines. In addition, new waves of huge volumetric attacks are now launched from datacenters of cloud service providers, when attackers either rent or compromise cloud-based systems that have tremendous Internet bandwidth.

A botnet is a gang of Internet-connected compromised systems that could be used to send spam email messages, participate in DDoS attacks, or perform other illegitimate tasks. The word botnet comes from the words robot and network. The compromised systems are often called zombies. Zombies can be compromised by tricking users into making a "drive-by" download, exploiting web browser vulnerabilities, or convincing the user to run other malware such as a trojan horse program. Figure 2 shows an example of a typical botnet.

In this example, an attacker controls the zombies to launch a DDoS attack against the victim's infrastructure. These zombies run a covert channel to communicate with the command-and-control server that the attacker controls. This communication often takes place over Internet Relay Chat (IRC), encrypted channels, bot-specific peer-to-peer networks, and even Twitter.

With the advent of cloud services and providers, a new trend has emerged. Attackers are either renting or compromising large datacenter/cloud machines to launch DDoS attacks. Cloud computing is not only creating new opportunities for legitimate organizations; it's also providing a great platform for cyber criminals because it inexpensively and conveniently allows them to use powerful computing resources to do bad things. This concept is illustrated in Figure 3.

Application DDoS Flood Attacks

Application DDoS attacks can target many different applications; however, the most common target HTTP aiming to exhaust Web servers and services. Some of these attacks are characteristically more effective than others because they require fewer network connections to achieve their goal. For instance, an attacker could launch numerous HTTP GETs or POSTS to exhaust a web server or web application.

On the other hand, other applications such as Voice over IP (VoIP), DNS, and others are often targeted. Examples of these attacks are covered later in this paper.

Low-Rate DoS Attacks

Low-rate DoS (LDoS) attacks often take advantage of application implementation weaknesses and design flaws. A prime example of these types of attacks is Slowloris, a tool that allows an attacker to take down a victim's web server with minimal bandwidth requirements and without launching numerous connections at the same time. Slowloris will be covered in detail later in this paper.

Modern Technique in Defending Against DDoS Attacks

Challenges in Defending DDoS Attacks

The challenge in preventing DDoS attacks lies in the nature of the traffic and the nature of the "attack" because most often the traffic is legitimate as defined by protocol. Therefore, there is not a straightforward approach or method to filter or block the offending traffic. Furthermore, the difference between volumetric and application-level attack traffic must also be understood.

Volumetric attacks use an increased attack footprint that seeks to overwhelm the target. This traffic can be application specific, but it is most often simply random traffic sent at a high intensity to over-utilize the target's available resources. Volumetric attacks generally use botnets to amplify the attack footprint. Additional examples of volumetric attacks are DNS amplification attacks and SYN floods.

Application-level attacks exploit specific applications or services on the targeted system. They typically bombard a protocol and port a specific service uses to render the service useless. Most often, these attacks target common services and ports, such as HTTP (TCP port 80) or DNS (TCP/UDP port 53). For further details about mitigating application-level attacks, see Identifying and Mitigating the Distributed Denial of Service Attacks Targeting Financial Institutions.

Stateful Devices

Stateful devices do not provide complete coverage and mitigation for DDoS attacks because of their ability to monitor connection states and maintain a state table. Maintaining such information is CPU and memory intensive. When bombarded with an influx of traffic, the stateful device spends most, if not all, of its resources tracking states and further connection-oriented details. This effort often causes the stateful device to be the "choke point" or succumb to the attack.

For further information about stateful inspection, see the Stateful Inspection Overview section of the Cisco ASA 5500 Series Configuration Guide. Common stateful inspection devices and their role in threat mitigation are firewalls, IDS/IPS devices, load balancers, and web application firewalls.

Firewalls represent the most common stateful inspection devices in today's threat mitigation arsenal. In stateful firewall solutions, there is a component commonly known as the stateful packet inspection (SPI) engine. This is also referred to as DPI (deep packet inspection). This engine provides intelligence by looking into the packet flow to determine and define connection information and application-level details. For more details about firewall stateful inspection, see the Cisco IOS Software Stateful Packet Inspection section of the Cisco IOS Firewall Design Guide.

IDS/IPS devices are often deployed at the network core and/or edge and provide intelligent decision capabilities by using DPI to analyze and mitigate an array of attacks and threats. Moreover, DPI allows the IDS/IPS device to react to network events and traffic in real time, providing alerts or inline mitigation. For more details about IDS/IPS stateful inspection, see Cisco IOS Intrusion Prevention System.

Load balancers use SPI to make decisions based on the connections that traverse the load balancer function. For more details about the load balancer stateful inspection engine, see Is Your Load Balancer A Firewall?

Web application firewalls use SPI to evaluate web-based application flows, such as GET requests. For details about SPI in web application firewalls, see the Web Application Firewall page documented by the Open Web Application Security Project (OWASP).

Route Filtering Techniques

Remotely triggered black hole (RTBH) filtering can drop undesirable traffic before it enters a protected network. Network black holes are places where traffic is forwarded and dropped. When an attack has been detected, black holing can be used to drop all attack traffic at the network edge based on either destination or source IP address. For further information regarding RTBH filtering, see the Remotely Triggered Black Hole Filtering -- Destination Based and Source Based (PDF).

Note: RTBH filtering is supported on Cisco IOS, Cisco IOS-XE, and Cisco IOS-XR platforms. For more details, including using RTBH filtering for IPv6, see Remotely Triggered Black Hole Filtering in IP Version 6 for Cisco IOS, Cisco IOS XE, and Cisco IOS XR Software.

Unicast Reverse Path Forwarding

Network administrators can use Unicast Reverse Path Forwarding (uRPF) to help limit malicious traffic flows occurring on a network, as is often the case with DDoS attacks. This security feature works by enabling a router to verify the "reachability" of the source address in packets being forwarded. This capability can limit the appearance of spoofed addresses on a network. If the source IP address is not valid, the packet is discarded.

uRPF guards against IP spoofing by ensuring that all packets have a source IP address that matches the correct source interface according to the routing table. Normally, the security appliance examines only the destination address when determining where to forward the packet. uRPF instructs the security appliance to look also at the source address. For any traffic to be allowed through the security appliance, the security appliance routing table must include a route back to the source address. See RFC 2267 for more information.

To enable uRPF, enter this command: hostname(config)#ip verify reverse-path interface interface_name

uRPF works in two different modes: strict mode and loose mode. When administrators use uRPF in strict mode, the packet must be received on the interface that the security device would use to forward the return packet. uRPF in strict mode may drop legitimate traffic that is received on an interface that was not the firewall's choice for sending return traffic. Dropping this legitimate traffic could occur when asymmetric routing paths exist in the network.

When administrators use uRPF in loose mode, the source address must appear in the routing table. Administrators can change this behavior using the allow-default option, which allows the use of the default route in the source verification process. In addition, a packet that contains a source address for which the return route points to the Null 0 interface will be dropped. An access list may also be specified that permits or denies certain source addresses in uRPF loose mode.
Care must be taken to ensure that the appropriate uRPF mode (loose or strict) is configured during the deployment of this feature because it can drop legitimate traffic. Although asymmetric traffic flows may be a concern when deploying this feature, uRPF loose mode is a scalable option for networks that contain asymmetric routing paths.

Geographic Dispersion (Global Resources Anycast)

A newer solution for mitigating DDoS attacks dilutes attack effects by distributing the footprint of DDoS attacks so that the target(s) are not individually saturated by the volume of attack traffic. This solution uses a routing concept known as Anycast. Anycast is a routing methodology that allows traffic from a source to be routed to various nodes (representing the same destination address) via the nearest hop/node in a group of potential transit points. This solution effectively provides "geographic dispersion." For details regarding geographic dispersion that uses Anycast to dilute a DDoS attack, see How whitehats stopped the DDoS attack that knocked Spamhaus offline.

Tightening Connection Limits and Timeouts

Antispoofing measures such as limiting connections and enforcing timeouts in a network environment seek to ensure that DDoS attacks are not launched or spread from inside the network either intentionally or unintentionally. Administrators are advised to leverage these solutions to enable antispoofing and thwart random DDoS attacks on the inside "zones" or internal network. To use connection limits and timeouts for DDoS defense purposes, see the Configuring Connection Limits and Timeouts section of the Cisco ASA 5500 Series Configuration Guide.

Caution: Oversubscription of stateful processes can cause a device to fail. For more details, see Stateful Devices.

Reputation-Based Blocking

Reputation-based blocking has become an essential component to today's web filtering arsenal. A common trend of malware, botnet activity, and other web-based threats is to provide a URL that users must visit for a compromise to occur. Most often such techniques as spam, viruses, and phishing attacks direct users to the malicious URL.

Reputation-based technology provides URL analysis and establishes a reputation for each URL. Reputation technology has two aspects. The intelligence aspect couples world-wide threat telemetry, intelligence engineers, and analytics/modeling. The decision aspect focuses on the trustworthiness of a URL. Reputation-based blocking limits the impact of untrustworthy URLs. For details about web reputation technology, see Cisco Web Reputation Technology. An example of reputation-based solutions is the Cisco Web Security Appliance and Cisco Email Security Appliance.

Global and crowd-sourced reputation information provides the most coverage in web reputation technology, and administrators may question which reputation engine or service to use and whether one is enough. The recommendation is to use multiple engines or services, such as the following:

• WatchGuard Reputation Authority
• WebSEO Analytics

Moreover, web reputation solutions with high coverage include Cisco Web Security Appliance, Imperva, Trend Micro, and others.

Another evolution is on the horizon for web reputation. Beyond the traditional attack, there is a continuous threat to the brand and business reputation. Many tools and services are available for organizations to protect manage their reputations. See References for more details regarding the available tools.

Access Control Lists

ACLs provide a flexible option to a variety of security threats and exploits, including DDoS. ACLs provide day zero or reactive mitigation for DDoS attacks, as well as a first-level mitigation for application-level attacks. An ACL is an ordered set of rules that filter traffic. Each rule specifies a set of conditions that a packet must satisfy to match the rule. Firewalls, routers, and even switches support ACLs. When the device determines that an ACL applies to a packet, it tests the packet against the conditions of all rules. The first match determines whether the packet is permitted or denied. If there is no match, the switch applies the applicable default rule (generally an implicit "deny all"). The device continues processing packets that are permitted and drops packets that are denied.

Note: Switches support port and VLAN ACLs.

ACLs are often used to protect networks and specific hosts from unnecessary or unwanted traffic via protocol/port filtering, although filtering may also be based on TCP options and flags. For example, ACLs can disallow HTTP traffic from a high-security network to the Internet. You could also use ACLs to allow HTTP traffic only to specific sites, using the IP address of the site to identify it in an IP ACL.

ACL filtering provides flexible mitigation options. The following list provides additional examples of the available filtering options:

• Layer 4 protocol
• TCP and UDP ports
• ICMP types and codes
• IGMP types
• Precedence level
• Differentiated Services Code Point (DSCP) value
• TCP packets with the ACK, FIN, PSH, RST, SYN, or URG bit set
• Established TCP connections

The following resources provide more details about ACL configuration and management:

• Configuring Commonly Used IP ACLs
• Configuring IP Access Lists
• Cisco Nexus 5500 Series NX-OS Software Configuration Guide - Configuring ACLs

DDoS Run Books

Early in 2013, the concept of DDoS run books gained a bit of prevalence. The premise behind a DDoS run book is simply to provide a "playbook" for an organization in the event that a DDoS attack arises. In essence, the run book provides crisis management (better known as an incident response plan) in the event of a DDoS attack. The run book provides details about who owns which aspects of the network environment, which rules or regulations must still be adhered to, and when to activate/instrument certain process, solutions, and mitigation plans. A case study and an example template for DDoS run books are in References.

Manual Responses to DDoS Attacks

It is worth nothing that manual responses to DDoS attacks focus on measures and solutions that are based on details administrators discover about the attack. For example, when an attack such as an HTTP GET/POST flood occurs, given the information known, an organization can create an ACL to filtering known bad actors or bad IPs and domains. When an attack such as Slowloris arises, administrators can configure or tune firewalls or load balancers to limit connection attempts, as discussed in Tightening Connection Limits and Timeouts. Manual responses also include obscuring IP addressing schemes, using Network Address Translation (NAT), and creating custom IPS signatures or application layer inspection policies based on attack traffic, baselines, and industry events.

The response process is often overlooked. As mentioned in DDoS Run Books, organizations often do not have a process or a plan and thus rely exclusively on manual responses. Proactive solutions and constant monitoring and configuration updates should be the common practice, with manual responses regarded as rare solutions.

Traffic Scrubbing and Diversion

Because of the prevalence of DDoS attacks in recent years, numerous organizations and businesses now provide DDoS protection as a service. While there are various ways to accomplish DDoS protection and attack mitigation, most providers offer an inline solution in which an organization's traffic can be sent to or through the service entity. The service then filters out the offending traffic and reinjects the good traffic into the organization. A few of the most prevalent in the industry are in the following list:

• Prolexic Technologies: DoS and DDoS Protection
• AT&T Internet Protect: Distributed Denial of Service Defense
• Verizon: DoS Defense Services
• Arbor Networks: Pravail Availability Protection System (APS)

At its core, the Prolexic DDoS Solution uses Prolexic's PLX routed platform service (the most basic Prolexic DDoS mitigation solution). In general it allows a customer to route traffic to the Prolexic environment where it will be inspected and filtered based on anomalies, known misbehaviors, and provided details. Subsequently the "clean" traffic will be routed back into the customer environment. For more details regarding the PLXrouted solution, see the PLXrouted datasheet (PDF). For more details regarding Prolexic solutions, see their DDoS mitigation service portal.

The AT&T Internet Protect: Distributed Denial of Service Defense solution is for AT&T customers looking for DDoS protection. Because AT&T already runs the network that the customer's traffic is traversing, AT&T uses its expertise and intelligent solutions in the backbone to filter any malicious or ill-advised traffic before it enters the customer environment. In addition, the defense solution analyzes netflow. If any flows pose a threat, they are routed to a "scrubbing environment" where the traffic is filtered, allowing the remaining "good" traffic to continue to the customer environment. For more details about the AT&T Internet Protect - Distributed Denial of Service Defense solution, see AT&T Internet Protect - Distributed Denial of Service Defense Solution Product Brief (PDF).

The Verizon DoS Defense Service works much like those previously discussed in that it monitors traffic and routes traffic through the Verizon environment to be scrubbed, allowing the good traffic to be routed back to the protected customer environment. For details, including Service Level Agreement (SLA) information, see the Verizon DoS Defense page.

The Arbor Networks Pravail Availability Protection System (APS) solution is an example of an onsite (on premise) solution. The unit sits inline in a customer environment and has a connection back to the Arbor intelligence backend. This service incorporates intelligence and information learned from the Arbor Security Engineering and Response Team (ASERT). Coupled with techniques such as baselining and anomaly detection, Arbor APS is a prominent DDoS solution. See the Pravail Availability Protection System solution page.

Example

Cisco Unified Wireless IP Phone 7921G

The Cisco Unified Wireless IP Phone 7921G is an IEEE 802.11a/b/g wireless IP phone that provides voice communications. The wireless LAN must be validated to ensure it meets the requirements to deploy the Cisco Unified Wireless IP Phone 7921G.

The cell edge should be designed to -67 dBm where there is a 20-30% overlap of adjacent access points at that signal level.This ensures that the Cisco Unified Wireless IP Phone 7921G always has adequate signal and can hold a signal long enough in order to roam seamlessly where signal based triggers are utilized vs.packet loss triggers. Also need to ensure that the upstream signal from the Cisco Unified Wireless IPPhone 7921G meets the access point’s receiver sensitivity for the transmitted data rate. Rule of thumb is to ensure that the received signal at the access point is -67 dBm or higher.It is recommended to design the cell size to ensure that the Cisco Unified Wireless IP Phone 7921Gcan hold a signal for at least 5seconds

Supported voice and wireless LAN protocols include the following:

•CCX v4

•Wi-Fi MultiMedia (WMM)

•Unscheduled Auto Power Save Delivery (U-APSD)

•Traffic Specification (TSPEC)

•Traffic Classification (TCLAS)

•Skinny Call Control Protocol (SCCP)

•Real Time Protocol (RTP)•G.711, G.722, G.729, iLBC

•Real Time Control Protocol (RTCP)

•Cisco Discovery Protocol (CDP)

•Syslog

CLI Commands

sast1 trustpoint

To specify the name of the SAST1 trustpoint, use the sast1 trustpoint command in CTL-client configuration mode. To return to the default, use the no form of this command.

sast1 trustpoint label

no sast1

Syntax Description

label

Name of the SAST1 trustpoint.

Command Default

No SAST1 trustpoint name is specified

Command Modes

CTL-client configuration (config-ctl-client)

Command History

Cisco IOS Release	Cisco Product	Modification
12.4(4)XC	Cisco Unified CME 4.0	This command was introduced.
12.4(9)T	Cisco Unified CME 4.0	This command was integrated into Cisco IOS Release 12.4(9)T.

Usage Guidelines

This command is used with Cisco Unified CME phone authentication.

The sast1 trustpoint and sast2 trustpoint commands are used to set up the System Administrator Security Token (SAST) credentials, which are used to sign the CTL file. The SAST1 and SAST2 certificates must be different from each other, but to conserve memory either one of them can use the same certificate as Cisco Unified CME. The CTL file is always signed by SAST1 credentials. The SAST2 credentials are included in the CTL file so that if the SAST1 certificate is compromised, the CTL file can be signed by SAST2 to prevent the phones from being reset to their factory defaults.

Examples

The following example names sast1tp as the SAST1 trustpoint.

Router(config)# ctl-client
Router(config-ctl-client)# server capf 10.2.2.2 trustpoint capftrust
Router(config-ctl-client)# server cme 10.2.2.3 trustpoint cmetp
Router(config-ctl-client)# server tftp 10.2.2.4 trustpoint tftptp
Router(config-ctl-client)# sast1 trustpoint sast1tp
Router(config-ctl-client)# sast2 trustpoint sast2tp
Router(config-ctl-client)# regenerate
 

Related Commands

Command	Description
sast2 trustpoint	Specifies the name of the SAST2 trustpoint.

sast2 trustpoint

To specify the name of the SAST2 trustpoint, use the sast2 trustpoint command in CTL-client configuration mode. To return to the default, use the no form of this command.

sast2 trustpoint label

no sast2

Syntax Description

label

Name of the SAST2 trustpoint.

Command Default

No SAST2 trustpoint name is specified.

Command Modes

CTL-client configuration (config-ctl-client)

Command History

Cisco IOS Release	Cisco Product	Modification
12.4(4)XC	Cisco Unified CME 4.0	This command was introduced.
12.4(9)T	Cisco Unified CME 4.0	This command was integrated into Cisco IOS Release 12.4(9)T.

Usage Guidelines

This command is used with Cisco Unified CME phone authentication.

The sast1 trustpoint and sast2 trustpoint commands are used to set up the System Administrator Security Token (SAST) credentials, which are used to sign the CTL file. The SAST1 and SAST2 certificates must be different from each other, but to conserve memory either one of them can use the same certificate as Cisco CME. The CTL file is always signed by SAST1 credentials. The SAST2 credentials are included in the CTL file so that if the SAST1 certificate is compromised, the CTL file can be signed by SAST2 to prevent the phones from being reset to their factory defaults.

Examples

The following example names sast2tp as the SAST2 trustpoint.

Router(config)# ctl-client
Router(config-ctl-client)# server capf 10.2.2.2 trustpoint capftrust
Router(config-ctl-client)# server cme 10.2.2.3 trustpoint cmetp
Router(config-ctl-client)# server tftp 10.2.2.4 trustpoint tftptp
Router(config-ctl-client)# sast1 trustpoint sast1tp
Router(config-ctl-client)# sast2 trustpoint sast2tp
Router(config-ctl-client)# regenerate
 

Related Commands

Command	Description
sast1 trustpoint	Specifies the name of the SAST1 trustpoint.

sdspfarm conference lecture mode on

To permit a participant in a video conference call to switch back and forth between lecture mode and the the configured default mode in DSP farm, use the sdspfarm conference command in telephony-service configuration mode. The participant who enters the FAC becomes the lecturer and is displayed on all other screens. The lecturer’s screen displays a scanning stream of the other participants.

To delete a tag generated by the sdspfarm conference command, use the no form of this command.

sdspfarm conference lecture mode on FAC release FAC

no sdspfarm conference lecture mode on FAC release FAC

Syntax Description

FAC	Sets the Feature Access Codes (FAC) that a participants enters on the keypad to switch to the lecture mode. Valid values are the numbers on the keypad. Maximum 3 digits
release FAC	Sets the Feature Access Codes (FAC) that a participants enters on the keypad to exit lecture mode. Valid values are the numbers on the keypad. Maximum 3 digits

Command Default

Lecture mode is not enabled by default.

Command Modes

Telephony-service configuration (config-telephony)

Command History

Cisco IOS Release	Cisco Product	Modification
15.1(4)M	Cisco Unified CME 8.6	This command was introduced.

Usage Guidelines

You can define any three digits to be FAC for lecture mode. A participant cannot enter lecture mode on a phone with unsupported video formats, for example an audio-only phone. The lecture mode participant must exit lecture mode before anyone else can become the lecturer.

Examples

The following example configure lecture mode to be activated when the user presses a FAC number of 111.

Router(config)# telephony-service
outer(config-telephony)# sdspfarm conference lecture-mode on 111 release 222

Related Commands

Command	Description
dspfarm profile	Enters DSP farm profile configuration mode and defines a profile for DSP farm services.
sdspfarm transcode	Specifies the maximum number of transcoding sessions allowed per Cisco CME router.
sdspfarm units	Specifies the maximum number of DSP farms that are allowed to be registered to the SCCP server.

sdspfarm conference mute-on mute-off

To define mute-on and mute-off DTMF digits for use during conferencing, use the sdspfarm conference mute-on mute-off command in telephony-service configuration mode. To disable the mute-on and mute-off digits, use the no form of this command.

sdspfarm conference mute-on mute-on-digits mute-off mute-off-digits

no sdspfarm conference mute-on mute-on-digits mute-off mute-off-digits

Syntax Description

mute-on mute-on-digits	Defines the buttons you press on your phone to mute during a conference. Maximum: 3 digits. Valid values are the numbers and symbols that appear on your telephone keypad: 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, *, and #.
mute-off mute-off-digits	Defines the buttons you press on your IP phone to unmute during a conference. Maximum: 3 digits. Valid values are the numbers and symbols that appear on your telephone keypad: 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, *, and #.

Command Default

No mute-on or mute-off digits are defined.

Command Modes

Telephony-service configuration (config-telephony)

Command History

Cisco IOS Release	Cisco Product	Modification
12.4(11)XJ2	Cisco Unified CME 4.1	This command was introduced.
12.4(15)T	Cisco Unified CME 4.1	This command was integrated into Cisco IOS Release 12.4(15)T.

Usage Guidelines

You must define mute-on and mute-off digits to mute or unmute your phone using the keypad during a conference. The mute-on digits and mute-off digits can be the same or different. You can mute and unmute your phone using the phone’s mute button also. You must unmute the phone in the same way that you muted it, either with the keypad or the mute button.

Examples

The following example configures #5 as the buttons to press to mute and unmute the phone during a conference:

Router(config-telephony)# sdspfarm conference mute-on #5 mute-off #5
 

2. SIP INVITE Flood Attacks

The Session Initiation Protocol (SIP) is a VoIP standard defined in RFC 3261. SIP INVITE messages are used to establish a media session between user and calling agents. In SIP INVITE flood attacks, the attacker sends numerous (often spoofed) INVITE messages to the victim, causing network degradation or a complete DoS condition.

The SIP network infrastructure consists of the following:

•The SIP end-point device: a user agent that is responsible for generating and terminating SIP requests. This could be a soft-phone, an instant messenger, an IP phone or even a cellular phone.

•SIP Proxy: an application that enables SIP devices to locate and communi-cate with one another.

•SIP Registrar: an application with which the SIP devices need to register in order to make and receive calls.

•SIP Redirect Server: an application that receives a request from another SIP device or proxy and returns a redirection response indicating where the re-quest should be directed.

•Usually the SIP proxy, SIP registrar and SIP redirect server are implemented on one system.

FLOODING ATTACKS IN SIP

A flooding attack against an Internet application or service can be launched either from a single or multiple sources. The latter exploits ‘innocent’ Internet hosts, known as attack reflectors, which create a large number of requests (e.g., TCP connection requests) against the victim. This kind of attack is called a reflection distributed DoS (RDDoS) attack [30]. Such an attack as well as other generic-transport layer attacks (see a CERT report [31]) can be used to paralyze SIP infra- structure, too. Below we describe how this type of attack can be launched towards the SIP infrastructure. Flooding Registrar Server — One of the cardinal network elements in SIP telephony service is the registrar. When an attacker manages to paralyze the registrar (e.g., by sending numerous bogus registration requests), it can easily cause a DoS. This situation can be avoided only if the SIP server blocks all messages coming from unknown origins. As discussed eariler, a REGISTER request can add a new binding between a user’s SIP address and one or more contact addresses (currently IP addresses) so that the user can utilize the provided telephony service. Consequently, when the attacker launches an attack against a REGISTRAR by employing a large number of registration requests, he/she aims to accomplish one of the following goals:

• To guess legitimate users’ passwords

• To cause a DoS in the SIP registrar

Figure 1 depicts such an attack scenario against a SIP reg- istrar server. This attack can be possibly launched by employing different ways to send a SIP message, each time changing just a few parameters. For example, the attacker can try to de-register the legitimate user to cause DoS. The only difference between registration and deregis- tration (terminate the session) procedure is the value of the EXPIRES header. This header is set to zero

when the UA wants to terminate the session (deregister). In this way, an attacker will try to evade any

existing countermeasure. In both procedures, the attacker needs to “guess” the legitimate user’s pass-

word.This type of attack can also be launched in a distributed manner. As an example, multiple attackers can either undertake the task to find out a legitimate user’s password or disrupt the provided service by sending simultaneous REGISTER messages to the registrar, as the authentication procedure is considered computationally expensive.

Flooding attacks on SIP protocol can be divided into the following four categories:

1. SIP Registration Flooding Attacks

An attacker can forward a large number of Register messages with a fake ID and incorrect password and address to the SIP server. In response, the attacker will receive 401 UNAUTHORIZE message. And ignoring it, the attacker will send more messages. Processing address, ID and password will waste server resources and server will fail to

response the authorized users.

2. INVITE Flooding Attacks

After registration as an authorized user, the attacker will send INVITE messages to the server. Since the server sends the message to the destination and must wait a period of time for each INVITE request and during this time it keeps information related to the request, this high volume of unanswered messages takes server resources and therefore server will be unable to respond to the authorized users.

3. BYE Flooding Attacks

In this type of attacks, an attacker attempts to send messages of session termination to the server . These messages can terminate the authorized sessions without requesting for session termination by authorized users and suddenly a large volume of sessions will be disconnected unwontedly.

4. Combinational Attacks

A smart attacker can generate attack traffic including a combination of SIP packets to bypass some attack detection mechanisms. These attacks can be classified into the category of combinational attacks while they can take place by an attacker or multiple attackers (distributed DoS attacks) . Flooding attacks can have several causes. First, it can be a planned attack aimed at damaging the designed network, or these attacks occur without any intention and the reason is defective device or wrong SIP implementation. For example, consider a REGISTER Flooding after power failure; all devices try to send REGISTER message at the same time. Also, faulty design of re-REGISTER time scales may result in such a case. However, due to the same consequences for the two states, detecting and fixing the problem in both cases are mandatory. Clearly, it would be easier to detect unintentional attacks since real attackers will consider measures to evade detection.

prevention of attack

An important step that must be implemented is to prevent the attack. In this part, we get help of the different hash functions that we used in Sketch tables for the test intervals. According to different hash functions and by intersecting between SIP addresses of Sketch cells from which the largest amount of change of entropy is

obtained, we will identify SIP address of attacker and the packets related to these addresses are discarded; also, having informed the server of these addresses, we prevent their being serviced or limit the transmission rate for them. The attackers` list is dynamic and each member, in the absence of anomalous behavior after a specified time

interval, can be removed from the list. Through this mechanism, even if the addresses are fake or related to the victims of attacker, our aim at protecting the SIP server and servicing to authorized users can be achieved.