Интернет-шлюз на&nb p;базе OpenSUSE&nb p;10.2. Настройка SuSEfirewall2

SuSEfirewall2 — удобная надстройка над ip_tables

Современные версии ядра Linux (2.6.x) содержат мощное средство контроля над IP-трафиком — ip_tables, для его настройки служит утилита iptables. Этот механизм обеспечивает в числе прочего трансляцию адресов (DNAT и SNAT), Forwarding и Masquerading. На сайте разработчиков представлен полный набор документации, включая руководство на нескольких языках. Единственный недостаток — высокая сложность освоения — с точки зрения многих пользователей перевешивает любые достоинства. По этой причине в дистрибутив OpenSUSE включено удобное и простое в использовании средство — SuSEfirewall2 (сокращенно — SFW2), фактически представляющее собой надстройку над iptables.

 

 

О правильном применении этого инструмента и пойдет речь далее.

Прежде всего потребуется настроить сетевые интерфейсы, в простейшем случае достаточно двух — внешнего и внутреннего. Допустим, это будут eth1 (MAC 00:2e:15:fb:61:10) и eth0 (MAC 00:16:ac:47:8f:ad) соответственно. Можно воспользоваться разделом Network Devices / Network Card конфигуратора YaST2 (/sbin/yast2) либо набрать в консоли следующую последовательность команд:

ifconfig eth0 down
ifconfig eth0 10.10.1.1 netmask 255.255.255.0 up
ifconfig eth1 down
ifconfig eth1 195.14.50.94 netmask 255.255.255.248 up
route add default gw 195.14.50.89

Очевидно, что приведенные для примера IP-адреса и сетевые маски следует заменить актуальными для вашей сети.

Конфигурация SFW2 хранится в файле /etc/sysconfig/SuSEfirewall2. Для его редактирования можно использовать, например, вызываемый по клавише F4 встроенный редактор файлового менеджера mc. При переносе текстовых файлов между ОС следует помнить, что принятый в Linux разделитель строк состоит из единственного символа CR, тогда как в DOS и Windows используется пара CR/LF.

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

gawk '{ if(substr($0, 0, 1)!="#") if(substr($0, length($0)-2)!="=\"\"") print $0 }'
/etc/sysconfig/SuSEfirewall2 | grep .

gawk — подходящее средство для построчной фильтрации без использования регулярных выражений

В результате ее выполнения в консоль будет выведено содержимое конфигурационного файла в легко читаемом виде — окажутся исключены строки, начинающиеся со знака «#» (комментарии) либо заканчивающиеся на «=""» (не определенные явным образом параметры). Чтобы не набирать длинную команду более одного раза, можно сохранить ее, например, в файле swf2cfg, предварив строкой «#!/bin/sh» и установив соответствующие права командой chmod 700 swf2cfg. Теперь для анализа настроек достаточно набрать в консоли ./swf2cfg, однако, используя подобный фильтр, не следует забывать о существовании значений по умолчанию.

Рассмотрим подробнее формат и назначение основных параметров /etc/sysconfig/SuSEfirewall2.

Первым делом следует определить, какой из сетевых интерфейсов является внешним (подключенным к сети интернет-провайдера) и внутренним (подключенным к локальной сети). Параметр any означает «все прочие, не указанные явным образом интерфейсы» — в нашем случае таковые считаются по умолчанию внешними:


• FW_DEV_EXT="any eth-id-00:2e:15:fb:61:10"
• FW_DEV_INT="eth-id-00:16:ac:47:8f:ad"

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


• FW_ROUTE="yes"
• FW_MASQUERADE="yes"
• FW_MASQ_DEV="$FW_DEV_EXT"

Далее надлежит перечислить маскируемые подсети, с указанием сетевых протоколов и портов, а также адресов, куда разрешается перенаправлять трафик. Подсети перечисляются через пробел, для большей читабельности примера они размещены по одной на строку с применением символа конкатенации — обратной косой черты (поскольку фактически речь идет об одной строке, комментарии до завершающих кавычек недопустимы). Итак, в нашем случае находящемуся в локальной сети серверу 10.10.1.3 разрешается соединяться с любыми внешними сетями по протоколу tcp/ip, при этом допустимы три порта назначения 25 (smtp), 110 (pop3), 5899 (Radmin). Кроме того, разрешаются DNS-запросы по протоколу udp. Имеющая адрес 10.10.1.20 рабочая станция получает возможность соединяться с почтовым сервером по адресу 195.151.13.100, используя стандартные tcp/ip порты 25/110:


• FW_MASQ_NETS="\
• 10.10.1.3/32,0/0,tcp,25 \
• 10.10.1.3/32,0/0,tcp,110 \
• 10.10.1.3/32,0/0,tcp,5899 \
• 10.10.1.3/32,0/0,udp,53 \
• \
• 10.10.1.20/32,195.151.13.100/32,tcp,25 \
• 10.10.1.20/32,195.151.13.100/32,tcp,110"

Следующие два параметра включают защиту от возможных атак на внутренний сетевой интерфейс, но разрешают доступ из локальной сети к портам 22 (ssh) и 3128 (proxy) роутера:


