Kort sagt: Utgående anslutningar från en server kontrollerar ni med ss -tunap eller lsof -i, som kopplar varje anslutning till en process. Normala är anslutningar till databas, e-postserver, uppdateringsservrar och kända gränssnitt. Anslutningar från PHP- eller webbserverprocesser till okända mål, ovanliga portar och varaktiga anslutningar utan anledning är varningssignaler för fjärrstyrning eller dataläckage. Varaktigt hjälper en utgångsfiltrering som bara tillåter nödvändiga mål.
Varför blicken utåt avslöjar så mycket
Vid sökandet efter ett intrång tittar de flesta på filer. Men en angripare vill göra något med sin åtkomst: ladda ned verktyg, ta emot kommandon, föra ut data eller använda servern för spam eller angrepp på andra. Allt detta kräver anslutningar utåt.
En webbserver bygger av sig själv upp bara få anslutningar, och de flesta av dem är förutsägbara: den frågar databasen, lämnar över e-post, anropar betal- eller fraktgränssnitt och hämtar uppdateringar. Därför sticker främmande anslutningar ut här särskilt. Enligt de rapporter vi har tillgång till hör utgående anslutningar till de allmänna varningssignalerna efter ett intrång; bekräftade Indicators of Compromise specifikt för PHP2Shell finns inte. Fler tecken sammanfattar Är jag redan komprometterad?.
Lista utgående anslutningar och koppla dem till processer
Kommandona nedan läser bara. Kör dem som root, annars saknas processuppgifterna.
# Alla uppbyggda TCP-anslutningar med process
ss -tnp state established
# TCP och UDP inklusive lyssnande tjänster
ss -tunap
# Anslutningar per program och användare, utan namnuppslagning
lsof -i -n -P | grep -v LISTEN
# Bara anslutningar från webbserveranvändarnas processer
lsof -i -n -P -u www-data 2>/dev/null
Se i utskriften på tre kolumner: processen, måladressen med port och användaren. En anslutning från php-fpm till databasen på port 3306 är normal. En anslutning från ett program med okänt namn ur /tmp till en främmande adress på en ovanlig port är det inte. Under vilken användare PHP körs beror på distribution och panel.
Normalt eller misstänkt? En bedömning
| Iakttagelse | Snarare normalt | Snarare misstänkt |
|---|---|---|
| Mål | egen databas, e-postserver, kända API:er, uppdateringsservrar | okända adresser utan koppling till applikationen |
| Process | php-fpm, webbserver, e-post- och uppdateringstjänster | okända program, processer från /tmp eller /dev/shm |
| Port | 443, 3306, 5432, 587 | ovanliga höga portar, IRC-typiska portar |
| Varaktighet | kort, passar till förfrågningar | varaktigt öppen, även på natten utan besökare |
| Mängd | låg och jämn | plötsliga toppar i utgående datavolym |
| E-posttrafik | utskick via den avsedda e-postservern | många direkta anslutningar på port 25 |
Många anslutningar på port 25 tyder på spamutskick; om det finns ett eget inlägg, Servern skickar spam.
Bedöma ett okänt mål
En främmande adress i listan är ännu inget bevis. Innan ni avgör något klargör ni vart anslutningen leder och vem som har byggt upp den. Även dessa steg ändrar ingenting:
- Bestäm processen: Ta PID ur
ssoch kontrollera medls -l /proc/PID/exeoch kommandoraden vilket program som ligger bakom. - Slå upp målet: Med
dig -x <IP>tar ni reda på namnet och medwhois <IP>nätoperatören. - Stäm av mot applikationen: Fråga utvecklare eller tjänsteleverantör om er applikation använder den tjänsten.
- Kontrollera förloppet: Brandväggs- och nätverksloggar visar sedan när anslutningen har funnits och hur mycket data som har flödat.
- Säkra resultaten: Spara utskrifter med klockslag innan ni avslutar eller spärrar något.
Räkna med tvetydiga resultat. Många legitima tjänster körs hos stora moln- och CDN-leverantörer vars adresser inte medger någon slutsats om kunden. Omvänt använder också angripare hyrda molnservrar. En känd nätoperatör är alltså varken signal om att faran är över eller bevis; avgörande är om processen och syftet passar till er applikation.
En ögonblicksbild med ss visar bara det som är öppet just nu. Korta anslutningar som byggs upp i minuttakt ser ni bara i loggar. Därför är brandväggs- eller flödesloggar för frågan om dataläckage ofta viktigare än blicken på själva servern.
Kan data möjligen ha lämnat er server och är personuppgifter berörda, kan en anmälningsskyldighet enligt GDPR i regel inom 72 timmar föreligga. Klargör det tidigt med ert dataskyddsombud; bakgrund finns under GDPR-anmälan inom 72 timmar. Detta är ingen juridisk rådgivning.
Glöm inte DNS och containrar
Inte varje dataläckage kräver en synlig anslutning till en främmande adress. Namnuppslagningar via DNS går till ert datacenters resolver och märks knappt i listan från ss. Angripare kan packa data i långa, slumpmässigt verkande underdomäner och på så vis föra ut dem via DNS-förfrågningar. Tecken på det ger resolverns loggar: ovanligt många förfrågningar till samma främmande domän, mycket långa namn eller förfrågningar vid tider då ingen använder webbplatsen.
Körs era applikationer i containrar ser värden ofta containrarnas anslutningar bara som trafik i containernätet. Kontrollera då i varje container för sig, i den mån verktygen finns där, eller utvärdera anslutningarna på värdens och brandväggens nivå.
# Anslutningar inne i en container (om ss ingår i imagen)
docker exec <container> ss -tnp 2>/dev/null
# På värden: anslutningar som kärnan spårar, om conntrack är installerat
sudo conntrack -L 2>/dev/null | head -50
Begränsa utgående trafik varaktigt
Den mest verksamma förebyggande åtgärden är en utgångsfiltrering: servern får bara nå de mål den verkligen behöver, allt annat spärras och loggas. För angripare blir det därigenom avsevärt svårare att ladda ned verktyg eller dra ut data, även om de kan köra kod.
Vägen dit börjar med en lista över de nödvändiga målen, som ni härleder ur de anslutningar ni samlade in ovan. Därefter följer en fas där spärrade anslutningar bara loggas, innan spärren aktiveras på allvar. Betaltjänster, uppdateringsservrar och gränssnitt med växlande adresser kräver särskild omsorg. Hur en brandvägg för webbservrar byggs upp i sin helhet beskrivs i Brandvägg för webbservrar: öppna bara nödvändiga portar.
Hur hjälper PHP SOS konkret?
- Kontrollera anslutningar: Vi kopplar alla aktiva anslutningar till processer och syften och bedömer okända mål.
- Uppskatta dataläckage: Vi utvärderar brandväggs- och nätverksloggar och klargör om och när data har överförts.
- Begränsa utgången: Vi tar tillsammans med er fram en lista över tillåtna mål och sätter upp utgångsfiltreringen steg för steg.
- Övervaka varaktigt: Med säkerhetsövervakningen meddelar vi nya eller ovanliga anslutningar.
Vanliga frågor
Vilka utgående anslutningar är normala för en webbserver?
Typiskt är anslutningar till databasen, e-postservern, betal- och fraktjänster, uppdateringsservrar och applikationens kända gränssnitt. Allt som inte går att koppla till något av dessa syften förtjänar en närmare titt.
Hur ser jag vilken process som har byggt upp en anslutning?
Med ss -tunap eller lsof -i -n -P som root. Båda visar för varje anslutning process-ID och programnamn. Så ser ni om anslutningen kommer från PHP, webbservern eller ett främmande program.
Betyder en okänd anslutning att data har läckt ut?
Inte nödvändigtvis. Men den är ett tecken som måste klarläggas. Om och vilka data som har överförts går ofta bara att besvara med brandväggs- eller nätverksloggar. Är personuppgifter berörda kan anmälningsskyldighet finnas.
Bör en webbserver överhuvudtaget få göra utgående anslutningar?
Bara till de mål den behöver. En utgångsfiltrering som spärrar allt annat försvårar för angripare avsevärt att ladda ned verktyg och att läcka ut data. Den måste dock testas noggrant.