OpenView Network Node Manager

Управление средой брандмауэра с использованием NNM

Показывать лекцию целиком

Введение

Демилитаризованная зона (DMZ) – это термин, который часто используется для характеристики островка безопасности или периметра защищенности, который охраняет корпоративную сеть от соединенных с ней ненадежных сетей. DMZ часто применяется, чтобы уберечь подключение к Internet от злоумышленников (право входа), одновременно управляя тем, какой уровень доступа к Internet имеют корпоративные пользователи (право выхода).

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

Специальные защищенные конфигурации для систем UNIX в среде DMZ содержат ограничение доступных сетевых служб и разрешение доступа к определенным сервисам, таким как telnet, конкретным пользователям и системам. Атак типа отказ в обслуживании (Denial of Service, DOS) удается избежать путем конфигурирования статических маршрутизаторов, ARP-кэшей и данных DNS.

Управление сетью через брандмауэр означает предоставление возможности некоторым портам TCP и UDP на входе и выходе системы NNM работать через фильтры пакетов (в предположении, что брандмауэр основан на технологии фильтрации пакетов). Система NNM может находиться внутри или вне DMZ. Влияние на фильтры пакетов брандмауэра в этих случаях различается.

Списки управления доступом (или access-lists ) маршрутизаторов могут мешать NNM раскрывать устройства и определять их конфигурацию. Требуется, чтобы системам NNM предоставлялся доступ только по чтению (ReadOnly, RO), по крайней мере, к демону SNMP (иначе называемому сервером SNMP).

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

Удаленный доступ к системе NNM необходим для внешнего персонала. Диапазон защитных решений простирается от низкопроизводительного коммутируемого доступа и среднепроизводительных ISDN и DSL до высокоскоростных кабельных модемов. Защитная аутентификация может обеспечиваться средствами двойных паролей, карт с переменным паролем (token card) и VPN.

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

Определение среды DMZ

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

DMZ содержит маршрутизаторы, фильтры пакетов, коммутаторы Ethernet, серверы DNS, proxy-серверы, socks-серверы и шлюзы telnet. Обычно DMZ представляет собой набор подсетей, которые конфигурируются в расчете на очень специфическую функциональность, ориентированную на обеспечение безопасности. Корректное функционирование DMZ является критически важным, и DMZ нуждается в активном управлении.

Право на вход в частную сеть часто ограничивается сервисами на основе SMTP (e-mail). Право на выход из частной сети часто ограничивается до web-трафика (HTTP), операций get службы передачи файлов (FTP), telnet и электронной почты (e-mail) на основе SMTP.

Как управлять DMZ? Поскольку доступ к DMZ ограничен, можно было бы располагать систему NNM внутри DMZ. Каким образом пользователи получили бы доступ к системе NNM? Можно было бы обязать пользователей обращаться к NNM физически изнутри DMZ. Также можно было бы сконфигурировать микроканал через брандмауэр DMZ, чтобы передавать трафик X-Windows в золотую подсеть, расположенную в частной сети.

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

(рис 10.1) Управление DMZ.

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

Работа с группой корпоративной безопасности

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

Группа безопасности может с большим успехом использовать систему NNM для мониторинга DMZ. Какой средой корпоративной сети следует управлять более тщательно? Путем установки порогов для ключевых показателей можно быстро отследить необычное поведение производительности. Имеет ли место лавина широковещательных пакетов на интерфейсе маршрутизатора в ненадежной сети? Повышается ли частота ошибок? Сильно ли загрузка превышает норму? Действует ли соединение? Не виноват ли в этом недавно раскрытый узел в DMZ? Почему он здесь? Почему загрузка ЦП proxy-сервера неожиданно достигает 100%? Почему не работает входящий сервер SMTP?

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

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

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

Специальная конфигурация средств безопасности для UNIX в DMZ

