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

Начнем с межсетевого экрана. Мультипротокольный маршрутизатор (MPR) из комплекта ВМ снабжен такими функциями, как фильтрация пакетов и подмена сетевых адресов (NAT для протокола IP, Address Maping Gateway для протокола IPX). Таким образом, можно говорить о том, что мы имеем файрвол сетевого уровня, позволяющий нам, некоторым образом закрыть нашу сеть от нежелательных пакетов извне или не выпускать наружу нежелательные пакеты изнутри.

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

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

Политика безопасности есть совокупность правил разграничения доступа людей к ресурсам информационной системы. Правила фильтрации пакетов очень сложно интерпретировать таким образом. Внутри пакета сетевого уровня нет информации о том, кто его отправил (есть только адрес хоста с которого ушел пакет), и, тем более, у вас нет возможности проверить личность отправителя (произвести аутентификацию). Таким образом, правила пакетной фильтрации могут быть интерпретированы только в смысле "ВСЕМ МОЖНО" или "НИКОМУ НЕЛЬЗЯ". Если такими правилами можно отразить вашу политику безопасности, то вам повезло, и вы можете ограничиться файрволом, если нет, значит нужны дополнительные средства.

Для каких целей разумно использовать файрвол? Например, для защиты хоста или группы хостов от завала мусором. Вы можете запретить, к примеру, прием хостом пакетов ICMP (типа PING). Очень полезно использовать файрвол для прикрытия так называемой демиллитаризованной зоны (ДМЗ). Эта самая ДМЗ организуется ввиде маленькой сети прицепленой к Интернет. В ней располагаютя "бесконтрольные" ресурсы, такие как публичные интернет-серверы или рабочие станции (интернет-киоск). Может быть разумно прикрыть ДМЗ от ненужных пакетов. Если вы, например, используете только ограниченный список протоколов (и стандартные порты для них), разумно отфильтровать все остальное. Это может избавить вас от "хакеров-любителей". Для организации интернет-киосков очень хорош NAT, можно подвесить целую кучу станций на один официальный IP адрес.

Для организации соединения корпоративной сети с Интернет лучше использовать одну из двух других компонент пакета Border Manager, шлюз (ip/ip или ipx/ip) или прокси-сервер. В этих компонентах вы получаете сразу два преимущества. Во-первых, правила контроля доступа применимые к принципиалам безопасности NDS (User, Group, Organization Unit, Organization). Во-вторых, узел, осуществляющий соединение сетей, на самом деле, их не соединяет на сетевом уровне, в том смысле, что не является маршрутизатором. Сетевой пакет не сможет проникнуть из одной сети в другую, даже если очень захочет, поскольку для обеих сетей это конечный узел и маршрута между сетями нет.

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

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

Запретить все пакеты всех протоколов обмена информацией о маршрутах и сервисах сети, проходящие через публичный интерфейс. А именно IPX RIP и SAP, IP RIP, EGP и OSPF. Запретить все пакеты IP и IPX через публичный интерфейс. Про Source Route Bridge я не пишу, поскольку выключено, аналогично AppleTalk. На самом деле IPX на публичном интерфейсе тоже поддерживать не надо, но на всякий случай, фильтры я рекомендую оставить, вдруг случайно включите IPX не на тот интерфейс. Короче говоря, должно быть примерно так:

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

Теперь пора писать исключения (Exceptions). Но сначала разберемся с типами фильтров. Имеющиеся у нас фильтры можно разделить на два главных типа: статические и динамические. Статический фильтр делает то, что написано. Сказано пропустить пакет такого-то типа с такого-то на такой-то адрес и порт, он это и сделает. Динамический фильтр (Statefull) начнет умничать и пороть отсебятину. Он в дополнение к сказанному создаст временный фильтр, разрешающий прием ответа на пропущенный пакет, причем ответ будет разрешен только тому хосту, на который ушел пакет, разрешенный динамическим фильтром. Понятно, что динамические фильтры обеспечивают сразу два преимущества. Во-первых, сокращается количество фильтров (вам не надо прописывать фильтры разрешающие ответные пакеты). Во-вторых, повышается уровень безопасности (ответ разрешается только после того, как был отправлен запрос, т.е. только по вашей инициативе). Однако есть случаи, когда динамические фильтры вредны. Если вы хотите использовать Real Audio динамические фильтры будут приводить к потере пакетов и постоянному восстановлению соединения с сервером. Причина видимо в том, что сервер может не успеть ответить за время существования ответного фильтра (с протоколом UDP такое бывает). Может причина и в чем-то другом, но вывод один: если вы используете Real Audio, вам необходимо задать для этого протокола статические фильтры.

