Blogerator.org

× Версия для печати

Третья, заключительная часть моей серии статей про portknocking (PK). Начало этой серии читайте здесь.

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

Гибридный PK: сумма всех лучших технологий

Гибридными называют технологии PK, в рамках которых сочетаются сразу несколько разнородных концепций. Обобщая, можно выделить типичные составляющие гибридного PK (HPK): традиционный port-knocking, стеганография, криптография, реализация обоюдной авторизации (часто двухсторонняя SPA).

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

Существует несколько работ подробно описывающих HPK, из-за недостатка места я сосредоточусь лишь на двух, — типичных преимуществах этого подхода:

1. Проблема идентификации пакета: если с одной стороны, есть некая явная и однозначная сигнатура для каждого «магического пакета» (как в Cerberus), то такие пакеты будут рано или поздно обнаружены и выделены из общего TCP/IP-потока злоумышленником. С другой стороны, если опасаясь этого, такие пакеты никак не маркировать, заставляя сервер PK каждый входящий пакет «вслепую» распаковывать и верифицировать по некой контрольной сумме (как в fwknop ), то это создает весьма ощутимую нагрузку на сервер. Это открывает возможность злоумышленнику для намеренной эксплуатации «родовой особенности» этой техники, что потенциально приведёт к возникновению сильнейшего DDoS-эффекта.
   

HPK в этой дилемме занял выигрышную компромиссную позицию: он маркирует каждый свой «магический пакет», но при этом для сокрытия идентифицирующего признака применяются продвинутые методы стеганографии. Как пример последнего, номер запрашиваемого для открытия сервиса/порта + пакет авторизации здесь может быть передан даже не на транспортно-сетевом уровне TCP/IP, а на прикладном уровне (или их смешении), — будучи внедрены в обычное со всех точек зрения png-изображение.

2. Проблема replay-атак: в HPK всегда применяется двухсторонняя авторизация, таким образом, здесь PK осуществляется всегда в две стороны, что устраняет множество потенциальных проблем и неудобств, которые свойственны другим PK-техникам, пытающихся противодействовать replay-атакам с помощью различных полумер (необходимость предварительной синхронизации времени на клиенте и сервере, как в Cerberus; хранение базы из хэшей всех обработанных пакетов, как в fwknop и так далее). У такого подхода есть ещё несколько преимуществ, но для баланса отметим и главный недостаток — общий алгоритм взаимодействия при этом резко усложняется.

У разных реализаций HPK имеются множество нюансов, поэтому предлагаю очень кратко коснуться технических особенностей лишь одной, но весьма достойной — Tariq:

• Здесь очень ясный и чистый код на Python, в силу того, что логика сервера — это лишь надстройка над пакетом scapy. В результате все низкоуровневые детали его протокольно-транспортного устройства изолированы от самой системы.
• Tariq не прослушивает множество TCP/IP-портов, как это делают стандартные PK-сервера. Он использует возможности scapy для пассивного сниффинга всего входящего трафика, равно как и для конструирования обратного пакета-ответа.
• Для ещё большего упрощения логики устройства, Tariq использует сторонние библиотеки: шифрования (GnuPG), стеганографии (steganogra-py) и возможности упомянутого scapy для всего остального спектра сетевых операций.
• В данном случае для доставки скрытых зашифрованных пакетов используется приведенный выше пример — обычные графические изображения (прикладной уровень OSI), для работы с которыми дополнительно понадобится библиотека Python Imaging Library (PIL).
• Tariq поставляется сразу как совмещенный пакет — с сервером и клиентом, укомплектованный всеми необходимыми библиотеками, и может быть запущен в качестве клиента везде, где доступна среда исполнения Python (в том числе на мобильных платформах).

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

Watch_dns: пример высшей магии скрытой авторизации

Известный американский специалист по безопасности Брайн Хатч (автор популярной серии книг «Linux Exposed») описал и реализовал в 2009 году систему для прослушки DNS-запросов на предмет скрытых knock-knock запросов. В его оригинальной реализации простая Perl-программа под названием watch_dns просматривала весь UDP-трафик поступающий на локальный DNS-сервер, формируя список всех запрашиваемых хостов, а также IP-адреса источников запросов.

