Накратко: За да проверите основните файлове на CMS, сравнете инсталираните файлове с чист оригинал на същата версия: при WordPress чрез официалните контролни суми, при други системи чрез свеж файл за изтегляне или чрез възстановяване от composer.lock. Всяко отклонение е задача за проверка. Сравнението открива и неизвестен зловреден код, но покрива само файлове, за които има оригинал.
Защо сравнението открива повече от всяка сигнатура
Скенерите за зловреден софтуер търсят познати модели. Което не познават, пропускат. Сравнението с оригинала работи обратно: то не пита дали един файл изглежда подозрително, а дали точно отговаря на това, което производителят е доставил. Всяко отклонение се забелязва, независимо дали следва познат модел.
След PHP2Shell това е особено ценно. За уязвимостите CVE-2026-109618 и CVE-2026-109619 няма публикувани, потвърдени Indicators of Compromise. Затова скенерите не могат да търсят целенасочено следи от PHP2Shell. Сравнението с оригинала обаче открива всяка промяна в ядрото, независимо как е възникнала. Защо скенерите сами не са достатъчни, обяснява статията Скенери за зловреден софтуер за уебсайтове: какво откриват и какво не.
Принципът: същата версия, чист източник
Едно сравнение е толкова добро, колкото е референцията му. Трябва да са изпълнени три условия:
- Точно същата версия: сравнение с по-нова версия показва стотици безобидни разлики. Установете инсталираната версия от приложението или от
composer.lock. - Официален източник: оригиналът идва от производителя, от официалната директория с пакети или от Вашата собствена система за контрол на версиите. Не от старо резервно копие на засегнатия сървър.
- Сравнение върху копие: работете върху запазено копие на уеб директорията, за да останат времевите печати и следите.
| Система | Референция | Инструмент |
|---|---|---|
| Ядро на WordPress и добавки от директорията | контролни суми от WordPress.org | wp core verify-checksums, wp plugin verify-checksums |
| Composer проекти (напр. Shopware 6, Laravel, Symfony, Drupal, TYPO3 в Composer режим) | възстановяване от composer.lock |
composer install в празна директория, после diff |
| CMS с пакет за изтегляне | пакет на същата версия от производителя | diff -rq |
| Собствени проекти с Git | последен известен commit | git status, git diff |
| Системни пакети на сървъра | база данни на пакетите на дистрибуцията | dpkg --verify, rpm -Va |
WordPress: повече от verify-checksums
Как да проверите ядрото и добавките с WP-CLI, е описано в ръководството Намиране на задни врати в WordPress. Има смисъл в едно допълнение: според документацията на WP-CLI опцията --include-root проверява всички файлове и папки в главната директория и предупреждава за записи, които не принадлежат на WordPress. Именно там атакуващите обичат да оставят файлове, чиито имена напомнят на основни файлове.
# Ядро срещу официалните контролни суми, включително чужди файлове в главната директория
wp core verify-checksums --include-root
Търговски добавки и теми този път не обхваща. За тях изтегляте оригиналния пакет на същата версия от доставчика и сравнявате с diff.
Проверка на основните файлове на CMS при Composer проекти
Много съвременни PHP приложения се състоят предимно от пакети, които инсталира Composer, управлението на пакети за PHP. Как работи то, обяснява страницата Composer: управление на пакети за PHP. Файлът composer.lock фиксира кои версии точно са инсталирани. Според документацията на Composer composer install използва именно тези версии. Така може да се възстанови състоянието при доставка:
# На чиста система, не на засегнатия сървър
mkdir /tmp/referenz && cd /tmp/referenz
cp /pfad/zur/kopie/composer.json /pfad/zur/kopie/composer.lock .
composer install --no-scripts --no-plugins --no-autoloader
# Изброяване на разликите в папката vendor
diff -rq /tmp/referenz/vendor /pfad/zur/kopie/vendor
Опциите --no-scripts и --no-plugins предотвратяват изпълнението на скриптове от пакетите при възстановяването. Ако продукцията е инсталирана с --no-dev, използвайте тази опция и при възстановяването, иначе пакетите за разработка ще се появят като разлика. Обърнете внимание на два вида резултат: файлове, които се различават, и файлове, които съществуват само на сървъра. Втората група често е по-интересната. Как допълнително да проверите инсталираните пакети за известни уязвимости, описва ръководството Проверка на зависимостите на Composer за уязвимости.
Сравнете и операционната система
Ако нападателят е имал root права, той може да е заменил и системни програми. Управлението на пакетите носи собствено сравнение:
# Debian, Ubuntu: файлове, чието съдържание се различава от пакета
sudo dpkg --verify
# RHEL, AlmaLinux, Rocky: проверка на всички пакети
sudo rpm -Va
Цифра 5 на третата позиция от изхода означава, че съдържанието на файла е променено. Според ръководството на dpkg сравнението на съдържанието е там понастоящем единствената действаща проверка. Променените конфигурационни файлове са нормални и са маркирани с c. Променена програма в /usr/bin обаче е сериозен тревожен знак. Имайте предвид: нападател с root права може да манипулира и базата данни на пакетите. При съмнение за root достъп преинсталирането е по-надеждно от всяко сравнение.
Система за контрол на версиите за кода на приложението превръща бъдещите сравнения в работа за секунди. git status показва тогава всяко отклонение от одобреното състояние.
Оценка на отклоненията и познаване на границите
Не всяко отклонение е атака. Някои агенции по-рано са променяли основни файлове директно, вместо да използват разширения. Езикови пакети, краища на редове след пренос по FTP или впоследствие приложени корекции също създават разлики. Решаващо е дали някой може да обясни промяната.
Преминете през всяко отклонение поотделно и запишете резултата: известно и документирано, безобидно обяснимо или неясно. Неясните файлове отваряйте само като текст върху копие и ги заменяйте от чистия източник. При файлове, които съществуват само на сървъра, въпросът е по-прост: който не ги познава, трябва да ги запази и да ги премахне, след като съдържанието им е проверено.
Качените файлове, конфигурационни файлове като wp-config.php или .env, собствените промени и кешовете нямат оригинал. Те трябва да се проверяват целенасочено, както и базата данни, cron задачите, потребителските акаунти и SSH ключовете. Чисто сравнение затова е важен градивен елемент, но не оправдателна присъда за целия сървър.
Как помага PHP SOS конкретно?
- Установяваме инсталираните версии и изграждаме чиста референция от официални източници.
- Сравняваме ядро, разширения, Composer пакети и системни програми и оценяваме всяко отклонение.
- Проверяваме целенасочено областите без оригинал и заменяме променените файлове от чист източник в рамките на премахването на зловреден софтуер.
- По желание въвеждаме версионно състояние, спрямо което да се провеждат бъдещите проверки.
Често задавани въпроси
Как да проверя дали основните файлове на WordPress са променени?
С WP-CLI и командата wp core verify-checksums. Тя сравнява файловете с контролните суми, които WordPress.org публикува за инсталираната версия. С опцията --include-root WP-CLI допълнително предупреждава за файлове в главната директория, които не принадлежат на WordPress.
Какво да направя при CMS без вградена функция за проверка?
Изтегляте точно същата версия от официалния източник на производителя и сравнявате двете директории с diff. При Composer проекти изграждате състоянието от composer.lock в празна директория и сравнявате папката vendor.
Открива ли сравнението и зловреден код в добавки и теми?
Само ако за тях има чист оригинал, например от официалната директория или от доставчика. Собствените промени, качените файлове и конфигурационните файлове нямат оригинал и трябва да се проверяват отделно.
Замества ли сравнението скенера за зловреден софтуер?
Допълва го. Сравнението открива всяка промяна в познати файлове, включително неизвестен зловреден код. То обаче не казва нищо за файлове без оригинал, за базата данни, cron задачите или достъпите.