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

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

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

• чрезмерная нагрузка на сеть, вызванная неконтролируемым скачиванием сотрудниками объемных файлов из Интернет-сети. В случае, когда речь идет о постоянном или выделенном подключении с фиксированной скоростью канала от провайдера, просмотр или загрузка пользователями видеофайлов негативно скажется на распределении ресурсов сети и загрузке Интернет-канала в целом, а также на стоимости нецелевого трафика;
• нерациональное использование ресурсов сети и рабочего времени в результате деятельности любителей онлайновых игр с видео- или голосовыми чатами;
• неконтролируемые удаленные соединения сотрудников с рабочими серверами корпоративных сетей посредством 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-средств на хостах сети.

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

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

Чтобы этого не произошло, в решениях 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-соединения.

Между двумя маршрутизаторами 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-туннеля между различными системами нужно выяснить, какие алгоритмы поддерживаются каждой стороной, чтобы была возможность выбора наиболее безопасной политики из всех возможных.

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

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

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

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

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

Во второй схеме защищенный канал устанавливается между двумя шлюзами безопасности. Эти шлюзы принимают данные от конечных хостов, подключенных к сетям, расположенным за шлюзами. Конечные хосты в этом случае не поддерживают протокол 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-туннеля)), но он не обеспечивает защиту подлинности.

Схема фильтрации шифрованного трафика без раскрытия ключей шифрования.

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

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

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

Одна из ключевых причин заключается в том, что современные атаки развиваются очень быстро - эволюционируют и усложняются в реальном времени. Эволюционирует и сам сервис - сайт и приложение развиваются, поэтому может оказаться, что «нормальное» поведение пользователей во время предыдущей атаки уже не является актуальным.

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

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

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

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

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

Ещё одним недостатком использования протокола NetFlow в качестве основного инструмента анализа является то, что он даёт лишь некоторую характеристику потоков данных - их описание, но не сами потоки. Поэтому, конечно, вы заметите атаку основываясь на параметрах, которые отражает NetFlow, но более сложные виды атак, которые должны обнаруживаться с помощью анализа содержимого потока, видны не будут. Поэтому атаки на прикладной уровень (L7) сложно отражать используя только NetFlow метрику, за исключением случаев стопроцентной очевидности атаки внутри транспорта (потому что выше L4 NetFlow откровенно бесполезен).

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

Говоря, что обратное проксирование сужает возможности фильтрации только до протоколов HTTP и HTTPS (SSL), вы озвучиваете лишь половину правды. HTTP-трафик является неотъемлемой и одной из критически важных частей сложных систем фильтрации, а обратное проксирование - один из самых эффективных способов осуществлять его сбор и анализ.

2. Как мы знаем, распределённые атаки на отказ в обслуживании могут принимать многие формы и модифицироваться, сдвигаясь от HTTP-протокола. Почему облако в данном случае лучше, чем отдельно стоящее оборудование на стороне у клиента?

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

До атаки невозможно сказать наверняка, что будет проще: вывести из строя отдельно стоящее оборудование (CPE) или узел сети фильтрации. Но подумайте вот о чём - отказ точки всегда является проблемой вашего вендора, а вот кусок оборудования, отказывающийся работать как заявлено, уже после покупки, является только вашей проблемой.

3. Узел сети, выступающий в роли прокси-сервера, должен быть в состоянии получить от ресурса контент и данные. Значит ли это, что любой может обойти облачное решение по нейтрализации атак?

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

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

4. Порой в качестве аргумента против облачной фильтрации используется соотношение стоимости услуги и затрат на неё со стороны поставщика. Как выглядит эта ситуация в сравнении с оборудованием размещённым на стороне клиента?

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

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

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

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

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

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

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

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

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

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

Имейте это ввиду, делая выбор между железной коробкой и облаком фильтрации.

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

Можно предложить и другие способы распределения сеансов по портам. Например, в со­ ответствии с ІР-адресами пакетов, которые инкапсулированы в кадры канального уровня, типами прикладных протоколов (почта по одному порту, веб-трафик по другому и т. д.). Полезным оказывается назначение порту сеансов с МAC-адресами, которые были изучены как идущие именно через этот порт -тогда трафик сеанса пойдет через один и тот же порт в обоих направлениях.

