Asterisk Security
Good day to you, residents of Habr.
It so happened that I took a distance learning course on the topic "Information Security", at the end of which it was necessary to protect my graduation work. I chose “Asterisk Security” as the topic for this work, a lot of articles and publications have been written on this topic, but in my opinion they are either incomplete, or do not fully cover this topic, or there is no indication of the relevance of this issue. I took the liberty of collecting “everything” into one document, which resulted in the final work. He defended himself successfully, received a diploma - decided to share this work with the community.
1. Risks associated with Asterisk IP-PBX
Everyone knows that in the age of information technology, the actions of attackers (hackers) bring huge losses to organizations. As a rule, the most painful attacks are those aimed at causing harm to the organization or the direct theft of funds. Despite the fact that Asterisk is a telephone exchange based on a computer platform, but due to the fact that communication channels go through the Internet (some system services are open to the outside world), hackers are able to gain unauthorized access to the system.
When building a security system for IP telephony solutions, it is important to be aware of the risks involved. In general, they can be distinguished as follows:
1. Violation of confidentiality and distortion of content. Interception session.
2. Penetration into the organization’s network through vulnerabilities that appeared during the deployment of IP-telephony.
3. Actions aimed at deteriorating services (Dos attacks).
4. Resale traffic (Toll-Fraud).
Reselling traffic is one of the most convenient ways for hackers to make money. Hacking the station and sending calls to expensive international destinations, the hacker receives a certain reward for his electronic wallets, then they are cashed and real money is received. Consider in more detail a typical traffic resale scheme.
There is a hacker who wants to make money by reselling traffic. He goes to the drain traffic exchange, registers and receives some pool of numbers that can identify him in the future. Further, through some fake servers, IP-ATC servers are discovered and, if it turns out, are hacked. Further, calls begin to go to numbers that were provided to the hacker at the drain traffic exchange. Calls are paid. Let's say a call costs 10 rubles. (payment of the victim to the operator). The call is sent, usually abroad (usually Cuba, Palestine, Romania, Latvia, etc.), to countries where cyber crime is not given due attention, that is, where there is the opportunity to do this kind of business. And so the Victim pays OS (Telecommunications operator) 10 rubles per minute. OS goes to international lines through OMT (operator of international traffic), which he pays in the region of 8 rubles. per minute, then OMT sends a call to a local operator (Cuba, Palestine, etc.), which is engaged in the "washing" of voice traffic and pays him 6 rubles. per minute, this operator is in share and he distributes the money as follows - part of the money goes to him in payment for services (so to speak, earns this amount - leaves in his account), and the honor of the money is sent to the drain traffic exchange where the hacker is registered . Further, the exchange, leaving itself one ruble, pays two to the hacker. Visible, the diagram is shown in Fig. 1. this operator is in share and he distributes the money in the following way - part of the money goes to him in payment for the services (so to speak, earns this amount - leaves in his account), and the honor of the money is sent to the drain traffic exchange where the hacker is registered. Further, the exchange, leaving itself one ruble, pays two to the hacker. Visible, the diagram is shown in Fig. 1. this operator is in share and he distributes the money in the following way - part of the money goes to him in payment for the services (so to speak, earns this amount - leaves in his account), and the honor of the money is sent to the drain traffic exchange where the hacker is registered. Further, the exchange, leaving itself one ruble, pays two to the hacker. Visible, the diagram is shown in Fig. 1.
Fig. 1. Resale scheme for Voip traffic
Given that the directions are chosen expensive and the flow of calls is intense, the hacker makes a good profit. And due to the fact that sometimes systems are not properly protected, hacking occurs quickly and without any time-consuming and financially expensive things - Asterisk becomes a "red rag". Well, after all the manipulations, the victim will receive a large bill (10-100 000 rubles) by telephony.
Unfortunately, these kinds of problems have recently become frequent. Therefore, many believe that Asterisk is an unsafe system. However, I want to challenge this thesis. Firstly, if we talk about the capabilities of Asterisk itself, then it has a very rich set of security tools. Asterisk's toolkit is stronger than many competitors. However, Asterisk is very often hacked. How so? Why is that? It's all about the administrator of this system. There is no single tick to activate Asterisk security. Asterisk security is the adoption of a number of comprehensive measures that, as a rule, administrators forget about, thereby exposing Asterisk to threats.
2. Multilevel protection of IP-PBX Asterisk
Speaking about the security of the IP-ATC solution in general, you need to understand that security is based not only on the security of Asterisk itself, it is also necessary to ensure the security and surroundings of Asterisk.
The IP-ATC protection system is built on several levels.
1. Network protection.
2. Network design.
3. Log analysis.
4. Asterisk configuration.
5. Protection plan call routing (dialplan).
6. Linux configuration.
7. Protection of peripheral devices.
8. Administrative measures.
If you define globally what is the problem of Asterisk in terms of security, then as stated above - this problem is not the competence of the administrator of Asterisk.
Due to the fact that there are “box solutions” - installed and it worked, we get a very large number of installed Asterisk servers without the proper security settings and the necessary administrator qualifications, as a result of which we get a hacked Asterisk, loss of organization’s financial resources, and a shadow in the name of Asterisk. Either a non-competent integrator did not properly install the server and after payment it disappears. And the client later receives huge bills by telephony or the operator blocks their directions.
Let's look at the typical mistakes made by novice Asterisk administrators.
1. Weak passwords on internal numbers (Lack of passwords, password is the same as ext).
2. Lack of a firewall (Lack of iptables, either iptables is turned off, or it is configured incorrectly).
3. Old distributions and Software (Old software may contain vulnerabilities. Constant system updates are required. As an example, trixbox is no longer supported, is not updated - there are vulnerabilities).
4. Standard logins and passwords (Web interface, Sql, equipment).
5. Network design (Asterisk and equipment working with it at an external address, but without protection - this is a tidbit for hackers).
6. Errors in the configuration.
7. Lack of control over the system (set and forgot, no control of logs).
2.1
Firewall When deploying a system, it is important to use a firewall. Linux has a powerful and flexible IPTables tool that is command driven. By default, IPTables is configured as follows.
-A INPUT –m state --state ESTABLISHED, RELATED –j ACCEPT (allow packets for already established connections)
-A INPUT –p icmp –j ACCEPT (allow icmp packets)
-A INPUT –i lo –j ACCEPT (allow traffic from the interface lo)
-A INPUT –m state --state NEW –m tcp –p tcp –dport 22 –j ACCEPT (allow a new connection ssh)
-A INPUT –j REJECT --reject-with icmp-host-prohibited (disable all other incoming connections)
-A FORWARD –j REJECT - reject-with icmp-host-prohibited (prohibit all transit connections)
COMMIT
This “config” defines - Allow the connections we initiate, deny all incoming connections except ssh. Next, we configure for your tasks. The config is located here / etc / sysconfig / iptables. To configure IPTables, the main thing to understand is the philosophy of this tool. The essence of writing rules is to create “chains” into which traffic is driven according to certain classifiers (-s source, -p protocol, -i interface ... ..), where the action on the traffic takes place - we either allow, or deny, or forward it to another the chain. If the traffic ran through all the chains and did not fall under any rule - undefined traffic (more than one classifier did not work), traffic is prohibited. That is, for example, in order for IP phones, softphones from the internal network to be able to connect to the Asterisk server, we need to write a rule
-A INPUT –s xxx.xxx.xxx.xxx/24 –j ACCEPT
By this rule, we allow incoming connections from the network xxx.xxx.xxx.xxx \ 24. Since the package according to the rules runs from top to bottom, it must be understood that this rule will work if we write it higher than the prohibiting rules. Thus, you can configure the firewall so that Asterisk will only service those directions and only those packages that we knowingly trust, and it will be almost impossible for an attacker to get to the server. You can more flexibly configure the firewall logic - we create our own chain for each group of packets (Admin, SIP, IAX2 ...) with their own rules, and in the main INPUT chain, according to the rules, packets are sent in their chains, where appropriate actions are taken.
2.2 Network Design
When designing and implementing the system, you need to pay attention to network design.
Often without any need, Asterisk is connected to the network according to the most vulnerable scheme shown in Fig. 2.
Fig. 2. Not recommended scheme for connecting Asterisk to an external address
The fact that Asterisk is accessible from the Internet is the main threat to the security of the entire system. Any weak password or any vulnerability in the Asterisk source code can be used by attackers to gain unauthorized access to the PBX and make calls at the expense of the company that owns the Asterisk server. In the best case scenario, an attacker could target denial of service.
Strong passwords and regular updates, of course, reduce the risk. Even stronger it can be reduced by specialized means of protection, namely - firewalls (ME). If you connect Asterisk as shown in fig. 3, then the server will be safely closed behind the perimeter of the local network.
Fig. 3. The recommended Asterisk connection scheme using the ME
ME allows outgoing traffic from the Asterisk server to the SIP provider and back through dynamic NAT rules. And the ability to connect users of remote offices is provided through a VPN tunnel. The user first connects via VPN to the enterprise network, and only then, via a virtual channel, to the Asterisk server. Asterisk is no longer visible from the external network, it is not available to the attacker.
We also note another important aspect that you need to pay attention to is the separation of data. It is important to separate voice and data through the construction of Vlan. Computers, servers, other network equipment should be in one Vlan, and equipment working with Asterisk (the server itself, gate, ip-phones ...) in another Vlan. This is done so that users themselves, as well as possible viruses on user machines, cannot harm IP-ATC and vice versa. The scheme with Vlan is presented in fig. 4.
Fig. 4. Separation of voice and data into different Vlan.
2.3 Log Analysis
During the operation of the IP-ATC system, Asterisk itself and other applications log all their activities. Since the log contains data both on authorized actions and on unauthorized actions, it is very important to periodically review them for incidents. It is necessary to control the connections, control the selection of passwords, monitor multiple connection attempts, control unplanned activity.
Asterisk toolkit does not have such a tool as a log analyzer, which under certain conditions would take some action on the connection. There is an unplanned activity, which is important to monitor in order to prevent the possibility of hacking the Asterisk server, one of such activities is the selection of passwords (enumerating passwords in a dictionary). Asterisk does not have such a tool that would prevent brute force passwords, and since this is an important point in security, it is proposed to use the external Fail2Ban service, which can work with many services, such as Asterisk, Apache, ssh, ftp and others. The work of this service is based on one principle, “Detect and Eliminate”, the service “reads” the logs, analyzes them and, upon detection of multiple login attempts, blocks this connection at the IPTables level. In fig.
Fig. 5. The principle of operation of Fail2Ban
. I would also like to note one more recommendation - it is desirable that the logs (logs) about events in the system are either stored remotely or constantly copied to a remote resource. This is due to the fact that the attacker, having gained access to the device, in particular to the IP PBX, tries to hide his presence and his actions by deleting all events from the log files. If the logs are sent to a remote server, it will make it difficult or impossible to hide their presence.
2.4 Asterisk configuration
In this chapter, we will consider system protection at the Asterisk configuration level. And so, what we need to configure in Asterisk itself is to increase the security of IP-ATC.
If Asterisk "sits" on an external address and there is no way to use IPTables (the situation when you need to connect a device with a dynamic ip address), or vpn is not used, then the first thing to do is change the standard port 5060 (sip) to any other. Thus, we will avert our suspicions that our Asterisk server will not attack it further. We will protect ourselves from the BruteForce attack from the outside.
How to do it. Edit the sip.conf
[general] file
; bindport = 5060 ; Commented out the standard parameter.
bindport = 9060 ; Change the default port to another free port - for security reasons.
Do not forget to indicate on the terminal devices the port to which we changed the standard one. Since by default, devices will try to connect to Asterisk on port 5060, and nothing will work.
What else can we improve system security at the sip.conf configuration level.
[general]
alwaysauthreject = yes; We protect the server from enumeration by numbers. If the value is no, then the server will faithfully respond that there is no such subscriber, until the attacker guesses the existing ext, then the server will reply that the password is incorrect. Thus, the attacker learns about the existence of the extension number, it remains only to pick up the password. Next, there is a password search for a very specific extension number. The yes option rejects authentication requests for existing users for the same reason as non-existent users. This makes it difficult for scammers to figure out existing ext.
allowguest = no ; We prohibit connections to the server in direct sip calls mode, so-called guest calls, when you can call a subscriber by his E-mail.
bindaddr = xxx.xxx.xxx.xxx; At what address will Asterisk listen for network connections using the sip protocol. This is if the server is connected to various networks, it is better to explicitly specify from which network to receive sip.
[1000]
deny = 0.0.0.0 / 0.0.0.0 ; We prohibit connection from all addresses
permit = xxx.xxx.xxx.xxx / 24 ; Allow connections from the network xxx.xxx.xxx.xxx
secret = bdDfg12312fc ; Strong passwords are required, different from standard things (admin, ext, 1000, password ...)
call-limit = 2 ; We set a limit on the number of simultaneous lines for the subscriber.
2.5 Call Routing Plan Protection (dialplan)
Using well-written dialplan (call routing plan) can significantly improve security. The first thing that is recommended is the separation of subscribers into contexts with their own routing rules.
In sip.conf
[1000]
context = from_chef
[1001]
context = from_it
[1002]
context = from_fin
The separation of contexts gives us the opportunity to give different rights to subscribers for telephone communications. This is important, since not everyone needs, say, to call international destinations. Next, we assign the rules to the contexts. In extension. conf
[allow]
exten => _ X., n, Dial (SIP / operator / $ {EXTEN}) ; We allow any calls through the Operator
exten => _ [12] XXX, n, Dial (SIP / $ {EXTEN}); We allow internal connections
[from_chef]
exten => _X., N, Goto (allow, $ {EXTEN}, 1) ; We direct all calls to the context [allow]
[from_it]
exten => _9810., N, Hungup () ; We limit the international directions
exten => _X., N, Goto (allow, $ {EXTEN}, 1) ; We direct all calls to the context [allow]
[from_fin]
exten => _9810., N, Hungup () ; We limit the international directions
exten => _989., N, Hungup () ; We limit directions to cellular directions.
exten => _X., n, Goto (allow, $ {EXTEN}, 1) ; We direct all calls to the context [allow]
Thus, the financial department is prohibited calls to international destinations and to mobile destinations. It only bans international destinations. Well, the head is allowed any connections.
In order to receive information about prohibited calls to e-mail, we will teach Asterisk to fiscal about violations. For this we add another context [alarm].
[alarm]
exten => _9810X., 1, playback (zapresheno) ; We inform the subscriber that he is prohibited in this direction.
exten => _9810X., n, System (echo "To" $ {EXTEN} "Ext" $ {CALLERID (num)} | mail -s "8-10 ALARM" it_admin@list.ru) ; Fiscalit to mail if there are international calls.
exten => _9810X., n, Hangup () ; put the phone down.
And we send forbidden calls to this context
[allow]
exten => _ X., n, Dial (SIP / operator / $ {EXTEN}) ; We allow any calls through the Operator
exten => _ [12] XXX, n, Dial (SIP / $ {EXTEN}) ; We allow internal connections
[from_chef]
exten => _X., N, Goto (allow, $ {EXTEN}, 1) ; We direct all calls to the context [allow]
[from_it]
exten => _9810., N, Goto (alarm, $ {EXTEN}, 1) ; We direct international calls to the context [alarm]
exten => _X., N, Goto (allow, $ {EXTEN}, 1) ; We direct all calls to the context [allow]
[from_fin]
exten => _9810., N, Goto (alarm, $ {EXTEN}, 1) ; We direct international calls to the context [alarm]
exten => _989., N, Hungup () ; We limit directions to cellular directions.
exten => _X., n, Goto (allow, $ {EXTEN}) ; We direct all calls to the context [allow]
Thus, we not only block prohibited directions, but also in the event of an incident we get a message who (ext) is trying to get through. Thus, we will be able to understand in time that the server is hacked, and not when huge communication bills arrive.
That's what Asterisk is good for, dilplan allows you to flexibly configure routing. We can prohibit directions according to various parameters, we can differentiate rights for subscribers, we can set up notifications about barred calls, you can also set time limits for calls, we can set up pin-code calls and much more, which can improve IP-ATC security. It is recommended to use the pin code for remote users with a dynamic ip address, since it is impossible to restrict permit / deny and iptables, in this case it is advisable to close international destinations, change the standard port (5060) to something else, and route calls by pin code.
2.6 Linux configuration
Both in Asterisk itself and in the Linux OS itself, there are services that are launched by default, but they are not needed for work. Therefore, one of the recommendations is the need to disable unused services (modules) in both Asterisk and Linux.
Asterisk loads a large number of modules, which in principle may never be useful - various codecs, commands, tools for working with the database, channels. Disabling unnecessary modules will not only free up memory, but also make IP-ATC less vulnerable. What we are striving for. And since it can be done.
The autoload = yes parameter is specified in the /etc/asterisk/modules.conf file, which forces Asterisk to initialize and start all services located in the / usr / lib / asterisk / modules folder at boot time. In order to prohibit the start of one or another unnecessary service, it is necessary to write the following lines in the
/etc/asterisk/modules.conf file noload => chan_gtalk.so ; Gtalk Channel Module.
noload => app_morsecode.so ; Transmission of a given string in Morse code.
noload => cdr_pgsql.so ; Module for storing CDR data in a PostgreSQL database.
and others depending on which modules are needed and which are not.
Also directly in Linux itself there are services that are loaded, but possibly not needed for IP-ATC to work - it is also advisable to disable them. You can use the chkconfig –list command to see which services are running and determine which services are redundant. Suppose, in CentOS 5, the bluetooth service is loaded by default, on the Asterisk telephone exchange this service is not needed, we will remove it from startup with the chkconfig bluetooth off command. We will do the same with other unnecessary services. All these manipulations must be done very carefully and thoughtfully, otherwise you can “put” both the OS itself and the Asterisk server.
To administer the OS and Asterisk, the IP-ATC administrator needs remote access. It is not recommended to use protocols for remote access without encryption (for example telnet); it is recommended to use SSH (Secure SHell). The SSH service used to access the server remotely is the main door to the PBX control center. To increase the security level, the PBX administrator is recommended to perform the following measures.
1. Change of port. The default SSH port is the 22nd. Many hackers scan the Internet for servers with open port 22, and then try to crack them. You need to come up with a different port, in the range 1-65535, and specify it in the Port directive to configure ssh.
Also, we forget to indicate this port in the client when connecting to the server.
2. Explicit listing of users who have access to the system via SSH protocol in the [AllowUsers] directive. In the event that it is still necessary to provide access to the system to a number of proxies, list them.
3. It is recommended that you use only the SSH protocol version 2.
4. Deny direct root access. This will significantly complicate and rather make it impossible to attack the brute force password, as root will be denied access to the system, even if his correct password is entered. Use the sudo subsystem to obtain root access if necessary and only after remote login under an unprivileged account.
5. Use a time limit for entering passwords or certificates. Setting the minimum possible time for entering a password, for example, 1 second, can well confuse an attacker.
All the above recommendations are reflected in the configuration file / etc / ssh / sshd_config
Port 30222
AllowUsers ats admin
Protocol 2
PermitRootLogin no
LoginGraceTime 1s
It is also good practice to enter SSH using certificates. If you often use SSH to connect to a remote host, one of the ways to secure your connection is to use a public / private SSH key, since no password is transmitted over the network and the system is resistant to brute force attacks.
Creating a public / private SSH key in Linux is very simple.
1. In the console, enter ssh-keygen –t rsa. In this case, RSA is an asymmetric encryption algorithm. You can also use DSA (Digital Signature Algorithm).
2. Next, it is proposed to specify the location for saving the key. By default, this is the .ssh folder in your home directory. In order to accept the default settings, just press “Enter”.
3. Next, we are asked to enter the passphrase. This is not a passphrase for connecting to a remote host. This is the passphrase for unlocking the private key, so it won’t help you access the remote server, even if your private key is stored on it. Entering a passphrase is optional. To leave it empty, press Enter.
4. Our keys are generated. We go to the home directory in the .ssh folder, our keys id_rsa and id_rsa.pub should be located there.
5. Next, edit the configuration file / etc / ssh / sshd_config
RSAAuthentication yes
PubkeyAuthentication yes
PasswordAuthentication no
Thus, we only allow ssh login using a certificate.
6. The contents of the id_rsa.pub file are copied to the newly created authorized_keys file.
We copy and create the file with the cat id_rsa.pub >> authorized_keys command
7. We set the read and write permissions on the file
chmod 600 authorized_keys
8. Copy the id_rsa private key to the computer from which we will Connect to the server via SSH.
9. In order for the client (Putty) to understand this private key, run it (load) it through the puttygen program. At the output (Save private key) we get the private key (* .ppk).
10. Now add the key to the session. We start PuTTY, load the necessary session or enter the data for the connection and go to "SSH - Auth", select our private key, which was obtained through the processing of "puttygen".
11. We go to the menu “Connection - Data” and in the field “Auto-login username” enter the login under which the key is generated.
12. Save the session, restart the SSH service on the /etc/init.d/ssh reload server
13. Connect.
Thus, we have increased the security of the SSH connection.
2.7 Protection of peripheral devices
One of the important points is the protection of equipment that connects to Asterisk in one way or another, such equipment is ip-phones, voip-gate and others. An IP-ATC system cannot be secure unless peripherals are protected. To protect this equipment, it is proposed to carry out a number of measures:
1. This is an update of the equipment software. It is important to monitor this aspect and in the event of a new “firmware”, update it on the appropriate device. Many vulnerabilities are addressed through updates.
2. This point has already been discussed above. If possible, place the ip equipment in a separate Vlan from the data.
3. Place the equipment behind the firewall. It is highly undesirable to give ip equipment external ip addresses.
4. The vulnerability is the web-based interface of the equipment. In order to protect equipment from hacking through the Web-based interface, it is recommended to disable it for ip phones, as it does not carry a large semantic load, or set a strong password for voip-gate.
5. Change of service ports. As with Astersik, it is recommended that you change the sip port from 5060 to any other on IP phones and voip-gate. Thereby increasing the resistance to scanning.
If we are talking about a softphone that is installed on a computer, then it's hard to talk about security. The only effective measure in this case is limited contexts with the ability to notify the administrator of an attempt to make a forbidden call.
2.8 Administrative measures
Even if all the recommendations described above are followed, the system can still be hacked - there is no absolute security. Therefore, administrative measures are important. Consider them.
1. If the organization does not need international calls, then you can block international destinations at the level of a telecom operator. If there are very few such calls, you can agree with the provider about some monitoring of this direction - in case of a large number of calls to international destinations - block these connections.
2. You can also go for a simple but effective method - this is to limit the amount of the bill for communication at the operator level. You can ask the telecom operator to set a limit, which we determine for ourselves (average annual monthly payment for communication + a certain%), and if the limit is reached, communication is blocked. This measure will not let go into a deep minus in case of hacking IP-ATC.
3. Protection of workstations with softphones.
4. Change passwords when changing the administrator.
5. Raising staff awareness.
6. One of the most important points - do not forget that there is no absolute protection. It is necessary to constantly monitor and audit the system for new vulnerabilities, the emergence of new risks, etc., and if something is detected, take this into account in the system’s security system. That is, the "Deming cycle" is required to apply to this system.
Conclusion
I hope that this work has revealed the thesis that, with proper system configuration, Asterisk can be made one of the safest systems with great functionality in the telephony field, and this system is not inferior in functionality to commercial solutions from leading vendors such as Cisco, Avaya, etc. .
Well, the fact that according to statistics they hack more often than Asterisk is determined by the fact that Asterisk has a lot less entry threshold than other systems. That is, a Malomalian it-specialist, after reading a couple of articles on the Internet, can deploy Asterisk, but since qualifications are still lacking, the system, as a rule, turns out to be working, but vulnerable. And for the deployment of commercial solutions, specialists in their field are required who pay due attention to security issues. For this simple reason, Asterisk is hacked more often.
IP-ATC Asterisk is a secure system when configured correctly.
List of references
1. Meggelen J., Madsen L., Smith J. Asterisk ™: the future of telephony, 2nd edition. - Per. from English - St. Petersburg: Symbol-Plus, 2009 .-- 656 p., Ill.
2. Platov M. Asterisk and Linux - IP-telephony mission [Text] / M. Platov // System Administrator. -2005 -№ 31.- S. 12-19.
3. Platov M. Asterisk and Linux: the mission of IP-telephony. Action 2 [Text] / M. Platov // System Administrator. -2005, No. 32. - S. 32-38.
4. Platov M. Asterisk and Linux: the mission of IP-telephony. Action 3 [Text] / M. Platov // System Administrator. -2005, No. 33. - S. 10-19.
5. Asterisk Knowledge Base [Electronic resource]. –– access mode: asterisk.ru/knowledgebase
6. Voxlink Knowledge Base [Electronic resource]. - access mode: www.voxlink.ru/kb
7. HabrHabr. Security in VoIP networks [Electronic resource]. - access mode: habrahabr.ru/post/145206
8. Roslyakov A.V., Samsonov M.Yu., Shibaeva I.V. IP telephony. –M .: Eco-Trends, 2003. -252 pp., Ill.
9. Goldstein B.S., Pinchuk A.V., Sukhovitsky A.L. IP telephony. –M .: Radio and communications, 2001. -336 p.: Ill.
10. CITForum. IP Telephony Security - Field Sketches. A. Veselov [Electronic resource]. - access mode: citforum.ru/security/articles/ipsec
PS
Special thanks for the understanding of this issue to Voxlink CEO Sergey Grushko and his work.
I understand that the topic is hackneyed and everyone seems to know everything, but at the same time, hacked IP stations are not getting smaller. I hope that the article will be at least useful to someone.
It so happened that I took a distance learning course on the topic "Information Security", at the end of which it was necessary to protect my graduation work. I chose “Asterisk Security” as the topic for this work, a lot of articles and publications have been written on this topic, but in my opinion they are either incomplete, or do not fully cover this topic, or there is no indication of the relevance of this issue. I took the liberty of collecting “everything” into one document, which resulted in the final work. He defended himself successfully, received a diploma - decided to share this work with the community.
1. Risks associated with Asterisk IP-PBX
Everyone knows that in the age of information technology, the actions of attackers (hackers) bring huge losses to organizations. As a rule, the most painful attacks are those aimed at causing harm to the organization or the direct theft of funds. Despite the fact that Asterisk is a telephone exchange based on a computer platform, but due to the fact that communication channels go through the Internet (some system services are open to the outside world), hackers are able to gain unauthorized access to the system.
When building a security system for IP telephony solutions, it is important to be aware of the risks involved. In general, they can be distinguished as follows:
1. Violation of confidentiality and distortion of content. Interception session.
2. Penetration into the organization’s network through vulnerabilities that appeared during the deployment of IP-telephony.
3. Actions aimed at deteriorating services (Dos attacks).
4. Resale traffic (Toll-Fraud).
Reselling traffic is one of the most convenient ways for hackers to make money. Hacking the station and sending calls to expensive international destinations, the hacker receives a certain reward for his electronic wallets, then they are cashed and real money is received. Consider in more detail a typical traffic resale scheme.
There is a hacker who wants to make money by reselling traffic. He goes to the drain traffic exchange, registers and receives some pool of numbers that can identify him in the future. Further, through some fake servers, IP-ATC servers are discovered and, if it turns out, are hacked. Further, calls begin to go to numbers that were provided to the hacker at the drain traffic exchange. Calls are paid. Let's say a call costs 10 rubles. (payment of the victim to the operator). The call is sent, usually abroad (usually Cuba, Palestine, Romania, Latvia, etc.), to countries where cyber crime is not given due attention, that is, where there is the opportunity to do this kind of business. And so the Victim pays OS (Telecommunications operator) 10 rubles per minute. OS goes to international lines through OMT (operator of international traffic), which he pays in the region of 8 rubles. per minute, then OMT sends a call to a local operator (Cuba, Palestine, etc.), which is engaged in the "washing" of voice traffic and pays him 6 rubles. per minute, this operator is in share and he distributes the money as follows - part of the money goes to him in payment for services (so to speak, earns this amount - leaves in his account), and the honor of the money is sent to the drain traffic exchange where the hacker is registered . Further, the exchange, leaving itself one ruble, pays two to the hacker. Visible, the diagram is shown in Fig. 1. this operator is in share and he distributes the money in the following way - part of the money goes to him in payment for the services (so to speak, earns this amount - leaves in his account), and the honor of the money is sent to the drain traffic exchange where the hacker is registered. Further, the exchange, leaving itself one ruble, pays two to the hacker. Visible, the diagram is shown in Fig. 1. this operator is in share and he distributes the money in the following way - part of the money goes to him in payment for the services (so to speak, earns this amount - leaves in his account), and the honor of the money is sent to the drain traffic exchange where the hacker is registered. Further, the exchange, leaving itself one ruble, pays two to the hacker. Visible, the diagram is shown in Fig. 1.
Fig. 1. Resale scheme for Voip traffic
Given that the directions are chosen expensive and the flow of calls is intense, the hacker makes a good profit. And due to the fact that sometimes systems are not properly protected, hacking occurs quickly and without any time-consuming and financially expensive things - Asterisk becomes a "red rag". Well, after all the manipulations, the victim will receive a large bill (10-100 000 rubles) by telephony.
Unfortunately, these kinds of problems have recently become frequent. Therefore, many believe that Asterisk is an unsafe system. However, I want to challenge this thesis. Firstly, if we talk about the capabilities of Asterisk itself, then it has a very rich set of security tools. Asterisk's toolkit is stronger than many competitors. However, Asterisk is very often hacked. How so? Why is that? It's all about the administrator of this system. There is no single tick to activate Asterisk security. Asterisk security is the adoption of a number of comprehensive measures that, as a rule, administrators forget about, thereby exposing Asterisk to threats.
2. Multilevel protection of IP-PBX Asterisk
Speaking about the security of the IP-ATC solution in general, you need to understand that security is based not only on the security of Asterisk itself, it is also necessary to ensure the security and surroundings of Asterisk.
The IP-ATC protection system is built on several levels.
1. Network protection.
2. Network design.
3. Log analysis.
4. Asterisk configuration.
5. Protection plan call routing (dialplan).
6. Linux configuration.
7. Protection of peripheral devices.
8. Administrative measures.
If you define globally what is the problem of Asterisk in terms of security, then as stated above - this problem is not the competence of the administrator of Asterisk.
Due to the fact that there are “box solutions” - installed and it worked, we get a very large number of installed Asterisk servers without the proper security settings and the necessary administrator qualifications, as a result of which we get a hacked Asterisk, loss of organization’s financial resources, and a shadow in the name of Asterisk. Either a non-competent integrator did not properly install the server and after payment it disappears. And the client later receives huge bills by telephony or the operator blocks their directions.
Let's look at the typical mistakes made by novice Asterisk administrators.
1. Weak passwords on internal numbers (Lack of passwords, password is the same as ext).
2. Lack of a firewall (Lack of iptables, either iptables is turned off, or it is configured incorrectly).
3. Old distributions and Software (Old software may contain vulnerabilities. Constant system updates are required. As an example, trixbox is no longer supported, is not updated - there are vulnerabilities).
4. Standard logins and passwords (Web interface, Sql, equipment).
5. Network design (Asterisk and equipment working with it at an external address, but without protection - this is a tidbit for hackers).
6. Errors in the configuration.
7. Lack of control over the system (set and forgot, no control of logs).
2.1
Firewall When deploying a system, it is important to use a firewall. Linux has a powerful and flexible IPTables tool that is command driven. By default, IPTables is configured as follows.
-A INPUT –m state --state ESTABLISHED, RELATED –j ACCEPT (allow packets for already established connections)
-A INPUT –p icmp –j ACCEPT (allow icmp packets)
-A INPUT –i lo –j ACCEPT (allow traffic from the interface lo)
-A INPUT –m state --state NEW –m tcp –p tcp –dport 22 –j ACCEPT (allow a new connection ssh)
-A INPUT –j REJECT --reject-with icmp-host-prohibited (disable all other incoming connections)
-A FORWARD –j REJECT - reject-with icmp-host-prohibited (prohibit all transit connections)
COMMIT
This “config” defines - Allow the connections we initiate, deny all incoming connections except ssh. Next, we configure for your tasks. The config is located here / etc / sysconfig / iptables. To configure IPTables, the main thing to understand is the philosophy of this tool. The essence of writing rules is to create “chains” into which traffic is driven according to certain classifiers (-s source, -p protocol, -i interface ... ..), where the action on the traffic takes place - we either allow, or deny, or forward it to another the chain. If the traffic ran through all the chains and did not fall under any rule - undefined traffic (more than one classifier did not work), traffic is prohibited. That is, for example, in order for IP phones, softphones from the internal network to be able to connect to the Asterisk server, we need to write a rule
-A INPUT –s xxx.xxx.xxx.xxx/24 –j ACCEPT
By this rule, we allow incoming connections from the network xxx.xxx.xxx.xxx \ 24. Since the package according to the rules runs from top to bottom, it must be understood that this rule will work if we write it higher than the prohibiting rules. Thus, you can configure the firewall so that Asterisk will only service those directions and only those packages that we knowingly trust, and it will be almost impossible for an attacker to get to the server. You can more flexibly configure the firewall logic - we create our own chain for each group of packets (Admin, SIP, IAX2 ...) with their own rules, and in the main INPUT chain, according to the rules, packets are sent in their chains, where appropriate actions are taken.
2.2 Network Design
When designing and implementing the system, you need to pay attention to network design.
Often without any need, Asterisk is connected to the network according to the most vulnerable scheme shown in Fig. 2.
Fig. 2. Not recommended scheme for connecting Asterisk to an external address
The fact that Asterisk is accessible from the Internet is the main threat to the security of the entire system. Any weak password or any vulnerability in the Asterisk source code can be used by attackers to gain unauthorized access to the PBX and make calls at the expense of the company that owns the Asterisk server. In the best case scenario, an attacker could target denial of service.
Strong passwords and regular updates, of course, reduce the risk. Even stronger it can be reduced by specialized means of protection, namely - firewalls (ME). If you connect Asterisk as shown in fig. 3, then the server will be safely closed behind the perimeter of the local network.
Fig. 3. The recommended Asterisk connection scheme using the ME
ME allows outgoing traffic from the Asterisk server to the SIP provider and back through dynamic NAT rules. And the ability to connect users of remote offices is provided through a VPN tunnel. The user first connects via VPN to the enterprise network, and only then, via a virtual channel, to the Asterisk server. Asterisk is no longer visible from the external network, it is not available to the attacker.
We also note another important aspect that you need to pay attention to is the separation of data. It is important to separate voice and data through the construction of Vlan. Computers, servers, other network equipment should be in one Vlan, and equipment working with Asterisk (the server itself, gate, ip-phones ...) in another Vlan. This is done so that users themselves, as well as possible viruses on user machines, cannot harm IP-ATC and vice versa. The scheme with Vlan is presented in fig. 4.
Fig. 4. Separation of voice and data into different Vlan.
2.3 Log Analysis
During the operation of the IP-ATC system, Asterisk itself and other applications log all their activities. Since the log contains data both on authorized actions and on unauthorized actions, it is very important to periodically review them for incidents. It is necessary to control the connections, control the selection of passwords, monitor multiple connection attempts, control unplanned activity.
Asterisk toolkit does not have such a tool as a log analyzer, which under certain conditions would take some action on the connection. There is an unplanned activity, which is important to monitor in order to prevent the possibility of hacking the Asterisk server, one of such activities is the selection of passwords (enumerating passwords in a dictionary). Asterisk does not have such a tool that would prevent brute force passwords, and since this is an important point in security, it is proposed to use the external Fail2Ban service, which can work with many services, such as Asterisk, Apache, ssh, ftp and others. The work of this service is based on one principle, “Detect and Eliminate”, the service “reads” the logs, analyzes them and, upon detection of multiple login attempts, blocks this connection at the IPTables level. In fig.
Fig. 5. The principle of operation of Fail2Ban
. I would also like to note one more recommendation - it is desirable that the logs (logs) about events in the system are either stored remotely or constantly copied to a remote resource. This is due to the fact that the attacker, having gained access to the device, in particular to the IP PBX, tries to hide his presence and his actions by deleting all events from the log files. If the logs are sent to a remote server, it will make it difficult or impossible to hide their presence.
2.4 Asterisk configuration
In this chapter, we will consider system protection at the Asterisk configuration level. And so, what we need to configure in Asterisk itself is to increase the security of IP-ATC.
If Asterisk "sits" on an external address and there is no way to use IPTables (the situation when you need to connect a device with a dynamic ip address), or vpn is not used, then the first thing to do is change the standard port 5060 (sip) to any other. Thus, we will avert our suspicions that our Asterisk server will not attack it further. We will protect ourselves from the BruteForce attack from the outside.
How to do it. Edit the sip.conf
[general] file
; bindport = 5060 ; Commented out the standard parameter.
bindport = 9060 ; Change the default port to another free port - for security reasons.
Do not forget to indicate on the terminal devices the port to which we changed the standard one. Since by default, devices will try to connect to Asterisk on port 5060, and nothing will work.
What else can we improve system security at the sip.conf configuration level.
[general]
alwaysauthreject = yes; We protect the server from enumeration by numbers. If the value is no, then the server will faithfully respond that there is no such subscriber, until the attacker guesses the existing ext, then the server will reply that the password is incorrect. Thus, the attacker learns about the existence of the extension number, it remains only to pick up the password. Next, there is a password search for a very specific extension number. The yes option rejects authentication requests for existing users for the same reason as non-existent users. This makes it difficult for scammers to figure out existing ext.
allowguest = no ; We prohibit connections to the server in direct sip calls mode, so-called guest calls, when you can call a subscriber by his E-mail.
bindaddr = xxx.xxx.xxx.xxx; At what address will Asterisk listen for network connections using the sip protocol. This is if the server is connected to various networks, it is better to explicitly specify from which network to receive sip.
[1000]
deny = 0.0.0.0 / 0.0.0.0 ; We prohibit connection from all addresses
permit = xxx.xxx.xxx.xxx / 24 ; Allow connections from the network xxx.xxx.xxx.xxx
secret = bdDfg12312fc ; Strong passwords are required, different from standard things (admin, ext, 1000, password ...)
call-limit = 2 ; We set a limit on the number of simultaneous lines for the subscriber.
2.5 Call Routing Plan Protection (dialplan)
Using well-written dialplan (call routing plan) can significantly improve security. The first thing that is recommended is the separation of subscribers into contexts with their own routing rules.
In sip.conf
[1000]
context = from_chef
[1001]
context = from_it
[1002]
context = from_fin
The separation of contexts gives us the opportunity to give different rights to subscribers for telephone communications. This is important, since not everyone needs, say, to call international destinations. Next, we assign the rules to the contexts. In extension. conf
[allow]
exten => _ X., n, Dial (SIP / operator / $ {EXTEN}) ; We allow any calls through the Operator
exten => _ [12] XXX, n, Dial (SIP / $ {EXTEN}); We allow internal connections
[from_chef]
exten => _X., N, Goto (allow, $ {EXTEN}, 1) ; We direct all calls to the context [allow]
[from_it]
exten => _9810., N, Hungup () ; We limit the international directions
exten => _X., N, Goto (allow, $ {EXTEN}, 1) ; We direct all calls to the context [allow]
[from_fin]
exten => _9810., N, Hungup () ; We limit the international directions
exten => _989., N, Hungup () ; We limit directions to cellular directions.
exten => _X., n, Goto (allow, $ {EXTEN}, 1) ; We direct all calls to the context [allow]
Thus, the financial department is prohibited calls to international destinations and to mobile destinations. It only bans international destinations. Well, the head is allowed any connections.
In order to receive information about prohibited calls to e-mail, we will teach Asterisk to fiscal about violations. For this we add another context [alarm].
[alarm]
exten => _9810X., 1, playback (zapresheno) ; We inform the subscriber that he is prohibited in this direction.
exten => _9810X., n, System (echo "To" $ {EXTEN} "Ext" $ {CALLERID (num)} | mail -s "8-10 ALARM" it_admin@list.ru) ; Fiscalit to mail if there are international calls.
exten => _9810X., n, Hangup () ; put the phone down.
And we send forbidden calls to this context
[allow]
exten => _ X., n, Dial (SIP / operator / $ {EXTEN}) ; We allow any calls through the Operator
exten => _ [12] XXX, n, Dial (SIP / $ {EXTEN}) ; We allow internal connections
[from_chef]
exten => _X., N, Goto (allow, $ {EXTEN}, 1) ; We direct all calls to the context [allow]
[from_it]
exten => _9810., N, Goto (alarm, $ {EXTEN}, 1) ; We direct international calls to the context [alarm]
exten => _X., N, Goto (allow, $ {EXTEN}, 1) ; We direct all calls to the context [allow]
[from_fin]
exten => _9810., N, Goto (alarm, $ {EXTEN}, 1) ; We direct international calls to the context [alarm]
exten => _989., N, Hungup () ; We limit directions to cellular directions.
exten => _X., n, Goto (allow, $ {EXTEN}) ; We direct all calls to the context [allow]
Thus, we not only block prohibited directions, but also in the event of an incident we get a message who (ext) is trying to get through. Thus, we will be able to understand in time that the server is hacked, and not when huge communication bills arrive.
That's what Asterisk is good for, dilplan allows you to flexibly configure routing. We can prohibit directions according to various parameters, we can differentiate rights for subscribers, we can set up notifications about barred calls, you can also set time limits for calls, we can set up pin-code calls and much more, which can improve IP-ATC security. It is recommended to use the pin code for remote users with a dynamic ip address, since it is impossible to restrict permit / deny and iptables, in this case it is advisable to close international destinations, change the standard port (5060) to something else, and route calls by pin code.
2.6 Linux configuration
Both in Asterisk itself and in the Linux OS itself, there are services that are launched by default, but they are not needed for work. Therefore, one of the recommendations is the need to disable unused services (modules) in both Asterisk and Linux.
Asterisk loads a large number of modules, which in principle may never be useful - various codecs, commands, tools for working with the database, channels. Disabling unnecessary modules will not only free up memory, but also make IP-ATC less vulnerable. What we are striving for. And since it can be done.
The autoload = yes parameter is specified in the /etc/asterisk/modules.conf file, which forces Asterisk to initialize and start all services located in the / usr / lib / asterisk / modules folder at boot time. In order to prohibit the start of one or another unnecessary service, it is necessary to write the following lines in the
/etc/asterisk/modules.conf file noload => chan_gtalk.so ; Gtalk Channel Module.
noload => app_morsecode.so ; Transmission of a given string in Morse code.
noload => cdr_pgsql.so ; Module for storing CDR data in a PostgreSQL database.
and others depending on which modules are needed and which are not.
Also directly in Linux itself there are services that are loaded, but possibly not needed for IP-ATC to work - it is also advisable to disable them. You can use the chkconfig –list command to see which services are running and determine which services are redundant. Suppose, in CentOS 5, the bluetooth service is loaded by default, on the Asterisk telephone exchange this service is not needed, we will remove it from startup with the chkconfig bluetooth off command. We will do the same with other unnecessary services. All these manipulations must be done very carefully and thoughtfully, otherwise you can “put” both the OS itself and the Asterisk server.
To administer the OS and Asterisk, the IP-ATC administrator needs remote access. It is not recommended to use protocols for remote access without encryption (for example telnet); it is recommended to use SSH (Secure SHell). The SSH service used to access the server remotely is the main door to the PBX control center. To increase the security level, the PBX administrator is recommended to perform the following measures.
1. Change of port. The default SSH port is the 22nd. Many hackers scan the Internet for servers with open port 22, and then try to crack them. You need to come up with a different port, in the range 1-65535, and specify it in the Port directive to configure ssh.
Also, we forget to indicate this port in the client when connecting to the server.
2. Explicit listing of users who have access to the system via SSH protocol in the [AllowUsers] directive. In the event that it is still necessary to provide access to the system to a number of proxies, list them.
3. It is recommended that you use only the SSH protocol version 2.
4. Deny direct root access. This will significantly complicate and rather make it impossible to attack the brute force password, as root will be denied access to the system, even if his correct password is entered. Use the sudo subsystem to obtain root access if necessary and only after remote login under an unprivileged account.
5. Use a time limit for entering passwords or certificates. Setting the minimum possible time for entering a password, for example, 1 second, can well confuse an attacker.
All the above recommendations are reflected in the configuration file / etc / ssh / sshd_config
Port 30222
AllowUsers ats admin
Protocol 2
PermitRootLogin no
LoginGraceTime 1s
It is also good practice to enter SSH using certificates. If you often use SSH to connect to a remote host, one of the ways to secure your connection is to use a public / private SSH key, since no password is transmitted over the network and the system is resistant to brute force attacks.
Creating a public / private SSH key in Linux is very simple.
1. In the console, enter ssh-keygen –t rsa. In this case, RSA is an asymmetric encryption algorithm. You can also use DSA (Digital Signature Algorithm).
2. Next, it is proposed to specify the location for saving the key. By default, this is the .ssh folder in your home directory. In order to accept the default settings, just press “Enter”.
3. Next, we are asked to enter the passphrase. This is not a passphrase for connecting to a remote host. This is the passphrase for unlocking the private key, so it won’t help you access the remote server, even if your private key is stored on it. Entering a passphrase is optional. To leave it empty, press Enter.
4. Our keys are generated. We go to the home directory in the .ssh folder, our keys id_rsa and id_rsa.pub should be located there.
5. Next, edit the configuration file / etc / ssh / sshd_config
RSAAuthentication yes
PubkeyAuthentication yes
PasswordAuthentication no
Thus, we only allow ssh login using a certificate.
6. The contents of the id_rsa.pub file are copied to the newly created authorized_keys file.
We copy and create the file with the cat id_rsa.pub >> authorized_keys command
7. We set the read and write permissions on the file
chmod 600 authorized_keys
8. Copy the id_rsa private key to the computer from which we will Connect to the server via SSH.
9. In order for the client (Putty) to understand this private key, run it (load) it through the puttygen program. At the output (Save private key) we get the private key (* .ppk).
10. Now add the key to the session. We start PuTTY, load the necessary session or enter the data for the connection and go to "SSH - Auth", select our private key, which was obtained through the processing of "puttygen".
11. We go to the menu “Connection - Data” and in the field “Auto-login username” enter the login under which the key is generated.
12. Save the session, restart the SSH service on the /etc/init.d/ssh reload server
13. Connect.
Thus, we have increased the security of the SSH connection.
2.7 Protection of peripheral devices
One of the important points is the protection of equipment that connects to Asterisk in one way or another, such equipment is ip-phones, voip-gate and others. An IP-ATC system cannot be secure unless peripherals are protected. To protect this equipment, it is proposed to carry out a number of measures:
1. This is an update of the equipment software. It is important to monitor this aspect and in the event of a new “firmware”, update it on the appropriate device. Many vulnerabilities are addressed through updates.
2. This point has already been discussed above. If possible, place the ip equipment in a separate Vlan from the data.
3. Place the equipment behind the firewall. It is highly undesirable to give ip equipment external ip addresses.
4. The vulnerability is the web-based interface of the equipment. In order to protect equipment from hacking through the Web-based interface, it is recommended to disable it for ip phones, as it does not carry a large semantic load, or set a strong password for voip-gate.
5. Change of service ports. As with Astersik, it is recommended that you change the sip port from 5060 to any other on IP phones and voip-gate. Thereby increasing the resistance to scanning.
If we are talking about a softphone that is installed on a computer, then it's hard to talk about security. The only effective measure in this case is limited contexts with the ability to notify the administrator of an attempt to make a forbidden call.
2.8 Administrative measures
Even if all the recommendations described above are followed, the system can still be hacked - there is no absolute security. Therefore, administrative measures are important. Consider them.
1. If the organization does not need international calls, then you can block international destinations at the level of a telecom operator. If there are very few such calls, you can agree with the provider about some monitoring of this direction - in case of a large number of calls to international destinations - block these connections.
2. You can also go for a simple but effective method - this is to limit the amount of the bill for communication at the operator level. You can ask the telecom operator to set a limit, which we determine for ourselves (average annual monthly payment for communication + a certain%), and if the limit is reached, communication is blocked. This measure will not let go into a deep minus in case of hacking IP-ATC.
3. Protection of workstations with softphones.
4. Change passwords when changing the administrator.
5. Raising staff awareness.
6. One of the most important points - do not forget that there is no absolute protection. It is necessary to constantly monitor and audit the system for new vulnerabilities, the emergence of new risks, etc., and if something is detected, take this into account in the system’s security system. That is, the "Deming cycle" is required to apply to this system.
Conclusion
I hope that this work has revealed the thesis that, with proper system configuration, Asterisk can be made one of the safest systems with great functionality in the telephony field, and this system is not inferior in functionality to commercial solutions from leading vendors such as Cisco, Avaya, etc. .
Well, the fact that according to statistics they hack more often than Asterisk is determined by the fact that Asterisk has a lot less entry threshold than other systems. That is, a Malomalian it-specialist, after reading a couple of articles on the Internet, can deploy Asterisk, but since qualifications are still lacking, the system, as a rule, turns out to be working, but vulnerable. And for the deployment of commercial solutions, specialists in their field are required who pay due attention to security issues. For this simple reason, Asterisk is hacked more often.
IP-ATC Asterisk is a secure system when configured correctly.
List of references
1. Meggelen J., Madsen L., Smith J. Asterisk ™: the future of telephony, 2nd edition. - Per. from English - St. Petersburg: Symbol-Plus, 2009 .-- 656 p., Ill.
2. Platov M. Asterisk and Linux - IP-telephony mission [Text] / M. Platov // System Administrator. -2005 -№ 31.- S. 12-19.
3. Platov M. Asterisk and Linux: the mission of IP-telephony. Action 2 [Text] / M. Platov // System Administrator. -2005, No. 32. - S. 32-38.
4. Platov M. Asterisk and Linux: the mission of IP-telephony. Action 3 [Text] / M. Platov // System Administrator. -2005, No. 33. - S. 10-19.
5. Asterisk Knowledge Base [Electronic resource]. –– access mode: asterisk.ru/knowledgebase
6. Voxlink Knowledge Base [Electronic resource]. - access mode: www.voxlink.ru/kb
7. HabrHabr. Security in VoIP networks [Electronic resource]. - access mode: habrahabr.ru/post/145206
8. Roslyakov A.V., Samsonov M.Yu., Shibaeva I.V. IP telephony. –M .: Eco-Trends, 2003. -252 pp., Ill.
9. Goldstein B.S., Pinchuk A.V., Sukhovitsky A.L. IP telephony. –M .: Radio and communications, 2001. -336 p.: Ill.
10. CITForum. IP Telephony Security - Field Sketches. A. Veselov [Electronic resource]. - access mode: citforum.ru/security/articles/ipsec
PS
Special thanks for the understanding of this issue to Voxlink CEO Sergey Grushko and his work.
I understand that the topic is hackneyed and everyone seems to know everything, but at the same time, hacked IP stations are not getting smaller. I hope that the article will be at least useful to someone.