Существуют различные варианты попыток защиты\сокрытия сервисов от "любопытных глаз". Основные: использование нестандартного порта, fail2ban, ACL и tarpit (и их сочетание).
Есть ещё port knocking. Но, очень часто эта технология оказывается не используемой. Где-то из-за незнания технологии (хотя, статей хватает). Но, чаще из-за проблем на практике, которые мешают её внедрению:

• сложности использования технологией неподготовленным пользователям;

• фильтрация трафика (как на стороне клиента, так и сервиса);

• несогласованность с другими отделами безопасности (трафик для port knocking может считаться зловредным);

• «раздувание» сгенерированных правил.

Часто игнорирование port knocking приводит к тому, что задачи по безопасности пытаются решать другими технологиями. Что приводит к решениям, простота и эффективность которых вызывает вопросы. Усугубляется это частым отсутствием знаний в области наступательной безопасности: непониманием как атакующие могут обходить средства защиты. Я за годы работы пентестером и архитектором безопасности очень полюбил port knocking и нашёл варианты решить самые частые проблемы с его использованием. Ими и хочу поделиться.

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

Нестандартный порт, fail2ban, ACL, tarpit

Прежде, чем перейдём к port knocking, давайте обсудим эффективность других техник (если уже знаете: что это и какие там проблемы - пропускайте эти спойлеры).

Нестандартный порт

Самый банальный вариант. Надежда на то, что номер порта не попадает в топ стандартных портов для сканирования. И потому злоумышленнику потребуется сканировать до 65535 портов, чтобы обнаружить сервис (а там, глядишь - какая-нибудь система защиты его заблокирует и результат сканирования будет неполноценным). Как можно увидеть из анализа от поисковика Shodan - такие порты также можно обнаружить.

картинка с топ 15 портов для SSH по версии Shodan (на момент публикации)

Принцип работы port knocking

Название технологии и передаёт её суть: постучись в мою дверь порты. Можно сравнить с кодовым замком: некая последовательность обращений на определённые порты даст сигнал, что пользователь легитимный. Такого пользователя добавляют в ACL (статический или динамический). При этом правильная последовательность обращений должна произойти за определённое время. В дальнейшем появился вариант с размером ICMP пакета вместо номера порта. Реализовать можно как на уровне маршрутизаторов (пример для MikroTik), так и на хостовой системе (даже для Windows). Для Linux систем популярный вариант - knockd.

Варианты port knocking:

• разные TCP\UDP порты (классика);

• последовательность ICMP пакетов разного размера;

• прозрачный (я его так называю): последовательное обращение на один и тот же порт сервиса.

Для ICMP нужную последовательность можно отправить через команду ping. Для TCP - netcat, telnet клиент или клиент knock. Для UDP - netcat или клиент knock.

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

Проверить, что порт сервиса (защищённый через port knocking) не виден при сканировании можно через nmap:

nmap -vv -sS IP-адрес -p номер_порта

Обнаружение использования Port knocking атакующим

Port knocking может быть преодолён в случаях:

• злонамеренный сотрудник может сообщить об этом средстве защиты потенциальным злоумышленникам;

• атакующий обнаружил аномалии на сетевом оборудовании.

Иллюстрация к последнему пункту

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

Проблемы с использованием port knocking на практике

Самая частая проблема: не все пользователи готовы к каким-то лишним действиям перед обращением к сервису. Если port knocking создаёт пользователь сам для себя - вопрос не возникает. А другим пользователям такое "ноухау" часто кажется лишним\неудобным. Автоматизация действия для пользователя подразумевает:

• передачу исполняемых файлов (опционально - зависит от того, каких приложений в ОС пользователя не хватает);

• передачу скрипта, создающего сетевые пакеты по нужному правилу;

• использование инструкции ("перед подключением к сервису запустите скрипт, убедитесь в наличие необходимых приложений и т.д.").

Не редкость также и фильтрация трафика с клиентской стороны. Особенно актуально, если клиент использует общедоступный Wi-Fi.

