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

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

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

Рассмотрим основные понятия, относящиеся к информационной безопасности, и их взаимосвязь.

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

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

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

увеличить изображение

Рис. 1.1. Взаимосвязь основных понятий безопасности информационных систем

Дадим следующие определения:

Уязвимость – слабое место в системе, с использованием которого может быть осуществлена атака.

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

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

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

Механизм безопасности – программное и/или аппаратное средство, которое определяет и/или предотвращает атаку.

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

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

Для создания надежной и безопасной ИТ-инфраструктуры необходимо разработать так называемую "оборону в глубину".

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

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

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

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

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

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

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

1.2 Классификация сетевых атак

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

Рис. 1.2. Информационный поток

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

Несмотря на все многообразие, все сетевые атаки можно разделить на два класса: пассивные и активные.

1.2.1 Пассивная атака

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

В этом случае также говорят, что нарушена конфиденциальность.

Рис. 1.3. Пассивная атака

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

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

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

Сканеры уязвимостей являются специальным типом сканеров, которые проверяют наличие конкретных уязвимостей на хостах. Атакующий может запустить сканер уязвимостей, который определит список хостов (IP-адресов), уязвимых для конкретной атаки.

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

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

1.2.2 Активная атака

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

Отказ в обслуживании – DoS-атака (Denial of Service)

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

DoS-атаки также могут пытаться замедлить или остановить системы или сервисы в целевой сети. Существует два типа DoS-атак: шквальная эксплуатация и наводнение (flooding).

Классическим примером такой атаки в сетях TCP/IP является SYN-атака, при которой нарушитель посылает пакеты, инициирующие установление ТСР-соединения, но не посылает пакеты, завершающие установление этого соединения. В результате на сервере может произойти переполнение таблицы соединений, и серверу не удастся установить соединение с законными пользователями.

Рис. 1.4. DoS-атака

DoDoS-атаки шквальной эксплуатации

Атаки шквальной эксплуатации вызывают "шквал" в ПО целевой системы, что приводит к невозможности обработки запросов законных пользователей или исчерпанию системных ресурсов. Например, результатом "ping of death" атаки является невозможность обработки полученного пакета. Данная атака состоит в отправке очень большого ICMP-пакета с помощью утилиты ping. Некоторые ОС Windows не могут обработать такой пакет, в результате чего происходит крах системы. Что касается исчерпания ресурсов, то под ресурсами в данном случае понимается время ЦП, память, дисковое пространство, пространство в некотором буфере или пропускная способность сети. Во многих случаях достаточно установить последние версии ПО, чтобы предотвратить данный тип DoS-атаки.

DoS-атаки наводнения

Атакующий может попытаться монополизировать сетевое соединение с целевой системой, в результате этого никто не сможет получить доступ к ресурсу. Такие атаки называются flooding DoS-атаками, и в этом случае не создается шквала на целевой системе.

Термин "распределенная DoS-атака" (DDoS) означает подмножество DoS-атак. DDoS-атаки являются вариантами DoS-атак наводнения, когда атакующий использует несколько компьютеров для запуска атаки. Эти компьютеры часто находятся под управлением атакующего и таким образом действуют как единая огромная атакующая система. Атакующий обычно не может нанести вред большому сайту электронной коммерции с помощью наводнения сетевыми пакетами с единственного хоста. Однако, если он получит управление над огромным количеством хостов, взломав их таким образом, чтобы заставить их выполнять атаку под своим управлением, то он может получить достаточно средств для успешной атаки на самые большие системы.

Модификация потока данных – атака "man in the middle"

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

Рис. 1.5. Атака «man in the middle»

Создание ложного потока (фальсификация, проникновение)

Фальсификация (нарушение аутентичности) означает попытку одного субъекта выдать себя за другого.

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

Рис. 1.6. Создание ложного потока

Атаки проникновения имеют два варианта: локальный и удаленный.

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

User to Root: локальный пользователь получает полное управление над целевой системой.
Remote to User: атакующий по сети получает доступ с правами локальной пользовательской учетной записи на целевой системе.
Remote to Root: атакующий по сети получает полное управление над целевой системой.
Remote Disk Read: атакующий по сети получает возможность читать файлы на целевой системе без прохождения аутентификации.
Remote Disk Write: атакующий по сети получает возможность записывать в файлы на целевой системе без прохождения аутентификации.

Атаки авторизованного пользователя

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

Атаки публичного доступа

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

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

Повторное использование

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

Рис. 1.7. Replay-атака

Перечисленные атаки могут существовать в любых типах сетей, а не только в сетях, использующих в качестве транспорта протоколы TCP/IP, и на любом уровне модели OSI. Но в сетях, построенных на основе TCP/IP, атаки встречаются чаще всего, потому что, во-первых, интернет стал самой распространенной сетью, а во-вторых, при разработке протоколов TCP/IP требования безопасности никак не учитывались.

1.2.3 Определение расположения атакующего

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

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

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

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

Однако существует одно исключение, связанное с квалифицированными атакующими. Атакующий может послать пакеты, используя поддельный IP-адрес источника, но установить ловушку для ответов жертвы на этот поддельный адрес. Это можно сделать без доступа к компьютеру с поддельным адресом. Такая манипуляция с IP-адресацией называется "IP-Spoofing".

1.2.4 Соглашения по именованию атак

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

В настоящее время приложены определенные усилия по разработке общей номенклатуры компьютерных уязвимостей и атак. Наиболее популярным из них является Common Vulnerabilities and Exposures List (CVE), который поддерживается MITRE, получающим информацию от различных профессиональных сообществ по безопасности. Многие производители программных и аппаратных продуктов, связанных с безопасностью, делают их CVE-совместимыми. Список CVE может быть найден на сайте http://cve.mitre.org.

Лекция 2. Основы администрирования межсетевого экрана D-Link DFL-860E

Лабораторный практикум

Лабораторная работа №1. Основы администрирования межсетевого экрана

Цель

Рассмотрим общие вопросы администрирования межсетевого экрана.

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

Описание практической работы

Управление межсетевым экраном с помощью различных интерфейсов

Доступ к межсетевому экрану с рабочей станции

Новому межсетевому экрану D-Link NetDefend с заводскими настройками по умолчанию система NetDefendOS автоматически назначает внутренний IP-адрес по умолчанию на интерфейсе lan1 (или интерфейс lan на моделях с одним локальным интерфейсом). IP-адрес, назначаемый интерфейсу управления, зависит от модели межсетевого экрана NetDefend:

Для моделей межсетевых экранов NetDefend DFL-210, 260, 800, 860, 1600 и 2500, IP-адрес интерфейса управления, назначаемый по умолчанию – 192.168.1.1.
Для моделей межсетевых экранов NetDefend DFL-1660, 2560, 2560G и 260E/860E, IP-адрес интерфейса управления, назначаемый по умолчанию – 192.168.10.1.

IP-адреса интерфейса межсетевого экрана, который соединен с рабочей станцией, и интерфейс самой рабочей станции, которая должна выполнять управление межсетевым экраном, должны быть в одной и той же сети. Поэтому интерфейсу рабочей станции вручную должен быть назначен статический IP-адрес из подсети 192.168.1.0/24 и основной шлюз 192.168.1.1:

IP-адрес: 192.168.1.30

Маска подсети: 255.255.255.0

Основной шлюз: 192.168.1.1

Веб-интерфейс

Система NetDefendOS предоставляет веб-интерфейс (WebUI) для управления системой с помощью стандартного веб-браузера.

Первоначальная регистрация в веб-интерфейсе и Мастер установки

Для первоначального доступа к веб-интерфейсу межсетевого экрана с заводскими настройками по умолчанию следует использовать URL https://192.168.1.1.

После этого появится диалоговое окно аутентификации пользователя.

увеличить изображение

Рис. 1.1.

Имя пользователя по умолчанию – admin

пароль по умолчанию – admin

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

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

Общий вид веб-интерфейса:

увеличить изображение

Рис. 1.2.

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

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

Home – Возврат на главную страницу веб-интерфейса.

Configuration

Save and Actvate – Сохранение и активация настроек.

Discard changes – Отмена изменений в настройках, выполненных во время текущей сессии.

View Changes – Список изменений в настройках с момента последнего сохранения.

Tools – Инструментальные средства, необходимые для обслуживания системы.

Status – Текущие статусы, используемые для диагностики текущего состояния системы.

Maintenance – Обслуживание.

Update Center – Обновление сигнатур антивируса и определения вторжений, которое может выполняться как вручную, так и по расписанию.

License – Просмотр лицензии и ввод кода активации.

Backup – Создание резервной копии настроек на рабочей станции и восстановление предварительно созданной резервной копии.

Reset – Перезапуск межсетевого экрана или сброс к заводским настройкам по умолчанию.

Upgrade – Обновление программного обеспечения межсетевого экрана.

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

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

Веб-интерфейс:

System -> Remote Management -> Add -> HTTP/HTTPS Management

увеличить изображение

Рис. 1.3.

Командная строка:

add RemoteManagement RemoteMgmtHTTP https Network=all-nets Interface=any LocalUserDatabase=AdminUsers HTTPS=Yes

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

Интерфейс командной строки CLI

Система NetDefendOS предоставляет интерфейс командной строки (CLI), который доступен локально через серийный консольный порт (соединение с которым описывается ниже) или удаленно через один из интерфейсов межсетевого экрана с помощью клиента протокола SecureShell (SSH).

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

Наиболее часто используемые команды CLI:

add – Добавление объекта, например, IP-адреса или правила в настройки межсетевого экрана.

set – Изменение какого-либо свойства объекта.

show – Отображение текущих категорий или значений объекта.

delete – Удаление объекта.

Структура команд

Большинство команд имеют следующую структуру:

<command> [<object_category>] <object_type> <object_name> [<object_properties>]

Например, для отображения IP-адреса объекта my_address используется команда:

gw-world:/>show Address IP4Address my_address

Все настраиваемые сущности (IP-адреса, интерфейсы, правила фильтрования и маршрутизации и т.п.) межсетевого экрана называются объектами. Каждый объект принадлежит определенному типу (IP4Address, Ethernet, IPsecTunnel, IPRule, RoutingRule и т.п.). Несколько типов могут быть сгруппированы в категорию (Address, Interface, Settings и т.п.).

Команда

gw-world:/>help help

выводит справочную информацию о системе.

История команд

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

Функция Tab Completion

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

Возможность tab completion можно также использовать для автоматического заполнения параметров команды значениями по умолчанию. Для этого в качестве значения следует ввести символ "." и нажать клавишу tab. Например, если при наборе незаконченной команды:

set Address IP4Address lan_ip Address=

ввести "." и нажать клавишу tab, то отобразится текущее значение параметра Address. Если данным значением является, например, 10.6.58.10 будет автоматическисоздана следующая команда:

set Address IP4Address lan_ip Address=10.6.58.10

После этого ее можно при необходимости отредактировать и выполнить.

Категории объектов

Ранее упоминалось, что объекты группируются по типу, например, IP4Address. Типы могут группироваться по категориям. Тип IP4Address принадлежит категории Address. При использовании в категориях функция tab completion применяется для поиска типа объекта, который необходимо использовать.

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

Не все типы объектов принадлежат категориям. В этом случае после ввода команды и нажатия tab будет появляться список возможных типов объектов.

Выбор категории объектов

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

gw-world:/>cc RoutingTable main

gw-world:/main>

Обратите внимание, что приглашение изменяется. Теперь можно добавить маршрут:

gw-world:/main>add Route Name=new_route1 Interface=lan Network=lannet

Для отмены указания текущей категории следует использовать команду cc без параметров.

В категориях, в которых перед созданием или редактированием объектов требуется указать экземпляр с помощью команды cc, в списке, показываемом командой show, после имени категории следует символ "/".

увеличить изображение

Рис. 1.4.

Определение нескольких значений параметров

Иногда параметр команды может иметь несколько значений. Эти значения должны разделяться запятой. Например:

AccountingServers=server1,server2,server3

Добавление нового правила в список правил

Порядок правил в списке, например, набор правил фильтрования, является важным. По умолчанию новое правило добавляется в конец списка. Если упорядоченность важна, то может быть добавлен параметр Index=<Номер позиции в списке правил>.

Использование уникальных имен

Для удобства рекомендуется назначать всем объектам уникальные имена, чтобы эти имена можно было использовать в качестве ссылки на объект. Это особенно часто используется при написании сценариев.

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

Использование dns-имени вместо IP-адреса

В некоторых командах адрес в виде dns-имени, а не IP-адреса. В этом случае перед именем должен стоять префикс dns:, указывающий на то, что необходимо использовать сервис DNS для поиска IP-адреса по имени хоста. Например, dns-имя host.company.com следует указывать в командной строке как dns:host.company.com.

Параметры, в которых могут употребляться dns-имена в командной строке:

Удаленная конечная точка для IPsec-, L2TP- и PPTP-туннелей.
Хост для LDAP-серверов.

Если необходимо использовать сервис DNS, то следует настроить хотя бы один DNS-сервер, который будет выполнять преобразования dns-имена в IP-адреса.

Локальный доступ к интерфейсу командной строки

Серийный порт консоли – это порт RS-232 межсетевого экрана NetDefend, обеспечивающий локальный доступ к интерфейсу командной строки. Порт RS-232 существует на старших моделях DFL 1660/2560. На новых младших моделях DFL консольный порт выполнен в виде Ethernet-разъема.

Доступ к интерфейсу командной строки по протоколу SSH (SecureShell)

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

Система NetDefendOS поддерживает версии 1, 1.5 и 2 протокола SSH. Разрешение доступа по протоколу SSH предоставляется с помощью политики удаленного управления, и по умолчанию разрешения доступа по протоколу SSH нет.

Веб-интерфейс:

System -> Remote Management -> Add -> Secure Shell Management

Name: SSH_lan

увеличить изображение

Рис. 1.5.

увеличить изображение

Рис. 1.6.

Командная строка:

add RemoteManagement RemoteMgmtSSH ssh Network=lannetFW1 Interface=lan LocalUserDatabase=AdminUsers

Изменение пароля пользователя admin

После первоначального запуска рекомендуется как можно скорее изменить пароль по умолчанию admin на любой другой. Пароль пользователя может быть любой комбинацией символов и не может содержать более 256 символов.

Веб-интерфейс:

User Authentication -> Local User Databases -> AdminUsers

увеличить изображение

Рис. 1.6.

Командная строка:

cc LocalUserDatabase AdminUsers

set User admin Password=admin

Учетные записи для администрирования межсетевого экрана

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

По умолчанию имеется локальная база данных AdminUsers, которая содержит учетную запись admin. Пароль данной учетной записи – admin.

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

увеличить изображение

Рис. 1.7.

Для управления межсетевым экраном определены две группы: Administrators и Auditors.

Учетные записи, принадлежащие группе Administrators, обладают правами по чтению и записи всех настроек межсетевого экрана.

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

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

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

увеличить изображение

Рис. 1.8.

увеличить изображение

Рис. 1.9.

Сценарии командной строки

Для простоты хранения и выполнения команд администратором, NetDefendOS поддерживает функцию CLIscripting. CLIscript– это записанная в файл последовательность команд, которые можно выполнить после загрузки файла на межсетевой экран.

Для создания CLIscript следует выполнить следующие шаги:

Создать текстовый файл, содержащим последовательность команд, по одной команде в строке. Для этих файлов рекомендуется использовать расширение .sgs (Security Gateway Script). Имя файла, включая расширение, не должно содержать более 16 символов.
Загрузить файл на межсетевой экран, используя Secure Copy (SCP). Файлы-сценарии должны храниться в папке scripts.
Использовать команду CLI script –execute для выполнения команд из файла.

Команда script – это инструментальное средство, используемое для выполнения определенной последовательности команд. Полный синтаксис команды описан в Руководстве по интерфейсу командной строки CLI. Рассмотрим некоторые примеры использования данной команды.

В сценариях можно использовать следующие четыре команды: add, set, delete, cc.

Если в сценарии появляется любая другая команда, она игнорируется, при этом генерируется сообщение с предупреждением. Например, команда ping будет проигнорирована.

С помощью команды script -execute запускается указанный в параметре –name файл сценария.

script -execute -name=my_script.sgs

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

$1, $2, $3, $4 $n

Фактические параметры этих переменных указываются в командной строке script -execute.

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

script -execute -name=my_script2.sgs -force

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

script -execute -name=my_script2.sgs -verbose

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

script -store -name=my_script.sgs

Если требуется переместить в энергонезависимую память все сценарии, то используется команда.

script -store -all

Для удаления сценария используется команда script –remove.

Команда script без параметров отображает список всех сценариев, размер каждого сценария и тип памяти, в которой хранится сценарий (Disk или Memory).

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

script -show -name=<имя файла>

Автоматическое создание сценариев

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

Команда

script –create <object_type>

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

Например, для создания всех объектов IP4Address с одними и теми же параметрами на нескольких межсетевых экранах следует выполнить команду.

script -create Address IP4Address -name new_script.sgs

Файл new_script_sgs может быть загружен на локальную рабочую станцию и затем скачен и активирован на других межсетевых экранах. После этого у всех устройств в адресных книгах будут находиться одни и те же объекты IP4Address.

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

Строка в файле сценария, которая начинается с символа #, является комментарием.

Сценарии, вызывающие другие сценарии

Один сценарий может вызывать другой. Например, сценарий my_script.sgs может содержать строку.

script -execute -name my_script2.sgs

Максимальное количество вложенных сценариев – 5.

Дата и время

Обзор

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

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

Протоколы синхронизации времени

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

Установка даты и времени и установка часового пояса

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

Веб-интерфейс:

System -> Date and Time

увеличить изображение

Рис. 1.10.

увеличить изображение

Рис. 1.11.

Командная строка:

time –set YYYY-mm-DD HH:MM:SS

set DateTime Timezone=GMTplus4

Серверы времени (Time Servers)

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

Поддерживаются следующие протоколы синхронизации времени:

SNTP Определяется стандартом RFC 2030, простой сетевой протокол синхронизации времени – реализация NTP (RFC 1305). NetDefendOS использует данный протокол для запросов к NTP-серверам.
UDP/TIME Протокол времени – Time Protocol (UDP/TIME) – более ранний протокол, также обеспечивающий синхронизацию времени через интернет.

Большинство серверов времени поддерживают NTP или SNTP-протоколы.

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

Максимальная величина корректировки времени

Чтобы избежать установления некорректного времени, которое может произойти при синхронизации с неисправным сервером, можно установить максимальную величину корректирования времени (Maximum Adjustment) (в секундах). Если разница между текущим временем системы и временем, полученным с сервера, будет больше заданной максимальной величины, то данные, полученные с сервера, будут отклонены. Например, значение максимального времени установки равно 60 секунд и текущее время системы NetDefendOS составляет 16:42:35. Если время, полученное с сервера: 16:43:38, то разница составляет 63 секунды, что превышает максимальную величину, т.е. текущее время не будет обновлено.

Веб-интерфейс:

System -> Date and Time

увеличить изображение

Рис. 1.12.

Командная строка:

set DateTime TimeSyncMaxAdjust=40000

Значение максимальной регулировки времени можно отключить.

time -sync –force

При необходимости можно изменить интервал между попытками синхронизации. По умолчанию интервал равен 86 400 секунд (1 день).

Серверы синхронизации времени D-Link

При работе с системой NetDefendOS для синхронизации времени рекомендуется использовать серверы синхронизации времени D-Link, путь к которым прописан в опциях системы. Серверы D-Link взаимодействуют с системой по протоколу SNTP.

Когда опция D-Link Server включена, синхронизация осуществляется автоматически.

Веб-интерфейс:

System -> Date and Time

увеличить изображение

Рис. 1.13.

Командная строка:

set DateTime TimeSynchronization=D-Link

Следует помнить, что для работы с серверами синхронизации времени D-Link необходимо настроить сервис DNS.

Серверы DNS

Если в системе настроены DNS-сервера, то вместо IP-адреса можно указывать соответствующее доменное (FQDN) имя.

Система NetDefendOS является DNS-клиентом и может использовать три DNS-сервера: Primary Server (первичный сервер), Secondary Server (вторичный сервер) и Tertiary Server (третий сервер).

Настройка хотя бы одного DNS-сервера необходима для функционирования следующих модулей системы NetDefendOS:

Автоматическая синхронизация времени.
Доступ к СА для получения сертификатов.
Доступ к внешним сервисам, содержащим различные базы данных сигнатур, используемые в системе (антивирусные или IDP).

Веб-интерфейс:

System -> DNS

увеличить изображение

Рис. 1.14.

Командная строка:

set DNSDNSServer1=wan1/wan1_dns1

Перезапуск межсетевого экрана, сброс к заводским настройкам по умолчанию

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

Веб-интерфейс:

Maintenance -> Reset

увеличить изображение

Рис. 1.15.

Командная строка:

reset -unit

Активация и применение изменений

После внесения изменений в конфигурацию следует выполнить команды activate и commit.

Если в течение 30 секунд (по умолчанию) не выполнена команда commit, выполненные изменения автоматически отменяются, и происходит восстановление прежних настроек.

Управление сессиями с помощью команды sessionmanager

Интерфейс командной строки предоставляет команду sessionmanager для управления сессиями. Команда используется для управления всеми типами сессий:

Сессии командной строки, созданные при использовании протокола SSH.
Сессия командной строки, созданные через интерфейс серийной консоли RS232.
Сессии, созданные при использовании протокола Secure Copy (SCP).
Сессии веб-интерфейса, созданные при использовании протокола HTTP или HTTPS.

Команда без каких-либо опций предоставляет краткую информацию о текущих открытых сессиях. Для просмотра списка всех сессий используется опция -list.

Командная строка:

sessionmanager

sessionmanager -list

Если пользователь обладает правами администратора, можно завершить любую сессию с помощью опции -disconnect.

Поиск неисправностей – команда pcapdump

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

Примеры использования pcapdump:

Освобождение памяти, использованной командой pcapdump и удаление всех файлов, которые были ранее сохранены с помощью команды pcapdump.
pcapdump –cleanup
Запись в буфер в оперативной памяти межсетевого экрана всех пакетов, проходящих через интерфейс lan. Если интерфейс не указан, то будет выполнен перехват всех пакетов, проходящих через все интерфейсы.
pcapdump –start lan
Запись всех пакетов, прошедших через интерфейс lan, из буфера в оперативной памяти в файл lan_int.cap. Данные файлы находятся в корневой папке межсетевого экрана.
pcapdump -write lan -filename=lan_int.cap
Отображение перехваченных пакетов в консоли.
pcapdump –show
Останов перехвата пакетов, проходящих через интерфейс lan. Если интерфейс не указан, то будет выполнен останов перехвата пакетов, проходящих через все интерфейсы.
pcapdump –stop lan

Загрузка выходного файла

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

Для дальнейшего анализа пакетов рекомендуется использовать программу Wireshark (ранее известную как Ethereal). Данная программа является приложением с открытым исходным кодом и использует библиотеку Pcap.

Для получения более подробной информации о программе Wireshark, см сайт http://www.wireshark.org.

Лекция 3. Конфиденциальность, целостность, доступность

1.3 Триада безопасной ИТ-инфраструктуры – Конфиденциальность, Целостность, Доступность

Основой безопасной ИТ-инфраструктуры является триада сервисов – Конфиденциальность, Целостность, Доступность – Confidentiality, Integrity, Availability (CIA).

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

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

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

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

Три основных сервиса – CIA – служат фундаментом информационной безопасности. Для реализации этих трех основных сервисов требуется выполнение следующих сервисов.

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

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

Подотчетность – возможность системы идентифицировать отдельного индивидуума и выполняемые им действия. Наличие этого сервиса означает возможность связать действия с пользователями. Данный сервис очень тесно связан с сервисом невозможности отказа.

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

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

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

Если хотя бы один из этих сервисов не функционирует, то можно говорить о нарушении всей исходной триады CIA.

Для реализации сервисов безопасности должна быть создана так называемая "оборона в глубину". Для этого должно быть проделано:

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

1.4 Гарантирование выполнения

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

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

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

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

1.5 Анализ рисков

При анализе рисков первым делом следует проанализировать информационные активы, которые должны быть защищены.

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

Анализ рисков является процессом определения рисков для информационных активов и принятия решения о том, какие риски являются приемлемыми, а какие нет. Анализ рисков включает:

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

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

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

Вирусы, черви, троянские кони.
DoS-атаки.
Просмотр сетевого трафика.
Кража данных.

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

Критичные данные, для которых нет резервной копии.
Единственное критичное место в сетевой инфраструктуре (например, базовый маршрутизатор).
Неправильное управление доступом к ключам, которые используются для шифрования критических данных.

Уязвимости, которые могут существовать в информационных активах, могут быть связаны с наличием:

Слабых мест в ПО:

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

Слабых мест в архитектуре:

Наличие единственной точки отказа.

Слабых мест, связанных с человеческим фактором.

Возможные стратегии управления рисками:

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

1.6 Аутентификация и управление Идентификациями

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

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

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

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

Возможны следующие способы аутентификации.

1.6.1 Пароли

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

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

В большинстве современных приложений пароль не хранится и не передается в явном виде.

1.6.2 Токены

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

Смарт-карты.
Одноразовые пароли.
Устройства, работающие по принципу запроса – ответа.

1.6.3 Биометрические параметры

Используются некоторые физические характеристики пользователя.

1.6.4 Криптографические ключи

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

Существует два типа алгоритмов и, соответственно, два типа ключей – симметричные и асимметричные.

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

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

1.6.5 Многофакторная аутентификация

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

1.6.6 Централизованное управление идентификационными и аутентификационными данными

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

Легкое администрирование.
Увеличение производительности.

Примерами являются:

Сервисы Директории:

Microsoft AD.
Различные реализации LDAP.

Протоколы:

Radius.
PAP, CHAP.
Kerberos.

Системы федеративной идентификации.

Целями систем федеративной идентификации являются:

Обеспечить единую аутентификацию (так называемый Single Sign On – SSO) в пределах сетевого периметра или домена безопасности.
Обеспечить пользователей возможностью легко управлять своими идентификационными данными.
Создать родственные группы, которые могут доверять друг другу аутентифицировать своих пользователей.

1.7 Управление доступом

Управление доступом или авторизация означает определение прав и разрешений пользователей по доступу к ресурсам.

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

Основные вопросы, на которые должен отвечать сервис авторизации: "Кто и что может делать в компьютерной системе или сети?" и "Когда и где он может это делать?".

Компоненты управления доступом:

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

Объекты или ресурсы –файлы или любые сетевые ресурсы, к которым субъект хочет получить доступ. Это включает файлы, папки и другие типы ресурсов, такие как записи базы данных (БД), сеть или ее компоненты, например, принтеры.

Разрешения – права, предоставленные субъекту по доступу к данному объекту или ресурсу.

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

Управление доступом на уровне файловой системы может быть интегрировано в ОС. Как правило в этом случае используются списки управления доступом (Access Control List – ACL) или возможности (capabilities).

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

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

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

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

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

Преимущества управления доступом на сетевом уровне:

Возможное четкое определение точек входа, что облегчает мониторинг и управление доступом.
Возможно скрытие внутренних адресов для внешних пользователей. Межсетевой экран может быть сконфигурирован как прокси или может выполнять преобразование адресов (Network Address Translation – NAT) для сокрытия внутренних IP-адресов хостов.

Недостатки управления доступом на сетевом уровне:

Не всегда удается использовать подход "установить и забыть" – необходимо анализировать и изменять правила межсетевого экрана при изменении конфигурации или требований к безопасности.
Может оказаться единственной точкой отказа.
Анализирует только заголовки сетевого уровня.

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

Прокси-сервер является устройством или сервисом, который расположен между клиентом и целевым сервером. Запрос на сервер посылается к прокси-серверу. Прокси-сервер анализирует запрос и определяет, является ли он допустимым.

Преимущества управления доступом на прикладном уровне:

Управление доступом отражает специфику конкретной целевой системы. Увеличивает точность (гранулированность) управления доступом.
Может снизить влияние неправильной конфигурации отдельных хостов.
Выполняется подробный анализ пакетов.
Выполняется более сильная аутентификация.

Недостатки управления доступом на прикладном уровне:

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

1.8 Обеспечение отчетности

Отчетность – это возможность знать, кто и что делал в системе и сети. Это включает:

Создание и аудит системных логов.
Мониторинг систем и сетевого трафика.
Обнаружение проникновений.

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

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

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

1.9 Гарантирование доступности

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

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

С точки зрения гарантирования доступности можно дать следующие определения.

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

Избыточность – создание одной или нескольких копий (backup) си-стемы, которые становятся доступными в случае сбоя основной системы, или наличие дополнительных возможностей системы для организации её отказоустойчивости.

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

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

Основные технологии обеспечения отказоустойчивости этих компо-нент:

Данные:

Защита с помощью RAID.
Шифрование данных и управление ключом.
Стратегии создания копий и восстановления.

Компоненты систем:

Горячее резервирование аппаратуры и подсистем.
Резервирование на уровне сетевых интерфейсов.
Резервирование данных на уровне ОС и приложений.

Сетевая топология:

Обеспечение масштабируемости пропускной способности и количества интерфейсов.

Маршрутизаторы и коммутаторы:

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

Критические сервисы:

Обеспечение балансировки нагрузки для таких критических сервисов, как DNS, DHCP и т.п.
Обеспечение балансировки нагрузки для прикладных сер-веров (веб, почта, БД).
Обеспечение балансировки нагрузки для сетевых устройств, таких как межсетевые экраны и прокси-серверы.

1.10 Управление конфигурациями

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

Регулярное обновление ПО.
Управление и контроль существующих ресурсов.
Управление изменениями.
Оценка состояния сетевой безопасности.

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

Управление обновлением ПО является одной из ежедневных обязанностей, которая является относительно простой. В идеале обновление должно проводиться на отдельном оборудовании и после тестирования переноситься на все производственные системы. Этого достаточно трудно добиться даже в небольших сетях. Различные производители, такие как Microsoft, и системы с открытым кодом, такие как Linux, уделяют большое внимание этой проблеме, и на сегодняшний день существуют достаточно зрелые технологии, например, Windows Server Update Services (WSUS), которые позволяют администратору управлять внесением обновлений в сетях, построенных с использованием ОС Windows. С другой стороны, для таких устройств сетевой инфраструктуры, как коммуникаторы и маршрутизаторы, обновление выполняется значительно труднее. Обычно они либо пол-ностью заменяются, либо должен быть загружен и заменен образ всей ОС.

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

