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 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 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’

Begründung der Einstellungen:

1. SIP-Signalisierung (UDP 5060) – Zugriff von allen IP-Adressen erlaubt
   Der UDP-Port 5060 für SIP wird aktuell für alle Quell-IP-Adressen weltweit geöffnet. Dies ermöglicht den Empfang von SIP-Signalen unabhängig vom Anbieter oder Standort der Gegenstelle. Diese Konfiguration erlaubt maximale Erreichbarkeit, birgt jedoch ein gewisses Risiko durch mögliche SIP-Scan- oder Brute-Force-Angriffe aus dem Internet.
2. RTP-Medienstrom (UDP 10000–20000) – ebenfalls offen für alle IPs
   Die UDP-Ports 10000 bis 20000, die für die Übertragung von RTP-Sprachdaten verwendet werden, sind aktuell für alle IP-Adressen freigegeben. Diese Einstellung gewährleistet, dass Medienströme von jeder Gegenstelle empfangen werden können, was für eine generische VoIP-Umgebung notwendig sein kann, allerdings auch unerwünschten Traffic nicht ausschließt.
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.
    

Statt der eben gemachten Regeln könnte man auch strenger vorgehen, wie hier am Beispiel der Deutschen Telekom gezeigt. Man müsste also nur die IP-Adressen seines Providers einsetzen.

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

Zu beachten ist:
Diese Beschränkung auf den eigenen Telefonie-Provider hatte bei mir zur Folge, dass eingehende Telefonate wie gewünscht funktionierten, ausgehende zwar kurz eine Verbindung zur Gegenseite aufbauten. Einen Ton konnte man in der Verbindung nicht hören, sondern die Verbindung brach regelmässig zusammen. Deshalb empfiehlt sich hier die Version mit “from any to any port”. Die Absicherung gegen ungewollte Zugriffe sollte stattdessen über ergänzende Maßnahmen wie Fail2ban mit SIP-spezifischen Filtern erfolgen. Dies schützt effektiv vor Brute-Force-Angriffen oder Scans auf Port 5060, ohne legitimen Traffic einzuschränken.

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.