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

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

Журнал SSH

Начните с самого сервера. На Ubuntu журнал службы SSH можно посмотреть так:

Ищите строки об отказах входа, например с Failed password или Invalid user, и адрес, с которого пришло подключение. Если таких строк за выбранное время нет, работу Fail2Ban по журналу пока не проверить: попыток просто не было. Можно повторить проверку после обычной неудачной попытки входа с другого устройства. Не включайте вход по паролю специально ради теста, если он уже отключён.

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

Источник событий Fail2Ban

Теперь проверьте jail sshd и источник событий, который он читает:

В разделе Filter ищите список файлов или Journal matches. Первый вариант означает чтение файлов журнала, второй указывает на systemd journal. Статус без ошибок ещё не подтверждает, что выбранный источник содержит нужные SSH-события.

Что делать, если jail читает не тот журнал?

Если jail читает файлы, узнайте их имена. Для чтения journal посмотрите условие отбора записей:

Сравните результат с тем, где вы увидели отказ входа. Если SSH пишет в journal, а jail следит за отсутствующим или неиспользуемым файлом, в уже существующей секции [sshd] файла /etc/fail2ban/jail.local можно указать:

Строку backend добавляют в существующую секцию, вторую секцию [sshd] создавать не нужно. После правки проверьте конфигурацию и перезапустите службу:

Если служба сообщает, что не может использовать backend systemd, проверьте наличие пакета python3-systemd. Для чтения journal Fail2Ban нужна библиотека Python для systemd, и без неё одной правки конфигурации недостаточно.

Проверка фильтра

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

Команда читает записи journal и показывает, сколько строк подошло под фильтр sshd. Для сервера, где jail читает файл /var/log/auth.log, укажите вместо systemd-journal этот путь. Проверять нужно тот источник, которым пользуется работающий jail.

Почему фильтр не находит ошибки входа?

Если совпадений нет, сначала убедитесь, что в выбранном источнике есть свежие отказы SSH. Затем сравните сами строки отказов с тем, что ожидает фильтр: после обновления OpenSSH формат записей может измениться, и тогда понадобится более свежий фильтр. Повышать maxretry здесь бессмысленно. Положительное число совпадений тоже требует внимания: команда может найти старые записи. Оно подтверждает работу фильтра на прочитанном журнале, но само по себе ничего не говорит о новых попытках и блокировке подключений.

Пороги и исключения

Когда фильтр распознаёт ошибки, проверьте пороги и исключения, которые действуют сейчас

Fail2Ban блокирует адрес, если за интервал findtime накопилось maxretry подходящих событий. Пять ошибок от пяти разных адресов не складываются в один бан. Если нужный адрес указан в ignoreip, jail его пропустит. Сверяйте исключения с адресом в журнале SSH, особенно после смены сети или провайдера.

Адрес для ignoreip смотрите в журнале SSH либо узнавайте на устройстве, с которого вы входите. Если отправить запрос к сервису определения IP с самого VPS, он покажет внешний адрес сервера. При часто меняющемся адресе постоянное исключение для администратора может оказаться бесполезным. Тогда главным запасным путём остаётся консоль провайдера.

Текущие счётчики и заблокированные адреса снова видны в статусе jail:

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

Проверка блокировки

Бан в статусе Fail2Ban показывает только решение программы заблокировать адрес. Применил ли его сетевой экран, видно по отказу нового SSH-подключения. Сначала узнайте, какое действие назначено jail:

Действие должно соответствовать сетевому экрану, который работает на VPS. По умолчанию, как правило, указано iptables-multiport. В этом случае Fail2Ban держит свои правила в отдельной цепочке f2b-sshd:

Если в списке стоит действие для nftables, его правила можно посмотреть так:

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

Как проверить бан с другого устройства?

Для контрольной проверки нужен клиент из другой сети, например с мобильным интернетом. Второй ноутбук в том же Wi-Fi обычно выходит в интернет с того же публичного адреса, что и основной. До бана убедитесь, что тестовый клиент входит по SSH, а его IP отсутствует в ignoreip.

Оставьте основной доступ к серверу и консоль провайдера. Узнайте внешний IP на тестовом устройстве, а затем на сервере временно заблокируйте именно его. Ниже указан адрес из диапазона для примеров. Перед выполнением замените его на адрес тестового клиента.

Проверьте, что адрес появился в статусе sshd, и попробуйте открыть с тестового устройства новое SSH-соединение. Уже открытый сеанс может сохраниться. Если вы заблокировали IPv4-адрес, убедитесь, что клиент не подключается к серверу по IPv6. Сразу после этого снимите бан:

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

После проверки

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

