Hoe een luie reverse proxy-configuratie een crypto-botnet mijn thuisserver liet kapen

Ik schrijf vaak over de beste praktijken voor homelabbers, maar ik volg niet altijd mijn eigen advies. Dat kwam me onlangs duur te staan toen mijn homelab was gecompromitteerd en een crypto-bot de CPU van mijn server op 100% liet draaien—hier is wat ik heb gedaan om het te repareren.

Ik opende bijna elke zelf-gehoste dienst op het internet met een reverse proxy

Het maakte externe toegang gemakkelijk, oké?

Een paar jaar geleden ging ik op reis weg van mijn homelab. Ik had een VPN opgezet op een Raspberry Pi 3b, en sommige diensten gingen offline die ik moest repareren. Mijn VPN was traag en haperend (dankzij de 10/100Mbps poort op de Pi 3b) en dat maakte het onhoudbaar om te proberen diensten te repareren via de VPN.

Dus besloot ik de tijd die ik via VPN met de server verbonden was te gebruiken om eigenlijk alles op het netwerk via een reverse proxy te laten lopen. Dat zou het eenvoudig maken om op afstand toegang te krijgen tot alle zelfgehoste services die ik moest beheren als ik niet thuis was. Een bijkomend voordeel was dat ik, zelfs wanneer ik thuis was, gemakkelijker toegang tot de services had omdat ze allemaal een FQDN (fully qualified domain name) zouden hebben.

Het probleem is dat veel homelabbers dezelfde fout maken. Zodra je Nginx Proxy Manager of Cloudflare Tunnels hebt ingesteld, is het gemakkelijk om elke dienst met slechts een paar klikken buiten het netwerk beschikbaar te maken. Externe toegang tot die diensten hebben is handig, maar het is zeker niet de juiste keuze, zoals ik ontdekte.

Tegenwoordig heb ik Tailscale op de meeste van mijn apparaten geïnstalleerd, en dat draait op mijn server met een 2,5 Gb/s LAN-verbinding en een 1 Gb/s WAN-verbinding. Het probleem is dat ik nog steeds veel van mijn diensten achter mijn reverse proxy heb staan, want als het niet kapot is… ja, dan is het kapot.

Een opnieuw geïnstalleerde qBittorrent-container was mijn ondergang

Ik heb van container gewisseld en ben vergeten het wachtwoord terug te zetten… oeps

Onlangs heb ik mijn hele homelab herschikt, waarbij ik diensten van de ene node naar de andere verplaatste en diensten opnieuw installeerde om ze robuuster te maken—qBittorrent was een van die diensten.

Ik heb het grootste deel van de configuratie-informatie voor qBittorrent overgezet toen ik naar een nieuwe container overstapte. Het probleem is dat ik er eigenlijk geen wachtwoord voor had ingesteld. Het is zo lang geleden dat ik voor het laatst een verse qBittorrent-container heb ingezet dat ik volledig was vergeten dat het een wachtwoord in de logs genereerde en de gebruikersnaam op admin zette. Heel eerlijk gezegd dacht ik dat het overzetten van mijn configuratiebestanden mijn gebruiker/wachtwoord van de oude server naar de nieuwe server zou overbrengen—ik had het mis.

Iets wat ik niet wist, is dat er botnets zijn die actief het internet afzoeken op zoek naar blootgestelde qBittorrent admin web-UIs om te proberen te kraken. Ik ben daar eerder nooit slachtoffer van geworden omdat ik admin niet als gebruikersnaam gebruikte en mijn wachtwoord 48 tekens lang en willekeurig gegenereerd was.

De nieuwe container had echter een wachtwoord van acht tekens en gebruikte de gebruikersnaam admin, en daar kwam mijn probleem vandaan. Hoewel het een willekeurig gegenereerd wachtwoord had, was het slechts acht tekens lang, wat relatief gemakkelijk te kraken is voor botnets. Dus, met de gebruikersnaam admin en een gemakkelijk te kraken wachtwoord, werd mijn qBittorrent-instantie gecompromitteerd en zat er een botnet in.

Eenmaal binnen de qBittorrent-instantie, downloadde het botnet een testtorrent om ervoor te zorgen dat het de juiste machtigingen had die het nodig had, en toen vertrok het—een crypto-miner ging snel aan het werk op de server en begon mijn CPU-cores tot 100% te belasten. Dat was het moment waarop ik besefte wat er aan de hand was en begon te werken om het te fixen.

Het is een gemakkelijke vergissing om te maken, maar de gevolgen kunnen ernstig zijn

Gelukkig was de oplossing niet zo moeilijk, maar ik had hem eigenlijk helemaal niet hoeven maken.

Mijn qBittorrent-client draait op mijn Lenovo RD440 rackmount-server, die allesbehalve stil is. Normaal gesproken is het echter vrij rustig; mijn kantoor blijft koel dankzij een airconditioner die in het raam is gemonteerd, en het heeft niet veel belasting, dus de ventilatoren draaien eigenlijk nooit op volle snelheid. De cryptominer die daarentegen op 100% CPU-gebruik draait over beide Xeon-CPU's, veranderde de normaal gesproken stille server echter in een straalmotor.

Dit deed me onmiddellijk in het systeem duiken om te zien wat er aan de hand was. Ik kon het foutieve proces vinden en beëindigen, en ik ging vervolgens naar mijn qBittorrent-client en veranderde het wachtwoord. Vanaf daar dacht ik dat ik veilig was, maar ik miste de zwervende torrent die het botnet had geüpload, en ik miste ook de wijziging in mijn qBittorrent-configuratie die was aangebracht.

Uiteindelijk heb ik de qBittorrent-container helemaal opnieuw geïnstalleerd en al mijn ISO-bestanden teruggezet naar waar ze eerder waren, en de hack was voorbij. Het was een gek uur of twee om uit te vinden wat er aan de hand was en hoe het op te lossen, maar uiteindelijk kreeg ik het weer onder controle.

Mijn homelab is slechts zo veilig als ik het maak—en ik heb het vrij onveilig gemaakt

Ik ben nog steeds bezig om alles weer onder controle te krijgen na dit kleine avontuur, maar het heeft me wel een paar dingen laten zien. Alleen omdat ik in meer dan vijf jaar dat ik mijn homelab draai geen enkele beveiligingsinbreuk heb gehad, betekent dat niet dat ik nooit een beveiligingsinbreuk zal hebben.

Best practices voor een homelab zijn om een reden best practices, en het plaatsen van elke service achter een reverse proxy die extern toegankelijk is, is zeker geen best practice.

Ik zal de komende weken gebruiken om de beveiliging van mijn homelab echt aan te scherpen en diensten van externe domeinnamen naar interne reverse proxy-domeinnamen te verplaatsen, zodat ik weer via VPN toegang moet hebben. Tailscale op een snellere computer is veel responsiever dan mijn oude VPN op mijn Pi, en het is tijd dat ik de diensten correct verplaats zoals ze moeten zijn.