Ограничение доступа к системе NNM происходит там, где начинаются требования безопасности. Сначала следует остановить все сетевые службы, а потом запустить только те из них, которые нужны. Необходимо удалить все учетные записи пользователей и образовать те из них, которые в данном случае требуются. Следовательно, файл /etc/hosts.deny должен содержать (по крайней мере, изначально) строку

ALL: ALL

чтобы запретить доступ ко всем службам и системам. Затем для некоторых систем можно открыть входящую службу telnet, добавив в файл /etc/hosts.allow следующую строку:

in.telnetd: john@master1.myco.com, bar@foo.myco.com

Можно также обдумать возможность полного отключения telnet и использования для удаленного доступа безопасного варианта shell ( ssh ). Многие администраторы UNIX-систем являются приверженцами ssh.

Может потребоваться оказать дополнительное противодействие попыткам имитации соединения и конфигурировать сервис ident, чтобы клиентские узлы взаимодействовали путем запуска identd. Эта служба возвращает входное имя пользователя, запрашивающего сетевое соединение. Подробности можно найти на страницах оперативного руководства для hosts.allow, hosts.deny, snmpd.conf и identd. Заметим, что identd (демон идентификации) и inetd (демон Internet) различны, хотя их легко перепутать.

Следует убедиться, что разрешены теневые пароли. Нужно сконфигурировать файл /etc/securetty таким образом, чтобы он содержал только запись устройства console, и чтобы root не мог входить в систему напрямую через сеть. Это заставит каждого пользователя входить сначала в систему в качестве обычного пользователя. Далее следует запретить опцию .rhosts, включить аудит и воспользоваться HP OV Operations для отслеживания неудачных попыток входа в систему (или, по крайней мере, стоит написать несколько простых скриптов для выполнения этой задачи). Службы NIS и NFS последовательно отключаются для предотвращения сетевого доступа к файловой системе. Следует отказаться от всех демонов, которые обычно работают непрерывно, запускаются во время начальной загрузки и не обеспечивают ключевые сервисы.

Все несущественные сетевые сервисы, управляемые посредством inetd, "закомментариваются" в файле inetd.conf. Стоит также обдумать использование "упаковщиков (wrapper) TCP", для управления соединениями с inetd и из него. Это средство может разрешить/запретить соединения на основе данных о порте и/или адресе. Если необходимо наличие службы FTP, то нужно убедиться, что для ограничения доступа к этому сервису используется /etc/hosts.allow. В системе HP-UX для ограничения доступа к сетевым сервисам золотой подсетью следует использовать /usr/adm/inetd.sec.

Следует конфигурировать систему NNM таким образом, чтобы использовать DNS-серверы, предназначенные для DMZ, но если количество управляемых устройств относительно невелико, то более безопасно задействовать локальный файл /etc/hosts вместо того, чтобы обеспечивать управление конфигурацией. В самом крайнем случае следует использовать средства безопасности из восьмой версии BIND.

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

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

Брандмауэры и использование портов NNM

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

Имеются два основных сценария, которые следует принять во внимание при чтении остальной части этого раздела. В сценарии A управляемая сеть и накопительные станции NNM разделены брандмауэром. В NNM должна быть предусмотрена возможность проникновения через брандмауэр к своему домену управления. Пользователи NNM имеют прямой доступ к своим системам NNM. В сценарии B накопительная станция NNM размещается внутри домена управления. Пользователи и управляющая станция располагаются по другую сторону брандмауэра. Теперь и пользователи, и управляющая станция должны проходить через брандмауэр, чтобы достичь накопительной станции. (см. рис. 10.2).

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

Демон netmon посылает ICMP-запросы откликов и параметров. Обычно SNMP получает запросы на порт UDP 161, и ответы обязательны для обычных операций, включая обновление топологии между накопительной и управляющей станциями. Прерывания SNMP могут быть получены на порт UDP 162. Если имеется накопительная станция по другую сторону брандмауэра, тогда будет иметь место трафик от pmd до pmd Здесь pmd — это демон службы Postmaster в системе HP OpenView, поддерживающий коммуникации между всеми приложениями и процессами OpenView с использованием протоколов CMOT, CMIT и SNMP. (Прим. переводчиков). на порт TCP 162. При раскрытии серверов HTTP используются запросы на порты 80 и 280.