Стандартный способ создания агрегированных каналов, описанный в спецификации 802.3ad, предполагает возможность создания логического порта путем объединения не­ скольких физических портов, принадлежащих разным коммутаторам. Для того чтобы коммутаторы могли автоматически обеспечиваться информацией о принадлежности какого-либо физического порта определенному логическому порту, в спецификации предложен служебный протокол управления агрегированием линий связи (Link Control Aggregation Protocol, LCAP). Поэтому возможны такие конфигурации агрегированных ка­ налов, которые увеличивают отказоустойчивость сети не только на участках между двумя коммутаторами, но и в более сложных топологиях (рис. 14.8).

Агрегированный канал

Рис. 14.8. Распределенное агрегирование каналов

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

Фильтрация трафика

Локальная сеть обеспечивает взаимодействие каждого узла с каждым -это очень полезное свойство, так как не требуется производить никаких специальных действий, чтобы обе­

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

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

Пользовательский фильтр, который также часто вазываютслискомдоступа {access list), предназначендлясозданиядополнительныхбарьеровнаггут кадров, чтопозволяетограничи­ вать доступ определенных групп полЁзовапгелейк Пользовательский

фильтр - это набор условий, которые ограничмваотобычную/югиет передачи кадров комму­ таторами.

Наиболее простыми являются пользовательские фильтры на основе МAC-адресов станций. Так как МАС-адреса -это та информация, с которой работает коммутатор, он позволяет создавать подобные фильтры удобным для администратора способом, возможно, про­ ставляя некоторые условия в дополнительном поле адресной таблицы, например условие отбрасывать кадры с определенным адресом (см. рис. 13.6 в главе 13). Таким способом пользователю, работающему на компьютере с данным МАС-адресом, полностью запре­ щается доступ к ресурсам другого сегмента сети.

Рассмотрим применение пользовательского фильтра на примере сети, показанной на рис. 14.9.

Рис. 14.9. Контрольдоступа к серверу с помощью пользовательского фильтра

Пусть мы хотим разрешить доступ к серверу 51 только с компьютеров С 1 иС 3, кадры от всех остальных компьютеров до этого сервера доходить не должны. Список доступа, ко­ торый решает эту задачу, может выглядеть так:

Числа 10,20 и ЗО -это номера строк данного списка. Строки нумеруются с интервалом 10 для того, чтобы в дальнейшем была возможность добавить в этот список другие записи, сохраняя исходную последовательность строк. Первое условие разрешает (permit) пере­ дачу кадра, если его адрес источника равен МАС-С1, а адрес назначения -МАС-SI; второе условие делает то же, но для кадра с адресом источника МАС-СЗ, третье условие запрещает (deny) передачу кадров с любыми (any) адресами.

Для того чтобы список доступа начал работать, его нужно применить к трафику опреде­ ленного направления на какому-либо порту коммутатора: либо к входящему, либо к ис­ ходящему. В нашем примере нужно применить список доступа к исходящему трафику порта 1 коммутатора SW3, к которому подключен сервер 51. Коммутатор SW3, перед тем как предать кадр на порт 1, будет просматривать условия списка доступа по очереди. Если какое-то условие из списка соблюдается, то коммутатор выполняет действие этого условия для обрабатываемого кадра, и на этом применение списка доступа для данного кадра заканчивается.

Поэтому когда от компьютера С 1 приходит кадр, адресованный серверу 51, то соблюдается первое условие списка, которое разрешает передачу кадра, так что коммутатор выполняет стандартное действие по продвижению кадра, и тот доходит до сервера 52. С кадром от компьютера СЗ совпадение происходит при проверке второго условия, и он также переда­ ется. Однако когда приходят кадры от других компьютеров, например компьютера С2, то ни первое, ни второе условия не соблюдаются, зато соблюдается третье условие, поэтому кадр не передается, а отбрасывается.

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

