Ваш сервер атакуют прямо сейчас

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

Я сам давно держал пару виртуалок для разных нужд — сайты, тестовые проекты, какие-то эксперименты с кодом. Всё шло своим чередом, казалось, под контролем.

За два года работы в технической поддержке облачного хостинга я видел множество взломов, помогал клиентам с восстановлением серверов. Видел всё: от примитивных майнеров до полностью стёртых проектов без бэкапов. Сейчас я работаю инженером технической поддержки в компании CleverData (входит в холдинг LANSOFT).

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

$ grep "Failed password" /var/log/auth.log | wc -l
53732

53 000 попыток проникновения. За пять дней.

Каждая такая строка — это неудачная попытка входа через SSH. Кто-то (или, скорее, что-то) пытался подобрать логины и пароли к серверу десятки тысяч раз. Автоматические боты, брутфорс-скрипты, сканеры — они начинают работать почти сразу после появления нового IP в интернете.

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

Меня это удивило. Я задумался: что, если копнуть глубже? Как быстро интернет-джунгли находят новую жертву? Поэтому я решил провести небольшой эксперимент: отследить динамику атак на только что развернутый сервер в реальном времени.

Для чистоты эксперимента я решил создать абсолютно новый, чистый VDS с нуля, не меняя стандартных настроек SSH, и отследить, как быстро и с какой интенсивностью начнутся атаки. Хотелось понять динамику — когда первый бот постучится на мой сервер? Через час? Через сутки? И как будет расти их число?

Первым делом я настроил реал-тайм мониторинг логов /var/log/auth.log — именно туда Linux записывает все попытки авторизации через SSH, включая неудачные. Простейший способ — использовать команду tail -f /var/log/auth.log, которая выводит новые записи в логах в реальном времени. Но я хотел большего — не просто смотреть, как логи мелькают, а анализировать их на лету. Поэтому я написал небольшой скрипт на Bash, который фильтровал строки с "Failed password" и подсвечивал ключевые детали: IP-адрес атакующего, страну, логин, который он пытался использовать, и время атаки. Для установления страны я установил пакет geoip-bin (sudo apt install geoip-bin) и использовал утилиту geoiplookup, которая сопоставляет IP-адреса с данными из базы GeoIP. Вот как выглядел мой простенький скрипт:

#!/bin/bash

tail -f /var/log/auth.log | grep --line-buffered "Failed password" | while read line; do
  ip=$(echo $line | grep -oP '\d+\.\d+\.\d+\.\d+')
  user=$(echo $line | grep -oP 'for \K[^ ]+')
  time=$(echo $line | cut -d' ' -f1-3)
  country=$(geoiplookup $ip | grep -oP 'GeoIP Country Edition: \K.*' || echo "Unknown")
  echo "[ALERT] $time | IP: $ip | Country: $country | Attempted user: $user"
done

и вот пошли первые попытки проникновения:

Эксперимент: сколько атак получает новый сервер

Первые 7 часов жизни сервера:

$ sudo grep "Failed password" /var/log/auth.log | wc -l
2847

Через сутки:

$ sudo grep "Failed password" /var/log/auth.log | wc -l
42799

Второй день:

$ sudo grep "Failed password" /var/log/auth.log | wc -l
55812

Третий день:

$ sudo grep "Failed password" /var/log/auth.log | wc -l
58204

За три дня работы на абсолютно новый, никому не известный сервер поступило почти 60 тысяч попыток несанкционированного доступа. Это не целенаправленные атаки — это автоматическое сканирование всего интернета ботнетами 24/7.

Любой созданный VDS уже начинают атаковать в первые минуты запуска, когда он становится доступным в сети, в среднем за неделю эта цифра может быть более 50 000 попыток проникновения, и это только по SSH.

Реальность, которую многие игнорируют

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

Владелец: "У меня же ничего важного нет! Кому нужен мой тестовый сервер?" Реальность: Злоумышленникам всё равно. Ваш сервер — это вычислительные мощности, канал в интернет, плацдарм для атак.

Самые частые последствия взлома:

Майнинг криптовалют — при взломе вашего VDS злоумышленник может установить скрытую программу для майнинга криптовалют, такую как XMRig. Она начнёт использовать ресурсы виртуального сервера (CPU, возможно RAM) на максимум, что приведёт к резкому падению производительности, росту нагрузки и, при почасовой тарификации, увеличению ваших расходов. Хостинг-провайдер может при этом не сразу заметить нелегальную активность, а вы — не сразу понять, почему сервер тормозит.