Также важна регулярная оценка состояния сетевой безопасности. Существуют различные инструментальные средства, такие как Baseline Security Analyzer компании Microsoft и инструментальное средство с открытым кодом Nessus, которые помогают администратору выполнить такую оценку.

1.11 Управление инцидентами

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

1.12 Использование третьей доверенной стороны

Модель безопасного сетевого взаимодействия в общем виде можно представить следующим образом:

увеличить изображение

Рис. 1.8. Использование третьей доверенной стороны

В некоторых случаях для выполнения сервисов безопасности необходимо взаимодействие с третьей доверенной стороной (Third Trusted Party – TTP). Например, третья сторона может быть ответственной за распределение между двумя участниками секретной информации, которая не стала бы доступна оппоненту. Либо третья сторона может использоваться для решения споров между двумя участниками относительно достоверности передаваемого сообщения.

1.13 Криптографические механизмы безопасности

Перечислим основные криптографические механизмы безопасности:

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

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

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

Лекция 4. Соединение сетей за межсетевыми экранами

Цель

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

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

Топология сети

увеличить изображение

Рис. 2.1.

На Межсетевом Экране 1 (МЭ 1) используются четыре интерфейса, которые обозначены lan, dmz, wan1 и wan2.

Интерфейс lan имеет IP-адрес 192.168.1.10 и соединен с подсетью 192.168.1.0/24, в которой расположены рабочие станции пользователей.

Интерфейс dmz имеет IP-адрес 172.17.100.1, в текущей топологии к нему не подсоединена никакая сеть.

Интерфейс wan1 имеет IP-адрес 10.6.10.62 и соединен с подсетью 10.6.10.0/28 со шлюзом провайдера, который обеспечивает выход в интернет и имеет IP-адрес 10.6.10.3.

Интерфейс wan2 имеет IP-адрес 192.168.20.10 и соединен с подсетью 192.168.20.0/24, в которой расположен Межсетевой Экран 2 (МЭ 2) с IP-адресом 192.168.20.20.

На Межсетевом Экране 2 (МЭ 2) используются четыре интерфейса, которые обозначены lan, dmz, wan1 и wan2.

Интерфейс lan имеет IP-адрес 192.168.2.20 и соединен с подсетью 192.168.2.0/24, в которой расположены рабочие станции пользователей.

Интерфейс dmz имеет IP-адрес 172.17.200.2, в текущей топологии к нему не подсоединена никакая сеть.

Интерфейс wan1 является DHCP-клиентом, который получает IP-адрес, маску подсети, шлюз по умолчанию и IP-адрес DNS-сервера от DHCP-сервера провайдера.

Интерфейс wan2 имеет IP-адрес 192.168.20.20 и соединен с подсетью 192.168.20.0/24, в которой расположен Межсетевой Экран 1 (МЭ 1) с IP-адресом 192.168.20.10.

Описание практической работы

Сервисы DNS

Межсетевой Экран 1

увеличить изображение

Рис. 2.2.

На МЭ 1 весь DNS-трафик из своей локальной сети и удаленной локальной сети должен перенаправляться на DNS-сервер провайдера, поэтому Межсетевой Экран 1 должен знать IP-адрес DNS-сервера провайдера. Необходимо выполнить следующие настройки:

В Адресной Книге создать необходимые объекты.
Для удобства конфигурирования объединить в одну группу интерфейсы, которые требуют одинаковых Правил фильтрования.
Создать Правила фильтрования, перенаправляющие DNS-трафик из локальной сети и dmz-сети к DNS-серверу.
При необходимости в таблицу маршрутизации добавить маршруты.

Объекты Адресной Книги

В Адресной Книге создать необходимые объекты.

Объекты интерфейса lan.
Веб-интерфейс:

Object -> Address Book -> Add -> Address Folder

Name: lan

Object -> Address Book -> lan

увеличить изображение

Рис. 2.3.

Командная строка:

add Address AddressFolder lan Comments=lan

cc Address AddressFolder lan

add IP4Address lan_ip Address=192.168.1.10 Comments=’IPAddress of interface lan’

add IP4Address lan_net Address=192.168.1.0/24 Comments=’The network on interface lan’
Объекты интерфейса dmz.

Веб-интерфейс:

Object -> Address Book -> Add -> Address Folder

Name: dmz

Object -> Address Book -> lan

увеличить изображение

Рис. 2.4.

Командная строка:

add Address AddressFolder dmz Comments=dmz

cc Address AddressFolder dmz

add IP4Address dmz_ip Address=172.17.100.1 Comments=’IPAddress of interface dmz’

add IP4Address dmz_net Address=172.17.100.0/24 Comments=’The network on interface dmz’
Объекты интерфейса wan1.

Веб-интерфейс:

Object -> Address Book -> Add -> Address Folder
Name: wan1
Object -> Address Book -> wan1

увеличить изображение

Рис. 2.5.

Командная строка:
add Address AddressFolder wan1 Comments=wan1
cc Address AddressFolder wan1
add IP4Address wan1_ip Address=10.6.10.62 Comments=’IPAddress of interface wan1’
add IP4Address wan1_gw Address=10.6.10.3 Comments=’Default gateway for interface wan1’
add IP4Address wan1_dns1 Address=10.6.10.3 Comments=’Primary DNS server for interface wan1’
add IP4Address wan1_net Address=10.6.10.0/28 Comments=’The network on interface wan1’
Объекты интерфейса wan2.
Веб-интерфейс:
Object -> Address Book -> Add -> Address Folder
Name: wan2
Object -> Address Book -> wan2

увеличить изображение

Рис. 2.6.

Командная строка:
add Address AddressFolder wan2 Comments=wan2
cc Address AddressFolder wan2
add IP4Address wan2_ip Address=192.168.20.10 Comments=’IPAddress of interface wan2’
add IP4Address wan2_gw Address=192.168.20.20 Comments=’The network on interface wan2’
add IP4Address wan2_net Address=192.168.20.0/24 Comments=’The network on interface wan2’
Объекты, описывающие LAN-сеть, расположенную за МЭ 2.
Веб-интерфейс:
Object -> Address Book -> Add -> Address Folder
Name: remote
Object -> Address Book -> rem_lan

увеличить изображение

Рис. 2.7.

Командная строка:
add Address AddressFolder remote Comments=’The remote objects’
cc Address AddressFolder remote
add IP4Address rem_lan Address=192.168.2.0/24 Comments=’The remote lan’
Дополнительные объекты, необходимые для удобства администрирования и объединяющие в одну группу сети и IP-адреса, которые необходимы одинаковые сервисы DNS.
Веб-интерфейс:
Object -> Address Book -> InterfaceAddresses -> Add
Name: dns_relay
Object -> Address Book -> dns_relay

увеличить изображение

Рис. 2.8.

Командная строка:
add Address AddressFolder dns_relay Comments=’DNS services’
cc Address AddressFolder dns_relay
add IP4Group dns_net Members=lan/lan_net, dmz/dmz_net
add IP4Group dns_ip Members=lan/lan_ip, dmz/dmz_ip

Привязка созданных объектов Адресной Книги к интерфейсам

Объекты, созданные в пунктах 1, 2, 3 и 4, должны быть привязаны к соответствующим Ethernet-интерфейсам.

Веб-интерфейс:

Interfaces -> Ethernet-> wan1

увеличить изображение

Рис. 2.9.

Если IP-адрес данного интерфейса должен быть получен по протоколу DHCP, то следует установить соответствующий флаг "Enable DHCP Client".

увеличить изображение

Рис. 2.10.

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

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

Командная строка:

set Interface Ethernet lan IP=lan/lan_ip Network=lan/lan_net AutoInterfaceNetworkRoute=yes

set Interface Ethernet dmz IP=dmz/dmz_ip Network=dmz/dmz_net AutoInterfaceNetworkRoute=yes

set Interface Ethernet wan1 IP=wan1/wan1_ip Network=wan1/wan1_net DefaultGateway=wan1/wan1_gw Name=wan1 AutoInterfaceNetworkRoute=yes AutoDefaultGatewayRoute=yes

set Interface Ethernet wan2 IP=wan2/wan2_ip Network=wan2/wan2_net DefaultGateway=wan2/wan2_gw Name=wan2 AutoInterfaceNetworkRoute=yes

В результате заданы следующие параметры интерфейсов:

увеличить изображение

Рис. 2.11.

Таблица маршрутизации следующая:

увеличить изображение

Рис. 2.12.

Группа интерфейсов

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

Веб-интерфейс:

Interfaces -> Interface Group ->Add

увеличить изображение

Рис. 2.13.

Командная строка:

add Interface InterfaceGroup dns_relay_int Members=lan,dmz

Правила фильтрования

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

Создать правила SAT и NAT для каждого интерфейса, соединенному с сетями, которым необходим сервис DNS. В качестве сети источника следует указать сеть (группу сетей), которой требуется сервис DNS. В качестве сети назначения следует указать IP-адрес интерфейса.
Правило SAT заменяет IP-адрес получателя на IP-адрес, указанный на вкладке SAT.
На вкладке SAT в качестве адреса назначения следует указать IP-адрес DNS-сервера.
Веб-интерфейс:
Rules -> IP Rules -> Add -> IP Rule Folder
Name: dns_relay_multi
Rules -> IP Rules -> dns_relay_multi

увеличить изображение

Рис. 2.13.

увеличить изображение

Рис. 2.14.

увеличить изображение

Рис. 2.15.

Командная строка:
add IPRuleFolder Name=dns_relay_multi
cc IPRuleFolder <N folder>
add IPRule Action=SAT SourceInterface=lan SourceNetwork=lan/lan_net DestinationInterface=core DestinationNetwork=lan/lan_ip Service=dns-all SATTranslateToIP=wan1/wan1_dns1 Name=sat_dns_lan
add IPRule Action=NAT SourceInterface=lan SourceNetwork=lan/lan_net DestinationInterface=core DestinationNetwork=lan/lan_ip Service=dns-all Name=nat_dns_lan
add IPRule Action=SAT SourceInterface=dmz SourceNetwork=dmz/dmz_net DestinationInterface=core DestinationNetwork=dmz/dmz_ip Service=dns-all SATTranslateToIP=wan1/wan1_dns1 Name=sat_dns_dmz
add IPRule Action=NAT SourceInterface=dmz SourceNetwork=dmz/dmz_net DestinationInterface=core DestinationNetwork=dmz/dmz_ip Service=dns-all Name=nat_dns_dmz
Использовать созданные группы IP-сетей, IP-адресов и интерфейсов, для сетей которых необходим сервис DNS. В этом случае будет достаточно одной пары правил SAT-NAT.
Веб-интерфейс:
Rules -> IP Rules -> Add -> IP Rule Folder
Name: dns_relay
Rules -> IP Rules -> dns_relay -> Add

увеличить изображение

Рис. 2.16.

увеличить изображение

Рис. 2.17.

увеличить изображение

Рис. 2.18.

Второе Правило зависит от требований провайдера. На МЭ 1 указано правило NAT. В этом случае провайдер видит только IP-адрес интерфейса wan1 МЭ1.

Командная строка:

add IPRuleFolder Name=dns_relay

cc IPRuleFolder <N folder>

add IPRule Action=SAT SourceInterface=dns_relay_int SourceNetwork=dns_relay/dns_relay_net DestinationInterface=core DestinationNetwork=dns_relay/dns_ip Service=dns-all SATAllToOne=Yes SATTranslateToIP=wan1/wan1_dns1 Name=sat_dns

add IPRule Action=NAT SourceInterface=dns_relay_int SourceNetwork=dns_relay/dns_relay_net DestinationInterface=core DestinationNetwork=dns_relay/dns_ip Service=dns-all Name=nat_dns

Результирующий трафик следующий.

На интерфейс lan приходит трафик:

увеличить изображение

Рис. 2.19.

С интерфейса wan1 уходит трафик:

увеличить изображение

Рис. 2.20.

Адрес получателя тот, который указан на вкладке SAT правила SAT.
Адрес отправителя соответствует правилу NAT.

Статическая маршрутизация

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

увеличить изображение

Рис. 2.21.

Проверка доступности DNS-сервисов из локальной сети

Проверить из командной строки на рабочей станции, расположенной в локальной сети, возможность обрабатывать DNS-запросы с помощью команды nslookup:

увеличить изображение

Рис. 2.22.

Межсетевой Экран 2

увеличить изображение

Рис. 2.23.

На Межсетевом Экране 2 следует выполнить аналогичные настройки.

В Адресной Книге создать необходимые объекты.
Для удобства конфигурирования объединить в одну группу интерфейсы, которые требуют одинаковых правил фильтрования.
Создать правила, перенаправляющие DNS-трафик из локальной сети и dmz-сети к DNS-серверу.
При необходимости в таблицу маршрутизации добавить маршруты.

Объекты Адресной Книги

В Адресной Книге создать необходимые объекты.

Объекты интерфейса lan.
Веб-интерфейс:
Object -> Address Book -> Add -> Address Folder
Name: lan
Object -> Address Book -> lan

увеличить изображение

Рис. 2.24.

Командная строка:
add Address AddressFolder lan
cc AddressAddressFolder lan
add IP4Address lan_ip Address=192.168.2.20 Comments=’IPAddress of interface lan’
add IP4Address lan_net Address=192.168.2.0/24 Comments=’The network on interface lan’
Объекты интерфейса dmz.
Веб-интерфейс:
Object -> Address Book -> Add -> Address Folder
Name: dmz
Object -> Address Book -> dmz

увеличить изображение

Рис. 2.25.

Командная строка:
add Address AddressFolder dmz
cc AddressAddressFolder dmz
add IP4Address dmz_ip Address=172.17.200.20 Comments=’IPAddress of interface dmz’
add IP4Address dmz_net Address=172.17.200.0/24 Comments=’The network on interface dmz’
Объекты интерфейса wan2.
Веб-интерфейс:
Object ->Address Book ->Add->Address Folder
Name: wan2
Object ->Address Book ->wan2

увеличить изображение

Рис. 2.26.

Командная строка:
add Address AddressFolder wan2
cc Address AddressFolder wan2
add IP4Address wan2_ip Address=192.168.20.20 Comments=’IPAddress of interface wan2’
add IP4Address wan2_gw Address=192.168.20.10 Comments=’Default gateway for interface wan2’
add IP4Address wan2_net Address=192.168.20.0/24 Comments=’The network on interface wan2’
Объекты, описывающие сети, расположенные за МЭ 1.
Веб-интерфейс:
Object ->Address Book ->Add->Address Folder
Name: remote
Object ->Address Book -> remote

увеличить изображение

Рис. 2.27.

Командная строка:
add Address AddressFolder remote Comments=’The remote objects’
cc Address AddressFolder remote
add IP4Address rem_lan Address=192.168.1.0/24 Comments=’The remote lan’
Дополнительные объекты, необходимые для удобства администрирования и объединяющие в одну группу сети и IP-адреса, которые необходимы одинаковые сервисы DNS.
Веб-интерфейс:
Object -> Address Book -> Add -> Address Folder
Name: dns_relay
Object -> Address Book -> dns_relay

увеличить изображение

Рис. 2.28.

Командная строка:
add Address AddressFolder dns_relay Comments=’DNS services’
cc Address AddressFolder dns_relay
add IP4Group dns_net Members =lan/lan_net, dmz/dmz_net
add IP4Group dns_ip Members = lan/lan_ip, dmz/dmz_ip

Привязка созданных объектов Адресной Книги к интерфейсам

Объекты, созданные в пунктах 1, 2 и 3, должны быть привязаны к соответствующим Ethernet-интерфейсам.

Веб-интерфейс:

Interfaces -> Ethernet -> wan1

увеличить изображение

Рис. 2.29.

увеличить изображение

Рис. 2.30.

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

Командная строка:

set Interface Ethernet lan IP=lan/lan_ip Network=lan/lan_net Name=lan AutoInterfaceNetworkRoute=yes

set Interface Ethernet dmz IP=dmz/dmz_ip Network=dmz/dmz_net Name=dmz AutoInterfaceNetworkRoute=yes

set Interface Ethernet wan1 IP=wan1/wan1_ip Network=wan1/wan1_net DefaultGateway=wan1/wan1_gw Name=wan1 AutoInterfaceNetworkRoute=yes DefaultGateway= wan1/wan1_gw DHCPEnabled=Yes

set Interface Ethernet wan2 IP=wan2/wan2_ip Network=wan2/wan2_net Name=wan2 AutoInterfaceNetworkRoute=yes

В результате заданы следующие параметры интерфейсов:

увеличить изображение

Рис. 2.31.

Группа интерфейсов

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

Веб-интерфейс:

Interfaces -> Interface Groups -> Add -> Interface Group

увеличить изображение

Рис. 2.32.

Командная строка:

add Interface InterfaceGroup dns_relay_int Members=lan,dmz

Правила фильтрования

Веб-интерфейс:

Rules -> IP Rules -> Add -> IP Rule Folder

Name: dns_relay

Rules -> IP Rules -> dns_relay

увеличить изображение

Рис. 2.33.

увеличить изображение

Рис. 2.34.

увеличить изображение

Рис. 2.35.

Вторым правилом на МЭ2 является правило NAT.

Командная строка:

add IPRuleFolder Name=dns_relay

cc IPRuleFolder <N folder>

add IPRule Action=SAT SourceInterface=dns_relay_int SourceNetwork=dns_relay/dns_net DestinationInterface=core DestinationNetwork=dns_relay/dns_ip SATAllToOne=Yes SATTranslateToIP=wan1/wan1_dns1 Service=dns-all Name=sat_dns

add IPRule Action=NAT SourceInterface=dns_relay_int SourceNetwork=dns_relay/dns_net DestinationInterface=core DestinationNetwork=dns_relay/dns_ip Service=dns-all Name=nat_dns

Статическая маршрутизация

В таблице маршрутизации уже созданы все необходимые маршруты.

увеличить изображение

Рис. 2.36.

Доступ в интернет

Межсетевой Экран 1

На МЭ 1 все необходимые объекты в Адресной Книге уже созданы и маршруты определены. Осталось добавить Правила фильтрования, разрешающие доступ в интернет.

Правила фильтрования

Веб-интерфейс:

Rules -> IP Rules -> Add -> IP Rule Folder

Name: toInet

Rules -> IP Rules -> toInet

увеличить изображение

Рис. 2.37.

Командная строка:

add IPRuleFolderName=toInet

cc IPRuleFolder <N folder>

add IPRule Action=Drop SourceInterface=dns_relay_int SourceNetwork=dns_relay/dns_relay_net DestinationInterface=wan2 DestinationNetwork=all-nets Service=smb_all Name=drop_smb-all

add IPRule Action=NAT SourceInterface=dns_relay_int SourceNetwork=dns_relay/dns_relay_net DestinationInterface=wan2 DestinationNetwork=all-nets Service=all_tcpudp Name=NAT_standard

Проверка доступа в интернет из локальной сети

увеличить изображение

Рис. 2.38.

Межсетевой Экран 2

На МЭ1 все необходимые объекты в Адресной Книге уже созданы и маршруты определены. Осталось добавить Правила фильтрования, разрешающие доступ в интернет. Для удобства конфигурирования Правил фильтрования был создан объект в Адресной Книге, который объединяет все сети, из которых необходим доступ в интернет.

Правила фильтрования

Веб-интерфейс:

Rules -> IPRules -> Add -> IPRuleFolder

Name: toInet

Rules -> IP Rules -> toInet

увеличить изображение

Рис. 2.39.

Командная строка:

add IPRuleFolderName=toInet

cc IPRuleFolder <N folder>

add IPRule Action=NAT SourceInterface=dns_relay_int SourceNetwork=dns_relay/dns_net DestinationInterface=wan1 DestinationNetwork=all-nets Service=all_tcpudp Name=NAT_standard

Проверка доступа в интернет из локальной сети

увеличить изображение

Рис. 2.40.

Доступ из локальных сетей к каждому межсетевому экрану

Межсетевой Экран 1

Группа интерфейсов

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

Веб-интерфейс:

Interfaces -> Interface Groups -> Add-> Interface Group

увеличить изображение

Рис. 2.41.

Командная строка:

add Interface InterfaceGroup lan_plus Members=core,lan

Правила фильтрования

Веб-интерфейс:

Rules -> IP Rules -> Add-> IP Rule Folder

Name: toFW2

Rules -> IP Rules -> toFW2

увеличить изображение

Рис. 2.42.

Командная строка:

add IPRuleFolderName=toFW2

cc IPRuleFolder <N folder>

add IPRule Action=Allow SourceInterface=lan SourceNetwork=lan/lan_net DestinationInterface=wan2 DestinationNetwork=remote/rem_lan Service=all_services Name=Allow_to

add IPRule Action=Allow SourceInterface=wan2 SourceNetwork=remote/rem_lan DestinationInterface=lan_plus DestinationNetwork=lan/lan_net Service=all_services Name=Allow_from

Статическая маршрутизация

Веб-интерфейс:

Routing -> Routing Tables -> main -> Add -> Route IPv4

увеличить изображение

Рис. 2.43.

Командная строка:

cc RoutingTable main

add Route Interface=wan2 Network=remote/rem_lan Gateway=wan2/wan2 Metric=100

Межсетевой Экран 2

Следует выполнить настройки, аналогичные настройкам, сделанным на Межсетевом Экране 1.

Проверка конфигурации

Проверяем доступ (команда ping) с lan-интерфейса межсетевого экрана 1 к рабочей станции в локальной сети (IP-адрес 192.168.1.122) и к lan-интерфейсу межсетевого экрана 1.

увеличить изображение

Рис. 2.44.

Лекция 5. Сегментирование сетей на канальном уровне

2.1 Использование технологии VLAN для создания подсетей

Рассмотрим использование технологии VLAN, которая позволяет сегментировать трафик на канальном уровне.

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

Рассмотрим типичную топологию сети небольшой организации (рис. 2.1).

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

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

увеличить изображение

Рис. 2.1. Типичная топология сети

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

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

Технология VLAN обладают следующими характеристиками:

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

2.2 Стандарт IEEE 802.1Q

Технология VLAN описана в стандарте IEEE 802.1Q. Этот стандарт определяет использование дополнительных полей кадра для хранения информации о принадлежности к VLAN при пересылке данного кадра по сети.

увеличить изображение

Рис. 2.2. Добавление vlan-заголовков в кадр

VLAN ID – это число от 0 до 4095, используемое для идентификации конкретной виртуальной локальной сети, которой принадлежит данный кадр. Ethernet-кадры могут принадлежать разным виртуальным локальным сетям, но проходить через один и тот же физический Ethernet-порт.

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

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

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

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

Характеристики VLAN на основе стандарта IEEE 802.1Q:

Гибкость при настройке и изменении топологии сети. Можно создавать необходимые комбинации виртуальных сетей, используя как один коммутатор, так и несколько коммутаторов с поддержкой стандарта IEEE 802.1Q, расположенных в разных сегментах сети. На Ethernet-порте коммутатора в заголовки пакетов добавляется тег, что позволяет создавать VLAN, проходящую через 802.1Q-совместимые коммутаторы.
Возможность не только добавлять, но и удалять метки из кадра позволяет использовать коммутаторы и сетевые устройства, которые не распознают эти метки.

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

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

2.3 Типовая топология сети с использованием VLAN

увеличить изображение

Рис. 2.3. Топология сети при использовании VLAN

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

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

В нашем случае рабочие станции отдела А подключены портам 02 и 03 Коммутатора 1. Эти порты входят в VLAN с VID 20 как немаркированные (untagged) порты. Рабочая станция отдела В подключена к порту 04 Коммутатора 1. Данный порт входит в VLAN с VID 30 как немаркированный (untagged) порт.

увеличить изображение

Рис. 2.4. Порты Коммутатора 1, к которым подключены рабочие станции

Рабочая станция отдела А подключена порту 02 Коммутатора 2. Данный порт входит в VLAN с VID 20 как немаркированный (untagged) порт. Рабочие станции отдела В подключены к портам 03 и 04 Коммутатора 2. Данные порты входят в VLAN с VID 30 как немаркированные (untagged) порты.

увеличить изображение

Рис. 2.5. Порты Коммутатора 2, к которым подключены рабочие станции

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

увеличить изображение

Рис. 2.6. Uplink-порт Коммутатора 1, подключенный к маршрутизатору или межсетевому экрану

увеличить изображение

Рис. 2.7. Uplink-порт Коммутатора 2, подключенный к маршрутизатору или межсетевому экрану

На физических Ethernet-портах маршрутизатора или межсетевого экрана создаются соответствующие vlan-интерфейсы.

увеличить изображение

Рис. 2.8. Создание vlan-интерфейсов на маршрутизаторе

Физический Ethernet-порт маршрутизатора может соединяться либо с коммутаторами (обычно управляемыми), которые поддерживают 802.1Q VLAN, либо с неуправляемыми коммутаторами или другим оборудованием без поддержки VLAN (например, с рабочими станциями пользователей). В первом случае соединения между межсетевым экра-ном и коммутаторами представляют собой vlan-каналы (магистральные каналы), по которым передается трафик всех vlan-сетей, настроенных на коммутаторах. Для этого на маршрутизаторе создается нужное количество vlan-интерфейсов, и каждому vlan-интерфейсу, созданному на Ethernet-порту межсетевого экрана и подключенному к коммутатору, назначается один из ID vlan-сетей, которые сконфигурированы на коммутаторе.

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

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

2.4 VLAN на основе портов

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

увеличить изображение

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

Если к маршрутизатору или межсетевому экрану подключены коммутаторы или другие устройства (например, рабочие станции пользователей), не поддерживающие технологию VLAN, вся сегментация локальной сети на виртуальные локальные сети и разграничение доступа между ними выполняется маршрутизатором. На маршрутизаторе создаются vlan-интерфейсы с соответствующими ID vlan-сетей. После этого каждый vlan-интерфейс привязывается к со-ответствующему Ethernet-порту. В этом случае маршрутизатор работает в режиме Port-based VLAN.

увеличить изображение

Рис. 2.10. Привязка vlan-интерфейса в Ethernet-порту

Стоит отметить, что в отличие от управляемых коммутаторов с поддержкой стандарта IEEE 802.1Q, которые могут одновременно обрабатывать маркированный и немаркированный трафик, в межсетевых экранах D-Link моделей DFL-260E и DFL-860E существует ограничение, связанное невозможность одновременной работы Ethernet-портов в режиме 802.1Q и Port-based VLAN. Vlan-интерфейсы этих моделей межсетевых экранов могут обрабатывать либо только маркированный входной трафик, либо только немаркированный. При использовании VLAN на основе портов каждый Ethernet-порт коммутатора может принадлежать единственной VLAN, не зависимо от того, какой пользователь или компьютер подключен к этому Ethernet-порту. Это означает, что все пользователи, подключенные к этому Ethernet-порту, будут членами одной VLAN. Принадлежность Ethernet-портов к VLAN статическая и может быть изменена только вручную.

Преимущества VLAN на основе портов:

Чаще всего применяются, если используется один коммутатор. Если необходимо разграничить трафик нескольких групп пользователей в пределах небольшой сети с использованием одного коммутатора, например, необходимо разделить трафик технического отдела и отдела продаж, то использование VLAN на основе портов является оптимальным решением.
Простота настройки. Создание виртуальных сетей на основе группирования Ethernet-портов не требует большой работы, достаточно каждому Ethernet-порту, входящему в определенную VLAN, присвоить один и тот же идентификатор VLAN ID.
Возможность изменения логической топологии сети без физического перемещения хостов. Достаточно просто изменить настройки Ethernet-порта, указав в настройках данного порта другой VLAN ID (например, VLAN ID технического отдела изменить на VLAN ID отдела продаж), и рабочая станция сразу получает возможность использовать ресурсы новой VLAN.
Каждый Ethernet-порт может входить только в одну VLAN.

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

Цель

Создать для разных отделов отдельные виртуальные сети.

Топология

увеличить изображение

Рис. 3.1.

Описание практической работы

Коммутатор 1

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

В нашем случае рабочие станции отдела А подключены портам 02 и 03 Коммутатора 1. Эти порты входят в vlan с VID 30 как немаркированные (untagged) порты. Рабочая станция отдела В подключена к порту 04 Коммутатора 1. Данный порт входит в vlan с VID 40 как немаркированный (untagged) порт.

увеличить изображение

Рис. 3.2.

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

увеличить изображение

Рис. 3.3.

Коммутатор 2

Рабочая станция отдела А подключена порту 02 Коммутатора 2. Данный порт входит в vlan с VID 30 как немаркированный (untagged) порт. Рабочие станции отдела В подключены к портам 03 и 04 Коммутатора 2. Данные порты входят в vlan с VID 40 как немаркированные (untagged) порты.

увеличить изображение

Рис. 3.4.

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

увеличить изображение

Рис. 3.5.

Межсетевой Экран

Объекты Адресной Книги

Создать объекты с IP-адресами vlan-интерфейса и vlan-сети.

Веб-интерфейс:

Object -> Address Book -> Add -> Address Folder

Name: vlan

Object -> Address Book -> vlan -> Add

увеличить изображение

Рис. 3.6.

Командная строка:

add Address AddressFolder vlan

cc Address AddressFolder vlan

add IP4Address vlan_30_ip Address=192.168.30.10

add IP4Address vlan_30_net Address=192.168.30.0/24

add IP4Address vlan_40_ip Address=192.168.40.10

add IP4Address vlan_40_net Address=192.168.40.0/24

VLAN-Интерфейс

Создать интерфейс vlan, связав его с lan-интерфейсом и указав VLAN ID.

Веб-интерфейс:

Interfaces -> VLAN -> Add

увеличить изображение

Рис. 3.7.

Командная строка:

add Interface VLAN vlan_30 Ethernet=lan IP=vlan/vlan_30_ip Network=vlan/vlan_30_net VLANID=30

add Interface VLAN vlan_40 Ethernet=lan IP=vlan/vlan_40_ip Network=vlan/vlan_40_net VLANID=40

Статическая маршрутизация

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

увеличить изображение

Рис. 3.8.

Следует также проверить созданные маршруты.

увеличить изображение

Рис. 3.9.

Правила фильтрования

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

Веб-интерфейс:

Interfaces -> Interface Groups

увеличить изображение

Рис. 3.10.

Командная строка:

set Interface InterfaceGroup dns_relay_int Members=vlan_30,vlan_40

Веб-интерфейс:

Objects -> Address Book -> dns_relay -> dns_net

увеличить изображение

Рис. 3.11.

Командная строка:

set IP4Group dns_net Members=vlan/vlan_30_net, vlan/vlan_40_net

Веб-интерфейс:

Objects ->Address Book -> dns_relay -> dns_ip

увеличить изображение

Рис. 3.12.

