# Preverjanje odhodnih povezav strežnika

> Preverite odhodne povezave strežnika: s ss in lsof dodelite procese, ocenite neznane cilje in odtekanje podatkov omejite z izhodnim filtrom.

Vir: https://phpsos.de/sl/blog/ausgehende-verbindungen-pruefen/  
Stanje: 25.10.2026  
Ponudnik: PHP SOS, Nujna pomoč za PHP in varnost strežnikov. Takojšnja pomoč po WhatsAppu: https://wa.me/491736494914?text=Pozdravljeni%2C%20PHP%20SOS%2C%20potrebujemo%20pomo%C4%8D%20z%20na%C5%A1im%20stre%C5%BEnikom%20PHP.%20Podjetje%3A%20%E2%80%A6%20Spletna%20stran%3A%20%E2%80%A6

**Na kratko:** Odhodne povezave strežnika preverite z `ss -tunap` ali `lsof -i`, ki vsako povezavo dodelita procesu. Običajne so povezave do podatkovne baze, poštnega strežnika, strežnikov za posodobitve in znanih vmesnikov. Povezave procesov PHP ali spletnega strežnika z neznanimi cilji, nenavadna vrata in trajne povezave brez povoda so opozorilni znaki za daljinsko upravljanje ali odtekanje podatkov. Trajno pomaga izhodno filtriranje, ki dovoli samo potrebne cilje.

## Zakaj pogled navzven toliko pove

Pri iskanju vdora večina gleda datoteke. Toda napadalec s svojim dostopom želi nekaj početi: naložiti orodja, prejemati ukaze, spraviti ven podatke ali strežnik uporabiti za neželeno pošto ali napade na druge. Vse to potrebuje povezave navzven.