Прежде всего рекомендую установить в TCP/IP Packet Forwarding Filters следующие два исключения:

Этих фильтров достаточно для того, чтобы клиенты внутренней сети могли работать через прокси-сервер или шлюз. Вы можете обратить внимание на то, что фильтры не очень "строгие". Но это не является сколько-нибудь опасным, ведь инициатором соединения может выступать только ваш ВМ-сервер. Следует заметить, что эти фильтры не позволяют использовать протокол ICMP. Соответственно, вы не сможете пользоваться командой Ping, и ваш сервер не будет отвечать на пакеты ICMP Echo Request или другие пакеты ICMP. Если вы хотите оставить себе возможность пользоваться Ping, но не давать такой возможности клиентам Интернет, добавьте к этому списку фильтр под названием "ping-st" (Statefull ICMP) из списка предопределенных фильтров в утилите FILTCFG.

Здесь я привел фильтры, прикрывающие публичный интерфейс шлюза или прокси. Их можно легко переделать в фильтры, прикрывающие ДМЗ, для этого необходимо указать Source Interface - HPTX_1 (Private), Src Addr Type - Network, Src IP Address - адрес вашей сети ДМЗ.

К указаным фильтрам необходимо добавлять другие по мере того, как вы хотите разрешить доступ клиентов интернет к сервисам внутри вашей ДМЗ или сервисам вашего BM-сервера. Например, если вам нужен Reverse-Proxy (HTTP Accelerator), то необходимо разрешить доступ на его порт (обычно 80) по инициативе "снаружи". То же самое касается шлюза электронной почты (или SMTP Proxy). Для этого вы можете использовать Statefull фильтры из списка предопределенных в утилите FILTCFG. Только не забудьте поменять местами записи во всех строках Source и Destination из приведенного мной примера.

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

Еще несколько слов об организации ДМЗ. Когда вы договариваетесь с провайдером о подключении вас к Интернет, желательно покупать постоянные IP адреса, причем не один, а несколько (небольшую сеть). Это даст вам возможность организовать ДМЗ, что очень полезно. Вообще говоря, понятие ДМЗ подразумевает, что на нее не распространяются какие-либо требования защиты, но как я говорил выше, сетевой файрвол здесь не помешает, более того применив NAT, вы серьезно расширите свою ДМЗ. Это очень просто, конфигурируете публичный интерфейс с одним из официальных адресов (это будет ваш Primary адрес) и, командой с консоли add secondary ipaddress, добавляете все остальные официальные адреса (или по мере надобности). Включаете на интерфейсе NAT в режиме Static and Dynamic. При этом Primary адрес будет использоваться в режиме Dynamic, а все Secondary в режиме Static. Статический режим необходим для тех хостов ДМЗ, к которым нужен доступ снаружи, к ним относятся все серверы ДМЗ, включая прокси (шлюз), который обеспечивает границу между корпоративной сетью и Интернет (в данном случае ДМЗ). Кроме того статический режим понадобится тем хостам, которые намерены работать как Х-терминалы каких-либо UNIX-хостов Интернет (к таким хостам тоже нужен доступ снаружи, поскольку на них запускаются Х-серверы). Прочие рабочие станции могут работать с режимом Dynamic. Таким образом вы можете, имея пригоршню официальных адресов, создать здоровенную ДМЗ. Подробнее о том, как конфигурировать NAT, читайте в документации. Главное не забудьте, что сервер, который поддерживает NAT, должен быть маршрутизатором (в этом его кардинальное отличие от шлюза или прокси).