Ботнет — скомпрометированный VDS может быть подключён к ботнету и начать участвовать в DDoS-атаках по команде злоумышленника. Это значит, что ваш IP-адрес будет фиксироваться как источник вредоносного трафика, что приведёт к его блокировке на других сервисах и, возможно, к автоматическому отключению сервера хостингом за нарушение правил использования.

Спам-рассылка — если на VDS настроен или взломан почтовый сервис, его могут использовать для массовой рассылки спама или фишинговых писем. Это быстро приведёт к попаданию IP-адреса в DNSBL (чёрные списки спамеров), из-за чего легитимные письма от вас будут блокироваться. В случае серьёзного нарушения провайдер может приостановить обслуживание или потребовать объяснений.

Хранилище нелегального контента — взломанный VDS часто превращают в "склад" для хранения и распространения нелегального контента: пиратских фильмов, запрещённых материалов, украденных баз данных. Такой контент может распространяться через HTTP/FTP, торренты или через dark web. Владелец VDS несёт ответственность за то, что происходит на его сервере, и может столкнуться с жалобами от правообладателей, блокировками и даже юридическими претензиями.

Точка входа — если VDS связан с другими вашими проектами или внутренними системами (например, через VPN, SSH-доступ или общую базу данных), то при взломе он становится отправной точкой для дальнейшего проникновения. Хакер может использовать его для атаки на другие серверы, кражи данных, компрометации учётных записей или внедрения вредоносного ПО в вашу инфраструктуру.

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

Три уровня реальных историй

История первая: "Простой пароль"

Пароль "очень_лёгкий". Взломали менее чем за час после создания сервера. Владелец не подозревал, что его сервер майнит биткоины, пока не обнаружил 100% нагрузку на CPU.

История вторая: "Обновления — это для параноиков"

CMS Bitrix не обновлялась 2 года. Когда вышел эксплойт для известной уязвимости, сайты пострадали тысячами. Причём взлом происходил автоматически — боты сканировали весь интернет на предмет уязвимых установок.

История третья: "Доверяй, но проверяй"

Разработчик скачал Node.js с поддельного сайта вместо официального. В инсталлятор был встроен бэкдор. Месяцами на страницы сайта внедрялся вредоносный контент, пока поисковики не начали банить домен за сомнительное содержание страниц.

Мораль всех историй: безопасность — это не паранойя, а необходимость.

Защита уровня "Новичок": делаем основы правильно

Даже если вы только начинаете работать с VDS, простые шаги по настройке безопасности уже способны предотвратить большинство типичных угроз. Хакеры часто ищут лёгкие цели — серверы без паролей, с открытыми портами и устаревшими ОС, программами. Поэтому важно правильно выстроить базовую защиту: несложно, но эффективно. Разберём, какие минимальные меры нужно принять, чтобы ваш VDS не стал фермой для майнинга, участником ботнета или хранилищем нелегального контента.

1. Пароль как первая линия обороны

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

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

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

Вот простой способ сгенерировать его прямо из консоли:

# Генерируем надёжный пароль
openssl rand -base64 32

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

Какие требования к хорошему паролю?

• Минимум 20 символов — чем длиннее, тем сложнее взлом.

• Смешанные символы — заглавные и строчные буквы, цифры, спецсимволы.

• Никаких словарных слов — "password123" или "qwerty2024" — это подарок злоумышленнику.

• Никакой личной информации — дата рождения, имя питомца или улица из детства — это легко гуглится.

• Уникальность — никогда не используйте один и тот же пароль для разных серверов или сервисов. Один слив — и все двери открыты. Поверьте, на этот пункт многие забивают, а зря. Был случай, когда веб-мастером были установлены одинаковые логины и пароли на все базы данных. Это привело к тому, что все базы были потёрты. Если бы пароли были разные, вероятность потерять все данные была бы меньше.

2. Смена SSH-порта: простая, но эффективная мера

Самый простой способ отсеять 90% автоматических атак:

# Редактируем конфигурацию SSH
sudo nano /etc/ssh/sshd_config

# Меняем стандартный порт 22
Port 2244

# Перезапускаем сервис ssh
sudo systemctl restart ssh

Результат на практике: После смены порта SSH количество попыток проникновения на новом сервере упало с 58 000 до 2 757 за 4 дня — снижение в 20 раз!

Почему это работает? Большинство ботов сканируют только стандартные порты. Смена порта не обеспечивает криптографическую стойкость, но отсеивает 99% скрипт-кидди (в хакерской культуре название тех, кто пользуется скриптами или программами, разработанными другими).

3. Прощаемся с root-доступом

