Чем отличается мониторинг трафика от фильтрации. В россии появится национальная система фильтрации интернета. Назначение фильтрации для созданного правила

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

Батранков Денис, denisNOSPAMixi.ru

Надеюсь, эта статья будет полезна как администраторам, так и тем, кто занимается безопасностью сетей. К сожалению, обычно это разные люди.

Введение. О фильтрации вообще.

Вы только посмотрите на формат заголовка IP пакета (эта структура взята из исходников WinPCap) typedef struct ip_header{ u_char ver_ihl; // Version (4 bits) + Internet header length (4 bits) u_char tos; // Type of service u_short tlen; // Total length u_short identification; // Identification u_short flags_fo; // Flags (3 bits) + Fragment offset (13 bits) u_char ttl; // Time to live u_char proto; // Protocol u_short crc; // Header checksum ip_address saddr; // Source address ip_address daddr; // Destination address u_int op_pad; // Option + Padding }ip_header;

сколько полей требуют проверки на правильность уже на входе в сеть. Очевидно, у каждого поля существует множество значений которое определено в cтандарте RFC как имеющие какой-то смысл. И очевидно, что существует множество значений, которые не определены нигде, являются бессмысленными, и мы даже не можем предположить как эти значения будут восприняты хостом-получателем. Если у пакета хоть одно поле неправильное, то и весь он неправильный и он не должен засорять нашу сеть. Однако в настоящее время во многих сетях это не так. С такими пакетами разбирается на каждом хосте своя система защиты от атак (IPS). Я предлагаю не ждать, когда такие пакеты прибудут на хост получателя, а убивать их уже на входе в сети. Причем фильтровать и блокировать трафик мы можем последовательно начиная от канального и заканчивая уровнем приложений (в рамках модели ISO OSI). Это позволит разгрузить сеть и защитить от атак, которые пользуются тем, что мы "закрываем глаза" на неправильные пакеты.

Эта идея не нова. Намек на то, какие пакеты в вашей сети могут быть неправильными, содержится в правилах систем обнаружения атак. Системы обнаружения атак уже давно проверяют все поля пакетов и собирают статистику для анализа найденных неправильных пакетов, которую можно просмотреть и принять меры к наиболее назойливым. Мне больше всего нравится Snort, поскольку в нем все открыто для расширения возможностей. Это позволяет изменять стандартные правила или писать свои, анализировать статистику при помощи и даже можно добавлять правила на блокирование IP адресов при помощи SnortSam в почти любой из известных на данное время FW: Cisco PIX, MS ISA, Checkpoint FW-1, Watchguard Firebox и встроенные в Linux и FreeBSD FW.

Однако, не ограничивая общности можно сказать, что у тех людей, которые пользуются какими бы то ни было системами обнаружения атак, например Сisco NetRanger, RealSecure(Proventia) или Snort, есть мечта: когда же наконец они прекратят генерировать ложные алерты. У меня, по крайней мере, есть такая мечта, поскольку у меня в четырех внешних сетках класса C постоянно происходит что-то новое, хотя типы информационных потоков уже давно устаканились. Я уже не получаю многие алерты типа BAD-TRAFFIC Unassigned/Reserved IP protocol , BAD TRAFFIC Non-Standard IP protocol , BAD-TRAFFIC loopback traffic , BAD-TRAFFIC same SRC/DST , BAD-TRAFFIC tcp port 0 traffic , не потому что я отключил эти правила, а потому что я заблокировал этот "плохой трафик" сразу же на входе. К сожалению, на сегодняшний день приходится игнорировать различные события, зная, что это обычная ложная тревога и заблокировать я это не могу, поскольку любой провайдер не должен блокировать трафик клиенту каким бы он ни был: опасным или просто бесполезным. Но уж "неправильный" трафик я себе блокировать позволяю: неправильные адреса, неправильные флаги, неправильные или опасные порты.

Понятно почему есть системы IDS, которые показывают администратору какой трафик является плохим, но нет программ, которые бы автоматически фильтровали трафик на входе и выходе ваших сетей так, чтобы Snortу было не на что было ругаться. Проблема в ложных алертах. Есть много правил у того же Snort, которые должны не просто детектировать нестандартное поведение, а сразу же его блокировать. Например логично заблокировать трафик который удовлетворяет условию BAD-TRAFFIC ip reserved bit set , то есть те пакеты у которых неправильно выставлен резервный бит. (Кстати, вспомните ли вы сходу какой firewall сможет проверить такое условие и заблокировать такой пакет? ;-)) С другой стороны есть и алерты о полезности которых можно поспорить. Например, недавно стоящие у меня в сети eMule стали виновниками алертов BACKDOOR typot trojan traffic .

Итак, в идеале, с точки зрения систем обнаружения атак, нам нужно сделать так чтобы не срабатывали те правила, которые однозначно показывают, что фильтрация настроена неправильно. И правильно ее настроить - главная задача администратора.

Фильтр грубой очистки. Защита от спуфинга IP адресов.

Поскольку я пишу не книгу, а статью, то я сегодня докопаюсь лишь до одного поля IP пакета: source address. Известно, что там находится IP адрес источника пакета. И, насколько мне известно, в технологии Cisco SAFE советуют фильтровать это поле согласно RFC и для защиты от IP спуфинга. Давайте разберемся какие точно адреса мы должны блокировать. (Поле адреса получателя (destination address) должно быть в пределах выделенного вам адресного пула, поэтому тут рассуждать не о чем.)

Итак мы знаем, что начиная с 1 января 1983 года было введено понятие IP адреса 4 версии, который представляет из себя 32 битное число, которое мы обычно записываем в виде 4-х десятичных чисел, разделенных точкой. Существует организация Internet Assigned Numbers Authority (IANA), которая распределяет адреса во всем Интернет. Существуют четыре Regional Internet Registries (RIR) распределенных по миру: APNIC (Asia Pacific Network Information Centre) , ARIN (American Registry for Internet Numbers) , LACNIC (Latin American and Caribbean IP address Regional Registry) , RIPE NCC , которые распределяют адреса между Internet Service Providers (ISP). И наконец существует табличка на сайте IANA , в которой записано какой блок адресов кому отдан.

Если попытаться классифицировать адреса, то кроме (изучаемых уже сейчас в школе) классов А,B,C,D,E мы обнаруживаем что существуют специальные адреса, определяемые не только RFC 1918 , но и RFC 3330 , и которые не должны быть использованы в Интернет.

1. Приватные адреса - зарезервированы под использование в локальных сетях согласно RFC 1918.

10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255

2. Адреса получаемые при автоматическом назначении IP адреса самому себе при отсутствии DHCP сервера и согласно RFC 3330 тоже не должны выходить за пределы локальной сети.

169.254.0.0 - 169.254.255.255

3. Loopback адреса используемые для проверки работы TCP стека. Используются каждым хостом только для самого себя.

127.0.0.0 - 127.255.255.255

4. Тестовый диапазон - должен использоваться в документациях и примерах кода.

192.0.2.0–192.0.2.255

5. Multicast адреса не могут стоять в поле источника. Только в поле получателя пакета, поскольку используются для обращения к группе хостов.

224.0.0.0 - 239.255.255.255

6. Зарезервированные и невыделенные никому адреса. Эти адреса перечислены все на той же табличке на сайте IANA . На 12 декабря 2004 года в резерве следующие блоки

0.0.0.0 - 2.255.255.255
5.0.0.0 - 5.255.255.255
7.0.0.0 - 7.255.255.255
23.0.0.0 - 23.255.255.255
27.0.0.0 - 27.255.255.255
31.0.0.0 - 31.255.255.255
36.0.0.0 - 37.255.255.255
39.0.0.0 - 39.255.255.255
41.0.0.0 - 42.255.255.255
49.0.0.0 - 50.255.255.255
73.0.0.0 - 79.255.255.255
89.0.0.0 - 126.255.255.255
173.0.0.0 - 187.255.255.255
189.0.0.0 - 190.255.255.255
197.0.0.0 - 197.255.255.255
223.0.0.0 - 223.255.255.255
240.0.0.0 - 255.255.255.255

Последний список впечатляет. И мы еще жалуемся, что нам не хватает адресов. И это я еще объединил несколько блоков адресов, если они находились рядом в списке.

7. Есть еще один класс адресов, который не может быть в поле sources. Это ваши собственные адреса. Те адреса Интернет, которые выделены вам и только вам провайдером. Очевидно, что никто кроме вас не имеет права пользоваться ими и вы должны блокировать любые попытки прислать пакет с адресом источника из вашего пула адресов. Тем более, что подстановка вашего адреса в поле sources может использоваться для реализации различных атак. Например, в атаке Land, посылается SYN-пакет с адресом отправителя, совпадающим с адресом получателя.

Итак, оказалось что существует достаточно большое множество адресов, которых не может быть в поле sources наших IP пакетов. Как правило, если в sources прописан один из перечисленных выше адресов, то это либо неправильно работающая у вышестоящего провайдера маршрутизация (выпускающая наружу неправильные адреса), либо возможная DOS атака. Именно поэтому я предлагаю заблокировать все перечисленные выше адреса на входе вашего маршрутизатора.

Суммируя вышесказанное, мы получаем достаточно приличный список адресов отправителя, который мы должны блокировать. Например, если вы используете маршрутизатор Cisco то access-list будет выглядеть следующим образом:

ip access-list extended complete_bogon	Используем именованный расширенный список доступа
deny ip 0.0.0.0 1.255.255.255 any	IANA Reserved
deny ip 2.0.0.0 0.255.255.255 any	IANA Reserved
deny ip 5.0.0.0 0.255.255.255 any	IANA Reserved
deny ip 7.0.0.0 0.255.255.255 any	IANA Reserved
deny ip 10.0.0.0 0.255.255.255 any	RFC 1918
deny ip 23.0.0.0 0.255.255.255 any	IANA Reserved
deny ip 27.0.0.0 0.255.255.255 any	IANA Reserved
deny ip 31.0.0.0 0.255.255.255 any	IANA Reserved
deny ip 36.0.0.0 1.255.255.255 any	IANA Reserved
deny ip 39.0.0.0 0.255.255.255 any	IANA Reserved
deny ip 41.0.0.0 0.255.255.255 any	IANA Reserved
deny ip 42.0.0.0 0.255.255.255 any	IANA Reserved
deny ip 49.0.0.0 0.255.255.255 any	IANA Reserved
deny ip 50.0.0.0 0.255.255.255 any	IANA Reserved
deny ip 73.0.0.0 0.255.255.255 any	IANA Reserved
deny ip 74.0.0.0 1.255.255.255 any	IANA Reserved
deny ip 76.0.0.0 3.255.255.255 any	IANA Reserved
deny ip 82.0.0.0 1.255.255.255 any	IANA Reserved
permit 88.0.0.0 0.255.255.255 our_net	разрешим доступ с адресом 88/8 в нашу сеть (чтобы не заблокировать ниже)
deny ip 88.0.0.0 7.255.255.255 any	IANA Reserved
deny ip 96.0.0.0 31.255.255.255 any	IANA Reserved и Loopback
deny ip 169.254.0.0 0.0.255.255 any	автоназначенные адреса
deny ip 172.16.0.0 0.15.255.255 any	RFC 1918
deny ip 173.0.0.0 0.255.255.255 any	IANA Reserved
deny ip 174.0.0.0 1.255.255.255 any	IANA Reserved
deny ip 176.0.0.0 7.255.255.255 any	IANA Reserved
deny ip 184.0.0.0 3.255.255.255 any	IANA Reserved
deny ip 189.0.0.0 0.255.255.255 any	IANA Reserved
deny ip 190.0.0.0 0.255.255.255 any	IANA Reserved
deny ip 192.0.2.0 0.0.0.255 any	Адреса для тестов.
deny ip 192.168.0.0 0.0.255.255 any	RFC 1918
deny ip 197.0.0.0 0.255.255.255 any	IANA Reserved
deny ip 198.18.0.0 0.1.255.255 any	IANA Reserved
deny ip 201.0.0.0 0.255.255.255 any	IANA Reserved
deny ip 222.0.0.0 1.255.255.255 any	IANA Reserved
deny ip 223.0.0.0 0.255.255.255 any	IANA Reserved
deny ip 224.0.0.0 31.255.255.255 any	Multicast и затем IANA Reserved
deny ip our_net any	блокируем наши адреса на входе
permit ip any our_net	разрешаем все остальное

our_net я обозначил ваш блок адресов. Например, он может выглядеть как 194.194.194.0 0.0.0.255 согласно правил написания access-listов.

Неважно где будет реализован этот метод фильтрации на вашем пограничном маршрутизаторе, межсетевом экране или даже на сервере, но самое главное что атакующий лишается возможности использовать адреса из несуществующих сетей. Хочу заметить, что если вы пользуетесь Cisco IOS последних версий (12.2 и выше), то вам не нужно этот access-list делать самому. Такой же access-list формируется простой (казалось бы) командой auto secure .

Команда auto secure делает ВСЁ за специалиста по компьютерной безопасности! Все что наработано на сегодняшний день по защите маршрутизаторов Cisco делается этой одной командой. Вы, конечно, должны представлять что она делает, когда вводите ее, но эта команда сделает все, даже если у вас нет никаких сертификатов и образования в этой области. :(Я вообще когда узнал про возможности auto secure решил, что вот и пришла пора бросать заниматься безопасностью и пойти утюги продавать - там и зарплата, говорят, больше и высшее образование не нужно. ;-) Зачем теперь специалисты, если все делается одной командой.

Однако у этого метода есть минус: вам нужно постоянно отслеживать изменения в таблице на сайте IANA http://www.iana.org/assignments/ipv4-address-space , чтобы после изменения этого списка вы изменили свой access-list. Например, последнее изменение было в августе этого года: выделены сети 71/8, 72/8 для ARIN. Я не знаю есть ли готовый скрипт для выполнения этой работы, но если вы найдете такой или напишете сами, то общество будет Вам благодарно. Есть одна страничка, где всегда хранится актуальный access-list http://www.cymru.com/Documents/secure-ios-template.html , но там список доступа слегка длинноват. Его можно сократить. Принцип сокращения такой

deny ip 0.0.0.0 0.255.255.255 any
deny ip 1.0.0.0 0.255.255.255 any

меняем на

deny ip 0.0.0.0 1.255.255.255 any

В случае если на входе в сеть нет такого фильтра, то возможно вам хочется настроить фильтр на своем собственном сервере или рабочей станции. Кстати авторы персональных FW могли бы взять это на вооружение. Это поможет защитить хост от DOS атак. Вот, например, пример атиспуфингового фильтра для BIND .

После того как мы разобрались с адресами, можно заняться другими полями IP пакета. Например, мне в сеть очень часто приходят tcp пакеты с портом 0. Почему бы вам не посмотреть какие порты используются в пакетах ходящих по вашей сетке.

Фильтр тонкой очистки или Isolated VLAN.

Теперь посмотрим на трафик во внутренней сети. Одним из ключевых факторов построения безопасной конфигурации сети является точное определение всех объектов сети и точное понимание с кем нужно обмениваться информацией каждому из этих объектов и какой вид трафика при этом порождается. Весь другой трафик между этими объектами должен быть отклонен.

Давайте рассмотрим на примере Демилитаризованной зоны (DMZ). Считается правильным выделять сервера компании в отдельную сеть, защищенную как от пользователей из Интернет, так и от внутренних пользователей. Как говорят, доверяй, но проверяй. На картинке показаны два возможных варианта реализации: DMZ располагается между двумя Firewall и DMZ висит на одном из портов Firewall.

Итак, межсетевые экраны фильтруют трафик, приходящий из Интернет и из локальной сети. И, как правило, дизайнеры сети успокаиваются на этой схеме. Все сервера подключаются через один свитч и оказываются в одном широковещательном домене. Однако нужно ли взаимодействие между серверами в DMZ друг с другом? Нужно смотреть в каждом конкретном случае. Можно предположить, что если будет взломан один из серверов DMZ, то с этого сервера возможна атака на соседний сервер, тем более что мы на этапе проектирования никак не защитили один сервер от другого. Таким образом, в тех случаях, когда серверы не должны функционировать друг с другом рекомендуется делать несколько отдельных DMZ. Однако лучшим вариантом является использование PVLAN. Если порты, к которым подключены серверы не будут пересылать пакеты друг другу на канальном уровне, то не будет никакого трафика между серверами и единственный способ для них связаться друг с другом - пройти через Firewall, на котором это соединение должно быть разрешено и передано на нужный порт. Такие порты которые не передают трафик друг другу на канальном уровне называются изолированными.

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

С помощью этого же механизма можно объединять пользователей в группы (community), в пределах которых организуется их "выделенное" общение. При этом и изолированные пользователи, и группы могут передавать свой трафик в так называемые публичные (promiscuous) порты, на которых работает маршрутизатор, межсетевой экран и система обнаружения атак.

У Сisco PVLAN реализован так, что трафик, который приходит на promiscuous порт может быть распределен по любым другим портам типа isolated и community. Трафик, который приходит на isolated порт может быть направлен только на promiscuous порт. Трафик, который приходит на community порт может быть направлен на promiscuous порт и на порты принадлежащие этой же community.

Таким образом, даже находясь в одном VLAN хосты у которых в схеме информационных потоков не должно быть взаимного трафика не будут получать ни единого пакета друг от друга. Единственная возможность обменяться информацией – прописать явно правило на межсетевом экране или маршрутизаторе разрешающее передавать пакеты между ними. Но это правило уже работает на третьем уровне модели OSI и в этом случае можно применять access-list и правила межсетевого экрана для явного указания разрешенных портов и протоколов.

Если копнуть более глубоко, то когда хост 1 посылает ARP запрос (в поиске MAC адреса хоста 2 с нужным ему IP из той же подсети) хост 2 не получает это запрос и не отвечает хосту 1, поскольку оба сидят на изолированных друг от друга портах. Мы добились того, что хост 1 считает, что хост 2 недоступен и наоборот. Таким образом решается задача контроля трафика внутри сети и, самое главное, не нужно разбивать сеть на подсети. Мы можем безболезненно наложить технологию PVLAN на уже имеющиеся сети.

Когда же нам становится нужно, чтобы сервера общались друг с другом, то маршрутизатор (или firewall) может ответить, что этот хост доступен через него. Эта техника называется Proxy ARP . Хост 1 думает, что хост 2 находится в другом сегменте и посылает IP пакет через маршрутизатор (или firewall). То есть получается, что в пакете стоит MAC адрес маршрутизатора, и IP адрес хоста 2. А вот маршрутизатор (или firewall) уже решает передавать пакет хосту 2 или нет.

Надо заметить, что есть и уязвимость этого метода: если у вас используется маршрутизатор который не имеет никаких правил доступа и, не задумываясь, маршрутизирует все пакеты, что к нему приходят, то злоумышленник с хоста 1 может специально послать пакет с МАС адресом маршрутизатора, но с IP адресом хоста 2. Такой пакет пройдет через isolated port к маршрутизатору и затем будет послан маршрутизатором на хост 2. Поэтому, надо либо добавить правила доступа на маршрутизаторе (или firewall) запрещающие или разрешающие такие пакеты явно, либо пользоваться дополнительно VLAN Access Control List (VACL) на свитче.

Раньше в рамках одного свитча была похожая возможность которая называлась protected port, но она работала только в пределах одного свитча и информация о protected портах не передавалась по транкам. Сейчас это понятие расширено и дополнено community портами.

Технология PVLAN может быть практически реализована на достаточно большом количестве выпускаемых в настоящее время управляемых коммутаторов имеющих порты Ethernet со скоростью работы 10/100/1000 мегабит в секунду.

Конкретная реализация этих схем на свитчах Cisco описана .

Фильтрация информационных потоков состоит в их выборочном пропускании через экран, возможно, с выполнением некоторых преобразований и извещением отправителя о том, что его данным в пропуске отказано. Фильтрация осуществляется на основе набора правил, предварительно загруженных в экран и являющихся выражением сетевых аспектов принятой политики безопасности. Поэтому межсетевой экран удобно представлять как последовательность фильтров (рис.А.2), обрабатывающих информационный поток. Каждый из фильтров предназначен для интерпретации отдельных правил фильтрации путем выполнения следующих стадий:

1. Анализа информации по заданным в интерпретируемых правилах критериям, например, по адресам получателя и отправителя или по типу приложения, для которого эта информация предназначена.

2. Принятия на основе интерпретируемых правил одного из следующих решений:

Не пропустить данные;

Обработать данные от имени получателя и возвратить результат отправителю;

Передать данные на следующий фильтр для продолжения анализа;

Пропустить данные, игнорируя следующие фильтры.

Рис. А.2. Структура межсетевого экрана

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

разрешение или запрещение дальнейшей передачи данных;