Несогласованность port knocking с другими отделами безопасности организации - тоже частая история. Обращение по нескольким портам к одному IP-адресу за ограниченный промежуток времени часто воспринимается как сканирование. За что бан (и, как следствие, недоступность сервиса для клиента). Бывают случаи, когда службы безопасности начинают внедрять защиту, просто блокируя весь трафик, кроме отдельных портов. Верный признак такого подхода - необходимость сообщить куда-либо: какие IP-адреса используются и какие сервисы на них находятся. Попытки добавить туда порты для port knocking ("а вот на этих портах ничего нет, но они мне нужны для port knocking") - часто встречают непонимание. Может показаться, что для ICMP проблемы не будет. Но, я несколько раз встречался с внезапной блокировкой ICMP. Как оказывалось - причина в желании защититься от ICMP-сканирования (логика: если адрес не отвечает на ping - то и сканировать его будут реже). Но, при этом происходит блокировка всех ICMP пакетов. Хотя, можно было заблокировать только ответы: ICMP reply (и это никак не помешало бы port knocking). Иногда ICMP блокируют для предотвращения туннелей, благодаря которым атакующие могут обходить правила МСЭ для развития успешной атаки.

Прозрачный port knocking

Кажется, что проблем так много, что от port knocking лучше вообще отказаться (что я часто и наблюдал на практике). Но, есть ещё вариант, избавленный от вышеуказанных недостатков. Идея заключается в последовательном обращении на один и тот же порт сервиса несколько раз. Изначально вариант я придумал, как "костыль", для одного проекта. Но, присмотревшись к результатам и вспомнив минусы других вариантов port knocking, понял, что это совсем не "костыль".

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

В общем виде, прозрачный port knocking избавлен от вышеуказанных недостатков. Т.е.:

• не требует лишних действий от пользователя;

• реже блокируется средствами защиты (я с такими случаями не встречался вообще).

Минусом варианта можно назвать необходимость ожидания времени, пока клиентское приложение отправит нужное количество запросов (подробности чуть ниже).

Я сделал скрипт для создания прозрачного port knocking. Несколько знакомых, которые пользуются этим скриптом, подтвердили, что со временем порт сервиса исчез из результатов Shodan и Censys (не стоит забывать, что у некоторых поисковиков есть история, которая "всё помнит").

Пример истории IP-адреса в Censys

Один из главных вопросов, который возникает при внедрении: сколько повторов нужно указать в конфиге port knocking для конкретного клиентского ПО? И сколько времени нужно будет ожидать клиенту? Ответ стоит искать на практических тестах. Например, для OpenSSH сервера (Ubuntu 22.04) подключение стандартным клиентом с другого сервера (также Ubuntu 22.04) в локальной сети показало: 3 повтора - 3 секунды ожидания. 6 повторов - 6 сек.
Для определения такой задержки (перед попаданием адреса клиента в ACL) рекомендуется провести практический тест. Например, запустить knockd в дебаг режиме и засечь время (сколько пройдёт до добавления адреса клиента) после запуска клиентского софта. Для такого теста даже сам сервер не требуется.

Запуск knockd в дебаг режиме

Что касается количества повторов. Я рекомендую не менее 3-х: несмотря на то, что сканер nmap не увидел открытым порт, защищаемый через port knocking с 2-я повторами, возможно, какие-то сканеры могут при каких-то обстоятельствах отправлять 2 запроса. И нужно помнить, что 1 повтор равносилен отсутствию повтора - как если бы port knocking вообще не было.

Результат сканирования через nmap при 2-х повторах

"Раздувание" правил port knocking

Некоторые реализации port knocking могут приводить к "раздуванию" правил МСЭ. Например, knockd с указанными в документации параметрами добавляет в список iptables правило. Т.е. каждый раз при срабатывании правила новый IP-адрес клиента будет увеличивать список правил iptables. Даже учитывая вариант с ограниченным временем жизни записей: если потенциальных клиентов много - в конкретный момент список iptables будет выглядеть перегруженным. Для решения этой проблемы можно использовать ipset. В этом случае у нас будет всего 1 правило. А все адреса будут в едином списке. И, вроде как, это ещё будет и эффективней про производительности (если статья с 2010 года не потеряла актуальности). Максимальное время жизни записи в ipset - 2147483 секунды (примерно 24 суток). Сам ipset также предотвращает добавление дублирующихся адресов в список (во всяком случае, с параметром hash:ip).

ipset create your_name_ACL hash:ip timeout 10

command = /usr/sbin/ipset -q add your_name_ACL %IP% timeout your_seconds

Лично мне на практике не доводилось вносить через port knocking более пары десятков адресов. Поэтому возникает вопрос: что там с производительностью при большом количестве записей? Я сделал небольшой тест. Добавил 10 000 сгенерированных записей (IPv4 адреса) в ipset. Согласно выводу ipset list используемая память увеличилась с 200 байт (когда 0 записей) до 240 872 байт (когда 10 000 записей). Далее я запустил knockd и сравнил сколько времени уйдёт на прозрачный port knocking. Т.е. к 100 000 записей добавилась ещё одна (после срабатывания port knocking). Время ушло примерно столько же, как при одной записи.