Root — это суперпользователь в Linux с полными правами. Именно его чаще всего атакуют: сканеры и боты из интернета непрерывно подбирают пароли к учётной записи root, ведь если взломать её — доступ ко всему серверу открыт. Несмотря на это, большинство начинающих пользователей не придают этому значению, продолжая использовать root-доступ по умолчанию. Часто это связано с удобством: "зашёл — и сразу администратор", не нужно переключаться между пользователями или использовать sudo.

Однако это — критическая уязвимость. Root — предсказуемое имя, и если к нему ещё и слабый пароль, сервер становится лёгкой добычей. Вот пример, что за первые минуты работы сервера, все боты пытаются получить доступ именно к root пользователю:

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

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

Как выбрать логин для SSH-пользователя

1. Не используйте "admin", "user", "test", "ubuntu", "guest", "root"

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

2. Избегайте слишком очевидных производных от имени

Если вас зовут Иван Петров, логины ivan, petrov, ipetrov, ivanp — это тоже легко угадывается.

3. Используйте необычное, но запоминающееся имя

Например, можно взять слово из двух частей — короткое и уникальное, не связанное напрямую с вашей личностью:

• blueoak

• firebird7

• arkstone

• orbitalx

• netmonk

Можно добавить числа или немного изменить написание: ark5tone, n3tmonk — главное, чтобы это не превращалось в головоломку для вас.

4. Избегайте специальных символов

Хотя они могут быть допустимы, это может вызывать неудобства в скриптах или автоматизации. Лучше ограничиться маленькими буквами, цифрами и, при желании, дефисом (-).

Действуем по шагам

Шаг 1: создаём нового пользователя

Создаём безопасного пользователя, например blueoak, и даём ему права администратора через группу sudo:

# Создание нового пользователя
sudo adduser blueoak

# Добавление его в группу sudo для выполнения команд от имени root
sudo usermod -aG sudo blueoak

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

Шаг 2: запрещаем root-доступ по SSH

Редактируем SSH-конфигурацию используя редактор nano, который установлен на большинстве дистрибутивов: sudo nano /etc/ssh/sshd_config 

