Kort sagt: En servers udgående forbindelser kontrollerer I med ss -tunap eller lsof -i, som knytter hver forbindelse til en proces. Normale er forbindelser til database, mailserver, opdateringsservere og kendte grænseflader. Forbindelser fra PHP- eller webserverprocesser til ukendte mål, usædvanlige porte og vedvarende forbindelser uden anledning er advarselstegn på fjernstyring eller dataudsivning. Varigt hjælper en udgangsfiltrering, der kun tillader nødvendige mål.
Hvorfor blikket udad afslører så meget
Ved søgningen efter et indbrud ser de fleste på filer. Men en angriber vil bruge sin adgang til noget: hente værktøjer, modtage kommandoer, få data ud eller bruge serveren til spam eller angreb på andre. Alt det kræver forbindelser udad.
En webserver opbygger af sig selv kun få forbindelser, og de fleste af dem er forudsigelige: Den forespørger databasen, afleverer mails, kalder betalings- eller forsendelsesgrænseflader og henter opdateringer. Derfor falder fremmede forbindelser her særligt i øjnene. Ifølge de rapporter, vi har foran os, hører udgående forbindelser til de generelle advarselstegn efter et indbrud; bekræftede indicators of compromise specielt for PHP2Shell findes ikke. Yderligere tegn samler Er jeg allerede kompromitteret?.
Opregn udgående forbindelser og knyt dem til processer
Følgende kommandoer læser kun. Kør dem som root, ellers mangler procesoplysningerne.
# Alle opbyggede TCP-forbindelser med proces
ss -tnp state established
# TCP og UDP inklusive lyttende tjenester
ss -tunap
# Forbindelser pr. program og bruger, uden navneopløsning
lsof -i -n -P | grep -v LISTEN
# Kun forbindelser fra webserverbrugernes processer
lsof -i -n -P -u www-data 2>/dev/null
Vær i output opmærksom på tre kolonner: processen, måladressen med port og brugeren. En forbindelse fra php-fpm til databasen på port 3306 er normal. En forbindelse fra et program med ukendt navn fra /tmp til en fremmed adresse på en usædvanlig port er det ikke. Under hvilken bruger PHP kører, afhænger af distribution og panel.
Normal eller mistænkelig? En vurdering
| Observation | Snarere normal | Snarere mistænkelig |
|---|---|---|
| Mål | egen database, mailserver, kendte API'er, opdateringsservere | ukendte adresser uden tilknytning til applikationen |
| Proces | php-fpm, webserver, mail- og opdateringstjenester | ukendte programmer, processer fra /tmp eller /dev/shm |
| Port | 443, 3306, 5432, 587 | usædvanligt høje porte, IRC-typiske porte |
| Varighed | kort, passende til forespørgsler | vedvarende åben, også om natten uden besøgende |
| Mængde | lille og jævn | pludselige spidser i det udgående datavolumen |
| Mailtrafik | afsendelse via den tilsigtede mailserver | mange direkte forbindelser på port 25 |
Mange forbindelser på port 25 peger på spamafsendelse; hertil findes et eget indlæg, Serveren sender spam.
Vurdér et ukendt mål
En fremmed adresse på listen er endnu intet bevis. Før I beslutter noget, afklar, hvor forbindelsen fører hen, og hvem der har opbygget den. Også disse skridt ændrer intet:
- Bestem processen: Tag PID fra
ss, og kontrollér medls -l /proc/PID/exeog kommandolinjen, hvilket program der står bag. - Slå målet op: Med
dig -x <IP>finder I navnet og medwhois <IP>netværksoperatøren. - Afstem med applikationen: Spørg udvikleren eller tjenesteyderen, om jeres applikation bruger denne tjeneste.
- Kontrollér forløbet: Firewall- og netværkslogs viser, siden hvornår forbindelsen har bestået, og hvor mange data der er flydt.
- Sikr resultaterne: Gem output med klokkeslæt, før I afslutter eller spærrer noget.
Regn med flertydige resultater. Mange legitime tjenester kører hos store cloud- og CDN-udbydere, hvis adresser ikke tillader slutninger om kunden. Omvendt bruger også angribere lejede cloudservere. En kendt netværksoperatør er altså hverken fuld afblæsning eller bevis; afgørende er, om processen og formålet passer til jeres applikation.
Et øjebliksbillede med ss viser kun, hvad der netop er åbent. Korte forbindelser, der opbygges i minutrytme, ser I kun i logs. Derfor er firewall- eller flow-logs ofte vigtigere end blikket på selve serveren, når spørgsmålet gælder dataudsivning.
Har data muligvis forladt jeres server, og er personoplysninger berørt, kan der bestå en anmeldelsespligt efter GDPR, som regel inden for 72 timer. Afklar det tidligt med jeres databeskyttelsesrådgiver; baggrund under GDPR-anmeldelsespligt inden for 72 timer. Dette er ikke juridisk rådgivning.
Glem ikke DNS og containere
Ikke enhver dataudsivning kræver en synlig forbindelse til en fremmed adresse. Navneopløsninger via DNS går til jeres datacenters resolver og falder næppe i øjnene på listen fra ss. Angribere kan pakke data ind i lange, tilfældigt udseende subdomæner og på den måde få dem ud via DNS-forespørgsler. Fingerpeg herom giver resolverens logs: usædvanligt mange forespørgsler til det samme fremmede domæne, meget lange navne eller forespørgsler på tidspunkter, hvor ingen bruger websitet.
Kører jeres applikationer i containere, ser værten ofte containernes forbindelser kun som trafik i container-netværket. Kontrollér da i hver container for sig, for så vidt værktøjerne er til stede dér, eller analysér forbindelserne på værtens og firewallens niveau.
# Forbindelser inden i en container (hvis ss er indeholdt i imaget)
docker exec <container> ss -tnp 2>/dev/null
# På værten: forbindelser fulgt af kernen, hvis conntrack er installeret
sudo conntrack -L 2>/dev/null | head -50
Begræns udgående trafik varigt
Den mest virksomme forebyggelse er en udgangsfiltrering: Serveren må kun nå de mål, den virkelig har brug for, alt andet spærres og logges. For angribere bliver det dermed tydeligt sværere at hente værktøjer eller trække data ud, selv om de kan udføre kode.
Vejen dertil begynder med en liste over de nødvendige mål, som I udleder af de ovenfor indsamlede forbindelser. Derefter følger en fase, hvor spærrede forbindelser kun logges, før spærringen sættes skarpt. Betalingstjenester, opdateringsservere og grænseflader med skiftende adresser kræver dér særlig omhu. Hvordan en firewall til webservere overordnet bygges op, beskriver Firewall til webservere: Åbn kun nødvendige porte.
Hvordan hjælper PHP SOS konkret?
- Kontrollér forbindelser: Vi knytter alle aktive forbindelser til processer og formål og vurderer ukendte mål.
- Vurdér dataudsivning: Vi analyserer firewall- og netværkslogs og afklarer, om og hvornår data er overført.
- Begræns udgangen: Vi udarbejder sammen med jer en liste over tilladte mål og sætter udgangsfiltreringen op trin for trin.
- Overvåg varigt: Med security-overvågningen melder vi nye eller usædvanlige forbindelser.
Ofte stillede spørgsmål
Hvilke udgående forbindelser er normale for en webserver?
Typiske er forbindelser til databasen, til mailserveren, til betalings- og forsendelsestjenester, til opdateringsservere og til applikationens kendte grænseflader. Alt, der ikke kan knyttes til et af disse formål, fortjener et nøjere kig.
Hvordan ser jeg, hvilken proces der har opbygget en forbindelse?
Med ss -tunap eller lsof -i -n -P som root. Begge viser ved hver forbindelse proces-id og programnavn. Så kan I se, om forbindelsen stammer fra PHP, webserveren eller et fremmed program.
Betyder en ukendt forbindelse, at data er sivet ud?
Ikke nødvendigvis. Men den er et fingerpeg, som skal afklares. Om og hvilke data der er overført, kan ofte kun besvares med firewall- eller netværkslogs. Er personoplysninger berørt, kan der bestå anmeldelsespligter.
Bør en webserver overhovedet have lov til udgående forbindelser?
Kun til de mål, den har brug for. En udgangsfiltrering, der spærrer alt andet, gør det betydeligt sværere for angribere at hente værktøjer og lade data sive ud. Den skal dog testes omhyggeligt.