Для ограничения типов подключений и типов пакетов, которые будет пропускать(ACCEPT) или перенаправлять(FORWARD) ваш Firewall, вам необходимо создать правила для межсетевого экрана. Лучшим местом для этого будет таблица Packet , цепочки FORWARD и INCOMING. Если ваш firewall работает в режиме маршрутизатора и вы хотите также защитить вашу сеть с помощью него, вам необходимо обрабатывать FORWARD(проходящие) пакеты. Однако, если вы хотите также защитить сервер, где размещен файрволл, то дополнительно, необходимо внести правила в цепочку INCOMING.
Firewall также позволяет ограничить исходящие пакеты от компьютеров в локальной сети. Для этого вам необходимо добавить правила в цепочку OUTPUT таблицы Packet filtering(Фильтрация пакетов) . Это может быть полезно для ограничения IP адресов хостов и портов, которые открыты наружу.
Для создания нового правила для блокирования трафика, проделайте следующие шаги:
1. На главной странице модуля, выберите Packet filtering из списка и нажмите кнопку Show IPtable(Показать IPtable) . Вы увидите таблицу Packet filtering со всем цепочками в ней.
2. Для добавления правила для всего входящего трафика, нажмите кнопку Add Rule(Добавить правило) в секции Incoming packets(Входящие пакеты) . Если вы хотите ограничить только для проходящего(FORWARD) трафика, то вам необходимо будет нажать на кнопку Add Rule(Добавить правило) в секции Forwarded packets(Проходящие пакеты) . Вам откроется форма для добавления правила, как на рисунке 1.
3. Установите поле Action(Действие) в значение Drop(Отбросить) и тогда пакеты, подходящие это правило будут отброшены.
4. В поле Rule comment(Комментарий к правилу) введите краткое пояснение, для чего предназначено это правило. Это бывает полезным, чтобы не запутаться в правилах.
5. В секции Condition details(Критерии отбора) , определите критерии, соответствие которым будет приводить к отбрасыванию пакета. Только пакеты, подходящие под все определенные вами критерии, будут отброшены.
Некоторые примеры использования критериев для блокирования трафика:
Блокировать все подключения на определенный TCP порт Установите критерий Network protocol(Сетевой протокол) в значение Equals(Равно) и выберите TCP. Для блокировки порта, обязательно должен быть выбран протокол. Установите поле Destination TCP or UDP port(TCP или UDP порт назначение) в значение Equals(Равно) и введите номер порта в поле Port(s). Вы можете блокировать несколько портов, введя их номера через запятую в поле Port(s) или блокировать целые диапазоны выбрав Port range(Диапазон портов) и введя начальное и конечное значения в соответствующие поля.
Блокировать весь трафик с определенных адресов Установите критерий в значение Equals(Равно) и введите IP адрес, который необходимо блокировать. Вы можете блокировать целые сети вводя в диапазон в формате сеть/префикс, типа 192.168.1.0/24 в поле рядом.
Установите Connection state(Статус подключения) в значение Does not equal(Не равно) и выберите Existing connection(Существующее соединение) из выпадающего меню. Это шаг позволит вашей системе подключатся к блокированным адресам, но не наоборот.
Блокировать трафик к определенным адресам Установите критерий Destination address or network(IP адрес назначения или сеть) в значение Equals(Равно ) и введите IP адрес или сеть, которую вы хотите блокировать в поле рядом.
6. Когда вы закончили с созданием условий, нажмите на кнопку Create(Создать) . Если Webmin не выявит ошибок в написании правила, то вас вернет на главную страницу модуля и вы увидите свое новое правило в списке правил.
7. Для того, чтобы активировать новое правило, нажмите на кнопку Apply Configuration(Применить конфигурацию) внизу страницы.
Правила в каждой цепочке срабатывают в порядке - сверху вниз и действие(Action) применяется от того правила, которое сработало первым. Если ни одно правило не отработало, то применяется правило по умолчанию - обычно пропустить(ACCEPT) пакет.
Иногда вам может понадобится добавить правило в середину существующей цепочки. Чтобы это сделать, используйте одну из стрелок под Add column(Добавить столбец) на главной странице модуля, для создания нового правила перед или после уже существующего. Помните, порядок размещения правил, является очень важным.
Наиболее общие действия и их назначения описаны ниже. Не все из них доступны во всех цепочках и таблицах.
Do nothing (Ничего не делать) Собственно, ничего не делать. При этом обработка переходит к следующему правилу.
Accept (Пропустить) Пропустить пакет. Дальнейшая обработка не требуется. Однако правила в других таблицах, могут исключить пакет, даже если он прошел предыдущую таблицу.
Drop (Отбросить) Пакет отбрасывается, как если бы его просто не было. Дальнейшая обработка не требуется.
Userspace (Пользовательская обработка) Пакет поступает на обработку неким локальным процессом(сервером или какой-либо программой). Это действие практически не используется.
Exit (Выход) Переход к концу цепочки и выполнение действия по умолчанию. Если это используется в пользовательской цепочке, обработка вернет пакет к правилу, которое вызвало это действие, так как в пользовательских цепочках не предусмотрено использование действия по умолчанию.
Masquerade (Маскарадинг) У пакетов будет заменен их адрес источника как будто они пришли с системы, где размещен межсетевой экран и дальнейшая обработка будет остановлена. Когда это действие выбрано, вы можете указать Source ports(Порты источника) для поля маскарадинга, с тем, чтобы определить, для каких портов будет применен маскарадинг. Смотри раздел Настройка NAT для более полной информации. Masquerade доступен только в таблице в POSTROUTING цепочке.
Source NAT Схожее с опцией Masquerade, но более предпочтительно для систем имеющих статический IP адрес в Интернет. Если выбрана эта опция, вы можете указать IP адреса и порты в поле SNAT, с тем чтобы определить, для каких портов будет применен NAT. Подробнее, читай в разделе Настройка NAT . Эта опция доступна только в таблице Network address translation(Трансляция сетевых адресов) в цепочке POSTROUTING
Destination NAT У пакетов заменяется их адрес и порт назначения на те, что указаны в поле DNAT. Это основа для прозрачного проксирования. Смотри раздел Настройка прозрачного проксирования для подробностей.
Это действие доступно только в таблице Network address translation в цепочках PREROUTING и OUTPUT.
Redirect (Перенаправление) Это действие перенаправляет все пакеты на порт или порты указанные в поле Target ports for redirect(Порты для редиректа) . Оно также используется для прозрачного проксирования, хотя DNAT более гибкий в этом плане.
Перенаправление доступно только в таблице Network address translation(Трансляция сетевых адресов) в цепочках PREROUTING и OUTPUT.
Вы также можете выбрать действие Run chain(Запуск цепочки), с тем чтобы пакет перешел для обработки в пользовательскую цепочку или было бы выполнено определенное действие. Смотри раздел . Вот некоторые из действий - LOG(для записи в журнал syslog), MIRROR(для отправки пакетов отправителю) и MARK(для маркировки пакетов для последующей обработки).
Для каждого критерия доступны опции -
Например, если условие Incoming interface(Входящий интерфейс) установлено в Does not equal(не равно) и выбран eth0, то правило будет срабатывать на все пакеты, пришедшие со всех сетевых интерфейсов, за исключением основного eth0.
Поскольку почти все сетевые протоколы пропускают трафик в двух направлениях, то закрыв входящий трафик с определенных адресов, указав их в критерии Source address or network(IP адрес источника или сеть) , вы закроете и исходящий трафик, ведь ответные пакеты являющиеся частью соединения будут отброшены. То же самое происходит и при блокировке входящих данных на определенный порт используя критерии Destination TCP or UDP port(TCP или UDP порт назначения). Поэтому, хорошей идеей, при создании блокирующих правил устанавливать Connection state(Статус подключения) в значение Does not equal(не равно) Existing connection(Существующее подключение). То есть не блокировать соединения, созданные вашим сервером.
Как вы можете видеть, IPtables позволяет работать с большим количеством критериев, которые могут комбинироваться в сложные правила. Смотри раздел Применяемые критерии для создания Firewall правил для подробностей. Поскольку возможных критериев очень много, Webmin позволяет вам создавать новые правила схожие с уже существующими. Чтобы это сделать, нажмите на существующее правило, чтобы редактировать его. Затем нажмите кнопку Clone rule(Клонировать правило) внизу страницы, чтобы создать новое правило на основе выбранного(существующего).
Для базового понимания работы файрвола, необходимо ознакомиться с понятиями цепочки (chain), состояния соединения (connection state), условия и действия (action).
Цепочки (chain)
При фильтрации трафик, в зависимости от своего предназначения попадает в одну из цепочек (chain) обработки трафика. В фильтре предопределены три основные цепочки:
- input входящий трафик предназначенный для маршрутизатора. Например, когда вы подключаетесь к маршрутизатору при помощи приложения winbox, трафик как раз попадает в эту цепочку.
- output Исходящий трафик. Трафик, создаваемый самим маршрутизатором. Например, если вы выполните команду ping непосредственно с самого маршрутизатора, трафик попадет в эту цепочку.
- forward Трафик, идущий через маршрутизатор. Например, если компьютер из локальной сети, установил соединение с внешним сайтом, данный трафик попадает в цепочку forward .
Таким образом мы видим, что для защиты самого маршрутизатора необходимо использовать цепочку input , а для защиты и фильтрации трафика между сетями необходимо использовать цепочку forward .
Кроме того, администратор имеет возможность создавать свои собственные цепочки обработки трафика, к которым можно обращаться из основных цепочек. Данная возможность будет рассмотрена в дальнейшем.
Состояние соединения (connection state)
Каждое из сетевых соединений MikroTik относит к одному из 4 состояний:
- New - Новое соединение. Пакет, открывающий новое соединение, никак не связанное с уже имеющимися сетевыми соединениями, обрабатываемыми в данный момент маршрутизатором.
- Established - Существующее соединение. Пакет относится у уже установленному соединению, обрабатываемому в данный момент маршрутизатором.
- Related - Связанное соединение. Пакет, который связан с существующим соединением, но не является его частью. Например, пакет, который начинает соединение передачи данных в FTP-сессии (он будет связан с управляющим соединением FTP), или пакет ICMP, содержащий ошибку, отправляемый в ответ на другое соединение.
- Invalid - Маршрутизатор не может соотнести пакет ни с одним из вышеперечисленных состояний соединения.
Исходя из вышеизложенного, мы видим, что хорошим вариантом настройки фильтрации пакетов будет следующий набор условий:
Условие
При прохождении пакета через фильтр, маршрутизатор последовательно проверяет соответствие пакета заданным условиям, начиная от правила, расположенного первым. и последовательно проверяя пакет на соответствие правилам номер два, три и так далее, пока не произойдет одно из двух событий:
- Пакет будет соответствовать заданному условию. При этом сработает соответствующее правило, в котором это условие было задано, после чего обработка пакета будет завершена.
- Закончатся все условия и пакет не будет признан соответствующим ни одному из них. При этом, по умолчанию он будет пропущен дальше.
Исходя из п.2, нельзя не отметить, что есть две стратегии построения фильтра пакетов:
- Нормально открытый файрвол. Данный тип настройки можно определить как «Все разрешено, что не запрещено». При этом мы запрещаем прохождение только некоторых типов трафика. Если пакет не соответствует этим типам - он будет пропущен. Обычно данный тип файрвола характерен для мест, где не предъявляется высоких требований к безопасности пользователей, а трафик может быть самым разнообразным и не поддающимся жесткой квалификации. Такая настройка характерна для операторов связи (Интернет-провайдеров), открытых точек доступа, домашних маршрутизаторов.
- Нормально закрытый файрвол. Данный тип настройки можно определить как «Все запрещено, что не разрешено». При этом разрешается прохождение только определенных типов трафика, а последним правилом в файрволе стоит правило, запрещающее прохождение любого типа трафика. Такой тип настройки файрвола характерен для корпоративного использования, где существуют жесткие требования к безопасности.
Не могу сказать, что какая-то из стратегий является правильной, а какая-то неправильной. Обе стратегии имеют право на жизнь, но каждая — в определенных условиях.
Теперь подробнее распишем все варианты условий, на основании которых мы можем принимать решение о действии.
Закладка general
|
Наименование |
Описание |
|
Цепочка (см. выше). Если ввести свое название - получим свою цепочку. |
|
|
Адрес источника пакета. Варианты заполнения поля: Один адрес. Например, 192.168.0.5 Подсеть. Например, 192.168.0.0/24 Диапазон адресов. Например, 192.168.0.5-192.168.0.15 Обратите внимание: если вам надо задать несвязанный диапазон адресов, то это нельзя сделать в этом поле, но можно сделать через Src. Address List на закладке Advanced |
|
|
Адрес назначения пакета. Варианты заполнения поля см. выше |
|
|
Протокол соединения. TCP, UDP, ICMP и т.п. |
|
|
Порт, с которого пришел пакет. Поле можно заполнить только если протокол соответствует TCP или UDP. Один порт. Например, 22. Диапазон портов. Например, 10000-20000. Несколько портов. Например,22,23,25. Несколько диапазонов портов. Например, 5060-5070,10000-20000 . Диапазон и несколько портов. Например, 22,23,10000-20000. |
|
|
Порт, на который пришел пакет. Поле можно заполнить, только если протокол соответствует TCP или UDP. |
|
|
Любой порт. Например, или Src. Port, или Dst. Port |
|
|
Peer-to-Peer протокол. Пакет относится к одному из P2P протоколов. Например, edonkey или BitTorrent. |
|
|
Интерфейс, с которого пришел проверяемый пакет. (Не работает, если chain=output, т.к. источник трафика - сам маршрутизатор) |
|
|
Интерфейс, куда будет передан пакет. (Не работает, если chain=input, так как трафик предназначен для маршрутизатора и дальше передан быть не может). |
|
|
Пакет имеет определенную маркировку, полученную ранее через Mangle. |
|
|
Пакет имеет определенную маркировку, полученную ранее через Mangle. |
|
|
Пакет относится к определенному типу соединения, включенному на закладке Firewall/Service Ports |
|
|
Connection State |
Состояние соединения. Описывалось выше. |
Обратите внимание, что перед частью полей можно поставить флаг восклицательного знака. Этот флаг будет обозначать отрицание. Например:
обозначает что адрес источника любой, кроме 192.168.0.0/24 . Также обратите внимание, что если поле не заполнено, оно должно быть серым. Если вы передумали заполнять поле, чтобы его исключить и сделать серым - нажмите стрелку «вверх», справа от поля.
Закладка Advanced
На этой закладке собраны расширенные опции выбора пакета.
|
Наименование |
Описание |
|
Src. Address List |
Адрес источника пакета совпадает с одним из адресов в именованном списке адресов, заданном на закладке Firewall/Address Lists. |
|
Dst. Address List |
Адрес назначения пакета совпадает с одним из адресов в именованном списке адресов, заданном на закладке Firewall/Address Lists. |
|
Layer 7 Protocol |
При проверке пакета L7-фильтром, заданным на закладке Firewall/Layer 7 Protocols, он был отнесен к одному из определенных на этой закладке протоколов. |
|
Внутри пакета содержится определенная строка символов. |
|
|
Connection Bytes |
Количество байт, прошедших через соединение. При этом 0 обозначает бесконечность. Например, 1000000-0 = более 1МБ. |
|
Connection Rates |
Скорость соединения. Например, 0-128000. Это правило сработает, если скорость подключения менее 128 килобит в секунду. (Поставив флаг [!] перед таким правилом, мы заставим срабатывать правило на соединение более 128kbps) |
|
Per Connection Classifier |
|
|
Src. MAC Address |
MAC-адрес сетевой карты источника. Сработает, только если источник пакета находится в одном Ethernet-сегменте с маршрутизатором. |
|
Порт назначения интерфейса типа bridge, при активированной в Bridge опции Use IP Firewall. |
|
|
Порт источника интерфейса типа bridge, при активированной в Bridge опции Use IP Firewall. |
|
|
Ingress Priority |
Приоритет пакета. Может быть получен из VLAN, WMM или MPLS ext. bit |
|
Определяет DSCP, заданный в заголовке пакета. |
|
|
Размер MSS (Maximum segment size) TCP пакета. |
|
|
Размер пакета. |
|
|
Случайное срабатывание правила. Число задается в диапазоне 1-99, что соответствует вероятности срабатывания правила от 1 до 99 процентов. Обычно используется при тестировании сервисов, когда надо изобразить случайную потерю пакетов на нестабильном канале. |
|
|
Флаги TCP соединения. |
|
|
Опции (типы сообщения) ICMP. |
|
|
В заголовке пакета имеется заданная опция протокола Ipv4. |
|
|
Time To Live - Время жизни пакета соответствует … |
Закладка Extra
Эта закладка продолжает список расширенных опций, не поместившихся на закладку Advanced.
|
Наименование |
Описание |
|
Connection Limit |
Предел количества соединений для адреса или подсети. Адрес или подсеть задается полем netmask (для 1 адреса 32). |
|
Предназначено для ограничения количества передаваемых пакетов: Rate - количество пакетов в секунду (минуту/час). Burst - Количество неучитываемых пакетов (пакетов не входящих в packet rate). |
|
|
Ограничение количества передаваемых пакетов по адресу источника/назначения. В отличии от limit, учитываются пакеты для каждого адреса или адреса/порта в зависимости от выбранных опций. Дополнительный поля: Limit By - по какому критерию (src|dst address | address/port) учитывать пакеты. Expire - через какой промежуток времени запомненный адрес/порт будут удалены. |
|
|
Каждый из: Every - из какого числа пакетов. Packet - сколько. Например Every=3, packet=2 Обозначает «Каждые 2 из 3 пакетов или проще 2/3 пакетов). |
|
|
Время действия правила. Позволяет ограничить действие правила во времени и по дням недели. Так как у маршрутизатора нет аппаратно-независимых часов, для корректной работы опции требуется настроенный SNTP-клиент (System/SNTP-Client) и часовой пояс (System/Clock) |
|
|
Src. Address Type |
Тип IP-адреса источника (Local, Unicast, Broadcast, Multicast) |
|
Dst. Address Type |
Тип IP-адреса назначения (Local, Unicast, Broadcast, Multicast) |
|
Port Scan Detect. Опция позволяющая настроить определение события сканирования портов. Поля: Weight Threshold = При каком значении сработает. Delay Threshold = Максимальная задержка между пакетами с разными портами назначения, пришедшими с одного адреса. Low Port Weight = сколько при подсчете стоит каждый порт в диапазоне 0-1023. High Port Weight = сколько при подсчете стоит каждый порт в диапазоне 1024-65535. Например, на скриншоте правило сработает, если будет просканировано 7 и более портов в привилегированном диапазоне; Или 21 и более портов в непривилегированном диапазоне. При этом пауза между поступающими пакетами с одного источника, направленного на разные порты будет не более 3 секунд. |
|
|
Опции, связанные с работой хотспот, если он настроен на маршрутизаторе. |
|
|
Пакет является фрагментом другого пакета. |
Как мы видим, в маршрутизаторе существует достаточно большое количество правил выбора пакетов, которые позволяют очень гибко и тонко настраивать работы с трафиком.
Теперь, когда мы поняли, на основании каких правил мы можем найти интересующий нас пакет, давайте посмотрим, что можно сделать после срабатывания правила.
При отсутствии гибкой фильтрации доступа к сети Интернет на долю ненужных и опасных сайтов, ежедневно посещаемых сотрудниками, приходится чуть ли не половина общего трафика.
Лидерами в списке нежелательных ресурсов являются социальные сети, порталы, выкладывающие контент непристойного содержания, серверы онлайновых игр, а также сайты, генерирующие так называемый "тяжелый" трафик и предлагающие посетителям загружать и просматривать видеоролики и флэш-баннеры.
Потенциальные угрозы, возникающие в результате посещения сотрудниками различных не относящихся к выполняемой ими работе сайтов, помимо нецелевого использования рабочего времени, могут выглядеть как:
- чрезмерная нагрузка на сеть, вызванная неконтролируемым скачиванием сотрудниками объемных файлов из Интернет-сети. В случае, когда речь идет о постоянном или выделенном подключении с фиксированной скоростью канала от провайдера, просмотр или загрузка пользователями видеофайлов негативно скажется на распределении ресурсов сети и загрузке Интернет-канала в целом, а также на стоимости нецелевого трафика;
- нерациональное использование ресурсов сети и рабочего времени в результате деятельности любителей онлайновых игр с видео- или голосовыми чатами;
- неконтролируемые удаленные соединения сотрудников с рабочими серверами корпоративных сетей посредством VPN-соединений или утилит, связанные с риском заражения локальной сети вирусами, потенциально находящимися на удаленном компьютере;
- снижение уровня безопасности корпоративной сети.
Чтобы обеспечить безопасность и целостность бизнеса, перекрыть каналы возможной утечки информации и повысить производительность работы сотрудников, необходимо управлять потоком Интернет-трафика, входящего в локальную сеть при помощи фильтрации Интернет-запросов. Запрещая при помощи настройки фильтров доступ к тем или иным ресурсам, можно решить вопросы снижения затрат на нецелевые Интернет-ресурсы, а также значительно уменьшить риск инфицирования внутренних ресурсов корпоративной сети.
Применение фильтрации в межсетевых экранах NetDefend D-Link рассмотрено в разделе "Функции IDP, WCF, AV" ("Фильтрация Web-содержимого (WCF)").
Виртуальные локальные сети VLAN
VLAN (Virtual Local Area Network – виртуальная локальная сеть). Виртуальной локальной сетью называется логическая группа устройств, имеющих возможность взаимодействовать между собой напрямую на канальном уровне, хотя физически при этом они могут быть подключены к разным сетевым коммутаторам. И наоборот, трафик устройств, находящихся в разных VLAN’ах, полностью изолирован от других узлов сети на канальном уровне, даже если они подключены к одному коммутатору. Это означает, что передача кадров между разными виртуальными сетями на основании MAC-адреса невозможна, независимо от типа адреса – уникального, группового или широковещательного.
VLAN’ы обладают следующими преимуществами:
- гибкость внедрения – VLAN являются эффективным способом группировки сетевых пользователей в виртуальные рабочие группы, несмотря на их физическое размещение в сети;
- применение VLAN обеспечивает возможность контроля широковещательных сообщений, что увеличивает полосу пропускания, доступную для пользователя;
- применение VLAN позволяет повысить безопасность сети, определив с помощью фильтров, настроенных на коммутаторе или маршрутизаторе, политику взаимодействия пользователей из разных виртуальных сетей;
В системе NetDefendOS виртуальная локальная сеть может поддерживать один или несколько VLAN-интерфейсов, которые связаны с конкретным физическим интерфейсом. В межсетевых экранах NetDefend VLAN-интерфейсы рассматриваются как логические интерфейсы и могут обращаться к другим интерфейсам NetDefendOS с помощью наборов правил и таблиц маршрутизации. Виртуальные локальные сети, настроенные в межсетевых экранах серии DFL-xxx, функционируют на уровне L3.
VLAN применяется в нескольких случаях. Обычное применение – когда один Ethernet-интерфейс представлен как несколько интерфейсов. Это означает, что число физических Ethernet-портов на межсетевых экранах NetDefend не ограничивается числом соединений внешних сетей.
Виртуальные локальные сети также используются для группировки отдельных пользователей таким образом, чтобы их трафик был полностью отделен от других виртуальных локальных сетей. Под управлением NetDefendOS трафик может проходить между различными VLAN’ами и фильтроваться с помощью политик безопасности, предусмотренными правилами системы NetDefendOS.
Конфигурация VLAN системы NetDefendOS включает в себя комбинацию VLAN-каналов (trunk) от межсетевых экранов NetDefend до коммутаторов, интерфейсы которых настроены, как VLAN на основе портов (port based VLANs). Любой физический интерфейс межсетевого экрана может одновременно пропускать оба трафика – VLAN-трафик для одного или нескольких виртуальных локальных сетей и не- VLAN-трафик.
NetDefendOS полностью поддерживает стандарт IEEE 802.1Q для виртуальных локальных сетей, которые функционируют, добавляя к заголовку Ethernet-кадра идентификатор виртуальной локальной сети (VLAN ID). VLAN ID – это число от 0 до 4095, используемое для идентификации виртуальной локальной сети, которой принадлежит каждый фрейм. С применением такого механизма Ethernet-фреймы могут принадлежать разным виртуальным локальным сетям и при этом совместно использовать один физический интерфейс. В NetDefendOS одному физическому интерфейсу может назначаться уникальный VLAN ID и тот же самый VLAN ID может быть назначен другим физическим интерфейсам, т.е. одна и та же виртуальная сеть позволяет объединить компьютеры пользователей, подключенных к разным физическим интерфейсам (на рис. 6.1 – VLAN1 и VLAN2).
Рис.
6.1.
Один или несколько VLAN’ов настроены на физический интерфейс межсетевого экрана NetDefend и соединяются прямо с коммутатором. Это соединение работает как VLAN-канал (trunk). Коммутатор должен поддерживать тип port based VLANs. Конфигурация порта коммутатора, который соединяется с межсетевым экраном, должна быть настроена на прием VLAN ID, которые будут передаваться через VLAN-каналы (trunk).
Так же как в проводной локальной сети представлена возможность использования VLAN’ов, так и в беспроводной сети существуют механизмы разграничения беспроводных клиентов.
Виртуальные частные сети (VPN)
Интернет все чаще используется в качестве средства коммуникации между компьютерами, поскольку он предлагает эффективную и недорогую связь. Однако Интернет является сетью общего пользования и для того чтобы обеспечивать безопасную коммуникацию через него необходим некий механизм, удовлетворяющий как минимум следующим задачам:
- конфиденциальность информации;
- целостность данных;
- доступность информации;
Этим требованиям удовлетворяет механизм, названный VPN (Virtual Private Network – виртуальная частная сеть) – обобщённое название технологий, позволяющих обеспечить одно или несколько сетевых соединений (логическую сеть) поверх другой сети (например, Интернет) с использованием средств криптографии (шифрования, аутентификации, инфраструктуры открытых ключей, средств для защиты от повторов и изменений передаваемых по логической сети сообщений).
Создание VPN не требует дополнительных инвестиций и позволяет отказаться от использования выделенных линий. В зависимости от применяемых протоколов и назначения, VPN может обеспечивать соединения трёх видов: хост-хост, хост-сеть и сеть-сеть .
Для наглядности представим следующий пример: предприятие имеет несколько территориально отдаленных филиалов и "мобильных" сотрудников, работающих дома или в разъезде. Необходимо объединить всех сотрудников предприятия в единую сеть. Самый простой способ – это поставить модемы в каждом филиале и организовывать связь по мере необходимости. Такое решение, однако, не всегда удобно и выгодно – порой нужна постоянная связь и большая пропускная способность. Для этого придется либо прокладывать выделенную линию между филиалами, либо арендовать их. И то и другое довольно дорого. И здесь в качестве альтернативы при построении единой защищенной сети можно применять VPN-подключения всех филиалов фирмы через Интернет и настройку VPN-средств на хостах сети.
Рис. 6.5.
В этом случае решаются многие проблемы – филиалы могут располагаться где угодно по всему миру.
Опасность здесь заключается в том, что, во-первых, открытая сеть доступна для атак со стороны злоумышленников всего мира. Во-вторых, по Интернету все данные передаются в открытом виде, и злоумышленники, взломав сеть, будут обладать всей информацией, передаваемой по сети. И, в-третьих, данные могут быть не только перехвачены, но и заменены в процессе передачи через сеть. Злоумышленник может, например, нарушить целостность баз данных, действуя от имени клиентов одного из доверенных филиалов.
Чтобы этого не произошло, в решениях VPN используются такие средства, как шифрование данных для обеспечения целостности и конфиденциальности, аутентификация и авторизация для проверки прав пользователя и разрешения доступа к виртуальной частной сети.
VPN-соединение всегда состоит из канала типа точка-точка, также известного под названием туннель . Туннель создаётся в незащищённой сети, в качестве которой чаще всего выступает Интернет.
Туннелирование (tunneling) или инкапсуляция (encapsulation) – это способ передачи полезной информации через промежуточную сеть. Такой информацией могут быть кадры (или пакеты) другого протокола. При инкапсуляции кадр не передается в том виде, в котором он был сгенерирован хостом-отправителем, а снабжается дополнительным заголовком, содержащим информацию о маршруте, позволяющую инкапсулированным пакетам проходить через промежуточную сеть (Интернет). На конце туннеля кадры деинкапсулируются и передаются получателю. Как правило, туннель создается двумя пограничными устройствами, размещенными в точках входа в публичную сеть. Одним из явных достоинств туннелирования является то, что данная технология позволяет зашифровать исходный пакет целиком, включая заголовок, в котором могут находиться данные, содержащие информацию, которую злоумышленники используют для взлома сети (например, IP-адреса, количество подсетей и т.д.).
Хотя VPN-туннель устанавливается между двумя точками, каждый узел может устанавливать дополнительные туннели с другими узлами. Для примера, когда трём удалённым станциям необходимо связаться с одним и тем же офисом, будет создано три отдельных VPN-туннеля к этому офису. Для всех туннелей узел на стороне офиса может быть одним и тем же. Это возможно благодаря тому, что узел может шифровать и расшифровывать данные от имени всей сети, как это показано на рисунке:
Пользователь устанавливает соединение с VPN-шлюзом, после чего пользователю открывается доступ к внутренней сети.
Внутри частной сети самого шифрования не происходит. Причина в том, что эта часть сети считается безопасной и находящейся под непосредственным контролем в противоположность Интернету. Это справедливо и при соединении офисов с помощью VPN-шлюзов. Таким образом, гарантируется шифрование только той информации, которая передаётся по небезопасному каналу между офисами.
Существует множество различных решений для построения виртуальных частных сетей. Наиболее известные и широко используемые протоколы – это:
- PPTP (Point-to-Point Tunneling Protocol) – этот протокол стал достаточно популярен благодаря его включению в операционные системы фирмы Microsoft.
- L2TP (Layer-2 Tunneling Protocol) – сочетает в себе протокол L2F (Layer 2 Forwarding) и протокол PPTP. Как правило, используется в паре с IPSec.
- IPSec (Internet Protocol Security) – официальный Интернет-стандарт, разработан сообществом IETF (Internet Engineering Task Force).
Перечисленные протоколы поддерживаются устройствами D-Link.
Протокол PPTP, в первую очередь, предназначен для виртуальных частных сетей, основанных на коммутируемых соединениях. Протокол позволяет организовать удаленный доступ, благодаря чему пользователи могут устанавливать коммутируемые соединения с Интернет-провайдерами и создавать защищенный туннель к своим корпоративным сетям. В отличие от IPSec, протокол PPTP изначально не предназначался для организации туннелей между локальными сетями. PPTP расширяет возможности PPP – протокола, расположенного на канальном уровне, который первоначально был разработан для инкапсуляции данных и их доставки по соединениям типа точка-точка.
Протокол PPTP позволяет создавать защищенные каналы для обмена данными по различным протоколам – IP, IPX, NetBEUI и др. Данные этих протоколов упаковываются в кадры PPP, инкапсулируются с помощью протокола PPTP в пакеты протокола IP. Далее они переносятся с помощью IP в зашифрованном виде через любую сеть TCP/IP. Принимающий узел извлекает из пакетов IP кадры PPP, а затем обрабатывает их стандартным способом, т.е. извлекает из кадра PPP пакет IP, IPX или NetBEUI и отправляет его по локальной сети. Таким образом, протокол PPTP создает соединение точка-точка в сети и по созданному защищенному каналу передает данные. Основное преимущество таких инкапсулирующих протоколов, как PPTP – это их многопротокольность. Т.е. защита данных на канальном уровне является прозрачной для протоколов сетевого и прикладного уровней. Поэтому, внутри сети в качестве транспорта можно использовать как протокол IP (как в случае VPN, основанного на IPSec), так и любой другой протокол.
В настоящее время за счет легкости реализации протокол PPTP широко используется как для получения надежного защищенного доступа к корпоративной сети, так и для доступа к сетям Интернет-провайдеров, когда клиенту требуется установить PPTP-соединение с Интернет-провайдером для получения доступа в Интернет.
Метод шифрования, применяемый в PPTP, специфицируется на уровне PPP. Обычно в качестве клиента PPP выступает настольный компьютер с операционной системой Microsoft, а в качестве протокола шифрования используется протокол Microsoft Point-to-Point Encryption (MPPE). Данный протокол основывается на стандарте RSA RC4 и поддерживает 40- или 128-разрядное шифрование. Для многих приложений такого уровня шифрования использование данного алгоритма вполне достаточно, хотя он и считается менее надежным, нежели ряд других алгоритмов шифрования, предлагаемых IPSec, в частности, 168-разрядный Triple-Data Encryption Standard (3DES).
Как происходит установление соединения PPTP?
PPTP инкапсулирует пакеты IP для передачи по IP-сети. Клиенты PPTP создают управляющее туннелем соединение, которое обеспечивает работоспособность канала. Этот процесс выполняется на транспортном уровне модели OSI. После создания туннеля компьютер-клиент и сервер начинают обмен служебными пакетами.
В дополнение к управляющему соединению PPTP создается соединение для пересылки данных по туннелю. Инкапсуляция данных перед отправкой в туннель включает два этапа. Сначала создается информационная часть PPP-кадра. Данные проходят сверху вниз, от прикладного уровня OSI до канального. Затем полученные данные отправляются вверх по модели OSI и инкапсулируются протоколами верхних уровней.
Данные с канального уровня достигают транспортного уровня. Однако информация не может быть отправлена по назначению, так как за это отвечает канальный уровень OSI. Поэтому PPTP шифрует поле полезной нагрузки пакета и берет на себя функции второго уровня, обычно принадлежащие PPP, т. е. добавляет к PPTP-пакету PPP-заголовок (header) и окончание (trailer). На этом создание кадра канального уровня заканчивается. Далее, PPTP инкапсулирует PPP-кадр в пакет Generic Routing Encapsulation (GRE), который принадлежит сетевому уровню. GRE инкапсулирует протоколы сетевого уровня, например IP, IPX, чтобы обеспечить возможность их передачи по IP-сетям. Однако применение только GRE-протокола не обеспечит установление сессии и безопасность данных. Для этого используется способность PPTP создавать соединение для управления туннелем. Применение GRE в качестве метода инкапсуляции ограничивает поле действия PPTP только сетями IP.
После того как кадр PPP был инкапсулирован в кадр с заголовком GRE, выполняется инкапсуляция в кадр с IP-заголовком. IP-заголовок содержит адреса отправителя и получателя пакета. В заключение PPTP добавляет PPP заголовок и окончание.
На рис. 6.7 показана структура данных для пересылки по туннелю PPTP:
Для организации VPN на основе PPTP не требуется больших затрат и сложных настроек: достаточно установить в центральном офисе сервер PPTP (решения PPTP существуют как для Windows, так и для Linux платформ), а на клиентских компьютерах выполнить необходимые настройки. Если же нужно объединить несколько филиалов, то вместо настройки PPTP на всех клиентских станциях лучше воспользоваться Интернет-маршрутизатором или межсетевым экраном с поддержкой PPTP: настройки осуществляются только на пограничном маршрутизаторе (межсетевом экране), подключенном к Интернету, для пользователей все абсолютно прозрачно. Примером таких устройств могут служить многофункциональные Интернет-маршрутизаторы серии DIR/DSR и межсетевые экраны серии DFL.
GRE-туннели
Generic Routing Encapsulation (GRE) – протокол инкапсуляции сетевых пакетов, обеспечивающий туннелирование трафика через сети без шифрования. Примеры использования GRE:
- передача трафика (в том числе широковещательного) через оборудование, не поддерживающее определенный протокол;
- туннелирование IPv6-трафика через сеть IPv4;
- передача данных через публичные сети для реализации защищенного VPN-соединения.
Рис. 6.8.
Между двумя маршрутизаторами A и B ( рис. 6.8) находится несколько маршрутизаторов, GRE-туннель позволяет обеспечить соединение между локальными сетями 192.168.1.0/24 и 192.168.3.0/24 так, как если бы маршрутизаторы A и B были подключены напрямую.
Протокол L2TP появился в результате объединения протоколов PPTP и L2F. Главное достоинство протокола L2TP в том, что он позволяет создавать туннель не только в сетях IP, но и в сетях ATM, X.25 и Frame relay. L2TP применяет в качестве транспорта протокол UDP и использует одинаковый формат сообщений как для управления туннелем, так и для пересылки данных.
Как и в случае с PPTP, L2TP начинает сборку пакета для передачи в туннель с того, что к полю информационных данных PPP добавляется сначала заголовок PPP, затем заголовок L2TP. Полученный таким образом пакет инкапсулируется UDP. В зависимости от выбранного типа политики безопасности IPSec, L2TP может шифровать UDP-сообщения и добавлять к ним заголовок и окончание Encapsulating Security Payload (ESP), а также окончание IPSec Authentication (см. в разделе "L2TP over IPSec"). Затем производится инкапсуляция в IP. Добавляется IP-заголовок, содержащий адреса отправителя и получателя. В завершение L2TP выполняет вторую PPP-инкапсуляцию для подготовки данных к передаче. На рис. 6.9 показана структура данных для пересылки по туннелю L2TP.
Компьютер-получатель принимает данные, обрабатывает заголовок и окончание PPP, убирает заголовок IP. При помощи IPSec Authentication проводится аутентификация информационного поля IP, а ESP-заголовок IPSec помогает расшифровать пакет.
Далее компьютер обрабатывает заголовок UDP и использует заголовок L2TP для идентификации туннеля. Пакет PPP теперь содержит только полезные данные, которые обрабатываются или пересылаются указанному получателю.
IPsec (сокращение от IP Security) – набор протоколов для обеспечения защиты данных, передаваемых по межсетевому протоколу IP, позволяет осуществлять подтверждение подлинности и/или шифрование IP-пакетов. IPsec также включает в себя протоколы для защищённого обмена ключами в сети Интернет.
Безопасность IPSec достигается за счёт дополнительных протоколов, добавляющих к IP-пакету собственные заголовки – инкапсуляции. Т.к. IPSec – стандарт Интернет, то для него существуют документы RFC:
- RFC 2401 (Security Architecture for the Internet Protocol) – архитектура защиты для протокола IP.
- RFC 2402 (IP Authentication header) – аутентификационный заголовок IP.
- RFC 2403 (The Use of HMAC-MD5-96 within ESP and AH) - использование алгоритма хэширования MD-5 для создания аутентификационного заголовка.
- RFC 2404 (The Use of HMAC-SHA-1-96 within ESP and AH) – использование алгоритма хэширования SHA-1 для создания аутентификационного заголовка.
- RFC 2405 (The ESP DES-CBC Cipher Algorithm With Explicit IV) – использование алгоритма шифрования DES.
- RFC 2406 (IP Encapsulating Security Payload (ESP)) – шифрование данных.
- RFC 2407 (The Internet IP Security Domain of Interpretation for ISAKMP) – область применения протокола управления ключами.
- RFC 2408 (Internet Security Association and Key Management Protocol (ISAKMP)) – управление ключами и аутентификаторами защищенных соединений.
- RFC 2409 (The Internet Key Exchange (IKE)) – обмен ключами.
- RFC 2410 (The NULL Encryption Algorithm and Its Use With IPsec) – нулевой алгоритм шифрования и его использование.
- RFC 2411 (IP Security Document Roadmap) – дальнейшее развитие стандарта.
- RFC 2412 (The OAKLEY Key Determination Protocol) – проверка аутентичности ключа.
IPsec является неотъемлемой частью Интернет-протокола IPv6 и необязательным расширением версии Интернет-протокола IPv4.
Механизм IPSec решает следующие задачи:
- аутентификацию пользователей или компьютеров при инициализации защищенного канала;
- шифрование и аутентификацию данных, передаваемых между конечными точками защищенного канала;
- автоматическое снабжение конечных точек канала секретными ключами, необходимыми для работы протоколов аутентификации и шифрования данных.
Компоненты IPSec
Протокол AH (Authentication Header) – протокол идентификации заголовка. Обеспечивает целостность путём проверки того, что ни один бит в защищаемой части пакета не был изменён во время передачи. Но использование AH может вызвать проблемы, например, при прохождении пакета через NAT устройство. NAT меняет IP-адрес пакета, чтобы разрешить доступ в Интернет с закрытого локального адреса. Т.к. пакет в таком случае изменится, то контрольная сумма AH станет неверной (для устранения этой проблемы разработан протокол NAT-Traversal (NAT-T), обеспечивающий передачу ESP через UDP и использующий в своей работе порт UDP 4500). Также стоит отметить, что AH разрабатывался только для обеспечения целостности. Он не гарантирует конфиденциальности путём шифрования содержимого пакета.
Протокол ESP (Encapsulation Security Payload) обеспечивает не только целостность и аутентификацию передаваемых данных, но еще и шифрование данных, а также защиту от ложного воспроизведения пакетов.
Протокол ESP – инкапсулирующий протокол безопасности, который обеспечивает и целостность, и конфиденциальность. В режиме транспорта ESP-заголовок находится между исходным IP-заголовком и заголовком TCP или UDP. В режиме туннеля ESP-заголовок размещается между новым IP-заголовком и полностью зашифрованным исходным IP-пакетом.
Т.к. оба протокола – AH и ESP – добавляют собственные заголовки IP, каждый из них имеет свой номер (ID) протокола, по которому можно определить, что последует за IP-заголовком. Каждый протокол, согласно IANA (Internet Assigned Numbers Authority – организация, ответственная за адресное пространство сети Интернет), имеет свой собственный номер (ID). Например, для TCP этот номер равен 6, а для UDP – 17. Поэтому, очень важно при работе через межсетевой экран настроить фильтры таким образом, чтобы пропускать пакеты с ID AH и/или ESP протокола.
Для того чтобы указать, что в заголовке IP присутствует AH, устанавливается ID протокола 51, а для ESP – номер 50.
ВНИМАНИЕ : ID протокола не то же самое, что номер порта.
Протокол IKE (Internet Key Exchange) – стандартный протокол IPsec, используемый для обеспечения безопасности взаимодействия в виртуальных частных сетях. Предназначение IKE – защищенное согласование и доставка идентифицированного материала для ассоциации безопасности (SA).
SA – это термин IPSec для обозначения соединения. Установленный SA (защищенный канал, называемый "безопасной ассоциацией" или "ассоциацией безопасности" – Security Association, SA) включает в себя разделяемый секретный ключ и набор криптографических алгоритмов.
Протокол IKE выполняет три основные задачи:
- обеспечивает средства аутентификации между двумя конечными точками VPN;
- устанавливает новые связи IPSec (создаёт пару SA);
- управляет существующими связями.
IKE использует UDP-порт с номером 500. При использовании функции NAT Traversal, как упоминалось ранее, протокол IKE использует UDP-порт с номером 4500.
Обмен данными в IKE происходит в 2 фазы. В первой фазе устанавливается ассоциация SA IKE. При этом выполняется аутентификация конечных точек канала и выбираются параметры защиты данных, такие как алгоритм шифрования, сессионный ключ и др.
Во второй фазе SA IKE используется для согласования протокола (обычно IPSec).
При настроенном VPN-туннеле для каждого используемого протокола создаётся одна пара SA. SA создаются парами, т.к. каждая SA – это однонаправленное соединение, а данные необходимо передавать в двух направлениях. Полученные пары SA хранятся на каждом узле.
Так как каждый узел способен устанавливать несколько туннелей с другими узлами, каждый SA имеет уникальный номер, позволяющий определить, к какому узлу он относится. Этот номер называется SPI (Security Parameter Index) или индекс параметра безопасности .
SA храняться в базе данных (БД) SAD (Security Association Database).
Каждый узел IPSec также имеет вторую БД – SPD (Security Policy Database) – БД политики безопасности. Она содержит настроенную политику узла. Большинство VPN-решений разрешают создание нескольких политик с комбинациями подходящих алгоритмов для каждого узла, с которым нужно установить соединение.
Гибкость IPSec состоит в том, что для каждой задачи предлагается несколько способов ее решения, и методы, выбранные для одной задачи, обычно не зависят от методов реализации других задач. Вместе с тем, рабочая группа IETF определила базовый набор поддерживаемых функций и алгоритмов, который должен быть однотипно реализован во всех продуктах, поддерживающих IPSec. Механизмы AH и ESP могут использоваться с различными схемами аутентификации и шифрования, некоторые из которых являются обязательными. Например, в IPSec определяется, что пакеты аутентифицируются либо с помощью односторонней функции MD5, либо с помощью односторонней функции SHA-1, а шифрование осуществляется с использованием алгоритма DES. Производители продуктов, в которых работает IPSec, могут добавлять другие алгоритмы аутентификации и шифрования. Например, некоторые продукты поддерживают такие алгоритмы шифрования, как 3DES, Blowfish, Cast, RC5 и др.
Для шифрования данных в IPSec может быть применен любой симметричный алгоритм шифрования, использующий секретные ключи.
Протоколы защиты передаваемого потока (AH и ESP) могут работать в двух режимах – в транспортном режиме и в режиме туннелирования . При работе в транспортном режиме IPsec работает только с информацией транспортного уровня, т.е. шифруется только поле данных пакета, содержащего протоколы TCP / UDP (заголовок IP-пакета не изменяется (не шифруется)). Транспортный режим, как правило, используется для установления соединения между хостами.
В режиме туннелирования шифруется весь IP-пакет, включая заголовок сетевого уровня. Для того чтобы его можно было передать по сети, он помещается в другой IP-пакет. По существу, это защищённый IP-туннель. Туннельный режим может использоваться для подключения удалённых компьютеров к виртуальной частной сети (схема подключения "хост-сеть") или для организации безопасной передачи данных через открытые каналы связи (например, Интернет) между шлюзами для объединения разных частей виртуальной частной сети (схема подключения "сеть-сеть").
Режимы IPsec не являются взаимоисключающими. На одном и том же узле некоторые SA могут использовать транспортный режим, а другие – туннельный.
На фазе аутентификации вычисляется контрольная сумма ICV (Integrity Check Value) пакета. При этом предполагается, что оба узла знают секретный ключ, который позволяет получателю вычислить ICV и сравнить с результатом, присланным отправителем. Если сравнение ICV прошло успешно, считается, что отправитель пакета аутентифицирован.
В режиме транспорта AH
- весь IP-пакет, за исключением некоторых полей в заголовке IP, которые могут быть изменены при передаче. Эти поля, значения которых для расчета ICV равняются 0, могут быть частью службы (Type of Service, TOS), флагами, смещением фрагмента, временем жизни (TTL), а также заголовком контрольной суммы;
- все поля в AH;
- полезные данные пакетов IP.
AH в режиме транспорта защищает IP-заголовок (за исключением полей, для которых разрешены изменения) и полезные данные в исходном IP-пакете (рисунок 3.39).
В туннельном режиме исходный пакет помещается в новый IP-пакет, и передача данных выполняется на основании заголовка нового IP-пакета.
Для туннельного режима AH при выполнении расчета в контрольную сумму ICV включаются следующие компоненты:
- все поля внешнего заголовка IP, за исключением некоторых полей в заголовке IP, которые могут быть изменены при передаче. Эти поля, значения которых для расчета ICV равняются 0, могут быть частью службы (Type of Service, TOS), флагами, смещением фрагмента, временем жизни (TTL), а также заголовком контрольной суммы;
- все поля AH;
- исходный IP-пакет.
Как видно на следующей иллюстрации, режим туннелирования AH защищает весь исходный IP-пакет за счет дополнительного внешнего заголовка, который в режиме транспорта AH не используется:
В режиме транспорта ESP аутентифицирует не весь пакет, а обеспечивает защиту только полезных данных IP. Заголовок ESP в режиме транспорта ESP добавляется в IP-пакет сразу после заголовка IP, а окончание ESP (ESP Trailer), соответственно, добавляется после данных.
Режим транспорта ESP шифрует следующие части пакета:
- полезные данные IP;
- ESP Trailer.
Алгоритм шифрования, который использует режим шифрования цепочки блоков (Cipher Block Chaining, CBC) имеет незашифрованное поле между заголовком ESP и полезной нагрузкой. Это поле называется вектором инициализации IV (Initialization Vector) для расчета CBC, которое выполняется на получателе. Так как это поле используется для начала процесса расшифровки, оно не может быть зашифрованным. Несмотря на то, что у злоумышленника есть возможность просмотра IV, он никак не сможет расшифровать зашифрованную часть пакета без ключа шифрования. Для предотвращения злоумышленниками изменения вектора инициализации, он охраняется контрольной суммой ICV. В этом случае ICV выполняет следующие расчеты:
- все поля в заголовке ESP;
- полезные данные, включая открытый текст IV;
- все поля в ESP Trailer, за исключением поля данных проверки подлинности.
Туннельный режим ESP инкапсулирует весь исходный IP-пакет в заголовок нового IP, заголовок ESP и ESP Trailer. Для того чтобы указать, что в заголовке IP присутствует ESP, устанавливается идентификатор протокола IP 50, причем исходный заголовок IP и полезные данные остаются без изменений. Как и в случае с туннельным режимом AH, внешний IP-заголовок базируется на конфигурации туннеля IPSec. В случае использования туннельного режима ESP область аутентификации IP-пакета показывает, где была поставлена подпись, удостоверяющая его целостность и подлинность, а зашифрованная часть показывает, что информация является защищенной и конфиденциальной. Исходный заголовок помещается после заголовка ESP. После того, как зашифрованная часть инкапсулируется в новый туннельный заголовок, который не зашифровывается, осуществляется передача IP-пакета. При отправке через общедоступную сеть такой пакет маршрутизируется на IP-адрес шлюза принимающей сети, а уже шлюз расшифровывает пакет и отбрасывает заголовок ESP с использованием исходного заголовка IP для последующей маршрутизации пакета на компьютер, находящийся во внутренней сети. Режим туннелирования ESP шифрует следующие части пакета:
- исходный IP-пакет;
- ESP Trailer.
- Для туннельного режима ESP расчет ICV производится следующим образом:
- все поля в заголовке ESP;
- исходный IP-пакет, включая открытый текст IV;
- все поля заголовка ESP, за исключением поля данных проверки подлинности.
Резюме по применению режимов IPSec:
- Протокол – ESP (AH).
- Режим – туннельный (транспортный).
- Способ обмена ключами – IKE (ручной).
- Режим IKE – main (aggressive).
- Ключ DH – group 5 (group 2, group 1) – номер группы для выбора динамически создаваемых ключей сеанса, длина группы.
- Аутентификация – SHA1 (SHA, MD5).
- Шифрование – DES (3DES, Blowfish, AES).
При создании политики, как правило, возможно создание упорядоченного списка алгоритмов и Diffie-Hellman групп. Diffie-Hellman (DH) – протокол шифрования, используемый для установления общих секретных ключей для IKE, IPSec и PFS (Perfect Forward Secrecy – совершенная прямая секретность). В таком случае будет использована первая позиция, совпавшая на обоих узлах. Очень важно, чтобы всё в политике безопасности позволяло добиться этого совпадения. Если за исключением одной части политики всё остальное совпадает, узлы всё равно не смогут установить VPN-соединение. При настройке VPN-туннеля между различными системами нужно выяснить, какие алгоритмы поддерживаются каждой стороной, чтобы была возможность выбора наиболее безопасной политики из всех возможных.
Основные настройки, которые включает в себя политика безопасности:
- Симметричные алгоритмы для шифрования/дешифрования данных.
- Криптографические контрольные суммы для проверки целостности данных.
- Способ идентификации узла. Самые распространенные способы – это предустановленные ключи (pre-shared secrets) или СА-сертификаты.
- Использовать ли режим туннеля или режим транспорта.
- Какую использовать группу Diffie-Hellman (DH group 1 (768-bit); DH group 2 (1024-bit); DH group 5 (1536-bit)).
- Использовать ли AH, ESP, или оба вместе.
- Использовать ли PFS.
Ограничением IPSec является то, что он поддерживает только передачу данных на уровне протокола IP.
Существуют две основные схемы применения IPSec, отличающиеся ролью узлов, образующих защищенный канал.
В первой схеме защищенный канал образуется между конечными хостами сети. В этой схеме протокол IPSec защищает тот узел, на котором выполняется:
Рис. 6.13.
Во второй схеме защищенный канал устанавливается между двумя шлюзами безопасности. Эти шлюзы принимают данные от конечных хостов, подключенных к сетям, расположенным за шлюзами. Конечные хосты в этом случае не поддерживают протокол IPSec, трафик, направляемый в публичную сеть, проходит через шлюз безопасности, который выполняет защиту от своего имени.
Для хостов, поддерживающих IPSec, возможно использование как транспортного, так и туннельного режимов. Для шлюзов разрешается использование только туннельного режима.
Установка и поддержка VPN
Как упоминалось выше, установка и поддержка VPN-туннеля выполняется в два этапа. На первом этапе (фазе) два узла договариваются о методе идентификации, алгоритме шифрования, хэш-алгоритме и группе Diffie-Hellman. Они также идентифицируют друг друга. Всё это может пройти в результате обмена тремя нешифрованными сообщениями (т.н. агрессивный режим, Aggressive mode ) или шестью сообщениями, с обменом зашифрованной информацией об идентификации (стандартный режим, Main mode ).
В режиме Main Mode обеспечивается возможность согласований всех параметров конфигурации устройств отправителя и получателя, в то время как в режиме Aggressive Mode такой возможности нет, и некоторые параметры (группа Diffie-Hellman, алгоритмы шифрования и аутентификации, PFS) должны быть заранее одинаково настроены на каждом устройстве. Однако, в данном режиме меньше и число обменов, и число пересылаемых при этом пакетов, в результате чего требуется меньше времени для установки сеанса IPSec.
Предполагая, что операция завершилась успешно, создаётся SA первой фазы – Phase 1 SA (также называемый IKE SA ) и процесс переходит ко второй фазе.
На втором этапе генерируются данные ключей, узлы договариваются об используемой политике. Этот режим, также называемый быстрым режимом (Quick mode), отличается от первой фазы тем, что может установиться только после первого этапа, когда все пакеты второй фазы шифруются. Правильное завершение второй фазы приводит к появлению Phase 2 SA или IPSec SA и на этом установка туннеля считается завершённой.
Сначала на узел прибывает пакет с адресом назначения в другой сети, и узел инициирует первую фазу с тем узлом, который отвечает за другую сеть. Допустим, туннель между узлами был успешно установлен и ожидает пакеты. Однако узлам необходимо переидентифицировать друг друга и сравнить политику по прошествие определённого периода времени. Этот период называется время жизни Phase One или IKE SA lifetime .
Узлы также должны сменить ключ для шифрования данных через отрезок времени, который называется временем жизни Phase Two или IPSec SA lifetime .
Phase Two lifetime короче, чем у первой фазы, т.к. ключ необходимо менять чаще. Нужно задать одинаковые параметры времени жизни для обоих узлов. Если не выполнить этого, то возможен вариант, когда изначально туннель будет установлен успешно, но по истечении первого несогласованного промежутка времени жизни связь прервётся. Проблемы могут возникнуть и в том случае, когда время жизни первой фазы меньше аналогичного параметра второй фазы. Если настроенный ранее туннель прекращает работу, то первое, что нуждается в проверке – это время жизни на обоих узлах.
Еще следует отметить, что при смене политики на одном из узлов изменения вступят в силу только при следующем наступлении первой фазы. Чтобы изменения вступили в силу немедленно, надо убрать SA для этого туннеля из базы данных SAD. Это вызовет пересмотр соглашения между узлами с новыми настройками политики безопасности.
Иногда при настройке IPSec-туннеля между оборудованием разных производителей возникают затруднения, связанные с согласованием параметров при установлении первой фазы. Следует обратить внимание на такой параметр, как Local ID – это уникальный идентификатор конечной точки туннеля (отправителя и получателя). Особенно это важно при создании нескольких туннелей и использовании протокола NAT Traversal.
Dead Peer Detection
В процессе работы VPN, при отсутствии трафика между конечными точками туннеля, или при изменении исходных данных удалённого узла (например, смена динамически назначенного IP-адреса), может возникнуть ситуация, когда туннель по сути таковым уже не является, становясь как бы туннелем-призраком. Для того чтобы поддерживать постоянную готовность к обмену данными в созданном IPSec-туннеле, механизм IKE (описанный в RFC 3706) позволяет контролировать наличие трафика от удалённого узла туннеля, и в случае его отсутствия на протяжении установленного времени, посылается hello- сообщение (в межсетевых экранах D-Link посылается сообщение "DPD-R-U-THERE"). При отсутствии ответа на это сообщение в течение определённого времени, в межсетевых экранах D-Link заданного настройками "DPD Expire Time", туннель демонтируется. Межсетевые экраны D-Link после этого, используя настройки "DPD Keep Time" ( рис. 6.18), автоматически пытаются восстановить туннель.
Протокол NAT Traversal
IPsec-трафик может маршрутизироваться по тем же правилам, что и остальные IP-протоколы, но так как маршрутизатор не всегда может извлечь информацию, характерную для протоколов транспортного уровня, то прохождение IPsec через NAT-шлюзы невозможно. Как упоминалось ранее, для решения этой проблемы IETF определила способ инкапсуляции ESP в UDP, получивший название NAT-T (NAT Traversal).
Протокол NAT Traversal инкапсулирует трафик IPSec и одновременно создает пакеты UDP, которые NAT корректно пересылает. Для этого NAT-T помещает дополнительный заголовок UDP перед пакетом IPSec, чтобы он во всей сети обрабатывался как обычный пакет UDP и хост получателя не проводил никаких проверок целостности. После поступления пакета по месту назначения заголовок UDP удаляется, и пакет данных продолжает свой дальнейший путь как инкапсулированный пакет IPSec. Таким образом, с помощью механизма NAT-T возможно установление связи между клиентами IPSec в защищённых сетях и общедоступными хостами IPSec через межсетевые экраны.
При настройке межсетевых экранов D-Link в устройстве-получателе нужно отметить два пункта:
- в полях Remote Network и Remote Endpoint указать сеть и IP-адрес удаленного устройства-отправителя. Необходимо разрешить преобразование IP-адреса инициатора (отправителя) с помощью технологии NAT (рисунок 3.48).
- при использовании общих ключей с несколькими туннелями, подключенными к одному удаленному межсетевому экрану, которые были преобразованы с помощью NAT в один и тот же адрес, важно убедиться в том, что Local ID является уникальным для каждого туннеля.
Local ID может быть одним из:
- Auto – в качестве локального идентификатора используется IP-адрес интерфейса исходящего трафика.
- IP – IP-адрес WAN-порта удаленного межсетевого экрана
- DNS – DNS-адрес
- Email – Email
IPSec в межсетевых экранах D-Link
Межсетевые экраны NetDefend позволяют создавать IPSec-туннели на основе IKE-ключей и сертификатов.
Использование ключей (Pre-Shared Key)
При минимальных настройках для работы VPN-сервера необходимо:
- Создать объекты (в папке Objects
):
- IP-адрес удаленной точки (например, IPSec_remote_endpoint) и удаленной сети (например, IPSec_remote_net);
- ключ Pre-shared Key (Autentication Objects) , объект IKE Algorithms и объект IPSec Algorithms (VPN Objects) . По умолчанию в DFL объекты IKE Algorithms , IPSec Algorithms и алгоритмы шифрования и хеширования уже заданы, но можно изменить или добавить алгоритмы, которые могут быть использованы при обмене ключами (IKE Algorithms) и самом шифровании трафика (IPSec Algorithms).
- Создать IPSec Tunnel (в папке Interfaces ).
- Создать разрешающие правила (в папке IP Rules ) для доступа трафика из туннеля во внутреннюю сеть и обратно.
Использование сертификатов (Certificates)
Сертификаты X.509 базируются на методе шифрования с открытым ключом. Каждый сертификат наряду с другой информацией (сроком действия, именем владельца и т.п.) содержит публичный ключ. Секретный ключ владелец сохраняет в отдельном файле.
Сертификаты подписываются центром Certificate Authority (CA), что позволяет подтвердить подлинность сертификата, информации, содержащейся в сертификате и, в конечном итоге, удаленного хоста. Подлинность CA проверяется в соответствии с его свидетельством, которое является общедоступным.
Сертификаты являются цифровым подтверждением личности и могут быть использованы для аутентификации индивидуальных пользователей или других конечных пользователей. Для установки VPN-туннеля с аутентификацией по сертификатам межсетевому экрану необходимо иметь собственный сертификат и сертификат удаленного межсетевого экрана. Эти сертификаты могут быть либо самоподписанными, либо подписаны центром сертификации (CA).
При установке VPN-туннеля межсетевой экран должен знать, кому он должен доверять. При использовании заранее распределенных ключей все просто. Межсетевой экран доверяет всем, у кого есть такой же ключ. В случае использования сертификатов межсетевой экран должен доверять всем, чей сертификат подписан данным CA. Прежде чем сертификат будет принят, выполняются следующие действия для проверки подлинности сертификата:
- создается путь сертификации к корневому CA, которому доверяют;
- проверяются подписи всех сертификатов в пути сертификации.
Обычно VPN-туннель устанавливается, если сертификат удаленного узла, подписанный CA, представлен в поле Root certificates во вкладке Authentication в меню созданного VPN-туннеля. Однако в некоторых случаях возникает необходимость ограничить тех, кто может устанавливать VPN-туннель даже среди узлов, подписанных тем же CA. Список личностей может быть выбран в поле Identification List Различие этих двух режимов в том, что Aggressive mode передаст большее количество информации в меньшем количестве пакетов (сокращается время соединения (создания IPSec-туннеля)), но он не обеспечивает защиту подлинности.
Криптостойкость алгоритма определяется размером ключа: 1 (768 bit), 2 (1024 bit) или 5 (1536 bit). Размер ключа DH группы 1 равен 768 бит. Размер ключа DH группы 2 равен 1024 бит. Размер ключа DH группы 5 равен 1536 бит. Чем выше группа, тем более криптоскойким становится алгоритм, и тем больше ресурсов процессора он потребляет.
Если функция PFS включена, для каждого согласования на второй фазе будет выполняться новый обмен по протоколу Diffie-Hellman, обеспечивая новые данные для ключей. В результате чего система обладает большей устойчивостью в отношении криптографических атак. Если один ключ будет взломан, другой ключ не сможет быть получен при использовании той же информации. При этом увеличивается загрузка процессора и снижается общая производительность системы.
Disabled – межсетевой экран не будет отправлять идентификатор "vendor ID".
On if supported and NATed – если одно из устройств IPSec-туннеля работает под NAT’ом и DFL сообщает об этом второму устройству, отправляя идентификатор "vendor ID".
On if supported – всегда использовать NAT, когда устанавливается туннель.
Disable – механизм Keep-alive отключен
Auto – межсетевой экран будет отправлять сообщения ping ICMP на IP-адреса, автоматически найденные в параметрах туннеля VPN.
Схема фильтрации шифрованного трафика без раскрытия ключей шифрования.
Часто в дискуссиях мы слышим, что услуга нейтрализации распределённых атак на отказ в обслуживании базирующаяся на постоянной фильтрации трафика, является менее эффективной и более дорогостоящей по сравнению с фильтрацией по-требованию.
Аргументы, использующиеся в подобных диалогах, практически не меняются со временем, когда начинается обсуждение: высокая стоимость постоянной фильтрации против задержки во времени, необходимой на включение специалиста, или оборудования в процесс нейтрализации атаки по требованию.
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 важно иметь хорошо масштабируемое решение, обладающие высокой связностью, чего очень сложно достичь покупая отдельную коробку оборудования.
Когда происходит серьёзная атака, любое отдельно стоящее оборудование будет пытаться сигнализировать в облако о факте её начала и пытаться распределять трафик по фильтрующим точкам. Однако, никто не говорит о том, что когда канал забит мусором нет никакой гарантии, что он сможет доставить данное сообщение до собственного облака. И снова - потребуется время на переключение потока данных.
Поэтому, единственной реальной ценой, которую клиент может заплатить, помимо денежных средств, за защиту собственной инфраструктуры от атак на отказ в обслуживании, является задержка и ничего кроме неё. Но, как мы уже сказали, правильно построенные облака снижают задержки, улучшая глобальную доступность запрашиваемого ресурса.
Имейте это ввиду, делая выбор между железной коробкой и облаком фильтрации.
Для клиентов могут быть применены различные ограничения, причем некоторые могут быть сделаны общими, или для группы, или для всех -
Фильтры.
В программе фильтрация реализуется двумя способами -
Соответственно и фильтры предусмотрены 2-х типов -
По типу действий фильтры могут быть -
В качестве критерия адресов в фильтрах используется понятие "адрес источника" и "адрес назначения".
"Адрес источника" - это хосты внутренней сети. Их явно задавать нельзя, взамен используются данные авторизации. В зависимости от того, относится трафик к авторизованному клиенту или нет, имеются следующие типы фильтров -
В качестве "адреса назначения" могут быть -
| Любой трафик. Кроме трафика на сам сервер. |
Кроме адресов в фильтрах могут быть заданы и другие критерии IP уровня - тип IP протокола, а также TCP/UDP порты со стороны адреса источника и назначения.
DNS преобразование имен в IP адреса для фильтров.
Traffic Inspector имеет уникальную функцию преобразования имен хостов в IP адреса для применения в IP фильтрах. Для работы фильтров в драйвере программы надо задать IP адрес, так как фильтрация идет на уровне IP пакета. Конечно, всегда можно определить IP адрес и задать его в фильтре явно. Но эта функция преобразования имен позволяет в фильтрах задать имя, не заботясь о том, что реальный IP адрес потом может измениться, что бывает довольно часто. Служба преобразования имен будет периодически перепроверять эти имена, поддерживая фильтр в рабочем состоянии. Администратор имеет возможность задать несколько параметров в виде интервалов времени для более тонкой настройки этой службы.
Списки в фильтрах. (Настраивается в Описания \ IP сети)
Для IP фильтров в списке могут быть заданы IP адреса, сети и диапазоны IP адресов. Данные могут быть экспортированы из обычных текстовых файлов описания сетей и поддерживаются различные варианты синтаксиса. Например -
10.0.0.2 - одиночный адрес
10.0.0.0/24 - сеть
10.0.0.0/255.255.255.255 - сеть
10.0.0.0-10.0.0.10 - диапазон адресов
Также в списке для IP фильтров поддерживаются и имена хостов. В этом случае имена через DNS преобразуются в IP адреса.
Для фильтров приложений список представляет собой набор выражений regular expressions (см. далее).
Фильтры приложений.
В фильтрах приложений дополнительно доступны функции на основе анализа HTTP контента -
Более подробно все настройки фильтров описаны в разделе "Администрирование".
Логика применения фильтров и других действий.
По умолчанию для "не клиентов" трафик разрешен -
Также имеется 2 списка фильтров -
Если включен внутренний firewall, то разрешающие фильтры "для всех" на любой адрес назначения на сам сервер трафик не разрешают. Для разрешения доступа на сам сервер надо прописать разрешающий фильтр "на сам сервер", причем в списке такие фильтры надо обязательно поместить выше других разрешающих фильтров. В других случаях порядок фильтров в этих двух списках на логику работы не влияет, но может влиять на производительность - менее ресурсоемкие фильтры следует помещать в начало списка.
Для клиентов при фильтрации применена логика единого списка - разрешающие, запрещающие и другие типы фильтров при анализе пакета обрабатываются последовательно строго в зависимости от их порядка, заданного в списке консоли, причем порядок разных типов фильтров может быть произвольным. Это позволяет реализовать практически любую логику фильтрации и произвольно переопределять параметры.
По умолчанию для клиента трафик наружу разрешен. Но для группы есть возможность по умолчанию трафик и запретить. В таком случае у клиента должны обязательно присутствовать разрешающие фильтры.
Логика просмотра списка следующая. Просмотр идет с начала списка и до первого разрешающего или запрещающего фильтра. Если фильтр содержит параметр, то он применяется только если ранее при просмотре списка он не был применен. Под параметрами здесь понимаются дополнительные действия, задаваемые в фильтре -
Помещение общих фильтров в первый или третий список меняет их приоритет относительно списка группы.
Параметры ограничения скорости, заданные н настройках клиента или группы имеют самый низкий приоритет, т.е. фильтры их всегда переопределяют.
Если включен внутренний firewall, то разрешающие фильтры клиентов на любой адрес назначения на сам сервер трафик не разрешают. Для разрешения доступа на сам сервер для клиентов надо прописать разрешающий фильтр "на сам сервер".
Для клиента, у которого включено "является администратором", внутренний firewall не применяется, а также к нему не применяются фильтры на запрет. Это сделано для исключения ситуации недоступности сервера при удаленном администрировании при ошибках в процессе настройки фильтров. Это распространяется только на IP фильтры, для фильтров приложений запрещающие правила действуют обычным образом.
Если трафик подпадает под условие разрешения его "для всех" (см. выше), то он всегда считается бесплатным и направляется мимо шейпера. Это также относится к любому трафику в пределах внутренних сетей. Данные от сетях тут берутся на основании таблицы маршрутизации.
