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

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

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

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

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

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