Межсетевые экраны
Лапонина Ольга Робертовна

Содержание


Лекция 1. Основные принципы создания надежной и безопасной ИТ-инфраструктуры

1.1 Введение

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

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

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

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

Собственник определяет множество информационных ценностей (активов), которые должны быть защищены от различного рода атак. Атаки осуществляются агентами угроз (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-атака, при которой нарушитель посылает пакеты, инициирующие установление ТСР-соединения, но не посылает пакеты, завершающие установление этого соединения. В результате на сервере может произойти переполнение таблицы соединений, и серверу не удастся установить соединение с законными пользователями.

DoS-атака


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

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

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

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

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

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

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

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

Атака «man in the middle»


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

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

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

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

Создание ложного потока


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

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

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

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

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

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

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

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

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

Повторное использование означает пассивный захват данных с последующей их пересылкой целевой системе для получения несанкционированного доступа – это так называемая replay-атака. На самом деле 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. Основы администрирования межсетевого экрана

Цель

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

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

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

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

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

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

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-имена в командной строке:

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

  1. Создать текстовый файл, содержащим последовательность команд, по одной команде в строке. Для этих файлов рекомендуется использовать расширение .sgs (Security Gateway Script). Имя файла, включая расширение, не должно содержать более 16 символов.
  2. Загрузить файл на межсетевой экран, используя Secure Copy (SCP). Файлы-сценарии должны храниться в папке scripts.
  3. Использовать команду 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)

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

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

Большинство серверов времени поддерживают 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:

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

System -> DNS



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

Рис. 1.14. 

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

set DNSDNSServer1=wan1/wan1_dns1

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

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

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

Maintenance -> Reset



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

Рис. 1.15. 

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

reset -unit

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

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

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

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

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

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

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

sessionmanager

sessionmanager -list

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

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

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

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

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

    pcapdump –cleanup

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

    pcapdump –start lan

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

    pcapdump -write lan -filename=lan_int.cap

  4. Отображение перехваченных пакетов в консоли.

    pcapdump –show

  5. Останов перехвата пакетов, проходящих через интерфейс lan. Если интерфейс не указан, то будет выполнен останов перехвата пакетов, проходящих через все интерфейсы.

    pcapdump –stop lan

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.6.1 Пароли

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

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

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

1.6.2 Токены

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. Соединение сетей за межсетевыми экранами

Цель

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

  1. Настроить сервисы DNS на обоих межсетевых экранах.
  2. Разрешить доступ из обеих локальных сетей в интернет.
  3. Разрешить доступ из локальных сетей к 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-сервера провайдера. Необходимо выполнить следующие настройки:

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

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

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

  1. Объекты интерфейса 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’

  2. Объекты интерфейса 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’

  3. Объекты интерфейса 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’

  4. Объекты интерфейса 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’

  5. Объекты, описывающие 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’

  6. Дополнительные объекты, необходимые для удобства администрирования и объединяющие в одну группу сети и 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-серверу в интернете. Это можно сделать несколькими способами:

  1. Создать правила 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

  2. Использовать созданные группы 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. 

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

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

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



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

Рис. 2.21. 

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

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



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

Рис. 2.22. 

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



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

Рис. 2.23. 

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

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

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

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

  1. Объекты интерфейса 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’

  2. Объекты интерфейса 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’

  3. Объекты интерфейса 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’

  4. Объекты, описывающие сети, расположенные за МЭ 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’

  5. Дополнительные объекты, необходимые для удобства администрирования и объединяющие в одну группу сети и 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. 

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



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

Рис. 2.30. 

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

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

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

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 обладают следующими характеристиками:

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

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

Добавление 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:

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

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

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


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

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

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

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

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

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


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

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

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

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


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

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

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

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


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

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

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


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

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

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

Создание 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.

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


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

Рис. 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 на основе портов:

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

Цель

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

Топология

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



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

Рис. 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. 

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

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

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

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

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

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

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

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

Управление трафиком осуществляется на основе анализа следующей информации, содержащейся в пакете:

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

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

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

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

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

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

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

Пример топологии сети с использованием пакетного фильтра и DMZ


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

Рис. 3.1.  Пример топологии сети с использованием пакетного фильтра и DMZ

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

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

Необходимость открывать порты с «большими» номерами на стороне клиента


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

Рис. 3.2.  Необходимость открывать порты с «большими» номерами на стороне клиента

Набор правил пакетного фильтра без анализа состояния


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

Рис. 3.3.  Набор правил пакетного фильтра без анализа состояния

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

Преимущества пакетных фильтров:

Недостатки пакетных фильтров:

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

Практически все современные межсетевые экраны включают большее количество возможностей, сейчас трудно найти межсетевой экран, который имеет возможности только пакетного фильтра. Примером может являться маршрутизатор, осуществляющий проверку списка контроля доступа для управления сетевым трафиком. Высокая производительность пакетных фильтров также способствует тому, что они реализуются в устройствах, обеспечивающих высокую доступность и особую надежность; некоторые производители предлагают аппаратные и программные решения как высоко доступные, так и особо надежные. Также большинство SOHO (Small Office Home Office) устройств межсетевых экранов и межсетевых экранов, встроенных по умолчанию в ОС, предоставляют возможности пакетных фильтров.

Пакетные фильтры с анализом состояния

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

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

В простейшем случае межсетевой экран пропускает любой пакет, если он считает, что пакет является частью открытого соединения (или соединения, которое еще не полностью установлено). Хотя многие межсетевые экраны точно могут определить состояние таких протоколов, как ТСР и UDP, и они могут блокировать пакеты, которые не соответствуют состоянию протокола. Например, часто межсетевой экран проверяет такие параметры, как последовательные номера ТСР, и отбрасывает пакеты, номера которых вне ожидаемого диапазона. Если межсетевой экран предоставляет сервис NAT, то информация NAT часто также содержится в таблице состояний.

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

