Как проверить сайт на вирусы через SSH: простые Linux-команды для поиска опасного кода

Поиск вредоносного кода при помощи SSH

Сайт может продолжать открываться, принимать заказы и выглядеть совершенно нормально, даже если внутри него уже находится вредоносный код.

После взлома злоумышленники далеко не всегда уничтожают страницы или сразу блокируют работу проекта. Гораздо выгоднее действовать незаметно:

• рассылать спам от имени сайта;
• перенаправлять посетителей на мошеннические страницы;
• размещать скрытые ссылки;
• воровать пароли и данные клиентов;
• создавать новых администраторов;
• использовать сервер для атак на другие ресурсы;
• оставлять скрытый доступ на будущее.

Владелец сайта может месяцами не подозревать о проблеме. Первые признаки часто появляются только тогда, когда поисковая система показывает предупреждение о заражении, хостинг блокирует аккаунт или посетители начинают жаловаться на странные переадресации.

В этой статье разберем, как самостоятельно выполнить первичную проверку сайта через SSH и найти наиболее подозрительные фрагменты кода с помощью стандартных команд Linux.

Что такое SSH и кому подойдет этот способ

SSH — это способ подключиться к серверу через командную строку.

Вместо привычного файлового менеджера вы видите терминал, в который можно вводить команды. С их помощью удобно искать файлы, проверять даты изменений и находить определенные конструкции сразу во всех каталогах сайта.

Доступ по SSH обычно предоставляется:

• на VPS и выделенных серверах;
• на большинстве современных хостингов;
• в некоторых тарифах виртуального хостинга;
• в панелях управления сервером.

Данные для входа можно найти в личном кабинете хостинга. Обычно потребуются:

• адрес сервера;
• имя пользователя;
• пароль или SSH-ключ;
• номер порта, чаще всего 22.

Подключиться из Windows можно через PowerShell, Windows Terminal или программу PuTTY.

Пример подключения:

ssh username@example.com

Вместо username указывается имя пользователя, а вместо example.com — адрес сервера или его IP.

После подключения необходимо перейти в каталог сайта.

Например:

cd /var/www/example.com

На виртуальном хостинге путь может выглядеть иначе:

cd ~/www/example.com

или:

cd ~/public_html

Узнать текущий каталог можно командой:

pwd

А посмотреть находящиеся в нем файлы:

ls -la

Важное предупреждение перед проверкой

Команды из статьи предназначены прежде всего для поиска.

Они не удаляют и не изменяют файлы. Это важно, потому что автоматическое удаление всего «подозрительного» может полностью сломать сайт.

Например, функции base64_decode, exec или curl_exec могут использоваться не только вирусами, но и обычными компонентами сайта.

Поэтому найденный фрагмент нельзя удалять только из-за того, что команда отметила его как подозрительный.

Перед любыми изменениями желательно:

1. Создать резервную копию файлов сайта.
2. Сделать дамп базы данных.
3. Сохранить найденный файл отдельно.
4. Проверить его назначение и контекст.
5. Только после этого принимать решение об удалении или восстановлении.

С чего начать проверку

Предположим, что сайт находится в каталоге:

/var/www/example.com

В командах ниже его нужно заменить на реальный путь к своему сайту.

На некоторых хостингах поиск по большому каталогу может занимать заметное время. Если на аккаунте размещено несколько сайтов, лучше проверять каждый проект отдельно.

1. Ищем недавно измененные файлы

Если проблемы с сайтом появились недавно, первым делом стоит посмотреть, какие файлы изменялись за последние несколько дней.

Команда для поиска файлов, измененных за последние сутки:

find /var/www/example.com -type f -mtime -1

За последние семь дней:

find /var/www/example.com -type f -mtime -7

Можно ограничить поиск только PHP-файлами:

find /var/www/example.com -type f -name "*.php" -mtime -7

Почему это полезно?

Предположим, сайт не обновлялся несколько месяцев, но в системных папках внезапно появились PHP-файлы с сегодняшней датой. Это серьезный повод их проверить.

Особое внимание стоит обратить на файлы:

