Security asterisk
Good day, to you, inhabitants of Habr.
It so happened that I took a distance learning course on the topic of “Information Security”, after which it was necessary to protect my final work. I chose “Asterisk Security” as the topic for this work, a lot of articles and publications are written about this topic, but in my opinion they are either incomplete or do not fully disclose this topic, or there is no indication of the relevance of this issue. He took the liberty of collecting “everything” in one document, which resulted in his final work. He defended himself successfully, the diploma was received - he decided to share this work with the community.
1. The risks associated with Asterisk IP-PBX
Everyone knows that in the age of information technology, huge losses to organizations are caused by the actions of intruders (hackers). As a rule, the most painful are attacks aimed at causing harm to the organization or 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 via the Internet (some system services are open to the outside world), hackers have the opportunity 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. Breach 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 the deterioration of services (Dos-attacks).
4. Resale of traffic (Toll-Fraud).
Resale traffic is one of the most convenient ways to make money by hackers. Having hacked the station and sent calls to expensive international destinations, the hacker receives a certain reward on his e-wallets, which are then cashed out and real money is received. Let us consider in more detail the typical traffic resale scheme.
There is a hacker who wants to earn money by reselling traffic. He goes to the stock exchange of drain traffic, registers and receives some pool of numbers that can identify him further. Further, through some dummy servers are detected and if, it turns out, IP-ATC servers are hacked. Further to the numbers that were provided to the hacker on the exchange of drain traffic, calls start to go. Calls are paid. Suppose a call costs 10 rubles. (payment of the victim to the operator). The call is usually sent abroad (usually Cuba, Palestine, Romania, Latvia, etc.) to countries where due attention is not paid to cyber crime, that is, where there is an opportunity to engage in this type of business. And so the Victim pays the OS (Telecom Operator) 10 rubles per minute. The operating system goes to international lines through OMT (international traffic operator), to which it pays around 8 rubles. per minute, then OMT sends a call to a local operator (Cuba, Palestine, and others), who launches voice traffic and pays him already 6 rubles. per minute, this operator is in the share and he distributes the money as follows - part of the money goes to him in payment for services (so to say, earns this amount - leaves in his account), and sends the honor of money to the exchange of drain traffic, where the hacker is registered . Next, the exchange, leaving one ruble, two pays a hacker. Visually, the scheme is shown in Fig.1.
Fig.1. Voip traffic resale scheme
')
Taking into account the fact that the directions are chosen expensive and the flow of calls is intense, the hacker gets not a bad profit. And due to the fact that sometimes the systems are not properly protected, the hacking occurs quickly and without any laborious and financially costly 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, this kind of problem has recently become frequent. Therefore, many believe that Asterisk is an insecure system. However, this thesis wants to challenge. First, if we talk about the possibility of Asterisk itself, then it has a very rich set of security tools. The toolkit is protected by Asterisk 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 checkbox for activating Asterisk security. Asterisk security is the adoption of a series of comprehensive measures that, as a rule, administrators forget about, thereby exposing Asterisk to threats.
2. Multi-Level IP-PBX Asterisk Protection
Speaking about the security of the IP-ATC solution as a whole, you need to understand that security is not only based on the security of Asterisk itself, it is also necessary to ensure the security of the Asterisk environment.
The IP-ATC security system is built on several levels.
1. Network protection.
2. Network design.
3. Analysis of the logs.
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 the Asterisk problem is in terms of security, as mentioned above, this problem is not the competence of the Asterisk administrator.
Due to the fact that there are “boxed solutions” - installed and working, we get a very large number of installed Asterisk servers without proper security settings and the necessary administrator qualifications, resulting in hacked Asterisk, loss of organization’s funds, and a shadow on Asterisk’s name. Either a not competent integrator has not properly installed the server and after payment it disappears. And the client later receives huge bills by telephone or the operator blocks their directions.
Consider the typical mistakes that novice Asterisk administrators make.
1. Weak passwords on internal numbers (No passwords, the password is the same as ext).
2. Lack of a firewall (Lack of iptables, either iptables is turned off, or not configured correctly).
3. Older distributions and Software (Older software may contain vulnerabilities. Constant system updates are required. As an example, the 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 on an external address, but without protection - this is a tasty morsel for hackers).
6. Errors in the configuration.
7. Lack of control over the system (Set and forget, there is no control logs).
2.1 Network Protection
When deploying a system, it is important to use a firewall. Linux has a powerful and flexible IPTables tool that is controlled by commands. 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 protocol packets)
-A INPUT –i lo –j ACCEPT (allow traffic from the lo interface)
-A INPUT –m state --state NEW –m tcp –p tcp –dport 22 –j ACCEPT (allow new ssh connection)
-A INPUT –j REJECT --reject-with icmp-host-prohibited (we prohibit all other incoming connections)
-A FORWARD –j REJECT - reject-with icmp-host-prohibited (we prohibit all transit connections)
COMMIT
This "config" defines - We allow connections initiated by us, we prohibit all incoming connections except ssh. Next, customize your tasks. The config is here / etc / sysconfig / iptables. To configure IPTables, the main thing is to understand the philosophy of this tool. The essence of writing the rules is to create "chains" into which traffic is driven according to certain classifiers (-s source, -p protocol, -i interface ... ..), where action takes place over traffic - either allowed or denied, or forward to another the chain. If the traffic ran through all the chains and did not fall under any rule - unspecified traffic (more than one classifier did not work), the traffic is prohibited. That is, for example, in order to connect to the Asterisk server ip-phones, softphones from the internal network, 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 xxx.xxx.xxx.xxx \ 24 network. Since the packet passes by rules from top to bottom, it should be understood that this rule will work if we write it higher than the prohibiting rules. Thus, you can configure the firewall, that Asterisk will serve only those directions and only those packages that we obviously trust, and it will be almost impossible for an attacker to get to the server. It is possible to more flexibly adjust the logic of the firewall — we create our own chain for each packet group (Admin, SIP, IAX2, ...) with its own rules, and in the main INPUT chain, according to the rules, the packets are sent along their own chains, where appropriate actions are taken.
2.2 Network Design
When designing and implementing a system, you need to pay attention to the 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 Asterisk connection to an external address
The fact that Asterisk is available 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 call at the expense of the company that owns Asterisk. At best, the attackers target may be denial of service.
Strong passwords and regular updates, of course, reduce the risk. Even more, it can be reduced by specialized means of protection, namely, firewalls (ME). If you connect Asterisk as shown in Fig. 3, the server will be safely closed outside the perimeter of the local network.
Fig. 3. Recommended wiring diagram for Asterisk using ME
The ME passes 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, unavailable to the attacker.
We also note another important aspect that needs attention - the separation of data. It is important to separate voice and data through the construction of a Vlan. Computers, servers, other network equipment must be in one Vlan, and equipment working with Asterisk (the server itself, gate, ip-phones ...) in another Vlan. This is done so that the users themselves, as well as possible viruses on user machines, could not harm IP-ATC and vice versa. The scheme with Vlan is presented in fig. four.
Fig. 4. Separation of voice and data in different Vlan.
2.3 Log Analysis
During the IP-ATC system, Asterisk and other applications log all their actions. Since the log contains data on both authorized actions and unauthorized actions, it is very important to periodically review them for incidents. It is necessary to monitor connections, control the selection of passwords, track multiple connection attempts, monitor unplanned activity.
In the Asterisk toolkit, there is no such tool as a log analyzer that would, under certain conditions, take certain actions on the connection. There is an unplanned activity, which is important to monitor in order to prevent the possibility of hacking Asterisk server, one of such activities is the selection of passwords (brute force passwords in the dictionary). There is no such tool that would prevent Asterisk from overwriting passwords, and since this is an important point in security, it is proposed to use the external service Fail2Ban, which can work with many services, such as Asterisk, Apache, ssh, ftp and others. The operation of this service is based on the same 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. Figure 5 shows the operation of the Fail2Ban service.
Fig. 5. The principle of Fail2Ban
I would also like to note one more recommendation - it is desirable that the logs (logs) about events in the system be 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 its presence and actions by removing all events from the log files. If the logs are sent to a remote server, it will make it difficult or impossible to hide your presence.
2.4 Asterisk Configuration
In this chapter, we will look at system security at the Asterisk configuration level. And so, what we have to configure in Asterisk itself, which would increase the security of IP-ATC.
If Asterisk is “sitting” on an external address and there is no possibility to use IPTables (a situation when you need to connect a device with a dynamic ip address), or not using vpn, then the first thing to do is change the standard port 5060 (sip) to any other. Thus, we will withdraw from our suspicions that our Asterisk server will not attack it further. Let us protect ourselves from the BruteForce attacks outside.
How to do it. Rule sip.conf file
[general]
; bindport = 5060 ; Commented out the standard option.
bindport = 9060 ; Changing the default port to another free is for security reasons.
Do not forget on the endpoint devices to indicate the port to which we changed the standard one. Since by default devices will strive to connect to Asterisk on port 5060, and nothing happens.
How else can we improve system security at the sip.conf configuration level.
[general]
alwaysauthreject = yes ; We protect the server from brute force by numbers. If the value is no, the server will honestly respond that there is no such subscriber, until the attacker guesses the existing ext, then the server will answer that the password is not correct. Thus, the attacker learns about the existence of an internal number, it remains only to find the password. Next is already going over the password for a very specific internal number. The yes option allows you to reject authentication requests for existing users with the same reason as for non-existing users. Thus, we make it more difficult for fraudsters to find out the existing ext.
allowguest = no ; We prohibit connections to the server in the mode of direct sip calls, the so-called guest calls, when you can call the subscriber by his E-mail.
bindaddr = xxx.xxx.xxx.xxx ; At what address will Asterisk listen to network connections using the sip protocol? This is if the server is connected to different networks, it is better to explicitly indicate from which network to accept 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 xxx.xxx.xxx.xxx network
secret = bdDfg12312fc ; Requires strong passwords that are 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 Protection by call routing plan (dialplan)
With the help of well-written dialplan (call routing plan), you can significantly increase security. The first thing recommended is the division of subscribers into contexts with their own routing rules.
In sip.conf
[1000]
context = from_chef
[1001]
context = from_it
[1002]
context = from_fin
Separation by contexts gives us the opportunity to endow telephone subscribers with different rights. This is important, since not everyone needs, say, to call international destinations. Further to contexts we assign rules. In extension. conf
[allow]
exten => _ X., n, Dial (SIP / operator / $ {EXTEN}) ; Allow any calls through the Operator
exten => _ [12] XXX, n, Dial (SIP / $ {EXTEN}) ; Allow internal connections
[from_chef]
exten => _X., n, Goto (allow, $ {EXTEN}, 1) ; All calls are directed to the context [allow]
[from_it]
exten => _9810., n, Hungup () ; We limit international destinations
exten => _X., n, Goto (allow, $ {EXTEN}, 1) ; All calls are directed to the context [allow]
[from_fin]
exten => _9810., n, Hungup () ; We limit international destinations
exten => _989., n, Hungup () ; We limit directions to cellular directions.
exten => _X., n, Goto (allow, $ {EXTEN}, 1) ; All calls are directed to the context [allow]
Thus, the financial department prohibits calls to international destinations and cellular directions. It division prohibited only international destinations. Well, the head allow any connections.
In order to receive information about the banned calls to the post office, we will teach Asterisk to discourage violations. To do this, add another context [alarm].
[alarm]
exten => _9810X., 1, playback (zapresheno) ; We notify the subscriber that this direction is prohibited to him.
exten => _9810X., n, System (echo "To" $ {EXTEN} "Ext" $ {CALLERID (num)} | mail -s "8-10 ALARM" it_admin@list.ru) ; Fiscalit mail if there are international calls.
exten => _9810X., n, Hangup () ; hang up
And send prohibited calls to this context.
[allow]
exten => _ X., n, Dial (SIP / operator / $ {EXTEN}) ; Allow any calls through the Operator
exten => _ [12] XXX, n, Dial (SIP / $ {EXTEN}) ; Allow internal connections
[from_chef]
exten => _X., n, Goto (allow, $ {EXTEN}, 1) ; All calls are directed to the context [allow]
[from_it]
exten => _9810., n, Goto (alarm, $ {EXTEN}, 1) ; We direct international calls in context [alarm]
exten => _X., n, Goto (allow, $ {EXTEN}, 1) ; All calls are directed to the context [allow]
[from_fin]
exten => _9810., n, Goto (alarm, $ {EXTEN}, 1) ; We direct international calls in context [alarm]
exten => _989., n, Hungup () ; We limit directions to cellular directions.
exten => _X., n, Goto (allow, $ {EXTEN}) ; All calls are directed to the context [allow]
Thus, not only we block the forbidden directions, but in the event of an incident we get a message who (ext) is trying to reach. Thus, we can understand in time that the server is hacked, but not when huge bills for communication come.
That's good Asterisk, dilplan allows you to flexibly configure routing.We can prohibit directions by various parameters, we can differentiate the rights to subscribers, we can set up notifications about barred calls, you can also set up call restriction by time, we can set up calls to enter a pin-code and much more, which allows to increase the security of IP-ATC. Pin code is recommended for remote users with a dynamic ip-address, since the restriction on permit / deny and iptables is impossible, in this case it is desirable to close international destinations, change the standard port (5060) to something of your own, and call the calls by pin-code.
2.6 Linux configuration
Both in Asterisk itself and in Linux itself there are services that are started 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 databases, channels. Disabling unnecessary modules will not only free up memory, but also make IP-ATC less vulnerable. What we seek. And since it can be done.
In the /etc/asterisk/modules.conf file, the autoload = yes parameter is specified, which causes Asterisk to initialize and start all services that are in the / usr / lib / asterisk / modules folder when it is loaded. In order to prohibit the launch of this or that unnecessary service, it is necessary in the file /etc/asterisk/modules.conf to prescribe the following lines
noload => chan_gtalk.so ; Gtalk channel module.
noload => app_morsecode.so ; Transfer the specified string to 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 perhaps not needed for IP-ATC operation - it is also desirable to disable them. Using the chkconfig –list command, you can see which services are started and determine which services are superfluous. Suppose, on CentOS 5, the bluetooth service is loaded by default, this service is not needed at the Asterisk telephone exchange, we’ll remove it from the startup with the command chkconfig bluetooth off. We will do the same with other unnecessary services. All these manipulations need to 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 log in remotely to the server is the main door to the PBX control center. To increase security, the PBX administrator is recommended to perform the following measures.
1. Change port. The default SSH port is the 22nd. Many hackers scan the Internet for servers with open port 22, then try to hack them. You need to think of another port, in the range of 1-65535, and specify it in the Port directive in the ssh configuration.
We also forget to specify this port in the client when connecting to the server.
2. Explicit enumeration of users who have access to the system via the 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 to use only SSH protocol version 2.
4. Disable direct root user access. This will significantly complicate and most likely make it impossible for the password brute force attack, since the root user will be denied access to the system, even if the correct password is entered. Use the sudo subsystem to gain root access if necessary and only after remote login to the system under an unprivileged account.
5. Use a temporary password restriction or certificates. Setting the minimum possible time to enter a password, for example, 1 second, can well confuse the 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 a good practice to log in to SSH using certificates. If you often use SSH to connect to a remote host, one of the ways to ensure the security of a 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. Further it is proposed to specify a place for key saving. 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 an ID phrase. This is not the passphrase for connecting to a remote host. This is the passphrase for unlocking the private key, so it will not help you access the remote server, even if your private key is stored on it. Entering an ID phrase is optional. To leave it empty, press "Enter".
4. Our keys are generated. Go to the home directory in the folder .ssh, there should be generated our keys id_rsa and id_rsa.pub.
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. Copy the contents of the id_rsa.pub file to the newly created authorized_keys file.
Copy and create the file with the cat id_rsa.pub >> authorized_keys command
7. Install the read and write permissions to the file
chmod 600 authorized_keys
8. Copy the private id_rsa 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 (load) it through the puttygen program. At the exit (Save private key) we get a private key (* .ppk).
10. Now add the key to the session. We start PuTTY, load the necessary session or enter data for the connection and go to “SSH - Auth”, choose our private key, which was obtained through the processing “puttygen”.
11. Go to the menu "Connection - Data" and in the field "Auto-login username" enter the login under which generated the key.
12. Save the session, restart the SSH service on the server /etc/init.d/ssh reload
13. Connect.
Thus, we have improved the security of the SSH connection.
2.7 Peripheral Protection
One of the important points is the protection of equipment that is connected in one way or another to Asterisk, such equipment are ip-phones, voip-gate and others. An IP-ATC system cannot be secure unless peripheral devices are protected. To protect this equipment, it is proposed to conduct a number of activities:
1. This is a software update of the equipment. It is important to monitor this aspect in the event of a new “firmware” release, update it on the appropriate device. Many vulnerabilities are fixed with updates.
2. This point has already been discussed above. If possible, put the ip-equipment in a separate Vlan from the data.
3. Place equipment behind the network screen. It is not desirable to give ip-equipment external ip-addresses.
4. The vulnerability is the Web-based hardware interface. In order to protect equipment from hacking via a web interface, it is recommended to disable it for ip phones, since it does not carry much meaning, or to set a strong password for voip-gate.
5. Change of service ports. As in the case of Astersik, on ip-phones and voip-gate it is recommended to change the sip port from 5060 to any other. Thereby we increase resistance to scanning.
If we are talking about a softphone that is installed on a computer, then it is hard to talk about security. The only effective measure in this case is limited contexts with the possibility of notifying the administrator about an attempt to make a barred call.
2.8 Administrative measures
Even if all the recommendations described above are implemented, 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 carrier level. If there are very few such calls, then you can agree with the provider on some monitoring of this direction - in case of a large number of calls to international destinations - to 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, the connection is blocked. This measure will not let go into a deep minus in the case of hacking IP-ATC.
3. Protection of workstations with softphones.
4. Change passwords when changing admin.
5. Increase staff awareness.
6. One of the most important moments is not to forget that there is no absolute protection. It is necessary to constantly monitor and audit the system for new vulnerabilities, new risks, etc., and if something is revealed, take it into account in the system security system. That is, the "Deming cycle" is required in application to this system.
Conclusion
I hope that this work reveals the thesis that if the system is properly configured, Asterisk can be made one of the safest systems with more functionality in the field of telephony, and this system is not inferior to commercial solutions from leading vendors such as Cisco, Avaya, etc.
Well, the fact that, according to statistics, Asterisk is more often cracked, is determined by the fact that Asterisk has a lower threshold for entry than other systems. That is, a small IT specialist, after reading a couple of articles on the Internet, can deploy Asterisk, and since there is still not enough qualifications, the system is usually working, but vulnerable. And for the deployment of commercial solutions, you need experts in your business who pay due attention to security issues. This is the reason why Asterisk is being cracked more often.
IP-ATC Asterisk is a secure system when properly configured.
References
1. Meggelen J., Madsen L., Smith J. Asterisktm: The Future of Telephony, 2nd Edition. - Per. from English- SPb: Symbol Plus, 2009. - 656 s., Ill.
2. Platov M. Asterisk and Linux - mission IP-telephony [Text] / M. Platov // System Administrator. - 2005 - No. 31. - p. 12-19.
3. Platov M. Asterisk and Linux: the mission of IP-telephony. Action 2 [Text] / M. Platov // System Administrator. - 2005 - No. 32. - p. 32-38.
4. Platov M. Asterisk and Linux: the mission of IP-telephony. Step 3 [Text] / M. Platov // System Administrator. - 2005 - № 33. - p. 10-19.
5. Asterisk Knowledge Base [Electronic resource]. - access mode: asterisk.ru/knowledgebase
6. Knowledge base Voxlink [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-Trend, 2003. -252 pp., Ill.
9. Goldstein B.S., Pinchuk A.V., Sukhovitsky A.L. IP telephony. –M .: Radio and Communication, 2001. -336 pp., Ill.
10. CITForum. IP telephony security - field sketches. A. Veselov [Electronic resource]. - access mode: citforum.ru/security/articles/ipsec
PS
Separately, thanks for the understanding of this issue to Sergey Voxlink CEO Sergey Grushko and his work.
I understand that the topic is beaten and it seems everyone knows everything, but at the same time there are no fewer cracked IP stations. 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 of “Information Security”, after which it was necessary to protect my final work. I chose “Asterisk Security” as the topic for this work, a lot of articles and publications are written about this topic, but in my opinion they are either incomplete or do not fully disclose this topic, or there is no indication of the relevance of this issue. He took the liberty of collecting “everything” in one document, which resulted in his final work. He defended himself successfully, the diploma was received - he decided to share this work with the community.
1. The risks associated with Asterisk IP-PBX
Everyone knows that in the age of information technology, huge losses to organizations are caused by the actions of intruders (hackers). As a rule, the most painful are attacks aimed at causing harm to the organization or 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 via the Internet (some system services are open to the outside world), hackers have the opportunity 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. Breach 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 the deterioration of services (Dos-attacks).
4. Resale of traffic (Toll-Fraud).
Resale traffic is one of the most convenient ways to make money by hackers. Having hacked the station and sent calls to expensive international destinations, the hacker receives a certain reward on his e-wallets, which are then cashed out and real money is received. Let us consider in more detail the typical traffic resale scheme.
There is a hacker who wants to earn money by reselling traffic. He goes to the stock exchange of drain traffic, registers and receives some pool of numbers that can identify him further. Further, through some dummy servers are detected and if, it turns out, IP-ATC servers are hacked. Further to the numbers that were provided to the hacker on the exchange of drain traffic, calls start to go. Calls are paid. Suppose a call costs 10 rubles. (payment of the victim to the operator). The call is usually sent abroad (usually Cuba, Palestine, Romania, Latvia, etc.) to countries where due attention is not paid to cyber crime, that is, where there is an opportunity to engage in this type of business. And so the Victim pays the OS (Telecom Operator) 10 rubles per minute. The operating system goes to international lines through OMT (international traffic operator), to which it pays around 8 rubles. per minute, then OMT sends a call to a local operator (Cuba, Palestine, and others), who launches voice traffic and pays him already 6 rubles. per minute, this operator is in the share and he distributes the money as follows - part of the money goes to him in payment for services (so to say, earns this amount - leaves in his account), and sends the honor of money to the exchange of drain traffic, where the hacker is registered . Next, the exchange, leaving one ruble, two pays a hacker. Visually, the scheme is shown in Fig.1.
Fig.1. Voip traffic resale scheme
')
Taking into account the fact that the directions are chosen expensive and the flow of calls is intense, the hacker gets not a bad profit. And due to the fact that sometimes the systems are not properly protected, the hacking occurs quickly and without any laborious and financially costly 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, this kind of problem has recently become frequent. Therefore, many believe that Asterisk is an insecure system. However, this thesis wants to challenge. First, if we talk about the possibility of Asterisk itself, then it has a very rich set of security tools. The toolkit is protected by Asterisk 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 checkbox for activating Asterisk security. Asterisk security is the adoption of a series of comprehensive measures that, as a rule, administrators forget about, thereby exposing Asterisk to threats.
2. Multi-Level IP-PBX Asterisk Protection
Speaking about the security of the IP-ATC solution as a whole, you need to understand that security is not only based on the security of Asterisk itself, it is also necessary to ensure the security of the Asterisk environment.
The IP-ATC security system is built on several levels.
1. Network protection.
2. Network design.
3. Analysis of the logs.
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 the Asterisk problem is in terms of security, as mentioned above, this problem is not the competence of the Asterisk administrator.
Due to the fact that there are “boxed solutions” - installed and working, we get a very large number of installed Asterisk servers without proper security settings and the necessary administrator qualifications, resulting in hacked Asterisk, loss of organization’s funds, and a shadow on Asterisk’s name. Either a not competent integrator has not properly installed the server and after payment it disappears. And the client later receives huge bills by telephone or the operator blocks their directions.
Consider the typical mistakes that novice Asterisk administrators make.
1. Weak passwords on internal numbers (No passwords, the password is the same as ext).
2. Lack of a firewall (Lack of iptables, either iptables is turned off, or not configured correctly).
3. Older distributions and Software (Older software may contain vulnerabilities. Constant system updates are required. As an example, the 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 on an external address, but without protection - this is a tasty morsel for hackers).
6. Errors in the configuration.
7. Lack of control over the system (Set and forget, there is no control logs).
2.1 Network Protection
When deploying a system, it is important to use a firewall. Linux has a powerful and flexible IPTables tool that is controlled by commands. 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 protocol packets)
-A INPUT –i lo –j ACCEPT (allow traffic from the lo interface)
-A INPUT –m state --state NEW –m tcp –p tcp –dport 22 –j ACCEPT (allow new ssh connection)
-A INPUT –j REJECT --reject-with icmp-host-prohibited (we prohibit all other incoming connections)
-A FORWARD –j REJECT - reject-with icmp-host-prohibited (we prohibit all transit connections)
COMMIT
This "config" defines - We allow connections initiated by us, we prohibit all incoming connections except ssh. Next, customize your tasks. The config is here / etc / sysconfig / iptables. To configure IPTables, the main thing is to understand the philosophy of this tool. The essence of writing the rules is to create "chains" into which traffic is driven according to certain classifiers (-s source, -p protocol, -i interface ... ..), where action takes place over traffic - either allowed or denied, or forward to another the chain. If the traffic ran through all the chains and did not fall under any rule - unspecified traffic (more than one classifier did not work), the traffic is prohibited. That is, for example, in order to connect to the Asterisk server ip-phones, softphones from the internal network, 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 xxx.xxx.xxx.xxx \ 24 network. Since the packet passes by rules from top to bottom, it should be understood that this rule will work if we write it higher than the prohibiting rules. Thus, you can configure the firewall, that Asterisk will serve only those directions and only those packages that we obviously trust, and it will be almost impossible for an attacker to get to the server. It is possible to more flexibly adjust the logic of the firewall — we create our own chain for each packet group (Admin, SIP, IAX2, ...) with its own rules, and in the main INPUT chain, according to the rules, the packets are sent along their own chains, where appropriate actions are taken.
2.2 Network Design
When designing and implementing a system, you need to pay attention to the 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 Asterisk connection to an external address
The fact that Asterisk is available 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 call at the expense of the company that owns Asterisk. At best, the attackers target may be denial of service.
Strong passwords and regular updates, of course, reduce the risk. Even more, it can be reduced by specialized means of protection, namely, firewalls (ME). If you connect Asterisk as shown in Fig. 3, the server will be safely closed outside the perimeter of the local network.
Fig. 3. Recommended wiring diagram for Asterisk using ME
The ME passes 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, unavailable to the attacker.
We also note another important aspect that needs attention - the separation of data. It is important to separate voice and data through the construction of a Vlan. Computers, servers, other network equipment must be in one Vlan, and equipment working with Asterisk (the server itself, gate, ip-phones ...) in another Vlan. This is done so that the users themselves, as well as possible viruses on user machines, could not harm IP-ATC and vice versa. The scheme with Vlan is presented in fig. four.
Fig. 4. Separation of voice and data in different Vlan.
2.3 Log Analysis
During the IP-ATC system, Asterisk and other applications log all their actions. Since the log contains data on both authorized actions and unauthorized actions, it is very important to periodically review them for incidents. It is necessary to monitor connections, control the selection of passwords, track multiple connection attempts, monitor unplanned activity.
In the Asterisk toolkit, there is no such tool as a log analyzer that would, under certain conditions, take certain actions on the connection. There is an unplanned activity, which is important to monitor in order to prevent the possibility of hacking Asterisk server, one of such activities is the selection of passwords (brute force passwords in the dictionary). There is no such tool that would prevent Asterisk from overwriting passwords, and since this is an important point in security, it is proposed to use the external service Fail2Ban, which can work with many services, such as Asterisk, Apache, ssh, ftp and others. The operation of this service is based on the same 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. Figure 5 shows the operation of the Fail2Ban service.
Fig. 5. The principle of Fail2Ban
I would also like to note one more recommendation - it is desirable that the logs (logs) about events in the system be 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 its presence and actions by removing all events from the log files. If the logs are sent to a remote server, it will make it difficult or impossible to hide your presence.
2.4 Asterisk Configuration
In this chapter, we will look at system security at the Asterisk configuration level. And so, what we have to configure in Asterisk itself, which would increase the security of IP-ATC.
If Asterisk is “sitting” on an external address and there is no possibility to use IPTables (a situation when you need to connect a device with a dynamic ip address), or not using vpn, then the first thing to do is change the standard port 5060 (sip) to any other. Thus, we will withdraw from our suspicions that our Asterisk server will not attack it further. Let us protect ourselves from the BruteForce attacks outside.
How to do it. Rule sip.conf file
[general]
; bindport = 5060 ; Commented out the standard option.
bindport = 9060 ; Changing the default port to another free is for security reasons.
Do not forget on the endpoint devices to indicate the port to which we changed the standard one. Since by default devices will strive to connect to Asterisk on port 5060, and nothing happens.
How else can we improve system security at the sip.conf configuration level.
[general]
alwaysauthreject = yes ; We protect the server from brute force by numbers. If the value is no, the server will honestly respond that there is no such subscriber, until the attacker guesses the existing ext, then the server will answer that the password is not correct. Thus, the attacker learns about the existence of an internal number, it remains only to find the password. Next is already going over the password for a very specific internal number. The yes option allows you to reject authentication requests for existing users with the same reason as for non-existing users. Thus, we make it more difficult for fraudsters to find out the existing ext.
allowguest = no ; We prohibit connections to the server in the mode of direct sip calls, the so-called guest calls, when you can call the subscriber by his E-mail.
bindaddr = xxx.xxx.xxx.xxx ; At what address will Asterisk listen to network connections using the sip protocol? This is if the server is connected to different networks, it is better to explicitly indicate from which network to accept 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 xxx.xxx.xxx.xxx network
secret = bdDfg12312fc ; Requires strong passwords that are 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 Protection by call routing plan (dialplan)
With the help of well-written dialplan (call routing plan), you can significantly increase security. The first thing recommended is the division of subscribers into contexts with their own routing rules.
In sip.conf
[1000]
context = from_chef
[1001]
context = from_it
[1002]
context = from_fin
Separation by contexts gives us the opportunity to endow telephone subscribers with different rights. This is important, since not everyone needs, say, to call international destinations. Further to contexts we assign rules. In extension. conf
[allow]
exten => _ X., n, Dial (SIP / operator / $ {EXTEN}) ; Allow any calls through the Operator
exten => _ [12] XXX, n, Dial (SIP / $ {EXTEN}) ; Allow internal connections
[from_chef]
exten => _X., n, Goto (allow, $ {EXTEN}, 1) ; All calls are directed to the context [allow]
[from_it]
exten => _9810., n, Hungup () ; We limit international destinations
exten => _X., n, Goto (allow, $ {EXTEN}, 1) ; All calls are directed to the context [allow]
[from_fin]
exten => _9810., n, Hungup () ; We limit international destinations
exten => _989., n, Hungup () ; We limit directions to cellular directions.
exten => _X., n, Goto (allow, $ {EXTEN}, 1) ; All calls are directed to the context [allow]
Thus, the financial department prohibits calls to international destinations and cellular directions. It division prohibited only international destinations. Well, the head allow any connections.
In order to receive information about the banned calls to the post office, we will teach Asterisk to discourage violations. To do this, add another context [alarm].
[alarm]
exten => _9810X., 1, playback (zapresheno) ; We notify the subscriber that this direction is prohibited to him.
exten => _9810X., n, System (echo "To" $ {EXTEN} "Ext" $ {CALLERID (num)} | mail -s "8-10 ALARM" it_admin@list.ru) ; Fiscalit mail if there are international calls.
exten => _9810X., n, Hangup () ; hang up
And send prohibited calls to this context.
[allow]
exten => _ X., n, Dial (SIP / operator / $ {EXTEN}) ; Allow any calls through the Operator
exten => _ [12] XXX, n, Dial (SIP / $ {EXTEN}) ; Allow internal connections
[from_chef]
exten => _X., n, Goto (allow, $ {EXTEN}, 1) ; All calls are directed to the context [allow]
[from_it]
exten => _9810., n, Goto (alarm, $ {EXTEN}, 1) ; We direct international calls in context [alarm]
exten => _X., n, Goto (allow, $ {EXTEN}, 1) ; All calls are directed to the context [allow]
[from_fin]
exten => _9810., n, Goto (alarm, $ {EXTEN}, 1) ; We direct international calls in context [alarm]
exten => _989., n, Hungup () ; We limit directions to cellular directions.
exten => _X., n, Goto (allow, $ {EXTEN}) ; All calls are directed to the context [allow]
Thus, not only we block the forbidden directions, but in the event of an incident we get a message who (ext) is trying to reach. Thus, we can understand in time that the server is hacked, but not when huge bills for communication come.
That's good Asterisk, dilplan allows you to flexibly configure routing.We can prohibit directions by various parameters, we can differentiate the rights to subscribers, we can set up notifications about barred calls, you can also set up call restriction by time, we can set up calls to enter a pin-code and much more, which allows to increase the security of IP-ATC. Pin code is recommended for remote users with a dynamic ip-address, since the restriction on permit / deny and iptables is impossible, in this case it is desirable to close international destinations, change the standard port (5060) to something of your own, and call the calls by pin-code.
2.6 Linux configuration
Both in Asterisk itself and in Linux itself there are services that are started 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 databases, channels. Disabling unnecessary modules will not only free up memory, but also make IP-ATC less vulnerable. What we seek. And since it can be done.
In the /etc/asterisk/modules.conf file, the autoload = yes parameter is specified, which causes Asterisk to initialize and start all services that are in the / usr / lib / asterisk / modules folder when it is loaded. In order to prohibit the launch of this or that unnecessary service, it is necessary in the file /etc/asterisk/modules.conf to prescribe the following lines
noload => chan_gtalk.so ; Gtalk channel module.
noload => app_morsecode.so ; Transfer the specified string to 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 perhaps not needed for IP-ATC operation - it is also desirable to disable them. Using the chkconfig –list command, you can see which services are started and determine which services are superfluous. Suppose, on CentOS 5, the bluetooth service is loaded by default, this service is not needed at the Asterisk telephone exchange, we’ll remove it from the startup with the command chkconfig bluetooth off. We will do the same with other unnecessary services. All these manipulations need to 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 log in remotely to the server is the main door to the PBX control center. To increase security, the PBX administrator is recommended to perform the following measures.
1. Change port. The default SSH port is the 22nd. Many hackers scan the Internet for servers with open port 22, then try to hack them. You need to think of another port, in the range of 1-65535, and specify it in the Port directive in the ssh configuration.
We also forget to specify this port in the client when connecting to the server.
2. Explicit enumeration of users who have access to the system via the 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 to use only SSH protocol version 2.
4. Disable direct root user access. This will significantly complicate and most likely make it impossible for the password brute force attack, since the root user will be denied access to the system, even if the correct password is entered. Use the sudo subsystem to gain root access if necessary and only after remote login to the system under an unprivileged account.
5. Use a temporary password restriction or certificates. Setting the minimum possible time to enter a password, for example, 1 second, can well confuse the 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 a good practice to log in to SSH using certificates. If you often use SSH to connect to a remote host, one of the ways to ensure the security of a 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. Further it is proposed to specify a place for key saving. 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 an ID phrase. This is not the passphrase for connecting to a remote host. This is the passphrase for unlocking the private key, so it will not help you access the remote server, even if your private key is stored on it. Entering an ID phrase is optional. To leave it empty, press "Enter".
4. Our keys are generated. Go to the home directory in the folder .ssh, there should be generated our keys id_rsa and id_rsa.pub.
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. Copy the contents of the id_rsa.pub file to the newly created authorized_keys file.
Copy and create the file with the cat id_rsa.pub >> authorized_keys command
7. Install the read and write permissions to the file
chmod 600 authorized_keys
8. Copy the private id_rsa 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 (load) it through the puttygen program. At the exit (Save private key) we get a private key (* .ppk).
10. Now add the key to the session. We start PuTTY, load the necessary session or enter data for the connection and go to “SSH - Auth”, choose our private key, which was obtained through the processing “puttygen”.
11. Go to the menu "Connection - Data" and in the field "Auto-login username" enter the login under which generated the key.
12. Save the session, restart the SSH service on the server /etc/init.d/ssh reload
13. Connect.
Thus, we have improved the security of the SSH connection.
2.7 Peripheral Protection
One of the important points is the protection of equipment that is connected in one way or another to Asterisk, such equipment are ip-phones, voip-gate and others. An IP-ATC system cannot be secure unless peripheral devices are protected. To protect this equipment, it is proposed to conduct a number of activities:
1. This is a software update of the equipment. It is important to monitor this aspect in the event of a new “firmware” release, update it on the appropriate device. Many vulnerabilities are fixed with updates.
2. This point has already been discussed above. If possible, put the ip-equipment in a separate Vlan from the data.
3. Place equipment behind the network screen. It is not desirable to give ip-equipment external ip-addresses.
4. The vulnerability is the Web-based hardware interface. In order to protect equipment from hacking via a web interface, it is recommended to disable it for ip phones, since it does not carry much meaning, or to set a strong password for voip-gate.
5. Change of service ports. As in the case of Astersik, on ip-phones and voip-gate it is recommended to change the sip port from 5060 to any other. Thereby we increase resistance to scanning.
If we are talking about a softphone that is installed on a computer, then it is hard to talk about security. The only effective measure in this case is limited contexts with the possibility of notifying the administrator about an attempt to make a barred call.
2.8 Administrative measures
Even if all the recommendations described above are implemented, 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 carrier level. If there are very few such calls, then you can agree with the provider on some monitoring of this direction - in case of a large number of calls to international destinations - to 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, the connection is blocked. This measure will not let go into a deep minus in the case of hacking IP-ATC.
3. Protection of workstations with softphones.
4. Change passwords when changing admin.
5. Increase staff awareness.
6. One of the most important moments is not to forget that there is no absolute protection. It is necessary to constantly monitor and audit the system for new vulnerabilities, new risks, etc., and if something is revealed, take it into account in the system security system. That is, the "Deming cycle" is required in application to this system.
Conclusion
I hope that this work reveals the thesis that if the system is properly configured, Asterisk can be made one of the safest systems with more functionality in the field of telephony, and this system is not inferior to commercial solutions from leading vendors such as Cisco, Avaya, etc.
Well, the fact that, according to statistics, Asterisk is more often cracked, is determined by the fact that Asterisk has a lower threshold for entry than other systems. That is, a small IT specialist, after reading a couple of articles on the Internet, can deploy Asterisk, and since there is still not enough qualifications, the system is usually working, but vulnerable. And for the deployment of commercial solutions, you need experts in your business who pay due attention to security issues. This is the reason why Asterisk is being cracked more often.
IP-ATC Asterisk is a secure system when properly configured.
References
1. Meggelen J., Madsen L., Smith J. Asterisktm: The Future of Telephony, 2nd Edition. - Per. from English- SPb: Symbol Plus, 2009. - 656 s., Ill.
2. Platov M. Asterisk and Linux - mission IP-telephony [Text] / M. Platov // System Administrator. - 2005 - No. 31. - p. 12-19.
3. Platov M. Asterisk and Linux: the mission of IP-telephony. Action 2 [Text] / M. Platov // System Administrator. - 2005 - No. 32. - p. 32-38.
4. Platov M. Asterisk and Linux: the mission of IP-telephony. Step 3 [Text] / M. Platov // System Administrator. - 2005 - № 33. - p. 10-19.
5. Asterisk Knowledge Base [Electronic resource]. - access mode: asterisk.ru/knowledgebase
6. Knowledge base Voxlink [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-Trend, 2003. -252 pp., Ill.
9. Goldstein B.S., Pinchuk A.V., Sukhovitsky A.L. IP telephony. –M .: Radio and Communication, 2001. -336 pp., Ill.
10. CITForum. IP telephony security - field sketches. A. Veselov [Electronic resource]. - access mode: citforum.ru/security/articles/ipsec
PS
Separately, thanks for the understanding of this issue to Sergey Voxlink CEO Sergey Grushko and his work.
I understand that the topic is beaten and it seems everyone knows everything, but at the same time there are no fewer cracked IP stations. I hope that the article will be at least useful to someone.
Source: https://habr.com/ru/post/188440/
All Articles