Командная строка:

set IP4Groupdns_netMembers=vlan/vlan_30_ip, vlan/vlan_40_ip

Проверка конфигурации

Проверяем созданную конфигурацию, используя команду ping.

увеличить изображение

Рис. 3.13.

Лекция 7. Сегментирование подсетей на основе port-based VLAN

Цель

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

Топология

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

увеличить изображение

Рис. 4.1.

Межсетевой Экран

Объекты Адресной Книги

Создать объекты с IP-адресами vlan-интерфейса и vlan-сети.

Веб-интерфейс:

Object -> Address Book -> Add -> Address Folder

Name vlan

Object -> Address Book -> vlan -> Add

увеличить изображение

Рис. 4.2.

Командная строка:

add Address AddressFolder vlan

cc Address AddressFolder vlan

add IP4Address vlan_30_ip Address=192.168.30.10

add IP4Address vlan_30_net Address=192.168.30.0/24

add IP4Address vlan_40_ip Address=192.168.40.10

add IP4Address vlan_40_net Address=192.168.40.0/24

VLAN-Интерфейс

Создать интерфейс vlan, связав его с lan-интерфейсом и указав VLAN ID.

Веб-интерфейс:

Interfaces -> VLAN -> Add

увеличить изображение

Рис. 4.3.

Командная строка:

add Interface VLANvlan_30 Ethernet=lan IP=vlan/vlan_30_ip Network=vlan/vlan_30_net VLANID=30

add Interface VLAN vlan_40 Ethernet=lan IP=vlan/vlan_40_ip Network=vlan/vlan_40_net VLANID=40

Далее следует указать номер порта коммутатора, на котором сконфигурирован данный vlan.

Веб-интерфейс:

Interfaces -> Switch Management

Поставить флаг Enable Port based VLAN.

В строке, соответствующей номеру порта, к которому подключен Ehternet-кабель, выбрать созданный vlan-интерфейс.

увеличить изображение

Рис. 4.4.

Командная строка:

set SwitchManagement Port1=vlan_30 Port2=vlan_30 Port3=vlan_40

Статическая маршрутизация

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

увеличить изображение

Рис. 4.5.

Следует также проверить созданные маршруты.

Рис. 4.6.

Правила фильтрования

Веб-интерфейс:

Interfaces -> Interface Groups

увеличить изображение

Рис. 4.7.

Командная строка:

set Interface InterfaceGroup dns_relay_int Members=vlan_30,vlan_40

Веб-интерфейс:

Objects -> Address Book -> dns_relay -> dns_net

увеличить изображение

Рис. 4.8.

Командная строка:

set IP4Group dns_net Members=vlan/vlan_30_net, vlan/vlan_40_net

Веб-интерфейс:

Objects -> Address Book -> dns_relay -> dns_ip

увеличить изображение

Рис. 4.9.

Командная строка:

set IP4Groupdns_netMembers=vlan/vlan_30_ip, vlan/vlan_40_ip

Проверка конфигурации

Проверяем созданную конфигурацию, используя команду ping.

увеличить изображение

Рис. 4.10.

Лекция 8. Технологии межсетевых экранов

3.1 Введение

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

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

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

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

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

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

Рассмотрим технологии предотвращения нежелательного доступа в локальную сеть и к информационным системам.

Сервисы безопасности, которые предотвращают нежелательный доступ, можно разбить на две категории:

Первая категория состоит из процедур входа, основанных на использовании разного рода аутентификаторов (паролей, аппаратных ключей, сертификатов и т.п.). Это позволяет разрешить доступ только законным пользователям. К этой категории относятся также различные межсетевые экраны (firewall), которые предотвращают атаки, основанные на использовании уязвимостей на различных уровнях стека протоколов TCP/IP.

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

Межсетевые экраны защищают компьютеры и сети от попыток несанкционированного доступа с использованием уязвимых мест, существующих в семействе протоколов ТСР/IP. Дополнительно они помогают решать проблемы безопасности, связанные с наличием уязвимостей в другом ПО, которое установлено на компьютерах в сети.

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

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

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

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

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

В данной главе:

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

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

Затем опишем различные типы окружения межсетевого экрана. Приведем примеры расположения межсетевых экранов и их взаимодей-ствий с другими инструментальными средствами безопасности. Также опишем дополнительные функции современных межсетевых экранов, такие как использование их в качестве конечных точек VPN, выполнение трансляции IP-адресов, фильтрации содержимого веб или e-mail.

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

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

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

Определить все требования, которые накладывает внешнее окружение на функционирование межсетевого экрана.

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

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

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

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

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

Управлять архитектурой, политиками, ПО и другими компонентами межсетевого экран следует в течение всего времени его функционирования.

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

3.2 Технологии межсетевых экранов

3.2.1 Стек протоколов

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

Классической моделью, описывающей принципы сетевого взаимодействия, является модель OSI (Open Systems Interconnection). Данная модель описывает сетевое взаимодействие как набор вложенных друг в друга уровней. Данные протоколов более высокого уровня расположены в теле протоколов более низкого уровня. Каждый уровень выполняет определенные функции, для которых разработаны специальные протоколы. В модели OSI определено семь уровней.

Таблица 3.1.
Уровень 7	Прикладной уровень
Уровень 6	Представительский уровень
Уровень 5	Сеансовый уровень
Уровень 4	Транспортный уровень
Уровень 3	Сетевой уровень
Уровень 2	Канальный уровень
Уровень 1	Физический уровень

Стек протоколов TCP/IP состоит из четырех уровней.

Таблица 3.2.
Уровень стека протоколов	Примеры протоколов
Прикладной уровень	Обеспечивает взаимодействие пользовательских приложений с сетью. Протоколы: HTTP, FTP, TFTP. DNS, SMTP, Telnet, SNMP и т.п.
Транспортный уровень	Обеспечивает передачу данных и коррекцию ошибок. Протоколы: TCP, UDP и т.п.
Сетевой уровень	Выполняет адресацию и маршрутизацию. Протоколы: IP, OSPF, ICMP, IGMP и т.п.
Канальный уровень	Упаковывает данные в стандартные кадры для передачи через физический уровень и обеспечивает проверку и коррекцию ошибок. Протоколы: Ethernet, PPP и т.п. На этом уровне работает ARP.

Канальный уровень (также называемый Data Link уровень) обеспечивает взаимодействие компонентов физической сети. Канальный уровень представляет собой реальную аппаратуру физического соединения и физическую среду, такую как Ethernet. Это уровень, который обычно называется локальной сетью или LAN. Это первый уровень, обладающей возможностью адресации, с помощью которой можно идентифицировать отдельный хост. Адреса назначаются на сетевые интерфейсы и называются МАС (Media Access Control) адресами. Ethernet-адрес, принадлежащий Ethernet-карте, является примером МАС-адреса. Межсетевые экраны редко имеют дело с данными на этом уровне. Блок данных, передаваемый на канальном уровне, называют кадром.

Сетевой уровень (также называемый IP-уровнем) маршрутизирует пакеты между локальными сетями. IPv4 является основным протоколом сетевого уровня для TCP/IP. Другими часто используемыми протоколами сетевого уровня являются IPv6 и IGMP. Данный уровень отвечает за доставку пакетов между отдельными локальными сетями, соединенными маршрутизаторами. Такие сети часто обозначаются WAN (Wide Area Network). Адреса данного уровня называются IP-адресами; они обычно являются уникальными, но при определенных обстоятельствах, например, при трансляции сетевых адресов (Network Address Translation – NAT), возможны ситуации, когда различные физические системы имеют один и тот же IP-адрес. Блок данных, передаваемый на сетевом уровне, называют дейтаграммой.

Транспортный уровень предоставляет сервисы, ориентированные на соединение, которые используются для передачи данных между сетями. Часть протоколов (а именно ТСР) могут гарантировать надежность соединения. Примерами протоколов транспортного уровня являются ТСР и UDP. На транспортном уровне возникает понятие сессии как потока данных между двумя приложениями. Для сессии определено понятие портов, которые являются конечными точками сессии: номер порта источника опре-деляет конечную точку коммуникационной сессии на исходной системе; номер порта назначения определяет конечную точку коммуникационной сессии на системе назначения. Хост может иметь с другими хостами практически любое число сессий на транспортном уровне.

Прикладной уровень посылает и получает данные конкретных приложений, таких как DNS, HTTP, SMTP. Прикладной уровень сам может состоять из нескольких подуровней. Например, SMTP или НТТР могут инкапсулировать другие форматы, такие как HTML.

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

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

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

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

3.2.2 Состояния ТСР-соединения

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

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

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

Для идентификации начальной и конечной точек ТСР-соединения вводится понятие номера порта. Номера портов выбираются независимо для каждого ТСР-соединения, при этом они не обязательно должны быть уникальными. Пара (IP-адрес, порт) называется сокетом.

Каждый конец ТСР-соединения является либо клиентом, либо сервером. Соединение инициируется клиентом. Сервер ждет установления соединения от клиента, в этом случае говорят, что сервер слушает порт. ТСР-соединение может быть открыто либо в пассивном – сервером, либо в активном режиме – клиентом.

Сервер может использовать любые номера портов. Тем не менее определены некоторые базовые принципы назначения номеров портов. Существуют "хорошо известные" номера портов, которые обычно соответствуют определенным приложениям. При инициализации ТСР-сессии на стороне клиента открывается порт, номер которого в соответствии со спецификацией протокола ТСР должен быть в диапазоне от 1023 до 65535. Номер порта на стороне клиента может быть каждый раз разным.

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

Установление ТСР-соединения происходит с использованием так называемого "тройного рукопожатия". Соединение инициирует клиент, посылая пакет с установленным битом SYN. Сервер отвечает клиенту пакетом с установленными битами SYN и ACK. Сервер также передает начальный порядковый номер в поле Sequence Number. Наконец, клиент посылает серверу сообщение с установленным битом ACK, в поле Sequence Number указывает свой начальный номер, в поле Acknowledgement Number указывает полученный от сервера начальный порядковый номер, увеличенный на единицу.

В течение своего жизненного цикла соединение проходит через несколько состояний.

Состояния на стороне клиента:

CLOSED
SYN-SENT
ESTABLISHED
FIN-WAIT-1
CLOSE-WAIT
FIN-WAIT-2
CLOSING
LAST-ACK
CLOSED

Состояния на стороне сервера:

CLOSED
LISTEN
SYN-RESEIVED
ESTABLISHED
FIN-WAIT-1
CLOSE-WAIT
FIN-WAIT-2
CLOSING
TIME-WAIT
CLOSED

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

LISTEN – состояние сервера, в котором он ожидает запрос от клиента на создание соединения.

SYN-SENT – состояние клиента, в котором он ожидает ответа от сервера после посылки запроса на создание соединения.

SYN-RECEIVED – состояние сервера, в котором он ожидает подтверждения после того, как и клиент, и сервер получили и послали запрос на создание соединения.

ESTABLISHED – состояние как клиента, так и сервера, которое представляет собой открытое соединение: полученные данные доставляются на прикладной уровень. Обычное состояние при пересылке данных по соединению.

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

FIN-WAIT-1 – состояние инициатора закрытия соединения, при котором данной стороной был послан пакет с флагом FIN. Инициатор закрытия соединения ожидает подтверждения на запрос закрытия.

CLOSE-WAIT – состояние отвечающей стороны закрытия соединения, при котором было послано подтверждение ACK на запрос закрытия (FIN). При этом канал становится симплексным: передача возможна только в одном направлении – от отвечающей стороны закрытия соединения, т.е. от того, кто послал подтверждение ACK.

FIN-WAIT-2 – состояние инициатора закрытия соединения, при котором было получено подтверждение ACK запроса закрытия соединения от удаленной стороны. После этого данная сторона ждет получения пакета с установленным флагом FIN. При получении пакета с флагом FIN канал считается окончательно разрушенным.

LAST-ACK – состояние отвечающей стороны закрытия соединения, при котором послано подтверждение (пакет с установленным флагом FIN) завершения соединения, ранее посланного удаленной стороне.

CLOSING – обе стороны инициировали закрытие соединения одновременно: после отправки пакета с флагом FIN инициатор закрытия получает пакет с флагом FIN.

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

ТСР-соединение переходит из одного состояния в другое в результате возникновения событий. Событиями являются вызовы функций OPEN, SEND, RECEIVE, CLOSE, ABORT и STATUS, входящие пакеты, содержащие флаги SYN, ACK, RST и FIN, а также таймауты.

3.2.3 Классификация межсетевых экранов

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

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

Фильтрование пакетов

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

Управление трафиком осуществляется на основе анализа следующей информации, содержащейся в пакете:

IP-адрес источника в пакете – адрес хоста, с которого пришел пакет.
IP-адрес получателя в пакете – адрес хоста, которому предназначен пакет.
Транспортный протокол, используемый для взаимодей-ствия хостов отправителя и получателя, такой как ТСР, UDP или ICMP.
Возможно некоторые характеристики коммуникационной сессии транспортного уровня, такие как порты источника и получателя (например, ТСР 80 для порта получателя и ТСР 1320 для порта источника).
Интерфейс, через который проходит пакет, и направление (входящий или исходящий).

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

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

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

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

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

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

Пограничные маршрутизаторы.
ОС.
Персональные межсетевые экраны.

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

увеличить изображение

Рис. 3.1. Пример топологии сети с использованием пакетного фильтра и DMZ

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

Порт на стороне сервера имеет фиксированный номер. На стороне клиента открывается порт, номер которого может быть каждый раз разным.

увеличить изображение

Рис. 3.2. Необходимость открывать порты с «большими» номерами на стороне клиента

увеличить изображение

Рис. 3.3. Набор правил пакетного фильтра без анализа состояния

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

Преимущества пакетных фильтров:

Основным преимуществом пакетных фильтров является их скорость.
Пакетный фильтр прозрачен для клиентов и серверов, так как не разрывает ТСР-соединение.

Недостатки пакетных фильтров:

Так как пакетные фильтры не анализируют данные более высоких уровней, они не могут предотвратить атаки, которые используют уязвимости, специфичные для приложения. Например, пакетный фильтр не может блокировать конкретные команды приложения; если пакетный фильтр разрешает данный трафик для приложения, то все операции, определенные в данном приложении, будут разрешены.
В логах пакетного фильтра содержится информация только о параметрах сетевого и транспортного уровней. Логи пакетного фильтра обычно содержат ту же информацию, которая использовалась при принятии решения о возможности доступа (адрес источника, адрес назначения, тип трафика и т.п.).
Большинство пакетных фильтров не поддерживают возможность аутентификации пользователя. Данная возможность обеспечивается межсетевыми экранами, анализирующими более высокие уровни.
Пакетные фильтры обычно уязвимы для атак, которые используют такие уязвимости ТСР/IP, как подделка (spoofing) сетевого адреса. Многие пакетные фильтры не могут определить, что в сетевом пакете изменена адресная информация транспортного уровня. Spoofing-атаки обычно выполняются для обхода управления доступом, осуществляемого межсетевым экраном.
Пакетные фильтры трудно конфигурировать. Можно случайно переконфигурировать пакетный фильтр для разрешения типов трафика, источников и назначений, которые должны быть запрещены.
Так как номер порта клиента может быть любым, так называемым "большим номером" (с 1023 до 65535), то на межсетевом экране приходится открывать все порты с номерами больше 1023.

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

Практически все современные межсетевые экраны включают большее количество возможностей, сейчас трудно найти межсетевой экран, который имеет возможности только пакетного фильтра. Примером может являться маршрутизатор, осуществляющий проверку списка контроля доступа для управления сетевым трафиком. Высокая производительность пакетных фильтров также способствует тому, что они реализуются в устройствах, обеспечивающих высокую доступность и особую надежность; некоторые производители предлагают аппаратные и программные решения как высоко доступные, так и особо надежные. Также большинство SOHO (Small Office Home Office) устройств межсетевых экранов и межсетевых экранов, встроенных по умолчанию в ОС, предоставляют возможности пакетных фильтров.

Пакетные фильтры с анализом состояния

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

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

В простейшем случае межсетевой экран пропускает любой пакет, если он считает, что пакет является частью открытого соединения (или соединения, которое еще не полностью установлено). Хотя многие межсетевые экраны точно могут определить состояние таких протоколов, как ТСР и UDP, и они могут блокировать пакеты, которые не соответствуют состоянию протокола. Например, часто межсетевой экран проверяет такие параметры, как последовательные номера ТСР, и отбрасывает пакеты, номера которых вне ожидаемого диапазона. Если межсетевой экран предоставляет сервис NAT, то информация NAT часто также содержится в таблице состояний.

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

увеличить изображение

Рис. 3.4. Пример таблицы состояний пакетного фильтра с анализом состояний

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

увеличить изображение

Рис. 3.5. Пример таблицы состояний для протокола UDP

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

увеличить изображение

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

Преимущества межсетевых экранов с анализом состояния:

Разрешают прохождение пакетов только для установленных соединений;
Прозрачны для клиентов и серверов, так как не разрывают ТСР-соединение.

Недостатки межсетевых экранов с анализом состояния:

Реально используются только в сетевой инфраструктуре TCP/IP. Хотя надо отметить, что межсетевые экраны с анализом состояния можно реализовать в других сетевых протоколах тем же способом, что и пакетные фильтры.

Лекция 9. Политики без проверки состояния

Цель

Создать политику без проверки состояния, которая должна разрешать http-трафик из локальной сети 192.168.1.0/24 к веб-серверу, расположенному в DMZ и имеющему IP-адрес 172.17.100.130.

Топология сети

увеличить изображение

Рис. 5.1.

Описание практической работы

Объекты Адресной Книги

В адресную книгу следует добавить объект, указывающий IP-адрес веб-сервера.

Веб-интерфейс:

Object ->Address Book -> dmz

увеличить изображение

Рис. 5.2.

Командная строка:

cc Address AddressFolder dmz

add IP4Address web_server Address=172.17.100.130

Правила фильтрования

Правила без проверки состояния будем создавать на межсетевом экране 1 (МЭ 1).

Создаем сервис, в котором в качестве портов отправителя указаны все необходимые порты НТТР, а в качестве портов получателя указаны все непривилегированные порты (так называемые порты с "большими" номерами).
Веб-интерфейс:
Object -> Services -> Add

увеличить изображение

Рис. 5.3.

Командная строка:
add Service ServiceTCPUDP all_tcp_unpriv DestinationPorts=1024-65535 SourcePorts=80,8080,443
Создаем два правила фильтрования с действием FwdFast. В первом правиле в качестве сервиса указываем стандартный сервис http-all, в котором в качестве портов отправителя указаны все порты с непривилегированными ("большими") номерами, а в качестве портов получателя указаны порты, необходимые веб-серверу. Во втором правиле в качестве сервиса указываем созданный в п.1 сервис. Для входящего трафика (web_in) открыты только порты, необходимые для протокола http. Для исходящего трафика (web_out) открыты все непривилегированные порты, так как на стороне клиента порт может быть любой.
Веб-интерфейс:
Rules -> IP Rules -> Add -> IP Rule Folder
Name webS
Rules -> IP Rules -> webS -> Add

увеличить изображение

Рис. 5.4.

Командная строка:
add IPRuleFolderName=webS
cc IPRuleFolder <N folder>
add IPRule Action=FwdFast SourceInterface=lan SourceNetwork= lan/lan_net DestinationInterface=dmz DestinationNetwork= dmz/web_server Service=http-all Name=web_in
add IPRule Action=FwdFast SourceInterface=dmz SourceNetwork=dmz/web_server DestinationInterface=lan DestinationNetwork=lan/lan_net Service=all_tcp_unpriv Name=web_out

Статическая маршрутизация

Правила маршрутизации созданы автоматически при определении параметров Ethernet-интерфейсов.

Проверка конфигурации

Используем браузер, в качестве адреса указываем IP-адрес.

увеличить изображение

Рис. 5.5.
Проверяем, что таблица состояний для интерфейса dmz пустая.

увеличить изображение

Рис. 5.6.

Лекция 10. Прикладной уровень

Межсетевые экраны прикладного уровня

Современная тенденция анализа состояний состоит в добавлении возможностей анализа состояний протокола, которое некоторыми производителя называется глубоким анализом пакета (deep packet inspection). Анализ состояния протокола добавляет в стандартный анализ состояния базовую технологию обнаружения вторжения, которая анализирует протокол на прикладном уровне, сравнивая поведение протокола с определенными производителем профилями и определяя отклонения в поведении. Это позволяет межсетевому экрану разрешать или запрещать доступ, основываясь на том, как выполняется приложение. Например, межсетевой экран прикладного уровня может определить, что почтовое сообщение содержит неразрешенный тип присоединенного файла (такой как выполняемый файл). Другая возможность состоит в том, что он может блокировать соединения, в которых выполняются определенные действия (например, присутствуют команды put в FTP). Данная возможность также позволяет разрешать или запрещать передавать веб-страницы в зависимости от конкретных типов содержимого, такого как Java или ActiveX, или проверять, что SSL сертификаты подписаны конкретным СА.

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

Другая возможность состоит в проверке входных данных для отдельных команд, такой как минимальная и максимальная длина аргументов. Например, аргумент имени пользователя длиной в 1000 символов является подозрительным или если он содержит бинарные данные. Межсетевые экраны прикладного уровня доступны для многих протоколов, включая НТТР, БД (SQL), почтовые (SMTP, POP, IMAP), VoIP и XML.

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

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

увеличить изображение

Рис. 3.7. Пример создания правил шлюза прикладного уровня (ALG)

увеличить изображение

Рис. 3.8. Параметры правила шлюза прикладного уровня

увеличить изображение

Рис. 3.9. Создание правила прикладного уровня

увеличить изображение

Рис. 3.10. Добавление проверок прикладного уровня в правило межсетевого экрана

увеличить изображение

Рис. 3.11. Тестирование выполнения проверок прикладного уровня (запрет загрузки gif-файлов)

Преимущества межсетевых экранов прикладного уровня:

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

Недостатки межсетевых экранов прикладного уровня:

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

Прокси-шлюзы прикладного уровня

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

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

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

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

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

Преимущества прокси-серверов прикладного уровня:

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

Более развитая функциональность прикладного прокси имеет также несколько недостатков по сравнению с пакетными фильтрами

Недостатки прокси-серверов прикладного уровня:

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

Выделенные прокси-сервера

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

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

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

увеличить изображение

Рис. 3.12. Пример топологии сети с выделенным прокси-сервером

Конечные точки VPN

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

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

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

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

Гибридные технологии межсетевых экранов

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

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

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

Расширенное управление доступом в сеть

Часто требованием к межсетевым экранам, которые расположены на границы сетевого периметра, является необходимость разрешения входящих соединений не только после выполнения аутентификации удаленного пользователя, но и проверки параметров безопасности пользовательского компьютера. Такая проверка, называемая обычно управлением доступом в сеть (network access control – NAC) или защитой доступа в сеть (network access protection – NAP) разрешает доступ не только на основе пользовательских креденциалов, но и на проверке "жизнеспособности" пользовательского компьютера. Проверка жизнеспособности обычно состоит из проверки того, что выполнены определенные условия организационной политики:

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

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

Унифицированное управление угрозами

Многие межсетевые экраны имеют возможность централизованного управления несколькими сетевыми устройствами. Идея состоит в том, что установить и поддерживать политику в единственной системе легче, чем на нескольких системах, которые развернуты в разных местах в сети. Типичная система унифицированного управления угрозами (Unified Threat Management – UTM) включает межсетевой экран с возможностями определения и удаления вредоносного ПО на находящихся под его управлением хостах, определения сетевых проблем, блокирования нежелательного трафика и т.п. Существуют аргументы за и против совмещения нескольких функций в одной системе. Например, развертывание UTM уменьшает сложность, так как в этом случае единственная система отвечает за политику безопасности нескольких сетевых устройств. Но при этом может существенно ухудшиться производительность: единственная система, решающая несколько задач, должна иметь достаточное количество ресурсов, таких как ЦП и память, для выполнения каждой задачи. В одном случае можно найти определенный баланс для использования UTM, в другом случае лучше использовать несколько межсетевых экранов в одном сегменте сети.

Межсетевые экраны для веб-приложений

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

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

Межсетевые экраны для виртуальных инфраструктур

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

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

Межсетевые экраны для отдельных хостов и домашних сетей

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

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

Межсетевые экраны для хостов доступны как часть серверных ОС, таких как Linux, Windows, BSD, Mac OS X Server, они также могут быть установлены в качестве дополнительного компонента от третьих фирм. Политика безопасности межсетевого экрана для отдельного хоста разрешает только необходимый трафик, защищая сервер от вредоносной деятельности всех хостов, включая тех, которые расположены в той же самой подсети или в подсетях, которые не отделены межсетевым экраном. Может быть также полезно ограничение исходящего трафика для предотвращения распространения вредоносного ПО, которым может быть инфицирован хост. Межсетевые экраны для отдельного хоста обычно создают достаточно подробные логи и могут быть сконфигурированы для выполнения управления доступом на основе адреса и на основе приложения. Многие межсетевые экраны для отдельного хоста также функционируют как системы предотвращения вторжения (IPS), т.е. после определения атаки предпринимают действия по остановке атакующего и предотвращению нанесения вреда защищаемому хосту.

Персональным межсетевым экраном называется ПО, которое выполняется на настольном компьютере или ноутбуке с установленной на нем пользовательской ОС, такой как Windows Vista/7, Macintosh OS X или Linux. Персональный межсетевой экран аналогичен межсетевому экрану для отдельного хоста, но компьютер защищается в интересах конечного пользователя, интерфейс обычно более дружественный. Персональный межсетевой экран предоставляет дополнительный уровень безопасности для персонального компьютера, расположенного как внутри, так и за пределами сетевого периметра (например, для мобильных пользователей), так как он может ограничивать входящие соединения и часто может также ограничивать исходящие соединения. Это позволяет не только защитить персональный компьютер от внешних атак, но и ограничить распространение вредоносного ПО с инфицированного компьютера и использование нелицензионного ПО.

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

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

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

Устройства персональных межсетевых экранов

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

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

Преимущества межсетевых экранов для отдельного хоста:

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

Недостаток межсетевых экранов для отдельного хоста:

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

3.2.4 Ограниченность анализа межсетевого экрана

Межсетевые экраны эффективны только для трафика, который они могут анализировать. Независимо от выбранной технологии межсетевого экрана, если он не может понимать проходящий через него трафик, он не может осмысленно разрешить или запретить его. Много сетевые протоколы используют криптографию, чтобы скрыть содержимое. Примерами таких протоколов являются IPsec, TLS, SSH и SRTP (Secure Real-time Transport Protocol). Межсетевые экраны не могут также читать зашифрованные прикладные данные, например, если почтовое сообщение зашифровано с помощью протоколов S/MIME или OpenPGP. Другим примером ограничения является то, что многие межсетевые экраны не понимают туннелированный трафик, даже если он не зашифрован. Например, IPv6 трафик может быть туннелирован в IPv4 многими различными способами. Содержимое даже может быть незашифровано, но если межсетевой экран не понимает используемый механизм туннелирования, трафик не может быть проинтерпретирован.

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

Лекция 11. Политики межсетевых экранов и рекомендации

3.3 Политика межсетевого экрана

Политика межсетевого экрана определяет, как межсетевой экран будет обрабатывать сетевой трафик для определенных IP-адресов и диапазонов адресов, протоколов, приложений и типов содержимого (например, активного содержимого). Перед разработкой политики межсетевого экрана следует проанализировать риски и определить типы трафика, которые необходимы организации. Анализ риска должен основываться на оценки угроз и уязвимостей.

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

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

3.3.1 Политики, основанные на IP-адресах и протоколах

Политика межсетевого экрана должна разрешать прохождение только необходимых IP-протоколов, например, ICMP, TCP и UDP. Другими примерами являются протоколы IPsec (ESP и АН) и протоколы маршрутизации, которым тоже может быть необходимо проходить межсетевой экран. Все остальные IP-протоколы по умолчанию запрещены.

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

IP-адреса и другие характеристики IP

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

Трафик с недействительными IP-адресами источника и получателя должен всегда блокироваться, независимо от расположения межсетевого экрана. Например, недействительными IPv4-адресами являются адреса с 127.0.0.0 по 127.255.255.255 (также известные как localhost адреса) и 0.0.0.0 (интерпретируемый некоторыми ОС как локальный или широковещательный (broadcast) адрес). Эти адреса не должны использоваться в сети.
На сетевом периметре должен блокироваться трафик с недействительным адресом источника для входящего трафика и недействительным адресом получателя для исходящего трафика. Данный трафик часто связан с вредоносным ПО, spoofing и DoS атаками или попытками переконфигурировать оборудование. Большинство типов недействительных внешних адресов являются IPv4-адреса в диапазоне, определенном в RFC 1918 как адреса для частных сетей. Этими диапазонами являются с 10.0.0.0 по 10.255.255.255 (10.0.0.0/8 в CIDR нотации), с 172.16.0.0 по 172.31.255.255 (172.16.0.0/12) и с 192.168.0.0 по 192.168.255.255 (192.168.0.0/16).
На границы сетевого периметра должен блокироваться входящий трафик, если у него адрес источника принадлежит внутренней сети. Может выполняться преобразование адресов, чтобы разрешить внутренним хостам с частными адресами взаимодействовать с внешними хостами, но частные адреса не должны проходить через сетевой периметр.
Исходящий трафик с недействительными адресами источника должен блокироваться (это часто называется выходным фильтрованием), так как скомпрометированные системы могут использоваться для выполнения атак на другие системы в интернете. Атаки, которые используют недействительные адреса источника, остановить гораздо труднее. Блокирование межсетевым экраном данного типа трафика снижает эффективность подобных атак.
Входящий трафик, адресом получателя в котором является сам межсетевой экран, должен блокироваться, если только межсетевой экран не предоставляет сервисы для входящего трафика, которые требуют прямого соединения – например, если межсетевой экран действует как прикладной прокси.

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

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

Некоторые производители выделяют в отдельную группу правила, проверяющие доступность IP-адреса источника в пакете с интерфейса, на который пришел данный пакет. Это так называемые правила доступа – Access Rules. Эти правила позволяют предотвратить одну из наиболее распространенных атак – атаку подделки IP-адреса источника (IP Spoofing). В подобных атаках нарушитель изменяет IP-адрес источника на IP-адрес доверенного хоста, что может позволить пакету соответствовать правилам фильтрования для доверенных хостов. Хотя в этом случае источник не может получать возвращаемые пакеты и завершить установление соединения, возникает потенциальная угроза DoS-атак.

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

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

IPv6

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