выполнение дополнительных защитных функций.

В качестве критериев анализа информационного потока могут использоваться следующие параметры:

служебные поля пакетов сообщений, содержащие сетевые адреса, идентификаторы, адреса интерфейсов, номера портов и другие значимые данные;

непосредственное содержимое пакетов сообщений, проверяемое, например, на наличие компьютерных вирусов;

внешние характеристики потока информации, например, временные,

частотные характеристики, объем данных и т. д.

Используемые критерии анализа зависят от уровней модели OSI, на которых осуществляется фильтрация. В общем случае, чем выше уровень модели OSI, на котором брандмауэр фильтрует пакеты, тем выше и обеспечиваемый им уровень защиты.

Выполнение функций посредничества

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

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

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

идентификацию и аутентификацию пользователей;

проверку подлинности передаваемых данных;

разграничение доступа к ресурсам внутренней сети;

разграничение доступа к ресурсам внешней сети;

фильтрацию и преобразование потока сообщений, например, динамический поиск вирусов и прозрачное шифрование информации;

трансляцию внутренних сетевых адресов для исходящих пакетов сообщений;

регистрацию событий, реагирование на задаваемые события, а также анализ зарегистрированной информации и генерацию отчетов;

кэширование данных, запрашиваемых из внешней сети.

Для высокой степени безопасности необходима идентификация и аутентификация пользователей не только при их доступе из внешней сети во внутреннюю, но и наоборот. Пароль не должен передаваться в открытом виде через общедоступные коммуникации. Это предотвратит получение несанкционированного доступа путем перехвата сетевых пакетов, что возможно, например, в случае стандартных сервисов типа Telnet. Оптимальным способом аутентификации является использование одноразовых паролей. Удобно и надежно также применение цифровых сертификатов, выдаваемых доверительными органами, например центром распределения ключей. Большинство программ-посредников разрабатываются таким образом, чтобы пользователь аутентифицировался только в начале сеанса работы с межсетевым экраном. После этого от него не требуется дополнительная аутентификация в течение времени, определяемого администратором. Программы-посредники могут осуществлять проверку подлинности получаемых и передаваемых данных. Это актуально не только для аутентификации электронных сообщений, но и мигрирующих программ (Java,ActiveXControls), по отношению к которым может быть выполнен подлог. Проверка подлинности сообщений и программ заключается в контроле их цифровых подписей. Для этого также могут применяться цифровые сертификаты. Идентификация и аутентификация пользователей при обращении к межсетевому экрану позволяет разграничить их доступ к ресурсам внутренней или внешней сети. Способы разграничения к ресурсам внутренней сети ничем не отличаются от способов разграничения, поддерживаемых на уровне операционной системы. При разграничении доступак ресурсам внешней сети чаще всего используется один из следующих подходов:

разрешение доступа только по заданным адресам во внешней сети;

фильтрация запросов на основе обновляемых списков недопустимых адресов и блокировка поиска информационных ресурсов по нежелательным ключевым словам;

накопление и обновление администратором санкционированных информационных ресурсов внешней сети в дисковой памяти брандмауэра и полный запрет доступа во внешнюю сеть.

Фильтрация и преобразование потока сообщений выполняется посредником на основе заданного набора правил. Здесь следует различать два вида программ посредников:

экранирующие агенты, ориентированные на анализ потока сообщений для определенных видов сервиса, например, FTP,HTTP,Telnet;

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

Брандмауэры с посредниками позволяют также организовывать защищенные виртуальные сети (VirtualPrivateNetwork-VPN), например, безопасно объединить несколько локальных сетей, подключенных кInternet, в одну виртуальную сеть.VPNобеспечивают прозрачное для пользователей соединение локальных сетей, сохраняя секретность и целостность передаваемой информации путем ее динамического шифрования. При передаче поInternetвозможно шифрование не только данных пользователей, но и служебной информации - конечных сетевых адресов, номеров портов и т. д. Программы-посредники могут выполнять и такую важную функцию, как трансляцию внутренних сетевых адресов. Данная функция реализуется по отношению ко всем пакетам, следующим из внутренней сети во внешнюю. Для этих пакетов посредник выполняет автоматическое преобразованиеIP-адресов компьютеров-отправителей в один "надежный"IP-адрес, ассоциируемый с брандмауэром, из которого передаются все исходящие пакеты. В результате все исходящие из внутренней сети пакеты оказываются отправленными межсетевым экраном, что исключает прямой контакт между авторизованной внутренней сетью и являющейся потенциально опасной внешней сетью.IP-адрес брандмауэра становится единственным активнымIP-адресом, который попадает во внешнюю сеть.

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

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

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

Особенности межсетевого экранирования на различных уровнях модели OSI

Брандмауэры поддерживают безопасность межсетевого взаимодействия на различных уровнях модели OSI. При этом функции защиты, выполняемые на разных уровнях эталонной модели, существенно отличаются друг от друга. Поэтому комплексный межсетевой экран удобно представить в виде совокупности неделимых экранов, каждый из которых ориентирован на отдельный уровень модели OSI. Чаще всего комплексный экран функционирует на сетевом, сеансовом и прикладном уровнях эталонной модели. Соответственно различают такие неделимые брандмауэры (рис. А.3), как экранирующий маршрутизатор, экранирующий транспорт (шлюз сеансового уровня), а также экранирующий шлюз (шлюз прикладного уровня).

Учитывая, что используемые в сетях протоколы (TCP/IP, SPX/IPX) не однозначно соответствуют модели OSI, то экраны перечисленных типов при выполнении своих функций могут охватывать и соседние уровни эталонной модели. Например, прикладной экран может осуществлять автоматическое зашифровывание сообщений при их передаче во внешнюю сеть, а также автоматическое расшифровывание криптографически закрытых принимаемых данных. В этом случае такой экран функционирует не только на прикладном уровне модели OSI, но и на уровне представления. Шлюз сеансового уровня при своем функционировании охватывает транспортный и сетевой уровни модели OSI. Экранирующий маршрутизатор при анализе пакетов сообщений проверяет их заголовки не только сетевого, но и транспортного уровня.

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

Рис. А.3. Типы межсетевых экранов, функционирующих на отдельных уровнях модели OSI

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

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

Потенциальные угрозы, возникающие в результате посещения сотрудниками различных не относящихся к выполняемой ими работе сайтов, помимо нецелевого использования рабочего времени, могут выглядеть как:

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

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

Применение фильтрации в межсетевых экранах NetDefend D-Link рассмотрено в разделе "Функции IDP, WCF, AV" ("Фильтрация Web-содержимого (WCF)").

Виртуальные локальные сети VLAN

VLAN (Virtual Local Area Network – виртуальная локальная сеть). Виртуальной локальной сетью называется логическая группа устройств, имеющих возможность взаимодействовать между собой напрямую на канальном уровне, хотя физически при этом они могут быть подключены к разным сетевым коммутаторам. И наоборот, трафик устройств, находящихся в разных VLAN’ах, полностью изолирован от других узлов сети на канальном уровне, даже если они подключены к одному коммутатору. Это означает, что передача кадров между разными виртуальными сетями на основании MAC-адреса невозможна, независимо от типа адреса – уникального, группового или широковещательного.

VLAN’ы обладают следующими преимуществами:

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

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

VLAN применяется в нескольких случаях. Обычное применение – когда один Ethernet-интерфейс представлен как несколько интерфейсов. Это означает, что число физических Ethernet-портов на межсетевых экранах NetDefend не ограничивается числом соединений внешних сетей.

Виртуальные локальные сети также используются для группировки отдельных пользователей таким образом, чтобы их трафик был полностью отделен от других виртуальных локальных сетей. Под управлением NetDefendOS трафик может проходить между различными VLAN’ами и фильтроваться с помощью политик безопасности, предусмотренными правилами системы NetDefendOS.

Конфигурация VLAN системы NetDefendOS включает в себя комбинацию VLAN-каналов (trunk) от межсетевых экранов NetDefend до коммутаторов, интерфейсы которых настроены, как VLAN на основе портов (port based VLANs). Любой физический интерфейс межсетевого экрана может одновременно пропускать оба трафика – VLAN-трафик для одного или нескольких виртуальных локальных сетей и не- VLAN-трафик.

NetDefendOS полностью поддерживает стандарт IEEE 802.1Q для виртуальных локальных сетей, которые функционируют, добавляя к заголовку Ethernet-кадра идентификатор виртуальной локальной сети (VLAN ID). VLAN ID – это число от 0 до 4095, используемое для идентификации виртуальной локальной сети, которой принадлежит каждый фрейм. С применением такого механизма Ethernet-фреймы могут принадлежать разным виртуальным локальным сетям и при этом совместно использовать один физический интерфейс. В NetDefendOS одному физическому интерфейсу может назначаться уникальный VLAN ID и тот же самый VLAN ID может быть назначен другим физическим интерфейсам, т.е. одна и та же виртуальная сеть позволяет объединить компьютеры пользователей, подключенных к разным физическим интерфейсам (на рис. 6.1 – VLAN1 и VLAN2).

Рис. 6.1.

Один или несколько VLAN’ов настроены на физический интерфейс межсетевого экрана NetDefend и соединяются прямо с коммутатором. Это соединение работает как VLAN-канал (trunk). Коммутатор должен поддерживать тип port based VLANs. Конфигурация порта коммутатора, который соединяется с межсетевым экраном, должна быть настроена на прием VLAN ID, которые будут передаваться через VLAN-каналы (trunk).

Так же как в проводной локальной сети представлена возможность использования VLAN’ов, так и в беспроводной сети существуют механизмы разграничения беспроводных клиентов.

Виртуальные частные сети (VPN)

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

конфиденциальность информации;
целостность данных;
доступность информации;

Этим требованиям удовлетворяет механизм, названный VPN (Virtual Private Network – виртуальная частная сеть) – обобщённое название технологий, позволяющих обеспечить одно или несколько сетевых соединений (логическую сеть) поверх другой сети (например, Интернет) с использованием средств криптографии (шифрования, аутентификации, инфраструктуры открытых ключей, средств для защиты от повторов и изменений передаваемых по логической сети сообщений).

Создание VPN не требует дополнительных инвестиций и позволяет отказаться от использования выделенных линий. В зависимости от применяемых протоколов и назначения, VPN может обеспечивать соединения трёх видов: хост-хост, хост-сеть и сеть-сеть .

