Автор: Лебедь С.В.
Теги: информационные технологии вычислительная техника обработка данных программирование информатика информационная безопасность интернет
ISBN: 5-7038-2059-6
Год: 2002
Текст
j 1 i 1- ч
l ъ I h
13 9 28518
л 3 В 9 0 8
I
i
i
О
5 о
I о
I 8
э Cl В 5 Лебедь
, w . . 0 J 4 2 3 1 4 4 4/7 5 32 1
1 6 0 8 4 4 0 255847040 839
Межсетевое j
экранирование
*72® 5 / 8 0 8 93 . .J 4 9 /96*125
Теория и практика
защиты °
! вкеШнего' периметра
Б 0 Н > 0 3 4 . * 4 4 ’ * i J . . * » 4 6
9 0 8 6 0 8 4 4 0 2 5 5 8 4 7 0 4 0 8
С.В. Лебедь
Межсетевое
экранирование
Теория и практика
защиты внешнего
периметра
Москва
Издательство МГТУ имени Н.Э. Баумана
2002
УДК 004
ББК 32.973
Л334
Рецензенты:
кафедра «Информационная безопасность банковских систем»
Московского государственного инженерно-физического института
(зав. кафедрой канд. техн, наук, доцент А.И. Толстой);
д-р техн, наук, профессор Т.М. Лохов
Под редакцией д-ра техн, наук профессора И.А. Шеремета
Лебедь С.В.
Л334 Межсетевое экранирование. Теория и практика за-
щиты внешнего периметра. - М.: Изд-во МГТУ им.
Н.Э. Баумана, 2002. - 304 с.: ил.
ISBN 5-7038-2059-6
Одной из сложнейших проблем, решаемых при подключении корпора-
тивных компьютерных сетей к Интернету, является проблема обеспечения
безопасности их информационных ресурсов. Для решения этой проблемы
применяют ряд технологий, каждая из которых рассчитана на парирова-
ние определенного класса возможных угроз безопасности: системы обна-
ружения вторжений (Intrusion Detection Systems - IDS), открытых клю-
чей (Public Key Infrastructure - PKI), виртуальные частные сети (Virtual
Private Networks - VPN) и т. п. Среди этих технологий важнейшее место
занимают межсетевые экраны (firewalls), грамотное применение которых
способно радикально снизить риски, связанные с хищением и несанкцио-
нированным изменением хранимых и передаваемых данных.
В книге описывается одна из главных технологий обеспечения инфор-
мационной безопасности вычислительных сетей - технология межсетевого
экранирования. Рассмотрены области применения, архитектура построе-
ния, схемы классификации, функциональные возможности и уязвимости
межсетевых экранов. Теоретический материал подкреплен практическими
примерами, рассмотрены наиболее интересные продукты рынка межсете-
вых экранов.
Материал монографии автор использует при чтении курса лекций на
кафедре «Информационная безопасность» МГТУ им. Н.Э. Баумана.
Книга предназначена для специалистов в области информационной бе-
зопасности, сетевых администраторов, студентов. Будет полезна пользо-
вателям сети Интернет, заинтересованным в обеспечении информационной
безопасности своих персональных данных.
УДК 004
ББК 32.973
© С.В. Лебедь, 2002
© МГТУ им. Н.Э. Баумана, 2002
ISBN 5-7038-2059-6
Оглавление
Предисловие..........................................7
Введение. История индустрии межсетевых экранов......10
1. Межсетевое экранирование - технология информаци-
онной безопасности..................................13
1.1. Угрозы сетевой информационной безопасности..13
1.2. Основные принципы обеспечения информационной безо-
пасности ........................................16
1.3. Межсетевое экранирование....................19
1.4. Преимущества использования МЭ...............22
1.5. От чего не может защитить МЭ................25
1.6. Политика безопасности.......................27
2. Основные компоненты архитектуры межсетевых экра-
нов 30
2.1. Архитектура МЭ..............................30
2.2. База правил.................................34
2.3. Модуль аутентификации и авторизации.........35
2.4. Журнал событий..............................36
2.5. Модуль управления...........................37
2.6. Модуль мониторинга и оповещения.............39
2.7. Прикладные посредники.......................40
2.8. Модуль создания отчетов.....................41
3. Классификация межсетевых экранов...............45
3.1. Способ реализации...........................45
3.2. Защищаемые объекты..........................46
Сегментные МЭ (47). Персональные МЭ (47). Встраиваемые
МЭ (47).
3.3. Уровни модели OSI...........................48
Управляемые коммутаторы (48). Статические фильтры пакетов
(53). МЭ прикладного уровня (55). МЭ динамической фильтра-
ции пакетов (57). Посредники сеансового уровня (58). Шлюзы
сеансового уровня (инспекторы состояния) (58). МЭ эксперт-
ного уровня (61).
3
4. Схема подключения межсетевых экранов...........62
4.1. Dual-homed................................62
Демилитаризованная зона (63). Разрешение маршрутизации между
сетевыми интерфейсами (65). Запрещение маршрутизации меж-
ду сетевыми интерфейсами (66). МЭ в локальной вычислительной
сети (67).
4.2. Экранирующий экран..........................69
4.3. Экранирующая подсеть...................... 70
5. Технологии межсетевых экранов........................71
5.1. Сетевая трансляция адресов.....................71
Динамическая трансляция (72). Д инамическая трансляция с ди-
намической выборкой IP-адресов (74). Статическая трансляция (76).
Трансляция с динамической выборкой IP-адресов (76). Особен-
ности использования NAT (77).
5.2. Трансляция портов...............................77
5.3. Антивирусная защита............................78
5.4. Аутентификация..................................80
Методы аутентификации (80). Прозрачность аутентификации (83).
Протоколы и схема аутентификации (84).
5.5. Обнаружение вторжений и аномальной активности ..87
5.6. Управление бюджетами пользователей..............89
5.7. Контроль времени действия правил политики безопас-
ности.................................................90
5.8. Виртуальные частные сети......................91
Протоколы VPN (94). Протоколы шифрования и контроля цело-
стности (97). Протоколы управления ключами (98). Инфраструк-
тура открытых ключей (99). Прохождение VPN-трафика через
МЭ(ЮО).
5.9. Split DNS................................... 102
5.10. Балансировка нагрузки и управление полосой пропус-
кания 103
5.11. Управление сетями.......................... 105
Управление МЭ через платформы управления сетями (105). Уп-
равление списками доступа маршрутизаторов (108).
5.12. Посредник сеансового уровня SOCKS.......... 109
5.13. Разделяемые сетевые соединения..............113
6. Уязвимости информационной безопасности межсетевых
экранов..............................................115
6.1. Идентификация и вскрытие политики безопасности МЭ ..115
4
Идентификация МЭ по открытым транспортным портам (117).
Идентификация МЭ по отпечатку сетевого стека (118). Анализ
банеров прикладных служб (119). Трассировка маршрута (120).
6.2. Ошибки администрирования...................... 124
6.3. Отказ в обслуживании.......................... 125
6.4. Уязвимости пакетных фильтров.................. 126
6.5. Уязвимость прикладных посредников............. 129
6.6. Уязвимость «адаптивно-управляемых» МЭ......... 132
6.7. Уязвимости персональных МЭ.................... 136
Идентификация сетевых приложений (136). Уязвимость конфи-
гурационных файлов (138).
6.8. Примеры выявленных уязвимостей МЭ..............139
WatchGuard SOHO Firewall (139). Check Point Fire Wall-1(141).
Cisco PIX Firewall (144).
7. Тестирование межсетевых экранов.................... 145
7.1. Общие рекомендации............................ 145
7.2. Средства исследования МЭ...................... 147
Коммерческие сетевые сканеры безопасности (148). Nmap (151).
Hping(153). FireWalk (15 8). Netcat( 159).
7.3. Анализаторы и генераторы трафика.............. 161
7.4. Методика проверки инспекторов состояний....... 163
8. Обзор межсетевых экранов........................... 168
8.1. Check Point FireWall-1........................ 168
8.2. Axent Raptor Fire Wall........................ 187
8.3. Cisco IOS Firewall............................ 192
8.4. Cisco PIX Firewall............................ 197
8.5. CyberGuard Firewall............................199
8.6. TIS Firewall Toolkit...........................206
8.7. IP Filter......................................208
8.8. Ipfwadm, ipchains, iptables....................215
8.9. WinRoute Pro...................................225
8.10. Встраиваемый МЭ Network-1 CyberwallPLUS........228
8.11. Internet Connection Firewall операционной системы MS
Windows XP.............................................232
8.12. Персональные МЭ................................235
ConSeal PC Firewall (237). ZoneAlarm (240). PGP Desktop Security
(243). AtGuard (246). McAfee Personal Firewall (247).
8.13. МЭ защиты телефонных линий.....................252
5
8.14. Выбор МЭ...................................254
8.15. Перспективы развития МЭ....................264
Приложения.........................................268
П. 1. Формат кадров Ethernet.....................268
П.2. Формат пакета IP............................270
П.З. Форматы некоторых сообщений протокола ICMP..273
П.4. Формат пакета UDP...........................276
П.5. Формат пакета TCP...........................277
П.6. Производители МЭ............................280
П.7. МЭ, сертифицированные по «Общим критериям»..285
П.8. Прикладные протоколы, «трудные» для фильтрации.... 287
П.9. Ресурсы Интернет............................290
Список сокращений..................................295
Список литературы..................................300
ПРЕДИСЛОВИЕ
Сегодня все больше организаций подключают свои вычисли-
тельные сети к глобальной сети Интернет, а многие используют
возможности Интернет для ведения так называемой электронной
коммерции (e-commerce). Все они так или иначе сталкиваются с
различными проблемами обеспечения информационной безопас-
ности своих локальных и корпоративных сетей. Проблема инфор-
мационной безопасности также актуальна и для отдельных рабо-
чих станций, подключаемых к Интернет. Рискиугроз информационной
безопасности - основной фактор, определяющий необходимость
развертывания системы обеспечения информационной безопас-
ности.
Несмотря на относительную молодость рынка средств инфор-
мационной безопасности, он представлен многочисленными про-
дуктами, реализующими различные технологии защиты. Это прежде
всего такие средства, как межсетевые экраны, VPN-шлюзы, си-
стемы обнаружения вторжений, антивирусные средства, крипто-
графические системы, системы аутентификации, сканеры безопас-
ности и др. Целью книги является: ознакомление читателя с
одной из самых распространенных технологий обеспечения инфор-
мационной безопасности - технологией межсетевого экранирова-
ния - показать, какие задачи информационной безопасности мож-
но решать с помощью межсетевых экранов (FireWall), а также
отразить все аспекты эксплуатации межсетевых экранов: обосно-
вание выбора, установка, тестирование конфигурации, настройка
политики безопасности, управление, анализ защищенности.
Одна из основных целей, преследуемых автором при написа-
нии книги, состояла в освещении всех функциональных возможно-
стей, предоставляемых межсетевыми экранами, а также смеж-
ных технологий информационной безопасности, с тем чтобы помочь
читателям обоснованно подойти к выбору конкретного продукта,
исходя из требований политики безопасности организации. В моно-
7
графин дан обзор наиболее интересных продуктов рынка межсе-
тевых экранов, который поможет сориентироваться читателям при
выборе продукта.
Книга может быть полезна широкому кругу специалистов ин-
формационных технологий: сетевым администраторам, админи-
страторам безопасности, начальникам служб информационной
безопасности, менеджерам по продаже средств защиты, специали-
стам по сертификации, а также студентам, обучающимся по на-
правлению «информационные технологии» и специальности «Инфор-
мационная безопасность». Главы, в которых описаны персональные
межсетевые экраны, будут интересны и большинству пользовате-
лей, подключающих свои персональные компьютеры к Интернет.
Читатели должны знать основы сетевого взаимодействия на
базе стека протоколов TCP/IP и иметь представление о функцио-
нировании таких распространенных протоколов и приложений, как
FTP, SMTP, POP3, HTTP, TELNET, ping, traceroute, использован-
ных в большинстве примеров книги. При необходимости эти зна-
ния можно получить или обновить в литературе [61,64].
Структура книги организована следующим образом. В первой
главе приведены основные угрозы информационной безопасности
при подключении локальных компьютерных сетей к Интернет, опи-
саны принципы обеспечения информационной безопасности. На-
глядно продемонстрировано - какие задачи обеспечения информа-
ционной безопасности можно решать при использовании межсетевых
экранов.
Во второй главе рассмотрены компоненты архитектуры меж-
сетевых экранов. Этот материал позволяет понять базовые прин-
ципы работы функциональных модулей, входящих в состав межсе-
тевых экранов, и подготавливает читателя к изучению более
сложного материала.
Третья глава посвящена различным схемам классификации
межсетевых экранов. Классификация межсетевых экранов по уров-
ням модели взаимодействия открытых систем раскрывает основ-
ные типы межсетевых экранов и особенности их функционирова-
ния. В этой главе описаны особенности работы управляемых
коммутаторов, статических и динамических пакетных фильтров,
инспекторов состояний и прикладных посредников.
В четвертой главе приведены возможные схемы подключения
межсетевых экранов. В настоящее время в основном применяют
схему подключения с несколькими сетевыми интерфейсами. Под-
ключение с одним сетевым интерфейсом, приеняемое в первых
реализациях межсетевых экранов, практически уже не использу-
ют (для общего ознакомления оно также рассмотрено).
8
Пятая глава - основа книги. Она содержит подробное описание
большинства технологий защиты и функциональных возможностей,
используемых в современных межсетевых экранах. Знание воз-
можностей современных средств защиты позволяет обоснованно
подходить к выбору конкретных изделий, а также предъявлять
практически реализуемые требования при разработке политики
или архитектуры системы обеспечения информационной безопас-
ности организации.
К сожалению, межсетевые экраны не только не решают всех
задач информационной безопасности при организации защиты внеш-
него периметра безопасности, но и сами могут быть причиной на-
рушения информационной безопасности и объектами сетевых атак.
Шестая глава посвящена основным угрозам информационной бе-
зопасности межсетевых экранов.
Один из важных жизненных этапов функционирования любого
межсетевого экрана - этап тестирования и проверки реализации
принятой политики безопасности. В седьмой главе даны общие ре-
комендации по тестированию экранов и описаны различные про-
дукты, используемые для этих целей.
В восьмой главе приведен обзор наиболее интересных продук-
тов рынка межсетевого экранирования как коммерческих, так и
свободно распространяемых. В каждом из рассматриваемых про-
дуктов не только перечислены реализуемые функциональные воз-
можности, но и подчеркнуты те возможности, которые заметно
отличают их от других аналогичных продуктов. Даны рекоменда-
ции по выбору программных продуктов из множества представ-
ленных на рынке.
Хочется выразить глубокую признательность А.Н. Смирнову
из компании Demos за оказанную помощь в подготовке материа-
лов книги и своей жене О.И. Лебедь за поддержку и терпение.
Ваши пожелания и замечания направляйте по адресу:
SVL@demos.su.
Автор
9
ВВЕДЕНИЕ. ИСТОРИЯ ИНДУСТРИИ
МЕЖСЕТЕВЫХ ЭКРАНОВ
Большинство публикаций, посвященных истории Интернет, на-
чинается примерно так: «В 1957 г. СССР запустил Спутник, Пер-
вый искусственный спутник Земли. В ответ Соединенные штаты
формируют Advanced Research Projects Agency (ARPA)...’». Так
в 1969 г. в результате холодной войны появилась военная исследо-
вательская сеть ARPANET, прародительница современной глобаль-
ной сети Интернет.
По ряду причин при разработке стека протоколов TCP/IP - ос-
новы сети Интернет - не было уделено должного внимания вопро-
сам безопасности. В результате в мире Интернет до сих пор остро
стоят вопросы информационной безопасности. Одним из методов
защиты сетевых информационных ресурсов организации является
использование специальных программных (программно-аппарат-
ных) средств, называемых в англоязычной литературе Fire Wall (ог-
ненная стена). В отечественной технической литературе их приня-
то называть межсетевыми экранами (МЭ). Иногда встречается
название «брандмауэр», но сейчас этот термин устарел и исполь-
зуется редко.
Индустрия МЭ постоянно развивается. Вслед за развитием но-
вых способов нарушения информационной безопасности создава-
лись и новые технологии защиты, предотвращающие такие нару-
шения.
Межсетевые экраны первого поколения - фильтры пакетов -
появились в конце 1980-х годов и представляли собой сетевые мар-
шрутизаторы с расширенными функциями. В 1985 г. компания Cisco
(подразделение IOS software) представила законченное решение
фильтрующего маршрутизатора. Первые публикации, описываю-
щие процесс экранирования, использующий фильтрацию пакетов,
появились только в 1988 г. (Дж. Могул из компании DEC).
’ http://info.isoc.org/guest/zakon/Intemet/History/HIT.html- по этому адресу
можно найти подробную информацию об истории развития Интернета.
10
Д. Пресото и Г. Трикей из AT&T Bell Laboratories в течение
1989 - 1990 годов разработали архитектуру МЭ второго поколения,
известных сейчас как МЭ уровня соединения (circuit level). Они же
испытали первую рабочую модель МЭ следующего поколения - МЭ
прикладного уровня - однако эти работы не были опубликованы.
Сегодня этот тип МЭ принято называть инспекторами состояний.
Третье поколение межсетевых экранов прикладного уровня раз-
рабатывалось одновременно несколькими группами в Соединенных
Штатах в конце 1980 - начале 1990-х годов. Публикации Г. Спафорда
из университета Пардью, Б. Чесвика из AT&T Bell Laboratories и
М. Ранума, описывающие МЭ прикладного уровня, впервые по-
явились в 1990 - 1991 годах. Работа Ранума была быстро реализо-
вана в первом коммерческом продукте DEC SEAL. 13 июня 1991 г.
первый коммерческий МЭ DEC SEAL был предоставлен хими-
ческой компании.
1 октября 1993 г. компания Trusted Information System (TIS) пре-
доставила сообществу Интернет в исходных текстах пакет разра-
ботки МЭ Fire Wall Toolkit (FWTK), что послужило мощным толч-
ком разработки новых продуктов. FWTK составил основу
коммерческого МЭ Gauntlet. Отдельные компоненты FWTK и в
настоящее время используют в некоторых коммерческих и во мно-
гих свободно распространяемых продуктах.
В 1991 г. Б. Чесвик и С. Белловин разработали для Bell Labora-
tories межсетевой экран, реализующий технологию динамической
фильтрации пакетов, однако он не был реализован. В 1992 г. Б.
Брейден и А. Дешон из USCs Information Sciences Institute начали
совместные исследования МЭ динамической фильтрации пакетов
для системы, которую они назвали «Visas». Компания Check Point
Software реализовала в 1994 г. первый коммерческий продукт,
основанный на этой архитектуре.
Следующим толчком в развитии технологии стало появление
МЭ Fire Wall-1 компании Check Point. Впервые МЭ имел друже-
ственный цветной графический интерфейс пользователя, значитель-
но облегчающий процесс настройки и обслуживания.
Начиная примерно с середины 1990-х годов, рынок продуктов
межсетевых экранов получил бурное развитие и на сегодняшний
день насчитывает более ста реализаций различных производителей.
Сегодня ни одна организация, использующая Интернет, не обходится
без использования МЭ или, по крайней мере, отдельных технологий
межсетевого экранирования.
11
Рис. В.1. Распределение продуктов безопасности
Современные коммерческие МЭ представляют собой сложные
многофункциональные системы, использующие последние достижения
в области информационных технологийизащиты информации. Сегодня
МЭ представляют до 85 % всех используемых в локальных сетях
средств защиты и по прогнозу некоторых аналитических компаний
МЭ, поддерживающие технологию виртуальных частных сетей, дли-
тельное время будут составлять основу средств защиты информа-
ции при подключении организаций к публичным сетям (рис. В. 1).
1. МЕЖСЕТЕВОЕ ЭКРАНИРОВАНИЕ -
ТЕХНОЛОГИЯ ИНФОРМАЦИОННОЙ
БЕЗОПАСНОСТИ
Развитие любых технологий всегда сопровождается их использо-
ванием в силовых и в противоправных целях. Можно привести не-
мало примеров, когда передовые достижения человечества исполь-
зовались преступниками при совершении, как принято говорить,
преступлений с использованием высоких технологий. Развитие ин-
формационных технологий не только предоставило широкие воз-
можности для новых общественных отношений, но и дало возмож-
ность совершения высокотехнологичных преступлений. Теперь
преступления стало возможным совершать, сидя за компьютером,
не выходя из дома или рабочего кабинета, и при этом совершенно
не рискуя физической безопасностью.
В главе 1 показана роль информационных технологий в совре-
менном обществе, необходимость обеспечения информацион-
ной безопасности и ее основные принципы, место политики ин-
формационной безопасности - основного документа организации,
отражающего взгляд руководства на вопросы информационной бе-
зопасности. Рассмотрены преимущества использования межсете-
вых экранов - технических средств обеспечения информационной
безопасности.
1.1. Угрозы сетевой информационной безопасности
Роль информационных технологий в современном мире
Экспериментальная сеть ARPANET, разработанная американ-
скими учеными сначала для повышения надежности военной сис-
темы управления, а затем дешевого и быстрого обмена сообще-
ниями, стала прародительницей современной глобальной сети
13
Интернет. Сегодня для многих людей в мире Интернет это:
• быстрый и дешевый способ общения;
• способ поиска и общения с единомышленниками;
• способ донесения до всех людей своих идей и мыслей;
• возможность ведения бизнеса и приобретения товаров и
услуг;
• возможность оперативного доступа к различного рода инфор-
мации;
• способ создания рабочих коллективов, члены которых живут
в различных странах и многие другие возможности, объединяю-
щие людей на различных континентах.
Те же принципы, заложенные в основу сети Интернет, успешно
используются и в частных сетях (локальных сетях, интранет, экст-
ранет). Использование локальных сетей позволяет автоматизиро-
вать большое число задач, значительно повысить эффективность
их решения, перейти на «безбумажную» организацию труда.
Доступ к информации - вот что побуждает людей воспользо-
ваться услугами сети Интернет. Существует более сотни опреде-
лений понятия «информация». Независимо от определений, очевидно,
что далеко не любую информацию можно предоставить для обще-
го доступа. Существует информация, определяемая как государ-
ственная тайна, коммерческая тайна, тайна личной жизни и др.
Каждые общественные образования могут определить, что для них
является тайной. Можно утверждать, что если одни определяют
тайну, то всегда существуют другие, которые хотят получить к ней
доступ. С развитием информационных технологий информация при-
обретает особое значение.
Можно привести много примеров, когда несанкционированный
доступ к информации или ее уничтожение приводили к различного
рода издержкам. Например, в декабре 2000 г. злоумышленники
похитили с сайта Creditcards.com, расположенного в Лос-Анджеле-
се, 55 тыс. номеров кредитных карт. Стоимость замены одной кре-
дитной карты составляет 10...20 $. Нетрудно подсчитать, что сто-
имость замены всех похищенных карт составила около 1 млн $.
Хранение информации
Организации располагают собственными информационными
ресурсами, представленными в виде файловых архивов, баз дан-
ных, прикладных сетевых сервисов и др. В большинстве случаев
непосредственный доступ к информационным ресурсам осуществ-
14
ляется по технологии клиент/сервер. Клиенты с помощью специ-
ального программного обеспечения подключаются к соответству-
ющим серверам и запрашивают необходимую им информацию.
Рабочие станции пользователей также могут выступать в каче-
стве сервера, например, для предоставления доступа к файловой
системе коллегам.
От кого нужно защищать информационные ресурсы
Прежде всего, от тех, кто может быть в них заинтересован.
Для коммерческих организаций - это конкуренты и преступные
сообщества, для правительственных ведомств - иностранные раз-
ведки. Рабочие станции, подключенные к сети Интернет, также
представляют повышенный интерес для злоумышленников. Рабо-
чие станции могут хранить параметры доступа к различным плат-
ным информационным сервисам, в том числе к системам элект-
ронных платежей, к сервис-провайдеру сети Интернет. Кто бы ни
выступал в качестве желающих заполучить доступ к защищаемым
информационным ресурсам, их принято называть хакерами или зло-
умышленниками.
Как и кто защищает информационные ресурсы
Защиту информационных ресурсов организации планирует и осу-
ществляет посредством использования специальных программных
и аппаратных средств администраторы безопасности сети или се-
тевые администраторы.
Почему существует возможность нарушения
информационной безопасности
Несмотря на огромные достижения в области информацион-
ных технологий, именно человеческий фактор остается ее самым
слабым звеном. Ошибки разработчиков общего программного
обеспечения (ПО) и средств защиты, сетевых администраторов,
администраторов безопасности - основные причины известных на-
рушений информационной безопасности компьютерных систем. Это
так называемые непреднамеренные ошибки ПО и ошибки адми-
нистрирования систем. Но существуют и преднамеренные действия
как разработчиков, так и злоумышленников, специально разраба-
тывающих программные закладки, троянские программы и остав-
ляющих «потайные ходы» (back doors) в своих программах.
15
Немалая часть проблем информационной безопасности (ИБ)
связана и с ошибками руководителей предприятий при организации
защиты своих информационных ресурсов. Известная организация
«SANS Institute» [19] выделила семь правил, невыполнение кото-
рых руководителями создает условия уязвимости ИБ:
• если проблема будет игнорирована, она будет появляться по-
вторно;
• при краткосрочном решении проблемы безопасности будут
появляться вскоре повторно;
• неверное представление стоимости информационной репута-
ции организации;
• полностью полагаются на защиту, реализуемую МЭ;
• ошибки соблюдения аспектов безопасности - корректировка
выявленных уязвимостей выполняется без последующей провер-
ки того, что проблема полностью решена;
• отсутствие понимания взаимосвязи ИБ и вопросов (проблем)
бизнеса. Есть понимание физической безопасности и отсутствие
понимания необходимости информационной безопасности;
• поручение неподготовленным сотрудникам решать вопросы
безопасности, не обеспечивая в дальнейшем их обучение.
1.2. Основные принципы обеспечения
информационной безопасности
С точки зрения безопасности к информации как объекту защи-
ты выдвигается три важных требования: конфиденциальность, це-
лостность, доступность (рис. 1.1).
Конфиденциальность - никто, кроме легальных пользовате-
лей, не может получить доступ к данным.
Целостность - никто, кроме легальных пользователей, не мо-
жет выполнять операции изменения данных.
Доступность - данные всегда должны быть доступны легаль-
ным пользователям.
Каждое из этих требований безопасности разбивается на уров-
ни, которые в дальнейшем ставятся в соответствие, определенным
категориям легальных пользователей.
Процесс обеспечения безопасности информации должен иметь
комплексный, непрерывный и адекватный характер. Комплексность
подразумевает использование всех необходимых методов и
средств защиты. При этом принимаемые меры должны отвечать
принципам разумной достаточности (адекватности защиты возмож-
ным угрозам ИБ).
16
Рис. 1.1. Требования и сервисы обеспечения
безопасности информации
Безопасность информации обеспечивается сервисами безопас-
ности, среди которых особо выделяют следующие: контроль дос-
тупа, аудит событий, аутентификация, мониторинг активности,
шифрование, контекстная (антивирусная) проверка, резервное копи-
рование, анализ защищенности.
Контроль доступа - сервис ИБ, определяющий порядок дос-
тупа (разрешить или запретить) объектов (пользователей и про-
цессов) к различным информационным ресурсам на основе неко-
торых исходных данных (имя и пароль пользователя, IP-адрес
клиента, время суток и др.). Контроль доступа является неотъем-
лемой частью обеспечения ИБ.
Аудит событий основывается на анализе сообщений генери-
руемых различными средствами и подсистемами безопасности
(журналы событий операционных систем, прикладных служб, меж-
сетевых экранов, систем обнаружения вторжений и др.). Аудит
событий позволяет выполнить анализ попыток несанкционирован-
ного доступа и вторжений, аномальной активности пользователей
17
и других событий безопасности, обнаруженных средствами защи-
ты. По результатам анализа данных аудита могут быть приняты
дополнительные меры защиты. Кроме этого, совокупный анализ
событий, полученных от различных систем, позволяет «видеть»
комплексную картину состояния безопасности информационной си-
стемы в целом.
Аутентификация - процесс, гарантированно определяющий
подлинность объекта аутентификации на основе предъявляемых
идентификаторов и использования специальных протоколов и схем
аутентификации. Контроль доступа, аутентификация и аудит собы-
тий являются основными сервисами безопасности в локальных
сетях.
Мониторинг активности позволяет в реальном времени от-
слеживать всю динамику изменения как сетевых событий, так и
событий безопасности. Мониторинг активности предоставляет та-
кие данные, как списки активных пользователей и используемые
ими ресурсы, списки открытых соединений, распределения исполь-
зования прикладных сервисов, количество открытых соединений
каждым клиентом и др. Периодический мониторинг активности
направлен прежде всего на обнаружение так называемой аномаль-
ной (необычной) активности. Под необычной активностью пони-
маются такие действия пользователей, троянских программ и зло-
умышленников, которые, используя различные приемы, нарушают
или способствуют нарушению политики безопасности.
Шифрование обеспечивает защиту данных путем использо-
вания криптографических методов и гарантирует невозможность
чтения информации без знания секретного ключа. Шифрование
сообщений и данных позволяет безопасно передавать их через от-
крытые (общедоступные) сети.
Контекстная (антивирусная) проверка контролирует данные
на прикладном уровне и различных стадиях их жизненного цикла.
Примерами контекстной проверки являются: антивирусная защи-
та, контроль содержимого Web-страниц (java, ActiveX, теги HTTP)
и ограничение доступа к Web/FTP-ресурсам на основе URL.
Резервное копирование, как процесс обеспечения ИБ, позво-
ляет быстро восстановить данные (с откатом к некоторому пре-
дыдущему состоянию) в случае их повреждения, уничтожения,
изменения по причине нарушения ИБ. Резервное копирование, во-
обще говоря, предназначено в первую очередь для минимизации
последствий аппаратных и программных ошибок. Но в случаях,
когда предъявляются особые требования к безопасности данных,
может рассматриваться и как сервис обеспечения ИБ.
18
Контроль и анализ защищенности - комплекс мероприятий,
направленных на оценку текущего состояния ИБ системы. Анализ
защищенности выявляет уязвимости ИБ, которые должны быть
исключены (путем применения пакетов исправлений, соответству-
ющей настройкой средств защиты и программного обеспечения).
Физическая и техническая защита направлена на ограниче-
ние физического доступа персонала и других лиц к объектам ин-
формационных систем (серверные комнаты, линии коммуникаций,
носители информации и др.). Техническая защита подразумевает
использование специальных технических средств, таких как сис-
темы видеоконтроля и физического доступа, охранные сигнализа-
ции и др. Физическая и техническая защита являются неотъемле-
мой частью комплексного обеспечения ИБ.
1.3. Межсетевое экранирование
Как было показано выше, использование сети Интернет связа-
но с определенными рисками ИБ. Сети организаций, подключен-
ные к Интернет без использования специальных мер защиты,
становятся полноценными ее членами, а значит, и являются потенци-
альными объектами воздействий злоумышленников. При непосред-
ственном подключении сети к Интернет злоумышленник может без
особых трудностей выполнить следующие действия (рис. 1.2):
• получить информацию об адресной структуре сети и простран-
стве имен DNS;
• установить типы и версии используемого сетевого ПО (сете-
вое оборудование, операционные системы, прикладные и служеб-
ные сервисы);
• получить информацию о пользователях сети;
• попытаться осуществить несанкционированное подключение
к информационным ресурсам сети;
• вызвать отказ в обслуживании легальных пользователей.
Кроме явных, т. е. непосредственно направленных на сеть орга-
низации, внешних угроз ИБ, существуют угрозы, связанные с не-
умышленным распространением зловредного программного кода
самими сотрудниками организации. К зловредному программному
коду относят вирусы, троянские гфограммы, «опасные» компонен-
ты прикладных протоколов.
В большинстве случаев подключение локальных сетей к Ин-
тернет (и вообще сетей между собой) осуществляется таким об-
19
ю
о
Интернет
Злоумышленники
WWW
Бесплатное и условно
бесплатное ПО
WWW-серверы
сомнительного содержания
сбор информации о структуре сети
и ее пользователях
несанкционированый доступ к
информационным ресурсам
отказ в обслуживании сетевых сервисов
троянские программы
злонамеренные программы (вирусы)
ActiveX, Java
Корпаративные
информационные
ресурсы
Локальная сеть
организации
(Интранет)
FTP WWW
Пользователи
локальной сети
Рис. 1.2. Внешние угрозы ИБ
разом, что в точке соединения сетей существует возможность кон-
троля всего сетевого трафика, проходящего между этими сетями.
Исключение составляет случай, когда локальная сеть одновременно
подключена к Интернет более чем одним соединением, например,
для резервирования каналов связи или повышения пропускной спо-
собности.
МЭ, будучи первым эшелоном обороны, позволяет значитель-
но уменьшить, а в некоторых случаях и полностью исключить зону
возможных рисков при подключении к потенциально опасным се-
тям, таким как Интернет (рис. 1.3 и 1.4). В идеальном случае МЭ
должен блокировать все угрозы ИБ, имеющие место в Интернет,
на своем внешнем сетевом интерфейсе.
Под контролем трафика понимается возможность его блокиро-
вания (запрещения), разрешения или изменения. Такие действия и
выполняет МЭ, обеспечивая защиту («экранирование») сети.
Говоря о МЭ, прежде всего подразумевают что они использу-
ются в Интернет, которая базируется на стеке протоколов TCP/IP.
Сети на основе протокола IP являются сетями с коммутацией
пакетов. Пакеты в таких сетях выступают единицей передачи дан-
ных между участниками сетевого обмена. В самом общем случае,
Рис. 1.3. Зоны риска незащищенной части сети
Межсетевой
экран
Рис. 1.4. Зоны риска защищенной части сети
21
Рис. 1.5. Принципы межсетевого экранирования
МЭ выполняет фильтрацию сетевых пакетов согласно некоторым
правилам. Но как будет показано далее, перед принятием решения
о судьбе пакета современные МЭ выполняют более сложную про-
верку.
Межсетевой экран представляет собой программный, аппа-
ратный или программно-аппаратный комплекс, реализующий фун-
кции фильтрации сетевого трафика (информационных потоков) меж-
ду двумя (или более) автоматизированными системами по
некоторому набору правил, определяемых политикой безопаснос-
ти защищаемой сети (рис. 1.5).
Другими словами, МЭ - это компонент сетевой инфраструкту-
ры, устанавливающий барьер безопасности между сетями или се-
тевыми сегментами. МЭ представляет собой устройство, частич-
но реализующее принятую политику безопасности сети организации.
Межсетевой экран разделяет физически и логически две и более,
как правило, IP-сети на сети с различными политиками безопасно-
сти. В большинстве случаев МЭ разделяет две сети, одна из кото-
рых является сетью защищаемой организации, а другая - Интер-
нет.
1.4. Преимущества использования МЭ
Функциональные возможности современных МЭ позволяют в
ряде случаев возложить на них до 100 % всех требований полити-
ки безопасности организации. Основными преимуществами исполь-
зования МЭ являются следующие.
22
Управляемый доступ к сетевым ресурсам
МЭ реализует политику безопасности организации, которая, в
частности, исходя из решаемых ею задач, определяет сервисы и
порядок доступа к ним всех категорий пользователей. Основным
преимуществом использования МЭ является его способность обес-
печения управляемого доступа пользователей к информационным
ресурсам.
Под управляемым доступом понимается метод защиты, осно-
ванный на регулировании использования всех ресурсов системы.
Реализация управляемого доступа к сетевым ресурсам позво-
ляет:
• значительно повысить уровень ИБ путем ограничения числа
разрешенных сервисов;
• повысить уровень защиты разрешенных сервисов за счет раз-
граничения доступа на уровне пользователей и групп пользовате-
лей;
• ограничить доступ к ресурсам сомнительного содержания;
• пресекать использование рабочего времени не по назначению.
Защита сетевых ресурсов от внешних угроз
Внешние факторы являются основным источником угроз ИБ и
основной задачей МЭ является обеспечение надежной защиты
именно от внешних угроз.
МЭ позволяет значительно усилить защищенность потенциаль-
но уязвимых сетевых сервисов, непосредственное использование
которых может привести к нарушению ИБ. Существует немало
полезных и удобных прикладных сервисов, использование которых
в ряде случаев запрещается политикой безопасности по причине
их потенциальной уязвимости. Примером такой службы может быть
интерфейс NetBIOS (точнее, NBT - NetBIOS over TCP). Удален-
ные пользователи операционных систем (ОС) MS Windows с лег-
костью бы использовали встроенные возможности этой ОС при
подключении к корпоративным файловым ресурсам.
МЭ позволяет решить проблемы использования уязвимых сер-
висов и усилить защищенность используемых прикладных служб
путем установления специальных посредников между клиентами и
сервером службы.
Контроль МЭ содержимого сетевых соединений позволяет об-
наруживать и блокировать на входе в защищаемую сеть деструк-
тивный код (вирусы, троянские программы, java, ActiveX).
23
Обнаружение и защита от типовых атак
отказа в обслуживании
МЭ обеспечивают защиту от большинства типовых атак типа
отказа в обслуживании, а также позволяют обнаруживать и мно-
гие другие типы атак, частично выполняя функции систем обнару-
жения вторжений (в некоторых реализациях МЭ).
Скрытие структуры локальной сети
Большинству сетевых вторжений злоумышленников в корпора-
тивные сети предшествуют подготовительные действия, целью
которых является изучение физической и логической структур сети,
а также поиска в ней уязвимых мест.
Использование МЭ позволяет практически полностью решить
эту проблему. В большинстве случаев корпоративная сеть может
быть представлена с внешней стороны всего одним IP-адресом,
даже если она состоит из сотен компьютеров!
Конфиденциальность внешних сетевых соединений
Непосредственное использование сети Интернет для передачи
конфиденциальных данных между подразделениями организации,
мобильными пользователями и в ряде других случаев не обеспе-
чивает безопасности соединений. Кроме того, очень немногие при-
ложения используют защищенные соединения, а большинство из-
вестных реализаций таких распространенных служб, как TELNET,
FTP, POP3, передают данные и пароли в открытом виде.
МЭ обеспечивают конфиденциальность внешних соединений
посредством использования технологии виртуальных частных се-
тей.
Аудит событий безопасности
Аудит событий безопасности является одним из методов обес-
печения ИБ. МЭ состоит из нескольких взаимосвязанных функци-
ональных модулей, каждый из которых генерирует собственные
сообщения событий безопасности. Непрерывное накопление и ана-
лиз этих событий позволяют:
• выявлять попытки нарушения ИБ;
• обнаруживать источники угроз и нарушителей ИБ;
• усиливать защищенность сети за счет обнаружения слабых и
уязвимых мест.
24
Управление сетевым трафиком
МЭ в некотором приближении можно рассматривать как сете-
вой маршрутизатор с расширенными функциями. Подобно сете-
вым маршрутизаторам, МЭ управляют прохождением трафика
между сетями, что позволяет:
• накапливать и предоставлять различную учетную информа-
цию (время работы пользователей, распределение объема трафи-
ка между пользователями и службами, статистика ошибок и др.);
• распределять нагрузку между прикладными службами (ба-
лансировка нагрузки).
Доля участия МЭ в реализации политики безопасности (ПБ)
зависит в первую очередь от требований политики безопасности, а
также от его функциональных возможностей. По этой причине ад-
министраторам безопасности очень важно знать потенциальные
возможности МЭ и используемых в них технологий защиты.
1.5. От чего не может защитить МЭ
Основное предназначение МЭ заключается в реализации при-
нятой сетевой политики безопасности организации в части, касаю-
щейся доступа к сетевым ресурсам организации из общедоступ-
ной сети и доступа к ресурсам открытой сети сотрудников. Как
было показано выше, МЭ основывается на возможности контроля
трафика, проходящего между сетями.
Очевидно, только одного контроля межсетевого трафика явно
недостаточно для предотвращения всех угроз ИБ. Рассмотрим
угрозы сетевой безопасности, от которых технология МЭ защи-
тить не может.
Внутренние угрозы
По данным консалтинговых компаний, оказывающих услуги в
области ИБ, большинство всех случаев реализаций угроз сетевой
безопасности происходит во внутренней сети или по причинам,
вызванным персоналом компании.
Атаки, направленные из внутренней сети на внутренние корпо-
ративные ресурсы, не видны для МЭ, поскольку сетевые пакеты,
реализующие эти атаки, не проходят через него. В этом случае
МЭ, установленный на границе сети, не может обеспечить защиты.
25
Политика безопасности организации должна предусматривать
и защиту от внутренних угроз, что достигается как администра-
тивными мерами, так и техническими (физическая защита досту-
па к носителям, разграничение доступа к внутренним прикладным
сервисам и др.).
Иногда целесообразно установить МЭ во внутренней сети орга-
низации между сетевыми сегментами, в которых циркулируют дан-
ные с разными уровнями доступа (конфиденциальности) или необ-
ходимо обеспечить защиту критически важных служб.
Несанкционированные модемные соединения
Рассматриваемый вид угроз также относится к внутренним, но
по своей простоте реализации и опасности выделяется особенно.
Несанкционированное использование модемов, подключенных
к рабочим станциям пользователей, является одной из самых опас-
ных и трудно обнаруживаемых угроз безопасности. Действитель-
но, все усилия по обеспечению надежной защиты сети могут быть
сведены на нет при непосредственном подключении рабочего ме-
ста к Интернет через модемное (коммутируемое) соединение.
Причем подключение не обязательно может использоваться для
доступа в Интернет. Возможны соединения и к серверам других
организаций, и к отдельным компьютерам, например домашним.
Часто модемы входят в состав рабочих мест пользователей.
Пользователям достаточно лишь настроить сетевое соединение.
Причины наличия модемов:
• модемы встроены в портативные компьютеры или поставля-
лись вместе с компьютерами;
• модемы предназначены для обеспечения факсимильной свя-
зью рабочих мест пользователей.
И в первом, и во втором случае проблема может быть решена
только организационным путем - модемы должны быть изъяты из
системных блоков, а факсимильная связь должна быть организо-
вана, например, через сетевой факс-сервер.
Развитие современных систем и средств связи (мобильная
связь, беспроводные устройства доступа, персональные цифровые
помощники и органайзеры) только усугубляет проблему несанкци-
онированных сетевых подключений.
26
Таким образом, МЭ не является достаточным техническим
средством обеспечения ИБ организации и ее самым уязвимым
местом являются пользователи защищаемой сети. МЭ не в состо-
янии защитить сеть от своих же пользователей и важно, что он и не
должен делать это!
1.6. Политика безопасности
Значимость информационных технологий в современном мире
неоспорима. Подключение локальной сети к сети Интернет откры-
вает широкие возможности для различных приложений обмена ин-
формацией. Вместе с тем локальная сеть становится доступной
всем пользователям сети Интернет. Доступности, целостности и
конфиденциальности данных, циркулирующих в локальных и гло-
бальных сетях при организации и ведении различных бизнес-отно-
шений и управлении критическими инфраструктурами уделяется
особое внимание. Ущерб от действий злоумышленников в инфор-
мационной сфере исчисляется триллионами долларов в год. Со-
гласно данным издательства Information Week Research (http://
www.intemetwk.com/) в 2000 г. ущерб от действий хакеров и виру-
сов в мировом масштабе составил 1,6 трлн $. Злоумышленниками
являются не только отдельные личности, но и хорошо организован-
ные, технически высококвалифицированные преступные группы. В
промышленном шпионаже появилось новое направление - компь-
ютерный шпионаж. Конфиденциальную информацию необходимо за-
щищать!
В этих условиях каждая организация должна четко понимать
насколько для нее опасны те или иные формы утечки или потери
информации. Конечно, существуют организации, не использующие
по разным причинам современные методы обработки, хранения и
обмена информацией со своими партнерами или клиентами. Но и в
этом случае простейший вирус может парализовать ее деятель-
ность на несколько дней. Вот почему организация, осознающая важ-
ность, критичность своих данных, должна разработать и практи-
чески реализовать собственную политику безопасности (security
policy).
Политика безопасности (ПБ) - это взгляд руководства органи-
зации на проблему ИБ. В ПБ входят правила и инструкции для все-
го персонала организации, призванные защитить ее информацион-
ные ресурсы. Ее разрабатывают документально и она должна
описывать:
27
• какие данные представляют ценность и как они должны быть
защищены;
• какие прикладные сервисы доступны различным категориям
пользователям и каков порядок доступа к ним;
• что понимается под нарушением ИБ;
• права и обязанности всех сотрудников в области ИБ;
• ответственные должностные лица;
• инструкции пользователям и должностным лицам на случай
обнаружения нарушения ИБ.
Рис. 1.7. Пример организации сетевой безопасности
с двумя периметрами безопасности
28
Рассматривая безопасность информационных систем, выделя-
ют периметры безопасности - условные границы, разделяющие
зоны с разными уровнями безопасности (рис. 1.6). В большинстве
случаев периметр безопасности включает как минимум две гра-
ницы - внутренний и внешний периметры (рис. 1.7). МЭ разделяет
внутренний и внешний периметры, являясь барьером безопаснос-
ти двух (и более) сетей.
Политика безопасности реализуется административными (орга-
низационными) мероприятиями, физическими и техническими сред-
ствами. С этой точки зрения МЭ можно рассматривать как техни-
ческое средство, практически реализующее часть политики
безопасности организации. Оно формализует описание ПБ в виде
правил, конфигурационных файлов и/или списков доступа.
2. ОСНОВНЫЕ КОМПОНЕНТЫ
АРХИТЕКТУРЫ МЕЖСЕТЕВЫХ ЭКРАНОВ
Современные МЭ являются сложными и многофункциональны-
ми системами. Можно выделить следующие основные компоненты
(модули) МЭ (рис. 2.1): база правил, пакетный фильтр, модуль аутен-
тификации и авторизации, журнал событий, модуль управления, ядро
МЭ, модуль мониторинга и оповещения, прикладные посредники,
модуль поддержки VPN, модуль создания отчетов. Для более ясного
понимания принципов функционирования и функциональных воз-
можностей МЭ рассмотрим подробнее назначение и взаимодей-
ствие этих компонентов.
2.1. Архитектура МЭ
Знание архитектуры позволяет более полно оценить возможно-
сти продукта. Под архитектурой МЭ понимают прежде всего тех-
нические решения разработчиков, принятые за основу реализации
разрабатываемого продукта. При этом выделяют базовую плат-
форму (аппаратная часть, операционная система - ОС), языки и
среду разработки и, конечно, алгоритмы функционирования как от-
дельных модулей, так и всего МЭ в целом. Этапу проектирования
предшествует этап определения функциональных возможностей,
целей, задач, условий и границ использования продукта. Как прави-
ло, по вполне понятным причинам производители не раскрывают
особенностей алгоритмов функционирования своих продуктов.
Существует один из немногих компонентов архитектуры МЭ,
особенности реализации которого подчеркивают производители, -
ядро МЭ. Оно реализует функции по первичной обработке потоков
данных и в большинстве случаев определяет ряд показателей МЭ,
таких как безопасность, производительность, устойчивость к ата-
кам типа «отказ в обслуживании».
30
Модуль управления
Политика безопасности
(база правил)
Прикладные посредники
HTTP, FTP, TELNET...
VPN
&
Ядро (сетевой стек)
Аутентификация
Журнал событий
Мониторинг и сигнализация
Рис. 2.1. Основные компоненты архитектуры межсетевого экрана
В зависимости от типа МЭ ядро может быть реализовано:
• на прикладном уровне ОС;
• в виде драйвера ОС;
• в виде драйвера под управлением специальной защищенной ОС;
• программным модулем программно-аппаратной платформы.
Как правило, ядро МЭ встраивается ниже сетевого стека ОС
или полностью заменяет ее некоторые низкоуровневые модули
(драйверы), тем самым усиливая ее сетевой стек. Большинство
МЭ (все коммерческие экспертного класса) не полагаются на под-
держку системы защиты самой ОС, а применяют собственные
драйверы устройств и стеки протоколов. Использование специаль-
но разработанного сетевого стека позволяет значительно повысить
защищенность ОС. Так, например, в состав МЭ BlackHole компа-
нии MilkyWay входит собственный сетевой стек «Hardened TCP/IP
31
Stack», который заменяет собственный стек Windows NT и может
работать независимо. Даже использование этого стека без самого
МЭ позволяет: ограничивать максимальный размер пакетов и ТСР-
окна, управлять параметрами протокола ARP (время тайм-аута,
время жизни, время повтора запросов), блокировать пакеты на ос-
нове заданных параметров, защищаться от Syn-flood-атак, отправ-
лять уведомления о событиях на другой хост!
Реализация ядра на прикладном уровне характерна для МЭ,
выступающих в роли прикладных посредников или реализующих
функции защиты на основе прикладных протоколов. Уязвимости ОС
могут стать причиной уязвимости и самого МЭ. Особенно недопу-
стимы ошибки в стандартных библиотеках ОС. Так или иначе, МЭ
пользуется услугами, предоставляемыми ОС (управление памя-
тью и другими ресурсами, операции ввода/вывода, обработка строк
и др.). Появление (наличие) ошибки в любой из этих библиотек
может привести к проявлению ослабления защиты МЭ. Особенно
это обстоятельство характерно для уязвимостей, вызванных ошиб-
ками переполнения буфера (buffer overflow).
Наиболее полно документирована архитектура сетевого стека
ОС компании Microsoft, которая предоставляет несколько интер-
фейсных уровней, позволяющих не только разрабатывать новые
сетевые протоколы и драйвера сетевых адаптеров на основе API,
но и выполнять различные операции над сетевым трафиком. Со-
гласно [16] в зависимости от типа ОС (Windows 95/98, NT, 2000,
ХР) существует возможность реализации пакетной фильтрации в
пользовательском режиме ОС четырьмя способами, а в режиме
ядра - пятью. На рис. 2.2 изображена архитектура сетевой подси-
стемы ОС Windows, где показаны некоторые возможные точки под-
ключения программ МЭ. Чем ниже расположен уровень подклю-
чения, тем больше уровень защиты может реализовывать
программа-МЭ, но вместе с этим повышается ее сложность, а зна-
чит, повышается и вероятность наличия ошибок этапа разработки.
Значительная часть уязвимостей сетевых систем зависит от
поэтапного повышения прав пользователя. Сетевая система ста-
новится полностью контролируемой злоумышленником при полу-
чении им права суперпользователя (root или administrator). Подоб-
ную схему может использовать и злоумышленник, чтобы получить
возможность управления МЭ. МЭ, работающие под управлением
специальных защищенных версий UNIX (CX/UX, CX/SX, например),
реализуют более высокий уровень защиты. В защищенных ОС внут-
ренние механизмы защиты реализованы особым образом. Первые
реализации МЭ на основе защищенных ОС называли «Bastion host».
32
User-Mode Client
Рис. 2.2. Архитектура сетевой подсистемы
ОС Microsoft Windows
Такая ОС может обеспечивать:
• мандатный контроль доступа;
• дискретный контроль доступа;
• усиленные механизмы идентификации и аутентификации всех
субъектов системы;
• аудит.
Производители МЭ, использующие защищенные версии ОС, за-
являют, что их продукты реализуют лучшую защиту сетей. Здесь
следует сделать два замечания:
2 Лебедь С.В.
33
• это верно с точки зрения защиты локальных процессов (ОС и
МЭ), безопасности администрирования, устойчивости и надежно-
сти самого МЭ;
• безопасность сетевых соединений и защищаемых сервисов
остается сильно зависимой от корректности реализации МЭ и реа-
лизуемой ПБ.
МЭ на базе защищенных ОС чаще используют внутри локаль-
ных сетей, где безопасности информации уделяется особое внима-
ние.
Специальные программно-аппаратные платформы также повы-
шают защищенность МЭ, поскольку изучение архитектуры МЭ и
вместе с этим его уязвимостей представляет для злоумышленни-
ков довольно сложную задачу.
2.2. База правил
База правил - это формализованное описание ПБ, содержащая
описание объектов сети (сети, сетевые группы, пользователи, сер-
висы и др.), правил их взаимодействия и другие параметры функ-
ционирования в терминах функциональных возможностей МЭ. В
различных реализациях можно встретить и другие названия базы
правил - правила МЭ (firewall rules), списки контроля доступа (access
control lists - ACL), файлы конфигурации (config files).
База правил полностью определяет политику безопасности пе-
риметра защищаемой сети. Политика безопасности, реализуемая
МЭ, является составной частью корпоративной ПБ организации,
которая должна определять:
• какие сервисы внешней сети могут быть доступны пользова-
телям защищаемой сети;
• какие сервисы защищаемой сети могут быть доступны пользо-
вателям внешней сети;
• кто допущен к внутренним и внешним сервисам;
• когда (время, дни) разрешен доступ к сетевым ресурсам.
Обычно правила составляются на специальном формализован-
ном языке, который интерпретирует МЭ. В этом случае база пра-
вил представляет собой один или несколько текстовых файлов* .
Для облегчения описания правил и управления ими большинство
коммерческих МЭ оснащено хорошо продуманным графическим
интерфейсом, практически исключающим ошибки администратора.
* Хорошим примером такого языка является язык МЭ Fire Wall-1 INSPECT.
34
В больших сетях описание политики безопасности является
сложным и трудоемким процессом, поэтому необходимо предпри-
нять дополнительные меры защиты файлов политики безопаснос-
ти средствами ОС, а также регулярно выполнять резервное копи-
рование основных конфигурационных файлов МЭ.
Важным свойством МЭ является политика безопасности, реа-
лизуемая по умолчанию. Существует два варианта политики по
умолчанию - все запрещено и все разрешено. В первом случае ни
один пакет не будет пропущен через МЭ без ввода соответствую-
щего правила, во втором - МЭ функционирует как обычный стати-
ческий маршрутизатор. Даже если МЭ по умолчанию, т. е. в от-
сутствии правил разрешает все пакеты, то не составляет труда
определить правило, блокирующее весь трафик.
2.3. Модуль аутентификации и авторизации
Прежде чем разрешить пользователю сети работать по неко-
торому протоколу или использовать какой-либо сетевой ресурс, МЭ
выполняет аутентификацию и авторизацию пользователей. Процесс
аутентификации обеспечивает проверку того, что пользователь
действительно является тем, кем себя представляет. Аутентифи-
кация выполняется с помощью различных алгоритмов и схем аутен-
тификации, которые будут рассмотрены далее. Процесс авториза-
ции обеспечивает определение права доступа к запрашиваемому
ресурсу. Ресурсом может быть сетевой или прикладной протокол,
пул сетевых адресов или отдельные прикладные серверы сети.
МЭ может поддерживать как внутренние, так и внешние про-
граммные и аппаратно-программные схемы и протоколы аутенти-
фикации, такие как RADIUS, TACACS, RS A SecurlD, NT Domain.
Если МЭ не поддерживает развитых средств аутентификации или
эти режимы не используются, пакетная фильтрация, которая под-
держивается практически любым МЭ, также может рассматри-
ваться как простейший способ аутентификации на основе 1Р-адре-
сов и транспортных портов отправителя и получателя сетевых
пакетов.
Часто аутентификацию на МЭ используют не столько для ре-
шения задачи контроля доступа, сколько для аудита и мониторинга
активности пользователей. В этом случае имеется возможность
регистрации в журнале событий, кроме времени события, 1Р-адре-
сов, транспортных портов клиента и сервера, но и имени пользова-
теля. В тех случаях, когда рабочие станции используются в много-
пользовательском режиме или режиме динамического назначения
2*
35
IP-адресов (DHCP), аутентификация может быть единственным
способом аудита и мониторинга активности пользователей.
Технологии аутентификации, поддерживаемые МЭ, имеют ряд
особенностей, которые будут рассмотрены далее в гл. 5.
2.4. Журнал событий
Межсетевой экран должен предоставлять возможность регис-
трации всех происходящих событий и действий, выполняемых им.
Такими событиями являются прием/отправка пакета из интерфей-
са, открытие/закрытие соединений, результаты аутентификации
пользователей, учет использования системных ресурсов и др. Со-
бытия регистрируются в журналах событий в виде сообщений, каж-
дое из которых представляет собой одну текстовую строку. Неко-
торые реализации МЭ позволяют регистрировать и двоичную
информацию - фрагменты пакетов домены памяти и др.
Анализ событий позволяет выявить попытки нарушения ИБ, оце-
нить корректность принятых настроек МЭ, получить распределе-
ние трафика между прикладными протоколами и пользователями и
другую необходимую информацию, которая может быть собрана
МЭ. Как показывает практика, особенно в больших компаниях, для
проведения административных расследований периодически воз-
никает необходимость обращения к журналам различной давнос-
ти. Поэтому рекомендуется вести практику хранения журналов МЭ
в течение одного года, а иногда и больше. Это также относится и к
журналам других важных ресурсов сети - базы данных, почтовые
серверы, серверы удаленного доступа и др.
МЭ должен регистрировать события как при успешных дей-
ствиях, так и при действиях, запрещенных ПБ. Исходя из ПБ и
нагрузки на МЭ, администратор решает, какие из событий должны
регистрироваться. По степени важности события делятся на ин-
формационные, предупреждения и критические.
Журнал событий хранится в одном из трех форматов: тексто-
вом, своем собственном или одной из баз данных (Oracle, Sybase,
Informix, MS SQL Server, DB2, MySQL или любой другой доступ-
ной, например, через интерфейс QDBC). Журнал может быть экс-
портирован в другие форматы для дальнейшей обработки. Неко-
торые МЭ записывают свои события в системные журналы ОС.
Так, например, BlackHole Fire Wall ведет журнал в своем собствен-
ном формате и позволяет экспортировать его в базу данных (БД)
MS Access; IBM eNetwork Fire Wall использует текстовый формат
журнала и предоставляет возможность записывать сообщения в
БД DB2.
36
К сожалению, стандартных форматов журналов событий для
МЭ пока не существует. Наибольшее распространение получил
формат компании WebTrends WELF (WebTrends Enhanced Log
Format), разрабатывающей продукты для анализа журналов собы-
тий. Некоторые МЭ используют формат Extended Log File Format
консорциума W3C, изначально предназначенного для протоколиро-
вания событий Web-серверов [20].
2.5. Модуль управления
Модуль управления предоставляет прикладные средства, обес-
печивающие выполнение всех административных действий над МЭ.
В состав модуля управления может входить:
• интерфейс пользователя (администратора);
• средства удаленного управления;
• средства резервного копирования и восстановления после сбоев;
• средства протоколирования изменения конфигурации;
• средства проверки целостности компонентов МЭ.
Интерфейс пользователя (администратора)
В зависимости от типа МЭ и платформы интерфейс может быть
графическим, текстовым или отсутствовать вовсе, а все настрой-
ки в этом случае выполняются в текстовых конфигурационных
файлах.
Интерфейс пользователя должен быть интуитивно понятен, не
вызывать противоречий в установках параметров и соответство-
вать принятым стандартам. Как говорилось выше, хорошо проду-
манный графический интерфейс пользователя исключает ошибки
администратора. Тем не менее до сих пор существует мнение о
нецелесообразности применения графического интерфейса в сис-
темах защиты, поскольку графическая система имеет ряд потен-
циально опасных мест, что делает всю систему уязвимой.
Некоторые МЭ, например CyberGuard, используют графичес-
кий интерфейс с одновременным отображением изменений в тек-
стовом конфигурационном файле. В этом случае графический ин-
терфейс облегчает редактирование текстового файла.
Хорошим тоном считается использование в продуктах стандарт-
ных интерфейсов ОС или интерфейсов управления, например ММС
в ОС Windows NT. Пользователям привычнее иметь дело со зна-
комыми элементами управления и навигации.
37
Средства удаленного управления МЭ
Управление МЭ, установленным в физически защищенном ме-
сте или в специальном шкафу, довольно неудобно. К тому же МЭ
может быть расположен на территориально удаленном объекте.
Чтобы исключить перехват пароля, средства удаленного управле-
ния (администрирования) должны обеспечивать защищенное со-
единение между МЭ и клиентом управления. Клиент удаленного
управления может быть как интегрирован с МЭ, так и стандарт-
ным средством удаленного управления, например на основе прото-
кола SSH.
Средства резервного копирования
и восстановления после сбоев
Средства резервного копирования (back-up) и восстановления
после сбоев предназначены для минимизации времени восстанов-
ления МЭ при программных и аппаратных сбоях. При обнаруже-
нии сбоев или краха системы администратор использует резерв-
ную копию всей системы или только основных файлов для
восстановления МЭ. Большинство МЭ использует возможности
резервного копирования, предоставляемые ОС (восстановление си-
стемы с ленты, периодический автоматический back-up).
Средства протоколирования изменения конфигурации
Часто возникают ошибки функционирования МЭ из-за некор-
ректных действий администратора. В этом случае наличие пре-
дыдущих версий конфигурационных файлов позволяет вернуть МЭ
к рабочему состоянию. Кроме этого, протоколирование изменения
конфигурации МЭ позволяет выполнять и важную функцию безо-
пасности - мониторинг изменения политики безопасности МЭ.
Средства проверки целостности компонентов МЭ
Автоматический контроль целостности компонентов (файлов)
МЭ позволяет обнаруживать и предотвращать вторжения зло-
умышленников на сам МЭ как объект нападения. Получение дос-
тупа злоумышленниками к МЭ позволяет им вести полный конт-
роль сетевых потоков. Контроль целостности состоит из двух этапов
- создание эталонной БД текущей конфигурации, содержащей кон-
трольные суммы всех критических файлов, и периодический ко нт-
38
роль соответствия контрольных сумм. Если МЭ не предоставляет
такой возможности, то можно использовать программы, подобные
Tripwire, MD5SUM.
2.6. Модуль мониторинга и оповещения
Модуль мониторинга и оповещения генерирует все динамичес-
кие и статистические данные всех подсистем МЭ и ОС (количе-
ство принятых/отправленных, разрешенных/запрещенных пакетов,
попыток неудачной аутентификации, расходование дискового про-
странства и оперативной памяти и др.) и оповещает администра-
тора о критических и иных событиях (обнаружение типовых атак,
исчерпание системных ресурсов, подключение к определенному
ресурсу новых пользователей и др.).
Большинство МЭ позволяют определять действия, которые дол-
жен осуществить экран в случае выполнении правила или наступ-
ления какого-либо события. К таким действиям относятся:
• запуск внешних программ с передачей им параметров;
• вывод сообщений на консоль управления МЭ;
• подача звукового сигнала;
• запись в журнал;
• отправка сообщения по электронной почте;
• отправка сообщения на пейджер;
• отправка SNMP-трапа.
Выбор того или иного способа оповещения зависит от типа пра-
вила, для которого определено событие МЭ. Например, для разре-
шающего правила нет смысла отправлять администратору сооб-
щение по электронной почте, поскольку администратору нет
необходимости отслеживать нормальную активность. Но в случае
срабатывания запрещающих правил или обнаружения вторжений
администратор должен быть информирован об этом как можно
скорее. Но и для запрещающих правил определять выполняемые
действия МЭ нужно осторожно, поскольку взрывной рост выпол-
нения таких правил (например, при сканировании портов, выполне-
нии атаки SYN-flood на запрещенные порты) может привести к
отказу обслуживания как самого МЭ, так и используемой схемы
оповещения. Чтобы исключить подобную ситуацию, некоторые МЭ
имеют опцию «регистрировать только первое событие» или «при-
менить только для первого пакета».
При организации защиты грамотное использование системы
сигнализации МЭ играет огромную роль, поскольку она в первую
очередь предназначена для выявления аномалий активности и пре-
39
дупреждения администратора безопасности о попытках наруше-
ния ИБ или ситуациях, требующих его вмешательства.
Модули мониторинга и оповещения современных МЭ частично
выполняют функции систем обнаружения вторжений (IDS - intrusion
detection system), целью которых является обнаружить и предотв-
ратить вторжения на первых стадиях их проявления.
2.7. Прикладные посредники
Прикладные посредники являются неотъемлемой частью боль-
шинства МЭ. Они позволяют управлять ПБ на прикладном уровне
сетевых приложений. Принцип действия посредников основывает-
ся на установлении посредничества между клиентом и сервером.
В самом общем случае клиент устанавливает соединение с по-
средником и запрашивает его об установлении соединения с сер-
вером. Таким образом устанавливается два соединения: между
клиентом и посредником и между посредником и сервером. По-
средник контролирует корректность и допустимость команд и па-
раметров, передаваемых клиентом с одной стороны, а при приеме
данных от сервера выполняет их проверку на ряд условий безопас-
ности. Очевидно, для каждого прикладного протокола должен быть
разработан собственный прикладной посредник, и для каждого при-
кладного протокола реализуемые функции безопасности также бу-
дут различными.
Поскольку посредники прикладного уровня понимают приклад-
ной протокол, то имеется возможность более тонко управлять по-
литикой доступа к сетевым сервисам. Например, большинство
посредников HTTP (HTTP-proxy) позволяет управлять доступом к
различным WEB-ресурсам по имени универсального локатора ре-
сурсов (URL), а также блокировать активные компоненты - Java,
Java script, ActiveX, теги HTML. Для протокола FTP возможно раз-
деление полномочий по доступу к файлам FTP-сервера по различ-
ным критериям. Например, разрешить доступ только к строго оп-
ределенным директориям или файлам, ограничить выполнение
FTP-команд, запретить загрузку файлов при превышении макси-
мально установленного размера файла.
Большинство ограничений использования прикладного сервиса
может быть установлено на самом сервере. Перечислим некото-
рые причины, когда использование посредника предпочтительнее
(иногда это единственный способ реализации той или иной задачи
безопасности):
• прикладной сервер находится не в локальной сети и его нельзя
контролировать;
40
• отсутствуют функциональные возможности программного
обеспечения прикладного сервера по реализации требуемых огра-
ничений;
• МЭ реализует более гибкое обеспечение безопасности ис-
пользования сервиса.
Подробно прикладные посредники как МЭ прикладного уровня
рассматриваются в гл. 3.
2.8. Модуль создания отчетов
МЭ сохраняет все события в журнале событий. Из-за большо-
го количества событий, происходящих в МЭ, журнал событий очень
быстро заполняется и содержит низкоуровневые данные (время,
протокол, IP-адреса и порты отправителя и назначения, имя пользо-
вателя, действие МЭ и др.), которые сложно анализировать (осо-
бенно если они накоплены на большом промежутке времени или
при интенсивной сетевой нагрузке). Задача модуля создания отче-
тов состоит в обработке этих данных и представлении на их осно-
ве результирующих данных (распределение временной загрузки,
распределение используемых служб, IP-адреса, с которых пред-
принимались попытки несанкционированных подключений, статис-
тика работы пользователей и т. п.).. Если МЭ содержит много при-
кладных посредников, например HTTP, то в журнале событий может
быть представлена информация о наиболее посещаемых узлах, вы-
явлена информация о посещении узлов сомнительного содержания
или развлекательного назначения.
Генераторы отчетов могут поддерживать следующие функци-
ональные возможности:
• экспорт отчета в распространенные форматы файлов - MS
Word, MS Excel, HTML, RTF;
• автоматическая подготовка и отправка по электронной почте
администратору МЭ, в файл, на принтер или приложение сформи-
рованных отчетов по расписанию;
• формирование отчетов в режиме online;
• создание шаблонов, позволяющих получать отчеты различ-
ной направленности;
• преобразование IP-адресов в доменные имена, извлечение до-
полнительной информации из БД Whois регистрационных центров
Интернет (RIPE, RIPN, APNIC и др.);
• подсчет стоимости использования ресурсов на основе объе-
ма трафика (accounting).
41
Отчеты, предоставляемые МЭ, играют огромную роль при про-
ведении периодического анализа безопасности и, в особенности,
анализа произошедших инцидентов. Тем не менее анализ отчетов,
не исключает анализа журналов в ручном режиме администрато-
ром безопасности. Дело в том, что большинство генераторов от-
четов консолидируют большие объемы данных и предоставляют
обобщенную отчетную информацию прежде всего для руководи-
телей организаций и IT-служб. Разбор инцидентов безопасности,
углубленный анализ состояния ИБ требуют работы с журналами
событий непосредственно. В этом случае используются средства
просмотра журналов с возможностью формирования произвольных
запросов.
На рис. 2.3 приведен пример отчета о блокированных МЭ па-
кетах, полученный генератором fwanalog. Отчет позволяет сде-
лать следующие выводы:
• зарегистрировано 69 блокированных пакетов от одного источ-
ника212.17.85.31;
• нарушитель пытался получить доступ к службам FTP, IMAP,
PRINTER, TELNET, SWAT, POSTGRES, LINCONF, POP3,
XWINDOW и службам TCP на портах 6001, 6002. Причем наи-
большее внимание уделялось службам FTP, IMAP, PRINTER,
TELNET, а для остальных, скорее всего, была предпринята попыт-
ка сканирования;
Blocked Packet Report
Listing blocked packets with at least 1 blocked packet, sorted by
the number of blocked packets.
#blocks: %blocks: last time: blocked packet
69: 100%: Apr/ 7/01 06:19: 212.17.85.31
69: 100%: Apr/ 7/01 06:19: 212.17.85.31/TCP
22: 31.88%: Apr/ 7/01 06:19: 212.17.85.31:ftp/TCP
15: 21.74%: Mar/31/01 01:13: 212.17.85.31:imap/TCP
13: 18.84%: Apr/ 7/01 01:05: 212.17.85.31:printer/TCP
5: 7.25%: Mar/31/01 01:14: 212.17.85.31:telnet/TCP
2: 2.90%: Mar/31/01 01:14: 212.17.85.31:swat/TCP
2: 2.90%: Mar/31/01 01:14: 212.17.85.31:6002/TCP
2: 2.90%: Mar/31/01 01:13: 212.17.85.31:postgres/TCP
2: 2.90%: Mar/31/01 01:14: 212.17.85.31:6001/TCP
2: 2.90%: Mar/31/01 01:14: 212.17.85.31:linconf/TCP
2: 2.90%: Mar/31/01 01:14: 212.17.85.31:pop3/TCP
2: 2.90%: Mar/31/01 01:14: 212.17.85.31:xwindow/TCP
Рис. 2.3. Фрагмент отчета «Blocked Packet Report»,
созданного генератором отчетов fwanalog
42
Cserjit tw е»»им1
и c#tK»i e***» t«t ,
OfcUlM £««*,»* «**>'<# tsr C««w s
terrjrj of WNN*
Wwwag» W IhteMl Al*» КИ <
W»W for AljHHW» I'
СЧй,** M Wo» M Невы» ЙК '.
w»?*ier **
Sumawry о» tei^Ktaax^ai ?
Sonwnry w П«якж«
V**ry hrt<w*»j Rwrwfft ЙМ|Й
a VPN Ac w -
M Wl Ь«Ч»
o*h u«»s«
’Л 1Чле« f>y if A44*« i
If AjMmsUsrtUHt
i? мни* u«<s ft*»'** vr*<
a Web usage
U Email Usage
ftp usage
Telnet Usage
S? Firewas Management ;:
Bandwidth Usage Trends
^General Statist
^Bandwidth Usage
«> Security
W-»-*» Л CjShea# £*♦«*
This sect «on prowdes an w«w of feewall actmty I helps you undertlsnd the bandwidth require merits of
your firewall by mdceting the volume d actmty in KBytes Transferred Volume of transfers is calculated both
for transfers to your see and from your site
General Firewall Statistics
В*«ТТ1ж1ыГл^^.......................... 2L Ж1: ITSSXtF’'" “‘"""“1
Total”В Ы event» _____T____________________* *J
ТЫ<ИВЫс»й«са1 event» tOTtopfite ~ ..J'-^---"" ' . ........-
Told » tA «mm end wottwnge ______ ЯБЗ , ...............
fetal id VPN evewts for fag file_\ _____JL__________J
T otal t of byte» to» «нйумпд согемн^ют_ *&???*......... _ ..... |
Рис 2.4. Генератор отчетов сообщений МЭ WebTrends
Firewall Suite
• попытки доступа осуществлялись с 31 марта по 7 апреля.
Для более глубокого анализа действий злоумышленника необ-
ходимо детально проанализировать все события безопасности, за-
регистрированные для этого адреса. При этом может быть полу-
чена следующая информация:
• последовательность действий злоумышленника во времени;
• список сервисов, к которым получил доступ злоумышленник
(на основе анализа разрешенных пакетов, журналов прикладных
посредников и прикладных сервисов);
• предпринятые действия злоумышленника на предоставлен-
ных сервисах (на основе анализа журналов прикладных посредни-
ков и прикладных сервисов), а также аналогичные действия с дру-
гих адресов источника;
• особенности блокированных пакетов - тип сканирования (TCP
Connect, Stealth Scan и др.), атаки отказа в обслуживании;
• события ОС, связанные по времени с анализируемыми собы-
тиями.
43
Процедура создания отчета особенно за большой промежуток
времени может потребовать значительных системных ресурсов,
поэтому в ряде случаев целесообразно анализ событий безопасно-
сти выносить за переделы МЭ.
Как правило, МЭ не предоставляют развитых средств созда-
ния отчетов. Продукты третьих производителей заполняют этот
пробел (см. «Средства мониторинга и создания отчетов МЭ»). Если
в МЭ не предусмотрены средства генерации отчетов и отсутству-
ют генераторы, поддерживающие формат журнала событий МЭ,
то в этом случае можно преобразовать сообщения в формат WELF
и воспользоваться продуктом WebTrends Firewall Suite (рис. 2.4).
3. КЛАССИФИКАЦИЯ
МЕЖСЕТЕВЫХ ЭКРАНОВ
Различные возможности управления сетевым трафиком, реали-
зуемые в межсетевых экранах, разные подходы производителей их
реализации определяют многообразие рынка МЭ. В главе рассмот-
рены схемы классификации МЭ на основе способа реализации, ти-
пов защищаемых объектов и уровней модели взаимодействия от-
крытых систем. Предлагаемая классификация упорядочивает знания
о МЭ, и ее можно использовать при сравнении МЭ, выборе и
предъявлении функциональных требований к МЭ.
3.1. Способ реализации
По способу реализации МЭ бывают программными и аппарат-
но-программными. И те, и другие имеют свои достоинства и недо-
статки. Программные МЭ ориентированы на конкретную платфор-
му (Windows NT Intel, Solaris Sun и др.), что дает следующие
преимущества:
• возможность интеграции с другими программными продукта-
ми;
• простота наращивания мощности аппаратного обеспечения;
• возможность быстрого проведения апгрейдов и «латания дыр»
программного обеспечения МЭ.
К недостаткам программных МЭ можно отнести:
• уязвимость ОС, на которой базируется МЭ, может стать при-
чиной нарушения ИБ;
• администратор МЭ должен хорошо знать как сам экран, так и
ОС, поскольку ошибки администрирования ОС могут привести к
нарушению ИБ.
Программно-аппаратные МЭ выполняются в виде «черного
ящика», конфигурируемого через интерфейсы удаленного управле-
ния на основе собственных приложений либо с использованием
стандартных интерфейсов (Web, SSH и др.). Основными, досто-
45
инствами таких МЭ являются простота эксплуатации и более вы-
сокая производительность и надежность по сравнению с программ-
ными МЭ.
Технология МЭ нашла широкое применение не только непос-
редственно в МЭ, но и при реализации таких технологий, как раз-
деление доступа (dial-up, DSL sharing connection), маршрутизации,
VPN. Продукты, реализующие эти технологии, также попадают
под определение МЭ, но имеют другое основное функциональное
назначение, чем экранирование сетей, и будут рассмотрены ниже.
3.2. Защищаемые объекты
По типам защищаемых объектов различают МЭ: сегментные,
встраиваемые и персональные (рис. 3.1). Сегментные МЭ пред-
назначены для контроля сетевых потоков между двумя и более
сетями, т. е. выполняют защиту сетей. Встраиваемые МЭ уста-
навливаются на прикладных серверах и предназначены для защи-
ты этих серверов. Персональные МЭ защищают рабочие станции
пользователей от внешних сетевых угроз и сетевых троянских про-
грамм.
Сегментные
(межсетевые)
Встраиваемые
Управляемые
коммутаторы
__ Статические фильтры
пакетов
I Динамические
фильтры пакетов
— Инспекторы состояний
__ Посредники
сеансового уровня
__ Прикладные
посредники
— Экспертные
Рис. 3.1. Классификация МЭ по типу защищаемых объектов
46
Сегментные МЭ
Под сегментными понимают МЭ, установленные на границе
двух и более сетей. Сегментные МЭ позволяют контролировать
весь сетевой трафик между сетями, к которым подключен МЭ.
Контроль трафика осуществляется на всех уровнях модели OSI,
начиная с сетевого. Для лучшего понимания принципа действия
сегментный МЭ можно представить как сетевой маршрутизатор,
который не только осуществляет маршрутизацию пакетов между
сетями, но и выполняет анализ пакетов и информационных потоков
на соответствие требованиям ПБ. Пакеты и информационные по-
токи, не удовлетворяющие этим требованиям, блокируются.
Именно сегментные МЭ являются одним из основных средств
обеспечения ИБ и наиболее полно рассматриваются в этой книге.
Персональные МЭ
Персональные МЭ предназначены для защиты рабочих стан-
ций пользователей как отдельно подключенных к сети Интернет,
так и функционирующих в составе локальных сетей. В последнем
случае персональные МЭ создают дополнительный уровень защи-
ты, в том числе и от внутренних угроз, и не исключают использо-
вания сетевых МЭ на границе локальной сети. Среди персональ-
ных МЭ выделяют пакетные фильтры, мониторы приложений и
гибридные МЭ.
Пакетные фильтры отслеживают только сетевые пакеты на
сетевом и транспортном уровне и не могут отслеживать соответ-
ствие пакетов и сетевых приложений. Пакетные фильтры требуют
высокой квалификации пользователей.
Мониторы приложений отслеживают активность сетевых при-
ложений. Такой подход не требует высокой квалификации пользо-
вателей и обеспечивает повышенный уровень защиты (по сравне-
нию с пакетными фильтрами). Мониторы приложений могут иметь
в своем составе прикладных посредников.
Гибридные персональные МЭ под держивают функциональность
и пакетных фильтров, и мониторов приложений, что позволяет реа-
лизовывать политику безопасности как на уровне сетевых прило-
жений, так и на пакетном уровне.
Встраиваемые МЭ
Иногда возникает необходимость в усилении защиты приклад-
ных сервисов, реализуемых одним или несколькими серверами. При
этом использование сетевых МЭ может быть не оправдано по при-
47
чине их высокой стоимости или условий эксплуатации (например,
выделенный сервер на территории провайдера). В этом случае
можно использовать встраиваемые МЭ, которые функционируют
на одной платформе с защищаемыми серверами, обеспечивая их
защиту. Низкая стоимость встраиваемых МЭ позволяет устано-
вить их на каждый защищаемый сервер.
Встраиваемые МЭ обеспечивают защиту по принципу персо-
нальных фильтрующих МЭ и предоставляют более широкие воз-
можности управления (удаленное управление, резервное копирова-
ние, временные ограничения ПБ и др.) и анализа событий. Но в
отличие от персональных, они не обеспечивают интерактивности
взаимодействия с администратором прикладного сервера.
3.3. Уровни модели OSI
Основным признаком при классификации МЭ является уровень
эталонной модели взаимодействия открытых систем, на котором
функционирует конкретный тип МЭ. Такая классификация носит
достаточно условный характер, поскольку современные МЭ функ-
ционируют сразу на нескольких уровнях. Тем не менее она помога-
ет понять основные принципы действия МЭ. Выделяют следую-
щие типы МЭ (рис. 3.2):
• управляемые коммутаторы;
• фильтры пакетов;
• динамические фильтры пакетов;
• инспекторы состояний;
• посредники сеансового уровня;
• посредники прикладного уровня;
• МЭ экспертного уровня.
Управляемые коммутаторы
Современные локальные сети строятся на основе коммутато-
ров Ethernet. В отличие от концентраторов, коммутаторы позво-
ляют строить высокопроизводительные сети за счет установки
высокоскоростного соединения между двумя точками взаимодей-
ствия.
Управляемые коммутаторы попадают под определение МЭ, но
действуют они на самом нижнем уровне модели взаимодействия
(канальном), что не позволяет управлять на уровне протокола IP.
Тем не менее появление коммутаторов 3-го уровня, стандартизация
протоколов коммутации, расширение возможностей коммутаторов
2-го уровня позволяют использовать возможности коммутаторов в
48
Уровни модели OSI
Рис 3.2. Классификация сегментных МЭ
целях повышения безопасности локальных сетей и на более высо-
ких уровнях - на сетевом и транспортном. Технология виртуаль-
ных локальных сетей VLAN (Virtual Local Area Network) позволя-
ет создавать группы узлов сети, трафик которых полностью
изолирован от других узлов сети. Применение VLAN помогает
решать две задачи. Во-первых, это повышение производительнос-
ти сети, и во-вторых, как уже говорилось, обеспечение безопасно-
сти за счет физического разделения трафика между сегментами
сети.
Выделяют следующие способы построения виртуальных ло-
кальных сетей на базе коммутаторов [61]:
• использование номеров подсетей сетевого уровня;
• группировка портов;
• группировка МАС-адресов;
• группировка протоколов сетевого уровня;
• добавление к кадрам канального уровня меток виртуальных
сетей.
Второй и третий способы являются универсальными, их под-
держивают большинство моделей коммутаторов Cisco, ЗСош, Вау
Networks, Cabletron. При группировке портов узлы сети объединя-
ются в виртуальные группы по портам коммутатора. Каждой из
создаваемых сетей VLAN назначаются определенные порты ком-
мутатора (рис. 3.3). При построении сети способом группировки
МАС-адресов параметром разграничения выступает МАС-адрес
сетевого адаптера компьютера (IP-узла), который является уни-
кальным. Зная МАС-адреса всех компьютеров, можно создать
группы и определить правила прохождения трафика между ними.
Последние модели современных коммутаторов позволяют филь-
тровать пакеты не только на основе МАС-адресов и портов ком-
мутатора. Так, например, коммутаторы Bay Networks управляют
прохождением (разрешить, блокировать, перенаправить) Ethemet-
пакетов на основе анализа по 12-байтной маске 255 байт данных
пакета. Поскольку длина заголовка протокола IP равна 24 байт, а
протокола TCP - 20 байт, то коммутатор может контролировать
пакеты на сетевом, транспортном и даже прикладном уровнях. На
рис. 3.4 показан пример фильтра, запрещающего прохождение IP-
трафика для Ethemet-пакетов Ethemet_II и SNAP. Рисунок иллюс-
трирует необходимость учета формата кадра Ethernet (см. Прил.
П. 1) при создании правил фильтрации.
50
VLAN2
Рис. 3.3. Построение сети VLAN на основе группировки
портов коммутатора
В последнее время производители коммутаторов наряду с по-
вышением производительности все больше внимания уделяют и
вопросам безопасности. Так, магистральные коммутаторы компа-
нии Cisco серии Catalyst 6000 имеют следующие возможности -
аутентификация TACACS+ и RADIUS, поддержка списков досту-
па на основе IP-адреса, поддержка системы Syslog, рефлексивные
и динамические ACL, маршрутизация на основе политики безопас-
ности, сетевая трансляция адресов, SPAN, VLAN.
Р 10.0 0 1 - Configuration
ИЕ1В
' ---7" ;
FLTR_CMJ1 1 LLC 0 AAAA03.00 00.00 08 00 EQ 0 255 DROP
2 MAC 12 08.00 EQ 0 255 DROP | |
Add Fillet | AddSeq [ Delete Seq |
Рис. 3.4. Фильтр коммутатора Bay Network, запрещающий IP-трафик
51
bjj Gwrtch 1100 : Unit 1 • Microsoft Internet Explore» HB
j, 3^-®^ ' J^pacna _ £ ' - -
[Jjh Ш tfl .Si ‘ < **! J toee |Й wznatm[-
SuperStack * II
Switch 1100
om
3€ocn Corrti
-.- «ияшф
i&EMB stack
Sflllin.92
VLANs | Switch Database | Software Upgrade | Roving Analysis Port |
Resilient Links | Reset | Port Trunks | Initialize I Advanced.Staok^W.
йшйшоШш
VLANs
Available:
VLAN ’
Operation
Available Ports
Add to VLAN
|7mlan2* *
Edit.. I Delete I Create..
Mb
VLAN Members
mssBsraa
< Unit 1 Port 4
<, ЧГ/ unit 1 Port 5
С Unit 1 Porte
Unit 1 Port 7
Unit l Port 8
unit 1 Port 9
Unit 1 Port 10-J
Unit 1 Port 11
unit 1 Port 12 jj
Remove from VLAN
(802.10 tagged ports only)
«Remove I
Unit 1 Port 2, 802. IQ
®T
Рис. 3.5. Конфигурация VLAN через Web-интерфейс коммутатора
3Com Switch 1100
При реализации политики безопасности в корпоративной сети
управляемые коммутаторы могут быть мощным и достаточно
дешевым решением проблемы безопасности. Особенно полезны
управляемые коммутаторы для разграничения доступа внутри орга-
низации с жесткой и статичной ПБ. К тому же, в большинстве ком-
паний коммутаторы составляют основу сети, и не стоит забывать
о дополнительных их возможностях.
К основным недостаткам использования управляемых комму-
таторов, таких как МЭ, можно отнести:
• отсутствие или ограничение возможностей фильтрации тра-
фика на сетевом и более высоких уровнях модели OSI;
• отсутствие механизмов аутентификации;
• сложность управления и определения правил фильтрации.
В ряде случаев сегментация с использованием технологии
VLAN, поддерживаемой управляемыми коммутаторами, являет-
ся достаточным решением при организации разграничения досту-
па внутри локальной сети.
52
Статические фильтры пакетов
Фильтры пакетов - первое поколение технологии МЭ - анали-
зируют сетевой трафик на сетевом и транспортных уровнях. Каж-
дый IP-пакет проверяется на соответствие набору правил, опреде-
ляющих разрешенные потоки данных. Фильтры пакетов или
пакетные фильтры (ПФ) обычно позволяют контролировать сле-
дующие поля сетевых пакетов:
• физический сетевой интерфейс, с которого получен пакет
(МАС-адрес);
• IP-адрес источника;
• IP-адрес получателя;
• тип транспортного протокола (TCP, UDP, ICMP);
• поля служебных заголовков протоколов IP, TCP;
• порт источника транспортного уровня (TCP/UDP порт);
• порт назначения транспортного уровня (TCP/UDP порт).
Фильтры пакетов не понимают прикладной уровень модели OSI.
Они работают, применяя набор правил, установленных в ядре
TCP/IP стека МЭ. Этот набор правил содержит ассоциативные
действия, которые будут применены ко всем входящим и исходя-
щим пакетам.
Действие над поступающим на сетевой интерфейс или исходя-
щим из него пакетом имеет одно из двух значений: запретить (deny)
или разрешить (allow). Запрещение прохождения пакета выполня-
ется одним из следующих способов:
1) пакет отбрасывается (drop) без каких либо дополнительных
действий;
2) пакет отбрасывается (reject) и отправителю посылается па-
кет с установленным флагом «сброс соединения». Правило reject
используется только для ТСР-пакетов;
3) пакет отбрасывается и отправителю посылается сообщения
ICMP - хост недостижим или порт недоступен.
Последние два способа запрещения пакетов позволяют создать
видимость отсутствия средств защиты (фильтрации) на пути про-
хождения сетевых пакетов.
Два списка - запрещенный список и список доступа - обраба-
тываются в ядре МЭ. Сетевой пакет, проходящий через МЭ, дол-
жен пройти оба списка доступа. В большинстве МЭ применяется
правило: что явно не разрешено, то запрещено. Некоторые фильт-
ры пакетов, включенные в состав маршрутизаторов, используют
другую политику. В таких фильтрах пакетов пакет должен быть
явно запрещен или иначе он будет разрешен. По этой причине
53
необходимо ясно понимать политику фильтрации, используемой в
активном оборудовании и МЭ. При задании правил фильтра паке-
тов используют и другие более сложные подходы, реализующие
многоуровневую иерархическую структуру.
Фильтры пакетов обычно оперируют набором команд, контро-
лирующих IP-адреса, номера портов источника и назначения TCP
и UDP. Поскольку протокол ICMP не использует портов, это зат-
рудняет реализацию политики безопасности для него. Для обеспе-
чения эффективной политики безопасности для ICMP фильтр паке-
тов должен установить таблицу состояний, чтобы обеспечить
работу протокола (транслировать ICMP-отклик) для внутренних
хостов. Эта способность «контроля состояния» является одной из
основных различий между простым фильтром пакетов и динами-
ческим фильтром пакетов.
Основные достоинства МЭ на базе фильтров пакетов заключа-
ются прежде всего в простоте реализации и широкой доступности
как в программном исполнении, так и аппаратном (в составе мар-
шрутизаторов). Кроме того:
• фильтры пакетов обычно быстрее (более производительны)
других типов МЭ, поскольку выполняют меньшее количество опе-
раций в процессе анализа;
• пакетные фильтры не требуют специального конфигурирова-
ния клиентских компьютеров;
• в сочетании с сетевой трансляцией адресов использование
МЭ фильтрации пакетов позволяет скрыть внутренние адреса сети
от внешних пользователей.
Фильтр пакетов не контролирует данные сетевого пакета на
прикладном уровне и состояние соединения, поэтому он обеспечи-
вает наименьшую защищенность, что позволяет получить доступ
через МЭ с минимальным числом дополнительных исследований.
Другими словами, если доступ разрешен, сетевой пакет будет мар-
шрутизирован через МЭ как определенный правилами в таблице
маршрутизации МЭ. Поскольку такой МЭ требует минимальных
вычислительных затрат и обеспечивает самую высокую произво-
дительность, его часто используют в таких аппаратных решениях,
как 1Р-маршрутизаторы.
Фильтр пакетов часто реализуют модификацию IP-адреса
сетевых пакетов. Процесс переадресации сетевых пакетов называется
сетевой трансляцией адресов (network address translation-NAT).
Сетевая трансляция адресов скрывает топологию и адреса защи-
щенной сети от внешней сети и позволяет работать в ограниченном
зарегистрированном адресном блоке.
54
МЭ, основанные на статической фильтрации пакетов, имеют
следующие недостатки:
• фильтры пакетов не интерпретируют прикладной уровень мо-
дели OSI, не отслеживают текущие сессии. Поэтому они обеспе-
чивают меньшую защищенность, чем МЭ прикладного уровня или
уровня соединения;
• фильтры пакетов имеют ограниченные системы аудита и пре-
дупреждений или вообще не имеют их;
• из-за сложности реализации большинства прикладных серви-
сов возникают сложности определения разрешенных и запрещен-
ных списков правил, что, в свою очередь, усложняет их админист-
рирование.
Фильтры пакетов являются неотъемлемой частью МЭ эксперт-
ного уровня.
МЭ прикладного уровня
МЭ прикладного уровня (application-level proxy, application proxy,
посредник) - технология МЭ, которая проверяет информационные
потоки на корректность данных на прикладном уровне. Дополни-
тельно на этом уровне МЭ прикладного уровня могут контролиро-
вать различные характеристики защищенности, присущие только
прикладному уровню, такие как пароль пользователя и запрашива-
емые объекты протоколов. Обратите внимание, посредники опе-
рируют не пакетами, а информационными массивами в виде ко-
манд и их параметров, результатами выполнения команд,
различными высокоуровневыми объектами - файлами, элемента-
ми баз данных, компонентами Java, Java script и др.
Большинство МЭ прикладного уровня включают специальное
программное обеспечение и сервис-посредники (proxy services).
Сервис-посредники - программы специального назначения, кото-
рые управляют трафиком через МЭ для определенных сервисов,
таких как HTTP, FTP, SMTP, POP3, Telnet, DNS, RealAudio, SQLnet
и др. Как правило, каждый сервис-посредник, называемый также
прокси-приложением, состоит из двух отдельных компонент - про-
кси-клиента и прокси-сервера. Чаще всего сетевые приложения
напрямую взаимодействуют с прокси-серверами, что не требует
дополнительного программного обеспечения на клиентских рабо-
чих местах. Прокси-сервер выступает конечным сервером для всех
запросов от клиентов защищаемой сети.
Различают прозрачные (transparent proxy) и непрозрачные (not
transparent) посредники прикладного уровня. Прозрачные посред-
ники работают незаметно для соответствующих клиентских при-
55
ложений и не требуют их конфигурации. Это достигается за счет
перехвата всех сетевых пакетов сервером-посредником, соответ-
ствующим прикладному приложению (на основе TCP или UDP-nop-
тов назначения). Непрозрачные посредники требуют специальной
конфигурации клиентских приложений, которая заключается в ука-
зании приложению адреса, порта посредника, параметров аутенти-
фикации и при необходимости других дополнительных параметров.
МЭ прикладного уровня позволяют блокировать потенциально
опасные компоненты и команды прикладного протокола. Так, на-
пример, они позволяют блокировать компоненты ActiveX, Java, Java
script, банеры протокола HTTP, запрещать/разрешать команды про-
токолов FTP и HTTP, блокировать несуществующие команды. Кро-
ме того, МЭ прикладного уровня умеют кэшировать информацию
и управлять характеристиками кэша, за счет чего уменьшают вре-
мя загрузки данных и расходы за трафик.
Основными преимуществами сервис-посредников являются:
• интерпретация и усиление защиты высокоуровневых приклад-
ных протоколов, таких как HTTP и FTP;
• блокирование напрямую установленных соединений между
внешними серверами и внутренними хостами;
• перенаправление внешних запросов на другие серверы внут-
ренних сервисов;
• широкий набор учетных данных для отчетности по сравне-
нию с другими типами МЭ (идентификатор пользователя, время и
продолжительность соединения для каждой пары адресов, имена и
характеристики запрашиваемых объектов, статистика посещения
узлов и запрашиваемых объектов, распределение затраченного
сетевого времени между приложениями и пользователями и ряд
других);
• обеспечение дополнительных возможностей (кэширование
объектов HTTP, фильтрация URL, аутентификация пользователей,
балансировка нагрузки и др.).
Недостатки сервис-посредников:
• поскольку они прослушивают тот же порт, что и сам приклад-
ной сервер, то не всегда есть возможность расположения сервера
и МЭ на одном и том же компьютере;
• значительное время обработки, поскольку входящие данные
обрабатываются дважды - приложением и его посредником;
• для каждого прикладного протокола, пропускаемого через МЭ,
должен быть разработан собственный сервис-посредник.
Сервис-посредники обеспечивают самый высокий уровень защи-
ты из всех типов МЭ, но имеют самую низкую производительность.
56
МЭ динамической фильтрации пакетов
МЭ динамической фильтрации пакетов (МЭ ДФ) позволяют
модифицировать (корректировать) базу правил «на лету». Эта тех-
нология изначально разрабатывалась для поддержки транспортно-
го протокола UDP. Транспортный протокол UDP обычно использу-
ется при небольших информационных запросах и ответах на
прикладном уровне.
МЭ ДФ ассоциирует все UDP-пакеты с неким виртуальным
соединением (напомним, что протокол UDP не определяет поня-
тие соединения). Если МЭ обнаруживает ответный пакет, то уста-
навливается виртуальное соединение, и пакету разрешается про-
ходить через МЭ. Информация, ассоциированная с виртуальным
соединением, обычно запоминается на короткий промежуток вре-
мени, и если в этот промежуток времени не получен (обнаружен)
ответный пакет, то виртуальное соединение разрывается (ликви-
дируется).
МЭ ДФ имеют такие же преимущества и недостатки, как и
первое поколение МЭ - МЭ ФП с одним исключением: дополни-
тельно они не пропускают незапрашиваемые (согласно оценок вир-
туального соединения) UDP-пакеты. МЭ пропускает первый па-
кет UDP во внутреннюю сеть. Ответный пакет должен содержать
соответствующий адрес назначения и номер порта.
МЭ ДФ можно использовать для поддержки ограниченного под-
множества команд протокола ICMP. ICMP-протокол часто приме-
няют для проверки сетевого соединения между двумя хостами
путем обмена парой пакетов (ping). В этом случае МЭ может ре-
шать различные задачи «видимости» внешних и внутренних хос-
тов по некоторым правилам, что особо важно, поскольку протокол
ICMP используется при реализации некоторых широко распрост-
раненных атак.
Динамические фильтры, как МЭ, в настоящее время не исполь-
зуют. Принципы, заложенные в ДФ, реализованы и значительно
расширены в инспекторах состояний. По сравнению с инспектора-
ми соединений в МЭ ДФ была предпринята попытка управлять
взаимодействием хостов по протоколу UDP. Но, как будет показа-
но ниже, инспекторы состояний при управлении UDP-трафиком ин-
спектируют данные прикладного уровня, а МЭ ДФ использовали
только адреса, транспортные порты и временные системы.
57
Посредники сеансового уровня
Посредники сеансового уровня работают на сеансовом уровне
модели OSI (напомним, что этот уровень в стандартном стеке про-
токолов Интернет отсутствует). Они позволяют аутентифицировать
клиентов, передавать данные по защищенному каналу и иметь ряд
дополнительных возможностей, отсутствующих в ПФ.
Наиболее известным примером посредника сеансового уровня
является посредник SOCKS5. При запросе соединения с некото-
рым узлом Интернет, SOCKS5 проводит аутентификацию клиента
и проверяет его права на доступ к запрашиваемому узлу по запра-
шиваемому прикладному протоколу (на основании номера порта
TCP/UDP). При успешной аутентификации пользователя SOCKS5
устанавливает соединение с запрашиваемым узлом, что обеспе-
чивает единую точку входа в сеть с обеих сторон сервера SOCKS5.
SOCKS5 позволяет передавать данные как в открытом виде, так и
по защищенному протоколу, например SSL.
Недостатком использования посредника SOCKS5 является не-
обходимость установки на каждое рабочее место клиентской час-
ти SOCKS5, если, конечно, прикладные приложения сами не под-
держивают работу через SOCKS5. Кроме того, нужно отметить,
что поскольку клиентская часть SOCKS5 работает на основе пе-
рехвата вызовов сетевого API ОС, то по ряду причин не все прило-
жения будут поддерживать работу через SOCKS5.
Одно из основных преимуществ SOCKS5 состоит в том, что он
позволяет полноценно управлять доступом к различным ресурсам
(адрес:порт) закрытой и общедоступной сетей на основе строгой
аутентификации и при этом поддерживает транспортные протоко-
лы TCP и UDP.
Шлюзы сеансового уровня (инспекторы состояния)
Шлюзы сеансового уровня (stateful inspection firewall) осуще-
ствляют фильтрацию сетевых пакетов с учетом информации о те-
кущей фазе соединения. Инспектор состояний гарантирует, что ни
один сетевой пакет не будет пропущен, если он не принадлежит
ранее установленному соединению. Шлюзы сеансового уровня
более известны как инспекторы состояния. Подобно фильтрам
пакетов, шлюзы сеансового уровня используют набор правил, ко-
торые установлены в ядре TCP/IP МЭ.
Для подтверждения TCP-сессии МЭ исследует каждый про-
цесс установки соединения, следующий за законным рукопожати-
ем. Кроме того, пакеты данных не отправляются, пока процесс
58
рукопожатия не будет закончен. МЭ поддерживает таблицу состо-
явшихся соединений (в которой содержится полная информация о
состоянии сессий: номера последовательностей TCP/UDP, IP-ад-
реса, портов) и позволяет сетевым пакетам проходить тогда, когда
информация о пакете соответствует фазе соединения. Как только
соединение закрывается, записи о нем удаляются из таблицы, и
виртуальное соединение между двумя транспортными уровнями
закрывается.
При установлении соединения шлюз сеансового уровня может
сохранять следующую информацию о соединении:
• уникальный идентификатор сессии для соединения, который
используется для управляющих целей;
• состояние (фаза) соединения: рукопожатие, установлено, зак-
рыто;
• текущие значения номеров последовательностей пакетов;
• IP-адрес источника;
• IP-адрес назначения;
• тип транспортного протокола (TCP, UDP, ICMP);
• порт источника транспортного уровня (TCP/UDP порт);
• порт назначения транспортного уровня (TCP/UDP порт);
• некоторые поля служебных заголовков пакетов;
• физический сетевой интерфейс, с которого ожидается поступ-
ление очередного сетевого пакета;
• время жизни (тайм-аут) виртуального соединения в случае
отсутствия активности.
Используя эти данные, МЭ контролирует информацию заголов-
ков каждого сетевого пакета и определяет, когда передающий хост
имеет право передачи данных принимающему хосту и когда прини-
мающий хост имеет право получать данные. Дополнительно МЭ
могут выполнять проверку того, что сетевой пакет не был подме-
нен и данные, содержащиеся в заголовке пакета транспортного
уровня, соответствуют определению этого протокола, что позволя-
ет МЭ обнаружить некоторые изменения пакета данных.
Шлюзы сеансового уровня имеют ограниченное понимание про-
токолов, используемых в сетевых пакетах. Полная инспекция со-
стояния возможна только для транспортного протокола TCP. Для
протоколов UDP и ICMP инспекция состояния виртуального со-
единения реализуются искусственно, с использованием данных
прикладного уровня. Например, при инспекции ICMP подразуме-
вается, что для каждого пакета ECHO_REQUEST должен после-
довать соответствующий пакет ECHO_REPLAY. При этом ответ
не может последовать, если не был отправлен запрос.
59
Инспекторы разрешают доступ с минимальным количеством
исследований путем построения ограниченной формы состояний
соединения. Только пакетам, ассоциированным с существующим
соединением (в таблице состояний), разрешено прохождение че-
рез МЭ. Этот метод очень быстр и обеспечивает ограниченное
число проверок состояний.
Шлюзы сеансового уровня могут использовать технологию се-
тевой трансляции адресов. В этом случае в таблице состояний так-
же хранится информация о транслированных адресах.
Большинство современных МЭ поддерживают технологию ин-
спекции состояния соединения. Отличие состоит лишь в том, на-
сколько «точно» МЭ могут контролировать виртуальные соедине-
ния для протоколов TCP, UDP и ICMP.
В общем случае МЭ на основе шлюзов сеансового уровня име-
ют следующие преимущества:
• шлюзы сеансового уровня обычно быстрее, чем МЭ приклад-
ного уровня, поскольку выполняют меньшее количество операций;
• шлюз сеансового уровня контролирует сессию в целом, что
обеспечивает большую защищенность по сравнению с фильтрами
пакетов;
• практически исключена подделка трафика и отдельных паке-
тов TCP.
Недостатками МЭ на основе шлюзов сеансового уровня явля-
ются:
• полнофункциональная инспекция возможна только для TCP;
• не обеспечена проверка вышестоящих протоколов;
• ограниченные возможности аудита событий, но по сравнению
с ПФ они могут связывать сетевой пакет с протоколом прикладно-
го уровня путем построения ограниченных форм состояний сес-
сии;
• из-за непонимания протоколов прикладного уровня не имеют
дополнительных возможностей, таких как кэширование объектов
HTTP или фильтрация URL;
• из-за сложности реализации большинства прикладных серви-
сов возникают сложности определения разрешенных и запрещен-
ных списков доступа (правил).
Одним из основных достоинств инспекторов состояния явля-
ются гибкость создания правил ПБ (по сравнению с пакетными
фильтрами), а также способность защиты от большинства DDos-
атак, использующих различные виды флудинга и некорректности
сетевых пакетов.
60
МЭ экспертного уровня
МЭ экспертного уровня реализуют все вышеперечисленные тех-
нологии МЭ, за исключением фильтрации МАС-адресов, использу-
емых в некоторых типах управляемых коммутаторов. Практичес-
ки все коммерческие МЭ относят именно к этому классу.
Алгоритмы работы МЭ экспертного уровня имеют сложный
многоуровневый характер и отличаются у различных фирм-произ-
водителей МЭ, однако можно выделить следующие черты, прису-
щие всем МЭ экспертного уровня:
• имеют набор прикладных посредников;
• должны поддерживать технологию инспекции состояния этих
каналов связи;
• для увеличения защищенности самой ОС, а также из-за слож-
ности алгоритмов обработки заменяют сетевой стек ОС на соб-
ственный. Кроме того, осуществляют действия по настройке име-
ющихся механизмов защиты ОС, например, настройке прав доступа
к объектам ОС, включению механизмов аудита и др.;
• имеют встроенные механизмы обнаружения и защиты от ти-
повых сетевых атак типа «отказа в обслуживании»;
• предоставляют возможности централизованного управления
и интеграции с системами управления сетями;
• обеспечивают режимы повышенной надежности (НА - High
Availability) за счет объединения однотипных продуктов в отказо-
устойчивый кластер;
• поддерживают усиленные схемы аутентификации;
• имеют развитую систему аудита и уведомления о событиях
безопасности;
• поддерживают технологию VPN.
61
4. СХЕМЫ ПОДКЛЮЧЕНИЯ
МЕЖСЕТЕВЫХ ЭКРАНОВ
Несмотря на то, что основной схемой подключения МЭ являет-
ся схема с использованием двух и более сетевых интерфейсов, при-
меняют и другие схемы, не потерявшие своей актуальности с разви-
тием технологий защиты. В главе рассмотрены все возможные
варианты использования МЭ.
4.1. Dual-homed
В терминологии TCP/IP термин multihomed host используют
для указания того, что хост содержит несколько сетевых адапте-
ров (интерфейсов). Применительно к МЭ, термин dual-homed оз-
начает, что МЭ имеет два сетевых адаптера, подключенных к двум
различным сетям (рис. 4.1). Это наиболее распространенная схе-
ма подключения МЭ. Большинство МЭ рассчитаны именно на эту
схему подключения. МЭ осуществляет физическое и логическое
разделение двух сетей, принимая решение о возможности установ-
ления соединения (передачи пакетов) между ними. Все перечис-
ленные выше МЭ можно использовать по приведенной схеме (см.
рис. 4.1).
Как правило, со стороны внешней сети МЭ подключен к марш-
рутизатору (чаще всего к маршрутизатору провайдера). Маршру-
тизатор является первой «линией обороны» защиты сети. Некор-
62
ректно настроенный внешний (пограничный) маршрутизатор мо-
жет стать причиной нарушения ИБ сети. Внешний маршрутизатор
должен пропускать только пакеты, принадлежащие адресному IP-
пространству МЭ или внутренней сети. Если маршрутизатор под-
держивает функции фильтра пакетов, то для повышения произво-
дительности МЭ на маршрутизаторе могут быть заданы первичные
правила фильтрации входящего трафика. Например, иногда целе-
сообразно с. помощью маршрутизатора блокировать (IP-пакеты с
подделанным адресом отправителя IP-spoofing), блокировать не-
используемые порты.
Внутренний маршрутизатор используется в больших корпора-
тивных сетях или для усиления ПБ. Чаще всего после МЭ распо-
лагают сетевой коммутатор или концентратор Ethernet.
Демилитаризованная зона
В некоторых МЭ допускается использование нескольких сете-
вых адаптеров с установлением различных ПБ между подключае-
мым к ним сетям. В большинстве случаев существует возмож-
ность образования так называемой демилитаризованной зоны
(DMZ - demilitarized zone) (рис. 4.2,4.3). Как правило, в DMZ раз-
мещают службы, которые должны быть доступны и клиентам сети
Интернет, и клиентам защищенной сети. Поскольку доступ к сер-
висам DMZ должен осуществляться из открытой сети, то в деми-
литаризованной зоне определяются менее жесткие требования к
сетевой безопасности, но достаточные для организации защиты от
внешних угроз. Демилитаризованная зона может быть образована
и путем подключения серверов перед МЭ. В этом случае описать
правила безопасности для МЭ более сложно.
Если в сети используются группы пользователей с четким раз-
граничением доступных сервисов или различными уровнями кон-
фиденциальности обрабатываемой информации, то МЭ может кон-
тролировать сетевые потоки не только во внешние сети, но и между
внутренними сегментами сети. Такая возможность достигается
за счет использования дополнительных интерфейсов и установки
соответствующих правил.
Выделение DMZ, а также поддержка нескольких сетевых ин-
терфейсов межсетевым экраном позволяют вести централизован-
ное управление защитой сетевых ресурсов с различными приняты-
ми политиками безопасности.
Рассмотрим пример. Пусть имеется корпоративный Web-cep-
вер, осуществляющий публикацию данных компании в Интернет.
Данные извлекаются Web-сервером из внутреннего сервера БД.
Доступ к серверу БД разрешен только во внутренней сети. Для
63
МЭ
Рис. 4.2. Демилитаризованная зона перед МЭ
Рис. 4.3. Использование МЭ с демилитаризованной зоной
обеспечения работы интерфейса Web-системы управления базой
данных (СУБД) необходимо разрешить доступ от Web-сервера к
внутреннему серверу СУБД. Тогда при нарушении защиты Web-сер-
вера, можно получить доступ во внутреннюю сеть (как минимум,
к серверу БД, рис. 4.4,4.5). Выделение зоны DMZ не только реша-
ет проблемы сервера БД защиты от внешних угроз, но и значи-
тельно уменьшает возможность проникновения в локальную сеть
в случае уязвимости Web-сервера.
64
Сервер Web
Рис. 4.4. Размещение Web-сервера перед МЭ без выделения DMZ:
1 - пользователь Интернет; 2 - запросы от Web-сервера к серверу БД;
3 - пользователи защищаемой сети
Рис. 4.5. Размещение Web-сервера в DMZ:
1 - пользователь Интернет; 2 - запросы от Web-сервера к серверу БД;
3 - пользователи защищаемой сети
Разрешение маршрутизации между
сетевыми интерфейсами
В большинстве случаев между сетевыми интерфейсами раз-
решена маршрутизация пакетов на уровне ОС. Механизмы стати-
ческой и динамической пакетной фильтрации МЭ управляют про-
хождением этих пакетов. Включение режима маршрутизации
является необходимым требованием функционирования большин-
ства реализаций МЭ.
3 Лебедь С.В.
65
В процессе загрузки/перезагрузки ОС существует временной
интервал, во время которого сетевой стек с включенным режимом
маршрутизации загружен, но сервис (демон) МЭ еще не активен.
В течение этого относительно короткого промежутка времени воз-
можно прохождение пакетов между интерфейсами и, как следствие,
возможна реализация сетевых атак. Этот процесс можно отсле-
дить следующим образом:
• в редакторе ПБ запретить ping интерфейсов МЭ;
• запустить с любого хоста программу ping < 1 Р_адре с_интерфей -
са_мэ> и убедиться в корректности реализации соответствующего
правила МЭ;
• перезагрузить МЭ.
Наличие ICMP-ответов (Internet Control Message Protocol) от
исследуемого интерфейса МЭ в процессе перезагрузки ОС будет
свидетельствовать об описываемом процессе. Этим же способом,
уменьшая интервалы между ICMP-запросами, можно оценить ин-
тервал времени, в течение которого пакеты маршрутизируются,
но МЭ еще не активен.
Запрещение маршрутизации между
сетевыми интерфейсами
При использовании МЭ только прикладных посредников необ-
ходимость в маршрутизации пакетов отсутствует. В этом случае
прикладные посредники устанавливают посредничество между
клиентом и сервером без поддержки маршрутизации пакетов со
стороны ОС. При этом маршрутизацию между сетевыми интер-
фейсами можно запретить. Какие же преимущества дает такая
схема? Поскольку пакеты могут передаваться между интерфей-
сами только средствами прикладных посредников, то значительно
повышается уровень защищенности, реализуемый МЭ. Теперь
любой пакет, поступивший на сетевой интерфейс и не переданный
на обработку посреднику, будет отброшен. В защищаемой сети
может использоваться любое адресное пространство, в том числе
и из класса приватных адресов. Механизм защиты трансляции ад-
ресов в этом случае реализуется посредниками.
Эту схему часто применяют в небольших организациях, где
используют только протоколы HTTP и FTP на базе свободно рас-
пространяемого посредника SQUID. Разрешение имен выполня-
ется посредником, поэтому необходимость в поддержке трафика
DNS отсутствует.
Использование только прикладных посредников не означает
отказ от пакетной фильтрации. Пакетные фильтры должны запре-
щать все пакеты, не предназначенные для получения посредника-
ми, поскольку в противном случае возможны различные атаки, на-
правленные на сетевой стек ОС МЭ.
66
МЭ в локальной вычислительной сети
МЭ можно использовать для сегментирования локальной сети
с целью повышения ее уровня ИБ и защиты отдельных сетевых
сегментов. Сегментирование сети используют, например, в следу-
ющих случаях:
• в локальной сети присутствуют функциональные группы, об-
рабатывающие информацию с различным уровнем доступа;
• необходимо осуществлять управляемый доступом к приклад-
ным и служебным сервисам;
• необходимо контролировать обмен информационными пото-
ками между различными функциональными группами.
Наиболее просто сегментирование локальных сетей выполня-
ется путем «нарезки» VLAN-сегментов на коммутаторах Ethernet.
Однако при решении различных задач ИБ такой подход не всегда
приемлем, ввиду ограниченности функциональных возможностей
коммутаторов Ethernet.
На рис. 4.6 показан пример использования МЭ для сегментиро-
вания локальной сети. Локальная сеть разбита на пять сегментов.
Нулевой сегмент образован на интерфейсе МЭ ethO (сеть 10.0.0.0/24)
и включает один хост - рабочую станцию администратора безо-
пасности, предназначенную для обеспечения безопасного управ-
ления МЭ. Первый, второй и третий сегменты образованы на ин-
терфейсах ethl (сеть 10.0.1.0/24), eth2 (сеть 10.0.2.0/24) и eth3 (сеть
10.0.3.0/24) соответственно. Эти сегменты предназначены для раз-
деления информационных потоков функциональных групп с различ-
ными требуемыми уровнями ИБ. Четвертый сегмент образован,
на интерфейсе eth4 (сеть 10.0.4.0/24) и предназначен для защиты
прикладных серверов. <
Подобная сегментация, в частности, позволяет решать следу:
ющие задачи обеспечения безопасности функционирования локаль-
ной сети:
1) безопасность управления МЭ обеспечивается жесткостью
ПБ, запрещающей подключение к механизмам управления МЭ, за
исключением выделенной рабочей станции администратора безо-
пасности, подключенной к одному из интерфейсов МЭ. С рабочего
места администратора МЭ запрещается подключение к другим хо-
стам. Такой подход позволяет использовать и незащищенные от
прослушивания протоколы удаленного управления;
2) информационные потоки между функциональными группами
могут жестко контролироваться вплоть до полной блокировки лю-
бых сетевых потоков;
3) доступ к прикладным серверам может контролироваться на
основе функциональной группы (сетевого сегмента), IP-адреса кли-
э*
67
00
Администратор
безопасности
Сетевые сегменты с различными
требуемыми уровнями
информационной безопасности
Сеть 10.0.ethX.0
nzzzzzzzzzzzzzzzzzzzzzzzzzz
МЭ
Защищенный сегмент
прикладных серверов
Сеть 10.0.4.0
Рис. 4.6. Схема использования МЭ в составе многосегментной ЛВС
ента, конкретного пользователя (при выполнении процедуры аутен-
тификации), типа транспортного протокола, номеров транспортных
портов;
4) механизмы протоколирования сетевых событий МЭ позво-
ляют выполнять мониторинг и аудит состояния ИБ на уровне сети.
4.2. Экранирующий экран
В отличие от МЭ с несколькими интерфейсами, разделяющего
две и более сетей, экранирующий МЭ (ранее в литературе его на-
зывали бастион-хост) подключен только ко внутренней сети и име-
ет один сетевой интерфейс.
В такой схеме подключения особое внимание уделяется на-
стройке маршрутных таблиц маршрутизатора, IP-адресам интер-
фейса МЭ и внутренней сети. Маршрутизатор настраивается так,
чтобы весь входящий трафик отправлялся на интерфейс МЭ, а во
внутренней сети в качестве шлюза должен быть указан адрес ин-
терфейса МЭ (рис. 4.7).
Экранирующий МЭ можно представить как распределенный
МЭ, состоящий из маршрутизатора, который может дополнитель-
но выполнять функции фильтра пакетов, и самого МЭ.
Использование схемы экранирующего МЭ обеспечивает мень-
шую защищенность, поскольку требуется правильная настройка как
самого МЭ, так и маршрутизатора и всех IP-хостов внутренней
сети. Так, если адреса внутренней сети являются зарегистриро-
ванными, то возможен обход МЭ путем указания в качестве адре-
са шлюза адреса маршрутизатора вместо адреса интерфейса МЭ.
Тем не менее использование этой схемы в ряде случаев оправ-
дано. Например, если в сети отсутствует МЭ, и необходимо реали-
зовать аутентификацию пользователей, работающих по любому
протоколу, например HTTP, то можно предложить следующее ре-
Рис. 4.7. Использование экранирующего МЭ
69
Рис. 4.8. Подключение МЭ по схеме «экранирующая подсеть»
шение. Во внутренней сети выделяется хост для реализации функ-
ции МЭ, на который устанавливается посредник сеансового уровня
SOCKS5 и выполняются необходимые настройки. На маршрути-
заторе запрещаются исходящие пакеты с адресами источника, от-
личными от адреса МЭ. На рабочих местах устанавливается кли-
ентская часть SOCKS5. Теперь все пользователи для работы по
протоколу HTTP должны пройти аутентификацию, в то время как
работа по остальным протоколам остается без изменений.
Подключение МЭ по схеме экранирующего МЭ обеспечивает
большую гибкость, но меньшую защищенность и поэтому исполь-
зуется редко.
4.3. Экранирующая подсеть
Конфигурация «экранирующая подсеть» добавляет дополни-
тельный уровень безопасности в конфигурацию экранирующего МЭ
путем внесения сетевого сегмента для улучшения «изоляции» за-
щищенной сети от Интернет. Использование двух маршрутизато-
ров усиливает защищенность путем жесткого определения сете-
вых интерфейсов, через которые проходят сетевые пакеты.
На рис. 4.8 представлено подключение МЭ по схеме «экрани-
рующая подсеть». Два экранирующих маршрутизатора образуют
внутреннюю фильтрующую подсеть, которая может выполнять
функции демилитаризованной зоны, и к ней можно подключить не-
обходимые сервисы DMZ.
Так же, как и в случае с экранирующим МЭ, использование
экранирующей подсети требует правильной настройки маршрут-
ных таблиц экранирующих маршрутизаторов и позволяет гибко уп-
равлять сетевым трафиком, определяя, какие пакеты могут быть
проходить напрямую, минуя МЭ.
Подключение по схемам экранирующего МЭ и экранирующей
подсети обеспечивают большую гибкость, но меньшую защиту, чем
подключение МЭ с несколькими сетевыми интерфейсами (dual-
homed в том числе).
70
5. ТЕХНОЛОГИИ
МЕЖСЕТЕВЫХ ЭКРАНОВ
Основными технологиями защиты, реализуемыми с помощью
межсетевых экранов, являются фильтрация пакетов и технология
установления посредничества между клиентом и сервером на при-
кладном уровне. Существуют и успешно реализуется в МЭ ряд дру-
гих технологий защиты и управления сетевым трафиком. В главе рас-
смотрены основные технологии защиты, используемые в современных
МЭ. Именно поддержка этих дополнительных технологий и опреде-
ляет основные различия между конкретными реализациями МЭ.
5.1. Сетевая трансляция адресов
Технологию сетевой трансляции адресов (NAT - Network
Address Translation) широко используют в большинстве МЭ. Она
имеет большое значении при реализации защиты сети.
При использовании NAT МЭ выступает посредником между
двумя IP-узлами, организуя два канала передачи данных. При этом
МЭ, использующий NAT, взаимодействует с внешним IP-узлом от
имени внутреннего, но со своим IP-адресом. Таким образом, с внеш-
ней стороны нельзя узнать IP-адреса внутренней сети, что позво-
ляет, во-первых, скрыть внутреннюю структуру сети, а во-вторых,
иметь всего лишь один зарегистрированный IP-адрес для обеспе-
чения работы всех внутренних хостов. IP-адреса внутренней сети
рекомендуется использовать из блока приватных адресов (10.0.0.0
- 10.255.255.255, 172.16.0.0 - 172.31.255.255, 192.168.0.0 -
192.168.255.255), рекомендованных в [30-32] специально для внут-
ренних сетей. Важное достоинство NAT заключается также и в
том, что не требуется изменения конфигурации хостов локальной
сети. NAT является «прозрачной» технологией.
NAT обеспечивает простую и надежную защиту путем уста-
новления так называемой «однонаправленной маршрутизации», ког-
да сетевые пакеты передаются через МЭ только из внутренней
сети.
71
В некоторых источниках NAT относят не к технологии МЭ, а к
отдельному виду шлюзов сеансового уровня. Поскольку NAT в
чистом виде не используется как МЭ, а только в составе различ-
ных типов МЭ, то автор считает, что сетевую трансляцию логич-
нее рассматривать как технологию.
Сетевая трансляция адресов осуществляется в следующих ре-
жимах: динамическом, статическом и комбинированном. Различа-
ют также трансляцию адреса источника (Source Translation) и ад-
реса назначения (Destination Translation). В большинстве случаев
используется трансляция адреса источника. Далеко не все МЭ под-
держивают трансляцию адреса назначения.
Сетевая трансляция обычно применяется в следующих случаях:
• ПБ требует сокрытия адресов внутренней сети;
• смена адресов хостов в сети невозможна;
• необходимо подключить сеть с большим количеством хостов,
но провайдер услуг Интернет выделил ограниченное количество
IP-адресов.
Трансляцию адресов назначения применяют также при распре-
делении нагрузки ТСР-трафика.
Динамическая трансляция
При динамическом режиме, иногда называемом трансляцией
на уровне портов, МЭ имеет один внешний IP-адрес. Все обраще-
ния в общедоступную сеть со стороны клиентов внутренней сети
осуществляются с использованием этого внешнего адреса. МЭ при
обращении клиента выделяет ему уникальный порт транспортного
протокола (TCP, UDP) для внешнего IP-адреса. Выделяемый пул
портов составляет до 65535 портов, но практически эта цифра ог-
раничена диапазоном 10000 - 20000, поскольку для каждого соеди-
нения резервируется блок оперативной памяти, что накладывает
ограничение на системные ресурсы используемой платформы МЭ.
Например, в МЭ Checkpoint Fire Wall-1 4.1 пул портов, используе-
мых для трансляции, начинается с порта 10000. При этом обес-
печивается максимальное количество установленных соединений
25000. В некоторых реализациях Cisco IOS могут использоваться
для этих целей следующие диапазоны портов: 0-511,512- 1023,
1024 - 65535, в ОС Linux с оперативной памятью более 128 Мб
используется пул 32768 - 61000, а менее 128 Мб - 1024 - 4999.
Рассмотрим пример динамической трансляции адресов (рис. 5.1).
В локальной сети используется ^маршрутизируемая сеть с ад-
72
1
2
Distination
Source
Distination
10.0.0.21 207.46.130.149
1025 80
Source
200.0.0.1 207.46.130.149
5001 80
Source
Distination
Source Distination
207.46.130.149
10.0.0.21
80
1025
207.46.130.149 200.0.0.1
80 5001
3
4
Рис. 5.1. Пример динамической трансляции адресов
ресным пространством 10.0.0.0. Клиент локальной сети желает ус-
тановить соединение с Web-сервером www.microsoft.com (IP-ад-
рес 207.46.130.149). Операционная система клиента формирует
обычные IP-пакеты (шаг 7) и отправляет их в сеть. При прохожде-
нии пакетов через МЭ (шаг 2) последний изменяет адрес источни-
ка на адрес внешнего интерфейса, транспортный порт источника
на первый свободный из пула неиспользуемых портов и заново вы-
числяет контрольную сумму пакета. Для Web-сервера клиентом
выступает хост, имеющий IP-адрес 200.0.0.1, т. е. МЭ. Сервер от-
вечает клиенту обычным образом (шаг 3). При прохождении паке-
тов от сервера обратно МЭ выполняет обратные действия - заме-
няет адрес получателя и порт отправителя (шаг 4). Таким образом,
как для клиента, так и для сервера процедура выполнения трансля-
ции адресов является абсолютно прозрачной.
В ряде ОС линии Unix динамический режим трансляции при
подключении с динамическим IP-адресом называют маскарадин-
гом (от английского masquerading).
Динамический режим предназначен для сетей, хосты которых
в большинстве случаев выступают клиентами ресурсов открытой
сети Интернет.
Динамическая трансляция с динамической
выборкой IP-адресов
В динамическом режиме с динамической выборкой IP-адресов
внешние IP-адреса выделяются динамически из пула внешних ад-
ресов. Как и при динамической трансляции для каждого соедине-
ния выделяется транспортный порт. Отличие состоит в том, что
при исчерпании всего пула портов выделяется следующий внешний
1Р-адрес.
Динамический режим трансляции адресов накладывает огра-
ничения на количество одновременных соединений. Поскольку для
каждого TCP-соединения выделяется один транспортный порт, то
теоретически максимальное количество одновременных соедине-
ний составляет 65535. Практически это значение намного ниже,
поскольку большинство МЭ имеют фиксированный пул транслиру-
ющих портов, а программное обеспечение как МЭ, так и базовой
ОС использует сокеты для межпроцессорных коммуникаций и дру-
гих целей.
74
Source
1
2
Distillation
Source
200.0.0.21 IP-адрес клиента
80 Порт клиента
10.0.0.1 IP-адрес клиента
80 Порт клиента
4 _______________________________________________ 3
Приватный IP-адрес Маршрутизируемый IP-адрес
10.0.0.21 10.0.0.22 200.0.0.21 200.0.0.22
Ch
Рис. 5.2. Пример статистической трансляции адресов
Динамическая трансляция с динамической выборкой 1Р-адре-
сов используется при необходимости обеспечения большого коли-
чества одновременных соединений.
Статическая трансляция
При статическом режиме внешнему интерфейсу МЭ назнача-
ется столько зарегистрированных IP-адресов, сколько хостов име-
ется во внутренней сети. Каждому хосту внутренней сети ставит-
ся в соответствие уникальный внешний IP-адрес МЭ. Статический
режим используется, если хосты внутренней сети предоставляют
сервисы для клиентов общедоступной сети (являются серверами
Интернет).
На рис. 5.2 Приведен пример статической трансляции адресов:
• клиент общедоступного сегмента сети Интернет обращается
к Web-серверу по адресу 200.0.0.21 (шаг 7);
• МЭ (или маршрутизатор, поддерживающий NAT) находит в
таблице NAT соответствующее правило и заменяет адрес назна-
чения 200.0.0.21 на 10.0.0.21 (шаг 2);
• сервер возвращает ответный пакет с адресом источника
10.0.0.21 (шаг 5);
• при выходе из локальной сети МЭ заменяет адрес источника
на адрес 200.0.0.21 (шаг 4).
Таким образом, для внешнего клиента соединение с сервером,
находящимся в локальной сети, является абсолютно прозрачным.
Трансляция с динамической выборкой IP-адресов
Этот вид трансляции не использует транспортные порты - каж-
дому клиенту назначается динамически IP-адрес, назначаемый из
пула внешних адресов. Трансляция с динамической выборкой IP-
адресов проще в реализации, обеспечивает большую производи-
тельность, но имеет значительный недостаток - число одновре-
менно работающих пользователей ограничивается количеством
внешних IP-адресов.
Все вышеперечисленные типы трансляций адресов можно ис-
пользовать в комбинированном режиме. Комбинированный режим
использует сразу несколько таких режимов. Его применяют в се-
тях, где необходимо обеспечить работу и клиентов, и серверов, рас-
положенных в защищенной сети. Далеко не все МЭ поддерживают
комбинированный режим трансляции адресов.
76
Особенности использования NAT
При использовании NAT характерен такой недостаток, как не-
возможность трансляции адресов, применяемых на уровне приклад-
ных протоколов, например протокол FTP. Протокол FTP устанавли-
вает два канала - управления и передачи данных. В активном
режиме канал передачи открывается после создания канала уп-
равления путем передачи клиентом номера TCP-порта, с которым
сервер должен установить соединение (кроме того, в процессе пе-
редачи данных некоторые типы FTP-клиентов передают IP-адрес
своего интерфейса). Поскольку номер порта передается на при-
кладном уровне, то возникает проблема открытия канала переда-
чи данных. МЭ, использующие NAT, должны иметь специальные
модули, учитывающие особенности протокола FTP. Если МЭ не
предусматривает работу протокола FTP в активном режиме, то
FTP-клиент должен поддерживать пассивный режим. При этом
FTP-сервер сам назначает порт для канала передачи данных. К со-
жалению, не все FTP-клиенты могут работать в пассивном режиме.
Компания Novell использует технологию трансляции сетевых
протоколов IPX/IP. При таком подходе внутренняя сеть использу-
ет протокол IPX, а специальный шлюз проводит трансляцию запро-
сов клиентов во внешнюю сеть по протоколу IP и наоборот, что
обеспечивает повышенную защищенность, поскольку во внутрен-
ней сети используется другой протокол, передача данных и управ-
ление по которому невозможны через стек IP. Это верно, если во
внутренней сети используется исключительно сетевой протокол IPX
и не используется механизм туннелирования протоколов IPX по-
верх IP.
5.2. Трансляция портов
Механизм трансляции портов (РАТ - Port Address Translation,
port mapping) на основе транспортного порта назначения позволяет
перенаправлять сетевые пакеты (соединения) на заданные 1Р-ад-
рес:порт. Данный механизм трансляции позволяет:
• перенаправлять соединения на сервера-посредники, например,
принудительно перенаправлять клиентов локальной сети на посред-
ник HTTP;
• устанавливать соединения с серверами локальной сети, име-
ющих приватные адреса;
• повышать безопасность сетевых сервисов путем переназна-
чения стандартных портов.
Иногда производители МЭ не выделяют отдельно трансляцию
портов как поддерживаемую технологию, а рассматривают ее со-
77
вместно с NAT. Например, реализация NAT компанией Cisco пре-
дусматривает и управление портами. Компания Cisco под РАТ по-
нимает технологию трансляции адресов на основе выделения транс-
портных портов.
Таблица трансляции портов может иметь следующий вид:
200.0.0.1:4200 10.0.0.10:80
200.0.0.1:110 10.0.0.20:110
200.0.0.1:21 10.0.0.10:21
0.0.0.0:80,8080 200.0.0.1:80
Первая запись указывает - перенаправлять входящие соеди-
нения с 4200 портов в локальную сеть на адрес 10.0.0.10 и 80 порт.
Таким образом, может быть организован ограниченный доступ к
серверу Web для бизнес-партнеров (http://200.0.0.1:4200). Вторая и
третья записи позволяют обращаться внешним клиентам к почто-
вому и ftp-серверам соответственно. Последняя запись выполня-
ет принудительное перенаправление на НТТР-посредника.
5.3. Антивирусная защита
Одной из самых опасных и распространенных видов угроз ИБ
является распространение деструктивного кода в виде вирусов и
так называемых троянских программ. Средством их распростра-
нения являются различные прикладные протоколы, позволяющие
передавать файлы с одного компьютера на другой. Это прежде
всего относится к протоколам FTP, SMTP и HTTP, которые исполь-
зуют для решения своих задач практически все организации.
Поскольку МЭ с точки зрения прохождения сетевого трафика
обеспечивает единую точку входа (выхода) в сеть, то целесооб-
разно возложить на него также и функции антивирусной защиты.
Для решения задачи антивирусной защиты компанией Checkpoint
в рамках проекта OPSEC (Open Platform for Secure Enterprise
Connectivity) был разработан протокол CVP (Content Vectoring
Protocol - протокол перенаправления содержания). Производители
программного обеспечения, пользуясь открытой спецификацией
OPSEC, предоставляющей открытый интерфейс разработки прило-
жений, могут поставлять дополнительное программное обеспече-
ние для усиления МЭ или дополнения его функций.
Межсетевой экран, поддерживающий протокол перенаправле-
ния содержания CVP, выступает как клиент сервера CVP (рис. 5.3).
На сервере CVP осуществляется обработка информационных по-
токов (в данном случае - обнаружение вирусов), поступающих от
78
CVP Клиент
Получатель
Отправитель
События
Функции API
Поток
сервера
CVP Сервер
Обработчик событий
(callback)
Рис. 5.3. Клиент-серверная модель протокола CVP
клиента. При обнаружении вируса антивирусный сервер произво-
дит его удаление либо осуществляет другие необходимые действия.
Результат обработки возвращается обратно МЭ.
Антивирусный сервер для повышения производительности мо-
жет быть расположен как на отдельно выделенном компьютере,
так и на компьютере с МЭ. По умолчанию для сервера CVP выде-
ляется транспортный порт TCP 18181. Протокол CVP поддержи-
вают такие хорошо зарекомендовавшие себя антивирусные про-
граммы, как AVP for Fire Wall (лаборатория Касперского), Norton
AntiVirus for Fire Wall (Symantec).
Известны и другие решения реализации антивирусной защиты.
Так, например, в МЭ BlackHole 4.11 компании Milky Way трафик
протокола SMTP перенаправляется на 25-й порт выделенного ан-
тивирусного сервера, который после обработки почты возвраща-
ется обратно на МЭ. Данная реализация очень напоминает работу
по описанному выше универсальному протоколу CVP, но не обес-
печивает универсальности.
Некоторые производители МЭ ранее включали в состав своих
продуктов антивирусные средства. Однако из-за сложности под-
79
держки антивирусных баз самими производителями МЭ такие ре-
шения быстро «умирали». Следует обратить внимание на совмес-
тимость МЭ и CVP-сервера. К сожалению, протокол CVP на се-
годняшний день не стандартизирован и его реализации сильно
отличаются у различных производителей.
5.4. Аутентификация
Для определения полномочий пользователей доступа к сете-
вым ресурсам как внутренней, так и внешней сетей выполняется
их аутентификация. Использование механизмов аутентификации
позволяет значительно усилить защиту любых информационных
ресурсов. В тех случаях, когда вопросам обеспечения ИБ уделя-
ется повышенное внимание, процедура аутентификации должна
быть неотъемлемой частью ПБ. Аутентификация используется
практически во всех приложениях ИБ, поэтому далее вопросы аутен-
тификации будут рассматриваться с точки зрения технологии МЭ.
Аутентификация (authentication) - процесс, гарантированно оп-
ределяющий подлинность объекта аутентификации на основе
предъявляемых идентификаторов и использования специальных
протоколов и схем аутентификации. В большинстве случаев суть
аутентификации состоит в доказательстве того, что представлен-
ный идентификатор (например, имя пользователя) действительно
принадлежит заявителю.
Чаще всего процедуру аутентификации используют при органи-
зации доступа пользователей к критическим информационным ре-
сурсам, а также при подключении мобильных или внешних пользо-
вателей к ресурсам защищаемой сети. Поскольку процедура
аутентификации требует ряда определенных административно-тех-
нических мероприятий и вносит дополнительную нагрузку на МЭ,
то критерием целесообразности ее использования, в первую оче-
редь, должна выступать ценность защищаемых ресурсов.
Методы аутентификации
Основная задача процедуры аутентификации состоит в опреде-
лении подлинности идентификатора пользователя на основе предо-
ставляемой им информации. В технологии МЭ различают следую-
щие методы аутентификации:
• пользователей;
• клиентов;
• сессии.
80
Аутентификация пользователей
Аутентификация пользователей предоставляет доступ на осно-
ве информации о пользователе (login/password). Этот метод при-
меняют только для протоколов, использующих аутентификацию на
прикладном уровне, например - TELNET, FTP. Аутентификация
пользователей выполняется для каждого соединения.
Аутентификация клиентов
Аутентификация клиентов осуществляется на основе 1Р-адре-
са хоста клиента. Метод хотя и не обеспечивает полной защищен-
ности аутентификации, но он удобен и достаточен, если точно из-
вестно соответствие пользователей и закрепленных за ними
IP-адресов. Это самый распространенный тип аутентификации, под-
держиваемый всеми без исключения МЭ. Аутентификация клиен-
тов используется в сети со статическими адресами и невысокими
требованиями к обеспечению ИБ.
Аутентификация сессии
Аутентификация сессии выполняется для каждого запрашива-
емого соединения на основе информации о пользователе. Этот
метод требует дополнительного программного обеспечения (аген-
та аутентификации сессии) на клиентских машинах сети. Аутенти-
фикация сессии позволяет использовать различные протоколы
аутентификации и применима практически для всех прикладных и
некоторых служебных сервисов.
Существует два подхода инициализации аутентификации сес-
сии. В первом случае МЭ перехватывает запрос клиента на соеди-
нение и устанавливает соединение с агентом аутентификации.
Агент аутентификации является сервером, ожидающим запроса
соединения от МЭ. Агент аутентификации «поднимает» форму вво-
да данных аутентификации (запрашивает данные) и передает эти
данные на МЭ. При успешном выполнении аутентификации соеди-
нение разрешается, в противном случае - блокируется. Агент аутен-
тификации может запускаться на компьютере-источнике (клиен-
те), компьютере-сервере и на других хостах. Такой подход
реализован в МЭ Fire Wall-1 (рис. 5.4).
Во втором случае агент аутентификации на клиентском компь-
ютере перехватывает запросы установления соединений приклад-
ных программ на сетевом уровне (перехват сетевого API ОС) и
устанавливает соединение с МЭ, где выполняется аутентифика-
ция. В случае успешной аутентификации соединение разрешается.
81
£ FireWall-1 Soecion Authentication ИЕЗВ
И||1|И||М
:'-Лд^о,'Л .>
; fW-1 Session Authenticalbn Requestfrortfsque;:
Cormectinq to server equecomcom.com for service 80Лср
Рис. 5.4. Запрос агента аутентификации МЭ Fire Wall-1
Агент аутентификации инкапсулирует сетевые пакеты приклад-
ной программы и осуществляет их доставку МЭ. МЭ выделяет из
них пакеты прикладной программы и отправляет их по адресу на-
значения. Примером реализации этого метода является аутенти-
фикация протокола SOCKS (рис. 5.5).
82
Основное преимущество аутентификации сессии заключается
в возможности строгой аутентификации любого сетевого приложе-
ния, использующего транспортные протоколы TCP и UDP, а в не-
котрых реализациях и ICMP.
Прозрачность аутентификации
Если при выполнении процедуры аутентификации не требуется
участие пользователей, то она называется прозрачной. В зависи-
мости от типа аутентификации возможны как прозрачные, так и
непрозрачные механизмы ее выполнения.
Аутентификация клиентов на основе IP-адреса хоста всегда
является прозрачной. В зависимости от реализации аутентифика-
ция сессии может быть как прозрачной, так и непрозрачной.
London
(FireWalled Gateway)
Router
localnet
A
DMZ
(HTTP, FTP, etc)
W
BigBen
(FTP Server)
tower # ftp bigben
Connected to London.
220 london Checkpoint FireWall-1 secure ftp server
running on London
Name (bigben:jim): jimb
331-aftpd: FireWall-1 password: you can use password@FW-
1-password
Password: <Unix password on bigben>@<FireWall-1 password>
230-aftpd: User jimb authenticated by FireWall-1
authentication.
230-aftpd: Connected to bigben. Logging in...
230-aftpd: 220 bigben ftp server (UNIX(r) System V
Release 4.0) ready.
230-aftpd: 331 Password required for jimb.
230-aftpd: 220 User jimb logged in.
Рис. 5.6. Пример выполнения прозрачной аутентификации
83
> telnet fw (адрес МЭ)
fw proxy-telnet [v3.0] ready
Please enter your userid: serg (аутентифкация МЭ)
Password:
command==> connect linux
Looking up linux...
[proxy-telnet: connected to IPv4[10.0.0.40:23] ]
Linux 2.2.14 (linux) (ttypl)
linux login: serg
Password:
Linux 2.2.14.
Last login: Tue Apr 4 12:55:14 on tty2.
No mail.
linux:
Рис. 5.7. Пример выполнения непрозрачной аутентификации
TELNET-соединения МЭ BlackHole
Рассмотрим подробнее особенности прозрачной и непрозрач-
ной аутентификации пользователей. Прозрачная аутентификация
не требует от клиента самостоятельного подключения к МЭ.
Межсетевой экран перехватывает запрос клиента на установле-
ние соединения и запускает процедуру аутентификации.
На рис. 5.6 приведен пример выполнения прозрачной аутенти-
фикации пользователей [4]. Пользователь j imb желает открыть
FTP-соединение с сервером BigBen. МЭ осуществляет перехват
запроса соединения и предлагает выполнить аутентификацию. Пос-
ле успешной аутентификации МЭ устанавливает соединение с зап-
рашиваемым сервером.
На рис. 5.7 показан пример выполнения непрозрачной аутенти-
фикации TELNET-соединения МЭ BlackHole компании Milky Way.
Пользователь serg пытается установить TELNET-соединение с
сервером linux. Для этого он подключается к TELNET-посред-
нику МЭ f w, где выполняется аутентификация. После успешной
аутентификации МЭ предоставляет интерфейс подключения к тре-
буемому серверу linux.
Протоколы и схемы аутентификации
МЭ могут использовать как встроенные схемы и протоколы
аутентификации, так и внешние. Выбор той или иной схемы зависит
прежде всего от требований надежности аутентификации и интегра-
ции с существующими сетевыми сервисами и программным обеспе-
84
чением сети. Если в сети уже имется система аутентификации, то
использование такой системы МЭ является предпочтительным.
Как правило, все коммерческие МЭ используют схемы OS
Password, S/Key, Kerberos, Fire Wall password (INIX-like password),
но могут поддерживать и внешние схемы RADIUS, TACACS,
TACACS+, SecurlD. Рассмотрим некоторые из них подробнее.
FireWall password и OS Password
Межсетевые экраны позволяют создавать пароли пользовате-
лей непосредственно на МЭ. Схема аутентификации с использова-
нием таких паролей называется FireWall password или UNIX-like
password. Если же МЭ применяет для аутентификации пароль
пользователя для входа в ОС своей рабочей станции, то такая схе-
ма называется OS Password. В зависимости от реализации МЭ и
типа клиентской ОС (Unix, Windows NT, Windows 9x, Novell) па-
роль пользователя на вход в ОС может быть импортирован на МЭ
или использоваться синхронно.
S/Key
- программная схема аутентификации, использующая од-
норазовые пароли. Клиент на основе секретного ключа, известного и
клиенту, и серверу для каждого соединения генерирует одноразовый
пароль. Пароль не может быть использован повторно (рис. 5.8).
One-Time-Password Generator
Ал- .... * '
...'
H'sSSisS.......rrl..................'....r"rr........r”Iin.....J
I I t -
Рис. 5.8. Программный генератор одноразовых
паролей Axent
85
Kerberos
Kerberos - это стандартный протокол безопасности Интернет
для определения подлинности пользователей или систем. Kerberos
разработан в Массачусетском технологическом институте и ут-
вержден в качестве стандарта Интернет [29]. Протокол использу-
ет трехуровневую архитектуру («цербер» - мифический трехголо-
вый пес): клиент, аутентичность которого необходимо доказать;
сервер, услугами которого желает воспользоваться клиент; сервер
проверки подлинности, выступающий третьей стороной, которой
доверяет и клиент, и сервер. Ключевым понятием в протоколе яв-
ляется понятие билета (ticket). Kerberos обеспечивает надежные
механизмы аутентификации; при этом пароли не передаются по сети
даже в зашифрованном виде. Kerberos поддерживается всеми со-
временными ОС, а некоторые его реализации доступны и в исход-
ных текстах.
Использование внешних схем позволяет использовать МЭ уже
существующие методы аутентификации в сети или более защи-
щенные схемы аутентификации.
SecurlD
SecurlD - технология аутентификации компании RSA Security
[16], использующей генерацию одноразовых паролей (OTP - one
time password) на основе временной синхронизации. SecurlD ис-
пользует так называемую двухфакторную аутентификацию -
пользователь имеет свой собственный уникальный PIN-код (пер-
вый фактор), на основе которого генерируется одноразовый пароль
(второй фактор).
SecurlD имеет аппаратную реализацию в виде электронного
ключа, похожего на небольшой калькулятор (рис. 5.9). Каждый
пользователь имеет собственный уникальный электронный ключ
(токен), зарегистрированный на сервере аутентификации (АСЕ/
Server). Аутентификацию SecurlD поддерживают такие МЭ, как
Checkpoint FireWall-1, CyberGuard, Cisco PIX, AXENT Raptor
Fire Wall, Novell BorderWare Fire Wall, NAI Gauntlet и др.
CRYPTOCard
CRYPTOCard - технология аутентификации одноименной ком-
пании [12]. В основе CRYPTOCard заложены принципы двухфак-
торной аутентификации, используемые и в RSA SecurlD. Основное
отличие от RSA состоит в особенностях протокола аутентифика-
ции (CRYPTOCard использует более защищенные методы), управ-
лении и лицензировании токенов.
86
. л :
SecurlD®
0 0 В В 0 18 В В 0
Рис. 5.9. Электронные токены SecurlD SD200
и SD600 компании RSA Security
TACACS и RADIUS
Системы TACACS (Terminal Access Controller Access Control
System) и RADIUS (Remote Authentication Dial-In User Service) раз-
работаны для централизованного контроля доступа к сети уда-
ленных пользователей [26, 36]. Сервера TACACS и RADIUS выс-
тупают в качестве посредников между серверами удаленного
доступа и сетевыми сервисами. МЭ для сервера TACACS являет-
ся клиентом. Сетевые ресурсы, на подключение к которым прове-
ряет полномочия сервер TACACS, описываются в виде пары IP-
адрес:порт.
В свою очередь сервер TACACS может использовать различ-
ные схемы аутентификации - OS password, SecurlD и др.
5.5. Обнаружение вторжений
и аномальной активности
Организация безопасности информационных ресурсов должна
обеспечивать не только защиту этих ресурсов, но и решать задачи
обнаружения и предупреждения попыток нарушения ИБ. Обнару-
87
жение попыток несанкционированного доступа, воздействий отка-
за в обслуживании на ранних этапах их осуществления позволяет
своевременно принять адекватные меры, направленные на предот-
вращение последствий нарушений.
Под аномальной (необычной) активностью подразумевают та-
кие сетевые события, которые нельзя непосредственно классифи-
цировать как атаку, но в то же время их проявление в той или иной
степени отличается от «нормального». К аномальной активности
можно отнести: возрастание объема сетевых подключений, резкое
возрастание объема трафика (в рабочее и нерабочее время), воз-
растание сообщений протокола ICMP и др. Причиной подобных
событий являются не только действия злоумышленников, но и
ошибки в сетевом программно-аппаратном обеспечении, некоррект-
ные действия пользователей сети.
Существует отдельный класс программных средств, решаю-
щих задачу обнаружения вторжений и аномальной активности -
системы обнаружения вторжений (IDS - Intrusion Detection
Systems). Средства IDS имеют обычно двухуровневую архитекту-
ру, включающую сенсоры (агенты обнаружения) и консоль безо-
пасности (управления). В зависимости от источника анализируе-
мых данных различают системные (host based), сетевые (network
based) и прикладные (application based) агенты. Агенты собирают
различные данные и отправляют их на сервер консоли безопаснос-
ти, где происходит их накопление и анализ. В некоторые системах
сенсоры сами распознают факт атаки, в других - решение прини-
мает консоль. IDS имеют описания (сигнатуры) -известных атак,
на основании которых и происходит анализ собираемых данных и
принятие решения о событии атаки.
Большинство атак обнаруживается на основе анализа некото-
рого объема сетевых пакетов, что требует значительных ресурсов
аппаратной платформы. В отличие от IDS, оптимизированных для
обнаружения вторжений в реальном или максимально приближен-
ном к реальному времени, основная задача МЭ состоит в обеспе-
чении надежной и непрерывной защиты. Поэтому МЭ решают за-
дачи IDS лишь частично. Ограничения МЭ заключаются в
следующем:
• МЭ, поддерживающие функции IDS, позволяют обнаруживать
ограниченное количество сетевых атак, в большинстве случаев -
типовые атаки отказа в обслуживании. МЭ обнаруживают так на-
зываемые атомарные сетевые атаки, которые используют некор-
ректно сформированные пакеты;
88
• функции IDS реализованы в МЭ жестко, т. е. на уровне про-
граммного кода, что не позволяет адаптировать МЭ к новым ти-
пам атак. Типовые IDS (network based) распознают около тысячи
сетевых атак, в то время как МЭ порядка десяти;
• с целью повышения производительности механизмы обнару-
жения атак в МЭ сильно упрощены. Например, некоторые реали-
зации МЭ выполняют поиск вторжений путем периодического ана-
лиза журналов событий на некотором промежутке времени.
Очевидно, такой подход с точки зрения обнаружения вторжений
имеет ряд ограничений, но позволяет минимизировать нагрузку на
МЭ.
Из вышесказанного следует, что функции систем обнаружения
вторжений реализуются в МЭ недостаточно, а значит, для повы-
шения уровня защиты необходимо использовать самостоятельные
полнофункциональные продукты IDS (ISS RealSecure, Axent
NetRecon, NFR, Snort и др.).
В идеальном случае системы IDS и МЭ должны быть само-
стоятельными продуктами, но взаимодействующими друг с дру-
гом - при обнаружении нарушителей или сетевых атак система
IDS должна уведомлять МЭ, который должен при явной необходи-
мости соответствующим образом корректировать реализуемую ПБ.
Именно таким образом реализовано взаимодействие МЭ FireWall-
1 компании Checkpoint и IDS RealSecure.
5.6. Управление бюджетами пользователей
Управление бюджетами пользователей в большой организации
может стать проблемой как для сетевых администраторов, так и
для пользователей сети. Доступ к таким корпоративным ресурсам,
как электронная почта, Web, файл-сервер, система обработки до-
кументов (например, LotusNotes), БД требуют выполнения проце-
дуры аутентификации. А это значит, что для каждого пользователя
всех информационных ресурсов должны существовать его учет-
ные записи (или бюджеты). Проблема усугубляется еще такими
обстоятельствами:
• прикладные службы установлены физически на разных ком-
пьютерах;
• наличие в сети нескольких серверных платформ - Windows
NT, NetWare, Unix;
• разделение обязанностей между администраторами - адми-
нистратор безопасности, администратор БД, администратор интер-
нет-ресурсов и др.
89
Трудности могут возникнуть и у пользователей сети, поскольку
необходимо помнить пароль на доступ к каждому ресурсу. Бюд-
жет пользователя на МЭ может быть сформирован одним из сле-
дующих способов:
• создан непосредственно на МЭ. В этом случае администра-
тор МЭ вводит самостоятельно всю необходимую учетную инфор-
мацию о пользователе (в том числе и пароль). При большом числе
пользователей такой способ управления бюджетом может быть
причиной нарушения ИБ, поскольку появляется проблема сообще-
ния пароля пользователю. Чаще всего администратор записывает
его на бумаге и затем передает ее пользователю или отправляет
по электронной почте;
• импорт бюджетов пользователей. Большинство МЭ под уп-
равлением Windows NT позволяют импортировать и даже синх-
ронизировать бюджеты пользователей домена Windows NT. Такой
способ разрешает быстро получить пользовательские бюджеты и
использовать их в некоторых схемах аутентификации;
• использование централизованной БД бюджетов пользовате-
лей или сервера аутентификации.
На сегодняшний день наиболее известной и быстро развиваю-
щейся технологией этого типа является служба каталогов на осно-
ве LDAP-серверов. Облегченный протокол доступа к каталогу
LDAP (Lightweight Directory Access Protocol) был разработан спе-
циально для сетей TCP/IP на основе протокола доступа к каталогу
Х.500.
Использование сервера LDAP в целях хранения учетных дан-
ных пользователей позволяет:
• использовать одни и те же учетные записи пользователей для
всех прикладных служб, требующих аутентификацию;
• самостоятельно устанавливать и изменять свои пароли;
• использовать на МЭ существующие учетные записи на сер-
верах LDAP без необходимости их импортирования (если МЭ под-
держивает LDAP).
5.7. Контроль времени действия
правил политики безопасности
Политика безопасности организации может быть значительно
усилена за счет использования временных ограничений действия
правил МЭ. Временное ограничение может быть особенно акту-
альным в крупных организациях с большим числом сотрудников и
информационных ресурсов. Если в организации используется вре-
менное ограничение доступа, то об этом должны быть обязатель-
но проинформированы все сотрудники.
90
Предоставление пользователям доступа к ресурсам сети толь-
ко в часы рабочего времени позволяет:
• сосредоточить анализ аудита безопасности в строго опреде-
ленное время - время рабочего дня. Таким образом, часть ме-
роприятий аудита, выполняемая на основе событий безопасности
нерабочего времени, может быть направлена только на анализ по-
пыток нарушения ИБ со стороны внешнего периметра безопас-
ности;
• повысить организацию дисциплины рабочего времени, посколь-
ку сотрудники не могут начинать рабочий день раньше или закан-
чивать его позже установленного времени;
• предотвратить несанкционированное использование рабочих
станций в целях несанкционированного доступа к сетевым ресур-
сам в нерабочее время;
• выполнять в установленное время технологические меропри-
ятия (резервное копирование, репликацию, обновление программ-
ного обеспечения и др.) на серверах сети без потери рабочего вре-
мени сотрудников. Например, при необходимости репликацию БД с
удаленным сервером можно выполнять не в ночное время, как это
обычно принято, а во время обеденного перерыва, запретив на это
время весь трафик, кроме трафика БД. Тем самым повышается
актуальность данных, хранящихся в БД.
Развитая политика управления временем действия правил МЭ
позволяет определять не только жесткие промежутки времени, но
и оперировать временем как высокоуровневым объектом, опреде-
ляя дни недели, четные и нечетные дни, праздничные дни, а также
их различные комбинации.
Практически все коммерческие МЭ экспертного уровня, филь-
тры в составе маршрутизаторов поддерживают механизмы управ-
ления временем действия правил. Пакетные фильтры не реализу-
ют такой возможности. В ОС линии Unix можно организовать
временное управление ПБ при помощи планировщика выполнения
заданий (cron). Для этого необходимо иметь несколько конфигура-
ционных файлов ПФ для каждого временного промежутка. Если
ПФ предоставляет механизмы вставки/удаления правил, то конфи-
гурационные файлы могут учитывать только необходимые изме-
нения в ПБ, что обеспечивает более гибкие механизмы управле-
ния МЭ.
5.8. Виртуальные частные сети
Угроза ИБ при использовании Интернет для организации биз-
нес-связей между филиалами компаний, бизнес-партнерами, мо-
бильными пользователями сводит на нет удобство и низкую сто-
91
имость такого решения. На сегодняшний день практически ни одна
крупная компания, использующая Интернет в своем бизнесе, не
обходится без применения технологии VPN. Технология виртуаль-
ных частных сетей позволяет использовать сети общего пользова-
ния для построения защищенных сетевых соединений. Рассмотрим
базовые моменты технологии подробнее, чтобы понять особенно-
сти использования МЭ, поддерживающих функции VPN-шлюзов.
Технология VPN выполняет две основные функции:
• шифрование данных, за счет чего обеспечивается безопас-
ность сетевых соединений. При шифровании, как правило, исполь-
зуют общеизвестные стандартные протоколы RC4, CAST, DES,
3DES и др;
• туннелирование протоколов, что обеспечивает прозрачность
использования технологии VPN. Протоколы туннелирования чаще
называют протоколами VPN (IPSec, РРТР, L2TP и др.).
Продукты VPN могут быть реализованы в виде:
• самостоятельных программных продуктов;
• аппаратных устройств;
• дополнительных функций маршрутизаторов и коммутаторов;
• дополнительных функций МЭ.
Под термином «виртуальные частные сети» чаще всего пони-
мается организация защищенных информационных потоков между
объектами виртуальной сети, организованных через сети общего
пользования. При этом потоки данных частной и общей сетей не
должны влиять друг на друга.
Защищенные потоки (каналы) виртуальной частной сети могут
быть созданы между VPN-шлюзами сети, VPN-шлюзами и VPN-
клиентами, а также между VPN-клиентами (рис. 5.10). Создание
виртуальных защищенных каналов достигается за счет шифрова-
ния трафика и инкапсуляции (туннелирования) протоколов между
объектами VPN-сети.
VPN-шлюз -? сетевое устройство, установленное на границе
сети, выполняющее функции образования защищенных VPN-кана-
лов, аутентификации и авторизации клиентов VPN-сети.
VPN-шлюз располагается аналогично МЭ таким образом, что-
бы через него проходил весь сетевой трафик организации. В боль-
шинстве случаев VPN-сеть для пользователей внутренней сети
остается прозрачной и не требует установки специального про-
граммного обеспечения.
VPN-клиент - программное обеспечение (иногда с аппаратным
акселератором), устанавливаемое на компьютеры пользователей,
осуществляющих подключение к сети VPN (через VPN-шлюзы).
VPN-клиент выполняет функции передачи параметров аутентифи-
кации и шифрования/дешифрования трафика.
92
пользователь
(VPN-клиент)
Рис. 5.10. Варианты организация защищенных каналов VPN
В большинстве случаев необходимо одновременно обеспечить
функционирование двух каналов - Интернет и VPN. При этом мож-
но использовать или различные физические линии связи или одну.
Однако стоимость эксплуатации одного канала связи для доступа
к сети Интернет и поддержки VPN обходится значительно ниже.
Рис. 5.11. Варианты относительного
расположения VPN-шлюза и МЭ
93
На рис. 5.11 представлены возможные варианты взаимного рас-
положения МЭ и VPN-шлюза при использовании одного физичес-
кого канала. МЭ и VPN-шлюзы могут быть как независимыми про-
дуктами, так и дополнять функции друг друга.
Преимущество использования МЭ, поддерживающего функции
VPN-шлюза (см. рис. 5.11, в), заключается в возможности про-
зрачного управления политикой безопасности в едином интерфейсе
управления как открытого, так и защищенного трафика Интернет.
Такое решение значительно облегчает процесс управления МЭ и
VPN-шлюзом, но предъявляет повышенные требования к произво-
дительности аппаратных средств.
Протоколы VPN
В табл. 5.1 представлены основные протоколы, используемые
для организации защищенных сетевых соединений. Одно из основ-
ных требований, предъявляемых к сетям VPN, заключается в обес-
печении прозрачности для сетевых приложений и протоколов. Дру-
гими словами, технология частных сетей должна обеспечивать
возможность применения для любых приложений. По этой причи-
не в технологии VPN используются протоколы, функционирующие
на трех уровнях модели OSI - канальном, сетевом и транспортном.
Таблица 5.1. Протоколы, используемые для организации защищенных
сетевых соединений
Уровень OSI Протокол Примечание
Прикладной — —
Представительный SSL, TSL, (SSH) Требует поддержки приложе- нием. Наибольшее распространение получил в протоколе HTTP (HTTPS)
Сессионный SOCKS Требует поддержки приложе- нием или использования специ- ального ПО
Транспортный — —
Сетевой IPSec, IP over IP Система открытых стандартов Интернет, решающая задачи уста- новления и поддержания защищен- ного соединения
Канальный PPTP, L2F, L2TP Многопротокольный удаленный доступ к ресурсам корпоративной сети через сеть общего доступа
Физический — —
94
Протоколы канального уровня (РРТР, L2F, L2TP) не зависят от
протоколов верхних уровней, что позволяет создавать VPN-кана-
лы для большинства сетевых протоколов (IP, IPX, ApplTalk). Не-
смотря на универсальность, у протоколов канального уровня от-
сутствует требуемая гибкость использования и поэтому они
ориентированы на одиночных пользователей.
Наибольшее применение в продуктах VPN нашли протоколы
сетевого уровня. Самым распространенным представителем это-
го класса является система протоколов IPSec.
Система протоколов IPSec
Система открытых стандартов Интернет IPSec [42] разрабо-
тана с учетом всех требований, предъявляемых к технологии VPN.
IPSec используется как для подключения удаленных пользовате-
лей, так и для создания защищенных каналов между экстрасетя-
ми.
Система протоколов IPSec обеспечивает решение следующих
задач:
• аутентификацию пользователей или хостов при инициализации
защищенного канала;
• шифрование и аутентификацию передаваемых данных между
конечными точками защищенного канала;
• безопасное снабжение конечных точек секретными ключами
и другой ключевой информацией.
Решение этих задач реализуют три протокола:
• АН (Authentication Header) - обеспечивает целостность и
аутентификацию данных и опционально предоставляет сервис от
ложного воспроизведения [43];
• ESP (Encapsulation Security Payload) - обеспечивает прежде
всего конфиденциальность трафик^ а так же, как и протокол АН,
может обеспечивать целостность, аутентификацию данных и за-
щиту отложного воспроизведения [44];
• IKE (Internet Key Exchange) - выполняет функции инициали-
зации защищенного канала и управления ключами шифрования/де-
шифрования.
IPSec предоставляет производителям и потребителям средств
защиты гибкость в выборе протоколов шифрования, аутентифика-
ции данных и способов инициализации соединений (обмена ключа-
ми). Это позволяет обойти такие проблемы, как ограничения на
экспорт криптографических средств, совместимость с другими
продуктами и требования использования конкретных протоколов
шифрования.
95
Протокол РРТР
Протокол РРТР (Point-to-Point Tunneling Protocol) является со-
вместной разработкой компаний Microsoft, ЗСот, ECI-Telematics,
US Robotics и Ascend Communication. Протокол не получил стату-
са стандарта Интернет, поскольку почти одновременно с Microsoft
компания Cisco Systems представила в IETF свой протокол L2F
(Layer 2 Forwarding). В результате на основе двух представленных
протоколов был создан протокол L2TP.
Основное преимущество РРТР заключается в его многопрото-
кольности, т.е. возможности инкапсулирования различных прото-
колов (IP, IPX, NetBEUI и др.). РРТР инкапсулирует пакеты РРР в
IP пакеты с помощью протокола GRE (рис. 5.12). РРТР использу-
ет протоколы аутентификации MS-CHAP или EAP-TLS. Протокол
EAP-TLS (Extensible Authentication Protocol - Transport Level
Security) обеспечивает аутентификацию соединений по требованию
на основе цифровых сертификатов.
Заголовок протокола канального уровня (PPP, Ethernet) Заголовок IP Заголовок GRE Исходный пакет РРР
Рис. 5.12. Схема инкапсулирования пакетов протоколом РРТР
Шифрование пакетов в РРТР реализуется в соответствии с про-
токолом МРРЕ (Microsoft Point-to-Point Encryption Protocol) [51], в
котором использован алгоритм RC-4 с длиной ключа 40 или 128
бит. Инициализация канала РРТР выполняется удаленным пользо-
вателем путем установки TCP-соединения (портТ723) с сервером
RAS, выполняющим функции однонаправленного VPN-шлюза (в
терминологии РРТР).
Протокол нашел широкое распространение при организации за-
щищенных подключений удаленных пользователей, использующих
ОС компании Microsoft.
Протоколы L2F и L2TP
Протокол L2TP (Layer 2 Tunneling Protocol) унаследовал луч-
шие стороны протоколов Microsoft РРТР, Cisco L2F и в настоящее
время имеет статус проекта стандарта Интернет [49, 39]. По этой
причине протокол L2F не нашел распространения и используется
только в предыдущих линиях продуктов Cisco.
96
Основные свойства протокола L2TP:
• прозрачность для конечных систем. Протокол использует схе-
му, в которой туннель образуется между сервером удаленного до-
ступа провайдера (LAC - L2TP Access Concentrator) и маршрути-
затором корпоративной сети (LNS - L2TP Network Server).
Пользователь инициирует PPP-соединение с концентратором LAC,
после чего образуется Ь2ТР-туннель между LAC и LNS. Конечно,
провайдер должен предоставлять сервис L2TP, а концентратор LAC
должен быть соответствующим образом сконфигурирован;
• аутентификация в рамках возможностей, заложенных в про-
токол PPP (СНАР/РАР, TACACS+, RADIUS и др.);
• назначение адреса клиенту выполняется сервером LNS, а не
провайдером.
L2TP может работать поверх любого транспортного протокола
с коммутацией пакетов. В IP-сетях протокол использует UDP-
транспорт (порт 1701). Протокол нашел широкое распространение
и используется в продуктах компаний Cisco, ЗСот, Altiga Networks,
Ascend, Compaq, IBM, Intel, Microsoft.
Протоколы шифрования и контроля целостности
Если протоколы VPN обеспечивают универсальность и прозрач-
ность для сетевых приложений и пользователей, то протоколы шиф-
рования и контроля целостности реализуют защиту самих соеди-
нений от возможного просмотра и модификации. Протоколы
шифрования и контроля целостности данных используются «внут-
ри» протоколов VPN.
Основными показателями протоколов шифрования являются
открытость и криптостойкость. Открытость алгоритма шифрова-
ния позволяет мировому сообществу убедится в его возможнос-
тях (отсутствие «полицейских» входов, невозможность компроме-
тации и т. п.), а криптостойкость показывает стойкость алгоритма
к возможности подбора пароля.
Контроль целостности осуществляется путем выполнения од-
носторонней криптографической, так называемой, хэш-функции (или
дайджест-функции), в качестве аргументов которой выступают кон-
тролируемые данные и секретный ключ.
Наибольшее распространение в продуктах VPN нашли следу-
ющие протоколы шифрования - DES, 3DES (тройной DES), CAST,
RC4, RSA Keys и протоколы контроля целостности MD5, SHA-1.
4 Лебедь С.В.
97
Протоколы управления ключами
Проблема распределения (распространения) секретных ключей
характерна для всех приложений, в том числе и при организации
сети VPN. Эта задача в технологии VPN решается путем исполь-
зования протоколов IKE, SKIP и инфраструктуры открытых клю-
чей. Существует ряд протоколов, например GKMP (Group Key Mana-
gement Protocol), не нашедших пока применения в продуктах VPN.
Протокол IKE
Протокол IKE (Internet Key Exchange) [46] разработан на осно-
ве протоколов ISAKMP [45], Oakley [45], SKEME [22] и использу-
ется в составе системы протоколов IPSec. Протокол ISAKMP
(Internet Security Association and Key Management Protocol) описы-
вает лишь общие процедуры установления безопасных ассоциа-
ций, аутентификации и обмена секретными ключами, без описания
используемых для этого протоколов. За основу IKE был взят про-
токол ISAKMP, дополненный конкретными процедурами аутенти-
фикации и обмена ключами из протоколов Oakley и SKEME. По
этой причине протоколы ISAKMP/Oakley и IKE часто используют
как синонимы.
IKE предоставляет два способа аутентификации сторон - ис-
пользование предварительно разделенного секретного ключа («сек-
рета») и цифровых сертификатов Х.509. Разделенный секрет ис-
пользуют для получения цифровой подписи, на основе которой
доказывается аутентичность противоположной стороны. Исполь-
зование цифровых сертификатов будет рассмотрено ниже.
После успешной аутентификации начинает функционировать
протокол Диффи-Хелмана (Diffie-Hellman), который обеспечивает
защищенный механизм получения сторонами секретного ключа,
используемого безопасными ассоциациями IPSec АН или ESP.
IKE использует в обоих направлениях транспортный порт 500
протокола UDP.
Протокол SKIP
Простой протокол управления ключами SKIP’ (Simple Key-
Management for Internet Protocols) [1] разработан компанией Sim
Microsystems и в настоящее время рассматривается как проект
стандарта Интернет. SKIP изначально ориентирован на дейтаграмм-
’ http://www.skip-vpn.org.
98
ный характер протокола IP и обеспечивает высокую скорость об-
мена ключами. В протоколе заложена поддержка конфигураций, в
которых используются механизмы повышенной надежности (High
Availability), балансировки нагрузки, а также предусмотрена защи-
та от атак типа отказа в обслуживании и утери ключа аутентифи-
кации пакетов.
Так же, как и IKE, SKIP использует ключи Диффи-Хелмана,
аутентичность которых может быть проверена при помощи серти-
фикатов Х.509, Secure DNS или PGP. Для шифрования ключевой
информации используются любые симметричные алгоритмы (в на-
стоящее время поддерживаются - DES-CBC, 3DES, IDEA-CBC,
RC2, RC4, RC4, RC5, SAFER). SKIP инкапсулируется в IP как про-
токол с зарегистрированным номером 57 (поле IP заголовка
«Protocol number»).
Протокол SKIP предусматривает взаимодействие с протоко-
лами АН и ESP, но пока не вошел в систему протоколов IPSec. В
свою очередь, из-за того, что протокол не признан в качестве стан-
дарта, он не нашел широкого распространения в продуктах VPN.
Инфраструктура открытых ключей
Технологии на основе открытых ключей (асимметричной крип-
тографии) и цифровых сертификатов Х.509 ввиду своих явных дос-
тоинств и преимуществ находят все большее распространение в
организациях, где требуется обеспечить защиту разнородных дан-
ных и единую схему аутентификации. К основным преимуществам
технологии открытых ключей можно отнести:
• обеспечение целостности данных (на основе хэш-функции);
• гарантии невозможности подмены отправителя сообщения (на
основе цифровой подписи);
• гарантии конфиденциальности (обеспечиваются криптографи-
ческими алгоритмами - прочитать сообщение может только тот
получатель, которому оно действительно предназначалось);
• универсальность применения.
Использование системы открытых ключей в глобальном мас-
штабе требует принятия дополнительных административно-техни-
ческих усилий, что приводит к необходимости использования тех-
нологии PKI (Public Key Infrastructure). Инфраструктура открытых
ключей решает проблемы хранения, выдачи, верификации, аннули-
рования цифровых сертификатов и другие задачи по обеспечению
функционирования технологии в большой распределенной среде.
99
Технология PKI позволяет создать единый механизм как для
всех приложений, где требуется обеспечить защиту данных, так и
для всех пользователей, предоставляя эффективные механизмы
безопасного доступа. Основными компонентами PKI являются:
• доверенные центры (СА - Certificate Authority);
• архив сертификатов;
• система аннулирования сертификатов (CRL - Certificate
Revocation Lists);
• система создания резервных копий и восстановления ключей;
• система поддержки невозможности отказа от цифровых под-
писей;
• система автоматической корректировки пар ключей и серти-
фикатов.
Использование технологии PKI при организации VPN-соедине-
ний дает следующие преимущества:
• используются надежные механизмы взаимной аутентифика-
ции сторон;
• повышается скорость и безопасность подключения новых
пользователей и узлов, поскольку достаточно указать уникальный
идентификатор пользователя (сертификата);
• автоматически решаются задачи аннулирования и обновле-
ния ключевой информации;
• VPN легко интегрируется в существующую инфраструктуру
PKI.
Технология PKI требует принятия значительных организацион-
но-технических усилий на этапе развертывания системы. Однако
эти усилия вполне оправданы, если организация имеет большое
число удаленных пользователей, распределенных филиалов или
партнеров.
Прохождение VPN-трафика через МЭ
Как было показано выше, возможны различные варианты вза-
имного расположения VPN-шлюза и МЭ. В случае размещения
VPN-шлюза за МЭ необходимо обеспечить прохождение VPN-тра-
фика через МЭ. Для решения этой задачи МЭ должен:
• поддерживать работу с транспортными протоколами, отлич-
ными от TCP и UDP;
• знать соответствующие номера протоколов, инкапсулируемых
в IP.
В табл. 5.2 приведены номера основных протоколов VPN.
100
Таблица 5.2. Номера основных протоколов VPN
Протокол Инкапсулирован в протокол Номер протокола
АН IP 51
ESP IP 50
IKE UDP 500
SKIP IP 57
L2F, L2TP UDP 1701
GRE IP 47
РРТР (TCP) TCP 1723
В большинстве случаев в политике безопасности МЭ необхо-
димо создать, как минимум, два правила для прохождения трафи-
ка VPN. Например, подключение удаленных пользователей по про-
токолу РРТР требует разрешения прохождения следующих пакетов
к серверу RAS:
• IP-пакеты с инкапсулированным протоколом GRE;
• TCP-пакеты с портом получателя 1723.
Обратим еще раз внимание на то, что в случае размещения
VPN-шлюза за МЭ он не может контролировать трафик VPN, а
значит, целесообразно серверы RAS или VPN-шлюзы выносить в
зону DMZ. Тогда защищенный трафик будет проходить через вне-
шний интерфейс МЭ в зону DMZ (рис. 5.13), где VPN-шлюз «из-
влечет» шифрованный трафик и возвратит его через внутренний
Рис. 5.13. Размещение VPN-шлюза в зоне
DMZ обеспечивает контроль VPN-трафика
101
интерфейс МЭ в локальную сеть. На маршруте DMZ - внутренний
интерфейс можно применить правила МЭ, что позволит обеспе-
чить требуемый уровень безопасности. Кроме этого, полномочия
удаленных пользователей можно определять непосредственно и на
самом VPN-шлюзе.
5.9. Split DNS
Система DNS, благодаря своей простоте и удобству использо-
вания, нашла широкое применение не только в глобальных сетях,
но и в небольших локальных сетях. Пользователям намного удоб-
нее оперировать логическими доменными адресами, чем запоми-
нать четырех-байтные IP-адреса. Вместе с удобством использо-
вания система DNS порождает ряд проблем ИБ. Одна из них
связана с возможностью исследования доменных имен локальной
сети в целях вскрытия ее внутренней структуры.
Действительно, система DNS, как правило, отображает орга-
низационную структуру фирмы и позволяет злоумышленнику, как
минимум, выделить рабочие станции и прикладные сервера. В про-
стейшем случае может быть использована команда ОС nslookup
(Unix, Windows NT), позволяющая выполнять основные запросы к
системе DNS.
Технология Split DNS (split - расщепление) призвана разделить
использование системы DNS на внешнюю и внутреннюю. Расщеп-
ление выполняется таким образом, что клиенты внутренней сети
могут обращаться как к внутренним, так и к внешним объектам
DNS; при этом внешние запросы на разрешение имен и IP-адресов
будут обрабатываться МЭ на основе установленных правил.
Некоторые реализации Split DNS представляют возможность
автоматической замены локальных доменных имен и IP-адресов в
заголовках прикладных протоколов, что особенно полезно при ис-
пользовании в локальной сети SMTP-сервера. В этом случае заго-
ловок сообщения при выходе из локальной сети будет содержать
два поля «Received»: в первом будет указан адрес или имя клиен-
та, отправившего сообщение, а во втором - «адрес» или имя само-
го почтового сервера.
На рис. 5.14 приведен фрагмент SMTP-заголовка сообщения,
из конференции, посвященной МЭ. Анализ заголовка позволяет
сделать сразу несколько важных выводов:
1) локальная сеть, в которой находится автор сообщения, рас-
положена за пределами МЭ;
2) письмо отправлено почтовым клиентом exmh version 2.1.1;
102
Received: from raptor (raptor.bruderer-research.com
[195.65.50.27]) by spike.rwc.gnac.net (8.8.8/8.8.8)
with ESMTP id VAA08212 for <firewalls@Lists.GNAC.NET>;
Mon, 26 Jun 2000 21:53:50 -0700 (PDT)
Received: by raptor; id GAA03427; Tue, 27 Jun 2000 06:53:49
+0200(MET DST)
Received: from madmax.bruderer-research.com(10.0.0.5) by raptor.
bruderer-research.com via smap (V5.5) id xma003423;
Tue, 27 Jun 00 06:53:12 +0200
Received: from madmax.bruderer-research.com (brudy@localhost
[127.0.0.1] by madmax.bruderer-research.com
(8.9.3/8.9.3/SuSELinux 8.9.3-0.1) with ESMTP id
GAA23209 for <firewalls@Lists.GNAC.NET>; Tue, 27 Jun
2000 06:53:11 +0200
Message-Id: <200006270453.GAA23209@madmax.bruderer-research.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To: firewalls@Lists.GNAC.NET
Subject: Re: giga-byte firewall
Content-Type: text/plain; charset=us-ascii
Date: Tue, 27 Jun 2000 06:53:11 +0200
From: Peter Bruderer <brudy@bruderer-research.com>
Рис. 5.14. Пример SMTP-заголовка сообщения электронной почты
3) локальный адрес почтового сервера - 10.0.0.5;
4) ОС почтового сервера - SuSeLinux;
5) слово raptor может указывать на использование МЭ Raptor
компании Axent;
6) IP-адрес внешнего интерфейса МЭ - 195.65.50.27.
Заметьте, эта информация может быть получена совершенно
законным образом, без использования специального программного
обеспечения!
Поддержка Split DNS реализована в свободно распространяе-
мом DNS-сервере BIND (начиная с версии 9), которую можно ис-
пользовать в качестве дополнения защитных возможностей МЭ,
функционирующих на Unix-платформах.
5.10. Балансировка нагрузки
и управление полосой пропускания
Один из недостатков стека протоколов TCP/IP заключается в
отсутствии предусмотренных механизмов управления полосой про-
пускания сетевых соединений. Кроме того, протокол TCP во вре-
мя соединения пытается максимально увеличить скорость пере-
дачи. Эти обстоятельства приводят к тому, что даже при наличии
высокоскоростного внешнего канала связи имеют место следую-
щие проблемы:
103
• пользователи сети находятся в неравном положении - кто-то
может «захватить» канал;
• скорость доступа к критическим сетевым приложением не
может быть гарантирована;
• осложняется работа сетевых приложений, чувствительных к
задержкам, например приложений видеосвязи.
В последнее время в связи с резким возрастанием пропускной
способности каналов связи, используемых Интернет, и увеличени-
ем роли Интернет в различных сферах человеческой деятельнос-
ти, актуальна и такая проблема, как оптимизация нагрузки на се-
тевые службы. Один из возможных путей ее решения заключается
в балансировке нагрузки между несколькими идентичными серве-
рами.
Решением вышеперечисленных проблем стала разработка ряда
протоколов управления приоритетами трафика, реализуемых в боль-
шинстве сетевых маршрутизаторах: Class Based Queuing (CBQ),
TCP Window Sizing, Random Early Detection (RED), Stochastic Fairness
Queuing, Retransmit Detect Early Drop (RDED) и др. [23, 53-57].
Задача управления полосой пропускания должна решаться на
границе сетей с разными пропускными способностями. Поскольку
МЭ размещаются именно в этом месте, то и возникает разумный
вопрос - почему бы не возложить на них эту задачу. В настоящее
время наиболее полно проблема управления полосой пропускания
решена в МЭ FireWall-1 компании Check Point. Check Point разра-
ботала собственный алгоритм управления очередями Check Point
Multi Path Queuing (очередь нескольких путей), реализованный в
модуле FloodGate-1. FloodGate-1 интегрирован в GUI «Check Point
Policy Editor» и позволяет быстро создавать требуемые правила
пропускной способности для заданных служб (рис. 5.15).
В большинстве МЭ для решения задачи оптимизации нагрузки
на прикладные серверы используется механизм «карусель». С по-
мощью механизма карусели (round robin) можно оптимизировать
нагрузку за счет циклического перенаправления соединений на оче-
редной сервер из пула зеркальных.
Name Source [Destination | Service Action |
; 35.
PointCast Rule ©Any ©Ary PdntCas» Wi 5
©Any i©Ary I© Any ММдМ 1П
Рис. 5.15. Правила управления полосой пропускания Check Point
FloodGate-1
104
5.11. Управление сетями
Управление МЭ через платформы
управления сетями
Современная инфраструктура сетей состоит из множества ус-
тройств, выполняющих самые разнообразные функции. Это - се-
теобразующие устройства: коммутаторы, маршрутизаторы, вспо-
могательные и прикладные устройства: устройства бесперебойного
питания, сетевые устройства хранения и др. Все они имеют раз-
личные протоколы, форматы управления и, к тому же, работают
под разными ОС. Управление множеством сетевых устройств в
большой сети может быть существенной проблемой.
В настоящее можно выделить два направления решения этой
проблемы. Первое направление заключается в предоставлении
производителями устройств доступных интерфейсов управления,
например TELNET и WWW (клиенты этих служб есть в каждой
ОС). Но такой подход облегчает лишь доступ администратора к
устройству, при большом количестве разнородных устройств не-
обходимо привыкать к каждому интерфейсу. Второе решение про-
блемы состоит в поддержке устройствами протоколов управления
сетями, например SNMP, RMON. В этом случае возможно исполь-
зование систем управления сетями, предоставляющих единые ме-
ханизмы управления и мониторинга сетевых устройств и программ-
ного обеспечения. Лидерами рынка продуктов управления сетями
являются Computer Associates Unicenter TNG, Tivoli Systems и
Hewlett-Packard OpenView.
Межсетевые экраны являются неотъемлемой частью сетевой
инфраструктуры, и с этой точки зрения для них также характерны
проблемы удаленного управления и взаимодействия с другими се-
тевыми устройствами в сети.
Средства управления сетями позволяют вести всеобъемлющий
мониторинг состояния всех сетевых устройств, а также выполнять
управление теми из них, которые предоставляют такую возмож-
ность. С этой точки зрения сетевые администраторы, выполняю-
щие непрерывный мониторинг сети, могут контролировать и со-
стояние средств защиты, а при обнаружении сигналов тревоги
сообщать об этом администратору безопасности.
Практически все коммерческие МЭ в качестве одного из ме-
ханизмов уведомления о событиях (SNMP trap) используют про-
токол SNMP. Как правило, это критические события ОС или кри-
тические события безопасности. Использование SNMP-трапов
105
Acknawbdga Др| gwr lirfo, j | Сигом* Бйрйу Орвм» I Сигом*: i 1 i
ShoM AS Alutroa I Hwrttny 34 । *
АсДцимй»**» | ft» Tro | ____. __ J &******________________JL.J |
Statu» |OMM I Tiro» IDffmfrfa** .101
Info IMAftl/HI IJtHtl? 1нрЙ1И|Ы!11Ш) 1 и. Ml .VIII I UeW-Mi
|tnfo (М/Ш/1П I 101 III 1мИШ1 «да 010 1 M> I 4 1 .4,21! 1 1 1
^o«md 04/30/01 13 00 14 Link Up PoO 3 FneWall
IIFrHifi il ” fH/WJtlt 13flB 14 1 ink 1 In Pint 7 * * ' **'• ’"*
*NotmJ 04/30/01 13 0034^ Unk Up FiieWalf’
jM.ijni IH/ilMH PhW I nld Mail
IMAttl/lil Laid Siad
^М<цг«»
Рис. 5.16. HP OpenView Alarm Log
подразумевает, что в сети используется система мониторинга или
SNMP-монитор. При получении трапов система управления мо-
жет изменять окраску устройств (каждый цвет соответствует важ-
ности сигнала, например, Info, Warning, Critical, Error), отображае-
мых на карте сети, выводить звуковой сигнал или визуальное
сообщение (рис. 5.16).
Сетевое оборудование, управляемое по протоколу SNMP, выс-
тупает в качестве агентов SNMP. Агенты SNMP поддерживают
только те функциональные возможности, которые в них заложены.
Это означает, что если МЭ имеет в своем составе SNMP-агента,
то это вовсе не означает, что возможно выполнение всех админис-
тративных функций через протокол SNMP. Производители обору-
дования, поддерживающие протокол SNMP, предоставляют так
называемые базы управляющей информации (MIB - Management
Information Base), содержащие описание значений, форматов и до-
пустимые операции (read/write) над ними в нотации ASN. 1 (Abstract
Syntax Notation One). База MIB должна быть доступна системе
управления сетью. На рис. 5.17 приведен фрагмент MIB-файла МЭ
FireWaU-1.
Данные, доступные для чтения, могут быть получены единож-
ды или с заданной периодичностью, что позволяет отслеживать
динамику их изменения. Например, имеется возможность отсле-
живания динамики изменения трех значений: количества разрешен-
ных пакетов «fwAccepted», отброшенных пакетов «fwRejected» и
запрещенных пакетов «fwDropped» (рис. 5.18). Резкое возраста-
ние количества запрещенных пакетов может свидетельствовать о
попытках нарушения ИБ - сканировании портов или DoS-атаках.
106
CHECKPOINT-MIB DEFINITIONS ::= BEGIN
— SUBTREE: 1.3.6.1.4.1.2620.1.1
— iso.org.dod.internet.private.enterprises.checkpoint.
products.f w
fwMbduleState OBJECT-TYPE
SYNTAX Displaystring (SIZE (0..255))
ACCESS read-only
STATUS mandatory
DESCRIPTION
’’The state of the fw module.”
::= { fw 1 )
fwFilterName OBJECT-TYPE
SYNTAX Displaystring (SIZE (0..255))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The name of the loaded filter."
::= { fw 2 }
Рис. 5.17. Фрагмент MIB-файла МЭ Check Point FireWall-1
Большинство систем управления сетями предоставляет API,
позволяющие добавлять новые функциональные модули управле-
ния оборудованием и программным обеспечением.
Рис. 5.18. Динамика обработки пакетов
107
Использование протокола SNMP, с точки зрения безопасности,
имеет ряд особенностей. Первая версия протокола SNMP vl не
предоставляет никаких механизмов защиты от неавторизованного
доступа, поэтому использование этой версии протокола возможно
только внутри локальной сети. Во второй версии протокола автори-
зация выполняется на основе значения community, которое по умол-
чанию устанавливается в Public, и очень часто администраторы
не изменяют его. Кроме этого, SNMP-трафик передается в откры-
том виде с использованием транспорта UDP, что делает возмож-
ным подделку, просмотр и изменение SNMP-пакетов при прохож-
дении их через общедоступные сети. И только в третьей версии
(SNMP v3) реализованы механизмы полной защиты протокола с
использованием криптографических методов.
Протокол SNMP предоставляет универсальные возможности
мониторинга и управления сетевым оборудованием и программ-
ным обеспечением, а использование средств управления сетями
позволяет использовать все его преимущества, в том числе и при
управлении средствами безопасности. Использование средств уп-
равления сетями особенно оправдано в сетях с большим количе-
ством активного оборудования, но требует высокой квалификации
администратора.
Управление списками доступа маршрутизаторов
Пограничные маршрутизаторы формируют первый эшелон обо-
роны сети. Кроме выполнения непосредственно функций маршру-
тизации, современные маршрутизаторы содержат фильтры паке-
тов, что позволяет возложить на них часть функций по обеспечению
безопасности сети. Такое решение может быть принято по причи-
не разделения функций или по соображениям производительности.
Производительность маршрутизаторов намного превышает произ-
водительность МЭ, поскольку первые выполняют ограниченный
набор операций и реализуются на аппаратном уровне. Для решения
этих задач МЭ могут поддерживать функции управления маршру-
тизаторами. Управление маршрутизаторами в этом случае осу-
ществляется через пользовательский интерфейс МЭ, скрывая
от администратора особенности настроек конкретного типа марш-
рутизатора. Кроме этого, при формировании списков доступа ад-
министратор может оперировать объектами (сети, службы, прото-
колы), определенными ранее, а не вводить их вручную.
108
5.12. Посредник сеансового уровня SOCKS
Протокол SOCKS изначально разрабатывался как МЭ и оста-
ется одним из самых распространенных посредников сеансового
уровня. SOCKS, пожалуй, единственный стандартизованный МЭ,
который, помимо возможностей, имеющихся у большинства МЭ,
позволяет производить аутентификацию любых TCP- и UDP-со-
единений, что позволяет гибко управлять политикой доступа к при-
кладным ресурсам сети. Если в сети используется МЭ на основе
прикладных посредников таких протоколов, как FTP, TELNET, SMTP,
HTTP, то для поддержки нового прикладного протокола в сети мо-
жет потребоваться разработка нового посредника. Протокол SOCKS
позволяет избежать такой проблемы. Некоторые производители МЭ
используют протокол SOCKS для реализации функции аутентифи-
каций сессии (например, ШМ Network FireWall), другие разраба-
тывают собственные методы, например Check Point FireWall-1.
SOCKS v5 (версии 5) также известен как authenticated firewall
traversal (AFT). Он является открытым стандартом Интернет для
реализации сетевых посредников на транспортном уровне [35].
Протокол основан на клиент/серверной технологии - SOCKS-cep-
вера и клиентской библиотеки. SOCKS-сервер работает на при-
кладном уровне, а клиентская библиотека - между прикладным и
транспортным уровнями (рис. 5.19). SOCKS-сервер выступает по-
средником для всех соединений, запрашиваемых клиентом.
Рис. 5.19. Протокол SOCKS в модели OSI
109
Протокол SOCKS позволяет выполнять соединения и без аутен-
тификации пользователей, но требует, чтобы конкретные реализа-
ции поддерживали методы GSSAPI [27, 28] и USERNAME/
PASSWORD. Кроме того, SOCKS предоставляет возможность
использования других зарегистрированных протоколов аутентифи-
кации (CHAP, CRAM, Kerberos, SSL и т. п.).
Процедура установления TCP-соединения по протоколу SOCKS
выглядит следующим образом. Клиентская библиотека может быть
связана с клиентским SOCKS-совместимым приложением дина-
мическим или статическим образом. При статическом связыва-
нии код SOCKS-библиотеки помещен в самом приложении на эта-
пе его компиляции, т. е. поддержка протокола закладывается
разработчиками приложения. Динамическое связывание реализу-
ется специальными программами (SOCKS-клиентами) путем пе-
рехвата вызовов сетевого API (winsock в Windows, Berkley Socket
в Unix). SOCKS-клиенты могут быть самостоятельными програм-
мами или интегрированы в сетевой стек ОС.
В обоих случаях SOCKS-библиотека устанавливает ТСР-со-
единение с SOCKS-сервером (по умолчанию TCP порт - 1080) и
передает ему сообщение, содержащее версию протокола и под-
держиваемые методы аутентификации:
VER NMETHODS METHODS
1 1 1-255
Поле VER содержит версию протокола (х05 для пятой версии).
Поле NMETHODS содержит длину поля METHODS. Сервер вы-
бирает один из предложенных методов и посылает сообщение-от-
VER METHOD
1 1
Если значение поля METHODS установлено сервером в xFF,
то сервер не поддерживает ни один из методов, предложенных кли-
ентом, и клиент должен закрыть соединение. Если выбранный ме-
тод подразумевает контроль целостности или шифрование, то все
последующие сообщения между клиентом и сервером SOCKS ин-
капсулируются в пакеты, определяемые этим методом.
После завершения переговоров о методе SOCKS-клиент отправ-
ляет запрос на выполнение требуемого действия:
VER CMD RSV ATYP DST.ADDR DST.PORT
1 1 xOO 1 Variable 2
Здесь: VER - версия протокола; CMD - команда: хО 1 - CONNECT,
х02 - BIND, хОЗ - UDP ASSOCIATE; RSV- зарезервировано;
110
ATYP - тип адреса: хО1 - IP V4, хОЗ - доменное имя, x04 - IP V6;
DST.ADDR - адрес назначения; DST.PORT - транспортный порт
назначения.
Команда BIND позволяет установить соединение, открывае-
мое со стороны прикладного сервера, например, ftp-соединение,
открываемое в активном режиме. Команда подразумевает, что
устанавливается вторичное соединение после установления соеди-
нения командой CONNECT.
Команда UDP ASSOCIATE используется при передаче клиент-
ских UDP-дейтаграмм, при этом между клиентом и SOCKS-серве-
ром устанавливается TCP-соединение. Передача UDP-дейтаграмм
ассоциируется с TCP-соединением. При закрытии или разрыве
TCP-соединения ассоциированное соединение также разрывается.
Далее SOCKS-сервер выполняет требуемые команды и возвра-
щает соответствующие ответы:
VER REP RSV ATYP BND.ADDR BND.PORT
1 1 хОО 1 Variable 2
Все поля, кроме REP, имеют то же назначение, что и в сообще-
нии-запросе. Поле REP содержит результат выполнения запроса и
может иметь следующие значения: хОО - команда выполнена удач-
но; хО1 - ошибка SOCKS-сервера; х02 - правила запрещают со-
единение; хОЗ - сеть недоступна; х04 - хост недоступен; х05 -
сброс соединения; х06 - превышение TTL (времени ожидания от-
вета); х07 - команда не поддерживается; х08 - тип адреса не
поддерживается.
При успешном выполнении команды (поле REP содержит хОО)
клиент может передавать данные. В противном случае SOCKS-
сервер закрывает соединение.
В настоящее время существует две версии протокола SOCKS
- 4 и 5 (SOCKS v4 и SOCKS v5). SOCKS v4 выполняет три функ-
ции: запрос соединения, установление посредничества, передача
данных. В SOCKS v5 добавлена аутентификация и поддержка про-
токола FTP.
Одна из самых привлекательных реализаций протокола SOCKS
заключается в том, что в некоторых случаях нет необходимости
перекомпилировать или каким-либо образом изменять клиентские
приложения, что позволяет прозрачно использовать имеющееся про-
граммное обеспечение. Это достигается реализацией клиентской
SOCKS-библиотеки, перехватывающей вызовы сетевого API. Та-
кие библиотеки реализованы практически под все ОС, например,
runsocks для Unix и SocksCap для Windows 3.11, 9х и NT компании
NEC.
Ill
Чтобы использовать без изменения имеющееся ПО, оно долж-
но отвечать ряду требований. Эти требования определяют прави-
ла вызова стандартных функций BSD-сокетов (или winsock для
Windows). Например, для обеспечения совместимости приложе-
ний с клиентом SOCKS SocksCap компании NEC необходимо, что-
бы приложение отвечало следующим требованиям:
• ОС сама должна назначать транспортный порт источника;
• не использовать функцию bind() перед установлением соеди-
нения;
• перед привязкой сокетов в многосокетном (multi-socket) кли-
енте необходимо сначала устанавливать соединение с сервером;
• для определения локального IP-адреса необходимо использо-
вать функцию getsockname();
• не использовать функции writev(), readv();
• инициализировать соединение с сервером.
Кроме того, существуют бесплатные Си-библиотеки, позволя-
ющие разрабатывать ПО, совместимое с протоколом SOCKS.
В табл. 5.3 представлены некоторые бесплатные SOCKS-
клиенты, а в табл. 5.4 приведены сведения о поддерживаемых плат-
формах одной из самых распространенных реализаций протокола
компании NEC (распространяется бесплатно).
Таблица 5.3. Свободно распространяемые SOCKS-клиенты
Продукт ОС Интернет
Hummingbird; SOCKS Client Windows 9x, NT 4.0 http ://www. hummingbird, com/
NEC SocksCap Windows 3.x, 9x, NT 4.0, Windows 2000 http ://www. socks, nec. com/
NEC runsocks См. табл. 5.4 http://www.socks.nec.com/
Таблица 5.4. Поддерживаемые SOCKS-клиентом компании NEC
os SOCKS v5 server Static library Bundled clients Dynamic client
AIX4.1.4.2 + + + —
BSDi 3.* + + + —
BSDi 4.* + + + —
FreeBSD 2.* + + + runsocks
HPUX 10.* + + + —
HPUX 11.* 4- + + —
112
Окончание табл. 5.4
OS SOCKS v5 server Static library Bundled clients Dynamic client
Irix 5.* + + + runsocks
Irix 6.3 + + + runsocks
Irix 6.5 + + + runsocks
Linux 1 .* + + + runsocks
Linux 2.* + + + runsocks
OSF 3.* + + + runsocks
OSF 4.* + + + runsocks
Solaris 2.* + + + runsocks
SunOS 4.1.* + + + runsocks
* Все версии данной серии.
Один из основных недостатков SOCRS, ограничивающих его
распространение, заключается в необходимости поддержки прило-
жением клиентской библиотеки. Тем не менее, возможность аутен-
тификации UDP- и TCP-приложений, которая также возможна толь-
ко в прикладных посредниках и МЭ экспертного уровня, делает
продукты на основе SOCKS весьма привлекательными для орга-
низаций с небольшим бюджетом.
5.13. Разделяемые сетевые соединения
Проблема одновременного использования одного физического
подключения к Интернет (dial-up, ISDN, DSL) привела к появле-
нию отдельного класса ПО и аппаратных разработок - Sharing
connection, предназначенных для разделения одного соединения
между несколькими пользователями Некоторые представители
продуктов этого класса представлены в табл. 5.5.
И хотя основное назначение подобных программ - разделение
соединения, - их также можно отнести и к классу межсетевых
экранов. К основным отличиям продуктов разделения соединения
от МЭ можно отнести:
• функционирование на прикладном уровне API ОС (в случае
программной реализации);
• ограниченное количество поддерживаемых прикладных по-
средников;
• отсутствие или слабая реализация механизма аутентифика-
ции пользователей;
ИЗ
Рис. 5.20. Intel Internet Station 56K
Таблица 5.5. Продукты подключения рабочих групп к сети Интернет
Продукт Тип реализации Производитель Интернет
WinRoute по TINY Software www.tinysoftware.com
WinGate по Deerfield Communication wingate.deerfield.com
WinProxy по OSITIS www.winproxy.com
Internet Sharing Hub CN904 Аппаратный Cnet www.cnet.com
Internet Station Аппаратный Intel www.intel.com
Prestige 100WH Аппаратный ZyXEL www.zyxel.com
• относительно невысокая цена;
• относительная простота и удобство эксплуатации.
Несмотря на то, что эти продукты выделены в отдельный класс,
технически разделение соединения основывается на технологии
трансляции адресов и в большинстве случаев реализуется только
динамическая NAT. Аппаратные устройства содержат встроенные
модем и один или несколько портов Ethernet, что позволяет очень
быстро организовать доступ пользователей локальной сети к Ин-
тернет (рис. 5.20). Наличие последовательных портов позволяет
использовать внешние модемы.
Практически все современные ОС имеют встроенные сред-
ства подключения пользователей к Интернет через имеющееся
соединение с одним зарегистрированным IP-адресом. Если в ОС
линии UNIX такая возможность существует уже давно (при помо-
щи NAT), то в линии MS Windows такая возможность появилась
только в версии Windows 2000.
114
6. УЯЗВИМОСТИ
ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ
МЕЖСЕТЕВЫХ ЭКРАНОВ
Межсетевые экраны предназначены для защиты сетей от внешних
угроз, решения задач управления доступом к внутренним и внешним
сетевым ресурсам путем контроля потоков данных между этими
сетями. Имея те же, с точки зрения сетевого взаимодействия
характеристики, МЭ выступает для внешнего наблюдателя как
обычный IP-хост. Конечно, МЭ может быть «черным ящиком» (не
иметь IP-адреса и открытых транспортных портов, не откликаться на
ICMP-запросы), но и в этом случае МЭ продолжает обрабатывать
IP-трафик.
Недостатки в реализации IP-стека, сложность программного
обеспечения как с точки зрения разработки, так и управления им, а
также ошибки администрирования обуславливают уязвимости МЭ.
6.1. Идентификация и вскрытие
политики безопасности МЭ
На рис. 6.1 представлена обобщенная схема действий сетево-
го злоумышленника, описывающая порядок его действий в боль-
шинстве случаев. В любом случае атакующий должен выполнять
ряд действий по сбору информации об атакуемой системе. На ос-
нове полученной информации строится дальнейший план действий.
Причем на этапе сбора информации злоумышленник не выполняет
каких-либо разрушительных или противоправных действий. Пер-
вичные данные об интересующей системе могут быть получены
из следующих открытых источников:
• система DNS - организационная структура предприятия, со-
ответствие IP-адресов и доменных имен, почтовые серверы. Как
правило, внутренняя структура доменных имен локальной сети ото-
бражает организационную структуру предприятия;
115
Рис. 6.1. Обобщенная схема действий злоумышленника
• БД Whois регистрационных центров RIPE, RIPN, APNIC и др.
В их реестрах содержится вся учетная информация владельцев
инфраструктуры сети Интернет - организации, почтовые и элект-
ронные адреса, персоны, осуществляющие техническую поддерж-
ку и многое другое;
• сайты организаций - электронные адреса, комментарии кода
web-страниц могут содержать отладочную информацию (пароли
доступа к БД, имена разработчиков и др.)
Определив объект атаки и используя активные методы сбора
информации, злоумышленник попытается выяснить - находится ли
на его пути МЭ. Объектом воздействия может выступать и МЭ.
Как злоумышленник может идентифицировать МЭ, т. е. опреде-
лить его название, производителя и версию? Поскольку МЭ функ-
116
ционирует по правилам IP-протокола и может иметь прикладные
службы-посредники, то и идентифицировать его можно теми же
хорошо известными способами, что и обычный 1Р-хост:
• по открытым по умолчанию (или специфическим) для данно-
го МЭ транспортным портам;
• по отпечатку сетевого стека;
• посредством анализа банеров прикладных служб.
Идентификация МЭ
по открытым транспортным портам
Как правило, каждому открытому транспортному порту соот-
ветствует некоторая служба. Например, 25 - SMTP, 110 - POP3,
80 - WWW. Жесткое соответствие служб численным номерам
портов позволяет клиентским приложением соединяться по задан-
ному адресу с соответствующей службой на сервере. Зная, какие
порты открыты на некотором IP-хосте, можно определить, какие
службы на этом хосте активны, а в некоторых случаях определить
и ОС. Для линии ОС Windows, например, характерно наличие служ-
бы NetBIOS, а для ОС линии UNIX - SUNRPC, NFS.
МЭ также может иметь специфические порты. Во-первых, это
порты (по умолчанию) служб его удаленного управления и адми-
нистрирования. Большинство МЭ имеют собственные номера пор-
тов удаленного управления, которые администратор может в даль-
нейшем изменить. Так, МЭ Fire Wall-1 компании Check Point
использует для этого порт 258, Raptor компании Axent - 418,
WinRoute компании TINY Software - 44333. Во-вторых, некоторые
МЭ используют собственные протоколы и схемь!, обеспечиваю-
щие их функциональность. Например, Microsoft Proxy Server ис-
пользует порт 1745 для канала управления с клиентами службы
WinSocks. И в третьих, существует, по крайней мере, одна служба,
которая может быть запущена только на МЭ. Это посредник
SOCKS, порт 1080.
Таким образом, зная транспортные порты по умолчанию всех
МЭ (удаленного управления, SOCKS, служебные), можно с неко-
торой долей вероятности идентифицировать МЭ. Инструментом
идентификации в этом случае служит сканер портов. Например,
для поиска Microsoft Proxy Server с помощью сканера шпар нужно
выполнить команду
nmap —n —w -Р0 -р256,1080,1745 192.168.0.1-0.254.
Здесь Р0 - не выполнять «ping» для определения наличия хоста,
поскольку МЭ может блокировать ICMP-запросы; w - выводить
117
подробности выполнения операций сканирования; п - не выпол-
нять привязку к доменным именам.
Сканирование портов - «шумная» технология, но целенаправ-
ленный поиск «целей», как в приведенном выше примере - с ис-
пользованием дополнительных мер, направленных на сокрытие
самого процесса сканирования и IP-адреса сканирующего хоста -
позволяют активно использовать эту технологию злоумышлен-
никами.
Защита
Блокируйте (выключите) не используемые посредники приклад-
ного уровня. Если нет необходимости управления МЭ со стороны
Интернет, то необходимо настроить МЭ таким образом, чтобы
управление осуществлялось только со стороны локальной сети. Если
МЭ не предусматривает такой возможности, то нужно заблокиро-
вать порты управления на внешнем интерфейсе. Когда все-таки
существует необходимость управления со стороны открытой сети,
нужно переопределить номера портов управления.
Если используемый вами МЭ не поддерживает функции обна-
ружения сканирования портов, то имеет смысл рассмотреть воп-
рос об использовании систем обнаружения вторжений, например,
RealSecure компании ISS.
Идентификация МЭ
по отпечатку сетевого стека
Этот метод основан на том, что производители сетевых стеков
ОС, маршрутизаторов и других сетевых устройств реализовали IP-
стек не одинаково. Так, основной документ, описывающий прото-
кол TCP - RFC793, - не определяет жестких требований на неко-
торые условия, поля и фазы состояния TCP, чем и обуславливаются
различные варианты реализации протокола. В некоторых случаях
производители вообще игнорируют требования отдельных положе-
ний стандартов.
Метод идентификации ОС по отпечатку сетевого стека срав-
нивает результаты тестовых воздействий исследуемого хоста с эта-
лонной БД, содержащей все известные «отпечатки» сетевых сте-
ков.
Сетевой сканер безопасности Nmap версии 2.12 идентифици-
рует этим методом более 200 сетевых стеков, в том числе стеки
следующих МЭ:
118
• Cisco Pix firewall running PIX 4.1(5);
• Cyberguard 4.0 firewall;
• Raptor firewall 5.03 on NT 4;
• Sonic Wall/10 Firewall.
Если программный МЭ работает на базе сетевого стека ОС,
как это делают прикладные посредники или SOCKS-посредник, то
этот метод позволит определить ОС, под управлением которой ра-
ботает МЭ.
Защита
Метод срабатывает лишь в том случае, если на исследуемом
хосте имеется хотя бы один открытый и хотя бы один закрытый
порты. Поэтому МЭ, не имеющий открытых портов, идентифици-
рован не будет.
Анализ банеров прикладных служб
Информационные сообщения прикладных посредников могут со-
держать полное название МЭ, как показано на рис. 6.2. Название,
версия МЭ и ОС могут указываться в банерах протоколов FTP,
TELNET, SMTP, HTTP, IMAP, POP3 и др. Это наиболее простой и
быстрый способ идентификации не только МЭ, но и любых систем
с действующими прикладными сервисами.
+ОК WinRoute Pro 4.1 POP3 server ready <4293374165.9694
46369@unspecified.host>
220 unspecified.host ESMTP - WinRoute Pro 4.1
Рис. 6.2. Банеры сервисов POP3 и SMTP МЭ WinRoute Pro 4.1
Ранее, когда работа с удаленными системами выполнялось
только в терминальном режиме, банеры использовались как часть
элемента взаимодействия с пользователями. В настоящее время
работа с сервисами в терминальном режиме, за исключением, по-
жалуй, TELNET, практически не используется, поскольку большин-
ство клиентских приложений используют графический интерфейс.
Защита
МЭ формируют информационную строку банера путем комби-
нации следующих параметров: <текущие дата и время>, «^домен-
ное имя хоста>, <название сервиса>, <имя МЭ>. Прежде всего
119
не используйте в имени МЭ таких названий, как checkpoint-fw,
fw-gw, firewall, security-gw, sec и подобных, поскольку они
если и не указывают непосредственно на тип МЭ, то позволяют
предположить назначение хоста.
Большинство МЭ позволяют заменять информационные сооб-
щения, заголовки протоколов и приглашения на вход в систему.
Рекомендуется использовать «обманные» сообщения. Например,
изменять название ОС - Unix системы, представлять как NT и,
наоборот, изменять название прикладных посредников на имена ана-
логичных сервисов. В этом случае злоумышленник будет направ-
лен на ложный путь, поскольку он попытается применять уязвимо-
сти для тех сервисов, ОС и МЭ, которые увидит в банерах.
В некоторых МЭ банеры можно отключить, если соответству-
ющие посредники использовать только в прозрачном режиме
(transparent proxy).
Трассировка маршрута
Трассировка маршрута позволяет обнаруживать МЭ и прово-
дить анализ политики безопасности пакетных фильтров. Он заклю-
чается в исследовании результатов трассировки маршрута, выпол-
няемой программами traceroute в UNIX или tracert.exe в
Windows.
Техника трассировки заключается в следующем. К хосту, мар-
шрут к которому нужно определить, отправляются UDP-пакеты с
последовательно увеличиваемым значением временем жизни TTL.
Согласно требованиям протокола IP, каждый маршрутизатор дол-
жен уменьшать на единицу значение поля TTL. Когда TTL умень-
шается до нуля, маршрутизатор отбрасывает пакет и отправляет
ICMP-сообщение ttl expired. Это сообщение регистрируется про-
граммой трассировки как IP-адрес маршрутизатора на пути сле-
дования сетевых пакетов к целевому хосту. Программы трасси-
ровки отправляют UDP-Пакеты (ИЛИ ICMP пакеты Echo Request),
начиная с TTL=1, последовательно увеличивая это значение на
единицу. В качестве тестовых можно использовать и 1СМР-паке-
ты.
Программа tracert. ехе в Windows использует исключительно
пакеты ICMP, a traceroute - в UNIX по умолчанию использует
пакеты UDP и с ключом -I — ICMP. Реализация программы в ОС
семейства UNIX предоставляет значительно больше возможнос-
тей при проведении исследований сетей, поэтому далее будем рас-
сматривать UNIX-версию программы.
120
darkstar:-# traceroute www.usa.net
traceroute to www.usa.net (165.212.22.100), 30 hops max,
40 byte packets
10 so-0-0-0.IR2.NYC9.ALTER.NET (152.63.23.65) 426.14 ms
419.116 ms 309.147 ms
11 119.at-5-0-0.TR2.NYC9.ALTER.NET (152.63.1.202)
526.055 ms 299.063 ms 329.168 ms
12 0.so-4-0-0.TR2.NYC9.ALTER.NET(152.63.15.182)326.11 ms
429.113 ms 329.119 ms
13 180.ATM4-0.BR2.NYC9.ALTER.NET (152.63.22.221) 306.046
ms 299.006 ms 429.018 ms
14 137.39.52.10 (137.39.52.10) 755.921 ms 759.027 ms
659.274 ms
15 so-4-l-0.mpl.NewYorkl.level3.net (209.247.10.37)
705.846 ms 758.938 ms 759.096 ms
16 loopbackO.hsipaccessl.Denverl.Level3.net
(209.244.2.114) 776.029 ms 769.27 ms 758.76 ms
17 209.245.16.38 (209.245.16.38) 766.218 ms 768.978 ms
769.285 ms
18 * * *
19 usa.net (165.212.22.100) 416.114 ms 439.151 ms
429.039 ms
Рис. 6.3. Листинг трассировки хоста www.usa.net
Некоторые МЭ могут быть настроены так, чтобы не выдавать
ICMP-сообщений ttl expired для входящих ICMP и UDP паке-
тов. В этом случае можно получить картину трассировки хоста,
показанную на рис. 6.3. Маршрут сетевых пакетов к узлу
www.usa.net проходит через восемнадцать маршрутизаторов. Как
видно на рис. 6.3, на восемнадцатом «скачке» (для трех пакетов с
установленным значением TTL =18) пакеты «теряются». Факт
«потери» пакетов позволяет сделать предположение о наличии на
пути к целевому хосту пакетного фильтра.
По умолчанию, traceroute отправляет UDP-пакеты с произ-
вольным транспортным портом отправителя и последовательно
увеличиваемым портом назначения, начиная со значения 33435. Для
того чтобы МЭ отвечал на пакеты traceroute, в его ПБ должно
быть определено соответствующее правило. Например, в МЭ
Checkpoint Fire Wall-1 этот сервис описывается следующим обра-
зом:
udp, uh_dport > 33000, ip_ttl <30
Это означает, что если traceroute использует отличные от
указанного диапазона порты UDP или на МЭ отсутствует соот-
ветствующее правило, то пакеты не будут пропущены МЭ.
Тем не менее в ряде случаев с помощью trace route возможно
не только обнаружить присутствие МЭ, но и частично вскрыть его
121
политику безопасности. Предположим, МЭ пропускает пакеты,
разрешенные политикой безопасности. Тогда для разрешенных па-
кетов, уже попавших в защищаемую сеть и имеющих установлен-
ное значение TTL = 1, должны генерироваться ICMP-сообщения
TTL expired. Получение таких пакетов будет свидетельствовать
об открытии соответствующего порта.
Для того чтобы проверить с помощью traceroute, открыт ли
интересуемый порт на МЭ, можно воспользоваться следующей
формулой:
(target_port -(number_of_hops * num_of_probes)) - 1,
где target_port — исследуемый порт назначения; number_of_hops
- количество «прыжков»; num_of_probes - количество тестовых
пакетов для каждого значения TTL.
Если МЭ пропустит в защищаемую сеть пакет с текущим зна-
чением TTL = 1, то следующий IP-хост на пути следования паке-
тов должен отправить ICMP-сообщение TTL expired (маршрути-
затор локальной сети) или port unreachable (хост назначения).
Рассмотрим пример. Допустим, что перед исследуемым хос-
том и после маршрутизатора с IP-адресом 209.245.16.38 находит-
ся МЭ или фильтрующий маршрутизатор. Определим правило для
протокола DNS (UDP, порт 53), реализуемое «виртуальным» МЭ.
По формуле (6.1) получаем
53 - (17*3) - 1=1.
Командная строка traceroute -pl www.usa.net (рис. 6.4) оп-
ределяет программе traceroute использовать начальный порт на-
значения равным 1. Тогда при достижении исследуемого хоста па-
кет будет иметь значение TTL = 1. Анализ полученных результатов
позволяет сделать следующие выводы:
• политика безопасности исследуемого МЭ разрешает прохож-
дение UDP-пакетов с портом назначения 53 (возможно, это прави-
ло реализует политику относительно протокола DNS);
• обнаружен новый маршрутизатор с адресом 165.212.15.216;
• поскольку ICMP-отклик от целевого хоста не получен, то воз-
можно, для поддержки приложений типа traceroute МЭ реализу-
ются специальные правила.
Необходимо сделать два важных замечания, сужающих прак-
тические условия использования рассматриваемого метода вскры-
тия реализуемой МЭПБ
122
darkstar:-# traceroute -pl www.usa.net
traceroute to www.usa.net (165.212.22.100), 30 hops max, 40 byte
packets
10 so-0-0-0.IR2.NYC9.ALTER.NET (152.63.23.65) 329.898 ms
299.822 ms 299.961 ms
11 119.at-5-0-0.TR2.NYC9.ALTER.NET (152.63.1.202) 309.896ms
309.821 ms 309.912 ms
12 0.so-4-0-0.TR2.NYC9.ALTER.NET (152.63.15.182) 289.988ms
339.794 ms 330.019 ms
13 180.ATM4-0.BR2.NYC9.ALTER.NET (152.63.22.221) 429.812ms
309.7 ms 439.912 ms
14 137.39.52.10 (137.39.52.10) 759.895 ms 689.719 ms 769.915 ms
15 so-4-l-0.mpl.NewYorkl.level3.net (209.247.10.37) 699.877 ms
770.006 ms 759.871 ms
16 loopbackO.hsipaccessl.Denverl.Level3.net (209.244.2.114)
789.714 ms 789.78 ms 759.932 ms
17 209.245.16.38 (209.245.16.38) 769.854 ms 769.789 ms
789.909 ms
18 * * *
19 165.212.15.216 (165.212.15.216) 590.077 ms 429.914 ms
439.858 ms
20 * * *
30 * * *
Рис. 6.4. Листинг трассировки хоста www.usa.net
с начальным значением порта UDP 1
1. Метод основан на том, что МЭ пропустит сетевой пакет в
защищаемую сеть при условии что исследуемый порт открыт, что
возможно в следующих случаях:
• МЭ не является инспектором состояний (инспектор отслежи-
вает принадлежность пакета к уже установленному соединению);
• целевой хост существует и активен;
• не используется NAT.
2. МЭ должен «выпускать» ICMP-сообщения (ttl expired, port
unrechabie) из локальной сети, на основе которых принимается
решение о состоянии политики безопасности для исследуемого порта.
Защита
Как показано выше, метод трассировки маршрута требует до-
статочно много условий для успешного применения. Таким обра-
зом, наличие МЭ с поддержкой технологии инспекции соединений,
а также жесткая политика безопасности обеспечат защиту от при-
менения данного метода.
123
6.2. Ошибки администрирования
Установка МЭ, его первичная настройка, установка пакетов
исправлений и дополнений МЭ и ОС (patches, software updates) и,
конечно, редактирование ПБ - неотъемлемые этапы жизненного
цикла МЭ. И на любом из этих этапов некорректные действия ад-
министратора МЭ могут создать условия нарушения ИБ.
Компетентности администратора должно уделяться особое вни-
мание. Все усилия и немалые денежные затраты на обеспечение
безопасности могут быть перечеркнуты одним неверным действием.
Редактирование политики безопасности - одна из самых важ-
ных операций. Администратор должен четко представлять, что
реализует каждое правило политики безопасности. Часто админи-
страторы используют шаблоны политик, приведенные в примерах
документации или поставляемые вместе с МЭ. Лучше не исполь-
зовать правила, если нет уверенности в том, что они реализуются.
Обратите внимание на то, какую политику по умолчанию реализу-
ет ваш МЭ - «все запретить» или «все разрешить».
Наряду с этим существует проблема «абсурдных» правил. Что
произойдет, если используются взаимно исключающие правила,
например,
Block all # 1 строка
Pass all # 24 строка
Однозначного ответа в данном случае быть не может. Все за-
висит от конкретного МЭ. Для некоторых МЭ приведенный при-
мер может быть и вполне нормальным случаем, а некоторые об-
наружат взаимоисключающие правила на этапе анализа файла
конфигурации.
Защита
Приведем несколько рекомендаций, позволяющих если не ис-
ключить, то свести к минимуму ошибки администратора:
• с самого первого шага - этапа подготовки ОС к установке
МЭ - следуйте инструкциям, изложенным в документации на МЭ.
Знание технической документации используемого изделия являет-
ся необходимым требованием эксплуатации МЭ;
• большинство производителей предлагает перед установкой са-
мого МЭ заполнить специально подготовленную карту с указани-
ем всех необходимых начальных данных - IP-адреса сетевых ин-
терфейсов и их маски, IP-адреса шлюза по умолчанию, почтового
124
сервера, серверов DNS и др. Заполнение этой карты позволит не
только подготовить МЭ к первому запуску, но и иметь в дальней-
шем паспорт начальной конфигурации;
• не подвергайтесь соблазну установки очередных пакетов ис-
правлений ОС. Пакеты исправлений часто содержат исправления
к прикладному и служебному ПО, никак не влияющему на защит-
ные функции МЭ. Если такая необходимость действительно воз-
никла, используйте выборочные пакеты (в терминах Microsoft -
fix);
• при установке пакетов исправлений и обновлений выполняйте
резервное копирование всей системы в целом или только ее крити-
ческих файлов. Это поможет выполнить «откат» в случае, если
установленные пакеты вызовут проблемы в работе ОС или МЭ;
• внимательно относитесь к установке на один компьютер с
МЭ прикладных серверов. Прикладные посредники и ПО приклад-
ных серверов могут конфликтовать между собой, например, по при-
чине одних и тех же используемых транспортных портов.
6.3. Отказ в обслуживании
Под атаками типа «Отказ в обслуживании» (DoS - denial of
service) понимают такое воздействие на ресурсы (сетевые и ло-
кальные), которое приводит к снижению производительности или
блокировке доступа к ресурсу. Выделяют две основные причины
возможности DoS-атак - захват ресурсов (оперативная память,
дисковое пространство, полоса пропускания канала связи) и ошиб-
ки разработки. Причем, если для реализации атак, направленных на
захват ресурсов, требуется выполнение большого количества опе-
раций, то для атак, основанных на ошибках программного обеспе-
чения, часто достаточно отправки единственного сетевого пакета
или некорректно сформированной команды прикладного протоко-
ла. К наиболее известным атакам отказа в обслуживании можно
отнести: WinOOB, SYN-Flood, ICMP Flood (Ping Flooding), Ping of
Death, TearDrop, Chaigen Attack, Land, Land UDP, TrinOO, Stacheldraht.
Большинство известных атак отказа в обслуживании возмож-
ны из-за ошибок реализации различных модулей как МЭ так и се-
тевого стека ОС. Защитные механизмы современных МЭ от наи-
более распространенных DoS-атак закладывают еще на стадии
проектирования.
Атаки отказа в обслуживании, особенно распределенные DoS-
атаки, достаточно сложно предотвратить. МЭ являются основным
средством защиты от сетевых DoS-атак. Они позволяют блокиро-
125
вать некоторые типы атак отказа в обслуживании с использовани-
ем следующих механизмов:
• пакетная фильтрация. При разработке соответствующих пра-
вил ПФ блокируют некоторые типы spoofing-атак и атак, использу-
ющих некорректно сформированные пакеты;
• инспекция состояний. Инспекторы состояний блокируют не-
корректно сформированные сетевые пакеты, а также пакеты, не
принадлежащие ранее установленным соединениям. Инспекторы
состояний без дополнительных мер не могут блокировать такую
распространенную атаку, как SYN-flooding, поскольку пакеты с ус-
тановленным флагом SYN инициализируют соединение;
• прикладные посредники. Они контролируют корректность ко-
манд и корректность параметров команд, блокируют DoS-атаки,
направленные на прикладные сервисы;
• механизмы ограничений позволяют определять такие пара-
метры, как максимальное количество установленных соединений
в единицу времени, максимальное время отсутствия активности в
TCP-соединениях, что позволяет блокировать flooding-атаки.
DoS-атаки могут быть направлены как на сам МЭ, так и на
защищаемые им сетевые ресурсы. К сожалению, МЭ, как и дру-
гим продуктам, присущи ошибки, заложенные на различных эта-
пах разработки. Известно достаточно много выявленных уязви-
мостей МЭ, из-за которых могут быть применены атаки отказа в
обслуживании. Успешно реализованная DoS-атака на МЭ приво-
дит к отказу в обслуживании всех ресурсов защищаемой сети, в
том числе и ее пользователей. Поэтому несмотря на то, что МЭ
сам является средством защиты периметра сети, необходимо пред-
принимать меры по его защите от различных атак, в том числе
атак отказа в обслуживании. Рассмотрим более подробно возмож-
ные уязвимости МЭ, в том числе и к атакам отказа в обслуживании.
6.4. Уязвимости пакетных фильтров
Пакетные фильтры являются самым распространенным типом
МЭ. Как было показано выше, ПФ фильтры не в состоянии решить
все аспекты защиты сетей (ограниченная возможность аутенти-
фикации, отсутствие возможностей контекстной проверки и конт-
роля прикладных протоколов). Однако простота реализации, высо-
кая производительность и доступность часто определяют их
использование.
Один из недостатков ПФ заключается в сложности определе-
ния правил политики безопасности. При этом имеют место следу-
ющие проблемы.
126
Слабость политики безопасности
Слабость политики безопасности не является недостатком па-
кетных фильтров. Но поскольку ПФ являются неотъемлемой час-
тью большинства МЭ, слабость реализуемой ПБ может стать при-
чиной нарушения ИБ.
Можно привести следующий распространенный пример реали-
зации пакетным фильтром слабой ПБ. Поскольку порты основных
служб имеют значение менее 1024, то администраторы часто зап-
рещают доступ извне только к этому диапазону портов. В этом
диапазоне располагаются потенциально опасные с точки зрения
безопасности службы (FTP, TELNET, NBT, RPC и др.) и клиентс-
кие приложения используют порты источника, начиная с 1024. Но
необходимо учитывать, что в диапазоне выше 1024 располагают-
ся такие сетевые приложения, например, как системы управления
БД (практически все без исключения)! Кроме этого, ничто не ме-
шает использовать пользователям сети другие номера портов (N
порта + 1000), например, для организации доступа к персонально-
му Web-серверу своим друзьям.
Другим часто встречающимся примером может быть следую-
щее правило:
allow from any to DNS_Server
которое разрешает доступ к серверу DNS, в том числе и по прото-
колу TCP, что обеспечивает, разрешает выполнение так называе-
мых зонных пересылок. Исследование зоны DNS часто использу-
ется злоумышленниками на этапе исследования сети. Поэтому для
исключения такой возможности необходимо использовать следую-
щие правила:
allow from any to DNS_Server proto udp
allow from DNS_ISP to DNS_Server proto top
# DNS_ISP - DNS server ISP.
Особенности функционирования
прикладных протоколов
Ряд прикладных протоколов имеют особенности функциони-
рования, которые могут привести к сложностям настройки ПФ.
Например протокол FTP использует два TCP-канала, причем в
обычном режиме транспортный порт канала данных открывается
на клиенте.
127
Программные ПФ для поддержки «сложных» протоколов ис-
пользуют специальные модули. Для большинства бесплатных ПФ
на платформе UNIX эти модули подключаются на этапе компиля-
ции продукта.
Если же ПФ не поддерживают «сложных» протоколов, то ад-
министраторам приходится делать сложный выбор - или отказаться
от использования сервисов, или применять более «широкие» правила.
Сложность политики безопасности
Отсутствие возможности поддержки пакетными фильтрами
групп IP-адресов и групп сервисов или неиспользование админист-
ратором такой возможности приводит к разрастанию файла конфи-
гурации. Эта проблема характерна в большой сети, когда, исходя
из решаемых задач, разным группам пользователей разрешены
различные права доступа к сетевым сервисам. Большой файл зна-
чительно затрудняет анализ конфигурации, что может привести к
серьезным ошибкам при выполнении настройки МЭ.
К сожалению, имеют место случаи, когда по причине сложнос-
ти файла конфигурации администраторы в последующем игнори-
руют ПБ организации и применяют менее жесткие правила, тем
самым нарушая ее. Безусловно, администратор МЭ должен обла-
дать определенной культурой формирования правил ПБ.
При этом некорректно настроенный ПФ может привести к сле-
дующим проблемам информационной безопасности.
Наличие скрытых «каналов»
Скрытые «каналы» образуются вследствие некорректной на-
стройки параметров МЭ или его политики безопасности. Напри-
мер, в некоторых реализациях очень важна последовательность
правил, неверная последовательность которых может привести к
неожиданным результатам. Наличие скрытых «каналов» позволя-
ет не только осуществлять действия злоумышленникам, но и вы-
полнять несанкционированные действия самим пользователям за-
щищенной сети. Если правила, образующие скрытые «каналы», не
предусматривают протоколирование событий, то обнаружить их
активность не представляется возможным.
Исследуя сеть, злоумышленники выявляют скрытые «каналы»,
чтобы впоследствии использовать их для доступа к защищаемым
сетевым ресурсам.
128
Плацдарм для функционирования
распределенных DoS-агентов
Под DoS-агентами понимаются троянские программы, реали-
зующие функции отказ в обслуживании и управляемые удаленно с
единого центра управления. Центр управления знает адрес каждо-
го DoS-агента и при начале воздействия на атакуемый хост пере-
дает им адрес жертвы и время начала атаки.
Администраторы МЭ часто не ставят ограничения на 1Р-адре-
са источников сетевых пакетов. Это может привести к использо-
ванию защищенной сети в качестве плацдарма для функциони-
рования различных распределенных DoS-средств, поэтому
необходимо запрещать исходящие пакеты с IP-адресами источ-
ника отличного от адресов, используемых в локальной сети. Кро-
ме того, эти меры предотвратят использование DoS-средств и са-
мими пользователями сети.
6.5. Уязвимости прикладных посредников
Одной из основных функций прикладных посредников является
усиление безопасности сетевых соединений за счет возможности
контроля данных команд на прикладном уровне. Поскольку каждый
сервис-посредник является уникальным для каждого прикладного
протокола, то и возможные уязвимости информационной безопас-
ности также будут характерны только для конкретных реализаций
посредников. Тем не менее можно выделить уязвимости в той или
иной степени, характерные для всех прикладных посредников.
Идентификация прикладных посредников
Как было показано выше, если администратором безопаснос-
ти не принято специальных мер, то для злоумышленника не соста-
вит особых трудностей идентифицировать тип МЭ а иногда и вер-
сию ОС путем анализа банеров прикладных служб. По этой причине
прикладные посредники наиболее просто поддаются удаленной
идентификации. Практически все МЭ позволяют заменять банеры
или приглашения для входа в систему (например, FTP и TELNET).
DoS-атаки
Прикладные посредники выполняют большое количество опе-
раций и являются самыми низкопроизводительными МЭ. Поэтому
они наиболее подвержены некоторым видам типовых атак типа
5 Лебедь С.В.
129
отказа в обслуживании. Поскольку в обособленном виде приклад-
ные посредники используются редко, то защита от DoS-атак ло-
жится на другие модули МЭ, в состав которых входят прикладные
посредники.
Причиной отказа в обслуживании могут быть не только атаки,
использующие механизмы увеличения нагрузки, но и ошибки реа-
лизации самого посредника.
Некорректный или ограниченный набор контролируемых
параметров и команд прикладных протоколов
Наиболее часто встречаемая ошибка реализации посредников
заключается в некорректном или ограниченном контроле набора
параметров и команд прикладных протоколов. Это объясняется тем,
что реализация прикладных посредников намного сложнее соот-
ветствующих прикладных серверов, поскольку кроме полной под-
держки функциональности протоколов, посредник должен уделять
повышенное внимание вопросам безопасности, таким как усилен-
ная аутентификация, контроль корректности и размеров команд и
параметров, протоколирование, сигнализация и др.
Отсутствие ограничений доступа
В небольших сетях работа сотрудников в Интернете часто обес-
печивается использованием отдельных прикладных посредников
либо посредников, входящих в состав некоторого МЭ. При этом в
явном виде пакетная фильтрация и трансляция адресов не исполь-
зуются, поскольку, во-первых, прикладные посредники используют
режим разделения соединения, и во-вторых, использование других
служб не требуется.
Рассмотрим следующий пример (рис. 6.5). Для решения своих
задач организация использует для доступа в сеть Интернет только
службу HTTP и имеет один маршрутизируемый IP-адрес (не важ-
но - динамический или статический). Функционирование HTTP
обеспечивается соответствующим посредником (прокси-сервером).
В локальной сети (с приватными IP-адресами) используется
сервер БД с доступом по протоколу HTTP. Пусть внутренний ин-
терфейс прокси-сервера имеет адрес 10.0.0.1. В параметрах на-
стройки клиентских Интернет-браузеров необходимо указать ад-
рес и транспортный порт посредника (рис. 6.6). Описанная
конфигурация соответствует конфигурации большинства устанав-
ливаемых по умолчанию посредников, используемых, в первую
130
Рис. 6.5. Пример использования уязвимости НТТР-посредника:
1,2- информационные потоки
очередь, для разделения соединения. Главная причина уязвимости
такой конфигурации состоит в ее симметричности относительно
интерфейсов посредника, что позволяет воспользоваться услуга-
ми посредника как пользователям локальной сети, так и любому
пользователю сети Интернет.
Возможны следующие схемы использования злоумышленни-
ками некорректностей конфигурации прокси-серверов.
1. Анонимизация доступа к различным серверам Интернета. В
этом случае основная цель злоумышленника состоит в получении
IP-адреса внешнего интерфейса посредника. Чужой IP-адрес мо-
жет быть использован в самых различных целях, например, для
сокрытия следов присутствия при выполнении противоправных
действий, прохождения систем авторизации, проверяющих по ре-
гистрационным реестрам (RIPN, RIPE, APNIC) принадлежность
IP-адресов или доменных имен.
' -Прокси-сере^";",;.' 1 ............——•—— ------------—;---------
110 0.0.1 'Оорт: 13128 : Дополнительно...|
, Г* Ндиспольао^тъпроксичероер для лок^тьньк адресов!
Рис. 6.6. Настройка посредника HTTP в Internet Explorer
5*
131
Последствия при использовании этой схемы заключаются в
компрометации организации перед системами, к которым осуще-
ствлялся доступ, а также в увеличении суммарного объема тра-
фика, что, в свою очередь, приводит к возрастанию стоимости ис-
пользования Интернет.
2. Доступ в локальную сеть. Поскольку посредник «знает» мар-
шруты доступа к хостам локальной сети, то возможно подключе-
ние из внешней сети к внутренним серверам, даже если они имеют
немаршрутизируемые (приватные) IP-адреса. Для этого злоумыш-
леннику необходимо знать адресное пространство локальной сети
(например, методом анализа заголовков сообщений электронной
почты и новостей) и последовательно попытаться осуществить
соединение с каждым хостом. Таким образом, в рассмотренном
примере может быть осуществлен несанкционированный доступ к
Web-серверу локальной сети.
Описываемая уязвимость характерна для таких прикладных
посредников, как TELNET, SMTP, HTTP, SOCKS. Защититься от
несанкционированного использования вашего прокси-сервера до-
статочно просто - необходимо или использовать авторизацию досту-
па, или запретить доступ с IP-адресов, отличных от используемых
в локальной сети. В МЭ экспертного уровня несанкционированное
использование посредников может произойти только по причине
некорректной настройки МЭ администратором, поскольку по умол-
чанию используется политика «все запрещено», а интерфейс уп-
равления способствует минимизации ошибок.
6.6. Уязвимость «адаптивно-управляемых» МЭ
Некоторые коммерческие МЭ экспертного класса имеют воз-
можность создания динамических правил по сигналу сетевых сен-
соров IDS. Такая функциональная возможность позволяет автома-
тически в реальном времени блокировать источники сетевых атак.
Один из сетевых сенсоров системы IDS, расположенный перед МЭ,
прослушивает весь сетевой трафик и при обнаружении вторжений
(сетевых атак) передает соответствующие сообщения на консоль
IDS. Это же сообщение может быть передано и МЭ. В зависимо-
сти от конфигурации МЭ может блокировать источник атаки, зак-
рыть все текущие соединения с источником атаки или уведомить
администратора о произошедшем событии (рис. 6.7).
132
Sensor Responses ЙВП
> focafonl
$ EMAIL
О lmf
~^na
Ш LockDestAddi
-Ш LockSendce
jg LockSfcAddr
LockSrcOrDeslAddr
ф RSKJLL
•1 SNMP
R| USER SPECIFIED
<~ ShotlotuHoAM
. r shwtbw.***': \
<~ Long Loa: NoMet
' /-
' -C~ ыиив^до»
FWalWc*...*
<*AI
C (Safeway»
>0ta '
тгкж &|ф*тдп
Ёюй [ймйш! - Р”
♦ «* **-*'*” ""лл"' - ---- - - .. -.^kw^vAv^ *
j jW&1 Management Sew Addfess: Ewfhxfc
J |тшбйл I fio
JJtS^UiPDefnCipCWW I ~ 1дЯрв1Ж«Шп1ЖЖ» /iisTrW J
| OK | Coned I tH> I
Рис. 6.7. Система IDS компании ISS RealSecure взаимодействует
с МЭ Checkpoint Fire Wall-1 по протоколу SAMP
Этот механизм так называемого «адаптивного управления
безопасностью» имеет одну обратную сторону - возможность ре-
ализации злоумышленниками атак отказа в обслуживании. Действи-
тельно, злоумышленнику не составляет большого труда имитиро-
вать сетевые атаки от имени серверов, сервисы которых используют
пользователи защищаемой сети (рис. 6.8,6.9). Такими сервисами,
например, могут быть DNS, электронная почта, WWW. Для реали-
зации атаки злоумышленнику необходимо определить IP-адреса этих
серверов и провести атаку от их имени. Наиболее просто имитиру-
ются атаки, не требующие установления TCP-соединений - скани-
рование портов и DoS-атаки.
Например, чтобы блокировать доступ к почтовому серверу (IP-
адрес 192.168.0.100), злоумышленник может использовать следу-
ющую команду:
nmap -sS -Р0 -D192.168.0.100 IP_Victim,
где I p_victim—IP-адрес любого хоста, трафик которого прослу-
шивается сетевым сенсором. Таким адресом может быть адрес
133
Ы bom Attack Dctcclo» Policy Fditoi В
F в Nh
Rt Й NHTP
Ft ЙРОР
® О яи=* *
t-’ Scanner
PI Cjd^Cop„Scann«
PJ IPHdfScan
’ E) ’ss
P| Niw_.Sc*’>
FMeri^
s I?) Оиея>~$сап
El Satan
s Й UDP^Port_$can
it: snmp
l+i й Sun RPC
HF Telnet
& □ TFTP
[f El UnwRemote
♦ P; Windows
□ eRSKILL
E3 /* LOGOS
□ » VIEWSESSION
EMAIL
OB SNMP
s^ZZLI
Defaul
о lOQWithoutRdW
Q LockSroAddf
Portscan Detection"
LockOeslAddr
LodiSrcOrDestAddr
Lcx&Setvice
~ As»... |ДСо-. ]ЙДО«... J>FIU I
Type: Pre-attack prob®
Console Name: Port_Scan
3
Рис. 6.8. Политика сетевого сенсора RealSecure, определяющая
возможные действия при обнаружении атаки - блокировка ад-
реса источника, адреса назначения или используемого сервиса
внешнего интерфейса МЭ, адрес сетевого сенсора, адреса серве-
ров, размещенных в зоне DMZ, или даже адреса локальной сети в
том случае, когда не используется NAT.
Отказ в обслуживании может быть реализован как блокиров-
кой доступа к серверам и блокировкой самих пользователей, так и
созданием чрезмерно большого количества блокирующих правил,
приводящего к снижению производительности МЭ.
Можно дать следующие рекомендации защиты от описывае-
мого способа атаки:
• системам IDS свойственен недостаток генерации большого
количества сигналов ложной тревоги, что требует проведения тон-
кой настройки параметров для каждой распознаваемой атаки. На-
пример, с установками по умолчанию в локальной сети сетевой
сенсор RealSecure распознает обычный ping без параметров,
как Ping Flood. В связи с этим необходимо предоставлять как
можно меньше возможностей по динамическому конфигурирова-
нию МЭ системой IDS;
134
Злоумышленник
Рис. 6.9. Схема выполнения отказа в обслуживании пользователей защищаемой
сети посредством имитации вторжений
Lh
• целесообразно поручать системе IDS блокировать только те
атаки, которые могут привести к блокировке используемых серви-
сов;
• целесообразно использовать возможности пограничного мар-
шрутизатора по предотвращению IP-спуфинга и защите самого
сетевого сенсора. Защита сетевого сенсора также достаточно вся-
кий вопрос, поскольку он размещается в незащищаемой зоне и дол-
жен не только пассивно прослушивать сетевой трафик, но и взаи-
модействовать с МЭ и консолью IDS;
• принять правильное решение о блокировке определенного вида
трафика может только администратор МЭ, поэтому необходимо
использовать наиболее подходящую систему уведомления о со-
бытиях (alert).
6.7. Уязвимости персональных МЭ
Идентификация сетевых приложений
Отличительные особенности персональных МЭ, а именно воз-
можность контроля деятельности сетевых приложений и функцио-
нирование на защищаемой системе, обуславливают и наличие ха-
рактерных для них уязвимостей. Персональные МЭ позволяют
усиливать защиту сетевых рабочих станций не только путем ис-
пользования механизмов ПФ и прикладных посредников, но и за
счет контроля деятельности сетевых приложений. Персональный
МЭ, контролирующий деятельность сетевых приложений, перехва-
тывает обращения приложений к сетевым ресурсам и на основе
имеющейся информации в базе правил (имя приложения, порт ис-
точника, адрес:порт получателя) разрешает или запрещает доступ
приложения.
Клиентским сетевым приложениям в большинстве случаев в
базе правил персонального МЭ соответствуют записи примерно
следующего вида:
Имя приложения Порт источника Адресшорт получателя Действие (разрешить/запретить /подтверждение)
EXPLORE* Any Апу:80 Разрешить
MSIMN Any Апу:(25,110) Разрешить
* Первые восемь байт исполняемого приложения.
136
Интересен вопрос - как персональные МЭ идентифицируют
сетевые приложения? В подавляющем большинстве случаев МЭ
ассоциирует приложение только с именем процесса в памяти ОС и
не выполняет привязку к исполняемому файлу и тем более не вы-
числяет контрольных сумм этих файлов. А это означает, что лю-
бая сетевая программа (троянский конь, например) может функци-
онировать и оставаться незамеченной для персонального МЭ.
Рассмотрим следующий пример. На большинстве Windows-xo-
стов используются приложения Internet Explorer и Outlook Express.
Возможные настройки МЭ для этих приложений приведены выше.
Троянская программа, имеющая имя IEXPLORE.EXE или
MSIMN.EXE и использующая транспортные порты 80 или 25| 110
для установки соединений с сервером управления соответственно,
может остаться незамеченной персональным МЭ.
Существует достаточно простой способ проверить ваш персо-
нальный МЭ на корректное функционирование:
• найдите в системном каталоге Windows программу TEL-
NET.EXE и скопируйте ее в любой другой каталог (например,
C:\Temp). Программа TELNET позволяет установить соединение
с любой удаленной TCP-службой, а также выполнять команды боль-
шинства из них;
• внимательно изучите базу правил вашего МЭ и выберите пра-
вило, которое предстоит эмулировать. Пусть, например, выбрано
приложение EXPLORE. Тогда переименовываем имя предвари-
тельно скопированной программы TELNET.EXE в EXPLORE.EXE;
• выполните следующую команду:
C:\temp> iexplore.exe 80 www.microsoft.com
Эта команда предписывает программе TELNET.EXE (мы ее
переименовали в IEXPLORE.EXE) установить TCP-соединение с
80 портом сервера www.microsoft.com. Последующий анализ ре-
акции МЭ (визуальный или анализ журналов) позволит сделать со-
ответствующий вывод.
Если использование программы TELNET вызывает трудности,
то можно воспользоваться утилитой LeakTest* (рис. 6.10). Про-
грамма LeakTest предназначена для проверки корректности рабо-
ты персонального МЭ путем установления TCP-соединения с 21
портом FTP-сервера (сервер Gibson Research Corp.). Предваритель-
но имя файла программы (LeakTest.exe) необходимо переимено-
вать в имя эмулируемого приложения. Поскольку LeakTest исполь-
зует только протокол FTP, то и выбор приложения ограничен только
* http://grc.com/lt/leaktest.htm.
137
LT I irev^dl I p?
Ready to Test
When you we connected to the Internet r* . ]
press the "Test For Leaks" button to begin. - “’
ИХ». CopyrioH(c)2000 . I |
byoeaehRaseerchCorp. “elp 1 Iest ror L8aKS I
Рис. 6.10. Утилита тестирования персональных МЭ LeakTest
имеющимися клиентами FTP (например, ftp.exe, GetRight, Internet
Explorer, Netscape Navigator, CutFTP и др.).
LeakTest сообщит результаты попытки установления соедине-
ния, и дальнейший анализ состоит в изучении реакции персональ-
ного МЭ. Именно появление программы LeakTest и реакция пользо-
вателей побудили производителей персональных МЭ «усиливать»
механизмы идентификации сетевых приложений.
Уязвимость конфигурационных файлов
Если защите платформ сетевых МЭ уделяется повышенное
внимание, то персональные МЭ функционируют изначально в по-
тенциально опасной среде. Объектами воздействия злоумышлен-
ника могут быть и персональные МЭ. Получив контроль над поли-
тикой безопасности персонального МЭ через его конфигурационные
файлы, злоумышленник может выполнять свои функции в обход за-
щиты МЭ.
Можно предложить следующий простой способ проверки уяз-
вимости конфигурационных файлов персональных МЭ. Попробуй-
те изменить и сохранить конфигурационный файл политики безо-
пасности в любом текстовом редакторе (если, конечно, файл
является текстовым). МЭ должен блокировать доступ других при-
ложений к своим файлам конфигурации. Эти же действия можно
выполнить, если настройки хранятся в системном реестре.
Блокировка конфигурационных файлов не обеспечивает доста-
точных мер предосторожности, существуют и другие способы по-
лучения управления персональными МЭ.
Описанные выше уязвимости персональных МЭ еще раз под-
тверждают тот факт, что использование персональных МЭ для
защиты сетевых рабочих станций недостаточно. Персональные МЭ
сосредотачивают свои усилия на контроле использования прило-
138
жениями сетевых ресурсов, а локальная деятельность приложений
остается вне поля их зрения. Поэтому необходимо совместно с пер-
сональными МЭ обязательно использовать и антивирусные средства.
6.8. Примеры выявленных
уязвимостей МЭ
В заключение этой главы приведем несколько примеров выяв-
ленных уязвимостей МЭ. Примеры, приведенные здесь, еще раз
заставляют задуматься о критериях выбора МЭ и степени дове-
рия к продуктам защиты информации, сертификационным испыта-
ниям и организациям.
Проект CVE (Common Vulnerabilities and Exposures) (http://
cve.mitre.org) позволил решить проблему накопления и учета всех
выявленных уязвимостей информационной безопасности различ-
ных продуктов. До недавнего времени производители сканеров бе-
зопасности и центры безопасности использовали собственные си-
стемы классификации и накопления уязвимостей различных
продуктов. CVE вводит единую систему наименования уязвимос-
тей, что значительно облегчает взаимодействие специалистов меж-
ду собой. В начале 2001 г. поддержку каталога CVE использовали
в своих продуктах 29 компаний, в том числе Axent, Cisco, ISS,
Symantec и др.
На август 2001 г. БД CVE содержала более 1300 уязвимых про-
дуктов, среди которых присутствуют и МЭ.
WatchGuard SOHO Firewall
Источник Internet Security Systems Security Advisory
Дата December 14,2000
CVE CAN-2000-0894 Weak authentication and Password Reset
using POST Operation
CAN-2000-0895 GET Request Buffer Overflow
CAN-2000-0896 Fragmented IP packet attack
Уязвимые версии: WatchGuard SOHO Firewall 1.6.0 и
WatchGuard SOHO Firewall 2.1.3 (только пункт 4).
Обнаруженные уязвимости позволяют удаленному злоумыш-
леннику получить доступ к административным функциям без вы-
полнения процедуры аутентификации или аварийно остановить кон-
фигурационный сервер или МЭ.
139
Weak Authentication
По умолчанию МЭ WatchGuard SOHO используют собствен-
ный встроенный HTTP-сервер для настройки устройства через
стандартный Web-браузер. Вход администратора в сервер осуще-
ствляется путем его аутентификации (user name/password). Одна-
ко механизм аутентифкации основывается только на особенностях
реализации HTML-интерфейсе.
Злоумышленник может напрямую запрашивать объекты, изме-
нять пароль администратора и перегружать МЭ без знания имени
и пароля администратора.
GET Request Buffer Overflow
Запрос большого размера GET к Web-серверу приводит к ава-
рийной остановке сервера конфигурации, что требует его перезаг-
рузки.
Fragmented IP packet attack
Большое количество фрагментированных пакетов, направлен-
ных на МЭ, приводят к перегрузке используемых им системных
ресурсов. В результате этого прекращается передача пакетов меж-
ду интерфейсами и сбрасываются все соединения. Для восстанов-
ления работоспособности требуется перезагрузка МЭ.
Password Reset using POST Operation
Программное обеспечение WatchGuard SOHO 2.1.3 позволяет
администраторам установить пароль для доступа к конфигураци-
онному серверу через Web-интерфейс. Однако при выполнении пу-
стого запроса аутентификации к объекту /passcfg происходит
удаление пароля, что позволяет осуществлять доступ к любым
административным функциям без знания пары имя/пароль.
Рекомендации
WatchGuard рекомендует обновить ПО до версии 2.2.1 (http://
bisd.watchguard.com/SOHO/Downloads/swupdates.asp).
140
Check Point FireWall-1
Источник Internet Security Systems Security Advisory
Дата September 27th, 2000
CVE CAN-2000-0804 One-way Connection Enforcement Bypass
CAN-2000-0779 Improper stderr Handling for RSH/REXEC
CAN-2000-0813 FTP Connection Enforcement Bypass
CAN-2000-0805 Retransmission of Encapsulated Packets
CAN-2000-0806 FWA1 Authentication Mechanism Hole
CAN-2000-0807 OPSEC Authentication Spoof
CAN-2000-0808 S/Key Password Authentication Brute
Force Vulnerability
CAN-2000-0809 GetKey Buffer Overflow
Во время проведения конференции Black Hat* 2000 (26 июля
2000 г.) было озвучено сразу несколько уязвимостей, обнаружен-
ных во всех версиях МЭ FireWall-1 компании Check Point.
Уязвимые версии: Nokia IP440 FireWall-1 v. 4.0 SP5.
One-way Connection Enforcement Bypass
Любой клиент защищаемой локальной сети может установить
несанкционированное сетевое соединение через МЭ. Эта уязви-
мость может быть реализована для сложных протоколов, исполь-
зующих несколько сетевых соединений путем использования фраг-
ментированных запросов или путем повторного открытия
однонаправленных TCP-соединений. Уязвимость основывается на
некорректном контроле МЭ направления действия правил.
Improper stderr Handling for RSH/REXEC
Злоумышленник может из внешней сети открыть несанкциони-
рованное соединение с внутренним защищенным клиентом RSH/
REXEC путем посылки специально форматированного stderr зап-
роса соединения (как сервер RSH/REXEC). Открываемые соеди-
нения некорректно контролируются FireWall-1, что и позволяет ус-
пешно их создавать.
Успешно проведенная атака может привести к нарушению це-
лостности, конфиденциальности и ретрансляции доступа к целевым
хостам защищаемой сети.
* http://www.dataprotect.conVbh2000/blackhat-fwl .html.
141
FTP Connection Enforcement Bypass
Злоумышленник может использовать эту уязвимость для пере-
направления соединения на доступные серверы FTP. Использует-
ся стандартная атака «FTP Bounce», не контролируемая демоном
FireWall-1. Уязвимость часто используется как форма IP-спуфин-
га для скрытия источника атаки и как способ получения несанкци-
онированного доступа к FTP-серверу в обход политики безопасно-
сти, реализуемой МЭ.
Retransmission of Encapsulated Packets
Злоумышленник может отправить пакеты, которые обойдут
правила безопасности и средства антиспуфингового контроля МЭ.
Пакеты являются модифицированными F WZ-пакетами. Уязвимость
позволяет под видом FWZ-клиента выполнять спуфинг через МЭ.
Чтобы нейтрализовать эту уязвимость, должно быть введено пра-
вило, определяющее использование протокола FWZ.
FWA1 Authentication Mechanism Hole
Злоумышленник может обойти механизмы аутентификации (но
не механизмы шифрования в последующем), после чего выпол-
нить (теоретически) DoS-атаки, основанные на флудинге.
Как часть схемы аутентификации FWA1 (внутренняя схема
аутентификации, используемая при взаимодействии компонентов
распределенной архитектуры Checkpoint) сервер отправляет кли-
енту случайное число и хэш случайного числа и общего разделяе-
мого секрета. Клиент, в свою очередь, отправляет свое случайное
число и хэш случайного числа, отправленного сервером, сложен-
ного операцией XOR со случайным числом клиента и секретом.
При использовании случайного числа клиента, равного 0, злоумыш-
ленник может обойти механизмы аутентификации, поскольку опе-
рация XOR случайного числа сервера с нулем эквивалентна само-
му числу и, следовательно, может быть получено одно и то же
значение хэша (клиента и сервера). Хотя и существует возмож-
ность обхода механизма аутентификации, она не приводит к рас-
крытию секретного ключа.
Все реализации МЭ без новых пакетов обновлений включали
правила, разрешающие управляющие соединения от любых клиен-
тов. В версии 4.1 FireWall-1 разрешает по умолчанию управляю-
щие соединения только от систем, на которых установлены компо-
ненты МЭ.
142
OPSEC Authentication Spoof
Удаленный злоумышленник может выполнить аутентификацию
любого OPSEC-канала, разрешенного базой правил, и получить
полный доступ к соответствующим сервисам.
При аутентификации сервера по протоколу OPSEC клиенту от-
правляются случайное число и хэш случайного числа и общего
секрета. Клиент выполняет проверку ключа путем вычисления хэша
над полученным числом и собственным секретом. Далее таким
же образом аутентифицируется клиент. Механизм аутентификации
нарушается, если злоумышленник инициализирует соединение и
получает случайное число и хэш от сервера. Клиент отправляет
полученное сообщение обратно серверу. Поскольку сервер не про-
веряет случайные числа, сгенерированные им самим и клиентом,
то данные клиента проходят успешную проверку, и ему предостав-
ляется доступ.
S/Key Password Authentication Brute Force Vulnerability
Злоумышленник может получить несанкционированный доступ,
используя узвимость аутентификации S/Key. Уязвимость реализу-
ется путем перебора (brute force) атакующим всех возможных
вариантов секретного ключа.
GetKey Buffer Overflow
Злоумышленник может остановить работу демона МЭ без на-
рушения текущей политики безопасности, что представляет воз-
можную угрозу целостности всех объектов, определенных в пра-
вилах ПБ. Отсутствие проверки границ в процедуре GetKey,
используемой в протоколе взаимодействия между программными
модулями МЭ может быть использовано путем отправки специ-
альной инструкции, приводящей к переполнению буфера и останов-
ки демона МЭ.
Рекомендации
Check Point выпустила пакеты исправлений VPN-1/FireWall-1
4.0 SP7 и VPN-1/FireWall-14.1 SP2, которые устраняют эти уязви-
мости.
143
Cisco PIX Firewall
Источник Cisco: bugIDCSCdr91002, CSCds30699, CSCds38708
Internet Security Systems Security Advisory
Дата 27 September 2000
CVE CVE-2000-1022
Уязвимые версии: все версии до 4.4(6) (включая 2.7, 3.0, 3.1,
4.0,4.1), версия 5.0.x и выше, все версии 5.1.x, версии 5.2(2) и 5.2(3).
Посредник протокола SMTP (mailguard) в МЭ Cisco Secure PIX
Firewall версии 5.2(2) и более ранних версий некорректно выполня-
ет контроль команд, что позволяет исполнять любую команду на
сервере SMTP после отправки команды DATA.
Очевидно, что защищаемый почтовый сервер может быть уяз-
вим только лишь в том случае, если сам, в свою очередь, некор-
ректно обрабатывает команды, пропускаемые МЭ.
Подробности: http://www.cisco.com/warp/public/707/PIXfire-
wallSMTPfilter-pub.shtml.
1. ТЕСТИРОВАНИЕ
МЕЖСЕТЕВЫХ ЭКРАНОВ
Мероприятия по тестированию практически реализуемой защи-
ты межсетевым экраном должны являться неотъемлемыми этапами
как при применении новой политики безопасности, так и при вводе
МЭ в эксплуатацию. В главе даны рекомендации и рассмотрены
основные средства проведения испытаний и исследований межсете-
вых экранов.
7.1. Общие рекомендации
Коммерческие МЭ экспертного уровня являются многофунк-
циональными и сложными с точки зрения управления и функци-
онирования продуктами. Одной из первых проблем, с которой
сталкивается администратор МЭ, является проверка его работоспо-
собности и корректной реализации межсетевым экраном каждо-
го правила политики безопасности. В документации к коммерчес-
ким МЭ, как правило, даны четкие поэтапные инструкции по их
установке и запуску. Но в большинстве случаев отсутствуют ре-
комендации по проверке работоспособности. Бесплатные же про-
дукты для Unix платформ, ориентированные прежде всего на вы-
сококвалифицированных администраторов (пользователей),
предоставляют только самую необходимую информацию в доку-
ментации, подразумевая, что все остальное администратор дол-
жен знать.
Большинство нарушений информационной безопасности проис-
ходит в первые часы подключения информационных систем к сети
Интернет. В этот момент происходит проверка работоспособнос-
ти сетевых сервисов, но не защищенности системы!
Еще раз подчеркивая важность проверки правильного функци-
онирования МЭ, дадим общие рекомендации, позволяющие убедить-
ся в том, что работающий МЭ выполняет свои функции корректно.
В идеальном случае администратор МЭ должен пройти соответ-
145
ствующие курсы подготовки. К сожалению, не все организации
могут обучить своего администратора. Причины могут быть са-
мые разные - высокая стоимость курсов (минимальная стоимость
базового курса по конкретному изделию составляет примерно 500
$ США), территориальное отсутствие организаций, читающих кур-
сы по конкретному МЭ, непонимание руководством компании не-
обходимости подготовки специалиста. Последняя причина особен-
но актуальна для России. Руководители организаций, в которых нет
начальников отделов автоматизации, как правило, считают, что
администратор способен разобраться с любым изделием самосто-
ятельно.
Прежде всего перед установкой МЭ, как впрочем, и любого
другого продукта, необходимо внимательно изучить прилагаемую
документацию и подготовить на бумаге исходные данные. Если
администратор хорошо знаком с одним МЭ или он просто «хоро-
ший» администратор, то это вовсе не означает, что он способен
сразу установить незнакомый ему МЭ. Каждый МЭ требует вво-
да специфичных только для него параметров или иметь особенно-
сти установки. "
В большинстве случаев исходными данными для установки МЭ
являются:
• IP-адреса сетевых интерфейсов МЭ и шлюзов;
• доменное имя и IP-адрес сервера DNS;
• имя и пароль администратора МЭ;
• адрес электронной почты администратора для отправки уве-
домлений о событиях;
• список используемых сервисов и предоставляемых ресурсов.
До начала установки программного МЭ проверяется рабо-
тоспособность сетевых интерфейсов и корректность маршрутиза-
ции пакетов между сетями, которые разделяет МЭ. Эта проверка
необходима, так как после установки МЭ локализовать причину
достаточно сложно. Например, обнаружить неправильно установ-
ленный или неисправный сетевой адаптер (сетевую карту) после
установки МЭ более сложно, так как после установки МЭ все про-
блемы невольно связываются с МЭ. Основным инструментом
здесь является хорошо известная утилита ping, использующая
протокол ICMP.
Итак, МЭ установлен и активизирован. Теперь необходимо убе-
дится в том, что МЭ уже начал защищать вашу сеть. Во-первых,
необходимо найти имя процесса МЭ в памяти. В большинстве ре-
ализаций только что установленный МЭ блокирует весь трафик
между сетями, за исключением трафика ICMP. Проверить этот
факт позволит попытка установления соединения по некоторому
146
прикладному протоколу, например HTTP. Далее обязательно нуж-
но просмотреть журналы ОС и МЭ на предмет сообщений об ошиб-
ках. В случае неудачного первичного старта МЭ типичными ошиб-
ками могут быть:
• ошибка ввода, отсутствие или повреждение лицензионных
данных;
• несоответствие лицензии реально установленным IP-адресам
интерфейсов. Большинство МЭ лицензируется на фиксированный
IP-адрес внешнего интерфейса;
• включение маршрутизации Control Panel>Network>Proto-
cols>TCP/IP>Route на уровне сетевого стека ОС Windows NT. Для
некоторых МЭ это может привести к тому, что сетевой пакет
отправится через интерфейс ранее, чем будет проанализирован;
• неправильно установлены некоторые параметры МЭ. Напри-
мер, по умолчанию в МЭ BlackHole 4.11 для NT параметр «default
interface» равняется 0, при этом МЭ запускается и не подает ника-
ких признаков некорректной работы. Между тем, в такой ситуации
МЭ работает как обычный маршрутизатор, что приводит к нару-
шению ИБ.
Лучший способ убедиться в корректности реализации правил
безопасности для сетевых сервисов - провести небольшой экспе-
римент с ними. Для этого нужно попробовать осуществить соеди-
нение через МЭ для конкретного сервиса при разрешающем и
запрещающем правиле для данного сервиса и, может быть, с раз-
личными специфичными для него параметрами. Оценка реакции
сетевого приложения и журналов МЭ позволит принять соответ-
ствующее решение.
В сложных ситуациях может понадобиться сетевой анализа-
тор трафика, выполняющий перехват сетевого трафика и его пред-
ставление по соответствующим уровням модели OSI. Встроенные
возможности некоторых сетевых анализаторов позволяют локали-
зовать различные ошибки в сети (перегрузка, неисправность сете-
вых адаптеров, ошибки контрольных сумм, шторм широковеща-
тельных и ICMP сообщений и др.).
Рассмотрим подробнее продукты и технологии, которые мож-
но использовать при проверке реализации межсетевым экраном по-
литики безопасности, а также при проведении различных тестов
над ним.
7.2. Средства исследования МЭ
Цель исследования МЭ состоит в проверке соответствия раз-
работанной и реализуемой им политик безопасности. ПБ опреде-
147
ляет права доступа внешних и внутренних пользователей к различ-
ным сетевым ресурсам (общего и ограниченного использования).
При использовании ПФ необходимо удостоверится в том, что из
всех возможных комбинаций пакетов, включающих допустимые
значения IP-адреса источника, IP-адреса получателя, транспорт-
ного порта источника, транспортного порта получателя относитель-
но всех интерфейсов, МЭ пропускает только те пакеты, которые
соответствуют принятой политике безопасности. Необходимо
учесть также нестандартные ситуации, которые могут привести к
уязвимости ПБ. Например, фрагментированные пакеты, пакеты с
некорректно установленными полями и др.
Как видно, только проверка корректной работы ПФ является
трудоемкой задачей. Полная проверка прикладных посредников с
использованием различных схем аутентификации - еще более слож-
ная процедура.
Сетевые сервисы, описываемые в ПБ, с точки зрения стека
TCP/IP ассоциируются транспортными портами TCP и UDP. Это
означает, что для каждого разрешенного сервиса ПБ должен быть
«разрешен» соответствующий транспортный порт. Поскольку ПБ
не симметрична относительно интерфейсов МЭ, то и список «раз-
решенных» портов на каждом из интерфейсов будет различным.
Соответственно сервисы, доступ к которым необходимо блокиро-
вать, будут описываться «запрещенными» портами.
Поскольку состояния «разрешен» и «запрещен» в большей сте-
пени характеризуют ПБ, то в ряде случаев удобнее использовать
термины «порт не фильтруется» и «порт фильтруется».
Состояние транспортного порта на МЭ «открыт» говорит о том,
что на МЭ порт обслуживается программой-сервером, и порт на-
ходится в состоянии LISTEN, т. е. прослушивается. Такой програм-
мой может быть сетевой сервис ОС, служба-посредник МЭ, служ-
ба удаленного управления МЭ и др. Состояние «порт не
фильтруется» означает, что МЭ пропускает сетевые пакеты с ус-
тановленным транспортным портом получателя.
Коммерческие сетевые сканеры безопасности
Допустим, что МЭ работает согласно разработанной ПБ. Не-
обходимо проверить, что представляет собой МЭ со стороны Ин-
тернет, т. е. что может увидеть хакер, исследующий вашу сеть.
Для решения этой задачи необходимо определить, какие 1Р-хосты
доступны, какие сетевые сервисы на них установлены и какие из
них имеют уязвимости. Задача решается с помощью программ-
ных продуктов оценки уязвимостей или сетевых сканеров портов.
148
Сканеры портов определяют в заданном диапазоне IP-адресов
доступность хостов и наличие открытых транспортных портов TCP
(в некоторых случаях и UDP). Сетевые сканеры оценки защи-
щенности также выполняют сканирование в заданном диапазо-
не IP-адресов, но дополнительно, подобно антивирусным средствам,
содержат сигнатуры уязвимостей, на основании которых и опреде-
ляется уязвимость сервисов. К лучшим представителям коммер-
ческих продуктов оценки безопасности сетевых сервисов можно
отнести Internet Security Scanner компании ISS, Axent NetRecon,
Network Associates CyberCop.
Использование сетевых сканеров безопасности при оценке за-
щиты, реализуемой МЭ, позволяет:
• выявить уязвимые сервисы как расположенные в защищае-
мой сети, так и установленные на самом МЭ;
• оценить защитные возможности прикладных посредников;
• обнаружить некоторые слабые места в настройках МЭ;
. • получить «картину» защищаемой сети с точки зрения зло-
умышленника.
Очевидно, уязвимости МЭ могут быть обнаружены лишь в том
случае, если их описание содержится в БД сигнатур сканера. На-
пример, в составе Internet Security Scanner компании ISS предус-
мотрен модуль Firewall Scanner, позволяющий обнаружить целый
ряд уязвимостей МЭ. Приведем несколько диагностических сооб-
щений этого сканера:
FTP proxy penetrated Risk Level: High
Описание
Посредник FTP сконфигурирован некорректно и может содер-
жать брешь в защите МЭ.
Рекомендации
Если уязвимость обнаружена, пересмотрите правила посред-
ника и переконфигурируйте, как это необходимо. Для получения
большей информации обратитесь к документации производителя.
SOCKS v3 daemon misconfigured Risk Level: High
SOCKS v4 daemon misconfigured
SOCKS v5 daemon misconfigured
Описание
Обнаружена незащищенная конфигурация сервиса SOCKS v3.0
(4.0, 5.0). Конфигурация позволяет атакующим получить доступ к
внутренней сети через шлюзовой хост. Через посредник SOCKS
могут осуществляться соединения со следующими службами: FTP,
149
TELNET, SMTP, Finger, HTTP и POP3. Сервер SOCKS v4 может
быть обнаружен на сервере SOCKS v5, если последний имеет об-
ратную совместимость.
Рекомендации
Проверьте правила посредника и переконфигурируйте, как это
необходимо. Для получения большей информации обратитесь к до-
кументации производителя.
Squid proxy was penetrated Risk Level: Medium
to reach protected hosts
Описание
HTTP-посредник Squid был использован для соединения по URL
за МЭ. Если это разрешено, то атакующий может обойти некото-
рые фильтры МЭ.
Рекомендации
Проверьте конфигурацию Squid. Для получения большей инфор-
мации обратитесь к документации вашего МЭ.
HTTP proxy penetrated Risk Level: High
Описание
HTTP-посредник позволяет осуществлять доступ через сервер-
посредник. Если тест был выполнен с внешней стороны МЭ, то
атакующий может использовать сервер-посредник для осуществ-
ления доступа к любой части сети за МЭ.
Рекомендации
Проверьте установки сервера. Для получения большей инфор-
мации обратитесь к документации вашего МЭ.
Winroute allows unrestricted access Risk Level: High
to proxy configuration
Описание
Процедура, используемая для аутентификации пользователей
при доступе к меню администратора сервера Winroute, содержит
дефект, который позволяет пользователям обойти аутентификацию
и получить прямой доступ. Этот доступ для изменения конфигура-
ции может быть выполнен удаленно.
Рекомендации
Обратитесь к Tiny Software для получения информации.
150
Как видно из приведенных выше примеров, для тестирования
МЭ возможностей даже самых лучших сканеров явно недостаточно.
Nmap
Сетевой сканер Nmap (Network Mapper) заслужено пользуется
большой популярностью у сетевых администраторов, админист-
раторов безопасности и у хакеров [13]. Хотя Nmap распространя-
ется бесплатно (и доступен в исходных текстах), но по некоторым
предоставляемым возможностям он не уступает и многим анало-
гичным коммерческим продуктам. Nmap не выполняет проверку
уязвимости сетевых сервисов и соответственно не имеет собствен-
ной БД уязвимостей, но предоставляет ряд возможностей, кото-
рые делают его незаменимым при исследовании защищенности се-
тей.
Сетевой сканер Nmap выполняет сканирование различными ме-
тодами (UDP scan, TCP connect, TCP SYN, FTP proxy, Reverse-
ident, ICMP, FIN, ACK, Xmas tree, NULL scan) любого количества
объектов сети в заданном диапазоне портов. Большой набор до-
полнительных возможностей позволяет определять тип ОС и под-
держиваемые протоколы, выполнять «невидимое» сканирование,
сканирование с использованием ложных хостов, прямое RPC-ска-
нирование, определять наличие пакетных фильтров, осуществлять
сканирование с использованием 1Р-фрагментации.
При исследовании МЭ или реализуемой им ПБ сканер Nmap
позволяет ответить на следующие вопросы:
• как МЭ или защищаемая сеть видны из внешней сети (Интер-
нет);
• обнаруживает ли МЭ процессы сканирования Nmap различ-
ными методами;
• может ли злоумышление вскрыть ПБ, реализуемую МЭ.
Результат работы сканера отображается в виде состояния ис-
следуемого порта: «открыт», «фильтруемый» и «нефильтруемый».
«Открыт» означает, что транспортный порт удаленного хоста на-
ходится в состоянии «LISTEN». Состояние «фильтруемый» озна-
чает, что МЭ (пакетный фильтр) блокирует доступ к этому порту, и
Nmap не смог определить его состояние. «Нефильтруемый» озна-
чает, что Nmap определил порт как закрытый, при этом средства
защиты (МЭ) не помешали определить это состояние.
Описание всех возможностей сканера можно найти в докумен-
тации, доступной и на русском языке. Ниже описаны методы, ко-
торые использует Nmap для определения состояния транспортных
портов.
151
TCP connect
TCP SYN
UDP scan
FIN scan
Xmas scan
NULL scan
Это наиболее общий метод сканирования портов, ко-
торый заключается в установке полноценного ТСР-
соединения со сканируемым хостом (используя
функцию connect(), присутствующую во всех сетевых
ОС). В случае успешного соединения принимается
решение - порт открыт, иначе - закрыт. Это самый
доступный и распространенный метод сканиро-
вания, поэтому он обнаруживается всеми средст-
вами регистрации событий, обнаружения сканиро-
ваний, IDS и некоторыми МЭ
Скрытое (stealth) сканирование, известное также как
«полуоткрытое сканирование». При «полуоткрытом
сканировании» сканирующий хост отправляет пакет
с установленным флагом SYN, имитируя открытие
соединения, но при получении ответа сбрасывает
соединение, отправляя пакет с установленным
флагом RST. Если ответ содержит пакет с
установленными флагами SYN и АСК, то принима-
ется решение - порт открыт. Пакет с установленным
флагом RST означает, что порт закрыт. Далеко не
все системы позволяют обнаруживать и регист-
рировать «полуоткрытое» сканирование
Метод используется для определения открытых
UDP-портов. На порты сканируемой машины от-
правляются UDP-пакеты без данных. Порт считается
открытым, если в ответе было получено 1СМР-сооб-
щение «порт недоступен», иначе предполагается,
что порт закрыт
Сканирующий хост отправляет пакеты с установлен-
ным флагом FIN. Согласно рекомендации RFC 973
п. 64, ОС сканируемого хоста должна ответить на
такой пакет пакетом RST, если порт закрыт, и игно-
рировать эти пакеты, если порт открыт
Метод Xmas Tree использует тестовый пакет с уста-
новленными флагами FIN|URG|PSH
При NULL-сканировании используется пакет без
установленных флагов
152
ACK scan Метод используется для определения правил ПБ
МЭ. На сканируемый порт хоста (подразумевается,
что исследуется МЭ) отправляется АСК-пакет со
случайными значениями полей acknowledgement
number и sequence number. Порт считается «не-
фильтруемым», если в ответ получен RST-пакет, и
«фильтруемым», если ответа не последовало или по-
лучено ICMP-сообщение о недоступности порта.
Метод сообщает о правилах для портов на скани-
руемом хосте, а не об их состоянии
Window scan Метод TCP Window так же, как и АСК skan,
предназначен для определения правил политики
безопасности МЭ, но в отличие от метода АСК scan,
использует особенности формирования значения
поля Initial Window различными ОС
Nmap имеет специальную опцию для исследования особеннос-
тей обработки фрагментированных пакетов. Эта опция может быть
использована при сканировании методами SYN, FIN, Xmas и NULL.
Следует заметить, что результативность описанных методов
сильно зависит от реализации сетевого стека исследуемых хостов.
Поэтому при исследовании каким-либо одним методом вы може-
те получить ложный результат. Чтобы этого избежать, выполняй-
те проверку различными методами и сравнивайте получаемые ре-
зультаты между собой.
Hping
Как указывается в документации, сканер hping позволяет вы-
полнять аудит стека TCP/IP, вскрывать политику безопасности МЭ,
сканировать порты TCP различными методами, передавать фай-
лы через МЭ и предоставляет ряд других интересных возможнос-
тей [14].
В отличие от других сканеров, hping требует от пользователя
глубоких знаний стека протоколов TCP/IP. Hping оперирует значе-
ниями полей заголовков сообщений различных протоколов и не де-
лает выводы по результатам своей работы, предоставляя эту воз-
можность пользователю.
Алгоритм работы hping состоит в следующем. С помощью клю-
чей и опций командной строки формируется тестовый пакет прото-
колов ICMP, IP, UDP или TCP, отправляемых к исследуемому IP-
хосту с заданной периодичностью. Далее hping принимает отклики
153
на отправляемые им пакеты от исследуемого IP-хоста и отобра-
жает их на консоли согласно установленным опциям.
Несмотря на кажущуюся тривиальность алгоритма, hping по-
зволяет выполнять не только универсальные исследования МЭ, но
и является незаменимым инструментарием сетевых администра-
торов. Рассмотрим применение hping на примерах.
darkstar:-# hping www.packetfactory.net
pppO default routing interface selected (according to /proc)
HPING www.packetfactory.net (pppO 209.234.217.205): NO FLAGS are
set, 40 headers + 0 data bytes
40 bytes from 209.234.217.205: flags=RA seq=0 ttl=44 id=12553
win=0 rtt=446.6 ms
40 bytes from 209.234.217.205: flags=RA seq=l ttl=44 id=12554
win=0 rtt=400.1 ms
40 bytes from 209.234.217.205: flags=RA seq=2 ttl=44 id=12555
win=0 rtt=390.2 ms
40 bytes from 209.234.217.205: flags=RA seq=3 ttl=44 id=12556
win=0 rtt=480.2 ms
40 bytes from 209.234.217.205: flags=RA seq=4 ttl=44 id=12557
win=0 rtt=400.1 ms
40 bytes from 209.234.217.205: flags=RA seq=5 ttl=44 id=12558
win=0 rtt=400.1 ms
40 bytes from 209.234.217.205: flags=RA seq=6 ttl=44 id=12559
win=0 rtt=390.1 ms
40 bytes from 209.234.217.205: flags=RA seq=7 ttl=44 id=12560
win=0 rtt=410.1 ms
40 bytes from 209.234.217.205: flags=RA seq=8 ttl=44 id=12561
win=0 rtt=410.1 ms
40 bytes from 209.234.217.205: flags=RA seq=9 ttl=44 id=12562
win=0 rtt=410.1 ms
--- www.packetfactory.net hping statistic ----
10 packets tramitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 390.1/413.8/480.2 ms
Рис. 7.1. Использование hping без параметров
При запуске программы без параметров (рис. 7.1), формиру-
ется TCP-пакет без флагов, без данных, со случайным портом от-
правителя и портом назначения, равным 0. Как видно из рисунка,
узел www.packetfactory.net отвечает на получаемые пакеты сбро-
сом соединения (установлены флаги RST и АСК). Какие выводы
можно сделать на основе полученных данных?
1. С большой вероятностью можно утверждать, что хост не
защищен, поскольку TCP порт 0 не используется прикладными
службами и не все ОС обрабатывают запросы к нему.
2. Получены значения минимального, среднего и максималь-
ного времени отклика. Это позволяет использовать hping для диаг-
ностических целей, а также в случаях, когда использование стан-
154
darkstar:-# hping www.yahoo.com -p 80 -A -r
pppO default routing interface selected (according to
/proc)
HPING www.yahoo.com (pppO 216.32.74.53): A set, 40
headers + 0 data bytes
40 bytes from 216.32.74.53: flags=R seq=O ttl=46 id=6765
win=16384 rtt=317.5 ms
40 bytes from 216.32.74.53: flags=R seq=l ttl=46 id=+749
win=16384 rtt=320.1 ms
40 bytes from 216.32.74.53: flags=R seq=2 ttl=46 id=+773
win=16384 rtt=320.1 ms
40 bytes from 216.32.74.53: flags=R seq=3 ttl=46 id=+712
win=16384 rtt=310.2 ms
Рис. 7.2. Использование hping с опцией г
дартной программы ping невозможно, например, при блокировании
МЭ пакетов ICMP. Метод анализа отклика TCP-портов известен
как TCP-ping.
3. Анализ параметра id (идентификатор IP-пакета) позволяет
оценить загрузку исследуемого хоста. В предположении, что ОС
для каждого IP-пакета формирует значение id путем последова-
тельного увеличения на единицу, можно определить, сколько паке-
тов отправил хост в некотором интервале времени. Hping по умол-
чанию отправляет пакеты с интервалом в 1 с. Как видно на рис. 7.1,
значения id увеличиваются последовательно на единицу, а это
означает, что во время проведения исследования хост www.packet-
factory.net не осуществлял сетевого взаимодействия ни с кем дру-
гим! Опция г указывает hping выводить разницу значений id меж-
ду пакетами (рис. 7.2).
Рассмотрим следующий пример. Проведем некоторые иссле-
дования Web-сайта www.company.com (доменное имя и IP-адреса
изменены умышленно).
Шаг 1. Запускаем hping без параметров (рис. 7.3). Результат
этого шага позволяет сделать предположение - либо ОС Web-cep-
darkstar:-# hping www.company.com
pppO default routing interface selected (according to /proc)
HPING www.company.com (pppO 1.0.0.10): NO FLAGS are set, 40
headers + 0 data bytes
--- www.company.com hping statistic ---
39 packets tramitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
Рис. 7.3. Исследование узла www.company.com (шаг 1)
155
darkstar:-# hping company.com -p 801 -S
pppO default routing interface selected (according to /proc)
HPING www.company.com (pppO 1.0.0.10): S set, 40 headers + 0
data bytes
ICMP Packet filtered from 16.0.0.17 (unknown host name)
ICMP Packet filtered from 16.0.0.17 (unknown host name)
ICMP Packet filtered from 16.0.0.17 (unknown host name)
--- www.company.com hping statistic ----
7 packets tramitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
Рис. 7.4. Исследование узла www.company.com (шаг 2)
вера не обслуживает нулевой порт, либо хост защищен фильтром
пакетов (МЭ или фильтрующим маршрутизатором).
Шаг 2. Предположим, что МЭ защищает исследуемый узел и
выполним следующий тест (рис. 7.4). Отправим на произвольный,
заведомо не используемый порт SYN-пакеты (инициализация ТСР-
соединения). МЭ должен либо ничего не отправлять в ответ, либо
отвечать сбросом соединения. Как видно на рис. 7.4, пакеты бло-
кируются IP-хостом 16.0.0.17 и последний отправляет ICMP-сооб-
щения «host 1.0.0.10 unreachable». Найден первый эшелон обороны
- это хост с IP-адресом 16.0.0.17.
Шаг 3. Трассировка маршрута также подтверждает последний
вывод (рис. 7.5).
Шаг 4. С помощью следующего теста попробуем выяснить тип
используемого МЭ - ПФ или «интеллектуальный» инспектор со-
стояний. Поскольку исследуемый хост является общедоступным
Web-узлом, то и без дополнительного его изучения известно, что
порт 80 открыт. Пакетный фильтр должен пропускать все пакеты
на этот порт, а инспектор состояний только те пакеты, которые «при-
надлежат» установленному соединению. Как видно из рис. 7.6, все
пакеты, отправляемые на порт 80, блокируются.
darkstar:traceroute www.company.com
traceroute to www.company.com (1.0.0.10), 30 hops max,
40 byte packets
18 10.2.1.158340.005ms 339.671ms 339.912ms
19 10.3.8.141 340.201 ms 339.817 ms 349.9 ms
20 10.5.2.158 330.09 ms 329.852 ms 339.934 ms
21 13.2.25.13 1790 ms 329.722 ms 329.947 ms
22 16.0.0.17 (16.0.0.17) 349.884 ms * *
23 * * *
Рис. 7.5. Исследование узла www.company.com (шаг 3)
156
darkstar:hping www.company.com -p 80 -A (-F|R|-N)
pppO default routing interface selected (according to
/proc)
HPING www.company.com (pppO 1.0.0.10): A set, 40 headers
+ 0 data bytes
--- www.company.com hping statistic ----
17 packets tramitted, 0 packets received, 100% packet
loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
Рис. 7.6. Исследование узла www.company.com (шаг 4)
darkstar: hping www.company.com -p 80 -S
pppO default routing interface selected (according to
/proc)
HPING www.company.com (pppO 1.0.0.10): S set, 40 headers
+ 0 data bytes
44 bytes from 1.0.0.10: flags=SA seq=0 ttl=229 id=47766
win=32768 rtt=430.0 ms
44 bytes from 1.0.0.10: flags=SA seq=l ttl=229 id=47767
win=32768 rtt=360.1 ms
44 bytes from 1.0.0.10: flags=SA seq=2 ttl=229 id=47768
win=32768 rtt=350.2 ms
44 bytes from 1.0.0.10: flags=SA seq=3 ttl=229 id=47769
win=32768 rtt=340.1 ms
44 bytes from 1.0.0.10: flags=SA seq=4 ttl=229 id=47770
win=32768 rtt=600.2 ms
44 bytes from 1.0.0.10: flags=SA seq=5 ttl=229 id=47771
win=32768 rtt=410.1 ms
44 bytes from 1.0.0.10: flags=SA seq=6 ttl=229 id=47772
win=32768 rtt=340.1 ms
44 bytes from 1.0.0.10: flags=SA seq=7 ttl=229 id=47773
win=32768 rtt=350.2 ms
--- www.company.com hping statistic --
8 packets tramitted, 8 packets received, 0% packet loss
round-trip min/avg/max = 340.1/397.6/600.2 ms
Рис. 7.7. Исследование узла www.company.com (шаг 5)
Шаг 5. На запрос соединения получаем подтверждение - фла-
ги SYN АСК (рис. 7.7)
Последние два результата, полученные на шагах 4 и 5, позволя-
ют сделать вывод, что используемый МЭ для защиты узла
www.company.com является инспектором состояний.
С точки зрения исследуемых хостов, использование hping с клю-
чом S (с установленным флагом SYN) может восприниматься как
157
атака SYN flood, направленная на реализацию отказа в обслужива-
нии. Вы можете с помощью hping исследовать реакцию собствен-
ных МЭ на атаку S YN-flood. Опция I позволяет указывать времен-
ной интервал отправки пакетов с точностью до микросекунд.
Сканер безопасности hping является очень мощным средством
при исследовании МЭ. В качестве примеров здесь приведена лишь
малая часть возможных применений этой программы.
Firewalk
Средство исследования МЭ Firewalk (рис. 7.8) предназначено
для исследования политики безопасности ПФ. Для этого оно ис-
пользует метод, описанный в разделе «Трассировка маршрута» [17].
Напомним, что суть этого метода заключается в том, что для се-
тевых пакетов, пропущенных МЭ во внутреннюю защищаемую
сеть, с установленным значением TTL = 1 хостами внутренней сети
генерируются соответствующие ICMP-сообщения Time exceeded.
Основными исходными данными для Firewalk являются IP-ад-
реса исследуемого МЭ IP^ и любого хоста 1РХ, расположенного в
(да
F irewalk Control Panel
33434
0 ^Network wrtBng pause
Initial ramping port
RedwdancyCmim
1
; fT“ J|" бфЙ vector' , [53,80
j; jйеей*ер'«Ш.»»е«:.;<’:\ да-' .
j Quiet mode'-'-5
YY - '3'' '
port scan list
да
Set Parameters
1
Close
Рис. 7.8. Параметры Firewalk
158
-. ~ч- ';-.. < : -:.м|
Welcome to Firewalk/GTK. 2
Please enter a gateway host.
Please enter a destination host.
Ramping up hopcounts to binding host...
probe: 1 TTL: 1 port 53: Bound scan at 1 hops [192168 0 1 ]
port 53: CDestination at 2 hops> [10.0.0.36]
port 80: *
0 ports open t 0 ports unknown
3 probes sent, 2 replies received
, "f.'-.,-/; .//i^7ee7i > - - ' ' ?'/? |ioqo36 .
Рис. 7.9. Результат исследования ПБ МЭ с IP-адресом
внешнего интерфейса 192.168.0.1
защищаемой сети. Алгоритм функционирования программы состоит
из двух основных этапов:
• определение контрольного значения TTL. Firewalk, аналогич-
но traceroute, отправляет UDP-пакеты с последовательно увели-
чиваемым значением TTL с адресом назначения 1РХ. При получе-
нии ICMP-отклика от исследуемого МЭ 1РМЭ определяется
контрольное значение TTL^;
• опеределение политики безопасности МЭ. Для каждого ис-
следуемого порта PN отправляется пакет с IP-адресом назначения
1РХ, портом назначения PN и значением TTL = ТТЪмэ + 1. В случае
получения ICMP-сообщения Time exceeded, порт МЭ PN считает-
ся открытым (рис. 7.9).
Правильный выбор транспортного порта отправителя также
влияет на получаемый результат, поскольку правила МЭ определя-
ют не только транспортный порт назначения, но и порт отправите-
ля. Значением транспортного порта отправителя может быть лю-
бой порт, разрешенный политикой безопасности МЭ. В большинстве
случаев разрешены порты 53 (DNS) и 80 (HTTP).
Сканер Firewalk позволяет исследовать правила МЭ и для про-
токола TCP. Конечно, исследование правил для протокола TCP воз-
можно только для ПФ.
Netcat
Netcat позиционируется разработчиками как средство отладки
и исследования сетевого стека [15]. Он может выполнять функции
и TELNET-подобного клиента, и сервера. В отличие от TELNET
159
клиента, Netcat не осуществляет терминальные преобразования
символов. Основное достоинство netcat при тестировании МЭ зак-
лючается в возможности создания «настраиваемых» TCP- или
UDP-соединений с произвольными характеристиками. Например,
следующая команда создает сервер, прослушивающий порт 80 TCP,
и при подключении клиентов передает им содержимое файла
messages.txt:
nc -1 -р 80 < /tmp/messages . txt
Приведенная команда позволяет быстро смоделировать НТТР-
трафик для ПФ и убедиться в корректности прозрачных посредни-
ков HTTP (они не должны пропускать подобный трафик).
Часто при исследовании устойчивости сетевого стека к повы-
шенным нагрузкам используют так называемые стресс-тесты,
которые различными способами создают максимальную нагрузку
на сетевой стек. Обычно для этого используют утилиту ping с ми-
нимальным интервалом отправки пакетов (ключ -f в Unix). Netcat
позволяет также просто создать стресс-нагрузку на прикладном
уровне. Например, настройка следующего соединения между кли-
ентом и сервером
сервер: yes test_messages_to_client i
nc ~v -v -1-p 2222 > /dev/null
клиент: yes test_messages_to_servr i
nc server_name 2222 > /dev/null
создаст стрессовое соединение, через которое с максимальной
скоростью (зависящей от пропускной способности сети, произво-
дительности клиента, сервера и МЭ) будет передаваться текст
TEST_MESSAGES_TO_CLIENT и TEST_MESSAGES_TO_SERVR.
Netcat также обладает и другими возможностями:
• сканирование портов;
• протоколирование событий;
• регистрация (dump) сетевого трафика;
• поддержка протокола UDP;
• поддержка конвейеров и фильтров Unix, что позволяет разра-
батывать различные сценарии сетевых соединений, которые будут
полезны при исследовании и тестировании МЭ.
160
7.3. Анализаторы и генераторы трафика
Несмотря на многообразие средств исследования и тестиро-
вания МЭ, пожалуй, самыми необходимыми и универсальными сред-
ствами являются сетевые анализаторы трафика. Анализаторы тра-
фика в первую очередь предназначены для решения задач
диагностики сетей, которая подразумевает измерение текущей на-
грузки, выявление причин ошибок передачи, сбор различных ста-
тистических данных и т. п.
Анализаторы трафика выполняют перехват и последующий ана-
лиз (представление содержимого пакета по уровням модели OSI)
всех пакетов в рамках одного физического сегмента сети. В зави-
симости от класса решаемых задач анализаторы трафика бывают
программными, аппаратными или программно-аппаратными, мо-
гут выполнять анализ в реальном или отложенном режимах време-
ни, поддерживать различное количество декодируемых протоко-
лов, собирать данные при помощи агентов с различных физических
сегментов и поддерживать другие функции. Например, ряд анали-
заторов автоматически (на основе измерения временных парамет-
ров) обнаруживают и уведомляют администратора о некоторых
событиях, что позволяет создать простейшую систему обнаруже-
ния DoS-вторжений.
Использование анализаторов в режиме мониторинга трафика
позволяет наблюдать динамику изменения сетевой активности,
получать графики распределения протоколов и активности хостов,
матрицы взаимодействия хостов и т. п. (рис. 7.10). Сетевые адми-
нистраторы обязательно должны периодически использовать этот
режим и в целях мониторинга безопасности, что способствует вы-
явлению, например, необычной активности пользователей и прило-
жений, злоупотребления сотрудниками рабочим временем (сете-
вые игры, посещение узлов сомнительного содержания), а также
использования протоколов, не входящих в стек TCP/IP.
Большинство коммерческих анализаторов имеет в своем со-
ставе генераторы трафика. Генераторы трафика позволяют при
помощи шаблонов и конструкторов быстро создавать и отправлять
любую последовательность тестовых пакетов. При этом сам ана-
лизатор выполняет анализ реакции МЭ на отправленные пакеты.
Например, можно имитировать различные DoS-атаки, 1Р-спуфинг,
пакеты с некорректными полями и контрольными суммами и т. п.
6 Лебедь С.В.
161
Os
©И Qgnft7ur«utx< Ию»» tStxMe M6f*W View* G«lbjr« View* J>j*S JMndow tt*>
feMKfy ^niiKVM'MwoitSsMkieiOth' M;i9:S6
Рис. 7.10. Анализатор трафика Shomiti Surveyor в режиме мониторинга трафика
При исследовании МЭ анализаторы трафика позволяют:
• выполнять детальный анализ сетевых пакетов на соответству-
ющих уровнях модели OSI;
• анализировать реакцию МЭ на различные тестовые последо-
вательности пакетов и другие сетевые события;
• исследовать режимы или особенности функционирования NAT;
• контролировать особенности преобразования пакетов, прохо-
дящих через интерфейсы МЭ из защищенной сети в незащищен-
ную сеть и наоборот;
• обнаруживать различные ошибки МЭ как сетевого устрой-
ства, а также некорректности подключенных к нему коммуника-
ций (ошибки сетевых адаптеров, ошибки маршрутизации и др.).
В табл. 7.1 представлены некоторые средства анализа сетево-
го трафика.
Таблица 7.1. Средства анализа сетевого трафика
Анализатор трафика Адрес Интернет ОС
Tcpdump WinDump (аналог tcpdump для Windows) Ethereal SpyNet Shomiti Surveyor Microsoft Network Monitor Sniffer Pro Iris www.tcpdunp.org netgroup- serv.polito.it/windunp www.ethereal.com www.shomiti.com www.microsoft.com www.sniffer.com www.eeye.com UNIX Windows 9x, NT, 2000 UNIX, Windows 98, NT Windows 9x, NT, 2000 Windows 9x, NT, 2000 Windows NT, 2000 Windows NT, 2000 Windows 9x, NT, 2000
Критериями выбора анализаторов трафика являются прежде
всего качество декодирования и типы поддерживаемых интерфей-
сов.
7.4. Методика проверки инспекторов состояний
Практически все производители коммерческих экспертных МЭ
заявляют, что их изделия поддерживают технологию инспекторов
состояний. Шлюзы сеансового уровня, инспекторы состояний
(statefull inspection), динамические фильтры, TCP/UDP-посредники
(TCP/UDP proxy) - в большинстве случаев под этими технологиями
6'
163
МЭ понимается следующее: ни один сетевой пакет не будет
пропущен, если он не принадлежит к некоторому виртуально-
му соединению, ассоциированному МЭ с ранее установленным
соединением. Исключение составляют пакеты, разрешенные по-
литикой безопасности МЭ и принадлежащие фазе установления со-
единения.
Сигналом МЭ к открытию виртуального соединения для ТСР-
соединений является инициализация процесса рукопожатия клиен-
та и сервера, а для дейтаграмм UDP - ответ сервера на отправлен-
ный пакет клиента в заданном промежутке времени. В большинстве
случаев проверить и сравнить декларируемые возможности МЭ
различных производителей не вызывает проблем. Тестирование же
инспекторов состояний вызывает ряд вопросов. Во-первых, под-
робные алгоритмы их функционирования производителями никогда
не раскрываются, а во-вторых, не существует специальных про-
граммных средств выполнения таких тестов. Между тем, прове-
рить базовые возможности инспекторов состояний достаточно
просто. Для этого необходимо создать следующую тестовую кон-
фигурацию (рис. 7.11). Во внешней и внутренней сети выделяются
клиент и сервер, необходимы два анализатора трафика, содержа-
щие встроенные генераторы трафика. Программные анализаторы
трафика могут быть установлены или на компьютеры клиента и
сервера, или на выделенные компьютеры (очень удобны программ-
ные анализаторы NetXRay компании Network General* и Shomiti
Surveyor компании Shomiti).
На МЭ устанавливается разрешающее правило для любой до-
ступной прикладной TCP-службы, например TELNET, HTTP и т. п.
Если МЭ имеет прикладного посредника для выбранной службы,
то его нужно отключить. Любые схемы аутентификации нужно
также отключить.
Анализатор
трафика
Анализатор
трафика
Рис. 7.11. Стенд тестирования инспекторов состояний
‘ В настоящее время на основе NetXRay разработан анализатор SnifferPro,
принадлежащий компании Network Associates.
164
Д NetXRay - LocalZPR0120 100Л10 Mbps PCI Bus Fast Ethernet Adapter (ACPI)„_1 - [telnet client Checkpoint, cap : 9/20... ВНЕ
£E E*J® Capture Packet Tools Window Help
|^|Я| Д|г<«| i«|« |»|»м| р|л-|дк| &t|Q|ldi|<S|a|g |^| G|
10.0.0.40
No. [Status |Scxjrce Address
Ok
F 12 Ok 10.0.0.40
194 . t
F 14 Ok 10.0.0.40
|Layer I Summary*
|Pest Address jtayer Isummary |l_en |r el. T ime
194.67.88.201 TCP Теlnet->1034,S-l647108527,A-44076,»-32S‘68
10.0.0.40
lTELNE'1103 4
S = 44&
;^глтк«тв1йЖк?^аэ4^-ж«
194.67.08.201 TCP Telnet—>1034, S-16'.
0:00:^
325* 68
0:00:—
Find Packet..
Go to...
Go to First Packet
Go to Last Packet
Display Options...
194.67.88.201 TCP Теlnet->1034,S-16*
Telnei~>103< S*1S4
io. о .ТЕыге: '1о.з4ч>те1пвс, s-44 j
325* 68 0:00:
~ i «-J
Mark Range.
Checksum: 0x2180
Q IP address 194.67.88.201 ->10.0.0.40
< No option
Transmission Control Protocol
Port 1034 ------> Telnet
C?} Sequence Number: 44085
Oil Acknowledgement. Number: 1647188533
C) Header LengthJMSB 4 bits) : 5 (32-bix word)
Cl Reserved(LSB 4 bits) : О
+ Qcode: ACK,PSH,
Apply Display Filter...
Edit Display Filter...
Send Current Packet.
Send Current Butter...
|\ Decode Хма^Ьс X,Host X Protocol
Send current packet
в ГТ
Рис. 7.12. Программный анализатор трафика NetXRay компании Network General
Цель тестирования - проверить, что ни один сетевой пакет, не
принадлежащий открытому текущему соединению между клиен-
том и сервером, не будет пропущен через МЭ. Для этого необходи-
мо выполнить следующие действия:
1) запустить оба анализатора трафика;
2) открыть разрешенное соединение между клиентом и серве-
ром, при этом регистрируется сетевой трафик в обоих сегментах
сети;
3) закрыть соединение с клиентом обычным образом на при-
кладном уровне (TELNET - logout (exit), POP3 - QUIT);
4) остановить регистрацию трафика сетевыми анализаторами.
В результате выполнения этих действий получаем «снимки» со-
единения в обоих сетевых сегментах. Помимо непосредственного
анализа заголовков пакетов (TTL, адреса, порты, номера последо-
вательностей), мы получили также набор тестовых пакетов, кото-
рые теперь не нужно создавать вручную, и самое главное, - эти
пакеты принадлежали разрешенному политикой безопасности со-
единению.
Теперь можно приступить непосредственно к самому тестиро-
ванию. Первый тест заключается в проверке прохождения через
МЭ произвольного пакета из полученного «снимка» при отсутствии
открытых соединений. МЭ, декларирующий инспекцию состояния,
не должен пропустить ни один такой пакет (конечно, кроме SYN-
пакетов, открывающих соединение).
Тестирование состоит из следующих шагов:
1) запустить оба сетевых анализатора;
2) из полученного внешнего «снимка» выбрать произвольный
TCP-пакет с IP-адресом отправителя, равным адресу клиента, и
IP-адресом назначения, равным адресу сервера;
3) отправить с помощью генератора трафика выбранный пакет
через МЭ;
4) остановить анализаторы трафика;
5) провести анализ пакетов, зарегистрированных анализаторами.
На этом этапе ни один сетевой пакет не должен быть пропу-
щен инспектором состояний.
Следующий тест проверяет, будет ли пропущен сетевой пакет,
принадлежащий текущему открытому TCP-соединению, но отправ-
ляемый «не в свое время». Сложность этого теста заключается в
том, что изначально отсутствуют данные о параметрах виртуаль-
ного соединения, создаваемого МЭ. Особенно важным и неизвес-
тным параметром в данном случае является диапазон допусти-
мых номеров последовательностей. В предположении, что диапазон
номеров последовательностей начинается с начальных номеров
166
инициализации TCP-соединения, можно предложить следующий ал-
горитм действий.
1) запустить оба анализатора трафика;
2) открыть разрешенное ТСР-соединение;
3) поддерживать соединение открытым (например, путем пе-
редачи данных или команд на прикладном уровне);
4) остановить сетевой анализатор внешней сети;
5) выбрать пакет из снимка (при необходимости могут быть
изменены номера последовательностей или другие параметры па-
кета);
6) отправить выбранный пакет через МЭ, при этом ТСР-соеди-
нение остается открытым;
7) остановить анализатор.
Тестирование можно повторить несколько раз, изменяя усло-
вия п. 5. Тестовые пакеты не должны пройти через инспектор со-
стояний. Это обязательно, если номера последовательностей тес-
товых пакетов установлены на заведомо меньшие значения, чем в
первом SYN-пакете.
Предлагаемая схема позволяет исследовать и особенности
реализации NAT. Результаты тестов для одного и того же МЭ при
включенной и выключенной NAT, естественно, будут различными.
Если при включенной NAT тестируемый МЭ для проходящих па-
кетов не изменяет номера последовательностей пакетов (и тем
более, номера портов!), то можно сделать однозначный вывод о
декларируемом инспекторе состояния - он просто отсутствует.
Ниже приведены результаты тестирования двух хорошо извес-
тных МЭ FireWall-1 4.0 NT компании Check Point и CyberGuard 4.2
NT одноименной компании:
Тест FireW all-1 4.0 NT* Check Point CyberGuard 4.2 NT** CyberGuard
Произвольный пакет при отсутствии разрешенных ТСР-соединений Произвольный пакет при активном разрешенном Т СР-соединений Пропущен Пропущен He пропущен He пропущен
* В версии 4.1 SP2 этот недостаток устранен (см. главу Обзор МЭ.
Checkpoint FireWall-1). Все пакеты, не принадлежащие ни к одному
установленному соединению блокируются и генерируется сообщение:
drop...unknown established TCP packet.
* * Без установленной опции Apply to established connections.
Выводы делайте сами!
167
8. ОБЗОР МЕЖСЕТЕВЫХ ЭКРАНОВ
На сегодняшний день рынок сегментных МЭ представлен более
50-ю компаниями-производителями. Наблюдается бурный рост и на
рынке персональных экранов. Продукты даже одного производите-
ля могут сильно отличаться от версии к версии или в зависимости от
платформы, что также затрудняет выбор конкретного продукта. В
главе рассмотрены наиболее яркие представители соответствующих
классов и уровней МЭ.
8.1. Check Point FireWall-1
http ://www. checkpoint, com
Уровень Экспертный
Класс Enterprise
Инспектор состояний Да
Версия 4.1 SP2
Израильская компания Check Point, один из старейших произ-
водителей МЭ, на сегодняшний день является безусловным миро-
вым лидером рынка МЭ. Почти половина всех инсталяций МЭ при-
надлежит именно этой компании. В основном продукте компании
МЭ VPN-1/FireWall-1 интегрированы все передовые технологии
обеспечения безопасности внешнего периметра, а предоставляе-
мое компанией API открытой спецификации OPSEC позволяет раз-
рабатывать собственные или использовать продукты третьих фирм,
усиливающие или дополняющие защитные функции FireWall-1.
FireWall-1, как ни один другой МЭ, имеет широкий набор функ-
циональных возможностей и поддерживаемых технологий. Рассмот-
рим только его уникальные возможности, а также те из них, кото-
рые выделяют его среди других МЭ экспертного класса.
Архитектура МЭ VPN-1 /FireWall-1
FireWall-1 относится к экспертному классу МЭ (рис. 8.1). Под-
держка технологии инспекции состояний (Stateful Inspection) в
этом продукте имеет более широкое значение.
168
Рис. 8.1. Архитектура МЭ FireWall-1 Check Point
Модульная структура FireWall-1 включает следующие три ком-
понента:
• графический интерфейс пользователя (GUI);
• сервер управления (Management Server);
• модули FireWall (FireWall Module).
Политика безопасности определяется и управляется при помо-
щи интуитивно понятного графического интерфейса пользователя.
Редактор Check Point Policy Editor позволяет определять ПБ в тер-
минах сетевых объектов (network objects) и правил безопасности
(security rules). Редактор не разрешает использовать непосредствен-
но в правилах характеристики объектов защищаемой сети (IP-ад-
реса, сети, протоколы). Администратор предварительно выполня-
ет описание используемых сетевых объектов (workstation, network,
domain, router, switch, integrated firewall, group, logical server, address
range, gateway cluster). Такой подход обеспечивает универсаль-
ность, гибкость и исключает ошибки пользователя при определе-
нии ПБ. Графический интерфейс пользователя GUI реализован в
виде отдельной программы Management Client.
Сервер управления хранит ПБ, разработанную и введенную при
помощи GUI; БД, содержащие описание сетевых объектов, пользо-
вателей; файлы журналов для каждой точки, на которой установ-
лен модуль FireWall. Сервер управления и средства GUI могут быть
установлены на одной машине или взаимодействовать в клиент-сер-
верной конфигурации.
169
Рис. 8.2. Функции модулей VPN/FireWall
и Inspection
Модуль FireWall непосредственно выполняет функции защиты,
реализуя ПБ, разработанную при помощи GUI. Модуль FireWall
содержит Inspection Module и VPN-1/FireWall-1 Security Servers
(рис. 8.2). Inspection Module выполняет контроль сетевого трафика
согласно ПБ, a Security Servers выполняют функции аутентифика-
ции и контроля безопасности содержимого (Content Security) на при-
кладном уровне. Политика безопасности, введенная посредством
GUI, преобразуется в скрипт языка INSPECT, компилируется, и
скомпилированный код устанавливается на одну или несколько
платформ, поддерживающих модуль FireWall.
Модули Management Module, VPN/FireWall Module, SecureServer
могут быть установлены на следующие платформы: Windows NT
4.0, Solaris (2.6-2.7), HP-UX (10.20,11.0), IBM AIX (4.2.1,4.3.2),
Red Hat Linux 6.1 (kernel 2.2.x).
Маршрутизаторы корпоративной сети представляют первый
эшелон обороны внешнего периметра безопасности. FireWall-1 по-
зволяет возложить часть ПБ на маршрутизаторы и МЭ третьих про-
изводителей. В табл. 8.1 представлены поддерживаемое FireWall-1
оборудование и возможности по его управлению.
Существует возможность непосредственной установки моду-
лей VPN/FireWall и INSPECTION на устройства третьих произво-
дителей (Embedded Systems and Appliances). В версии 4.1 поддер-
живаются системы Bay RS, Bay SEC, Xylan Switch и Nokia.
170
Таблица 8.1. Поддерживаемые FireWall-1 маршрутизаторы
и «черные ящики»
Платформа, версия Правила фильт- рации (Accept/ Rejec) Защита от спу- финга Уста- новка пара- метров Про- TOKO- лиро- вание и уведом- ление Приме- нение послед- него правила «Reject АН» Конт- роль соеди- нения «FTP Data» Импорт ACL
Маршрутизаторы Bay Networks Y Y Y Y N — —
Маршрутизаторы ЗСот Y Y Y Y Y Y Y
Маршрутизаторы Cisco 9 Y N Y Y Y — —
Маршрутизаторы Cisco 10 и выше Y Y Y Y Y Y Y
Cisco PIX Firewall 3.0, 4.x Y N N Y Y — Y*
Microsoft Stealhead Y* N Y* N Y* N Y
* Существуют некоторые ограничения или особенности использования.
Аутентификация
FireWall-1 поддерживает большое количество различных алго-
ритмов и схем аутентификации. Одна из примечательных особен-
ностей этого изделия заключается в возможности выполнения стро-
гой аутентификации любой сессии, даже если она не поддерживает
аутентификацию на прикладном уровне, а также аутентификации
пользователей в среде с динамическим адресным пространством.
Такая возможность обеспечивается двумя средствами:
• программным компонентом Authentication Agent, который ус-
танавливается на компьютеры пользователей;
• использованием дополнительного продукта MetalP, который
управляет процессом динамического распределения IP-адресов в
локальной сети и отслеживает строгое соответствие пользовате-
лей и назначаемых им адресов.
Координированный контроль доступа в нескольких точках
и централизованное управление средствами безопасности
Распределенная архитектура комплекса VPN-1/FireWall-1, ин-
теграция средств контроля доступа и средств VPN, а также тес-
171
ная интеграция всех продуктов компании Check Point в едином ин-
терфейсе управления позволяют обеспечить полнофункциональную
защиту в нескольких точках корпоративной сети. Администратор
сетевой безопасности с любой точки сети может осуществлять
управление политиками безопасности шлюзов (FireWall Module),
определять списки контроля доступа пограничных маршрутизато-
ров, выполнять мониторинг и аудит событий.
При необходимости ПБ шлюзов могут синхронизироваться, что
позволяет корректно поддерживать сессии при динамических из-
менениях маршрутов.
Прикладные посредники
Усиление защитных функций МЭ при контроле данных на при-
кладном уровне достигается в МЭ FireWall-1 несколькими спосо-
бами:
• использование встроенных посредников Security Servers.
Security Servers являются полнофункциональными прикладными по-
средниками служб TELNET, RLOGIN, FTP, HTTP, SMTP, позволя-
ющими контролировать безопасность содержимого (с помощью
CVP), выполнять дополнительную аутентификацию службы и кон-
тролировать другие параметры, специфичные для каждой службы;
• применение продуктов третьих производителей, использую-
щих компоненты спецификации OPSEC. Примером таких компо-
нентов являются:
- С VP (Content Vectoring Protocol) сервер, выполняет контроль
содержимого,
- UFP (URL Filtering Protocol) сервер, выполняет категорирова-
ние URL;
• использование механизмов технологии Statefill Inspection. Этот
способ не контролирует полноценно данные на прикладном уровне, и
не выполняет посредничества, но позволяет значительно усилить бе-
зопасность сетевых соединений. FireWall-1 под держивает более 100
прикладных служб. Для большинства из этих служб на языке INSPECT
определены соответствующие правила ПБ (файл base.def).
Обнаружение вторжений и аномальной активности
МЭ FireWall-1 имеет две возможности обнаружения вторже-
ний. Первая заключается в использовании встроенной технологии
MAD (Malicious Activity Detection - обнаружение необычной ак-
тивности). MAD основывается на анализе файлов журнала регист-
172
рации событий и позволяет обнаруживать следующие атаки и со-
бытия: чрезмерный рост уведомлений системы сигнализации, ска-
нирование портов, сканирование запрещенных портов, ошибки
аутентификации, чрезмерное количество открытых соединений,
поступающих на один и тот же порт от одного источника, TCP SYN
Flood, Spoofing. Для каждой атаки понятие «чрезмерного количе-
ства» определяется индивидуально.
Вторая возможность заключается в использовании отдельного
продукта Check Point RealSecure, являющегося совместным про-
дуктом двух лидеров средств защиты информации - компаний
Internet Security Systems и Check Point.
Система Check Point RealSecure позволяет:
• автоматически анализировать и сопоставлять в реальном вре-
мени данные мониторинга событий, происходящих в сетевых сег-
ментах и узлах корпоративной сети;
• обнаруживать попытки взлома системы защиты. Постоянно
обновляющаяся база знаний включает несколько сотен известных
образцов атак;
• при обнаружении атаки или подозрительной активности:
- автоматически предупреждать администратора системы с
помощью уведомлений различного типа,
- регистрировать событие в системном журнале,
- автоматически блокировать атаки или несанкционированные
действия путем реконфигурации МЭ;
• генерировать отчеты разной степени подробности;
• «проигрывать» зарегистрированные события для детального
анализа или для использования в качестве доказательства факта
нарушения.
Поддержка технологии VPN
Спектр VPN-продуктов, выпускаемых компанией Check Point,
позволяет на основе открытых стандартов (IPSec, SKIP, IKE, сер-
тификаты Х.509, PKI) и собственного протокола FWZ организо-
вать полнофункциональную VPN-сеть шлюз-шлюз и/или шлюз-кли-
ент. Поддержка открытых стандартов гарантирует взаимодействие
с VPN-продуктами других производителей.
Удаленные пользователи могут использовать два VPN-клиента
- VPN-1 SecureRemote и VPN-1 SecureClient. VPN-1 SecureRe-
mote поддерживает стандарты IPSec, IKE и цифровые сертификаты,
что позволяет устанавливать VPN-соединения не только со
шлюзами своего предприятия, но и со шлюзами предприятий-
173
партнеров. Продукт VPN-1 SecureClient добавляет к возможностям
SecureRemote функции контроля доступа на основе технологии
Check Point Statefill Inspection. SecureClient позволяет усилить
защиту предприятия за счет контроля VPN-шлюзом конфигурации
клиента. Соединение разрешается клиенту лишь в том случае, когда
конфигурация безопасности его компьютера соответствует
установленной администратором предприятия.
Балансировка нагрузки и поддержка QoS
Модуль FloodGate-1 позволяет управлять балансировкой нагрузки
нескольких серверов и распределять имеющуюся полосу пропус-
кания между прикладными службами.
Другие продукты Check Point
Кроме МЭ FireWall-1, компания Check Point предлагает ряд до-
полнительных продуктов, расширяющих функции защиты FireWall-1
или используемых автономно:
• VPN-1 Appliance - аппаратное решение на платформе Nokia,
которое обеспечивает быстрое развертывание высоконадежной
корпоративной системы безопасности;
• VPN-1 Accelerator Card - PCI-карта, совместимая с SUN
Solaris и Windows NT-платформами. Предназначена для увеличе-
ния производительности VPN-шлюза;
• VPN-1 SecureRemote/SecureClient - VPN-клиенты;
• VPN-1 Certificate Manager - средство реализации инфраструк-
туры открытых ключей на базе продуктов VPN-1. Комплекс по-
зволяет организовать IPSec/IKE-соединения между различными
сетями или отдельными клиентами с применением сертификатов
Х.509;
• Account Management Module - позволяет легко интегрировать
FireWall-1/VPN-1 в имеющуюся инфраструктуру на основе LDAP
и получать необходимые системе безопасности данные о пользо-
вателях как с одного, так и нескольких серверов LDAP;
• Reporting Module - универсальное средство мониторинга и
аудита сетевого трафика защищаемой сети;
• Check Point Real Secure - система обнаружения вторжений
(IDS), которая имеет обратную связь с FireWall-1 и позволяет ав-
томатически переконфигурировать МЭ при обнаружении вторже-
ний;
• High Availability Module - объединяет в кластеры шлюзы
FireWall-1/VPN-1, что обеспечивает необходимое резервирование
для создания безотказных конфигураций. При выходе из строя или
174
недоступности основного МЭ осуществляется автоматическое пе-
реключение системы на работу с резервным шлюзом, при этом
сохраняются все таблицы состояний соединений, в том числе и
использующие IKE совместимый VPN;
• Compression Module - обеспечивает компрессию между шлю-
зами FireWall-1/VPN-1, что существенно повышает скорость об-
мена между ними;
• ConnectControl - позволяет обеспечить гибкое регулирование
сетевой нагрузки на серверы приложений;
• FloodGate-1 - система управления приоритетами трафика;
• Meta IP - автоматизированная система управления IP-про-
странством предприятия. Используемая технология User-to-Address
Mapping (UAM) обеспечивает однозначное сопоставление аутен-
тифицированного имени пользователя и принадлежащего ему IP-
адреса;
• Provider-1 - многофункциональная система управления поли-
тиками безопасности, ориентированная на сервис-провайдеров;
• MultiGate - предоставляет возможность крупным предприя-
тиям и провайдерам сетевых услуг реализовывать высокотехно-
логичные точки присутствия, обеспечивающие в том числе услуги
ИБ.
Технология Stateful Inspection компании Check Point
Компания Check Point разработала и использует в своих про-
дуктах технологию Stateful Inspection. Данная технология основа-
на на шлюзах сеансового уровня незначительно расширена по срав-
нению с классическими инспекторами состояний.
В отличие от шлюзов сеансового уровня, таблицы виртуаль-
ных соединений которых содержат информацию, извлекаемую толь-
ко из полей заголовков сетевых и транспортных протоколов, Stateful
Inspection оперирует понятием контекста. Контекст изменяется
динамически и отображает текущее состояние соединения, осно-
вываясь на анализе следующей информации и событий:
• информация заголовков полей сетевых и транспортных прото-
колов;
• информация, наследованная из предыдущих этапов сетевого
взаимодействия;
• информация, наследованная на прикладном уровне и из собы-
тий безопасности МЭ.
Например, ранее аутентифицированный пользователь должен
быть допущен только к авторизованным сервисам, и нет необходи-
мости выполнять авторизацию для каждой открываемой приклад-
ной сессии.
175
Каждая фаза сетевого взаимодействия может иметь свое от-
ражение в виде собственного уникального контекста. Все сетевые
пакеты аутентифицируются со своими контекстами, и в случае
неуспешной аутентификации пакет будет запрещен. Тем не менее,
чтобы задействовать механизмы контекстов, для каждого приклад-
ного протокола должны быть приняты специальные меры, учиты-
вающие особенности этих протоколов. Проверить, как МЭ реали-
зует защиту того или иного сервиса, можно, просмотрев файл
base. def. Если сценарий для искомого сервиса отсутствует, то
FireWall-1 до версии 4.1 SP2 без использования аутентификации
выполняет обработку сервиса (правила) как пакетный фильтр! И
только версия 4.1 SP2 дополнена полноценным инспектором со-
стояний (см. Методика проверки инспекторов состояний, стр. 163).
Все операции над контекстами выполняет так называемая вир-
туальная машина INSPECT Virtual Machine, работа которой состо-
ит из следующих шагов (рис. 8.3).
Рис. 8.3. Взаимодействие модулей VPN-l/FireWall-1
Сначала при помощи графического редактора формируются
правила ПБ. Политику безопасности можно увидеть на экране, выб-
рав меню Policy -> View. Она представляет собой скрипт, написан-
ный на языке INSPECT (Inspection Script). Скрипт Inspection script
(*.pf) получается в результате преобразования файла ПБ (*.w).
Файл правил ПБ, Inspection script и другие описания объектов хра-
нятся на сервере управления, имеют текстовый формат и их мож-
но редактировать в любом текстовом редакторе.
Далее файл ПБ компилируется посредством INSPECT Compiler.
Результатом компиляции является файл Inspection Code (*.fc). Это
позволяет получить высокие показатели производительности, по-
скольку вся ПБ размещается в оперативной памяти в виде испол-
няемого кода.
Затем исполняемый код (Inspection Code), полученный на вы-
ходе компилятора, устанавливается непосредственно на МЭ
(Firewalled gateway). Сервер управления позволяет управлять не-
сколькими шлюзами с различными или синхронными ПБ.
Язык МЭ FireWall-1 INSPECT
Язык МЭ INSPECT - объектно-ориентированный, высокоуров-
невый язык сценариев, который определяет дальнейшую обработ-
ку сетевого пакета путем классификации его содержания (content)
и состояния (state). Механизм (engine) INSPECT позволяет выпол-
нять проверку содержимого пакетов на всех уровнях, начиная с
сетевого.
Поскольку INSPECT изначально разрабатывался как язык МЭ,
то и результирующие действиями над пакетом определяются пра-
вилами ПБ (Source, Destination, Services, Action, Track, Install On).
Например, правило ПБ, определенное в Check Point Policy Editor как:
No. Source |Destination Service | Action | Track Install On Time
|e ьмр
localnet
Any
accept
и Gateways © Any
трансформируется в следующий сценарий:
(rule-1
: src (
: localnet
)
: dst (
: Any
177
:services (
: http
)
:action (
: (accept
:type (accept)
:color («Dark green»)
.•macro (RECORD_CONN)
:icon-name (icon-accept)
:text-rid (61463)
:windows-color (green)
)
)
:track (
: Short
)
:install (
: (Gateways
: type (gateways)
:color («Navy Blue»)
:icon-name (icon-gateways)
)
)
: time (
: Any
)
)
Язык сценариев INSPECT имеет следующие особенности:
• не допускает циклических операций;
• осуществляет проверку условий - если часть выражения оце-
нена как ЛОЖЬ, то остальная часть выражения не рассматрива-
ется;
• в нем отсутствуют механизмы распределения памяти;
• аргументы функций передаются только по значению;
• функции не поддерживают рекурсию;
• функции возвращают всегда одно значение;
• исходный текст находится в одном файле и не допускает ни-
каких внешних связей. Разрешается директива С-препроцессора
tfinclude;
• пространство имен (названия макросов, функций, таблиц и
форматов) начинается в конце секции определения имен и сохра-
няется до конца файла.
178
Основой языка INSPECT является механизм динамических таб-
лиц (Dynamic Tables), который и позволяет создавать и управлять
контекстами соединений технологии Stateful Inspection. Динамичес-
кие таблицы определяются следующим образом:
table-name = dynamic {} ;
где table-name - имя создаваемой таблицы. В фигурных скоб-
ка^ определяются опциональные параметры:
expcall — вызов по номеру функции ядра МЭ при истечении
времени жизни таблицы;
expires п — записи, к которым не обратились в течение п
секунд, удаляются из таблицы. В дальнейшем этот
атрибут может быть переопределен при выполнении
операции записи в таблицу;
free — вызов функции х при удалении записи или
function х истечении времени expires п;
hashsize — размер хэша (hash). Рекомендуется, чтобы он был
близок к размеру таблицы;
implies — запись, удаляемая из динамической таблицы, будет
table_name также удалена и из таблицы table_name;
kbuf х — аргумент х является указателем на внутреннюю
структуру данных (обычно используется при
шифровании);
keep — сохранять записи таблицы, даже если ПБ (Security
Policy) переустановлена;
limit х — ограничить эту таблицу максимальным значением х
записей;
nexpires — элементы таблицы не устаревают, но удаляются при
явном удалении. Параметр устанавливается по
умолчанию;
refresh — сброс таймера при обращении к записям;
synch — синхронизировать эту таблицу при использовании
синхронизации VPN-1/FireWall-1.
Для каждого протокола определяются индивидуальные атри-
буты контекста, хранящиеся в динамических таблицах. Например,
в главе Уязвимости информационной безопасности межсетевых
экранов показано, каким образом возможна организация скрытно-
179
го канала передачи данных на основе протокола ICMP. В этом
случае контекст определяется из следующего условия - ICMP-
сообщения от исследуемых хостов (ping) или маршрутизаторов
(traceroute, tracert) могут быть пропущены в локальную сеть толь-
ко в том случае, если эти отклики инициализированы хостами ло-
кальной сети. Тогда контекст для ping должен хранить следующую
информацию:
• IP-адрес источника (src);
• IP-адрес получателя (dst);
• идентификатор ICMP-сообщения icmp_ip_id;
• номер ICMP-сообщения icmp_ip_seq,
а операции записи и сравнения с контекстом будут выглядеть со-
ответственно следующим образом:
record <src,dst,icmp_ip_id; icmp_ip__seq> in ping_table
icmp_ip_seq = ping_table [dst,src,icmp_ip_id]
Рассмотрим пример реализации безопасного механизма исполь-
зования протокола ICMP. Комментарии переведены на русский
язык. В некоторых случаях автор для лучшего понимания включил
собственные дополнительные пояснения.
// Файл: icmpl3. def
//
// Stateful icmp vl.3 William D. Bums (shadow@netscape.com)
// (c) Copyright 1997,1998,1999 Netscape Communications
// first released August 17, 1997. Last updated: August 3,1999
//
// ICMP INSPECT SCRIPT
//
//
// ==============================================
// Секция определения переменных
// в версии 4 уже определено
// #define icmpicmpseq [54:2,b]
// ==============================================
// расположение icmp sequence number
#define icmp ip seq [24:2,b]
//определение времени жизни записей в динамических таблицах
#define Timeout 5
//определение динамических таблиц
ping table = dynamic {} expires Timeout;
mstrttable = dynamic {} expires Timeout;
180
unixtrttable = dynamic {} expires Timeout;
// ==============================================
// Секция определения пакетов
// ==============================================
// ==============================================
// пинг-запрос имеет вид:
//
#define is_ping_request (icmp, icmp_type=ICMP_ECHO)
// ==============================================
// запрещение входящих фрагментированных пакетов
//
#define not_fragmented (((ip_off & 0x2000) = 0) )
// ===========================================
// корректный пинг-ответ имеет следующий вид:
//
#define is_ping_reply (icmp, icmp_type=ICMP_ECHOREPLY)
// =========================================
// определение пакета ICMP Time exceeded (type 11)
//
#define is_timxceed_reply (icmp, icmp_type=ICMP_TIMXCEED)
// =============================================
// определение пакета unix traceroute
//
#define is_traceroute_request(udp, uh_dport >33000,ip_ttl< 30)
// =========================================
// определение ответного пакета unix traceroute
//
#define is_dstunreach_reply (icmp, icmp_type = ICMP_UNREACH)
// ==================================
// Начало секции отслеживания и принятия решений
// ========================================
// ==============================================
// ICMP echo request
//
// Если пакет является ICMP echo запросом
// и не фрагментирован, то
// - записать в таблицу ping table
// - ответы на запрос должны прийти от адресата
// или, если пакет отправлен программой tracert.exe Microsoft
// - записать в таблицу ms trt table
// - ответы на запрос должны прийти от адресата
181
// или маршрутизаторов на пути следования пакета
//
#define ping__request__accept ( \
is_ping_request, not_fragmented, \
record <src,icmp_ip_id; icmp_ip_seq> in ms_trt_table, \
record <src,dst,icmp_ip_id; icmp_ip_seq> in ping_table
\
)
// ==============================================
// Анализ получаемых пакетов ICMP echo reply
//
// разрешить пакет, если он соответствует
// ранее зарегистрированному пакету echo-request
//
#define ping__reply_intercept ( \
is_ping_reply, not_fragmented, \
accept ( \
icmp_ip_seq = ping_table [dst,src,icmp_ip_id], \
delete <dst, icmp_ip_id> from ms__trt_ table, \
delete <dst,src,icmp_ip_id> from ping_table \
or (log icmp_long, drop) \
) \
)
// ==============================================
// Анализ получаемых пакетов ICMP time exceeded
//
// разрешить пакет, если ему соответствует
// ранее зарегистрированный
//
#define timxceed_reply_intercept ( \
is_timxceed_reply, not_fragmented, \
accept ( \
(icmp_ip_seq = ms_trt_table [dst,icmp_ip_id] \
or \
icmp_uh_dport = unix_trt_table [dst,icmp_uh_sport]), \
delete <dst,icmp_ip_id> from ms_trt_table, \
delete <dst,icmp_uh_sport> from unix_trt_table \
or (log icmp_long, drop) \
) \
)
// ==============================================
// Секция traceroute UNIX
// ==============================================
//
// Отслеживаем любые пакеты, похожие на «traceroute»
// и записываем их в таблицу unix trt table
//
182
И Отклики должны быть подобны
// tracert.exe Microsoft (icmp type И), но будут
// включать icmp type 3
// ==============================================
// Анализ пакетов Traceroute Request UNIX
//
// Согласно RFC, UDP порты источника и назначения
// ДОЛЖНЫ быть в ответном пакете.
// Ответы будут проверяться по этому критерию.
//
//define traceroute__request__accept ( \
is_traceroute_request, \
record <src,uh_sport;uh_dport> in unix_trt_table \
)
// ==============================================
// Анализ пакетов ICMP Destination Unreachable
//
// Разрешаем пакет, если для него существует
// ранее зарегистрированная пара
//
//define dstunreach__reply__intercept ( \
is_dstunreach_reply, not_fragmented, \
accept ( \
icmp_uh_dport = unix_trt_table[dst,icmp_uh_sport],\
delete <dst,icmp_uh_sport> from unix_trt_table \
or (log icmp_long, drop) \
// =============================================
// ==============================================
// Секция проверки ответов ICMP
// =============================================
// ==============================================
// мы хотим разрещить только три типа ICMP-пакетов
// - echo reply (эхо-ответ) или
// - time exceeded (время жизни дейтаграммы истекло) или
// - destination unreachable (адресат недостижим)
//
//define ns__icmp__reply_intercept ( \
ping_reply_intercept or \
timxceed_reply_intercept or \
dstunreach_reply_intercept \
)
//Это необходимо указать в поле Prologue
//диалога User-Defined Service Properties
//редактора политики безопасности
183
и
# de fine ns_icmp_code { \
ns_icmp_reply_intercept; \
}
//конец файла
Чтобы использовать этот INSPECT-код, необходимо выполнить
следующие действия:
• скопировать файл icmpi3. def в директорию $FWDIR/fw/lib и
изменить файл $FWDIR/fw/lib посредством добавления после пред-
последней строки файла следующую строку:
#include «icmp12.def»
• отключить установки по умолчанию ПБ для протокола ICMP
- «Properties...[Allow ICMP»
• создать посредством редактора ПБ новый сервис с именем
ns_icmp (рис. 8.4):
service type=other; Match=ping_request_accept or
traceroute_request_accept;
Prologue=ns_icmp_code;
В поле Match указывается строка (идентификатор), на основании
которой FireWall-1 начинает выполнять действия, соответствующие
User Defined Service Properties
Рис. 8.4. FireWall-1: определение сервиса ns_ismp
184
правилу. В нашем примере МЭ должен начинать контролировать
политику «stateful icmp» при получении пакетов ping, traceroute и
tracert из локальной сети. Эти пакеты определены в макросах IN-
SPECT-КОДа ping_request_accept И trace-route_request_accept. В
простейшем случае может быть указан, например, транспортный
порт назначения dport = telnet. (Файл tcpip.def содержит предоп-
ределенные компоненты, которые можно использовать в вы-
ражениях.)
Определим новое правило с использованием нового сервиса:
permit from intranet to any, service=ns_icmp, action=long
log,
где intranet - определение адресного пространства локальной сети.
Необходимо сохранить новый набор правил и установить поли-
тику МЭ.
Для усиления безопасности протоколов не обязательно всегда
применять контексты (динамические таблицы). В ряде случаев до-
статочно использовать интеллектуальные «шаблоны сообщений
протокола», с которыми будут сравниваться аутентифицируемые
пакеты. Применение подробных шаблонов протоколов совместно
с контекстами позволяет усилить ПБ. Ниже приведен фрагмент
INSPECT-кода Check Point (файл base.def), определяющий прави-
ла обработки «опасного» протокола NetBios.
у* ********************************************** **************
* *
♦ NetBios *
♦ ♦
********************************************************************/
#define NBNAME 137
#defme NBDATAGRAM 138
/* NetBios Datagram Service */
#defme NBDSDATAGRAMTYPE [UDPDATA:1]
#define NBDS_DIRECT_UNIQUE (NBDSDATAGRAMTYPE = 0x10)
#define NBDS DIRECT GROUP (NBDS DATAGRAM TYPE = 0x11)
/* NetBios Name Service */
#defmeNBNS_XID
#define NBNSRESPFLAG
[UDPDATA:2,b]
((([(UDPDATA+2):1])» 7) & 0x01)
185
//define NBNS_REQUEST //define NBNSRESPONSE (NBNS_RESP FLAG = 0) (NBNS_RESP_FLAG = 1)
//define NBNSOPCODE //define NBNS_QUERY //define NBNSREGISTRATION ((([(UDPDATA+2):1]) » 3) & OxOf) (NBNS_OPCODE = 0x00) ((NBNSOPCODE = 0x05) or (NBNS_OPCO- DE = OxOf))
//define NBNSRELEASE //define NBNS_WACK //define NBNS_REFRESH (NBNSOPCODE = 0x06) (NBNS_OPCODE = 0x07) (NBNS_OPCODE = 0x08)
# define NBNSRC ODE //define NBNS_SUCCESS (([(UDPDATA+3):1]) & OxOf) (NBNSRCODE = 0)
//define NBDS_SRC_NAME_LEN //define NBDSDSTNAMELEN [UDPDATA + 14:1] [UDPDATA + 14 + NBDS_SRC_NAME_LEN + 2:1]
//define NBDS_SMB_DATA \
(UDPDATA +14 + NBDS_SRC_NAME_LEN + NBDSDSTNAMELEN + 4)
/* SMB */ //define SMB_DATA_OFFSET [NBDSSMBDATA + 57:2,1]
//define NETLOGONOPCODE [NBDSSMBDATA + SMBDATAOF- FSET:2,1]
//define LOGON_REQUEST //define LOGONRESPONSE (NETLOGONOPCODE = 0) (NETLOGONOPCODE = 6)
//define NBTXLATE 0
//define NBT UNXLATE 1
# define FWXSRC 0
//define FWXDST 1
#ifhdef NO XLATION
//define NBT_ANTICIPATE(host_offset,method) \
(call KFUNC_XLATE_ANTICIPATE \
<conn, BUILD_CONT_REV((method),0), 63, 0, 0, (host offset) >)
//define NBT PREDICT(offset) \
(call KFUNC XLATE PREDICT <offset,FWX_SRC,NBT_XLATE>)
//else
//define NBT_ANTICIPATE(host_offset,method) (1)
//define NBT PREDICT(offset) (1)
Z/endif
//define nbdatagramcode \
( \
udp, dport = NBDATAGRAM, \
NBDSDIRECTUNIQUE or NBDS DIRECT GROUP, \
186
(r_cdir != 2, NBT_ANTICIPATE(UDPDATA+4,1)) \
or \
(r_cdir = 2, NBT_ANTICIPATE(UDPDATA+4,3)) \
)
//define nbname_code \
( \
udp, \
( \
dport = NBNAME, NBNSREQUEST, \
NBNSREGISTRATION or NBNSRELEASE or NBNS_REFRESH,\
[(UDPDATA+64),b] = src, \
NBT_ANTICIPATE(UDPDATA+64,1) \
)or( \
sport = NBNAME, NBNSRESPONSE, \
( \
NBNSREGISTRATION or NBNSRELEASE or NBNS_REFRESH,\
NBT_ANTICIPATE(UDPDATA+58,4) \
)or( \
NBNSQUERY, NBNS_SUCCESS, direction = 0, \
NBT_PREDICT(UDPDATA+58) \
) \
) \
)
//define netbios_code nbdatagramcode or nbname_code;
Компания Check Point предоставила администраторам МЭ мощ-
ный механизм INSPECT, позволяющий создавать собственные ин-
теллектуальные правила обработки сетевых пакетов (контексты
соединений). Использование этого механизма требует от админи-
стратора не только глубоких знаний стека TCP/IP и прикладных
протоколов, но и хороших знаний самого языка. К сожалению, в
документации, прилагаемой к Fire Wall-1, практические особеннос-
ти использования языка не рассмотрены. Хорошим пособием в
изучении INSPECT послужит исследование файлов *.def дирек-
тории $FWDIR/fw/lib, в которых определены правила обработки
наиболее распространенных прикладных сервисов.
8.2. Axent Raptor FireWall
http ://www. axent. com
Уровень Экспертный
Класс Enterprise
Инспектор состояний Да
Версия 6.5
187
МЭ Raptor компании Axent занимает лидирующее положение
на американском рынке МЭ. В конце 2000 г. эту компанию приоб-
рела не менее известная компания Symantec. Raptor относится к
экспертному классу МЭ и поддерживает практически все возмож-
ности технологий защиты, используемых в МЭ. Межсетевой экран
Raptor работает как на платформе NT, так и на платформах Solaris,
НР-ЦХиТги64.
Продукт вызывает некоторые трудности при первоначальном
освоении. Это обстоятельство, в первую очередь, объясняется бо-
гатыми функциональными возможностями (большое количество на-
страиваемых параметров), а также насыщенностью графического
интерфейса управления (рис. 8.5). Интерфейс управления для плат-
формы NT выполнен в виде встраиваемого модуля (snap-in) ММС-
RMC (Raptor Management Console). Параметры конфигурации хра-
нятся в обычных текстовых файлах, которые можно редактировать
в любом текстовом редакторе.
13 ггасБЪ - (Cortsok: HootXAXCNT I eUinuloutvsVtaplui MdmKjement CuntokAfw {Connectt*<J)\MQnitonn<| CunUols\Loyhtes\Fcbtuaiy. 2 ИДС
111
fw
% Codiguration Reports
fw
fw
fw
Note
Note
Note
Note
Note
Note
Note
128
111
111
128
128
Wamng
Warring
Irfcwns..
Warning
Wamng
Warring
Informs. fw
Informs.. fw
Note fw
Note fw
S-A. AXENT Tachncfogiae
«Ф» Raptor Management Console
8 fw (Connected)
i-5 CJ Sate Component*
: ф DNS Record*
- ф Network Interfaces
Access Contiote
1 Rdet
I Эи Content Ptolies
t И1 HTTPDocumertCortert
: B-O Rating Rufe Ptrttes
: i '^RafangPhsee*
, Rating Modfcation*
e O NNTPRUeProOet
; : ф Newsgroup*
NewtgroMp Proflet
: "S Redeected Service*
: 3 NAT Pod*
fAdtkes* Transform*
H323A6e*«*
Proxy Services
Bi О Montaing Control*
ф NoMcaHon*
Я Acbve Connections
£ LogHe*
H t February. 2001
Homa fw
Iniorma. fw
Irtcrma. fw
infoma... fw
Informs...; fw
Informa...
informs.
Informs...
Inform».
Inlotma..
Inform».
Note
informs.,
inform».
Informs..
kernel
kernel
roadhawk
kernel
kernel
kernel
tend
readhawk
kernel
kernel
kernel
kame!
kernel
kernel
teadhawk
readhawk
readhawk
readhawk
readhawk
madhawk
readhawk
toadhawk
readhewk
toadhawk
rearbawk
kernel
readhawk
dnsd
dhsd
kernel
kernel
kernel
kernel
111
111
111
111
111
111
111
111
111
111
111
125243..
125247.
126250...
125251...
125255
125259..
125305...
125341...
1254.03...
1254:01..
1254.05.
1254.08..
125407...
1254:07..
125450.
125531..
125548..
1256.01.
125511..
125655..
1257:27...
125800...
125818..
125844...
125544...
125908.
12®t32..
130001..
130008.
130014..
130014.
130014 .
130014..
343
343
121
343
343
343
120
121
239
239
239
239
239
239
121
121
121
121
121
121
121
121
121
121
121
239
121
120
120
343
239
239
ArpWiny The hott 192168.0.1 it «pbg
Arp Waning The host 19216801 it arp’ng
Stetetitx duratron-0.20 id-X tent-31 rcvd-T
Arp Warning The host 192168.0.1 it «ping -
Arp Warner» The hwt 19216881 it «png,
Arp Warring The hot! 19216881 it агрЪдГ
dnsd Info: Fated to handte request from 127.
Statelier duta6on-O,2Oid.¥ *ert-31 rcwW ,
Setting TCP Reset« port (18184)not afoeC>
Serving TCP Reset at port (18184) not afo*A
Sendteg TCP Resets port П8184) not Mm»::
Serving TCP Retel at port (18184) not aloe;' .
Sendrq TCP Reset a* port (18184) net alow
Sendng TCP Retel a* port (18184) not Moe '
Statelet: duMtion-021 id-2 toni-31 rcvd-l;... -
Statetes duration-018id»10 tert»3l rcvd» '
Stattttex durabcn-0.20 id-11 tent-31 rcvd*
Statistics: duration-0.15 id-12 tent-31 tevrf- >.
StMntkx duration-014 id-13 tent-31 icvd»'-<
Statistic*; duaton-0.14 id-14 tert-31 tevd* \
Statelier duration-019 id-15 eert-31 revd- >
Statelier duration-019 id-16 «ent-31 revd-
Statelet; duration-016 id-17 tert-31 revtk
Statelet duration-2314 id-18 mnt-422 rev
Stateties. dutation-0.15 id-19 tert-31 tcvd«
Scndng TCP Reset as port (18184) not ak*
Statistic*: duration-014 id-1btenl-31 revd* '
dried info Fatedtohandterequest horn 127. ';
dted Info: Faied to handte request Iron» 127. ,
Arp Warning: The host 19216801« afotog <
Sendhg TCP Retet at port (18184) not Mow
Sendng TCP Reset at port (18184) not aloe; |
Sendteg TCP Reset at port (18184) not Mow~d
Рис. 8.5. Консоль управления Axent Raptor FireWall
188
fw\Rule\Rule ttl : Privatenetwork - Universe* i http* Properties
|w EI90x1 3
Ч '>*->.•<< <»:<->' _ <’• -
'''p^stined forX' X;-' v 4 ’ f'- , у z
^Universe* jj|
;Frahh epurcer-
zX<( |jft Private network
Coming out via:
::^|wEI90x2
’ -^^iei/айЪ^^йп to allowor deny access to services; > >s -x" - *г <*
/' -$ X t' :>>:<?.; . * >>>.<; - v x&r
x << Access To Services _ ' /X .. w ,.x
XX^ VXX'Xj X XX ‘ **’ ' ''' < „,. ’? _
4 XX ' * > V' zX > X ' / '
X:v^?XxxyXfXXX-j :»/>£< >4x ;X-. ’ "Wav
OK I Отмена ' ' v\x Сп|эа®ка
Рис. 8.6. Правила доступа МЭ Raptor
обеспечивают привязку к интерфейсам
Механизмы сетевой трансляции адресов, перенаправления сер-
висов, статической маршрутизации и специальных фильтров пере-
сылки (forwarding filter) предоставляют гибкие возможности в
управлении сетевым трафиком, что позволяет реализовать прак-
тически любые схемы сетевых соединений, в том числе для про-
токолов, отличных от TCP и UDP. Например, Raptor не имеет встро-
енного шлюза РРТР, но позволяет перенаправлять и поддерживать
соединения (GRE и TCP) удаленных пользователей на выделен-
ный шлюз РРТР с приватным IP-адресом.
МЭ Raptor реализует правила доступа не только на основе па-
раметров источник-назначение-служба, но и позволяет определять
входные и выходные сетевые интерфейсы МЭ, к которым будет
189
< $айл Правка йч» Избранное С^жмс -&&!»*& |Б9|
http/л 0 0 0 4 888Лод(п ...3 Переход
Edit
• Protocol enable status for user usertest at 10 0 0 36
i Protocol Enabled Sessions Idle timeout Timeout
' http* (http) P 10000 (hour 3 hours
। OK [ Logout |
Cq^rnehr © /9№0СЮ АХЫТ fechnohgfet.he Al! Rights Rutrttd
\ ljj> ЙнтернвГ?
Рис. 8.7. Аутентификация Axent OOBA
применяться правило (рис. 8.6). Привязка допускает использовать
более двух сетевых интерфейсов (например, возможна организа-
ция нескольких зон безопасности), а также усиление ПБ за счет
определения фильтров на интерфейсах. Интерфейсные фильтры ра-
ботают на самом нижнем уровне архитектуры МЭ и поэтому обес-
печивают высокую производительность.
МЭ поддерживает протоколы и схемы аутентификации S/Key,
Firewall password, SecurlD, CryptoCard, TACACS, RADIUS, Axent
Defender, NT Domain, LDAP и OOBA. Схема OOBA (Out of Band
Authentication) предусматривает подключение пользователей с по-
мощью Web-браузера на специальный порт МЭ, где выполняется
аутентификация по одному из поддерживаемых протоколов. Аутен-
тификация по схеме ООВА дает возможность пользователю са-
мостоятельно выбрать для текущей работы доступные для него
сервисы (рис. 8.7).
Встроенные механизмы защиты позволяют обнаруживать ата-
ки SYN Flood, Port scan и некоторые виды DoS-атак. Raptor может
взаимодействовать с системой IDS Axent NetProwler, что позво-
ляет автоматически создавать фильтры, блокирующие обнаружен-
ных нарушителей. Для защиты от DoS-атак администратор, кроме
использования фильтров, может самостоятельно варьировать сле-
дующими параметрами МЭ:
190
Параметр По умол- чанию Значение
connection_rate.limit=1 ООО -1 (Off) Количество соединений, раз- решенных в интервале вре- мени connection_rate.interval
connection_rate.interval=30 30 Временной интервал, с, подсчета количества соеди- нений connection_rate. limit
connection_rate.blocktime=3600 3600 Время, с, блокировки 1Р-ад- ресов, превысивших лимит
connection_rate.limit.<IP address> нет Ограничение количества соединений для заданных IP-адресов.
pingd. maxlength 256 Максимальная длина, байт, ICMP запроса ECHO request
МЭ Raptor содержит прикладные посредники протоколов FTP,
HTTP, NetBIOS, NTP, NNTP, GOPHER, SQL Net, RealAudio,
RealVideo, H.323, DNS и PING. Несмотря на небольшое число по-
средников, каждый из них может работать в прозрачном режиме и
предоставлять дополнительные возможности обеспечения защи-
ты данных на прикладном уровне. Например, посредник SMTP по-
зволяет блокировать spam-рассылки, NNTP гибко управляет поли-
тикой доступа к новостным группам, HTTP-посредник обеспечивает
ограничение доступа к Web-ресурсам на основе их тематического
содержания (система WebNOT).
Raptor отличают достаточно развитые средства мониторинга
текущего состояния и конфигурации. Мониторинг текущих актив-
ных соединений отображается в окне «Active Connections» RMC.
Текущие события отображаются в реальном времени. Журнал со-
бытий имеет текстовый формат, что позволяет использовать раз-
личные способы и продукты анализа журналов.
В состав пакета Raptor включена утилита анализа трафика
tcpdump - полный аналог UNIX-версии одноименной программы.
Raptor — одно из немногих средств, предоставляющих отчетную
документацию о параметрах текущей конфигурации, что позволя-
ет легко документировать и протоколировать все изменения кон-
фигурации. Отчеты конфигурации, в свою очередь, позволяют
выполнять мероприятия анализа ПБ, передачи проектной доку-
ментации и т. п.
191
Raptor обеспечивает режим повышенной надежности на осно-
ве Microsoft Cluster Server и может выполнять балансировку на-
грузки на основе циклического распределения (round robin). К со-
жалению, Raptor не предоставляет собственных средств защиты
от потенциально опасного содержимого прикладных протоколов
(вирусов, троянских программ и т. п.). Предоставляемый механизм
прозрачного перенаправления трафика позволяет использовать про-
дукты третьих производителей (например, Symantec). Но и в этом
случае не обеспечивается универсальности решения проблемы, по-
скольку для каждой прикладной службы требуется собственный
антивирусный сервер.
8.3. Cisco IOS Firewall
http://www.cisco.com
Уровень Экспертный
Класс SOHO/Enterprise
Инспектор состояний Да
Версия 12.1
Компания Cisco давно известна как один из лидеров рынка
средств сетеобразования. Сетевые маршрутизаторы компании
отличаются широкими функциональными возможностями, гибкос-
тью и высокой производительностью. Поскольку МЭ можно пред-
ставить как маршрутизатор с расширенными функциями, то ком-
пании не составило особого труда создать высокопроизводительный
и надежный аппаратный МЭ. Маршрутизаторы Cisco функциони-
руют под управлением собственной встраиваемой ОС IOS, выпол-
няющей все функции по управлению процессом обработки сетево-
го трафика. IOS предоставляет базовые функции безопасности,
получившие название AAA (Authentication, Authorization, and
Accounting). Управление IOS выполняется посредством использо-
вания специальных команд, которые могут быть загружены в виде
конфигурационного файла или вводятся вручную в консольном ре-
жиме (терминальная консоль, Telnet, SSH).
Реализация IOS Firewall Future Set позволяет использовать мар-
шрутизатор в качестве МЭ, либо усиливать маршрутизатор защит-
ными функциями. Рассмотрим функциональные возможности, пре-
доставляемые IOS Firewall.
Standard access list
Списки доступа (access list) являются основным защитным
механизмом IOS, поддерживаемым и в обычных ее вариантах.
Списки доступа обеспечивают реализацию механизмов пакетной
фильтрации.
192
Использование списков доступа состоит в выполнении двух
шагов - определении списка и его применении к определенному
интерфейсу. Каждый список доступа должен иметь уникальный
номер или имя. Для протокола IP номера списка выбираются из
диапазона 1-99 и 1300-1999.
Рассмотрим пример создания списка доступа с номером 2, бло-
кирующего входящие пакеты с сети 10.1.0.0 и разрешающего па-
кеты от хоста с адресом 192.168.0.1:
access-list 2 permit 192.168.0.1
access-list 2 deny 10.1.0.0 0.0.255.255 log
interface ethernet 0
ip access-group 2 in
МЭ проверяет каждый пакет на соответствие условиям списка
доступа сверху вниз. При первом удовлетворении условию прави-
ло применяется (пакет пропускается или блокируется), и дальней-
шая проверка не выполняется.
Списки доступа поддерживают время действия правил:
time-range no-http
periodic weekdays 8:00 to 18:00
Static extended access list
Статические расширенные списки доступа, в отличие от стан-
дартных, определяют условия на адреса и порты отправителя и
получателя.
Динамические списки доступа Lock-and-key
Механизм Lock-and-key позволяет создавать динамические
списки доступа. Клиент, желающий получить доступ через МЭ,
выполняет процедуру аутентификации. В случае ее успешного вы-
полнения МЭ создает список доступа. Динамические списки мо-
гут использоваться для отдельных клиентов, IP-хостов и сетей.
Аутентификация проводится посредством подключения по про-
токолу Telnet к интерфейсу МЭ. Непосредственно сама процедура
аутентификации выполняется на МЭ или на серверах TACACS+,
RADIUS. Время действия созданного списка доступа определя-
ется установленным временем тайм-аута, в течение которого кли-
ент не проявляет сетевой активности.
7 Лебедь С.В.
193
Reflexive access list
Рефлексивные списки доступа выполняют инспекцию состоя-
ния сетевых соединений на сетевом и транспортном уровнях мо-
дели OSL Напомним, инспекторы состояния проверяют принад-
лежность каждого пакета к ранее установленному соединению и
являются неотъемлемой частью современных МЭ.
Сетевая трансляция адресов
Cisco IOS предоставляет все существующие возможности NAT,
включая статическую, динамическую, динамическую со статичес-
кой выборкой, а также обеспечивает балансировку нагрузки ТСР-
сервисов.
Event Logging
Маршрутизаторы Cisco не имеют встроенных устройств дли-
тельного хранения больших объемов данных. Поэтому для прото-
колирования сетевых событий используют внешний сервер Syslog.
Кроме того, сообщения могут выводиться на консоль терминала.
TCP intercept
Механизм TCP intercept (перехват) направлен на предотвраще-
ние DoS-атак, основанных на генерации большого количества SYN-
пакетов (SYN-flood). МЭ перехватывает первый пакет клиента с
установленным SYN-флагом и отправляет ответный пакет клиен-
ту от имени сервера. В случае успешного установления соедине-
ния с клиентом (т. е. клиент действительно желает установить со-
единение), МЭ устанавливает соединение с сервером от имени
клиента и далее выступает посредником. Если же соединение с
клиентом не устанавливается, значит, клиент не желает устано-
вить соединение, т. е. имеет место атака SYN-flood.
Необходимо отметить, что описанный здесь механизм TCP
intercept в некоторых реализациях МЭ является составной частью
инспекторов состояний. В литературе встречается и другое его
название - TCP proxy.
ip tcp intercept list 101
i
access-list 101 permit tcp any 192.168.1.0 0.0.0.255
Рис. 8.8. Пример конфигурации TCP intercept
для всех сервисов TCP-сети 192.168.1.0/24
194
Context based access control (CBAC)
СВАС выполняет контроль содержимого сетевых пакетов на
сетевом, транспортном и прикладном уровнях. Он сочетает в себе
функции инспектора состояний, прикладных посредников и поддер-
живает следующие прикладные протоколы: TCP и UDP сессии, CU-
SeeMe, FTP, java (HTTP), H.323, UNIX r commands (rlogin, rexec,
rsh), RealAudio, RTSP (Real Time Streaming Protocol), RPC, SMTP,
SQL*Net, StreamWorks, TFTP и VDOLive.
Кроме инспекции состояния соединения, контроля корректнос-
ти команд и данных прикладных протоколов, СВАС позволяет пре-
дотвращать DoS-атаки посредством установления следующих по-
роговых значений:
• общего количества полуоткрытых соединений TCP;
• количества полуоткрытых соединений TCP на заданном про-
межутке времени;
• общего количества полуоткрытых соединений TCP, иницииро-
ванных одним хостом.
При достижении этих пороговых значений СВАС автоматичес-
ки сбрасывает соединения отправкой RST-пакетов или блокирует
новые SYN-пакеты.
Authentication Proxy
Authentication Proxy выступает посредником между МЭ и сер-
вером аутентификации (TACACS+, RADIUS), что несколько напо-
минает механизм Lock-and-Key. Authentication Proxy имеет несколь-
ко важных отличий от Lock-and-Key, а именно:
• аутентификация выполняется по протоколу HTTP;
• аутентификация не может выполняться на МЭ;
• профили списков доступа загружаются только с внешних сер-
веров TACACS+ или RADIUS;
• посредник может быть использован в среде с динамически
назначаемыми IP-адресами.
Port to Application Mapping (РАМ)
РАМ позволяет запускать сетевые прикладные службы на пор-
тах, отличных от стандартных. Он работает совместно с СВАС,
что позволяет контролировать сетевой трафик на прикладном уровне
и при использовании нестандартных портов. Различают три вида
отображения (mapping) портов:
т
195
• System-Defined Port Mapping - содержит таблицу зарегистри-
рованных портов (служб), поддерживаемых СВАС;
• User-Defined Port Mapping - произвольное отображение пор-
тов. Позволяет, например, запускать сервер HTTP на 8000 порту;
• Host-Specific Port Mapping - произвольное отображение пор-
тов с привязкой к IP-хосту или сети. Например, возможно отобра-
жение HTTP-трафика на порт 3000 одного IP-хоста и telnet-трафи-
ка на 3000 порт другого 1Р-хоста:
access-list 10 permit 192.168.0.1
access-list 20 permit 192.168.0.2
ip port-map http port 3000 list 10
ip port-map http ftp 3000 list 20
Основное отличие РАМ от NAT заключается в том, что РАМ
может поддерживать СВАС.
Обнаружение вторжений
Встроенная в IOS Firewall система IDS позволяет обнаружить
59 самых распространенных сетевых атак и может дополнять Cisco
Secure IDS (NetRanger) как сетевой сенсор. При обнаружении ата-
ки МЭ может выполнить следующие действия: отправить сообще-
ние на сервер Syslog или Cisco Secure IDS Director, отбросить па-
кет или сбросить TCP-соединение. Отличительной особенностью
модуля IDS является большое для МЭ число обнаруживаемых атак
(обычно МЭ распознают около десяти различных DoS-атак, про-
веряют корректность пакетов и обнаруживают сканирование пор-
тов).
Поддержка VPN
В IOS Firewall реализована полная поддержка стандартного
протокола построения VPN-сетей IPSec. Cisco IOS Firewall предо-
ставляет основные механизмы защиты, присущие современным
МЭ экспертного уровня. Основные преимущества в пользу выбо-
ра IOS Firewall следующие:
• при наличии собственного маршрутизатора Cisco заменой,
имеющейся IOS на версию IOS Firewall, можно быстро «нарас-
тить» функциональность МЭ (с поддержкой VPN);
• оптимизированная сетевая аппаратная платформа позволяет
получить большую производительность и надежность.
196
К недостаткам рассмотренного МЭ можно отнести:
• высокую стоимость;
• необходимость внешней «обвязки» в виде серверов аутенти-
фикации, протоколирования событий и станции управления, что также
повышает стоимость системы защиты;
• методология управления несколько отличается от принятой в
ОС Unix и NT, что требует обязательного обучения специалистов.
8.4. Cisco PIX Firewall
http ://www. cisco. com/go/pix
Уровень
Класс
Инспектор состояний
Версия
Экспертный
SOHO, Enterprise
Да
5.2
На сегодняшний день МЭ Cisco Secure PIX (Private Internet
Exchange) Firewall, изначально разработанный компанией TNI
(Translation Networks Inc.), является самым производительным. По
заявлению производителей, PIX 535 обеспечивает до 500 тыс. од-
новременных соединений при пропускной способности 1 Гбит/с и
поддерживает до 10 сетевых интерфейсов. Сравнительная характе-
ристика некоторых МЭ серии Cisco Secure PIX приведена в табл. 8.2.
Как и в продуктах маршрутизации Cisco, в PIX используется
концепция AAA (Authentication, Authorization, Accounting) и, кроме
того, реализуется концепция безопасности Adaptive Security Algo-
rithm (ASA). В основе ASA лежат следующие положения:
1) ни один сетевой пакет не может быть пропущен через МЭ,
если для него отсутствует информация в таблице состояний. В таб-
лице состоянии отслеживаются адреса и порты отправителя и по
лучателя, номера последовательностей TCP, флаги TCP;
2) номера последовательностей TCP выбираются случайно;
3) исходящие соединения разрешаются только на основе спис
ков контроля доступа (ACL). Всем интерфейсам назначаются уров
ни безопасности (от 0 до 100). Внут-
ренний интерфейс всегда имеет
наивысший уровень безопасности
(100), а внешний - наименьший (0);
4) все входящие соединения
блокируются, если только специаль-
но не были разрешены;
5) все пакеты ICMP запреще-
ны по умолчанию;
Рис. 8.9. МЭ PIX Firewall 520
197
Таблица 8.2. Сравнительная характеристика МЭ Cisco PIX
Характеристика МЭ
МЭ PIX501 PIX 506 PIX 515 PIX 520 PIX 525 PIX 535
Производитель- ность (одновре- менное соедине- нение тыс./ про- пускная способ- ность, Мбит/с) 3,5...10 8 100... 170 — 280... 370 500... 1000
Тип поддержи- ваемых сетевых интерфейсов Ethernet Ethernet Ethernet Ethernet, FDDI, Token Ring Ethernet Ethernet
Максимальное 6ETH
количество интерфейсов 2 2 6 4TR 2 FDDI 8 10
Ориентация потребителя Remote office, tele- workers Remote office SOHO — Enter- prise, ISP Enter- prise, ISP
6) все попытки обхода вышеизложенных правил пресекаются с
записью соответствующих сообщений в журнал событий.
Как следует из первого положения, PIX является инспектором
состояний, и инспекция состояний положена в основу концепции
ASA. Cisco является одной из немногих компаний, достаточно полно
описывающих технические подробности используемых ей техно-
логий.
Управление конфигурацией может выполняться в командном
режиме (в стиле IOS) через терминальное соединение, TELNET,
SSH и в графическом интерфейсе посредством использования ути-
лит PIX Firewall Manager (PFM) или Secure Policy Manager. PFM
управляет до десяти устройствами PIX. Самостоятельный продукт
Secure Policy Manager позволяет графически создавать ПБ сети
организации и применять ее к продуктам Cisco, используемых в
обеспечении безопасности - коммутаторам, маршрутизаторам, IDS
и, конечно, самому МЭ PIX.
Прикладные посредники реализованы для протоколов Н ГГР, FTP,
SMTP, RealAudio, RealVideo, SQL Net, H.323. Посредники «уме-
ют» контролировать только корректность данных и команд приклад-
198
ных протоколов. Использование дополнительных возможностей
(блокировка апплетов, ограничение доступа на основе URL, кэши-
рование данных и т. п.) требует использования дополнительных сер-
веров.
PIX не имеет встроенных механизмов аутентификации, но под-
держивает внешние схемы RADIUS, TACACS+ и Kerberos. Для
решения задачи аутентификации Cisco предлагает использовать
собственный продукт Cisco Secure Access Control Server (ACS),
который предоставляет широкий набор протоколов, схем аутенти-
фикации и авторизации, в том числе - NT Domain, ADS, RADIUS,
TACACS+, CHAP, MS-CHAP, PAP, SecurlD, CyptoCard. Протоко-
лирование событий выполняется по протоколу Syslog (стандарт-
ный протокол UNIX), который обеспечивает вывод сообщений на
консоль или отправку сообщений на выделенный сервер Syslog.
Также возможна отправка трапов SNMP. Мониторинг состояния
осуществляется по протоколу SNMP или посредством вызова слу-
жебных команд ОС PIX. Функции повышенной надежности обес-
печиваются путем объединения в стек двух МЭ.
Обеспечение защиты внешнего периметра безопасности с по-
мощью PIX может потребовать использования «обвязки» в виде
сервера аутентификации, сервера Syslog, серверов-посредников,
станции управления, системы обработки журналов. Использова-
ние всех этих компонентов, в свою очередь, может потребовать
значительных финансовых затрат. По этой причине МЭ PIX про-
мышленных версий можно рекомендовать в случаях, когда дей-
ствительно необходимо обеспечить высокую производительность
и надежность, например, для сегментации высокоскоростной кор-
поративной сети или как VPN-шлюз для обеспечения большого
количества удаленных пользователей или для провайдеров услуг
Интернет.
8.5. CyberGuard Firewall
http ://www. cyberguard, com
Уровень Экспертный
Класс Enterprise
Инспектор Да
состояний
Версия 4.3
Компания CyberGuard Corporation известна на рынке межсете-
вых экранов с 1989 г. как производитель высокозащищенных и
высокопроизводительных систем безопасности. Отличительной
199
Рис. 8.10. Программно-аппаратный МЭ CyberGuard StarLord
чертой всех продуктов этой компании является подход к построе-
нию безопасных платформ, на которых базируются МЭ. Начиная с
первых своих продуктов, CyberGuard использовала как специаль-
ные защищенные версии Unix (Trusted Unix), так и предпринимала
собственные меры по усилению защитных возможностей ОС.
Комплексный подход к созданию высоконадежной и безопас-
ной архитектуры МЭ нашел свое продолжение и в последней линии
продуктов, включающей программно-аппаратные межсетевые эк-
раны - KnightSTAR, STARLord (рис. 8.10), FireSTAR и программ-
ные для ОС Windows NT и UnixWare.
При правильной настройке ОС Windows NT 4.0 способна обес-
печить достаточно мощную защиту локальных и сетевых серви-
сов системы. Эти встроенные возможности ОС и использует МЭ
CyberGuard 4.2. Начиная с процесса инсталляции, CyberGuard при-
нимает все меры по усилению и активизации защитных возможно-
стей ОС. Исходя из целевого назначения системы (выделенный
МЭ, МЭ + Контроллер домена, МЭ + сервер БД), на которой осу-
ществляется инсталяция МЭ, выполняются соответствующие на-
стройки подсистемы безопасности ОС (высокая, средняя и стан-
дартная безопасности соответственно).
Активизация защитных возможностей заключается в настрой-
ке ПБ доступа к системному реестру, политики управления пользо-
вательскими бюджетами и паролями, политики аудита событий,
ограничений встроенных сетевых возможностей ОС, политики вхо-
да в систему (Logon) и других ограничений, позволяющих значи-
200
тельно усилить защиту системы. В отличие от большинства дру-
гих МЭ для Windows NT, CyberGuard не инсталлируется на диск с
FAT-разделом. Инсталляция возможна только на NTFS-раздел.
МЭ CyberGuard для ОС UnixWare принимает еще большие меры
по усилению защиты своей ОС. В процессе инсталляции особым
образом формируется файловая система, устанавливаются жест-
кие права доступа к объектам ОС и специальные защищенные драй-
веры аппаратных средств. После завершения процесса инсталля-
ции МЭ компьютер немногим отличается от аппаратных реализаций
МЭ: X-manager UnixWare заменяется графической средой управ-
ления МЭ CyberGuard, а пользователю FSO (Firewall Security Officer)
разрешено выполнять только административные действия над МЭ.
Все другие операции требуют повышенных полномочий, которые
можно получить только путем перезагрузки ОС с незащищенной
версией ядра. Любые действия по администрированию ОС требу-
ют от пользователей глубоких знаний как ОС, так и МЭ. Такой
подход к организации защиты самого МЭ исключает фатальные
ошибки и некорректные действия администраторов системы.
МЭ для ОС UnixWare ведет журнал изменения всех настроек,
выполненных пользователем FSO, что позволяет при необходимо-
сти выполнить «откат» конфигурации или отследить историю ее
изменения, которая сохраняется в БД SCCS (Source Code Control
System) в виде архива.
Можно выделить следующие базовые функциональные возмож-
ности МЭ CyberGuard:
• прикладные посредники: AOL* , GopherTM*, FTP, HTTP, LDE,
NNTP, Lotus Notes, POP3, Port Guard, Rlogin*, Real Audio*, SSL*,
SMB, SMTP, SQL Net, Telnet, X-Window*, Proxy Writer*;
• поддержка статической и динамической сетевой трансляции
адресов;
• поддержка схем аутентификации: NT Password, RADIUS,
SecurlD, SecureNetKey;
• SOCKS’^
• авторизация - Passport One;
• поддержка Split DNS;
• обеспечение антивирусной защиты по протоколу CVP;
• уведомление о событиях - Window, Mail, SNMP Trap, Pager,
Syslog’, OS Command;
• встроенная система обнаружения атак - Land, Ping of death,
SYN flood, IP spoofing, port scan;
’ Реализовано только в аппаратных моделях и UnixWare.
201
• повышенная надежность (High Availability, НА);
• централизованное управление;
• гибкие возможности резервного копирования и восстановле-
ния после сбоев;
• балансировщик загрузки (Load Equalizer);
• VPN (IPSec).
Основные операции по настройке ПБ в МЭ выполняются в ре-
дакторе правил Packet-Filtering Rules. Графический редактор отве-
чает негласным требованиям, предъявляемым к системам безо-
пасности - правила хранятся в обычном текстовом ASCII-файле,
а сам редактор контролирует и облегчает процесс ввода и измене-
ния правил (рис. 8.11). В фильтре отсутствует ряд функций, прису-
щих пакетным фильтрам, - контроль полей служебных заголовков
протоколов IP/UDP/TCP, определение диапазона транспортных пор-
тов (больше, меньше, диапазон), определение портов источника
сетевых пакетов.
Рис. 8.11. Редактор правил фильтра пакетов МЭ CyberGuard
202
ЯЯЕЗ
- ei it*
FTP Fit Ttantfa Protocol П Г п г* Г
HTTP Hypertext Tianrfw Protocol г г г г Г ?
IDE Load Equalizer г Г г г г
NNTP Network Newt Ttansport Protocol г г г Г” г
Notes Lotus Note* эе г г г г г ?«
PG Port Guard Г г г г г
POP3 Post Office Protocol _ ГН) р р г г Г
SMB SMB Protocol р г Г
SMTP ' Simple Mai T tarafer Protocol (SH* Пг г г г
SQLW SQL-Net г г г г г *1
Рис. 8.12. Окно настройки прикладных посредников
SmartProxies МЭ CyberGuard
Встроенный механизм прикладных посредников SmartProxies
(рис. 8.12) позволяет использовать защитные возможности посред-
ников входящих и исходящих соединений в режимах То Firewall и
Trough Firewall. В режиме То Firewall клиент выполняет соедине-
ние непосредственно с МЭ, который осуществляет посредничество
между клиентом и сервером. В этом случае клиент не знает ис-
тинного адреса прикладного сервера; адресом этого сервера для
клиента является адрес МЭ. Режим Trough Firewall является про-
зрачным для клиента - клиент выполняет прямое соединение с
прикладным сервером, это соединение перехватывает МЭ, кото-
рый устанавливает посредничество.
Каждый из посредников имеет собственные индивидуальные
параметры настроек, усиливающих соответствующие прикладные
службы. Все изменения, выполняемые в редакторе SmartProxies,
автоматически вносятся в виде соответствующих правил пакетно-
го фильтра. Наряду с наиболее распространенными прикладными
посредниками (HTTP, FTP, SMTP, POP и т. п.), МЭ имеет собствен-
ные реализации посредников - SMB Proxy и Port Guard Proxy.
Посредник SMB Proxy позволяет осуществлять подключение
удаленных пользователей к внутренним сетевым ресурсам по про-
токолу Server Message Block (NetBIOS over TCP). SMB Proxy яв-
ляется базовым протоколом сетевого взаимодействия ОС линии
MS Windows. Поскольку реализация Microsoft этого протокола име-
ет ряд серьезных уязвимостей, то в большинстве случаев админи-
страторы МЭ запрещают его использование.
SMB Proxy принимает решение о допустимости доступа на ос-
нове следующих параметров:
• IP-адреса SMB-сервера. Если сервер не указывается, то по-
иск сервера производится по имени ресурса;
203
• имени пользователя;
• типа ресурса - Drive, Printer, Pipe, Any;
• имени ресурса (например, \\FileServer\Distrib).
В режиме То Firewall посредник SMB обеспечивает безопас-
ное подключение удаленных пользователей к внутренними ресур-
сам (SMB-серверам).
Port Guard Proxy - посредник общего назначения для ТСР-при-
ложений, который позволяет:
1) перенаправлять запросы соединения с IP-адресом одного из
интерфейсов МЭ на определенные серверы. Это возможно и при
включенной динамической трансляции, что позволяет организовы-
вать соединение с серверами локальной сети;
2) выполнять трансляцию портов (РАТ);
3) ограничивать максимальное количество соединений, макси-
мальное время задержек между посредником и сервером, а также
между клиентом и посредником.
Схема аутентификации Passport One обеспечивает выполнение
авторизации полномочий пользователей. Профили Passport Оле со-
держат набор правил ПБ. Каждому пользователю или группе
пользователей может соответствовать один профиль. Процедура
авторизации состоит из следующих шагов:
• используя агентов аутентификации (НИ Р или Telnet), пользова-
тель подключается к специально назначенным портам МЭ (рис. 8.13);
• выполняется аутентификация пользователя одним из поддер-
живаемых методов;
>3 Passport One - Login Page - Microsoft Internet Explorer HEJE3
Файл Правка Вид Избранное Сервис Справка
£дрес |#] http://1 D.0 0 4:3080/ ^Переход
11^——нвннванав|нвп
Passport One
Your source address is 10.0.0.36
Login:
Готово ф Интернет
Рис. 8.13. Аутентификация пользователя Passport One
204
3 Passport One - Accept Page - Microsoft Internet Explorer №□
Файл Правка Виа Избранное Сервис Справка
4-J ” » £арес http://10.0.0.4 3090/Response "Я! Переход
В
CyberGuard Firewall I
Passport One I
Hello serg
Your source address is 10.0.0.S6
Your session (i<19) is running... I
Pressing STOP will terminate this session
'______________________________в
Открытие с! HHHHBHHBB . 30 И ктернет
Рис. 8.14. Успешное выполнение аутентификации
Passport One
• в случае успешной аутентификации МЭ автоматически до-
бавляет правила ПБ, содержащиеся в соответствующем профиле
Passport One (рис. 8.14);
• после закрытия соединения агента аутентификации МЭ уда-
ляет соответствующие правила ПБ.
Использование функций повышенной надежности позволяет
организовать кластер из двух МЭ CyberGuard, что обеспечивает
непрерывное функционирование сети в случае выхода из строя од-
ного из МЭ. Такую возможность поддерживают далеко не все МЭ.
Кластер состоит из основного и резервного МЭ. Все изменения,
внесенные администратором в конфигурацию основного МЭ, авто-
матически дублируются в резервном МЭ, что обеспечивает иден-
тичность их конфигурации. Автоматическое переключение на ре-
зервный МЭ кластера происходит в одном из следующих случаев:
• выключение основного МЭ;
• потеря специальных сигналов от основного МЭ;
• появление сбоев в критических интерфейсах основного МЭ;
• обнаружение катастрофических неисправностей основного МЭ.
Реализация функций повышенной надежности основывается на
механизме Link Aggregation (LAG), который позволяет интегриро-
вать несколько физических сетевых адаптеров в один логический
сетевой интерфейс.
205
8.6. TIS Firewall Toolkit
http ://www.fwtk.org/
Уровень Пакет прикладных посредников
Версия 2.1
В 1993 г. компания Trusted Information Systems (TIS) разработа-
ла и предоставила для общего использования пакет Firewall Toolkit,
представляющий собой готовый к применению набор прикладных
посредников, ставший также основой многих коммерческих МЭ.
Пакет распространяется вместе с исходными текстами и может
функционировать на многих ОС линии UNIX: SunOS4.1 .X, Solaris,
HP/UX, CMU MACH, ULTRIX, BSDI, BSD/386, IBM/AIX, SCO,
SINIX, XENIX, Linux, NeXTStep, SGI IRIX. Несмотря на то, что
пакет используют почти десять лет, он не утратил своей актуаль-
ности, и укрепил свои позиции на рынке программных продуктов
ИБ. Разработчики пакета по этой причине даже ввели понятие
«Crystal Box» в противоположность понятию «Black Box», подчер-
кивая открытость и надежность исходного кода.
В состав пакета входят посредники протоколов Telnet, FTP, rlogin,
http, SMTP, XI1. Для каждого из них определяются как общие па-
раметры ПБ (разрешенные и запрещенные хосты, время тайм-аута
активности), так и специфичные (например, параметры фильтра-
ции java, javascript, ActiveX протокола HTTP). Предусмотрена воз-
можность подключения посредников для любых других протоко-
лов на основе TCP (plug-proxy). В этом случае обеспечивается
непрозрачное посредничество - клиент должен подключиться к пор-
ту МЭ, а последний установит соединение, в свою очередь, с ука-
занным в настройках сервером.
Firewall Toolkit реализует непрозрачную аутентификацию пользо-
вателей (только для Telnet, FTP, rlogin), для чего используется сер-
вер аутентификация authsrv, который может быть установлен на
выделенном компьютере. Данный подход позволяет легко наращи-
вать схемы аутентификации. Пакет поддерживает схемы username/
password, S/Key, MD5, Secure Net Key (SNK) компании Digital
Pathways, Enigma компании Enigma Logics, SecurlD компании RSA
Security, CRYPTOCard.
Протоколирование событий выполняется через систему Syslog,
при этом на этапе компиляции можно указать параметры facility и
level (по умолчанию используются LOG NOTICE/LOG DAEMON).
Сообщения журнала содержат подробные сведения о работе
пользователей. В состав пакета входит набор шел-скриптов,
206
которые анализируют журналы и предоставляют различную
статистику по работе посредников.
Настройка всех параметров МЭ выполняется в текстовом файле
netperm-table, а подключение plug-сервисов - через стандартный
tcp-wrappers ОС Unix inetd (файл inetd.conf). Ниже приведен
фрагмент файла netperm-table:
# Пример конфигурации сервера аутентификации authsrv:
#
authsrv: database /var/adm/authsrv.db
authsrv: permit-hosts localhost
authsrv: permit-hosts 10.0.0.121 cipherkey
# Пример конфигурации посредника ftp:
# :---------
ftp-gw: authserver localhost 7777
ftp-gw: denial-msg /usr/local/etc/ftp-deny.txt
ftp-gw: welcome-msg /usr/local/etc/ftp-welcome.txt
ftp-gw: help-msg /usr/local/etc/ftp-help.txt
ftp-gw: permit-hosts 192.168.0.23
ftp-gw: permit-hosts 192.168.0.* -log {retr stor} \
-auth { stor }
ftp-gw: permit-hosts * -authall
ftp-gw: timeout 3600
# Пример конфигурации подключаемого посредника для протокола
# POP3, клиенты должны подключаться через порт 2009 на МЭ
#
plug-gw:port 2009 192.168.0.* -plug-to рорЗ.company.com\
-port 110
МЭ Firewall Toolkit взят за основу многих коммерческих МЭ,
например, этот пакет составил основу МЭ Gauntlet Firewall компа-
нии Network Associates и МЭ Застава-2 российской компании
JetlnfoSystems. Совместно используя рассматриваемый пакет и
один из свободно распространяемых пакетных фильтров (ipfilter,
ipchains/iptables, ipfw), можно построить МЭ, не уступающий по ре-
ализуемым функциям и некоторым коммерческим продуктам, а
наличие исходных текстов программ и расширяемого интерфейса
аутентификации позволяет расширять функциональные возможно-
сти.
207
8.7. IP Filter
http:// coombs.anu.edu.au/~avalon/
http://false.net/ipfilter/
Уровень Фильтр пакетов
Класс SOHO
Инспектор состояний Да
Версия 3.4.14
МЭ IP Filter - это один из лучших свободно распространяемых
ПФ для платформ линии Unix (доступен для операционных систем
BSD, FreeBSD, NetBSD, OpenBSD, Linux, IRIX, Solaris, HP-UX).
IP Filter является пакетным фильтром с поддержкой технологии
инспекции состояний. Наличие инспектора состояний, богатые воз-
можности контроля и управления сетевым трафиком заметно вы-
деляют его среди других аналогичных продуктов.
IP Filter состоит из нескольких основных модулей:
• ipf — модуль чтения правил и команд из стандартного буфера
ввода (stdin) или файла - выполняет первичную обработку с целью
определения корректности правил и передает их в ядро МЭ;
• ipfstat - модуль ведения и отображения статистики обработ-
ки входящих и исходящих пакетов;
• ipftest - модуль пошаговой отладки правил МЭ;
• ipmon - монитор МЭ - регистрирует и отображает текущее
состояние путем чтения буфера данных из устройства регистра-
ции (logging device, Idevlipl) и выдачи полученной информации на
экран, в файл или syslog;
• ipsend - генератор тестовых IP-пакетов;
• ipresend - генератор трафика - читает файл данных, содер-
жащий IP-пакеты (поддерживаемые форматы - snoop, tcpdump,
etherfind) и отправляет эти пакеты обратно в сеть;
• iptest - модуль, содержащий набор тестов, которые позволя-
ют отправлять последовательности различных IP-пакетов, тести-
рующих «стойкость» сетевого стека;
• ipnat - модуль чтения набора правил и добавления их в ядро
для активации NAT - отображает текущее состояние активных
сессий NAT;
• mkfilters - скрипт - позволяет интерактивно создавать прави-
ла ПБ.
На рис. 8.15 представлена диаграмма обработки сетевых па-
кетов МЭ IP Filter. Над сетевыми пакетами определены два воз-
можных действия - pass (пропустить), block (блокировать) и на-
правления действия - in (пакеты, поступающие на любой сетевой
208
I
IN
Рис. 8.15. Диаграмма потока обработки сетевых пакетов МЭ IP Filter
интерфейс), out (исходящие пакеты с любого интерфейса). Прави-
ла обрабатываются последовательно, при этом если анализируе-
мый пакет удовлетворяет требованиям одновременно нескольких
209
правил, то будет применено последнее правило. Например, полити-
ка безопасности, состоящая из двух правил:
block in all
pass in all
разрешает прохождение всех пакетов, поскольку последнее прави-
ло удовлетворяет всем пакетам.
Инструкция quick позволяет выполнять текущее правило без
последующего анализа остальных правил. Это значительно повы-
шает производительность МЭ (нет необходимости анализа всех
правил), а также контролировать последовательность применения
правил. Включение инструкции quick в предыдущем примере
block in quick all
pass in all
приводит к запрещению всех пакетов, поступающих на любой се-
тевой интерфейс.
Инспекция состояния сетевых соединений
Рассмотрим на примере МЭ IP Filter особенности реализации
инспекции состояния сетевых соединений пакетными фильтрами.
Если ПБ разрешает доступ всем пользователям защищаемой сети
к Web-ресурсам Интернет и запрещает любой доступ в локальную
сеть, то в большинстве МЭ экспертного класса достаточно сфор-
мировать правило следующего вида (политика по умолчанию - «все
запрещено»):
Источник Назначение Сервис Действие
local_net any http allow
Определим эту же ПБ в IP Filter без использования встроенных
механизмов инспекции состояния (xlO, xl 1 — внутренний и внешний
интерфейс МЭ соответственно):
block in on xll proto tcp all #1
block out on xll proto tcp all #2
block in log quick on xll proto tcp all flags S/SA #3
pass out quick on xlO proto tcp from any to any
port = http #4
pass in on xll proto tcp from any port =
http to any #5
210
Правила ПБ определяют следующее. Со стороны внешнего ин-
терфейса запрещены все TCP-пакеты, за исключением пакетов,
содержащих порт 80 отправителя и без установленных флагов SYN
или SYN ASK (правила 1, 3, 5). Попытки сканирования или под-
ключения к внутренним сервисам регистрируются (правило 3). Во
внешнюю сеть разрешены только клиентские HTTP-пакеты (пра-
вила 2, 4). Таким образом, IP Filter будет осуществлять искусст-
венную, т. е. определенную администратором, попытку инспекции
состояния канала связи. Очевидные недостатки такого решения
заключаются в следующем:
• инспекция пакетов осуществляется только на основе ограни-
ченной комбинации флагов. Например, TCP-пакеты с портом по-
лучателя 80 и отсутствием флагов или любой комбинацией флагов
URG, PSH, RST, FIN будут пропущены! Частично исключить эту
проблему можно путем определения в правиле 3 дополнительных
запрещенных комбинаций флагов TCP;
• не отслеживаются такие важные параметры как номера ТСР-
последовательностей и время жизни соединения, что делает воз-
можным прохождение копий одних и тех же разрешенных пакетов
в неограниченном количестве;
• очевидно, что перечисленные недостатки позволяют реали-
зовать некоторые типы DoS-атак.
Используем теперь встроенную в IP Filter возможность инс-
пекции состояния. При этом правила преобразуются к следующе-
му виду:
pass out quick on xll proto tcp from any to any
port = http flags S/SA keep state #1
block in quick proto tcp all #2
block out quick proto tcp all #3
Добавленная инструкция keep state определяет прохожде-
ние только тех TCP-пакетов, которые или принадлежат уже установ-
ленному HTTP-соединению, или устанавливают его (flags S/SA).
При этом keep state прозрачно разрешает прохождение пакетов,
принадлежащих соединению в обратном направлении (in). Суще-
ственно, что IP Filter создаст запись в таблице состояний только в
том случае, если пакет будет «выходить» с внешнего интерфейса,
и с установленным значением порта получателя, равным 80.
Контроль UDP-трафика, например DNS, в пакетных фильтрах
определяется примерно таким же образом:
211
block out proto udp all
block in proto udp all
pass out proto udp from any port > 1024 to any port = 53
pass in proto udp from any port = 53 to any port > 1024
При инспекции UDP-трафика правила можно представить в сле-
дующем виде:
block out proto udp all
block in proto udp all
pass in proto udp from any to any port = 53 keep state
Теперь ни один UDP-пакет с портом источника 53 не будет про-
пущен, если ему не предшествовал DNS-запрос. IP Filter не выпол-
няет инспекцию DNS-пакетов на прикладном уровне, как это дела-
ет, например, FireWall-1 (проверка корректности структуры формата
DNS), но контролирует IP-адреса, порты получателя и отправите-
ля, а также время жизни виртуального соединения UDP.
IP Filter предоставляет ряд возможностей отслеживания, трас-
сировки и исследования состояния инспектируемых соединений.
Наиболее простой способ заключается в обращении к таблице со-
стояний с помощью утилиты ipf stat с ключем -si (отобразить
таблицу состояний в расширенном формате):
#ipfstat -si
10.0.0.6 -> 192.168.0.2 ttl 863986 pass 0x500a pr 6 state 4/4
pkts 159 bytes 38012 1055 -> 80 8a3ff548:121664c 17520:32120
pass in quick keep state IPv4
pkt_flags & 2(b2) = b, pkt_options & ffffffff = 0
pkt_security & ffff = 0, pkt_auth & ffff = 0
interfaces: in xlO[0xc0a2e000] out xll[ОхсОаЗОООО]
Результат выполнения команды ipfstat -si соответствует
одной записи в таблице состояний и обозначает следующее:
• клиент 10.0.0.6:1055 установил соединение с сервером
192.168.0.2:80;
• поле state отображает текущую фазу соединения. Состояние
4/4 соответствует полностью установленному соединению;
• время жизни (ttl) 863986 с. Счетчик TTL уменьшается каж-
дую секунду на единицу, если отсутствовала активность соответ-
ствующего соединения. При достижении нулевого значения TTL
запись о соединении удаляется из таблицы состояний (state table).
По умолчанию начальное значение TTL после установления со-
212
единения равняется 864000 с, что соответствует 240 ч. В нашем при-
мере после установления соединения и до момента получения инфор-
мации о состоянии соединения прошло 14 с (864000 - 863986 = 14);
• за время соединения передано 159 пакетов, содержащих 38012
байт данных;
• последние две пары цифр во второй строке соответствуют
номерам TCP-последовательностей и размеру ТСР-окна;
• третья строка кратко отображает правило, использующее ин-
струкцию keep state;
• четвертая и пятая строка отображают значения некоторых
полей и флагов TCP-пакетов (не документированы);
• в последней строке отображаются имена интерфейсов с МАС-
адресами сетевых адаптеров со стороны клиента (in) и сервера
(out) соответственно.
Если ipf stat позволяет получить статическую информацию
в фиксированные моменты времени, то утилита ipfmon с ключом
-о S выводит зарегистрированные пакеты таблицы состояний. Па-
кеты регистрируются только в том случае, если в правилах ис-
пользуется ключевое слово log:
#ipfmon -о S
19:16:22.467357 STATE:CLOSE 10.0.0.6,1063 ->
192.168.0.2,80 PR tcp Pkts 167 Bytes 90840
19:16:22.853930 STATE:NEW 10.0.0.6,1065 ->
192.168.0.2,80 PR tcp
МЭ IP Filter выполняет также «интеллектуальную» инспекцию
и протокола ICMP. Например, правило
block in on xll
pass out on xll proto icmp from any to any
icmp-type 8 keep state
разрешает клиентам локальной сети использовать программу ping.
При этом гарантируется, что в локальную сеть будут пропущены
только те ICMP-ответы, которые соответствуют клиентским ICMP-
запросам.
Регистрация событий
IP Filter имеет прекрасные для пакетного фильтра возможнос-
ти регистрации пакетов:
• пакеты регистрируются, если в правила включается инструк-
ция log;
213
• высокая производительность системы регистрации достига-
ется за счет использования специальных программных решений;
• возможна регистрация первых 128 байт сетевых пакетов (log
body);
• чтобы избежать регистрацию серии одинаковых событий, ис-
пользуется инструкция log first, позволяющая регистрировать
только первое событие;
• утилита ip f mon позволяет извлекать данные в различных фор-
матах и формах представления, в том числе с указанием правил
ПБ или их номеров;
• используя инструкции dup-to | to [имя интерфейса],
копии пакетов можно дублировать на специально выделенный хост,
на котором может быть установлен IDS-сенсор или выполнен лю-
бой другой процесс анализа трафика.
Другие возможности IP Filter
Дополнительно к перечисленным IP Filter реализует следую-
щие возможности:
• поддерживает гибкий доступ в правилах к любым полям за-
головков протоколов IP, ICMP, TCP и UDP;
• поддерживает все виды NAT (статическую, динамическую,
статическую с динамической выборкой) и перенаправление пор-
тов;
• поддерживает циклическую балансировку нагрузки:
rdr xll 192.168.0.1/32 port 80 ->
192.168.0.1,192.168.0.2 port 80 top round-robin
• обеспечивает реализацию фильтрующего моста Ethernet;
• предоставляет механизмы разработки дополнительного ПО
(API и инструкции ПБ), усиливающего и дополняющего защитные
возможности МЭ. Например, имеется возможность разработки
собственных прикладных посредников и механизмов аутентифика-
ции;
• обеспечивает широкие возможности отладки и проверки кор-
ректности функционирования МЭ. Утилита ipf test позволяет вы-
полнять отладку любой последовательности правил МЭ без изме-
нения текущей реализуемой ПБ.
IP Filter обладает богатыми функциональными возможностя-
ми, совместим со многими Unix-системами и во многих случаях
может быть лучшим выбором при организации защиты достаточ-
но крупных сетей.
214
8.8. Ipfwadm, ipchains, iptables
http://www.rustcorp.com/linux/ipchains
http://www.rustcorp.com/linux/iptrables
http://netfilter.filewatcher.org/
Уровень Пакетные фильтры
Класс SOHO, SME
Инспектор состояний iptables
Версия iptables 1.2.4
Операционная система Linux, начиная с версии ядра 2.0 (1994 г.),
содержала ПФ ipfwadm, переписанный на основе фильтра ipwf из
ОС BSD. В 1998 г. в версии ядра 2.2 был реализован пакетный
фильтр ipchains. В 1999 г. в ядре 2.4 появился ПФ с поддержкой
инспекции состояния, получивший название NetFilter, а утилита,
управляющая правилами фильтра - iptables. И ipfwadm, и
ipchains, и iptables являются утилитами, управляющими пра-
вилами фильтрации ПФ. Сам ПФ реализован в ядре ОС или может
динамически загружаться в форме модулей ядра ОС. Фильтр
ipfwadm морально устарел, поэтому далее будем рассматривать
особенности ipchains и iptables.
Утилита iptables получила такое название из-за особеннос-
тей архитектуры ядра Linux NetFilter. Для управления всеми фун-
кциями управления трафиком используются три системные табли-
цы: nat, mangle и filter. Таблица nat хранит правила трансляции
адресов, mangle используется для пакетов, в которых принудитель-
но изменяются некоторые поля заголовков (TTL, TOS) или поме-
чаются для дальнейшей обработки ядром, filter - для хранения
правил фильтрации пакетов.
Концепция цепочек
Одним из ключевых моментов рассматриваемых ПФ является
концепция цепочек (chains). Цепочки определяют две вещи - логи-
ческое направление прохождения сетевых пакетов и правила филь-
трации внутри цепочки. По умолчанию используются встроенные
цепочки input, output и forward.
Встроенные цепочки в МЭ ipchains реализованы следующим
образом (рис. 8.16). Поступающие на сетевой интерфейс пакеты
попадают в цепочку input. Если правила цепочки разрешают даль-
нейшее прохождение пакета, то далее анализируется получатель
пакета (решение о маршрутизации). Здесь возможно два варианта
- или пакет является транзитным, тогда он поступает в цепочку
215
Рис. 8.16. Обработка пакетов встроенными цепочками ipchains
Рис. 8.17. Обработка пакетов встроенными цепочками iptables
forward, или пакет адресован тому же хосту, на котором функцио-
нирует МЭ, тогда он поступает на обработку локальным процес-
сам. Все проходящие (транзитные) пакеты поступают в цепочку
forward. После обработки пакета в цепочке forward или локаль-
ными процессами пакеты поступают в выходную цепочку output.
Реализация встроенных цепочек в iptables имеет некоторые
отличия (рис. 8.17). Прежде всего это касается цепочек INPUT и
OUTPUT (имена встроенных цепочек в iptables пишутся в вер-
хнем регистре): они отвечают только за пакеты, предназначенные
для локальных сетевых процессов (INPUT), и пакеты, генерируе-
мые этими процессами (OUTPUT). Все транзитные пакеты сразу
поступают в цепочку FORWARD. Такие изменения значительно
облегчили написание правил фильтрации, поскольку ранее в
ipchains правила для транзитных пакетов можно было опреде-
лять во всех встроенных цепочках, что затрудняло разработку ПБ
МЭ.
Политика по умолчанию
Iptables позволяет устанавливать политику по умолчанию
«все запрещено» или «все разрешено». Например, следующие три
216
правила устанавливают политику по умолчанию для встроенных
цепочек:
iptables -Р INPUT DROP
iptables -Р OUTPUT DROP
iptables -P FORWARD DROP
Пользовательские цепочки
Ipchains и iptables для повышения гибкости ПБ МЭ по-
зволяют создавать пользовательские цепочки. Рассмотрим исполь-
зование пользовательских цепочек на следующем примере. Необ-
ходимо разработать ПБ МЭ, схема подключения которого показана
на рис. 8.18. Примем следующие допущения: в DMZ и локаль-
ной сети используются маршрутизируемые адреса, трансляция
адресов не используется, применяются только механизмы пакет-
ной фильтрации. Если использовать только встроенные цепочки,
Рис. 8.18. Пример организации пользовательских цепочек
217
то каждая из них будет содержать правила для всех информацион-
ных потоков. При большом количестве протоколов редактировать
такую политику будет крайне неудобно. Образуем пользовательс-
кие цепочки по следующему правилу - имя цепочки будет соот-
ветствовать направлению информационных потоков (или сетевых
пакетов). Например цепочка, определяющая потоки из защищае-
мой сети LocalNet в Интерне^ будет иметь имя net_int и т. д.
Определив подобным образом все цепочки, ПБ МЭ можно органи-
зовать следующим образом:
# ПРИМЕР ИСПОЛЬЗОВАНИЯ ПОЛЬЗОВАТЕЛЬСКИХ ЦЕПОЧЕК
# Политика по умолчанию - все запрещено
iptables -Р INPUT DROP
iptables -Р OUTPUT DROP
iptables -P FORWARD DROP
# Определяем основные переменные
DMZ=10.2.0.0/24
LocalNet=10.1.0.0/24
# Серверы DMZ
DMZ_WWW=10.2.0.2
DMZ_SMTP=10.2.0.3
DMZ_POP3=10.2.0.3
INT_DNS=10.5.0.1
# Создаем пользовательские цепочки
iptables -N dmz_ _int
iptables -N int_ _dmz
iptables -N dmz_ net
iptables -N net _dmz
iptables -N net_ _int
iptables -N int_ net
# Перенаправляем пакеты из цепочки FORWARD в пользовательские
# цепочки
iptables -A FORWARD -s $DMZ -o ethO “j dmz_int
iptables -A FORWARD -d $DMZ -1 ethO “j int_dmz
iptables -A FORWARD -s $LocalNet -o eth2 “j net_dmz
iptables -A FORWARD -s $DMZ -o ethO “j dmz_net
iptables -A FORWARD -s $LocalNet “O ethO “j net_int
iptables -A FORWARD -d $LocalNet -1 ethO “j int_net
218
# Цепочка net_int - разрешаем пользователям локальной сети
# доступ в Интернет по протоколу http, domain
iptables -A net_int -р tcp —dport http -j ACCEPT
iptables -A net_int -p udp -d $INT_DNS —dport domain -j ACCEPT
# Цепочка int_net - получаем ответы от HTTP серверов и
# DNS сервера провайдера,запрещая при этом пакеты
# с установленным флагом SYN
iptables -A int_net -р tcp ! —syn —sport http -j ACCEPT
iptables -A int_net -p udp -s $INT_DNS —sport domain -j ACCEPT
iptables -A int_net -m limit -j LOG
# Цепочка net_dmz - разрешаем пользователям доступ в DMZ
# по протоколам HTTP, SMTP, POP3
iptables -A net_dmz -p tcp —dport http -d $DMZ_WWW -j ACCEPT
iptables -A net_dmz -p tcp-dport smtp -d $DMZ_SMTP -j ACCEPT
iptables -A net_dmz -p tcp —dport pop3 -d $DMZ_POP3 -j ACCEPT
# Протоколируем все попытки несанкционированных соединений
iptables -A net_dmz -m limit -j LQG
f
# Цепочка dmz_net - получаем ответы от серверов DMZ
iptables -A dmz_net -p tcp ! —syn —sport http-s $DMZ_WWW \
-j ACCEPT
iptables -A dmz_net -p tcp ! —syn —sport smtp-s $DMZ_SMTP \
-j ACCEPT
iptables -A dmz_net -p tcp ! —syn —sport рорЗ-s $DMZ_POP3 \
-j ACCEPT
# Протоколируем все попытки несанкционированных соединений
iptables -A dmz_net -m limit -j LOG
# Цепочка int_dmz - разрешаем доступ в DMZ из Интернет
# по протоколам HTTP,SMTP
iptables -A int_dmz -р tcp —dport http -d $DMZ_WWW -j ACCEPT
iptables -A int_dmz -p tcp —dport http -d $DMZ_SMTP -j ACCEPT
# Цепочка dmz_int - разрешаем ответы
# пользователям Интернет из DMZ
iptables-A dmz_int-р tcp! —syn —sport http-s $DMZ_WWW \
-j ACCEPT
iptables-A dmz_int -p tcp! —syn —sport smtp-s $DMZ_SMTP \
-j ACCEPT
Как следует из этого примера, пользовательские цепочки по-
зволяют структурировать политику МЭ, но использование только
механизмов пакетной фильтрации не решает всех проблем созда-
ния надежной защиты. Из приведенных ниже примеров видно, как
219
Рис. 8.19. Цепочки и цели трансляции iptables
применение механизмов трансляции адресов и инспекции состоя-
ния позволяет не только обеспечить крепкую защиту, но и значи-
тельно облегчить создание ПБ МЭ.
Трансляция адресов
iptables поддерживает трансляцию адреса источника и
трансляцию адреса назначения как в статическом, так и динами-
ческом режимах. Для выполнения трансляции используются цели
SNAT, DNAT и MASQUERADE. Правила трансляции помещаются
в специальную таблицу nat. Трансляция выполняется при
прохождении пакетов через встроенные цепочки PREROUTING,
POSTROUTING и OUTPUT (рис. 8.19).
Пакеты, для которых должна выполняться трансляция адреса
назначения (DNAT), очевидно, должны обрабатываться перед их
маршрутизацией, что реализуется в цепочке PREROUTING.
Трансляция адреса назначения выполняется при прохождении
пакетов через цепочку POSTROUTING. Для пакетов, генери-
руемых локальными процессами, имеет смысл только трансляция
адреса назначения, которая может определяться в цепочке OUT-
PUT. При использовании подключения с динамически назначаемым
IP-адресом правила трансляции должны обрабатываться в цепочке
MASQUERADE.
Реализуем теперь ПБ из предыдущего примера, используя ме-
ханизмы трансляции адресов.
# ПРИМЕР ИСПОЛЬЗОВАНИЯ ТРАНСЛЯЦИИ АДРЕСОВ
# Политика по умолчанию - все запрещено
iptables -t nat -F
iptables -P INPUT DROP
iptables -P OUTPUT DROP
220
iptables -P FORWARD DROP
iptables -t nat -P POSTROUTING DROP
iptables -t nat -P PREROUTING DROP
# Включаем трансляцию на внешнем интерфейсе для
# протоколов HTTP и DNS
iptables -t nat -A POSTROUTING -о ethO -р tcp \
-------------------------dport http -j SNAT----to 10.3.0.1
iptables -t nat -A POSTROUTING -o ethO -p.udp \
—dport domain -j SNAT —to 10.3.0.1
# Включаем трансляцию на интерфейсе DMZ для
# пользователей локальной сети
DMZ_WWW=10.2.0.2
DMZ_SMTP=10.2.0.3
DMZ_POP3=10.2.0.3
iptables -t nat -A POSTROUTING -о eth2 -р tcp \
--------------dport http -d $DMZ_WWW -j SNAT----to 10.2.0.1
iptables -t nat -A POSTROUTING -o eth2 -p tcp \
--------------dport smtp -d $DMZ_SMTP -j SNAT---to 10.2.0.1
iptables -t nat -A POSTROUTING -o eth2 -p tcp \
---dport pop3 -d $DMZ_POP3 -j SNAT--to 10.2.0.1
# Включаем статическую трансляцию для подключения
# пользователей Интернет к серверам DMZ, при этом
# сервера WWW и SMTP известны как:
NET_WWW=10.3.0.20
NET_SMTP=10.3.0.30
iptables -t nat -A PREROUTING -i ethO -p tcp \
--------------dport http -d $NET_WWW -j DNAT----to $DMZ_WWW
iptables -t nat -A PREROUTING -i ethO -p tcp \
----dport smtp -d $NET_SMTP -j DNAT--to $DMZ_POP3
В этом примере пользовательские цепочки и пакетная фильт-
рация не использовались. Кроме того, передача пакетов между ин-
терфейсами запрещена (-Р forward drop). ПБ реализована только
с использованием трансляции адресов. Одним из преимуществ ис-
пользования трансляции является автоматическое отслеживание
обратной стороны соединения, в нашем случае ответов от серве-
ров. Обратите внимание - мы нигде не определяли правила для
пакетов, отправляемых серверами Интернет и DMZ.
221
Iptables позволяет с помощью трансляции адресов также
организовать простейшие схемы балансировки нагрузки. Напри-
мер, следующее правило использует трансляцию адреса получа-
теля и позволяет организовать распределение нагрузки между Web-
серверами 10.2.0.40,10.2.0.41, 10.2.0.42,10.2.0.43:
iptables -t nat -A PREROUTING -i ethO -p tcp \
—dport http -j DNAT —to 10.2.0.40-10.2.0.43
Инспекция состояния в iptables
iptables, или более точнее Netfilter, позволяет определить
принадлежность каждого сетевого пакета к одной из следующих
возможных фаз состояния соединения:
NEW—новое соединение. Характеризует фазу инициализации
соединения;
ESTABLISHED — соединение установлено;
RELATED — определяет отношение пакета к некоторому се-
тевому взаимодействию, но не соединению. Например, сообщения
об ошибках протокола ICMP;
INVALID — пакет не может быть ассоциирован ни с одним из
установленных соединений.
Следующие два правила позволяют создать персональный эк-
ран, разрешающий все исходящие соединения и блокирующий все
входящие пакеты, не принадлежащие исходящим соединениям:
# ПРИМЕР ИСПОЛЬЗОВАНИЯ IPTABLES В КАЧЕСТВЕ ПЕРСОНАЛЬНОГО
ЭКРАНА
iptables -Р INPUT DROP
iptables -Р OUTPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -m state--------state ESTABLISHED,\
RELATED -j ACCEPT
iptables -A OUTPUT -m state-----state NEW,ESTABLISHED, \
RELATED - j ACCEPT
iptables -A INPUT -i ethO -m limit---------limit 2/m \
—limit-burst 5 -j LOG —log-prefix «Bad packet from ethO:»
Все пакеты, поступающие на сетевой интерфейс и не принад-
лежащие ранее установленным соединениям, будут регистриро-
ваться через Syslog с префиксом «Bad packet from ethO:»
222
Dec 19 23:28:50 fw kernel: Bad packet from ethO IN=ethO OOT=
MAC=00:01:02:c9:2e: 2f:00:80:ad:50:e3:57:08:00 SRC=10.0.0.40
DST=10.0.0.4 LEN=40 TOS=0x00 PREC=0x00 TTL=48 ID=63152
₽ROTO=TC₽ S₽T=39232 DPT=695 WINDOW=1024 RES=0x00 SYN URGP=0
Протоколирование событий и защита от DoS-атак
Использование механизма ограничения скорости срабатывания
правил (модуль limit) позволяет протоколировать события безопас-
ности без опасения быстрого заполнения журнала, а также предот-
вращать некоторые атаки отказа в обслуживании. При использо-
вании ограничений по умолчанию определяются три срабатывания
в 1 ч с максимальным количеством последовательно фиксируе-
мых событий, равным 5 (параметр —limit-burst). Дополни-
тельный параметр —limit-burst определяет максимальную оче-
редь срабатывания ограничений. Например, команда
iptables -A FORWARD -m limit -j LOG
регистрирует каждые 20 мин первые 5 пакетов и, таким образом,
максимальное количество записей в журнале событий (syslog) о
пакетах, пройденных через МЭ за 1 ч, определяется как
limit*burst = 3*5 = 15 записей.
Iptables, используя механизм ограничений, позволяет защи-
титься от типовых атак отказа в обслуживании и различных видов
сканирования портов. Например, следующие три команды позво-
ляют предотвратить атаки SYN-flood, Ping of death и скрытое ска-
нирование портов соответственно:
iptables -A FORWARD -р tcp —syn -m limit —limit 1/s \
-j ACCEPT
iptables -A FORWARD -p icmp ----icmp-type echo-request \
-m limit —limit 1/s -j ACCEPT
iptables -A FORWARD -p tcp -----tcp-flags SYN, ACK, FIN, RST\
RST -m limit —limit 1/s -j ACCEPT
Эти команды разрешают прохождение потенциально опасных
пакетов, если они появляются не чаще 5 раз в 1 с. Запись —tcp-
flags SYN, АСК, FIN, RST RST означает, что будут проверяться
флаги SYN, АСК, FIN, RST, но только флаг RST должен быть ус-
тановлен.
223
МА С-фильтрация
Iptables в цепочках PREROUTING и INPUT позволяет вы-
полнять фильтрацию пакетов на основе МАС-адреса отправителя.
Такая функциональная возможность особенно может быть полез-
на в домовых сетях, где проблема защиты от подмены IP-адресов
стоит особенно остро. Например, следующая команда разрешает
прохождение пакетов, если МАС-адрес источника соответствует
заданному:
iptables-A INPUT —maa-eource 00:10:А4:В2:ВЕ:8С -j ACCEPT
МЭ iptables предоставляет мощные, развитые средства ПФ,
управления сетевым трафиком и протоколирования событий. На
базе этого средства и свободно распространяемых прикладных
посредников и сервисов, таких как SQUID, Apache, BIND, можно
создавать системы защиты, не уступающие по ряду параметров и
некоторым коммерческим МЭ. Однако большое количество функ-
циональных возможностей, сложность командного языка, отсут-
ствие графического интерфейса управления определяют повышен-
ные требования к квалификации администратора МЭ. Проблему
сложности эксплуатации iptables можно частично компенсиро-
вать, используя различные дополнительные графические утилиты
управления, например Firewall Builder (рис. 8.20).
Рис. 8.20. Программа управления МЭ iptables Firewall Builder
224
8.9. WinRoute Pro
http: //www.tinysoftware. com
Уровень
Класс
Инспектор состояний
Версия
Экспертный
SOHO, SME
Да
4.1
МЭ WinRoute Pro компании TINY Software относится к классу
SOHO-приложений и предназначен для защиты сетей небольших и
средних размеров. Ряд примечательных свойств и возможностей
этого продукта особенно выделяют его среди других продуктов
своего класса, а по совокупности свойств приближается к промыш-
ленным МЭ.
Один и тот же дистрибутив (чуть более 1200 кб!) программы
может быть установлен на любую 32-разрядную ОС Windows -
95/98/NT4.0/2000. Требования к системным ресурсам минималь-
ны. В отличие от аналогичных продуктов, на хостах локальной сети
не требуется установка дополнительного ПО. Вся настройка ра-
бочих станций заключается в указании адресов шлюза и DNS-
сервера. Таким образом, WinRoute обеспечивает «прозрачность»
в работе для любых ОС.
Архитектура ядра реализована на нижнем уровне сетевого стека
ОС - драйвер WinRoute запускается перед запуском модулей NDIS.
Такой подход обеспечивает прием, анализ и обработку сетевых
пакетов перед тем, как они будут переданы ОС.
WinRoute поддерживает следующие функциональные возмож-
ности:
• фильтрация пакетов;
• трансляция адресов;
• трансляция портов;
• гибкое управление телефонными соединениями;
• мощный механизм протоколирования событий;
• кэширующий посредник HTTP;
• DHCP-сервер;
• Split DNS;
• SMTP/РОРЗ-серверы;
• удаленное управление, в том числе и по протоколу HTTP.
Пакетный фильтр определяет правила для входящих и исходя-
щих пакетов на любом существующем интерфейсе, а также позво-
ляет выполнять проверку принадлежности пакета к установленным
соединениям, для протокола TCP (рис. 8.21). Таким образом,
WinRoute частично реализует технологию инспекции состояния.
8 Лебедь С.В.
225
Add hem
f P«ck«t
j BK^M^ljrS*” ’""3 ' .-; : ', '/"< V- Ч- -v
!' £cuKjt"~" -—- ~’ >~~:"' ~
j .- Ти»‘| Network/МмГ 3- - ' , ТЙ^*|м^kites~’~^ --
j 1РЩт:|шаЙ ,; , 7;? >7/”- X V ;'
j ' МШ:}ЖЖЖО \'v; ,\" ' :. - /, : ,v;?' '/& -y.^Y-^y//
j' - RertrfAnJ—~ "'3 '' ' •<. ‘'V
j ../ . . < '\?5 ; >
l~-1CF Rags———
! ^Ф.^аЫИЪИ.TCF,.CGnr£g^| : ; i:
J. Г Onb’eMa^shhgTCT’txow^OT ’ |
rAelm-”*—i
J , C W :
,| . Г OW
j * tw
- Log Packet
-Г LogwtoPe
Г Ug«to2^fcw
| OK I Cancel |
Рис. 8.21. Фильтр пакетов WinRoute проверяет принадлежность
пакетов к установленным ТСР-соединениям
Поддержка нескольких сетевых интерфейсов позволяет организо-
вать DMZ-зону или управлять безопасностью для нескольких се-
тей.
Механизмы управления телефонными соединениями позволя-
ют реализовать практически любую схему установления сетевого
соединения (по запросу сетевых приложений, периодически в за-
данное время, постоянно), определять ограничение по дням неде-
ли, настраивать количество попыток соединения и время отсут-
ствия активности, после которого соединение разрывается.
Предоставляемые функциональные возможности управления со-
единениями позволяют, во-первых, значительно экономить сто-
имость оплаты соединения, а во-вторых, использовать линию для
телефонной связи.
Почтовая система WinRoute состоит из полнофункциональных
SMTP/РОРЗ-серверов. Две главные ее возможности - автомати-
ческий прием сообщений от внешних POP-серверов и перенаправ-
ление их на собственные, выполнение операций по расписанию -
позволяет организовать удобный, гибкий и экономичный почтовый
сервис.
226
10 ...100 Мбит
userl @provider.com
price@localnet
user2@provider.com
info@provider.com
secr@localnet
user3@provider.com
info@provider.com
main@localnet
WinRoute
SMTP/P0P3
Сервер провайдера
SMTP/POP3
Пользователи WinRoute
main
seer
price
POP ящики провайдера
Рис. 8.22. Вариант организации почтового сервиса с использованием WinRoute
м
На рис. 8.22 показан вариант организации почтового сервиса с
использованием WinRoute небольшой организации. Организация под-
ключена к сети Интернет через dial-up-соединение. Соединение ус-
танавливается по требованию. Четыре почтовых ящика предос-
тавлены провайдером услуг Интернет. Для трех пользователей
локальной сети созданы бюджеты на МЭ. Почтовая система
WinRoute периодически обращается к POP-серверу провайдера,
читает сообщения и перенаправляет их своим пользователям со-
гласно выбранным правилам, а также отправляет исходящую по-
чту по протоколу SMTP. Преимущества использования такой схе-
мы следующие:
• пользователи отправляют/принимают сообщения на скорос-
ти, обеспечиваемой локальной сетью и отделены от проблем, свя-
занных с низкоскоростным внешним соединением;
• внешние почтовые ящики могут совместно использоваться
несколькими пользователями локальной сети;
• экономнее расходуется время сетевого соединения.
К недостаткам WinRoute Pro можно отнести следующие:
• полностью отсутствуют механизмы уведомления о событи-
ях. Несмотря на то, что все ошибки регистрируются в соответ-
ствующих журналах, уведомлять о них администратора нет воз-
можности;.
• недостаток в процедуре аутентификации на POP-сервере по-
зволяет злоумышленнику проверять наличие пользовательских
бюджетов. При отсутствии пользователя после выполнения коман-
ды user <имя пользователя> сервер выдаст сообщение:
4-ОК WinRoute Pro 4.1 POP3 server ready <4293195365.969858051@gw>
USER office
-ERR Sorry, office doesn't get his mail here
Несмотря на указанные недостатки, низкая стоимость WinRoute
Pro делает его привлекательным для небольших организаций.
8.10. Встраиваемый МЭ Network-1 CyberwallPLUS
http ://www.network-1 .com
Уровень Фильтр пакетов
Класс SOHO
Версия 6.03
В некоторых случаях необходимо обеспечить защиту приклад-
ных серверов, но по каким-либо причинам использование обычных
228
сетевых МЭ иногда затруднено. Например, прикладные службы
размещаются на выделенных (dedicated) серверах провайдера, уда-
ленных территориально, или же защищаемые серверы находятся в
относительно небольшой односегментной локальной сети. Одним
из способов решения подобных задач может стать использование
так называемых встраиваемых (или встроенных) МЭ (Embedded
Server Firewall). Встраиваемый МЭ устанавливается на каждый
защищаемый сервер и является «прозрачным» как для ОС серве-
ра, так и для прикладных служб.
Одним из лучших продуктов класса встраиваемых МЭ являет-
ся продукт CyberwallPLUS компании Network-1. Один и тот же
дистрибутив этого продукта может быть установлен как встраи-
ваемый, персональный, многопротокольный или обычный МЭ. Рас-
смотрим особенности этого МЭ, устанавливаемого как встраива-
емый МЭ (рис. 8.23).
CyberwallPLUS обеспечивает защиту по принципу действия
пакетных фильтров. МЭ имеет очень простой и интуитивно понят-
ный графический интерфейс управления. Для тех администрато-
ров, которые имели дело с сетевыми МЭ, освоение этого продукта
займет не более 30 мин.
jy I уЬггнмИР! US SV jSV|Wrb Svtvei Secunty I empl МШ
Mmi I I lлмш I I I I SvitaM I ,/> ;
CyberwallPLUS*
Active Security PoUcy: (SV) Web Server Security Template
F^enHForHeip
Рис. 8.23. Окно управления «Main» МЭ CyberwallPLUS Network-1
229
1^й»пЛт»НЯйИ^:-'Л ' ’ • Pw»Л F<xHdp "
Рис. 8.24. Окно ПБ МЭ CyberwallPLUS Network-1
Политика безопасности МЭ определяется в закладке Rules
(рис. 8.24). Редактирование правил ничем не отличается от проце-
дуры редактирования правил пакетных фильтров за исключением
того, что одним из адресов источника или получателя всегда явля-
ется сам защищаемый сервер. Все объекты ПБ предварительно
должны быть определены в закладке Nodes (узлы).
Набор правил может быть сохранен в виде шаблона ПБ. Про-
дукт поставляется с типовыми шаблонами (более тридцати), со-
держащими схемы обеспечения безопасности наиболее распрост-
раненных сетевых служб. Одна из интересных особенностей
продукта заключается в возможности применения различных ПБ
по расписанию. Например, одним из вариантов использования та-
кой возможности может быть применение политики, запрещающей
подключение пользователей к прикладным службам в нерабочее
время, но разрешающей взаимодействие с другими серверами в
сети (например, в целях тиражирования или резервного копирова-
ния данных).
Встроенная система обнаружения вторжений позволяет обна-
руживать 11 различных DoS-атак, причем для большинства из них
администратор может изменять параметры, используемые по
умолчанию. Изменение параметров системы обнаружения втор-
230
Evert Record. 2948 ol 8920 @ 02/14/2001 151237 339
Evert Fol • SYN Flood
IProtocds:ETHERNETS IP TCP
Source [Origin: (Intrusted) Ary Node (10 0.0.40)
Destination : Local Machine (10 0.0 4)
й Frame. Ethernet V2
Desfmation„Address • 0x000102C92E2F
If DestmatrorLMamiacturer 0x000102
| $ouce_Addte» Qx0080AD50E357
:< DestmtionLSW' 0x2E2F
SourceJSW. 0x£357
I Source_Manrtadure<: OhOOBOAD
X Protocol 0x0800 - TCP/IP Internet Protocol
Network Protocol IP Internet Protocol
RawVarston: 0x40 . . -!s
Й Header_Length_Words: 5 <
й Type_of_Service 0x00
0000 000102C9 2E2FOO0O ADS0E3S7 00004500 ....z...P.O..E. a
0010 00ЭС1999 40004005 OCFOOAOO О020ОЛО0 < • • (
“ 0020 00040625 054D0B9E 2D730000 00004002 Z И -s . Д
0030 7D7000BS 00000204 05B40402 080Л001Е )x ....................
' 0040 FIOCOOOO 00000103 0300
Рис. 8.25. Протоколирование событий ПБ МЭ CyberwallPLUS
жений позволяет исключить сигналы ложной тревоги и увеличить
точность обнаружения атак.
CyberwallPLUS подробно протоколирует события ПБ. Для каж-
дого события, помимо его описания, полностью регистрируется и
сам сетевой пакет, вызвавший соответствующее действие (рис.
8.25). В режиме детального просмотра событий, подобно анализа-
торам трафика, МЭ выполняет подробный анализ пакета, что по-
зволяет как выявлять причины и источники проблем безопасно-
сти, так и анализировать работоспособность сервисов и самой
сети.
Функции централизованного удаленного управления позволяют
использовать продукт и в корпоративной среде. С одной консоли
управления можно не только управлять ПБ всех МЭ CyberwallPLUS
в сети, но и анализировать их журналы событий и получать различ-
ную отчетную информацию.
Продукт может использоваться и дополнительно, если защита
серверов (сервера) реализуется посредством сетевого МЭ. В этом
случае CyberwallPLUS вносит дополнительный уровень безопас-
ности.
231
8.11. Internet Connection Firewall
операционной системы MS Windows XP
http://www.microsoft.com
Тип
Версия
Дополнительные
возможности
фильтр пакетов
1.0
инспектор состояний
Впервые в своей ОС Windows ХР компания Microsoft реализо-
вала МЭ Internet Connection Firewall (ICF). Основное назначение
ICF - защита разделяемого соединения и организация подключе-
ний к внутренним сервисам защищаемой сети. Таким образом, ICF
выполняет динамическую трансляцию адресов на внешнем интер-
фейсе и статическую трансляцию для каждого сервиса защищае-
мой сети, доступ к которым необходимо обеспечить. Функции ПФ
реализованы только для протокола ICMP. ICF может быть вклю-
чен на каждом из имеющихся интерфейсов (рис. 8.26). Microsoft
4- ethO Properties
• GeneraH Authentication] Advanced
Internet Connection Firewall
0potsct n^Srn^er ar^r^worC^
_______________________________________________J
Learn more about Int^,,^
Internet Connection Sharing
Q AH°w other Detwork users to connect through this
computer’s Internet connection
Mfiw other network users to potrtrd or trie
shared Internet «nwter»
Learn more about Int^t Cpnna^Jharhq
If you're not sure how to set these properties, use .-------------------
theNgtwo^ I Settings... j
1 OK j I Cancel ]
Рис. 8.26. Включение МЭ Internet Connection
Firewall на интерфейсе ethO
232
Рис. 8.27. Определение правила для НТТР-сервиса
МЭ Internet Connection Firewall
рекомендует применять ICF при использовании режима разделе-
ния Intemet-соединения (Internet Connection Sharing) и непосред-
ственном подключении к Интернет рабочей станции.
Microsoft декларирует реализацию в МЭ ICF технологию инс-
пекции состояния канала связи. Обратим внимание на тот факт,
что ПФ как таковой в ICF отсутствует, а при динамической транс-
ляции в любой реализации NAT создается динамическая таблица,
содержащая правила соответствия исходных и транслируемых
адресов.
Политика безопасности МЭ определяется в окне «Service
settings» (рис. 8.27). Настройка параметров сводится только к ус-
тановке имени или IP-адреса сервиса защищаемой сети, типа
транспортного протокола (TCP или UDP) и номеров транспортных
портов. По умолчанию ICF предоставляет шаблоны для организа-
ции следующих входящих соединений: FTP, SMTP, IMAP3, IMAP4,
IKE, POP3, Remote Desktop, HTTPS, HTTP, Telnet, L2TPh PPTP.
Система регистрации событий позволяет протоколировать раз-
решающие и блокирующие правила ПБ. Журнал событий представ-
ляет собой текстовый файл, по умолчанию размещаемый в корне-
вом каталоге Windows с именем pfirewall.log (рис. 8.28).
Журнал имеет фиксированную структуру, включающую следую-
щие поля: дата, время, действие (DROP, OPEN, CLOSE), протокол
(ICMP, TCP, UDP), IP-адрес источника, IP-адрес назначения, порт
233
#Verson: 1.0
#Software: Microsoft Internet Connection Firewall
#Time Format: Local
#Fields: date time action protocol src-ip dst-ip src-
port dst-port size tcpflags tcpsyn tcpack tcpwin
icmptype icmpcode info
2001-10-22 12:51:34 DROP ICMP 10.0.3.1 10.0.3.2 — 60-----
80-
2001-10-22 12:51:34 DROP UDP 10.0.0.111 10.0.3.2 137 137
96--------
2001-10-22 12:53:37 DROP TCP 10.0.3.1 10.0.3.2 3747 139
48 S 674532789 0 16384 —
2001-10-22 12:59:16 OPEN TCP 10.0.1.2 10.0.0.111 3009 80
2001-10-22 12:59:23 DROP UDP 10.0.1.1 10.0.1.2 123 123
76--------
2001-10-22 13:00:48 CLOSE TCP 10.0.1.2 10.0.0.111 3009
80--------
Рис. 8.28. Фрагмент журнала событий МЭ Internet Connection Firewall
источника, порт получателя, размер пакета, флаги TCP, номер оче-
реди, номер очереди подтверждения, размер TCP-окна, тип ICMP-
сообщения, код ICMP-сообщения и дополнительное информацион-
ное поле. Незаполненные поля отмечаются в журнале символом «-».
Политика безопасности МЭ при использовании его в качестве
персонального экрана выглядит следующим образом - разрешены
все исходящие соединения, все входящие соединения блокируют-
ся. При этом отсутствует возможность блокировки исходящего
трафика. В режиме персонального экрана определение ПБ сводит-
ся только к определению сетевых сервисов, доступных на этой же
рабочей станции, и некоторых типов входящих и исходящих сооб-
щений протокола ICMP (рис. 8.29).
Можно выделить несколько недостатков ICF, затрудняющих его
практическое использование как в качестве персонального экрана,
так и ПФ на внешнем интерфейсе:
• ПФ отсутствует вовсе. По этой причине нельзя создавать
блокирующие правила;
• ICF не отслеживает работу сетевых локальных приложений
при использовании его в режиме персонального экрана;
• журнал событий регистрирует события применительно ко всем
правилам одновременно, отсутствует возможность выборочной
регистрации событий;
234
Рис. 8.29. Настройка использования протокола
ICMP в МЭ Internet Connection Firewall
• отсутствуют возможности удаленного управления;
• при наличии нескольких сетевых интерфейсов правила опре-
деляются независимо от других.
Несмотря на все эти недостатки, ICF входит в состав ОС и
обеспечивает минимальный уровень безопасности подключения к
Интернет. Наличие инспектора состояний позволяет предотвратить
большинство DoS-атак, а также отслеживать время открытия сес-
сий (на основе сообщений журнала событий OPEN и CLOSE). ICF
пока еще не может конкурировать с большинством других персо-
нальных экранов, но его можно использовать для защиты разделя-
емого соединения в небольших организациях и домашних сетях.
8.12. Персональные МЭ
Объектами сетевых атак в последнее время становятся не
только сетевые серверы, но и рабочие станции. Рабочие станции
корпоративной сети, домашние компьютеры сотрудников в некото-
рых случаях содержат более конфиденциальную и важную инфор-
235
мацию, чем корпоративные серверы. К тому же, защите рабочих
станций и тем более домашних компьютеров уделяется намного
меньше внимания (либо не уделяется вовсе). Все эти причины обус-
ловили появление отдельного класса МЭ - персональных.
Исходя из возможных угроз ИБ клиентского компьютера, под-
ключенного к Интернет, можно выделить следующие функции, ко-
торые целесообразно возложить на персональный МЭ:
• пресечение загрузки и выполнения троянских программ;
• обнаружение активных деструктивных компонент протокола
HTTP (java, ActiveX, cookies);
• фильтрация тегов HTTP с целью блокирования рекламных
банеров, картинок и мультимедийных компонент с целью умень-
шения времени загрузки HTML-страниц;
• контроль ресурсов компьютера, выделенных в общедоступ-
ное использование другим компьютерам локальной сети (через
интерфейс NetBIOS);
• обнаружение и блокирование DoS-атак;
• контроль всех сетевых соединений;
• контроль сетевой активности приложений, в том числе обна-
ружение и блокирование несанкционированных запусков локальных
программ-серверов;
• обнаружение и уведомление о сканировании портов или не-
санкционированных запросах на установление соединения;
• антивирусная защита;
• полная блокировка трафика (по команде пользователя или
автоматическая) при обнаружении атак.
Кроме перечисленных функций, персональный МЭ должен об-
наруживать подготовительные действия хакеров (например, ping
или tracert), т. е. выполнять функции «раннего предупреждения»
IDS. В отличие от МЭ, рассмотренных выше, персональные МЭ
призваны защитить всего один компьютер, что и определяет ос-
новные особенности построения и функциональности персональных
МЭ.
Если МЭ реализуют политику прохождения сетевых пакетов
между двумя и более сегментами сети, то персональные МЭ реа-
лизует политику прохождения (запретить/разрешить) входящих и
исходящих сетевых пакетов. Персональные МЭ могут выступать
посредниками между прикладными сетевыми процессами (програм-
мами) и сетевым драйвером. Такой подход более понятен для ря-
дового пользователя, поскольку политика реализуется на уровне
приложений. Например, два правила ПБ персонального МЭ в этом
случае могут звучать так:
236
1) программе Internet Explorer работу в Интернет РАЗРЕ-
ШИТЬ-,
2) программе Personal Web Server быть сервером для клиен-
тов Интернет ЗАПРЕТИТЬ.
Реализация политики на основе фильтров требует от пользова-
телей знаний основ стека TCP/IP. Но такой подход позволяет в не-
которых случаях усиливать ПБ или создавать тонкие и гибкие пра-
вила. Персональные МЭ, отслеживающие деятельность сетевых
приложений, лучше справляются с обнаружением и пресечением
действий троянских программ.
В ряде случаев персональные МЭ используют для защиты сер-
веров локальной сети, подобно встраиваемым МЭ. Большинство
персональных МЭ использует собственный драйвер, располагаю-
щийся ниже сетевого стека самой ОС, что позволяет усилить ее
защиту.
ConSeal PC Firewall
http://www.consealfirewall.com/
Тип Гибридный
Версия 2.06
ConSeal PC Firewall компании Signal 9 Solutions - один из луч-
ших персональных МЭ, работающий как фильтр пакетов сетевого
и транспортного уровней с расширенными возможностями. Ком-
пания McAfee приобрела права на ConSeal PC Firewall в начале
2000 г. и теперь этот продукт известен как McAfee Personal Firewall.
Сетевая безопасность локального компьютера реализуется за-
данием соответствующих правил. Для определения конкретного
правила необходимо определить следующие параметры:
• сетевое устройство (интерфейс), к которому применяется пра-
вило (все устройства, сетевой адаптер или модем);
• служба Интернет, для которой создается правило. Служба
определяет порт транспортного протокола, поэтому ее определе-
ние не обязательно - можно задать номер порта вручную;
• протокол (TCP/IP, UDP/IP, NetBEUI, IPX/SPX, ARP, RARP);
• направление передачи пакета - входящий, исходящий;
• приоритет правила. Приоритет определяет последовательность
применения правил для сетевых пакетов;
• действия над пакетом - разрешить, запретить. Если пакет
разрешен, то дополнительно можно применить еще два правила -
237
блокировка фрагментированных пакетов и блокировка входящих
соединений. Блокировка фрагментированных пакетов позволяет
избежать различных атак типа отказа в обслуживании, основан-
ных на фрагментации пакетов;
• адресная информация отправителя и получателя - 1Р-адрес,
маска, порт (или диапазон портов);
• когда применяется правило - всегда, при установленном dial-
up соединении, во время установления dial-up соединения или во
время работы конкретного клиентского приложения (например,
ICQ).
Если над пакетом выполнено действие, то результат может быть
записан в журнал и выдается предупреждение на экран консоли
МЭ. Журнал хранит записи в формате ASCII, который можно про-
смотреть любым текстовым редактором.
При первичной инсталляции программы (рис. 8.30) автомати-
чески создаются правила, блокирующие атаки, ориентированные
на ошибки в интерфейсе NetBIOS и реализации протокола ICMP, а
также атаки, использующие фрагментацию пакетов. Правила, за-
данные по умолчанию, обеспечивают защиту компьютера и рабо-
ту большинства клиентских приложений в Интернет.
При запросе соединения с удаленным IP-хостом программа
предлагает выполнить действие над запрашиваемым соединени-
FvewaR Rule set ИВ
Ref... | Desenpfon | Alo... | In | Out | Remote Address | Remot... j Remote Pct... } Local Addr.,
30 Block land* attack. Block In Out My Address
12 Atow Identifcatbn. Alow In Out AiAddresses
38 Alow FTP Alow In Out Al Addresses
15 Alow most Internet access Hu Alow In Out Al Addresses
5 Block Wr^uke^fleshares and.. Block In Out Al Addresses
3 Alow name resolution (DNS). Alow In Out Al Addresses
6 Block NetBIOS during diaksp. Block In Out Al Addresses
7 Alow NetBIOS (when nodiaMpL. Alow In Out Al Addresses
2 Ping others. Alow In Out Al Addresses
3 „ Block IOIP nukes and more. Block In. Out Al Addresses
_________________
255.255... Al Ports
0.0.00 Al Ports
0.0.00 Ftp
0.0.0.0 Al Pats
0.0.0,0 AlPorts
0.0.Q0 DNS
00.00 NetBIOS
0.0.00 NetBIOS
0.000 Ping Reply
00.0.0 Al Types
4Ш _
My Address
My Address
Al Addresses
My Address
My Address
My Address
My Address
Al Addresses
My Address
Al Addresses,
Рис. 8.30. Политика по умолчанию ConSeal PC Firewall
238
ConSeal PC FIREWALL EJ
Reirrate system 194.67.88.20T warts to corriect
to you. apparent^ for Finger, Alow I throe#»?
f~~A>ow~~|| Alow duino this session |
Bfodk | Block during this session |
Igrorei | .. Edl |
Show Petals | Eight» Rides | НФ |
Рис. 831. Реакции Conseal PC Firewall на
запрос соединения co службой Finger,
полученного от IP-хоста 194.67.88.201
ем - разрешить или блокировать (рис. 8.31) и автоматически со-
здает и добавляет соответствующее правило.
ConSeal PC Fierwall не содержит шлюзов приложений. Поэто-
му отсутствуют возможности, присущие шлюзам приложений, та-
кие как блокировка URL, компонентов протокола HTTP и т. п. На-
пример, определение правил для протокола FTP, использующего два
транспортных канала TCP (канал управления и канал передачи
данных), заключается в разрешении соединений для всех IP-адре-
сов, назначении портов TCP 20-21 и блокировки входящих соеди-
нений.
Рассмотрим, что произойдет, если на локальном компьютере с
установленными по умолчанию правилами, запустится троянская
программа, отправляющая результаты своей работы по электрон-
ной почте (протокол SMTP). В этом случае МЭ обнаружит новое
соединение, выдаст соответствующее предупреждение на консоль
и разрешит соединение (рис. 8.32). Если на компьютере установ-
лена звуковая карта, то предупреждение будет сопровождаться зву-
ковым сигналом. Несанкционированное соединение будет обна-
2000/04/20 17:40:49 GMT +0400: E190xl[Ref# 15]
Connection Attempt: 3X0=10.0.0.112, dst=10.0.0.40,
sport=1080, dport=25.
2000/04/20 17:40:50 GMT +0400: E190xl[Ref# 12] WARNING:
Incoming traffic: src=10.0.0.40, dst=10.0.0.112,
sport=1025, dport=113.
Рис. 8.32. Сообщения ConSeal PC Firewall
239
ружено, но не пресечено. Троянская программа может передавать
данные и по любому другому прикладному протоколу. Для того
чтобы исключить такую ситуацию, необходимо:
• задать правила для каждого используемого протокола,
• запретить все исходящие соединения,
• реагировать на предупреждения МЭ о появлении новых со-
единений в нехарактерные моменты времени (например, во время
отсутствия сетевой активности используемых приложений)
Для поддержки пользователей, не имеющих достаточных зна-
ний о стеке TCP/IP и работе сетевых приложений, предлагается
дополнительно с сервера компании загрузить файлы описания ПБ
для работы основных приложений Интернет.
Хотя ConSeal PC Fierwall и не отслеживает деятельность сете-
вых программ, тем не менее существует возможность определе-
ния времени действия правил МЭ по наличию активных сетевых
программ. Использование этой возможности позволяет пресекать
работу троянских программ.
ZoneAIarm
http ://www. zonelabs, сот/
Тип Монитор приложений
Версия 2.1
Работа персонального МЭ ZoneAIarm компании ZoneLabs со-
стоит в управлении разрешением сетевых соединений локальных
программ и входящих Интернет-соединений. Такой подход позво-
ляет использовать программу пользователям, имеющим минимум
знаний о ИБ при работе в сети и ее протоколах.
Так же, как и ConSeal PC Firewall, ZoneAIarm сразу после ин-
сталляции начинает работать с заданными по умолчанию настрой-
ками, создавая правила безопасности «на лету». Любая запускае-
мая программа, использующая протокол IP, блокируется, пока
пользователь не даст разрешение или запрещение на ее выполне-
ние (рис. 8.33). ZoneAIarm контролирует не только прикладные про-
граммы, но и системные, например службы Windows NT. Програм-
мы заносятся в список, в котором для каждой из них определяются
разрешения соединения (разрешить, запретить, запросить) при ра-
боте в Интернет и локальной сети. Аналогично определяется,
может ли программа выступать в качестве сервера (рис. 8.34).
240
ZoneAIarm
The firewal has tfocked Internet access to you
computer (NetBIOS Sewon) from 10.0.0.40 (TCP
Port 1034}.
Time: 21.04.0010:19:04
tjoreirrfo J
Г iDorft show this dialog agairj
OK
J
N
ZoneAIarm
Рис. 8.33. Предупреждение программы ZoneAIarm
о попытке инициализации сессии NetBIOS IP-хостом
10.0.0.40
Программа T ehet
П
Microwft internet Expfotet
500.2314.1000 Inter
Pro® am
^Команда Ping TCP/IP
UeaT * 1
4.00 Internet: 1 4 ?
fiSiislWi
4.00 4 X,4
loc< Product name П рограмма T elnet
File name DAWINNT\$y$tem32Melnet.exe
Product ver»
Create date
File toe
4.00
16.01.9711:28'26
79.63 К0
Рис. 8.34. Окно PROGRAMS МЭ ZoneAIarm
Обнаружение серверной активности предотвращает деятельность
различных троянских программ, предоставляющих хакерам меха-
низмы удаленного управления.
9 Лебедь С.В.
241
Персональный МЭ ZoneAlarm позволяет:
• блокировать весь трафик (Internet Lock - Замок Интернет)
или Интернет-соединение нажатием кнопки на панели управления;
• автоматически блокировать трафик в отсутствие активности
пользователя по времени или синхронно с запуском программы
хранителя экрана.
Для программ, постоянно (длительно) работающих в сети, можно
исключить режим автоматической блокировки, установив флажок
Pass Lock. ZoneAlarm разделяет сеть на две зоны - локальную,
включая компьютер пользователя и компьютеры локальной сети,
и зону Интернет. Разделение на зоны позволяет определить прави-
ла безопасности (режимы ограничений) в каждой зоне (табл. 8.3).
Правила определяют доступ к разделяемым ресурсам (интерфейс
NetBIOS), режим блокировки трафика и видимость компьютера
(прикладных серверов и ICMP-сообщений). При наивысшем уров-
не безопасности компьютер, как IP-хост, становится полностью
невидимым.
Таблица 8.3. Уровни безопасности персонального МЭ ZoneAlarm
Уровень безопас- ности Зона
Интернет Локальная
Low Medium Internet Lock блокирует толь- ко трафик приложении Разрешен Интернет-доступ к сервисам Windows, разделяе- мым файловым и принтерным ресурсам Серверные приложения ло- кального компьютера видны из Интернет Разрешен трафик в/из Интер- нет Internet Lock блокирует весь трафик Блокируется Интернет дос- туп к сервисам Windows, раз- деляемым файловым и прин- терным ресурсам Компьютер и его прикладные серверы видны в сети Интер- нет Internet Lock блокирует толь- ко трафик приложении Разрешен Интернет-доступ к сервисам Windows, разделяе- мым файловым и принтерным ресурсам Серверные приложения ло- кального компьютера видны из Интернет Internet Lock блокирует весь трафик В локальной сети разрешен доступ к сервисам Windows, разделяемым файловым и прин- терным ресурсам Компьютер и его прикладные серверы видны в локальной се- ти
242
Окончание табл. 8.3
Уровень безопас- ности Зона
Интернет Локальная
High Internet Lock блокирует весь трафик Блокируется Интернет-дос- туп к сервисам Windows, раз- деляемым файловым и прин- терным ресурсам Режим невидимки: МЭ скрывает все порты, не исполь- зуемые программами Internet Lock блокирует весь трафик Блокируется в локальной сети доступ к сервисам Windows, раз- деляемым файловым и принтер- ным ресурсам Режим невидимки: МЭ скрывает все порты, не исполь- зуемые программами
Персональный МЭ защищает от большинства сетевых атак,
направленных на пользовательские компьютеры, включенных в
Интернет. Для работыс ним пользователю не нужны глубокие зна-
ния о работе сетевого стека. МЭ ZoneAlarm хорошо справляется с
задачей обнаружения троянских программ или нежелательных со-
единений. Программа распространяется бесплатно.
PGP Desktop Security
http://www.pgp.com
Тип
Версия
Дополнительные
возможности
Пакетный фильтр
7.0
IDS
Программный комплекс PGP Desktop Security компании Net-
work Associates предоставляет пользователю практически весь
арсенал средств, позволяющих организовать защиту своих данных,
сетевых соединений, сообщений электронной почты и компьютера,
включенного в Интернет (рис. 8.35). Программный комплекс PGP
Desktop Security включает как уже хорошо известные средства:
PGP, PGPdisk, PGPnet (поддержка VPN), File Wiping, так и новые -
Personal Firewall, Personal IDS.
Модуль Personal IDS автоматически обнаруживает следующие
сетевые атаки: Back Orifice, Bonk, Fraggle, IP Spoofing, Jolt, Jolt2,
Land, Nestea, Ping Flood, Ping of Death, Port Scanning, Smurf, SYN
Flood, Teardrop, UDP Flood. При обнаружении любой из этих атак
он автоматически блокирует IP-адрес атакующего и при необхо-
димости отправляет уведомления об атаке по электронной почте
(рис. 8.36):
243
9*
Рис. 8.35. PGP Desktop Security
Рис. 8.36. Обнаружение сканирования портов модулем Personal IDS:
(nmap -sS -P0 -D194.190.0.1,194.190.0.2,194.190.0.1,ME
10.0.0.36)
Subject: PGPnet Intrusion Detection Notification
Attack Jolt2 detected from 10.0.0.12 on Tuesday, October 03,
2000 10:07:19
PGP Desktop Security имеет шесть встроенных степеней защи-
ты: None, Minimal, Client Medium, Client High, Server Medium, Server
High. Для каждой из них отображаются соответствующие правила
(рис. 8.37), которые пользователь не может редактировать. Для
244
PGP Options
ИВ
J « I «**» I ** I <* I | №M
‘ j(t_ . - .... урк | I vpHAfcmMd
0W4t IPsec. N/A ICMP EchoRequest{8) 0 О ♦ ICMP TinrntampReq (13) N/A N/A N/A Any Ary Ary
0 • 4 ICMP AddfMaskReq (17) N/A Ary
ЕЗЭФ ICMP WoReq(15) N/A Ary
04H ICMP RouterSofeotflO) N/A Ary
ICMP Redirect (5) N/A Ary
0S# ICMP Ary N/A Ary
0#4> UDP bootpc(68J bootp$(67) Any
0 # UDP Ary dn«(53) Ary
0tf# UDP fce(500) tke(500) Ay
0^# UDP ntp(123) 0 e* UDP ЫМП31 nip (123) Ary Ary Ary
.г
Рис. 8.37. Закладка Personal Firewall
программы PGP Desktop Security
того чтобы создать собственную ПБ или изменить существую-
щую, необходимо переключиться в режим «Custom».
Для создания нового правила нужно заполнить следующие поля:
действие (Block, Permit), протокол (ICMP, IGMP, TCP, UDP, IPsec
ESP, IPpsec AH, All), направление (Incoming, Outgoing, Either), ло-
кальный и удаленный сервисы и IP-адрес (Single, Subnet, Local
Subnet, Range, Any). Модуль МЭ имеет обратную связь с модулем
IDS - для любого блокирующего правила можно установить свой-
ство «Treat rule match as intrusion» (обрабатывать правила как втор-
жение). Тогда при обнаружении входящих пакетов, удовлетворяю-
щих правилу, Personal IDS автоматически заблокирует все пакеты,
поступающие от соответствующего IP-адреса.
При всей многофункциональности и привлекательном дизайне
рассматриваемого продукта можно указать на следующие недо-
статки, относящиеся к модулям Personal Firewall и Personal IDS:
• предоставляемая документация не позволяет обычному
пользователю самостоятельно разобраться с модулем Personal
Firewall;
245
• полностью отсутствует система протоколирования событий
(журнал событий). Продукт не предоставляет возможности выяв-
ления аномальной активности, кроме обнаруживаемых и опреде-
ляемых самостоятельно в правилах атак;
• при испытании продукта пользователи не могли быстро обна-
ружить функцию включения/выключения поддержки защиты сети
(кнопка выполнена в виде щита на панели PGPnet и больше нигде
не дублируется);
• программа не отслеживает действий сетевых программ, что
позволяет троянским программам обходить защиту МЭ, исполь-
зуя разрешенные правила.
AtGuard
http ://www.atguard.com
Тип
Версия
Дополнительные
возможности
Гибридный
3.22
Посредник HTTP с расширенными
возможностями
Персональный МЭ AtGuard компании WRQ сочетает достоин-
ства двух рассмотренных выше персональных МЭ (ZoneAlarm и
PGP Desktop Security) и имеет ряд дополнительных возможностей,
которые позволили ему значительно обогнать своих конкурентов.
В конце 1999 г. компания WRQ Inc передала права на свой МЭ
компании Symantec.
Фильтр пакетов, который позволяет создавать правила для про-
токолов ICMP, UDP и TCP, механизм перехвата обращений ло-
кальных программ в сеть и имеет возможность автоматического
создания правил в AtGuard, работает примерно так же, как и в двух
предшествующих МЭ. Поэтому рассмотрим возможности, отсут-
ствующие у рассмотренных экранов.
Web filters (локальный посредник HTTP) позволяет задать пра-
вила фильтрации компонентов протокола HTTP для всех или вы-
борочных сайтов Интернет. Фильтр может блокировать любые теги
HTML (точнее, фрагменты HTML-кода), ActiveX, скрипты и апп-
леты Java, cookies. Как говорилось выше, блокировка содержи-
мого HTML-страниц повышает ИБ локального компьютера и сни-
жает время загрузки страниц. Механизм Trashcan позволяет
через буфер обмена блокировать загрузку по заданному URL. Кро-
ме того, фильтр Web может управлять служебными заголовками
HTTP - Referer, User-agent, E-mail (From). Можно, например, для
246
поля User-agent указать строку «MS Internet Explorer 10.0» а в поле
From - «bili@microsoft.com». МЭ AtGuard ведет журнал посещен-
ных Web-сайтов.
Окно AtGuard Statistics предоставляет статистические дан-
ные работы сетевого стека, UDP и TCP-соединений, контролируе-
мых персональным МЭ, статистические данные работы Web-филь-
тра и скорости сетевого и HTTP-соединений, а также таблицу
открытых соединений. Большое число предоставляемых парамет-
ров (более тридцати) позволяет быстро проанализировать текущий
сеанс работы с точки зрения ИБ. Пусть, например, при первом
обращении к 139-му порту (NetBIOS session) с некоторого 1Р-хос-
та Интернет МЭ автоматически создаст блокирующее правило.
Все последующие попытки такого соединения будут предотвра-
щены, но не обнаружены. Анализ статистических данных позволя-
ет обнаружить резкое увеличение блокированных соединений. Пос-
ледующий просмотр журнала позволит выявить источник угрозы
безопасности.
McAfee Personal Firewall
http://www. McAfee.com
Тип Монитор приложений
Версия 2.14
Персональный МЭ компании McAfee.com осуществляет конт-
роль всех активных сетевых приложений (процессов) и на этой ос-
нове позволяет вести мониторинг и протоколирование сетевой ак-
тивности компьютера. Такой подход к построению защиты, в первую
очередь, позволяет пресечь деятельность троянских программ.
Отличительной особенностью данного МЭ является возмож-
ность контроля и управления сетевой активностью без погружения
пользователя в технические особенности прикладных протоколов,
такие как номера портов, исходящие и входящие пакеты и т. п.
Пользователю достаточно указать или подтвердить, каким прило-
жениям разрешен и каким запрещен доступ к сетевым ресурсам.
При первом же запуске МЭ определяет все активные программы,
являющиеся и серверами, и клиентами, запрашивает подтвержде-
ния на разрешение этим программам участвовать в сетевых со-
единениях (рис. 8.38) и сразу начинает выполнять свои защитные
функции.
247
Рис. 8.38. Запрос на разрешение
установления соединения
Настройка МЭ заключается
в определении доступа приложе-
ниям Application Settings (рис.
8.39) и при необходимости оп-
ределения разрешенных сете-
вых протоколов System Settings
(рис. 8.40) для каждого сетево-
го интерфейса.
МЭ позволяет управлять доступом как к своим, так и к другим
сетевым разделяемым ресурсам (print and file sharing). В любой
момент можно увидеть, кто подключен к локальным ресурсам, и
при необходимости блокировать доступ.'
МЭ работает в трех основных режимах*.
• все блокировать - весь сетевой трафик и любые сетевые вза-
имодействия блокируются. Режим используется в случае обнару-
жения аномальной сетевой активности или явной атаки, например
SYN flood;
• фильтровать трафик - основной режим - МЭ работает со-
гласно прикладным и системным настройкам. Только' в этом режиме
отображается весь текущий трафик;
• все разрешить - весь сетевой трафик разрешен, программы
из «запрещенного» списка могут участвовать в сетевом взаимо-
действии.
Applications Settings
Рис. 8.39. Категорирование
сетевых приложений
248
NdisWan3 Properties
НЕЗ
RIP ) PPTP | Other Protocols
NetBIOS over TCP | ICMP | ARP | DHCP
NetBIOS is used for file and print sharing. These
controls are for NetBIOS over TCP. For NetBIOS
over IFX or NetBEUI, set 'Other Protocols'.
-Control——----------—
Г me to reach othej
systems' shares"""
F Allow other systems to
reach my shares
-Reporting—————
F Report allowed traffic
F Report blocked traffic
OK | Отмена Справка
Рис. 8.40. Настройка основных протоколов
Вся информация о сетевой активности доступна из главного окна
программы в так называемом дереве активности - «Activity Tree»
(рис. 8.41). Здесь можно получить следующие данные:
• все активные сетевые приложения, в том числе системные
сервисы, и IP-адреса, с которыми осуществляется взаимодействие.
Для каждого приложения отображаются протокол, имя, порт и IP-
адрес удаленного компьютера, время запуска и продолжительность
активности, количество отправленных и принятых байт (рис. 8.42);
• текущие и статистические данные о задействованных прото-
колах NetBIOS, ICMP, ARP, DHCP, RIP, РРТР. Отдельно выделе-
ны две группы протоколов «Other IP Protocols» и «Non-П* * Protocols».
Группа «Other П* Protocols» отображает сетевую активность в рам-
ках протоколов, отличных от TCP и UDP, а «Non-П* Protocols» -
сетевую активность в рамках «не IP-протоколов», таких как П*Х,
IDRP, SNP;
• в разделе Unknown Traffic (неизвестный трафик) отобража-
ется трафик, «потерявший» связь с сетевыми приложениями. Та-
кая ситуация возможна на медленных линиях связи. Например
249
СП
о
4JrMcAfee.com Personal Firewall
**' Mjggihg
: Я;Ц^ЯЫСГЮЙП11^Л;,Й
ИЕО
8~® Му Computer
Й“!5 Appfcdtbns
S^jjADR
I ЧЭ Me (Email--(’1
Е fi (EXPLORE
| | Me (ephemeral) -207.41230.218 (WWW)
j L J J Me (ephemerall - 207.46.231218 (WWW)
Eg ® MSDTC
SfflMSTASK
E ® MYSQLD-SHAREWAR
S® RPCSS
Ehgg THEBAT
I | Me (ephemeral! - 21224.3210 (Email
J | Me (ephemeral) -212.24.3210 (Emai)
3 HI System
L NetBIOS (fieshares and printshares)
%% ICMP
g ARP
Fj DHCP
I g RIP
ИРРТР
DocalAddbesslF J
м 4- 195.46.169.115 195.46.169.115 195.46.169.115 1048 (ephemeral] 1042 (ephemeral) 1058 (ephemeral) 193.2328117 194.87.0.50 194.87.0.50 53 (DNS) 80 (W... 80 (W... 2000/09/3013:31:41 2000/09/3013.34.09 2000/03/3013.33:30
< 19S46.169.115 1062 (ephemeral) 194.87.0.50 80 (WW... 2000/09/301334:23
195.46.169.115 1063 (ephemeral) 194.87.12129 80 (WW... 2000/09/30 13:34:18
195.46.169.115 1039 (ephemeral) 195.46.160.1 53 (DNS) 20004)9^013:31:19
* 195.46.169.115 1038 (ephemeral) 193.23288.17 53 (DNS) 2000/09/301331:19
<- 195.46.169.115 1045 (ephemeral) 193.23288.17 53PNS) 2000/09/3013.31:39
195.46.169.115 1046 (ephemeral) 19S46.1611 53 (DNS) 2000/09/3013:31:39
<г 195.46.169.115 1049 (ephemeral) 19546.160.1 53 (DNS) 2000/09/301331:41
!O* Other IP protocols
L-Q NorHP protocols
; ra Current Activfty
-•Д Activity Log
И<5^жсхмв,Рймюпа1 Ягейа! “?’/
Рис. 8.41. Главное окно McAfee.com Personal Firewall
J My Computer
В В Appfications
^-"41 ADR
MefEmaibT)
Й Я MSDTC
ш H MSTASK
i Я MYSQLD SHAREWAR
ffiHBPCSS
System
Current Activity
Protocol
Remote Name
Remote IP Add...
Remote Port
Local Port
Start Time
Up time (seconds)
Appfcabon
Bytes Sent
Bytes Received
TCP/IP
193124.23.4
80 (WWW)
1309 (ephemeral)
2000/09/301749 46
92
IEXPLORE
0
0
Рис. 8.42. Дерево активности McAfee
приложение, отправлявшее запрос в систему DNS, завершило свою
работу, и пришедший ответ не «нашел» своего получателя. Причи-
ной появления «неизвестного» трафика также может быть скани-
рование или другое удаленное сетевое исследование (ping,
traceroute);
• ветвь «Current Activity» (текущая активность) отображает
текущую активность в данный момент времени, в том числе раз-
решенные и заблокированные приложения, входящий и исходящий
трафики;
• «Activity Log» - журнал событий (активности) отображает
последние 100 событий. Какие события будут регистрироваться,
определяется соответствующими настройками в «System Settings».
Более детальное описание событий можно найти в файле событий,
имеющем текстовый формат.
Персональный МЭ McAfee Personal Firewall позволяет доста-
точно просто и интуитивно понятно отслеживать активность сете-
вых приложений.
В заключение краткого обзора персональных МЭ рассмотрим
один тест, проведенный над рассматриваемыми продуктами МЭ.
Тест заключался в реакции МЭ на процесс сканирования портов.
Использовался хорошо известный сканер NMAP в режиме stealth-
сканирования (ключ -sS). Особенность stealth-сканирования зак-
лючается в том, что при сканировании не устанавливается ТСР-
соединение, что позволяет, во-первых, обходить защиту некоторых
МЭ на основе фильтров пакетов и, во-вторых, обходить некоторые
средства обнаружения вторжений, которые не обнаруживают та-
кой метод сканирования. Все персональные МЭ с идентично на-
строенными правилами остались «черным ящиком» для сканиру-
251
ющего хоста, т. е. справились со своей задачей. Но только AtGuard
сумел обнаружить все направленные 8878 сканирующих пакетов.
ConSeal PC Firewall и ZoneAlarm «доложили» только о попытках
соединения с 80 портом!
8.13. МЭ защиты телефонных линий
Несанкционированное использование модемных соединений на
рабочих местах пользователей корпоративной сети является од-
ной из серьезных проблем ИБ. Причины и условия возникновения
таких соединений рассмотрены в § 1.5. До недавнего времени техни-
ческих средств защиты от подобных соединений не существовало.
Американская компания SecureLogix (http://www.securelogix.com)
предложила собственное решение этой проблемы - продукты
Tele Wall и TeleSweep Secure, предназначенные для защиты корпо-
ративных телефонных сетей от несанкционированного использова-
ния модемов и устройств факсимильной связи.
TeleWall для Т1 линий
Сервер
управления
TeleWall
Рис. 8.43. МЭ для телефонных линий компании SecureLogix
РВХ
Клиент
TeleWall
Клиент
TeleWall
Модем
252
Концепция защиты и функциональные возможности системы
Tele Wall аналогичны используемым в традиционных МЭ. Подобно
МЭ, Tele Wall устанавливается на границе локальной (офисной) те-
лефонной сети (рис. 8.43) и обеспечивает мониторинг, контроль и
аудит телефонной сети. В качестве пограничных маршрутизато-
ров в этом случае выступают РВХ (УАТС, офисная АТС, мини-
АТС) и соответствующая аппаратура телефонного провайдера.
Tele Wall имеет трехуровневую структуру:
• непосредственно сам Tele Wall реализован аппаратно для ана-
логовых телефонных линий (12 линий), линий Т1 (24 канала) и ISDN-
PRI (24 канала). TeleWall генерирует сообщения событий безо-
пасности согласно принятой политике безопасности и отправляет
их на сервер TeleWall Server;
• TeleWall Server (Windows NT 4.0 или Solaris 7) контролирует
активность одного или нескольких устройств Tele Wall, что позво-
ляет централизованно управлять несколькими распределенными
устройствами Tele Wall;
• клиенты TeleWall предоставляют графический интерфейс
управления всей системой в целом. Интерфейс управления на-
поминает интерфейс, реализованный в МЭ FireWall-1 компании Check
Point..
TeleWall определяет четыре типа данных: голос, факс, модем и
STU-Ш*. Политика безопасности определяет - кому (интерфейс
или телефонный номер), куда (телефонный номер), когда (время),
тип данных (голос, факс, модем) - разрешается или запрещается
выполнять коммуникации. Контроль набираемых пользователями
номеров позволяет также бороться и с такой проблемой, как нео-
боснованные звонки (в том числе и платные) и междугородние пе-
реговоры.
Система сигнализации позволяет использовать электронную
почту, SNMP-трапы и пейджинговую связь.
Встроенный генератор отчетов содержит набор шаблонов, по-
зволяющих получать разнообразные итоговые отчеты. Кроме со-
бытий безопасности* отчеты содержат и детальную информацию
о загрузке телефонной сети с указанием номеров телефонов, пользо-
вателей, времени звонков и их продолжительности.
* Secure Telephone Unit (III - третье поколение) - цифровое устройство
защиты телефонных линий, широко используются в военных, государствен-
ных и частных организациях США для защиты телефонных линий при орга-
низации связи на основе коммутируемых телефонных сетей общего пользо-
вания (http://www.tscm.com/STUIIIhandbook.htm).
253
TeleSweep Secure - сканер телефонных линий - предназначен
для автоматического поиска модемов и факс-аппаратов телефон-
ной сети. Проводя аналогию с IP-сетями, можно сказать, что
TeleSweep Secure выполняет функции сканера безопасности теле-
фонной сети. При обнаружении модемов сканер позволяет иденти-
фицировать некоторые образцы коммуникационного ПО, ОС и за-
действуемые протоколы канального уровня.
Совместное использование МЭ для телефонных линий Tele Wall
и сканера безопасности TeleSweep Secure обеспечивают качествен-
ное решение защиты телефонной сети. При обнаружении неавто-
ризованной передачи данных Tele Wall передает управление телефон-
ному сканеру, который обеспечивает дальнейшую идентификацию
системы.
8.14. Выбор МЭ
На сегодняшний день существует большое количество МЭ,
производители которых, естественно, заявляют, что их продукт
лучший. Оценить реальные особенности МЭ (алгоритмы, реализу-
ющие правила фильтрации и защиты и т. п.) без подробного техни-
ческого описания и проведения соответствующих испытаний очень
трудно, тем более, что в большинстве из них используются прак-
тически одинаковые решения и технологии. Процедура выбора МЭ
может оказаться весьма непростой задачей, требующей оценки и
изучения многих технологий защиты, а также и потребностей сво-
ей ПБ. Как и при выборе других средств обеспечения ИБ, можно
руководствоваться следующими факторами.
Занимаемая доля рынка
Рынок является, пожалуй, самым ярким показателем автори-
тетности продукта. Какие бы большие средства ни были исполь-
зованы для продвижения продукта на рынке, вопрос качества про-
дукта - дело времени. В первой тройке лидеров рынка МЭ
находятся компании Cisco, Check Point и Axent (Symantec). Этот
факт вовсе не означает, что остальные продукты не достойны вни-
мания. Не существует универсального решения для всех. Есть ряд
средств, имеющих свои уникальные возможности (свойства).
Рынок средств информационных технологий условно разделя-
ют на четыре сегмента (рис. 8.44):
254
Рис. 8.44. Пирамида рынка средств ИТ
• Large Enterprise - промышленные системы, отвечающие са-
мым жестким требованием безопасности, производительности и
надежности;
• SME (Small-Medium Sized Enterprise) - средства для компа-
ний небольшого и среднего размера;
• SOHO (Small Office/Home Office) - рынок средств для не-
больших офисов и домашнего использования;
• TELECOMMUTERS - средства для удаленной работы (орга-
низация работы на дому).
Производители, как правило, сами заявляют о принадлежности
их средств к тому или иному сегменту рынка.
Качество технической поддержки
Одной из причин, по которой бесплатные продукты (в основном
на базе свободно распространяемых версий Unix) не находят при-
менения в корпоративной среде, является отсутствие технической
поддержки. Услуги технической поддержки могут и не понадобить-
ся, однако она гарантирует быстрое и качественное решение не-
предвиденных проблем.
Если несколько часов, а иногда и минут потери времени по при-
чине неисправности или некорректной работы МЭ могут привести
к значительным убыткам, то качественная 24-часовая техничес-
кая поддержка является необходимым требованием при выборе
продукта.
255
Наличие сертификатов соответствия стандартам ИБ
и рекомендаций независимых испытательных лабораторий
Стандарты ИБ призваны обеспечить взаимодействие между
производителями, потребителями и экспертами по квалификации
продуктов информационных технологий [62]. С точки зрения по-
требителя, соответствие МЭ некоторому классу защиты стандар-
та ИБ означает следующее:
• МЭ может противостоять строго определенному виду угроз
(обеспечивать защиту в заданных условиях);
• есть объективная возможность сравнения предоставляемых
защитных свойств нескольких МЭ;
• существует возможность использования продукта при необ-
ходимости удовлетворения государственным законодательным
требованиям.
В настоящее время существуют следующие стандарты ИБ:
• критерии безопасности компьютерных систем Министерства
обороны США [58];
• европейские критерии безопасности информационных техно-
логий [19]; -
• федеральные критерии безопасности информационных техно-
логий [9];
• руководящие документы Гостехкомиссии России, 1992 г.;
• канадские критерии безопасности компьютерных систем [3];
• единые критерии безопасности информационных технологий [6].
Наиболее современным и продуктивным стандартом ИБ явля-
ются «Единые критерии» (Common Criteria for Information
Technology Security Evaluation), версия 2.1 которого утверждена
Международной организацией по стандартизации в 1999 г. в каче-
стве международного стандарта ИБ ISO/IEC 15408. Стандарт оп-
ределяет требования ко всему жизненному циклу продукта - про-
ектирование, разработка, эксплуатация.
Единые критерии позволяют формализовать функциональные
требования к продукту защиты (ИТ-продукту) и определяют тре-
бования адекватности. Требования адекватности (гарантирован-
ности) отражают качества объекта оценки, по которым можно су-
дить о том, что необходимые меры безопасности объекта
эффективны и корректно реализованы. Стандарт определяет семь
уровней адекватности - с 1 по 7 (EAL1-EAL7). Чем выше уровень
адекватности, тем выше способность ИТ-продукта противостоять
угрозам ИБ. Хотя стандарт и определяет семь уровней адекватно-
256
сти, практически реализуемы на сегодняшний день только первые
четыре.
Процедура квалификации уровня безопасности (присвоение
класса уровня безопасности) является достаточно сложной и тру-
доемкой задачей, требующей глубокого знания стандартов ИБ, ква-
лифицируемого продукта, технологий испытаний и т. п. Поэтому
при необходимости обращения к стандарту (выработка функцио-
нальных требований защиты, интерпретация результатов квалифи-
кации) целесообразнее воспользоваться услугами специалистов по
ИБ и испытательных лабораторий.
В прил. П.8 приведен перечень МЭ, сертифицированных по Об-
щим критериям по состоянию на май 2001 г.
Предъявляемые требования к реализации ПБ
МЭ реализуют часть ПБ организации. Поэтому очевидным тре-
бованием к МЭ является возможность технической реализации
положений ПБ. Например, временное ограничение действия пра-
вил ПБ не поддерживает большинство ПФ и даже некоторые МЭ
экспертного уровня. Поэтому если ваша ПБ имеет особенности,
реализация которых может вызвать трудности, необходимо убе-
диться в поддержке требуемой функциональности МЭ. Кроме того,
имеет смысл удостовериться в поддержке МЭ таких функциональ-
ных возможностей, как типы поддерживаемых интерфейсов, вре-
менное ограничение действия правил, поддержка протоколов, от-
личных от TCP и UDP, поддержка протоколов, отличных от IP
(например, IPX), балансировка нагрузки, повышенная надежность,
автоматическое восстановление, CVP.
Требования производительности
(пропускной способности)
При организации защиты сети, подключенной к Интернет вы-
сокоскоростными каналами, одним из основных параметров МЭ
является его пропускная способность. Особо остро проблемы про-
изводительности могут возникнуть при организации защиты внут-
ри LAN, а также в том случае, когда МЭ выполняет функции VPN-
шлюза.
Большинство производителей заявляет, что производительность
их МЭ соизмерима со скоростью интерфейсов сетевых адапте-
ров. К сожалению, такие показатели не совсем корректны, посколь-
ку оценка производительности имеет комплексный характер.
257
100
й 90
о 80
| 70
| 60
Й 50
д 40
S 30
Ё 20
ю
Cisco NetScreen
CyberGuard • •
TopLayer • • Axent *
Nokia* • Lucent ___ _ _
i n . WatchGuard
Checkpoint
Computer Associates
SonicWall
• Network Associates
Secure Computing
Novell
Network-1
Entemet
0
1000 800 600 400 200 100 90 80 70 60
СТОИМОСТЬ/ПРОИЗВОДИТЕЛЬНОСТЬ
Рис. 8.45. Соотношение стоимость/производительность
продуктов ведущих производителей МЭ
Для потребителя основным показателем является пропускная
способность при максимальном количестве одновременных соеди-
нений для основных служб. Результат будет различным для ПФ и
прикладных посредников, а также при различных настройках МЭ,
влияющих на производительность (например, при включенном ауди-
те событий). Необходимо также учитывать значения пропускной
способности при воздействии DoS-атак.
По результатам испытаний издательства NetworkWorldFusion
(http://www.nwfusion.com/reviews/2001/0312rev.html) на март 2001 г.
самыми производительными являются МЭ компаний Cisco,
CyberGuard и NetScreen (рис. 8.45).
Стоимость продукта
Стоимость продукта, его эксплуатации и поддержки иногда яв-
ляются основными факторами при выборе МЭ. Большинство про-
дуктов лицензируются по числу IP-адресов защищаемой сети. При
этом используют примерно следующую градацию - менее 25, 50,
100,250 и неограниченное количество адресов. Ориентировочный ди-
апазон стоимости программных МЭ экспертного уровня с неограни-
ченной лицензией для платформы Intel составляет от 2000 до 25000 $.
Несколько дороже могут стоить МЭ для платформ SPARC, Alpha.
258
Помочь в выборе и выполнить сравнительный анализ МЭ по-
может табл. 8.4.
Таблица 8.4. Критерии выбора МЭ
Критерий Комментарии
Общие требования безопасности
Стабильность работы Часто в конференциях упоми- нается о сбоях в работе МЭ
Сколько существует дефектов (эксплоитов), выявленных в рас- сматриваемом продукте Сайты, подобные http://packetstorm.securify.com содержат опи- сания различных дефектов, в том числе обнаруженных в МЭ
За какое время производитель устраняет выявленные ошибки Продолжительность времени между выявлением дефектов и созданием пакетов исправлений
Есть ли в организации специа- лист, знающий ОС, под управле- нием которой работает рассмат- риваемый МЭ Администратор безопаснос-ти не обязательно должен знать все тонкости ОС, под урав- лением которой функциони- рует МЭ
Требования к аппаратной плат- форме Использование в организации аппаратных платформ одного производителя, требования эр- гономики
Ограниченное количество заре- гистрированных IP-адресов или ПБ требует сокрытия структуры ло- кальной сети Динамическая и статическая NAT
Локальная сеть имеет собствен- ную систему доменных имен. ПБ требует сокрытия структуры ло- кальной сети Split DNS
259
Продолжение табл. 8.4
Критерий Комментарии
МЭ должен выполнять функ- ции антивирусной защиты служб FTP, HTTP, SMTP/POP3 Поддержка протокола CVP
Есть ли сервисы (и есть ли не- обходимость в их защите), ко- торые должны быть доступны из Интернет. Такие сервисы обеспе- чивают представительство орга- низации в глобальной сети или обеспечивают ее функционирова- ние. Требуется контроль доступа персонала организации из локаль- ной сети к глобальным ресурсам Прикладные посредники для каждой защищаемой службы
Способность защиты от типо- вых DoS-атак Неустойчивость МЭ к DoS- атакам может свести на нет все усилия по обеспечению защиты сети
Поддержка инспекции состоя- ния Отсутствие инспектора сос- тояний позволяет реализовывать некоторые виды DoS-атак, а так- же делает возможным обход защиты МЭ
Совместимость с другими про- дуктами Интеграция с различными продуктами безопасности позво- ляет повысить уровень защиты и минимизировать затраты на эксплуатацию средств защиты
Требования производительности Число одновременно работаю- щих пользователей, количество одновременно открытых соедине- ний, поддержка высокоскорост- ных интерфейсов
260
Продолжение табл. 8.4
Критерий Комментарии
Управление МЭ
Гибкость и удобство опреде- ления правил ПБ Гибкость и удобство опре- деления правил позволяют соз- давать логически сложную и поэтому практически эффек- тивную ПБ
Простота отладки (трассиров- ки) правил ПБ Большинство правил «чита- ются» МЭ сверху вниз, если ПБ предоставляет механизмы пе- реходов, то необходимо средст- во трассировки правил ПБ
Простота установки Процедура установки МЭ не должна вызывать повышенных усилий
Корректность установок ос- новных параметров по умолча- нию Параметры по умолчанию, как при установке самого МЭ, так и при создании новых правил в GUI не должны создавать условия нарушения ИБ
Возможность быстрого восста- новления после аппаратных и программных сбоев МЭ должен предоставлять механизмы быстрого восстанов- ления после сбоев различного ха- рактера. В особых случаях необ- ходим режим повышенной на- дежности (High Availability)
Управление бюджетами пользователей
Большое число пользователей, работающих в различных ОС. Интеграция учетных данных, получаемых от различных источ- ников Интеграция с каталогами LDAP, импорт бюджетов поль- зователей с NT Domain, под- держка серверов аутентифика- ции третьих производителей
261
Окончание табл. 8.4
Критерий Комментарии
Безопасность соединения с мобильными и удаленными пользователями, бизнес-партнерами
Необходимость обеспечения защищенных соединений по нес- кольким прикладным протоколам Выполнение функции VPN- шлюза. Возможность фильтра- ции основных протоколов VPN
Обучение и поддержка
Полнота и качество печатной документации Техническая документация в большинстве случаев является единственным источником зна- ний для администратора МЭ
Полнота и качество локаль- ной online-документации Электронная документация позволяет оперативно решать возникшие вопросы и проблемы
Качество технической под- держки производителя Непрерывная и качественная поддержка являются неотъем- лемой частью корпоративной безопасности
Обучение Обучение подтверждает ква- лификацию персонала и умень- шает время развертывания сис- темы
Стоимость
Стоимость продукта и техни- ческой поддержки Затраты на продукт должны соответствовать реализуемому уровню безопасности
Политика лицензирования Привязка лицензии к аппа- ратной платформе может вызвать трудности при изменении обору- дования
262
По табл. 8.5 можно грубо оценить возможности основных ти-
пов МЭ. Заполненная ячейка означает поддержку соответствую-
щей функциональной возможности. Из данных табл. 8.5 следует,
что наиболее функциональными являются МЭ экспертного класса.
Таблица 8.5. Сравнение возможностей основных типов МЭ
Технология МЭ Тип МЭ
фильт- ры пакетов инспек- торы состояний посред- ники сеансо- вого уровня посред- ники приклад- ного уровня эксперт- ные
Пакетная фильтрация + + — — +
NAT + + + + +
Аутен- тификация пользо- ватели — — + + +
клиенты + + + + +
сессии — — + — +
События протоко- лирование + + + + +
уведом- ление + + + + +
Прикладные посредники — — — + +
VPN — + + — +
Управление бюджета- ми пользователей — — + + +
Управление МЭ + + + + +
Инспекция ICMP + + — — +
Антивирусная защита — — + + +
Обнаружение атак — + — + +
263
8.15. Перспективы развития МЭ
Возможность контроля всего сетевого трафика на границе не-
скольких сетей определяет использование МЭ в качестве основно-
го средства защиты как внешнего периметра сети, так и различ-
ных внутренних сетевых сегментов. Именно физическое разме-
щение МЭ на границе сетевых потоков определяет его универ-
сальность и необходимость применения при построении систем
сетевой защиты. Несмотря на сформировавшийся рынок продук-
тов и используемых в них технологий, производители ищут новые
пути повышения защитных возможностей своих изделий. Можно
выделить несколько общих направлений дальнейшего развития тех-
нологий и функциональных возможностей МЭ.
Расширение функциональных возможностей
Сегодня не существует МЭ, который поддерживал бы все из-
вестные функциональные возможности контроля сетевого трафика
и информационных потоков с точки зрения обеспечения ИБ, воз-
можности управления сетевым трафиком, подобно маршрутизато-
рам (маршрутизация, балансировка нагрузки, управление полосой
пропускания, дублирование каналов связи и др.). Производители МЭ
стремятся реализовать в своих продуктах как можно больше фун-
кциональных возможностей, но как показывает практический опыт,
они не используются в большинстве случаев и наполовину.
При разработке МЭ большое внимание будет уделяться повы-
шению их «интеллектуальности». В основе «интеллектуальных» МЭ
будут лежать алгоритмы обработки сетевых событий, построен-
ные на усиленных механизмах инспекции состояния канала связи,
взаимодействии с различными средствами обеспечения безопас-
ности (прежде всего системами IDS и сканерами безопасности).
МЭ будут выполнять инспекцию не только пакетов на всех уров-
нях модели OSI, но и проводить анализ пакетов на временном ин-
тервале с учетом всех происходящих событий.
Централизованное управление
Поддержка функций централизованного управления как одним,
так и несколькими МЭ в составе многоуровневой распределенной
системы защиты является одним из слабых мест существующих
продуктов. Если функции централизованного управления несколь-
кими распределенными МЭ у некоторых производителей имеют-
264
ся, то вторая проблема до сих пор никем не решена. Подобное
положение дел можно объяснить следующим:
• производители средств защиты специализируются на доста-
точно узком спектре продуктов, например, на средствах защиты
внешнего периметра;
• отсутствуют подходы (и тем более стандарты) к решению
проблемы централизованного управления безопасностью. Частич-
но решена проблема мониторинга средств защиты на основе сис-
тем управления сетями, но управление на основе этих же систем
носит обособленный характер.
Улучшенный интерфейс пользователя
Расширение функциональных возможностей МЭ приводит к
увеличению числа настраиваемых параметров, а значит, и услож-
нению механизмов управления. Поэтому отлаженный, интуитивно
понятный, с механизмами контроля ввода параметров графичес-
кий интерфейс пользователя (администратора) является неотъем-
лемой частью системы управления МЭ.
Компания Check Point, предложившая использование графичес-
кого интерфейса, первая реализовала решение визуального управле-
Internet Cloud
Л
sjMstbat net
\
sundfe bat net
csay.bat.net switch bat.net
Рис. 8.46. Визуализация политики безопасности
средствами МЭ Check Point Visual Policy Editor
265
ния политикой безопасности МЭ. Check Point Visual Policy Editor
позволяет графически вводить, управлять свойствами сетевых
объектов и, конечно, определять правила ПБ. На рис. 8.46 приве-
дена схема используемых объектов, построенная автоматически
на основе существующей ПБ. По данной схеме легко представить
структуру сети, схему адресного пространства и взаимное распо-
ложение объектов сети, описанных в ПБ.
Увеличение производительности
Скорости линий передачи приближаются к тактовым частотам
современных процессоров. Увеличение пропускной способности
каналов Интернет накладывает жесткие требования на производи-
тельность МЭ, которые в силу их места размещения и выполняе-
мых функций становятся одним из «тормозящих» звеньев компью-
терных сетей. Кроме этого, расширение функциональных
возможностей МЭ приводит к существенному повышению потреб-
ления ими системных ресурсов. Производители ищут новые пути
решения этой проблемы.
В настоящее время увеличение производительности достига-
ется за счет адаптации существующего продукта к специально
оптимизированной, с точки зрения производительности, программно-
аппаратной платформе. При этом, как правило, используется ОС
линии Unix.
Поддержка VPN
Незащищенность сетевых соединений от просмотра является
одним из главных факторов, «отпугивающих» различные организа-
ции от использования сравнительно дешевых услуг Интернет. По
прогнозу аналитических компаний, средства защиты на основе VPN
в скором времени будут так же популярны, как и сегодня антиви-
русные средства. Поскольку и МЭ, и VPN-шлюзы устанавлива-
ются на границе общедоступных и частных сетей, то вполне оче-
видно, что эти два типа систем защиты будут функционально
объединяться в одном изделии.
Поддержка протокола IPv6
Бурный рост числа хостов в сети Интернет привел к проблеме
распределения уникальных IP-адресов. Используемый в настоя-
щее время сетевой протокол IP версии 4 занимает для адресации
266
хостов 32 бит (4 байт). Таким образом, максимальное количество
адресуемых хостов может составлять 232. Перспективный прото-
кол IP версии 6 использует для адресации 128 бит, что позволяет
полностью решить проблему распределения IP-адресов, а предла-
гаемые схемы адресации и управления адресным пространством
также позволят облегчить процессы управления и конфигурации
сетями [37,40,41,50].
Другим важным аспектом применения протокола IPv6 являет-
ся поддержка последним встроенных механизмов создания защи-
щенных соединений на основе семейства протоколов IPSec. Под-
держка стеком ОС протокола IPv6 позволит значительно повысить
общий уровень защищенности и конфиденциальности в сети Ин-
тернет.
В настоящее время протокол IPv6 поддерживают МЭ Cisco IOS
12.2(2)Т, ip6fw (реализация МЭ ipfw в ОС линии BSD для протоко-
ла IPv6), iptables (ip6tables).
Приложения
П.1. Формат кадров Ethernet
Ethernet_II
Адрес получателя Адрес отправителя Тип протокола Данные CRC
6 6 2 46- 1500 4
MAC 802.3
IEEE 802.3
Адрес получателя Адрес отправителя Длина кадра Данные CRC
6 6 2 46- 1500 4
МАС 802.3
IEEE 802.3 с 802.2
Адрес полу- чателя Адрес отпра- вителя Тип прото- кола DSAP SSAP CNTL Данные CRC
6 6 2 1 1 1 35- 1489 4
МАС 802.3 LLC 802.2
IEEE 802.3 с 802.2 SNAP
Адрес полу- чателя Адрес отпра- вителя Тип прото- кола DSAP SSAP CNTL Код Тип Дан- ные CRC
6 6 2 1 1 1 3 2 38- 1492 4
МАС 802.3 LLC 802.2 SNAP 802.2
268
DSAP - Destination Service Access Point (поле адреса доступа к службе
получателя);
SSAP - Source Service Access Point (поле адреса доступа к службе отправителя);
CNTL - CoNTroL (управляющее поле);
МАС - Medium Access Control (управление доступом к среде);
LLC - Logical Link Control (управление логической связью);
SNAP - SubNetwork Access Protocol (протокол доступа к субсетям).
Некоторые реализации кадров Ehernet
Формат кадра Реализация
Ehemetn 802.3 802.2 SNAP DecNET, старые реализации TCP/IP NetWare 3.x NetWare 4.x EtherTalk, новые реализации TCP/IP
П.2. Формат пакета IP
0 4 8
31 бит
Версия | HLen | Тип сервиса Полная длина 24 октет
Идентификатор Флаги Указатель фрагмента
Время жизни | Протокол Контрольная сумма заголовка
ЕР-адрес отправителя
ЕР-адрес получателя
Опции (если есть) | Заполнитель
Данные
***
Версия Версия IP-протокола
HLen Длина заголовка в 32-разрядных словах. Без опций и
заполнителя длина заголовка равна 20 октет (байт)
Тип TOS (Type Of Service) определяет порядок обра-
сервиса ботки IP-пакета. Состоит из 6 подполей:
0 1 2 3 4 5 6 __________7________
| Приоритет | D | Т |. R | С | Не используется |
Трехбитное подполе Приоритет определяет приоритет каждого
пакета: 0 - обычный; 1 - приоритетный; 2- немедленный; 3 - срочный;
4 - экстренный; 5 - CEITIC/ECP; 6 - межсетевое управление; 7 - сетевое
управление.
Поля D, Т, R, С при установленном значении 1 определяют требования
к задержке, пропускной способности, надежности и стоимости соответ-
ственно. Только одно из этих полей может быть установленно в 1.
Документы RFC 1349, RFC 1455 регламентируют значения TOS.
270
Полная длина Полная длина IP-пакета, включая заголовок и данные
Ид ентиф икатор Уникальный код, используется для идентификации пакетов. Совместно с полями флаги и указатель фрагмента позволяет выполнять правильную сборку пакетов
Флаги Биты: 0 - зарезервирован; 1 - управление фрагментацией пакетов: 0- фрагментация разрешена, 1 - фрагментация запрещена; 2 - указатель последнего фрагмента: 0- последний фрагмент; 1 - ожидать продолжения
Указатель фраг- Используется для идентификации фрагмента-
мента рованных пакетов
Время жизни TTL (Time То Live) задает время жизни дейта- граммы
Протокол Определяет структуру поля Данные (ICMP-1, UDP- 17, ТСР-6)
Контрольная сумма заголовка Контрольная сумма вычисляется только по полям заголовка сложением 16-разрядных слов по мо- дулю 1. Контрольная сумма является дополнением по модулю 1 полученного результата сложения
IP-адрес отправителя IP-адрес получателя Опции IP-адрес отправителя пакета IP-адрес получателя пакета Поле опции не обязательно. Формат поля зависит от используемых опций. Формат описания опций: 1 октет 1 октет N | Код | Длина | Данные | Формат описания кода опций: 1 бит 2 бит 5 бит | Копия |. Класс опции | Номер опции | При установленном флаге Копия = 1, опция долж- на быть скопирована во все фрагменты дейтаграм- мы, иначе - только в первый фрагмент.
Опции
Значения поля Класс опции
Класс опции Описание
0 Дейтаграмма пользователя или
сетевое управление
1 Зарезервировано
2 Диагностика
3 Зарезервировано
Значение Кодов опции:
Класс опции Номер опции Длина описания Назначение
0 0 Конец списка оп- ций. Используется, если опции не ук- ладываются в поле заголовка
0 1 Никаких операций (используется для выравнивания ок- тетов в списке оп- ций)
0 2 11 Ограничения, свя- занные с секрет- ностью (для воен- ных приложений)
0 3 * Свободная марш- рутизация
0 7 * Запись маршрута
0 8 4 Идентификатор потока. Устарело
0 9 * Жесткая маршру- тизация
2 4 * Временная метка Интернет
— переменная длина.
Заполнитель
Данные
Выравнивает поле опций до 32-битной границы
Содержит протоколы вышележащих уровней
П.З. Форматы некоторых сообщений
протокола ICMP
Таблица П.З. 1. Коды функций ICMP-сообщения
ICMP-сообщение Описание сообщения
Тип Код icmp.h
0 ICMPECHOREPLY Эхо-ответ (ping-отклик)*
3 ICMPDESTUNREACH Адресат недостижим*
0 ICMP_NET_UNREACH Сеть недостижима*
1 ICMPHOSTUNREACH ЭВМ недостижима*
2 ICMPPROTUNREACH Протокол недоступен*
3 ICMP_PORT_UNREACH Порт недоступен*
4 ICMPFRAGNEEDED Необходима фрагментация собщения*
5 ICMPSRFAILED Исходный маршрут вышел из строя*
6 ICMPNETUNKNOWN Сеть места назначения неиз- вестна*
7 ICMPHOSTUNKNOWN ЭВМ места назначения неиз- вестна*
8 ICMPHOSTISOLATED Исходная ЭВМ изолирована*
9 ICMP_NET_ANO Связь с сетью места назначе- ния административно запре- щена*
10 ICMPHOSTANO Связь с ЭВМ места назначе- ния административно запре- щена*
И ICMP_NET_UNR_TOS Сеть недоступна для данного вида сервиса*
12 ICMP_HOST_UNR_TOS ЭВМ недоступна для данного вида сервиса*
13 ICMPPKTFILTERED Связь административно зап- рещена с помощью фильтра*
10 Лебедь С.В.
273
Окончание табл. П. 3.1
ICMP-сообщение Описания сообщений
Тип Код icmp.h
14 ICMP_PREC_VIOLATION Нарушение старшинства ЭВМ*
15 ICMPPRECCUTOFF Дискриминация по старшинст- ву*
4 0 ICMPSOURCEQUENCH Отключение источника при пе- реключении очереди*
5 ICMP_REDIRECT Переадресовать (изменить маршрут)
0 ICMPREDIRNET Переадресовать дейтаграмму в сеть (устарело)*
1 ICMP_REDIR_HOST Переадресовать дейтаграмму на ЭВМ*
2 ICMP_REDIR_NErTOS Переадресовать дейтаграмму для типа сервиса (TOS) и сети*
3 ICMP_REDIR_HOSTTOS Переадресовать дейтаграмму для типа сервиса и ЭВМ*
8 0 ICMP_ECHO Эхо запрос (ping-запрос)
9 0 Объявление маршрутизатора
10 0 Запрос маршрутизатора
И ICMPTIMEEXCEEDED Для дейтаграммы время жизни истекло (TTL=0):
0 ICMP_EXC_TTL При передаче*
1 ICMPEXCFRAGTIME При сборке (случай фрагмента- ции)*
12 0 1 ICMPPARAMETERPROB Проблема с параметрами дейтаграммы Ошибка в IP-заголовке* Отсутствует необходимая оп- ция*
13 ICMPTIMESTAMP Запрос временной метки
14 ICMPTIMESTAMPREPLY Временная метка-отклик
15 ICMP_INFO_REQUEST Запрос информации (устарел)
16 ICMP_INFO_REPLY Информационный отклик (ус- тарел)
17 ICMPADDRESS Запрос адресной маски
18 ICMPADDRESSREPLY Отклик на запрос адресной маски
Примечание. Символом * помечены сообщения об ошибках (остальные
сообщения являются запросами).
274
Формат эхо-запроса и отклика для протокола ICMP
О 8 16 31
Тип (8 или 0) | Код(О) Контрольная сумма
Идентификатор Номер по порядку
Данные
* * *
Формат ICMP-сообщения «адресат не достижим»
О 8 16 31
Тип (3) | Код Контрольная сумма
Не используется, заполняется нулями MTU на следующем этапе
Internet-заголовок (включая опции) + первые 64 бит дейтаграммы
* * *
Формат сообщения «время истекло»
О 8 16 31
Тип (11) | Код (0 или 1) | Контрольная сумма
_______________Не используется, заполняется нулями___________
bitemet-заголовок (включая опции) + первые 64 бит дейтаграммы
***
Схема вложения ICMP-пакетов________________
| ICMP-заголовок | ICMP-данные |
20 байт
Заголовок дейтаграммы Область данных дейтаграммы (IP)
Заголовок кадра Область данных кадра
10*
П.4. Формат пакета UDP
О
16 31
Порт отправителя Порт получателя 8 октет
Длина сообщения Контрольная сумма
Данные
***
Порт отправителя
Порт получателя
Длина сообщения
Контрольная сумма
Данные
Транспортный порт отправителя
Транспортный порт получателя
Количество байт дейтаграммы, включая
заголовок
Контрольная сумма вычисляется по всем
полям дейтаграммы
Прикладные данные протокола
П.5. Формат пакета TCP
0 4 10 16 24 31
Порт отправителя | Порт получателя
Номер очереди
Номер подтверждения
Смеще- ние данных Зарезерви- ровано и R G А С К р S н Р S S 5 11 5F if I Окно
Контрольная сумма Указатель на данные для срочной обработки
Опции | Выравнивание
Данные
***
Порт отправителя Номер порта отправителя (16 бит) Порт получателя Номер порта получателя (16 бит) Номер очереди Номер очереди для первого октета данных в сег- менте (за исключением тех случаев, когда присут- ствует флаг синхронизации SYN). Если же флаг SYN присутствует, то номер очереди является ини- циализационным (ISN), а номер первого октета данных увеличивается на единицу, т. е. ISN+1 (32 бит) Номер Если установлен контрольный бит АСК, то это по- подтверждения ле содержит следующий номер очереди, который отправитель данной дейтаграммы желает получить в обратном направлении. Номера подтверждения посылаются постоянно, как только соединение будет установлено (32 бит)
277
Смещение данных Количество 32-битных слов в TCP-заголовке. Ука- зывает на начало поля данных. ТСР-заголовок всег-да кончается на 32-битной границе слова, даже ес-ли он содержит опции (4 бит)
Зарезервировано Должно быть заполнено нулями (6 бит)
Контрольные биты 6 бит: URG - поле срочного указателя задействовано; АСК - поле подтверждения задействовано; PSH - функция проталкивания; RST - перезагрузка данного соединения; SYN - синхронизация номеров очереди; FIN - нет больше данных для передачи
Окно Количество октетов данных, начиная с октета, чей номер указан в поле подтверждения (16 бит)
Контрольная сумма 16-битное дополнение суммы всех 16-битных слов заголовка и данных. Если сегмент содержит в заго- ловке и поле Данные нечетное количество октетов, подлежащих учету в контрольной сумме, послед- ний октет будет дополнен нулями справа с тем, чтобы образовать для предоставления контрольной сумме 16-битное слово. Возникший при таком вы- равнивании октет не передается вместе с сегмен- том по сети. Перед вычислением контрольной сум- мы поле этой суммы заполняется нулями. Конт- рольная сумма, помимо всего прочего, учитывает 96 бит псевдозаголовка, который для внутреннего употебления ставится перед TCP-заголовком. Этот псевдозаголовок содержит адрес отправителя, ад- рес получателя, протокол и длину ТСР-сегмента. Такой подход обеспечивает защиту протокола TCP от ошибок при передаче. Эту информацию обраба- тывает протокол IP
Указатель на данные для срочной обра- ботки Сообщает текущее значение срочного указателя. Последний является положительной величиной — смещением относительно номера очереди данного сегмента. Указатель сообщает номер очереди для октета, следующего за срочными данными. Это по- ле интерпретируется только в том случае, когда в сегменте выставлен контрольный бит URG (16 бит)
278
Опции
Выравнивание
Могут располагаться в конце TCP-заголовка, длина
кратна 8 бит. Все опции учитываются при расчете
контрольной суммы. В настоящее время определе-
ны следующие опции: конец списка опций, нет
операций, максимальный размер сегмента
Заполняется нулями, чтобы поле данных сегмента
начиналось на 32-битной границе. Переменная
длина
П.6. Производители МЭ
Производитель | Web-сайт | Продукт
Коммерческие МЭ
3 Com Corporation www.3com.com NETBuilder OfficeConnect Internet FirewaU
Actanet www.actane.com STARTX25 ACTANE ControUer
Aker Concultancy and Infonnatique LTD Aker FirewaU
Alta Vista alta vista.software. digital.com/firewa 11/index.asp AltaVista FirewaU 98
Alcatel www.ind.alcatel. conr Ft. KnoxPoEcy Router
AXENT (фирма Eagle Firewall в 1998 г. вошла в сос- тав Axent с FWv Raptor Firewall) www.axent.com Raptor FirewaU
Ashley Laurent, Inc. www.vpcom.com/ pro ducts /pro ducts htm VPCom
aVirt Gateway Solutions www.avirt.com/ gateway.html aVirt Gateway
BorderWare Technologies, Inc. www.borderware. com BorderWare FirewaU Server
Bull S.A. www.bull.com NetWaU
Cendio Systems www.cendio.com Fuego FirewaU
280
Продолжение прил. П. 6
Производитель Web-сайт Продукт
Citadel Data Security www.cdsec.com CEQURUX Firewall
Check Point Software Technologies www.checkpoint. com Check Point Firewall-1
Cisco Systems Inc. www.cisco.com Cisco IOS 12.0 Cisco IOS Firewall Feature Set Private Internet Exchange (IX)
Com21, Inc. www.com21.com Office Cable Modem
Computer Associates www.cai.com Unicenter TNG Network Security Options GuardIT
CyberGuard Corporation www.cyberguard- corp.com Cyberguard Firewall
Deerfield Communications wingate.deerfield. com Win Gate
FreeGate Corporation www.freegate.com Freegate
Erlon Software www.elronsw.com /enterpris e/cvfire- wall.htm Elron CommandView Firewall
eSoft www.esoft.com Instagate Internet Appliance, IPAD
Fore Systems, Inc. www.marconi. com Firewall Switching Agent for Firewall-1
GenNet Technology Co., Ltd. www.gennet.com. tw WebGuard
Global Technology Assoc. Inc. www.gta.com GNAT Box
Herve Schauer Consultants www.hsc.fr HSC GateKeeper
IBM www.ibm.com/ Security eNetwork Firewall
Intel www.intel.com LANRover VPN Gateway
Internet Dynamics www.interdyn. com Conclave
INS Inter Networking Systems www.ins.de/ins/ engl/efluxhtm FLUX Enhanced Firewall
281
Продолжение прил. П. 6
Производитель Web-сайт Продукт
KarlNet Inc www.gbnet.net/ kbridge KarlBridge/KarlBrouter
KyberPASS www.kyber-pass. com KyberPASS > Security Server
Lucent Technologies, Inc. www.lucent.com/ security Lucent Managed Firewall Secure Connect Firewall Brick Firewall
LANGuard www.languard. com LANguard
Lacus Technology Co. www.lacus.com/ products.htm Safeguard InterServer
Livermore Software Laboratories, Inc www.lsli.com PORTUS Firewall Systems
Lucidata www.lucidata.com LuciGate Firewall
MATRAnet www.matranet. com M>WaU
Milky way Networks www.milkyway. com Black Hole (SecurlT) Firewall
NETASQ www.netasq.com NETASQ F100
Netguard Ltd. www.ntguard.com Guardian
Netopia, Inc. www.netopia.com Netopia S9500 Security Appliance
Net Screen Technologies, Inc. www.netscreen. com Netscreen
Network-1 Security Solutions, Inc. www.network-1. com CyberwallPLUS
Network Associates www.nai.com Gauntlet Internet Firewall
Nokia www.nokia.com Firewall-1 for IP330, IP440, and IP650
Norman Data Defense Systems www.norman.com Norman Firewall
Nortel Networks www.nortelnet- works.com BaySecure FireWall-1 for BayRS 13.20
Novell www.novell.com BorderManager Firewall Services 3
Progressive Systems, Inc. www.progres s ive- systems.com Phoenix Adaptive Firewall
282
Продолжение прил. П. 6
Производитель Web-сайт Продукт
RadGuard www.radguard. com cIPro- 5000 FW
Secure Computing www. s ecurecom- puting.com Sidewinder SecureZone
Silicon Graphics Пандора
SLM Software, Inc. www.milky way .com SecurlT Firewall
SonicWALL, Inc. www.sonicsys. com SonicWALL
SmallWorks smallworks.com/ netgate NetGate
SOS Corporation www.soscorp.com/ products/Brimstone. html Brimstone
Solsoft www.solsoft.fr/ products/index. html Solsoft Net Partitioner
Sun Microsystems Inc. www.sun.com SunScreen EFS
Symbolic www.symbolic.it COObFIRE
Technologic www.tlogic.com Interceptor and InstaGate
TUNIX Open System Consultants www.tunix.nl TUNIX Firewall
WatchGuard Technologies Inc. www.watchguard.com Watchguard LiveSecurity System
UUNET www.ans.net Uus ecure FireWall
ZONEOFTRUST www. web s afegu- ard.com WebSafeGuard
Инфосистемы Джет www.jet.msk.su Застава-Джет
Элвис+ (Trust Works Systems) Застава
Internet Devices (больше не сущест- вует- преобрела Alcatel) www.intemetdevices. com AFS 2000 Internet Device
CSM www.csm-usa. com CSM Proxy
Sterling Commerce www. s t erling с о mmer- ce.com CONNECT:Firewall
Netmatrix Internet Co. www.netmatrix.com IPAD 1200
283
Окончание прил. П. 6
Производитель | W еЬ-сайт | Продукт
Персональные МЭ
AgnitumLtd. www.agnitum.com Agnitum Outpost Firewall PRO Agnitum Outpost Firewall Free
Aladdin Knowledge Systems www.esafe.com www.ealaddin.com eSafe Protect Desktop
InfoExpress www.infoexpress.com CyberArmor Personal Firewall
McAfee.com www.McAfee.com McAfee.com Personal Firewall
Network ICE www.n et wo rkice .com BlackICE Defender LE
Secure4U www.secure4u.com Secure4U
Signal 9 Solutions (преобрела McAfee.com) www.cons ealfirewall. com www.signal9.com ConSeal PC Firewall
Sybergen www.sybergen.com Sybergen Secure Desktop'
Sygate www.sygate.com Sygate Personal Firewall
WRQ, Inc. (22.12.2000 переда- ла права Symantec) www.atguard.cogi www.symantec.com AtGuard /Norton Internet Security
ZoneLabs www.zonelabs .com/ zonealann.htm Zone Alarm
Бесплатные МЭ
BlackCode www.blackcode.com BlackCode Firewall
Ipchains ipchains .nerdherd.org www.rustcorp.com/ linux/ip chains ipchains
Mediator One www.comnet.com.au/ htmls/mediator 1 .html Mediator One Firewall
Obtuse Systems Corporation www.obtuse.com Juniper
SinusFireWall www.sinusfirewall.org SinusFireWall
Terrier.Rex www.opensourcefire- wall.com T.REX Firewall
Trusted Information Systems www.tis .com TIS Firewall
IP Filter coombs.anu.edu.au/ -avalon/ IP Filter
284
П.7. МЭ, сертифицированные
по «Общим критериям»
(По состоянию на 29 мая 2001 г.)
Межсетевой экран Уровень адекватности Заявитель Статус
VCS Firewall Version 3.0 EAL1 The Knowledge Group Certified March 1999
Cons eal Private Desktop Firewall EAL1 Signal 9 Solutions Certified May 1999
Check Point Firewall-1 Version 4.0 (SP 5) EAL2 Check Point Software Technologies, Inc. Certified Oct 1999
Cisco PIX Firewall 520V4.3(l) EAL2 Cisco Systems, Inc. Certified December 1998
Guantlet UNIX v4.2 Guantlet NT v3.0 Firewall EAL2 Network Associates Certified Oct 2000
Lucent Managed Firewall Version 3.0 (Build 150) EAL2 Lucent Technologies Certified Jan 1999
Lucent Technologies Lucent Managed Firewall - Version 4.0 (Build 199) EAL2 Lucent Technologies Certified Feb. 2000
SunScreen EFS 3.0 Revision В Routing Mode EAL2 National Institute of Standards and Techno lo gy/National Security Agency Certified Oct 2000
285
Окончание прил. П. 7
Межсетевой экран Уровень адекватности Заявитель Статус
SunScreen EFS 3.0 Revision В Stealth Mode EAL2 National Institute of Standards and T echnology/National Security Agency Certified Oct 2000
Voltaire 2nl (TM) Version 1.21 EAL2 Voltaire Advanced Data Security Certified Oct 2000
WatchGuard LiveSecurity System with Firebox II 4.1 EAL2 WatchGuard Technologies Certified Oct 2000
Milkyway Networks Black Hole Firewall V.3.01E2 for SPARCstations (SecurlT) EAL3 SLM (Milkyway) Networks Corporation Certified Aug. 1997
NAI Gauntlet Internet Firewall Version 5.5 on Sun Solaris/V 2.6 EAL4 Network Associates In Evaluation
BorderWare Firewall Server Version 6.1 EAL4 BorderWare Technologies Certificate Jan 2000
Cisco Secure PIX Firewall 515, 520, 525 V5.2(3) EAL4 Cisco Systems, Inc. Certified February 2001
CyberGuard Firewall for UnixWare /Premium Appliance Firewall Release 4.3 EAL4 CyberGuard Corporation Certified Dec 2000
Symantec Enterprise Firewall v6.5 EAL4 Syntegra CLEF In Evaluation
286
П.8. Прикладные протоколы,
«трудные» для фильтрации
File Transfer Protocol (FTP)
Протокол передачи файлов использует две TCP-сессии (ТСР-
канала): одну - для передачи команд управления (порт 21/tcp сер-
вера FTP), вторую - непосредственно для передачи данных (фай-
лов). Канал передачи может работать в активном или пассивном
режимах.
В активном режиме канал передачи открывается после созда-
ния канала управления путем передачи клиентом номера ТСР-
порта, с которым сервер должен установить соединение (кроме
того, в процессе передачи данных некоторые типы клиентов FTP
сообщают IP-адрес своего интерфейса). Поскольку номер порта
передается на прикладном уровне, то возникает проблема откры-
тия канала передачи данных. МЭ должны содержать специальные
модули, учитывающие особенности протокола FTP.
В пассивном режиме FTP-сервер сам назначает порт, с кото-
рым клиент должен установить соединение. Не все FTP-клиенты
могут работать в пассивном режиме.
Remote Procedure Call (Sun RPC)
Сервис RPC предназначен для удаленного выполнения проце-
дур в ОС Unix. Сервер RPC при запуске сообщает процессу portmap
номер прослушиваемого порта, и номера тех программ, которые
он готовится обслужить. Если клиенту нужно обратиться к RPC с
конкретным номером программы, то сначала он должен устано-
вить соединение с процессом portmap (порт 111/tcp) на сервере и
определить номер порта связи с пакетами RPC.
287
Команда г pc inf о позволяет получить список программ, их но-
меров и прослушиваемых ими транспортных портов, например:
linux:/# rpcinfo -р 10.0.0.4
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100005 1 udp 680 mountd
100005 2 udp 680 mountd
100005 1 tcp 683 mountd
100005 2 tcp 683 mountd
100003 2 udp 2049 nf s
100003 2 tcp 2049 nfs
Поскольку номера портов назначаются динамически, то реко-
мендуется использовать посредник RPC в составе МЭ.
Microsoft NetMeeting
NetMeeting - мультимедийное приложение компании Microsoft,
предоставляющие широкие возможности по организации видео/
аудио связи на основе протокола IP. NetMeeting использует следу-
ющие протоколы:
Порт Назначение
389/tcp 522/tcp 1503/tcp 1720/tcp 1731/tcp dynamic/tcp dynamic/udp Internet Locator Server User Location Server T.120 H.323 call setup Audio call control H.323 call control H.323 streaming [Realtime Transport Protocol (RTP) over UDP]
Для поддержки исходящих соединений через МЭ необходимо
разрешить соединения через порты TCP 389,522,1503,1720и 1731.
Необходимо также разрешить динамически назначаемые порты
UDP в диапазоне 1024 - 65535. Рекомендуются использование по-
средника.
Napster
Чтобы блокировать доступ пользователей к системе поиска му-
зыкальных файлов Napster, запретите доступ к группе следующих
серверов:
288
208.178.163.56/255.255.255.248
208.178.175.128/255.255.255.248
208.49.239.240/255.255.255.240
208.49.228.0/255.255.255.0
208.184.216.0/255.255.255.0
64.124.41.0/255.255.255.0
194.98.93.242
Доступ к этим серверам осуществляется по протоколу tcp (пор-
ты 80,7777,8875,8888). Клиент для предоставления доступа к соб-
ственным трЗ-файлам открывает по умолчанию порт 6699/tcp.
NetBIOS over TCP/IP (NBT)
NBT обеспечивает поддержку стека протоколов ТСРЛР для
NetBIOS (RFC 1002/1088) и использует следующие протоколы:
137/udp - NetBIOS name;
138/udp - NetBIOS datagram;
139/tcp - NetBIOS session.
Для удаленного подключения к ресурсам достаточно исполь-
зовать только протокол 139/tcp.
ICQ
Регистрация клиентов выполняется с сервером login.icq.com по
протоколу 5190/tcp. В последних версиях клиента ICQ ряд функци-
ональных возможностей реализовано через взаимодействие с пу-
лом серверов в домене .icq.com по протоколу http/tcp. По причине
использования балансировки нагрузки IP-адреса серверов назна-
чаются динамически.
Взаимодействие между клиентами выполняется через динами-
чески назначаемые ТСР-порты 1024:65535. В установках клиента
можно указать допустимый диапазон используемых портов, напри-
мер 4000:4500. В этом случае для поддержки протокола ICQ на
МЭ необходимо также обеспечить прохождение пакетов в задан-
ном диапазоне.
289
П.9. Ресурсы Интернет
Конференции и списки рассылки
Списки рассылки по МЭ
GN А С Firewalls Mailing List http ://www. lists .gnac.net/firewalls/
Checkpoint Firewalls Mailing List Raptor Mailing List http://www.checkpoint.com/services/mailing.html http://www.firetower.com/mailinglists.html
Списки рассылки, посвященные вопросам безопасности
CERT Mailing List http://cert.org/contact_cert/certmaillist.html
BugTraq http://www.netspace.org/
Microsoft Security http 'Лwww.micro s о ft. com/s ecurity
NT Security http У/www.nts ecurity .net/s ecurity/nts d.htm
Новостные группы Межсетевые экраны Общие вопросы безо- пасности Unix-систем comp.s ecurity .firewalls comp.s ecurity .unix
Web- и FTP-сайты
Linux Fire wall and Security Site www.linux-firewalltools.cpm
Электронный магазин средств сетевой www.firewallguide.com
защиты для SOHO
290
Firewall Product Overview
Internet Firewalls
Firewall Tests & Reviews
CSI Firewall Archives
Сравнение МЭ
Сайт посвящен DoS-атакам и дру-
гим вопросам информационной
безопасности
Публикации, архивы дискуссий,
информация о списках рассылки,
посвященные МЭ
Неофициальные FAQ и полезные
утилиты для МЭ FireWall-1 компа-
нии Check Point
Транспортные порты, используе-
мые наиболее распространенными
троянскими программами
FAQ по межсетевым экранам
Политика безопасности при рабо-
те в Интернете - техническое ру-
ководство
ICAT - база данных уязвимостей
Национального института стан-
дартов США
Зарегистрированные IANA номера
протоколов
Зарегистрированные IANA номера
транспортных портов
www.waterw.com/~manowar/
vendor.html
www.cerias.purdue.edu/coast/
firewalls/
www.vtcif.telstra.com.au/info/se-
curity/vendor.htm
www.spirit.com/CSI/archives .html
www.spirit.com/cgi-bin/report.pl
http ://www.denialinfo .com/
ftp.greatcircle.com/pub/firewalls/
www.phoneboy.com/fwl/
http y/www.cert.ru/trojan_lis t.html
http://www.simovits .com/trojans/
trojans.html
http ://www.clarknet/pub/mjrpubs/
fwfaq/indexhtm
http ://www.citforumru/intemet/
security_guide/indexshtml
http://icat.nist.gov/icat.cfin
http://www.isi.edu/innotes/iana/
as s ignments/protocol-numbers
http://www.isi.edu/innotes/iana/
as signments/port-numbers
291
Таблица П.9.1. Международные и правительственные
органы сертификации
Страна Организация Web-сайт
Россия Государственная техническая ко- миссия при Президенте РФ International Computer Security Association http ://www. infotecs. ru/gtc/ http ://www. icsa.com
Великобритания NSS Group http://www.nss.co.uk
США National Institute of Standards and Technology. Computer Security Division http://csrc.nist.gov/cc
США National Security Agency Attn: V2, Common Criteria Technical Advi- sor http://www.radium.ncsc. mil/tpep
Австралия Defence Signals Directorate Infor- mation Security Branch Certifica- tion and Evaluation Group http ://www. dsd.gov. au/ infosec
Канада Communications Security Establish- ment CCS Certification Body http://www.cse-cst.gc.ca
Франция Service Central de la Securite des Systemes d'Information Centre de Certification de la Securite des Technologies de 1'Information http://www.scssi.gouv.fr
Германия German Information Security Agency http://www.bsi.bund.de/cc
Нидерланды Netherlands National Communica- tions Security Agency http://www.tno.nl/instit/ fel/refs/cc.html
Великобритания Communications-Electronics Security Group http://www.cesg.gov.uk
Великобритания UK ITSEC http://www.itsec.gov.uk
Таблица П.9.2. Средства мониторинга и создания отчетов МЭ
Продукт Компания Поддерживаемые МЭ Web-сайт
Private I WebTrends Firewall Suite Open Sys- tems WebTrends FireWall-1 Checkpoint PIX, IOS Cisco AltaVista Software Firewall 97, 98 Aventail Extranet Center 3.0 and above Axent Technologies Raptor v 6.0.2 and earlier http://www.open- systems.com http://www.webtrends.com
292
Продолжение табл. П.9.2
Продукт Компания Поддерживаемые МЭ Web-сайт
WebTrends Firewall Suite WebTrends Raptor Eagle 3.x, 4.x BorderWare Technologies BorderWare Firewall Server 5.0 and above Cendio Fuego 2.4.0 Check Point Software FW- 1 3.0b and above Cisco Systems Pix Secure Firewall Up to 5.11 IOS Fire- wall Feature Set 11.3, 12.0 Cache Engine 2.01 and abo- ve CyberGuard CyberGuard Firewall 4.1 Internet Dynamics Conclave Firewall 1.52x Lucent Technologies Mana- ged Firewall 3.0x Microsoft Corporation Pro- xy Server 2.x and above Network Associates Gaunt- let Firewall for Unix 4.x and above Gauntlet Firewall for NT 2.x, 5.x NetScreen NetScreen 1.6 Netopia S9500 Security Appliance 1.6 Netscape Corporation Nets- cape Proxy Server 1.x, 2.x, 3.x Network Appliance Netcape 3.3 Novell BorderManager 2.x and above Secure Computing Side- winder 5.0 Squid Project Squid Inter-net Object Cache 1.1, 2.x Sonicwall DMZ 4.10 SOHO 4.10 Pro 4.10 Watchguard Technologies Fi- rebox II 3.3 LSS 4.x MSS 2.x http://www.web- trends.com
293
Окончание табл. П.9.2
Продукт Компания Поддерживаемые МЭ Web-сайт
Websense Enterprise Check Point FireWall-1 Edition Websense Check Point FireWall-1 http://www.web- sense.com/products /integrations/check point, cfin
Websense Enterprise Cisco Secure PIX Firewall Edition Websense Cisco PIX http://www.web- sense.com/products /integrations/cis- copix.cfm
Pixlog 1.0 Matt Post Cisco PIX http ://cs. calvin. edu/ ~mpost89/ pixlog
Fwlogwatch Boris Wesslowski Ipchains http://www.kyb. uni-stuttgart. de/ boris/ software, shtml
Fwlogsum Rui Bernardino and Paul J. Ewing Jr. Check Point Firewall http://fwlogsum. sourceforge.net
Fwlogstat Rajeev Kumar Check Point Firewall http://www.geoci- ties.com/Silicon Valley/Bit/9363
Fwanalog Balazs IP Filter http://tud.at/progra
Barany ipchains iptables m/fwanalog/
MRTG Программное средство http://www.mrtg.
(MultiRouter Traffic Grapher) мониторинга сетевого трафика org
Firewall Lord Предоставляет удобный http://www.fwbuil-
Builder Vkurland графический интерфейс для конфигурирования МЭ iptables, ipchains и ipfilter | der.org
294
Список сокращений
ИБ — Информационная безопасность
МЭ — Межсетевой экран
ОС — Операционная система
ПБ — Политика безопасности
ПО — Программное обеспечение
ACL — Access Control List (список контроля доступа)
API — Application Programming Interface (интерфейс разра-
ботки приложений)
СА — Certificate Authority (центр сертификации)
CBQ — Class Based Queuing (классовая очередь)
CVP —Content Vectoring Protocol (протокол перенаправле-
ния содержания)
DDoS —Distributed Denial of Service (распределенная атака
типа «отказ в обслуживании»)
DMZ — Demilitarized Zone (демилитаризованная зона)
DNS — Domain Name System (система доменных имен)
DoS — Denial of Service (отказ в обслуживании)
FAQ — Frequently Asked Questions (часто задаваемые вопро-
сы)
FSO — Firewall Security Officer (офицер безопасности меж-
сетевого экрана)
295
FTP —File Transmition Protocol (протокол передачи фай-
лов)
FWZ — Схема шифрования Checkpoint, используемая в про-
дуктах VPN-1/FireWall-l
GSS-API — Generic Security Service API (прикладной интерфейс
разработки общего сервиса безопасности)
НА — High Availability (повышенная готовность)
HTML —HyperText Markup Language (гипертекстовый язык
разметки)
HTTP —HyperText Transfer Protocol (протокол передачи ги-
пертекстовой информации)
IANA — Internet Assigned Numbers Authority (центр назначе-
ния номеров Интернет)
ICMP — Internet Control Message Protocol (протокол управ-
ляющих сообщений Интернет)
IKE — Internet Key Exchange (протокол Интернет обмена
ключами)
IP — Internet Protocol (протокол Интернет)
IPSec — Internet Protocol Secure (протокол безопасности Ин-
тернет)
ISAKMP — Internet Security Association and Key Management
Protocol (протокол Интернет безопасных ассоциа-
ций и управления ключами)
L2F — Layer 2 Forwarding (протокол пересылки уровня 2)
L2TP — Layer 2 Tunneling Protocol (протокол туннелирова-
ния уровня 2)
LDAP — Lightweight Directory Access Protocol (облегченный
протокол доступа к каталогу)
MAD — Malicious Activity Detection (обнаружение злонаме-
ренной активности)
ММС — Microsoft Management Console (консоль управления
компании Microsoft)
МРРЕ —Microsoft Point-to-Point Encryption Protocol (прото-
кол шифрования компании Microsoft точка-точка)
296
FTP — File Transmition Protocol (протокол передачи фай-
лов)
FWZ — Схема шифрования Checkpoint, используемая в про-
дуктах VPN-1/FireWall-l
GSS-API — Generic Security Service API (прикладной интер-
фейс разработки общего сервиса безопасности)
НА — High Availability (повышенная готовность)
HTML —HyperText Markup Language (гипертекстовый язык
разметки)
HTTP — HyperText Transfer Protocol (протокол передачи ги-
пертекстовой информации)
IANA — Internet Assigned Numbers Authority (центр назначе-
ния номеров Интернет)
ICMP — Internet Control Message Protocol (протокол управ-
ляющих сообщений Интернет)
IKE —Internet Key Exchange (протокол Интернет обмена
ключами)
IP — Internet Protocol (протокол Интернет)
IPSec — Internet Protocol Secure (протокол безопасности Ин-
тернет)
ISAKMP — Internet Security Association and Key Management
Protocol (протокол Интернет безопасных ассоциа-
ций и управления ключами)
L2F — Layer 2 Forwarding (протокол пересылки уровня 2)
L2TP — Layer 2 Tunneling Protocol (протокол туннелирова-
ния уровня 2)
LDAP — Lightweight Directory Access Protocol (облегченный
протокол доступа к каталогу)
MAD — Malicious Activity Detection (обнаружение злонаме-
ренной активности)
ММС — Microsoft Management Console (консоль управления
компании Microsoft)
297
МРРЕ — Microsoft Point-to-Point Encryption Protocol (прото-
кол шифрования компании Microsoft точка-точка)
NAT — Network Address Translation (сетевая трансляция
адресов)
NBT — NetBIOS over TCP (NetBIOS поверх TCP)
NetBEUI — NetBIOS Extended User Interface (расширенный
пользовательский интерфейс NetBIOS)
NetBIOS — Network Basic In/Out System (простая сетевая сис-
тема ввода/вывода, интерфейс программирова-
ния)
OPSEC — Open Platform for Secure Enterprise Connectivity
(открытая платформа взаимодействия средств,
безопасности)
OSI — Open Systems Interconnections (модель взаимо-
действия открытых систем)
РВХ — Private Branch Exchange (телефонный коммута-
тор)
PKI — Public Key Infrastructure (инфраструктура откры-
тых ключей)
POP3 — Post Office Protocol (протокол передачи почты)
РРТР — Point-to-Point-Tunneling Protocol (протокол тунне-
лирования точка-точка)
QoS — Quality of Service (качество сервиса)
RADIUS —Remote Authentication Dial-In User Service (сервис
удаленной аутентификации пользователей)
RDED — Retransmit Detect Early Drop (раннее обнаружение
и блокировка повторной передачи)
RFC — Request for Comments (рабочее предложение)
SAMP — Suspicious Activity Monitoring Protocol (протокол
мониторинга подозрительной активности, Check
Point OPSEC)
298
SKIP — Simple Key management for Internet Protocol (прос- той протокол управления ключами для IP)
SMB — Server Message Block (блок серверных сообще- ний, протокол Microsoft)
SME — Small-Medium sized Enterprise (рынок промыш- ленных систем среднего размера)
SMTP — Simple Mail Transfer Protocol (простой протокол передачи почты)
SOHO — Small Office/Home Office (небольшие и домашние офисы)
SPAN — System Performance Analysis (анализ производи- тельности системы)
SSH — Secure SHell (защищенная оболочка)
SSL — Secure Socket Layer (уровень безопасности соке- тов)
STU — Secure Telephone Unit (телефонный узел безопас- ности)
TACACS — Terminal Access Controller Access Control System (система управления доступом к контроллерам терминального доступа)
TCP — Transport Control Protocol (протокол управления транспортом)
TLS — Transport Layer Security (безопасность транспорт- ного уровня)
UAM — User-to-Address Mapping (протокол компании Check Point привязки пользователей к адресам)
UDP — User Datagram Protocol (протокол пользователь- ских датаграм)
URL — Universal Resource Locator (универсальный лока- тор ресурса)
VPN — Virtual Private Network (виртуальные частные се- ти)
WFQ WWW — Weighted Fair Queuing (равновесная очередь) — Word Wide Web (всемирная паутина)
299
Список литературы
1. Aziz A., Markson Т., Prafullchandra Н. SKIP Algorithm Discovery
Protocol, October 1996.
2. Building Internet Firewalls. O’Reilly & Associates, 1999.
3. Canadian Trusted Computer Product Evaluation Criteria. Canadian
System Security Centre, Communication Security Establishment,
Government of Canada. Version 3.0e. January 1993.
4. Check Point FireWall-1 Architecture and Administration. Version
4.0. Check Point Software Technologies Ltd, 1999.
5. Cisco IOS 12.0 Network Security. Cisco Press, 1999.
6. Common Criteria for Information Technology Security Evaluation.
Version 2.1, August 1999.
7. David D. Clark, Scott Shenker and Lixia Zhang. Supporting Real-
Time Applications in an Integrated Services Packet Network: Arc-
hitecture and Mechanism.
8. DNS and Bind, Second Edition, Albitz, Paul, and Liu, Cricket,
O’Reilly & Associates, Inc., 1997.
9. Federal Criteria for Technology Security. National Institute of
Standards and Technology & National Security Agency. Version 1.0,
December 1992.
10. Firewalls: A Complete Guide. McGraw-Hill.
11. Firewalls Complete. McGraw-Hill.
12. http://www.cryptocard.com
13. http://www.insecure.org/nmap
14. http://www.kyuzz.org/antire27i1ping/
15. http://www.10pht.com/~weld/netcat/
16. http://www.ntndis.com/articles/firewall.htm
17. http://www.packetfactory.net/Projects/Firewalk/
18. http://www.rsasecurity.com
19. http://www.sans.org
300
20. http://www.w3 .org/TR/WD-logfile.html
21. Information Technology Security Evaluation Criteria. Harmonized
Criteria of France-Germany-Netherlands-United Kingdom. - Department
of Xrade and Industry, London, 1991.
22. Krawczyk H. SKEME: A Versatile Secure Key Exchange
Mechanism for Internet, from IEEE Proceedings of the 1996 Symposium
on Network and Distributed Systems Security.
23. Paul E. McKenney. Stochastic Fairness Queuing. Internet-
working: Research and Experience, v.2,1991, p.113-131.
24. Paul E. McKenney. Stochastic Fairness Queuing, IEEE
INFOCOMM’90 Proceedings, San Francisco, 1990.
25. Protecting Your Web Site With Firewalls. Prentice Hall.
26. RFC 1492. An Access Control Protocol, Sometimes Called TACACS.
27. RFC 1508. Linn, J. Generic Security Service API.
28. RFC 1509. Wray, J.. Generic Security Service API: C-bindings.
29. RFC1510. The Kerberos Network Authentication Service (V5).
30. RFC 1579. Firewall-Friendly FTP.
31. RFC 1597. Address Allocation for Private Internets.
32. RFC 1631. The IP Network Address Translator (NAT).
33. RFC 1881. IPv6 Address Allocation Management.
34. RFC 1918. Address Allocation for Private Internets.
35. RFC 1928. Socks Protocol Version 5.
36. RFC 2058. Remote Authentication Dial in User Service (RADIUS).
37. RFC 2185. Routing Aspects Of IPv6 Transition.
38. RFC 2196. Site Security Handbook.
39. RFC 2341. Cisco Layer Two Forwarding (Protocol) «L2F».
40. RFC 2373. IP Version 6 Addressing Architecture.
41. RFC 2374. An IPv6 Aggregatable Global Unicast Address Format.
42. RFC 2401. Security Architecture for the Internet Protocol.
43. RFC 2402. IP Authentication Header.
44. RFC 2406. IP Encapsulating Security Payload.
45. RFC 2408. Internet Security Association and Key Management
Protocol (ISAKMP).
46. RFC 2409. Internet Key Exchange (IKE).
47. RFC 2412. OAKLEY Key Determination Protocol.
48. RFC 2631. Diffie-Hellman Key Agreement Method.
49. RFC 2661. Layer Two Tunneling Protocol «L2TP».
50. RFC 2894. Router Renumbering for IPv6.
51. RFC 3078. Microsoft Point-to-Point Encryption Protocol.
52. RFC 959. File Transfer Protocol.
53. Sally Floyd and M. Speer. Experimental Results for Class-Based
Queueing, 1998.
301
54. Floyd S. and Jacobson V. Link-sharing and Resource Management
Models for Packet Networks, IEEE/АСМ Transactions on Networking,
Vol.3,No.4,1995.
55. Floyd S. and Jacobson V. Random Early Detection Gateways
for Congestion Avoidance, 1993, IEEE/АСМ Transactions on
Networking.
56. Floyd S. Notes on CBQ and Guaranted Service, 1995.
57. Floyd S. Notes on Class-Based Queueing: Setting Parameters,
1996.
58. Trusted Computer system Evaluation Ctriteria. US Department
of Defense 5200.28-STD, 1983.
59. U.S. Department of Defense Traffic-Filter Firewall Protection
Profile For Medium Robustness Environments. Version 1.4, May 2000.
60. U.S. Government Traffic-Filter Firewall Protection Profile for
Low-Risk Environments. Version 1.1, April 1999.
61. Олифер В., Олифер H. Новые технологии IP-сетей. - СПб.:
БХВ - Санкт-Петербург, 2000.
62. Зегжда Д.П., Ивашко А.М. Основы безопасности информа-
ционных систем. - М.: Горячая линия - Телеком, 2000.
63. Гриняев С.Н. Интеллектуальное противодействие информа-
ционному оружию. -М.: СИНТЕГ, 1999.
64. Семенов Ю.А. Протоколы и ресурсы Internet. - М.: Радио и
связь, 1996.
Научное издание
Сергей Васильевич Лебедь
Межсетевое экранирование
Теория и практика защиты внешнего периметра
Редактор НЕ. Овчеренко
Художник О.В. Левашова
Корректор ГС. Беляева
Компьютерная верстка И.Ю. Бурова
Подписано в печать 18.07.2002. Формат 60x90/16
Бумага офсетная. Печать офсетная. Гарнитура «Таймс»
Усл. печ. л. 19. Уч.-изд. л. 18,28. Тираж 1000 экз.
Заказ № 2041
Издательство МГТУ им. Н.Э. Баумана,
105005, Москва, 2-я Бауманская, 5
Отпечатано с оригинал-макета во ФГУП ИПК «Ульяновский Дом печати»
432980, г. Ульяновск, ул. Гончарова, 14
Издательство
МГТУ имени Н.Э. Баумана
Предлагает книги из серии
«Информатика в техническом университете»
ИИ. Норенков
Основы автоматизированного проектирования
Г. С. Иванова, Т.Н. Ничушкина, Е.К. Пугачев
Объектно-ориентированное программирование
Г.Б. Евгенев
Системология инженерных знаний
В.А. Овчинников
Алгоритмизация комбинаторно-оптимизационных
задач при проектировании ЭВМ и систем
Г. С. Иванова
Основы программирования
Л.Г. Комарцова, А.В. Максимов
Нейрокомпьютеры
Ю.А. Григорьев, Г. И. Ревунков
Банки данных
Адрес: 105005, Москва, 2-я Бауманская ул., д. 5
Тел.: (095) 263-6798 Факс: (095) 263-6045
E-mail: press@bmstu.ru
Интернет: www.press.bmstu.ru