# Намиране на наскоро променени файлове на уеб сървъра

> Намиране на променени файлове под Linux: времеви прозорец с find, правилно тълкуване на mtime и ctime, сверка с пакети и резервни копия и изключване на фалшиви тревоги.

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

**Накратко:** Променени файлове под Linux намирате с `find` и времеви прозорец, например от 17 октомври 2026 г., първия според съобщения в медиите наблюдаван опит за нападение с PHP2Shell. Проверявайте при това не само времето на промяна на съдържанието (mtime), а и на метаданните (ctime), защото първото се фалшифицира лесно. Резултатът става надежден едва със сверка с контролни суми на пакети, Git или резервно копие.

## Защо времевите печати са добро начало, но не и доказателство

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

За PHP2Shell като начало на прозореца се предлага 17 октомври 2026 г., денят на първия според съобщения в медиите наблюдаван опит за нападение. Пачовете излязоха на 21 октомври. Който е актуализирал сървъра си едва след това, търси до деня на собствената си актуализация и отвъд него. Как да разпознаете уеб шелове сред находките, описва [Разпознаване и премахване на уеб шел](https://phpsos.de/bg/ratgeber/webshell-erkennen/). Тук става дума за самия метод на търсене.

## Трите времеви печата на един файл

Linux съхранява за всеки файл няколко момента. За търсенето на промени два са решаващи.

| Времеви печат | Значение | Може ли да се фалшифицира? |
|---|---|---|
| mtime | последна промяна на съдържанието | да, напр. с `touch`, от всеки, който може да пише във файла |
| ctime | последна промяна на съдържанието или на метаданни като права | не с прости средства |
| atime | последен достъп за четене | често изключен или неточен, малко подходящ за търсенето |

Нападателите обичат да връщат mtime към датата на съседните файлове, за да не бие на очи нов файл. ctime обаче се променя заедно с това. Файл със стар mtime и пресен ctime затова е силно указание за манипулация.

При сравнението внимавайте за часовите зони. `find` и `ls` показват местното време на сървъра, докато много лог файлове и услуги работят в UTC. Който поставя находки от файловата система и от логовете един до друг, трябва да преобразува всички данни в една и съща часова зона, иначе събитията привидно не си пасват. Пачовете излязоха около 21 октомври в 14:00 UTC, тоест в 16:00 ч. германско време.

## Намиране на променени файлове под Linux с find

Всички команди само четат. Пригодете пътя и датата.

```bash
# Съдържание, променено от 17.10.2026 г., сортирано, с mtime, ctime и собственик
find /var/www -type f -newermt "2026-10-17" -printf '%TY-%Tm-%Td %TH:%TM  %CY-%Cm-%Cd %CH:%CM  %u  %p\n' | sort

# Метаданни, променени от 17.10.2026 г. (намира и върнатите назад файлове)
find /var/www -type f -newerct "2026-10-17" -printf '%C+  %T+  %p\n' | sort

# Скриване на познатия шум: кеш, логове, сесии
find /var/www -type f -newerct "2026-10-17" \
  -not -path "*/cache/*" -not -path "*/logs/*" -not -path "*/sessions/*" -printf '%C+  %p\n' | sort

# Погледнете и извън уеб директорията
find /etc /usr/local/bin /tmp /var/tmp /dev/shm -xdev -type f -newerct "2026-10-17" -printf '%C+  %p\n' 2>/dev/null | sort
```

При всяко попадение сравнете двата времеви печата. Ако ctime е значително по-млад от mtime и никой в това време не е променял права или копирал файлове, файлът принадлежи в списъка. Внимавайте и за собственика: файл на потребителя на уеб сървъра между файлове на потребителя за deploy бие на очи.

Не забравяйте скритите файлове и директории. Имена, започващи с точка, много файлови мениджъри и обикновеното `ls` не показват. Нападателите обичат това, както и имена, които се бъркат лесно с истинските файлове.

```bash
# Скрити файлове и папки в уеб директорията, без познати като .htaccess и .git
find /var/www -name ".*" -not -name ".htaccess" -not -name ".well-known" -not -path "*/.git/*" -printf '%C+  %u  %p\n' | sort
```

## Сверка с надежден източник

Времевите печати показват къде нещо се е раздвижило. Дали е било легитимна промяна, показва едва сравнението с източник, на който се доверявате.

1. **Управление на пакетите:** За системни файлове `dpkg --verify` (Debian/Ubuntu) или `rpm -Va` (RHEL семейство) проверяват файловете спрямо контролните суми на инсталираните пакети. Конфигурационните файлове се различават легитимно, файловете на програмите - не.
2. **Git:** Ако приложението е в хранилище, `git -C /var/www/projekt status --porcelain` показва всяко отклонение от последния commit.
3. **Контролни суми на CMS:** Много системи могат да сверяват ядрените си файлове с официалните контролни суми, вижте [Сравняване на ядрените файлове на CMS с оригинала](https://phpsos.de/bg/blog/cms-kerndateien-vergleichen/).
4. **Резервно копие от преди инцидента:** Сравнение в пробен режим изброява разликите, без нищо да копира.

```bash
# Само изброяване на разликите между състоянието на копието и живата система (пробен режим, нищо не копира)
rsync -rcn --out-format="%n" /backup/www-2026-10-15/ /var/www/
```

Сравнението с резервно копие предполага, че копието е възникнало преди инцидента и самò не е променено. Защо отделно съхраняваните копия са тук решаващи, обяснява [Резервни копия по правилото 3-2-1](https://phpsos.de/bg/ratgeber/backups-3-2-1/).

> **Съвет:**
> Записвайте резултатите от всяко търсене с дата във файл извън сървъра. От тези списъци по-късно възниква времевата линия на инцидента и те доказват какво и кога сте проверили.

## Когато няма нито резервно копие, нито хранилище

При много по-малки уебсайтове няма чиста база за сравнение: няма Git, няма копие от преди инцидента, добавките се обновяват от години на ръка. Все пак не оставате без опора.

Изтеглете CMS и разширенията точно в инсталираните версии от производителя и сравнете тези файлове със сървъра. Което се различава или липсва, заслужава поглед. Остават Вашите собствени нагласи, качените файлове и конфигурацията; там помага търсенето по времеви печати, допълнено с поглед върху собственика и правата. Файлове, които са единствени в директория с друга група, други права или значително по-млад ctime от съседите си, принадлежат в списъка.

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

## Типични източници на грешки при търсенето

- **Прекалено щедри изключвания:** Кеш директориите и директориите за качване са любими скривалища.
- **Проверен само mtime:** Върнатите назад файлове се изплъзват.
- **Deployment в прозореца:** Редовен rollout променя стотици файлове и закрива отделни находки. Сверете с хранилището.
- **Файлове вече отворени или копирани:** Копия без запазване на времевите печати унищожават следи. Запазвайте с инструменти, които запазват времевите печати.
- **Търсене само в уеб директорията:** Нападателите оставят инструменти и в `/tmp`, `/dev/shm` или в домашната директория на потребителя на уеб сървъра.
- **Пропуснати промени в правата:** Файл, чиито права внезапно позволяват запис на всички, е находка, дори съдържанието му да е непроменено.

Как находките се подреждат в ход на събитията, показва [Съставяне на времева линия на инцидент](https://phpsos.de/bg/blog/zeitleiste-eines-vorfalls/).

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

- **Систематично търсене:** Претърсваме уеб директориите и системните пътища за промени в съответния времеви прозорец и оценяваме mtime и ctime заедно.
- **Проверка спрямо оригиналите:** Сверяваме с пакети, хранилище, контролни суми на CMS и Вашите резервни копия.
- **Оценка на находките:** Отделяме редовните промени от манипулациите и запазваме доказателства.
- **Почистване:** С [премахване на зловреден софтуер](https://phpsos.de/bg/leistungen/malware-entfernung/) възстановяваме чисто състояние и го документираме.


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

**Как да намеря всички файлове, променени от определена дата насам?**  
С find и опцията -newermt, например find /var/www -type f -newermt "2026-10-17". За промени в метаданните ползвайте -newerct. И двете команди само четат и не променят нищо.

**Каква е разликата между mtime и ctime?**  
mtime е моментът на последната промяна на съдържанието и може да се върне назад с прости средства. ctime е моментът на последната промяна на съдържанието или метаданните и не се фалшифицира толкова лесно. Ако двете се различават силно, си заслужава внимателен поглед.

**Как да изключа кеш файловете от търсенето?**  
С -not -path за познати кеш директории, директории с логове и сесии. Не изключвайте обаче прекалено щедро, защото нападателите обичат да оставят файлове точно там, където много промени са нормални.

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

## Източници

- [BSI: Федерална служба за информационна сигурност на Германия](https://www.bsi.bund.de/)
- [Debian Security Tracker](https://security-tracker.debian.org/)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)