Пример таблицы состояний пакетного фильтра с анализом состояний


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

Рис. 3.4.  Пример таблицы состояний пакетного фильтра с анализом состояний

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

Пример таблицы состояний для протокола UDP


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

Рис. 3.5.  Пример таблицы состояний для протокола UDP

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

Правила пакетного фильтра с анализом состояний


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

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

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

Недостатки межсетевых экранов с анализом состояния:

Лекция 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).

  1. Создаем сервис, в котором в качестве портов отправителя указаны все необходимые порты НТТР, а в качестве портов получателя указаны все непривилегированные порты (так называемые порты с "большими" номерами).

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

    Object -> Services -> Add



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

    Рис. 5.3. 

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

    add Service ServiceTCPUDP all_tcp_unpriv DestinationPorts=1024-65535 SourcePorts=80,8080,443

  2. Создаем два правила фильтрования с действием 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-интерфейсов.

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

  1. Используем браузер, в качестве адреса указываем IP-адрес.



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

    Рис. 5.5. 

  2. Проверяем, что таблица состояний для интерфейса dmz пустая.



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

    Рис. 5.6. 

Лекция 10. Прикладной уровень

Межсетевые экраны прикладного уровня

Современная тенденция анализа состояний состоит в добавлении возможностей анализа состояний протокола, которое некоторыми производителя называется глубоким анализом пакета (deep packet inspection). Анализ состояния протокола добавляет в стандартный анализ состояния базовую технологию обнаружения вторжения, которая анализирует протокол на прикладном уровне, сравнивая поведение протокола с определенными производителем профилями и определяя отклонения в поведении. Это позволяет межсетевому экрану разрешать или запрещать доступ, основываясь на том, как выполняется приложение. Например, межсетевой экран прикладного уровня может определить, что почтовое сообщение содержит неразрешенный тип присоединенного файла (такой как выполняемый файл). Другая возможность состоит в том, что он может блокировать соединения, в которых выполняются определенные действия (например, присутствуют команды put в FTP). Данная возможность также позволяет разрешать или запрещать передавать веб-страницы в зависимости от конкретных типов содержимого, такого как Java или ActiveX, или проверять, что SSL сертификаты подписаны конкретным СА.

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

Другая возможность состоит в проверке входных данных для отдельных команд, такой как минимальная и максимальная длина аргументов. Например, аргумент имени пользователя длиной в 1000 символов является подозрительным или если он содержит бинарные данные. Межсетевые экраны прикладного уровня доступны для многих протоколов, включая НТТР, БД (SQL), почтовые (SMTP, POP, IMAP), VoIP и XML.

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

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

Пример создания правил шлюза прикладного уровня (ALG)


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

Рис. 3.7.  Пример создания правил шлюза прикладного уровня (ALG)

Параметры правила шлюза прикладного уровня


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

Рис. 3.8.  Параметры правила шлюза прикладного уровня

Создание правила прикладного уровня


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

Рис. 3.9.  Создание правила прикладного уровня

Добавление проверок прикладного уровня в правило межсетевого экрана


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

Рис. 3.10.  Добавление проверок прикладного уровня в правило межсетевого экрана

Тестирование выполнения проверок прикладного уровня (запрет загрузки gif-файлов)


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

Рис. 3.11.  Тестирование выполнения проверок прикладного уровня (запрет загрузки gif-файлов)

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

Недостатки межсетевых экранов прикладного уровня:

Прокси-шлюзы прикладного уровня

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

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

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

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

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

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

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

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

Выделенные прокси-сервера

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

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

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

Пример топологии сети с выделенным прокси-сервером


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

Рис. 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-адресов следующие:

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

Пример конфигурирования параметров ICMP-протокола


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

Рис. 3.13.  Пример конфигурирования параметров ICMP-протокола

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

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

Политики, основанные на приложениях

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

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

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

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

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

Пример конфигурирования параметров НТТР-протокола


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

Рис. 3.14.  Пример конфигурирования параметров НТТР-протокола

Пример 2 конфигурирования параметров НТТР-протокола


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

Рис. 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 Основные рекомендации

Просуммируем основные рекомендации данного раздела:

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

Понятие сессии

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

Можно считать, что сессия – это совокупность трафика, который обрабатывается как единое целое. ТСР/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 должны разделять следующие характеристики.

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

NAT преобразует адреса в частной сети в адреса во внешней сети для обеспечения прозрачной маршрутизации дейтаграмм между разными адресными областями. В некоторых случаях преобразование может быть сделано и для идентификаторов транспортного уровня (такие как порты ТСР/UDP). Преобразование адреса выполняется при инициализации сессии. Может существовать два способа назначения адресов.

При статическом назначении адреса существует отображение один-к-одному между адресами частной сети и адресами внешней сети в течение всего времени функционирования NAT.

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

3.4.3 Варианты выполнения NAT

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

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

Правила МЭ с преобразованием NAT


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

Рис. 3.18.  Правила МЭ с преобразованием NAT

Использование IP-адреса интерфейса в качестве IP-адреса источника


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

Рис. 3.19.  Использование IP-адреса интерфейса в качестве IP-адреса источника

IP-адрес источника до преобразования NAT


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

Рис. 3.20.  IP-адрес источника до преобразования NAT

IP-адрес источника после преобразования NAT


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

Рис. 3.21.  IP-адрес источника после преобразования NAT

Использование выделенного IP-адреса в качестве IP-адреса источника

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

Использование выделенного IP-адреса в качестве адреса источника


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

