Geen beveiligde wachtwoorden gebruiken voor je server (Brute force gevaar)
Je server is het hart van je trading setup. Je Python bots draaien erop, je backtests draaien erop, je hebt er toegang tot de API van je broker.
Als iemand binnenkomt door een zwak wachtwoord, is je hele handelssysteem in één klap lamgelegd. Je API-sleutels, je data, je geld. Dat risico loop je niet.
Wat is een brute force aanval?
Een brute force aanval is simpelweg raden tot het lukt. Een script probeert duizenden wachtwoorden achter elkaar op je inlogpagina, SSH-poort of API-endpoint.
Het voelt niet persoonlijk, het is gewoon een machine die doorloopt tot hij jouw zwakke wachtwoord vindt. Als je wachtwoord “Trading2024” is, ben je binnen een minuut gekraakt. Een gemiddelde bot test 100 combinaties per seconde.
Dat betekent: 6.000 pogingen per minuut. Zonder bescherming is je server sneller leeggetrokken dan je een order kunt plaatsen.
Waarom is dit relevant voor algorithmic trading? Omdat je server constant online is. Je bot draait 24/7, je broker-API staat open, je backtests laden grote datasets. Een aanvaller ziet die activiteit en weet: hier zit waarde. Ze hoeven maar één deur te vinden.
Waarom zwakke wachtwoorden een direct gevaar zijn voor traders
Een trading bot heeft toegang tot je broker via API. Als je API-sleutels op je server staan en iemand komt binnen, kunnen ze orders plaatsen, posities sluiten of je account leegtrekken.
Dat is geen theorie; het gebeurt. Vooral bij openbare backtesting-servers of VPS-instances met standaard credentials.
Veel traders gebruiken dezelfde wachtwoorden voor hun VPS, broker-dashboard en data-provider. Als één plek valt, vallen allemaal. Je backtest-data van Interactive Brokers of Alpaca, je Python-omgeving, je risicomanagement-scripts: alles staat op één stapel.
Denk ook aan latency. Een brute force aanval vertraagt je server door CPU- en netwerkbelasting.
Je bot mist een entry, je slippage loopt op, je risicomanagement faalt. Je verdient geen geld als je server bezig is met aanvallen afweren.
Hoe een brute force aanval werkt in de praktijk
Stel: je hebt een VPS bij DigitalOcean of Hetzner draaien met Ubuntu. Je SSH-poort staat open op poort 22.
Een aanvaller scant het internet, vindt jouw IP en probeert in te loggen met een lijst van veelvoorkomende wachtwoorden. Geen menswerk, een simpele script. Je broker-API is ook een doelwit.
Als je een Python script gebruikt met bijvoorbeeld de CCXT-bibliotheek of de IB-insync library, en je slaat je API-sleutels plaintext op in een .env-bestand, dan is het een kwestie van inloggen en de sleutel lezen.
Daarna kunnen ze via de broker-API transacties uitvoeren. Backtesting-servers zijn extra kwetsbaar. Je draagt grote datasets, je draait zware berekeningen, je hebt vaak tijdelijke credentials voor data-providers. Een aanvaller kan niet alleen je wachtwoord kraken, maar ook je data kapen of je backtest-resultaten manipuleren.
Veelvoorkomende zwakke punten
- Standaard wachtwoorden: “admin”, “password”, “root123”.
- Herbruikte wachtwoorden over meerdere diensten.
- API-sleutels in Git-repos of onbeveiligde .env-bestanden.
- Open SSH-poorten zonder extra beveiliging.
- Geen tweefactorauthenticatie (2FA) op broker-accounts.
Modellen en prijzen voor beveiligde oplossingen
Goede beveiliging begint bij je VPS-keuze. Kies een provider met ingebouwde firewall en monitoring. Een instap-VPS bij DigitalOcean of Hetzner kost circa €5-€10 per maand.
Voeg een managed firewall toe voor €2-€5 per maand, of gebruik gratis tools als UFW.
Voor wachtwoordbeheer gebruik je een password manager. Bitwarden kost ongeveer €10 per jaar voor de premium-versie.
1Password kost rond €36 per jaar. Je bewaart er je VPS-inlog, broker-API-keys en data-provider-credentials in. Geen hergebruik, geen plaintext-opslag.
Voor extra bescherming op je server kun je een hardware security key overwegen, zoals een YubiKey.
Die kost €45-€55 per stuk. Je sluit hem aan op je laptop en gebruikt hem voor SSH via FIDO2. Dat maakt brute force bijna onmogelijk. Wil je professionele hulp?
Een security-audit voor je trading-infrastructuur kost tussen €500 en €2.000, afhankelijk van de grootte van je setup. Voor de perfecte infrastructuur voor je trading bot kom je vaak uit op €500-€800. Dat is eenmalig, en het voorkomt grotere verliezen.
Praktische tips om brute force te voorkomen
Zet nooit openbare poorten open zonder extra beveiliging. Je broker-API is je geldkraan, bescherm die alsof het je portemonnee is.
Gebruik sterke wachtwoorden van minimaal 16 tekens. Mix hoofdletters, kleine letters, cijfers en symbolen.
Gebruik een password manager om ze te genereren en op te slaan.
Voorbeeld: “R7k#pQ2@L9mX4vT8zW5s” – niet te onthouden, wel veilig. Schakel SSH-key authenticatie in en zet password login uit. Genereer een ed25519-sleutel op je laptop en kopieer de publieke sleutel naar je VPS.
Test het eerst, zet daarna passwords uit. Dat is gratis en verlaagt het risico enorm.
Beperk toegang tot je API-sleutels. Gebruik environment variables en sla ze nooit rechtstreeks in je Python-code op. Gebruik python-decouple of python-dotenv. Zet .env-bestanden in .gitignore.
Geef je bot alleen de minimale rechten die het nodig heeft bij je broker.
Activeer tweefactorauthenticatie op je broker-account. Bij Interactive Brokers, Alpaca, Kraken of Binance: zet 2FA aan. Gebruik een authenticator-app of een hardware key.
Zonder 2FA is je account een open deur voor brute force op je broker-login. Gebruik fail2ban op je VPS.
Het blokkeert IP-adressen na een aantal mislukte inlogpogingen. Installeer het met één commando, configureer een paar regels, en je bent direct beschermd. De configuratie kost 10 minuten en is gratis.
Sluit onnodige poorten en gebruik een firewall. Met UFW op Ubuntu: “sudo ufw default deny incoming”, “sudo ufw allow 22/tcp”, “sudo ufw enable”.
Voeg alleen poorten toe die je echt nodig hebt, zoals SSH en je backtesting-dashboard in een schaalbare Docker-omgeving.
Vermijd standaardpoorten. Verander je SSH-poort van 22 naar bijvoorbeeld 2222 of 22222. Dat verlaagt het aantal bots dat je direct vindt.
Let op: dit is security by obscurity, niet voldoende alleen, maar wel een nuttige extra stap. Log en monitor.
Gebruik “lastb” en “journalctl” om mislukte inlogpogingen te zien. Zet een simpel alert op je server dat je een seintje geeft bij verdachte activiteit. Een Telegram- of Slack-notificatie via een Python-script is snel gemaakt. Hou je Python-omgeving schoon.
Gebruik virtual environments per bot. Installeer alleen benodigde packages via pip.
Controleer regelmatig op verouderde bibliotheken. Een kwetsbare library is een open deur naar je API-sleutels. Back-up je data en scripts veilig.
Gebruik encrypted backups naar een cloud-opslag of een tweede VPS. Test je restores. Een back-up is je vangnet als er toch iets misgaat.
Gebruik een VPN of private netwerk voor interne communicatie. Als je meerdere servers gebruikt voor backtesting en live trading, verbind ze via een VPC of WireGuard. Zo blijven API-queries binnen je eigen netwerk en kom je niet op het open internet. Check of je server klaar is voor live trading voordat je de stap zet.
Plan een security-checklist per maand. Controleer wachtwoorden, API-rechten, firewall-regels, logs en updates.
Doe dit altijd voor een belangrijke backtest of live-start. Voorkomen is goedkoper dan herstellen.
Als je een fout maakt, herstel snel. Wissel je API-sleutels direct bij een vermoeden van compromis. Reset wachtwoorden, revoke tokens, en controleer of er ongebruikelijke orders zijn geplaatst.
Neem contact op met je broker voor ondersteuning. Denk ook aan je team.
Als je samenwerkt, gebruik role-based access. Geef iedereen een eigen account met minimale rechten. Geen gedeelde wachtwoorden. Geen gedeelde API-sleutels. Zo beperk je schade bij een fout. Sluit af met een simpele regel: beveilig je server alsof je er geld op hebt liggen.
Want dat heb je. Je trading bots, je backtests, je API-toegang – het is allemaal verbonden.
Een sterk wachtwoord is je eerste verdedigingslinie, en het is gratis.