Чтобы обеспечить доступ к системе NNM через брандмауэр, должна быть разрешена работа протокола telnet на порте TCP 23. Чтобы иметь возможность запуска own через брандмауэр, должен допускаться трафик X-Windows на порте TCP 6000. Кроме того, для доступа можно использовать консоль NNM, основанную на web. Для нее используется порт TCP 8880.

(рис 10.2) Взаимосвязь между NNM и брандмауэром

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

Сводка номеров портов NNM
Сервис Протокол Порт источника Источник Порт назначения Назначение
SNMP UDP 10-24-65535 Управляющая станция 161 Управляемые узлы
SNMP Trap UDP 10-24-65535 Узлы 162 Управляющая станция
OV events TCP 1 0-24-65535 Накопительная станция 162 Управляющая станция
ICMP IP N/A Управляющая станция N/A Управляемые узлы
HTTP TCP 10-24-65535 Управляющая станция 80 or 280 Управляемые узлы
Telnet TCP 10-24-65535 Управляющая станция 23 Накопительная станция/управляемые узлы
X-Windows OVW TCP 10-24-65535 Накопительная станция 6000 Управляющая станция

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

Если важно наличие удобства FTP, то и для портов TCP 20 и 21 должно обеспечиваться прохождение данных через брандмауэр.

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

Учитывая последствия для безопасности разрешения доступа telnet и X-Windows через брандмауэр, и систему NNM, и брандмауэр следует конфигурировать таким образом, чтобы пропускался только трафик хорошо известных систем. Чтобы дать управляющей станции возможность выполнять необходимую операцию SNMP set на накопительной станции, нужно конфигурировать файл /etc/snmpd.conf на накопительной станции посредством следующей строки:

set-community-name:  secretКонечно, не следует на самом деле использовать "secret" как строку сообщества; об этом слишком легко догадаться.
		  VIEW: 1.3.6.1.4.1.11.2.17.4.3.1.1 .

Списки управления доступом маршрутизаторов и NNM

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

Поскольку в NNM используется SNMP, маршрутизаторы следует конфигурировать так, чтобы разрешать системам NNM доступ к службе SNMP на порте 161. Доступ можно дополнительно ограничить до некоторой части MIB (в зависимости от поставщика и версии ОС маршрутизатора). Например, в маршрутизаторе внешнего доступа с огромной таблицей маршрутизации будет возникать высокий уровень загрузки ЦП, когда NNM запрашивает его таблицу маршрутизации. Это очень неприятно, поскольку функционирование маршрутизаторов внешнего доступа тщательно отслеживается. Конфигурирование такого маршрутизатора, запрещающее доступ к таблице маршрутизации, восстанавливает психическое здоровье сетевых менеджеров. Это не влияет на процесс автоматического раскрытия, производимый NNM, поскольку домен управления обычно не распространяется за пределы маршрутизатора внешнего доступа. Пример списка доступа приводится на рис. 10.3.

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

(рис 10.3) Пример списка доступа маршрутизатора

Эти строки в конфигурационном файле маршрутизатора Cisco определяют access-list 2 как IP-адреса 192.6.173.101 и 192.6.173.202. Список access-list 2 применяется к агенту SNMP ( snmp-server ), так что только устройства из этого списка могут выполнять операции snmpget (RO). Строкой сообщества для RO является public.

Фильтрация пакетов с использованием маршрутизатора

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