• в каталогах загрузки изображений;
• внутри папок кэша;
• в каталогах временных файлов;
• в старых резервных копиях;
• в папках, где обычно не должно быть PHP-кода.

Однако дата изменения не является доказательством взлома. Файл мог измениться после штатного обновления CMS, темы или плагина.

2. Проверяем PHP-файлы в каталогах изображений

Одна из распространенных схем — разместить вредоносный PHP-файл в папке, предназначенной для фотографий и документов.

Например, в WordPress это может быть каталог:

wp-content/uploads

Обычно там должны находиться изображения, архивы, PDF и другие загруженные материалы. PHP-файл в такой папке требует внимательной проверки.

Команда для WordPress:

find /var/www/example.com/wp-content/uploads -type f -name "*.php"

Для произвольного сайта можно проверить каталоги с характерными названиями:

find /var/www/example.com -type f -path "*/uploads/*" -name "*.php"

Дополнительно:

find /var/www/example.com -type f -path "*/images/*" -name "*.php"

find /var/www/example.com -type f -path "*/cache/*" -name "*.php"

find /var/www/example.com -type f -path "*/tmp/*" -name "*.php"

Это не означает, что каждый найденный файл заражен. Некоторые системы действительно хранят служебные PHP-файлы в кэше. Но такие результаты нужно проверить в первую очередь.

3. Ищем функцию eval

Функция eval() позволяет выполнить текстовую строку как PHP-код.

Это очень мощный инструмент, но в обычной разработке он требуется редко. Злоумышленники часто используют его для запуска предварительно зашифрованного или закодированного фрагмента.

Команда:

grep -RIn --include="*.php" "eval[[:space:]]*(" /var/www/example.com

Параметры означают:

• -R — искать во всех вложенных каталогах;
• -I — пропускать бинарные файлы;
• -n — показывать номер строки;
• --include="*.php" — проверять только PHP-файлы.

Особенно подозрительно выглядит сочетание:

eval(base64_decode($code));

или:

eval(gzinflate(base64_decode($data)));

Здесь код сначала декодируется или распаковывается, а затем выполняется.

Но наличие eval() еще не доказывает заражение. Функция может находиться в старой библиотеке, системе шаблонов или отладочном инструменте.

4. Ищем закодированные фрагменты base64

Функция base64_decode() превращает строку из формата Base64 обратно в исходные данные.

Base64 используется в обычных проектах, например:

• при работе с API;
• для обработки изображений;
• в почтовых вложениях;
• при хранении токенов;
• при передаче бинарных данных.

Но вредоносный код часто кодируют именно таким способом, чтобы его было сложнее заметить глазами.

Команда:

grep -RIn --include="*.php" "base64_decode[[:space:]]*(" /var/www/example.com

Сам по себе результат не означает, что файл опасен.

Обратить особое внимание нужно, если рядом находятся:

eval(...)

assert(...)

gzinflate(...)

gzuncompress(...)

str_rot13(...)

Также подозрительно, если внутри файла находится одна огромная нечитаемая строка из букв, цифр и символов.

5. Ищем распаковку скрытого кода

Для сокрытия содержимого злоумышленники могут несколько раз кодировать и сжимать вредоносный фрагмент.

Найти функции распаковки можно так:

grep -RInE --include="*.php" "gzinflate|gzuncompress|gzdecode" /var/www/example.com

Особенно опасны многоступенчатые конструкции:

eval(gzinflate(base64_decode("длинная_строка")));

Человеку сложно сразу понять, что находится внутри такой строки. Именно на это и рассчитывает автор вредоносного кода.

При этом функции сжатия могут законно использоваться библиотеками и системами кэширования. Поэтому снова необходимо смотреть не только на название функции, но и на весь фрагмент.

6. Ищем команды, способные запускать программы на сервере

PHP может запускать системные команды Linux. Для некоторых проектов это нормальная функция.

Например, сайт может:

• обрабатывать видео через FFmpeg;
• создавать архивы;
• запускать фоновые задачи;
• работать с Git;
• вызывать внешние утилиты.

