= Безопасность =
"FIREWALL": СТЕНА ОГНЯ, КОТОРАЯ ЗАЩИЩАЕТ
Константин Николаенко aka Steel Human lightnet@obninsk.ru
окончание: начало в #73, #74, #76, #77, #82
Радуйтесь юзвери: это последняя статья из серии о "Firewall":) Правда, заключительные статьи предназначались вовсе не вам, а админам... Ради вашей же безопасности:)
Группы правил и логирование
IPF позволяет группировать правила, что становится удобным при наличии большого количества правил фильтрации. Это в свою очередь ускоряет работу фильтра, т.к. уменьшается число проверок. В добавок, можно записывать в лог-файл сведения о конкретно отработавшем правиле.
Правила целесообразно группировать по определенному свойству: интерфейсам, направлениям и т.п. Например, в примере #82 "Контроль интерфейсов", если пакет поступает извне в локальную сеть не от 192.110.5.1, то прежде чем пропустить пакет, IPF просмотрит все правила и только потом, дойдя до последней строки, примет решение о том, что пакет нужно пропустить (pass out quick on ed3 all). Чтобы избежать такого нерационального использования правил фильтрации, изменим правила следующим образом.
1: pass in on ed3 all head 1
2: block in log quick on ed3 from any to 192.110.5.1 group 1
3: block in log quick on ed3 from any to 211.112.95.2 group 1
4: pass in quick on ed3 all group 1
5: block out quick on ed3 from 192.110.5.1 to any
6: pass out quick on ed3 all
head – объявляет заголовок группы, т.е. по этому признаку будут объединятся правила опцией group (в нашем случае объединены правила, фильтрующие входящие пакеты интерфейса ed3). Если пакет выходящий, то IPF, проверив первое правило и убедившись, что группа не подходит (она для входящих пакетов), пропустит группу и сразу перейдет к рассмотрению правила 5.
Стоит заметить, что опция log в правилах 2 и 3 указывает IPF на то, что необходимо писать в лог-файл информацию о всех пакетах, отфильтрованных этими правилами.
Флаги
При установке соединения по протоколу tcp в первом пакете (в пакете запроса) содержится так называемый флаг SYN. Ответный пакет на запрос соединения содержит так называемый флаг ACKN SYN. IPF позволяет отлавливать эту информацию и тем самым фиксировать запросы на установление соединения. К примеру, блокировать все запросы на установление соединения извне с компьютерами в локальной сети можно так:
block out log quick on ed3 proto tcp from any to any flags S/SA
keep state и ответ на заблокированные пакеты
Если администратор маршрутизатора хочет "впускать" в локальную сеть только ответные пакеты на запросы пользователей из локальной сети, а остальные входящие пакеты блокировать, то необходимо использовать опцию keep state. Причем, также необходимо посылать "ответы" на заблокированные пакеты. Это необходимо делать потому, что иначе пользователь компьютера (в худшем случае - злоумышленник), находящегося вне локальной сети и посылающего пакеты в нашу локальную сеть, заметит присутствие firewall на маршрутизаторе (т.к. firewall не должен выдавать своего присутствия).
В частности протокол tcp имеет RST (Reset) пакет, который приходит в ответ от сервера, если запрашиваемый сервис на данном сервере не поддерживается.
pass out quick on ed3 proto tcp from any to any keep state
block return-rst in log all
В этом случае, благодаря keep state, все выходящие из локальной сети пакеты записываются в динамическую таблицу соответствия адресов, и когда приходит пакет извне, то происходит поиск по таблице (по адресу назначения и источника). Если соответствия не было, то пакет блокируется.
На этом краткое ознакомление с использованием IPF можно закончить. Берегите себя и свои компУтеры:) Пример настройки firewall для веб-сервера находится на сайте газеты.
ПРАКТИКА
Ниже следует пример применения IPF на практике: настроить firewall на одном из рабочих серверов (195.112.90.1), где установлена ОС FreeBSD и имеется IPF.
Задание
Имеется сервер c одним внешним интерфейсом (rl0), поддерживающий следующие сервисы: WWW (TCP/IP, port 80), MySQL (TCP/IP, port 3306), SSH (TCP/IP, port 22), GATE KEEPER (UDP, port 3000).
Настроить firewall следующим образом:
* доступ к WWW ограничен определенными адресами и все коннекты логируются;
* доступ к MySQL ограничен определенными адресами и все коннекты логируются;
* доступ по SSH открыт с любого адреса и коннекты логируются;
* доступ к GATE KEEPER открыт определенным адресам, без логирования;
* все остальные входящие пакеты блокировать и писать в лог;
* логировать исходящие запросы на установку соединения.
Выполнение задания
Рекомендую осуществлять доступ к серверу при помощи клиента SecureCRT v.3.2 по протоколу ssh2. (скачать можно с ftp://shareware.maxnet.ru/) После аутентификации и входа в систему как администратор (root) осуществляем настройкк IPFilter и мониторинг сетевого трафика, используя установленное на сервере ПО.
Для решения был составлен такой конфигурационный файл
#---------------------- ipf.cfg -------------------------------
#------ разрешить и логировать SSH-соединения
1: pass in log quick on rl0 proto tcp from any to 195.112.90.1 port = 22 flags S/SA
2: pass out quick on rl0 proto tcp from 195.112.90.1 port = 22 to any
#------ разрешить WWW-доступ
3: pass in on rl0 from any to any port = 80 head 1
4: pass in log quick on rl0 from 195.112.0.0/24 to any flags S/SA group 1
#----- разрешить MySQL
5: pass in on rl0 from any to any port = 3306 head 2
6: pass in log quick on rl0 from 195.112.97.0/24 to any flags S/SA group 2
#----- разрешить GATE KEEPER
7: pass in quick on rl0 proto udp from 195.112.97.0/24 to any port = 3000
#---- запретить все остальные запросы на соединение с сервером
8: block in log quick on rl0 all flags S/A
#----- выпускать выходящие пакеты
9: pass out log quick on rl0 all
Примечение:
В реальном конфигурационном файле номера строк должны отсутствовать – строки пронумерованы в листинге только для удобства восприятия и сопровождения комментариями
Прокомментирую правила фильтрации, требуемые для реализации задачи.
1: пропускает и записывает в лог все запросы на SSH-соединение с сервером;
2: выпускаем с сервера все пакеты SSH-протокола;
3: заголовок группы #1 для входящих WWW-пакетов;
4: член группы #1- пропускает c определенных адресов (195.112.97.0/24) и пишет в лог все запросы на WWW-соединение с сервером;
5: заголовок группы #2 для входящих MySQL-пакетов;
6: член группы #2- пропускает c определенных адресов (195.112.97.0/24) и пишет в лог все запросы на MySQL-соединение с сервером;
7: пропускает все входящие пакеты для GATE KEEPER;
8: запрещаем все остальные запросы на соединения с сервером;
9: разрешаем все выходящие пакеты.
Таким образом, легко заметить, что все входящие пакеты, не удовлетворяющие правилам указанным выше правила #8, блокируются, что и требовалось в задании. Это можно проверить и отследить (что и было осуществлено при практической реализации), запустив утилиты мониторинга трафика сети и лог-записей.
Примечание 1 (команды IPF):
ipf –f ipf.cfg - загрузить конфигурационный файл (правила действуют сразу после загрузки)
ipfstat -io - показать текущие правила фильтрации
ipf –rf ipf.cfg - выгрузить конфигурационный файл
ipf –Fa - выгрузить все правила фильтрации
ipmon –o I - посмотреть и очистить лог (для мониторинга трафика)
ifconfig –au - показать все активные интерфейсы
Примечание 2 (мониторинг трафика):
tcpdump –i <interface> host <ip_addr>
<interface> - тип интерфейса (rl0),
<ip_addr> - IP-адрес сервера (119.112.90.1)
|