Иногда администратору требуется задать более тонкие условия фильтрации, например запретить некоторому пользователю печатать свои документы на сервере печати Windows, находящемуся в чужом сегменте, а остальные ресурсы этого сегмента сделать доступными. Для реализации подобного фильтра нужно запретить передачу кадров, которые удовлет­ воряют следующим условиям: во-первых, имеют определенный МАС-адрес, во-вторых, содержат в поле данных пакеты SMB, в-третьих, в соответствующем поле этих пакетов в качестве типа сервиса указана печать. Коммутаторы не анализируют протоколы верх­ них уровней, такие как SMB, поэтому администратору приходится для задания условий фильтрации «вручную» определять поле, по значению которого нужно осуществлять фильтрацию. В качестве признака фильтрации администратор указывает пару «смещениеразмер» относительно начала поля данных кадра канального уровня, а затем еще приводит шестнадцатеричное значение этого поля.

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

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

Важным свойством коммутатора локальной сети является способность контролировать передачу кадров между сегментами сети. По различным причинам (соблюдение прав до­ ступа, политика безопасности и т. д.) некоторые кадры не следует передавать по адресу назначения.

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

Виртуально^ сетью группаузлов сети,

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

Виртуальные локальные сети могут перекрыватьсяу если один или несколько компьютеров входят в состав более чем одной виртуальной сети. На рис. 14.10 сервер электронной почты входит в состав виртуальных сетей 3 и 4. Это означает, что его кадры передаются комму­ таторами всем компьютерам, входящим в эти сети. Если же какой-то компьютер входит в состав только виртуальной сети 3, то его кадры до сети 4 доходить не будут, но он может взаимодействовать с компьютерами сети 4 через общий почтовый сервер. Такая схема защищает виртуальные сети друг от друга не полностью, например, широковещательный шторм, возникший на сервере электронной почты, затопит и сеть 3, и сеть 4.

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

Назначение виртуальных сетей

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

□ Приходится задавать отдельные условия для каждого узла сети , используя при этом громоздкие МАС-адреса. Гораздо проще было бы группировать узлы и описывать усло­ вия взаимодействия сразу для групп.

□ Невозможно блокировать широковещательный трафик Широковещательный трафик может быть причиной недоступности сети, если какой-то ее узел умышленно или неумышленно с большой интенсивностью генерирует широковещательные кадры.

Техника виртуальных локальных сетей решает задачу ограничения взаимодействия узлов сети другим способом.

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

ІО^оіоиногаомзр^снолсншвирту&1ьнЫ*сэт^ запнетсято,чтоонапозволяетсоаддватьпсшностыо изолированныеоегментысетияутемлогическогоконфигурированиякоммутаторов,реприбегая

кизмененик>физиче<жойо^у<1>1>ы.

До появления технологии VLAN для создания отдельной сети использовались либо фи­ зически изолированные сегменты коаксиального кабеля, либо не связанные между собой сегменты, построенные на повторителях и мостах. Затем эти сети связывались маршрути­ заторами в единую составную сеть (рис. 14.11).

Изменение состава сегментов (переход пользователя в другую сеть, дробление крупных сегментов) при таком подходе подразумевает физическую перекоммутацию разъемов на

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

Сегменты на повторителях

Рис. 14.11. Составная сеть, состоящая из сетей, построенных на основе повторителей

Длясвязывания виртуальных сетей в общую сеть требуется привлечение средств сетевого уровня. Он может быть реализован в отдельном маршрутизаторе или в составе программ­ ного обеспечения коммутатора, который тогда становится комбинированным устрой­ ством - так называемым коммутатором 3-го уровня (см. главу 18).

Технология виртуальных сетей долгое время не стандартизировалась, хотя и была реали­ зованав очень широком спектре моделей коммутаторов разных производителей. Положе­ ниеизменилось после принятия в 1998 году стандарта IEEE 802.1Q, который определяет базовые правила построения виртуальных локальных сетей, не зависящие от протокола канального уровня, поддерживаемого коммутатором.

Создание виртуальных сетей на базе одного коммутатора

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

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

Второй способ образования виртуальных сетей основан на группировании МАС-адресов. Каждый МАС-адрес, который изучен коммутатором, приписывается той или иной вир­ туальной сети. При существовании в сети множества узлов этот способ требует от адми­ нистратора большого объема ручной работы. Однако при построении виртуальных сетей

на основе нескольких коммутаторов он оказывается более гибким, чем группирование портов.

