Port knocking как инструмент управления доступом к скрытым сервисам
Один из самых старых способов скрытого получения доверенного доступа к не менее скрытым сервисам в Интернете (как IP-сети) это port knocking (метод “секретного портового стука”). Суть метода изложить не трудно: скрываемый сервис работает на закреплённом за ним номером порта, но доступ для TCP-соединений (например) к этому номеру порта открывается только для тех IP-адресов, которые выполнили установленный набор попыток подключений по другим номерам портов. Чуть более развёрнутое объяснение для тех, кто не сетевой инженер (опять же, используем TCP): TCP-соединение – это соединение “точка-точка”, на каждом из концов соединению соответствует IP-адрес и номер порта, где номер порта, можно считать, это просто 16-битное число; например, 10.11.12.13:14395 -> 10.101.102.103:22 – соединение клиента с номером порта 14395 на серверный номер порта 22 (это обычный номер для SSH); предположим, что доступ на сервере по порту 22 закрыт межсетевым экраном (брандмауэром), то есть, попытка соединения на этот номер порта будет проигнорирована сервером; но если некоторый клиент с IP 10.11.12.13 выполнит попытки TCP-подключения на другие номера портов сервера по заданной ключевой последовательности: 1011, 1022, 1033, то брандмауэр, который фиксирует у себя попытки подключения, откроет подключения по номеру порта 22, но только для соответствующего IP-источника.
Естественно, все номера тут могут быть любыми (из допустимых интервалов). Метод весьма полезный, я его использую для открытия доступа к шлюзам, ведущим в некоторую “закрытую” сеть: совершенно необязательно открывать конкретный сервис на конкретном узле, с тем же успехом можно открыть туннель.
Почему-то данный метод и известен не столь широко, как можно подумать, да и нередко его необоснованно относят к способам защиты из разряда Security through obscurity (“Безопасность через неясность”, в одном из переводов), которые, как бы, “заведомо слабые”, что как раз и есть хороший пример неверного обобщения “принципа Керкгоффса”. Однако данный метод хорош, если используется по назначению и в верном контексте. А если излишне настойчиво обобщать, то и авторизация SSH по ключу может показаться “безопасностью через неясность” – действительно, а как если бы он знал значения байтов секретного ключа и их последовательность? Впрочем, это лирическое отступление.
Идея port knocking очень гибкая, потому что достаточно общая: во-первых, годится и TCP, и UDP, и ещё что угодно “с номерами”; во-вторых, последовательность “стука” не обязательно фиксированная – если есть общий секретный ключ и общее время, то номера можно генерировать псевдослучайным образом; в-третьих, вежливо постучать клиент может в один узел (IP-адрес), а доступ ему откроется на совсем другом (так тоже бывает). Поэтому именно “портовый стук” представляет собой эффективный дополнительный инструмент, затрудняющий обнаружение скрытого сервиса разными активными сканерами (что называется – connection probe). Если последовательность стуков неправильная, то, понятно, никто на неё просто не ответит, поэтому и никакой новой информации получить не выйдет.
Действительно, номера портов, которые открывают возможность соединения, видны в сетевом трафике. Но если это псевдослучайная последовательность, толку, в плане анализа трафика и сервисов, от этого не очень много – мало ли кто и какие порты сканирует? Добавление же контекста в DPI тут существенно повышает сложность анализа трафика. К port knocking можно добавить пакеты (UDP, например), содержащие дополнительные ключи, что, вместе с заменой адресов, совсем хорошо перемешает информацию, ещё больше затруднив анализ и построение контекста. Интересно, что через номера портов, в принципе, можно передавать и выбранный номер входного узла, к которому требуется получить доступ. То есть, конкретный вход в туннель и его свойства определяются выбранной последовательностью “стуков”. Впрочем, если простой port knocking в линуксах, например, относительно легко реализуется силами iptables (типовой межсетевой экран), то расширенные, хитрые способы – потребуют отдельного специализированного модуля, обрабатывающего низкоуровневую информацию о соединениях.
Адрес записки: https://dxdt.ru/2023/10/04/11172/
Похожие записки:
- Удостоверяющие центры TLS-сертификатов Рунета
- Реплика: перемешивающие сети Google и фильтрация
- Stack Overflow и OpenAI
- Ретроспектива заметок: программный код из "реальности" в "виртуальности"
- "Вес" значений омонимов в текстах для LLM
- Постквантовая криптография и рост трафика в TLS
- ИИ с превышением
- Реплика: явления слуха и представления о физических процессах
- Автомобили, "подключенные" для сбора данных
- Подмена хостнейма WHOIS-сервиса .MOBI
- Браузеры и перехват TLS без участия УЦ
Комментарии читателей блога: 3
1 <t> // 4th October 2023, 17:46 // Читатель Nataraj написал:
Я бы отнес Port Knocking не к средствам защиты от взлома, тут он действительно немного подходит на Security through obscurity, а к средствам сокрытия от стороннего наблюдателя факта существования сервиса: тут не обслуживают, проходите мимо.
Что сильно понижает вероятность прохождения ненаправленной атаки, но на самом деле нужно не только для этого… А сам сервис должен быть безопасным сам по себе, вне зависимости от Port Knocking…
2 <t> // 8th November 2023, 22:30 // Читатель AndreyKopeyko написал:
Всецело поддержу коллегу – port knoking является лишь “холстом, на котором в каморке папы Карло нарисован очаг”, но и этого хватило чтобы на несколько десятилетий, как мы теперь знаем из повествования Джани Родари, скрыть потайную дверь даже от самого папы Карло.
3 <t> // 24th January 2024, 18:40 // Читатель vlad написал:
Бывают же совпадения. Мне примерно в начале октября, совершенно независимо, пришли мысли насчет такого подхода и где то через месяц я его запилил. А может это не совпадения, а наводки от соседних ячеек памяти в матрице :)
Написать комментарий