Потребление памяти ipset

port knocking в docker контейнерах

Давайте разберём причины почему стоит присмотреться к такому варианту. Первое, что приходит в голову: port knocking можно настроить и на хостовой системе. Зачем делать в контейнере?
Основное - не хочется перегружать правилами МСЭ хостовой системы. Чем больше правил - тем проще в них запутаться и в итоге ошибиться при очередной их модификации (о чём уже говорил в разделе Access Control List). В Ubuntu 22.04 после установки docker создаётся порядка 30 строк правил. Наверняка на хост системе есть ещё какие-то правила (в т.ч. для других контейнеров). Т.е. итоговый список правил уже не маленький.

     1	# Generated by iptables-save v1.8.7 on Wed Oct 30 17:59:12 2024
     2	*filter
     3	:INPUT ACCEPT [0:0]
     4	:FORWARD DROP [0:0]
     5	:OUTPUT ACCEPT [0:0]
     6	:DOCKER - [0:0]
     7	:DOCKER-ISOLATION-STAGE-1 - [0:0]
     8	:DOCKER-ISOLATION-STAGE-2 - [0:0]
     9	:DOCKER-USER - [0:0]
    10	-A FORWARD -j DOCKER-USER
    11	-A FORWARD -j DOCKER-ISOLATION-STAGE-1
    12	-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
    13	-A FORWARD -o docker0 -j DOCKER
    14	-A FORWARD -i docker0 ! -o docker0 -j ACCEPT
    15	-A FORWARD -i docker0 -o docker0 -j ACCEPT
    16	-A DOCKER-ISOLATION-STAGE-1 -i docker0 ! -o docker0 -j DOCKER-ISOLATION-STAGE-2
    17	-A DOCKER-ISOLATION-STAGE-1 -j RETURN
    18	-A DOCKER-ISOLATION-STAGE-2 -o docker0 -j DROP
    19	-A DOCKER-ISOLATION-STAGE-2 -j RETURN
    20	-A DOCKER-USER -j RETURN
    21	COMMIT
    22	# Completed on Wed Oct 30 17:59:12 2024
    23	# Generated by iptables-save v1.8.7 on Wed Oct 30 17:59:12 2024
    24	*nat
    25	:PREROUTING ACCEPT [0:0]
    26	:INPUT ACCEPT [0:0]
    27	:OUTPUT ACCEPT [0:0]
    28	:POSTROUTING ACCEPT [0:0]
    29	:DOCKER - [0:0]
    30	-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
    31	-A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER
    32	-A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE
    33	-A DOCKER -i docker0 -j RETURN
    34	COMMIT
    35	# Completed on Wed Oct 30 17:59:12 2024

Во-вторых, добавление правила в контейнер происходит независимо от настроек хостовой системы (единственное: запускать докер контейнер нужно с капой NET_ADMIN). Это означает, что port knocking на контейнере будет работать, даже если на хостовой системе будут случайно ослаблены правила МСЭ из-за человеческого фактора (о чём говорили в разделе Access Control List).

Установка зависимостей (iptables, ipset, knockd) требует root привилегий, не забудьте после этого вернуть контейнер к непривилегированному пользователю.
В некоторых статьях делают port knocking для привилегированного докер контейнера. Это не лучшая идея: сильно понижается безопасность и крайне не рекомендуется.

Большая проблема на практике: когда уже есть безопасный жизненный цикл разработки - модифицировать его, добавив выше указанный port knocking. Часто в этом не видят необходимости: админы/SOC же должны настраивать/(следить за) безопасностью сети.

Спорные практики защиты

Здесь обсудим варианты, когда port knocking был бы полезен, но, игнорируется. Что приводит к иным вариантам защиты, эффективность которых вызывает вопросы.

Статический ACL и сервис на нестандартном порту мы уже обсудили (к слову, ничего не мешает совместить нестандартный порт и port knocking).

Торчащие наружу порты корпоративной почты
Их пытаются защищать через fail2ban или иным образом определять аномалии с конкретного IP-адреса. Вообще, хорошая практика для корпоративной почты - убрать все порты (кроме 25-ого) за VPN. А сам порт VPN уже можно закрыть через port knocking.
Сервисам корпоративной почты (кроме 25-ого порта) незачем быть доступными всем желающим. Случаев атак на почтовые сервисы было много разных. Навскидку можно вспомнить Zimbra CVE-2019-9621. И Heartbleed - CVE-2014-0160 (одними из первых из-за уязвимости пострадали в т.ч. общедоступные почтовые сервисы). А вот с CVE-2024-45519 port knocking не поможет т.к. уязвим порт 25, который должен быть общедоступен (для возможности получать почту с других доменов).