Некоторые межсетевые экраны не могут обрабатывать трафик IPv6; другие имеют ограниченные возможности фильтрования трафика IPv6. Если во внутренней сети необходим трафик IPv6, то межсетевой экран также должен иметь возможности в фильтровании этого трафика. Такие межсетевые экраны должны обладать следующими возможностями:

Межсетевой экран должен иметь возможность указывать IPv6 адреса в правилах фильтрования.
Для облегчения администрирования интерфейс администратора должен позволять клонировать IPv4 правила в IPv6 правила.
Межсетевой экран должен иметь возможность фильтровать протокол ICMPv6, как описано в RFC 4890.
Межсетевой экран должен иметь возможность блокировать относящиеся к IPv6 протоколы, такие как v6-to-v4 туннелирование, Teredo и ISATAP, если они не требуются.
Многие сайты туннелируют IPv6 пакеты в IPv4 пакеты. Это чаще всего используется сайтами, которые экспериментируют с IPv6, потому что в настоящий момент легче получать IPv6 от туннелирующего брокера с помощью v6-to-v4 туннеля, чем получать исходный IPv6 от ISP. Существует большое число способов сделать это, при этом стандарты туннелирования только разрабатываются. Если межсетевой экран умеет анализировать содержимое IPv4 пакетов, ему необходимо знать, как анализировать трафик, который туннелирован каким-либо из способов. Следствием этого является то, что если межсетевой экран используется для запрещения прохождения IPv6 в сеть, то он должен распознавать и блокировать все формы v6-to-v4 туннелирования.

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

Для межсетевых экранов, которые допускают использование IPv6, трафик с недействительным IPv6 адресами источника и получателя должен блокироваться – аналогично блокированию трафика с недействительными IPv4 адресами. Следует заметить, что определить список недействительных IPv6 адресов гораздо сложнее. Также IPv6 позволяет администратору назначать адреса различными способами. Это означает, что конкретный диапазон адресов, связанный с организацией, может иметь огромное число недействительных представлений, и только несколько представлений будут действительными. Перечисление всех недействительных IPv6 адресов является более сложной задачей, чем перечисление недействительных IPv4 адресов.

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

Протоколы ТСР и UDP

Прикладные протоколы могут использовать ТСР, UDP или оба протокола. Прикладной сервер обычно слушает один или несколько фиксированных ТСР- или UDP-портов. Некоторые приложения используют один порт, но многие приложения используют несколько портов. Например, хотя SMTP использует ТСР-порт 25 для отправки почты, он использует также порт 587 для передачи почты. Аналогично, FTP использует по крайней мере два порта, один из которых не предсказуем. Большинство веб-серверов используют ТСР порт 80, но часто также используются дополнительные порты, такие как ТСР-порт 8080. Некоторые приложения используют как ТСР, так и UDP; например, поиск (lookup) DNS может происходить и через UDP порт 53, и через ТСР порт 53. Прикладные клиенты обычно используют любой порт из широкого диапазона портов.

С учетом этого в наборе правил для межсетевого экрана для входящего ТСР и UDP трафика по умолчанию должна использоваться запрещающая политика (Drop). Для исходящего ТСР- и UDP-трафика обычно используется менее строгая политика, потому что в большинстве случаев локальным пользователям разрешается доступ ко внешним приложениям.

Протокол ICMP

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

Для предотвращения вредоносной деятельности межсетевые экраны, расположенные на границе сетевого периметра, должны запрещать весь входящий и исходящий ICMP трафик, за исключением отдельных типов и кодов, которые должны быть специально разрешены. Для ICMP IPv4 сообщения типа 3 не должны фильтроваться, потому что они используются для сетевой диагностики. Команды ping (ICMP код 8) является важной диагностикой сети, но входящие ping часто блокируются политикой межсетевого экрана, чтобы предотвратить изучение внутренней топологии сети атакующим. Для ICMP в IPv6 многие типы сообщений должны быть разрешены.

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

увеличить изображение

Рис. 3.13. Пример конфигурирования параметров ICMP-протокола

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

Организации, которые разрешают использование IPSec, должны блокировать ESP и АН за исключением определенных адресов во внутренней сети – это адреса шлюзов IPSec, которые будут являться конечными точками VPN. Реализация такой политики будет требовать от сотрудников организации получить соответствующее разрешение на доступ к маршрутизаторам IPSec. Это также уменьшит количество зашифрованного трафика во внутренней сети, который не может быть проанализирован.

Политики, основанные на приложениях

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

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

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

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

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

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

увеличить изображение

Рис. 3.14. Пример конфигурирования параметров НТТР-протокола

увеличить изображение

Рис. 3.15. Пример 2 конфигурирования параметров НТТР-протокола

3.3.2 Политики, основанные на идентификации пользователя

Традиционное фильтрование пакетов не знает идентификацию пользователя, который устанавливает соединение, поэтому без дополнительных возможностей технологии межсетевых экранов не могут иметь политики, которые разрешают или запрещают доступ на основе этих идентификаций. Однако существуют технологии межсетевых экранов, которые могут видеть эти идентификации и, следовательно, устанавливать политики, основанные на аутентификации пользователя. Одним из наиболее общих способов использовать на межсетевом экране политику, основанную на идентификации пользователя, является использование VPN. Как IPSec VPN, так и SSL VPN имеют много способов аутентификации пользователей, такие как секреты, определяемые для каждого пользователя, многофакторная аутентификация (например, криптографические токены, основанные на времени и защищенные PIN-кодом) или цифровые сертификаты, выданные каждому пользователю. Популярным методом для межсетевых экранов также становится NAC (Network Access Control), с помощью которого разрешается или запрещается доступ пользователей к отдельным сетевым ресурсам. Кроме того, прикладные межсетевые экраны могут разрешать или запрещать доступ, основываясь на аутентификации пользователя самим приложением.

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

увеличить изображение

Рис. 3.16. Пример политики, основанной на идентификации пользователя

3.3.3 Политики, основанные на сетевой активности

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

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

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

3.3.4 Основные рекомендации

Просуммируем основные рекомендации данного раздела:

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

Лекция 12. Возможности NAT

3.4 Межсетевые экраны с возможностями NAT

3.4.1 Используемая терминология и основные понятия

Частные и внешние сети

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

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

Частной сетью будем называть сеть, в которой хосты имеют зарезервированные для частных сетей адреса. В RFC 1918 для частных сетей определены три диапазона IP-адресов:

С 10.0.0.0 по 10.255.255.255 (10.0.0.0/8 в CIDR нотации)

С 172.16.0.0 по 172.31.255.255 (172.16.0.0/12 в CIDR нотации)

С 192.168.0.0 по 192.168.255.255 (192.168.0.0/16 в CIDR нотации)

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

Термин "прозрачная маршрутизация" используется для описания маршрутизации, выполняемой NAT. Традиционная маршрутизация, выполняемая традиционными маршрутизаторами, отличается тем, пакеты маршрутизируются внутри одной области адресов.

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

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

Прозрачная маршрутизация между хостами в частной области и внешней области – основная функция маршрутизатора NAT.

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

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

NAT рассматривается исключительно для IPv4.

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

Стандартные режимы IPSec, в которых IP-адреса конечных точек не изменяются, не работают с NAT. Такие протоколы как АН и ESP защищают содержимое IP-заголовков от изменения, а одна из основных функций NAT как раз и состоит в изменении адресов в IP-заголовке пакета.

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

Другим примером, когда NAT взаимосвязан с политикой безопасности, является возможность идентификации источника трафика в логах межсетевого экрана. Если используется NAT, он должен записывать в логи частный адрес, а не публичный адрес, на который NAT изменил частный. В противном случае в логах будут некорректно определяться многие хосты, которые будут представлены там единственным публичным адресом.

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

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

Понятие сессии

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

Можно считать, что сессия – это совокупность трафика, который обрабатывается как единое целое. ТСР/UDP сессии однозначно определяются IP-адресом и портом источника и IP-адресом и портом получателя. Сессии ICMP-запросов определяются IP-адресом источника, ID ICMP-запроса и IP-адресом получателя. Все остальные сессии характеризуются IP-адресами источника и получателя и IP-протоколом.

Трансляция адресов, выполняемая NAT, основана на сессии и включает преобразование входящих и исходящих пакетов, принадлежащих сессии.

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

Первый пакет ТСР-сессии содержит информацию о начале сессии. Первый пакет ТСР-сессии можно распознать по наличию бита SYN и отсутствию бита ACK во флагах ТСР. Все ТСР-пакеты, за исключением первого пакета, должны иметь установленный бит ACK.

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

Завершение ТСР-сессии происходит при получении флага FIN обеими сторонами сессии или когда одна из сторон посылает пакет с флагом RST. Однако при выполнении NAT, так как невозможно знать, что пакеты действительно доставлены получателю (они могут быть отброшены между хостом, выполняющим NAT, и получателем), невозможно точно знать, что пакеты, содержащие FIN или RST, будут последними пакетами в сессии (так как могут быть повторные передачи). Следовательно, надо предполагать, что сессия завершена только по истечении 4 минут (2 * на максимальное время жизни пакета) с момента определения завершения.

Заметим также, что возможно, что ТСР-сессия будет завершена без обнаружения этого события устройством, выполняющим NAT (например, в случае перезапуска одной или обеих сторон). Следовательно, сбор мусора является необходимым сервисом NAT, чтобы очистить неиспользуемые соединения. Однако в общем случае невозможно различить соединение, по которому долгое время ничего не передается, от соединений, которые больше не существуют. В случае UDP-сессий не существует единственного способа определить завершения сессии, так как это во многом зависит от приложения.

Для определения завершения сессии используются различные эвристические подходы. Можно предположить, что ТСР-сессии, которые не используются, скажем, в течение 24 часов, и не-ТСР-сессии, которые не используются в течение пары минут, завершены. Часто такие предположения верные, но могут существовать случаи, когда предположения оказались неверными. Период простоя может существенно отличаться как от приложения к приложению, так и от сессии к сессии в одном приложении. Следовательно, таймауты сессии должны быть конфигурируемы. Но даже и в этом случае нет гарантии, что может быть найдено приемлемое значение. Не существует также гарантии, что завершенная с точки зрения NAT сессия будет завершенной с точки зрения приложения.

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

Шлюз прикладного уровня (ALG)

Не для всех приложений можно использовать NAT; в частности, это касается тех приложений, которые используют IP-адреса и ТСР/UDP порты в содержимом пакета. ALG является прикладным агентом, который позволяет приложению, выполняющемуся на хосте в одной адресной области, прозрачно взаимодействовать с противоположной стороной, выполняющейся на хосте в другой области. ALG должен взаимодействовать с NAT, чтобы установить состояние NAT, использовать информацию состояния NAT, модифицировать специфичное для приложения содержимое или выполнить что-то еще, что необходимо для выполнения приложения при пересылке пакетов из одной адресной области в другую.

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

3.4.2 Статическое и динамическое назначение адресов

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

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

NAT преобразует адреса в частной сети в адреса во внешней сети для обеспечения прозрачной маршрутизации дейтаграмм между разными адресными областями. В некоторых случаях преобразование может быть сделано и для идентификаторов транспортного уровня (такие как порты ТСР/UDP). Преобразование адреса выполняется при инициализации сессии. Может существовать два способа назначения адресов.

При статическом назначении адреса существует отображение один-к-одному между адресами частной сети и адресами внешней сети в течение всего времени функционирования NAT.

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

3.4.3 Варианты выполнения NAT

Существует много вариантов выполнения преобразования адресов. Перечисленные ниже способы не претендуют на полноту, но описывают основные подходы.

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

увеличить изображение

Рис. 3.17. Сценарий выполнения NAT

Хост-A с адресом Addr-A расположен в области с частными адресами, которая обозначена как сеть N-Pri. N-Pri изолирована от внешней сети с помощью маршрутизатора NAT. Хост-X с адресом Addr-X расположен во внешней области, обозначенной как сеть N-Ext. Маршрутизатор NAT имеет два интерфейса, каждый из которых соединен с соответствующей областью. Интерфейсу к внешней области назначен адрес Addr-Nx, интерфейсу к частной области назначен адрес Addr-Np. Адреса Addr-A и Addr-Np принадлежат сети N-Pri, а адреса Addr-X и Addr-Nx принадлежат сети N-Ext.

Традиционный (или исходящий) NAT

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

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

Традиционный маршрутизатор NAT разрешает Хост-A инициировать сессию к Хост-X, но не наоборот. Также N-Ext является маршрутизируемой из N-Pri, в то время как N-Pri не может быть маршрутизируема из N-Ext.

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

Существует два варианта традиционного NAT, называемые базовым NAT и NAPT (Network Address Port Translation).

Базовый NAT

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

NAPT

NAPT дополнительно преобразует идентификатор транспорта, такой как номера портов ТСР и UDP. NAPT позволяет большому числу хостов разделять единственный внешний адрес. Заметим, что NAPT может быть скомбинирован с базовым NAT таким образом, чтобы использовался пул внешних адресов совместно с преобразованием портов.

Маршрутизатор NAPT может быть сконфигурирован для преобразования сессий из N-Pri в единственный внешний адрес, например, Addr-i.

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

Использование IP-адреса интерфейса в качестве IP-адреса источника

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

увеличить изображение

Рис. 3.18. Правила МЭ с преобразованием NAT

увеличить изображение

Рис. 3.19. Использование IP-адреса интерфейса в качестве IP-адреса источника

увеличить изображение

Рис. 3.20. IP-адрес источника до преобразования NAT

увеличить изображение

Рис. 3.21. IP-адрес источника после преобразования NAT

Использование выделенного IP-адреса в качестве IP-адреса источника

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

увеличить изображение

Рис. 3.22. Использование выделенного IP-адреса в качестве адреса источника

увеличить изображение

Рис. 3.23. Опубликование этого IP-адреса на интерфейсе

увеличить изображение

Рис. 3.24. Проверка опубликования IP-адреса

увеличить изображение

Рис. 3.25. Трафик до преобразования NAT

увеличить изображение

Рис. 3.26. Трафик после преобразования NAT

Использование IP-адреса из NAT-пула

В качестве IP-адреса источника может использоваться NAT-пул – диапазон IP-адресов, определенный администратором сети. В этом случае в качестве IP-адреса NAT будет использовать очередной доступный IP-адрес из пула. Причем NAT-пулов может существовать несколько. А также один NAT-пул может быть использоваться в более чем одном NAT-правиле.

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

Типы NAT-пулов

Существует три типа NAT-пулов, каждый из которых производит распределение новых подключений разными способами:

Stateful (с поддержкой состояния)
Stateless (без поддержки состояния)
Fixed (Фиксированный)

NAT-пулы типа Stateful

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

увеличить изображение

Рис. 3.27. Определение диапазона IP-адресов

увеличить изображение

Рис. 3.28. Создание NAT-пула с поддержкой состояния и созданным ранее диапазоном IP-адресов

увеличить изображение

Рис. 3.29. Использование механизма Proxy ARP для опубликования IP-адресов на указанном интерфейсе

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

Для того чтобы таблица состояний не содержала записей о неактивных соединениях, можно установить время активного состояния соединения (State Keepalive) – время неактивности подключения в секундах, по истечении которого, запись об этом подключении будет удалена из таблицы состояний. По прошествии данного периода система считает, что исходящих соединений от данного хоста создаваться больше не будет. В случае если запись о состоянии подключения из таблицы удалена, то последующие подключения данного хоста будут заноситься в новую запись таблицы и могут иметь другой внешний IP-адрес из NAT-пула.

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

В каждом NAT-пуле есть только одна таблица соответствий, поэтому, если один NAT-пул несколько раз используется в разных IP-правилах NAT, то они будут совместно использовать одну и ту же таблицу состояний.

увеличить изображение

Рис. 3.30. Указание NAT-пула в NAT-правиле фильтрования

NAT-пулы типа Stateless

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

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

NAT-пулы типа Fixed

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

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

Двунаправленный (Two-Way) NAT

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

Первый способ. NAT должен быть сконфигурирован таким образом, чтобы отображать определенный порт получателя на конкретный хост и порт за NAT. Например, все НТТР-запросы, которые приходят на NAT, могут быть перенаправлены на один хост, расположенный в защищенной межсетевым экраном сети. Данная технология иногда называется pinholing. Например, если политикой требуется, чтобы все НТТР-сервера, доступные извне, были расположены в DMZ, то один из способов сделать – это определить в NAT возможность pinholing на ТСР-порт 80.

увеличить изображение

Рис. 3.31. Правило SAT, обеспечивающее доступ к серверам, расположенным за преобразованием NAT

увеличить изображение

Рис. 3.32. IP-адрес сервера, к которому требуется доступ извне

увеличить изображение

Рис. 3.33. Обращение к серверу, расположенному за NAT, по IP-адресу межсетевого экрана

Второй способ. Хосту в частной сети (Хост-A) может быть назначен IP-адрес, доступный из внешней сети.

Двунаправленный маршрутизатор NAT позволяет Хост-A инициировать сессию к Хосту-X, и Хост-X инициировать сессию к Хосту-A, если Хост-A доступен либо первым, либо вторым способом. Также как и в случае традиционного NAT N-Ext является маршрутизируемой из N-Pri, но N-Pri остается не маршрутизируемой из N-Ext.

Рассмотрим особенности реализации второго способа создания двунаправленного NAT, когда хост в частной сети имеет IP-адрес из внешней сети. NAT-маршрутизатор является узлом, который расположен на границе между частной и внешней областями и имеет возможность выполнять маршрутизацию пакетов из внешней области в частную область. В случае двунаправленного NAT пакеты могут как исходить от Хоста-A, так и быть направлены к Хосту-A.

Хост-A при соединении с хостом во внешней области имеет IP-адрес из внешнего пространства адресов. После этого никакой другой хост в частном или внешнем домене не может иметь тот же самый адрес.

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

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

В примере Хост-A имеет адрес Addr-k из внешней области, что означает возможность создания сессий от Addr-X к Addr-k. Если Addr-k не маршрутизируется внутри частной сети, то для прохождения пакетов внутри частной области можно создать туннель:

Туннелирование внутри частной сети:

увеличить изображение

Рис. 3.34. Вариант совместного использования преобразования NAT и туннелирования

Могут существовать и другие подходы.

Хост-A будет иметь следующие характеристики

Хосту-A назначается адрес из внешней области для взаимодействия с хостами из этой области. Такой адрес может быть связан статически или получаться динамически (с помощью заранее определенного протокола) от узла, который может назначать адреса из внешней области. Маршрутизатору NAT назначен адрес внешней области.
Выполняется маршрутизация пакетов к внешним хостам, используя маршрутизатор NAT в качестве шлюза. Хосту-A может потребоваться возможность функционирования в качестве конечной точки туннеля для инкапсуляции пакетов для их пересылки и выполнять обратную де-капсуляцию при получении.

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

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

Возможен другой вариант, при котором несколько частных хостов используют единственный внешний адрес, но имеют различные идентификаторы транспортного уровня (т.е. номера портов TCP/UDP и ICMP Query ID).

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

Маршрутизатор NAT аналогичен предыдущему случаю в том, что он должен маршрутизировать пакеты из внешней области к Хосту-A внутри частной области. Обычно маршрутизатор NAT также назначает параметры транспорта для Хоста-A.

В примере Хост-A получает параметры (Addr-Nx, TCP-порт T-Nx) от маршрутизатора NAPT. Пересылка пакетов между конечными точками внутри частной области может быть проиллюстрирована следующим образом. При использовании первого метода внешний заголовок исходящего пакета от Хоста-A использует (частный адрес Addr-A, порт источника T-Na) в качестве параметров источника для взаимодействия с Хостом-X. Маршрутизатор NAPT преобразует эти параметры в (Addr-Nx, порт T-Nxa).

Использование туннеля внутри частной области:

увеличить изображение

Рис. 3.35. Вариант совместного использования преобразования NAРT и туннелирования

Двойной NAT

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

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

Маршрутизатор двойного NAT будет позволять Хосту-A инициировать сессии к Хосту-X. Тем не менее N-Ext (или подмножество N-Ext) не маршрутизируемо внутри N-Pri, и N-Pri не маршрутизируемо из N-Ext.

Например, частные хосты используют 200.200.200.0/24 пространство адресов, которое может быть одним и тем же с хостом в публичном интернете. Хост-A (200.200.200.1) в частном пространстве хочет соединиться с Хостом-X (200.200.200.100) во внешней сети. Для этого необходимо, чтобы адрес Хоста-X был отображен в адрес Хоста-A и наоборот. Двойной NAT, расположенный на границе частной сети, может быть сконфигурирован следующим образом:

Private to Public : 200.200.200.0/24 -> 138.76.28.0/24

Public to Private : 200.200.200.0/24 -> 172.16.1.0/24

В этом случае хост из частной сети будет во внешней сети иметь адрес 138.76.28.1, а хост из внешней сети в частной сети будет иметь адрес 172.16.1.1.

Поток дейтаграмм: Хост-A (Private) → Хост-X (Public)

1. Внутри частной сети

DA: 172.16.1.100 SA: 200.200.200.1

2. После преобразования двойным NAT

DA: 200.200.200.100 SA: 138.76.28.1

Поток дейтаграмм Хост-X (Public) → Хост-A (Private)

1. Во внешней сети

DA: 138.76.28.1 SA: 200.200.200.100

2. После преобразования двойным NAT в частной сети

SA: 200.200.200.1 SA: 172.16.1.100

Двойной NAT работает следующим образом. Когда Хост-A хочет инициировать сессию с Хостом-X, он создает DNS-запрос для Хост-X. DNS-ALG заменяет адрес Хост-X адресом, который корректно маршрутизируется в частной области (скажем Хост-XPRIME). Затем Хост-A инициализирует взаимодействие с Хост-XPRIME. Когда пакеты проходят через NAT, IP-адрес источника преобразуется аналогично случаю традиционного NAT, а адрес получателя преобразуется в Хост-X. Аналогичные преобразования выполняются для возвращаемых пакетов, приходящих от Хоста-X.

Multihomed NAT

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

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

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

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

3.4.4 Сеть с частными адресами и туннели

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

Обсудим два сценария, когда туннели используются

1. Совместно с преобразованием адресов.

2. Без преобразования адресов.

Туннелирование преобразованных пакетов

Все варианты преобразования адресов, которые обсуждались ранее, могут применяться не только к прямым соединениям, но и к туннелям и VPN.

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

Магистральные (Backbone) разделенные на сегменты частные сети

Существует много примеров, когда частная сеть (такая как сеть корпорации) состоит из отдельных подсетей, расположенных в разных местах, и использует публичную сеть для взаимодействия между ними. В таких случаях нежелательно выполнять преобразование адресов, как потому что большому числу хостов может потребоваться взаимодействие через основную сеть, что потребует большой таблицы адресов, так и потому, что будет большое число приложений, которые зависят от сконфигурированных адресов, что затруднит работу DNS-сервера. Будем называть такую частную сеть магистральной, разделенной на сегменты, (backbone-partitioned) частной сетью.

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

Если необходимо доставить пакет из тупикового сегмента Х в тупиковый сегмент Y, то преобразование NAT для сегмента Х инкапсулирует пакет в IP-заголовок с адресом получателя, установленным в глобальный адрес устройства, выполняющего NAT для сегмента Y. Когда преобразование NAT для сегмента Y получает пакет с этим адресом получателя, NAT де-капсулирует IP-заголовок и перенаправляет пакет во внутреннюю сеть. Заметим, что в этом случае может как происходить преобразование адреса, так и не происходить, т.е. будет выполняться простая пересылка пакетов из одной частной сети в другую по внешней сети посредством туннеля.

Рассмотрим следующий пример.

увеличить изображение

Рис. 3.36. Топология магистральной сети, разделенной на сегменты

Необходимо соединить две локальные сети через магистральную сеть, в которой возможна коллизия адресов как с локальной сетью LAN 1, так и с локальной сетью LAN 2.

Самым простым решением в этом случае является использование GRE-туннеля.

На МЭ 1 заданы правила.

увеличить изображение

Рис. 3.37. Правила на МЭ 1 для использования NAT и туннеля

После этого весь трафик из LAN 1 будет иметь IP-адрес источника, определенный для локальной точки GRE-туннеля.

увеличить изображение

Рис. 3.38. Определение параметров GRE-туннеля на МЭ 1

Правила маршрутизации на МЭ 1 следующие.

увеличить изображение

Рис. 3.39. Правила маршрутизации на МЭ 1

На МЭ 2 заданы аналогичные правила.

увеличить изображение

Рис. 3.40. Правила на МЭ 2 для использования NAT и туннеля

После этого весь трафик из LAN 2 будет иметь IP-адрес источника, определенный для противоположной точки GRE-туннеля.

увеличить изображение

Рис. 3.41. Определение параметров GRE-туннеля на МЭ 2

Правила маршрутизации на МЭ 1 следующие.

увеличить изображение

Рис. 3.42. Правила маршрутизации на МЭ 2

увеличить изображение

Рис. 3.43. Пример трафика с преобразованием NAT и туннелированием

3.4.5 Свойства NAT

При преобразовании NAT должны изменяться только заголовки IP/TCP/UDP/ICMP и ICMP-сообщения error.

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

Если содержимое транспортного уровня содержит IP-адрес.
Когда необходимо обеспечить безопасность до конечных точек.

Технологии безопасности прикладного уровня, которые не зависят от IP-адресов (т.е. TLS/SSL и SSH), работают корректно вместе с NAT. В отличие от этого, технологии безопасности на транспортном уровне, такие как IPSec, могут иметь проблемы при использовании NAT.

В транспортном режиме IPSec как АН, так и ESP обеспечивают проверку целостности всего содержимого. Если преобразование NAT модифицирует адрес, то проверка целостности не пройдет.

Заметим, что ESP в туннельном режиме допустимо, так как преобразование не затрагивает внешний IP-заголовок.

Преобразование NAT также влияет на инфраструктуры открытых ключей, такие как DNSSec и сертификаты Х.509. В случае DNSSec каждый RRset DNS подписан ключом своей зоны. Аутентичность ключа проверяется с помощью цепочки доверия, которая устанавливается от корневого DNS. Когда DNS-ALG модифицирует адреса (например, как в случае двойного NAT), проверка подписей не проходит.

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

Поддержка FTP

Рассмотрим, как FTP может поддерживаться NAT. FTP ALG является составной частью большинства реализаций NAT. Некоторые производители включают дополнительные ALG для поддержки других приложений.

Команда PORT и ответ PASV в содержимом сессии протокола FTP содержит IP-адрес и TCP-порт, который участники должны использовать при передаче данных. Для успешного прохождения NAT требуется FTP ALG для просмотра и изменения содержимого управляющей сессии таким образом, чтобы информация содержимого соответствовала параметрам конечных точек. ALG должен также взаимодействовать с NAT таким образом, чтобы NAT мог установить информацию о состоянии FTP-сессии для данных.

Так как адрес и ТСР-порт представлены в ASCII кодировке, в результате может измениться размер пакета. Например, "10,18"– это 5 символов ASCII, а "110,118"– это 7 символов ASCII. Если новый размер совпадает с тем, который был до преобразования, то необходимо только изменить контрольную сумму ТСР. Если же новый размер меньше или больше, чем до преобразования, то необходимо также поменять последовательный номер ТСР, чтобы отобразить изменение длины в управляющем потоке FTP. ALG может использовать специальную таблицу, чтобы корректировать последовательный номер и номер подтверждения в ТСР. Причем это необходимо делать для всех последующих пакетов в соединении.

Приложения с несколькими взаимозависимыми сессиями

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

Однако существуют приложения, такие как Н.323, которые используют одну или более управляющих сессий для установки характеристик последующих сессий. Такие приложения требуют специальных ALG, которые интерпретируют и при необходимости преобразуют содержимое.

Анализ логов

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

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

Вычислительная нагрузка

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

3.4.6 Обсуждение безопасности

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

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

Совмещение возможностей NAT, ALG и межсетевого фильтра обеспечивает прозрачно функционирующее окружение для частного домена. Если будем предполагать, что NAT расположен в доверенном месте, то туннельный режим IPSec может выполняться совместно с маршрутизатором NAT (или в комбинации NAT, ALG и межсетевой экран).

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

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

UDP-сессии по своей сути небезопасны. Ответы на дейтаграммы могут прийти с адреса, отличного от адреса, используемого отправителем. Как результат, входящий UDP-пакет может соответствовать исходящей сессии традиционного маршрутизатора NAT только частично (адрес получателя и номер UDP порта пакета совпадают, а адрес и номер порта источника могут не совпадать). В этом случае существует потенциальная возможность компрометации безопасности в том, что разрешаются частично соответствующие входящие пакеты. Данная проблема безопасности UDP также присуща и межсетевым экранам. Традиционный NAT реализует это, не отслеживая дейтаграммы на уровне сессии, а связывая несколько UDP-сессий, использующих один и тот же адрес, что может привести к компрометации безопасности.
Групповые (Multicast) сессии (основанные на UDP) являются другим слабым местом для маршрутизаторов традиционного NAT. Следует заметить, что межсетевые экраны имеют такую же дилемму, связанную с безопасностью, что и маршрутизаторы NAT. Скажем, хост в частной сети инициализирует групповую сессию. Дейтаграммы, посылаемые частным хостом, могут инициировать ответы в обратном направлении от нескольких внешних хостов. Реализации традиционного NAT, которые используют единственное состояние для отслеживания групповой сессии, не могут определить в общем случае, что входящий UDP-пакет является ответом в существующей групповой сессии или начинает новую UDP-сессию, инициализируемую атакующим.

Устройства NAT могут быть целью атак. Так как устройства NAT являются хостами интернета, они могут быть целью различных атак, таких как SYN flood и ping flood. Устройства NAT должны использовать определенные технологии защиты, как это делают другие серверы интернета.

Лекция 13. Межсетевые экраны

Лабораторный практикум

Лабораторная работа № 6. Политики для традиционного (или исходящего) NAT

Цель

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

Топология сети

увеличить изображение

Рис. 6.1.

Описание практической работы

Статическая маршрутизация

Правила маршрутизации созданы автоматически при определении параметров Ethernet-интерфейсов.

Правила фильтрования

Создаем правило с действием NAT.

Веб-интерфейс:

Rules -> IP Rules -> Add -> IP Rule Folder

Name toInet

Rules -> IP Rules -> Add -> toInet

увеличить изображение

Рис. 6.2.

На вкладке General указано действие NAT и интерфейсы и сети источника и получателя:

увеличить изображение

Рис. 6.3.

На вкладке NAT указано использование адреса интерфейса в качестве адреса источника:

увеличить изображение

Рис. 6.4.

