Тут это наткнулся на интересную статью, думаю многим убудет интересно:
Создание прозрачного firewall на основе FreeBSD.
Межсетевой экран с возможностями фильтрации/ограничения пропускной способности трафика.
Иногда полезно разделить одну физическую сеть (такую, как сегмент Ethernet) на два отдельных сегмента сети без необходимости создания подсетей IP и использования маршрутизатора для соединения сегментов. Устройство, которое соединяет две сети на такой манер, называется мостом. Система FreeBSD с двумя сетевыми адаптерами может выступать в роли моста.
Мост работает на основе изучения адресов уровня MAC (адресов Ethernet) устройств на каждом из своих сетевых интерфейсах. Он перенаправляет трафик между двумя сетями, только когда адреса отправителя и получателя находятся в разных сетях.
По многим параметрам мост работает также, как коммутатор Ethernet с малым количеством портов.
Где же может применяться такой фильтрующий мост? Первое и самое очевидное - при подключении к провайдеру. Вот пример - вам выделили диапазон ip-адресов и выдали ethernet подключение к маршрутизатору провайдера, к которому вы доступа не имеете и который не выполняет абсолютно никакой фильтрации, а вам необходимо защитить свои сервера, создать DMZ... Конечно, сразу напрашивается решение - поставить програмный маршрутизатор на основе FreeBSD, выполняющий фильтрацию. Однако тут обычно и бывают сложности. Во-первых, у вас сразу уменьшится число ip-адресов на 2, т.к. маршрутизатору нужен адрес на каждый интерфейс и вам придется перекраивать выделенный блок ip-адресов, чтобы получить сеть с нормальной маской (возможно, даже теряя адреса). Во вторых, для установки маршрутизатора необходимо, чтобы провайдер прописал его на своем маршрутизаторе, чтобы тот был в курсе, куда посылать пакеты для вашего блока ip-адресов. Вот тут и придет на помощь мост с фильтрацией.
Настройка моста
1. Выбор сетевого адаптера
Для работы моста требуются по крайней мере два сетевых адаптера. К сожалению, не все сетевые адаптеры во FreeBSD поддерживают функции моста. Прочтите страницу Справочника по bridge(4) для выяснения подробностей о поддерживаемых адаптерах.
Перед тем, как продолжить, сначала установите и протестируйте два сетевых адаптера на работоспособность.
2. Конфигурация ядра.
options BRIDGE
# Включим поддержку firewall
options IPFIREWALL
# для того, чтобы добавить возможность firewall вести логи
# добавим параметр:
options IPFIREWALL_VERBOSE
# ограничим число пакетов, о которых ядро будет сообщать:
options IPFIREWALL_VERBOSE_LIMIT=10
#Если вы хотите использовать мост в качестве
# машины, ограничивающей пропускную
# способность, то добавьте в файл конфигурации
# ядра опцию
DUMMYNET
#А для создания прозрачного прокси сервера опцию
IPFIREWALL_FORWARD
# Добавим еще парочку нужных параметров
# ICMP_BANDLIM включает ограничение полосы для
# ответов icmp error
# Поскольку мы дадим мосту 1 ip-адрес,
# этот параметр в некоторых случаях
# помогает от D.O.S. атак.
options ICMP_BANDLIM
# Добавим также параметр, который заблокирует
# перезагрузку системы при нажатии Ctrl+Alt+Del
options SC_DISABLE_REBOOT
3. Включение функций моста.
Для того, чтобы запустить IPFirewall, необходимо добавить несколько параметров в /etc/rc.conf. Для начала опишем необходимые параметры, а затем приведем готовый фрагмент для вставки в rc.conf.
Прежде всего необходимо добавить параметр
firewall_enable="YES"
Параметр firewall_script="/etc/rc.firewall" укажет, какой скрипт будет запускаться для активизации правил firewall. Следующим параметром будет firewall_type. Этот параметр показывает, какой тип firewall будет использоваться из заранее приготовленных разработчиками (open, client, simple, closed) или же имя файла, из которого будут браться правила для firewall, если не подходит ни один из заранее приготовленных типов. Мы создадим файл ipfw.rules со своими собственными правилами, посему поставим
firewall_type="/etc/ipfw.rules"
Также необходим параметр firewall_quiet. Если его поставить в YES, то при загрузке будет отключен вывод на экран правил firewall. Однако для начала лучше ему дать значение NO, чтобы видеть активируемые правила при загрузке. Парметр firewall_logging установим в YES для того, чтобы велись логи. Поскольку у нас машина с двумя сетевыми картами и чтобы она вдруг не заработала как маршрутизатор поставим
gateway_enable="NO"
Итого, у нас получилась следующая вставка в rc.conf:
firewall_enable="YES"
firewall_script="/etc/rc.firewall"
firewall_type="/etc/ipfw.rules"
firewall_quiet="NO"
firewall_logging="YES"
gateway_enable="NO"
в файл /etc/sysctl.conf для включения функций моста во время работы системы. Если вы хотите, чтобы пакеты, проходящие через мост, фильтровались через ipfw(8), вы должны также туда добавить строчку
net.link.ether.bridge_ipfw=1
net.inet.ip.fw.one_pass=0
net.inet.ip.forwarding=1
net.link.ether.bridge=1
4. Настройка правил для Firewall
Создадим и отредактируем файл /etc/ipfw.rules, который мы указали в параметрах в rc.conf. Поскольку в конфиг ядра мы не добавляли параметр IPFIREWALL_DEFAULT_TO_ACCEPT, то ipfw по умолчанию не зависимо от наших настроек будет добавлять в конец правило 65535 deny ip from any to any. Поэтому мы должны разрешить все необходимые сервисы в нашем файле.
Пусть у нас есть 2 интерфейса - xl0 и xl1. Для мостов приемлимым решением (а иногда и необходимым) является разрешение любого трафика на одном из интерфейсов и фильтрация входящего и исходящего на другом. Так и поступим - разрешим любой трафик на интерфейсе xl1, а фильтровать будем входящий на xl0.
При работе моста есть еще одна особенность. Дело в том, что для корректной работы ip протокола необходимо использование протокола ARP. Если пакеты этого протокола не будут проходит через мост, то станции по разные стороны моста не смогут передавать друг другу пакеты, т.к. не будет выполняться преобразование ip-адресов в mac-адреса сетевых карт. ipfw имеет возможность ограничивать ethernet-протоколы. Для этого создается специальное правило для udp пакетов с адресом источника 0.0.0.0, а порт источника будет показывать номер ethernet-протокола. Таким образом можно заставить мост пропускать или не пропускать протоколы, отличные от IP. Для вышеупомянутого протокола arp правило будет выглядеть следующим образом:
add allow udp from 0.0.0.0 2054 to 0.0.0.0
Поскольку мы решили помимо фильтрации также использовать traffic shaper dummynet, напишем правило, ограничивающее, например, весь проходящий icmp-трафик (входящий+исходящй) на 50Кб/с:
add pipe 1 icmp from any to any
pipe 1 config bw 50Kbit/s queue 10
Заметим, что в случае написания других правил для shaper'а, включающих в себя адресаузлов, сетей - их нужно ставить в самое начало нашего файла ipfw.rules. ipfw устроен таким образом, что пакет проверяется по правилам сверху вниз и как только находится правило, которому он удовлетворяет - проверка на соответствие другим нижестоящим правилам не производится. Таким образом, если пакет будет удовлетворять правилу фильтрации - он может не дойти до правил traffic shaper'а. Однако если первыми стоят правила шейпера, то существует возможность пропустить пакет по правилам, котрые стоят ниже правил шейпера. Для этого нужно установить переменную net.inet.ip.fw.one_pass=0.
Програмируем переменные для нашей сети:
наш сервер
bridge="212.265.265.1"
наша сеть
net="212.265.265.0"
mask="255.255.255.224"
кому зарезаем пропускную способность канала:
slow_1="212.265.265.10"
slow_2="212.265.265.30"
slow_1_speed="1024Kbit/s"
slow_2_speed="2048Kbit/s"
Добавим еще парочку правил, например, разрешающих прохождение входящего dns-трафика, обращений к web-серверу и icmp-трафика через интерфейс xl0. Также не забудем разрешить любой трафик через xl1:
add 1000 allow tcp from any to any in via xl0 established
add 1200 allow tcp from any to any domain in via xl0
add 1300 allow udp from any to any domain in via xl0
add 1400 allow udp from any domain to any 1024-65535 in via xl0
add 1500 allow tcp from any to any www in via xl0
add 1600 allow icmp from any to any
add 1700 allow ip from any to any via xl1
также добавляем правила прозрачного прокси сервера который расположен на этом компьютере
add 1100 fwd 127.0.0.1,3128 tcp from $net:$mask to any 80
Устанавливаем ограничения по траффику для клиентов
pipe 10 config mask dst-ip 255.255.255.255 bw $slow_1_speed queue
pipe 11 config mask dst-ip 255.255.255.255 bw $slow_2_speed queue
add 910 pipe 10 tcp from any to $slow_1 via xl0
add 911 pipe 11 tcp from any to $slow_2 via xl0
Итого, наш итоговый файл /etc/ipfw.rules получился следующим:
add pipe 1 icmp from any to any
pipe 1 config bw 50Kbit/s queue 10
pipe 10 config mask dst-ip 255.255.255.255 bw $slow_1_speed queue
pipe 11 config mask dst-ip 255.255.255.255 bw $slow_2_speed queue
add 0900 allow udp from 0.0.0.0 2054 to 0.0.0.0
add 910 pipe 10 tcp from any to $slow_1 via xl0
add 911 pipe 11 tcp from any to $slow_2 via xl0
add 1000 allow tcp from any to any in via xl0 established
#Пока отключаем эту функцию т.к. про конфигурацию прозрацного прокси сервера будет рассказано позднее
#add 1100 fwd 127.0.0.1,3128 tcp from $net:$mask to any 80
add 1200 allow tcp from any to any domain in via xl0
add 1300 allow udp from any to any domain in via xl0
add 1400 allow udp from any domain to any 1024-65535 in via xl0
add 1500 allow tcp from any to any www in via xl0
add 1600 allow icmp from any to any
add 1700 allow ip from any to any via xl1
Установка дополнительного П.О для анализа
У нас получился полностью рабочий бридж, но ведь мы можем не только фильтровать пакеты, ограничивать скорость, но и считать трафик. Для этого нам понадабится программа IPFM которую можно поставить из портов (/usr/ports/net/ipfm) и скрипт написаный Гавриловым Анатолием для обработки вывода в веб данных IPFM.
Устанавливаем IPFM
cd /usr/ports/net/ipfm
make
make install
make clean
Теперь правим конфиг /usr/local/etc/ipfm.conf
# Имя интерфеса для анализа
DEVICE xl1
#настройка статистики
#Анализировать траффик от сети 10.1.1.0 но не к сети 10.1.0
LOG 10.1.1.0/255.255.255.0 NOT WITH 10.1.0.0/255.255.0.0
FILENAME /var/log/ipfm/daily/ipfm-%d.%m-%H.%M.%S
# Лог записывать кадый 1 час
TIME 1 hour
SORT IN
NORESOLVE
##### Вторичная конфигурация #####
NEWLOG
#log subnet 10.10.10.0 when not in relation with subnet 10.1O.0.0
LOG 10.10.10.0/255.255.255.0 NOT WITH 10.10.0.0/255.255.0.0
# do not log 10.10.10.10 when in relation with 10.10.10.20
LOG NONE 10.10.10.10 WITH 10.10.10.20
FILENAME /var/log/ipfm/weekly/ipfm-%d.%m-%H.%M.%S
# Лог записывать кадые 7 дней
TIME 7 day
SORT IN
NORESOLVE
Функция NORESOLVE нужна для того чтобы наши клиенты отображались в качестве ИП а не имён хостов.
Теперь в директории /var/log создаём директории weekly и daily.
И создаём в директории /usr/local/etc/rc.d файл ipfm.sh в котором прописываем :
#!/bin/sh
/usr/local/sbin/ipfm -c /usr/local/etc/ipfm.conf
теперь делаем chmod +x /usr/local/etc/rc.d/ipfm.sh
Запускаем его. Теперь у нас считается статистика кто сколько накачал. Лог файлы IPFM выглядят так :
HOST IN OUT TOTAL
10.1.1.110 4858300 802923 5661223
10.1.1.12 4042790 401824 4444614
10.1.1.28 3191423 1099193 4290616
...
Это не совсем удобно, потомучто такой файл создаётся каждый час. Вы представьте у нас 24 часа в дне, и примерно 30 дней в месяце. Итого получаем 24*30=720 файлов. Поэтому мы будем использовать скрипт который будет обрабатывать эти файлы и выводить сумму. Для полноценной работы нам понадобится Веб сервер Apache поставить его можно из портов, /usr/ports/www/apache13 также как и предыдущюю программу. Скачиваем скрипт из секции cкачать->WEB утилиты->Lss. Распаковываем, кладём его в cgi-bin. Файл stat.html в data. Файл usesk.txt нужно положить в /var/log/ipfm/daily/ или подправить скрипт под себя.
Формат файла usesk.txt таков:
login;password;e-mail;Ф.И.О.;Группа;Limit;IP
Вариант для распечатки
OpenNET: Виртуальная конференция (Public)
on
03-Апр-03, 12:05 (MSK)
