Сайт стал работать медленнее, хотя посетителей не прибавилось. Процессор загружен даже по ночам, в почтовой очереди появляются неизвестные письма, а провайдер сообщает о подозрительных запросах с IP-адреса сервера. Первая мысль обычно простая: что-то сломалось. Но причина может оказаться серьезнее. Иногда сервер с виду продолжает работать нормально, хотя посторонний уже использует его для рассылки спама, атак на другие ресурсы или получения доступа к данным.
Подтвердить взлом по одному признаку удается редко. Высокую нагрузку может дать резервное копирование, ошибка в коде или наплыв ботов. Незнакомый файл порой появляется после обновления. Подозрения становятся обоснованными, когда сразу возникает несколько нетипичных изменений и понятного объяснения им нет.
Какие признаки могут указывать на взлом сервера
Сначала стоит сравнить текущее поведение системы с тем, как она работает обычно. Администратор примерно представляет, сколько ресурсов потребляет сайт, в какое время запускаются фоновые задачи и какой объем трафика проходит через сервер. Если этот привычный ритм резко изменился, нужна проверка.
Основные признаки подозрительной активности:
- процессор, оперативная память или диск постоянно загружены без понятной причины;
- появились неизвестные процессы, службы, пользователи или задания в планировщике;
- в журналах видны успешные входы с незнакомых IP-адресов либо в необычное время;
- файлы сайта или системные настройки менялись без участия администратора;
- сервер отправляет много писем, устанавливает сторонние соединения или создает необычный трафик;
- IP-адрес оказался в спам-базах либо поступила жалоба на атаки с вашего сервера.
Сам по себе ни один из этих пунктов еще не доказывает взлом. Но если сервер одновременно начал потреблять больше ресурсов, соединяться с неизвестными адресами и запускать незнакомый процесс, списывать все на обычный сбой уже не стоит.
Нагрузка выросла, хотя на сайте ничего не менялось
Самый заметный сигнал – сайт внезапно начинает тормозить. Страницы открываются дольше, панель управления отвечает с задержкой, процессор почти постоянно работает на пределе. Иногда так ведет себя скрытый майнер. В других случаях сервер подбирает пароли, сканирует сети или выполняет команды злоумышленника.
Для начала нужно выяснить, какой именно процесс забирает ресурсы. Знакомое название тоже ничего не гарантирует: вредоносную программу могут выдать за системную службу. Имеют значение путь к файлу, пользователь, от имени которого запущен процесс, время его появления и сетевые подключения.
Посмотреть стоит и на работу диска. Большое число операций записи иногда говорит о том, что программа создает временные файлы, собирает украденные данные в архив или снова записывает удаленный вредоносный код. Если нагрузка появилась сразу после обновления, импорта или запуска резервной копии, причина может быть обычной. В остальных случаях проверку лучше не откладывать.
В системе появились неизвестные входы
Журналы авторизации нередко рассказывают больше, чем общий график нагрузки. Насторожить должны успешные входы с адресов, которыми администраторы не пользуются, подключения глубокой ночью или авторизация после сотен неудачных попыток.
Получив доступ, злоумышленник не обязательно продолжит пользоваться украденным паролем. В Linux он может добавить свой SSH-ключ, создать отдельного пользователя или выдать ему право выполнять команды администратора. В Windows Server стоит проверить участников группы администраторов, входы через удаленный рабочий стол, недавно появившиеся службы и изменения политик безопасности.
Поэтому одной смены пароля хватает не всегда. Если в системе осталась чужая учетная запись, ключ или скрытая служба, доступ быстро появится снова.
Файлы изменились без вашего участия
После взлома сайта вредоносный код часто прячется среди обычных файлов CMS. У файла может быть неприметное название, он может находиться в каталоге загрузок или выглядеть как часть плагина. Сам сайт при этом внешне работает по-прежнему.
Последствия становятся заметны позже. Посетителей перебрасывает на посторонние страницы, в поиске появляются чужие материалы, браузер предупреждает об опасном ресурсе. Иногда вредоносный код запускается только для пользователей из отдельных стран или с мобильных устройств. Владелец сайта за своим компьютером ничего необычного не видит.
Проверить нужно файлы, которые в последнее время не должны были меняться, и каталоги, куда разрешена запись. Если подозрительный файл после удаления появляется снова, значит, где-то остался процесс, задание в планировщике или другой скрипт, который его восстанавливает.
О проблеме сообщил провайдер или почтовый сервис
Иногда о взломе узнают не из панели мониторинга. Хостинг-провайдер может заметить сканирование чужих портов, попытки подбора паролей или аномальное количество исходящих соединений. Почтовый сервис ограничивает отправку, а IP-адрес сервера оказывается в списках спамеров.
Не стоит считать такое сообщение ошибкой только потому, что сайт все еще открывается. Злоумышленнику часто нет смысла полностью его ломать. Гораздо выгоднее как можно дольше незаметно пользоваться ресурсами сервера.
Причиной может быть не полный доступ к операционной системе, а один зараженный сайт, уязвимый плагин или украденный пароль от почтового ящика. Но даже такая локальная проблема способна перейти в серьезный взлом, если вредоносный код получит дополнительные права.
Что делать при подозрении на взлом
Не нужно сразу беспорядочно удалять файлы и перезагружать сервер. Вместе с ними могут исчезнуть журналы, активные соединения и другие следы, по которым можно было бы понять, как произошло проникновение. Сначала желательно ограничить внешний доступ, сохранить логи и зафиксировать текущее состояние системы.
После этого проверяют активные процессы, пользователей, ключи, сетевые соединения, задания в планировщике и последние изменения файлов. Пароли следует менять с безопасного устройства. Речь не только о доступе к серверу, но и о панели управления, CMS, базе данных, почте и остальных связанных сервисах.
Найти и удалить один зараженный файл недостаточно. Нужно закрыть уязвимость, через которую он оказался на сервере, проверить другие сайты и убедиться, что скрытых способов доступа больше нет. Иногда надежнее развернуть чистую систему и вернуть проверенные данные из резервной копии, чем очищать сервер вручную.
Если собственного опыта для такого анализа не хватает, лучше обратиться к системному администратору или специалисту по кибербезопасности. Он поможет выяснить, каким образом посторонний код попал в систему, остались ли скрытые каналы доступа и какие данные могли оказаться скомпрометированы. Резервные копии стоит держать отдельно от основного сервера и время от времени проверять восстановление. От взлома они не защищают, но позволяют вернуть сайт в чистое состояние, если заражение или повреждение обнаружили слишком поздно.
Добавить комментарий