Коллектив авторов - Защита от хакеров корпоративных сетей

• установлением подлинности.Каждая сторона зашифрованного соединения уверена в подлинности идентификационных данных другой стороны;

• проверкой целостности.Любой поток данных, передаваемый по зашифрованному соединению, не может быть разделен на части, похищен или изменен путем добавления посторонних данных.

Простым примером разделяемого секрета является короткое слово или фраза, известное обоим участникам соединения, которое в общем случае не удовлетворяет трем перечисленным свойствам, но тем не менее позволяет обеспечить разумную безопасность используемым технологиям. Сказанное не означает существования подобных систем в прошлом. Используемый набор паролей во многом определяет успех применения систем, удостоверяющих подлинность своих пользователей. К сожалению, на многих сайтах Telnet занимает лидирующие позиции среди технологий обмена паролями. Вызывает сожаление, что для обмена паролями большинство сайтов не используют профиль сообщения (короткую цифровую строку фиксированной длины, формируемую из более длинного сообщения с использованием специального алгоритма), получаемый с помощью стандарта MD5.

Если пароль каждой компании был бы напечатан в специально выделенной для этой цели колонке газеты New York Times, то могло быть и хуже. Это несколько успокаивает. «Если работает межсетевой экран, то можно не ждать подвоха ни от одного из своих устройств. По крайней мере, хоть пароли не напечатаны в New York Times».

Шутки в сторону. Современные системы разделения секрета – это криптографические системы, которые защищают криптографическими методами охраняемые ими системы. Почти всегда используются приличные протоколы с хорошими функциональными возможностями, но с очень плохой защитой. Пожалуй, следует отметить преимущества протоколов RIPv2 и TACACS+ по сравнению с оригинальными протоколами RIP и TACACS/XTACACS соответственно. Но и они страдают от двух главных проблем.

Во-первых, их криптография не очень хороша. Компания Solar Designer в документе «Анализ протокола TACACS+ и его реализации» приводит пример того, насколько идеально переговоры по поводу TACACS напомнили бы консультацию по вопросам безопасности. Этот документ размещен по адресу www.openwall.com/advisories/0W-00l-tac_plus.txt. Фальсифицировать пакеты таким образом, чтобы они казались бы знающими разделяемый секрет, – не очень трудная задача для подкованного злоумышленника с возможностями активного спуфинга.

Второе, и гораздо более важное: пароли в значительной степени теряют свою криптостойкость, если их совместно используют два хоста! И TACACS+, и RIPV2 зависят от единственного разделяемого пароля на протяжении всего использования инфраструктуры (на самом деле протокол TACACS+ можно было бы переписать, чтобы он не зависел от этого, но RIPV2, по мнению автора, вряд ли). Когда пароль только у двух машин, внимательно изучите последствия этого:

• пароль конфиденциальный?Все хосты, за исключением избранных, передаваемые по каналу связи данные воспринимают как шумовые помехи. Для посвященных хостов, владеющих разделяемым паролем, полученная абракадабра преобразуется в открытый осмысленный текст;

• пароль удостоверен?Каждая сторона зашифрованного канала связи уверена в подлинности идентификационных данных другой стороны. Основаниями для отклонения какого-либо хоста из десятков, сотен или тысяч других является либо кража им пароля, либо активный спуфинг, при помощи которого он самостоятельно установил соединение;

• пароль обеспечивает целостность?Любой передаваемый по зашифрованным каналам связи поток данных может быть разделен на части, разорван, похищен, или в него будут добавлены лишние данные, если была допущена утечка информации о пароле.

Хорошо зарекомендовало себя использование двумя хостами единственного пароля в виртуальных двухточечных соединениях. Даже когда соединения организованы по схеме клиент-сервер (как, например, в схеме TACACS+, где единственный клиентский маршрутизатор подтверждает подлинность пароля, предложенного CiscoSecure – вычислительной машиной базы данных сервера паролей Cisco). В любом случае одна из сторон соединения является или клиентом, запрашивающим пароль, или сервером, предлагающим его. Если она – сервер, то один-единственный хост с паролем является клиентом. Если она – клиент, то только единственный хост с паролем является сервером, которому она доверяет.

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

Это не означает, что если система использует в своей работе пароль, то она хорошо противодействует спуфингу. Для того чтобы предоставить инженеру безопасный способ передачи своего пароля маршрутизатору, маршрутизаторы Cisco используют обмен паролями по протоколу SSH. В этом случае пароль нужен только для подтверждения маршрутизатору подлинности пользователя. Вопросы конфиденциальности, целостности соединения (нельзя допустить передачу инженером своего пароля неверному устройству!) и аутентификации маршрутизатора решаются инженером на следующем уровне: уровне секретного ключа.

Способность подтвердить секретный ключ криптографической пары: «Я могу распознать ваш голос?»

Проверка способности подтвердить знание секретного ключа криптографической пары требует знания той части криптографии, которая известна под названием асимметричного шифрования, или асимметричных шифров. Симметричные шифры, как, например, алгоритмы тройного DES, Blowfish и Twofish, используют единственный ключ для зашифровки и расшифровки сообщения. Подробнее об этом уже говорилось в главе 6. Только в случае, когда два хоста совместно используют один и тот же ключ, гарантируется надежность аутентификации. Если одна из участвующих в соединении сторон не посылала сообщения, то это сделала другая сторона, у которой есть копия секретного ключа.

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