Коллектив авторов - Защита от хакеров корпоративных сетей
Не стоит строить иллюзий относительно приведенных в главе сведений. Зачастую туннелирование является способом обхода чрезмерно строгого контроля за безопасностью. Не всегда это плохо. Помните, целью существования компании является не обеспечение своей безопасности ради самой безопасности. Обанкротившаяся компания небезопасна, особенно когда она получает доступ к записям пользователя. Но очень трудно возражать против ограничений чужой системы обеспечения безопасности, если собственное решение страдает вызывающими изъянами защиты. При атаке на защищенный межсетевым экраном туннель ключом к необходимым для нее разрешениям (другими словами, к отпущению грехов атакующего) является понимание вопросов обеспечения безопасности межсетевого экрана. Прежде всего вопросов, связанных с адресацией. Их понимание притупляет обвинения в адрес пользователя как единственного ответственного за нанесение системе ущерба. Особенно это касается корпоративной сферы. Далее рассмотрим наиболее важные требования, предъявляемые к проектируемым системам туннелирования.
...Инструментарий и ловушки
Инкапсуляция против интеграции
Для обеспечения безопасности соединения между двумя хостами существуют два основных подхода. Первый подход состоит в инкапсуляции незашифрованной линии связи внутри предназначенной для этого системы. Второй – заключается в интеграции (встраивании) криптографической подсистемы в протокол, который приложение предполагает использовать. Обычно к интеграции разработчика подталкивает желание самостоятельно все сделать самому. Вполне возможно, что он так делает для того, чтобы полностью вылизать уже написанный программный код, подгоняя его под специальные требования. Например, достижение межпакетной независимости, общедоступной возможности частичной расшифровки данных или доверительного хранения ключа, когда некоторые участники обмена сохраняют возможность расшифровки трафика, находясь при этом вне рамок сквозного маршрута передачи данных.
Дальше будет рассказано о недостатках инкапсуляции, которыми могут воспользоваться злоумышленники. Но они ничто по сравнению с запутанной историей развития интеграции. Никто не поверит производителю, если он создаст свой собственный алгоритм шифрования (даже если это будет алгоритм шифрования с 4096-битным ключом). Точно так же вызовет оправданное недоверие производитель, который спроектирует свою собственную замену протоколу защищенных сокетов SSL. Разумный подход заключается в том, что большей части программного обеспечения нельзя доверять управление паролями. Основанные на здравом смысле проверки, преследующие цель не допустить проникновения Троянских коней в систему, в основном относятся к общим вопросам обеспечения безопасности, а не к проектированию систем коммуникации, которые надежно защищены от проникновения в них злоумышленника.
Читателю необходимо понять, что проектирование систем безопасности на самом деле сильно отличается от проектирования других систем. В большинстве случаев код пишется для добавления каких-либо возможностей: визуализировать изображение, оживить его, напечатать документ. Напротив, код системы безопасности предназначен для запрещения возможностей: не позволить взломать систему, предотвратить пустую трату бумаги. Все, что предоставляет функциональность, безопасность забирает обратно. В большинстве случаев это касается не пользующихся доверием пользователей, то есть недоверяемых пользователей (untrusted user), но всегда что-то отнимается и от пользующихся доверием пользователей – доверяемых пользователей (trusted user). Точно так же, как многие газеты нашли успешную модель «Китайской стены» между редакционным отделом, который формирует круг читателей, и отделом рекламы, который перепродает сформированный редакционным отделом читательский спрос, протоколы безопасности извлекают выгоду из ограничения в доступе с одновременным расширением предоставляемых ими же возможностей. В рамках инкапсуляции предложено использовать так называемую «песочницу», реализующую механизм обеспечения безопасности подкачанных из сети или полученных по электронной почте программ. Этот механизм предусматривает изоляцию на время выполнения загружаемого кода в ограниченной среде-«песочнице». Иногда эта «песочница» может потребовать большего доверия, чем на самом деле предоставлено участникам обмена, но, по крайней мере, в нее заложен предел доверия, который не может быть превышен.
Описанные в данной главе системы объединяют методы, пригодные для инкапсуляции произвольного содержимого.
Конфиденциальность: «Куда уходит мой трафик?»
Основополагающими вопросами сохранения тайны коммуникаций, другими словами, их конфиденциальности, являются следующие:
• может ли еще кто-либо контролировать мой трафик внутри туннеля? Ответ на этот вопрос предполагает наличие доступа по чтению к передаваемым по туннелю данным, который может быть получен при предоставлении кому-либо возможности расшифровать передаваемые данные;
• может ли еще кто-либо модифицировать трафик внутри туннеля или скрытно получить к нему доступ? Это не что иное, как получение доступа по записи к передаваемым по туннелю данным, который в основном может быть получен при помощи выполнения процедуры аутентификации (удостоверения подлинности).
Сохранение тайны коммуникаций лежит в основе проектирования любого безопасного туннеля передачи данных. До известной степени, не зная участников, которые передают данные по туннелю, пользователь не знает, ни куда по туннелю отправляются данные, ни как они были получены ранее. Труднейшие проблемы проектирования систем туннелирования связаны с достижением крупномасштабного уровня безопасности «многие ко многим» («п-к-п»). Этого не удастся достичь до тех пор, пока системе не станут полностью доверять, считая ее безопасным решением, потому что это единственное, что сможет убедить людей начать ее использовать.
Трассируемость: «Через какую сеть можно передавать данные?»
В основе идеи трассируемости лежат следующие главные вопросы:
• насколько хорошо туннель соответствует ограниченным возможностям маршрутизации пакетов через сеть пользователя? Другими словами, в какой степени характеристики пакетов способствуют их прохождению через сеть пользователя;
• насколько естественно выглядит имитация необходимых функциональных возможностей сети? Ответ на этот вопрос зависит от возможности использования маскирующего шума для слияния с окружающей сетевой средой.
Для туннелирования будет очень кстати следующая аналогия. Допустим, что сеть эквивалентна мягкому грунту, и предпринимается попытка прокопать под горой туннель, чтобы перебраться с одной ее стороны на другую. Трассируемость обычно относится к решению вопроса о том, можно ли вообще определить траекторию туннеля. В конкретном случае это означает возможность нахождения такого маршрута передачи информации, который не нарушал бы каких-либо ограничений на тип разрешенного к передаче потока данных. Например, многие межсетевые экраны разрешают передачу Web-трафика и в небольших количествах еще чего-то. Юмор мира сетей состоит в том, что громадная пропускная способность межсетевых экранов для HTTP-трафика приводит к тому, что весь поток данных может быть инкапсулирован в трафике этого протокола.
В трассируемости нашли применение две хотя и отдельные, но тесно связанные идеи. Первая – это возможность туннелей воспользоваться для передачи данных пропускной способностью сети и инкапсуляцией трафика внутри разрешенных форм передачи данных, независимо от его фактической природы. Например, воспользоваться набором сетевых маршрутов от адресата до получателя и обратно. Вторая идея очень важна для долговременного использования системы туннелирования в сетях, которые, возможно, враждебно настроены к передаче через них данных определенного типа. Она основана на возможности использования маскирующего шума для скрытия инкапсулированного трафика среди потока данных, обтекающего туннель.
Рассмотрим разницу между трафиками, инкапсулированными в протоколы HTTP и HTTPS. По большому счету, протокол HTTPS является протоколом HTTP, заключенным внутри протокола SSL. Другими словами, протокол HTTPS – защищенный вариант протокола HTTP. Передаваемый с помощью протоколов HTTP и HTTPS поток данных пройдет через большинство сетей. Если пользователь пожелает, то туннель протокола HTTP станет для него прозрачным и открытым для исследования. Напротив, для туннеля протокола HTTPS это невозможно. При организации туннеля с помощью протокола HTTPS нет необходимости в фактическом выполнении протокола HTTP, а благодаря использованию SSL туннель получается практически непроницаемым для любознательного администратора. Поэтому по туннелю можно передать все, что угодно. У пользователя нет способа узнать, что именно передается по туннелю, до тех пор, пока у него не появится возможность проверить его состояние.
