# Egy szerver kimenő kapcsolatainak ellenőrzése

> Egy szerver kimenő kapcsolatainak ellenőrzése: folyamatok hozzárendelése ss-sel és lsof-fal, ismeretlen célok értékelése, adatszivárgás korlátozása kimenő szűrővel.

Forrás: https://phpsos.de/hu/blog/ausgehende-verbindungen-pruefen/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**Röviden:** Egy szerver kimenő kapcsolatait az `ss -tunap` vagy az `lsof -i` paranccsal ellenőrzi, amelyek minden kapcsolatot egy folyamathoz rendelnek. Normálisak az adatbázishoz, a levelezőszerverhez, a frissítési szerverekhez és az ismert interfészekhez vezető kapcsolatok. A PHP- vagy webszerver-folyamatok kapcsolatai ismeretlen célokhoz, a szokatlan portok és az ok nélküli tartós kapcsolatok a távirányítás vagy az adatszivárgás figyelmeztető jelei. Tartósan egy olyan kimenő szűrés segít, amely csak a szükséges célokat engedi.

## Miért árul el ennyit a kifelé pillantás

A behatolás keresésekor a legtöbben a fájlokat nézik. A támadó azonban a hozzáféréssel akar valamit kezdeni: eszközöket letölteni, parancsokat fogadni, adatokat kivinni, vagy a szervert spamre vagy mások elleni támadásokra használni. Mindehhez kifelé irányuló kapcsolatok kellenek.

