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

Давайте рассмотрим пример максимально защищенного межсетевого экрана протокола HTTP. Пусть вы администратор межсетевого экрана. Вы сконфигурировали межсетевой экран таким образом, что разрешили только некоторые команды протокола HTTP. Вы разрешаете вашим пользователям посещать только те сайты, которые перечислены в списке из 20 санционированных к посещению сайтов. Вы настроили межсетевой экран таким образом, чтобы не пропускать программы на языках Java, JavaScript и ActiveX. Вы сконфигурировали межсетевой экран таким образом, что разрешили лишь загрузку HTML-файлов и файлов с расширениями gif и jpg.

Могут ли ваши пользователи чувствовать себя в безопасности за межсетевым экраном, настроенным подобным образом? Конечно, могут. Пусть я буду злым хакером (или возможно, неосведомленным в вопросах безопасности Web-мастером), пытающимся передать свою программу через такой межсетевой экран. Как мне обойти тот факт, что вы разрешили загружать только определенные типы файлов? Я разработаю и вывешу на всеобщее обозрение Web-страницу, которая сообщает вашим пользователям о необходимости нажатия правой копки мыши на jpg-файле для его загрузки на компьютер пользователя, а затем переименую загруженный файл в evil.exe, как только он окажется на вашем жестком диске (имеется в виду, что предварительно внедряемая программа была переименована в jpg-файл). Как преодолеть антивирусное программное обеспечение? Вместо сообщения вашим пользователям о переименовании файла в исполнимый exe-файл я сообщаю им о его переименовании в zip-файл и разархивирую его с использованием пароля «hacker». Ваше антивирусное программное обеспечение никогда не сможет проверить защищенный паролем архивный zip-файл. Пусть вы тем или иным способом не позволите своим пользователям попасть на мой сайт. Нет проблем. Все, что я должен делать, – это взломать один из одобренных вами для посещения сайтов. Однако вместо обычного очевидного искажения информации на сайте я оставлю все как есть, но с маленьким дополнением небольшого кода на JavaScript. К тому времени, когда кто-либо обнаружит эту едва различимую подмену, я наверняка добьюсь своей цели.

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

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

Оказывается, есть множество способов подвергнуться нападению через межсетевой экран. В идеале межсетевые экраны осуществляют политику безопасности в полной мере. В действительности межсетевой экран создают люди, поэтому он далек от совершенства. Одна из основных проблем межсетевых экранов состоит в том, что его администраторы с трудом могут ограничить именно тот трафик, который они хотели бы. Например, в политике безопасности может быть заявлено, что разрешен доступ к Интернету по протоколу HTTP и запрещено использование RealAudio. Администратору межсетевого экрана следует запретить порты RealAudio, не так ли? Проблема состоит в том, что люди, которые написали RealAudio, понимая, что подобное может произойти, предоставили пользователю возможность загрузить файлы RealAudio по протоколу HTTP. В действительности если вы при настройке не укажите явно вариант доступа к содержимому RealAudio с Web-сайта, то большинство версий RealAudio выполнит ряд проверок для определения варианта подобного доступа. При этом, если это потребуется, автоматически будет выбран протокол HTTP. Фактически проблема в этом случае состоит в том, что любой протокол может быть туннелирован по любому другому, если только синхронизация по времени не критична (то есть если туннелирование не приведет к чрезмерному замедлению работы). RealAudio выполняет буферизацию, если сталкивается с проблемой синхронизации.

Разработчики различных интернетовских «игрушек» хорошо осознают, какие протоколы обычно разрешены, а какие нет. Много программ разработано с использованием протокола HTTP в качестве основного или резервного средства переноса информации через сеть.