Why should Asterisk be protected even if it is behind a firewall?

While a firewall provides the first layer of protection and restricts access to defined ports and IP ranges, it is essential to further secure the Asterisk server itself because:

1. Defense in Depth:
   Security concepts work best with multiple layers of protection. If the firewall has a vulnerability for any reason (misconfiguration, zero-day vulnerability, or insider attack), an additionally secured Asterisk instance prevents attackers from gaining direct access.
2. Protection against internal threats:
   Not all attacks come from outside. A compromised device or a malicious insider on the local network could otherwise access Asterisk unhindered. Additional protection mechanisms on Asterisk limit the risk.
3. Incorrect firewall configurations:
   Firewalls are complex, and rule errors are common. A well-hardened Asterisk server ensures that even with incorrectly configured firewall rules, unauthorized use is impossible.
4. Specific vulnerabilities in the VoIP protocol:
   SIP and RTP are complex protocols with various attack vectors (e.g., brute force attacks on accounts, SIP flooding). Protection mechanisms built directly into Asterisk (Fail2Ban, secure authentication, TLS) help to specifically defend against these attacks.
5. Auditability and targeted response:
   Specific protection measures on Asterisk allow attacks to be better detected, logged and responded to individually without relying on the firewall.

These points demonstrate that, while an upstream firewall is very important, it cannot be a panacea. Security only becomes robust and reliable through several coordinated protection mechanisms. Protection on the Asterisk server is therefore essential to ensure secure and trouble-free operation. Regardless of whether this is a Raspberry Pi, as shown here, a virtual machine internally or in the cloud, or a single bare metal server on the internet.

Therefore, a solid firewall using the UFW tool based on IPTables is demonstrated here.

To simplify the configuration of IPTables rules, we use the program UFW (Uncomplicated Firewall), which is installed as follows.

~# apt-get update
~# apt install -y ufw

Essential firewall rules on Asterisk

First, we save the default settings on the firewall.

• incoming = deny:
  All incoming connections (i.e. from outside to the server) are blocked by default unless explicit rules are created that allow specific ports or IPs.
• outgoing = allow:
  All outgoing connections (i.e., connections from outside to the server, to the Internet or internal network) are allowed by default. This means the server can establish connections without restrictions.

The corresponding rules:

~# ufw default deny incoming
~# ufw default allow outgoing

and 

~# ufw allow from any to any port 5060 proto udp comment ‘Allow SIP signaling from all IPs (UDP 5060)’
~# ufw allow from any to any port 10000:20000 proto udp comment ‘Allow RTP media streams from all IPs (UDP 10000-20000)’
~# ufw allow from 192.168.0.0/16 to any port 80 proto tcp comment 'Allow HTTP from internal hosts'
~# ufw allow from 192.168.0.0/16 to any port 80 proto tcp comment 'Allow HTTP from internal hosts'
~# ufw allow from 192.168.0.0/16 to any port 443 proto tcp comment 'Allow HTTPS from internal host's
~# ufw allow from 192.168.0.0/16 to any port 22 proto tcp comment ‘Allow SSH from internal hosts’

Reason for the settings:

1. SIP Signaling (UDP 5060) – Access from all IP addresses permitted
   The UDP port 5060 for SIP is currently open to all source IP addresses worldwide. This enables the reception of SIP signals regardless of the provider or location of the remote party. This configuration allows for maximum accessibility, but carries a certain risk from possible SIP scanning or brute-force attacks from the internet.
2. RTP Media Stream (UDP 10000–20000) – also open to all IPs
   UDP ports 10000 to 20000, used for transmitting RTP voice data, are currently open to all IP addresses. This setting ensures that media streams can be received from any remote site, which may be necessary for a generic VoIP environment, but does not exclude unwanted traffic.
3. Internal services (HTTP, HTTPS, SSH) only from the local network (192.168.0.0/16)
   These services are not publicly available, but only available to hosts on the internal LAN. This reduces attack surfaces and avoids unnecessary exposure to the Internet.

Instead of the rules just outlined, one could also take a stricter approach, as demonstrated here with the example of Deutsche Telekom. One would only have to use the IP addresses of one's provider.

~# ufw allow from 87.128.0.0/11 to any port 5060 proto udp comment 'Allow SIP signaling from Telekom SIP servers (UDP 5060)'
~# ufw allow from 217.0.0.0/13 to any port 5060 proto udp comment ‘Allow SIP signaling from Telekom SIP servers (UDP 5060)’
~# ufw allow from 87.128.0.0/11 to any port 10000:20000 proto udp comment 'Allow RTP media streams from Telekom IP ranges (UDP 10000-20000)'
~# ufw allow from 217.0.0.0/13 to any port 10000:20000 proto udp comment ‘Allow RTP media streams from Telekom IP ranges (UDP 10000-20000)’

Please note:
This restriction to my own telephony provider resulted in incoming calls working as intended, but outgoing calls briefly connecting to the other party. I couldn't hear any audio in the connection, and the connection regularly dropped. Therefore, the "from any to any port" version is recommended. Instead, additional measures such as Fail2ban with SIP-specific filters should be used to protect against unwanted access. This effectively protects against brute-force attacks or scans on port 5060 without restricting legitimate traffic.

Finally, the firewall is started.

~# ufw enable
~# ufw status verbose

Or if it is already active, the rule will be reloaded with

~# ufw reload
~# ufw status verbose

This means your Asterisk is also rock solidly protected.

Additional protection with Fail2Ban

If you also want to fend off attacks, you can do so very effectively with Fail2ban. This is installed with

~# apt -y install fail2ban

Then a /etc/fail2ban/jail.local is created and filled.

~# vi /etc/fail2ban/jail.local
[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 192.168.0.0/24
ignorecommand =
bantime  = 3600
findtime  = 600
maxretry = 5
maxmatches = %(maxretry)s
action = %(action_mwl)s
destemail = fail2ban@example.tld
sender = asterisk@example.tld
mta = sendmail

[sshd]
enabled = true
port = 22
filter = sshd
logpath = /var/log/auth.log
maxretry = 5
bantime = 3600
findtime = 3600

[asterisk]
enabled  = true
filter   = asterisk
port     = 5060,5061,10000:20000
protocol = udp,tcp
logpath  = /var/log/asterisk/full
maxretry = 5
findtime = 600
bantime  = 3600

[recidive]
enabled  = true
logpath  = /var/log/fail2ban.log
bantime  = 7d
findtime = 1d
maxretry = 5

The filters for asterisk and sshd, respectively recidive, are located in /etc/fail2ban/filter.d/. The recidive jail monitors which IPs have been banned by Fail2Ban more often (i.e., "repeat offenders"). And the email delivery settings in [DEFAULT] are only effective if your Asterisk also has a mail client configured. This is to be expected, since otherwise, sending voicemail messages via email wouldn't work.

~# systemctl restart fail2ban.service
~# systemctl status fail2ban.service

starts the Fail2Ban. And you can view the jails this way.

~# fail2ban-client status
~# fail2ban-client status sshd
~# fail2ban-client status asterisk

This means Asterisk has absolutely solid security. Depending on which services and ports need to be open, this can be secured via the firewall or with Fail2ban.