Для наглядности представим следующий пример: предприятие имеет несколько территориально отдаленных филиалов и "мобильных" сотрудников, работающих дома или в разъезде. Необходимо объединить всех сотрудников предприятия в единую сеть. Самый простой способ – это поставить модемы в каждом филиале и организовывать связь по мере необходимости. Такое решение, однако, не всегда удобно и выгодно – порой нужна постоянная связь и большая пропускная способность. Для этого придется либо прокладывать выделенную линию между филиалами, либо арендовать их. И то и другое довольно дорого. И здесь в качестве альтернативы при построении единой защищенной сети можно применять VPN-подключения всех филиалов фирмы через Интернет и настройку VPN-средств на хостах сети.

Рис. 6.5.

В этом случае решаются многие проблемы – филиалы могут располагаться где угодно по всему миру.

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

Чтобы этого не произошло, в решениях VPN используются такие средства, как шифрование данных для обеспечения целостности и конфиденциальности, аутентификация и авторизация для проверки прав пользователя и разрешения доступа к виртуальной частной сети.

VPN-соединение всегда состоит из канала типа точка-точка, также известного под названием туннель . Туннель создаётся в незащищённой сети, в качестве которой чаще всего выступает Интернет.

Туннелирование (tunneling) или инкапсуляция (encapsulation) – это способ передачи полезной информации через промежуточную сеть. Такой информацией могут быть кадры (или пакеты) другого протокола. При инкапсуляции кадр не передается в том виде, в котором он был сгенерирован хостом-отправителем, а снабжается дополнительным заголовком, содержащим информацию о маршруте, позволяющую инкапсулированным пакетам проходить через промежуточную сеть (Интернет). На конце туннеля кадры деинкапсулируются и передаются получателю. Как правило, туннель создается двумя пограничными устройствами, размещенными в точках входа в публичную сеть. Одним из явных достоинств туннелирования является то, что данная технология позволяет зашифровать исходный пакет целиком, включая заголовок, в котором могут находиться данные, содержащие информацию, которую злоумышленники используют для взлома сети (например, IP-адреса, количество подсетей и т.д.).

Хотя VPN-туннель устанавливается между двумя точками, каждый узел может устанавливать дополнительные туннели с другими узлами. Для примера, когда трём удалённым станциям необходимо связаться с одним и тем же офисом, будет создано три отдельных VPN-туннеля к этому офису. Для всех туннелей узел на стороне офиса может быть одним и тем же. Это возможно благодаря тому, что узел может шифровать и расшифровывать данные от имени всей сети, как это показано на рисунке:

Пользователь устанавливает соединение с VPN-шлюзом, после чего пользователю открывается доступ к внутренней сети.

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

Существует множество различных решений для построения виртуальных частных сетей. Наиболее известные и широко используемые протоколы – это:

PPTP (Point-to-Point Tunneling Protocol) – этот протокол стал достаточно популярен благодаря его включению в операционные системы фирмы Microsoft.
L2TP (Layer-2 Tunneling Protocol) – сочетает в себе протокол L2F (Layer 2 Forwarding) и протокол PPTP. Как правило, используется в паре с IPSec.
IPSec (Internet Protocol Security) – официальный Интернет-стандарт, разработан сообществом IETF (Internet Engineering Task Force).

Перечисленные протоколы поддерживаются устройствами D-Link.

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

Протокол PPTP позволяет создавать защищенные каналы для обмена данными по различным протоколам – IP, IPX, NetBEUI и др. Данные этих протоколов упаковываются в кадры PPP, инкапсулируются с помощью протокола PPTP в пакеты протокола IP. Далее они переносятся с помощью IP в зашифрованном виде через любую сеть TCP/IP. Принимающий узел извлекает из пакетов IP кадры PPP, а затем обрабатывает их стандартным способом, т.е. извлекает из кадра PPP пакет IP, IPX или NetBEUI и отправляет его по локальной сети. Таким образом, протокол PPTP создает соединение точка-точка в сети и по созданному защищенному каналу передает данные. Основное преимущество таких инкапсулирующих протоколов, как PPTP – это их многопротокольность. Т.е. защита данных на канальном уровне является прозрачной для протоколов сетевого и прикладного уровней. Поэтому, внутри сети в качестве транспорта можно использовать как протокол IP (как в случае VPN, основанного на IPSec), так и любой другой протокол.

В настоящее время за счет легкости реализации протокол PPTP широко используется как для получения надежного защищенного доступа к корпоративной сети, так и для доступа к сетям Интернет-провайдеров, когда клиенту требуется установить PPTP-соединение с Интернет-провайдером для получения доступа в Интернет.

Метод шифрования, применяемый в PPTP, специфицируется на уровне PPP. Обычно в качестве клиента PPP выступает настольный компьютер с операционной системой Microsoft, а в качестве протокола шифрования используется протокол Microsoft Point-to-Point Encryption (MPPE). Данный протокол основывается на стандарте RSA RC4 и поддерживает 40- или 128-разрядное шифрование. Для многих приложений такого уровня шифрования использование данного алгоритма вполне достаточно, хотя он и считается менее надежным, нежели ряд других алгоритмов шифрования, предлагаемых IPSec, в частности, 168-разрядный Triple-Data Encryption Standard (3DES).

Как происходит установление соединения PPTP?

PPTP инкапсулирует пакеты IP для передачи по IP-сети. Клиенты PPTP создают управляющее туннелем соединение, которое обеспечивает работоспособность канала. Этот процесс выполняется на транспортном уровне модели OSI. После создания туннеля компьютер-клиент и сервер начинают обмен служебными пакетами.

В дополнение к управляющему соединению PPTP создается соединение для пересылки данных по туннелю. Инкапсуляция данных перед отправкой в туннель включает два этапа. Сначала создается информационная часть PPP-кадра. Данные проходят сверху вниз, от прикладного уровня OSI до канального. Затем полученные данные отправляются вверх по модели OSI и инкапсулируются протоколами верхних уровней.

Данные с канального уровня достигают транспортного уровня. Однако информация не может быть отправлена по назначению, так как за это отвечает канальный уровень OSI. Поэтому PPTP шифрует поле полезной нагрузки пакета и берет на себя функции второго уровня, обычно принадлежащие PPP, т. е. добавляет к PPTP-пакету PPP-заголовок (header) и окончание (trailer). На этом создание кадра канального уровня заканчивается. Далее, PPTP инкапсулирует PPP-кадр в пакет Generic Routing Encapsulation (GRE), который принадлежит сетевому уровню. GRE инкапсулирует протоколы сетевого уровня, например IP, IPX, чтобы обеспечить возможность их передачи по IP-сетям. Однако применение только GRE-протокола не обеспечит установление сессии и безопасность данных. Для этого используется способность PPTP создавать соединение для управления туннелем. Применение GRE в качестве метода инкапсуляции ограничивает поле действия PPTP только сетями IP.

После того как кадр PPP был инкапсулирован в кадр с заголовком GRE, выполняется инкапсуляция в кадр с IP-заголовком. IP-заголовок содержит адреса отправителя и получателя пакета. В заключение PPTP добавляет PPP заголовок и окончание.

На рис. 6.7 показана структура данных для пересылки по туннелю PPTP:

Для организации VPN на основе PPTP не требуется больших затрат и сложных настроек: достаточно установить в центральном офисе сервер PPTP (решения PPTP существуют как для Windows, так и для Linux платформ), а на клиентских компьютерах выполнить необходимые настройки. Если же нужно объединить несколько филиалов, то вместо настройки PPTP на всех клиентских станциях лучше воспользоваться Интернет-маршрутизатором или межсетевым экраном с поддержкой PPTP: настройки осуществляются только на пограничном маршрутизаторе (межсетевом экране), подключенном к Интернету, для пользователей все абсолютно прозрачно. Примером таких устройств могут служить многофункциональные Интернет-маршрутизаторы серии DIR/DSR и межсетевые экраны серии DFL.

GRE-туннели

Generic Routing Encapsulation (GRE) – протокол инкапсуляции сетевых пакетов, обеспечивающий туннелирование трафика через сети без шифрования. Примеры использования GRE:

передача трафика (в том числе широковещательного) через оборудование, не поддерживающее определенный протокол;
туннелирование IPv6-трафика через сеть IPv4;
передача данных через публичные сети для реализации защищенного VPN-соединения.

Рис. 6.8.

Между двумя маршрутизаторами A и B ( рис. 6.8) находится несколько маршрутизаторов, GRE-туннель позволяет обеспечить соединение между локальными сетями 192.168.1.0/24 и 192.168.3.0/24 так, как если бы маршрутизаторы A и B были подключены напрямую.

Протокол L2TP появился в результате объединения протоколов PPTP и L2F. Главное достоинство протокола L2TP в том, что он позволяет создавать туннель не только в сетях IP, но и в сетях ATM, X.25 и Frame relay. L2TP применяет в качестве транспорта протокол UDP и использует одинаковый формат сообщений как для управления туннелем, так и для пересылки данных.

Как и в случае с PPTP, L2TP начинает сборку пакета для передачи в туннель с того, что к полю информационных данных PPP добавляется сначала заголовок PPP, затем заголовок L2TP. Полученный таким образом пакет инкапсулируется UDP. В зависимости от выбранного типа политики безопасности IPSec, L2TP может шифровать UDP-сообщения и добавлять к ним заголовок и окончание Encapsulating Security Payload (ESP), а также окончание IPSec Authentication (см. в разделе "L2TP over IPSec"). Затем производится инкапсуляция в IP. Добавляется IP-заголовок, содержащий адреса отправителя и получателя. В завершение L2TP выполняет вторую PPP-инкапсуляцию для подготовки данных к передаче. На рис. 6.9 показана структура данных для пересылки по туннелю L2TP.

Компьютер-получатель принимает данные, обрабатывает заголовок и окончание PPP, убирает заголовок IP. При помощи IPSec Authentication проводится аутентификация информационного поля IP, а ESP-заголовок IPSec помогает расшифровать пакет.

Далее компьютер обрабатывает заголовок UDP и использует заголовок L2TP для идентификации туннеля. Пакет PPP теперь содержит только полезные данные, которые обрабатываются или пересылаются указанному получателю.

IPsec (сокращение от IP Security) – набор протоколов для обеспечения защиты данных, передаваемых по межсетевому протоколу IP, позволяет осуществлять подтверждение подлинности и/или шифрование IP-пакетов. IPsec также включает в себя протоколы для защищённого обмена ключами в сети Интернет.