Рис. 14.12. Виртуальные сети, построенные на одном коммутаторе

Создание виртуальных сетей на базе нескольких коммутаторов

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

Рис. 14.13. Построение виртуальных сетей на нескольких коммутаторах с группированием портов

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

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

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

Описанные два подхода основаны только на добавлении дополнительной информации к адресным таблицам коммутатора и в них отсутствует возможность встраивания в пере­ даваемый кадр информации о принадлежности кадра виртуальной сети. В остальных подходах используются имеющиеся или дополнительные поля кадра для сохранения информации о принадлежности кадра той или иной виртуальной локальной сети при его перемещениях между коммутаторами сети. При этом"нет необходимости помнить в каждом коммутаторе о принадлежности всех МАС-адресов составной сети виртуальным сетям.

Дополнительное поле с пометкой о номере виртуальной сети используется только тогда, когдакадр передается от коммутатора к коммутатору, а при передаче кадра конечному узлу оно обычно удаляется. При этом модифицируется протокол взаимодействия «коммутаторкоммутатор», а программное и аппаратное обеспечение конечных узлов остается неизмен­ ным. До принятия стандарта IEEE 802.1Q существовало много фирменных протоколов этоготипа, но все они имели один недостаток -оборудование различных производителей при образовании VLAN оказывалось несовместимым.

Этот стандарт вводит в кадре Ethernet дополнительный заголовок, который называется тегом виртуальной локальной сети.

^rrnatlon}- упрадляюадя шшщ** котороеявляется

*Фйс. 14.14. Структура помеченного кадра Ethernet

TerVLANне является обязательным для кадров Ethernet. Кадр, у которого имеется такой заголовок, называют помеченным (tagged frame). Коммутаторы могут одновременно ра­ ботатькак с помеченными, так и с непомеченными кадрами. Из-за добавления тега VLAN максимальная длина поля данных уменьшилась на 4 байта.

Для того чтобы оборудование локальных сетей могло отличать и понимать помеченные кадры, для них введено специальное значение поля EtherType, равное 0x8100. Это значе­ ние говорит о том, что за ним следует поле TCI; а не стандартное поле данных. Обратите внимание, что в помеченном кадре за полями тега VLAN следует другое поле EtherType, указывающее тип протокола, данные которого переносятся полем данных кадра.

В поле TCI находится 12-битное поле номера (идентификатора) VLAN, называемогоVID. Разрядность поля VID позволяет коммутаторам создавать до 4096 виртуальных сетей. Помимо этого в поле TCI помещено 3-битное полеприоритета кадра. Однобитное полеCFI было введено с целью поддержания специального формата кадра Token Ring, для сетей Ethernet оно должно содержать значение 0.

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

Для упрощения конфигурирования сети в стандарте 802.1Q вводятся понятия линии до­ ступа и транка.

^бммутатора (называемый в этом случае портом доступа) Йекйторойвиртуальной локальной сети.

щ соединяет ме*дусобой портыдаух коммутаторов; в общем!

#$фик несколькихвиртуальныхсетей. V ,j

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

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

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

Для более наглядное описания вернемся к рассмотренному ранее примеру сети. На рис. 14.15 показано, как решается задана избирательного доступа к серверам на основе техники VLAN.

VLAN-2

VLAN-3

Рис. 14.15. Разбиение сети на две виртуальные локальные сети

Чтобы решить эту задачу, можно организовать в сети две виртуальные локальные сети, VLAN2 и VLAN3 (напомним, что сеть VLAN1 уже существует по умолчанию -это наша исходная сеть), приписав один набор компьютеров и серверов к VLAN2, а другой - KVLAN3.

Для приписывания конечных узлов к определенной виртуальной локальной сети соот­ ветствующие порты объявляются портами доступа этой сети путем назначения им соот­ ветствующего идентификатора VID. Например, порт 1 коммутатора SW1 должен быть объявлен портом доступа VLAN2 путем назначения ему идентификатора VID2, то же самоедолжно быть проделано с портом 5 коммутатора SW1, портом 1 коммутатора SW2 и портом 1 коммутатора SW3. Порты доступа сети VLAN3 должны получить идентифи­ каторVID3.