Имитация IP происходит, когда исходный IP-адрес пакета, поступающего из ненадежной сети, подделывается таким образом, как будто он из корпоративной сети. Например, предположим, что LAN сервера безопасности (Secure Sever LAN, SSL) – это подсеть 192.6.173. Один интерфейс маршрутизатора находится в DMZ, а другой подключается к ненадежной сети. Этот интерфейс можно сконфигурировать так, чтобы избежать имитации IP путем блокирования пакетов, входящих из ненадежной сети с исходными IP-адресами, принадлежащими подсетям 192.6.173 и 192.6.174.

(рис 10.4) Пакетный фильтр маршрутизатора

Маршрутизатор, показанный на этом рисунке, сконфигурирован с фильтрами пакетов на его интерфейсах. Интерфейс, соединенный с ненадежной сетью, пропускает только пакеты, предназначенные для серверов web, mail, DNS и telnet. Это блокирует все прямые атаки на сам маршрутизатор, основной защитный компьютер и устройства в частной сети слева от основного защитного компьютера.

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

  • запросы SMTP (на порт TCP 25), посылаемые на сервер e-mail;
  • запросы DNS (на порт UDP 53);
  • ответы HTTP, возвращаемые на proxy-web-сервер;
  • запросы HTTP (порт TCP 80), относящиеся к публичному web-серверу;
  • ответы FTP, возвращаемые proxy-web-серверу;
  • пакеты telnet (от порта TCP 23), ограниченные шлюзом telnet.
  • Это предотвращает вход в DMZ telnet, FTP и других клиентов, и разрешает вход в DMZ клиентам SMTP, DNS и HTTP ненадежной сети.

    Удаленный доступ к NNM

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

    Простым низкопроизводительным решением является подключение модемного порта системы NNM к заданной телефонной линии. Удаленный член группы поддержки набирает номер и входит в систему UNIX, предоставляя свое учетное имя, пароль учетной записи и пароль подключения. Первоначально устанавливается терминальный сеанс, ограничивающий доступный набор инструментальных средств приложениями командной строки. Однако можно конфигурировать соединение по протоколу двухточечного соединения (PPP) либо вручную, либо во входном скрипте, чтобы дать портативному компьютеру возможность работать в качестве удаленного узла сети. Тогда специалист-ремонтник сможет запустить эмулятор X-Windows и получить доступ к полному GUI NNM. Ограничения на пропускную способность коммутируемых модемных соединений будут заметно снижать скорость реакции приложений X-Windows. Удачным решением при использовании коммутируемого доступа является VNC (Virtual Network Computing), так как для него используется гораздо меньшая пропускная способность, чем для X-Windows.

    Большинство корпораций обеспечивает более безопасное и потенциально более производительное решение для удаленного доступа пользователей портативных компьютеров в форме коммутируемого доступа "1-800", требующего наличия карт SecureID для аутентификации. В этом случае портативный компьютер становится доверенным узлом корпоративной сети, и удаленный специалист по поиску и устранению неисправностей получает доступ к системе NNM через telnet или X-Windows. Конечно, если доступ к системе NNM заблокирован по причине выхода из строя сети, запасным решением является прямое использование коммутируемой модемной связи.

    Для служащих, которые стационарно работают в удаленном режиме, например, у себя дома, часто обеспечивается защищенный доступ к корпоративной сети с помощью службы ISDN на скорости более 128Kbps. Служба ISDN является безопасной по причине наличия автоматического определения номера (ANI), свойственного протоколу сигнальной системы 7 (SS7), который используется в ISDN.

    Удаленные пользователи, работающие дома, могут также пользоваться высокоскоростным доступом в Internet в виде цифровой абонентской линии (DSL), кабельного модема или службы FTTH (Fiber To The Home). При этом некоторые корпорации предпочитают использовать технологию виртуальной частной сети (VPN) для создания защищенного шифрованного IP-туннеля между домашними компьютерами служащих и корпоративной сетью. Это обеспечивает высокоскоростной способ удаленного доступа к системам NNM корпорации. И снова считается, что выход сети из строя не затрагивает доступ к системе NNM.

    Вернуться к учебному плану