Найдите и измените строку: PermitRootLogin no Если она была закомментирована (#), уберите символ #.

Шаг 3: Перезапускаем SSH

После изменения настроек примените их: sudo systemctl restart sshd Перед этим убедитесь, что вы можете подключиться к серверу под новым пользователем (blueoak) и использовать sudo, иначе рискуете потерять доступ к управлению сервером.

4. Файрвол: возводим стены против цифровой орды

UFW (Uncomplicated Firewall / несложный брандмауэр) — это не громоздкий бастион для матёрых сисадминов, а лёгкий и понятный инструмент, идеальный для таких кто хочет быстро укрепить сервер без погружения в дебри iptables. Начнём с чистого листа, чтобы превратить VDS в неприступную крепость.

Ввовдим следующие команды:

# Устанавливаем UFW
sudo apt update -y && sudo apt install ufw -y

# Настраиваем политики по умолчанию: закрываем все входящие, разрешаем исходящие
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Открываем только те порты, которые нужны для работы
sudo ufw allow 2244/tcp  # SSH на новом порту — я сменил 22 на 2244, чтобы снизить количество ботов
sudo ufw allow 80/tcp    # HTTP для сайтов,если есть
sudo ufw allow 443/tcp   # HTTPS для будущих защищённых соединений

# Активируем файрвол
sudo ufw enable

# Проверяем
sudo ufw status verbose

Каждая команда в этом скрипте — как очередной кирпич в цифровой крепости.

Защита уровня "Продвинутый": автоматизируем безопасность

1. Fail2Ban: умная защита от брутфорса

Одна из самых распространённых атак на серверы — брутфорс: злоумышленник многократно пытается подобрать пароль, перебирая разные варианты. Это может быть атака на SSH, FTP или другие сервисы. Если не ограничивать такие попытки, хакер может получить доступ к вашему серверу.

По-простому, один бот может практически бесконечно стучаться к вам на сервер, перебирать пароли, и если пароль слабый, в конце концов он сможет его подобрать. Но даже если подобрать пароль не удастся, такие бесконечные попытки создают нагрузку на сервер. Тут поможет либо смена порта ssh, либо Fail2Ban — специальная программа, которая автоматически мониторит логи сервера и выявляет подозрительную активность. Как только она замечает несколько подряд неудачных попыток входа с одного IP-адреса, Fail2Ban временно блокирует этот адрес, добавляя правило в файрвол (обычно iptables). Таким образом, потенциальный злоумышленник оказывается "заперт" и не может продолжать атаки.

Основные преимущества Fail2Ban:

• Автоматизация защиты — вам не нужно вручную следить за логами и блокировать IP.

• Гибкие настройки — можно задать количество попыток, временной интервал и длительность блокировки.

• Поддержка множества сервисов — Fail2Ban работает не только с SSH, но и с веб-серверами, почтовыми сервисами, FTP и др.

• Снижение нагрузки — уменьшается количество запросов от атакующих, что сохраняет ресурсы сервера.

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

# Установка
sudo apt install fail2ban -y

# Создаём локальную конфигурацию
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

Оптимальная конфигурация:

[DEFAULT]
# Время бана в секундах (1 час)
bantime = 3600
# Окно поиска нарушений (10 минут)
findtime = 600
# Максимальное количество попыток
maxretry = 3

[sshd]
enabled = true
port = 2244
filter = sshd
logpath = /var/log/auth.log

Запускаем и проверяем:

sudo systemctl enable fail2ban
sudo systemctl start fail2ban
sudo fail2ban-client status sshd

2. SSH-ключи вместо паролей

Пароли — самый распространённый способ аутентификации, но они уязвимы к подбору (брутфорсу) и атакам с перебором. Особенно если пароль простой или повторно используется на других сайтах. Поэтому использование SSH-ключей — значительно более безопасный и современный метод доступа к серверу.

Как это работает?

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

Шаг 1: генерируем ключи на локальной машине

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

ssh-keygen -t ed25519 -C "комментарий"

• -t ed25519 — указывает тип ключа, современный и безопасный алгоритм.

• -C — комментарий, чтобы проще было ориентироваться в ключах.

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

Шаг 2: копируем публичный ключ на сервер

Чтобы сервер «узнал» ваш публичный ключ и разрешил доступ, перенесите его на сервер командой:

ssh-copy-id -p 2244 user@your_server_ip

Здесь -p 2244 — пример нестандартного SSH-порта, замените на ваш, если он отличается.

Иногда команда ssh-copy-id может быть недоступна или не работает (например, в нестандартной среде или на некоторых системах). Тогда ключ можно добавить вручную.

Как это сделать?

Шаг 1: найдите ваш публичный ключ

По умолчанию публичный ключ хранится в файле:

/home/ваш_пользователь/.ssh/id_ed25519.pub
или
/home/ваш_пользователь/.ssh/id_rsa.pub

Шаг 2 Открываем файл и копируем ключ

nano /home/ваш_пользователь/.ssh/id_ed25519.pub

Скопируйте всю строку целиком (начинается с ssh-ed25519 или ssh-rsa).

Шаг 4: Создайте директорию .ssh и файл .ssh/authorized_keys

Подключитесь к серверу по паролю

ssh -p 2244 user@your_server_ip

# В консоли выполните
mkdir -p ~/.ssh
chmod 700 ~/.ssh

nano ~/.ssh/authorized_keys

Вставьте в файл скопированный публичный ключ (в одну строку), сохраните и закройте.

Шаг 5: отключаем вход по паролю

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

sudo nano /etc/ssh/sshd_config

В файле найдите и измените строки:

PasswordAuthentication no
PubkeyAuthentication yes

Это отключит вход по паролю и включит аутентификацию только по ключам.

Шаг 6: перезапускаем SSH-сервис

Чтобы применить изменения, выполните:

sudo systemctl restart ssh

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

3. Ограничение доступа по IP

Если у вас есть статический IP-адрес (то есть ваш домашний или офисный интернет всегда использует один и тот же внешний адрес), это даёт отличную возможность повысить безопасность сервера, ограничив доступ по SSH только с этого конкретного IP. Такая мера сильно снижает риски атак с посторонних адресов — например, автоматических брутфорс-атак или попыток проникновения из других регионов

Без ограничений по IP ваш сервер открыт для любого пользователя из интернета, что увеличивает вероятность взлома. Даже если используются SSH-ключи и сложные пароли, чем меньше потенциальных точек входа, тем лучше. Ограничение доступа по IP — надёжный способ сузить круг допустимых подключений.

Защита уровня "Эксперт": серьёзные технологии

1. VPN: невидимость сервера

Чтобы по-настоящему защитить свою крепость, нужно сделать её невидимой. Никаких открытых портов для внешнего мира, никаких следов, по которым боты могли бы найти сервер, просто увести сервер в тень, спрятав его за VPN. Теперь доступ к SSH будет только у тех, кто подключён к конкретной сети — как пропуск в тайное убежище, куда чужакам вход запрешён.

Для этого отлично подойдёт WireGuard— лёгкий, быстрый и современный VPN-протокол, который работает как туннель между клиентом и сервером. Никаких сложных настроек, никаких громоздких инструментов — только чистая, эффективная защита. Настроить можно самостоятельно.Шаг 4: Создайте директорию .ssh и файл .ssh/authorized_keys

Далее настроим SSH, чтобы он работал только через VPN:

1.В файле /etc/ssh/sshd_config на сервере укажите:

ListenAddress 10.0.0.1

Перезапустите SSH:

sudo systemctl restart ssh

2. Настройте файрвол на сервере:

# Разрешить WireGuard
sudo ufw allow 51820/udp  
# SSH только через VPN
sudo ufw allow from 10.0.0.0/24 to any port 22 (или ваш порт ssh)  
# Закрыть SSH для всех остальных
sudo ufw deny 22 (или ваш порт ssh)  
sudo ufw enable

Далее выполните подключение к VPN, после чего можно зайти на сервер.

2. Port Knocking: секретный стук

Port knocking — это метод защиты, при котором SSH-порт открывается только после отправки определённой последовательности TCP-пакетов ("стука") на заданные порты. Это усложняет обнаружение и доступ к SSH для злоумышленников.

Базовая настройка ufw:

# Устанавливаем политики: блокируем входящие, разрешаем исходящие соединения
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Разрешаем трафик по loopback-интерфейсу (127.0.0.1/::1)
# нужно для внутренних соединений между локальными приложениями
sudo ufw allow in on lo

# Запрещаем входящие соединения на порт 2244/TCP
sudo ufw deny 2244/tcp

# Включаем ufw и проверяем статус
sudo ufw enable
sudo ufw status verbose

# Установим knockd
sudo apt update -y
sudo apt install knockd -y

# Изменим конфигурацию на ту, что ниже
sudo nano /etc/knockd.conf

[options]
    use_syslog

[openSSH]
  sequence    = 7000,8000,9000
  seq_timeout = 5
  tcpflags    = syn
  start_command = /bin/bash -c "ufw allow from %IP% to any port 2244 proto tcp"

[closeSSH]
  sequence    = 9000,8000,7000
  seq_timeout = 5
  tcpflags    = syn
  start_command = /bin/bash -c "ufw delete allow from %IP% to any port 2244 proto tcp"

• sequence: Последовательность портов для "стука" (7000, 8000, 9000 для открытия, 9000, 8000, 7000 для закрытия).

• seq_timeout: Время в секундах, в течение которого нужно завершить последовательность.

• tcpflags = syn: Проверяются только SYN-пакеты (начало TCP-соединения).

• command: Команды для добавления или удаления правила ufw,

Убедитесь, что knockd включён и слушает правильный интерфейс:

# Откройте файл конфигурации
sudo nano /etc/default/knockd:

# Укажите значение 1
START_KNOCKD=1

# Замените eth0 на ваш интерфейс
KNOCKD_OPTS="-i eth0"   

# Включаем автозапуск
sudo systemctl enable knockd
# Включаем службу
sudo systemctl start knockd

Использование с клиента:

# На клиенте устанавливаем knock:
sudo apt install knock -y 

Выполните «стук» и подключение:

# Стук по последовательности 7000,8000,9000
knock server_ip 7000 8000 9000

# Затем подключаемся по SSH на порт 2244
ssh -p 2244 user@server_ip

Чтобы закрыть порт ssh, выполните обратный стук:

knock server_ip 9000 8000 7000

3. Системы обнаружения вторжений

AIDE (Advanced Intrusion Detection Environment) — это система контроля целостности файлов, создающая криптографический «отпечаток» состояния системы. Она позволяет обнаруживать несанкционированные изменения: подмену или модификацию системных файлов, внедрение вредоносных программ и попытки скрытия следов атак.

sudo apt update -y
# Устанавливаем AIDE
sudo apt install aide -y

# Создаём начальную базу данных (снимок системы)
sudo aideinit

# Активируем рабочую базу
sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

Настройка правил мониторинга

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

sudo nano /etc/aide/aide.conf.d/system_paths.conf

Добавим каталоги, за которыми нужно следить:

/boot        Full    # ядро и загрузчик
/bin         Full    # базовые бинарники
/sbin        Full
/usr/bin     Full    # утилиты
/usr/sbin    Full
/etc         Full    # конфигурация
/root        Full    # root-скрипты, ключи

Далее добавим в конфиг группу правил Full:

# Открываем основной конфиг:
sudo nano /etc/aide/aide.conf

# И добавим в начало:

# Определение наборов правил
Normal = R+p+i+n+u+g+s+m+c+acl+selinux+xattrs+sha256
Full   = R+a+c+m+u+g+s+sha512

# Подключение нашего конфига
@@include /etc/aide/aide.conf.d/system_paths.conf

Проверка целостности

# Запуск проверки:
sudo aide --config=/etc/aide/aide.conf --check

Пример результатов:

Summary:
  Total number of entries:      87517
  Added entries:                2
  Removed entries:              1
  Changed entries:              4

---------------------------------------------------
Added entries:
---------------------------------------------------
f+++++++++++++++++: /root/aide/result.log
f+++++++++++++++++: /root/aide/test.txt
---------------------------------------------------
Removed entries:
---------------------------------------------------
f-----------------: /var/lib/aide/aide.db.new
---------------------------------------------------
Changed entries:
---------------------------------------------------
d = ....mc.. .. . : /root/aide
f = ...a....... . : /root/aide/result_1.log
f   .ug    . .. . : /var/lib/aide/aide.db
f >b... mc..H.. . : /var/log/sysstat/sa19

# Результаты проверки классифицируются по статусам:
# ADDED — появился новый файл
# (например, создан вручную или при установке ПО)
# CHANGED — файл был изменён
# (например, подмена бинарника или обновление конфига)
# REMOVED — файл, присутствующий в базе, был удалён
# (возможная попытка скрыть следы)

После легитимных изменений нужно обновить базу:

sudo aide --config=/etc/aide/aide.conf --update
sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

Мониторинг: знай, что происходит на твоём сервере

Ежедневный контроль

Создаём скрипт для мониторинга:

sudo nano /usr/local/bin/security-check.sh:

#!/bin/bash

# Проверяем количество неудачных попыток входа по SSH за последние 24 часа
echo "Failed SSH attempts in last 24h:"
sudo journalctl --since "24 hours ago" | grep "Failed password" | wc -l

# Показываем статус Fail2Ban для службы SSH (показывает, есть ли заблокированные IP и т.д.)
echo "Fail2Ban status:"
sudo fail2ban-client status sshd

# Отображаем активные сетевые соединения, фильтруем по порту 2244 (SSH)
echo "Active connections:"
ss -tuln | grep :2244

# Проверяем наличие доступных обновлений пакетов в системе
echo "Available updates:"
apt list --upgradable 2>/dev/null | wc -l

Далее выдаём скрипту права на выполнение:

sudo chmod +x /usr/local/bin/security-check.sh

Добавляем задачу в cron для ежедневного запуска:

sudo crontab -e
0 9 * * * /usr/local/bin/security-check.sh >> /var/log/security-check.log 2>&1

Все результаты выполнения скрипта будут сохраняться в файл /var/log/security-check.log, который создаётся автоматически при первом запуске.

Инструменты аудита безопасности

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

# Устанавливаем утилиту Lynis для аудита безопасности системы
sudo apt install lynis

# Запускаем полный аудит системы
sudo lynis audit system

# После завершения будет показан отчёт с цветовой индикацией:
# - Зелёный: настройки соответствуют рекомендациям
# - Жёлтый: есть возможности для улучшения
# - Красный: обнаружены потенциальные проблемы безопасности

# Просмотр списка выполненных тестов
sudo lynis show tests

# Детальная информация по конкретному тесту (например, SSH-7408)
sudo lynis show details SSH-7408

rkhunter — поиск руткитов:

# Сканирует систему на наличие известных руткитов и подозрительных изменений
# Устанавливаем rkhunter
sudo apt install rkhunter

# Обновляем базу сигнатур
sudo rkhunter --update

# Запускаем проверку системы
# --skip-keypress отключает паузы между этапами проверки
sudo rkhunter --check --skip-keypress

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

# Обновляем список пакетов
sudo apt update -y

# Устанавливаем chkrootkit
sudo apt install chkrootkit -y

# Запускаем проверку системы на наличие известных руткитов, троянов и скрытых процессов
sudo chkrootkit

Автоматизация: настраиваем один раз, работает всегда

Скрипт автоматической настройки безопасности

Скрипт автоматически: обновляет систему, устанавливает пакеты (UFW, Fail2Ban, rkhunter, lynis, unattended-upgrades), создаёт нового пользователя с правами sudo и доступом только по SSH-ключу, запрещает вход под root и по паролю, меняет порт SSH, настраивает файрволл для разрешения нужных портов (SSH, HTTP, HTTPS), активирует Fail2Ban и автоматические обновления безопасности, также проверяет корректность конфигурации SSH перед перезапуском.

Создаём скрипт:

 sudo nano /root/secure-server.sh

#!/bin/bash

set -e
echo "Автоматическая настройка безопасности VDS"

# Проверяем, что скрипт запущен от root
if [ "$EUID" -ne 0 ]; then
    echo "Запустите скрипт от root"
    exit 1
fi

# ПЕРЕМЕННЫЕ НАСТРОЕК
USERNAME="имя_пользователя"      # укажите имя пользователя
SSH_PORT=2244                    # порт SSH
SSH_KEY="ssh-ed25519 AAAAB3NzaC1yc2EAAAADAQABAAABAQ... _публичный_ключ ..."  
# Вставьте свой публичный SSH-ключ .pub, без лишних кавычек и переносов

# Обновляем систему
apt update && apt upgrade -y
# Устанавливаем необходимые пакеты
apt install -y ufw fail2ban rkhunter lynis unattended-upgrades sudo

# Создаём пользователя (если не существует)
if ! id "$USERNAME" &>/dev/null; then
    adduser --disabled-password --gecos "" "$USERNAME"
    usermod -aG sudo "$USERNAME"
    echo "Создан пользователь $USERNAME"

    # Добавляем SSH-ключ
    mkdir -p /home/$USERNAME/.ssh
    echo "$SSH_KEY" > /home/$USERNAME/.ssh/authorized_keys
    chown -R $USERNAME:$USERNAME /home/$USERNAME/.ssh
    chmod 700 /home/$USERNAME/.ssh
    chmod 600 /home/$USERNAME/.ssh/authorized_keys
    echo "Добавлен SSH-ключ для $USERNAME"
fi

# Делаем бэкап текущего конфига
cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup

# Настраиваем конфиг ssh
sed -i "/^#\?Port /c\Port $SSH_PORT" /etc/ssh/sshd_config
sed -i "/^#\?PermitRootLogin /c\PermitRootLogin no" /etc/ssh/sshd_config
sed -i "/^#\?PasswordAuthentication /c\PasswordAuthentication no" /etc/ssh/sshd_config

grep -q "^AllowUsers" /etc/ssh/sshd_config || echo "AllowUsers $USERNAME" >> /etc/ssh/sshd_config
sed -i "/^AllowUsers /c\AllowUsers $USERNAME" /etc/ssh/sshd_config

grep -q "^MaxAuthTries" /etc/ssh/sshd_config && \
  sed -i "s/^MaxAuthTries.*/MaxAuthTries 3/" /etc/ssh/sshd_config || \
  echo "MaxAuthTries 3" >> /etc/ssh/sshd_config

grep -q "^MaxSessions" /etc/ssh/sshd_config && \
  sed -i "s/^MaxSessions.*/MaxSessions 2/" /etc/ssh/sshd_config || \
  echo "MaxSessions 2" >> /etc/ssh/sshd_config

grep -q "^ClientAliveInterval" /etc/ssh/sshd_config && \
  sed -i "s/^ClientAliveInterval.*/ClientAliveInterval 300/" /etc/ssh/sshd_config || \
  echo "ClientAliveInterval 300" >> /etc/ssh/sshd_config

grep -q "^ClientAliveCountMax" /etc/ssh/sshd_config && \
  sed -i "s/^ClientAliveCountMax.*/ClientAliveCountMax 2/" /etc/ssh/sshd_config || \
  echo "ClientAliveCountMax 2" >> /etc/ssh/sshd_config

# Проверяем корректность конфига SSH перед перезапуском
if sshd -t 2>/dev/null; then
    echo "SSH конфигурация проверена — OK"
else
    echo "Ошибка в SSH-конфигурации! Проверь /etc/ssh/sshd_config"
    exit 1
fi

# Перезапускаем SSH (учитываем разные имена юнитов)
systemctl restart ssh 2>/dev/null || systemctl restart sshd

# Настраиваем UFW
ufw --force reset
ufw default deny incoming
ufw default allow outgoing
ufw allow ${SSH_PORT}/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw --force enable

# Настраиваем Fail2Ban 
[ -f /etc/fail2ban/jail.local ] || cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
systemctl enable fail2ban
systemctl restart fail2ban

# Настраиваем автоматические обновления безопасности 
echo 'Unattended-Upgrade::Automatic-Reboot "false";' >> /etc/apt/apt.conf.d/50unattended-upgrades
dpkg-reconfigure -fnoninteractive unattended-upgrades

# Устанавливаем периодичность 
# Ежедневное обновление списка пакетов и установка обновлений безопасности,
# очистка устаревших пакетов раз в неделю.
cat <<EOF > /etc/apt/apt.conf.d/20auto-upgrades
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::AutocleanInterval "7";
EOF

echo
echo " Настройка завершена успешно "
echo "SSH теперь работает на порту $SSH_PORT"
echo "Вход разрешён только по ключу для пользователя: $USERNAME"
echo "Root-вход отключён."

Проверьте новое SSH подключение перед закрытием текущей сессии!

Тестируем защиту: проверяем, что всё работает

Используем инструменты для проверки извне, как видит ваш сервер потенциальный атакующий):

