Защита SSH и FTP от перебора паролей

Остановите брутфорс SSH на ваших Linux-серверах

SSH Protector — лёгкий агент для Linux, который останавливает подбор паролей по SSH, SFTP и FTP. Он читает собственный лог аутентификации хоста — journald или auth.log — и, когда атакующий продолжает ошибаться, закрывает всю его подсеть /24 одним правилом nftables, переживающим перезагрузку. Решение принимается на самом сервере, поэтому защита работает и тогда, когда связь с панелью пропала. Установка занимает пару минут и не требует настройки.

Установить одной командой
curl -fsSL https://sshprotector.com/download/installer | sudo sh

Бесплатная версия включает в себя полную защиту для одного сервера.

Один агент для всех дистрибутивов Linux

Debian · Ubuntu · FedoraRHEL · Alma · Rocky · Alpinex64 · x86 · ARM64почти нулевая нагрузка
00

Установите агент

Один бинарник для всех, аккаунт для скачивания не нужен. Установите сейчас, а сервер подключите когда удобно - агент попросит токен из панели и до этого ничего не защищает.

Скачать скрипт установки

Любой современный Linux на systemd - Debian, Ubuntu, RHEL/CentOS/Alma/Rocky, Fedora - на x86-64 или ARM64. Скрипт ставит ту же службу и удобен для парка серверов.

01Зачем

Открытый SSH-порт атакуют круглосуточно

Боты сканируют весь диапазон адресов интернета и перебирают пароли на каждом доступном сервере. Неважно, корпоративная это машина или единственный VPS.

Тысячи попыток входа в сутки
Уже через несколько часов после запуска к серверу начинают стучаться боты со всего мира. На типичной машине с открытым SSH-портом счёт неудачных входов идёт на тысячи в сутки.
Ресурсы сервера тратятся впустую
Каждая попытка входа - это процессорное время, память, запись в журнал событий и сетевой трафик. Постоянный поток брутфорс-запросов создаёт фоновую нагрузку, замедляет сервер и раздувает журналы.
Один подобранный пароль - и взлом
Единственного удачного подбора достаточно для полного доступа к машине: шифровальщики, кража данных, рассылка спама с вашего адреса. Слабые и повторно используемые пароли подбираются по словарю за считанные дни.
Злоумышленник может заблокировать учётку администратора
Linux (через PAM faillock) блокирует учётную запись после нескольких неудачных входов. Подобрав действующее имя пользователя, атакующий упирается в этот лимит и блокирует настоящего администратора - отказ в обслуживании, даже не угадав пароль.

SSH Protector отсекает атаки на уровне фаервола

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

02Как это остановить

Как остановить брутфорс SSH на Linux: три способа

Три изменения действительно сокращают то, что доходит до sshd. Они складываются, и делать их стоит именно в этом порядке.

  1. 01Вход по ключам, а не по паролю

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

    # /etc/ssh/sshd_config.d/10-keys-only.conf
    PasswordAuthentication no
    KbdInteractiveAuthentication no
    PermitRootLogin prohibit-password
    Полное руководство
  2. 02Сократить, какая часть интернета дотягивается до порта

    Перенос sshd с порта 22 убирает основную массу неприцельного сканирования и больше ни от чего не защищает. Ограничение порта VPN или списком известных адресов убирает самого атакующего, а не шум; если у сервера постоянный набор администраторов, сделайте и то и другое.

    # /etc/ssh/sshd_config.d/20-exposure.conf
    Port 2202
    AllowGroups ssh-admins
    
    # nftables: only the VPN and the office reach it at all
    nft add rule inet filter input tcp dport 2202 \
      ip saddr { 10.8.0.0/24, 203.0.113.7 } accept
    Полное руководство
  3. 03Банить источник раньше, чем он успеет перебрать

    fail2ban — правильный первый ответ: читает лог аутентификации, считает отказы и на время блокирует адрес. Его границы структурны: один адрес за раз, истекающее состояние, ничего общего между хостами и jail, который после смены формата лога может молча перестать совпадать. SSH Protector банит всю подсеть /24 одним правилом nftables, сохраняет бан после перезагрузки и передаёт остальным то, что узнал один защищённый сервер.

    # /etc/fail2ban/jail.d/sshd.local
    [sshd]
    enabled  = true
    backend  = systemd
    maxretry = 4
    findtime = 10m
    bantime  = 1h
    Полное руководство

Что закрывает одно правило на подсеть

Подвигайте ползунки. Это арифметика, а не бенчмарк.

Бан по одному адресу

32 правил firewall

128 попыток всё ещё доходит до sshd

Бан всей подсети /24

1 правил firewall

4 попыток всё ещё доходит до sshd

В /24 помещается 256 адресов. Когда бан идёт по адресу, бот при переходе на следующий получает свежий лимит каждый раз; когда бан закрывает диапазон — ни разу. Здесь ничего не измерено, это тот же подсчёт, который делает агент.

03Как работает

От скачивания до защищённого сервера за несколько минут

Никаких конфигов и командной строки: скачайте установщик, запустите его и подтвердите запрос sudo.

  1. Создайте аккаунт

    Регистрация по email или через Google/GitHub. Банковская карта не нужна.

  2. Скачайте установщик

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

  3. Запустите его на сервере

    Агент сам определит порт SSH и добавит ваш текущий IP в вайтлист, чтобы вы не заблокировали сами себя.

  4. Готово

    Через несколько секунд сервер появится в панели со статусом «онлайн» и начнёт блокировать атакующих с разумными настройками по умолчанию.

04Возможности

Всё для защиты и управления вашими серверами

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

Защита SSH и FTP от перебора01

Агент читает неудачные входы из системного журнала (journald) и логов FTP-сервера и блокирует атакующего локально - мгновенно, даже без связи с облаком.

Бан подсетей, а не отдельных адресов02

Атакующие меняют адреса внутри своей сети. SSH Protector блокирует подсеть целиком по данным ASN - одним консолидированным правилом фаервола.

Общая база атакующих03

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

Гео-правила04

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

Временный доступ05

Держите порт закрытым по умолчанию и открывайте его для конкретного адреса после подтверждения по MFA - с таймером и автоматическим закрытием.

Вайтлист и строгий режим06

Доверенные адреса и динамические DNS-имена никогда не блокируются. В строгом режиме доступ к порту имеют только источники из вайтлиста.

Уведомления и аудит07

Всплеск блокировок, сервер ушёл в офлайн, изменилась конфигурация - придёт письмо, сообщение в Telegram, Slack или вебхук. Каждое действие фиксируется в журнале аудита.

Один лёгкий агент08

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

Централизованное управление09

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

Always-On: защита от блокировки учётки10

Гарантирует, что учётная запись не будет заблокирована при переборе: агент банит атакующих раньше порога блокировки PAM faillock и автоматически разблокирует защищённые учётные записи (администраторы + ваш список). Включено по умолчанию на всех тарифах.

05Тарифы

Фиксированные тарифы без доплат за каждый сервер

Free остаётся бесплатным навсегда, карта не нужна. У платных тарифов фиксированная цена и заранее известное число серверов.

Free

1 сервер
0 ₽/мес

Базовая защита SSH для одного сервера.

  • Защита SSH от перебора паролей
  • Мягкий вайтлист
  • Минимальная статистика

Solo

1 сервер
600 ₽/мес

Полная защита одного боевого сервера.

  • Всё из Free
  • Защита FTP от перебора паролей
  • Полная статистика
  • Email-уведомления
  • Базовый аудит

Pro

ПопулярныйДо 5 серверов
1 000 ₽/мес

Для команд и небольших парков серверов.

  • Всё из Solo
  • Строгий вайтлист и группы
  • Полный аудит с экспортом
  • Расширенная статистика
  • Общий блок-лист по поведению

Enterprise

До 50 серверов
7 000 ₽/мес

Для компаний с большим парком серверов.

  • Всё из Pro
  • Назначение администраторов и модераторов
  • Приоритетная поддержка
  • Общий блок-лист по поведению

Нужен ещё один сервер сверх тарифа? Докупайте серверы по одному - $3 за сервер в месяц, без перехода на старший тариф.

14 дней Pro бесплатно - без карты

Зарегистрируйтесь и попробуйте на своём сервере бан подсетей, уведомления в Telegram, GeoIP и общую базу угроз. По окончании аккаунт сам вернётся на Free, защита продолжит работать. Ничего не спишется, отменять нечего.

Включить пробный период
06Случаи

Когда защита Linux-сервера действительно необходима

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

0.0.0.0/022 · 21LISTEN 0.0.0.0$sshduptime 412dno consoleone host · always on

Когда необходимо защитить SSH-сервер на Linux

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

  1. 01

    SSH доступен откуда угодно, и пароли всё ещё работают

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

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

    • VPS или облачная машина, доступная по публичному адресу
    • Офисная машина за роутером, на которую проброшен порт 22
    • Сервер, который «временно» открыли ради миграции и так и не закрыли
    • Машина, чей адрес нигде не публиковали, но он всё равно попадает в сканируемый диапазон
  2. 02

    В облачном образе уже есть имя пользователя, известное всем

    Образы дистрибутивов и провайдеров приходят с заранее известной первой учётной записью: root на голом VPS, ubuntu в Ubuntu, ec2-user, debian, admin, pi. Половина задачи подбора - найти существующий логин - решена ещё до того, как машина закончила первую загрузку.

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

  3. 03

    На одном арендованном VPS живут сайт, база и резервные копии

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

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

    • Запаса нет: при компрометации проект не деградирует, а останавливается
    • Резервные копии часто лежат на том же диске - именно на это и рассчитан шифровальщик
    • Читать auth.log некому, и попытки копятся незамеченными
  4. 04

    Linux-машина - это роутер, NAS или прибор, который никто не считает сервером

    Межсетевой экран, сетевое хранилище, Raspberry Pi с кассовой программой магазина, контроллер в серверной, мини-ПК под столом, делающий резервные копии, - всё это Linux, на всём этом включён SSH, и ничего из этого не попадает ни в один список серверов.

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

  5. 05

    На том же хосте слушает FTP

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

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

    • Учётные записи FTP заводят подрядчику один раз и больше не пересматривают
    • Обычный FTP передаёт пароль по сети в открытом виде
    • Общая учётная запись для загрузки файлов, пароль от которой знает половина офиса
users triedrootadminubuntudeploypostgrestestpassword:PasswordAuthentication yesfailed9 999

Когда учётные записи и ключи перестают быть под контролем

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

  1. 06

    У разработчиков и подрядчиков свои логины

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

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

    • Ключи, добавленные ради одной выкладки и не удалённые после неё
    • Одна учётная запись на всех сотрудников подрядчика вместо записи на человека
    • О смене персонала у подрядчика вам никто не сообщает
  2. 07

    Учётные записи для деплоя и автоматизации не могут использовать второй фактор

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

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

  3. 08

    Парольный вход оставили «на всякий случай»

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

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

  4. 09

    Пароль уже есть в базе утечек

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

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

    • Пароль, одинаковый для серверной учётной записи и личного сервиса
    • Учётные данные, утёкшие из систем подрядчика, а не из ваших
    • Шаблоны, которые политика принимает, а словарь уже содержит: Лето2024!, Компания1
  5. 10

    Приватный ключ без пароля на чьём-то ноутбуке

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

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

/var/log/auth.log22:0023:0124:0225:0326:0427:0528:0629:07this month12 480blockedexported · signed

Когда вопрос ставят журнал, аудитор или хостер

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

  1. 11

    Аудитор, страховщик или заказчик спрашивает, как защищён удалённый доступ

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

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

    • Анкета киберстрахования перед выпуском или продлением полиса
    • Проверка поставщика крупным заказчиком перед подписанием договора
    • Требования к платёжным или персональным данным, предписывающие защиту от перебора
  2. 12

    auth.log и диск заполняются неудачными входами

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

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

  3. 13

    Списки блокировок, которые ведут вручную, стали отдельной работой

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

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

  4. 14

    Один администратор обслуживает серверы разных заказчиков

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

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

    • Машины разбросаны по нескольким провайдерам и адресным диапазонам
    • Заказчик, чей филиал нельзя блокировать никогда, как бы странно он ни выглядел
    • Передача дел между администраторами без потери причин, по которым настройка была сделана
  5. 15

    Связь с сервером ненадёжна, а защита должна держаться всё равно

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

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

07Вопросы

FAQ: когда нужна защита SSH от брутфорса

Безопасно ли ставить агент на боевой сервер?

Безопасно ли ставить агент на боевой сервер?

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

Работает ли защита без интернета?

Работает ли защита без интернета?

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

Что если я сменил порт SSH?

Что если я сменил порт SSH?

Агент определяет фактический порт SSH автоматически - по sshd_config и слушающим сокетам - и перестраивает правила при смене порта. Порт FTP определяется так же.

Могу ли я заблокировать сам себя?

Могу ли я заблокировать сам себя?

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

Какие дистрибутивы Linux поддерживаются?

Какие дистрибутивы Linux поддерживаются?

Любой современный дистрибутив на systemd - Debian, Ubuntu, RHEL/CentOS/Alma/Rocky, Fedora - на x86-64 и ARM64. Один статический бинарник без дополнительных зависимостей.

Как происходит оплата?

Как происходит оплата?

Оплата в России проходит через ЮKassa в рублях, международная - через PayPro Global, также доступна оплата криптовалютой. Тариф Free бессрочный и не требует карты.

Защита SSH с включённой парольной аутентификацией

Я оставил PasswordAuthentication включённой, а SSH слушает на публичном адресе Linux-сервера. В auth.log идут тысячи Failed password с разных IP и логинов, перенос порта 22 не помогает, а полностью закрыть доступ нельзя. Как мне настроить защиту SSH от перебора паролей до успешного входа?

С SSH Protector я устанавливаю агент как systemd-службу: он локально читает журнал аутентификации, определяет фактический порт sshd и после порога за окно времени блокирует сеть источника в системном фаерволе. Я заранее добавляю свой адрес или VPN в whitelist, контролирую историю в панели и сохраняю последнюю политику при потере интернета.

Бесплатно без SSH Protector я отключаю PasswordAuthentication и PermitRootLogin, оставляю ключи Ed25519, ограничиваю AllowUsers/AllowGroups и разрешаю порт только из VPN или доверенных CIDR. Если пароль временно обязателен, я настраиваю fail2ban по journald/auth.log, проверяю nftables/iptables, задаю findtime, maxretry и bantime и регулярно тестирую исключения с резервной консоли.

Защита стандартного логина облачного Linux-образа

Я развернул Ubuntu/Debian/RHEL из публичного cloud image, поэтому имя пользователя ubuntu, debian, ec2-user или root заранее известно ботам. Даже при хорошем пароле журнал заполнен целевыми попытками, а один ошибочно оставленный пароль делает аккаунт уязвимым. Как мне защитить SSH на облачном VPS со стандартным логином?

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

Бесплатно я запрещаю парольный и root-вход, создаю отдельного пользователя с sudo, загружаю уникальный ключ через cloud-init и закрываю Security Group до VPN/своих сетей. Я удаляю неиспользуемые authorized_keys, включаю MFA на bastion, настраиваю fail2ban и алерты по Accepted password/publickey для неизвестных источников; смену порта считаю только уменьшением шума.

Защита единственного Linux VPS с сайтом и базой

У меня один Linux VPS, где одновременно работают сайт, база данных и резервные копии, а SSH нужен для администрирования. Успешный вход под sudo-пользователем даст атакующему доступ ко всем слоям и позволит удалить локальные backup-файлы. Как мне защитить SSH на критичном VPS с минимальной нагрузкой?

С SSH Protector я ставлю статический агент, который читает локальные события и блокирует источник в фаерволе до компрометации учётной записи. Я использую бесплатную защиту первого сервера, включаю whitelist для своего канала и проверяю, что агент продолжает работать офлайн; резервное копирование и least privilege оставляю отдельными слоями.

Бесплатно я закрываю SSH за WireGuard/Tailscale, отключаю пароли и root, требую ключ с passphrase и ограничиваю sudo. Я храню резервные копии вне VPS с отдельными credentials, включаю автоматические security updates, fail2ban и аудит успешных входов; аварийную консоль провайдера проверяю до ужесточения фаервола.

Защита SSH на роутере, NAS и Linux-приборе

Я управляю Linux-роутером, NAS или ARM-устройством, которое не считаю полноценным сервером, но на нём работает sshd и порт доступен из внешней сети. Устройство редко обновляется, ресурсов мало, а компрометация даст опору внутри локальной сети. Как мне защитить SSH на маломощном Linux-устройстве?

С SSH Protector я использую поддерживаемый статический бинарник для подходящей архитектуры и systemd, включаю локальный анализ журнала и firewall-блокировку без входящего управляющего порта. Я проверяю совместимость ОС и фаервола до установки, задаю whitelist управления и слежу, чтобы агент не вытеснял ограниченные ресурсы устройства.

Бесплатно я вообще не публикую SSH наружу: подключаю устройство через VPN, запрещаю пароль и root, разрешаю один ключ и одну управляющую подсеть. Я обновляю прошивку, отключаю неиспользуемые службы, ставлю минимальный fail2ban только если хватает памяти и сохраняю конфигурацию фаервола; для неподдерживаемой ОС выбираю внешний шлюз, а не неизвестный бинарник.

Единая защита SSH и FTP на Linux

На Linux-хосте у меня открыты SSH и FTP, и боты перебирают оба сервиса через разные журналы. IP, заблокированный скриптом для sshd, продолжает атаковать FTP, а ручные iptables-цепочки расходятся. Как мне централизованно блокировать перебор паролей по SSH и FTP?

С SSH Protector я включаю чтение поддерживаемых журналов SSH и FTP, позволяю агенту определить порты и применяю единое локальное правило к сети источника. Я добавляю доверенные интеграции в whitelist, проверяю историю в панели и учитываю, что расширенная защита FTP и дополнительные функции могут зависеть от тарифа.

Бесплатно я заменяю обычный FTP на SFTP поверх SSH или FTPS, если протокол действительно нужен, и закрываю сервис от всего интернета. Я создаю отдельные jail fail2ban для sshd и FTP, направляю их в одну nftables set с timeout, проверяю формат журналов после обновлений и запрещаю общие учётные записи.

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

Я выдал разработчикам и подрядчикам отдельные Linux-логины и SSH-ключи, но часть ключей скопирована на личные ноутбуки, а список владельцев устарел. Мне нужно останавливать перебор, быстро отзывать человека и понимать, кто вошёл, не используя один общий ключ. Как мне защитить многопользовательский SSH-доступ?

С SSH Protector я оставляю автоматическую сетевую блокировку на всех внешних источниках и вношу в whitelist только контролируемый VPN, а не каждый домашний IP. Я использую панель для атак, но идентичность сохраняю в отдельных Unix-аккаунтах и ключах: агент защищает периметр, а отзыв доступа выполняю удалением конкретного ключа.

Бесплатно я веду authorized_keys централизованно через Ansible, выдаю по одному ключу на человека и устройство с понятным comment, запрещаю общий аккаунт и ограничиваю sudo. Я включаю VPN/MFA на bastion, задаю срок доступа в inventory, собираю Accepted publickey с fingerprint в SIEM и автоматически удаляю ключ по окончании договора.

Защита служебных SSH-аккаунтов без MFA

У меня есть deploy/backup-аккаунты, которыми пользуется CI и автоматизация, поэтому интерактивный MFA к ним неприменим. Их ключи должны работать без оператора, но компрометация runner или повторные пароли могут открыть сервер. Как мне защитить машинный SSH-доступ и не сломать deployment?

С SSH Protector я отделяю доверенные адреса runner через точный whitelist, а все остальные источники оставляю под блокировкой по неудачным входам. Я не считаю это заменой контроля ключа: агент сокращает перебор снаружи, пока ограничения самого служебного аккаунта сдерживают последствия успешной аутентификации.

Бесплатно я использую отдельный Ed25519-ключ на job, храню его в secret store, ограничиваю в authorized_keys через from=, command=, no-port-forwarding, no-agent-forwarding и no-pty. Я разрешаю SSH только из сети runner, выдаю минимальные sudo-команды, регулярно ротирую ключ и фиксирую fingerprint в журнале деплоя.

Безопасное отключение парольного входа по SSH

Я оставил парольный SSH-вход «на всякий случай», потому что боюсь потерять ключ или заблокировать себя после изменения sshd_config. В итоге PasswordAuthentication yes остаётся годами, а auth.log постоянно показывает подбор. Как мне перейти на SSH-ключи без риска потерять доступ к серверу?

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

Бесплатно я открываю вторую SSH-сессию и консоль провайдера, добавляю уникальный ключ, проверяю права ~/.ssh 700 и authorized_keys 600, запускаю sshd -t и reload, не закрывая первую сессию. Затем ставлю PasswordAuthentication no, KbdInteractiveAuthentication no и PermitRootLogin no, проверяю новый вход и сохраняю аварийный ключ отдельно.

Реакция на пароль SSH из утечки

Я узнал, что пароль Linux-пользователя есть в утечке, а в auth.log появились попытки с его именем из нескольких стран. Я не уверен, был ли успешный вход, потому что сервером пользуются из разных сетей. Как мне срочно закрыть перебор SSH и проверить компрометацию?

С SSH Protector я немедленно блокирую активные источники и сети, сверяю историю атак и оставляю доступ только через доверенный whitelist. Затем я меняю пароль/ключ, завершаю сеансы и отдельно анализирую Accepted password/publickey; блокировка уменьшает окно атаки, но не доказывает отсутствие уже успешного входа.

Бесплатно я временно закрываю SSH Security Group или nftables до VPN, блокирую пользователя, отзываю ключи и меняю связанные секреты. Я проверяю last/lastlog, journalctl, sudo, новые users/keys, cron/systemd units, процессы и сетевые соединения, затем восстанавливаю доступ только по ключам и запрещаю повторно используемые пароли.

Защита приватного SSH-ключа без passphrase

Я обнаружил приватный SSH-ключ без passphrase на ноутбуке сотрудника; ключ разрешён на нескольких серверах и мог попасть в backup или malware. Такой вход не создаст серию неверных паролей, поэтому обычный антибрутфорс его не остановит. Как мне ограничить ущерб и правильно защитить SSH-ключи?

С SSH Protector я продолжаю блокировать внешний перебор и вижу подозрительные источники, но не полагаюсь на него против корректного украденного ключа. Я немедленно удаляю fingerprint со всех серверов, выдаю новый ключ с passphrase и оставляю whitelist только для VPN; успешные входы расследую отдельно.

Бесплатно я ищу старый публичный ключ по всем authorized_keys, отзываю его конфигурационным управлением и проверяю Accepted publickey по fingerprint и источнику. Я выдаю аппаратный FIDO2/ed25519-sk или ключ с passphrase и ssh-agent timeout, запрещаю agent forwarding без необходимости и храню реестр владельца, устройства и даты ротации.

Подтверждение защиты SSH для аудита

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

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

Бесплатно я экспортирую sshd_config, nftables/ufw, fail2ban jail и журнал изменений из Git, а auth.log/journald отправляю в защищённое хранилище. Я ежемесячно проверяю PasswordAuthentication, PermitRootLogin, MFA/VPN и отзыв тестового ключа, подписываю результат и храню evidence за требуемый период.

Снижение объёма auth.log из-за SSH-брутфорса

Мой auth.log или journald заполняется Failed password и Invalid user, из-за ротации теряется полезная история, а парсер логов тратит ресурсы. Я не хочу отключать аудит, потому что успешный вход нужно расследовать. Как мне сократить поток событий перебора SSH?

С SSH Protector я блокирую источник в фаерволе после серии отказов, поэтому следующие TCP-соединения не доходят до sshd и не создают столько записей. Я сохраняю системный аудит, отдельно контролирую размер/retention journald и использую историю атак в панели как индекс, а не как замену исходному журналу.

Бесплатно я закрываю SSH до VPN/allowlist, отключаю пароли и стандартные логины, а fail2ban направляю в nftables set с timeout. Я настраиваю SystemMaxUse и ротацию journald/rsyslog, отправляю Accepted и ключевые Failed-события на внешний syslog и не уменьшаю LogLevel ниже значения, нужного для расследования.

Автоматизация Linux-блокировок вместо ручного blacklist

Я вручную копирую IP из auth.log в ufw/iptables, но адреса быстро меняются, старые правила не удаляются, цепочка растёт и одна ошибка может закрыть мой доступ. Поддержка blacklist стала отдельной ежедневной работой. Как мне автоматизировать блокировку SSH-брутфорса безопасно?

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

Бесплатно я заменяю отдельные вечные iptables rules на nftables set с timeout или fail2ban action, задаю maxretry/findtime/bantime и ignoreip для VPN. Я тестирую фильтр на реальных строках журнала, включаю recidive осторожно, ограничиваю размер набора и мониторю ошибки reload после обновления дистрибутива.

Управление защитой SSH у нескольких клиентов

Я обслуживаю Linux-серверы нескольких заказчиков на Debian, Ubuntu, RHEL и ARM, у каждого свои порты, доверенные сети и контакты. Локальные fail2ban и firewall-конфиги расходятся, а общий whitelist между клиентами недопустим. Как мне централизовать защиту SSH в мультиклиентском парке?

С SSH Protector я подключаю хосты поддерживаемым агентом, вижу обнаруженные порты и атаки из одной панели, но храню исключения и политику в границах нужного сервера/клиента. Я применяю базовые значения, отдельно документирую отклонения и направляю уведомления ответственному заказчика.

Бесплатно я описываю sshd, fail2ban и nftables ролями Ansible с отдельным inventory и vault каждого клиента, проверяю изменения в CI и собираю журналы в Wazuh/центральный syslog с tenant-тегами. Я автоматически сравниваю конфиг с baseline и никогда не объединяю ключи, CIDR и секреты разных заказчиков.

Автономная защита SSH при нестабильном интернете

Мой Linux-сервер стоит в филиале или за нестабильным каналом: облачная панель и DNS иногда недоступны, но SSH внутри или через проброшенный порт продолжает отвечать. Защита не должна ждать удалённого API для каждого решения. Как мне сохранить блокировку SSH-брутфорса офлайн?

С SSH Protector я заранее применяю политику на агенте; он продолжает читать локальный журнал и менять системный фаервол по последней конфигурации, когда связь с панелью потеряна. Я синхронизирую whitelist до отключения, проверяю накопленную историю после восстановления и не открываю входящий порт управления агентом.

Бесплатно я делаю контроль полностью локальным: nftables/ufw разрешает SSH только с VPN или нужных подсетей, а fail2ban работает по journald без внешней сети. Я сохраняю правила на загрузку, ставлю локальную очередь для уведомлений, тестирую перезапуск без DNS и оставляю физическую/провайдерскую консоль для восстановления ошибочного правила.

Замена fail2ban без разрыва в защите

На этом Linux-сервере fail2ban работает два года, jail для sshd исправен. Хочу попробовать вместо него управляемый агент, но оставить порт 22 без защиты даже на несколько минут нельзя, и не хочется, чтобы два инструмента дрались за одни и те же правила firewall. Как заменить fail2ban на SSH Protector без простоя?

Я ставлю агент SSH Protector, не останавливая fail2ban. У агента своя отдельная таблица nftables (inet sshprotector, на старых хостах — пространство имён ipset с префиксом), и он перестраивает только её, поэтому цепочек fail2ban не касается и ни один из двоих не откатывает другого. При установке я сразу добавляю свой адрес в белый список, затем сутки смотрю в панели, ловит ли агент те же источники, что и jail. Только после этого останавливаю fail2ban и убираю его правила. Если передумаю, удаление агента забирает его правила с собой и оставляет firewall прежним.

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

Выбор между CrowdSec и управляемым агентом

Сравниваю варианты защиты от брутфорса SSH для небольшого парка Linux-серверов, и всё время всплывает CrowdSec: открытый исходный код, общий блок-лист сообщества, охват шире, чем один SSH. Что SSH Protector делает такого, чего не делает CrowdSec, и как между ними выбирать?

Они решают пересекающиеся задачи с разных сторон, и я выбираю по форме, а не по баллам. CrowdSec — это движок с языком сценариев, отдельно устанавливаемыми компонентами блокировки и блок-листом, который наполняют все, кто его запускает; охват далеко выходит за SSH. SSH Protector — один бинарник, делающий одно: читает лог аутентификации SSH, SFTP и FTP, банит всю подсеть /24 атакующего в собственной таблице nftables, сохраняет бан после перезагрузки, определяет настоящий порт sshd вместо предположения о 22 и отчитывается в панель, которая скажет, когда защищённый сервер замолчал. Репутация делится между защищёнными аккаунтами, а не со всем интернетом.