Теперь можно переходить к следующему разделу.

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

Прежде всего я не рекомендую вам использовать IP Gateway. Чтобы эта штука работала, необходим специальный клиент на рабочих станциях (входит в состав Novell NetWare Client), который на сегодня имеется только для платформ Microsoft. Если у вас есть рабочие станции Linux или Solaris, то использовать шлюз они все равно не могут. Нормальная ситуация, когда вы используете только прокси-сервер. С ним может работать любой веб-браузер, а больше ничего и не надо. Но если вам очень хочется, то используйте шлюз, собственно это ваши трудности.

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

И так, о правилах контроля доступа. Какие правила надо писать? Прежде всего необходимо выбрать режим "запретить все, что не разрешено". Затем необходимо понимать, как составляется список эффективных правил для ВМ.

А суть в том, что правила можно записывать, как в контейнерах NDS, так и в свойсвах объекта Сервер того сервера, на котором установлен ВМ. Список эффективных правил составляется по принципу сначала список сервера, затем список контейнера, в котором находится сервер, затем список вышестоящего контейнера и так до контейнера класса Страна, последним действует правило Default (у нас "запретить все и всем"). Если вы определите правила в контейнерах, не попадающих в эту цепочку, то они и не будут приниматься во внимание. А выполняются правила по принципу: первое применимое из списка. То есть, если у вас есть два правила, одно из которых гласит, что всем разрешен доступ к такому-то хосту, а другое гласит, что Петрову запрещен доступ к такому-то хосту, то участь Петрова зависит от порядка правил в списке. Если первым окажется разрешающее правило, Петров получит доступ к хосту, если первым окажется запрещающее правило, Петров не получит доступа. А Сидоров получит доступ всегда (потому, что Сидоров у нас начальник управления IT и мы к нему относимся хорошо, он нам технику покупает, шутка). Вообщем, какое правило удалось применить первым, то и будет выполнено, оставшиеся игнорируются. По этой причине необходимо следить за порядком следования правил в списке.

Принимая во внимание вышесказанное, отправляемся в самый верхний контейнер нашего дерева NDS и пишем в нем правило:

Action: Allow, Access Type: Port, Access Details: Service: Any, Transport: TCP&UDP, Source: Specified: имя текущего контейнера, Destination: Any. Устанавливаем флаг Enable Rule Hit Loggin и говорим ОК.

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

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

Action: Allow, Access Type: Port, Access Details: Service: DNS, Transport: TCP&UDP, Source: Specified: 194.85.138.66, Destination: Any. Здесь указан IP адресс публичного интерфейса.

Это правило разрешает серверу ВМ справляться в DNS об именах хостов. Оно вам очень пригодится, когда вы захотите добавить правила, запрещающие доступ к некоторым хостам (не все котам масленица), указывая их имена. Без этого, такие правила работать не будут. Это правило лучше держать первым в списке (чтобы ненароком его не отменить). Заметим, что это правило останется единственным, в котором указан адрес хоста в качестве источника обращения к сервису. Если вы серьезно относитесь к контролю за доступом к корпоративным ресурсам (а канал в Интернет это тоже корпоративный ресурс), всегда пишите правила, относящиеся к людям, а не к хостам, сетям и т.п. и всегда включайте Rule Hit Loggin.

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

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

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

Теперь немного о НТТР - акселераторе. Это прокси наоборот. Позволяет разрешить доступ снаружи к внутренему веб-серверу. Здесь я позволю себе дать две рекомендации:

Во-первых, при прописывании акселератора, там где у вас спрашивают DNS-имя вашего внутреннего веб-сервера, лучше введите его IP адрес. Это избавит прокси сервер от необходимости лазить к вашему внутреннему DNS-серверу (настроен-то прокси на DNS провайдера, а там наверняка не знают ваших внутренних адресов).

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

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

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

Устал я уже от этого раздела, перейду к следующему.

Я еще не закончил. Продолжаю писать!