Миф: у меня маленький сайт, я никому не интересен

MAATRIX

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

Что в этом мифе правда

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

Проблема в том, что из верной посылки «меня лично не будут ломать вручную» человек делает неверный вывод «значит, мой сервер в безопасности». Это две разные вещи, и разрыв между ними закрывается не человеком с клавиатурой, а полностью автоматизированным процессом, которому ваша личность, содержание сайта и известность бренда совершенно безразличны.

Как на самом деле находят серверы в интернете

Интернет с точки зрения атакующей инфраструктуры — это не набор сайтов с именами и репутацией, а плоское адресное пространство IPv4 (около 4,3 миллиарда адресов) и постепенно растущее пространство IPv6, которое непрерывно обходят сканеры. Инструменты вроде masscan или zmap спроектированы именно для этого — не для точечной разведки, а для прохода по диапазонам адресов целиком, с проверкой открытых портов и баннеров сервисов на каждом.

# Пример того, как выглядит массовое сканирование диапазона
# (демонстрационная команда, не запускайте на чужих сетях —
# это само по себе может расцениваться как подготовка к атаке)
masscan 0.0.0.0/0 -p22,80,443,3389,2375,6379 --rate 100000

По оценкам исследователей интернет-сканирования (проекты вроде Rapid7 Project Sonar, Shodan), современный высокопроизводительный сканер способен пройти всё пространство IPv4 по одному порту за часы, максимум за сутки — точная цифра зависит от канала, но порядок величины именно такой. Это не разовая акция, а постоянный фоновый процесс: одни и те же диапазоны обходятся снова и снова, потому что новые серверы появляются каждую минуту.

Практический вывод из этого простой и проверяемый: как только вы арендуете VPS и получаете белый IP-адрес, этот адрес уже находится в чьей-то очереди на проверку. Не потому, что кто-то узнал про ваш новый сайт — а потому что этот IP просто существует и отвечает на пакеты. Открыть journalctl -u sshd или /var/log/auth.log на свежесозданном сервере, где ещё нет ни одной страницы сайта, и увидеть там первые попытки подбора логина root в течение первого часа работы — рутинный опыт почти любого, кто арендовал VPS. Это разобрано подробнее в статье про чеклист безопасности нового сервера — там же список того, что стоит закрыть в первые минуты после получения доступа, до того как на сервер вообще попадёт контент.

Ваш сервер интересен не как сайт, а как вычислительный ресурс

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

• Майнинг криптовалюты. Скомпрометированный сервер получает фоновый процесс майнера (типично — модифицированный xmrig под Monero, потому что этот алгоритм эффективен на обычном CPU без GPU). Владелец аккаунта майнинга получает вычислительную мощность бесплатно, а платите за электричество и трафик вы — по счёту от хостинга или в виде постоянной нагрузки, которая делает сайт медленнее.
• Включение в ботнет для DDoS. Взломанный сервер становится одним из тысяч узлов, которые по команде C2-сервера (command and control) одновременно шлют трафик на цель атаки — обычно совершенно постороннюю компанию, о которой вы никогда не слышали. Ваш VPS в этой схеме — просто ещё один источник пакетов, один из множества, и его вклад незаметен на общем фоне, пока не начинают приходить жалобы от вашего же хостинг-провайдера.
• Рассылка спама. Скомпрометированный сервер с работающим почтовым сервисом или просто с возможностью выполнять код используется для массовой рассылки — это выгодно именно потому, что репутация вашего домена и IP ещё не в спам-списках, в отличие от инфраструктуры самого спамера. Реальная реконструкция такого случая с деталями по логам Postfix — в статье ботнет использовал сервер для рассылки.
• Промежуточный узел для сокрытия следов другой атаки. Ваш сервер становится звеном в цепочке прокси, через которую проходит трафик атаки на третью цель — если правоохранительные органы или служба безопасности пострадавшей компании начнут распутывать цепочку, первым в логах на другом конце обнаружится IP-адрес именно вашего маленького сервера, а не настоящего атакующего.
• Хостинг фишинговых страниц. На взломанном сервере разворачивается поддельная страница банка, почтового провайдера или платёжной системы — обычно в скрытой директории, недоступной по основному домену, но доступной по прямой ссылке, которую рассылают в фишинговых письмах. Для этого нужен просто работающий веб-сервер с возможностью залить файлы, а не сайт с какой-то конкретной аудиторией.

Общий знаменатель у всех пяти сценариев один: атакующему нужен работающий, доступный из интернета сервер с уязвимостью, и всё. Известность, посещаемость и содержание сайта на этом сервере не участвуют в решении атаковать вообще никак.

Конкретный пример: как маленький сайт стал частью ботнета незаметно для владельца