То есть решение — про то, что у меня на самом деле есть. Нужна широта — HTTP, базы, произвольные источники логов, собственные сценарии детекта — у CrowdSec для этого есть место, и запуск ничего не стоит. Если же у меня несколько Linux-машин с открытым портом SSH и некому поддерживать стек детекта, мне нужна узкая вещь, которая права без настройки. Я не гонял их друг против друга на одном хосте, поэтому не выбираю по цифрам производительности — и тем, кто ими размахивает, тоже не стоит.

Защитите свой первый сервер уже сегодня

Тариф Free остаётся бесплатным навсегда. Перейти на платный тариф можно в один клик, когда понадобится.

08Доверие

Кто это пишет, кому вы платите и что агент может сделать на вашем сервере

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

Кто это пишет01

SSH Protector пишет Виктор Г. Бобров, ведущий специалист по безопасности серверов в Recovery Toolbox: 20+ лет в системной разработке и безопасности, сертификаты Microsoft MCSD/MCDBA. Правила обнаружения, логика банов и статьи на этом сайте - его работа, опубликованная под его именем, а не под безымянным брендом. Об авторе →

Кому вы платите02

Поставщик - File Master LLC, компания, зарегистрированная в Болгарии (ЕС): Bulstat/VAT 180842207, офис в Варне, доступна по телефону и почте. Платежи проводит PayPro Global как merchant of record; оферта, политика конфиденциальности и соглашение об обработке данных опубликованы полностью, а не в пересказе. Условия использования · Политика конфиденциальности · DPA

Что агент может и чего не может03

Агент читает журнал аутентификации SSH своего же хоста и пишет правила nftables на нём же. Он не открывает входящих портов, не имеет канала удалённых команд и наружу ходит только по HTTPS. Атакующих возможностей у него нет: ничем внутри него нельзя атаковать другую машину. Решение о бане принимается локально, поэтому защита работает и без связи с облаком, а ваш текущий IP попадает в белый список при установке - агент не может закрыть вам доступ к вашему же серверу. Установщик подписан. Как это работает →

09Ресурсы

Ресурсы: протокол, атаки и стандарты, внутри которых всё это находится

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

Ссылки ведут на сами источники: Wikidata там, где у сущности есть идентификатор, и первоисточник там, где его нет.

Recovery Toolbox / File Master LLC

Связаться с Recovery Toolbox

Контакты Recovery Toolbox и File Master LLC, а также профиль Виктора Г. Боброва, ведущего специалиста компании по безопасности.

Офис компании

File Master LLC - юридическое лицо, которое стоит за онлайн-сервисами и программными продуктами Recovery Toolbox.

File Master LLC
Serena app., office C13
Golden Sands, Varna, 9007
Болгария, Европейский союз
Булстат/НДС
180842207
Телефон
+359 88 2253194

О Recovery Toolbox

File Master LLC разрабатывает и поддерживает онлайн-сервисы и программные продукты Recovery Toolbox для восстановления повреждённых файлов, баз данных и почтовых форматов. Компания создаёт практичные инструменты восстановления для пользователей, ИТ-специалистов и бизнеса, которым нужно вернуть доступ к повреждённым данным.

Мы будем рады вашим замечаниям и предложениям. Пожалуйста, присылайте отзывы о сайте по электронной почте: webmaster@recoverytoolbox.com

Victor G. Bobrov, server security specialist and author of SSH Protector
Специалист по безопасности

Victor G. Bobrov

Специалист по безопасности серверов · 20+ лет в системной разработке и безопасности

Виктор Г. Бобров отвечает за безопасность в File Master LLC / Recovery Toolbox. Он проектирует логику обнаружения и блокировки в SSH Protector: чтение журнала аутентификации SSH, отличие брутфорса и распыления паролей от обычной опечатки, бан атакующей подсети одним правилом nftables и обмен репутацией атакующих между защищёнными парками серверов.

  • Защита от брутфорса
  • Харденинг Linux и SSH
  • nftables и сетевые политики
  • MCSD
  • MCDBA
Об авторе →

Сертификаты Microsoft

Microsoft Certified Solutions Developer - MCSD. Microsoft Certified Database Administrator - MCDBA.

MCSD MCDBA