Spletni strežnik sam vzpostavi le malo povezav, večina je predvidljivih: poizveduje po podatkovni bazi, predaja pošto, kliče plačilne ali dostavne vmesnike in prenaša posodobitve. Zato tuje povezave tu še posebej izstopajo. Po poročilih, ki so nam na voljo, odhodne povezave sodijo med splošne opozorilne znake po vdoru; potrjenih indikatorjev ogroženosti (Indicators of Compromise) posebej za PHP2Shell ni. Nadaljnje znake povzema [Ali smo že ogroženi?](https://phpsos.de/sl/php2shell/bin-ich-gehackt-anzeichen/).

## Naštejte odhodne povezave in jih dodelite procesom

Naslednji ukazi samo berejo. Izvedite jih kot root, sicer podatki o procesih manjkajo.

```bash
# Vse vzpostavljene povezave TCP s procesom
ss -tnp state established

# TCP in UDP vključno s poslušajočimi storitvami
ss -tunap

# Povezave po programu in uporabniku, brez razreševanja imen
lsof -i -n -P | grep -v LISTEN

# Samo povezave procesov uporabnikov spletnega strežnika
lsof -i -n -P -u www-data 2>/dev/null
```

V izpisu bodite pozorni na tri stolpce: proces, ciljni naslov z vrati in uporabnika. Povezava `php-fpm` do podatkovne baze na vratih 3306 je običajna. Povezava programa z neznanim imenom iz `/tmp` do tujega naslova na nenavadnih vratih ni. Pod katerim uporabnikom PHP teče, je odvisno od distribucije in nadzorne plošče.

## Običajno ali sumljivo? Razvrstitev

| Opazovanje | Prej običajno | Prej sumljivo |
|---|---|---|
| Cilj | lastna podatkovna baza, poštni strežnik, znani API-ji, strežniki za posodobitve | neznani naslovi brez povezave z aplikacijo |
| Proces | php-fpm, spletni strežnik, poštne storitve in storitve posodobitev | neznani programi, procesi iz `/tmp` ali `/dev/shm` |
| Vrata | 443, 3306, 5432, 587 | nenavadna visoka vrata, vrata, značilna za IRC |
| Trajanje | kratko, ustreza zahtevam | trajno odprto, tudi ponoči brez obiskovalcev |
| Količina | majhna in enakomerna | nenadni vrhovi v odhodnem obsegu podatkov |
| Poštni promet | pošiljanje prek predvidenega poštnega strežnika | veliko neposrednih povezav na vratih 25 |

Veliko povezav na vratih 25 kaže na pošiljanje neželene pošte; zanjo obstaja lasten prispevek, [Strežnik pošilja neželeno pošto](https://phpsos.de/sl/blog/server-verschickt-spam/).

## Ocena neznanega cilja

Tuj naslov na seznamu še ni dokaz. Preden odločite, razjasnite, kam povezava vodi in kdo jo je vzpostavil. Tudi ti koraki ničesar ne spremenijo:

1. **Določite proces:** Vzemite PID iz `ss` in z `ls -l /proc/PID/exe` ter ukazno vrstico preverite, kateri program stoji za njim.
2. **Poiščite cilj:** Z `dig -x <IP>` ugotovite ime, z `whois <IP>` omrežnega operaterja.
3. **Uskladite z aplikacijo:** Vprašajte razvijalca ali izvajalca, ali vaša aplikacija uporablja to storitev.
4. **Preverite potek:** Dnevniki požarnega zidu in omrežja pokažejo, od kdaj povezava obstaja in koliko podatkov je teklo.
5. **Zavarujte rezultate:** Izpise shranite s časom, preden karkoli končate ali zaprete.

Računajte z dvoumnimi rezultati. Številne legitimne storitve tečejo pri velikih ponudnikih oblaka in CDN, katerih naslovi ne dovoljujejo sklepanja o stranki. Obratno tudi napadalci uporabljajo najete strežnike v oblaku. Znan omrežni operater torej ni niti razbremenitev niti dokaz; odločilno je, ali proces in namen ustrezata vaši aplikaciji.

Posnetek z `ss` pokaže samo to, kar je ravno odprto. Kratke povezave, ki se vzpostavljajo v minutnem taktu, vidite samo v dnevnikih. Zato so dnevniki požarnega zidu ali pretoka za vprašanje odtekanja podatkov pogosto pomembnejši od pogleda na sam strežnik.

> **Pomembno:**
> Če so podatki morda zapustili vaš strežnik in so prizadeti osebni podatki, lahko praviloma v 72 urah obstaja obveznost prijave po GDPR. To zgodaj razjasnite s pooblaščencem za varstvo podatkov; ozadje pod [Obveznost prijave po GDPR v 72 urah](https://phpsos.de/sl/compliance/dsgvo-meldepflicht-72-stunden/). To ni pravno svetovanje.

## Ne pozabite DNS in vsebnikov

Vsako odtekanje podatkov ne potrebuje vidne povezave do tujega naslova. Razreševanje imen prek DNS gre na razreševalnik vašega podatkovnega centra in na seznamu `ss` komaj izstopa. Napadalci lahko podatke zapakirajo v dolge, naključno videti poddomene in jih tako spravijo ven prek poizvedb DNS. Namige dajo dnevniki razreševalnika: nenavadno veliko poizvedb po isti tuji domeni, zelo dolga imena ali poizvedbe ob časih, ko spletne strani nihče ne uporablja.

Če vaše aplikacije tečejo v vsebnikih, gostitelj povezave vsebnikov pogosto vidi samo kot promet omrežja vsebnikov. Tedaj preverite vsak vsebnik posebej, če so tam orodja na voljo, ali povezave ovrednotite na ravni gostitelja in požarnega zidu.

```bash
# Povezave znotraj vsebnika (če je ss v sliki)
docker exec <container> ss -tnp 2>/dev/null

# Na gostitelju: povezave, ki jih spremlja jedro, če je conntrack nameščen
sudo conntrack -L 2>/dev/null | head -50
```

## Odhodni promet trajno omejite

Najučinkovitejša preventiva je izhodno filtriranje: strežnik sme doseči samo cilje, ki jih res potrebuje, vse ostalo je zaprto in zabeleženo. Napadalcem je s tem bistveno težje nalagati orodja ali odtegovati podatke, tudi če lahko izvajajo kodo.

Pot do tega se začne s seznamom potrebnih ciljev, ki ga izpeljete iz zgoraj zbranih povezav. Sledi faza, v kateri se zaprte povezave samo beležijo, preden zaporo vklopite. Plačilne storitve, strežniki za posodobitve in vmesniki s spreminjajočimi se naslovi pri tem zahtevajo posebno skrbnost. Kako se požarni zid za spletne strežnike gradi v celoti, opisuje [Požarni zid za spletne strežnike: odprite samo potrebna vrata](https://phpsos.de/sl/blog/firewall-fuer-webserver/).

## Kako PHP SOS pomaga konkretno?

- **Preverjanje povezav:** Vse aktivne povezave dodelimo procesom in namenom ter ocenimo neznane cilje.
- **Ocena odtekanja podatkov:** Ovrednotimo dnevnike požarnega zidu in omrežja ter razjasnimo, ali in kdaj so bili podatki preneseni.
- **Omejitev izhoda:** Z vami pripravimo seznam dovoljenih ciljev in postopoma vzpostavimo izhodno filtriranje.
- **Trajen nadzor:** Z [varnostnim nadzorom](https://phpsos.de/sl/leistungen/security-monitoring/) javljamo nove ali nenavadne povezave.


## Pogosta vprašanja

**Katere odhodne povezave so pri spletnem strežniku običajne?**  
Tipične so povezave do podatkovne baze, poštnega strežnika, plačilnih in dostavnih storitev, strežnikov za posodobitve in znanih vmesnikov aplikacije. Vse, kar ni mogoče razvrstiti pod noben od teh namenov, zasluži natančnejši pogled.

**Kako vidim, kateri proces je vzpostavil povezavo?**  
Z ss -tunap ali lsof -i -n -P kot root. Oba za vsako povezavo pokažeta ID procesa in ime programa. Tako prepoznate, ali povezava izvira iz PHP, spletnega strežnika ali tujega programa.

**Ali neznana povezava pomeni, da so podatki odtekli?**  
Ne nujno. Je pa namig, ki ga je treba razjasniti. Ali in kateri podatki so bili preneseni, je pogosto mogoče ugotoviti samo z dnevniki požarnega zidu ali omrežja. Če so prizadeti osebni podatki, lahko obstajajo obveznosti prijave.

**Ali bi spletni strežnik sploh smel imeti odhodne povezave?**  
Samo do ciljev, ki jih potrebuje. Izhodno filtriranje, ki zapre vse ostalo, napadalcem bistveno otežuje nalaganje orodij in odtekanje podatkov. Vendar ga je treba skrbno preizkusiti.

## Viri

- [BSI: Zvezni urad za varnost v informacijski tehnologiji (Nemčija)](https://www.bsi.bund.de/)
- [DSGVO Art. 33: prijava nadzornemu organu](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)