Но эти же возможности часто используются веб-шеллами.

Поиск наиболее опасных функций:

grep -RInE --include="*.php" "shell_exec[[:space:]]*\(|passthru[[:space:]]*\(|proc_open[[:space:]]*\(|popen[[:space:]]*\(" /var/www/example.com

Отдельно можно искать system():

grep -RIn --include="*.php" "system[[:space:]]*(" /var/www/example.com

И exec():

grep -RIn --include="*.php" "exec[[:space:]]*(" /var/www/example.com

С последними двумя функциями возможны ложные совпадения. Например, слово system может находиться в названии пользовательской функции, класса или комментария.

Главный вопрос — откуда берется команда.

Особенно опасна конструкция, похожая на эту:

system($_GET['cmd']);

В таком случае посетитель может передать серверную команду прямо через адресную строку.

Например:

example.com/file.php?cmd=...

Это уже характерный признак веб-шелла.

7. Ищем выполнение данных из запросов посетителя

Во многих вредоносных файлах команды поступают через:

• $_GET;
• $_POST;
• $_REQUEST;
• cookies;
• HTTP-заголовки.

Попробуем найти строки, где пользовательские данные находятся рядом с опасными функциями:

grep -RInE --include="*.php" "(eval|system|exec|shell_exec|passthru).*\$_(GET|POST|REQUEST|COOKIE)" /var/www/example.com

Однако вредоносный код может быть записан и в обратном порядке, разбит на несколько строк или дополнительно скрыт.

Поэтому полезен и более широкий поиск:

grep -RInE --include="*.php" "\$_(GET|POST|REQUEST|COOKIE)" /var/www/example.com

Эта команда выдаст очень много результатов на любом современном сайте. Ее задача — не найти вирус автоматически, а помочь проверить конкретный подозрительный файл.

8. Ищем необычно длинные строки

Обфусцированный код часто представляет собой одну длинную строку, которую невозможно прочитать без декодирования.

Найти строки длиннее 1000 символов:

grep -RInE --include="*.php" ".{1000,}" /var/www/example.com

Для JavaScript:

grep -RInE --include="*.js" ".{2000,}" /var/www/example.com

У этого метода много ложных срабатываний.

Длинные строки встречаются:

• в минифицированных JavaScript-файлах;
• в скомпилированных библиотеках;
• в картах исходного кода;
• в SVG;
• в данных шаблонов;
• в легальных лицензированных продуктах с защищенным кодом.

Поэтому в первую очередь стоит проверять длинные строки в небольших неизвестных PHP-файлах, особенно если они были созданы недавно.

9. Ищем подозрительные имена файлов

Старые веб-шеллы часто назывались достаточно очевидно:

• shell.php;
• cmd.php;
• backdoor.php;
• mailer.php;
• upload.php;
• wso.php;
• c99.php;
• r57.php.

Найти такие названия можно командой:

find /var/www/example.com -type f | grep -Ei "/(shell|backdoor|cmd|mailer|wso|c99|r57|bypass|uploader)[^/]*\.php$"

Но современные вредоносные файлы редко называются настолько явно. Они могут маскироваться под системные компоненты:

class-wp-cache.php
functions-old.php
config_new.php
wp-system.php
index1.php

Иногда имя отличается от настоящего системного файла всего одной буквой.

Например:

wp-login.php
wp-logln.php

Во втором варианте вместо буквы i может использоваться строчная l.

Поэтому имя файла является лишь дополнительным признаком.

10. Ищем PHP-код внутри файлов с необычными расширениями

Злоумышленник может спрятать PHP-код в файле, который выглядит как изображение или текстовый документ.

Например:

photo.jpg
cache.dat
data.txt
avatar.png

Проверить наличие открывающего PHP-тега можно так:

grep -RIl "<?php" /var/www/example.com

Команда покажет все файлы, содержащие <?php, независимо от расширения.

Чтобы исключить обычные PHP-файлы:

grep -RIl "<?php" /var/www/example.com | grep -Ev "\.(php|phtml|php5|inc)$"

