Mijn CRM werd aangevallen, en dit is waarom de data veilig bleef

CRM beveiliging is zoiets waar je als gebruiker eigenlijk zo min mogelijk van wilt merken. Achter de schermen gebeurt echter veel meer dan je misschien denkt. Bots en geautomatiseerde scanners struinen voortdurend het internet af. Ze zoeken naar websites, servers en applicaties die ergens een deur op een kier hebben laten staan.

Onlangs zag ik daar een mooi voorbeeld van in de logbestanden van mijn eigen CRM. In deze applicatie verwerk ik vanzelfsprekend gegevens van mij en mijn klanten. Binnen een paar seconden probeerde één bezoeker honderden verschillende bestanden en locaties op de server te openen.

Dat klinkt misschien verontrustend. Daarom het belangrijkste maar meteen voorop: de aanval is niet geslaagd en de gegevens in het CRM zijn veilig gebleven.

CRM beveiliging in de praktijk

De verzoeken kwamen vanaf het IP-adres 195.178.110.242. Het begon met een normaal bezoek aan de hoofdpagina van het CRM. De server gaf daarop een HTTP 200-respons. De bezoeker kon de publieke pagina dus gewoon bekijken.

Vervolgens vroeg de bezoeker twee JavaScript-bestanden op die deze pagina gebruikt. Ook dat is normaal gedrag. Direct daarna veranderde het patroon echter compleet.

De bezoeker begon razendsnel allerlei bekende bestandsnamen en locaties te proberen. Denk bijvoorbeeld aan .git/config, .git-credentials en composer.json. Ook databaseback-ups, configuratiebestanden en debugpagina’s kwamen voorbij. Daarnaast zocht de scanner naar bestanden die mogelijk wachtwoorden of API-sleutels bevatten.

Een geautomatiseerde vulnerability scan

Dit noemen we een geautomatiseerde vulnerability scan. De scanner weet vooraf niet welke software er op mijn server draait. Dat kon je in dit geval ook heel duidelijk aan de verzoeken zien.

De scanner zocht niet alleen naar bestanden van PHP-applicaties. Ook configuraties van Python, Ruby, Docker, Git, Jenkins en verschillende cloudomgevingen kwamen voorbij.

Het principe is eigenlijk vrij simpel. Probeer in korte tijd een enorme lijst met bekende bestanden en locaties. Kijk vervolgens of de server ergens iets prijsgeeft.

Een vergeten databaseback-up kan bijvoorbeeld interessante informatie bevatten. Hetzelfde geldt voor een publiek toegankelijke .git-directory of een configuratiebestand met inloggegevens. Vindt een scanner zoiets, dan heeft een aanvaller mogelijk een aanknopingspunt voor een volgende stap.

Maar de deuren bleven dicht

En precies daar ging het voor deze scanner mis.

Bestanden die niet bestonden, leverden netjes een HTTP 404 “Not Found” op. Bij gevoelige bestanden ging de server nog een stap verder. De configuratie van de webserver blokkeerde deze verzoeken direct met HTTP 403 “Forbidden”.

In de logs zag ik bijvoorbeeld verzoeken naar .git, .github en .git-credentials. Ook probeerde de scanner verschillende back-upbestanden te openen. De webserver hield deze verzoeken tegen.

Ik heb vervolgens de honderden verdachte verzoeken gecontroleerd op succesvolle HTTP 200-responses. Daarbij vond ik geen enkel gevoelig bestand dat de scanner succesvol had opgehaald. De normale webpagina en publieke JavaScript-bestanden gaven uiteraard wel een HTTP 200-respons. Een gewone bezoeker mag die bestanden tenslotte ook opvragen.

En de gegevens in mijn CRM?

Dat is natuurlijk de belangrijkste vraag.

Het feit dat iemand mijn webserver kan benaderen, betekent niet dat diegene toegang heeft tot het CRM of de onderliggende database. De database staat niet als een publiek bestand op de website.

Daarnaast beschermt de applicatie de verschillende onderdelen met onder andere authenticatie, sessies en rechtencontroles. Ook verwerkt het CRM databaseverzoeken op een beveiligde manier. Dat zijn allemaal onderdelen van een goede CRM beveiliging.

Deze scanner probeerde juist buiten die normale route om een zwakke plek te vinden. Hij zocht naar bestanden die door een verkeerde serverconfiguratie per ongeluk openbaar zouden kunnen staan.

Op basis van de onderzochte logs vond ik daar geen aanwijzingen voor. De scanner haalde geen configuratie- of databasebestand op. Ook zag ik geen toegang tot afgeschermde CRM-gegevens.

De gegevens in mijn CRM zijn dus veilig gebleven.

Dit gebeurt vaker dan je denkt

Dit soort scans zijn helaas geen uitzondering. Zodra een server of subdomein vanaf het internet bereikbaar is, kunnen geautomatiseerde systemen hem vinden.

Dat betekent niet automatisch dat iemand persoonlijk achter mijn CRM of mijn klanten aan zat. Vaak controleren scanners automatisch enorme hoeveelheden servers, IP-adressen en domeinen. Ze proberen simpelweg dezelfde lijst met mogelijke zwakke plekken op iedere server.

Juist daarom vind ik een goede beveiliging belangrijk. Je kunt niet voorkomen dat iemand aan de deur voelt. Je kunt er wel voor zorgen dat die deur op slot zit.

Voor mij was dit vooral een interessant praktijkvoorbeeld van iets wat zich normaal gesproken volledig op de achtergrond afspeelt. De scanner probeerde in een paar seconden honderden deuren. De beveiligingsmaatregelen deden vervolgens precies waarvoor ze bedoeld zijn.

Het betreffende IP-adres kan ik daarna gewoon blokkeren.

Beveiliging betekent namelijk niet dat niemand ooit probeert binnen te komen. Het betekent vooral dat wanneer iemand het probeert, er niets te halen valt.