Командная строка:
add IPRuleFolderName=toInet
cc IPRuleFolder <N folder>
add IPRule Action=NAT SourceInterface=lan SourceNetwork= lan/lan_net DestinationInterface=wan1 DestinationNetwork= all-nets Service=all_services Name=inet
Проверяем возможность выхода в интернет.

увеличить изображение

Рис. 6.5.

Проверяем выполнение преобразования NAT.
До преобразования NAT:

увеличить изображение

Рис. 6.6.

После преобразования NAT:

увеличить изображение

Рис. 6.7.
На вкладке NAT указан IP-адрес, который будет использоваться в качестве IP-адреса источника. Данный IP-адрес должен быть предварительно создан в Адресной Книге.
Веб-интерфейс:
Object -> Address Book -> Add-> Address Folder
Name nat
Object -> Address Book -> nat

увеличить изображение

Рис. 6.8.

Командная строка:
add Address AddressFolder nat
cc Address AddressFolder nat
add IP4Address nat_address Address=10.6.10.70
Веб-интерфейс:

увеличить изображение

Рис. 6.9.

Командная строка:
cc IPRuleFolder <N folder>
set IPRule <N rule> NATAction=SpecifySenderAddress NATSenderAddress=nat/nat_address
Проверяем выполнение преобразования NAT.
После преобразования NAT:

увеличить изображение

Рис. 6.10.

На вкладке NAT указано использование NAT-пула, IP-адреса из которого будут использоваться в качестве IP-адреса источника. Данный NAT-пул должен быть предварительно создан.

Веб-интерфейс:

Object -> Address Book -> nat

увеличить изображение

Рис. 6.11.

Командная строка:

cc Address AddressFolder nat

add IP4Address nat_pool Address=10.6.10.71-10.6.10.75

Веб-интерфейс:

Object -> NAT Pools -> Add

увеличить изображение

Рис. 6.12.

Командная строка:

add NATPool natAddresses IPRange=nat/nat_pool

Веб-интерфейс:

увеличить изображение

Рис. 6.13.

Командная строка:

cc IPRuleFolder <N folder>

set IPRule <N rule> NATAction=UseNATPool NATPool=natAddresses

Проверяем выполнение преобразования NAT.

После преобразования NAT:

увеличить изображение

Рис. 6.14.

Лекция 14. Политики для двунаправленного (Two-Way) NAT, используя метод pinholing

Цель

Создать политики для доступа к серверу, расположенному за NAT, используя метод pinholing, т.е. используя IP-адрес межсетевого экрана.

Топология сети

увеличить изображение

Рис. 7.1.

Описание практической работы

Проверка отсутствия конфликта по портам

Метод pinholing некоторые производители называют SAT.

К веб-серверу будут обращаться по IP-адресу МЭ 1, поэтому следует гарантировать отсутствие конфликта по портам с удаленным администрированием МЭ 1. Это можно сделать несколькими способами.

Указать номер порта для удаленного администрирования, отличный от номера порта веб-сервера.
Веб-интерфейс:
System -> Remote Management -> Advanced Settings

увеличить изображение

Рис. 7.2.

Командная строка:
set Settings RemoteMgmtSettings WWWSrv_HTTPPort=82 WWWSrv_HTTPSPort=444
Указать номер порта для доступа к веб-серверу, отличный от номера порта для удаленного администрирования. При этом номер порта на самом веб-сервере можно не изменять, достаточно создать новый httр-сервис с номером порта, отличным от порта удаленного администрирования. Будем предполагать, что используется второй способ.
Веб-интерфейс:
Object -> Services -> Add
Name http_8080

увеличить изображение

Рис. 7.3.

Командная строка:
add Service ServiceTCPUDP http_8080 DestinationPorts=8080 SourcePorts=0-65535

Объекты Адресной Книги

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

Веб-интерфейс:

Object -> Address Book -> nat

увеличить изображение

Рис. 7.4.

Командная строка:

cc Address AddressFolder nat

add IP4Group web_pinholing Members =lan/lan_ip, wan1/wan1_ip

Группа интерфейсов

Веб-интерфейс:

Interfaces -> Interface Group -> Add

увеличить изображение

Рис. 7.5.

Командная строка:

add Interface InterfaceGroup web_int Members=lan,wan1

Правила фильтрования

Создать два правила фильтрования с действием SAT. В первом правиле качестве сервиса указать http, во втором правиле – https. Интерфейсом получателя должен быть core. Адрес получателя – IP-адреса интерфейсов, которые будут указываться клиентом в качестве веб-сервера. В нашем случае это группа интерфейсов web_int.

Создать правило фильтрования с действием Allow.

Веб-интерфейс:

Rules -> IP Rules -> Add -> IP Rule Folder

Name pinholing

Rules -> IP Rules -> pinholing -> Add

увеличить изображение

Рис. 7.6.

На вкладке SAT указать адрес веб-сервера и порт, который он слушает. Если необходимо, чтобы веб-сервер слушал несколько портов, например, 80 (http) и 443 (https), то требуется два правила SAT.

увеличить изображение

Рис. 7.7.

увеличить изображение

Рис. 7.8.

Командная строка:

сc IPRuleFolder <N folder>

add IPRule Action=SAT SourceInterface=web_int SourceNetwork=all-nets DestinationInterface=core DestinationNetwork=nat/web_pinholing Service=http SATTranslateToIP=dmz/web_server SATAllToOne=Yes SATTranslateToPort=80 Name=web_80

add IPRule Action=SAT SourceInterface=web_int SourceNetwork=all-nets DestinationInterface=core DestinationNetwork=nat/web_pinholing Service=https SATTranslateToIP=dmz/web_server SATAllToOne=Yes SATTranslateToPort=443 Name=web_443

add IPRule Action=Allow SourceInterface=web_int SourceNetwork=all-nets DestinationInterface=core DestinationNetwork=nat/web_pinholing Service=http-all Name=web

Проверка конфигурации

Заходим браузером по IP-адресу МЭ 1 и сконфигурированному номеру порта.

увеличить изображение

Рис. 7.9.

Лекция 15. Топология, планирование и внедрение

Описание лекции

3.5 Топология сети при использовании межсетевых экранов

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

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

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

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

увеличить изображение

Рис. 3.44. Простая маршрутизируемая сеть с межсетевым экраном

На рисунке показана типичная топология сети с межсетевым экраном, функционирующем в качестве маршрутизатора. Незащищаемая сторона межсетевого экрана соединена с единственным маршрутом, помеченным как WAN, защищаемая сторона соединена с тремя маршрутами, помеченными как LAN1, LAN2 и LAN3. Межсетевой экран действует как маршрутизатор трафика между WAN и различными маршрутами LAN. На рисунке один из маршрутов LAN также имеет маршрутизатор; часто внутри сети предпочтительнее использовать несколько уровней маршрутизаторов.

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

увеличить изображение

Рис. 3.45. Межсетевой экран с DMZ-сетью

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

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

3.5.1 Принципы построения окружения межсетевого экрана

Простота (Keep It Simple). Данный принцип говорит о первом и основном, о чем надо помнить при разработки топологии сети, в которой функционирует межсетевой экран. Важно принимать наиболее простые решения – более безопасным является то, чем легче управлять. Трудно понимаемые функциональности часто приводят к ошибкам в конфигурации.
Использовать устройства по назначению. Использование сетевых устройств для того, для чего они первоначально предназначались, в данном контексте означает, что не следует делать межсетевые экраны из оборудования, которое не предназначено для использования в качестве межсетевого экрана. Например, маршрутизаторы предназначены для выполнения маршрутизации; возможности фильтрования пакетов не являются их исходной целью, и это всегда надо учитывать при разработки окружения межсетевого экрана. Зависимость исключительно от возможности маршрутизатора обеспечивать функциональность межсетевого экрана опасна: он может быть легко переконфигурирован. Другим примером являются сетевые коммутаторы (switch): когда они используются для обеспечения функциональности межсетевого экрана вне окружения межсетевого экрана, они чувствительны к атакам, которые могут нарушить функционирование коммутатора. Во многих случаях гибридные межсетевые экраны и аппаратные устройства межсетевых экранов являются лучшим выбором, потому что они оптимизированы в первую очередь для функционирования в качестве межсетевых экранов.
Создавать оборону вглубь. Оборона вглубь означает создание нескольких уровней защиты в противоположность наличию единственного уровня. Не следует всю защиту обеспечивать исключительно межсетевым экраном. Где может использоваться несколько межсетевых экранов, они должны использоваться. Где маршрутизаторы могут быть сконфигурированы для предоставления некоторого управления доступом или фильтрации, это следует сделать. Если ОС сервера может предоставить некоторые возможности межсетевого экрана, это следует применить.
Уделять внимание внутренним угрозам. Наконец, если уделять внимание только внешним угрозам, то это приводит в тому, что сеть становится открытой для атак изнутри. Хотя это и маловероятно, но следует рассматривать возможность, что нарушитель может как-то обойти межсетевой экран и получить свободу действий для атак внутренних или внешних систем. Следовательно, важные системы, такие, как внутренние веб- или e-mail-серверы или финансовые системы, должны быть размещены позади внутренних межсетевых экранов или DMZ-зон.

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

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

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

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

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

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

3.5.3 DMZ-сети

Конфигурация с одной DMZ-сетью

В большинстве случаев окружение межсетевого экрана образует так называемую DMZ-сеть или сеть демилитаризованной зоны.

увеличить изображение

Рис. 3.46. Пример окружения межсетевого экрана с одной DMZ-сетью

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

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

Service Leg конфигурация

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

увеличить изображение

Рис. 3.47. Конфигурация Service Leg DMZ

Конфигурация с двумя DMZ-сетями

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

увеличить изображение

Рис. 3.48. Пример окружения межсетевого экрана с двумя DMZ-сетями

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

Основной межсетевой экран является VPN-шлюзом для удаленных пользователей; такие пользователи должны иметь ПО VPN-клиента для соединения с межсетевым экраном.

Входящий SMTP-трафик должен пропускаться основным межсетевым экраном.

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

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

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

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

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

3.5.4 Конечные точки VPN

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

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

увеличить изображение

Рис. 3.49. Пример совмещения межсетевого экрана и конечной точки VPN

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

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

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

3.5.5 Интранет

Интранетом называется сеть, которая основана на тех же протоколах и, следовательно, может выполнять те же самые сервисы и приложения, которые используются в интернете, но без наличия соединения с интернетом. Например, сеть предприятия, построенная на семействе протоколов TCP/IP, можно рассматривать как интранет.

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

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

3.5.6 Экстранет

увеличить изображение

Рис. 3.50. VPN и экстранет, соединяющая две интранет

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

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

3.5.7 Компоненты инфраструктуры: коммутаторы

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

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

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

3.5.8 Расположение серверов в DMZ-сетях

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

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

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

Внешне доступные серверы

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

VPN- и Dial-in-серверы

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

Внутренние серверы

Внутренне доступные НТТР-серверы, SMTP-серверы и серверы каталога могут быть размещены во внутренней DMZ, т.е. между двумя межсетевыми экранами, основным и внутренним; при этом внутренний межсетевой экран отделяет внутреннюю DMZ от защищенной сети. Размещение этих систем во внутренней DMZ обеспечивает оборону вглубь, защищая как от внешних, так и от внутренних угроз. Если НТТР-прокси используется для исходящего трафика, размещение этих систем во внутренней DMZ обеспечивает большую защиту от внутренних и внешних угроз.

DNS-серверы

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

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

Во-вторых, необходимо установить разрешенные типы доступа к DNS-серверу. Приложение DNS-сервера может выполняться с использованием двух транспортных протоколов: клиент обращается к серверу по протоколу UDP, а взаимодействие двух серверов DNS, выполняющих зонные пересылки, реализовано с использованием ТСР. Доступ к серверу DNS с использованием ТСР должен быть ограничен только для тех серверов DNS, которые должны выполнять зонные пересылки. Основной риск, который существует при функционировании DNS, состоит в модификации передаваемой информации. Например, если сервер допускает неаутентифицированные запросы и ответы DNS, атакующий может модифицировать информацию, в результате чего сетевой трафик будет перенаправлен на другой хост. На рисунке показан пример топологии сети с двумя DNS-серверами. Внутренний DNS-сервер должен быть сконфигурирован для разрешения имен внутренних серверов, чтобы внутренние пользователи могли соединяться с ними, всеми серверами в DMZ и интернетом. Внешний DNS-сервер должен обеспечивать разрешение имен самого DNS-сервера и серверов во внешней DMZ, но не во внутренней сети. Как результат, серверы во внешней DMZ будут видимы в интернете.

увеличить изображение

Рис. 3.51. Пример топологии сети с двумя DNS серверами

3.6 Планирование и внедрение межсетевого экрана

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

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

3.6.1 Планирование

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

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

Основные принципы, которым необходимо следовать при планировании развертывания межсетевого экрана:

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

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

При выборе межсетевого экрана следует проанализировать потребности организации и возможности межсетевого экрана:

Назначение межсетевого экрана
- Что должно защищаться (периметр, внутренние отделы, удаленный офис, отдельные хосты, конкретные сервисы, мобильные клиенты и т.п.).
- Какие типы технологий межсетевых экранов лучше всего подходят для трафика, который должен быть защищен (фильтрование пакетов, анализ состояния, прикладной межсетевой экран, шлюз прикладного прокси и т.п.).
- Какие дополнительные возможности безопасности – такие как возможности обнаружения проникновения, VPN, фильтрование содержимого – должен поддерживать межсетевой экран.
Возможности управления межсетевым экраном
- Какие протоколы должен поддерживать межсетевой экран для удаленного управления, например, НТТР-поверх-SSL, SSH или доступ по последовательному порту.
- Могут ли быть отключены протоколы удаленного управление, если они не приемлемы для организации и не соответствуют ее организационной политике.
- Может ли удаленное управление быть ограничено определенными интерфейсами на межсетевом экране и IP-адресами источника, например, принадлежащими конкретной внутренней сети.
- Поддерживает ли межсетевой экран централизованное управление несколькими устройствами (не обязательно только межсетевыми экранами) от одного производителя.
- Если централизованное управление возможно, выполняется ли оно специфичным для производителя приложением или может выполняться стандартными приложениями, например, через веб-интерфейс.
Производительность – обычно особенно важно для межсетевых экранов, расположенных на границы сетевого периметра.
- Какую пропускную способность, максимальное количество одновременно открытых соединений, соединений в секунду может обеспечивать межсетевой экран.
- Возможна ли балансировка нагрузки и резервирование для гарантирования высокой отказоустойчивости.
- Что является более предпочтительным – аппаратный или программный межсетевой экран.
Интеграция
- Требуется ли для межсетевого экрана специализированная аппаратура для корректной интеграции в сетевую инфраструктуру организации (специфические требования подключения к электричеству, специфический тип сетевого интерфейса (NIC), специфические устройства резервного копирования и т.п.).
- Необходима ли для межсетевого экрана совместимость с другими устройствами в сети или сервисами, которые обеспечивают безопасность.
- Существует ли интеропрерабельность логов, создаваемых межсетевым экраном, с существующими системами управления логами.
- Потребует ли установка межсетевого экрана каких-либо изменений в других сегментах сети.
Физическое окружение – обычно рассматривается для межсетевых экранов, установленных в сети, но может также применяться к централизованным компонентам межсетевых экранов для хостов.
- Где будет физически располагаться межсетевой экран и как будет гарантироваться его физическая защита.
- Достаточно ли силового кабеля, кондиционеров, сетевых соединений в том месте, где будет располагаться межсетевой экран.
Персонал
- Кто несет ответственность за управление межсетевым экраном.
- Необходимо ли обучение системных администраторов перед внедрением межсетевого экрана.
Будущие потребности
- Какие могут возникнуть потребности в будущем (планируется переход на IPv6, ожидаемые требования к пропускной способности, совместимость с регламентными требованиями и т.п.).

Также при покупке и внедрении персональных межсетевых экранов и межсетевых экранов для хостов следует рассмотреть:

Удовлетворяют ли рабочие станции и сервера минимальным системным требованиям, которые необходимы для функционирования межсетевого экрана.
Будет ли межсетевой экран совместим с другим ПО обеспечения безопасности на рабочей станции или сервере (например, с ПО обнаружения вредоносного кода).
Возможно ли централизованное управление межсетевым экраном и могут ли политики, которые обеспечивают безопасность организации, автоматически загружаться на клиентские машины.
Могут ли отчеты о нарушениях с межсетевого экрана передаваться на центральный сервер.
Может ли блокироваться межсетевой экран кем-либо, кроме администратора, и может ли кто-либо изменить установки межсетевого экрана.
Будет ли межсетевой экран конфликтовать с персональным межсетевым экраном, встроенным в ОС. Если да, то как легко преодолеть этот конфликт.

3.6.2 Конфигурирование

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

Установка аппаратуры и ПО

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

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

Конфигурировать межсетевой экран следует в помещении, в которое отсутствует неавторизованный доступ.

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

Конфигурирование политики

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

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

Детали создания набора правил зависят от типа межсетевого экрана и специфичны для каждого продукта. Например, многие межсетевые экраны последовательно сравнивают трафик с правилами до тех пор, пока не будет найдено соответствие. Для таких межсетевых экранов правила, которые соответствуют наибольшему количеству трафика, должны располагаться как можно выше в списке, чтобы увеличить производительность межсетевого экрана. Некоторые межсетевые экраны могут иметь более сложные способы обработки набора правил, такие как сначала проверка правил "drop (deny)", а затем проверка правил "allow".

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

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

Конфигурирование создания логов и оповещений

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

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

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

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

Любая модификация или запрещение правил межсетевого экрана.
Перезапуск системы, нехватка дискового пространства и другие события функционирования ОС.
Практически все системы межсетевого экрана обеспечивают ту или иную функциональность создания логов. Как обсуждалось ранее, логи в прикладном прокси являются более объемными, чем логи пакетных фильтров или межсетевых экранов с анализом состояния. Причина в том, что прикладные фильтры анализируют большее число уровней стека протоколов, чем пакетные фильтры.
Наиболее широко используемым приложением для создания логов является syslog в ОС UNIX. UNIX syslog предназначен для централизованного создания логов, кроме того он имеет много опций для их проверки и обработки. Данная программа создания логов доступна практически во всех основных ОС, включая Windows NT, 2xxx и все разновидности UNIX и Linux.
После того, как логи межсетевого экрана будут переданы централизованному серверу логов, могут использоваться различные пакеты для их обработки. Логи, совместимые с syslog, могут также подаваться в качестве входа в пакеты анализа проникновения и использоваться для судебного расследования.
Те межсетевые экраны, которые не поддерживают интерфейса syslog, должны использовать свою собственную внутреннюю функциональность создания логов. В зависимости от платформы межсетевого экрана, существует много инструментальных пакетов третьих фирм для поддержки и обработки логов.

Тестирование

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

Подключение. Пользователи могут устанавливать и поддерживать соединения через межсетевой экран.
Набор правил. Разрешенный трафик пропускается политикой, не разрешенный трафик блокируется. Проверка набора правил должна включать как просмотр их вручную, так и тестирование работы правил.
Совместимость с приложениями. Межсетевые экраны для хостов и персональные межсетевые экраны не препятствуют и не влияют на работу существующих приложений. Это включает сетевые взаимодействия между компонентами приложения. Межсетевой экран, расположенный в сети, не влияет на приложения, имеющие компоненты, которые должны взаимодействовать по сети (например, клиент-серверное ПО).
Управление. Администраторы могут конфигурировать и управлять межсетевым экраном эффективно и безопасно.
Создание логов. Функция создания и управления логами соответствует политике и стратегии организации.
Производительность. Обеспечивается адекватная производительность при нормальном и пиковом использовании. Во многих случаях лучшим способом протестировать производительность является использование генераторов симуляторов трафика, которые создадут аналоги реальных характеристик ожидаемого трафика. Можно также выполнить симуляцию DoS-атак. Тестирование должно включать проверку, что различные приложения проходят через межсетевой экран, особенно те, на которые влияет пропускная способность сети или проблемы, связанные с задержкой.
Безопасность реализации. Реализация межсетевого экрана сама может содержать уязвимости, которые может использовать атакующий. Следует выполнить оценку уязвимостей различных компонент межсетевого экрана.
Интероперабельность компонент. Компоненты межсетевого экрана должны совместно корректно функционировать. Это особенно важно, если используются компоненты от разных производителей.
Синхронизация политики. Если несколько межсетевых экранов должны выполнять синхронизованную политику или группу правил, то следует протестировать функционирование синхронизации в различных сценариях (например, если один или несколько узлов находятся в режиме off-line).
Дополнительные возможности. Дополнительные возможности, которые будут использоваться межсетевым экраном, такие как VPN и обнаружение вредоносного кода, должны быть протестированы, чтобы гарантировать их корректную работу.

3.6.3 Развертывание

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

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

3.6.4 Управление

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

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

Инциденты безопасности

Не существует простого ответа на вопрос, что такое инцидент безопасности.

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

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

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

В сущности, определение инцидента безопасности определяется политикой безопасности организации.

Межсетевые экраны являются важными элементами при определении инцидента безопасности – они указывают на корреляцию событий. Корреляцию событий обеспечивает тот факт, что межсетевые экраны являются рубежом, который должны пересечь все сетевые атаки, чтобы войти в сеть. Это ставит межсетевой экран в уникальное положение по анализу неавторизованной деятельности. По этой причине все межсетевые экраны и другие системы, создающие логи, такие, как IDS, должны выполнять синхронизацию времени. Наиболее общим механизмом для синхронизации времени является network time protocol (NTP).

Создание резервных копий межсетевых экранов

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

В принципе, на всех межсетевых экранах всегда должны создаваться полные резервные копии. В инкрементальных резервных копиях нет необходимости.

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

Также желательно (но не всегда возможно) использовать межсетевые экраны, у которых все критичные файловые системы расположены на CDROM.

Лекция 16. Системы обнаружения и предотвращения проникновений

4.1 Введение

Для определения проникновения необходимо просматривать события, происходящие на хосте или в сети и затем анализировать их с целью определения возможных инцидентов, которые нарушили или потенциально могут нарушить политику безопасности. Для предотвращения проникновения необходимо определить проникновение и попытаться остановить его. Системы обнаружения и предотвращения проникновений (Intrusion Detection and Prevention Systems – IDS/IDPS) первоначально фокусировались на определении возможных инцидентов, записи в логии информации о них, попытке остановить обнаруженные проникновения и уведомлении об этом администратора. Организации могут использовать IDPS для других целей, таких как определение проблем, связанных с политиками безопасности, документирование существующих угроз и определение внутренних пользователей, нарушающих политику безопасности.

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

Опишем характеристики IDPS и рассмотрим рекомендации для разработки, конфигурирования и сопровождения IDPS.

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

Рассмотрим основные способы классификации IDPS.

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

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

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

4.2 Основное назначение IDPS

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

Почему следует использовать IDPS, особенно если уже имеются межсетевые экраны, антивирусные инструментальные средства и другие средства защиты?

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

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

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

Возможность иметь реакцию на атаку позволяет заставить атакующего нести ответственность за собственную деятельность. Это можно сформулировать следующим образом: "Я могу прореагировать на атаку, которая произведена на мою систему, так как я знаю, кто это сделал или где его найти". Это трудно реализовать в сетях TCP/IP, где протоколы позволяют атакующим подделать IP-адрес источника и другие идентификаторы источника. В принципе очень трудно определить источник в любой системе, которая имеет слабые механизмы идентификации и аутентификации.
Возможность блокирования означает возможность распознать некоторую активность или событие как атаку и затем выполнить действие по блокированию источника. Данную цель можно сформулировать следующим образом: "Я не забочусь о том, кто атакует мою систему, потому что я могу распознать, что атака имеет место, и блокировать ее". Заметим, что требования реакции на атаку полностью отличаются от возможности блокирования.

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