# Быстрое сканирование популярных портов, если нужно быстро проверить основные службы
nmap -sS -O your_server_ip

# Детальное сканирование всех 65535 портов
nmap -p- -sV your_server_ip

# Проверка SSL/TLS (если есть HTTPS):
# Используем testssl.sh
git clone --depth 1 https://github.com/drwetter/testssl.sh.git
cd testssl.sh
./testssl.sh your_domain.com

Внутренний аудит

# Проверяем конфигурацию SSH
sudo sshd -T | grep -E "port|permitrootlogin|passwordauthentication"

# Ожидаемый результат:
# port 2245 (или ваш порт)
# permitrootlogin no
# passwordauthentication no

# Статус файрвола
sudo ufw status verbose

# Проверяем активные правила
sudo ufw status numbered

# Логи неудачных попыток входа за последние 24 часа
sudo journalctl --since "24 hours ago" | grep "Failed password" | wc -l

# Статус служб
systemctl status ufw fail2ban

# Проверяем, что службы включены при загрузке
systemctl is-enabled ufw fail2ban

# Статистика Fail2Ban
sudo fail2ban-client status sshd

# Список заблокированных IP
sudo fail2ban-client get sshd banip

# Анализ сетевой активности
# Проверка открытых портов (на каких портах система принимает входящие подключения)
sudo ss -tuln | grep LISTEN

