Firewall2
 
ы с общим смыслом ”SuSEfirewall – плохо, iptables – хорошо”, решил таки разродиться сим опусом, основаном на чтении документации и личном опыте настройки реального МСЭ(межсетевого экрана)
 
Сразу оговорюсь. YaST использовался исключительно для начальной настройки в стиле ”лишь бы работало”. Тобишь, прописал внешний и внутренний интерфейсы, включил маскарадинг и прописал минимальные фильтры (ncp, ssh, http, https, etc)
 
Далее открыл редактором /etc/sysconfig/SuSEfirewall2 и первым делом почистил от комментов, мешают, ну просто жуть как.
 
Вот, кстати, что таки оставил, - подсказку где искать помощи в случае ЧАВО.
# If you have got any problems configuring this file, take a look at
# /usr/share/doc/packages/SuSEfirewall2/EXAMPLES for an example.
 
Если эту опцию включить, то скриптом принимаются во внимание только настройки внешних интерфейсов, для всех внутренних открывается полный доступ. Т.к. мне надо было закрыть прямой доступ клиентов наружу, то внутренние сети я тож позакрывал
FW_QUICKMODE="no"
 
Ну тут собственно, прописаны 3 зоны, как вариант вместо МАС можно подставить имена интерфейсов, типа eth0, ppp0 и т.д.
FW_DEV_EXT="eth-id-00:a0:24:a6:c9:ff"
FW_DEV_INT="eth-id-00:50:04:52:95:e1"
FW_DEV_DMZ=""
 
Ну это мне YaST сам наколбасил на мое предложение вклюить маршрутизацию и маскарадинг на внешней сетке, приколько, получается что можно отмаскарадить Интернет в свою серую сетку.
FW_ROUTE="yes"
FW_MASQUERADE="yes"
FW_MASQ_DEV="$FW_DEV_EXT"
 
Туточки описываем, а кого собстно маскрадим. Здесь начинается первая часть веселья, ибо маскарадить можно практически как хошь.
10.0.0.0/8 – вся сетка 10.0.0.0/255.255.255.0 ходит куда хочет, без, так называемых рестрикшенов
10.0.1.0/24,0/0,tcp,80 – сеть 10.0.1.0 будет маскарадиться только если клиент пойдет за веб-контентом
10.0.1.0/24,0/0,tcp,1024:65535 – та же сеть маскарадится если клиент запросит что-то из диапазона портов 1024:65535
Если надо прописать несколько правил маскарадинга, то разделяем описания сетей пробелами.
Небольшая ремарка. Не разобрался еще почему так, но ситуация в следующем, если прописываем маскарадинг всей сети без указания портов, то наружу выпускает по всем портам. Параметр FW_AUTOPROTECT_SERVICES="yes" не решает проблему. Так что лучше указывать какой сети на какой порт разрешить натиться.
FW_MASQ_NETS="10.0.50.0/24 10.0.51.0/24,0/0,tcp,22"
 
Ну тут все прозрачно, включаем защиту от внутренней сети
FW_PROTECT_FROM_INTERNAL="yes"
 
Далее автоматически закрываем доступ ко всем запущенным службам, кроме описаных отдельно
FW_AUTOPROTECT_SERVICES="yes"
 
Вторая часть известного балета – расписывание к каким сервисам и по каким протоколам разрешен доступ снаружи. Допускается запись как номера порта, так и названия службы (описаной в /etc/services). Можно указать и диапазон портов. Для параметра FW_SERVICES_*_IP также указывается либо имя протокола либо его номер. Отдельные записи разделяются пробелами.
FW_SERVICES_EXT_TCP="524 8008:8030 http https ssh"
FW_SERVICES_EXT_UDP=""
FW_SERVICES_EXT_IP=""
FW_SERVICES_EXT_RPC=""
 
Аналогично для DMZ...
FW_SERVICES_DMZ_TCP=""
FW_SERVICES_DMZ_UDP=""
FW_SERVICES_DMZ_IP=""
FW_SERVICES_DMZ_RPC=""
 
... и внутренней сети. На всякий случай, обращаю внимание, что DNS, бегает по UDP протоколу, TCP используется только в случае если ответ сервера не умещается в одном пакете.
FW_SERVICES_INT_TCP="25 110 143 8008 8009 8028 8030 8080"
FW_SERVICES_INT_UDP="53"
FW_SERVICES_INT_IP=""
FW_SERVICES_INT_RPC=""
 
Все вышесказанное относится и к этому параметру, но он принимается во внимание только если включен ”быстрый режим” МСЭ
FW_SERVICES_QUICK_TCP=""
FW_SERVICES_QUICK_UDP=""
FW_SERVICES_QUICK_IP=""
 
