What is SBC (Border Controller Sessions) and why is it needed?
The market of border controllers of sessions is gaining momentum every year, while for many in the field of VoIP, this device remains a question - why is it needed and where to use it correctly. Actually, I would like to describe the functions and tasks that this equipment performs and why the installation of this device, if not necessary, is certainly highly desirable on a VoIP network.
Let's go from simple to complex. First, we define the three functions that SBC performs on the customer’s network.
1. Security
2. Compatibility
3. Quality assurance and control
In most cases, many people immediately have a lot of questions, because it would seem that there is a Firewall that does an excellent job with the security function and why protect the VoIP network additionally. Why ensure compatibility, if there is a standard RFC3261 and everyone works according to this standard. And quality - there is an opinion that VoIP quality depends more on the quality of the network, and not on some device. Now let's take a closer look at what the security of a VoIP network actually is, and why RFC3261 compatibility (SIP v2) is not enough, what exactly the Border Controller of Sessions provides in terms of quality.
1. Security
First, we need to figure out what we want to protect and what can an attacker do? The first and most painful thing an attacker can do is stealing traffic. The attacker gains access to ensure that your face has the opportunity to call a telecom operator and then makes quite expensive calls somewhere to sunny Cuba through your system. Than it threatens, probably, it is clear to all - the big expense from the operator.
How is theft happening and what are the mechanisms to prevent it?
As always, everything must start with the most primitive. Moreover, this primitive will protect you quite strongly. In most cases, intruders start by simply checking all IP addresses on the response to the SIP port (UDP 5060). For example, sending an OPTIONS message to this port sequentially to all IP addresses. So he is just looking for another victim. Next, the following happens: as soon as they receive a response, the attacker immediately receives a lot of information about you. Namely, he knows that your SIP is available via the Internet and in 99% of cases he knows the type of your IP-PBX. How exactly does he do it? Easy. When the IP-PBX responds to a SIP request, it gives an answer, where the User-Agent field with the name and version of the device is indicated. For example: user-agent: Asterisk 1.2.3. I just want to apologize to all Asterisk lovers, I will mention it, since it is the most popular system for hacking. What SBC does in this case: on the recommendation, it uses a port other than 5060 and easily replaces the value of the User-Agent field. Here we immediately put the attacker in a more difficult situation - firstly, his system does not always determine that you use SIP, since in most cases you simply do not respond to his requests; secondly, even having received the answer, he will not know what your station is and what side to approach it. Why the second is also very important. And everything is simple. For example: the attacker determined that you have Asterisk version 1.2.3, to which there was a bug that allowed you to call the extension number and then use DTMF dialing to redirect this extension number. And then he calls this internal number, where there is a call forwarding to the number he needs. And in general, the more functionality a PBX has, the more there are different ways to use this functionality for purposes other than those for which this functionality is intended.
And if we talk about forwarding, it is one of the most subtle, in terms of security in VoIP. Since in most cases no one thinks how and where to transfer the number, who made the call, and he is simply replaced with the number, who forwarded the call. This is also important and you need to check what the SBC does as well. In this article I will not delve into the topic of number forwarding.
Another important issue is management and access to management. SBC initially has many interfaces and the ability to configure VLANs, which allows the management interface to be put into a separate secure subnet, which makes the issue of accessing it very difficult.
From a security point of view, it is worthwhile to pay special attention to call routing and checking SIP packets. It is important that any package be as trusted as possible. For this SBC has a lot of tools. First, it is a test for various fields. For example, you know that a message always comes from the operator, with a field User-Agent: ITSP_SIP and something else adds. Or, when connecting to the telephone’s IP PBX via the Internet, it is imperative to check that the registration is from the telephone set that is allowed on your network. Also, it is required to determine as accurately as possible routes to which you can call, from which you can call. It also allows the SBC to provide the right level of security.
Another very important point that ensures SBC security of your IP PBX is the delimitation of VoIP traffic on your network. It allows you to allocate a separate subnet for your IP-PBX and make access to it only from another physical interface, thereby providing access to your VoIP network only through the Session Border Controller.
And further, this is a set of standard things, such as a regular firewall, which is also on the SBC.
Actually, it is these tools on the SBC that allow you to be safe from an attempt to hack the system to steal traffic or some other actions. Of course, SBC has other methods and methods of protection, but here I described rather the most popular and important actions to protect your VoIP network:
a. There are still DoS / DDoS attacks. On the one hand, they are more harmless, since, they just turn off the telephony service, but there is another side to this problem:
b. Here you need to clearly understand, if IP-PBX is disabled, then all telephony disappears from you, which is not pleasant in itself and can affect the business process.
c. Also not unimportant factor is that most often these attacks are made in order to select user passwords with further actions of this user. Including traffic theft.
SBC has a built-in Firewall, which works on two principles - static and dynamic. The first option is clear and to describe it, probably, there is no point. The second option works as follows. If you admit the possibility of registering SIP subscribers from the Internet, then theoretically it can be registered from any source and cannot be filtered statically. For example, if your employees flew somewhere to China and want to connect to your IP PBX, you will need to open full access, or at least for all Chinese IP addresses. The only way to secure your IP telephony network is to use dynamic access control lists when the SBC closes only those IP addresses at the network level from which anomalous traffic is coming. And the degree of anomaly you expose yourself.
There is also the issue of eavesdropping and the only way to get around this is encryption. But, since in our country security services are very scrupulous about this topic, I will disregard this topic. Moreover, in Russia no one provides encryption for the same reasons.
2. Compatibility
The second question that confronts SBC is compatibility. Everyone talks about the fact that they support SIP v2 (also known as RFC 3261) and everything will work that way. But as practice shows, this is not what we suck, or rather not at all. I would say that the issue of compatibility is the most complex and complex in a VoIP network. Why is that? And what are IP PBXs and unified communications systems made for? No matter how everyone says that they strive for standardization, in fact, the priority is the main one in the other and it completely contradicts the very idea of doing everything according to the standard. The task of PBX manufacturers is to provide the most interesting and complete set of services, and if someone suddenly came up with a new service, then they have no option but to do it in their own way. (Well, and then make a new RFC and say everything - support). Moreover, the flow of information works well in our world (but not great). And if a competitor has found out that someone is making a new feature, naturally, he does the same, though in his own way and standardizes his version of the implementation of this function and naturally, standardizes it. As a result, the world receives two different stations with the same function, which work differently, with the standard, but not compatible with each other. And if no one has problems with the basic challenge, then there are always plenty of issues with SIP extensions. For statistics, there are currently over 100 RFC extensions for SIP in the world. The station usually supports no more than 20, our SBC supports more than 80. And if it is required to you that you can use all your functionality when working with a telecom operator, then SBC is simply necessary in this case.
And the same security affects the compatibility. And not your security, but the security of your carrier. As a rule, the operator has his own SBC and in most cases he has clear and understandable message / field / function filters when working with the client. I will give two simple and clear examples:
a. The IP PBX uses SIP Refer to transfer the call (this is when the station tells the upstream station that you transfer the call to an external subscriber, and then continue the call between the upstream station. Everything is fine, but here's the moment - who should be billed. Operator in this case should close the call between the two non-subscribers. The bill should be billed to you, but the call was not with you. For this reason, the operator simply blocks such functionality (and does it right). SBC in this case takes over the question of switching the call and working out with The REFER messages and the operator display two calls (incoming and outgoing), and everything works fine.
b. Call forwarding. For example: Subscriber A called subscriber B, who has call forwarding to subscriber B. And the call goes from subscriber B to subscriber B, while the number A is displayed as the caller's number. And this is correct, since the calling number is the number A, not the one that redirects. This is the telephone standard. And if everything is clearly described in ISDN (E1), since there is a Redirect number field, then here in SIP number B for correct identification can be transferred using History-Info, Referred-By, Diversion. And based on this, operators simply like to block such numbers, referring to the fact that their billing does not work correctly. That is, carrier billing is contrary to the SIP standard, or the operator simply does not want to receive forwarded calls, according to the standard. SBC allows you to convert one format to another in every possible way or simply transfer the number from any field to the From and / or P-Asserted-Identity field.
The remaining examples are not so common, and no less important, since the less often they occur, the more difficult it is to solve them using standard telephone exchange methods. Separately, I want to say about the issues of compatibility and adaptation of voice codecs. The time has passed when everyone supported the G.711 and G.729 codecs, and this is enough. There are a lot of reasons for this, and most importantly, PBX manufacturers seek to improve the quality of communication using their own codecs or specialized codecs, such as SILK / OPUS / MS-RTA. Here the reason is simple (especially if we are talking about the unified communications system) - now all companies are trying to make telephony not only on the IP phone (which can be allocated to a separate VLAN and give traffic priority), but also make telephony everywhere - on tablets, leptopes, smartphones via WiFi, public Internet. And here it is not always possible to prioritize traffic and ensure proper quality in the overall IP stream, and adaptive codecs provide better quality on such networks, relative to G.711 / G.729.
This is where SBC helps you use the codec you want on the network, and dock with the operator using the one that it supports.
Separately, there is the question of DTMF and faxes, which no one has canceled in the VoIP environment. I do not want to delve into this topic, I can only say that at the moment we support all the options for sending both DTMF and faxes.
In fact, you can write about compatibility for a long time, and you can even make separate articles on how to solve this or that problem with the help of our SBC. But in any case, even if your operator says that he will achieve full compatibility with you, the operator does not always achieve this and the timing for setting this compatibility is always large. SBC will allow you to reduce risks and reduce costs when connecting.
')
3. Quality assurance and control
Well, in conclusion, I will write a little about quality assurance and control:
a. Quality assurance - first of all, this is work with voice codecs.
b. Quality control - SBC monitors all calls for a variety of parameters, such as Echo / delay / packet loss / Jitter / MoS and when you have a problem, you immediately and clearly understand which side and for what reason the connection deteriorated, thereby reducing deadlines for fixing problems. SBC also allows you to independently rebuild the route if the quality of communication with a single operator falls. This will preserve call quality without external intervention.
Also, not unimportant factor from the point of view of quality assurance, is the correct setting of routing with the possibility of balancing and reserving routes. Including, if you have a backup interface with the Internet, then it should be included, including for VoIP, regardless of the network equipment settings.
I can not say that these are all the functions and tasks performed by the SBC Border Controller (SBC), especially since it is extremely difficult to list everything. I would even say that, from the point of view of security, compatibility and quality of universal recipes, there is simply no and sometimes each connection is unique and special. Our task here is to provide the maximum number of opportunities so that your use of VoIP meets all your business requirements for an IP telephony system.
Let's go from simple to complex. First, we define the three functions that SBC performs on the customer’s network.
1. Security
2. Compatibility
3. Quality assurance and control
In most cases, many people immediately have a lot of questions, because it would seem that there is a Firewall that does an excellent job with the security function and why protect the VoIP network additionally. Why ensure compatibility, if there is a standard RFC3261 and everyone works according to this standard. And quality - there is an opinion that VoIP quality depends more on the quality of the network, and not on some device. Now let's take a closer look at what the security of a VoIP network actually is, and why RFC3261 compatibility (SIP v2) is not enough, what exactly the Border Controller of Sessions provides in terms of quality.
1. Security
First, we need to figure out what we want to protect and what can an attacker do? The first and most painful thing an attacker can do is stealing traffic. The attacker gains access to ensure that your face has the opportunity to call a telecom operator and then makes quite expensive calls somewhere to sunny Cuba through your system. Than it threatens, probably, it is clear to all - the big expense from the operator.
How is theft happening and what are the mechanisms to prevent it?
As always, everything must start with the most primitive. Moreover, this primitive will protect you quite strongly. In most cases, intruders start by simply checking all IP addresses on the response to the SIP port (UDP 5060). For example, sending an OPTIONS message to this port sequentially to all IP addresses. So he is just looking for another victim. Next, the following happens: as soon as they receive a response, the attacker immediately receives a lot of information about you. Namely, he knows that your SIP is available via the Internet and in 99% of cases he knows the type of your IP-PBX. How exactly does he do it? Easy. When the IP-PBX responds to a SIP request, it gives an answer, where the User-Agent field with the name and version of the device is indicated. For example: user-agent: Asterisk 1.2.3. I just want to apologize to all Asterisk lovers, I will mention it, since it is the most popular system for hacking. What SBC does in this case: on the recommendation, it uses a port other than 5060 and easily replaces the value of the User-Agent field. Here we immediately put the attacker in a more difficult situation - firstly, his system does not always determine that you use SIP, since in most cases you simply do not respond to his requests; secondly, even having received the answer, he will not know what your station is and what side to approach it. Why the second is also very important. And everything is simple. For example: the attacker determined that you have Asterisk version 1.2.3, to which there was a bug that allowed you to call the extension number and then use DTMF dialing to redirect this extension number. And then he calls this internal number, where there is a call forwarding to the number he needs. And in general, the more functionality a PBX has, the more there are different ways to use this functionality for purposes other than those for which this functionality is intended.
And if we talk about forwarding, it is one of the most subtle, in terms of security in VoIP. Since in most cases no one thinks how and where to transfer the number, who made the call, and he is simply replaced with the number, who forwarded the call. This is also important and you need to check what the SBC does as well. In this article I will not delve into the topic of number forwarding.
Another important issue is management and access to management. SBC initially has many interfaces and the ability to configure VLANs, which allows the management interface to be put into a separate secure subnet, which makes the issue of accessing it very difficult.
From a security point of view, it is worthwhile to pay special attention to call routing and checking SIP packets. It is important that any package be as trusted as possible. For this SBC has a lot of tools. First, it is a test for various fields. For example, you know that a message always comes from the operator, with a field User-Agent: ITSP_SIP and something else adds. Or, when connecting to the telephone’s IP PBX via the Internet, it is imperative to check that the registration is from the telephone set that is allowed on your network. Also, it is required to determine as accurately as possible routes to which you can call, from which you can call. It also allows the SBC to provide the right level of security.
Another very important point that ensures SBC security of your IP PBX is the delimitation of VoIP traffic on your network. It allows you to allocate a separate subnet for your IP-PBX and make access to it only from another physical interface, thereby providing access to your VoIP network only through the Session Border Controller.
And further, this is a set of standard things, such as a regular firewall, which is also on the SBC.
Actually, it is these tools on the SBC that allow you to be safe from an attempt to hack the system to steal traffic or some other actions. Of course, SBC has other methods and methods of protection, but here I described rather the most popular and important actions to protect your VoIP network:
a. There are still DoS / DDoS attacks. On the one hand, they are more harmless, since, they just turn off the telephony service, but there is another side to this problem:
b. Here you need to clearly understand, if IP-PBX is disabled, then all telephony disappears from you, which is not pleasant in itself and can affect the business process.
c. Also not unimportant factor is that most often these attacks are made in order to select user passwords with further actions of this user. Including traffic theft.
SBC has a built-in Firewall, which works on two principles - static and dynamic. The first option is clear and to describe it, probably, there is no point. The second option works as follows. If you admit the possibility of registering SIP subscribers from the Internet, then theoretically it can be registered from any source and cannot be filtered statically. For example, if your employees flew somewhere to China and want to connect to your IP PBX, you will need to open full access, or at least for all Chinese IP addresses. The only way to secure your IP telephony network is to use dynamic access control lists when the SBC closes only those IP addresses at the network level from which anomalous traffic is coming. And the degree of anomaly you expose yourself.
There is also the issue of eavesdropping and the only way to get around this is encryption. But, since in our country security services are very scrupulous about this topic, I will disregard this topic. Moreover, in Russia no one provides encryption for the same reasons.
2. Compatibility
The second question that confronts SBC is compatibility. Everyone talks about the fact that they support SIP v2 (also known as RFC 3261) and everything will work that way. But as practice shows, this is not what we suck, or rather not at all. I would say that the issue of compatibility is the most complex and complex in a VoIP network. Why is that? And what are IP PBXs and unified communications systems made for? No matter how everyone says that they strive for standardization, in fact, the priority is the main one in the other and it completely contradicts the very idea of doing everything according to the standard. The task of PBX manufacturers is to provide the most interesting and complete set of services, and if someone suddenly came up with a new service, then they have no option but to do it in their own way. (Well, and then make a new RFC and say everything - support). Moreover, the flow of information works well in our world (but not great). And if a competitor has found out that someone is making a new feature, naturally, he does the same, though in his own way and standardizes his version of the implementation of this function and naturally, standardizes it. As a result, the world receives two different stations with the same function, which work differently, with the standard, but not compatible with each other. And if no one has problems with the basic challenge, then there are always plenty of issues with SIP extensions. For statistics, there are currently over 100 RFC extensions for SIP in the world. The station usually supports no more than 20, our SBC supports more than 80. And if it is required to you that you can use all your functionality when working with a telecom operator, then SBC is simply necessary in this case.
And the same security affects the compatibility. And not your security, but the security of your carrier. As a rule, the operator has his own SBC and in most cases he has clear and understandable message / field / function filters when working with the client. I will give two simple and clear examples:
a. The IP PBX uses SIP Refer to transfer the call (this is when the station tells the upstream station that you transfer the call to an external subscriber, and then continue the call between the upstream station. Everything is fine, but here's the moment - who should be billed. Operator in this case should close the call between the two non-subscribers. The bill should be billed to you, but the call was not with you. For this reason, the operator simply blocks such functionality (and does it right). SBC in this case takes over the question of switching the call and working out with The REFER messages and the operator display two calls (incoming and outgoing), and everything works fine.
b. Call forwarding. For example: Subscriber A called subscriber B, who has call forwarding to subscriber B. And the call goes from subscriber B to subscriber B, while the number A is displayed as the caller's number. And this is correct, since the calling number is the number A, not the one that redirects. This is the telephone standard. And if everything is clearly described in ISDN (E1), since there is a Redirect number field, then here in SIP number B for correct identification can be transferred using History-Info, Referred-By, Diversion. And based on this, operators simply like to block such numbers, referring to the fact that their billing does not work correctly. That is, carrier billing is contrary to the SIP standard, or the operator simply does not want to receive forwarded calls, according to the standard. SBC allows you to convert one format to another in every possible way or simply transfer the number from any field to the From and / or P-Asserted-Identity field.
The remaining examples are not so common, and no less important, since the less often they occur, the more difficult it is to solve them using standard telephone exchange methods. Separately, I want to say about the issues of compatibility and adaptation of voice codecs. The time has passed when everyone supported the G.711 and G.729 codecs, and this is enough. There are a lot of reasons for this, and most importantly, PBX manufacturers seek to improve the quality of communication using their own codecs or specialized codecs, such as SILK / OPUS / MS-RTA. Here the reason is simple (especially if we are talking about the unified communications system) - now all companies are trying to make telephony not only on the IP phone (which can be allocated to a separate VLAN and give traffic priority), but also make telephony everywhere - on tablets, leptopes, smartphones via WiFi, public Internet. And here it is not always possible to prioritize traffic and ensure proper quality in the overall IP stream, and adaptive codecs provide better quality on such networks, relative to G.711 / G.729.
This is where SBC helps you use the codec you want on the network, and dock with the operator using the one that it supports.
Separately, there is the question of DTMF and faxes, which no one has canceled in the VoIP environment. I do not want to delve into this topic, I can only say that at the moment we support all the options for sending both DTMF and faxes.
In fact, you can write about compatibility for a long time, and you can even make separate articles on how to solve this or that problem with the help of our SBC. But in any case, even if your operator says that he will achieve full compatibility with you, the operator does not always achieve this and the timing for setting this compatibility is always large. SBC will allow you to reduce risks and reduce costs when connecting.
')
3. Quality assurance and control
Well, in conclusion, I will write a little about quality assurance and control:
a. Quality assurance - first of all, this is work with voice codecs.
b. Quality control - SBC monitors all calls for a variety of parameters, such as Echo / delay / packet loss / Jitter / MoS and when you have a problem, you immediately and clearly understand which side and for what reason the connection deteriorated, thereby reducing deadlines for fixing problems. SBC also allows you to independently rebuild the route if the quality of communication with a single operator falls. This will preserve call quality without external intervention.
Also, not unimportant factor from the point of view of quality assurance, is the correct setting of routing with the possibility of balancing and reserving routes. Including, if you have a backup interface with the Internet, then it should be included, including for VoIP, regardless of the network equipment settings.
I can not say that these are all the functions and tasks performed by the SBC Border Controller (SBC), especially since it is extremely difficult to list everything. I would even say that, from the point of view of security, compatibility and quality of universal recipes, there is simply no and sometimes each connection is unique and special. Our task here is to provide the maximum number of opportunities so that your use of VoIP meets all your business requirements for an IP telephony system.
Source: https://habr.com/ru/post/251717/
All Articles