# Проверка активных сетевых соединений (текущие установленные подключения)
sudo ss -tunap | grep ESTABLISHED

# Для идентификации незнакомых IP:
# whois <IP_адрес>

Реальная эффективность методов защиты: цифры и ограничения

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

Таблица эффективности методов защиты

Чек-лист безопасности: проверьте себя

Уровень "Минимум" (обязательно для всех):

• Сложный пароль root (20+ символов)

• SSH-порт изменён с 22 на другой

• Root-доступ по SSH отключён

• Создан пользователь с sudo-правами

• Настроен базовый файрвол (UFW)

• Включены автоматические обновления безопасности

Уровень "Стандарт" (рекомендуется):

• Аутентификация только по SSH-ключам

• Установлен и настроен Fail2Ban

• Ограничения SSH (MaxAuthTries, MaxSessions)

• Мониторинг логов безопасности

• Регулярные проверки rkhunter/chkrootkit

Уровень "Профи" (для критичных систем):

• Доступ к SSH только через VPN

• Port knocking для дополнительной скрытности

• IDS/IPS система обнаружения вторжений (AIDE)

• Контейнеризация сервисов

• Регулярный внешний аудит безопасности

Распространённые ошибки: учимся на чужих граблях

Ошибка №1: "Обновлю потом"

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

