9 rules how to protect your Asterisk!

Now everyone is writing about a large number of attacks on Asterisk and other PBXs. A living example from the practice - the DPRK hacker comrades failed to get to Asterisk, behind the ASUS ASUS simple router, why - more on that, but they did get a good break, or rather pick passwords to Yealink SIP T-22 IP phones.

It was not difficult to do this; standard admin / admin passwords are still very popular. And, as practice has shown, it can cost tens of thousands of rubles ...
')
MyAsterisk Team specialists have compiled 9 rules that will help you to avoid hacker attacks and keep funds on your account.

Rule One: Always change logins and passwords on all network devices. Especially on IP phones, VoIP gateways, etc.

Passwords of subscribers, admins, Asterisk managers, etc. must contain at least 12 characters (letters, numbers, case shift), use complex logins and passwords. Not following this simple rule for some has already cost 15,000 rubles.

Rule two: Use non-standard ports SIP, IAX, SSH.

Change the standard ports to any other. What it will be more unlike the standard - the better.

SIP : The port is configured in the sip file . Conf in the general section:
Bindport = 5060 => bindport = 5172

SSH : The new port should not conflict with the ports already open in the system. For example, we will use 9321. We edit / etc / ssh / sshd_config

Remove the # sign before the change. Port 9321
Then restart sshd to apply the changes using the command:
service sshd restart

IAX : Go to /etc/asterisk/iax.conf
change the port on the line for any free; bindport = 4569
Restart Asterisk with /etc/ininit.d/asterisk restart

Rule Three: Use a user with SSH access.

It is necessary to create a user and give him access rights over SSH only. For example, create a user myasterisk and give it a password. The password must contain characters, numbers and letters with a change of case.

# useradd myasterisk
# passwd myasterisk

Edit / etc / ssh / sshd_config , adding the following line to it: AllowUsers myasterisk

Prevent root user from connecting to Asterisk server via SSH: PermitRootLogin no

Rule Four: Set the allowed addresses for internal subscribers (Deny / Permit).

This setting restricts the ability to register internal subscribers only from trusted IP addresses. For each extension, we specify a range of addresses or a valid IP address.

123
Deny = 0.0.0.0 / 0.0.0.0
Permit = 10.10.1.7
Permit = 10.10.2.1 / 24
Where 10.10.2.1/24 is the range of local addresses from which the connection will be made. Connections from other Asterisk addresses will not be accepted.

Rule Five: Disable guest calls (guest-calls) and registration

You must edit /etc/asterisk/sip.conf
string Allowguest = yes replace with allowguest = no; Allow or reject guest calls (default is yes)

This option is not suitable for all users, sometimes it happens that it is not possible to refuse guest-calls.

Rule Six: Set Call Limit

In the event that you have already been hacked, the line Call-limit = 1 , specified in the settings of your internal subscribers, will help you to lose less money. This line limits the number of simultaneous connections of your internal subscriber.

Rule number seven: use different outbound routing rules

Do not be lazy and use default routes, such as Exten => _X., 1, Hangup . It is necessary to strictly register directions with the codes of cities, mobile operators and international codes (if such is needed at all), for example: 8495XXXXXXX, 8961XXXXXXXX, 89XXXXXXXXX , etc.

Rule Eight: Disable the wrong password answer.

By default, Asterisk gives one error about the wrong password for an existing account and another for a nonexistent account. There are many programs for selecting passwords, so the attacker will not be difficult to check all the short numbers and collect passwords only to existing accounts that answered the "wrong password". To prevent this, change the line in the /etc/asterisk/sip.conf file :
alwaysauthreject = no on alwaysauthreject = yes and restart Asterisk.

After this setup, Asterisk will respond in the same way for any incorrect "401 Unauthorized" authorizations and will not provide details.

Rule Nine: Use iptables and fail2ban

Fail2ban helps to catch strings like “failed for '127.0.0.1 ′ - Wrong password” and “failed for' 127.0.0.1 ′ - Peer is not supposed to register”. Fail2ban can significantly reduce the amount of junk SIP traffic.

However, there are several unpleasant situations in which Asterisk log analysis will not help. For example, in the case when an attacker sends a REGISTER request without identification data, the message “Wrong password” will never appear in the log.

The fact is that in Asterisk all SIP UDP signaling is handled by a single thread. Processing SIP traffic is a resource-intensive process, 7-8 megabits of garbage requests force Asterisk to completely consume the processor core (for example, Intel E5335, E5405). When the kernel is completely eaten, it displaces the useful SIP traffic - garbage.

DTMF stop working for clients using SIP INFO. Problems begin with the installation of new and the completion of existing connections. And this is the main threat that bruteforce robots carry.

So how to deal with problems about which there are no messages in the logs? It's very simple - you need to generate a problem report yourself, then the rest of our countermeasure system (for example, the fail2ban program) can be left unchanged. A characteristic feature of bruteforce is a large number of SIP packets per unit of time.

