Основы работы брандмауэров
Сенченко Т.В. (aka Boffin)
icq: 865491
(предыдущая страница ...)
DMZ (ДМЗ) - сокращение от "demilitarized zone" (демилитаризованная зона). В контексте брандмауэров этот термин означает часть сети, не входящую непосредственно ни во внутреннюю сеть, ни в Internet. Обычно это область между маршрутизатором, обеспечивающим доступ в Internet, и бастионным хостом, хотя так можно называть область между любыми двумя компонентами архитектуры защиты, обеспечивающими выполнение правил доступа.
ДМЗ можно создать, установив списки контроля доступа на маршрутизаторе, обеспечивающем выход в Internet. Это позволяет минимально открыть хосты локальной сети, разрешая доступ из Internet только к определенным и контролируемым службам на этих хостах. Многие коммерческие брандмауэры просто создают на бастионном хосте третий сетевой интерфейс и называют его DMZ. Суть в том, что соответствующая сеть не является ни "внешней", ни "внутренней".
Например, Web-сервер, работающий на платформе NT, может быть уязвим для многих атак на службы RPC, NetBIOS и SMB. Эти службы не нужны для работы Web-сервера, поэтому блокирование подключений по протоколу TCP к портам 135, 137, 138 и 139 на этом хосте уменьшит его уязвимость для атаки на службы. Фактически, если заблокировать передачу на этот хост информации по любым протоколам, кроме HTTP, атакующему останется для атаки только одна служба.
Этот пример иллюстрирует важный принцип: никогда не давайте атакующим больше точек доступа, чем абсолютно необходимо для поддержки служб, предлагаемых для общего доступа.
Продолжу опять от себя… Следующий, часто задаваемый вопрос:
Совместимость с программами, обращающимися к Internet, очень важна: неудачно спроектированный брандмауэр может истолковать вполне законное действие (скажем, открытие порта для осуществления Internet-коммуникации) как попытку взлома, а вполне обычную программу принять за вредоносную. Одни брандмауэры спрашивают у пользователя разрешения на запуск программ, другие самостоятельно разрешают или блокируют их выполнение. По совместимости в целом почти безупречные результаты показал BlackICE Defender, а McAfee.com отстал от него лишь ненамного. Norton и ZoneAlarm в большинстве случаев сработали хорошо; Secure Desktop и ESafe выступили слабо. Ну и устойчивее всех, мне показался Tiny Personal Firewall Engine.
Лучший способ – это установить сетевой экран на заново инсталлированную «чистую» систему, пока нет другого ПО, которое может препятствовать четкой спецификации правил вашего сетевого экрана.
Хороший брандмауэр в состоянии отличить сетевой трафик, принадлежащий «честным» программам, от злонамеренного, происходящего от «троянского коня» или злоумышленника. Это можно сделать, анализируя либо сами программы, либо трафик данных. Примером первого подхода может служить брандмауэр, который проверяет каждый запускаемый на выполнение файл по готовой таблице программ, дозволенных к применению. Пример второго, который не выясняет, какие программы запущены, но исследует все данные, поступающие на компьютер и отправляемые с него, на подозрительное поведение или наличие определенных сигнатур.
И, несомненно, самый оптимальный способ – это определение IP-адреса к которому подключается та или иная программа. Например, если вы приобрели модем для выхода в Интернет и используете web-браузер Internet Explorer, то ему нужно позволить выход один раз. Это означает, что в правилах вашего брандмауэра необходимо разрешить этот запрос, но только на исходящий трафик. Если вы пользуетесь каким либо почтовым клиентом, то ему также необходимо разрешить исходящий запрос.
А теперь представим (как вариант), что мы пробрели «пиратский» программный продукт для работы с графикой. Для примера возьмем Adobe PhotoShop. Перед инсталляцией запустили брандмауэр. Что же дальше? Мы вышли в Интернет и вдруг наш PFW выдает предупреждение, что PhotoShop «просится» в сеть. Первым делом, нужно отследить на какой ip-адрес был сделан запрос, а потом анализировать ситуацию, разрешить соединение или нет. Я могу однозначно сказать – НЕТ. Причин может быть множество, одна из которых – программа пытается передать «хозяину» информацию о лицензионном соглашении, но т. к. такового у нас нет, мы можем (разрешив) получить в ответ предупреждение: «Продукт не имеет лицензионного соглашения, а потому срок его использования истек».
Или возьмем другой пример. Вы используете для передачи IM сообщений в сети icq-клиента. После установки, программа icq попросит вас о соединении с Интернет и мы должны ей это разрешить, но при этом, опять таки, внимательно анализируя трафик. Естественным будет то, что icq попросится на свой сервер icq.com, но никак не будет естественным то, что клиент icq выдаст запрос на неизвестный домен. Тут мы вправе думать, что угодно, потому как неизвестно, какого рода информацию о нашей системе хочет отдать эта программа.
*источник: «Брандмауэры в Internet» (Matt Curtin & Marcus J. Ranum)
Протокол TCP поддерживает 6 "флагов", которые могут быть установлены (ON) или сброшены (OFF). Вот эти флаги:
FIN
"Управляемое" соединение закрыто
SYN
Открывается новое соединение
RST
"Непосредственное" соединение закрыто
PSH
Указывает получающему хосту передать данные приложению, а не просто поставить их в очередь
ACK
"Подтверждает" предыдущий пакет
URG
"Срочные" ("Urgent") данные, требующие немедленной обработки
Рассмотрим пример, когда клиент работает на хосте 5.6.7.8 и получил динамический порт 1049. Сервер работает на порту 80 хоста 1.2.3.4.
Клиент начинает попытку подключения:
5.6.7.8:1049 -> 1.2.3.4:80 SYN=ON
Сервер получает этот пакет и понимает, что кто-то хочет организовать новое подключение. Посылается ответ:
1.2.3.4:80 -> 5.6.7.8:1049 SYN=ON ACK=ON
Клиент получает ответ и информирует сервер, что ответ получен:
5.6.7.8:1049 -> 1.2.3.4:80 ACK=ON
Теперь подключение открыто. Это называется трехэтапным согласованием (three-way handshake). Его назначение - удостоверить ОБА хоста, что между ними установлено действующее соединение.
В сети Internet, ненадежной и переполненной, необходимы средства, компенсирующие потерю пакетов.
Если клиент посылает начальный пакет SYN и не получает пакет с флагами SYN+ACK в течение нескольких секунд, он посылает пакет SYN повторно.
Если сервер посылает пакет SYN+ACK и не получает пакет с флагом ACK в течение нескольких секунд, он посылает пакет SYN+ACK повторно.
Именно последнее является причиной, по которой атаки путем переполнения SYN-пакетами так хорошо работают. Если посылать пакеты SYN от множества различных портов, это потребует существенных ресурсов сервера. Если также отказаться отвечать на полученные в ответ пакеты SYN+ACK, сервер будет долго СОХРАНЯТЬ эти подключения, повторно посылая пакеты SYN+ACK. Некоторые серверы перестают принимать новые подключения при наличии достаточного количества формирующихся, вот почему атаки путем переполнения SYN-пакетами (SYN flooding) работают.
Все пакеты, передаваемые в обоих направлениях после трехходового согласования, будут иметь установленный бит ACK. Фильтры пакетов, не поддерживающие информацию о состоянии, используют эту особенность в так называемых фильтрах "установленных подключений". Они будут пропускать только пакеты с установленным битом ACK. При этом в определенном направлении не смогут проходить пакеты, способные организовать новое подключение. Обычно не разрешают открывать новые подключения с внешних хостов на внутренние, требуя установленного бита ACK во входящих пакетах.
Когда приходит время закрывать подключение, это можно сделать двумя способами. С помощью флага FIN или с помощью флага RST. При использовании флагов FIN обе стороны подключения должны послать пакеты с установленными флагами FIN, чтобы показать, что они собираются закрыть подключение, а затем послать подтверждения на эти FIN-пакеты, показывающие, что они поняли намерение противоположной стороны подключения закрыть его. При посылке пакетов RST подключение закрывается принудительно и вы не получаете информации о том, поняла ли противоположная сторона ваше требование о закрытии подключения и получила ли она на самом деле все посланные ей данные.
Закрытие подключения с помощью FIN-пакетов также может привести к ситуации отказа служб, поскольку стек TCP должен сравнительно надолго запоминать закрытые подключения на случай, когда другая сторона не получила одного из FIN-пакетов.
Если открыть и закрыть достаточно много подключений, в конечном итоге можно получить "закрытые" подключения во всех имеющихся слотах, описывающих подключения. В этом случае вы не сможете динамически выделять новые подключения, ибо все возможные уже использованы. Различные операционные системы по-разному реагируют на эту ситуацию.
Стивен Бэлловин (Steven M. Bellovin).
Реализация протокола FTP для поддержки брандмауэров (Firewall-friendly FTP).
Рабочий документ RFC 1579.
Р. Финлейсон (R. Finlayson).
Многоадресная IP-передача и брандмауэры (Ip multicast and firewalls).
Рабочий документ RFC 2588, май 1999.
Я. Рехтер (Y. Rekhter), Б. Московиц (B. Moskowitz), Д. Карренберг (D. Karrenberg), Г. де Грут (G. J. de Groot) и Е. Лир (E. Lear).
Распределение адресов для приватных IP-сетей (Address allocation for private internets).
Рабочий документ RFC 1918, февраль 1996.
Р. Сайер (R. Thayer), Н. Дорасвами (N. Doraswamy) и Р. Гленн (R. Glenn).
Принципы создания стандарта защиты IP (IP Security Document Roadmap).
Рабочий документ RFC 2411, ноябрь 1998.
Возможность безопасного администрирования межсетевых экранов в удаленных офисах из центральной сети предоставляет в распоряжение корпораций функциональность, которой им давно недоставало. Так как в удаленных офисах часто нет специалистов по обслуживанию такой техники, требуется полное управление из центра. Но даже в этом случае перед поставкой новинок в удаленный офис необходимо выполнить их конфигурацию. Помимо этого, такие устройства нужно правильно подключить. Большинство из них имеет несколько интерфейсов, каждый со своими параметрами защиты, поэтому правильное подключение имеет решающее значение для их корректной работы.
Те пользователи, которые справились с этими основополагающими требованиями, могут приступать к решению более сложных задач, таких, как применение наборов правил и управление событиями защиты. Нужно ли в каждом удаленном офисе реализовывать одни и те же наборы правил или они могут несколько различаться? Или, например, как обрабатывать события, фиксируемые персональным межсетевым экраном, в центральном офисе? Будут ли данные об этих событиях «путешествовать» по Internet в текстовом виде, открытые для перехвата и возможного искажения, или они будут заключены в туннели VPN? Кроме того, придется решить, что делать с данными о подобных событиях, когда они достигнут центрального офиса — интегрировать ли их в существующую систему сетевого управления так, чтобы служба технической поддержки была уведомлена о получении сообщения о событии высоким приоритетом. Помимо технических аспектов решений, это лишь некоторые из процедурных сложностей, возникающих при внедрении персональных межсетевых экранов.
Занимаетесь ли вы администрированием удаленных офисов или просто работаете на ПК дома, в любом случае вы, скорее всего, вложили немало труда и средств в свои компьютеры. Если же вы хотите должным образом защитить эти вложения, то персональные межсетевые экраны заслуживают самого пристального изучения.
Итак, каково же решение проблемы? Начните с создания собственной оборонительной системы. Это означает усиление и затем тестирование защиты всей сети — начиная с ОС и кончая внешними брандмауэрами и маршрутизаторами. «Тренируйте» сетевые службы на противодействие распределенным атакам, вирусам и прочим безобразиям, пока они не «научаться улаживать» такие проблемы.
Дата обновления 10.01.2005