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

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

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

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

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

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

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

Сегментация

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

Фильтрация трафика на коммутаторах

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

Некоторые коммутаторы поддерживают функции фильтрации трафика на различных уровнях модели OSI. Например, коммутаторы Cisco Catalyst, начиная с модели 3550, имеют возможность привязывать к коммутируемым портам входящие списки контроля доступа, проверяющие пакеты на третьем и четвертом уровне модели OSI (протоколы IP/TCP/UDP).

Более мощные устройства, например модуль Firewall Services Module (FWSM), для устройств Cisco Catalyst 6500 Series позволяют задавать правила фильтрации трафика на всех уровнях модели OSI, включая прикладной. Основным недостатком фильтрации трафика на коммутаторах на данный момент является его стоимость. Однако со временем функции фильтрации трафика будут встраиваться и в недорогие устройства уровня рабочих групп.

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

Фильтрация трафика на сетевых мостах

В последнее время большой популярностью пользуются сетевые мосты, реализующие функции межсетевого экрана (bridge firewall). Фильтрующий сетевой мост принимает пакеты на один из сетевых интерфейсов, но кроме стандартной функции ретрансляции проверяет их при помощи пакетного фильтра. Самым популярным решением является фильтрующий сетевой мост на основе межсетевого экрана IPtables (http://bridge.sourceforge.net/docs/Firewalling%20for%20Free.pdf).

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

Персональные межсетевые экраны

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

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

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

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

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

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

Рисунок 1. Работа системы обнаружения атак в режиме фильтрации соединений

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

Для протоколов, работающих без установления соединения (UDP, ICMP), в качестве реакции на запрещенный пакет обоим участникам соединения отправляется пакет ICMP Destination Unreachable и ICMP Port Unreachable. Кроме того, информация об этих пакетах заносится в журнал NIDS.

Практическая реализация

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

Рисунок 2. Схема защищаемой сети

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

Политику можно составить исходя из функций, выполняемых серверами, либо воспользоваться методами, описанными в разделе «Разработка политик фильтрации» статьи «Неизвестный IPSec», опубликованной в Windows & .NET Magazine/RE № 6 за 2003 год. В качестве полезного инструмента на данном этапе можно задействовать сетевые анализаторы (sniffer), реализующие функцию восстановления сессий.

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

Самым простым способом является привязка служб RPC к фиксированным номерам портов. Для этого целесообразно было бы использовать расширение параметров безопасности групповой политики в Security Configuration Manager, однако редактор неверно обрабатывает добавление параметров системного реестра, содержащих символ «/». Альтернативным методом централизованной привязки служб RPC к статическим портам является использование расширения групповых политик при помощи административных шаблонов (файлы с расширением ADM). Пример подобного файла, который может использоваться для настройки служб сервера Exchange и котроллеров домена, приведен ниже.

Файл rpcpm.adm

Данный файл (см. листинг 1) следует подключить к административным шаблонам компьютера в редакторе групповой политики (Computer Configuration— Administrative Template — Add/Remove Template). По умолчанию параметры шаблона в редакторе отображаться не будут. Это связанно с тем, что он модифицирует параметры разделов реестра, находящихся за пределами HKLMSoftware. Чтобы произвести настройку параметров шаблона, необходимо включить режим отображения устаревших политик. Для этого в меню View нужно снять флажок Show Policies Only. В Windows Server 2003 необходимо открыть пункт меню View — Filtering и снять флажок Only show policy settings that can be fully managed.

Следующим этапом является выбор метода, при помощи которого трафик сегмента будет передаваться NIDS. Поскольку сеть построена на основе коммутаторов, фреймы передаются непосредственно между получателем и отправителем пакета. Необходимо изменить пути прохождения пакетов таким образом, чтобы они попадали на сетевой интерфейс системы обнаружения атак. Для этого можно применять разветвители (tap), концентраторы и span-порты. Более подробно об этих методах рассказано в статье «Intrusion Detection FAQ» института SANS, переведенной А. В. Лукацким (http://www.infosec.ru/press/pub/p45.htm).

В качестве NIDS используется бесплатная система обнаружения атак Snort (www.snort.org). Поскольку разрабатывалась она для систем UNIX (хотя существуют реализации и для Windows), то в качестве базовой операционной системы для построения используется Linux Red Hat 7.2.

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

Чтобы Snort мог работать с функцией разрыва соединений, необходимо откомпилировать его с поддержкой функции Flexible Response. Для этого, кроме стандартных компонентов системы, нужно установить библиотеку libdnet. Затем собирается дистрибутив с поддержкой данной функции:

# ./configure —enable-flexresp

Далее настраивается файл конфигурации системы snort.conf (см. листинг 2.).

Файл snort.conf

В секции <1> определяются основные переменные— путь к файлам правил, адреса внутренней и внешней сети. В секции <2> подключаются препроцессоры сборки фрагментированных пакетов и сессий. Секция <3> описывает порядок обработки правил NIDS: первыми будут обрабатываться правила, пропускающие пакет. В секции <4> подключается файл permit.rules, содержащий правила фильтрации трафика (см. листинг 3).

Файл permit.rules

В секции <1> файла permit.rules описываются сетевые адреса серверов в зависимости от той роли, которую они выполняют в корпоративной сети. Серверы могут принадлежать нескольким группам. Например, в группу FILESRV также включаются контроллеры домена, использующие общие папки для хранения групповых политик и серверы баз данных, в случае поддержки ими сетевой библиотеки Named Pipes.

Секция <2> содержит собственно фильтры, описывающие разрешенный трафик. Фильтр начинается с ключевого слова pass (пропустить), содержит адрес и номер порта отправителя и получателя пакета. В приведенном примере для большинства протоколов предусмотрена возможность взаимодействия как по TCP, так и по UDP. Однако в реальных сетях следует, где возможно, отказаться от использования UDP как от менее надежного протокола.

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

В разделе Exchnage разрешается взаимодействие с основными службами Exchnage (RFR, NSPI, Information Store) клиентов сети. Предварительно эти службы были привязаны к статическим портам (2000, 2001, 2002) при помощи административного шаблона.

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

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

В секции <4> описываются правила, разрывающие TCP- и UDP-соединения, не подходящие под правила из секции <3>.

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

# snort -c /etc/snort/snort.conf -o -D

Информация о попытках нарушения политики фильтрации трафика будет сохраняться в файле /var/log/snort/alert.

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

Сергей Гордейчик (gordey@infosec.ru)— преподаватель учебного центра «Информзащита». Автор курса «Повышение защищенности систем на основе Microsoft Windows Server 2003». Имеет сертификаты MCSE, MCT