Ошибка №2: "Fail2Ban защищает навсегда"

Fail2Ban банит по IP, но атакующие используют ботнеты с тысячами адресов. Это замедляет атаку, но не останавливает её.

Ошибка №3: "Security through obscurity работает"

Смена порта SSH — хорошая мера, но не основная. Продвинутый сканер найдёт открытый SSH на любом порту.

Ошибка №4: "У меня нет ничего ценного"

Ваш сервер ценен сам по себе: CPU для майнинга, IP для ботнета, место для хранения нелегального контента. Даже если у вас ничего не украдут, то хостинг провайдер может наложить ограничения на ваш аккаунт.

Ошибка №5: "Настроил один раз — забыл"

Безопасность требует постоянного внимания. Новые уязвимости, изменения в атаках, устаревающие конфигурации.

Заключение: безопасность как образ жизни

За время работы в техподдержке я понял: взламывают не только плохо защищённые серверы, но и те, владельцы которых предприняли меры защиты, но потом расслабились.

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

1. Принцип многоуровневой защиты — не полагайтесь на один метод

2. Регулярные обновления — большинство взломов происходит через известные уязвимости

3. Мониторинг активности — вы должны знать, что происходит на сервере

4. Резервные копии — когда всё остальное не сработает

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

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

И главное, инвестируйте время в безопасность сегодня, чтобы не тратить недели на восстановление после взлома завтра. Безопасность — это марафон, а не спринт. Начните с базовых мер прямо сейчас.

Теги:

Хабы: