# Проверка на изходящите връзки на един сървър

> Проверка на изходящите връзки на сървър: свържете процесите с ss и lsof, оценете непознатите цели и ограничете изтичането на данни чрез филтър за изходящ трафик.

Източник: https://phpsos.de/bg/blog/ausgehende-verbindungen-pruefen/  
Актуалност: 25.10.2026  
Доставчик: PHP SOS, Спешна помощ за PHP и сигурност на сървъри. Незабавна помощ по WhatsApp: https://wa.me/491736494914?text=%D0%97%D0%B4%D1%80%D0%B0%D0%B2%D0%B5%D0%B9%D1%82%D0%B5%2C%20PHP%20SOS%2C%20%D0%B8%D0%BC%D0%B0%D0%BC%D0%B5%20%D0%BD%D1%83%D0%B6%D0%B4%D0%B0%20%D0%BE%D1%82%20%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%20%D1%81%20%D0%BD%D0%B0%D1%88%D0%B8%D1%8F%20PHP%20%D1%81%D1%8A%D1%80%D0%B2%D1%8A%D1%80.%20%D0%A4%D0%B8%D1%80%D0%BC%D0%B0%3A%20%E2%80%A6%20%D0%A3%D0%B5%D0%B1%D1%81%D0%B0%D0%B9%D1%82%3A%20%E2%80%A6

**Накратко:** Изходящите връзки на един сървър проверявате с `ss -tunap` или `lsof -i`, които свързват всяка връзка с процес. Нормални са връзките към база данни, пощенски сървър, сървъри за актуализации и познати интерфейси. Връзки на PHP или на процеси на уеб сървъра към непознати цели, необичайни портове и трайни връзки без повод са предупредителни сигнали за дистанционно управление или изтичане на данни. Трайно помага филтриране на изходящия трафик, което позволява само необходимите цели.

## Защо погледът навън разкрива толкова много

При търсенето на проникване повечето гледат файловете. Но нападателят иска да направи нещо със своя достъп: да зареди инструменти, да получава команди, да изнесе данни или да ползва сървъра за спам или нападения срещу други. Всичко това изисква връзки навън.