Второй Perl-скрипт в режиме реального времени сканировал это список и по специальному правилу выделял доменные имена, интерпретируя их как команды-запросы (для чего был разработан довольно простой, но в тоже время гибкий язык HidenHand).

Даже с точки зрения внешнего наблюдателя, который имел бы полный доступ к трафику обмена сообщениями между сервером и клиентом, не происходило бы ничего необычного — DNS-сервер, также как и все остальные сервисы работают штатным образом. Здесь, в отличие от обычного port knocking’a, нет вообще никаких бессмысленных, подозрительных или странных пакетов (например, ACK-запросов без ответа и т.п.). Но на самом деле HiddenHand позволяет не только открывать порты по запросу клиента, но также удаленно конструировать новые правила для работы системы безопасности, абсолютно незаметно, через имена подходящих по названию доменов-команд, динамически корректируя её логику работы и настройки.

Пока мы сосредоточились лишь на серверной стороне этой реализации, но стоит отметить также и удивительную простоту управления подобным механизмом со стороны клиента. В самом деле, здесь не нужно использовать какой-то сторонний «сакральный код» — для этого подходит множество подручных и обыденных программ, таких как nslookup или host , также можно воспользоваться веб-интерфейсами аналогичных сервисов. Но на самом деле все обстоит даже ещё проще. Брайан рекомендует создание на авторитетном DNS-сервере домена (находящимся полностью под вашим контролем) настройку для произвольного субдомена, который будет использоваться именно для этой цели.

Например, для созданного домена третьего уровня my.megashop.net можно настроить тригеры прослушки и интерпретации ваших DNS-команд, при каждом обращении к нему. После этого можно использовать обычный браузер, для запроса к подобному домену, например запрос к ресурсу static.my.megashop.net может открывать порт с SSH, а обращение к изображениям хранимым на img.my.megashop.net будет снова закрывать его. На самом деле, подобные запросы могут исходить откуда угодно, не обязательно от вашего браузера, а, например, от стороннего сайта, который хостит страницу, элемент которой (.css-файл или картинка-аватор, как в примере Брайана) загружается с данного ресурса.

Брайан приводит рабочую демонстрацию этого, когда вход на его любимый технический форум (после авторизации на форуме происходит подгрузка аватора с «магического субдомена»), вызывает вышеописанный эффект «веерно падающего домино», когда в конечном результате SSH «вдруг» оживает и начинает принимать запросы. Фактически, на базе идей PK здесь реализована классическая двухфазовая авторизация (в данном случае SSH), за тем лишь отличием, что в отличии, например, от подобной двухступенчатой схемы у Google, здесь факт прохождения идентификации носит крайне неявный характер (успешный вход на публичный форум = первая фаза аутентификации при доступе к приватному SSH).

Хочу отдельно подчеркнуть, что этот дополнительный уровень сокрытия и безопасности очень прост в реализации. Брайн использовал три простых Perl-скрипта, на написание и отладку которых у него ушел один викэнд.

Словесы заключительные

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

Во многом PK основывается на известном принципе «security through obscurity» и позволяет вывести наиболее чувствительные сервисы из зоны прямой видимости (и досягаемости) злоумышленника.

Но, как и любая технология, PK не лишен недостатков. Традиционная схема (TPK) подвержена опасности нарушения последовательности доставки (или потери) пакетов из-за естественных сетевых коллизий, сложностям в некоторых случаях при подключении через NAT/PAT (в этом случае можно попробовать более всеядный вариант — uPortKnock), использовании в многопользовательской среде или на нагруженных системах.

Кроме того на неё легко осуществить своего рода DDoS-атаку: когда злоумышленник бомбардируя потоком случайных «стуков» защищенный сервер (и для создания этого «шума» хватит даже низкоскоростного подключения), блокирует всякую возможность авторизоваться у легального пользователя. Большинство этих и других проблем успешно решаются в более современных реализациях PK, в первую очередь в вышерассмотренных методиках на основе SPA и HPK.

~

Общее оглавление и начало этой серии статей — доступно здесь.

Игорь Савчук © Системный Администратор, 2012