Накратко: Променени файлове под Linux намирате с find и времеви прозорец, например от 17 октомври 2026 г., първия според съобщения в медиите наблюдаван опит за нападение с PHP2Shell. Проверявайте при това не само времето на промяна на съдържанието (mtime), а и на метаданните (ctime), защото първото се фалшифицира лесно. Резултатът става надежден едва със сверка с контролни суми на пакети, Git или резервно копие.
Защо времевите печати са добро начало, но не и доказателство
Който внася код на сървър, променя файлове. Нови уеб шелове, нагодени конфигурационни файлове, добавени редове в съществуващи скриптове: всичко това оставя времеви печати. Търсенето на промени в правилния времеви прозорец затова е един от най-бързите пътища към първите находки.
За PHP2Shell като начало на прозореца се предлага 17 октомври 2026 г., денят на първия според съобщения в медиите наблюдаван опит за нападение. Пачовете излязоха на 21 октомври. Който е актуализирал сървъра си едва след това, търси до деня на собствената си актуализация и отвъд него. Как да разпознаете уеб шелове сред находките, описва Разпознаване и премахване на уеб шел. Тук става дума за самия метод на търсене.
Трите времеви печата на един файл
Linux съхранява за всеки файл няколко момента. За търсенето на промени два са решаващи.
| Времеви печат | Значение | Може ли да се фалшифицира? |
|---|---|---|
| mtime | последна промяна на съдържанието | да, напр. с touch, от всеки, който може да пише във файла |
| ctime | последна промяна на съдържанието или на метаданни като права | не с прости средства |
| atime | последен достъп за четене | често изключен или неточен, малко подходящ за търсенето |
Нападателите обичат да връщат mtime към датата на съседните файлове, за да не бие на очи нов файл. ctime обаче се променя заедно с това. Файл със стар mtime и пресен ctime затова е силно указание за манипулация.
При сравнението внимавайте за часовите зони. find и ls показват местното време на сървъра, докато много лог файлове и услуги работят в UTC. Който поставя находки от файловата система и от логовете един до друг, трябва да преобразува всички данни в една и съща часова зона, иначе събитията привидно не си пасват. Пачовете излязоха около 21 октомври в 14:00 UTC, тоест в 16:00 ч. германско време.
Намиране на променени файлове под Linux с find
Всички команди само четат. Пригодете пътя и датата.
# Съдържание, променено от 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 не показват. Нападателите обичат това, както и имена, които се бъркат лесно с истинските файлове.
# Скрити файлове и папки в уеб директорията, без познати като .htaccess и .git
find /var/www -name ".*" -not -name ".htaccess" -not -name ".well-known" -not -path "*/.git/*" -printf '%C+ %u %p\n' | sort
Сверка с надежден източник
Времевите печати показват къде нещо се е раздвижило. Дали е било легитимна промяна, показва едва сравнението с източник, на който се доверявате.
- Управление на пакетите: За системни файлове
dpkg --verify(Debian/Ubuntu) илиrpm -Va(RHEL семейство) проверяват файловете спрямо контролните суми на инсталираните пакети. Конфигурационните файлове се различават легитимно, файловете на програмите - не. - Git: Ако приложението е в хранилище,
git -C /var/www/projekt status --porcelainпоказва всяко отклонение от последния commit. - Контролни суми на CMS: Много системи могат да сверяват ядрените си файлове с официалните контролни суми, вижте Сравняване на ядрените файлове на CMS с оригинала.
- Резервно копие от преди инцидента: Сравнение в пробен режим изброява разликите, без нищо да копира.
# Само изброяване на разликите между състоянието на копието и живата система (пробен режим, нищо не копира)
rsync -rcn --out-format="%n" /backup/www-2026-10-15/ /var/www/
Сравнението с резервно копие предполага, че копието е възникнало преди инцидента и самò не е променено. Защо отделно съхраняваните копия са тук решаващи, обяснява Резервни копия по правилото 3-2-1.
Записвайте резултатите от всяко търсене с дата във файл извън сървъра. От тези списъци по-късно възниква времевата линия на инцидента и те доказват какво и кога сте проверили.
Когато няма нито резервно копие, нито хранилище
При много по-малки уебсайтове няма чиста база за сравнение: няма Git, няма копие от преди инцидента, добавките се обновяват от години на ръка. Все пак не оставате без опора.
Изтеглете CMS и разширенията точно в инсталираните версии от производителя и сравнете тези файлове със сървъра. Което се различава или липсва, заслужава поглед. Остават Вашите собствени нагласи, качените файлове и конфигурацията; там помага търсенето по времеви печати, допълнено с поглед върху собственика и правата. Файлове, които са единствени в директория с друга група, други права или значително по-млад ctime от съседите си, принадлежат в списъка.
Честно казано: без база за сравнение остава остатъчна несигурност. При системи с чувствителни данни ново изграждане от чисти източници е тогава често по-надеждно от търсенето на всеки отделен променен файл. За бъдещето поуката е проста: хранилище за кода и редовни, отделно съхранявани резервни копия.
Типични източници на грешки при търсенето
- Прекалено щедри изключвания: Кеш директориите и директориите за качване са любими скривалища.
- Проверен само mtime: Върнатите назад файлове се изплъзват.
- Deployment в прозореца: Редовен rollout променя стотици файлове и закрива отделни находки. Сверете с хранилището.
- Файлове вече отворени или копирани: Копия без запазване на времевите печати унищожават следи. Запазвайте с инструменти, които запазват времевите печати.
- Търсене само в уеб директорията: Нападателите оставят инструменти и в
/tmp,/dev/shmили в домашната директория на потребителя на уеб сървъра. - Пропуснати промени в правата: Файл, чиито права внезапно позволяват запис на всички, е находка, дори съдържанието му да е непроменено.
Как находките се подреждат в ход на събитията, показва Съставяне на времева линия на инцидент.
Как помага PHP SOS конкретно?
- Систематично търсене: Претърсваме уеб директориите и системните пътища за промени в съответния времеви прозорец и оценяваме mtime и ctime заедно.
- Проверка спрямо оригиналите: Сверяваме с пакети, хранилище, контролни суми на CMS и Вашите резервни копия.
- Оценка на находките: Отделяме редовните промени от манипулациите и запазваме доказателства.
- Почистване: С премахване на зловреден софтуер възстановяваме чисто състояние и го документираме.
Често задавани въпроси
Как да намеря всички файлове, променени от определена дата насам?
С find и опцията -newermt, например find /var/www -type f -newermt "2026-10-17". За промени в метаданните ползвайте -newerct. И двете команди само четат и не променят нищо.
Каква е разликата между mtime и ctime?
mtime е моментът на последната промяна на съдържанието и може да се върне назад с прости средства. ctime е моментът на последната промяна на съдържанието или метаданните и не се фалшифицира толкова лесно. Ако двете се различават силно, си заслужава внимателен поглед.
Как да изключа кеш файловете от търсенето?
С -not -path за познати кеш директории, директории с логове и сесии. Не изключвайте обаче прекалено щедро, защото нападателите обичат да оставят файлове точно там, където много промени са нормални.
Коя проверка е най-надеждна?
Сверката с надежден източник: контролни суми от управлението на пакетите, Git хранилище или резервно копие от преди инцидента. Времевите печати са добро начало, но не и доказателство.