Здесь уже можно более тонко настроить кому и что именно можно. Например, хосту 10.0.0.2 разрешено использовать ssh, а всей сети – прокси-сервис
FW_TRUSTED_NETS="10.0.0.2,tcp,22 10.0.0.0/24,tcp,3128"
 
Запрещаем доступ к портам сервера номером выше чем 1023. Не совсем понял вариант DNS, вроде как разрешает доступ только определенным серверам имен.
FW_ALLOW_INCOMING_HIGHPORTS_TCP="no"
FW_ALLOW_INCOMING_HIGHPORTS_UDP="DNS"
 
Данный параметр заставляет МСЭ детектить работающие сервисы
FW_SERVICE_AUTODETECT="yes"
 
Создатели программы рекомендуют поставить yes напротив нужных сервисов, чтобы они работали. Не знаю, не знаю... проксю я прописал в виде открытого порта 8080 на внутреннем интерфейсе и все работает.
Запрещаем доступ к DNS
FW_SERVICE_DNS="no"
Запрещаем работу клиента DHCP (тобишь этот сервер уже в жизни не получит автоматического адреса)
FW_SERVICE_DHCLIENT="no"
Запрещаем сервер DHCP
FW_SERVICE_DHCPD="no"
Запрещаем прокси
FW_SERVICE_SQUID="no"
Запрещаем самбу (с превиликим удовольствием! нафига самба если есть работающий ncp?
FW_SERVICE_SAMBA="no"
 
Проброс. Опасная штука. Рекомендуется использовать ТОЛЬКО для проброса соединения в DMZ. Синтаксис таков ”исходная сеть(или хост), хост назначения”. По желанию можно указать еще протокол и номер порта. Например, ”0/0,212.188.4.10,tcp,22” пробросит все соединения на 22 порт внутреннего хоста. Адрес назначения может быть только реальным. Типичное применение – организация доступа к почтовому серверу.
FW_FORWARD=""
 
Тоже самое что и абзацем выше, только для проброса во внутреннюю сеть. Чтобы сервис был доступен и из внутренней сети, необходимо сделать форвардинг (предыдущий абзац) из внутренней зоны на DMZ. Опять же, крайне не рекомендуется юзать эту фичу. Но она есть. Пример, внутри есть веб-сервер, нам нужно чтоб до него достучались снаружи. Пишем
FW_FORWARD_MASQ="10.0.0.2,tcp,80 10.0.0.2,tcp,443"
 
Штука полезная для организации прозрачного прокси, когда надо пробросить порт на нужный порт нашего шлюза. Синтаксис следующий ”источник (сеть/хост), назначение(сеть/хост), протокол, перенаправляемый порт, порт назначения”. Например, "10.0.0.0/8,0/0,tcp,80,3128 0/0,172.20.1.1,tcp,80,8080"
FW_REDIRECT=""
 
Ну на этом пожалуй все. Для начальной настройки вполне сойдет. А остальное уже нюансы, которые желающие могут сами раскопать. Статейка не претендует быть истиной на 100%, в ней могут быть ошибки. Буду рад, если присутствующие что-то уточнят либо исправят.
 
За сим раскланиваюсь.
Loky,
Novell Professional Services
 
 
Тонкая настройка SuSEfirewall2
Technorati Tags: openSuSE, SuSEfirewall2, firewall, configuring
Сколько раз мне попадались люди, которые неравнодушно относятся к вашему компьютеру/серверу/сайтам - dos'ят, пытаются взломать, спамят и т.д. Таких людей надо несомненно банить. Банить в файрволле, что бы ни один пакет не дошел от зловредного пользователя. Вот тут то и встает вопрос, о том, как это делать. В этом посте речь пойдет только об 11ом семействе SuSE (более ранние версии просто не проверял). Все знают, насколько удобная штука SuSEfirewall, хочется сказать спасибо разработчикам дистрибутива за этот прекрасный компонент системы. Файрволл в SuSE может управляться как с помощью yast, так и правкой конфига в /etc/sysconfig/SuSEfirewall2
В интернете полно статей по настройке с помощью SuSEfirewall NAT'а, разделения внешней, внутренней и демилитаризованной зон, пробоса портов. Единственное чего нет - так это возможности указать список ip адресов, которым необходимо запретить доступ к серверу. У меня сервер подключен к 3 сетям, сети интернет, локальной сети провайдера, и собственной домашней сети. Так вот, раньше приходилось добавлять в ручную ip адрес в таблицу INPUT и ставить по действие DROP. Но проблема просто этим не решалась, SuSEfirewall обновляет свои правила, и через несколько дней забаненные адреса просто пропадают, поэтому раньше я прописывал их где нибудь в конце /sbin/SuSEfirewall2 , дабы они всегда добавлялись при перезагрузке основных правил. Это было жутко не красиво и не удобно, все время ругались rkhunter и ossec на измененную checksumm для этого файла. Я перерыл весь гугл в поисках информации по данному вопросу (прим. авт. Либо я реально не умею искать, либо в гугле реально нет нормальной инфы по SuSEfirewall). Да хочется сказать, по поводу suse-community, обращаться туда я даже не пытался, после того как я попросил объяснить мне более детально настройку wi-fi. На официальном канале #opensuse мне просто кинули пару-тройку ссылок. Естественно я их уже не раз смотрел и мне ни чего не дало. На дальнешие мои просьбы о помощи мне сказали, что-то обидное(прим. авт. давно это было - непомню :-] ) и сказали, что бы я не задерживал их время. После этого случая я больше не разу туда не обращался, да и незачем было Потому что я считаю, что лучшая помощь только в googl'е. Вобще, я считаю, что настоящий профессионал или тот кто хочет стать им, должен сначала излазить все поисковики в поисках ответа, а потом беспокоить более опытных товарищей, потому что у них и проблемы покруче и время подороже нашего с вами.
Это было небольшое лирическое отступление, но что-то мы далеко отвлеклись от темы этого поста. Так вот внимательно просматривая /etc/sysconfig/SuSEfirewall2 я обнаружил параметр под номером 25FW_CUSTOMRULES. Здесь можно прописать путь к файлу дополнительных правил. В /etc/sysconfig/scripts/SuSEfirewall2-custom
лежит пример такого файла, вобщем он содержит функции вызываевымые перед различными событиями(hook'и) самого SuSEfirewall. Вот их список с пояснениями(прим. авт. специально перевел описания):
• fw_custom_before_antispoofing() - все что описано в этой функции будет загружено до того, как будут применены любые правила антиспуфинга. Желательно прописывать здесь правила для DROP'а ненужных broadcast пакетов и пропуска некоторых пакетов через механизм антиспуфинга.
• fw_custom_after_antispoofing() - загрузка ваших правил, после применения правил для антиспуфинга и обработки icmp-пакетов, но перед правилами для обработки IP пакетов. Здесь желательно прописывать правила для запрета доступа определенных ip-адресов или tcp/udp портов.
• fw_custom_before_port_handling() - загрузка ваших правил, после применения правил для антиспуфинга и обработки icmp-пакетов, а также после того, как весь траффик переопределен в специальные цепочки SuSEfirewall: input_XXX,forward_XXX и т.д. ,но перед правилами для обработки IP пакетов. Здесь желательно прописывать правила для запрета доступа определенных ip-адресов или tcp/udp портов.
• fw_custom_before_masq()(может также именоваться как "after_port_handling()" ) - правила, описанные здесь будут загружаться после обработки IP пакетов и TCP/UDP портов, но перед пробросом портов или маскардинга. Используйте этот хук, если вам он действительно нужен и необходим!
• fw_custom_before_denyall()(может также именоваться как "after_forwardmasq()" ) - правила, описанные здесь будут загружены после проброса портов и/или маскардинга. Используйте этот хук, для отключения логов ненужных пакетов.
 
Так вот, я фильтрую и рекомендую фильтровать все ненужные айпи адреса в hook'e fw_custom_before_antispoofing() что бы исключить возможность попадания любых пакетов в систему с ненужных айпи адресов.
Пример:
fw_custom_before_antispoofing() {
iptables -A INPUT -j DROP -s 10.49.56.211/32
iptables -A INPUT -j DROP -s 10.49.56.211/32
iptables -A INPUT -j DROP -s 10.49.48.196/32
iptables -A INPUT -j DROP -s 10.49.166.252/32
iptables -A INPUT -j DROP -s 10.49.42.2/32
}
 
Фильтрация идет по локальной сети корбины телеком от начинающих dos'еров. Надеюсь вы теперь стали еще более уверены, насколько гибкий и удобный инструмент подарили нам разработчики openSuSE, за что Спасибо Им Огромное!
 
Интернет-шлюз на базе OpenSUSE 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 и т.д.)
• следить за сообщениями о выявленных уязвимостях и своевременно устанавливать "обновления" и "заплатки"
• избегать использования ПО, источник происхождения которого вызывает сомнения
• отказаться (если это возможно) от использования роутинга в пользу прокси-сервера

PS: Статья перенесена со старого форума, под авторством Son1k 25/11/2010