3CX beveiligen tegen SIP-aanvallen met een eigen IP-blacklist
Een publiek bereikbare 3CX-installatie krijgt vroeg of laat ongewenst SIP-verkeer te verwerken. Geautomatiseerde scanners zoeken continu naar bereikbare VoIP-systemen. Vervolgens kunnen ze proberen extensies te registreren, authenticatiegegevens te raden of telefoniediensten te misbruiken.
In mijn eigen 3CX-omgeving zie ik dat ook gebeuren. De ingebouwde beveiliging van 3CX en de Global IP Blacklist blokkeren al veel bekende aanvallers. Toch wil ik zelf bepalen vanuit welke delen van de wereld mijn 3CX-installatie bereikbaar moet zijn.
Daarom combineer ik verschillende beveiligingslagen: firewall filtering, de ingebouwde 3CX Anti-Hacking functies, de Global IP Blacklist en een eigen blacklist met IP-ranges.
De belangrijkste vraag is daarbij:
Vanuit welke IP-adressen moet mijn 3CX-installatie werkelijk SIP-verkeer kunnen ontvangen?
Dat antwoord vormt de basis van mijn beveiligingsbeleid.
Begin bij de firewall
Een 3CX-server die rechtstreeks via internet bereikbaar is, krijgt verkeer uit de hele wereld aangeboden wanneer je daar geen beperkingen aan koppelt.
De firewall vormt daarom de eerste beveiligingslaag. Je kunt daar verkeer beperken voordat het de 3CX-server bereikt. 3CX beschrijft zelf dat de firewall nodig blijft naast de ingebouwde IP Blacklist. Wanneer je bijvoorbeeld alleen verkeer van bepaalde VoIP-providers wilt toelaten, hoort die beperking op de firewall te worden ingesteld.
In mijn omgeving blokkeer ik bijvoorbeeld verkeer uit delen van Azië, Oceanië, Afrika en Zuid-Amerika. Europa en Noord-Amerika blijven grotendeels bereikbaar omdat daar legitieme gebruikers of diensten vandaan kunnen komen.
Dat beleid hangt volledig af van de organisatie.
Een Belgische onderneming met medewerkers in België, Nederland, Frankrijk en Duitsland heeft een ander toegangsprofiel dan een onderneming met medewerkers in twintig landen.
Geoblocking is daarom een beleidskeuze die gebaseerd moet zijn op het werkelijke gebruikersprofiel van de organisatie.
3CX heeft zelf al meerdere beveiligingslagen
3CX beschikt over ingebouwde mechanismen om ongewenst verkeer en verdachte authenticatiepogingen te blokkeren.
De huidige 3CX-documentatie beschrijft onder andere automatische blokkering na herhaalde foutieve authenticatiepogingen en de mogelijkheid om IP-adressen en IP-ranges expliciet toe te laten of te weigeren. De configuratie bevindt zich in Admin > Advanced > IP Blacklist.
3CX: Anti Hacking, Whitelist en Blacklist
3CX Global IP Blacklist
3CX beschikt daarnaast over een centrale Global IP Blacklist. Deelnemende 3CX-installaties kunnen bekende aanvallende IP-adressen ontvangen vanuit deze centrale lijst. Nieuwe blacklistgebeurtenissen kunnen ook bijdragen aan deze globale lijst.
Deze beveiliging is nuttig omdat je daarmee gebruikmaakt van informatie uit een groter aantal 3CX-installaties.
3CX Anti-Hacking
De Anti-Hacking-functionaliteit biedt aanvullende bescherming tegen veelvoorkomende SIP- en webaanvalspatronen. Binnen Admin > Advanced kan je de beveiligingsinstellingen verder afstemmen.
Voor mijn eigen omgeving kijk ik daarom naar meerdere beveiligingslagen.
De 3CX-beveiliging beschermt de PBX. De firewall bepaalt welk verkeer de PBX überhaupt kan bereiken.
Waarom een eigen IP-blacklist?
Naast de automatische beveiliging van 3CX gebruik ik een eigen blacklist.
De reden is praktisch. Wanneer ik herhaaldelijk aanvallen uit een bepaald land zie en ik weet dat geen enkele legitieme gebruiker van mijn omgeving vanuit dat land verbinding hoeft te maken, kan ik ervoor kiezen om de betreffende IP-ranges vooraf te blokkeren.
Daarmee werk ik op basis van een vooraf bepaald toegangsbeleid.
Een individuele aanvaller kan bijvoorbeeld door 3CX automatisch worden geblokkeerd. Bij een land waarvan ik op voorhand weet dat daar geen legitieme gebruikers zitten, kan ik een veel grotere verzameling IP-ranges blokkeren.
Dat vraagt wel om een duidelijke bedrijfscontext.
Wanneer medewerkers regelmatig vanuit het buitenland werken, kan een geografische blokkering rechtstreeks invloed hebben op hun bereikbaarheid. Ook externe VoIP-providers, leveranciers en andere diensten kunnen IP-adressen gebruiken die je aanvankelijk niet verwacht.
Waar haal je de IP-ranges vandaan?
Er bestaan verschillende databases waarmee je IP-adressen aan landen kunt koppelen.
In mijn oorspronkelijke werkwijze gebruikte ik onder andere:
DB-IP biedt een gratis IP to Country Lite-database aan in CSV- en MMDB-formaat. De Lite-database heeft een beperktere dekking en nauwkeurigheid dan de commerciële database en wordt onder de Creative Commons Attribution 4.0-licentie aangeboden.
De actuele DB-IP-documentatie beschrijft de IP to Country Lite CSV als een lijst met onder andere een eerste IP-adres, laatste IP-adres en landcode.
Voor mijn specifieke workflow gebruik ik IP2Location omdat de IP-Country-database ook een CIDR-formaat aanbiedt. De actuele IP2Location-databasepagina vermeldt zowel CSV als CIDR als beschikbare formaten.
IP2Location IP-Country Database
Van land naar CIDR-lijst
Stel dat je verkeer uit het Verenigd Koninkrijk wilt blokkeren.
Bij een geschikte IP-database selecteer je het gewenste land en IPv4. Wanneer de bron CIDR ondersteunt, kies je CIDR als uitvoerformaat.
Je krijgt vervolgens netwerkblokken zoals:
2.16.14.0/24
2.16.27.0/24
2.16.35.0/24
2.16.37.0/24De exacte IP-ranges zijn geen vaste gegevens. IP-adressen worden opnieuw toegewezen en databases worden bijgewerkt. Gebruik daarom altijd een actuele bron wanneer je een nieuwe blacklist samenstelt.
De CSV voorbereiden
De volgende stap is het voorbereiden van het bestand voor mijn importworkflow.
Ik verwijder eerst de informatieve regels bovenaan het gedownloade bestand en open de resterende gegevens in Excel. Daarbij behandel ik de IP-ranges als tekst.
Vervolgens voeg ik de kolommen toe die ik voor mijn blacklist gebruik:
| Kolom | Inhoud |
|---|---|
IP | CIDR-netwerk |
expirationDate | Datum waarop de regel opnieuw moet worden beoordeeld |
description | Omschrijving van het land of de reden |
De expirationDate en description voeg ik zelf toe. Hierdoor kan ik later achterhalen waarom een netwerk werd geblokkeerd en wanneer ik die beslissing opnieuw wil beoordelen.
Van CSV naar JSON
Voor mijn importworkflow zet ik het CSV-bestand vervolgens om naar JSON.
De oorspronkelijke werkwijze gebruikt hiervoor:
De praktische workflow is:
- Selecteer het CSV-bestand.
- Controleer of de eerste rij als kolomnamen wordt gebruikt.
- Controleer de records.
- Genereer de JSON-output.
- Download het JSON-bestand.
- Open het resultaat bijvoorbeeld in Notepad++.
- Controleer de structuur en de velden.
Deze controle is belangrijk wanneer je een grote lijst importeert. Een fout in de brongegevens kan zich anders vermenigvuldigen over duizenden records.
Wat als je geen CIDR-bestand krijgt?
Niet iedere bron levert IP-ranges rechtstreeks als CIDR-netwerken aan.
Sommige databases gebruiken een begin- en eindadres. Die gegevens moeten eerst worden geconverteerd naar CIDR-netwerken.
In de oorspronkelijke werkwijze werd hiervoor deze tool gebruikt:
Bij IP2Location kan deze extra conversiestap worden vermeden wanneer je rechtstreeks een CIDR-output gebruikt. De actuele IP2Location-database biedt CIDR als beschikbaar formaat.
JSON importeren in 3CX
Wanneer het JSON-bestand gecontroleerd is, kan de blacklist in de 3CX-configuratie worden verwerkt.
In de huidige 3CX-documentatie bevindt de IP-blacklistfunctionaliteit zich onder:
Admin > Advanced > IP Blacklist
3CX ondersteunt daar individuele IP-adressen en netwerkbereiken. Een netwerk kan bijvoorbeeld met een subnetmasker worden gedefinieerd.
3CX Advanced System Features V20
Voor de workflow die ik in mijn omgeving gebruik, ziet de stap er als volgt uit:
Admin Console → Advanced → IP Blacklist → Import
Bij grote lijsten kan de verwerking enige tijd duren. Mijn eigen blacklist groeide in de beschreven omgeving uit tot een zeer omvangrijke lijst.
Wanneer de Management Console tijdens een grote import tijdelijk traag reageert, wacht ik eerst tot de verwerking is afgerond voordat ik verdere acties uitvoer.
Let op met IP-ranges
Een brede blacklist vereist controle voordat je ze toepast.
3CX waarschuwt zelf dat een geblokkeerde range niet het IP-adres van de PBX mag bevatten.
Controleer daarnaast of de range geen legitieme SIP-provider, externe locatie, gebruiker of andere dienst omvat.
Een fout in een firewallregel of blacklist kan immers rechtstreeks gevolgen hebben voor telefonie.
Bij IP-gebaseerde SIP-trunks moeten de toegestane bronadressen bovendien overeenkomen met de adressen die de SIP-provider documenteert. 3CX beschrijft dit expliciet voor IP-based trunks.
Een grote blacklist vraagt onderhoud
Een blacklist met duizenden IP-ranges is een onderhoudstaak.
IP-geolocatiedatabases veranderen. Ook de organisatie verandert. Een land dat vandaag geen gebruikers bevat, kan later relevant worden. Een uitzondering die vandaag nodig is, kan later verdwijnen.
Daarom gebruik ik bewust een expirationDate in mijn eigen CSV-structuur.
Die datum creëert een natuurlijk evaluatiemoment.
Het principe is eenvoudig:
Elke geografische blokkering moet een reden en een evaluatiemoment hebben.
Dat maakt de blacklist beter beheersbaar wanneer de organisatie, gebruikers of externe diensten veranderen.
Mijn beveiligingsmodel voor 3CX
Voor een publiek bereikbare 3CX-installatie kijk ik naar de beveiliging als een combinatie van verschillende maatregelen.
1. Firewall
Beperk het verkeer dat de PBX kan bereiken. Gebruik geoblocking wanneer het bedrijfsprofiel dat toelaat.
2. 3CX Global IP Blacklist
Gebruik de centrale blacklist van 3CX voor bekende aanvallende IP-adressen.
3. 3CX Anti-Hacking
Gebruik de ingebouwde beveiligingsfuncties om verdachte SIP- en authenticatieactiviteiten te detecteren en blokkeren.
4. Eigen IP-blacklist
Voeg IP-ranges toe wanneer je voldoende zekerheid hebt dat daar geen legitiem verkeer vandaan hoeft te komen.
5. Periodieke evaluatie
Gebruik een vervaldatum en controleer de regels opnieuw wanneer gebruikers, locaties, providers of de infrastructuur veranderen.
Security begint bij de architectuur
Een 3CX-installatie beveiligen begint voor mij bij een eenvoudige vraag:
Welk verkeer moet deze server werkelijk kunnen ontvangen?
Een Belgische onderneming met medewerkers in België en de buurlanden heeft een ander toegangsmodel dan een internationale organisatie.
Die bedrijfscontext bepaalt welke firewallregels en IP-ranges logisch zijn.
Een firewallregel, een IP-blacklist en een 3CX Anti-Hacking-instelling zijn technische maatregelen binnen een groter beveiligingsmodel. De architectuur bepaalt eerst welke verbindingen nodig zijn. De beveiligingsmaatregelen voeren dat beleid vervolgens uit.
Voor mijn eigen 3CX-omgeving betekent dit dat ik ongewenst verkeer zo vroeg mogelijk probeer te blokkeren en de resterende verbindingen door de beveiligingsfuncties van 3CX laat controleren.
De beste IP-blacklist is daarom niet de langste lijst. Het is een lijst die aansluit bij de werkelijke toegangsbehoefte van de organisatie en die regelmatig wordt geëvalueerd.
Ik ben een Systems Integrator en Infrastructure Architect met meer dan 28 jaar professionele ervaring. Mijn mening is mijn eigen mening en de visie van Peritus Consult, niet de mening van mijn werkgever Lab9 Pro.