Безопасность IPSec достигается за счёт дополнительных протоколов, добавляющих к IP-пакету собственные заголовки – инкапсуляции. Т.к. IPSec – стандарт Интернет, то для него существуют документы RFC:

RFC 2401 (Security Architecture for the Internet Protocol) – архитектура защиты для протокола IP.
RFC 2402 (IP Authentication header) – аутентификационный заголовок IP.
RFC 2403 (The Use of HMAC-MD5-96 within ESP and AH) - использование алгоритма хэширования MD-5 для создания аутентификационного заголовка.
RFC 2404 (The Use of HMAC-SHA-1-96 within ESP and AH) – использование алгоритма хэширования SHA-1 для создания аутентификационного заголовка.
RFC 2405 (The ESP DES-CBC Cipher Algorithm With Explicit IV) – использование алгоритма шифрования DES.
RFC 2406 (IP Encapsulating Security Payload (ESP)) – шифрование данных.
RFC 2407 (The Internet IP Security Domain of Interpretation for ISAKMP) – область применения протокола управления ключами.
RFC 2408 (Internet Security Association and Key Management Protocol (ISAKMP)) – управление ключами и аутентификаторами защищенных соединений.
RFC 2409 (The Internet Key Exchange (IKE)) – обмен ключами.
RFC 2410 (The NULL Encryption Algorithm and Its Use With IPsec) – нулевой алгоритм шифрования и его использование.
RFC 2411 (IP Security Document Roadmap) – дальнейшее развитие стандарта.
RFC 2412 (The OAKLEY Key Determination Protocol) – проверка аутентичности ключа.

IPsec является неотъемлемой частью Интернет-протокола IPv6 и необязательным расширением версии Интернет-протокола IPv4.

Механизм IPSec решает следующие задачи:

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

Компоненты IPSec

Протокол AH (Authentication Header) – протокол идентификации заголовка. Обеспечивает целостность путём проверки того, что ни один бит в защищаемой части пакета не был изменён во время передачи. Но использование AH может вызвать проблемы, например, при прохождении пакета через NAT устройство. NAT меняет IP-адрес пакета, чтобы разрешить доступ в Интернет с закрытого локального адреса. Т.к. пакет в таком случае изменится, то контрольная сумма AH станет неверной (для устранения этой проблемы разработан протокол NAT-Traversal (NAT-T), обеспечивающий передачу ESP через UDP и использующий в своей работе порт UDP 4500). Также стоит отметить, что AH разрабатывался только для обеспечения целостности. Он не гарантирует конфиденциальности путём шифрования содержимого пакета.

Протокол ESP (Encapsulation Security Payload) обеспечивает не только целостность и аутентификацию передаваемых данных, но еще и шифрование данных, а также защиту от ложного воспроизведения пакетов.

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

Т.к. оба протокола – AH и ESP – добавляют собственные заголовки IP, каждый из них имеет свой номер (ID) протокола, по которому можно определить, что последует за IP-заголовком. Каждый протокол, согласно IANA (Internet Assigned Numbers Authority – организация, ответственная за адресное пространство сети Интернет), имеет свой собственный номер (ID). Например, для TCP этот номер равен 6, а для UDP – 17. Поэтому, очень важно при работе через межсетевой экран настроить фильтры таким образом, чтобы пропускать пакеты с ID AH и/или ESP протокола.

Для того чтобы указать, что в заголовке IP присутствует AH, устанавливается ID протокола 51, а для ESP – номер 50.

ВНИМАНИЕ : ID протокола не то же самое, что номер порта.

Протокол IKE (Internet Key Exchange) – стандартный протокол IPsec, используемый для обеспечения безопасности взаимодействия в виртуальных частных сетях. Предназначение IKE – защищенное согласование и доставка идентифицированного материала для ассоциации безопасности (SA).

SA – это термин IPSec для обозначения соединения. Установленный SA (защищенный канал, называемый "безопасной ассоциацией" или "ассоциацией безопасности" – Security Association, SA) включает в себя разделяемый секретный ключ и набор криптографических алгоритмов.

Протокол IKE выполняет три основные задачи:

обеспечивает средства аутентификации между двумя конечными точками VPN;
устанавливает новые связи IPSec (создаёт пару SA);
управляет существующими связями.

IKE использует UDP-порт с номером 500. При использовании функции NAT Traversal, как упоминалось ранее, протокол IKE использует UDP-порт с номером 4500.

Обмен данными в IKE происходит в 2 фазы. В первой фазе устанавливается ассоциация SA IKE. При этом выполняется аутентификация конечных точек канала и выбираются параметры защиты данных, такие как алгоритм шифрования, сессионный ключ и др.

Во второй фазе SA IKE используется для согласования протокола (обычно IPSec).

При настроенном VPN-туннеле для каждого используемого протокола создаётся одна пара SA. SA создаются парами, т.к. каждая SA – это однонаправленное соединение, а данные необходимо передавать в двух направлениях. Полученные пары SA хранятся на каждом узле.

Так как каждый узел способен устанавливать несколько туннелей с другими узлами, каждый SA имеет уникальный номер, позволяющий определить, к какому узлу он относится. Этот номер называется SPI (Security Parameter Index) или индекс параметра безопасности .

SA храняться в базе данных (БД) SAD (Security Association Database).

Каждый узел IPSec также имеет вторую БД – SPD (Security Policy Database) – БД политики безопасности. Она содержит настроенную политику узла. Большинство VPN-решений разрешают создание нескольких политик с комбинациями подходящих алгоритмов для каждого узла, с которым нужно установить соединение.

Гибкость IPSec состоит в том, что для каждой задачи предлагается несколько способов ее решения, и методы, выбранные для одной задачи, обычно не зависят от методов реализации других задач. Вместе с тем, рабочая группа IETF определила базовый набор поддерживаемых функций и алгоритмов, который должен быть однотипно реализован во всех продуктах, поддерживающих IPSec. Механизмы AH и ESP могут использоваться с различными схемами аутентификации и шифрования, некоторые из которых являются обязательными. Например, в IPSec определяется, что пакеты аутентифицируются либо с помощью односторонней функции MD5, либо с помощью односторонней функции SHA-1, а шифрование осуществляется с использованием алгоритма DES. Производители продуктов, в которых работает IPSec, могут добавлять другие алгоритмы аутентификации и шифрования. Например, некоторые продукты поддерживают такие алгоритмы шифрования, как 3DES, Blowfish, Cast, RC5 и др.

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

Протоколы защиты передаваемого потока (AH и ESP) могут работать в двух режимах – в транспортном режиме и в режиме туннелирования . При работе в транспортном режиме IPsec работает только с информацией транспортного уровня, т.е. шифруется только поле данных пакета, содержащего протоколы TCP / UDP (заголовок IP-пакета не изменяется (не шифруется)). Транспортный режим, как правило, используется для установления соединения между хостами.

В режиме туннелирования шифруется весь IP-пакет, включая заголовок сетевого уровня. Для того чтобы его можно было передать по сети, он помещается в другой IP-пакет. По существу, это защищённый IP-туннель. Туннельный режим может использоваться для подключения удалённых компьютеров к виртуальной частной сети (схема подключения "хост-сеть") или для организации безопасной передачи данных через открытые каналы связи (например, Интернет) между шлюзами для объединения разных частей виртуальной частной сети (схема подключения "сеть-сеть").

Режимы IPsec не являются взаимоисключающими. На одном и том же узле некоторые SA могут использовать транспортный режим, а другие – туннельный.

На фазе аутентификации вычисляется контрольная сумма ICV (Integrity Check Value) пакета. При этом предполагается, что оба узла знают секретный ключ, который позволяет получателю вычислить ICV и сравнить с результатом, присланным отправителем. Если сравнение ICV прошло успешно, считается, что отправитель пакета аутентифицирован.

В режиме транспорта AH

весь IP-пакет, за исключением некоторых полей в заголовке IP, которые могут быть изменены при передаче. Эти поля, значения которых для расчета ICV равняются 0, могут быть частью службы (Type of Service, TOS), флагами, смещением фрагмента, временем жизни (TTL), а также заголовком контрольной суммы;
все поля в AH;
полезные данные пакетов IP.

AH в режиме транспорта защищает IP-заголовок (за исключением полей, для которых разрешены изменения) и полезные данные в исходном IP-пакете (рисунок 3.39).

В туннельном режиме исходный пакет помещается в новый IP-пакет, и передача данных выполняется на основании заголовка нового IP-пакета.

Для туннельного режима AH при выполнении расчета в контрольную сумму ICV включаются следующие компоненты:

все поля внешнего заголовка IP, за исключением некоторых полей в заголовке IP, которые могут быть изменены при передаче. Эти поля, значения которых для расчета ICV равняются 0, могут быть частью службы (Type of Service, TOS), флагами, смещением фрагмента, временем жизни (TTL), а также заголовком контрольной суммы;
все поля AH;
исходный IP-пакет.

Как видно на следующей иллюстрации, режим туннелирования AH защищает весь исходный IP-пакет за счет дополнительного внешнего заголовка, который в режиме транспорта AH не используется:

В режиме транспорта ESP аутентифицирует не весь пакет, а обеспечивает защиту только полезных данных IP. Заголовок ESP в режиме транспорта ESP добавляется в IP-пакет сразу после заголовка IP, а окончание ESP (ESP Trailer), соответственно, добавляется после данных.

Режим транспорта ESP шифрует следующие части пакета:

полезные данные IP;
ESP Trailer.

Алгоритм шифрования, который использует режим шифрования цепочки блоков (Cipher Block Chaining, CBC) имеет незашифрованное поле между заголовком ESP и полезной нагрузкой. Это поле называется вектором инициализации IV (Initialization Vector) для расчета CBC, которое выполняется на получателе. Так как это поле используется для начала процесса расшифровки, оно не может быть зашифрованным. Несмотря на то, что у злоумышленника есть возможность просмотра IV, он никак не сможет расшифровать зашифрованную часть пакета без ключа шифрования. Для предотвращения злоумышленниками изменения вектора инициализации, он охраняется контрольной суммой ICV. В этом случае ICV выполняет следующие расчеты:

все поля в заголовке ESP;
полезные данные, включая открытый текст IV;
все поля в ESP Trailer, за исключением поля данных проверки подлинности.