• FW_PROTECT_FROM_INT="yes"
• FW_SERVICES_INT_TCP="22 3128"

Далее необходимо указать внешние подсети, для которых явно запрещен (REJECT) или разрешен (ACCEPT) доступ к определенным сервисам, работающим на роутере. Следует иметь в виду, что при отсутствии явного разрешающего правила пакеты не будут пропущены — к ним будет применена политика DROP, в качестве реакции на возможную атаку более предпочтительная, чем REJECT. Первым параметром запрещается доступ с любых внешних адресов на порт 113 по протоколу tcp/ip, вторым допускаются соединения с внешнего адреса 80.17.230.11 по протоколу tcp/ip на порт 22 (ssh) роутера. Возможность удаленного подключения создает потенциальную уязвимость, категорически не рекомендуется разрешать ssh-сессии с произвольных адресов:


• FW_SERVICES_REJECT_EXT="0/0,tcp,113"
• FW_SERVICES_ACCEPT_EXT="80.17.230.11/32,tcp,22"

Доступные извне сервисы — угроза безопасности сетиСледующий параметр определяет доступность отдельных локальных сервисов для внешних подсетей. Речь идет, например, о почтовом или веб-сервере, которые находятся в маскируемом сегменте сети и не имеют внешних IP адресов. Необходимо понимать, что сам факт наличия доступных извне сервисов создает серьезную угрозу для безопасности всей локальной сети. Потенциальный злоумышленник может воспользоваться как недочетами конфигурации, так и обнаруженной уязвимостью в исполняемом коде. В приведенном примере открыт доступ к почтовому серверу 10.10.1.3 с внешних адресов, относящихся к подсети MTU-Stream, а с внешнего адреса 80.17.230.11 — к службе удаленного администрирования (Radmin):


• FW_FORWARD_MASQ="\
• 83.237.0.0/16,10.10.1.3,tcp,25,25,195.14.50.94 \
• 83.237.0.0/16,10.10.1.3,tcp,110,110,195.14.50.94 \
• \
• 85.140.0.0/16,10.10.1.3,tcp,25,25,195.14.50.94 \
• 85.140.0.0/16,10.10.1.3,tcp,110,110,195.14.50.94 \
• \
• 85.141.0.0/16,10.10.1.3,tcp,25,25,195.14.50.94 \
• 85.141.0.0/16,10.10.1.3,tcp,110,110,195.14.50.94"
• \
• 80.17.230.11,10.10.1.3,tcp,4899,4899,195.14.50.94 \

Очередная группа из четырех параметров влияет на количество журналируемых событий. Суффикс CRIT предписывает сохранять в лог-файл информацию об отброшенных (DROP) или принятых (ACCEPT) пакетах только при условии, что они были распознаны как «критичные» — существенные для безопасности. К таковым относятся в частности некоторые типы icmp-пакетов, запросы на rpc-соединения, перенаправленные пакеты. Суффикс ALL требует осторожного применения, ввиду вероятного раздувания лог-файла и переполнения дискового раздела:
• FW_LOG_DROP_CRIT="yes"
• FW_LOG_DROP_ALL="no"
• FW_LOG_ACCEPT_CRIT="yes"
• FW_LOG_ACCEPT_ALL="no"

Значение следующего параметра на время отладки можно установить в «no», после завершения тестов желательно вернуть к исходное состояние:
• FW_KERNEL_SECURITY="yes"

Рекомендованное значение «yes» позволяет роутеру отвечать на icmp-запрос «echo request» (так называемый ping), что может быть полезно при проверке работоспособности канала и доступности сервера:
• FW_ALLOW_PING_FW="yes"

Значение по умолчанию «no» запрещает исходящий из локальной сети ping:
• FW_ALLOW_PING_EXT="no"

Широковещательные рассылки могут быть разрешены ("yes"), запрещены ("no") или разрешены для отдельных портов ("137").
• FW_ALLOW_FW_BROADCAST_EXT="no"
• FW_ALLOW_FW_BROADCAST_INT="no"

Название очередной пары параметров способно ввести в заблуждение. В действительности значение «yes» читается как «не сохранять в лог сведения об отброшенных широковещательных пакетах»:
• FW_IGNORE_FW_BROADCAST_EXT="yes"
• FW_IGNORE_FW_BROADCAST_INT="no"

Следующий параметр допускает использование политики REJECT вместо DROP для внутреннего сетевого интерфейса, что сокращает время ожидания злоумышленником реакции на запрещенные действия:
• FW_REJECT_INT="yes"

Конфигурация вступает в силу после запуска /sbin/SuSEfirewall2 при условии отсутствия синтаксических ошибок.

Подробная документация с примерами находится в директории /usr/share/doc/packages/SuSEfirewall2/.

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

• отдавать предпочтение наиболее защищенным версиям ПО и протоколов (ssh, vsftpd и т.д.)
• следить за сообщениями о выявленных уязвимостях и своевременно устанавливать «обновления» и «заплатки»
• избегать использования ПО, источник происхождения которого вызывает сомнения
• отказаться (если это возможно) от использования роутинга в пользу прокси-сервера

Об установке прокси-сервера squid-cache пойдет речь в следующей, третьей части.



Статья получена: hostinfo.ru