You can count the number of packets per unit of time using the iptables module called recent. On the Internet there are many examples of how with the help of the recent module they discard packets coming in with a frequency higher than a certain one. Instead of discarding, we will generate messages for our attack detection system (for example, fail2ban). This approach has its own advantages and disadvantages. The main disadvantage is that the processing of messages will waste system resources, while discarding the package is conditionally free.

The advantages are slightly more: we will be able to take advantage of all the capabilities of our attack detection system, such as whitelisting of IP addresses, a uniform record of all detected attacks, and so on.

From theory to practice! Prepare the skeleton of the rules iptables:

-A INPUT -p udp --dport 5060 -j SCAMBLOCK
-A INPUT -p udp --dport 5060 -m recent --set --name SIP
-A INPUT -p udp --dport 5060 -m recent --update --seconds 2 --hitcount 60 --name SIP \
-j LOG --log-prefix “SIP flood detected:„

The first rule checks our package through the SCAMBLOCK chain. In this chain, blocked IP addresses are stored, if the packet matches one of the addresses of this chain - it is discarded. If the packet is not dropped, then in the second rule it is marked for accounting under the SIP name. The third rule considers whether this package has exceeded the specified amount (60) in the specified time (2 seconds).

If the quantity is not exceeded - the rule is ignored; if it is exceeded - the action is performed. In our case, detailed information about the package starting with the line “SIP flood detected:“ is written to the system log. The number of packets and time are counted separately for each source. Thus, it turns out that we have limited the speed of receiving SIP packets from each unblocked IP address at the level of 30 packets per second.

For me, this restriction is comfortable, on the one hand, all clients, even the largest ones, send packets from one IP address with speeds below 30 packets / s, on the other hand, 30 packets per second practically do not reflect on the system operation. It is possible that this value should be corrected in one direction or another, depending on server performance, number and type of subscribers.

In some systems, the built-in restriction of the recent module on the hitcount parameter is very small, for example, on CentOS this restriction is 20 packets. If you try the above command, you will get the following error:

iptables -A INPUT -p udp --dport 5060 -m recent --update --seconds 2 --hitcount 60 --name SIP \
-j LOG --log-prefix “SIP flood detected:„
iptables: Unknown error 4294967295
Or like this, for 64 bit systems:
iptables -A INPUT -p udp --dport 5060 -m recent --update --seconds 2 --hitcount 60 --name SIP \
-j LOG --log-prefix “SIP flood detected:„
iptables: Unknown error 18446744073709551615

You can change the maximum limit by passing a special parameter to the recent module at boot. To do this, create the file /etc/modprobe.d/ipt.conf and write the parameter of interest to it:

options ipt_recent ip_pkt_list_tot = 60

Be careful to increase this limit, remember that with it increases the memory required to store the latest packets, as well as the number of processor cycles required to process them.

Well, that's all, now any flood on port 5060 will be detected using the recent module module iptables. A message about the detected flood will be sent to the system log where our favorite attack detection system (for example, fail2ban) will be able to see it. iptables does not limit us to only the system log, the LOG action can specify the level (level) and facility of the message, and in the Syslog settings redirect the message data to a separate file. SIP flood messages themselves will look like this:

Jun 17 23:54:44 sip2 kernel: SIP flood detected: IN = eth0 OUT = MAC = 00: 21: 5e: db: 15: b8: 00: 0f: 34: f8: 28: 7: 08: 00 SRC = 184.172.62.3 DST = 192.168.224.217 LEN = 370 TOS = 0x00 PREC = 0x00 TTL = 47 ID = 0 DF PROTO = UDP SPT = 5495 DPT = 5060 LEN = 350
Jun 17 23:54:44 sip2 kernel: SIP flood detected: IN = eth0 OUT = MAC = 00: 21: 5e: db: 15: b8: 00: 0f: 34: f8: 28: 7: 08: 00 SRC = 184.172.62.3 DST = 192.168.224.217 LEN = 369 TOS = 0x00 PREC = 0x00 TTL = 47 ID = 0 DF PROTO = UDP SPT = 5495 DPT = 5060 LEN = 349
Jun 17 23:54:44 sip2 kernel: SIP flood detected: IN = eth0 OUT = MAC = 00: 21: 5e: db: 15: b8: 00: 0f: 34: f8: 28:

Thank you, Sergey Tamkovich, for the 9th rule.

Also, MyAsterisk Team recommends that you discuss registration with your SIP provider only from your ip address, set a spending limit per day, based on their average costs and not to disconnect a long-distance and international connection if you do not use it, or make it possible to make outgoing MGs and MN calls after entering the pin code.

Follow the safety rules of MyAsterisk Team , so as not to become the next hero of this video!