Туннельный режим ESP инкапсулирует весь исходный IP-пакет в заголовок нового IP, заголовок ESP и ESP Trailer. Для того чтобы указать, что в заголовке IP присутствует ESP, устанавливается идентификатор протокола IP 50, причем исходный заголовок IP и полезные данные остаются без изменений. Как и в случае с туннельным режимом AH, внешний IP-заголовок базируется на конфигурации туннеля IPSec. В случае использования туннельного режима ESP область аутентификации IP-пакета показывает, где была поставлена подпись, удостоверяющая его целостность и подлинность, а зашифрованная часть показывает, что информация является защищенной и конфиденциальной. Исходный заголовок помещается после заголовка ESP. После того, как зашифрованная часть инкапсулируется в новый туннельный заголовок, который не зашифровывается, осуществляется передача IP-пакета. При отправке через общедоступную сеть такой пакет маршрутизируется на IP-адрес шлюза принимающей сети, а уже шлюз расшифровывает пакет и отбрасывает заголовок ESP с использованием исходного заголовка IP для последующей маршрутизации пакета на компьютер, находящийся во внутренней сети. Режим туннелирования ESP шифрует следующие части пакета:

исходный IP-пакет;
ESP Trailer.
Для туннельного режима ESP расчет ICV производится следующим образом:
все поля в заголовке ESP;
исходный IP-пакет, включая открытый текст IV;
все поля заголовка ESP, за исключением поля данных проверки подлинности.

Резюме по применению режимов IPSec:

Протокол – ESP (AH).
Режим – туннельный (транспортный).
Способ обмена ключами – IKE (ручной).
Режим IKE – main (aggressive).
Ключ DH – group 5 (group 2, group 1) – номер группы для выбора динамически создаваемых ключей сеанса, длина группы.
Аутентификация – SHA1 (SHA, MD5).
Шифрование – DES (3DES, Blowfish, AES).

При создании политики, как правило, возможно создание упорядоченного списка алгоритмов и Diffie-Hellman групп. Diffie-Hellman (DH) – протокол шифрования, используемый для установления общих секретных ключей для IKE, IPSec и PFS (Perfect Forward Secrecy – совершенная прямая секретность). В таком случае будет использована первая позиция, совпавшая на обоих узлах. Очень важно, чтобы всё в политике безопасности позволяло добиться этого совпадения. Если за исключением одной части политики всё остальное совпадает, узлы всё равно не смогут установить VPN-соединение. При настройке VPN-туннеля между различными системами нужно выяснить, какие алгоритмы поддерживаются каждой стороной, чтобы была возможность выбора наиболее безопасной политики из всех возможных.

Основные настройки, которые включает в себя политика безопасности:

Симметричные алгоритмы для шифрования/дешифрования данных.
Криптографические контрольные суммы для проверки целостности данных.
Способ идентификации узла. Самые распространенные способы – это предустановленные ключи (pre-shared secrets) или СА-сертификаты.
Использовать ли режим туннеля или режим транспорта.
Какую использовать группу Diffie-Hellman (DH group 1 (768-bit); DH group 2 (1024-bit); DH group 5 (1536-bit)).
Использовать ли AH, ESP, или оба вместе.
Использовать ли PFS.

Ограничением IPSec является то, что он поддерживает только передачу данных на уровне протокола IP.

Существуют две основные схемы применения IPSec, отличающиеся ролью узлов, образующих защищенный канал.

В первой схеме защищенный канал образуется между конечными хостами сети. В этой схеме протокол IPSec защищает тот узел, на котором выполняется:

Рис. 6.13.

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

Для хостов, поддерживающих IPSec, возможно использование как транспортного, так и туннельного режимов. Для шлюзов разрешается использование только туннельного режима.

Установка и поддержка VPN

Как упоминалось выше, установка и поддержка VPN-туннеля выполняется в два этапа. На первом этапе (фазе) два узла договариваются о методе идентификации, алгоритме шифрования, хэш-алгоритме и группе Diffie-Hellman. Они также идентифицируют друг друга. Всё это может пройти в результате обмена тремя нешифрованными сообщениями (т.н. агрессивный режим, Aggressive mode ) или шестью сообщениями, с обменом зашифрованной информацией об идентификации (стандартный режим, Main mode ).

В режиме Main Mode обеспечивается возможность согласований всех параметров конфигурации устройств отправителя и получателя, в то время как в режиме Aggressive Mode такой возможности нет, и некоторые параметры (группа Diffie-Hellman, алгоритмы шифрования и аутентификации, PFS) должны быть заранее одинаково настроены на каждом устройстве. Однако, в данном режиме меньше и число обменов, и число пересылаемых при этом пакетов, в результате чего требуется меньше времени для установки сеанса IPSec.

Предполагая, что операция завершилась успешно, создаётся SA первой фазы – Phase 1 SA (также называемый IKE SA ) и процесс переходит ко второй фазе.

На втором этапе генерируются данные ключей, узлы договариваются об используемой политике. Этот режим, также называемый быстрым режимом (Quick mode), отличается от первой фазы тем, что может установиться только после первого этапа, когда все пакеты второй фазы шифруются. Правильное завершение второй фазы приводит к появлению Phase 2 SA или IPSec SA и на этом установка туннеля считается завершённой.

Сначала на узел прибывает пакет с адресом назначения в другой сети, и узел инициирует первую фазу с тем узлом, который отвечает за другую сеть. Допустим, туннель между узлами был успешно установлен и ожидает пакеты. Однако узлам необходимо переидентифицировать друг друга и сравнить политику по прошествие определённого периода времени. Этот период называется время жизни Phase One или IKE SA lifetime .

Узлы также должны сменить ключ для шифрования данных через отрезок времени, который называется временем жизни Phase Two или IPSec SA lifetime .

Phase Two lifetime короче, чем у первой фазы, т.к. ключ необходимо менять чаще. Нужно задать одинаковые параметры времени жизни для обоих узлов. Если не выполнить этого, то возможен вариант, когда изначально туннель будет установлен успешно, но по истечении первого несогласованного промежутка времени жизни связь прервётся. Проблемы могут возникнуть и в том случае, когда время жизни первой фазы меньше аналогичного параметра второй фазы. Если настроенный ранее туннель прекращает работу, то первое, что нуждается в проверке – это время жизни на обоих узлах.

Еще следует отметить, что при смене политики на одном из узлов изменения вступят в силу только при следующем наступлении первой фазы. Чтобы изменения вступили в силу немедленно, надо убрать SA для этого туннеля из базы данных SAD. Это вызовет пересмотр соглашения между узлами с новыми настройками политики безопасности.

Иногда при настройке IPSec-туннеля между оборудованием разных производителей возникают затруднения, связанные с согласованием параметров при установлении первой фазы. Следует обратить внимание на такой параметр, как Local ID – это уникальный идентификатор конечной точки туннеля (отправителя и получателя). Особенно это важно при создании нескольких туннелей и использовании протокола NAT Traversal.

Dead Peer Detection

В процессе работы VPN, при отсутствии трафика между конечными точками туннеля, или при изменении исходных данных удалённого узла (например, смена динамически назначенного IP-адреса), может возникнуть ситуация, когда туннель по сути таковым уже не является, становясь как бы туннелем-призраком. Для того чтобы поддерживать постоянную готовность к обмену данными в созданном IPSec-туннеле, механизм IKE (описанный в RFC 3706) позволяет контролировать наличие трафика от удалённого узла туннеля, и в случае его отсутствия на протяжении установленного времени, посылается hello- сообщение (в межсетевых экранах D-Link посылается сообщение "DPD-R-U-THERE"). При отсутствии ответа на это сообщение в течение определённого времени, в межсетевых экранах D-Link заданного настройками "DPD Expire Time", туннель демонтируется. Межсетевые экраны D-Link после этого, используя настройки "DPD Keep Time" ( рис. 6.18), автоматически пытаются восстановить туннель.

Протокол NAT Traversal

IPsec-трафик может маршрутизироваться по тем же правилам, что и остальные IP-протоколы, но так как маршрутизатор не всегда может извлечь информацию, характерную для протоколов транспортного уровня, то прохождение IPsec через NAT-шлюзы невозможно. Как упоминалось ранее, для решения этой проблемы IETF определила способ инкапсуляции ESP в UDP, получивший название NAT-T (NAT Traversal).

Протокол NAT Traversal инкапсулирует трафик IPSec и одновременно создает пакеты UDP, которые NAT корректно пересылает. Для этого NAT-T помещает дополнительный заголовок UDP перед пакетом IPSec, чтобы он во всей сети обрабатывался как обычный пакет UDP и хост получателя не проводил никаких проверок целостности. После поступления пакета по месту назначения заголовок UDP удаляется, и пакет данных продолжает свой дальнейший путь как инкапсулированный пакет IPSec. Таким образом, с помощью механизма NAT-T возможно установление связи между клиентами IPSec в защищённых сетях и общедоступными хостами IPSec через межсетевые экраны.

При настройке межсетевых экранов D-Link в устройстве-получателе нужно отметить два пункта:

в полях Remote Network и Remote Endpoint указать сеть и IP-адрес удаленного устройства-отправителя. Необходимо разрешить преобразование IP-адреса инициатора (отправителя) с помощью технологии NAT (рисунок 3.48).
при использовании общих ключей с несколькими туннелями, подключенными к одному удаленному межсетевому экрану, которые были преобразованы с помощью NAT в один и тот же адрес, важно убедиться в том, что Local ID является уникальным для каждого туннеля.

Local ID может быть одним из:

Auto – в качестве локального идентификатора используется IP-адрес интерфейса исходящего трафика.
IP – IP-адрес WAN-порта удаленного межсетевого экрана
DNS – DNS-адрес
Email – Email

IPSec в межсетевых экранах D-Link

Межсетевые экраны NetDefend позволяют создавать IPSec-туннели на основе IKE-ключей и сертификатов.

Использование ключей (Pre-Shared Key)

При минимальных настройках для работы VPN-сервера необходимо:

Создать объекты (в папке Objects ):
- IP-адрес удаленной точки (например, IPSec_remote_endpoint) и удаленной сети (например, IPSec_remote_net);
- ключ Pre-shared Key (Autentication Objects) , объект IKE Algorithms и объект IPSec Algorithms (VPN Objects) . По умолчанию в DFL объекты IKE Algorithms , IPSec Algorithms и алгоритмы шифрования и хеширования уже заданы, но можно изменить или добавить алгоритмы, которые могут быть использованы при обмене ключами (IKE Algorithms) и самом шифровании трафика (IPSec Algorithms).
Создать IPSec Tunnel (в папке Interfaces ).
Создать разрешающие правила (в папке IP Rules ) для доступа трафика из туннеля во внутреннюю сеть и обратно.

