Практические варианты использования port knocking
Существуют различные варианты попыток защиты\сокрытия сервисов от «любопытных глаз». Основные: использование нестандартного порта, fail2ban, ACL и tarpit (и их сочетание).
Есть ещё port knocking. Но, очень часто эта технология оказывается не используемой. Где-то из-за незнания технологии (хотя, статей хватает). Но, чаще из-за проблем на практике, которые мешают её внедрению:
‣ сложности использования технологией неподготовленным пользователям;
‣ фильтрация трафика (как на стороне клиента, так и сервиса);
‣ несогласованность с другими отделами безопасности (трафик для port knocking может считаться зловредным);
‣ «раздувание» сгенерированных правил.
Часто игнорирование port knocking приводит к тому, что задачи по безопасности пытаются решать другими технологиями. Что приводит к решениям, простота и эффективность которых вызывает вопросы. Усугубляется это частым отсутствием знаний в области наступательной безопасности: непониманием как атакующие могут обходить средства защиты. Я за годы работы пентестером и архитектором безопасности очень полюбил port knocking и нашёл варианты решить самые частые проблемы с его использованием. Ими и хочу поделиться.
Исходная задача: уменьшить количество несанкционированных обращений к сервису (в идеале — исключить полностью). При этом не мешая легитимным обращениям.
Навигация по содержанию статьи
Нестандартный порт, fail2ban, ACL, tarpit
Прежде, чем перейдём к port knocking, давайте обсудим эффективность других техник (если уже знаете: что это и какие там проблемы — пропускайте эти спойлеры).
Нестандартный порт
Самый банальный вариант. Надежда на то, что номер порта не попадает в топ стандартных портов для сканирования. И потому злоумышленнику потребуется сканировать до 65535 портов, чтобы обнаружить сервис (а там, глядишь — какая-нибудь система защиты его заблокирует и результат сканирования будет неполноценным). Как можно увидеть из анализа от поисковика Shodan — такие порты также можно обнаружить.
картинка с топ 15 портов для SSH по версии Shodan (на момент публикации)fail2ban
Это утилита, задача которой — анализировать логи по некоторому алгоритму для выявления и передачи IP-адресов для дальнейшей блокировки (например, через iptables). Это означает, что в логах уже что-то подозрительное должно быть. По какому принципу это делается — зависит от конфигурации. Чаще всего это сканирование или брутфорс. Для каждого защищаемого сервиса нужна своя конфигурация. Соответственно, качество защиты fail2ban зависит от качества написания конфигураций для каждого сервиса. Что предполагает и уровень компетенции специалиста, создающего правила для сервисов. Т.е. чем больше сервисов — тем выше требования к специалисту (или этим должны заниматься несколько специалистов).
Проблема в том, что в современном мире атакующему далеко не всегда нужно заниматься самостоятельным сканированием множества портов. Можно воспользоваться поисковиками типа Shodan, чтобы получить информацию о портах по интересующему диапазону IP-адресов. В случае необходимости — атакующий всегда может самостоятельно сканировать, опираясь на результат Censys\Shodan и иной информации для выявления и обхода срабатывания fail2ban. Что касается бана (например, при брутфорсе) — довольно часто факт бана можно обнаружить по поведению. После чего сменить IP-адрес (сменив VDS, арендовав прокси серверы или ботнеты) и постепенно настроить логику работы атакующего софта на менее подозрительную: сделать паузы между попытками обращения, распределить перебор между разными устройствами. Допустим, нужно перебрать 100 паролей. Если бы не было ботнета — нужно было бы делать большие паузы между запросами с одного IP. Используя ботнет — с множества адресов (смотря, какого размера ботнет) будет по 1 запросу (от каждого адреса свой уникальный запрос). Т.о. брутфорс будет идти в обход fail2ban. То же касается и сканирования: ботнет может решить вопрос блокировки. Особенно когда используется подход: один адрес сканирует подсеть на 1 порт (т.о. решается вопрос бана при нескольких запросах на разные порты на один адрес).
Access Control List (ACL, статический)
Также известен как «белый список». Это список IP-адресов, которым разрешён доступ к сервису. У разных сервисов может быть свой список, задаваемый в конфигурационном файле сервиса (если он это поддерживает). А можно настроить списки адресов непосредственно на маршрутизаторе (т.е. между сервисом и интернетом, например).
Т.о. доступ к сервису с адресов вне этого списка будут теоретически невозможным (если не учитывать несанкионированный доступ к одному из узлов в списке ACL). Основная проблема на практике — списки нужно поддерживать в актуальном состоянии: кого-то добавить, кого-то удалить. И часто есть пауза (временной интервал) перед изменением списка: пока узнаешь адрес, пока его внесёшь. Особенно проблема с удалёнщиками и командируемыми: у них IP-адреса меняются (в т.ч. из-за использования мобильного оператора). Именно эти проблемы часто и приводят к решению выше: вместо ACL сделать сервис общедоступным, но на нестандартном порту.
Ну, и частая проблема при работе с МСЭ — человеческий фактор: периодические сложности с поддержанием правил в верном состоянии. Инфраструктура меняется, правила МСЭ «раздуваются» + админы в организации могут поменяться (новый админ может не разобраться во всех правилах и что-то поменять, что скажется на логике защиты). А бывает, что и оптимизации правил хочется (и в результате модификаций могут случайно нарушить логику безопасности, задаваемую изначальными правилами). К слову — оптимизации могут проходить прям очень долго. Всё это приводит к тому, что на некоторое непределённое время изначальная логика правил может измениться и сказаться на ослаблении безопасности. О чём прекрасно осведомлены опытные атакующие (если речь о целенаправленных атаках на конкретную организацию), которые делают «канареек»: некий цифровой снимок результатов сканирований. Сканирование повторяется с некоторой регулярностью. И если в результате очередного сканирования что-то поменялось (появились новые открытые порты, например) — это знак о возможном изменении правил безопасности. В таких случаях планируется атака на выявленный сервис (на основании ранее собранной информации).
tarpit и ханипоты
Это общее название средств, призванных «вставить палки в колёса» атакующим при разведке. Вариантов реализации много. Подход может сработать в случае поиска любой наименее слабой цели в интернете. Но, при целенаправленной атаке не слишком эффективен. Я на практике часто встречал вариант, когда при SYN сканировании все порты оказывались якобы открыты. Идея в том, что атакующий (увидев сотни или тысячи открытых портов) запутается и не найдёт реально работающий сервис. На самом деле, именно в таком подходе проблемы у опытных атакующих нет: просто изначально отбрасываем сервисы, у которых не обнаружены баннеры (оставляя их «на потом»). Если сервисов с банерами вообще нет — значит, при сканировании сработали механизмы защиты. Или на IP-адресе вообще нет сервисов. При целенаправленном пентесте организации делаем пометку об этом и, в случае необходимости, возвращаемся к IP-адресу, когда будет больше информации об инфраструктуре вследствие других исследований сети.
Касаемо утверждения про замедление сканирования из-за бесконечного потока данных в ответах со стороны некоторых ханипот решений — я не особо верю в их эффективность в настоящее время: ничего не мешает внедрить таймаут на подключение.
Принцип работы 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 может быть преодолён в случаях:
‣ злонамеренный сотрудник может сообщить об этом средстве защиты потенциальным злоумышленникам;
‣ атакующий обнаружил аномалии на сетевом оборудовании.
Иллюстрация к последнему пункту
Атакующий перехватывает трафик и выявляет 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, понял, что это совсем не «костыль».
История про «костыль»
Заказчик хотел некий веб сервис (суть его не важна) с детектом нелегитимных обращений. Сервис представлял собой несколько файлов типа *.php с ограниченным набором параметров для GET\POST. Любое обращение вне этих параметров (в т.ч. обращение к несуществующим файлам) считалось нелегитимным и вносилось в журнал. Т.к. сервис был на VDS на стандартном порту - в логи часто попадали всякие сканеры\боты\краулеры. А сам факт наличия не пустого лога начинал вызывать раздражение у заказчика: мол, про его сервис кто-то узнал и пытается его атаковать (интерпретация заказчика). "Перевешивать" сервис на нестандартный порт заказчик не желал. Сначала пытались внедрить fail2ban. Но, это не полностью решило проблему: хотя бы одно обращение от краулера до его блокировки было в логах. Можно было спорить с заказчиком, объясняя что таковы реалии интернета. Но, решили пойти на хитрость: вспомнили про 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-х повторах
Порт выглядит недоступным
Правило для 2-х повторов в knockd при сканировании nmap
«Раздувание» правил port knocking
Некоторые реализации port knocking могут приводить к «раздуванию» правил МСЭ. Например, knockd с указанными в документации параметрами добавляет в список iptables правило. Т.е. каждый раз при срабатывании правила новый IP-адрес клиента будет увеличивать список правил iptables. Даже учитывая вариант с ограниченным временем жизни записей: если потенциальных клиентов много — в конкретный момент список iptables будет выглядеть перегруженным. Для решения этой проблемы можно использовать ipset. В этом случае у нас будет всего 1 правило. А все адреса будут в едином списке. И, вроде как, это ещё будет и эффективней про производительности (если статья с 2010 года не потеряла актуальности). Максимальное время жизни записи в ipset — 2147483 секунды (примерно 24 суток). Сам ipset также предотвращает добавление дублирующихся адресов в список (во всяком случае, с параметром hash:ip
).
Как добавить ipset в knockd
Создать список в ipset
ipset create your_name_ACL hash:ip timeout 10
В конфигурационном файле knockd заменить дляcommand
:
command = /usr/sbin/ipset -q add your_name_ACL %IP% timeout your_seconds
Замените your_name_ACL
и your_seconds
на нужные значения.
Лично мне на практике не доводилось вносить через port knocking более пары десятков адресов. Поэтому возникает вопрос: что там с производительностью при большом количестве записей? Я сделал небольшой тест. Добавил 10 000 сгенерированных записей (IPv4 адреса) в ipset. Согласно выводу ipset list
используемая память увеличилась с 200 байт (когда 0 записей) до 240 872 байт (когда 10 000 записей). Далее я запустил knockd и сравнил сколько времени уйдёт на прозрачный port knocking. Т.е. к 100 000 записей добавилась ещё одна (после срабатывания port knocking). Время ушло примерно столько же, как при одной записи.
Потребление памяти ipset
Пустой список
10 000 записей в списке
Параметры виртуальной машины для этого теста
ОС — Ubuntu 22.04; ОЗУ 600 МБ; один процессор
port knocking в docker контейнерах
Давайте разберём причины почему стоит присмотреться к такому варианту. Первое, что приходит в голову: port knocking можно настроить и на хостовой системе. Зачем делать в контейнере?
Основное — не хочется перегружать правилами МСЭ хостовой системы. Чем больше правил — тем проще в них запутаться и в итоге ошибиться при очередной их модификации (о чём уже говорил в разделе Access Control List). В Ubuntu 22.04 после установки docker создаётся порядка 30 строк правил. Наверняка на хост системе есть ещё какие-то правила (в т.ч. для других контейнеров). Т.е. итоговый список правил уже не маленький.
Правила iptables, автоматически созданные после установки docker в Ubuntu 22.04
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).
Вопросы безопасности, связанные с использованием capability NET_ADMIN
Обычно рекомендуется не включать без необходимости капы для контейнеров. Чаще всего формулировка в рекомендации обобщённая: «для уменьшения поверхности атаки». Если в контейнере уже используется капа NET_ADMIN
, то дополнительных рисков не возникнет. Если нет — кое-что следует учитывать. Я не специалист по капам. Но, по описанию капы предполагаю потенциальные угрозы (если атакующий смог получить root привелегии в контейтере):
— прослушивание трафика в неразборчивом режиме (собрать информацию о локальной сети);
— подмена IP-адреса контейнера: если есть ACL по IP — можно его обойти (т.е. выдача нового адреса в дополнение к старому — иначе есть шанс потерять удалённый доступ к контейнеру, не добившись профита, конфликт одинаковых IP-адресов не рассматриваем);
— банальный DoS (изменение IP адреса приведёт к недоступности сервисов на контейнере; изменение маршрутизации — потенциально тоже).
Также стоит учитывать вот эту и эту информацию касательно потенциальных угроз.
Установка зависимостей (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 может получится как в анекдоте: безопасно, но пользоваться невозможно.
Сам анекдот
— «Доктор, боюсь подхватить ЗППП, что делать?»
— «Элементарно: наденьте презерватив, намажьте йодом, поверх второй, его зелёнкой, поверх цементом… ну, и никаких половых актов!»