Советы по безопасности сервера, которые не работают

Перенесли SSH на порт 2222. Поставили fail2ban. Отключили пинг, чтобы «не нашли». Спрятали версию nginx. Придумали админке адрес позаковыристее.

И теперь чувствуете себя защищённым. Вот с этим ощущением и есть проблема, потому что модель угроз от всего перечисленного не изменилась примерно никак.

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

Дальше по каждому совету: что предлагают, как оно устроено механически, и что это меняет на самом деле. Без «эксперты рекомендуют» - только механика и цифры, которые можно проверить.

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

Содержание

Откуда взялись эти советы
Автомату всё равно
Сменить порт SSH
Поставить fail2ban и успокоиться
Отключить ICMP, чтобы не нашли
Спрятать версию сервера
Порт-нокинг
Менять пароли раз в три месяца
Антивирус на Linux-сервере
Секретный адрес админки
Складывать обскурность бесполезно
Что работает на самом деле
Как отличить меру от театра
Частые ошибки
Короткий итог

Источники

Откуда взялись эти советы

Тут важно быть справедливым: почти все они когда-то имели смысл.

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

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

Советы остались, противник поменялся. В этом вся история.

Автомату всё равно

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

Считаем на реальных числах. masscan в своём описании заявляет полный обход интернета за время меньше шести минут при десяти миллионах пакетов в секунду - правда, для этого нужна десятигигабитная карта и специальный драйвер. Возьмём вариант поскромнее: обычная машина без всякой экзотики выдаёт порядка полутора миллионов пакетов в секунду. Маршрутизируемых адресов IPv4 примерно 3,7 миллиарда.

Делим одно на другое и получаем около сорока минут, чтобы с одной обычной машины постучаться на один порт всего интернета. Не датацентра, не подсети. Всего.

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

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

Сменить порт SSH

Что советуют: перенести SSH с 22 на 2222, 22022 или что-нибудь ещё, чтобы боты не нашли.

Как на самом деле. Массовый перебор действительно ходит преимущественно по 22-му порту, потому что там улов. Так что после переезда логи заметно опустеют. Эффект настоящий, а не самовнушение.

Но опустеют они только от самой тупой части трафика. Тот, кто сканирует диапазоны портов, а не один порт, найдёт вас за секунды - см. цифру выше. Ни о какой защите тут речи не идёт, речь идёт о фильтрации шума.

Отдельно про аргумент, который любят приводить против переезда. В Linux порты ниже 1024 может занять только root, а порт 2222 - любой пользователь. Идея такая: если sshd упадёт, непривилегированный процесс сможет занять освободившийся порт и притвориться сервером. Аргумент существует, но он слабее, чем его подают: sshd и так работает от root, а на сервере, где у вас завёлся посторонний непривилегированный пользователь, есть проблемы поинтереснее. Плюс граница настраивается через net.ipv4.ip_unprivileged_port_start.

Вердикт. Не вредно. Делайте, если надоели тысячи строк в логах, - это законный повод. Просто не записывайте это в меры безопасности: замок на двери от переноса двери не меняется.

Поставить fail2ban и успокоиться

Сколько неудачных попыток нужно, чтобы fail2ban сработал? Несколько. Но обязательно с одного адреса, и вот на этом уточнении всё и держится.

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

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

А теперь главное, и оно ещё неприятнее. Если у вас отключена парольная аутентификация и вход только по ключам, перебирать нечего в принципе. Подобрать ключ перебором нельзя. То есть fail2ban в этой конфигурации караулит дверь, которая и так заварена.

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

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

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

Вообще если всё таки вы не хотите входить по ключам, а fail2ban вам ну очень нужен - рекомендую просто ставить правила, чтобы после первой неудачной попытки банило на сутки(при повторной попытке просто сканеры перестанут в вас стучать).

Отключить ICMP, чтобы не нашли

Сканер не пингует.

Он сразу отправляет SYN на интересующий порт: ответ на SYN информативнее, а лишний раунд с пингом только замедляет обход. Так что запрет пинга не убирает вас ни из одного списка и не мешает ни одному массовому сканированию. Совет не работает ровно в том, ради чего его дают.

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

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

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

Спрятать версию сервера

Поставьте себя на место атакующего. У вас есть эксплойт под конкретную версию. Что дешевле: сначала выяснить версию, а потом стрелять, или просто выстрелить? Выстрелить. Проверка стоит одного запроса, попытка стоит одного запроса, а результат попытки заодно отвечает и на вопрос про версию.

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

server_tokens off безвреден и копеечен, делайте если хочется. Только помните, что дыру закрывает обновление. Спрятанный номер версии на непропатченном сервере - наклейка поверх трещины.

Порт-нокинг

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

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

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

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

Менять пароли раз в три месяца

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

В актуальной редакции рекомендаций NIST (редакция четвёртая, июль 2025) прямо запрещено требовать периодическую смену пароля без признаков компрометации, и прямо запрещены правила состава - те самые «минимум одна заглавная и один символ». Заодно запрещены контрольные вопросы и требование не блокировать вставку в поле пароля.

Механика вреда очевидна, если подумать про людей, а не про регламент. Обязательная смена раз в квартал не рождает новый стойкий пароль, она рождает Password1!, который через три месяца становится Password2!. Человек не может помнить четыре несвязанных пароля в год, поэтому он делает счётчик.

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

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

Антивирус на Linux-сервере

Тут надо развести два вопроса, которые всё время слипаются в один.

Защищает ли он тех, кому вы отдаёте файлы? Да, если сервер принимает файлы от людей и раздаёт дальше или работает почтовым узлом. Только защищает он при этом не сервер, а виндовые машины на той стороне: сигнатуры в основном под них. Задача нормальная и понятная.

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

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

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

Секретный адрес админки

Панель переносят с /admin на что-нибудь вроде /ya-durak-9f и никому не говорят. Дальше адрес перестаёт быть секретом множеством скучных способов, и ни один из них не требует взлома.

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

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

От перебора защищает аутентификация, ограничение по IP или туннель. Смена пути даёт только ощущение, что вы что-то сделали.

Складывать обскурность бесполезно

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

Человек делает четыре вещи из списка и рассуждает так: одна мера слабая, но их же четыре, вместе получается серьёзно. Логика знакомая и в других областях рабочая - несколько слабых замков лучше одного.

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

Проверяется это одним вопросом: изменится ли исход, если атакующий уже знает, где вы и что у вас стоит? Для всех перечисленных советов ответ - нет, не изменится. Значит, это один слой, а не четыре.

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

Что работает на самом деле

Список короткий и до обидного скучный. Ровно поэтому его и не пишут в статьях: про него нечего рассказывать.

Ключи вместо паролей. Одна строчка в /etc/ssh/sshd_config:

PasswordAuthentication no

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

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

Наружу торчит только то, что должно. Проверить, что вы вообще слушаете:

ss -tulpn

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

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

Бэкапы, проверенные восстановлением. Непроверенный бэкап - это надежда, а не бэкап.

Двухфакторка там, где входит человек. На панель хостера в первую очередь: доступ к ней сильнее любого доступа к серверу.

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

Шесть с половиной пунктов. Ни одного секретного порта.

Как отличить меру от театра

Полезнее списка - способ проверять советы самому, потому что новые будут появляться и дальше.

Четыре вопроса к любой рекомендации:

1. От кого конкретно это защищает? Если ответ «ну, от хакеров» - это не ответ. Массовый сканер, целенаправленный атакующий и человек, укравший ваш ноутбук, - три разных противника, и мера обычно работает против одного из них.

2. Что именно атакующий не сможет сделать после этой меры? Формулировка должна быть в терминах действий. Если получается только «ему будет труднее меня найти» - перед вами обскурность, а не защита.

3. Меняется ли исход, если он уже нашёл и уже знает конфигурацию? Нет - значит, мера про заметность, а не про безопасность. Такие меры можно применять, но нельзя складывать (см. раздел выше).

4. Что я теряю? Сломанное определение MTU, потерянный доступ к собственному серверу, невозможность продиагностировать сеть, пароль вида Password7!. У любой меры есть цена, и иногда она выше пользы.

Прогоните по этим четырём вопросам любой чеклист из поиска - и он сократится примерно вдвое.

Где это пробовать

Единственное разумное место для экспериментов с файрволом, SSH и правами - не тот сервер, на котором что-то работает. Заблокировать себе доступ настройкой файрвола можно с первого раза, и это будет не смешно, если сервер боевой.

Отдельная копеечная виртуалка снимает вопрос целиком: там можно спокойно отключить себе пароли, ошибиться в правиле, потерять доступ, восстановить через консоль хостера и понять, как это выглядит, пока цена ошибки равна нулю. У меня для такого держится самый младший тариф на serv.host (промокод promo22382), и он окупился в первый же раз, когда я закрыл себе SSH правилом, которое казалось очевидным.

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

Частые ошибки

Считать перенос порта защитой. Это шумодав. Полезный, но не защита.
Ставить fail2ban при включённых паролях и успокаиваться. Он не решает проблему, он делает её менее заметной в логах.
Отключать ICMP целиком. Не прячет, зато ломает MTU и диагностику. Единственный совет, который портит работающую систему.
Путать скрытую версию с закрытой уязвимостью. Дыру закрывает патч.
Складывать меры одного типа и считать, что получилось несколько рубежей. Четыре способа спрятаться - это один рубеж.
Требовать смену паролей по расписанию. Прямо противоречит действующим рекомендациям и порождает счётчик в конце пароля.
Забывать про панель хостера. Доступ к ней даёт больше, чем root на сервере: там и консоль, и переустановка, и снапшоты.
Не проверять, что вообще слушает наружу. ss -tulpn показывает реальную картину, а не воображаемую.
Тестировать правила файрвола на боевом сервере без второй открытой сессии.

Короткий итог

Обскурность работает против того, кто выбирает цель. Сегодня цель не выбирают: одна обычная машина обходит весь интернет по одному порту примерно за сорок минут, а все порты одного хоста - меньше чем за секунду.
Смена порта SSH убирает шум в логах и больше ничего. Законная гигиена, не мера безопасности.
fail2ban не спасает от распределённого перебора (порог считается по одному адресу), а при входе по ключам охраняет уже заваренную дверь.
Отключение ICMP не прячет, но ломает определение MTU и диагностику. Остальные советы в худшем случае бесполезны, этот один портит работающее.
Скрытая версия не закрывает дыру. Массовая эксплуатация не читает баннеры, ей дешевле выстрелить.
Порт-нокинг добавляет хрупкости, а за дверью оказывается ровно та же аутентификация.
Смена паролей по расписанию и правила состава запрещены действующей редакцией рекомендаций NIST: первое рождает счётчик в конце пароля, второе сужает перебор до человеческого шаблона.
Меры одного типа не складываются. Проверка одним вопросом: изменится ли исход, если атакующий уже всё про вас знает?
Работает скучное: ключи вместо паролей, обновления, закрытые наружу порты, минимальные права, проверенные бэкапы, двухфакторка на панель хостера.

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

Вообще я микроразработчик, со мной можно связаться как угодно, я открыт ко всему

Сторонний мой проект: Zapret2UI.