Накратко: Изходящите връзки на един сървър проверявате с ss -tunap или lsof -i, които свързват всяка връзка с процес. Нормални са връзките към база данни, пощенски сървър, сървъри за актуализации и познати интерфейси. Връзки на PHP или на процеси на уеб сървъра към непознати цели, необичайни портове и трайни връзки без повод са предупредителни сигнали за дистанционно управление или изтичане на данни. Трайно помага филтриране на изходящия трафик, което позволява само необходимите цели.
Защо погледът навън разкрива толкова много
При търсенето на проникване повечето гледат файловете. Но нападателят иска да направи нещо със своя достъп: да зареди инструменти, да получава команди, да изнесе данни или да ползва сървъра за спам или нападения срещу други. Всичко това изисква връзки навън.
Уеб сървърът сам изгражда само малко връзки и повечето от тях са предвидими: пита базата данни, предава поща, извиква интерфейси за плащане или доставка и взема актуализации. Затова чужди връзки тук правят особено впечатление. Според наличните ни съобщения изходящите връзки спадат към общите предупредителни сигнали след проникване; потвърдени Indicators of Compromise специално за PHP2Shell няма. Други признаци обобщава Компрометиран ли съм вече?.
Изброяване на изходящите връзки и свързването им с процеси
Следните команди само четат. Изпълнете ги като root, иначе липсват данните за процесите.
# Всички изградени 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 сочат изпращане на спам; за това има отделна статия, Сървърът изпраща спам.
Оценка на непозната цел
Чужд адрес в списъка още не е доказателство. Преди да решите, изяснете накъде води връзката и кой я е изградил. И тези стъпки не променят нищо:
- Определете процеса: Вземете PID от
ssи проверете сls -l /proc/PID/exeи командния ред коя програма стои зад него. - Потърсете целта: С
dig -x <IP>установете името, а сwhois <IP>- мрежовия оператор. - Сверете с приложението: Попитайте разработчика или доставчика на услуги дали Вашето приложение ползва тази услуга.
- Проверете хода: Протоколите на защитната стена и на мрежата показват от кога съществува връзката и колко данни са преминали.
- Запазете резултатите: Запишете изходите с час, преди да прекратите или блокирате нещо.
Пригответе се за двусмислени резултати. Много легитимни услуги работят при големи облачни и CDN доставчици, чиито адреси не позволяват извод за клиента. Обратно, и нападателите ползват наети облачни сървъри. Познат мрежов оператор затова не е нито отбой, нито доказателство; решаващо е дали процесът и целта съответстват на Вашето приложение.
Моментна снимка с ss показва само онова, което е отворено в момента. Кратки връзки, изграждани на минути, виждате само в протоколите. Затова протоколите на защитната стена или на потоците често са по-важни за въпроса за изтичане на данни от погледа върху самия сървър.
Ако данни са напуснали евентуално Вашия сървър и са засегнати лични данни, по правило може да съществува задължение за уведомяване по ОРЗД в срок от 72 часа. Изяснете това рано с длъжностното лице по защита на данните; контекста има в Задължение за уведомяване по ОРЗД в рамките на 72 часа. Това не е правен съвет.
Не забравяйте DNS и контейнерите
Не всяко изтичане на данни изисква видима връзка към чужд адрес. Разрешаването на имена през DNS отива към резолвъра на Вашия център за данни и почти не се забелязва в списъка на ss. Нападателите могат да опаковат данни в дълги, привидно случайни поддомейни и така да ги изнасят през DNS заявки. Указания за това дават протоколите на резолвъра: необичайно много заявки към един и същ чужд домейн, много дълги имена или заявки в часове, в които никой не ползва уебсайта.
Ако Вашите приложения работят в контейнери, хостът често вижда връзките на контейнерите само като трафик на контейнерната мрежа. Проверете тогава във всеки контейнер поотделно, доколкото инструментите са налични там, или анализирайте връзките на ниво хост и защитна стена.
# Връзки в рамките на контейнер (ако ss се съдържа в образа)
docker exec <container> ss -tnp 2>/dev/null
# На хоста: проследявани от ядрото връзки, ако conntrack е инсталиран
sudo conntrack -L 2>/dev/null | head -50
Трайно ограничаване на изходящия трафик
Най-ефективната превенция е филтриране на изходящия трафик: сървърът може да достига само целите, от които наистина се нуждае, всичко останало се блокира и протоколира. За нападателите така става значително по-трудно да зареждат инструменти или да изтеглят данни, дори да могат да изпълняват код.
Пътят натам започва със списък на необходимите цели, който извеждате от събраните по-горе връзки. После следва фаза, в която блокираните връзки само се протоколират, преди блокировката да се включи на пълна сила. Услугите за плащане, сървърите за актуализации и интерфейсите с променящи се адреси изискват тук особено внимание. Как се изгражда защитна стена за уеб сървъри като цяло, описва Защитна стена за уеб сървъри: отваряйте само нужните портове.
Как помага PHP SOS конкретно?
- Проверка на връзките: Причисляваме всички активни връзки към процеси и цели и оценяваме непознатите цели.
- Оценка на изтичането на данни: Анализираме протоколите на защитната стена и на мрежата и изясняваме дали и кога са предавани данни.
- Ограничаване на изхода: Заедно с Вас изработваме списък на разрешените цели и въвеждаме филтрирането на изходящия трафик стъпка по стъпка.
- Трайно наблюдение: С Security Monitoring съобщаваме за нови или необичайни връзки.
Често задавани въпроси
Кои изходящи връзки са нормални за уеб сървър?
Типични са връзките към базата данни, към пощенския сървър, към услуги за плащане и доставка, към сървъри за актуализации и към познати интерфейси на приложението. Всичко, което не може да се причисли към тези цели, заслужава по-внимателен поглед.
Как виждам кой процес е изградил връзка?
С ss -tunap или lsof -i -n -P като root. И двете показват за всяка връзка ID на процеса и името на програмата. Така разпознавате дали връзката идва от PHP, от уеб сървъра или от чужда програма.
Означава ли непозната връзка, че са изтекли данни?
Не непременно. Тя е обаче указание, което трябва да се изясни. Дали и какви данни са предадени, често може да се отговори само с протоколи на защитната стена или на мрежата. Ако са засегнати лични данни, може да съществуват задължения за уведомяване.
Трябва ли изобщо уеб сървърът да има право на изходящи връзки?
Само към целите, от които се нуждае. Филтриране на изходящия трафик, което блокира всичко останало, значително затруднява нападателите при зареждането на инструменти и при изтичането на данни. Трябва обаче да се тества внимателно.