Warum sollte man Asterisk zusätzlich schützen, auch wenn er hinter einer Firewall steht?

Eine Firewall bildet zwar die erste Schutzschicht und beschränkt den Zugriff auf definierte Ports und IP-Bereiche. Dennoch ist es essenziell, den Asterisk-Server selbst weiter abzusichern, weil:

1. Verteidigung in der Tiefe (Defense in Depth):
   Sicherheitskonzepte funktionieren am besten mit mehreren Schutzebenen. Sollte die Firewall aus irgendeinem Grund eine Lücke haben (Fehlkonfiguration, Zero-Day-Lücke oder Insiderangriff), schützt eine zusätzlich abgesicherte Asterisk-Instanz davor, dass Angreifer direkt Zugriff bekommen.
2. Schutz vor internen Bedrohungen:
   Nicht alle Angriffe kommen von außen. Ein kompromittiertes Gerät oder ein böswilliger Insider im lokalen Netzwerk könnte sonst ungehindert auf den Asterisk zugreifen. Zusätzliche Schutzmechanismen auf Asterisk begrenzen das Risiko.
3. Fehlerhafte Firewall-Konfigurationen:
   Firewalls sind komplex und Fehler bei Regeln passieren häufig. Ein gut gehärteter Asterisk-Server stellt sicher, dass selbst bei falsch gesetzten Firewall-Regeln keine unautorisierte Nutzung möglich ist.
4. Spezifische Schwachstellen im VoIP-Protokoll:
   SIP und RTP sind komplexe Protokolle mit diversen Angriffsmöglichkeiten (z.B. Brute-Force auf Accounts, SIP-Flooding). Schutzmechanismen direkt auf Asterisk (Fail2Ban, sichere Authentifizierung, TLS) helfen, diese Angriffe gezielt abzuwehren.
5. Auditierbarkeit und gezielte Reaktion:
   Durch spezifische Schutzmaßnahmen auf Asterisk können Angriffe besser erkannt, protokolliert und individuell beantwortet werden, ohne auf die Firewall angewiesen zu sein.

Diese Punkte zeigen, dass zwar eine vorgeschaltete Firewall sehr wichtig ist, aber kann kein Allheilmittel sein. Die Sicherheit wird erst durch mehrere aufeinander abgestimmte Schutzmechanismen robust und zuverlässig. Der Schutz auf dem Asterisk-Server ist daher unerlässlich, um den Betrieb sicher und störungsfrei zu gewährleisten. Egal, ob das wie hier ein Raspberry Pi ist, eine Virtual Machine intern oder in einer Cloud oder ein einzelner Bare Metal Server im Internet.
Deshalb wird hier eine solide Firewall mittel des UFW-Tools auf Basis von IPTables gezeigt.

Wir benutzen zur leichteren Konfiguration der IPTables-Regeln das Programm UFW (Uncomplicated Firewall), das wie folgt installiert wird.

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

Essentielle Firewall-Regeln auf dem Asterisk

Zuerst sichern wir uns die Default-Einstellungen auf der Firewall.

• incoming = deny:
  Alle eingehenden Verbindungen (also von außen zu dem Server) werden standardmäßig blockiert, es sei denn, es werden explizite Regeln erstellt, die bestimmte Ports oder IPs zulassen.
• outgoing = allow:
  Alle ausgehenden Verbindungen (also von außen zu dem Server ins Internet oder interne Netz) werden standardmäßig erlaubt. Das heißt, der Server kann ohne Einschränkung Verbindungen aufbauen.

Die passenden Rules dazu:

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

und 

~# 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'

Zu beachten ist:
Die Netzwerk-Ranges “87.128.0.0/11”, “217.0.0.0/13” gehören zur Telekom und auch hier können in Ihrem Bereich andere IP-Adressen des Registrars gelten, insbesondere wenn Ihr Anbieter nicht die Telekom ist. Und anstelle von “192.168.0.0/16” kommt auch hier Ihre Konstellation rein.

Begründung der Einstellungen:

1. SIP Signaling (UDP 5060) nur von Telekom-IP-Bereichen erlauben
   Telekom stellt die SIP-Registrar- und Proxy-Server aus diesen IP-Blocks bereit. Die erlaubten IP-Range begrenzt den SIP-Zugriff auf legitime Telekom-Server und minimiert Angriffsfläche von außen. Beachten Sie eben gemachten Kommentar.
2. RTP-Medienstrom (UDP 10000-20000) ebenfalls nur von Telekom-IP-Bereichen
   Der RTP-Datenstrom, der die Sprachpakete transportiert, muss nur von und zu den Telekom-IP-Bereichen erreichbar sein. Diese Restriktion schützt vor unerwünschtem RTP-Traffic.
3. Interne Dienste (HTTP, HTTPS, SSH) nur aus dem lokalen Netzwerk (192.168.0.0/16)
   Diese Dienste sind nicht öffentlich, sondern nur für Hosts im internen LAN verfügbar. Das reduziert Angriffsflächen und vermeidet unnötige Öffnungen ins Internet.

Abschließend wird die Firewall gestartet.

~# ufw enable
~# ufw status verbose

Oder sofern sie bereits aktiv ist, werden die Regel neugeladen mit

~# ufw reload
~# ufw status verbose

Somit ist auch Ihr Asterisk grundsolide abgesichert.

Zusätzlicher Schutz mit Fail2Ban

Wollen Sie auch Angriffe abwehren, so geht das sehr praktikabel mit Fail2ban. Das wird installiert mit

~# apt -y install fail2ban

Anschließend wird eine /etc/fail2ban/jail.local angelegt und befüllt.

~# 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

Die Filter für asterisk und sshd respektive recidive liegen unter /etc/fail2ban/filter.d/.  Wobei die Jail recidive überwacht, welche IPs schon öfter von Fail2Ban generell gebannt wurden (also „Wiederholungstäter“). Und die Angaben zum Mailversand in [DEFAULT] sind nur wirksam, wenn auch Ihrem Asterisk ein Mail-Client einrichtet ist. Was aber anzunehmen ist, da sonst der Versand der Voicemail-Nachrichten per Mail nicht funktionieren würde.

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

startet den Fail2Ban. Und die Jails kann man sich so anzeigen lassen.

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

Somit ist der Asterisk absolut solide grundabgesichert. Je nachdem, welche Services und damit Ports offen sein sollen, lässt sich das auch in der Firewall als auch mit Fail2ban absichern.