Как защитить систему на Linux: главные принципы

Свежий Linux-сервер начинают перебирать по SSH в первые же часы после того, как он получает белый IP. Ханипоты ловят первые попытки входа за минуты. Вы тут ни при чём: по диапазонам адресов круглосуточно ползают боты и стучатся во всё, что отвечает на 22-й порт. Дальше всё решает то, что они найдут за этой дверью - пароль Server2024 или ключ, который перебрать нельзя.

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

Три вещи в первый час

Если у вас сейчас есть только час и свежая система, сделайте это:

1. Заведите обычного пользователя с правом sudo и войдите под ним по SSH-ключу.
2. В /etc/ssh/sshd_config выключите вход по паролю и вход под root.
3. Поднимите файрвол, который по умолчанию запрещает всё входящее, кроме SSH и портов ваших сервисов.

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

Кто ломится в ваш сервер на самом деле

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

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

SSH: единственная дверь, которую видно снаружи

На типовом сервере наружу торчит один порт - 22-й. Ему и достаётся почти весь поток попыток.

Сначала заведите пользователя и положите ему ключ. Генерируйте Ed25519, а не RSA:

ssh-keygen -t ed25519 -C "admin@company"
ssh-copy-id -i ~/.ssh/id_ed25519.pub admin@server

Про RSA есть путаница, которую стоит разъяснить. Из обихода вышла схема подписи ssh-rsa на SHA-1 - её отключили по умолчанию ещё в OpenSSH 8.8 в августе 2021 года. Сам RSA-ключ жив: 4096 бит с подписью rsa-sha2-256/512 работают нормально. Ed25519 просто короче, быстрее, и на нём нельзя случайно сгенерировать слабый ключ. А вот DSA закончился совсем - в OpenSSH 10.0 его выпилили окончательно.

Дальше правим /etc/ssh/sshd_config:

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
LoginGraceTime 20
AllowUsers admin deploy
ClientAliveInterval 300
ClientAliveCountMax 2

AllowUsers - недооценённая строка. Она превращает перебор логинов в бессмысленное занятие: даже угадав пароль от postgres, бот не войдёт, потому что этому пользователю SSH не отвечает вовсе. Только подставьте туда свои имена пользователей, а не скопируйте строку как есть - иначе выключите себе доступ вместе с ботами.

Про ключи ещё две вещи. Ставьте на них пароль - иначе украденный ноутбук админа сразу даёт доступ ко всему парку. И заведите привычку отзывать ключ при увольнении: в ~/.ssh/authorized_keys строчки живут годами, о них забывают первым делом.

Подробнее про варианты подключения и их отличия - в статье «Как установить безопасное соединение с сервером».

Перебор паролей: fail2ban и здравый смысл

fail2ban читает логи, видит серию неудачных входов с одного адреса и банит его на время правилами файрвола.

apt install fail2ban                      # Debian, Ubuntu
dnf install epel-release && dnf install fail2ban   # RHEL, AlmaLinux, Rocky

В RHEL-семействе fail2ban живёт в EPEL, а не в базовых репозиториях - без подключённого EPEL команда просто не найдёт пакет. В РЕД ОС он в штатных репозиториях, EPEL там не нужен.

Дальше ждёт ловушка, на которой спотыкаются регулярно. В Debian и Ubuntu джейл для SSH включён сразу после установки, а в RHEL-семействе пакет ставится с пустым набором правил и молча ничего не делает. Не считайте, что заработало, - проверьте:

fail2ban-client status sshd

Если в ответ «Sorry but the jail 'sshd' does not exist» - заведите /etc/fail2ban/jail.local с секцией [sshd] и enabled = true.

Тут нужна честность в оценке. Если вход по паролю вы уже отключили, подбирать боту нечего, и fail2ban работает на другое: чистит логи и снимает лишнюю нагрузку с sshd. Это гигиена, и она полезна - в чистых логах видно настоящие события, а не десять тысяч строк про Failed password for root.

Настоящая работа у fail2ban начинается там, где пароли остались: панели управления, почтовые сервисы, веб-формы входа. Там он и останавливает подбор.

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

Обновления: включить автоматические и спокойно жить

Совет «ставьте обновления» знают все, поэтому сразу к спорной части: обновления безопасности имеет смысл сделать автоматическими.

apt install unattended-upgrades && dpkg-reconfigure -plow unattended-upgrades   # Debian, Ubuntu
dnf install dnf-automatic && systemctl enable --now dnf-automatic.timer         # RHEL-семейство

Возражение «а вдруг сломает прод» справедливо ровно наполовину. В Debian и Ubuntu репозиторий security содержит бэкпорты исправлений в ту же версию пакета, без смены мажорных версий, - вероятность, что такое обновление уронит приложение, невелика. Риск реален для полного dist-upgrade, и вот его автоматизировать не нужно.

Отдельная история - ядро. Обновление ядра приезжает, но не применяется до перезагрузки, и сервер может месяцами работать с уже пропатченным, но не активированным ядром. Проверить просто: needrestart на Debian-семействе или dnf needs-restarting -r на RHEL-семействе скажут, требуется ли рестарт. Заведите окно раз в месяц.

И проверьте, поддерживается ли вообще ваш дистрибутив. CentOS 7 закончился 30 июня 2024 года: обновлений безопасности для него больше нет, и каждая новая уязвимость на нём остаётся открытой навсегда. Если такие машины ещё живы, миграция на AlmaLinux или Rocky Linux - более срочная задача, чем всё остальное в этой статье.

Файрвол в 2026: ваши iptables - это уже nftables

Здесь застряла вся выдача по теме. Гайды пишут «настройте iptables», хотя в Debian с 10-й версии, в RHEL с 8-й и в Ubuntu с 20.10 бэкендом по умолчанию работает nftables, а команда iptables - это обёртка iptables-nft, которая переводит старый синтаксис в новые правила. Практический вывод: смешивать инструменты нельзя. Правила, добавленные через nft, не увидит iptables-save, и наоборот - так и теряются куски конфигурации.

Выберите один слой управления и не трогайте остальные:

• ufw - Ubuntu и Debian, самый простой. ufw default deny incoming, дальше ufw allow 22/tcp и что нужно.
• firewalld - RHEL, AlmaLinux, Rocky, РЕД ОС. Зоны, firewall-cmd --permanent --add-service=ssh.
• чистый nft - когда нужны наборы адресов, счётчики и правила, которых в надстройках нет.

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

Не забудьте про IPv6. Если у сервера есть адрес v6, а правила написаны только для v4, вы сделали половину работы и не заметили этого.

Лишние службы: чего сервер не должен слушать

Половина портов, которые слушает типовой сервер, открыта случайно. Посмотрите, что там:

ss -tulpn

Дальше по каждой строке - вопрос «зачем она здесь». Postgres, слушающий 0.0.0.0 вместо 127.0.0.1, Redis без пароля, оставшийся с отладки, тестовый веб-сервер на 8080 - обычные находки. Их не надо закрывать файрволом, их надо выключить:

systemctl disable --now имя_службы

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

Как разбираться с юнитами, зависимостями и автозапуском - разобрано в гайде по systemd.

Права и sudo: коротко о главном

Тема прав доступа большая, у нас про неё есть отдельный разбор chmod и chown. Здесь - только то, что относится к защите:

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

В /etc/sudoers (правьте только через visudo) держите список коротким и без NOPASSWD там, где это не нужно для автоматики. И включите логирование - тогда в журнале останется, кто и какую команду выполнял с повышенными правами.

Про атрибут chattr +i скажем отдельно, потому что формулировку «защита, которую не обходит даже root» часто понимают слишком буквально. Файл с этим атрибутом действительно нельзя удалить или изменить, но root снимает сам атрибут одной командой chattr -i. Реальная польза другая: атрибут защищает конфиг от случайной перезаписи скриптом или пакетным менеджером. Как барьер от того, кто уже получил root, он не работает.

AppArmor или SELinux: что у вас уже включено

Обе системы делают одно - ограничивают, к чему процесс может обратиться, даже если он работает от root. Взломанный nginx с профилем AppArmor не прочитает /etc/shadow, потому что профиль ему такого не разрешал.

Разница практическая: AppArmor идёт по умолчанию в Ubuntu, Debian и SUSE, SELinux - в RHEL, Fedora, AlmaLinux, Rocky и российских дистрибутивах на их основе. Ставить SELinux поверх Ubuntu теоретически можно, но это занятие для тех, у кого много свободного времени.

Проверьте, что оно вообще работает:

aa-status          # AppArmor
getenforce         # SELinux, должно быть Enforcing

Если getenforce отвечает Permissive или Disabled - когда-то кто-то отключил защиту, чтобы заработало приложение, и забыл вернуть. Это самая частая находка при аудите. Правильный путь - дописать политику под приложение, но признаем честно: для одного админа на пять серверов это редко посильно. Тогда лучше оставить Permissive и знать об этом, чем считать, что защита есть.

Логи и аудит: заметить чужого до того, как всё встанет

По отчёту Mandiant M-Trends за 2026 год медианный срок между проникновением и обнаружением составил 14 дней - и это глобальная медиана, где заметная доля случаев приходится на компании с командой безопасности. Две недели в логах копятся следы, которые никто не читает.

Минимум, который окупается:

• journalctl -u ssh -p warning раз в неделю - кто и откуда пытался войти. В RHEL-семействе юнит называется sshd, а не ssh: команда с чужим именем молча вернёт пустоту, и это легко принять за тишину в логах.
• last и lastb - успешные и неудачные входы.
• auditd с правилами на изменение /etc/passwd, /etc/sudoers и ~/.ssh/authorized_keys - три файла, которые меняет тот, кто закрепляется в системе.
• Отправка логов на отдельную машину. Логи на взломанном сервере правит тот, кто его взломал; логи, уехавшие по сети, - уже нет.

Для парка из нескольких серверов ручное чтение перестаёт работать, и дальше начинается разговор про системы мониторинга безопасности - SIEM и IDS. Для одного сервера это перебор.

Бэкап, который кто-то проверял

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

Без двух условий бэкап остаётся декоративным.

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

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

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

Уровень, о котором молчат хостерские гайды: IPMI, iDRAC, iLO

Почти все руководства по защите Linux написаны с расчётом на облако, где железа у читателя нет. У вас оно есть - и вместе с ним модуль удалённого управления: IPMI на платформах Supermicro, iDRAC у Dell, iLO у HPE.

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

Теперь неприятная часть. В спецификации IPMI 2.0 есть дефект протокола (CVE-2013-4786): при попытке аутентификации контроллер отдаёт хеш пароля до проверки, то есть перебирать его можно офлайн, без единой попытки входа. Патча нет и не будет - это устройство самой спецификации. Сканирование интернета в июле 2026 года нашло 36 872 доступных снаружи IPMI-интерфейса, и 24 650 из них отдавали хеши всем желающим.

Что с этим делать:

• Вынести управляющие интерфейсы в отдельный сегмент сети, недоступный из интернета. Нужен доступ снаружи - только через VPN.
• Сменить заводские пароли. ADMIN/ADMIN на Supermicro знает каждый сканер, root/calvin на iDRAC 7 и 8 - тоже. У iDRAC 9 (PowerEdge 14-го поколения и новее) пароль уникальный и напечатан на сервисной бирке, но его часто меняют на удобный и общий для всего парка - проверьте, не ваш ли это случай.
• Отключить IPMI-over-LAN, если пользуетесь только веб-интерфейсом. UDP-порт 623 наружу не нужен никому.
• Обновлять прошивку BMC. Её обновляют реже всего, а дыры там живут дольше всего.

Проверить свой сервер можно за минуту: попробуйте открыть адрес BMC из сети, не относящейся к вашей серверной. Если открылось - это самая срочная задача из всей статьи.

Astra Linux, РЕД ОС и «Альт»: что меняется на российских ОС

Если сервер работает на сертифицированном отечественном дистрибутиве, базовая часть остаётся той же: SSH, файрвол, обновления, права. Сверху добавляются механизмы, которых в обычном Linux нет.

В Astra Linux Special Edition это замкнутая программная среда - система проверяет цифровую подпись исполняемых файлов и не даёт запустить то, что подписано не тем ключом, - и мандатный контроль целостности, который делит компоненты по уровням и запрещает записывать в объекты более высокого уровня. Механизмы полезные, но они меняют привычную работу: собранный вручную бинарник в замкнутой среде просто не запустится, и это нужно закладывать в план внедрения заранее.

Отдельно про регулирование, потому что здесь много путаницы. Приказ ФСТЭК № 117 от 11 апреля 2025 года вступил в силу 1 марта 2026-го и заменил приказ № 17, работавший с 2013 года. Он касается государственных информационных систем и систем госорганов, ГУПов и госучреждений. Для обычной коммерческой компании он напрямую обязательным не становится - требования приходят, когда вы подключаетесь к таким системам, работаете по госконтракту или проходите аттестацию сами. Если это ваш случай, разговор о защите начинается с класса защищённости и набора мер под него, а sshd_config идёт сильно позже.

Сравнение самих дистрибутивов - в статье про российские ОС для серверов.

Советы, которые кочуют по гайдам и почти ничего не дают

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

Смена порта SSH с 22 на нестандартный. Что реально происходит: массовые сканеры перестают вас находить, и поток мусора в логах падает почти до нуля. Что не происходит: адресный сканер портов найдёт ваш SSH за секунды, а nmap знает про такие хитрости с прошлого десятилетия. Считайте это уборкой в логах, а не защитой. Делать можно, полагаться - нет. И держите в голове побочный эффект: занять порт ниже 1024 может только процесс с правами root или со специально выданной привилегией, а на порт выше 1024 при упавшем sshd способен сесть любой процесс любого пользователя. Мелочь, но она работает против вас.

Отключение IPv6 «для безопасности». Совет вредный. Отключённый на уровне ядра IPv6 иногда включается обратно после обновления, а правила файрвола для него никто не пишет - и получается открытая дверь, о которой все забыли. Правильнее оставить IPv6 включённым и написать для него те же правила, что и для IPv4.

/etc/securetty для ограничения root. Этот файл перечисляет терминалы, с которых root может войти локально, к сетевым подключениям он отношения не имеет вовсе. Вдобавок механизм устарел: из Debian файл убрали ещё в 11-й версии, и в свежих системах его просто нет. Ограничение root по сети делается строкой PermitRootLogin no в конфиге SSH, а не этим файлом.

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

Когда всего этого мало

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

Вы обрабатываете персональные данные в объёме, при котором утечка тянет за собой штраф и уведомление регулятора в жёсткие сроки. Вы работаете с государственными информационными системами - тогда набор мер задаётся приказом, а не здравым смыслом. У вас публичный веб-сервис под реальной нагрузкой: там ломают само приложение, SSH идёт вторым номером, и нужен другой разговор - про WAF, зависимости и обновление кода. Или у вас больше десятка серверов, и ручное управление конфигурацией перестаёт масштабироваться: дальше идут системы управления конфигурацией и централизованный сбор логов.

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

Чек-лист: час, день, месяц

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

Нужен ли антивирус на Linux-сервере?

Для защиты самого сервера - обычно нет: сюда заходят подбором паролей и через непропатченные сервисы, вирусы тут почти ни при чём. Антивирус нужен в двух случаях: сервер раздаёт файлы Windows-машинам (тогда он ловит чужую заразу, а не свою) или этого требует регламент проверяющего.

Можно ли полностью отключить root?

Заблокировать пароль root командой passwd -l root и работать через sudo - нормальная практика. Полностью удалить учётную запись нельзя, она нужна системе. Важнее другое: закройте вход под root по сети, а локальный доступ через консоль оставьте - иначе при поломке sudo вы останетесь без единого способа зайти.

Что настраивать первым - файрвол или SSH-ключи?

Ключи. Файрвол всё равно оставляет SSH открытым, поэтому дверь остаётся, и вопрос только в том, чем она заперта. Разница по времени тут в минуты, так что обычно делают оба пункта подряд.

Как понять, что сервер уже взломали?

Признаки: незнакомые строки в ~/.ssh/authorized_keys, новые задания в crontab, процессы, грузящие процессор ночью, исходящий трафик на незнакомые адреса, пробелы в логах. Команды для быстрой проверки: last, ss -tupn, crontab -l -u <пользователь> и find /etc /usr/bin /usr/sbin /usr/local -mtime -3 -type f - искать по всему корню бессмысленно, /proc и /sys завалят вывод десятками тысяч строк.

Сертифицированная ОС сама по себе делает сервер защищённым?

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