Объявления о появлении новых уязвимостей являются общедоступными, например, через публичные сервисы, такие, как ICAT (http://icat.nist.gov) или CERT (http://www.cert.org), которые созданы для того, чтобы эти уязвимости нельзя было использовать для выполнения атак. Тем не менее, существует много ситуаций, в которых использование известных уязвимостей все же возможно.

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

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

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

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

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

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

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

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

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

4.3 Способы классификации IDPS

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

Способ мониторинга системы. По способам мониторинга системы делятся на network-based, host-based, беспроводные IDS, network behavior analysis (NBA) и application-based.
Способ анализа. Данная классификация описывает способы, которыми IDPS определяет, что имело место проникновение. Способами определения проникновения являются обнаружение злоупотреблений или сигнатурный подход (misuse detection) и обнаружение аномалий (anomaly detection).
Задержка во времени между получением информации из источника и ее анализом и принятием решения. В зависимости от задержки во времени, IDPS делятся на interval-based (или пакетный режим) и real-time.

Большинство коммерческих IDPS являются real-time network-based системами с сигнатурным способом определения проникновения.

К характеристикам IDPS также относятся:

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

Ответ – набор действий, которые выполняет система после определения проникновений. Они обычно разделяются на активные и пассивные меры, при этом под активными мерами понимается автоматическое вмешательство в некоторую другую систему, под пассивными мерами — отчет IDPS, сделанный для людей, которые затем выполнят некоторое действие на основе данного отчета.

4.3.1 Архитектура IDPS

Архитектура IDPS определяет, какие имеются функциональные компоненты IDPS и как они взаимодействуют друг с другом. Основными архитектурными компонентами являются: Хост — система, на которой выполняется ПО IDPS, и целевая система (Target) — система, за которой IDPS наблюдает.

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

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

Современные IDPS, как правило, состоят из следующих компонент:

Сенсор или агент – просматривает и анализирует деятельность. Термин сенсор обычно используется для IDPS, которая просматривает сеть, включая network-based, беспроводные и NBA технологии. Термин агент обычно используется для host-based IDPS технологий.
Управляющий сервер – централизованное устройство, которое получает информацию от сенсоров или агентов и управляет ими. Некоторые управляющие серверы анализируют события, которые получают от агентов и сенсоров, и могут определять события, которые отдельный сенсор или агент не может видеть. Сопоставление информации от нескольких сенсоров или агентов, такое как обнаружение событий, исходящих с некоторого IP-адреса, называется корреляцией. Управляющие сервера могут быть реализованы как аппаратно, так и программно. Некоторые небольшие IDPS не используют никаких управляющих серверов, но в большинстве случаев такой компонент существует. В больших конфигурациях IDPS может быть несколько управляющих серверов, и в некоторых случаях существует два уровня управляющих серверов.
Сервер БД – репозиторий информации о событиях, записанных сенсорами, агентами и/или управляющими серверами. Многие IDPS предоставляют поддержку для серверов БД.
Консоль – программа, которая предоставляет интерфейс для администратора IDPS. ПО консоли обычно инсталлируется на обычную рабочую станцию. Часто отдельная консоль используется для конфигурирования сенсоров или агентов и модификации ПО, другая используется для мониторинга и анализа событий.

4.3.2 Каналы связи и распределенность управления и принятия решения

Для успешного функционирования IDPS в сети должны быть созданы следующие каналы связи:

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

Рассмотрим возможные способы управления IDPS.

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

4.3.3 Скорость реакции

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

Реакция через определенные интервалы времени(пакетный режим)
В IDPS, реакция которых происходит через определенные интервалы времени, информационный поток от точек мониторинга до инструментов анализа не является непрерывным. В результате информация обрабатывается способом, аналогичным коммуникационным схемам "сохранить и перенаправить". Многие ранние host-based IDPS используют данную схему хронометража, так как они зависят от записей аудита в ОС. Основанные на интервале IDPS не выполняют никаких действий по предотвращению проникновения, являющихся результатом анализа событий.
Реакция в режиме реального времени (real-time)
IDPS реального времени непрерывно обрабатывают поток информации от источников. Чаще всего это является преобладающей схемой в network-based IDPS, которые получают информацию из потока сетевого трафика. Термин "реальное время" используется в том же смысле, что и в системах управления процессом. Это означает, что определение проникновения, выполняемое IDPS "реального времени", приводит к результатам достаточно быстро, что позволяет IDPS выполнять определенные действия в автоматическом режиме.

4.3.4 Информационные источники

Один из основных способов классификации IDPS состоит в разделении их по источникам информации. Некоторые IDPS для нахождения атакующих анализируют сетевые пакеты, захватываемые ими из сети. Другие IDPS для обнаружения признаков проникновения анализируют источники информации, созданные ОС или приложением.

Network-Based IDPS

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

Network-based IDPS часто состоят из множества сенсоров, расположенных в различных точках сети. Эти устройства просматривают сетевой трафик, выполняя локальный анализ данного трафика и передавая отчеты об атаках на центральную управляющую консоль. Многие из этих сенсоров разработаны для выполнения в "невидимом (stealth)" режиме, чтобы сделать более трудным для атакующего обнаружение их присутствия и расположения.

Преимущества network-based IDPS:

Несколько оптимально расположенных network-based IDPS могут просматривать большую сеть.
Развертывание network-based IDPS не оказывает большого влияния на производительность сети. Network-based IDPS обычно являются пассивными устройствами, которые прослушивают сетевой канал без воздействия на функционирование сети. Таким образом, обычно бывает легко модифицировать топологию сети для размещения network-based IDPS.
Network-based IDPS могут быть сделаны практически неуязвимыми для атак или даже абсолютно невидимыми для атакующих.

Недостатки network-based IDPS:

Network-based IDPS может быть трудно обрабатывать все пакеты в большой или занятой сети, и, следовательно, она может пропустить атаку, которая началась при большом трафике. Некоторые производители пытаются решить данную проблему, полностью реализуя IDPS аппаратно, что делает IDPS более быстрой. Необходимость быстро анализировать пакеты также может привести к тому, что производители IDPS будут определять небольшое количество атак или же использовать как можно меньшие вычислительные ресурсы, что снижает эффективность обнаружения.
Многие преимущества network-based IDPS не применимы к современным сетям, основанным на сетевых коммутаторах. Коммутаторы делят сети на много небольших сегментов. Многие коммутаторы не предоставляют возможности мониторинга всех своих портов, и это ограничивает диапазон мониторинга сенсора network-based IDPS только одним хостом. Даже когда коммутаторы предоставляют такой мониторинг портов, часто единственный порт не может охватить весь трафик, передаваемый коммутатором.
Network-based IDPS не могут анализировать зашифрованную информацию. Эта проблема возрастает, чем больше организации (и атакующие) используют VPN.
Большинство network-based IDPS не могут сказать, была ли атака успешной; они могут только определить, что атака была начата. Это означает, что после того, как network-based IDPS определит атаку, администратор должен вручную исследовать каждый атакованный хост для определения, происходило ли реальное проникновение.
Некоторые network-based IDPS имеют проблемы с определением сетевых атак, которые включают фрагментированные пакеты. Наличие фрагментированных пакетов может привести к тому, что IDPS будет либо не определит атаку, либо существенно снизит производительность сети.

Анализ состояния протокола

Анализ состояния протокола (network behavior analysis – NBA) состоит в сравнении заранее заданных профилей, которые описывают нормальную последовательность сообщений в протоколе, и реального трафика. В отличие от определения проникновения на основе аномалий, при котором используются профили, созданные для конкретного хоста или сети, анализ состояния протокола использует разработанные производителем универсальные профили, которые определяют последовательность сообщений и состояний конкретного протокола. "Stateful" в анализе состояния протокола означает, что IDPS понимает и отслеживает состояние сетевого, транспортного и прикладного протоколов, для которых существует понятие состояния. Важной составной частью анализа состояния является определение пар запросов и ответов. В результате создания таких пар IDPS может определить, была ли аутентификация успешной, найдя состояние статуса в соответствующем ответе. После того, как пользователь успешно аутентифицирован, сессия переходит в аутентифицированное состояние, и считается, что пользователь может выполнять команды протокола. Выполнение любой из этих команд в неаутентифицированном состоянии будет рассматриваться как возможная атака.

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

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

Преимущества NBA IDPS:

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

Недостатки NBA IDPS:

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

Host-Based IDPS

Host-based IDPS имеют дело с информацией, собранной внутри единственного компьютера. Заметим, что application-based IDPS на самом деле являются подмножеством host-based IDPS. Такое расположение позволяет host-based IDPS анализировать деятельность отдельного хоста, определяя процессы и пользователей, которые имеют отношение к конкретной атаке в ОС. В отличие от network-based IDPS, host-based IDPS могут "видеть" последствия предпринятой атаки, так как они могут иметь непосредственный доступ к системной информации, файлам данных и системным процессам, являющихся целью атаки.

Нost-based IDPS обычно используют информационные источники двух типов: результаты аудита ОС и системные логи. Результаты аудита ОС обычно создаются на уровне ядра ОС и, следовательно, являются более детальными и лучше защищенными, чем системные логи. Однако системные логи намного меньше и не столь многочисленны, как результаты аудита, и, следовательно, легче для понимания. Некоторые host-based IDPS разработаны для поддержки централизованной инфраструктуры управления и получения отчетов IDPS, что может допускать единственную консоль управления для отслеживания многих хостов. Другие создают сообщения в формате, который совместим с системами сетевого управления.

Преимущества host-based IDPS:

Host-based IDPS с их возможностью следить за событиями локально относительно хоста могут определить атаки, которые не могут видеть network-based IDPS.
Host-based IDPS часто могут функционировать в окружении, в котором сетевой трафик зашифрован, когда host-based источники информации создаются до того, как данные шифруются, и/или после того, как данные расшифровываются на хосте назначения.
На функционирование host-based IDPS не влияет наличие в сети коммутаторов.
Когда host-based IDPS работают с результатами аудита ОС, они могут оказать помощь в определении Троянских программ или других атак, которые нарушают целостность ПО.

Недостатки host-based IDPS:

Host-based IDPS более трудны в управлении, так как информация должна быть сконфигурирована и должна управляться для каждого просматриваемого хоста.
Так как по крайней мере источники информации (и иногда часть средств анализа) для host-based IDPS расположены на том же хосте, который является целью атаки, то, как составная часть атаки, IDPS может быть атакована и запрещена.
Host-based IDPS не полностью соответствуют возможности определения сканирования сети или других аналогичных исследований, когда целью является вся сеть, так как IDPS наблюдает только за сетевыми пакетами, получаемыми конкретным хостом.
Host-based IDPS могут быть блокированы некоторыми DoS-атаками.
Когда host-based IDPS использует результаты аудита ОС в качестве источника информации, количество информации может быть огромно, что потребует дополнительных локальных ресурсов.
Host-based IDPS используют вычислительные ресурсы хостов, за которыми они наблюдают, что влияет на производительность наблюдаемой системы.

Application-based IDPS

Application-based IDPS является специальным подмножеством host-based IDPS, которые анализируют события, возникающие в приложении. Наиболее общими источниками информации, используемыми application-based IDPS, являются логи приложения.

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

Преимущества application-based IDPS:

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

Недостатки application-based IDPS:

Application-based IDPS могут быть более уязвимы, чем host-based IDPS, для атак на логи приложения, которые могут быть не так хорошо защищены, как результаты аудита ОС, используемые host-based IDPS.
Application-based IDPS часто просматривают события на пользовательском уровне абстракции, на котором обычно невозможно определить Троянские программы или другие подобные атаки, связанные с нарушением целостности ПО. Следовательно, целесообразно использовать application-based IDPS в комбинации с host-based и/или network-based IDPS.

Беспроводные (wireless) IDРS

Беспроводная IDPS просматривает трафик беспроводной сети и анализирует беспроводные сетевые протоколы для определения нежелательной деятельности. Они не могут определить нежелательную деятельность в приложении или протоколах более высокого уровня (например, ТСР, UDP). В большинстве случаев такие сети развернуты внутри организаций, но возможно также их развертывание в таких местах, где могут быть подключены неавторизованные беспроводные сети.

4.3.5 Анализ, выполняемый IDPS

Существует два основных подхода к анализу событий, которые свидетельствуют о наличии атак: определение злоупотреблений или сигнатурный подход (misuse detection) и определение аномалий (anomaly detection).

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

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

Сигнатурный подход

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

Преимущества сигнатурного метода:

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

Недостатки сигнатурного метода:

Сигнатуры могут определить только те атаки, о которых они знают, – следовательно, надо постоянно обновлять их базы данных для получения сигнатур новых атак.
Многие сигнатуры разработаны таким образом, что могут использовать только строго определенные сигнатуры, а это не допускает определения вариантов общих атак. State-based детекторы злоупотреблений могут обойти данное ограничение, но они применяются в коммерческих IDPS не столь широко.

Определение аномалий

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

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

Определение допустимого порога. В этом случае основные атрибуты поведения пользователя и системы выражаются в количественных терминах. Для каждого атрибута определяется некоторый уровень, который устанавливается как допустимый. Такие атрибуты поведения могут определять число файлов, доступных пользователю в данный период времени, число неудачных попыток входа в систему, количество времени ЦП, используемое процессом и т.п.
Статистические метрики: параметрические, при которых предполагается, что распределение атрибутов профиля соответствует конкретному образцу, и непараметрические, при которых распределение атрибутов профиля является "обучаемым", исходя из набора значений истории, которые наблюдались за определенный период времени;
Метрики, основанные на правилах, которые аналогичны непараметрическим статистическим метрикам в том, что наблюдаемые данные определяют допустимые используемые образцы, но отличаются от них в том, что эти образцы специфицированы как правила, а не как численные характеристики;
Другие метрики, включая нейросети, генетические алгоритмы и модели иммунных систем.

Только первые две технологии используются в современных коммерческих IDPS.

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

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

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

Преимущества определения аномалий:

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

Недостатки определения аномалий:

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

4.3.6 Возможные ответные действия IDPS

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

Активные действия

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

Сбор дополнительной информации

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

Изменение параметров окружения

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

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

Выполнение действия против атакующего

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

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

Рекомендуется проконсультироваться с законодательством перед тем, как использовать какие-либо опции "ответного удара".

Пассивные действия

Пассивные ответы IDPS предоставляют информацию администратору системы, предполагая, что человек сам выполнит дальнейшие действия на основе данной информации. Многие коммерческие IDPS предполагают исключительно пассивные ответы.

Тревоги и оповещения

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

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

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

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

Использование SNMP Traps

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

Возможности отчетов и архивирования

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

Возможность хранения информации о сбоях

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

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

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

Лекция 17. Антивирусное сканирование

Цель

Принципы использования антивирусной защиты

Антивирусный модуль NetDefendOS обеспечивает защиту от вредоносного кода, который может содержаться в файлах, загружаемых из интернет. Файлы могут быть загружены как часть веб-страницы, полученной по протоколу HTTP, могут быть загружены по протоколу FTP или получены в виде вложений в электронную почту по протоколу SMTP. Вредоносный код во всех этих примерах может использоваться для различных целей, начиная от программ раздражающего воздействия до более злонамеренных действий, например, получение паролей, номеров кредитных карт и другой конфиденциальной информации. Термин "вирус" может быть использован как общее описание для всех видов вредоносного кода, переносимого файлами.

Настройка корректного системного времени и проверка наличия обновлений
Очень важно установить правильное системное время, если функция автоматического обновления антивирусных баз данных включена. Неправильное время может означать, что автоматическое обновление отключено.
Веб-интерфейс:
Maintenance -> Update Center

увеличить изображение

Рис. 8.1.

Командная строка:
updatecenter -status
Совместное использование с клиентским антивирусным сканированием
В отличие от системы обнаружения и предотвращения вторжений (IDP), которая в основном применяется для защиты серверов, антивирусное сканирование применяется для защиты клиентов при загрузках файлов. Антивирус NetDefendOS разработан как дополнение к стандартному антивирусному сканированию, которое обычно выполняется локально специализированным программным обеспечением, установленным на клиентских компьютерах. Антивирусное сканирование не предназначено для полноценной замены локального сканирования, а скорее является дополнительной функцией для повышения безопасности. Оно может также выступать в качестве резервной защиты, когда локальному клиенту не доступно антивирусное сканирование.
Сканирование потока
Так как передача файлов выполняется через межсетевой экран, то, если антивирусный модуль включен, система NetDefendOS будет сканировать поток данных на наличие вирусов. Так как файлы представляют собой поток трафика и не хранятся целиком в памяти, для такого сканирования требуется меньшей объем памяти, и, как следствие, влияние на общую пропускную способность будет минимальным.
Сопоставление с шаблоном
Процесс проверки основан на сопоставлении с базой данных известных вирусов, что с высокой степенью достоверности помогает определить наличие вируса. Как только в передаваемом файле обнаружен вирус, загрузка прекращается.
Типы сканируемых загружаемых файлов
Как описано выше, антивирусное сканирование запускается как часть ALG и может анализировать загружаемые файлы, передаваемые по протоколам HTTP, FTP, SMTP и POP3. В частности:
- Может быть просканирован любой тип несжатого файла, с которым связан соответствующий ALG.
- Если загружаемый файл сжат, то форматы ZIP и GZIP также могут быть просканированы.
Можно запретить загрузку определенных файлов, а также указать ограничение размера сканируемых файлов. Если размер не указан, то по умолчанию максимальный размер файлов не ограничен.
Одновременное выполнение нескольких сканирование
Не существует ограничения, сколько антивирусных сканирований может быть одновременно выполнено на одном межсетевом экране. Количество одновременных выполнений сканирований определяется доступным объемом памяти.
Учет специфики конкретного протокола
Так как антивирусное сканирование реализовано с использованием ALG, может учитываться специфика конкретного протокола. Например, для FTP сканирование выполняется как для потока команд, так и для потока данных. Если обнаружен вирус, то команда на прекращение загрузки посылается через управляющее соединение.
Взаимосвязь с IDP
Порядок, в котором выполняются антивирусное сканирование и IPD-сканирование, не важен, так как эти процессы выполняются на разных уровнях стека протокола. Поэтому антивирусное сканирования и IDP-сканирование могут происходить одновременно.
Если функция IDP включена, выполняется сканирование всех пакетов, которые соответствуют определенному правилу IDP, без учета семантики протоколов более высокого уровня, таких как HTTP. В противоположность этому антивирус осведомлен о семантики протоколов более высокого уровня и просматривает только данные, относящиеся к этим протоколам. Антивирусное сканирование является частью шлюза прикладного уровня, а IDP нет.
База данных сигнатур SafeStream
Антивирусное сканирование выполняется системой NetDefendOS D-Link с использованием баз данных сигнатур вирусов SafeStream. База данных SafeStream создана и поддерживается лабораторией Касперского – компанией, которая является мировым лидером в области обнаружения вирусов. База данных обеспечивает защиту от всех известных вирусов, включая троянские программы, "червей", "backdoor" и другие.
Обновление базы данных
База данных SafeStream обновляется ежедневно, добавляя сигнатуры новых вирусов. Старые сигнатуры редко удаляются, вместо этого они заменяются более общими сигнатурами, которые охватывают несколько вирусов. Поэтому локальная копия NetDefendOS базы данных SafeStream должна регулярно обновляться, и этот сервис обновления является частью подписки на Антивирус D-Link.

Описание практической работы

Использование шлюза прикладного уровня (ALG) для активизация антивирусного сканирования

Реакция на невозможность выполнения проверки на наличие вирусов
Антивирус NetDefendOS активизируется с помощью шлюза прикладного уровня (ALG), который связан с соответствующим протоколом. Активизация доступна для загружаемых файлов, связанных со следующими ALG и включается непосредственно в самом ALG:
- HTTP ALG
- FTP ALG
- POP3 ALG
- SMTP ALG
Если по какой-либо по причине не удается выполнить проверку на наличие вирусов, то при режиме Deny дальнейшая передача данных прекращается, при этом данное событие регистрируется в логах. Если установлен режим Allow, то ситуация, когда антивирусные базы не доступны или текущая лицензия не действительна, не приведет к запрещению пересылки. В этом случае пересылка файлов будет разрешена, и будет сгенерировано сообщение в логах, указывающее на то, что произошел сбой.
Веб-интерфейс:
Object -> ALG with AV/WCF -> Add -> HTTP ALG

увеличить изображение

Рис. 8.2.
Режим сканирования
Режим сканирования может быть следующим:
Disabled – Функция антивируса выключена.
Audit – Сканирование активизировано, но единственным действием является ведение логов.
Protect – Функция антивируса активизирована. Подозрительные файлы будут удалены, информация об этом будет записана в логи.
Исключение из сканирования
При необходимости можно явно отменить сканирование файлов с определенным расширением. Данное действие может увеличить общую пропускную способность, если загрузка файлов с данным расширением часто используется в каком-либо протоколе, например, HTTP.
NetDefendOS выполняет проверку всех MIME-расширений файлов, чтобы установить, что расширение файла корректно и затем посмотреть, не находится ли это расширение в списке исключенных.

увеличить изображение

Рис. 8.3.
Ограничение степени сжатия
При сканировании сжатых файлов файл сначала распаковывается. В некоторых случаях распакованный файл намного больше сжатого. Это означает, что сравнительно небольшое вложение сжатого файла может значительно израсходовать ресурсы межсетевого экрана и заметно снизить пропускную способность.
Для предотвращения подобной ситуации, следует указать предел степени сжатия (Compression Ratio). Если предел степени сжатия указан 20, то это будет означать, что, если несжатый файл в 20 раз больше, чем сжатый, то следует выполнить одно из следующих действий:
Allow – Разрешить передачу файла без проверки на наличие вирусов
Scan – Сканировать файл на наличие вирусов
Drop – Отбросить файл
В любом случае данное событие заносится в лог.

увеличить изображение

Рис. 8.4.
Проверка файлов на соответствие типам MIME
Параметр ALG File Integrity может быть использован совместно с антивирусным сканированием для того, чтобы проверить, соответствует ли содержание файла типу MIME.
MIME-тип определяет тип файла. Например, файл может быть определен как .gif и, следовательно, должен содержать данные этого типа. Некоторые вирусы могут пытаться скрыться внутри файлов, используя ложное расширение. Файл может быть указан как .gif, но содержимое файла не будет соответствовать данным этого типа, так как он заражен вирусом.
Включение этой функции рекомендуется для того, чтобы предотвратить прохождение вируса.

увеличить изображение

Рис. 8.5.

Командная строка:
set ALGALG_HTTPhttp-outbound-avAntivirus=Protect
Создание сервиса с ALG с установленной антивирусной защитой
Веб-интерфейс:
Object -> Services -> Add -> TCP/UDP Services

увеличить изображение

Рис. 8.6.
0.118
Командная строка:
add Service ServiceTCPUDP http-outbound-av DestinationPorts=80,8080,90,8090 SourcePorts=0-65535 ALG=http-outbound-av
Определение правила фильтрования с созданным сервисом
Веб-интерфейс:
Rules -> IP Rules -> toInet -> Add-> IP Rule

увеличить изображение

Рис. 8.7.
0.119
Командная строка:
add IPRuleFolder Name=toInet
cc IPRuleFolder <N folder>
add IPRule Action=NAT SourceInterface=lan SourceNetwork=lan/lan_net DestinationInterface=wan1 DestinationNetwork=all-nets Service=http-outbound-av Name=http_av

Лекция 18. Инструментальные средства

4.4 Дополнительные инструментальные средства

4.4.1 Системы анализа и оценки уязвимостей

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

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

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

4.4.2 Разница между системами анализа уязвимостей и системами обнаружения проникновения

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

Последовательность действий при анализе уязвимостей

Общий процесс оценки уязвимостей состоит в следующем:

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

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

Классификация инструментальных средств анализа уязвимостей

Существует два основных способа классификации систем анализа уязвимостей: первый – по расположению, из которого информация об исследуемой системе получена, и второй – по информации, которой располагает инструментальное средство анализа уязвимостей. В первом способе классификации систем анализа уязвимостей они классифицируются как network-based, и как host-based. При использовании второго способа системы классифицируются как credentialed или non-credentialed. Эти термины указывают, делался ли анализ с использованием или без креденциалами (такими, как ID и пароли или другая идентификационная и аутентификационная информация, с помощью которой предоставляется доступ к внутренним системам). Рассмотрим первый способ классификации для описания различных подходов к анализу уязвимостей.

Host-based анализ уязвимостей

Системы host-based анализа уязвимостей определяют уязвимость, анализируя доступный источник системных данных, такой, как содержимое файлов, параметры конфигурации и другую информацию о состоянии системы. Данная информация обычно доступна с использованием стандартных системных запросов и проверки системных атрибутов. Так как информация получена в предположении, что анализатор уязвимости имеет доступ к хосту, данный тип инструментальных средств анализа также иногда называется credential-based оценка уязвимости. Такая оценка определяется как пассивная.

Наиболее интересными являются host-based оценки уязвимостей, которые запускаются от имени непривилегированного пользователя и пытаются получить доступ привилегированного пользователя на исследуемой системе.

Network-Based анализ уязвимостей

Системы network-based анализа уязвимостей получили распространение в последние несколько лет. Эти системы устанавливают удаленное соединение с целевой системой и пытаются провести реальную атаку. Проведение реальных атак или поиск слабых мест может происходить независимо от того, есть ли разрешение на доступ к целевой системе; следовательно, это можно считать non-credential анализом. Более того, так как network-based анализ уязвимостей выглядит как реальная атака или сканирование целевой системы, он также иногда называется активным анализом.

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

Существуют два метода, используемые network-based для оценки уязвимостей:

Тестирование ошибок (exploit’ов) – в этом случае система пытается осуществить реальную атаку. После этого возвращается результат, указывающий, была ли атака успешной.

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

Преимущества систем анализа уязвимостей

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

Недостатки и проблемы систем анализа уязвимостей

Host-based анализаторы уязвимостей сильно привязаны к конкретным ОС и приложениям; следовательно, они часто являются более дорогими с точки зрения развертывания, сопровождения и управления.
Network-based анализаторы уязвимостей являются платформо-независимыми, но они менее точные и создают больше ложных тревог.
Некоторые network-based проверки, особенно это относится к DoS-атакам, могут разрушить систему, которую они тестируют.
При выполнении оценки уязвимостей в сетях, в которых работают системы обнаружения проникновений, IDPS могут блокировать проведение таких оценок. Хуже того, регулярные network-based оценки могут "обучить" некоторые IDPS, основанные на обнаружении аномалий. В результате этого IDPS будут игнорировать реальные атаки.

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

4.4.3 Проверка целостности файлов

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

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

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

4.5 Выбор IDPS

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

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

Выбор наиболее подходящейIDPS

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

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

4.5.1 Определение окружения IDPS

Во-первых, следует понимать, в каком окружении IDPS должна функционировать. Это важно, поскольку если IDPS не развернута с учетом информационных источников, которые доступны системе, она может не иметь возможности видеть все, что делается в сети или системе: как атаку, так и нормальную деятельность.

Технические спецификации окружения систем

Во-первых, следует определить технические характеристики окружения систем. Такая спецификация должна включать топологию сети с учетом количества и расположения хостов, ОС на каждом хосте, количества и типов сетевых устройств, таких как маршрутизаторы и коммутаторы. Должно быть сделано описание всех серверов, включая тип, конфигурацию, прикладное ПО и версии, выполняющиеся на каждом из них. Если работает система управления сетью, то нужно описать ее функционирование.
Технические спецификации используемой системы безопасности
После того, как описаны технические характеристики окружения системы, следует определить возможности системы обеспечения безопасности, которые уже существуют.
Следует определить количество, типы и расположение межсетевых экранов, серверов идентификации и аутентификации, устройств шифрования данных и соединений, антивирусные пакеты, ПО управления доступом, специализированную аппаратуру обеспечения безопасности (такую, как аппаратный крипто-акселератор для веб-серверов), VPN и любые другие механизмы обеспечения безопасности.
Цели организации
Некоторые IDPS разработаны для обеспечения определенных нужд конкретной индустрии или ниши рынка, например, электронная коммерция, здравоохранение, финансовые рынки. Следует определить соответствие возможностей системы целям организации.
Возможность формализации окружения системы и принципы управления, используемые в организации
Организационные стили могут сильно отличаться, в зависимости от функций организации и ее традиций. Например, военные или аналогичные организации, которые имеют дело с проблемами национальной безопасности, стремятся функционировать с высокой степенью формализации своей деятельности, особенно в сравнении с университетами или другими академическими средами.
Некоторые IDPS поддерживают создание конфигураций с формально заданными политиками с возможностями создания расширенных отчетов, детализирующих нарушения политики.

4.5.2 Цели использования IDPS

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

Наиболее простой способ описания целей состоит в определении категорий возможных угроз.

Защита от внешних угроз

Следует максимально конкретно определить возможные внешние угрозы.
Защита от внутренних угроз

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

4.5.3 Существующая политика безопасности

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

Структурированность

Следует определить цели политики безопасности в терминах стандартных целей безопасности (целостность, конфиденциальность и доступность), а также общих целей управления.
Описание функций, выполняемых пользователями системы

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

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

4.6 Требования организации к функционированию IDPS

4.6.1 Цели организации

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

Внешние по отношению к IDPS требования

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

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

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

Следует рассмотреть, имеются ли какие-либо функции аудита, которые IDPS может предоставлять или поддерживать.
Требования аккредитации системы

Следует рассмотреть, какая аккредитация требуется для IDPS и других систем.

4.6.2 Требования к ресурсам, необходимым для функционирования IDPS

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

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

4.7 Возможности IDPS

IDPS должна обеспечивать следующие возможности.

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

4.7.1 Учет возможного роста организации

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

Адаптируемость программного продукт к возрастающей квалификации пользователей
Следует проанализировать, может ли интерфейс IDPS конфигурироваться для использования настраиваемых по мере необходимости различных способов быстрого доступа к конфигурационным параметрам и т.п.
Адаптируемость программного продукта к возрастанию и изменению инфраструктуры организации
Это означает возможность масштабирования IDPS при расширении и увеличении разнородности сети. Большинство производителей могут хорошо адаптировать свои продукты к возрастанию сетей. Следует также узнать о поддержке новых стандартов протоколов и типов платформ.
Адаптируемость программного продукта к возрастанию и изменению угроз безопасности
Данный вопрос особенно актуален для текущего состояния угроз в интернете, когда каждый месяц появляется по 30-40 новых атак.

4.7.2 Предоставляемая поддержка программного продукта

Подобно другим программным продуктам, IDPS требуют постоянного сопровождения и поддержки.

Поддержка инсталляции и конфигурирования
Многие производители предоставляют квалифицированную помощь при инсталляции и конфигурировании IDPS; другие считают, что это могут делать собственные специалисты потребителя, и обеспечивают только поддержку по телефону или e-mail.
Возможность непрерывной поддержки программного продукта
- Существует ли подписка на обновления.
  В большинстве IDPS, которые определяют злоупотребления, программный продукт настолько хорош, насколько база данных сигнатур соответствует текущему состоянию. Большинство производителей предоставляют подписку на обновления сигнатур, которые создаются с некоторой периодичностью.
- Как часто подписчики получают обновления.
  При современных угрозах, когда ежемесячно публикуется 30-40 новых атак, это является важным фактором.
- Как быстро после обнаружения новой атаки производитель поставит новую сигнатуру.
  Если IDPS используется для защиты популярных сайтов в интернете, особенно важно получать сигнатуры для новых атак как можно быстрее.
- Включает ли подписка на обновление также и обновление ПО.
  Большинство IDPS являются программными продуктами и, следовательно, могут содержать ошибки и уязвимости. Таким образом, возможность частого обновления ПО также является весьма существенным фактором.
- Как быстро выпускаются обновления ПО после того, как о проблеме было сообщено производителю.
  Так как ошибки ПО в IDPS могут позволить атакующему обойти всю защиту, особенно важно, чтобы проблемы фиксировались надежно и быстро.
- Включены ли сервисы технической поддержки и сколько они стоят.
  Сервисы технической поддержки означают помощь производителя в настройке и адаптации IDPS для конкретных нужд, мониторинге наследуемых систем на предприятии или создание отчетов о результатах IDPS с использованием протокола или формата заказчика.
- Какой способ контакта (e-mail, телефон, системы мгновенных сообщений , веб-интерфейс) осуществляется для выполнения технической поддержки.
  Следует выяснить, как доступны сервисы технической поддержки для обработки инцидентов или других критичных по времени ситуаций.
- Какие имеются гарантии, связанные с IDPS.
  Как и в случае других продуктов ПО, IDPS должны иметь определенные гарантии, связанные с их функционированием.
Ресурсы по обучению, предоставляемые производителем как часть пакета услуг
После того, как IDPS выбрана, инсталлирована и сконфигурирована, она должна обслуживаться персоналом предприятия. Для того чтобы эти люди могли оптимально использовать IDPS, они должны научиться ее использовать. Некоторые производители предоставляют программы обучения как часть пакета услуг.
Дополнительные ресурсы, доступные для обучения
В случае, если производитель IDPS не предоставляет обучение как часть пакета IDPS, следует выделить определенный бюджет для обучения персонала.

4.8 Развертывание IDPS

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

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

4.8.1 Стратегия развертывания IDPS

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

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

4.8.2 Развертывание network-based IDPS

Единственный вопрос, который следует тщательно продумать при развертывании network-based IDPS, — это расположение системных сенсоров. Существует много вариантов расположения network-based IDPS, каждый из которых имеет свои преимущества:

увеличить изображение

Рис. 4.1. Возможные варианты расположения сенсоров network-based IDPS

Позади внешнего межсетевого экрана в DMZ-сети (расположение 1)

Преимущества:

Видит атаки, исходящие из внешнего мира, которым удалось преодолеть первую линию обороны сетевого периметра.
Может анализировать проблемы, которые связаны с политикой или производительностью межсетевого экрана, обеспечивающего первую линию обороны.
Видит атаки, целями которых являются прикладные серверы (такие, как веб или ftp), обычно расположенные в DMZ.
Даже если входящая атака не распознана, IDPS иногда может распознать исходящий трафик, который возникает в результате компрометации сервера.

Перед внешним межсетевым экраном (расположение 2)

Преимущества:

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

На основной магистральной сети (расположение 3)

Преимущества:

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

В критичных подсетях (расположение 4)

Преимущества:

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

4.8.3 Развертывание host-based IDPS

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

Далее следует рассмотреть возможность повышения квалификации администраторов. В большинстве случаев эффективность конкретной host-based IDPS зависит от возможности администратора различать ложные и верные тревоги.

Также важно (так как часто администратор не сопровождает постоянно host-based IDPS) установить график проверки результатов IDPS. Если это не сделано, риск, что противник изменит что-либо в IDPS в течение осуществления атаки, возрастает.

4.8.4 Стратегии оповещения о тревогах

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

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

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

4.9 Сильные стороны и ограниченность IDPS

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

4.9.1 Сильные стороны IDPS

IDPS хорошо выполняют следующие функции:

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

4.9.2 Ограничения IDPS

IDPS имеют много ограничений. Наиболее существенные следующие:

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

4.10 Выходные данные IDPS

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

время и дату;
IP-адрес сенсора;
название атаки, специфичное для производителя;
стандартное название атаки (если оно существует);
IP-адреса источника и назначения;
номера портов источника и назначения;
сетевой протокол, используемый для атаки.

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

Данное описание обычно содержит следующую информацию:

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

4.11 Будущие направления развития IDPS

Хотя функция аудита системы, которая являлась первоначальной задачей IDPS за последние пятьдесят лет, стала формальной дисциплиной, поле для исследований IDPS все еще остается обширным, большинство исследований датировано не позднее 80-х годов. Более того, широкое коммерческое использование IDPS не начиналось до середины 90-х.

Intrusion Detection и Vulnerability Assessment является быстро развивающейся областью исследований.

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

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

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

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

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

Лекция 19. Обнаружение и предотвращение вторжений

Цель

Принципы использования IDS

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

Для обнаружения и предотвращения вторжения, необходимо указать следующую информацию:

Какой трафик следует анализировать.
Что следует искать в анализируемом трафике.
Какое действие необходимо предпринять при обнаружении вторжения.

Эта информация указывается в IDP-правилах.

Maintenance и Advanced IDP

Компания D-Link предоставляет два типа IDP:

Maintenance IDP
Maintenance IDP является основой системы IDP и включено в стандартную комплектацию NetDefendDFL-210, 800, 1600 и 2500.
Maintenance IDP является упрощенной IDP, что обеспечивает базовую защиту от атак, и имеет возможность расширения до более комплексной Advanced IDP.
IDP не входит в стандартную комплектацию DFL-260, 860, 1660, 2560 и 2560G; для этих моделей межсетевых экранов необходимо приобрести подписку на Advanced IDP.
Advanced IDP
Advanced IDP является расширенной системой IDP с более широким диапазоном баз данных сигнатур и предъявляет более высокие требования к оборудованию. Стандартной является подписка сроком на 12 месяцев, обеспечивающая автоматическое обновление базы данных сигнатур IDP.
Эта опция IDP доступна для всех моделей D-Link NetDefend, включая те, в стандартную комплектацию которых не входит Maintenance IDP.
Maintenance IDP можно рассматривать, как ограниченное подмножество Advanced IDP. Рассмотрим функционирование Advanced IDP.
Advanced IDP приобретается как дополнительный компонент к базовой лицензии NetDefendOS. Подписка означает, что база данных сигнатур IDP может быть загружена на NetDefendOS, а также, что база данных регулярно обновляется по мере появления новых угроз.
Обновления базы данных сигнатур автоматически загружаются системой NetDefendOS через сконфигурированный интервал времени. Это выполняется с помощью HTTP-соединения с сервером сети D-Link, который предоставляет последние обновления базы данных сигнатур. Если на сервере существует новая версия базы данных сигнатур, она будет загружена, заменив старую версию.
Термины Intrusion Detection and Prevention (IDP), Intrusion Prevention System (IDP) и Intrusion Detection System (IDS) взаимозаменяютдругдруга. Все они относятся к функции IDP.

Последовательность обработка пакетов

Последовательность обработки пакетов при использовании IDP является следующей:

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

Поиск на соответствие шаблону

Сигнатуры

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

Рассмотрим пример простой атаки, состоящий в обращении к FTP-серверу. Неавторизованный пользователь может попытаться получить файл паролей passwd с FTP-сервера с помощью команды FTP RETR passwd. Сигнатура, содержащая текстовые строки ASCII RETR и passwd, обнаружит соответствие, указывающее на возможную атаку. В данном примере шаблон задан в виде текста ASCII, но поиск на соответствие шаблону выполняется аналогично и для двоичных данных.

Распознавание неизвестных угроз

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

Описания сигнатур

Каждая сигнатур имеет пояснительное текстовое описание. Прочитав текстовое описание сигнатуры, можно понять, какую атаку или вирус поможет обнаружить данная сигнатура. В связи с изменением характера базы данных сигнатур, текстовые описания не содержатся в документации D-Link, но доступны на веб-сайте D-Link: http://security.dlink.com.tw

Типы сигнатур IDP

В IDP имеется три типа сигнатур, которые предоставляют различные уровни достоверности в определении угроз:

Intrusion Protection Signatures (IPS) – Данный тип сигнатур обладает высокой точностью, и соответствие трафика данному шаблону в большинстве случаев означает атаку. Для данных угроз рекомендуется указывать действие Protect. Эти сигнатуры могут обнаружить действия, направленные на получение прав администратора, и сканеры безопасности.
Intrusion Detection Signatures (IDS) – У данного типа сигнатур меньше точности, чем у IPS, и они могут дать иметь ложные срабатывания, таким образом, поэтому перед тем как указывать действие Protect рекомендуется использовать действие Audit.
Policy Signatures – Этот тип сигнатур обнаруживает различные типы прикладного трафика. Эти сигнатуры могут использоваться для блокировки некоторых приложений, предназначенных для совместного использования приложений и мгновенного обмена сообщениями.

Предотвращение атак Denial-of-Service

Механизмы DoS-атак

DoS-атаки могут выполняться самыми разными способами, но все они могут быть разделены на три основных типа:

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

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

Перечислим некоторые из наиболее часто используемых DoS-атак:

Ping of Death / атаки Jolt
Перекрытие фрагментов: Teardrop / Bonk / Boink / Nestea
Land и LaTierra атаки
WinNuke атака
Атаки с эффектом усиления: Smurf, Papasmurf, Fraggle
TCP SYN Flood
Jolt2

Атаки Ping of Death и Jolt

"Ping of Death" является одной из самых ранних атак, которая выполняется на 3 и 4 уровнях стека протоколов. Один из простейших способов выполнить эту атаку – запустить ping -l 65510 1.2.3.4 на Windows 95, где 1.2.3.4 – это IP-адрес компьютера-жертвы. "Jolt" – это специально написанная программа для создания пакетов в операционной системе, в которой команда ping не может создавать пакеты, размеры которых превышают стандартные нормы.

Смысл атаки состоит в том, что общий размер пакета превышает 65535 байт, что является максимальным значением, которое может быть представлено 16-битным целым числом. Если размер больше, то происходит переполнение.

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

Атаки Ping of Death и Jolt регистрируются в логах как отброшенные пакеты с указанием на правило "LogOversizedPackets". Следует помнить, что в этом случае IP-адрес отправителя может быть подделан.

Атаки, связанные с перекрытием фрагментов: Teardrop, Bonk, Boink и Nestea

Teardrop – это атака, связанная с перекрытием фрагментов. Многие реализации стека протоколов плохо обрабатывают пакеты, при получении которых имеются перекрывающиеся фрагменты. В этом случае возможно как исчерпание ресурсов, так и сбой.

NetDefendOS обеспечивает защиту от атак перекрытия фрагментов. Перекрывающимся фрагментам не разрешено проходить через систему.

Teardrop и похожие атаки регистрируются в логах NetDefendOS как отброшенные пакеты с указанием на правило "IllegalFrags". Следует помнить, что в этом случае IP-адрес отправителя может быть подделан.

Атаки Land и LaTierra

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

Атака состоит в использовании IP-адреса компьютера-жертвы в полях Source и Destination.

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

Атаки Land и LaTierra регистрируются в логах NetDefendOS как отброшенные пакеты с указанием на правило по умолчанию AutoAccess, или, если определены другие правила доступа, указано правило правило доступа, в результате которого отброшен пакет. В данном случае IP-адрес отправителя не представляет интереса, так как он совпадает с IP-адресом получателя.

Атака WinNuke

Принцип действия атаки WinNuke заключается в подключении к TCP-сервису, который не умеет обрабатывать "out-of-band" данные (TCP-пакеты с установленным битом URG), но все же принимает их. Это обычно приводит к зацикливанию сервиса и потреблению всех ресурсов процессора.

Одним из таких сервисов был NetBIOS через TCP/IP на WINDOWS-машинах, которая и дала имя данной сетевой атаке.

NetDefendOS обеспечивает защиту двумя способами:

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

Веб-интерфейс

Advanced Settings -> TCP -> TCPUrg

увеличить изображение

Рис. 9.1.

Как правило, атаки WinNuke регистрируются в логах как отброшенные пакеты с указанием на правило, запретившего попытку соединения. Для разрешенных соединений появляется запись категории "TCP" или "DROP" (в зависимости от настройки TCP URG), с именем правила "TCP URG". IP-адрес отправителя может быть не поддельным, так как соединение должно быть полностью установлено к моменту отправки пакетов "out-of-band".

Атаки, приводящие к увеличению трафика: Smurf, Papasmurf, Fraggle

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

"Smurf" и "Papasmurf" отправляют эхо-пакеты ICMP по широковещательному адресу, указывая в качестве IP-адреса источника IP-адрес жертвы. После этого все компьютеры посылают ответные пакеты жертве.
"Fraggle" базирауется на "Smurf", но использует эхо-пакеты UDP и отправляет их на порт 7. В основном, атака "Fraggle" имеет более слабое усиление, так как служба echo активирована у небольшого количества хостов.

Атаки Smurf регистрируются в логах NetDefendOS как большое число отброшенных пакетов ICMP Echo Reply. Для подобной перегрузки сети может использоваться поддельный IP-адрес. Атаки Fraggle также отображаются в логах NetDefendOS как большое количество отброшенных пакетов. Для перегрузки сетb используется поддельный IP-адрес.

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

Веб-интерфейс

Advanced Settings -> IP -> DirectedBroadcasts

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

Защита на стороне компьютера-жертвы

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

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

Типы flood-атак Smurf и Papasmurf на стороне жертвы выглядят как ответы ICMP Echo Response. Если не используются правила FwdFast, таким пакетам не будет разрешено инициировать новые соединения независимо от того, существуют ли правила, разрешающие прохождение пакетов.
Пакеты Fraggle могут прийти на любой UDP-порт назначения, который является мишенью атакующего. В этой ситуации может помочь увеличение ограничений в наборе правил.

Шейпинг трафика также помогает предотвращать некоторые flood-атаки на защищаемые сервера.

Атаки TCP SYN Flood

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

Система NetDefendOS обеспечивает защиту от flood-атак TCP SYN, если установлена опция SYN Flood Protection в соответствующем сервисе, который указан в IP-правиле фильтрования. Иногда опция может обозначаться как SYN Relay.

увеличить изображение

Рис. 9.2.

Защита от flood-атак включена по умолчанию в таких сервисах, как http-in, https-in, smtp-in и ssh-in.

Механизм защиты от атак SYN Flood

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

Обнаружение SYN Floods

Атаки TCP SYN flood регистрируются в логах NetDefendOS как большое количество новых соединений (или отброшенных пакетов, если атака направлена на закрытый порт). Следует помнить, что в этом случае IP-адрес отправителя может быть подделан.

ALG автоматически обеспечивает защиту от flood-атак

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

Атака Jolt2

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

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

Если выбранное злоумышленником значение смещения фрагмента больше, чем ограничения, указанные в настройках Advanced Settings -> Length Limit Settings в NetDefendOS, пакеты будут немедленно отброшены. Атаки Jolt2 могут быть зарегистрированы в логах. Если злоумышленник выбирает слишком большое значение смещения фрагмента для атаки, это будет зарегистрировано в логах как отброшенные пакеты с указанием на правило LogOversizedPackets. Если значение смещения фрагмента достаточно маленькое, регистрации в логах не будет. IP-адрес отправителя может быть подделан.

Атаки Distributed DoS (DDoS)

Наиболее сложной DoS-атакой является атака Distributed Denial of Service. Хакеры используют сотни или тысячи компьютеров по всей сети интернет, устанавливая на них программное обеспечение для выполнения DDoS-атак и управляя всеми этими компьютерами для осуществления скоординированных атак на сайты жертвы. Как правило эти атаки расходуют полосу пропускания, вычислительные мощности маршрутизатора или ресурсы для обработки стека протоколов, в результате чего сетевые соединения с жертвой не могут быть установлены.

Хотя последние DDoS-атаки были запущены как из частных, так и из публичных сетей, хакеры, как правило, часто предпочитают корпоративные сети из-за их открытого и распределенного характера. Инструменты, используемые для запуска DDoS-атак, включают Trin00, TribeFlood Network (TFN), TFN2K и Stacheldraht.

Описание практической работы

Общий список сигнатур

В веб-интерфейсе все сигнатуры перечислены в разделе IDP/IPS ->IDP Signatures.

увеличить изображение

Рис. 9.3.

IDP-правила

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

Веб-интерфейс:

IDP/IPS -> IDP Rules -> Add -> IDP Rule

Действия IDP

При выявлении вторжения будет выполнено действие, указанное в правиле IDP. Может быть указано одно из трех действий:

Ignore – Если обнаружено вторжение, не выполнять никаких действий и оставить соединение открытым.
Audit – Оставить соединение открытым, но зарегистрировать событие.
Protect – Сбросить соединение и зарегистрировать событие. Возможно использовать дополнительную опцию занесения в "черный список" источник соединения.

увеличить изображение

Рис. 9.4.

Нормализация HTTP

IDP выполняет нормализацию HTTP,т.е. проверяет корректность URI в HTTP-запросах. В IDP-правиле можно указать действие, которое должно быть выполнено при обнаружении некорректного URI.

увеличить изображение

Рис. 9.5.

IDP может определить следующие некорректные URI:

Некорректная кодировка UTF8

Выполняется поиск любых недействительных символов UTF8 в URI.

Некорректный шестнадцатеричный код

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

Двойное кодирование

Выполняется поиск любой шестнадцатеричной последовательности, которая сама является закодированной с использованием других управляющих шестнадцатеричных последовательностей. Примером может быть последовательность %2526, при этом %25 может быть интерпретировано HTTP-сервером как %, в результате получится последовательность %26, которая будет интерпретирована как &.

Предотвращение атак, связанных со вставкой символов или обходом механизмов IDP

В IDP-правиле можно установить опцию Protect against Insertion/Evasion attack. Это защита от атак, направленных на обход механизмов IDP. Данные атаки используются тот факт, что в протоколах TCP/IP пакет может быть фрагментирован, и отдельные пакеты могут приходить в произвольном порядке. Атаки, связанные со вставкой символов и обходом механизмов IDP, как правило используют фрагментацию пакетов и проявляются в процессе сборки пакетов.

Атаки вставки

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

В качестве примера предположим, что поток данных состоит из 4 фрагментов пакетов: p1, p2, p3 и p4. Злоумышленник может сначала отправить фрагменты пакетов p1 и p4 целевому приложению. Они будут удерживаться и системой IDP, и приложением до прихода фрагментов p2 и p3, после чего будет выполнена сборка. Задача злоумышленника состоит в том, чтобы отправить два фрагмента p2’ и p3’ системе IDP и два других фрагмента p2 и p3 приложению. В результате получаются различные потоки данных, который получены системой IDP и приложением.

Атаки обхода

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

Обнаружение подобных атак

Если включена опция Insertion/Evasion Protect attacts, и атака вставки или обхода обнаружена, межсетевой экран автоматически корректирует поток данных, удаляя данные, связанные с атакой.

увеличить изображение

Рис. 9.6.

Запись в лог событий, связанных с атаками вставки и обхода

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

Сообщение Attack Detected, указывающее на то, что атака была обнаружена и предотвращена.

Сообщение Unable to Detect, уведомляющее о том, что система NetDefendOS не смогла выявить возможную атаку при сборке потока TCP/IP, хотя подобная атака могла присутствовать. Эта ситуация возможна при редких и сложных шаблонах данных.

Рекомендуемые настройки

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

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

Группы сигнатур IDP

увеличить изображение

Рис. 9.7.

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

Группы сигнатур IDP имеют три уровня иерархии. На верхнем уровне указывается тип группы сигнатур, на втором указывается тип приложения или протокола и на третьем указывается отдельное приложение или протокол. Примером является IDS_AUTHENTICATION_KERBEROS, где IDS означает тип сигнатуры, AUTHENTICATION – тип протокола, и KERBEROS – конкретный протокол. Определены следующие типы групп сигнатур и приложений.

Использование подстановки символов (Wildcarding) в сигнатурах IDP

Для выбора более одной группы сигнатур IDP можно использовать метод подстановки (Wildcarding). Символ "?" используется для подстановки единственного знака в имени группы. Символ "*" используется для замены любого количества символов.

Для увеличения производительности следует использовать минимальное количество сигнатур. Например, использование IDS_WEB*, IPS_WEB*, IDS_HTTP* и IPS_HTTP* будет достаточным для защиты HTTP-сервера.

"Черный список" хостов и сетей

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

увеличить изображение

Рис. 9.8.

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

TimetoBlockHost /Networkin Seconds
Хост или сеть, которые являются источником трафика, остаются в "черном списке" в течение указанного времени, а затем удаляются. Если тот же источник содержится в другой записи в "черном списке", то в таком случае будет восстановлено первоначальное время блокировки, т.е. суммирования не происходит.
Block only this Service
По умолчанию "черный список" блокирует все сервисы с данного хоста.
Exempt already established connections from Blacklisting
Если существуют установленные соединения с тем же источником, что и новая запись в "черном списке", то они не будут удалены, если установлена данная опция.

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

Для просмотра, а также для управления содержимым "черного" и "белого списков" используется команда blacklist.

Командная строка:

add IDPRule Service=http-all SourceInterface=wan2 SourceNetwork=all-nets DestinationInterface=dmz DestinationNetwork=dmz/dmz_net Name=idpWEB

Получение по e-mail сообщений о событиях IDP

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

После того, как произошло событие IDP, NetDefendOS ожидает несколько секунд (определяется параметром Hold Time) прежде, чем отправить уведомление по электронной почте. При этом сообщение будет отправлено только в том случае, если число событий, произошедших в этот период времени, больше или равно, чем значение Log Threshold. После отправки уведомления NetDefendOS ожидает несколько секунд (Minimum Repeat Time) прежде, чем отправить новое сообщение.

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

Веб-интерфейс:

System -> Log and Event Receivers -> Add -> SMTP Event Receiver

увеличить изображение

Рис. 9.9.

Командная строка:

add LogReceiver LogReceiverSMTP IDS_log1 IPAddress=InterfaceAddresses/Default_dns Receiver1=admin@oit.cmc.msu.ru

"Белый список" хостов и сетей

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

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

Веб-интерфейс:

System -> Whitelist -> Add -> Whitelist Host

увеличить изображение

Рис. 9.10.

Командная строка:

add BlacklistWhiteHost Addresses=lan/lan_Server1 Service=ssh

Лекция 20. Приоритезация трафика и создание альтернативных маршрутов

5.1 Создание альтернативных маршрутов доступа в интернет

5.1.1 Альтернативные таблицы маршрутизации

Стандартная маршрутизация отправляет пакеты в зависимости от IP-адреса получателя в соответствии с информацией, полученной из статических или динамических протоколов маршрутизации.

Policy-based Routing (PBR) маршрутизация предоставляет более гибкие возможности определения правил маршрутизации на основе большего количества критериев, используя для этого альтернативные таблицы маршрутизации.

PBR-маршрутизация может быть следующих типов:

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

Создание альтернативных маршрутов основано на следующих принципах.

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

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

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

5.1.2 Правила выбора таблицы маршрутизации

Для выбора таблицы маршрутизации используется так называемая "маршрутизация на основе правил" – "Policy-based Routing" (PBR).

Таблица маршрутизации выбирается с помощью правил маршрутизации – Routing Rules. Эти правила определяют, какую таблицу маршрутизации следует использовать для конкретного типа трафика. Тип трафика может задаваться набором сервисов (например, HTTP) или интерфейсом источника/назначения и сетью источника/назначения.

Записи Routing Rules упорядочены, используется первое правило, параметры в котором соответствуют параметрам пакета.

Рассмотрим выбор маршрута на следующем примере. Предположим, что сеть имеет следующую топологию.

увеличить изображение

Рис. 5.1. Топология сети с двумя сервис-провайдерами

С хостов, расположенных в DMZ, доступ в интернет необходимо выполнять через ISP 1, т.е. через интерфейс wan1 маршрутизатора.

С хостов, расположенных в LAN, доступ в интернет необходимо выполнять через ISP 2, т.е. через интерфейс wan2 маршрутизатора.

Когда маршрутизатор получает пакет, относящийся к новому соединению, то выбор таблицы маршрутизации происходит следующим образом: Определяется интерфейс назначения, используя таблицу main. В ней должен существовать либо маршрут для сети назначения, либо маршрут по умолчанию (сеть назначения – all-nets), который будет определять интерфейс назначения в случае, если более точный маршрут не будет найден.

увеличить изображение

Рис. 5.2. Пример таблицы маршрутизации main

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

Осуществляется поиск правила в Routing Rules, соответствующего параметрам пакета: интерфейс и сеть источника/назначения и протокол/сервис. Если подходящее правило найдено, то для определения маршрута используется указанная таблица маршрутизации. Если подходящее правило не найдено, то используется таблица main.

увеличить изображение

Рис. 5.3. Выбор таблицы маршрутизации

В нашем примере будет использоваться таблица altInet.
После того, как выбрана необходимая таблица маршрутизации, выполняется проверка доступности IP-адреса источника с входящего интерфейса. Ищется соответствие с правилами доступа (Access Rules). Если нет ни одного правила доступа, или не найдено соответствие параметров пакета ни одному из правил доступа, то в выбранной таблице маршрутизации осуществляется поиск маршрута к IP-адресу источника. Если маршрут не найден, в журнал записывается сообщение об ошибке "Default access rule".
В выбранной таблице маршрутизации осуществляется поиск маршрута, по которому пакет будет отправлен. Последовательность, в которой просматриваются выбранная таблица и таблица main, зависит от параметра Ordering, который определяется для каждой альтернативной таблицы.

увеличить изображение

Рис. 5.4. Определение последовательности просмотра выбранной таблицы маршрутизации и таблицы main
- Default – по умолчанию маршрут ищется сначала в основной таблице маршрутизации main. Если соответствующий маршрут не найден или найден маршрут с сетью назначения all-nets (0.0.0.0/0), то осуществляется поиск в альтернативной таблице. Если соответствующий маршрут в альтернативной таблице не найден, то будет использоваться маршрут по умолчанию из таблицы main.
- First – в этом случае поиск маршрута осуществляется сначала в альтернативной таблице маршрутизации. Если соответствующий маршрут не найден, то поиск осуществляется в таблице main. Если в альтернативной таблице маршрутизации найден маршрут с сетью назначения all-nets (0.0.0.0/0), то используется этот маршрут.
- Only – маршрут ищется только в выбранной альтернативной таблице. Данная опция позволяет создавать виртуальные системы, каждая из которых использует свою таблицу маршрутизации.
  
  увеличить изображение
  
  Рис. 5.5. Пример альтернативной таблицы маршрутизации
После того, как маршрут найден, соединение обрабатывается обычным образом набором IP-правил фильтрования. В частности, если правилами фильтрования определяется, что должно использоваться правило преобразования адреса, например, SAT, то это преобразование выполняется после выбора таблицы маршрутизации. Важно подчеркнуть, что поиск маршрута для определения интерфейса назначения осуществляется в выбранной альтернативной таблице с еще не преобразованным адресом.

увеличить изображение

Рис. 5.6. Правила фильтрования трафика, маршрутизируемого альтернативной таблицей
Если проверка IP-правилами фильтрования прошла успешно, то в таблице состояний системы открывается новое соединение, и пакет передается по этому соединению.

увеличить изображение

Рис. 5.7. Трафик из dmz-сети

увеличить изображение

Рис. 5.8. Проверка, что соединение из dmz-сети установлено через интерфейс wan1
Трафик из lan-сети будет идти через ISP 2, т.е. через интерфейс wan2.

увеличить изображение

Рис. 5.9. Трафик из lan-сети

увеличить изображение

Рис. 5.10. Проверка, что соединение из dmz-сети установлено через интерфейс wan1

5.2 Приоритезация трафика

Рассмотрим основные принципы приоритезации трафика и обеспечение качества обслуживания в системе NetDefendOS:

Основные способы ограничения (шейпинга) трафика.
Шейпинг трафика на основе правил IDP.
Правила порога.

5.2.1 Ограничение (шейпинг) трафика

Гарантирование качества сервиса и TCP/IP

Недостатком TCP/IP является отсутствие возможности гарантировать определенное качество сервиса (Quality of Service – QoS). Под QoS понимается возможность гарантировать определенные сервисы и ограничить полосу пропускания как для определенных сервисов, так и для определенных пользователей. Для крупных сетей были разработаны такие решения, как архитектура дифференцированного обслуживания – Differentiated Services (Diffserv), которые используют информацию в заголовках пакетов.

Поддержка Diffserv в NetDefendOS

NetDefendOS поддерживает архитектуру Diffserv следующими способами:

NetDefendOS передает 6 битов значения кода дифференцированного обслуживания (Differentiated Services Code Point (DSCP) – Diffserv), и копирует эти биты из заголовка данных внутри VPN-туннеля в инкапсулирующие пакеты.
Подсистема шейпинга трафика NetDefendOS может использовать DSCP-биты как основу для приоритезации трафика, проходящего через межсетевой экран.

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

Основные принципы шейпинга трафика

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

NetDefendOS обеспечивает QoS, позволяя администратору указывать приоритеты для сервисов и обеспечивать гарантии полосы пропускания. Этот подход называется шейпингом трафика (traffic shaping) и идеально подходит для управления полосой пропускания в локальной сети, а также для управления трафиком в "узких" местах, которые могут образоваться в крупных сетях. Шейпинг применяется к любому типу трафика, включая трафик, проходящий через VPN-туннели.

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

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

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

Шейпинг трафика в NetDefendOS

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

Существует два основных компонента, с помощью которых задается шейпинг трафика:

Каналы (Pipes)
Правила каналов (Pipe Rules)

Каналы (Pipes)

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

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

увеличить изображение

Рис. 5.11. Задание пропускной способности канала

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

увеличить изображение

Рис. 5.12. Задание гарантированной полосы пропускания для трафика с определенным приоритетом

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

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

увеличить изображение

Рис. 5.13. Пример канала

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

Правила каналов (Pipe Rules)

Правило каналов определяет, какой трафик направляется в какой канал. В каждом правиле канала указывается интерфейс/сеть источника/назначения, а также сервисы, к которым применяется правило. Одно или несколько Правил канала составляют множество Правил канала.

увеличить изображение

Рис. 5.14. Пример правил канала

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

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

увеличить изображение

Рис. 5.15. Параметры трафика, направляемого в канал

При создании правила канала перечисляются используемые в этом правиле каналы и указывается направление трафика в каждом канале. Списки каналов образует так называемые цепочки каналов (chain). Цепочки бывают двух типов: каналы для входящего трафика образуют Return Chain, каналы для исходящего трафика образуют Forward Chain.

Если указан только один канал, то характеристики данного канала применяются к трафику. Если указано несколько каналов, то эти каналы формируют цепочку каналов, через которые пройдет трафик. Максимальное количество каналов в цепочке – 8.

увеличить изображение

Рис. 5.16. Прямая и обратная цепочки каналов

Обход шейпинга трафика

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

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

Каналы и IP-правила фильтрования FwdFast

Следует заметить, что шейпинг трафика нельзя применять к трафику, к которому применялись правила фильтрования FwdFast.

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

Приоритеты

Приоритет по умолчанию

Объем передаваемых данных указывается либо для определенного Приоритета, либо для определенной Группы.

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

увеличить изображение

Рис. 5.17. Использование приоритетов для задания пропускной способности канала и гарантирования полосы пропускания

Если приоритет не указан, то у всех пакетов один и тот же приоритет по умолчанию – 0.

увеличить изображение

Рис. 5.18. Приоритеты канала

Уровни приоритетов

Существует восемь приоритетов, пронумерованных от 0 до 7. Приоритет 0 – наименьший приоритет, 7 – наибольший приоритет. Приоритет можно считать отдельной очередью трафика: трафик с приоритетом 2 будет отправлен раньше трафика с приоритетом 0, а трафик с приоритетом 4 перед трафиком с приоритетом 2.

Значение приоритета является относительным. При определении очередности прохождения трафика имеет значение только относительное значение приоритета трафика. Например, если используются два приоритета, то назначение приоритетов 4 и 6 вместо 0 и 3 не влияет на конечный результат.

Способ назначения приоритета трафику указывается в правиле канала. Приоритет трафика может определяться одним из трех способов:

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

увеличить изображение

Рис. 5.19. Использование приоритета канала для трафика
Использование фиксированного приоритета
Приоритет пакетов явно указывается в правиле.

увеличить изображение

Рис. 5.20. Использование фиксированного приоритета для трафика
Использование DSCP-битов
Приоритет пакетов определяется значением DSCP-битов в пакете. DSCP является элементом архитектуры Diffserv, а биты Type of Service (ToS) являются частью заголовка IP-пакета.

увеличить изображение

Рис. 5.21. Использование архитектуры дифференцированного обслуживания

Назначение приоритета для канала

При создании канала можно указать значения приоритета по умолчанию (Default Precedence), минимального приоритета (Minimum Precedence) и максимального приоритета (Maximum Precedence).

Приоритет по умолчанию – это приоритет, назначаемый пакету, в случае, если правилом канала трафику назначен приоритет первого канала.

увеличить изображение

Рис. 5.22. Назначение приоритета для канала

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

Гарантирование полосы пропускания для канала

Для канала можно дополнительно указать гарантирование полосы пропускания для каждого приоритета. Это гарантирование может быть указано в килобитах в секунду и/или пакетах в секунду (если указаны оба значения, то будет использоваться меньшее).

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

Наименьший приоритет имеет особое значение: он действует как Приоритет негарантированной доставки (Best Effort). Все пакеты с данным приоритетом обрабатываются в порядке поступления при наличии полосы пропускания.

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

Рассмотрим способ ограничения трафика с наименьшим приоритетом.

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

Приоритеты применяются только при заполнении канала.

Указание приоритета не имеет значения, если не достигнуто общее ограничение на количество трафика, указанное для канала. Это происходит потому, что пока не достигнуто заполнение канала, между приоритетами нет конкуренции.

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

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

Проблема может возникнуть в случае, если трафик, которому присвоен достаточно высокий приоритет, представляет собой непрерывный поток данных, например, аудио в режиме реального времени, что приводит к непрерывному использованию всей доступной полосы пропускания и длительному времени ожидания в очереди других сервисов, таких как http-трафик, dns-трафик или ftp-трафик. Для решения этой проблемы требуется возможность выделения некоторой части полосы пропускания для менее приоритетного трафика. Для этого используется гарантирование полосы пропускания (Bandwidth Guarantees).

Использование групп в канале

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

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

IP-адрес источника
IP-адрес назначения
Сеть источника
Сеть назначения
Порт и IP-адрес источника
Порт и IP-адрес назначения
Интерфейс источника
Интерфейс назначения

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

увеличить изображение

Рис. 5.23. Использование групп в канале

Если создание группы основано на номере порта, то при этом используется также и IP-адрес. Это означает, что порт 1024 компьютера А отличается от порта 1024 компьютера Б. В данном случае отдельный участник в группе идентифицируется по номеру порта и IP-адресу.

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

увеличить изображение

Рис. 5.24. Задание маски подсети для группы, основанной на сети

Указание ограничений для группы

После выбора способа создания группы необходимо указать Ограничения на группу (Group Limits). Данные ограничения могут состоять из одного или двух значений:

Суммарное ограничение трафика для всей группы
Данное значение указывает ограничение для каждого пользователя в созданной группе. Например, если создание группы выполняется по IP-адресу источника, и общее ограничение – 100 кбит/с, то это означает, что трафик с одного IP-адрес не сможет получить более 100 Кбит/с полосы пропускания.

увеличить изображение

Рис. 5.25. Ограничение трафика для группы
Гарантия полосы пропускания для трафика группы, имеющего определенный приоритет
В дополнение ограничению трафика на уровне группы можно задать гарантии полосы пропускания трафика, имеющего определенный приоритет. Например, если для приоритета 3 указано значение 50 кбит/с, то каждому отдельному участнику (другими словами, каждому IP-адресу источника, если выбрано создание группы именно по этому признаку) с этим приоритетом будет гарантировано 50 кбит/с за счет урезания трафика с более низким приоритетом.

увеличить изображение

Рис. 5.26. Гарантирование полосы пропускания для группы

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

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

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

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

Одновременное использование ограничений для каналов и групп

Предположим, что опция создания группы включена с помощью выбора одного из параметров создания группы, например, IP-адреса источника, и некоторые значения приоритетов указаны на вкладке Group Limits. Рассмотрим, как эти значения сочетаются со значениями, указанными для соответствующих приоритетов на вкладке Pipe Limits.

В данном случае значение приоритета на вкладке Group Limits является гарантией полосы пропускания, а значение для того же приоритета на вкладке Pipe Limits является ограничением количества трафика. Например, если трафик группируется по IP-адресу источника, и на вкладке Group Limits для приоритета 5 задано значение 5 Кбит/с, а на вкладке Pipe Limits приоритету 5 присвоено значение 20 Кбит/с, то после появления трафика с четвертого IP-адреса источника будет достигнуто ограничение количества трафика для данного приоритета (4 х 5 = 20 Кбит/с), в результате после этого гарантии полосы пропускания не смогут предоставляться.

Динамическая балансировка

Вместо указания ограничения в Group Limits можно включить опцию Dynamic Balancing. Это обеспечит одинаковое разделение полосы пропускания между всеми участниками независимо от их количества. Это будет означать ограничение для канала.

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

увеличить изображение

Рис. 5.27. Использование динамической балансировки для группы

Приоритеты и динамическая балансировка

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

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

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

Общие принципы использования шейпинга трафика

Важно указывать общее ограничение пропускной способности канала

Реальное ограничение трафика выполняется только в том случае, когда канал заполнен. Канал считается заполненным, если через него проходит трафик, количество которого равно значению, указанному в общем ограничении пропускной способности канала. Если для канала установлено общее ограничение пропускной способности в 500 кбит/с, но в текущей момент времени по нему проходит 400 кбит/с трафика с низким приоритетом и 90 кбит/с высокоприоритетного трафика, то остается 10 кбит/с полосы пропускания, поэтому нет необходимости урезать какой-либо из типов трафика. Поэтому важно указать общее ограничение для канала, чтобы механизму шейпинга была известна пропускная способность, и значения, указанные для приоритетов, учитывались.

Ограничения каналов для VPN

При выполнении шейпинга измеряется количество трафика внутри VPN-туннелей. Измеряется количество незашифрованных данных без дополнительных данных, добавляемых тем или иным протоколом VPN. Таким образом, измеряемый трафик будет меньше по объему, чем фактический VPN-трафик. VPN-протоколы, например IPSec, могут добавлять значительный объем к исходным данным, и по этой причине рекомендуется установить ограничение для каналов для VPN-трафика примерно на 20% меньше реальной полосы пропускания.

Использование ограничения на группу

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

Значения ограничений пропускной способности не должны превышать значения реальной полосы пропускания

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

Значения ограничений должны быть немного меньше значения реальной полосы пропускания

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

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

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

Атаки на полосу пропускания

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

Контроль, что весь трафик обрабатывается системой шейпинга

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

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

Краткая информация по шейпингу трафика

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

Необходимо указать обрабатываемый трафик, используя правила канала (Pipe Rules).
Правила канала направляют трафик в каналы (Pipes).
Для канала можно задать ограничение, определяющее максимальное количество трафика, которое может быть передано по каналу.
Канал может определить, что он заполнен, только если указано ограничение трафика в канале.
Один канал должен обрабатывать трафик только в одном направлении (хотя допустимы двунаправленные каналы).
Каналы могут быть объединены в цепочки. В этом случае трафик из одного канала попадает в другой.
Определенные типы трафика в канале могут иметь определенный приоритет.
Для приоритета может быть указано значение, которое является гарантией полосы пропускания. Трафик, превысивший это значение, будет иметь минимальный приоритет, который также называется приоритетом негарантированной доставки (Best Effort).
Все пакеты с приоритетом негарантированной доставки обрабатываются в порядке живой очереди.
В пределах канала трафик может быть разделен на группы (Group) по различным параметрам, например, по IP-адресу источника. Каждый участник в группе (т.е. в нашем случае каждый IP-адрес источника) имеет ограничение максимального значения полосы пропускания и приоритет, которые назначены группе.
Нет необходимости задавать ограничение канала, если указано ограничение для группы.
Динамическая балансировка может использоваться для указания того, что все участники в группе получают одинаковое количество полосы пропускания.

5.2.2 Шейпинг трафика с использованием IDP

Обзор

Шейпинг трафика на основе IDP дает возможность управлять трафиком, основываясь на информации, поступающей от подсистемы обнаружения и предотвращения вторжений (Intrusion Detection and Prevention, IDP).

Типичное применение – ограничения трафика приложения, активно использующего всю полосу пропускания

Основной задачей шейпинга на основе IDP является ограничения трафика, создаваемого ресурсоемкими приложениями. Типичным примером является трафик, генерируемый приложениями, работающими по протоколам peer-to-peer (P2P), например, такими как Bit Torrent и Direct Connect.

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

Совместное использование IDP и шейпинга трафика

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

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

Настройка шейпинга трафика с использованием IDP

Для конфигурирования шейпинга трафика с использованием IDP следует выполнить следующие шаги:

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

увеличить изображение

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

увеличить изображение

Рис. 5.29. Определение параметров шейпинга трафика на основе IDP
Можно также дополнительно определить временной интервал.
Это значение задает период времени (в секундах) после срабатывания правила, в течение которого шейпинг трафика применяется ко всем открытым взаимосвязанным соединениям.
Как правило, передача данных по P2P-протоколу начинается с установления начального соединения для передачи контрольной информации, за которым следует установление нескольких соединений, по которым передаются данные на другие хосты.
Именно это начальное соединение определяется IDP, а временной интервал определяет предположительный период, в течение которого будут открыты другие соединения, для которых необходимо выполнить шейпинг. Соединения, открытые после истечения временного интервала, не будут подвергаться шейпингу.
Временной интервал равный 0 означает, что под шейпинг попадает только трафик, проходящий через начальное соединение, вызвавшее срабатывание правила. Любые другие зависимые соединения, которые не вызывают срабатывания IDP-правила не будут подвергаться шейпингу.
Дополнительно можно указать сеть.
Если временной интервал больше 0, можно задать искомую сеть. Этот диапазон IP-адресов позволяет более точно определить последующие соединения, связанные с IDP-правилом, которые следует подвергнуть шейпингу. Для того чтобы выполнялся шейпинг данного трафика, хотя бы одна из сторон последующих соединений должна находиться в заданном диапазоне IP-адресов.

Обработка трафика

Рассмотрим последовательность обработки трафика с использованием IDP:

Открывается новое соединение между двумя хостами через межсетевой экран и начинается прохождение трафика. IP-адреса источника и назначения известны межсетевому экрану.
Параметры трафика соответствуют IDP-правилу. В качестве действия в IDP-правиле указано Pipe. В результате этого трафик данного соединения теперь является объектом шейпинга. Полоса пропускания канала задана в IDP-правиле.
Далее устанавливается новое соединение, которое не соответствует IDP-правилу, но у которого тот же IP-адрес источника или назначения, что и у соединения, соответствовавшего правилу. Если адрес источника или назначения принадлежат диапазону IP-адресов, указанному в поле Network, то трафик направляется в канал, в котором выполняется шейпинг, указанный в правиле шейпинга, начального соединения, соответствовавшего правилу.
Если значение Network не указано, то данное новое соединение будет также направлено в канал, определенный для трафика, для которого сработало правило, если адреса источника и назначения совпадают с адресами соединения, которое соответствовало правилу.

Важность указания сети в правиле шейпинга при использовании IDP

Соответствовать IDP-правилу может любая из сторон соединения

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

Причина возникновения непредсказуемых результатов

Рассмотрим ситуацию, когда клиент подключается к хосту по P2P-протоколу, и данный трафик соответствует IDР-правилу, в котором в качестве действия указано Pipe. В результате этого данное соединение становится объектом для шейпинга. Если другой клиент также подключается к тому же хосту, но, например, по HTTP-протоколу, то IDP-правило не срабатывает, и соединение не должно быть подвергнуто шейпингу наряду с соединением к тому же хосту по Р2Р-протоколу. Но в этом случае второе соединение также будет подвергнуто шейпингу, если хост, к которому происходит подключение как по Р2Р-протоколу, так и по НТТР-протоколу, входит в сеть, указанную в правиле.

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

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

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

5.2.3 Гарантирование полосы пропускания вместо ограничения трафика

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

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

5.2.4 Правила порога

Обзор

Основной целью применения Правил порога является обнаружение ненормальной сетевой активности и определение реакции на нее. Примером такой ненормальной сетевой активности может быть внутренний хост, зараженный вирусом, который постоянно создает соединения с внешними IP-адресами. Другим примером может являться внешний источник, пытающийся установить ненормально большое число соединений. (Термин "соединение" в данном случае относится ко всем типам соединений, включая TCP, UDP или ICMP, отслеживаемых механизмом состояний NetDefendOS).

Политики порога

Правило порога подобно другим правилам представляет собой комбинацию сеть/интерфейс источника/назначения и, возможно, типа сервиса, например, HTTP. Для каждого правила может быть определено одно или несколько Действий (Actions), которые определяют методы обработки различных условий порога.

Для Правила порога могут быть заданы следующие параметры:

Action (Действие)
Это ответ на превышение ограничения. Можно выбрать либо опцию Audit, либо Protect.

увеличить изображение

Рис. 5.30. Действия для правил порога
Group by (Группировать по)
Правило может быть задано либо для Host, либо для Network.

увеличить изображение

Рис. 5.31. Задание способа группирования
Threshold (Порог)
Числовое ограничение, при превышении которого выполняется указанное действие.

увеличить изображение

Рис. 5.32. Задание порогового значения
Threshold Type (Тип порога)
Правило может быть задано либо в виде ограничения количества соединений в секунду, либо в виде ограничения общего количества одновременных соединений.

Ограничение скорости соединения/общего количества соединений

Ограничение скорости соединения

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

Ограничение общего количества соединений

Ограничение общего количества соединений позволяет ограничить общее количество соединений.

Это особенно полезно, если требуются пулы NAT из-за большого количества соединений, установленных P2P-пользователями,

Способы группирования

Существует два способа группирования:

Host Based – Значение порога проверяется для соединения, установленного с отдельного IP-адреса.
Network Based – Значение порога проверяется для всех соединений, соответствующих правилу.

Действия правила

При срабатывании Правила порога возможен один из следующих ответов:

Audit – Не изменяет параметры соединения, но регистрирует событие.
Protect – Сбрасывает установленное соединение.

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

Одновременное выполнение нескольких действий

При срабатывании правила выполняются Actions, связанные с правилом, которые соответствуют возникшему условию. Если в правиле определено более одного Actions, то они выполняются в указанном в конфигурации порядке.

Если несколько Actions с одними и теми же Type и Grouping срабатывают одновременно, будет зарегистрировано будет только Action с более высоким значением порога.

Соединения, для которых не выполняется проверка

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

"Черный список" в Правилах Порога

Если указано действие Protect, Правила Порога могут быть сконфигурированы таким образом, чтобы источник, вызвавший срабатывание правила, автоматически добавлялся в "Черный список" IP-адресов или сетей. Если одновременно сработало несколько действий Protect с включенной функцией "черного списка", в этот список попадут только IP-адрес или сеть, указанные в первом действии.

увеличить изображение

Рис. 5.33. Задание параметров создания «черного списка»

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

После включения функции "черный список" уже существующие соединения с этим источником могут быть либо продолжены, либо сброшены в зависимости от установленного флага Do not drop existing connection.

Кроме этого можно установить время (в секундах), на которое данный источник будет помещен в "черный список".

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

Цель

Использовать два выхода в интернет: один канал использовать для доступа в интернет из локальной сети, в другой для доступа из DMZ-сети.

Топология сети

увеличить изображение

Рис. 10.1.

Следует использовать статическую маршрутизацию на основе правил (Policy-BasedRouting – PBR) для создания сети с двумя выходами в интернет.

Описание практической работы

Создать статическую маршрутизацию и политики доступа, которые обеспечивают доступ в интернет компьютеров из локальной сети LAN через канал, подключенный к wan1-интерфейсу маршрутизатора и доступ в интернет из DMZ-сети через канал, подключенный к wan2-интерфейсу маршрутизатора. Для этого следует использовать статическую маршрутизацию на основе правил.

Маршрутизация на основе адреса источника

Объекты Адресной Книги

В Адресной Книге создать объекты, описывающие альтернативные шлюзы интернет-провайдеров.

увеличить изображение

Рис. 10.2.

Альтернативная таблица маршрутизации

Создать альтернативную таблицу маршрутизации.

Веб-интерфейс:

Routing -> Routing Tables -> Add -> Routing Table

Name altInet

Ordering: Only

увеличить изображение

Рис. 10.3.

Командная строка:

add RoutingTable altInet Ordering=Only

В созданной таблице создать маршрут по умолчанию к ISP2 через интерфейс wan2.

Веб-интерфейс:

Routing -> Routing Tables -> altInet -> Add

увеличить изображение

Рис. 10.4.

Командная строка:

cc RoutingTable altInet

add Route Interface=wan2 Network=all-nets Gateway=altInet/gwISP2 Metric=100

В таблице маршрутизации main проверить наличие маршрутов по умолчанию к ISP2 через интерфейс wan2, а также остальных необходимых маршрутов.

Веб-интерфейс:

Routing -> Routing Tables -> main -> Add

увеличить изображение

Рис. 10.5.

Правило выбора таблицы маршрутизации PBR

Веб-интерфейс:

Routing -> Routing Rules -> Add -> Routing Rule

увеличить изображение

Рис. 10.6.

Командная строка:

add RoutingRule ForwardRoutingTable=altDMZ ReturnRoutingTable=altDMZ SourceInterface=dmz SourceNetwork= dmz/dmz_net DestinationInterface=any DestinationNetwork=all-nets Service=all_services Name=altDMZ

Правила фильтрования

Веб-интерфейс:

Rules -> IP Rules -> Add -> IP Rule Folder

Name toInet

Rules -> IP Rules -> toInet -> Add -> IP Rule

увеличить изображение

Рис. 10.7.

Командная строка:

add IPRuleFolder Name=toInet

cc IPRuleFolder <N folder>

add IPRule Action=NAT SourceInterface=lan SourceNetwork= lan/lan_net DestinationInterface=wan1 DestinationNetwork=all-nets Service=all_services Name=inet

add IPRule Action=NAT SourceInterface=dmz SourceNetwork=dmz/dmz_net DestinationInterface=wan2 DestinationNetwork=all-nets Service=all_services Name=inet_2

Проверка конфигурации

Выполняем выход в интернет с интерфейса lan и проверяем, что соединение установлено через интерфейс wan1.

увеличить изображение

Рис. 10.8.
Выполняем выход в интернет с интерфейса dmz и проверяем, что соединение установлено через интерфейс wan1.

увеличить изображение

Рис. 10.9.

Маршрутизация на основе сервиса

Альтернативная таблица маршрутизации

Альтернативная таблица маршрутизации создается аналогично маршрутизации на основе адреса источника.

Правило выбора таблицы маршрутизации PBR

Веб-интерфейс:

Routing -> Routing Rules -> Add -> Routing Rule

увеличить изображение

Рис. 10.10.

Командная строка:

add RoutingRule ForwardRoutingTable=altInet ReturnRoutingTable=altInet SourceInterface=dmz SourceNetwork=dmz/dmz_net DestinationInterface=any DestinationNetwork=all-nets Service=ssh Name=altDMZ

Правила фильтрования

Веб-интерфейс:

Rules -> IP Rules ->Add-> IP Rule Folder

Name toInet

Rules -> IP Rules -> toInet ->Add-> IP Rule

увеличить изображение

Рис. 10.11.

Командная строка:

add IPRule FolderName=toInet

cc IPRuleFolder <N folder>

add IPRule Action=NAT SourceInterface=lan SourceNetwork= lan/lan_net DestinationInterface=wan1 DestinationNetwork=all-nets Service=all_services Name=inet

add IPRule Action=NAT SourceInterface=dmz SourceNetwork= dmz/dmz_net DestinationInterface=wan2 DestinationNetwork=all-nets Service=ssh Name=inet_ssh

add IPRule Action=NAT SourceInterface=dmz SourceNetwork= dmz/dmz_net DestinationInterface=wan1 DestinationNetwork=all-nets Service=all_services Name=inet_2

Проверка конфигурации

Выполняем выход в интернет по протоколу ssh с dmz-интерфейса.

увеличить изображение

Рис. 10.12.
Выполняем выход в интернет по протоколу ICMP с dmz-интерфейса.

увеличить изображение

Рис. 10.13.

Лекция 22. Ограничение полосы пропускания трафика

Цель

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

Ограничить полосу пропускания для входящего трафика до 2 Мбит/с независимо от типа трафика.
Ограничить полосу пропускания в обоих направлениях до 2 Мбит/с независимо от типа трафика.

Топология сети

увеличить изображение

Рис. 11.1.

Описание практической работы

Ограничение полосы пропускания для входящего трафика

Каналы (Pipes)

Необходимо создать канал, который ограничивает весь проходящий через него трафик до 2 Мбит/с, не зависимо от типа трафика.

Веб-интерфейс:

Traffic Management -> Traffic Shaping -> Pipes -> Add -> Pipe

увеличить изображение

Рис. 11.2.

увеличить изображение

Рис. 11.3.

Командная строка:

add Pipe total_in LimitKbpsTotal=2000

Правила каналов (Pipe Rules)

Какой трафик должен проходить через канал указывается в Правиле канала.

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

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

Веб-интерфейс:

Traffic Management -> Traffic Shaping -> Pipe Rules -> Add -> Pipe Rule

увеличить изображение

Рис. 11.4.

увеличить изображение

Рис. 11.5.

Командная строка:

add PipeRule SourceInterface=lan SourceNetwork=lan/lan_net DestinationInterface=wan1 DestinationNetwork=all-nets Service=all_services ReturnChain=total_in Name=Inbound

Ограничение полосы пропускания в обоих направлениях

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

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

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

Помещение std-in в прямую цепочку (forward chain) не принесет результата, если требуется получить ограничение до 2 Мбит/с для исходящего трафика отдельно от ограничения до 2 Мбит/с для входящего. Если помимо исходящего трафика (2 Мбит/с) через канал проходит входящий трафик (2 Мбит/с), то общий поток трафика составит 4 Мбит/с. Так как ограничение канала составляет 2 Мбит/с фактическая величина потока будет близка к значению в 1 Мбит/с в каждом направлении.

Увеличение общего ограничения до 4 Мбит/с не решит проблему, так как для одного канала это не означает ограничения 2 Мбит/с для входящего и 2 Мбит/с для исходящего трафика. В результате может быть 3 Мбит/с исходящего и 1 Мбит/с входящего трафика, так как это также составляет 4 Мбит/с.

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

Каналы (Pipes)

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

Веб-интерфейс:

Traffic Management -> Traffic Shaping -> Pipes -> Add -> Pipe

увеличить изображение

Рис. 11.6.

увеличить изображение

Рис. 11.7.

Командная строка:

add Pipe total_out LimitKbpsTotal=2000

Правила каналов (Pipe Rules)

Traffic Management -> Traffic Shaping -> Pipe Rules -> Add -> Pipe Rule

увеличить изображение

Рис. 11.8.

увеличить изображение

Рис. 11.9.

Командная строка:

add PipeRule SourceInterface=lan SourceNetwork=lan/lan_net DestinationInterface=wan1 DestinationNetwork=all-nets Service=all_services ReturnChain=total_in ForwardChain=total_out Name=in_out

Ограничение полосы пропускания в зависимости от типа трафика

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

Каналы (Pipes)

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

Если создать два канала, один http-in для ограничения входящего веб-трафика с ограничением в 125 кбит/с, а другой канал all-in для всего остального трафика с ограничением в 250 кбит/с, то желаемый результат достигнут не будет, так как результирующий объем трафика будет равен сумме ограничений в каждом канале, т.е. 375 кбит/с.

Для решения подобной задачи следует создать цепочку, состоящую из канала all-in и канала http-in для веб-трафика. Входящий веб-трафик сначала проходит через канал http-in, максимальное ограничение в котором 125 кбит/с. Далее трафик проходит через канал all-in вместе с остальным входящим трафиком. Для второго канала установлено ограничение в 250 кбит/с.

Если веб-трафик полностью потребляет 125 кбит/с, эти 125 кбит/с займут половину канала http-in, оставшиеся 125 кбит/с будет использоваться для остального трафика. Если веб-трафик отсутствует, то все 250 кбит/с, отведенные для канала http-in, могут использоваться для другого трафика.

Это не обеспечивает гарантируемую полосу пропускания для веб-трафика, но устанавливает ограничение для него до 125 кбит/с и гарантирует полосу пропускания 125 кбит/с для всего остального трафика. Для веб-трафика в канале http-in применяются стандартные правила: трафик будет проходить на общих основаниях наравне с другим трафиком. Это означает ограничение в 125 кбит/с, при этом возможна более низкая скорость, если канал загружен.

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

Веб-интерфейс:

Traffic Management -> Traffic Shaping -> Pipes -> Add -> Pipe

увеличить изображение

Рис. 11.10.

Командная строка:

add Pipe http_in LimitKbpsTotal=125

add Pipe all_in LimitKbpsTotal=250

Правила каналов (Pipe Rules)

Traffic Management -> Traffic Shaping -> Pipe Rules -> Add -> Pipe Rule

увеличить изображение

Рис. 11.11.

увеличить изображение

Рис. 11.12.

увеличить изображение

Рис. 11.13.

увеличить изображение

Рис. 11.14.

увеличить изображение

Рис. 11.15.

Командная строка:

add PipeRule SourceInterface=lan SourceNetwork=lan/lan_net DestinationInterface=wan1 DestinationNetwork=all-nets Service=http-all ReturnChain=http_in,all_in Name=http_shaping

add PipeRule SourceInterface=lan SourceNetwork=lan/lan_net DestinationInterface=wan1 DestinationNetwork=all-nets Service=all_services ReturnChain=all_in Name=all_shaping

Использование приоритетов

Каналы (Pipes)

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

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

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

Если исходящий трафик с приоритетом 2 превышает 100 кбит/с, то приоритет той части трафика, которая превышает данное ограничение, понижается до приоритета негарантированной доставки (best effort). Весь трафик с приоритетом негарантированной доставки (best effort) будет отправлен в порядке поступления.

Веб-интерфейс:

Traffic Management -> Traffic Shaping -> Pipes -> Add -> Pipe

увеличить изображение

Рис. 11.16.

увеличить изображение

Рис. 11.17.

Командная строка:

add Pipe ssh_in LimitKbpsTotal=250 LimitKbps2=100

Правила каналов (Pipe Rules)

Веб-интерфейс:

Traffic Management -> Traffic Shaping -> Pipe Rules -> Add -> Pipe Rule

увеличить изображение

Рис. 11.18.

увеличить изображение

Рис. 11.19.

увеличить изображение

Рис. 11.20.

Командная строка:

add PipeRule SourceInterface=lan SourceNetwork=lan/lan_net DestinationInterface=wan1 DestinationNetwork=all-nets Service=ssh ReturnChain=ssh_in Name=ssh_shaping

Различные гарантий полосы пропускания для разных сервисов

Каналы (Pipes)

Иногда требуется предоставить различные гарантии полосы пропускания разным сервисам, например, гарантию в 32 кбит/с НТТР-трафику и гарантию в 64 кбит/с SSH-трафику. Можно было бы задать ограничение в 32 кбит/с для приоритета 2, 64 кбит/с для приоритета 4 и затем указать различным типам трафика разные приоритеты. При таком подходе можно столкнуться с ограниченным количеством различных приоритетов

Решение этой проблемы заключается в создании двух каналов: один для НТТР-трафика и другой для SSH-трафика. Для обоих каналов следует указать приоритет 2 в качестве приоритета по умолчанию, и задать ограничения для приоритета 2 , соответственно, 32 и 64 кбит/с.

Веб-интерфейс:

Traffic Management -> Traffic Shaping -> Pipes -> Add -> Pipe

увеличить изображение

Рис. 11.21.

увеличить изображение

Рис. 11.22.

увеличить изображение

Рис. 11.23.

увеличить изображение

Рис. 11.24.

увеличить изображение

Рис. 11.25.

увеличить изображение

Рис. 11.26.

увеличить изображение

Рис. 11.27.

Командная строка:

add Pipe std_out LimitKbpsTotal=250

add Pipe std_in LimitKbpsTotal=250

add Pipe ssh_in PrecedenceDefault=2 LimitKbps2=64

add Pipe http_in PrecedenceDefault=2 LimitKbps2=32

Правила каналов (PipeRules)

Следует создать два правила для НТТР-трафика и SSН-трафика.

В качестве прямой цепочки для обоих правил следует указать только канал std-out.

В качестве обратной цепочки в правиле для SSH-трафика следует указать канал ssh-in, затем канал std-in. В качестве обратной цепочки в правиле для НТТР-трафика следует указать канал http-in, затем канал std-in.

В качестве значения приоритета в обоих правилах следует выбрать установить флаг Use defaults from first pipe. Для обоих каналов ssh-in и http-in приоритетом по умолчанию является приоритет 2.

Использование данного подхода является более рациональным решением, чем указание приоритета 2 в наборе правил, так как в этом случае можно легко изменить приоритет всего трафика, как SSH, так и НТТР, поменяв приоритет по умолчанию каналов ssh-in и http-in.

Можно не задавать общее ограничение для каналов ssh-in и http-in, так как общее ограничение будет указано в канале std-in, который является последним в каждой из цепочек.

Каналы ssh-in и http-in действуют в качестве фильтров приоритетов. Благодаря им через канал std-in будет проходить только зарезервированное количество трафика с приоритетом 2 (64 и 32 кбит/с соответственно). Остальная часть трафика SSH и HTTP, превысившего эти значения, пройдет через канал std-in с приоритетом 0, который является приоритетом негарантированной доставки для каналов std-in и ssh-in.

Порядок цепочек важен. Если указать канал std-in перед ssh-in и http-in, то трафик пройдет через канал std-in с наименьшим приоритетом и, следовательно, будет конкурировать за 250 кбит/с доступной полосы пропускания с остальным трафиком.

Веб-интерфейс:

Traffic Management -> Traffic Shaping -> Pipe Rules -> Add -> Pipe Rule

увеличить изображение

Рис. 11.28.

увеличить изображение

Рис. 11.29.

увеличить изображение

Рис. 11.30.

увеличить изображение

Рис. 11.31.

увеличить изображение

Рис. 11.32.

увеличить изображение

Рис. 11.33.

увеличить изображение

Рис. 11.34.

Командная строка:

add PipeRule SourceInterface=lan SourceNetwork=lan/lan_net DestinationInterface=wan1 DestinationNetwork=all-nets Service=http-all ForwardChain=std_out ReturnChain=http_in,std_in Name=http_shaping

add PipeRule SourceInterface=lan SourceNetwork=lan/lan_net DestinationInterface=wan1 DestinationNetwork=all-nets Service=ssh ForwardChain=std_out ReturnChain=ssh_in,std_in Name=ssh_shaping

add PipeRule SourceInterface=lan SourceNetwork=lan/lan_net DestinationInterface=wan1 DestinationNetwork=all-nets Service=all_services ForwardChain=std_out ReturnChain=std_in Name=all_shaping

Использование групп

Каналы (Pipes)

Рассмотрим другую ситуацию, в которой общее ограничение полосы пропускания канала составляет 400 кбит/с. Если необходимо разделить эту полосу пропускания среди нескольких IP-адресов назначения таким образом, чтобы на отдельный IP-адрес приходилось не более 100 кбит/с полосы пропускания, необходимо выполнить следующие шаги:

Задать обычным способом ограничение канала – 400 кбит/с.
Установить в канале опцию Grouping в значении Destination IP.
На вкладке Group Limits задать общее ограничение канала для группы – 100 кбит/с.

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

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

Предположим, что опция создания группы включена с помощью выбора одного из параметров, например, IP-адреса источника, и значения некоторых приоритетов указаны на вкладке Group Limits. Рассмотрим, как эти значения взаимосвязаны со значениями, указанными для этих же приоритетов на вкладке Pipe Limits.

В данном случае значение приоритета на вкладке Group Limits является гарантией полосы пропускания, а значение для того же приоритета на вкладке Pipe Limits является ограничением трафика. Например, если трафик группируется по IP-адресу источника, и на вкладке Group Limits для приоритета 5 задано значение 5 Кбит/с, а на вкладке Pipe Limits приоритету 5 присвоено значение 20 Кбит/с, то после подключения четвертого IP-адреса источника (4 х 5 = 20 Кбит/с) будет достигнуто ограничение приоритета, и далее гарантии полосы пропускания не будут обеспечиваться.

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

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

Веб-интерфейс:

Traffic Management -> Traffic Shaping -> Pipe Rules -> Add -> Pipe Rule

увеличить изображение

Рис. 11.35.

увеличить изображение

Рис. 11.36.

увеличить изображение

Рис. 11.37.

увеличить изображение

Рис. 11.38.

Командная строка:

add Pipe std_in LimitKbpsTotal=400 Grouping=DestinationIP UserLimitKbpsTotal=100

add Pipe std_out

Правила каналов (Pipe Rules)

Правило каналов достаточно простое. В данном случае достаточно одного правила.

Веб-интерфейс:

Traffic Management -> Traffic Shaping -> Pipe Rules -> Add -> Pipe Rule

увеличить изображение

Рис. 11.39.

увеличить изображение

Рис. 11.40.

увеличить изображение

Рис. 11.41.

Командная строка:

add PipeRule SourceInterface=lan SourceNetwork=lan/lan_net DestinationInterface=wan1 DestinationNetwork=all-nets Service=all_services ForwardChain=std_out ReturnChain=std_in Name=all_shaping

Лекция 23. Ограничение полосы пропускания P2P-трафика с использованием IDP

Цель

Цель

Рассмотреть возможность ограничения Р2Р-трафика, используя IDP для обнаружения Р2Р-трафика.

Топология сети

увеличить изображение

Рис. 12.1.

Описание практической работы

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

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

Определение правила IDP

Веб-интерфейс:

IDP / IPS -> IDP Rules -> Add -> IDP Rule

увеличить изображение

Рис. 12.2.

увеличить изображение

Рис. 12.3.

увеличить изображение

Рис. 12.4.

увеличить изображение

Рис. 12.5.

увеличить изображение

Рис. 12.6.

Командная строка:

add IDPRule SourceInterface=lan SourceNetwork=lan/lan_ws DestinationInterface=wan1 DestinationNetwork=all-nets Service=all_services Name=idpP2P

cc IDPRule 1

add IDPRuleAction Action=Pipe PipeLimit=5 PipeNetwork=lan/lan_ws PipeNewConnections=Yes PipeTimeWindow=100 Signatures=POLICY_P2P_*

Просмотр объектов шейпинга трафика

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

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

Каналы шейпинга трафика на основе IDP можно определить по автоматическому добавлению к имени префикса IDP.