Met de botte bijl de server in

Extra beveiliging komt vaak pas ter sprake als het te laat is. Dan pas zie je eigenlijk hoe veel slechterikken er online actief zijn.

Geen zin in de inleiding? Ga hier naar de installatie-instructies!

Mijn server werd laatst gehackt. Geen versleutelde bestanden, gelukkig. Maar wel een cryptominer er op.

Ik kwam er achter omdat ik een melding kreeg van DirectAdmin. Net voordat ik op de fiets naar huis stapte. “Warning: The system load average is 10.08.” 10 is nog niet zo spannend. Misschien wat processen die zijn blijven hangen, of een back-up die gemaakt wordt.

Nog geen tien minuten later aan de eetkamertafel zoemde mijn telefoon weer. “Warning: The system load average is 22.49.” Ho even, dat kan zo maar niet. Via mijn telefoon ingelogd in DirectAdmin, de proces-lijst opgeroepen. Daar stond hij. Vol trots bovenaan de lijst, flink te stampen. Een cryptominer. Geld te verdienen met mijn server? Ik dacht het niet! Twee minuten later stond de server uit en keken mijn vrouw en kind me vragend aan. Want papa was opeens wel even héél snel.

Gelukkig ging het in dit geval om mijn ‘staging’ server. De server waar mijn applicaties op draaien die ik ontwikkeld heb en waar de opdrachtgever dan kan kijken hoe het er uit ziet, voordat ik de applicatie live zet. Wat dat betreft maakte het me niet eens zo heel veel uit, want die kan ik gemakkelijk herinstalleren en doorgaan. Maar het heeft me wel aan het denken gezet. Want als ze al op mijn staging server komen, dan kunnen ze dat ook bij mijn live server. En dáár word ik dan weer minder blij van.

De oorzaak

Tot op de dag van vandaag weet ik niet hoe ze er in zijn gekomen. Ik zorg altijd dat mijn server up-to-date is, draai de nieuwste versies van bijvoorbeeld OpenSSL en Apache en heb, dacht ik, redelijk sterke wachtwoorden, zelfs voor mijn testomgevingen. Toch wisten ze een bestand op root-niveau te plaatsen, wat eigenlijk alleen maar kan betekenen dat ze ofwel het root-wachtwoord wisten, ofwel zichzelf vanuit een user-account hebben kunnen upgraden.

In de logs was niets terug te vinden. Wachtwoord-bestanden zoals /etc/passwd en /etc/shadow waren intact. Uiteindelijk heb ik de klopjacht maar opgegeven en heb ik me neergelegd bij een 1-0 nederlaag.

En toen

De beslissing om een nieuwe server op te leveren was dan ook snel gemaakt. Na het installeren en het zorgen voor de juiste versies van PHP, GIT en nog meer van dat soort dingen, zocht ik mijn heil in de firewall van de server. DirectAdmin biedt namelijk ‘out of the box’ de mogelijkheid om de logs uit te lezen en te bepalen of er IP-adressen vaak foutief inloggen. De Brute Force Monitor.

Voor degene die niet weten hoe een Brute Force aanval werkt, eigenlijk is het heel simpel. Je hebt een deur. Je hebt een oneindig grote sleutelbos met mogelijke sleutels. Begin maar vooraan en ga net zo lang door totdat je de juiste sleutel hebt.

Met een kleine aanpassing in DirectAdmin en de installatie van een aantal extra scriptjes is het mogelijk om de logs volledig geautomatiseerd uit te laten lezen en de IP-adressen te laten blokkeren. Dat wist ik, maar ik had nog nooit de moeite genomen om me daar in te verdiepen. Daar werd het nu tijd voor.

Installeren

Met wat hulp van mijn technische collega’s heb ik op mijn gloednieuwe staging server de nodige stappen doorlopen om DirectAdmin automatisch te laten blokkeren. Via SSH waren dat de volgende 12 commando’s:

1. cd /etc/init.d2. mv -fv iptables iptables.backup3. wget http://files.directadmin.com/services/all/block_ips/2.1/iptables4. chmod 755 iptables5. /etc/init.d/iptables restart6. cd /usr/local/directadmin/scripts/custom7. wget http://files.directadmin.com/services/all/block_ip.sh8. wget http://files.directadmin.com/services/all/show_blocked_ips.sh9. wget http://files.directadmin.com/services/all/unblock_ip.sh10. wget http://files.directadmin.com/services/all/brute_force_notice_ip.sh11. chmod 700 block_ip.sh show_blocked_ips.sh unblock_ip.sh brute_force_notice_ip.sh12. touch /root/blocked_ips.txt; touch /root/exempt_ips.txt

Stap 1 t/m 5 hebben te maken met het instellen van IP-tables. Dit is de firewall van de server en door het overnemen van de DirectAdmin versie kan DA er vervolgens mee gaan babbelen.

Stap 6 t/m 11 halen de benodigde scripts van de DirectAdmin server af. De namen spreken redelijk voor zich.

• block_ip blokkeert een IP-adres
• show_blocked_ips leest de geblokkeerde IP-adressen uit voor de weergave binnen DA
• unblock_ip haalt een IP-adres uit de firewall
• brute_force_notice_ip is het script wat de admins notificeert dat een IP-adres een brute force aanval uitvoert en vervolgens ook de blokkade uitvoert.

In stap 11 worden de bestanden van de benodigde rechten voorzien. Ten slotte worden in stap 12 twee lege tekst-bestanden aangemaakt, waarin de geblokkeerde IP-adressen (blocked_ips) en de IP-adressen op de ‘skip list’ (een soort whitelist) worden opgeslagen.

Configureren

Vervolgens moet er binnen DirectAdmin het een en ander geconfigureerd worden. Hiervoor zijn er in de Administrator Settings een paar instellingen te vinden.

Een klein puntje van aandacht zijn de ‘notify admins after’ opties. Dit gaat namelijk niet alleen om het notifyen van de admin via het DirectAdmin message system, maar óók om het blokkeren van de IP’s. Beide acties worden namelijk uitgevoerd door het brute_force_notice_ip script wat in stap 10 binnen gehaald wordt. In eerste instantie had ik dat niet eens door. Ik hoef heus niet bij iedere paar pogingen een melding te ontvangen, dus ik had de limiet op 1000 ingesteld staan. Maar ik vind 25 keer verkeerd inloggen al voldoende om iemand de deur te wijzen. Maarja, door die limiet op 1000 te zetten, gaat DirectAdmin ook pas blokkeren bij 1000 mislukte inlogpogingen. #waytoofriendly

Resultaten

Uiteindelijk staat dan toch alles goed ingesteld en kan het blokkeren beginnen. En hoe. Het heet met recht een Brute force monitor, want die aanvallen die zijn er. In drie dagen tijd heb ik van DirectAdmin 177 berichten gevonden en staan er tussen de 40 en 60 IP-adressen op de blacklist. Op de root-user zijn er bijna 90.000 inlogpogingen geweest, 1200 op user admin en 156 op user oracle. Wie? Oracle. Volgens mij doen die iets met databases, maar waarom die dan op mijn server zou moeten staan? Geen idee…

Conclusie

Het meest frappante van dit alles? Het is een staging-server. Er staat niks van waarde op, er draaien geen live sites en de enige manier om bij de server uit te komen is toevallig te weten hoe mijn ontwikkel-domein heet. Het gaat hier dus niet om een gerichte aanval, maar om willekeurige hackers die willekeurige IP-adressen afstruinen om met willekeurige gebruikersnamen (oracle, git, pi, jenkins, ubuntu en zo kan ik nog wel even doorgaan) in te loggen. Maar met nog 8 uur te gaan op dag drie en de teller voor root hard stijgend naar de honderdduizend, weet ik in ieder geval dat ik mijn wachtwoorden extra aan moet gaan scherpen. Stelletje etterbakken.

Ook extra bescherming toevoegen op je server? Stuur een ticket naar onze technische dienst en wij regelen het voor je. Gratis voor managed servers, €35 ex btw voor unmanaged.