Анализ на логовете на уеб сървъра след атака: как да четете access лога

Накратко: Който иска да анализира access лога след атака, първо запазва логовете непроменени и след това работи само с копия. Търсят се заявки със статус 200 към непознати PHP файлове, подозрителни POST заявки, достъпи до директории за качвания и времеви модели. За PHP2Shell няма публикувани, потвърдени Indicators of Compromise, затова значение има цялостната картина от няколко източника на логове.

Първо запазване, после анализ

Лог файловете на повечето сървъри се ротират автоматично и след фиксирано време се изтриват. След атака затова първата стъпка е да се запазят наличните логове, преди да изчезнат. Това важи и когато още не сте сигурни дали изобщо нещо се е случило. За PHP2Shell специализираната преса съветва логовете да се пазят от 20.10.2026.

# Копиране на логовете с времеви печати и запазване на контролните суми
ZIEL=/root/sicherung-logs-$(date +%F)
mkdir -p "$ZIEL"
cp -a /var/log/nginx /var/log/apache2 /var/log/php* "$ZIEL"/ 2>/dev/null
cp -a /var/log/auth.log* /var/log/syslog* "$ZIEL"/ 2>/dev/null
find "$ZIEL" -type f -exec sha256sum {} + > "$ZIEL.sha256"

Съхранете архива допълнително на друга система. Атакуващ с достъп до сървъра иначе би могъл впоследствие да промени логовете. Контролните суми по-късно показват, че копието е непроменено. Ако е нужно доказателствено архивиране, например за сигнал или застраховка, архивирането трябва да поеме ИТ криминалистика.

Къде са логовете и как е устроен един ред

Местата за съхранение зависят от дистрибуцията и от административния интерфейс. Типични пътища:

В разпространения Combined формат всеки ред съдържа адреса на клиента, дата и час, метод и път на заявката, статус кода, размера на отговора в байтове, Referer и User-Agent. Обърнете внимание на часовата зона във времевия печат, особено когато сверявате логове със съобщения в UTC. Пачовете за PHP2Shell например бяха публикувани на 21.10.2026 в 14:00 UTC, т.е. в 16 ч. по немско време.

Ако уебсайтът Ви е зад прокси, CDN или load balancer, в лога вероятно стои само неговият адрес. Истинският адрес на посетителя тогава се намира в отделно поле или в логовете на предходната услуга.

Без команден ред: логове в панела или при хостинг доставчика

Не всеки оператор има достъп до shell. При споделен хостинг или управлявани сървъри административните интерфейси обикновено предлагат изглед на логовете и изтегляне на access и error логовете. Изтеглете файловете за целия наличен период и ги съхранете сигурно. Попитайте писмено хостинг доставчика колко дълго се пазят логовете и могат ли по-старите състояния да се запазят, преди да изтекат.

Имайте предвид при това защитата на данните: логовете съдържат IP адреси и често други лични данни. Съхранявайте копията със защитен достъп, предавайте ги само на лица, които ги нуждаят за изясняването, и определете кога ще бъдат изтрити след приключване на инцидента.

Анализ на access лога: най-важните заявки

Следните команди само четат и са подходящи за Nginx и Apache в Combined формат. Ротираните и компресираните файлове претърсвайте със zgrep или zcat.

LOG=/root/sicherung-logs-2026-10-25/nginx/access.log

# Успешни заявки към PHP файлове, по честота
awk '$9 == 200 && $7 ~ /\.php/ {split($7,p,"?"); print p[1]}' "$LOG" | sort | uniq -c | sort -rn | head -40

# Извиквания на PHP във директории за качвания, кеш или изображения
grep -E '"(GET|POST) /[^ ]*(uploads|cache|images|tmp)/[^ ]*\.php' "$LOG"

# POST заявки по цел и адрес
awk '$6 == "\"POST" {print $1, $7}' "$LOG" | sort | uniq -c | sort -rn | head -40

# Грешки 5xx на час: струпванията могат да сочат към сриващи се PHP процеси
awk '$9 ~ /^5/ {print substr($4, 2, 14)}' "$LOG" | sort | uniq -c

# Включване на ротираните логове
zgrep -h ' 200 ' /var/log/nginx/access.log.*.gz | grep -c '\.php'

При първата заявка особено интересни са имена на файлове, които не познавате или които не принадлежат към приложението. Сверете подозрителните файлове с файловата система: кога са създадени, на кого принадлежат, какво съдържат? Указания има в наръчника Разпознаване и премахване на уеб шелове.

Особености при PHP2Shell

При PHP2Shell уязвимостите са в обработката на заявките на самия PHP. При mod_php е показан експлойт още преди да започне да се изпълнява какъвто и да е код на приложението. Това значи: достатъчна може да бъде заявка към съвсем нормална страница. В access лога такава заявка може да изглежда неподозрително, защото съдържанието на тялото на заявката не е записано там.

Няма публикувани, потвърдени Indicators of Compromise. Затова внимавайте за поведение и връзки, например от 17.10.2026, първия според медийни съобщения наблюдаван опит за атака:

• Струпвания на грешки 500 или прекъснати отговори на обикновени страници.
• Съобщения за изчерпана памет или прекратени worker процеси в error лога и лога на PHP-FPM.
• Нови PHP файлове или променени файлове скоро след такива струпвания.
• Нови cron задачи, процеси или изходящи връзки под потребителя на уеб сървъра.

Нито един от тези сигнали сам по себе си не е доказателство. Заедно с други следи обаче те дават картина, която отговаря на въпроса за компрометиране или обосновава по-задълбочено разследване. Преглед на признаците ще намерите на страницата Вече компрометиран ли съм?.

Други източници: error лог, PHP-FPM и системни протоколи

Access логът показва само част. За пълна картина добавете други източници:

# PHP-FPM и уеб сървър в журнала от дадена дата
journalctl -u 'php*-fpm*' --since "2026-10-17" --no-pager | tail -200

# Влизания в сървъра
last -Fa | head -40
grep -E 'Accepted|Failed' /var/log/auth.log | tail -100

# Проверка на планираните задачи на всички потребители
for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done

Типични грешки при анализа са да се претърсва само текущият, а не и ротираните логове, да се пропусне часовата зона и да се сметнат отделни съвпадения на автоматизирани скенери за успешна атака. Също толкова рисково е обратното: неподозрителен access лог да се оцени като отбой, макар error логът и файловата система още да не са проверени.

Записвайте всяка находка с час, източник и наблюдение във времева линия. Тази времева линия по-късно е основа за решения, за уведомления до органи или застрахователи и за заключителния доклад.

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

• Запазваме логовете и съответните файлове така, че да остават проследими за по-късни проверки.
• Анализираме access, error, PHP и системните логове заедно и изготвяме времева линия на инцидента.
• При указания за компрометиране поемаме реагирането при инциденти с ограничаване и почистване.
• Настройваме ротацията и съхранението на логовете така, че при следващия инцидент да има необходимите данни.

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

Източници

• TechTarget: PHP2Shell, 22M exposed servers at risk
• php.net: Съобщения за сигурност
• BSI IT-Grundschutz