Показателен не гипотетический, а типовой, регулярно повторяющийся сценарий, уже разбиравшийся на этом блоге по реальным логам. В статье сервер взломали через забытый порт: реконструкция описан случай небольшого сайта на обычном VPS, где при первичной настройке остался открытым сервис, о котором просто забыли — не потому что сайт был кому-то интересен, а потому что автоматический сканер обнаружил уязвимую версию сервиса, и эксплуатация прошла по шаблону, применяемому к тысячам случайно найденных серверов подряд. Владелец не заметил компрометацию по контенту сайта — тот продолжал работать как обычно, — а узнал по косвенным признакам: возросшей нагрузке, странному исходящему трафику и письму от хостинга с жалобой на активность с его IP.

Похожий по механике, но другой по вектору случай — в статье ботнет использовал сервер для рассылки: компрометация произошла не через SSH и не через специально подобранную уязвимость конкретно этого сайта, а через устаревший, давно не обновлявшийся веб-скрипт, который сканер нашёл автоматически, проверяя одну и ту же сигнатуру на множестве сайтов сразу. В обоих случаях владелец верил именно в разбираемый миф — сайт маленький, зачем кому-то тратить время на взлом. Но время никто и не тратил: атака была полностью автоматической, единой для всех подходящих целей, и маленький сайт оказался в их числе просто потому, что технически подходил под критерии сканера, а не потому что был кому-то интересен как сайт.

Как выглядит автоматическая атака технически

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

1. Массовое сканирование диапазонов (masscan, zmap) находит IP-адреса с открытыми портами — чаще всего 22 (SSH), 80/443 (веб), 3389 (RDP), 2375 (незащищённый Docker API), 6379 (Redis без пароля), 23 (Telnet, классика для IoT-ботнетов вроде Mirai).
2. Отпечаток сервиса (banner grabbing) определяет версию ПО за портом — конкретную версию OpenSSH, WordPress с номером плагина в HTML-коде страницы, версию Redis по ответу на INFO.
3. Сопоставление с базой известных уязвимостей — если версия сервиса совпадает с чем-то из публичных баз CVE или Exploit-DB, для найденного IP автоматически запускается готовый эксплойт, без ручного анализа конкретной цели.
4. Закрепление в системе — установка cron-задачи, systemd-сервиса, модификация ~/.ssh/authorized_keys для сохранения доступа даже после смены пароля.
5. Монетизация — один из пяти сценариев, описанных выше, запускается автоматически по шаблону, зашитому в скрипт эксплуатации.

Ни на одном из этих пяти шагов нет момента, где кто-то смотрит на ваш сайт и решает: «о, интересная цель, стоит взломать». Решение принято заранее и относится к целому классу серверов — «любой сервер с такой-то версией такого-то сервиса», а не к вам лично. Список конкретных инструментов, которыми можно проверить собственный сервер на открытые уязвимости раньше, чем это сделает чужой сканер, разобран в статье сканирование уязвимостей сервера: инструменты.

Что реально защищает маленький сервер от автоматических атак

Хорошая новость в том, что раз атака автоматическая и шаблонная, защититься от подавляющего большинства таких попыток можно тоже шаблонно, без индивидуального анализа угроз — базовая гигиена закрывает почти весь объём фонового шума:

Практический минимум для нового сервера — то же самое, что рекомендуется для любого VPS независимо от масштаба проекта:

# Закрыть всё лишнее firewall'ом сразу после установки
sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw allow 80,443/tcp
sudo ufw enable

# Проверить, что нет случайно открытых наружу сервисов
sudo ss -tulpn | grep LISTEN

# Включить автообновления безопасности (Debian/Ubuntu)
sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

Отдельно стоит регулярно проверять сам сервер на признаки уже случившейся, но незамеченной компрометации — неожиданные процессы, нагружающие CPU без видимой причины, незнакомые cron-задачи, исходящие соединения на нетипичные порты. Как именно это делается и какие инструменты (rkhunter, chkrootkit, ручной аудит ps aux и crontab -l) стоит использовать — в статье как проверить сервер на майнер и вирусы. Если признаки компрометации уже найдены — порядок действий описан в статье взломали сервер: пошаговый план.

Почему миф живуч, несмотря на очевидность автоматизации

Интуитивно людям проще думать об атаке как о человеческом решении — кто-то целенаправленно выбрал вас целью — потому что так устроено большинство других видов риска в жизни: грабитель выбирает дом, конкурент выбирает вас как мишень для интриги. Модель «случайный автоматический процесс, которому вы безразличны как личность, но подходите как техническая цель» менее интуитивна, хотя именно она описывает подавляющее большинство инцидентов в интернете. Играет роль и эффект отсутствия обратной связи: пока сервер не взломан явно, владелец не видит доказательств, что сканеры вообще существуют и постоянно проверяют его IP — тишина в логах непроверенного сервера воспринимается как безопасность, а не как то, чем она обычно является: просто ещё не случившимся событием.

Стоит также разделить два разных мифа, которые люди иногда путают: миф «я никому не интересен» — про мотив атакующего, и миф «свой сервер безопаснее облака» — про инфраструктуру. Оба неверны примерно по одной и той же причине — предположение, что безопасность определяется субъективной значимостью или расположением сервера, а не тем, насколько хорошо закрыты конкретные технические уязвимости. Подробный разбор второго — в статье миф: свой сервер безопаснее облака.

Частые вопросы