The basics of SIP trunking explained
A comprehensive collection of articles, videos and more, hand-picked by our editors
Chapter 7, Security in a SIP Network
Learn about security in a SIP network and find out how an organization can protect itself from SIP-based VoIP and network attacks. In this section, you'll learn about the specific security measures that can be used to protect your SIP network.
Security solutions for SIP management
There are many reasons why many networks do not implement any form of security. Many platforms are older systems running operating systems that do not support security patches and must be completely replaced by newer platforms. This of course is cost prohibitive.
Other operators are severely short-handed and lack both the resources and the expertise to implement a strong security policy. They also lack the capital to invest in security implementations. Human error and configuration mistakes add to the problem, especially when expertise is lacking.
There are many different types of solutions available for securing networks. The security industry is probably one of the fastest growing tech sectors today, with products ranging the full gambit. This is both good and bad. With so many different products available, there are also just as many different approaches to security.
One worthy change within security concepts today is the layering of security implementations. Layering means implementing a security solution at all layers of the network. There are many reasons why this approach makes a lot of sense. When looking at the various types of attacks, some attacks are best detected at the lower layers, while others can only be detected at the application layers.
For example, security implemented at the network level will detect network anomalies and changes in the traffic flow but cannot detect buffer overruns in the application servers. Systems that operate at the network level have no visibility to the applications themselves and therefore are unable to detect problems within the applications themselves.
A layered approach provides a lot more flexibility to the operator as well. It allows operators to scale their security implementation rather than invest everything at the transport layer. By implementing just what is needed at the various layers, operators can save on their overall investments significantly.
Here is why. I could launch a distributed denial of service (DDoS) attack on a network that would be very difficult to detect at the transport layer. This is because I am sending large volumes of INVITEs from many different origination points within the network using bots. I would need to collect data from all over the network to determine that there was an attack of this nature in progress, or rely on an alarm at the destination point when it went into congestion.
However, if I am monitoring the application layer, I will see an increase in traffic in real time. Furthermore, I will see that the traffic is coming from multiple origination points and looks to be a DDoS attack. I could invest more money to implement sophisticated analysis applications at the transport layer combined with deep packet inspection, or I could invest in detection software at the application level (and most likely not have to invest as much).
There is no single-point security solution that will protect the entire network, so a layered approach is the best means of ensuring your network assets are protected. Also remember that a single security solution is purpose built, designed to protect against specific types of security breaches. All security plans should incorporate several different platforms and methods based on the type of network and the services being provided.
If the services consist mostly of content, then that content is what must be protected. Digital rights management (DRM) will be required to deter copyright violations, while security measures such as those discussed will be necessary to prevent unauthorized access to the network and the content.
The following sections discuss the various solutions available to protect a network from attack. These are not exclusive; there are numerous different solutions and approaches, but these should be considered as a bare minimum.
Monitoring systems have been used for several years to monitor the health of the network. Now they bring additional value as intrusion detection systems (IDSs). Of course, traditional network monitoring only has visibility to the call control layers within your network. You will need a platform to provide additional visibility into the transport layers as well.
This is especially true of data-intensive networks where the primary service is data services rather than just voice. In a voice network, traditional monitoring systems can easily be implemented to detect specific attack scenarios such as ISUP flooding (in an SS7 network) or SIP INVITE flooding (in a SIP network).
An IDS can operate in real time (or near real time) or historical mode. A real-time system is needed for detecting attacks while they are in progress. However, these systems should also have some capacity of storage to allow for the investigation of network events at a later time. The amount of storage depends on the amount of traffic to be stored, and the duration of time you need to review.
For example, if you want to be able to pull traffic for a six-month period, you will obviously need storage capacity for six months of traffic (or possibly more). While this is not common today, there are more and more network operators who are implementing long-term storage of their traffic for investigating incidents (as well as traffic modeling, revenue assurance, lawful intercept, and many other applications).
The purpose of these intrusion detection systems is to detect and notify of certain network anomalies at the call control layer. They should have the ability to see all SIP methods, and they should have the ability to provide basic key performance indicators (KPIs). These KPIs later become important for identifying flooding scenarios and other attack methods.
The IDS identifies the source of data (the network, application, or host). It performs analysis on the traffic based on rules (policy) and could also have the ability to establish its own policy through neural technology. The IDS then sends notification of the event to a console or other reporting system.
For example, in a flooding case, the monitoring system should detect an increase in the number of SIP requests across the entire network, as well as specific network segments. This could indicate (if it is a sharp rise in the number of requests) that there is a DoS attack underway.
If the system also supports the configuration of thresholds, then the system can be set to alert the users anytime these thresholds are exceeded. This is important for identifying DoS attacks.
Another advantage to monitoring systems is the ability to measure the performance and set thresholds for the entire network, or critical network segments. Because the monitoring system has visibility to all network elements, and all network facilities (if implemented network wide), the system can therefore see traffic levels across the entire network rather than within just one entity.
If you are relying on alarms from the various network entities, you will most likely not see a distributed DoS attack until it's too late. This is because a DDoS attack comes from many different sources, originating from many UAs across the network. Without a view of the entire network, you will not be able to see all of the traffic.
The individual network elements will only be able to detect and provide data on what they see, which is only a fraction of the traffic. For example, security implemented within proxies is great for identifying situations at the proxy, but they will miss anything that happens within other proxies, or occurs at any other point in the network.
For this reason it is best to leave network element security implementations focused on transport security, and rely on monitoring systems for security at the call control layers. This is the best way to ensure you will see all situations that could take place at that layer.
Monitoring systems can be thought of as network-based IDSs. They use probes to capture the network traffic, based on rules (or filters) defining the type of traffic. Usually the filters support defining traffic specifics such as origination points, type of traffic, and so on.
The probes then report back to a central server where the final analysis is completed. This server will also provide some form of console for reporting incidents and generating alarms. The probes themselves are passive, although they can be active in some cases.
Because they are passive, they do not require a network address. This makes them transparent in the network, which adds another distinct advantage. Because they cannot be detected, they are invisible to hackers.
The network-based IDS is best deployed both at the network edges (monitoring the access points into the network) and at aggregation points within the network (where it will be able to detect man-in-the-middle and other internal attacks).
One disadvantage to passive probes is that they do not work in networks where encryption is used. Because they are passive, they are unable to actively exchange encryption keys and negotiate these keys with other network elements. This can be a major setback, since encryption is key to any network security strategy.
There are a number of integrated solutions for detecting network intrusions at the transport layer. Host-based IDSs are typically implemented within the proxies and the gateways in the network.
The IDS should be separate from the elements it is protecting. In other words, it is not desirable to integrate the IDS function within the various network elements, since an attack on the network element would also compromise the IDS. The exception to this rule is when you are using a combination of IDS implementations. When combined with network IDSs, host-based IDSs can provide an additional advantage.
A host-based IDS monitors the various ports as well as processes within each of the network elements. This provides another set of eyes at the network element itself that a probe would never be able to detect. This can be important especially when looking for probing events where hackers are scanning platforms looking for vulnerabilities.
Another advantage of a host-based IDS is that it works within an encrypted network. Since it resides within the various hosts, the host-based IDS does not need to know the encryption keys. It is dealing with internal processes within the host itself, and any traffic data it receives will already be decrypted by the host it resides in.
Host-based IDSs are also capable of detecting viruses and Trojan horses residing on the host. Only a host-based IDS would have this visibility, since it requires visibility to internal processes and ports on the host. This is also a major advantage and key reason for implementing host-based IDSs in conjunction with network-based IDSs.
With all of the advantages also come drawbacks. A host-based IDS still needs to report back to a central authority events going on within each of the hosts. A central console is needed to collect data from all the IDSs deployed and provide reports and alarms. Otherwise, operators would have to access each host individually and extract this information on a host-by-host basis.
Backhauling all of the data from multiple hosts can be a challenge and in some cases would require a lot of bandwidth. For this reason, not every host should be covered. Certainly the critical hosts within the network should be protected.
Host-based IDSs are also susceptible to attack, since they reside within the targets themselves. This can add to the challenge and, of course, if compromised will become worthless. A good example of this would be virus protection implemented on your computer being compromised so that it receives automatic updates from a hacker site rather than the software vendor's own site. This is a tactic used today by many hackers.
Since they reside in the hosts themselves, host-based IDSs obviously do not have visibility to the rest of the network. For this reason they should not be used as the sole security implementation within a network. They should always be used in conjunction network-based IDSs.
An application-based IDS is actually a subset of a host-based IDS. It resides on the host but monitors specific applications on the host rather than the whole host. The purpose of an application-based IDS is to provide visibility to a user's interaction with the application, detecting unauthorized use of an application.
The application-based IDS should always be used in conjunction with network and host-based IDSs, to provide a layered approach to security, as well as a total view of what is truly going on within the network and its resources. When implemented in this fashion, the overall IDS strategy can provide enough visibility for an operator to detect in real-time events in the network before they cause significant disruptions and outages.
An IDS performs analysis on collected data to determine if there is an attack underway, or abnormal events within the network. There are two types of methods that are used: signature analysis and anomaly analysis.
Signature analysis relies on rules that are defined within the IDS (also referred to as policy). These signatures are established from previous attacks, so they are signatures of known attacks used as profiles for detecting the same attacks again.
These are very accurate, since they are based on known attack signatures. They are good for networks where expertise may not be abundant or resources are limited, but they should not be the only analysis used. Signature analysis is based on known attacks and therefore is not well suited for finding new attacks that use a different signature.
Anomaly analysis looks for abnormal behavior in the network. This is the best method for finding new attack signatures, but it does require additional expertise, since the analysis is usually a manual process today.
Profiles are built based on a snapshot of captured traffic over a period of time. The longer the duration of time used to collect the traffic, the better the profile. One method may include setting thresholds in the network, and anytime these thresholds are exceeded, raising an alarm. Anything that deviates from the profile is then considered an anomaly.
Statistics can also be used for establishing profiles. Statistics such as key performance indicators (KPIs) and key quality indicators (KQIs) are commonly used today in many monitoring systems for analyzing traffic data and determining if there are security breaches.
Both methods should be used together for the most effective approach. A signature analysis implementation alone will not be effective in finding new attacks and will leave the network very vulnerable, since attack methods change regularly.
A new approach is to deploy an IDS as a "honeypot," where a host is set as a decoy in the network. The data within the host is of enough interest to draw hackers, but benign to the network operator (no harm can be done with the data). When the attacker accesses the host, information is gathered about the attacker and all aspects of the session.
This information is then used in other IDSs within the network to establish a profile and signature to be used to detect other network breaches. Sometimes the attacker is even transferred to another part of the host where he or she is isolated from the network and its resources, limiting the harm the attacker can render on the network.
In voice networks (especially wireless) there can be individual numbers within number ranges that are left unassigned (dark). These numbers are then closely monitored for activity. If there is an attempt to call one of these numbers, the call data is collected and analyzed, since it could be a hacker attempt to create a hit list within a network to be used as targets at a later time.
An IDS should be deployed using the layered approach discussed in this section, using all forms of IDS rather than just a single approach. If only one approach is feasible, however, the network-based approach is the best direction to take, since this will give you the best visibility to network activity.
Network probes should be deployed behind firewalls, as well as at network edges, on major backbones, and on critical subnets. This will give the best overall view of everything in the network. They can also be converted to include active capability at a later time (or at the time of implementation).
An intrusion protection system (IPS) combines the analysis of an IDS with the added protection of a firewall. The IPS then must be configured with a network address, since it will be an active element within the network. It is able not only to alter received traffic but to generate traffic.
The IPS is capable of inspecting packets and altering packets, making them benign in the network. This allows rogue packets to continue in the network without sending failure responses back to the originators, alerting them that their attempt was not successful.
The IPS can be implemented as part of the IDS, or it can be implemented separately. In this type of implementation the IPS could receive instructions or data from the IDS or from a policy engine.
The IPS can also be integrated on a host with an application. Vendors are continually adding security features within their platforms to further enhance their applications. This adds another level of security, albeit at a slightly higher cost, since it must be implemented at all critical applications.
An IPS, like an IDS, must support the network protocols used within the network. This includes any vendor-proprietary protocols that are implemented on vendor platforms. It makes decisions based on policy, although in some cases intelligence can be added that allows the IPS to operate in a neural fashion, creating new profiles and policy based on historical traffic patterns. This requires storing traffic from many months for the most complete profile.
Many systems begin as passive IDSs and then later evolve into active IPSs. This is done by converting the passive probes to include active interfaces so that only those interfaces that are to be active would require a network address. This way, the passive capability can be maintained along with the active capability.
Read the first section: Identifying SIP-based network attacks
Read the second section: SIP network security measures
Read Chapter 7, "Security in a SIP Network" from Session Initiation Protocol (SIP): Controlling Convergent Networks in its entirety.