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

Представьте себе: вы арендовали скромный 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


\# Применяем изменения
sudo systemctl restart sshd

Результат на практике: После смены порта 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, иначе рискуете потерять доступ к управлению сервером.

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

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

\`\`\`bash
\# Устанавливаем UFW

sudo apt update && sudo apt install ufw


\# Настраиваем политики по умолчанию: закрываем все входящие, разрешаем исходящие
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


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

sudo nano /etc/fail2ban/jail.local

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

```ini
[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 "your_email@example.com"

• -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

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

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

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

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

sudo nano /etc/ssh/sshd_config

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

PasswordAuthentication no

PubkeyAuthentication yes

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

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

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

sudo systemctl restart sshd

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

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

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

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

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

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

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

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

Настроить его можно с помощью WG Easy на этом же сервере, инструкция есть в Readme репозитория.
https://github.com/wg-easy/wg-easy

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

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

ListenAddress 10.0.0.1

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

sudo systemctl restart sshd

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: секретный стук

SSH-порт открывается только после "стука" в определённую последовательность портов:

\# Установка knockd

sudo apt install knockd


\# Конфигурация /etc/knockd.conf
\[openSSH\]
sequence = 7000,8000,9000

seq_timeout = 5

tcpflags = syn

command = /usr/sbin/iptables -A INPUT -s %IP% -p tcp --dport 2244 -j ACCEPT


\[closeSSH\]
sequence = 9000,8000,7000

seq_timeout = 5

tcpflags = syn

command = /usr/sbin/iptables -D INPUT -s %IP% -p tcp --dport 2244 -j ACCEPT

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

\# "Стучимся" в порты
nmap -Pn --host-timeout 201 --max-retries 0 -p 7000 server_ip

nmap -Pn --host-timeout 201 --max-retries 0 -p 8000 server_ip

nmap -Pn --host-timeout 201 --max-retries 0 -p 9000 server_ip


\# Теперь можно подключиться по SSH

ssh -p 2244 user@server_ip

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

AIDE (Advanced Intrusion Detection Environment) для контроля целостности:

\# Установка
sudo apt install aide


\# Инициализация базы
sudo aideinit

sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db


\# Проверка изменений
sudo aide --check

Tripwire как альтернатива:

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

sudo apt install tripwire

sudo tripwire --init

sudo tripwire --check

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

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

Создаём скрипт для мониторинга /usr/local/bin/security-check.sh:

```bash
#!/bin/bash


echo "=== Security Check $(date) ==="


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


# Статус Fail2Ban

echo "Fail2Ban status:"
sudo fail2ban-client status sshd


# Активные соединения
echo "Active connections:"
ss -tuln | grep :2244


# Проверка обновлений
echo "Available updates:"
apt list --upgradable 2>/dev/null | wc -l


echo "=========================="

Добавляем в cron для ежедневного выполнения:

sudo crontab -e
\# Добавляем строку:
0 9 \* \* \* /usr/local/bin/security-check.sh | mail -s "Daily Security Report" your@email.com

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

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 сканирует системные файлы и процессы на признаки заражения, подмены утилит и следы руткитов.

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

\# Запускаем проверку 
sudo chkrootkit

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

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

Создаём /root/secure-server.sh:

\#!/bin/bash

set -e

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


\# Обновляем систему
apt update && apt upgrade -y


\# Устанавливаем необходимые пакеты
apt install -y ufw fail2ban rkhunter lynis unattended-upgrades


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


\# Настраиваем SSH

cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup

cat >> /etc/ssh/sshd_config << EOF

Port 2244

PermitRootLogin no

PasswordAuthentication no

MaxAuthTries 3

MaxSessions 2

ClientAliveInterval 300

ClientAliveCountMax 2

AllowUsers ваш_пользователь
EOF


\# Настраиваем UFW

ufw --force reset

ufw default deny incoming

ufw default allow outgoing

ufw allow 2244/tcp

ufw allow 80/tcp

ufw allow 443/tcp

ufw --force enable


\# Настраиваем Fail2Ban

cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

systemctl enable fail2ban

systemctl start fail2ban


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


\# Включаем автоматические обновления
sudo dpkg-reconfigure -plow 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

Далее:

\# Настраиваем автоматические обновления
sudo dpkg-reconfigure -plow unattended-upgrades


\# Конфигурация /etc/apt/apt.conf.d/20auto-upgrades

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::AutocleanInterval "7";

Система будет ежедневно проверять наличие обновлений, автоматически устанавливать их в зависимости от настроек в /etc/apt/apt.conf.d/50unattended-upgrades и раз в неделю очищать кэш от старых пакетов.

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

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

\# Быстрое сканирование популярных портов, если нужно быстро проверить основные службы
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, Tripwire)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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