Исследователи Hunt.io раскрыли операцию, которую назвали CameraSwarm. В период с 17 июня по 22 июля 2026 года один оператор скомпрометировал более 14 530 IP-камер Dahua.

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

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

Самое интересное произошло 23 июля: оператор оставил открытым HTTP-каталог на собственном сервере 154.86.119.60. Hunt.io обнаружил его и скачал практически всю рабочую среду атакующего: 2616 файлов в 234 каталогах общим объёмом около 407 МБ.

Внутри оказались исходники инструментов, логи, базы результатов сканирования, данные с камер и отдельный Windows-бинарник, который исследователи классифицировали как SalatStealer.

Как работала CameraSwarm

Атака строилась сразу по нескольким направлениям.

1. Массовый брутфорс через порт 37777

Первый путь- сканирование камер через TCP-порт 37777, используемый Dahua для протокола Easy4IP.

Оператор использовал массовое сканирование и затем перебирал учётные данные. Один только brute-force-движок успел обработать 12 324 уникальных IP-адреса. Сначала сканировалось российское адресное пространство, затем весь IPv4.

У инструментария была интересная особенность: перед сканированием очередного диапазона оператор проверял местное время. Если оно не попадало в рабочее окно 09:00-16:59, диапазон пропускался.

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

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

2. Старые механизмы обхода аутентификации

Вторая ветка использовала две уязвимости Dahua- CVE-2021-33044 и CVE-2021-33045.

Через них оператор мог обойти аутентификацию и затем установить на устройство постоянную учётную запись:

p2pwn / p2password

Такой аккаунт хранится отдельно от обычного пароля администратора. Поэтому простая смена пароля не удаляет бэкдор.

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

Всего Hunt.io обнаружил признаки установки такого постоянного аккаунта примерно на 1923 камерах.

Здесь важно не путать реальные методы атаки с некоторыми обозначениями в инструментарии оператора. Hunt.io отдельно установил, что два CVE, указанных в некоторых компонентах этого набора, были промаркированы неправильно. Поэтому для этой операции корректнее опираться именно на подтверждённые CVE-2021-33044 и CVE-2021-33045, а не переносить все CVE-метки из найденного кода как достоверные.

3. Облачный P2P-релей Dahua

Третий путь оказался ещё интереснее.

Dahua позволяет подключаться к камерам через облачную P2P-инфраструктуру, используя серийный номер устройства, то есть без необходимости знать его внешний IP-адрес.

Оператор смог таким способом добраться как минимум до 283 камер.

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

Это не означает, что одного серийного номера всегда было достаточно для полного контроля камеры.

Серийный номер позволял получить доступ к P2P-реле и построить туннель до устройства. Для непосредственного управления камерой затем могли потребоваться валидные учётные данные или одна из уязвимостей обхода аутентификации.

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

Recovery-коды: ещё одна проблема

Отдельно Hunt.io обнаружил генератор offline recovery-кодов.

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

Это особенно неприятная особенность архитектуры: удаление установленного на камере аккаунта p2pwn не решает проблему с уже существующими recovery-кодами.

По данным Hunt.io, такие коды остаются действительными до тех пор, пока Dahua не изменит серверную логику их генерации и проверки.

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

Это был не полностью оригинальный набор инструментов

Исследование показало, что оператор не написал весь инструментарий с нуля.

Найденный набор представляет собой смесь собственного кода, модифицированных публичных инструментов и исследований других специалистов. Hunt.io связал компоненты как минимум с несколькими upstream-разработчиками и исследовательскими проектами.

При этом важно различать использование инструмента и его авторство.

То, что код найден в инфраструктуре оператора, доказывает его использование, но не означает, что именно этот человек написал первоначальную версию инструмента.

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

Оператор хранил результаты прямо на сервере

В открытом каталоге обнаружены не только исходники и скрипты.

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

Для передачи информации оператор использовал Telegram. Найденные учётные данные отправлялись в Telegram-бот, а снимки с камер сохранялись в рабочем каталоге.

Кроме того, результаты компрометации автоматически преобразовывались в формат, который можно импортировать в SMART PSS - штатную enterprise-платформу Dahua.

В итоге 13 229 записей были преобразованы в 52 XML-файла.

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

На том же сервере нашли Windows-стилер

Ещё одна находка оказалась напрямую не связана с компрометацией камер.

На сервере находился UPX-упакованный Windows-бинарник, который Hunt.io классифицировал как SalatStealer.

Исследователи рассматривают его как отдельную возможность оператора, а не как часть основной цепочки CameraSwarm.

На сервере также находился PowerShell-скрипт, предназначенный для отключения Microsoft Defender несколькими способами.

В частности, использовались изменения Group Policy, способные сохраняться после перезагрузки системы.

То есть сервер оператора фактически содержал сразу две разные возможности:

• инструментарий массового взлома камер Dahua;

• отдельный набор средств для компрометации Windows-систем.

Что это означает для владельцев Dahua

Для владельцев камер Dahua и совместимых устройств ситуация неприятная по двум причинам.

Первая- наличие старых механизмов обхода аутентификации.

Вторая- архитектура P2P-доступа и recovery-механизмов, которые нельзя устранить простой сменой пароля камеры.

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

Поэтому для владельцев Dahua и совместимых ребрендированных устройств например, Amcrest, Lorex, Annke, Swann и других моделей на соответствующей платформе — стоит проверить конфигурацию отдельно.

Что делать

- Проверьте, нет ли на камере неизвестной учётной записи p2pwn / p2password.

- Если P2P-функция вам не нужна , то отключите её.

- Установите актуальную прошивку, закрывающую известные уязвимости.

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

- Проверьте журналы доступа и сетевую активность камер.

- Если камера ранее была доступна из интернета напрямую, проверьте её конфигурацию особенно внимательно.

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

- Учитывайте проблему recovery-кодов: её устранение зависит не только от настроек конкретной камеры, но и от серверной логики Dahua.

Главное

CameraSwarm показывает неприятную закономерность: для массового захвата IoT-устройств злоумышленнику необязательно искать неизвестные zero-day.

В этой операции использовались:

- старые уязвимости;

- слабая или отсутствующая аутентификация;

- открытые P2P-механизмы;

- автоматизированное сканирование;

- готовые публичные инструменты;

- и обычная ошибка самого оператора — открытый каталог на сервере.

В результате один оператор за 35 дней получил доступ более чем к 14 530 камерам Dahua.

И самое показательное здесь даже не число камер.

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

Подпишись на мой ВК и Дзен и астрологи объявят неделю изобилия до конца года)

Источник: hunt.io

▪В случаях, когда невозможно изменить порт, можно ограничить доступ к SSH определенными пользователями или группами. Это можно сделать с помощью параметров AllowUsers, AllowGroups, DenyUsers и DenyGroups в файле sshd_config. Логину также можно указать IP или подсеть. Например, можно разрешить доступ пользователю admin и user, при этом последний может подключаться только с одного IP.

AllowUsers admin user@192.168.0.1

▪Еще один действенный вариант защиты от перебора – использование для аутентификации сертификатов.

Например, запретим вход по SSH по паролю для пользователя root, разрешив всем остальным:

# всем разрешаем доступ по паролю

PasswordAuthentication yes

# root будет использовать только сертификат

match user root

PasswordAuthentication no

KbdInteractiveAuthentication no

▪Используя TCP Wrapper, также можем ограничить доступ к любому сервису только с определенных IP, для этого следует лишь прописать в файл /etc/hosts.allow или /etc/hosts.deny нужное правило. Разрешим в /etc/hosts.allow доступ только с нужной подсети:

sshd : 192.168.1.0/24 : allow

Или в /etc/hosts.deny:

sshd : ALL : deny

sshd : ALL EXCEPT 192.168.1.0/24 : allow

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

iptables -A INPUT -s !192.168.0.1 -p tcp -m tcp --dport 22 ↵

-j REJECT —reject-with icmp-port-unreachable

▪Fail2ban и Sshguard - специальные утилиты, которые помогают защитить систему от подозрительных действий. Эти программы фильтруют пакеты по портам и IP-адресам и блокируют подозрительные IP-адреса, используя iptables или TCP Wrapper.

Fail2ban был создан для защиты SSH, но сейчас он может быть настроен для использования с различными приложениями. Принцип работы очень прост - демон периодически проверяет журналы на наличие записей о подозрительной активности и блокирует подозрительные IP-адреса.

По умолчанию Fail2ban защищает только SSH, но может быть настроен для контроля нескольких сервисов одновременно. Все события отображаются в журнале fail2ban.log и могут быть отправлены по электронной почте.

В Ubuntu и Debian устанавливается командой:

$ sudo apt-get install fail2ban

▪Все настройки производятся в нескольких файлах, размещенных в каталоге /etc/fail2ban. В fail2ban.conf хранятся параметры запуска самого демона, в jail.conf описываются контролируемые сервисы (внутри секции SSH).

[ssh]

enabled = true

port = 22

filter = sshd

logpath = /var/log/auth.log

maxretry = 3

▪Фильтры и действия настраиваются в файлах в подкаталогах filter.d и action.d. Файлы по умолчанию имеют расширение .conf и их лучше не изменять, включая jail.conf. Лучше все изменения делать в файле с расширением .local (например, jail.local), который переопределяет настройки из первого файла и сохраняет их при обновлении. Для проверки работы фильтра можно использовать утилиту fail2ban-regex.

Мы в телеграме!