Tijdens mijn voorbereiding op de PNPT-certificering draai ik mijn volledige lab in Docker. Het geeft snelheid, controle en maakt het eenvoudig om scenario’s opnieuw op te bouwen. Maar zelfs in een omgeving die je zelf hebt opgezet, kunnen kleine inconsistenties in Docker networking onverwachte problemen veroorzaken. In dit geval weigerde de webapp verbinding te maken met de database, terwijl alle containers zonder fouten draaiden.
In dit artikel neem ik je mee door het volledige troubleshootingproces. Niet alleen de foutmelding zelf, maar de complete reeks aanwijzingen, analyses en beslissingen die uiteindelijk tot de oplossing leidden. Dit is exact het soort systematische aanpak dat je tijdens pentests continu nodig hebt: nieuwsgierig onderzoeken, oorzaken uitsluiten en logisch redeneren totdat het echte probleem zichtbaar wordt.
Het Oorspronkelijke Probleem
Bij het openen van de Capstone-applicatie verscheen de volgende foutmelding:
Connection failed: Host '172.18.0.4' is not allowed to connect to this MySQL server
Om het geheel duidelijker en vollediger te maken volgt hieronder de exacte troubleshooting timeline van wat er gebeurde en waarom.
Complete Troubleshooting Timeline
Bij het openen van de Capstone-applicatie verscheen de volgende foutmelding:
Connection failed: Host '172.18.0.4' is not allowed to connect to this MySQL server
Ik wist dat de applicatie volledig in Docker draaide en dat de databasecontainers correct waren geconfigureerd. Het IP-adres in de foutmelding kwam echter niet overeen met de verwachte adressen binnen mijn Docker-netwerk. Dit wees direct op een probleem binnen de netwerklaag van Docker.
Stap 1: MariaDB Conflict Discovery
Tijdens het troubleshooten probeerde ik eerst MariaDB lokaal op het systeem te starten:
sudo systemctl start mariadb
Dit faalde met de foutmelding dat de server niet kon starten omdat poort 3306 al in gebruik was. Dat was de eerste duidelijke aanwijzing dat Docker een conflict veroorzaakte.
Stap 2: Port Conflict Analysis
Om te zien wat er daadwerkelijk op poort 3306 draaide:
netstat -tlnp | grep 3306
Hieruit bleek dat Docker-proxy actief was op deze poort en dat er twee mysqld-processen actief waren. Dit bevestigde dat Docker meerdere databaseprocessen beheerde.
Stap 3: Container Discovery
Daarna controleerde ik welke containers actief waren:
docker ps
De output liet drie containers zien: labs-web-1, labs-peh-capstone-db-1 en labs-peh-db-1. Opvallend was dat de Capstone database niet op poort 3306 draaide, maar op 3307.
Stap 4: IP Mismatch
Tijdens het controleren van de IP-adressen viel een duidelijke afwijking op:
docker inspect labs-peh-capstone-db-1 | grep IPAddress
De databasecontainer had het adres 172.18.0.2, terwijl de foutmelding verwees naar 172.18.0.4. Dat betekende dat de webapp probeerde te verbinden met een oud of ongeldig adres, een typische indicator van een inconsistent of vervuild Docker-netwerk.
Stap 5: Network Issues
Het oude netwerk br-253c1b98d33e bleek beschadigd te zijn. Na het herstarten van containers werd automatisch een nieuw, schoon netwerk aangemaakt:
Network labs_default Created
Dit duidde op een corrupt of inconsistent Docker-netwerk. Dit verklaarde waarom IP-adressen niet meer overeenkwamen.
Stap 6: De oplossing door het netwerk opnieuw op te bouwen
Een volledige herbouw van het netwerk bleek voldoende om alles te herstellen:
docker compose down
docker compose up -d
Deze actie zorgde voor een nieuwe bridge, een frisse IP-range en correcte hostname-resolutie tussen de containers. De applicatie hoefde niet aangepast te worden. Zodra het netwerk was opgeschoond, werkte alles direct opnieuw.
Waarom Dit Realistisch Is
In complexe labomgevingen kunnen meerdere databases naast elkaar draaien. Port conflicts en network corruption komen vaak voor wanneer containers regelmatig worden gestart en gestopt. Hierdoor kunnen oude IP-referenties blijven hangen, wat leidt tot fouten zoals de hier beschreven database mismatch.
(Verplaatst) Onderliggende oorzaak: Een corrupte Docker-bridge
Tijdens het opnieuw starten van enkele containers viel het volgende op:
Network labs_default Created
Docker Compose creëerde automatisch een nieuw netwerk. Dat is een sterke aanwijzing dat de oorspronkelijke Docker-bridge beschadigd was of incorrecte IP-ranges bevatte. Door deze inconsistenties kreeg de database-container een nieuw IP-adres, maar de applicatie probeerde nog steeds verbinding te maken met het oude.
Een volledige herbouw van het netwerk bleek voldoende om alles te herstellen:
docker compose down
docker compose up -d
Deze actie zorgde voor een nieuwe bridge, een frisse IP-range en correcte hostname-resolutie tussen de containers. De applicatie hoefde niet aangepast te worden. Zodra het netwerk was opgeschoond, werkte alles direct opnieuw.
Wat dit betekent voor pentesters
Troubleshooting is een essentiële vaardigheid binnen pentesting. Tijdens een engagement werk je vaak in dynamische omgevingen waar systemen onverwacht gedrag kunnen vertonen. Deze situatie liet opnieuw zien hoe belangrijk het is om systematisch te werk te gaan.
Belangrijke inzichten
- Zelfs in gecontroleerde labs kunnen realistische fouten ontstaan doordat omgevingen dynamisch blijven.
- Troubleshooting vraagt meer dan het oplossen van fouten; het vereist inzicht in processen, afhankelijkheden, netwerken en systeemgedrag.
- IP-adressen binnen Docker zijn vluchtig. Het is betrouwbaarder om service-namen te gebruiken.
- Soms is het resetten van een netwerk geen gemakzuchtige oplossing maar de enige juiste.
Praktische tips voor PNPT-studenten die Docker gebruiken
- Controleer regelmatig welke containers actief zijn:
docker ps - Inspecteer IP-adressen als verbindingen falen:
docker inspect <container> - Herbouw het netwerk wanneer services onverklaarbaar stoppen met communiceren:
docker compose down && docker compose up -d - Gebruik waar mogelijk service-namen in plaats van IP-adressen.
- Verwijder oude netwerken periodiek om vervuiling te voorkomen:
docker network prune
Conclusie
Wat begon met een eenvoudige databasefout, bleek uiteindelijk een waardevolle oefening in methodisch troubleshooten. Het probleem zat niet in MySQL, niet in credentials en zelfs niet in de applicatie zelf, maar in een inconsistente Docker-bridge die verkeerde IP-adressen uitdeelde. Dat soort problemen kom je niet alleen in labs tegen: ook in productieomgevingen kunnen netwerken vervuild raken en onverwacht gedrag vertonen.
Het belangrijkste inzicht hier is dat een pentester meer is dan iemand die kwetsbaarheden zoekt. Een pentester moet kunnen onderzoeken, analyseren en logisch verbanden leggen. Troubleshooting is een fundamenteel onderdeel van dat vak – omdat real‑world omgevingen zelden perfect zijn.
Deze ervaring past daarmee precies in mijn PNPT‑journey. Niet alleen omdat het probleem opgelost werd, maar omdat het mijn manier van kijken naar systemen weer een stukje scherper heeft gemaakt.