A webszerver magától csak kevés kapcsolatot épít, és ezek többsége kiszámítható: lekérdezi az adatbázist, leveleket ad át, fizetési vagy szállítási interfészeket hív, és frissítéseket tölt le. Ezért itt különösen feltűnnek az idegen kapcsolatok. A rendelkezésünkre álló beszámolók szerint a kimenő kapcsolatok a behatolás utáni általános figyelmeztető jelek közé tartoznak; kifejezetten a PHP2Shellre vonatkozó megerősített Indicators of Compromise nincsenek. További jeleket foglal össze a [Megfertőzték már a rendszeremet?](https://phpsos.de/hu/php2shell/bin-ich-gehackt-anzeichen/) oldal.

## A kimenő kapcsolatok felsorolása és hozzárendelése folyamatokhoz

A következő parancsok csak olvasnak. Futtassa őket rootként, különben hiányoznak a folyamatadatok.

```bash
# Az összes felépített TCP-kapcsolat folyamattal
ss -tnp state established

# TCP és UDP, a figyelő szolgáltatásokkal együtt
ss -tunap

# Kapcsolatok programonként és felhasználónként, névfeloldás nélkül
lsof -i -n -P | grep -v LISTEN

# Csak a webszerver-felhasználók folyamatainak kapcsolatai
lsof -i -n -P -u www-data 2>/dev/null
```

A kimenetben három oszlopra figyeljen: a folyamatra, a célcímre porttal és a felhasználóra. A `php-fpm` kapcsolata az adatbázishoz a 3306-os porton normális. Egy ismeretlen nevű, a `/tmp` mappából származó program kapcsolata egy idegen címhez szokatlan porton nem az. Hogy a PHP melyik felhasználó alatt fut, az a disztribúciótól és a paneltől függ.

## Normális vagy gyanús? Egy besorolás

| Megfigyelés | Inkább normális | Inkább gyanús |
|---|---|---|
| Cél | saját adatbázis, levelezőszerver, ismert API-k, frissítési szerverek | ismeretlen címek az alkalmazáshoz való kapcsolat nélkül |
| Folyamat | php-fpm, webszerver, levelező- és frissítési szolgáltatások | ismeretlen programok, a `/tmp` vagy a `/dev/shm` alól futó folyamatok |
| Port | 443, 3306, 5432, 587 | szokatlan magas portok, IRC-re jellemző portok |
| Időtartam | rövid, a kérésekhez illő | tartósan nyitva, éjszaka látogatók nélkül is |
| Mennyiség | csekély és egyenletes | hirtelen csúcsok a kimenő adatmennyiségben |
| Levélforgalom | küldés a kijelölt levelezőszerveren át | sok közvetlen kapcsolat a 25-ös porton |

A 25-ös porton lévő sok kapcsolat spamküldésre utal; erről külön cikk van, [A szerver spamet küld](https://phpsos.de/hu/blog/server-verschickt-spam/).

## Egy ismeretlen cél értékelése

Egy idegen cím a listán még nem bizonyíték. Mielőtt döntene, tisztázza, hova vezet a kapcsolat, és ki építette fel. Ezek a lépések sem változtatnak semmit:

1. **A folyamat meghatározása:** Vegye az `ss` PID-jét, és az `ls -l /proc/PID/exe` paranccsal és a parancssorral ellenőrizze, melyik program áll mögötte.
2. **A cél utánanézése:** A `dig -x <IP>` paranccsal a nevet, a `whois <IP>` paranccsal a hálózat üzemeltetőjét derítheti ki.
3. **Egyeztetés az alkalmazással:** Kérdezze meg a fejlesztőket vagy a szolgáltatót, hogy az alkalmazása használja-e ezt a szolgáltatást.
4. **Az előzmények ellenőrzése:** A tűzfal- és hálózati naplók megmutatják, mióta áll fenn a kapcsolat, és mennyi adat áramlott.
5. **Az eredmények mentése:** Mentse a kimeneteket időponttal, mielőtt bármit befejezne vagy zárolna.

Számítson többértelmű eredményekre. Sok jogos szolgáltatás nagy felhő- és CDN-szolgáltatóknál fut, amelyek címei nem engednek következtetni az ügyfélre. Fordítva, a támadók is bérelnek felhőszervereket. Egy ismert hálózati üzemeltető tehát sem vészjelzés, sem bizonyíték; az a döntő, hogy a folyamat és a cél illik-e az alkalmazásához.

Az `ss` pillanatfelvétele csak azt mutatja, ami éppen nyitva van. A rövid kapcsolatokat, amelyeket percenként építenek fel, csak naplókban látja. Ezért az adatszivárgás kérdésében a tűzfal- vagy flow-naplók gyakran fontosabbak, mint magára a szerverre vetett pillantás.

> **Fontos:**
> Ha adatok esetleg elhagyták a szerverét, és személyes adatok érintettek, a GDPR szerinti bejelentési kötelezettség általában 72 órán belül állhat fenn. Egyeztessen erről korán az adatvédelmi felelősével; a háttér a [GDPR-bejelentési kötelezettség 72 órán belül](https://phpsos.de/hu/compliance/dsgvo-meldepflicht-72-stunden/) oldalon olvasható. Ez nem jogi tanácsadás.

## Ne feledkezzen meg a DNS-ről és a konténerekről

Nem minden adatszivárgáshoz kell látható kapcsolat egy idegen címhez. A DNS-en keresztüli névfeloldások az adatközpont resolverére mennek, és az `ss` listáján alig tűnnek fel. A támadók az adatokat hosszú, véletlenszerűnek tűnő aldomainekbe csomagolhatják, és így DNS-kéréseken keresztül vihetik ki. Erre a resolver naplói adnak jelzést: szokatlanul sok kérés ugyanahhoz az idegen doménhez, nagyon hosszú nevek, vagy olyan időpontokban érkező kérések, amikor senki sem használja a weboldalt.

Ha az alkalmazásai konténerekben futnak, a gazdagép a konténerek kapcsolatait gyakran csak a konténerhálózat forgalmaként látja. Ilyenkor ellenőrizze minden konténerben külön, amennyiben az eszközök ott megvannak, vagy értékelje ki a kapcsolatokat a gazdagép és a tűzfal szintjén.

```bash
# Kapcsolatok egy konténeren belül (ha az ss benne van az image-ben)
docker exec <container> ss -tnp 2>/dev/null

# A gazdagépen: a kernel által követett kapcsolatok, ha a conntrack telepítve van
sudo conntrack -L 2>/dev/null | head -50
```

## A kimenő forgalom tartós korlátozása

A leghatékonyabb megelőzés a kimenő szűrés: a szerver csak azokat a célokat érheti el, amelyekre valóban szüksége van, mindent mást zárolnak és naplóznak. A támadóknak így jóval nehezebb eszközöket letölteni vagy adatokat kinyerni, még ha tudnak is kódot végrehajtani.

Az út a szükséges célok listájával kezdődik, amelyet a fent összegyűjtött kapcsolatokból vezet le. Ezután egy olyan fázis következik, amelyben a zárolt kapcsolatokat csak naplózzák, mielőtt a zárolást élesítik. A fizetési szolgáltatások, a frissítési szerverek és a változó címekkel rendelkező interfészek különös gondosságot igényelnek. Hogyan épül fel egy webszerver tűzfala egészében, azt a [Tűzfal webszerverhez: csak a szükséges portokat nyissa meg](https://phpsos.de/hu/blog/firewall-fuer-webserver/) írja le.

## Hogyan segít konkrétan a PHP SOS?

- **A kapcsolatok ellenőrzése:** Az összes aktív kapcsolatot folyamatokhoz és célokhoz rendeljük, és értékeljük az ismeretlen célokat.
- **Az adatszivárgás megítélése:** Kiértékeljük a tűzfal- és hálózati naplókat, és tisztázzuk, történt-e adatátvitel, és mikor.
- **A kimenő forgalom korlátozása:** Önnel együtt kidolgozzuk az engedélyezett célok listáját, és fokozatosan beállítjuk a kimenő szűrést.
- **Tartós figyelés:** A [Security-Monitoringgal](https://phpsos.de/hu/leistungen/security-monitoring/) jelezzük az új vagy szokatlan kapcsolatokat.


## Gyakori kérdések

**Mely kimenő kapcsolatok normálisak egy webszervernél?**  
Tipikusak az adatbázishoz, a levelezőszerverhez, a fizetési és szállítási szolgáltatásokhoz, a frissítési szerverekhez és az alkalmazás ismert interfészeihez vezető kapcsolatok. Minden, ami egyik célhoz sem rendelhető, alaposabb vizsgálatot érdemel.

**Honnan látom, melyik folyamat épített kapcsolatot?**  
Az ss -tunap vagy az lsof -i -n -P paranccsal rootként. Mindkettő minden kapcsolathoz megmutatja a folyamatazonosítót és a programnevet. Így felismeri, hogy a kapcsolat a PHP-től, a webszervertől vagy egy idegen programtól származik.

**Az ismeretlen kapcsolat azt jelenti, hogy adatok szivárogtak ki?**  
Nem feltétlenül. De olyan jelzés, amelyet tisztázni kell. Hogy átvittek-e adatokat, és melyeket, azt gyakran csak tűzfal- vagy hálózati naplókkal lehet megválaszolni. Ha személyes adatok érintettek, bejelentési kötelezettségek állhatnak fenn.

**Egyáltalán lehetnek kimenő kapcsolatai egy webszervernek?**  
Csak azokhoz a célokhoz, amelyekre szüksége van. A mindent mást zároló kimenő szűrés jelentősen megnehezíti a támadóknak az eszközök letöltését és az adatok kiszivárogtatását. Gondosan tesztelni kell azonban.

## Források

- [BSI: a német szövetségi információbiztonsági hivatal](https://www.bsi.bund.de/)
- [GDPR 33. cikk: bejelentés a felügyeleti hatóságnak](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)