Если PHP-код обнаружен внутри файла .jpg, .png, .ico или .txt, это требует проверки.

Но возможны исключения. Например, резервная копия кода могла быть сохранена с расширением .txt.

11. Проверяем файлы с правами 777

Права 777 разрешают чтение, изменение и выполнение файла всем пользователям системы.

В некоторых старых инструкциях владельцам сайтов советовали назначать такие права каталогам загрузки. Это небезопасная практика.

Найти объекты с правами 777:

find /var/www/example.com -perm 0777 -print

Проверить только файлы:

find /var/www/example.com -type f -perm 0777 -print

Только каталоги:

find /var/www/example.com -type d -perm 0777 -print

Наличие таких прав не доказывает взлом, но увеличивает риск несанкционированной записи.

Не следует массово менять права без понимания структуры проекта. Неправильные разрешения могут нарушить загрузку файлов, обновления, кэширование и работу сайта.

12. Ищем файлы, владелец которых отличается от остальных

После ручной загрузки, работы вредоносного процесса или некорректного запуска скриптов часть файлов может получить необычного владельца.

Посмотреть владельцев файлов:

find /var/www/example.com -maxdepth 2 -type f -printf "%u %g %p\n" | head -100

Получить сводку по владельцам:

find /var/www/example.com -type f -printf "%u:%g\n" | sort | uniq -c | sort -nr

Если почти все файлы принадлежат одному пользователю, а несколько — другому, нужно выяснить причину.

На виртуальном хостинге эта команда может быть недоступна или выводить ограниченную информацию.

13. Ищем скрытые файлы

В Linux файлы, имя которых начинается с точки, считаются скрытыми.

Найти их в каталоге сайта:

find /var/www/example.com -type f -name ".*"

Скрытые файлы могут быть совершенно нормальными:

• .htaccess;
• .env;
• .gitignore;
• .user.ini;
• .well-known;
• файлы подтверждения домена.

Но неизвестные скрытые PHP-файлы или странные файлы в папках загрузок требуют проверки.

Например:

.cache.php
.system.php
.update.php

14. Проверяем файл .htaccess

После взлома злоумышленники могут изменить .htaccess, чтобы:

• перенаправлять посетителей;
• запускать PHP в каталогах изображений;
• скрывать вредоносный файл;
• показывать разный контент людям и поисковым роботам;
• запрещать владельцу открывать определенные файлы.

Найти все .htaccess:

find /var/www/example.com -name ".htaccess" -type f

Просмотреть основной файл:

cat /var/www/example.com/.htaccess

Если он большой, удобнее использовать:

less /var/www/example.com/.htaccess

Выход из режима less выполняется клавишей q.

Стоит обратить внимание на неизвестные:

• RewriteRule;
• RewriteCond;
• перенаправления на чужие домены;
• обработчики PHP для файлов изображений;
• правила, разрешающие выполнение необычных расширений;
• конструкции, добавленные одной длинной строкой.

Не удаляйте правила только потому, что они выглядят сложно. CMS и системы кэширования могут создавать достаточно объемные конфигурации.

15. Ищем внешние ссылки в PHP-коде

Вредоносный скрипт может загружать команды или дополнительный код с внешнего сервера.

Поиск ссылок:

grep -RInE --include="*.php" "https?://" /var/www/example.com

На современном сайте результатов может быть много: API, платежные системы, CDN, документация, обновления и интеграции.

Следует проверить неизвестные домены, особенно если ссылка находится рядом с:

• file_get_contents;
• curl_exec;
• include;
• require;
• eval;
• записью данных в файл.

Например, подозрительно выглядит логика, которая загружает содержимое с неизвестного домена, сохраняет его как PHP-файл и затем запускает.

16. Ищем запись новых PHP-файлов

Некоторые вредоносные программы восстанавливают себя после удаления. Владелец удаляет зараженный файл, но через несколько минут он появляется снова.

Причина может находиться в другом скрипте, который записывает вредоносный код обратно.

Поиск функций записи:

grep -RInE --include="*.php" "file_put_contents[[:space:]]*\(|fwrite[[:space:]]*\(|fopen[[:space:]]*\(" /var/www/example.com

Эти функции широко используются легальными приложениями:

• для логов;
• кэша;
• экспорта данных;
• генерации конфигураций;
• создания изображений;
• работы с временными файлами.

Проверять нужно, какие именно данные и в какой файл записываются.

Особенно подозрительно, если код формирует файл с расширением .php из данных, полученных от посетителя или внешнего сервера.

17. Ищем признаки кражи паролей и отправки данных

Вредоносный код может отправлять собранные данные на внешний сервер или электронную почту.

Поиск почтовой функции:

grep -RIn --include="*.php" "mail[[:space:]]*(" /var/www/example.com

Поиск сетевых запросов:

grep -RInE --include="*.php" "curl_exec|curl_init|fsockopen|stream_socket_client" /var/www/example.com

Но практически любой интернет-магазин, форма обратной связи или API-интеграция использует похожие функции.

Опасность определяется контекстом:

• какие данные собираются;
• куда они отправляются;
• известен ли домен;
• почему код скрыт;
• соответствует ли файл установленному модулю.

18. Комплексная команда для быстрого поиска

Для первичной проверки можно выполнить одну команду, которая ищет несколько опасных конструкций одновременно:

grep -RInE --include="*.php" \
"eval[[:space:]]*\(|assert[[:space:]]*\(|base64_decode[[:space:]]*\(|gzinflate[[:space:]]*\(|gzuncompress[[:space:]]*\(|shell_exec[[:space:]]*\(|system[[:space:]]*\(|exec[[:space:]]*\(|passthru[[:space:]]*\(|proc_open[[:space:]]*\(|popen[[:space:]]*\(|str_rot13[[:space:]]*\(" \
/var/www/example.com

Результат может оказаться очень большим.

Это нормально. Команда ищет не только вирусы, но и любые места, где используются потенциально опасные возможности PHP.

Лучше сохранить результаты в файл:

grep -RInE --include="*.php" \
"eval[[:space:]]*\(|assert[[:space:]]*\(|base64_decode[[:space:]]*\(|gzinflate[[:space:]]*\(|gzuncompress[[:space:]]*\(|shell_exec[[:space:]]*\(|system[[:space:]]*\(|exec[[:space:]]*\(|passthru[[:space:]]*\(|proc_open[[:space:]]*\(|popen[[:space:]]*\(|str_rot13[[:space:]]*\(" \
/var/www/example.com > suspicious-code.txt

После этого отчет можно открыть:

less suspicious-code.txt

Важно: файл отчета лучше сохранить за пределами публичного каталога сайта, чтобы посторонние не могли скачать его через браузер.

Как открыть найденный фрагмент кода

Допустим, команда показала:

/var/www/example.com/wp-content/cache/update.php:17

Это означает:

• найден файл update.php;
• подозрительная конструкция находится примерно на строке 17.

Посмотреть участок файла:

sed -n '1,50p' /var/www/example.com/wp-content/cache/update.php

Команда покажет строки с первой по пятидесятую.

Можно вывести область около найденной строки:

sed -n '10,30p' /var/www/example.com/wp-content/cache/update.php

Для просмотра всего файла:

less /var/www/example.com/wp-content/cache/update.php

Не запускайте неизвестный файл и не открывайте его адрес через браузер. Если это веб-шелл или загрузчик, обращение к нему может активировать вредоносную функцию.

Какие признаки особенно опасны

Отдельная функция редко дает однозначный ответ. Но сочетание нескольких признаков значительно увеличивает вероятность заражения.

Например:

• файл появился недавно;
• находится в папке изображений;
• имеет случайное или маскирующееся имя;
• содержит одну огромную строку;
• использует base64_decode;
• затем распаковывает данные через gzinflate;
• выполняет их через eval;
• принимает параметры из $_POST;
• скрывает ошибки через символ @.

Такой файл необходимо немедленно изолировать и подробно исследовать.

Пример крайне подозрительной конструкции:

<?php
@eval(gzinflate(base64_decode($_POST['data'])));

А вот одиночное использование:

$image = base64_decode($apiResponse);

может быть совершенно нормальной частью интеграции.

Именно поэтому обычный поиск по словам не заменяет полноценный анализ.

Что делать, если подозрительный файл найден

Не стоит сразу нажимать Delete.

Безопаснее действовать поэтапно.

1. Создайте копию

cp suspicious.php suspicious.php.backup

Еще лучше сохранить копию за пределами каталога сайта.

2. Ограничьте доступ

Файл можно временно переименовать:

mv suspicious.php suspicious.php.disabled

Но нужно понимать, что это может нарушить работу сайта.

3. Сравните файл с оригиналом

Если это файл CMS, плагина или темы, скачайте официальный дистрибутив той же версии и сравните содержимое.

Для сравнения:

diff suspicious.php original.php

4. Проверьте остальные файлы

Удаление одного веб-шелла не означает, что сайт очищен. Обычно злоумышленник оставляет несколько точек доступа.

5. Смените пароли

После подтвержденного взлома нужно заменить:

• пароль панели хостинга;
• пароль SSH;
• пароль FTP;
• пароли администраторов сайта;
• пароль базы данных;
• API-ключи;
• секретные ключи приложения.

6. Найдите причину проникновения

Если просто удалить вредоносный код, но не закрыть уязвимость, заражение повторится.

Причиной может быть:

• устаревший плагин;
• уязвимая тема;
• слабый пароль;
• украденный FTP-пароль;
• нулленый скрипт;
• открытая форма загрузки;
• неверные права доступа;
• зараженный компьютер администратора.

Почему ручной поиск не дает полной гарантии

SSH-команды полезны для первичной диагностики. Они помогают быстро заметить очевидные веб-шеллы, недавно созданные файлы и известные опасные конструкции.

Но у ручной проверки есть серьезные ограничения.

Вредоносный код может быть хорошо замаскирован

Вместо прямого вызова eval злоумышленник может собирать имя функции из нескольких частей:

$function = 'ev' . 'al';

Обычный поиск слова eval может не распознать такую логику.

Код может быть разбит между несколькими файлами

Один файл принимает данные, второй декодирует, третий выполняет. По отдельности каждый фрагмент может выглядеть относительно безобидно.

Опасная функция не всегда является вирусом

Команда может вывести тысячи совпадений из библиотек, CMS и установленных модулей. Просмотреть их вручную сложно.

Не все уязвимости похожи на вредоносный код

На сайте может не быть ни одного вируса, но оставаться опасные ошибки:

• SQL-инъекции;
• загрузка произвольных файлов;
• выполнение команд;
• подмена путей;
• раскрытие конфигурации;
• небезопасная обработка входных данных;
• уязвимые Composer-зависимости.

Обычный grep не всегда способен понять, как данные проходят через приложение и можно ли реально использовать найденную конструкцию.

Проверка быстро устаревает

Даже если сегодня сайт чист, вредоносный файл может появиться завтра. Для постоянного контроля команды придется запускать снова и снова.

Как автоматизировать поиск опасного кода

Для одного небольшого сайта ручная проверка может быть приемлемой. Но когда проект постоянно развивается, содержит тысячи файлов, сторонние библиотеки и регулярно обновляемые модули, анализ через SSH превращается в отдельную работу.

Нужно не просто искать слова eval или base64_decode, а учитывать:

• расположение файла;
• дату его появления;
• тип проекта;
• сочетание нескольких опасных функций;
• источник входных данных;
• возможность удаленного выполнения;
• известные сигнатуры вредоносного кода;
• изменения по сравнению с предыдущей версией;
• уязвимости установленных зависимостей;
• уровень реальной опасности.

Для решения этой задачи разрабатывается InspectorPro Security Shield — система автоматического контроля безопасности сайтов и серверов.

Она объединяет несколько направлений проверки.

Поиск вредоносного кода

Система анализирует файлы и ищет:

• веб-шеллы;
• бэкдоры;
• загрузчики;
• обфусцированный PHP-код;
• скрытые конструкции выполнения;
• подозрительные цепочки декодирования;
• неизвестные изменения;
• признаки внедрения кода в системные файлы.

Поиск опасных функций

InspectorPro Security Shield не просто показывает все упоминания exec или base64_decode, а помогает отделить потенциально опасные фрагменты от обычного кода.

Для каждого результата можно определить:

• файл;
• строку;
• найденную конструкцию;
• уровень риска;
• причину срабатывания;
• рекомендации по дальнейшей проверке.

Контроль целостности файлов

После первоначального сканирования система может отслеживать изменения:

• какие файлы были добавлены;
• какие изменились;
• какие исчезли;
• когда произошло изменение;
• было ли оно подтверждено владельцем.

Это особенно важно для сайтов, которые редко обновляются. Неожиданное изменение системного файла становится заметно практически сразу.

Проверка зависимостей

Даже чистый код может использовать библиотеку с известной уязвимостью.

InspectorPro Security Shield проверяет зависимости проекта и помогает находить компоненты, для которых уже опубликована информация об угрозах.

Проверки по расписанию

Вместо ручного подключения по SSH сканирование можно запускать автоматически.

Администратор получает отчет, а не десятки тысяч необработанных совпадений.

Обновляемые сигнатуры

Методы атак постоянно меняются. Поэтому система предусматривает обновление правил и сигнатур, чтобы новые способы маскировки кода можно было обнаруживать без ручного изменения команд на каждом сервере.

Кому может быть полезен InspectorPro Security Shield

Система ориентирована не только на специалистов по информационной безопасности.

Она может быть полезна:

• владельцам сайтов;
• веб-студиям;
• разработчикам;
• администраторам серверов;
• владельцам интернет-магазинов;
• компаниям, сопровождающим сайты клиентов;
• проектам, использующим собственный PHP-код;
• владельцам сайтов на популярных CMS.

Особенно актуален автоматический контроль для проектов, где хранятся пользовательские данные, принимаются заявки, проводятся платежи или работают личные кабинеты.

Ручная проверка или автоматическая защита?

SSH-команды из этой статьи стоит сохранить. Они полезны, когда нужно быстро проверить конкретный каталог, найти недавно измененный файл или разобраться в уже обнаруженном инциденте.

Но ручная проверка — это снимок состояния сайта в определенный момент.

Автоматический мониторинг позволяет видеть изменения постоянно.

Оптимальный подход выглядит так:

1. Периодически проверять сервер вручную.
2. Обновлять CMS, модули и зависимости.
3. Не устанавливать нулленые темы и скрипты.
4. Использовать сложные уникальные пароли.
5. Ограничивать права доступа к файлам.
6. Контролировать изменения автоматически.
7. Проверять не только вирусы, но и уязвимые участки кода.

Именно сочетание базовой серверной гигиены, ручной диагностики и автоматизированного анализа дает наиболее надежный результат.

Вывод

Проверить сайт на самые очевидные признаки заражения можно даже без дорогого программного обеспечения. Достаточно SSH-доступа и нескольких стандартных Linux-команд.

С их помощью можно найти:

• недавно измененные файлы;
• PHP-скрипты в папках изображений;
• вызовы системных команд;
• закодированные фрагменты;
• подозрительные права доступа;
• неизвестные изменения .htaccess;
• скрытые и замаскированные файлы.

Однако результаты такого поиска всегда требуют анализа. Опасная функция может оказаться частью нормальной библиотеки, а настоящий бэкдор — не содержать ни одного очевидного ключевого слова.

Поэтому ручные команды лучше использовать как инструмент первичной диагностики, а постоянный контроль доверить системе, которая умеет анализировать множество признаков одновременно.

InspectorPro Security Shield создается именно для такой задачи: автоматического поиска вредоносного кода, контроля файлов, обнаружения опасных конструкций, проверки зависимостей и регулярного мониторинга безопасности сайта.

Узнать подробнее о возможностях InspectorPro Security Shield и оставить заявку можно на официальном сайте InspectorPro.