Блокировка аккаунта при лимите на подбор
Периодически в том или ином виде эта мысль возникает (свежий пример). Полезность сомнительна. По идее - должен баниться IP-адрес (с которого брутфорс), а не аккаунт. Иначе может случиться ситуация, когда из-за действия злоумышленника легитимный пользователь не может зайти: злоумышленник периодически пытается авторизоваться в бесконечном цикле (с паузами). Что приводит к перманентной блокировке аккаунта. Банить IP-адрес может быть неэффективным в случае брутфорса с помощью ботнета (т.е. с разных IP-адресов). Найти правильный логин для перебора не всегда проблема: как минимум из-за возможных утечек. А часто логин совпадает с логином из корпоративной почты (который не является секретом и может быть засвечен где угодно). Бытует мнение, что SOC\SIEM системы должны как-то помочь от наплыва такого брутфорса (это в дополнение к бану аккаунта). Но, тут возникают вопросы: точно ли хорошо известно: как именно работает SOC\SIEM? Возможно, блокировка аккаунта - не всегда плохая идея. Например, для публичного веб сервиса. Но, для приватного сервиса ситуация: "давайте подождём недельку - пока брутфорс не закончится или SOC не внедрит механизмы от перебора со стороны ботнета", - звучит не очень приемлемо для бизнес-процесса. Конкретно для SSH можно начать с port knocking. И если вдруг этого недостаточно - тогда думать о дополнительных мерах.

Отсутствие защиты внутри локальной сети
Частый случай - когда сервис недоступен из интернета. Но, внутри локальной сети он не защищён. Если злоумышленник получил доступ в локальную сеть (через иной уязвимый сервис, доступный через интернет, например, что не редкость) - он может попытаться обнаружить иные сервисы в этой локальной сети. Например, сканирование внутренней сети через SSRF. В такой ситуации применение port knocking оправдано для воспрепятствования обнаружению сервиса потенциальным атакующим.

Распределённые системы
Для таких систем характерно периодическое изменение количества узлов. Например, консорциумный блокчейн Hyperledger Fabric имеет непростую организацию сети. И частая ситуация - изменение участников сети: как количества организаций, так и узлов внутри одной организации. Один из вариантов - ACL. Но, на практике он используется не всегда. Я не редко встречаю узлы в этого блокчейна в интернете (т.е. они общедоступны). А самое печальное: в ряде случаев можно удалённо остановить бизнес-процесс используя известную уязвимость (т.к. используется устаревшая версия ПО).
В таких случаях port knocking был бы полезен: можно усложнить обнаружение атакующими и убрать узлы из результатов выдачи поисковиков вроде Censys.
А для открытых блокчейнов смысла использовать port knocking не вижу: там как раз смысл в том, что узлы должны быть общедоступны (исключение: сервисы для чисто администраторских операций).

Заключение

Безусловно, port knocking, как и любая технология, не является "серебряной пулей". И в общем смысле не является заменителем какой-то другой. Но, используя port knocking совместно с другими решениями, можно существенно повысить безопасность сервисов. Внедрение данной защиты также потенциально увеличит доступное время для устранения уязвимости (пока её не начнут пытаться эксплуатировать на защищаемом сервисе). Использование port knocking также приводит к уменьшению логов. А, значит, логи проще обрабатывать. Также стоит отметить определённые требования к квалификации специалиста, которому надлежит внедрять port knocking. Как минимум ему нужно знать базовые принципы работы сетей и МСЭ. А также понимать: как внедрить один из вариантов port knocking в уже существующие правила МСЭ (не ухудшив изначальную настройку в части безопасности и работоспособности сервисов).

Надеюсь, что практические варианты, рассмотренные в статье, приведут к повышению частоты использования данной технологии. Также советую, при выборе любых вариантов защиты, консультироваться со специалистами по наступательной безопасности: они могут подсказать варианты обхода средств защиты, которые не были учтены. А вот конкретный выбор средств усиления защиты по итогу этой консультации лучше оставить для специалистов, понимающих ценность user frendly (разработчиков, архитекторов сервисов, специалистов по оборонительной безопасности - в зависимости от реализации разработки в конкретной компании). Иначе средство защиты без учёта user frendly может получится как в анекдоте: безопасно, но пользоваться невозможно.