Рис. 3.22.  Использование выделенного IP-адреса в качестве адреса источника

Опубликование этого IP-адреса на интерфейсе


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

Рис. 3.23.  Опубликование этого IP-адреса на интерфейсе

Проверка опубликования IP-адреса


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

Рис. 3.24.  Проверка опубликования IP-адреса

Трафик до преобразования NAT


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

Рис. 3.25.  Трафик до преобразования NAT

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

NAT-пулы типа Stateful

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

Определение диапазона IP-адресов


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

Рис. 3.27.  Определение диапазона IP-адресов

Создание NAT-пула с поддержкой состояния и созданным ранее диапазоном IP-адресов


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

Рис. 3.28.  Создание NAT-пула с поддержкой состояния и созданным ранее диапазоном IP-адресов

Использование механизма Proxy ARP для опубликования IP-адресов на указанном интерфейсе


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

Рис. 3.29.  Использование механизма Proxy ARP для опубликования IP-адресов на указанном интерфейсе

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

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

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

В каждом NAT-пуле есть только одна таблица соответствий, поэтому, если один NAT-пул несколько раз используется в разных IP-правилах NAT, то они будут совместно использовать одну и ту же таблицу состояний.

Указание NAT-пула в 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.

Правило SAT, обеспечивающее доступ к серверам, расположенным за преобразованием NAT


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

Рис. 3.31.  Правило SAT, обеспечивающее доступ к серверам, расположенным за преобразованием NAT

IP-адрес сервера, к которому требуется доступ извне


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

Рис. 3.32.  IP-адрес сервера, к которому требуется доступ извне

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

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

  1. На маршрутизаторе должен быть явно прописан маршрут к Хосту-A.
  2. Если указание такого маршрута вызывает проблемы, то может быть использовано туннелирование. Один из возможных подходов состоит в установке туннеля между Хостом-A и NAT-маршрутизатором, соединяющим две адресные области. Пакеты к Хосту-A и от Хоста-A могут быть туннелированы, но пакеты между NAT-маршрутизатором и удаленным получателем будет пересылаться в обычном виде. Заметим, что туннель от Хоста-A к пограничному маршрутизатору может и не требоваться. Как правило туннель бывает необходим, если межсетевой экран фильтрует пакеты, в которых адрес получателя принадлежит внешней сети.

В примере Хост-A имеет адрес Addr-k из внешней области, что означает возможность создания сессий от Addr-X к Addr-k. Если Addr-k не маршрутизируется внутри частной сети, то для прохождения пакетов внутри частной области можно создать туннель:

Туннелирование внутри частной сети:

Вариант совместного использования преобразования NAT и туннелирования


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

Рис. 3.34.  Вариант совместного использования преобразования NAT и туннелирования

Могут существовать и другие подходы.

Хост-A будет иметь следующие характеристики

  1. Хосту-A назначается адрес из внешней области для взаимодействия с хостами из этой области. Такой адрес может быть связан статически или получаться динамически (с помощью заранее определенного протокола) от узла, который может назначать адреса из внешней области. Маршрутизатору NAT назначен адрес внешней области.
  2. Выполняется маршрутизация пакетов к внешним хостам, используя маршрутизатор NAT в качестве шлюза. Хосту-A может потребоваться возможность функционирования в качестве конечной точки туннеля для инкапсуляции пакетов для их пересылки и выполнять обратную де-капсуляцию при получении.

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

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

Использование туннеля внутри частной области:

Вариант совместного использования преобразования NAРT и туннелирования


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

Рис. 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 заданы правила.

Правила на МЭ 1 для использования NAT и туннеля


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

Рис. 3.37.  Правила на МЭ 1 для использования NAT и туннеля

После этого весь трафик из LAN 1 будет иметь IP-адрес источника, определенный для локальной точки GRE-туннеля.

Определение параметров GRE-туннеля на МЭ 1


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

Рис. 3.38.  Определение параметров GRE-туннеля на МЭ 1

Правила маршрутизации на МЭ 1 следующие.

Правила маршрутизации на МЭ 1


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

Рис. 3.39.  Правила маршрутизации на МЭ 1

На МЭ 2 заданы аналогичные правила.

Правила на МЭ 2 для использования NAT и туннеля


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

Рис. 3.40.  Правила на МЭ 2 для использования NAT и туннеля

После этого весь трафик из LAN 2 будет иметь IP-адрес источника, определенный для противоположной точки GRE-туннеля.

Определение параметров GRE-туннеля на МЭ 2


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

Рис. 3.41.  Определение параметров GRE-туннеля на МЭ 2

Правила маршрутизации на МЭ 1 следующие.

Правила маршрутизации на МЭ 2


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

Рис. 3.42.  Правила маршрутизации на МЭ 2

Пример трафика с преобразованием NAT и туннелированием


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

Рис. 3.43.  Пример трафика с преобразованием NAT и туннелированием

3.4.5 Свойства NAT

При преобразовании NAT должны изменяться только заголовки IP/TCP/UDP/ICMP и ICMP-сообщения error.

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

  1. Если содержимое транспортного уровня содержит IP-адрес.
  2. Когда необходимо обеспечить безопасность до конечных точек.

