Kort gezegd: Uitgaande verbindingen van een server controleert u met ss -tunap of lsof -i, die elke verbinding aan een proces koppelen. Normaal zijn verbindingen naar database, mailserver, updateservers en bekende koppelingen. Verbindingen van PHP- of webserverprocessen naar onbekende doelen, ongewone poorten en permanente verbindingen zonder aanleiding zijn waarschuwingssignalen voor afstandsbesturing of gegevensuitstroom. Blijvend helpt een uitgaande filtering die alleen benodigde doelen toestaat.
Waarom de blik naar buiten zoveel verraadt
Bij het zoeken naar een inbraak kijken de meesten naar bestanden. Maar een aanvaller wil met zijn toegang iets doen: hulpmiddelen naladen, opdrachten ontvangen, gegevens naar buiten brengen of de server gebruiken voor spam of aanvallen op anderen. Dat alles vereist verbindingen naar buiten.
Een webserver bouwt uit zichzelf maar weinig verbindingen op, en de meeste daarvan zijn voorspelbaar: hij bevraagt de database, geeft mails door, roept betalings- of verzendkoppelingen aan en haalt updates op. Daarom vallen vreemde verbindingen hier bijzonder op. Volgens de ons beschikbare berichten behoren uitgaande verbindingen tot de algemene waarschuwingssignalen na een inbraak; bevestigde Indicators of Compromise speciaal voor PHP2Shell bestaan niet. Verdere tekenen vat Ben ik al gecompromitteerd? samen.
Uitgaande verbindingen opsommen en aan processen koppelen
De volgende opdrachten lezen alleen. Voer ze uit als root, anders ontbreken de procesgegevens.
# Alle opgebouwde TCP-verbindingen met proces
ss -tnp state established
# TCP en UDP inclusief luisterende services
ss -tunap
# Verbindingen per programma en gebruiker, zonder naamresolutie
lsof -i -n -P | grep -v LISTEN
# Alleen verbindingen van processen van de webservergebruikers
lsof -i -n -P -u www-data 2>/dev/null
Let in de uitvoer op drie kolommen: het proces, het doeladres met poort en de gebruiker. Een verbinding van php-fpm naar de database op poort 3306 is normaal. Een verbinding van een programma met onbekende naam uit /tmp naar een vreemd adres op een ongewone poort is dat niet. Onder welke gebruiker PHP draait, hangt af van distributie en paneel.
Normaal of verdacht? Een indeling
| Waarneming | Eerder normaal | Eerder verdacht |
|---|---|---|
| Doel | eigen database, mailserver, bekende API's, updateservers | onbekende adressen zonder verband met de toepassing |
| Proces | php-fpm, webserver, mail- en updateservices | onbekende programma's, processen uit /tmp of /dev/shm |
| Poort | 443, 3306, 5432, 587 | ongewone hoge poorten, IRC-typische poorten |
| Duur | kort, passend bij verzoeken | permanent open, ook 's nachts zonder bezoekers |
| Hoeveelheid | gering en gelijkmatig | plotselinge pieken in het uitgaande datavolume |
| Mailverkeer | verzending via de bedoelde mailserver | veel directe verbindingen op poort 25 |
Veel verbindingen op poort 25 wijzen op spamverzending; daarover bestaat een eigen artikel, De server verstuurt spam.
Een onbekend doel beoordelen
Een vreemd adres in de lijst is nog geen bewijs. Voordat u beslist, stelt u vast waarheen de verbinding leidt en wie haar heeft opgebouwd. Ook deze stappen wijzigen niets:
- Proces bepalen: PID uit
ssnemen en metls -l /proc/PID/exeen de opdrachtregel controleren welk programma erachter zit. - Doel opzoeken: Met
dig -x <IP>de naam en metwhois <IP>de netwerkexploitant achterhalen. - Met de toepassing vergelijken: Vraag ontwikkelaars of dienstverleners of uw toepassing deze dienst gebruikt.
- Verloop controleren: Firewall- en netwerklogs tonen sinds wanneer de verbinding bestaat en hoeveel gegevens zijn gevloeid.
- Resultaten veiligstellen: Uitvoer met tijdstip opslaan voordat u iets beëindigt of blokkeert.
Reken op dubbelzinnige uitkomsten. Veel legitieme diensten draaien bij grote cloud- en CDN-aanbieders, waarvan de adressen geen conclusie over de klant toelaten. Omgekeerd gebruiken ook aanvallers gehuurde cloudservers. Een bekende netwerkexploitant is dus noch ontwarring noch bewijs; beslissend is of het proces en het doel bij uw toepassing passen.
Een momentopname met ss toont alleen wat op dat moment open is. Korte verbindingen die elke minuut worden opgebouwd, ziet u alleen in logs. Daarom zijn firewall- of flowlogs voor de vraag naar gegevensuitstroom vaak belangrijker dan een blik op de server zelf.
Hebben gegevens uw server mogelijk verlaten en zijn persoonsgegevens getroffen, dan kan er een meldplicht volgens de AVG bestaan, in de regel binnen 72 uur. Stem dat vroeg af met uw functionaris voor gegevensbescherming; achtergronden onder AVG-meldplicht binnen 72 uur. Dit is geen juridisch advies.
DNS en containers niet vergeten
Niet elke gegevensuitstroom heeft een zichtbare verbinding naar een vreemd adres nodig. Naamresoluties via DNS gaan naar de resolver van uw datacenter en vallen in de lijst van ss nauwelijks op. Aanvallers kunnen gegevens verpakken in lange, willekeurig ogende subdomeinen en zo via DNS-verzoeken naar buiten brengen. Aanwijzingen daarvoor leveren de logs van de resolver: ongewoon veel verzoeken naar hetzelfde vreemde domein, zeer lange namen of verzoeken op tijdstippen waarop niemand de website gebruikt.
Draaien uw toepassingen in containers, dan ziet de host de verbindingen van de containers vaak alleen als verkeer van het containernetwerk. Controleer dan in elke container afzonderlijk, voor zover de hulpmiddelen daar aanwezig zijn, of analyseer de verbindingen op het niveau van de host en de firewall.
# Verbindingen binnen een container (voor zover ss in de image zit)
docker exec <container> ss -tnp 2>/dev/null
# Op de host: door de kernel gevolgde verbindingen, als conntrack is geïnstalleerd
sudo conntrack -L 2>/dev/null | head -50
Uitgaand verkeer blijvend beperken
De doeltreffendste preventie is een uitgaande filtering: de server mag alleen de doelen bereiken die hij werkelijk nodig heeft, al het andere wordt geblokkeerd en gelogd. Voor aanvallers wordt het daardoor aanzienlijk moeilijker hulpmiddelen na te laden of gegevens weg te trekken, zelfs als ze code kunnen uitvoeren.
De weg daarheen begint met een lijst van benodigde doelen, die u afleidt uit de hierboven verzamelde verbindingen. Daarna volgt een fase waarin geblokkeerde verbindingen alleen worden gelogd, voordat de blokkade scherp wordt gesteld. Betalingsdiensten, updateservers en koppelingen met wisselende adressen vragen daarbij bijzondere zorg. Hoe een firewall voor webservers in het geheel wordt opgebouwd, beschrijft Firewall voor webservers: alleen noodzakelijke poorten openen.
Hoe helpt PHP SOS concreet?
- Verbindingen controleren: Wij koppelen alle actieve verbindingen aan processen en doelen en beoordelen onbekende doelen.
- Gegevensuitstroom inschatten: Wij analyseren firewall- en netwerklogs en stellen vast of en wanneer gegevens zijn overgedragen.
- Uitgaand verkeer beperken: Wij stellen met u een lijst van toegestane doelen op en richten de uitgaande filtering stapsgewijs in.
- Blijvend bewaken: Met de security-monitoring melden wij nieuwe of ongewone verbindingen.
Veelgestelde vragen
Welke uitgaande verbindingen zijn bij een webserver normaal?
Typisch zijn verbindingen naar de database, de mailserver, betalings- en verzenddiensten, updateservers en bekende koppelingen van de toepassing. Alles wat zich aan geen van deze doelen laat koppelen, verdient een nauwkeuriger blik.
Hoe zie ik welk proces een verbinding heeft opgebouwd?
Met ss -tunap of lsof -i -n -P als root. Beide tonen bij elke verbinding de proces-ID en de programmanaam. Zo ziet u of de verbinding afkomstig is van PHP, de webserver of een vreemd programma.
Betekent een onbekende verbinding dat er gegevens zijn weggelekt?
Niet noodzakelijk. Het is wel een aanwijzing die moet worden opgehelderd. Of en welke gegevens zijn overgedragen, is vaak alleen met firewall- of netwerklogs te beantwoorden. Zijn persoonsgegevens getroffen, dan kunnen er meldplichten bestaan.
Mag een webserver überhaupt uitgaande verbindingen maken?
Alleen naar de doelen die hij nodig heeft. Een uitgaande filtering die al het andere blokkeert, bemoeilijkt voor aanvallers het naladen van hulpmiddelen en het wegsluizen van gegevens aanzienlijk. Ze moet echter zorgvuldig worden getest.