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

> Анализ на access лога след атака: първо запазване на логовете, намиране на типични следи, команди за Apache и Nginx и особености при PHP2Shell.

Източник: https://phpsos.de/bg/ratgeber/logfiles-auswerten/  
Актуалност: 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

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

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

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

```bash
# Копиране на логовете с времеви печати и запазване на контролните суми
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"
```

Съхранете архива допълнително на друга система. Атакуващ с достъп до сървъра иначе би могъл впоследствие да промени логовете. Контролните суми по-късно показват, че копието е непроменено. Ако е нужно доказателствено архивиране, например за сигнал или застраховка, архивирането трябва да поеме [ИТ криминалистика](https://phpsos.de/bg/leistungen/it-forensik/).

> **Важно:**
> Проверете ротацията на логовете (`/etc/logrotate.d/`) и удължете временно съхранението, за да не се изтриват повече файлове по време на анализа.

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

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

| Система | Access и error лог |
|---|---|
| Debian, Ubuntu с Apache | `/var/log/apache2/` |
| RHEL, AlmaLinux, Rocky с Apache | `/var/log/httpd/` |
| Nginx | `/var/log/nginx/` |
| Plesk | `/var/www/vhosts/system/<domain>/logs/` |
| PHP-FPM | `/var/log/php*-fpm.log` или в журнала |

В разпространения 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`.

```bash
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'
```

При първата заявка особено интересни са имена на файлове, които не познавате или които не принадлежат към приложението. Сверете подозрителните файлове с файловата система: кога са създадени, на кого принадлежат, какво съдържат? Указания има в наръчника [Разпознаване и премахване на уеб шелове](https://phpsos.de/bg/ratgeber/webshell-erkennen/).

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

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

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

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

Нито един от тези сигнали сам по себе си не е доказателство. Заедно с други следи обаче те дават картина, която отговаря на въпроса за компрометиране или обосновава по-задълбочено разследване. Преглед на признаците ще намерите на страницата [Вече компрометиран ли съм?](https://phpsos.de/bg/php2shell/bin-ich-gehackt-anzeichen/).

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

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

```bash
# 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 и системните логове заедно и изготвяме времева линия на инцидента.
- При указания за компрометиране поемаме [реагирането при инциденти](https://phpsos.de/bg/leistungen/incident-response/) с ограничаване и почистване.
- Настройваме ротацията и съхранението на логовете така, че при следващия инцидент да има необходимите данни.


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

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

**Показва ли access логът дали атаката е била успешна?**  
Не сам по себе си. Той показва заявките, статус кодовете и размерите на отговорите, но не и какъв код е бил изпълнен на сървъра. Надеждна картина се получава едва заедно с error лога, лога на PHP-FPM, промените във файловете и системните протоколи.

**Мога ли да предавам IP адреси от логовете на трети лица?**  
IP адресите по правило се смятат за лични данни. За изясняването на инцидент и за подаването на сигнали за престъпление има основания, но предаването трябва да се съгласува с длъжностното лице по защита на данните.

**Защо виждам в лога много атаки, въпреки че нищо не се е случило?**  
Публичните сървъри се сканират непрекъснато автоматизирано. Повечето от тези заявки отиват на празно и завършват с 404 или 403. Интересни са преди всичко заявките със статус 200 към непознати файлове и моделите, които съвпадат по време с други следи.

## Източници

- [TechTarget: PHP2Shell, 22M exposed servers at risk](https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released)
- [php.net: Съобщения за сигурност](https://www.php.net/)
- [BSI IT-Grundschutz](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)