В нашей сети нужно также организовать транки -те линии связи, которые соединяют между собой порты, коммутаторов. Порты, подключенные к транкам, не добавляют и не удаляют теги, они просто передают кадры в неизменном виде. В нашем примере такими портамидолжны быть порты 6 коммутаторов SW1 и SW2, а также порты 3 и 4 коммутатора SW3. Порты в нашем примере должны поддерживать сети VLAN2 и VLAN3 (и VLAN1, если всети есть узлы, явно не приписанные ни к одной виртуальной локальной сети).

Коммутаторы, поддерживающие технологию VLAN, осуществляют дополнительную фильтрациютрафика. В том случае если таблица продвижения коммутатора говорит о том, что пришедший кадр цужно передать на некоторый порт, перед передачей коммутатор проверяет, соответствует ли значение VID в теге VLAN кадра той виртуальной локальной сети, которая приписана к этому порту. В случае соответствия кадр передается, несоот­ ветствия -отбрасывается. Непомеченные кадры обрабатываются аналогичным образом, нос использованием условной сети VLAN1. МАС-адреса изучаются коммутаторами сети отдельно по каждой виртуальной локальной сети.

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

Альтернативные маршруты в виртуальных локальных сетях

По умолчанию протокол STP/RSTP образует в сети одно покрывающее дерево для всех виртуальных локальных сетей. Чтобы в сети можно было использовать разные покрываю­ щие деревья для разных виртуальных локальных сетей, существует специальная версия протокола, называемая множественным протоколом покрывающего дерева (Multiple Spanning Tree Protocol, MSTP).

Протокол MSTP позволяет создать несколько покрывающих деревьев и приписывать к ним различные виртуальные локальные сети. Обычно создается небольшое количество деревьев, например два или три, чтобы сбалансировать нагрузку на коммутаторы, в про­

тивном случае, как мы видели в примере на рис. 14.2 и 14.3, единственное покрывающее дерево может полностью оставить без работы некоторые коммутаторы сети, то есть недо­ использует имеющие сетевые ресурсы.

Если вернуться к нашему примеру (см. рис. 14.2), то при создании двух покрывающих деревьев можно сконфигурировать приоритеты коммутаторов так, чтобы для одного дерева корневым коммутатором стал коммутатор 111, а для второго -коммутатор 222 (рис. 14.16).

В этом варианте мы подразумеваем, что порты 4 коммутаторов с 555 по 888 сконфигу­ рированы как порты доступа одной виртуальной локальной сети, например VLAN100,

а порты 3 тех же коммутаторов -как порты доступ»другой виртуальной локальной сети, например VLAN200. Сеть VLAN100 приписана к покрывающему дереву с корневым коммутатором 111, a VLAN200 -к покрывающему дереву с корневым коммутатором 222.

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

Протокол MSTP основан на протоколе RSTP, поэтому обеспечивает быструю реакцию сетина отказы.

Качество обслуживания в виртуальных сетях

Коммутаторы локальных сетей поддерживают практически все механизмы QoS, которые мы обсуждали в главе 7. Это утверждение относится к коммутаторам локальных сетей как к классу коммуникационных устройств, каждая же конкретная модель коммутатора можетбыть наделена только определенным набором механизмов поддержания параметров QoS или же не иметь их вовсе. Как правило, коммутаторы рабочих групп средств QoS не поддерживают, в то время как дл^ магистральных коммутаторов эта поддержка является обязательной.

Классификация трафика

Коммутаторы локальных сетей являются устройствами второго уровня, которые анализи­ руютзаголовки только протоколов канального уровня. Поэтому коммутаторы обычно ис­ пользуютдля классификации трафика только МАС-адреса источника и приемника, а также номер порта, через который поступил кадр. Возможен также учет при классификации значения произвольного подполя внутри поля данных, заданного путем указания смеще­ ния в байтах. Эти способы не очень удобны для администратора, которому необходимо, например, отделить голосовой трафик от трафика передачи файлов. Поэтому некоторые коммутаторы, не поддерживая протоколы верхних уровней в полном объеме (например, не применяя протокол IP для продвижения пакетов), выполняют классификацию на основе признаков, содержащихся в заголовках пакетов этих протоколов -ІР-адресах и портах TCP/UDP