Использование сертификатов (Certificates)

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

Сертификаты подписываются центром Certificate Authority (CA), что позволяет подтвердить подлинность сертификата, информации, содержащейся в сертификате и, в конечном итоге, удаленного хоста. Подлинность CA проверяется в соответствии с его свидетельством, которое является общедоступным.

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

При установке VPN-туннеля межсетевой экран должен знать, кому он должен доверять. При использовании заранее распределенных ключей все просто. Межсетевой экран доверяет всем, у кого есть такой же ключ. В случае использования сертификатов межсетевой экран должен доверять всем, чей сертификат подписан данным CA. Прежде чем сертификат будет принят, выполняются следующие действия для проверки подлинности сертификата:

создается путь сертификации к корневому CA, которому доверяют;
проверяются подписи всех сертификатов в пути сертификации.

Обычно VPN-туннель устанавливается, если сертификат удаленного узла, подписанный CA, представлен в поле Root certificates во вкладке Authentication в меню созданного VPN-туннеля. Однако в некоторых случаях возникает необходимость ограничить тех, кто может устанавливать VPN-туннель даже среди узлов, подписанных тем же CA. Список личностей может быть выбран в поле Identification List Различие этих двух режимов в том, что Aggressive mode передаст большее количество информации в меньшем количестве пакетов (сокращается время соединения (создания IPSec-туннеля)), но он не обеспечивает защиту подлинности.

Группа ключей DH IKE (IKE DH Group) . DH – Diffie-Hellman – криптографический протокол, который позволяет двум сторонам, общающимся через небезопасную сеть (например, Интернет), сгенерировать общий секретный ключ, который впоследствии будет использоваться для шифрования данных между этими сторонами.

Криптостойкость алгоритма определяется размером ключа: 1 (768 bit), 2 (1024 bit) или 5 (1536 bit). Размер ключа DH группы 1 равен 768 бит. Размер ключа DH группы 2 равен 1024 бит. Размер ключа DH группы 5 равен 1536 бит. Чем выше группа, тем более криптоскойким становится алгоритм, и тем больше ресурсов процессора он потребляет.

PFS (Perfect Forward Secrecy – совершенная прямая секретность) – дополнительное шифрование при обмене ключами во второй фазе.

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

NAT Traversal используется в случае, если оба устройства, устанавливающие IPSec-туннель, работают под NAT’ом. Возможен выбор опций:

Disabled – межсетевой экран не будет отправлять идентификатор "vendor ID".

On if supported and NATed – если одно из устройств IPSec-туннеля работает под NAT’ом и DFL сообщает об этом второму устройству, отправляя идентификатор "vendor ID".

On if supported – всегда использовать NAT, когда устанавливается туннель.

Keep-alive отправляет сообщения "ping" в том случае, если одно устройство при отправке данных по туннелю не получает отклика от второго устройства. Возможен выбор опций:

Disable – механизм Keep-alive отключен

Auto – межсетевой экран будет отправлять сообщения ping ICMP на IP-адреса, автоматически найденные в параметрах туннеля VPN.

Средства фильтрации трафика

Задачами средств фильтрации трафика являются контроль сетевого трафика (содержимого сетевых пакетов) и блокировка (фильтрация) трафика, не отвечающего заданным правилам безопасности. Фильтры трафика проводят контроль и анализ содержимого сетевых пакетов на прикладном уровне, но в отличии от межсетевых экранов, не осуществляют посредническую функцию между двумя узлами для исключения их непосредственного взаимодействие (сетевые экраны и прокси сервера). В отличие от средств IDS/IPS фильтры трафика не обеспечивают выявление и предотвращение сетевых вторжений и атак.

К средствам фильтрации трафика относятся:

фильтры сетевых протоколов;
контент-фильтры, в том числе URL-фильтры;
спам-фильтры;
фильтры веб-трафика для защиты веб- приложений (Web Security).

Указанные средства фильтрации трафика встроены и применяются в внутри отдельных средства защиты, таких как Firewall, Network Antivirus, Proxy Server, IDS/IPS, UTM, WAF, E-Mail Security, HIPS, с решением различных задач или реализуются в виде отдельных программных и аппаратно-программных средств. Дополнительно средства фильтрации трафика используются в системах биллинга, учет и тарификация трафика; контроля, статистики, мониторинга сетевой активности пользователей в реальном времени и пользования сетью Интернет и др.

Фильтры по сетевым протоколам пропускают трафик по определенным сетевым протоколам и блокируют трафик других протоколов. Данные средства устанавливаются на границе сети, обеспечивая пропуск только необходимого сетевого трафика по определенным протоколам во внутрь сети и/или во внешнюю сеть, т.е. обеспечивают выполнение сетевых политик.

Контент-фильтры

Контент-фильтры (Content Monitoring and Filtering, CMF) блокируют достиуп к нежелательным контентам сети Интернет. Являются фильтрами веб-трафика (протоколы http/https).

Фильтрация веб-трафика производится по URL-адресам сайтов «черного списка» (URL-фильтры), ключевому слову, сигнатуре или типу файла, по содержимому сайтов с использованием морфологического анализа.Контент-фильтры устанавливаются в сетевых шлюзах (сетевые экраны, прокси сервера и др.) или на рабочих станциях в антивирусах (функция «родительский контроль», для защиты от фишинг-сайтов), персональных firewall и т.д. Могут применяться как отдельные программные средства.

Фильтры веб-трафика (Web Security)

Фильтры веб-трафика (Web Security) используют для защиты веб-приложений от различных видов угроз, поступающих по веб-трафику, в том числе от проникновения вредосного кода. Являются фильтрами веб-трафика (протоколы http/https).Функции фильтрации веб-трафика применяются в таких средствах защиты, как WAF. Для того чтобы защитить от угроз, исходящих по веб-трафику, рекомендуется применять специализированные решения класса Web Security.

Основные функции средств Web Security:

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

Как я уже не раз говорил в своих статьях по брандмауэру Windows в режиме повышенной безопасности, начиная с операционных систем Windows Vista и Windows Server 2008 R2, брандмауэр Windows по умолчанию улучшает безопасность каждого компьютера в организации путем блокировки всего входящего трафика, который не был разрешен явным образом. При установке приложения или компонента операционной системы, которому требуются входящие подключения, операционная система автоматически включает входящие правила брандмауэра и вам, в большинстве случаев, не приходится их конфигурировать вручную. Если вы откроете у себя оснастку непосредственно из панели управления или выполнив команду wf.msc в диалоговом окне «Выполнить» , или в командной строке, то увидите, что у вас уже некоторые правила автоматически включены. Например, это может быть правило, которое автоматически создается с установкой программы Windows Live Messenger или при развертывании роли Hyper-V, как показано на следующей иллюстрации:

Рис. 1. Автоматически воздаваемые правила входящих подключений

Но не во всех случаях правила входящих подключений брандмауэра Windows создаются автоматически. Для некоторых приложений, не создающих правила входящих подключений по умолчанию, вам придется создавать правила вручную. Если такая программа установлена на одном компьютере или на нескольких компьютерах, которые расположены в рабочей группе, вы можете создавать правила непосредственно в оснастке «Брандмауэр Windows в режиме повышенной безопасности» . Но что делать, если компьютеры ваших сотрудников являются членами домена и таких компьютеров десятки, а то и сотни? В таком случае, для применения администратором правил брандмауэра Windows в организации следует воспользоваться групповой политикой, которая предоставляет аналогичный интерфейс.

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

Создание объекта групповой политики для управления брандмауэрами Windows в режиме повышенной безопасности

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

После того как вы выполните все указанные ранее действия, можно заняться созданием входящих и исходящих правил для брандмауэра Windows в режиме повышенной безопасности.

Настройка правила для входящего и исходящего подключения

На этом этапе мы создадим правило для входящих подключений, применяемое к программе Windows Live Messenger на 1900 порт для 64-разрядных операционных систем Windows Vista и Windows 7, а также правило для исходящего подключения, разрешающее запросы от браузера Internet Explorer в объекте групповой политики, который создавался в предыдущем разделе данной статьи. По умолчанию члены локальной группы администраторов также могут создавать и изменять правила для входящих и исходящих подключений в оснастке «Брандмауэр Windows в режиме повышенной безопасности» . Такие правила объединяются с правилами, полученными из групповых политик, и применяются к конфигурации компьютера. Для того чтобы создать правило входящего подключения в созданном ранее объекте групповой политики, выполните следующие действия:

В узле «Объекты групповой политики» оснастки выберите созданный ранее объект GPO, в данном случае, объект «Настройка брандмауэра Windows» , нажмите на нем правой кнопкой мыши «Изменить» ;
В оснастке «Редактор управления групповыми политиками» в дереве консоли разверните узел Конфигурация компьютера\Политики\Конфигурация Windows\Параметры безопасности\Брандмауэр Windows в режиме повышенной безопасности\Брандмауэр Windows в режиме повышенной безопасности\Правила для входящих подключений . Щелкните правой кнопкой мыши элемент «Правила для входящих подключений» и из контекстного меню выберите команду «Создать правило» , как показано на следующей иллюстрации:

Рис. 6. Создание нового правила для входящих подключений

На первой странице «Мастера создания правила для нового входящего подключения» вы можете выбрать одну из опций, которые подробно описаны далее:
- Для программы . Этот тип правила для брандмауэра служит для создания правила, разрешающего или блокирующего подключения конкретного исполняемого файла, независимо от используемых номеров портов. Для большинства людей данный тип правила может оказаться самым полезным, так как далеко не все знают, какие порты использует конкретная программа. Лучше всего в большинстве случаев применять именно этот тип правила, но стоит обратить внимание на то, что данный тип не применяется в том случае, если конкретная служба не содержит собственный исполняемый файл;
- Для порта . Этот тип правила для брандмауэра служит для создания правила, разрешающего или блокирующего коммуникации для определенного TCP или UDP порта, независимо от программы, которая генерирует трафик. Создавая правило данного типа, вы можете указать одновременно несколько портов;
- Предопределённые . Этот тип правила для брандмауэра служит для создания правила, управляющего подключениями конкретной программы или службы операционной системы, которая отображается в соответствующем раскрывающемся списке. Некоторые программы после своей установки добавляют свои записи в данный список для упрощения процесса создания правил для входящих подключений;
- Настраиваемые . Этот тип правила для брандмауэра служит для создания правила, которое может комбинировать сведения о программе и порте одновременно.