Технологии безопасности прикладного уровня, которые не зависят от 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.

  1. UDP-сессии по своей сути небезопасны. Ответы на дейтаграммы могут прийти с адреса, отличного от адреса, используемого отправителем. Как результат, входящий UDP-пакет может соответствовать исходящей сессии традиционного маршрутизатора NAT только частично (адрес получателя и номер UDP порта пакета совпадают, а адрес и номер порта источника могут не совпадать). В этом случае существует потенциальная возможность компрометации безопасности в том, что разрешаются частично соответствующие входящие пакеты. Данная проблема безопасности UDP также присуща и межсетевым экранам. Традиционный NAT реализует это, не отслеживая дейтаграммы на уровне сессии, а связывая несколько UDP-сессий, использующих один и тот же адрес, что может привести к компрометации безопасности.
  2. Групповые (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. 

  1. На вкладке 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. 

  2. На вкладке 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. Это можно сделать несколькими способами.

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

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

    System -> Remote Management -> Advanced Settings



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

    Рис. 7.2. 

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

    set Settings RemoteMgmtSettings WWWSrv_HTTPPort=82 WWWSrv_HTTPSPort=444

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

Межсетевой экран с DMZ-сетью


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

Рис. 3.45.  Межсетевой экран с DMZ-сетью

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

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

3.5.1 Принципы построения окружения межсетевого экрана

  1. Простота (Keep It Simple). Данный принцип говорит о первом и основном, о чем надо помнить при разработки топологии сети, в которой функционирует межсетевой экран. Важно принимать наиболее простые решения – более безопасным является то, чем легче управлять. Трудно понимаемые функциональности часто приводят к ошибкам в конфигурации.
  2. Использовать устройства по назначению. Использование сетевых устройств для того, для чего они первоначально предназначались, в данном контексте означает, что не следует делать межсетевые экраны из оборудования, которое не предназначено для использования в качестве межсетевого экрана. Например, маршрутизаторы предназначены для выполнения маршрутизации; возможности фильтрования пакетов не являются их исходной целью, и это всегда надо учитывать при разработки окружения межсетевого экрана. Зависимость исключительно от возможности маршрутизатора обеспечивать функциональность межсетевого экрана опасна: он может быть легко переконфигурирован. Другим примером являются сетевые коммутаторы (switch): когда они используются для обеспечения функциональности межсетевого экрана вне окружения межсетевого экрана, они чувствительны к атакам, которые могут нарушить функционирование коммутатора. Во многих случаях гибридные межсетевые экраны и аппаратные устройства межсетевых экранов являются лучшим выбором, потому что они оптимизированы в первую очередь для функционирования в качестве межсетевых экранов.
  3. Создавать оборону вглубь. Оборона вглубь означает создание нескольких уровней защиты в противоположность наличию единственного уровня. Не следует всю защиту обеспечивать исключительно межсетевым экраном. Где может использоваться несколько межсетевых экранов, они должны использоваться. Где маршрутизаторы могут быть сконфигурированы для предоставления некоторого управления доступом или фильтрации, это следует сделать. Если ОС сервера может предоставить некоторые возможности межсетевого экрана, это следует применить.
  4. Уделять внимание внутренним угрозам. Наконец, если уделять внимание только внешним угрозам, то это приводит в тому, что сеть становится открытой для атак изнутри. Хотя это и маловероятно, но следует рассматривать возможность, что нарушитель может как-то обойти межсетевой экран и получить свободу действий для атак внутренних или внешних систем. Следовательно, важные системы, такие, как внутренние веб- или e-mail-серверы или финансовые системы, должны быть размещены позади внутренних межсетевых экранов или DMZ-зон.

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

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

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

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

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

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

3.5.3 DMZ-сети

Конфигурация с одной 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-атака.

Конфигурация Service Leg DMZ


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

Рис. 3.47.  Конфигурация Service Leg DMZ

Конфигурация с двумя DMZ-сетями

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

Пример окружения межсетевого экрана с двумя DMZ-сетями


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

Рис. 3.48.  Пример окружения межсетевого экрана с двумя DMZ-сетями

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

Основной межсетевой экран является VPN-шлюзом для удаленных пользователей; такие пользователи должны иметь ПО VPN-клиента для соединения с межсетевым экраном.

Входящий SMTP-трафик должен пропускаться основным межсетевым экраном.

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

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

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

3.5.4 Конечные точки VPN

Другой функциональностью, которой обычно обладают межсетевые экраны, является возможность функционирования в качестве конечной точки 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 Экстранет

VPN и экстранет, соединяющая две интранет


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

Рис. 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, интенсивность трафика и чувствительность обрабатываемых данных. Невозможны абсолютно универсальные рекомендации по расположению серверов, но основные принципы должны быть следующими.

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

Внешне доступные серверы

Внешне доступные НТТР-серверы, а также серверы каталога или 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 будут видимы в интернете.

Пример топологии сети с двумя DNS серверами


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

Рис. 3.51.  Пример топологии сети с двумя DNS серверами

3.6 Планирование и внедрение межсетевого экрана

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

  1. Планирование. На первом этапе необходимо определить все требования к межсетевому экрану, которые необходимо выполнить для реализации политики безопасности.
  2. Конфигурирование. Второй этап включает все аспекты конфигурирования платформы, на которой выполняется межсетевой экран. Это подразумевает установку аппаратуры и ПО, а также разработку правил.
  3. Тестирование. Следующий этап включает реализацию и тестирование прототипа в лабораторном или тестовом окружении. Исходная цель тестирования состоит в оценке функциональностей, производительности, масштабируемости и безопасности, а также в определении различных проблем, таких как интероперабельность, с различными компонентами другого ПО.
  4. Развертывание. После того, как тестирование завершено, и все проблемы решены, на следующем этапе следует развертывать межсетевой экран в реальных условиях.
  5. Управление. После того, как межсетевой экран развернут, необходимо управлять им в течение всего жизненного цикла его компонент и решать возникающие проблемы.

3.6.1 Планирование

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

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

Основные принципы, которым необходимо следовать при планировании развертывания межсетевого экрана:

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

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

Также при покупке и внедрении персональных межсетевых экранов и межсетевых экранов для хостов следует рассмотреть:

3.6.2 Конфигурирование

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

Установка аппаратуры и ПО

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

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

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

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

Конфигурирование политики

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

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

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

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

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

  1. Возможность иметь реакцию на атаку позволяет заставить атакующего нести ответственность за собственную деятельность. Это можно сформулировать следующим образом: "Я могу прореагировать на атаку, которая произведена на мою систему, так как я знаю, кто это сделал или где его найти". Это трудно реализовать в сетях TCP/IP, где протоколы позволяют атакующим подделать IP-адрес источника и другие идентификаторы источника. В принципе очень трудно определить источник в любой системе, которая имеет слабые механизмы идентификации и аутентификации.
  2. Возможность блокирования означает возможность распознать некоторую активность или событие как атаку и затем выполнить действие по блокированию источника. Данную цель можно сформулировать следующим образом: "Я не забочусь о том, кто атакует мою систему, потому что я могу распознать, что атака имеет место, и блокировать ее". Заметим, что требования реакции на атаку полностью отличаются от возможности блокирования.

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

    Объявления о появлении новых уязвимостей являются общедоступными, например, через публичные сервисы, такие, как ICAT (http://icat.nist.gov) или CERT (http://www.cert.org), которые созданы для того, чтобы эти уязвимости нельзя было использовать для выполнения атак. Тем не менее, существует много ситуаций, в которых использование известных уязвимостей все же возможно.

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

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

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

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

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

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

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

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

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

  7. IDPS помогает определить расположение источника атак по отношению к локальной сети (внешние или внутренние атаки), что важно при принятии решений о расположении ресурсов в локальной сети.

4.3 Способы классификации IDPS

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

  1. Способ мониторинга системы. По способам мониторинга системы делятся на network-based, host-based, беспроводные IDS, network behavior analysis (NBA) и application-based.
  2. Способ анализа. Данная классификация описывает способы, которыми IDPS определяет, что имело место проникновение. Способами определения проникновения являются обнаружение злоупотреблений или сигнатурный подход (misuse detection) и обнаружение аномалий (anomaly detection).
  3. Задержка во времени между получением информации из источника и ее анализом и принятием решения. В зависимости от задержки во времени, 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, как правило, состоят из следующих компонент:

4.3.2 Каналы связи и распределенность управления и принятия решения

Для успешного функционирования IDPS в сети должны быть созданы следующие каналы связи:

Рассмотрим возможные способы управления IDPS.

  1. Централизованное управление и принятие решения.

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

  2. Частично распределенное управление

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

  3. Полностью распределенное управление

    Мониторинг и определение атаки выполняются агентами, т.е. решение об ответе делается в точке определения атаки.

4.3.3 Скорость реакции

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

  1. Реакция через определенные интервалы времени(пакетный режим)

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

  2. Реакция в режиме реального времени (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 behavior analysis – NBA) состоит в сравнении заранее заданных профилей, которые описывают нормальную последовательность сообщений в протоколе, и реального трафика. В отличие от определения проникновения на основе аномалий, при котором используются профили, созданные для конкретного хоста или сети, анализ состояния протокола использует разработанные производителем универсальные профили, которые определяют последовательность сообщений и состояний конкретного протокола. "Stateful" в анализе состояния протокола означает, что IDPS понимает и отслеживает состояние сетевого, транспортного и прикладного протоколов, для которых существует понятие состояния. Важной составной частью анализа состояния является определение пар запросов и ответов. В результате создания таких пар IDPS может определить, была ли аутентификация успешной, найдя состояние статуса в соответствующем ответе. После того, как пользователь успешно аутентифицирован, сессия переходит в аутентифицированное состояние, и считается, что пользователь может выполнять команды протокола. Выполнение любой из этих команд в неаутентифицированном состоянии будет рассматриваться как возможная атака.

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

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

Преимущества NBA IDPS:

Недостатки NBA 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:

Application-based IDPS

Application-based IDPS является специальным подмножеством host-based IDPS, которые анализируют события, возникающие в приложении. Наиболее общими источниками информации, используемыми application-based IDPS, являются логи приложения.

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

Преимущества application-based IDPS:

Недостатки application-based IDPS:

Беспроводные (wireless) IDРS

Беспроводная IDPS просматривает трафик беспроводной сети и анализирует беспроводные сетевые протоколы для определения нежелательной деятельности. Они не могут определить нежелательную деятельность в приложении или протоколах более высокого уровня (например, ТСР, UDP). В большинстве случаев такие сети развернуты внутри организаций, но возможно также их развертывание в таких местах, где могут быть подключены неавторизованные беспроводные сети.

4.3.5 Анализ, выполняемый IDPS

Существует два основных подхода к анализу событий, которые свидетельствуют о наличии атак: определение злоупотреблений или сигнатурный подход (misuse detection) и определение аномалий (anomaly detection).

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

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

Сигнатурный подход

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

Преимущества сигнатурного метода:

Недостатки сигнатурного метода:

Определение аномалий

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

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

Только первые две технологии используются в современных коммерческих IDPS.

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

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

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

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

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

4.3.6 Возможные ответные действия IDPS

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

Активные действия

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

Сбор дополнительной информации

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

Изменение параметров окружения

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

Выполнение действия против атакующего

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

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

Рекомендуется проконсультироваться с законодательством перед тем, как использовать какие-либо опции "ответного удара".

Пассивные действия

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

  1. Настройка корректного системного времени и проверка наличия обновлений

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

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

    Maintenance -> Update Center



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

    Рис. 8.1. 

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

    updatecenter -status

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

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

  3. Сканирование потока

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

  4. Сопоставление с шаблоном

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

  5. Типы сканируемых загружаемых файлов

    Как описано выше, антивирусное сканирование запускается как часть ALG и может анализировать загружаемые файлы, передаваемые по протоколам HTTP, FTP, SMTP и POP3. В частности:

    • Может быть просканирован любой тип несжатого файла, с которым связан соответствующий ALG.
    • Если загружаемый файл сжат, то форматы ZIP и GZIP также могут быть просканированы.

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

  6. Одновременное выполнение нескольких сканирование

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

  7. Учет специфики конкретного протокола

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

  8. Взаимосвязь с IDP

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

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

  9. База данных сигнатур SafeStream

    Антивирусное сканирование выполняется системой NetDefendOS D-Link с использованием баз данных сигнатур вирусов SafeStream. База данных SafeStream создана и поддерживается лабораторией Касперского – компанией, которая является мировым лидером в области обнаружения вирусов. База данных обеспечивает защиту от всех известных вирусов, включая троянские программы, "червей", "backdoor" и другие.

  10. Обновление базы данных

    База данных SafeStream обновляется ежедневно, добавляя сигнатуры новых вирусов. Старые сигнатуры редко удаляются, вместо этого они заменяются более общими сигнатурами, которые охватывают несколько вирусов. Поэтому локальная копия NetDefendOS базы данных SafeStream должна регулярно обновляться, и этот сервис обновления является частью подписки на Антивирус D-Link.

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

Использование шлюза прикладного уровня (ALG) для активизация антивирусного сканирования

  1. Реакция на невозможность выполнения проверки на наличие вирусов

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

    • HTTP ALG
    • FTP ALG
    • POP3 ALG
    • SMTP ALG

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

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

    Object -> ALG with AV/WCF -> Add -> HTTP ALG



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

    Рис. 8.2. 

  2. Режим сканирования

    Режим сканирования может быть следующим:

    Disabled – Функция антивируса выключена.

    Audit – Сканирование активизировано, но единственным действием является ведение логов.

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

  3. Исключение из сканирования

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

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



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

    Рис. 8.3. 

  4. Ограничение степени сжатия

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

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

    Allow – Разрешить передачу файла без проверки на наличие вирусов

    Scan – Сканировать файл на наличие вирусов

    Drop – Отбросить файл

    В любом случае данное событие заносится в лог.



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

    Рис. 8.4. 

  5. Проверка файлов на соответствие типам 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’ов) – в этом случае система пытается осуществить реальную атаку. После этого возвращается результат, указывающий, была ли атака успешной.

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

Преимущества систем анализа уязвимостей

Недостатки и проблемы систем анализа уязвимостей

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

4.4.3 Проверка целостности файлов

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

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

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

4.5 Выбор IDPS

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

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

Выбор наиболее подходящейIDPS

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

4.5.1 Определение окружения IDPS

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

  1. Технические спецификации окружения систем

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

  2. Технические спецификации используемой системы безопасности

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

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

  3. Цели организации

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

  4. Возможность формализации окружения системы и принципы управления, используемые в организации

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

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

4.5.2 Цели использования IDPS

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

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

  1. Защита от внешних угроз

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

  2. Защита от внутренних угроз

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

  3. Необходимость обновления систем, за которыми ведется наблюдение

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

  4. Возможность использования IDPS для управления сетью

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

4.5.3 Существующая политика безопасности

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

  1. Структурированность

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

  2. Описание функций, выполняемых пользователями системы

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

  3. Реакция на нарушения политики безопасности

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

4.6 Требования организации к функционированию IDPS

4.6.1 Цели организации

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

  1. Внешние по отношению к IDPS требования

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

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

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

  3. Законодательные требования, относящиеся к безопасности и к расследованию инцидентов безопасности

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

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

  4. Требования внутреннего аудита

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

  5. Требования аккредитации системы

    Следует рассмотреть, какая аккредитация требуется для IDPS и других систем.

4.6.2 Требования к ресурсам, необходимым для функционирования IDPS

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

  1. Бюджет для приобретения и поддержки жизненного цикла аппаратуры, ПО и инфраструктуры IDPS

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

  2. Специалисты по эксплуатации IDPS

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

  3. Полномочия для осуществления изменений на основе результатов, предоставленных IDPS

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

4.7 Возможности IDPS

IDPS должна обеспечивать следующие возможности.

  1. Масштабируемость используемого программного продукта для конкретного окружения

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

  2. Протестированность программного продукта

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

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

4.7.1 Учет возможного роста организации

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

  1. Адаптируемость программного продукт к возрастающей квалификации пользователей

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

  2. Адаптируемость программного продукта к возрастанию и изменению инфраструктуры организации

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

  3. Адаптируемость программного продукта к возрастанию и изменению угроз безопасности

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

4.7.2 Предоставляемая поддержка программного продукта

Подобно другим программным продуктам, IDPS требуют постоянного сопровождения и поддержки.

  1. Поддержка инсталляции и конфигурирования

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

  2. Возможность непрерывной поддержки программного продукта

    • Существует ли подписка на обновления.

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

    • Как часто подписчики получают обновления.

      При современных угрозах, когда ежемесячно публикуется 30-40 новых атак, это является важным фактором.

    • Как быстро после обнаружения новой атаки производитель поставит новую сигнатуру.

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

    • Включает ли подписка на обновление также и обновление ПО.

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

    • Как быстро выпускаются обновления ПО после того, как о проблеме было сообщено производителю.

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

    • Включены ли сервисы технической поддержки и сколько они стоят.

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

    • Какой способ контакта (e-mail, телефон, системы мгновенных сообщений , веб-интерфейс) осуществляется для выполнения технической поддержки.

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

    • Какие имеются гарантии, связанные с IDPS.

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

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

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

  4. Дополнительные ресурсы, доступные для обучения

    В случае, если производитель 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, каждый из которых имеет свои преимущества:

Возможные варианты расположения сенсоров network-based IDPS


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

Рис. 4.1.  Возможные варианты расположения сенсоров network-based IDPS

Позади внешнего межсетевого экрана в DMZ-сети (расположение 1)

Преимущества:

Перед внешним межсетевым экраном (расположение 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 имеют много ограничений. Наиболее существенные следующие:

4.10 Выходные данные IDPS

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

Многие 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 выполняет шаги по нейтрализации как вторжения, так и его источника.

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

  1. Какой трафик следует анализировать.
  2. Что следует искать в анализируемом трафике.
  3. Какое действие необходимо предпринять при обнаружении вторжения.

Эта информация указывается в IDP-правилах.

Maintenance и Advanced IDP

Компания D-Link предоставляет два типа IDP:

  1. Maintenance IDP

    Maintenance IDP является основой системы IDP и включено в стандартную комплектацию NetDefendDFL-210, 800, 1600 и 2500.

    Maintenance IDP является упрощенной IDP, что обеспечивает базовую защиту от атак, и имеет возможность расширения до более комплексной Advanced IDP.

    IDP не входит в стандартную комплектацию DFL-260, 860, 1660, 2560 и 2560G; для этих моделей межсетевых экранов необходимо приобрести подписку на Advanced IDP.

  2. 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 является следующей:

  1. Пакет приходит на межсетевой экран. Если пакет является частью нового соединения, то первым делом ищется соответствующее IP-правило фильтрования. Если пакет является частью существующего соединения, он сразу же попадает в модуль IDP. Если пакет не является частью существующего соединения или отбрасывается IP-правилом, то дальнейшей обработки данного пакета не происходит.
  2. Адреса источника и назначения пакета сравниваются с набором правил 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 имеется три типа сигнатур, которые предоставляют различные уровни достоверности в определении угроз:

Предотвращение атак Denial-of-Service

Механизмы DoS-атак

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

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

Перечислим некоторые из наиболее часто используемых DoS-атак:

Атаки 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 обеспечивает защиту двумя способами:

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

Advanced Settings -> TCP -> TCPUrg



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

Рис. 9.1. 

Как правило, атаки WinNuke регистрируются в логах как отброшенные пакеты с указанием на правило, запретившего попытку соединения. Для разрешенных соединений появляется запись категории "TCP" или "DROP" (в зависимости от настройки TCP URG), с именем правила "TCP URG". IP-адрес отправителя может быть не поддельным, так как соединение должно быть полностью установлено к моменту отправки пакетов "out-of-band".

Атаки, приводящие к увеличению трафика: Smurf, Papasmurf, Fraggle

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

Атаки Smurf регистрируются в логах NetDefendOS как большое число отброшенных пакетов ICMP Echo Reply. Для подобной перегрузки сети может использоваться поддельный IP-адрес. Атаки Fraggle также отображаются в логах NetDefendOS как большое количество отброшенных пакетов. Для перегрузки сетb используется поддельный IP-адрес.

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

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

Advanced Settings -> IP -> DirectedBroadcasts

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

Защита на стороне компьютера-жертвы

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

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

Шейпинг трафика также помогает предотвращать некоторые 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. Может быть указано одно из трех действий:

  1. Ignore – Если обнаружено вторжение, не выполнять никаких действий и оставить соединение открытым.
  2. Audit – Оставить соединение открытым, но зарегистрировать событие.
  3. 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 в правиле. Существуют три параметра "черного списка":

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

Пример таблицы маршрутизации main


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

Рис. 5.2.  Пример таблицы маршрутизации main

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

  1. Осуществляется поиск правила в Routing Rules, соответствующего параметрам пакета: интерфейс и сеть источника/назначения и протокол/сервис. Если подходящее правило найдено, то для определения маршрута используется указанная таблица маршрутизации. Если подходящее правило не найдено, то используется таблица main.

    Выбор таблицы маршрутизации


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

    Рис. 5.3.  Выбор таблицы маршрутизации

    В нашем примере будет использоваться таблица altInet.

    После того, как выбрана необходимая таблица маршрутизации, выполняется проверка доступности IP-адреса источника с входящего интерфейса. Ищется соответствие с правилами доступа (Access Rules). Если нет ни одного правила доступа, или не найдено соответствие параметров пакета ни одному из правил доступа, то в выбранной таблице маршрутизации осуществляется поиск маршрута к IP-адресу источника. Если маршрут не найден, в журнал записывается сообщение об ошибке "Default access rule".

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

    Определение последовательности просмотра выбранной таблицы маршрутизации и таблицы main


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

    Рис. 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.  Пример альтернативной таблицы маршрутизации

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

    Правила фильтрования трафика, маршрутизируемого альтернативной таблицей


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

    Рис. 5.6.  Правила фильтрования трафика, маршрутизируемого альтернативной таблицей

  3. Если проверка IP-правилами фильтрования прошла успешно, то в таблице состояний системы открывается новое соединение, и пакет передается по этому соединению.

    Трафик из dmz-сети


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

    Рис. 5.7.  Трафик из dmz-сети

    Проверка, что соединение из dmz-сети установлено через интерфейс wan1


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

    Рис. 5.8.  Проверка, что соединение из dmz-сети установлено через интерфейс wan1

    Трафик из lan-сети будет идти через ISP 2, т.е. через интерфейс wan2.

    Трафик из lan-сети


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

    Рис. 5.9.  Трафик из lan-сети

    Проверка, что соединение из dmz-сети установлено через интерфейс wan1


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

    Рис. 5.10.  Проверка, что соединение из dmz-сети установлено через интерфейс wan1

5.2 Приоритезация трафика

Рассмотрим основные принципы приоритезации трафика и обеспечение качества обслуживания в системе NetDefendOS:

5.2.1 Ограничение (шейпинг) трафика

Гарантирование качества сервиса и TCP/IP

Недостатком TCP/IP является отсутствие возможности гарантировать определенное качество сервиса (Quality of Service – QoS). Под QoS понимается возможность гарантировать определенные сервисы и ограничить полосу пропускания как для определенных сервисов, так и для определенных пользователей. Для крупных сетей были разработаны такие решения, как архитектура дифференцированного обслуживания – Differentiated Services (Diffserv), которые используют информацию в заголовках пакетов.

Поддержка Diffserv в NetDefendOS

NetDefendOS поддерживает архитектуру Diffserv следующими способами:

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

Основные принципы шейпинга трафика

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

NetDefendOS обеспечивает QoS, позволяя администратору указывать приоритеты для сервисов и обеспечивать гарантии полосы пропускания. Этот подход называется шейпингом трафика (traffic shaping) и идеально подходит для управления полосой пропускания в локальной сети, а также для управления трафиком в "узких" местах, которые могут образоваться в крупных сетях. Шейпинг применяется к любому типу трафика, включая трафик, проходящий через VPN-туннели.

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

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

Шейпинг трафика в NetDefendOS

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

Существует два основных компонента, с помощью которых задается шейпинг трафика:

  1. Каналы (Pipes)
  2. Правила каналов (Pipe Rules)

Каналы (Pipes)

  1. Канал является объектом, с помощью которого задаются возможные приоритеты трафика, используемые для ограничения и/или гарантирования полосы пропускания для трафика. Трафик направляется в данный канал с помощью правил канала.
  2. Трафик может проходить через несколько каналов. Это определяется правилами каналов. Ограничение и/или гарантирование полосы пропускания может быть установлено как для первого канала, так и для последующих.
  3. Может быть включена функция динамической балансировки, которая позволяет равномерно распределить полосу пропускания между всеми участниками.

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

Задание пропускной способности канала


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

Рис. 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 не влияет на конечный результат.

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

Назначение приоритета для канала

При создании канала можно указать значения приоритета по умолчанию (Default Precedence), минимального приоритета (Minimum Precedence) и максимального приоритета (Maximum Precedence).

Приоритет по умолчанию – это приоритет, назначаемый пакету, в случае, если правилом канала трафику назначен приоритет первого канала.

Назначение приоритета для канала


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

Рис. 5.22.  Назначение приоритета для канала

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

Гарантирование полосы пропускания для канала

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

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

Наименьший приоритет имеет особое значение: он действует как Приоритет негарантированной доставки (Best Effort). Все пакеты с данным приоритетом обрабатываются в порядке поступления при наличии полосы пропускания.

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

Рассмотрим способ ограничения трафика с наименьшим приоритетом.

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

Приоритеты применяются только при заполнении канала.

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

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

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

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

Использование групп в канале

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

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

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

Использование групп в канале


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

Рис. 5.23.  Использование групп в канале

Если создание группы основано на номере порта, то при этом используется также и IP-адрес. Это означает, что порт 1024 компьютера А отличается от порта 1024 компьютера Б. В данном случае отдельный участник в группе идентифицируется по номеру порта и IP-адресу.

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

Задание маски подсети для группы, основанной на сети


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

Рис. 5.24.  Задание маски подсети для группы, основанной на сети

Указание ограничений для группы

После выбора способа создания группы необходимо указать Ограничения на группу (Group Limits). Данные ограничения могут состоять из одного или двух значений:

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

Контроль, что весь трафик обрабатывается системой шейпинга

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

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

Краткая информация по шейпингу трафика

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

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 следует выполнить следующие шаги:

  1. Указать IDP-правило, которое будет определять целевой трафик.

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

  2. В качестве действия для правила следует выбрать Pipe.

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

    Задание правил для шейпинга трафика на основе IDP


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

    Рис. 5.28.  Задание правил для шейпинга трафика на основе IDP

  3. Указать в правиле значение полосы пропускания.

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

    Соединения, открытые до срабатывания правила IDP, не будут подвержены ограничению.

    Определение параметров шейпинга трафика на основе IDP


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

    Рис. 5.29.  Определение параметров шейпинга трафика на основе IDP

  4. Можно также дополнительно определить временной интервал.

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

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

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

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

  5. Дополнительно можно указать сеть.

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

Обработка трафика

Рассмотрим последовательность обработки трафика с использованием IDP:

  1. Открывается новое соединение между двумя хостами через межсетевой экран и начинается прохождение трафика. IP-адреса источника и назначения известны межсетевому экрану.

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

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

Для Правила порога могут быть заданы следующие параметры:

Ограничение скорости соединения/общего количества соединений

Ограничение скорости соединения

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

Ограничение общего количества соединений

Ограничение общего количества соединений позволяет ограничить общее количество соединений.

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

Способы группирования

Существует два способа группирования:

Действия правила

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

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

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

  1. Выполняем выход в интернет с интерфейса lan и проверяем, что соединение установлено через интерфейс wan1.



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

    Рис. 10.8. 

  2. Выполняем выход в интернет с интерфейса 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

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

  1. Выполняем выход в интернет по протоколу ssh с dmz-интерфейса.



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

    Рис. 10.12. 

  2. Выполняем выход в интернет по протоколу ICMP с dmz-интерфейса.



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

    Рис. 10.13. 

Лекция 22. Ограничение полосы пропускания трафика

Цель

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

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

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

Определение правила 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_*

Просмотр объектов шейпинга трафика

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

Каналы шейпинга трафика на основе IDP можно определить по автоматическому добавлению к имени префикса IDP.

Дополнения


Литература