Уеб сървърът сам изгражда само малко връзки и повечето от тях са предвидими: пита базата данни, предава поща, извиква интерфейси за плащане или доставка и взема актуализации. Затова чужди връзки тук правят особено впечатление. Според наличните ни съобщения изходящите връзки спадат към общите предупредителни сигнали след проникване; потвърдени Indicators of Compromise специално за PHP2Shell няма. Други признаци обобщава [Компрометиран ли съм вече?](https://phpsos.de/bg/php2shell/bin-ich-gehackt-anzeichen/).

## Изброяване на изходящите връзки и свързването им с процеси

Следните команди само четат. Изпълнете ги като root, иначе липсват данните за процесите.

```bash
# Всички изградени TCP връзки с процес
ss -tnp state established

# TCP и UDP, включително слушащи услуги
ss -tunap

# Връзки за всяка програма и потребител, без разрешаване на имена
lsof -i -n -P | grep -v LISTEN

# Само връзки на процеси на потребителите на уеб сървъра
lsof -i -n -P -u www-data 2>/dev/null
```

Обърнете внимание в изхода на три колони: процеса, адреса на целта с порт и потребителя. Връзка на `php-fpm` към базата данни на порт 3306 е нормална. Връзка на програма с непознато име от `/tmp` към чужд адрес на необичаен порт не е. Под кой потребител работи PHP, зависи от дистрибуцията и панела.

## Нормално или подозрително? Класификация

| Наблюдение | По-скоро нормално | По-скоро подозрително |
|---|---|---|
| Цел | собствена база данни, пощенски сървър, познати API, сървъри за актуализации | непознати адреси без връзка с приложението |
| Процес | php-fpm, уеб сървър, пощенски услуги и услуги за актуализации | непознати програми, процеси от `/tmp` или `/dev/shm` |
| Порт | 443, 3306, 5432, 587 | необичайно високи портове, типични за IRC портове |
| Продължителност | кратка, съответстваща на заявките | трайно отворена, и нощем без посетители |
| Обем | малък и равномерен | внезапни пикове в изходящия обем данни |
| Пощенски трафик | изпращане през предвидения пощенски сървър | много директни връзки на порт 25 |

Много връзки на порт 25 сочат изпращане на спам; за това има отделна статия, [Сървърът изпраща спам](https://phpsos.de/bg/blog/server-verschickt-spam/).

## Оценка на непозната цел

Чужд адрес в списъка още не е доказателство. Преди да решите, изяснете накъде води връзката и кой я е изградил. И тези стъпки не променят нищо:

1. **Определете процеса:** Вземете PID от `ss` и проверете с `ls -l /proc/PID/exe` и командния ред коя програма стои зад него.
2. **Потърсете целта:** С `dig -x <IP>` установете името, а с `whois <IP>` - мрежовия оператор.
3. **Сверете с приложението:** Попитайте разработчика или доставчика на услуги дали Вашето приложение ползва тази услуга.
4. **Проверете хода:** Протоколите на защитната стена и на мрежата показват от кога съществува връзката и колко данни са преминали.
5. **Запазете резултатите:** Запишете изходите с час, преди да прекратите или блокирате нещо.

Пригответе се за двусмислени резултати. Много легитимни услуги работят при големи облачни и CDN доставчици, чиито адреси не позволяват извод за клиента. Обратно, и нападателите ползват наети облачни сървъри. Познат мрежов оператор затова не е нито отбой, нито доказателство; решаващо е дали процесът и целта съответстват на Вашето приложение.

Моментна снимка с `ss` показва само онова, което е отворено в момента. Кратки връзки, изграждани на минути, виждате само в протоколите. Затова протоколите на защитната стена или на потоците често са по-важни за въпроса за изтичане на данни от погледа върху самия сървър.

> **Важно:**
> Ако данни са напуснали евентуално Вашия сървър и са засегнати лични данни, по правило може да съществува задължение за уведомяване по ОРЗД в срок от 72 часа. Изяснете това рано с длъжностното лице по защита на данните; контекста има в [Задължение за уведомяване по ОРЗД в рамките на 72 часа](https://phpsos.de/bg/compliance/dsgvo-meldepflicht-72-stunden/). Това не е правен съвет.

## Не забравяйте DNS и контейнерите

Не всяко изтичане на данни изисква видима връзка към чужд адрес. Разрешаването на имена през DNS отива към резолвъра на Вашия център за данни и почти не се забелязва в списъка на `ss`. Нападателите могат да опаковат данни в дълги, привидно случайни поддомейни и така да ги изнасят през DNS заявки. Указания за това дават протоколите на резолвъра: необичайно много заявки към един и същ чужд домейн, много дълги имена или заявки в часове, в които никой не ползва уебсайта.

Ако Вашите приложения работят в контейнери, хостът често вижда връзките на контейнерите само като трафик на контейнерната мрежа. Проверете тогава във всеки контейнер поотделно, доколкото инструментите са налични там, или анализирайте връзките на ниво хост и защитна стена.

```bash
# Връзки в рамките на контейнер (ако ss се съдържа в образа)
docker exec <container> ss -tnp 2>/dev/null

# На хоста: проследявани от ядрото връзки, ако conntrack е инсталиран
sudo conntrack -L 2>/dev/null | head -50
```

## Трайно ограничаване на изходящия трафик

Най-ефективната превенция е филтриране на изходящия трафик: сървърът може да достига само целите, от които наистина се нуждае, всичко останало се блокира и протоколира. За нападателите така става значително по-трудно да зареждат инструменти или да изтеглят данни, дори да могат да изпълняват код.

Пътят натам започва със списък на необходимите цели, който извеждате от събраните по-горе връзки. После следва фаза, в която блокираните връзки само се протоколират, преди блокировката да се включи на пълна сила. Услугите за плащане, сървърите за актуализации и интерфейсите с променящи се адреси изискват тук особено внимание. Как се изгражда защитна стена за уеб сървъри като цяло, описва [Защитна стена за уеб сървъри: отваряйте само нужните портове](https://phpsos.de/bg/blog/firewall-fuer-webserver/).

## Как помага PHP SOS конкретно?

- **Проверка на връзките:** Причисляваме всички активни връзки към процеси и цели и оценяваме непознатите цели.
- **Оценка на изтичането на данни:** Анализираме протоколите на защитната стена и на мрежата и изясняваме дали и кога са предавани данни.
- **Ограничаване на изхода:** Заедно с Вас изработваме списък на разрешените цели и въвеждаме филтрирането на изходящия трафик стъпка по стъпка.
- **Трайно наблюдение:** С [Security Monitoring](https://phpsos.de/bg/leistungen/security-monitoring/) съобщаваме за нови или необичайни връзки.


## Често задавани въпроси

**Кои изходящи връзки са нормални за уеб сървър?**  
Типични са връзките към базата данни, към пощенския сървър, към услуги за плащане и доставка, към сървъри за актуализации и към познати интерфейси на приложението. Всичко, което не може да се причисли към тези цели, заслужава по-внимателен поглед.

**Как виждам кой процес е изградил връзка?**  
С ss -tunap или lsof -i -n -P като root. И двете показват за всяка връзка ID на процеса и името на програмата. Така разпознавате дали връзката идва от PHP, от уеб сървъра или от чужда програма.

**Означава ли непозната връзка, че са изтекли данни?**  
Не непременно. Тя е обаче указание, което трябва да се изясни. Дали и какви данни са предадени, често може да се отговори само с протоколи на защитната стена или на мрежата. Ако са засегнати лични данни, може да съществуват задължения за уведомяване.

**Трябва ли изобщо уеб сървърът да има право на изходящи връзки?**  
Само към целите, от които се нуждае. Филтриране на изходящия трафик, което блокира всичко останало, значително затруднява нападателите при зареждането на инструменти и при изтичането на данни. Трябва обаче да се тества внимателно.

## Източници

- [BSI: Федерална служба за информационна сигурност на Германия](https://www.bsi.bund.de/)
- [ОРЗД, чл. 33: Уведомяване на надзорния орган](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)