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 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-Bereichen (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-Bereichen (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 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'

Please note:
The network ranges "87.128.0.0/11" and "217.0.0.0/13" belong to Telekom, and here, too, different registrar IP addresses may apply in your area, especially if your provider is not Telekom. And instead of "192.168.0.0/16," your configuration will be used here as well.

Reason for the settings:

1. Allow SIP signaling (UDP 5060) only from Telekom IP ranges
   Telekom provides the SIP registrar and proxy servers from these IP blocks. The permitted IP range limits SIP access to legitimate Telekom servers and minimizes the attack surface from outside. Note the comment just made.
2. RTP media stream (UDP 10000-20000) also only from Telekom IP ranges
   The RTP data stream transporting the voice packets must be accessible only from and to the Telekom IP ranges. This restriction protects against unwanted RTP 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.

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.