Маркирование трафика

Маркирование трафика обычно выполняется на границе сети, а затем его результаты ис­ пользуются во всех промежуточных устройствах сети. В кадре Ethernet 802.3 отсутствует поле, в которое можно было бы поместить результат маркировки трафика. Однако этот недостаток исправляет спецификация 802.1р, в которой имеются три бита дополнительного заголовка 802.1Q/p для хранения приоритета кадра.

Фактически, эти три бита служат для хранения признака одного из восьми классов тра­ фика. Именно так трактует это поле стандарт 802.1 D-2004, куда вошла спецификация 802.1р. В приложении G стандарта 802.1D-2004 даются рекомендации по разделению всего трафика локальных сетей на семь классов:

□ NC (управление сетью). Управлению сетью дается высший приоритет при обслужива­ нии, так как от своевременного принятия решения и доставки управляющей информа­ ции сетевым устройствам зависят любые характеристики сети.

□ VI (видео). Видеотрафику требуется обеспечить задержу менее 100 мс.

□ CL (контролируемая нагрузка). При применении важных бизнес-приложений требуется некоторая форма контроля допуска (admission control) и резервирование пропускной способности для потока.

□ ЕЕ (улучшенное обслуживание). Это улучшенный вариант обслуживания по возмож­ ности, не дающий никаких гарантий пропускной способности.

□ BE (обслуживание по возможности, или с максимальными усилиями). Стандартное обслуживание в локальных сетях.

□ ВК (фоновый трафик). Наименее чувствительный к задержкам трафик, например тра­ фик резервного копирования, источник которого может передавать большие объемы данных, поэтому его целесообразно выделить в особый класс, чтобы он не замедлял обработку других типов трафика.

Управление очередями

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

Коммутатор обычно поддерживает некоторое максимальное количество очередей, которое может оказаться меньше, чем требуемое число классов трафика. В этой ситуации несколько классов будут обслуживаться одной очередью, то есть фактически сольются в один класс. Стандарт 802.1D-2004 дает рекомендации в отношении того, какие классы трафика нуж­ но реализовывать в сети в условиях ограниченного количества очередей в коммутаторах (табл. 16.1).

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

Две очереди дают возможность дифференцированно обслуживать группы классов трафи­ ка -менее требовательные классы ВК, BE и ЕЕ в одной очереди, а более требовательные классы VO, CL, VI, NC -в другой.

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

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

Резервирование и профилирование

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

Для коммутаторов локальных сетей не существует стандартного протокола резервирования ресурсов. Поэтому для выполнения резервирования администратор сети должен сконфи­ гурировать каждый коммутатор сети отдельно.

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

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

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

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

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

сколько полей требуют проверки на правильность уже на входе в сеть. Очевидно, у каждого поля существует множество значений которое определено в 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

• 169.254.0.0 - 169.254.255.255

• 127.0.0.0 - 127.255.255.255

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

• 192.0.2.0–192.0.2.255

• 224.0.0.0 - 239.255.255.255

• 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 будет выглядеть следующим образом:

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 описана .

Как я уже не раз говорил в своих статьях по брандмауэру 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 в режиме повышенной безопасности» . Такие правила объединяются с правилами, полученными из групповых политик, и применяются к конфигурации компьютера. Для того чтобы создать правило входящего подключения в созданном ранее объекте групповой политики, выполните следующие действия:

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





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

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

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




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

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



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

5. На странице «Протокол и порты» мастера создания правила для нового входящего подключения вы можете указать протокол и порты, используемые в сетевом пакете, которые будут удовлетворять текущему правилу. Если вам нужно указать несколько портов, вы можете их ввести через запятую. А если вам необходимо указать целых диапазон портов, разделите меньшее и большее значение портов дефисом. Вкратце рассмотрим параметры локальных портов для правил входящих подключений:
   • Все порты . Правило применяется для всех входящих и исходящих подключений по протоколам 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. Страница «Протокол и порты» мастера создания правила для нового входящего подключения

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



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

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

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




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

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



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

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



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

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

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

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

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

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

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

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

Заключение

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