Статья по базовой настройке SuSEfirewall2

06.02.2012 schkomp Linux

Сразу оговорюсь. 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=»»

Ну на этом пожалуй все. Для начальной настройки вполне сойдет.