Для того чтобы рассмотреть максимальное количество страниц мастера, выберем тип «Настраиваемое правило» ;

Рис. 7. Страница «Тип правила» мастера создания правила для нового входящего подключения

На странице «Программа» мастер создания правила для нового входящего подключения позволяет указать путь к программе, которую будет проверять брандмауэр Windows в режиме повышенной безопасности на то, чтобы посылаемые или принимаемые сетевые пакеты удовлетворяли данному правилу. В нашем случае установим переключатель на опцию «Путь программы» и в соответствующем текстовом поле введем «C:\Program Files (x86)\Windows Live\Messenger\msnmsgr.exe» , как показано ниже:

Рис. 8. Страница «Программа» мастера создания правила для нового входящего подключения

На странице «Протокол и порты» мастера создания правила для нового входящего подключения вы можете указать протокол и порты, используемые в сетевом пакете, которые будут удовлетворять текущему правилу. Если вам нужно указать несколько портов, вы можете их ввести через запятую. А если вам необходимо указать целых диапазон портов, разделите меньшее и большее значение портов дефисом. Вкратце рассмотрим параметры локальных портов для правил входящих подключений:
- Все порты . Правило применяется для всех входящих и исходящих подключений по протоколам TCP или UDP;
- Специальные порты . В данном случае вы можете указать конкретные порты, которые будут применяться для входящего или исходящего подключения по протоколам TCP или UDP;
- Сопоставитель конечных точек RPC . Данное значение можно выбрать только для входящих подключений по протоколу TCP. В данном случае компьютер будет получать входящие RPC-запросы по протоколу TCP через порт 135 в запросе RPC-EM, где указывается сетевая служба и запрашивается номер порта, по которому и прослушивается данная сетевая служба;
- Динамические порты RPC . Также как и для предыдущего значения, данное значение можно выбрать только для входящих подключений по протоколу TCP, где компьютер будет получать входящие сетевые RPC-пакеты через порты, которые назначаются средой выполнения RPC;
- IPHTTPS . Это значение доступно только для входящих подключений по протоколу TCP. В этом случае разрешается принимать входящие пакеты по протоколу туннелирования IPHTTPS, поддерживающему внедрение пакетов IPv6 в сетевые пакеты IPv4 HTTPS от удаленного компьютера;
- Обход узлов . Вы можете выбрать это значение только для входящих подключений по протоколу UDP, которое позволяет получать входящие сетевые пакеты Teredo.

Например, для того чтобы указать для программы Windows Live Messenger TCP порты 80, 443 и 1900, в раскрывающемся списке «Тип протокола» выберите «TCP» , в раскрывающемся списке «Локальный порт» выберите значение «Специальные порты» , а в текстовом поле, расположенном под указанным выше раскрывающемся меню введите «80, 443, 1900» . Оставьте значение раскрывающегося списка «Удаленный порт» без изменений и нажмите на кнопку «Далее» ;

Рис. 9. Страница «Протокол и порты» мастера создания правила для нового входящего подключения

На странице «Область» данного мастера вы можете указать IP-адреса локальных и удаленных компьютеров, сетевой трафик которых будет применяться для текущего правила. Здесь доступны два раздела: локальные и удаленные IP-адреса, к которым будет применяться данное правило. Как в первом, так и во втором разделах, сетевой трафик будет удовлетворять данное правило только в том случае, если IP-адрес назначения присутствует в данном списке. При выборе опции «Любой IP-адрес» , правилу будут удовлетворять сетевые пакеты с любым IP-адресом, которые будут указаны в качестве адреса локального компьютера или которые будут адресованы от любого IP-адреса (в случае с правилом для входящего подключения). Если же вам нужно указать конкретные IP-адреса, установите переключатель на опцию «Указанные IP-адреса» и определенный адрес или подсеть используя диалоговое окно, открывающееся по нажатию на кнопку «Добавить» . В нашем случае, оставим данную страницу без изменений и нажмем на кнопку «Далее» ;

Рис. 10. Страница «Область» мастера создания правила для нового входящего подключения

На странице «Действие» вы можете выбрать действие, которое будет выполняться для входящих или исходящих пакетов в данном правиле. Здесь вы можете выбрать одно из трех следующих действий:
- Разрешить подключение . При выборе данного значения, вы разрешаете все подключения, которые соответствуют критерию, указанному на всех предыдущих страницах мастера;
- Разрешить безопасное подключение . Текущее значение для правила брандмауэра Windows в режиме повышенной безопасности позволяет разрешать подключения только в том случае, если они соответствуют критериям, которые были указаны вами ранее, а также защищены по протоколу IPSec. Не будем останавливаться на данном значении, так как оно будет подробно рассмотрено в моих следующих статьях;
- Блокировать подключение . В этом случае брандмауэр Windows в режиме повышенной безопасности будет сбрасывать любые попытки подключения, которые соответствуют критериям, указанным вами ранее. Несмотря на то, что изначально все подключения блокируются брандмауэром, данное значение целесообразно выбирать в том случае, если вам нужно запретить подключения для конкретного приложения.

Так как нам нужно разрешить доступ для программы Windows Live Messenger, устанавливаем переключатель на опции «Разрешить подключение» и нажимаем на кнопку «Далее» ;

Рис. 11. Страница «Действие» мастера создания правила для нового входящего подключения

На странице «Профиль» мастера создания правила для нового входящего подключения вы можете выбрать профиль, к которому будет применимо данное правило. Вы можете выбрать или один из трех доступных профилей или сразу несколько. Чаще всего для организации выбирается или профиль «Доменный» или все три профиля. Если же в вашей организации не используются доменные службы Active Directory или вы настраиваете правила брандмауэра для домашнего компьютера, вам будет достаточно указать только профиль «Частный» . Правила для профиля «Публичный» создаются для общедоступных подключений, что, в принципе, делать небезопасно. В нашем случае, установим флажки на всех трех профилях и нажмем на кнопку «Далее» ;

Рис. 12. Страница «Профиль» мастера создания правила для нового входящего подключения

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

Рис. 13. Страница «Имя» мастера создания правила для нового входящего подключения

По умолчанию брандмауэр Windows в режиме повышенной безопасности разрешает весь исходящий трафик, что, по сути, подвергает компьютер меньшей угрозе взлома, нежели разрешение входящего трафика. Но, в некоторых случаях, вам необходимо контролировать не только входящий, но еще и исходящих трафик на компьютерах ваших пользователей. Например, такие вредоносные программные продукты как черви и некоторые типы вирусов могут выполнять репликацию самих себя. То есть, если вирус успешно смог идентифицировать компьютер, то он будет пытаться всеми доступными (для себя) способами отправлять исходящий трафик для идентификации других компьютеров данной сети. Таких примеров можно приводить довольно много. Блокирование исходящего трафика обязательно нарушит работу большинства встроенных компонентов операционной системы и установленного программного обеспечения. Поэтому, при включении фильтрации исходящих подключений вам нужно тщательно протестировать каждое установленное на пользовательских компьютерах приложение.

Создание исходящих правил незначительно отличается от указанной выше процедуры. Например, если вы заблокировали на пользовательских компьютерах все исходящие подключение, а вам нужно открыть пользователям доступ на использование браузера Internet Explorer, выполните следующие действия:

Если вам нужно, чтобы правило брандмауэра Windows для исходящего подключения было назначено в новом объекте групповой политике, выполните действия, которые были указаны в разделе «Создание объекта групповой политики для управления брандмауэрами Windows в режиме повышенной безопасности» ;
В оснастке «Редактор управления групповыми политиками» в дереве консоли разверните узел Конфигурация компьютера\Политики\Конфигурация Windows\Параметры безопасности\Брандмауэр Windows в режиме повышенной безопасности\Брандмауэр Windows в режиме повышенной безопасности\Правила для исходящих подключений . Щелкните правой кнопкой мыши элемент «Правила для исходящих подключений» и из контекстного меню выберите команду «Создать правило» ;
На странице мастера «Тип правила» выберите опцию «Для программы» и нажмите на кнопку «Далее» ;
На странице «Программа» , установите переключатель на опцию «Путь программы» и введите в соответствующее текстовое поле %ProgramFiles%\Internet Explorer\iexplore.exe или выберите данный исполняемый файл, нажав на кнопку «Обзор» ;
На странице «Действие» данного мастера выберите опцию «Разрешить подключение» и нажмите на кнопку «Далее» ;
На странице «Профиль» согласитесь со значениями по умолчанию и нажмите на кнопку «Далее» ;
На заключительной странице, странице «Имя» , введите имя для данного правила, например, «Правило для браузера Internet Explorer» и нажмите на кнопку «Готово» .

В области сведений оснастки «Редактор управления групповыми политиками» у вас должно отображаться созданное правило, как показано на следующей иллюстрации:

Рис. 14. Созданное правило для исходящего подключения

Назначение фильтрации для созданного правила

Теперь, после того как вы создали объект групповой политики с входящим и исходящим правилом для подключений, вам нужно обратить внимание на следующий момент. При создании правила для входящего подключения мы указали путь к Windows Live Messenger для 64-разрядной операционной системы. Все ли компьютеры в вашей организации оснащены 64-разрядными операционными системами. Если все, то вам сильно повезло и больше ничего не нужно делать. Но если у вас есть клиентские компьютеры с 32-разрядными ОС, то вы столкнетесь с некой проблемой. Правило просто не будет работать. Конечно, вы можете создать разные подразделения для компьютеров с 32-разрядными и для компьютеров с 64-разрядными операционными системами, но это не совсем рационально. Другими словами, вам нужно указать в оснастке «Управление групповой политикой» , что объект GPO должен применяться только на компьютерах с 64-разрядной операционной системой. Такое ограничение вы можете создать при помощи WMI-фильтра. Более подробно о фильтрации WMI вы узнаете в одной из следующих статей, а сейчас стоит лишь остановиться на создании такого фильтра. Для того чтобы указать WMI-фильтр для определения 64-разрядных операционных систем, выполните следующие действия:

Заключение

В данной статье вы узнали о том, как можно создать правила брандмауэра Windows в режиме повышенной безопасности для входящих и исходящих подключений средствами оснастки «Брандмауэр Windows в режиме повышенной безопасности» , а также при помощи групповых политик для компьютеров организации, которые являются членами домена Active Directory. Описаны предварительные работы, а именно создание подразделения с компьютерами, а также объекта групповой политики. Были рассмотрены примеры создания настраиваемого правила для входящего подключения, а также правило типа «Для программы» для исходящего подключения.