|
|
||
- Форум твоего направления
- *NIX
- Дистрибутивы
- FreeBSD
Статья Раздаем интернет во FreeBSD: natd + ipfw + dhcpd
| Ответить |
|
|
|
Vector
#1
|
|
|
Вес репутации:
0
Регистрация: 27.02.2009
Адрес: Москва
Сообщений: 7,302
Сказал(а) спасибо: 578
Спасибок 2,623
в 1,832 сообщениях 
|
Раздаем интернет во FreeBSD: natd + ipfw + dhcpd -
30.10.2009, 01:58
План действий:
Раздавать интернет, выдавать ip с помощью DHCP, небольшая защита с помощью ipfw NATD + IPWF firewall_enable="YES"
firewall_script="/etc/rc.myipfw"
natd_enable="YES"
natd_interface="vr0"
natd_flags=""
firewall_enable="YES" подгружаем модуль ipfw в ядро при загрузке firewall_script="/etc/rc.myipfw" правила ipfw берем из файла /etc/rc.myipfw , название любое, я сделал такое. Сами правила: #!/bin/sh
ipfw -q -f flush # чистим
# устанавливаем переменные
cmd="ipfw -q add " # для краткости
# теперь загружаем, используя краткие "макросы"
$cmd 00300 divert natd all from any to any
$cmd 00600 allow ip from any to any
natd_enable="YES" включаем natd natd_interface="vr0" указываем внешний интерфейс На данном этапе все работает, вручную задавая айпи на компьютере внутренней сети имеем на нем инет. DHCPD Я обновил порты и поставил isc-dhcp3-server. Далее cp /usr/local/etc/dhcpd.conf.sample /usr/local/etc/dhcpd.conf
option domain-name-servers 192.168.0.112;
subnet 192.168.10.0 netmask 255.255.255.0 {
range 192.168.10.10 192.168.10.20;
option routers 192.168.10.1;
}
Включаем в rc.conf dhcpd_enable="YES"
dhcpd_ifaces="rl0"
Составление правил для IPFW Как задействовать IPFW? Как известно существует два способа подключения IPFW:
Обычно ипользуются следующие опции в конфиге ядра: options IPFIREWALL
options IPFIREWALL_VERBOSE
options IPFIREWALL_VERBOSE_LIMIT=100
options IPFIREWALL_FORWARD
options IPDIVERT
options DUMMYNET
allow ip from any to any
options IPFIREWALL_DEFAULT_TO_ACCEPT
deny ip from any to any
После сборки и установки нового ядра получаем IPFW встроенный в ядро системы. Теперь о подключение модулем, тут все проще и сложнее одновременно. Подключение IPFW в качестве модуля ядра, осуществляется одной командой: kldload ipfw
Поддержку демона NATD в IPFW можно получить, загрузив аналогичной командой модуль ipdivert.ko kldload ipdivert IPFW
deny ip from any to any
firewall_enable="YES"
firewall_script="/usr/local/etc/ipfw.rules"
natd_enable="YES"
natd_interface="fxp1"
natd_flags="-same_ports"
kldload ipfw
firewall_enable="YES"
net.inet.ip.fw.enable=1
Продолжим строка: firewall_script="/usr/local/etc/ipfw.rules"
firewall_type="RULES"
natd -interface ${natd_interface} -same_ports
Замечание 1. Как все-таки подключать IPFW? Пожалуй решение такое: если FreeBSD используется в целях обучения, отладки и т.д. - проще подключать модулем, а если речь идет уже о "боевом" применении - лучше компиляция в ядро. Как IPFW работает? Общая схема  Замечание 2. IP- Пакет, попадая в фаервал IPFW, следует согласно порядку расположений его правил до первого удовлетворяющего, где над этим IP-пакетом, согласно данному правилу, совершаются какие-либо действия (пропускается, отбрасывается, возвращается обратно в фаервал и т.д.). Замечание 3. Входящие (IN) и исходящие (OUT) пакеты следует рассматривать относительно операционной системы, а не относительно сетевых интерфейсов. Замечание 4. Каждый маршрутизируемый IP-пакет попадает в фаервал как на входе в операционную систему, так и на выходе из неё. Рассмотрим, с учётом этих замечаний, следующие примеры и попытаемся в итоге понять проходят IP-пакеты по правилам IPFW и как составлять эти самые правила. Предположим: 1. Система имеет 2 сетевых интерфейса – {iif}- внутренний(fxp0) и {oif}-внешний(fxp1), псевдоинтефейc-{lo}, который мы намеренно опустим из виду. 2. {iip} – IP- адрес для {iif}, и соответственно {oip} – для {oif}. 3. {MyLan} - внутренняя сеть 4. В системе работает простейший демон NATD по трансляции внутренних адресов во внешний и наоборот. Пример №1. Как составлять правила? Имеем следующее не совсем очевидное, зато очень часто встречающееся правило: {fwcmd} add allow ip from {MyLan} to any
С учетом вышеописанных замечаний данное правило распишем в следующий набор правил: 1. {fwcmd} add allow ip from {MyLan} to any in via {iif}
2. {fwcmd} add allow ip from {MyLan} to any out via {iif}
3. {fwcmd} add allow ip from {MyLan} to any out via {oif}
4. {fwcmd} add allow ip from {MyLan} to any in via {oif}
любой xoст любой сети через внутренний интерфейс, аналогично и для правила №3, но через внешний интерфейс. Фактически эти два правила разрешают исходящие IP-пакеты от хостов внутренней сети к любым хостам любой сети. А теперь о том, что не так очевидно: правило №2, с учётом правила №1 фактически разрешает IP-пакеты между хостами локальной сети через интерфейс {iif}, что нормально, если предположить что в локальной сети хакеров нет, пользователи послушные, сами на роутер не полезут и делать там нечего плохого не будут. Однако сюрприз! Теперь правило №4 - с одной стороны оно достаточно бессмысленное. Действительно откуда снаружи взяться IP-пакетам от хостов внутренней сети? Правильно – хакеры, типичный спуфинг. Критики могут заметить, что со спуфингом умеет бороться чуть ли не каждая железяка, что демоны давно поумнели и т.д. и т.п. Тем не менее, согласитесь, такие правила боевой роутер совсем не красят, поэтому сюрприз №2. Можно уже делать первые выводы: Вывод №1. При составлении правил обязательно указывать о какой сетевом интерфейсе идет речь. Вывод №2. При составлении правил желательно указывать направление IP-пакетов. Вывод №3. При составлении правил по возможности конкретизировать сети и IP - адреса. Первые выводы сделаны, давайте попробуем разобраться как IP-пакеты бегают по правилам, которые мы напишем. Пример №2. Связка IPFW-NATD, как работает, какие нужны правила? Итак: исходные заданы, напишем правила IPFW, и прокомментируем их. #Разрешим трафик в локальной сети, конкретизировать по
# направлению не будем и так понятно:
1 {fwcmd} add allow ip from {MyLan} to {MyLan} via {iif}
#Вспомним про NATD.
2. {fwcmd} add divert natd ip from {MyLan} to any out via {oif}
3. {fwcmd} add divert natd ip from any to {oip} in via {oif}
#Роутер должен же как-то работать - изнутри мы уже все открыли,
#будем последовательны тоже сделаем и снаружи.
4. {fwcmd} add allow ip from {oip} to any out via {oif}
5. {fwcmd} add allow ip from any to {oip} in via {oif}
#Роутер у нас или нет? Давайте разрешим локальным хостам
# свободно лазить во внешнюю сеть.
#Для исходящих пакетов от хостов внутренней сети.
6. {fwcmd} add allow ip from {MyLan} to any in via {iif}
7.{fwcmd} add allow ip from {MyLan} to any out via {oif}
#Для входящих IP-пакетов к хостам внутренней сети.
8. {fwcmd} add allow ip from any to {MyLan} in via {oif}
9. {fwcmd} add allow ip from any to {MyLan} out via {iif}
#Для порядка завершим
10. {fwcmd} add deny ip from any to any
{fwcmd} add allow ip from any to any
|
|
Vector
#2
|
|
|
Вес репутации:
0
Регистрация: 27.02.2009
Адрес: Москва
Сообщений: 7,302
Сказал(а) спасибо: 578
Спасибок 2,623
в 1,832 сообщениях
|
30.10.2009, 01:59
Пусть хост внутренней сети (192.168.0.75) запрашивает почту с gmail.com (64.233.183.109:995), для нашего роутера внешний IP- 195.34.32.55.
Забудем про DNS, сразу к делу - какими видит IPFW проходящие пакеты: Правила №-№ 1-5 не подходят, а вот №6 как раз в точку: Код HTML:
TCP 192.168.0.75:1499 64.233.183.109:995 in via fxp0 Код HTML:
TCP 192.168.0.75:1499 64.233.183.109:995 out via fxp1 Код HTML:
TCP 195.34.32.55:1499 64.233.183.109:995 out via fxp1 Теперь рассмотрим как идет ответ сервера: Ответный пакет входит в файервал снаружи через внешний интерфейс fxp1: Код HTML:
TCP 64.233.183.109:995 195.34.32.55:1499 in via fxp1 Код HTML:
TCP 64.233.183.109:995 192.168.0.75:1499 in via fxp1 Код HTML:
TCP 64.233.183.109:995 192.168.0.75:1499 out via fxp0 Дайте рассмотрим ещё один случай связки IPFW-NATD - перенаправление входящего запроса на сервер внутренней сети. Предположим мы хотим открыть для доступа снаружи Web-сервер внутренней сети с IP-адресом 192.168.0.3, для чего изменим в rc.conf строку на natd_flags="-same_ports -redirect_port tcp 192.168.0.3:80 80"
Код HTML:
1. TCP 195.34.32.56:1076 195.34.32.55:80 in via fxp1 2. TCP 195.34.32.56:1076 192.168.0.3:80 in via fxp1 3. TCP 195.34.32.55:1076 192.168.0.3:80 out via fxp0 4. TCP 192.168.0.3:80 195.34.32.56:1076 in via fxp0 5. TCP 192.168.0.3:80 195.34.32.56:1076 out via fxp1 6. TСP 195.34.32.55:80 195.34.32.56:1076 out via fxp1 первая строка и вторая строка - один и тот же пакет - входящий запрос, который попадает в NATD через внешний интрефейс fxp1. NATD переписывает заголовок пакета и далее по правилам IPFW пакет попадает в операционную систему. третья строка - пакет прошедший по таблице маршрутизации операционной системы, исходящий через внутренний интерфейс fxp0. четвертая строка - ответ сервера входящий на внутренний интерфейс fxp0. пятая и шестая строки - один и тот же пакет, прошедший через NATD и ставший исходящим через внешний интерфейс fxp1. Примечание:MAN NATD - "После трансляции адреса, демон NATD, возвращает IP-пакет в фаервал IPFW к правилу со следующим номером после правила с DIVERT (не следующее правило, а правило со следующим номером)." Чтобы закончить со связкой IPFW-NATD, составим примерный список правил для конфига IPFW, обеспечивающий работоспособность данной связки : #Разрешаем все по интерфейсу обратной петли
{fwcmd} add allow ip from any to any via lo
#Разрешаем все внутри локальной сети,
#кроме того эти правила необходимы для связки IPFW-NATD
#Для защиты роутера от пользователей локальной сети перед этими правилами
#нужно вcтавить что-то запрещающее
#Если есть необходимость роутеру в широковещательных запросах
#нужно вставить что-то разрешающее
{fwcmd} add allow ip from {MyLan} to any in via {iif}
{fwcmd} add allow ip from any to {MyLan} out via {iif}
#Разрешаем входящие соединения к роутеру,
#это правило напрямую к связке IPFW-NATD отношения не имеет,
#оно необходимо для обеспечения работоспособности демонов роутера.
#Естественно правило необходимо расширить с учетом потребностей демонов.
#Внимание!!! правила расположены выше DIVERT,
# т.е в этом примере для хостов внутренней сети
#DNS сервер должен быть внутри сети
{fwcmd} add allow ip from any to {oip} 53 in via {oif}
{fwcmd} add allow ip from any 53 to {oip} in via {oif}
#NATD для исходящих соединений
{fwcmd} add divert natd ip from {MyLan} to any out via {oif}
#Внимание!!! Правило - разрешает исходящие соединения как для самого роутера,
#так и для хостов внутренней сети, IP которых транслировал NATD
{fwcmd} add allow ip from {oip} to any out via {oif}
#NATD для входящих соединений
{fwcmd} add divert natd ip from not {MyLan} to {oip} in via {oif}
#Внимание!!! Правило - разрешает входящие соединения только к хостам внутренней сети,
#IP которых транслировал NATD
{fwcmd} add allow ip from not {MyLan} to {MyLan} in via {oif}
{fwcmd} add deny ip from any to any
Что делать если требуется что-то прикрыть в интернете для хостов внутренней сети? Ответ достаточно очевиден: 1. Впереди правил для локальной сети (строки 2-3) пишем свои запреты. Ну и наоборот если требуется все запретить, разрешив только что-то: к примеру HTTP? 2. Приводим строки 2-3 к следующему виду: {fwcmd} add allow ip from {MyLan} to {MyLan} via {iif} {fwcmd} add allow tcp from {MyLan} to any http in via {iif} {fwcmd} add allow tcp from any http to {MyLan} out via {iif}
Продолжим исследования, разберем еще один частоиспользуемый случай IPFW-SQUID. Сначала без прозрачного прокси. Вернемся к первому варианту конфига IPFW и рассмотрим что происходит. Вот и подходящий кусочек лога: Код HTML:
TCP 192.168.0.112:1212 192.168.0.9:3128 in via fxp0 Код HTML:
TCP 195.34.32.55:52439 64.12.24.102:443 out via fxp1 Код HTML:
TCP 64.12.24.102:443 195.34.32.55:52439 in via fxp1 Код HTML:
TCP 192.168.0.9:3128 192.168.0.112:1212 out via fxp0 Пример несколько утрированный, однако интересен следующим: Первое - NATD не используется, а вернее так: в NATD входящий пакет от хоста 64.12.24.102:443 все равно попадет, правило №3 никто не отменял. Однако NATD об этом пакете ничего не знает, поэтому делать ничего не будет, он отправит пакет дальше путешествовать по правилам IPFW, пока последний не доберется до правила №4. Второе - сам адресат: 64.12.24.102:443 - протокол https, а хост из сети 64.12.0.0/16 AOL-MTC, т.е. ICQ. Продолжим, теперь на очереди прозрачный прокси, для него изменим правила IPFW следующим образом: добавив строку для форвардинга в итоге получим: 1. {fwcmd} add allow ip from {MyLan} to {MyLan} via {iif}
2. {fwcmd} add fwd {iip},3128 tcp from {MyLan} to not {MyLan} 80 in via {iif}
3. {fwcmd} add divert natd ip from {MyLan} to any out via {oif}
4. {fwcmd} add divert natd ip from to any to {oip} in via {oif}
5. {fwcmd} add allow ip from {oip} to any out via {oif}
6. {fwcmd} add allow ip from any to {oip} in via {oif}
7. {fwcmd} add allow ip from {MyLan} to any in via {iif}
8. {fwcmd} add allow ip from {MyLan} to any out via {oif}
9. {fwcmd} add allow ip from any to {MyLan} in via {oif}
10. {fwcmd} add allow ip from any to {MyLan} out via {iif}
11. {fwcmd} add deny ip from any to any
Код HTML:
TCP 192.168.0.100:1083 77.73.24.4:80 in via fxp0 Код HTML:
TCP 195.34.32.55:57415 77.73.24.4:80 out via fxp1 TCP 77.73.24.4:80 195.34.32.55:57415 in via fxp1 Код HTML:
TCP 77.73.24.4:80 192.168.0.100:1083 out via fxp0 Опять оговоримся: в примере рассмотрен только принцип прохождения пакета, реальный лог совсем не такой однозначный. Чтобы закончить тему связки IPFW-SQUD напишем примерные правила для IPFW: {fwcmd} add allow ip from any to any via lo
#Собственно следующие строки не только для локальной сети,
#они ещё задают варианты использование прокси для обычного достаточно
{fwcmd} add allow ip from {MyLan} to {MyLan} via {iif}
#для прозрачного
#Здесь мы попали в засаду с портами, впрочем это только начало
#{fwcmd} add fwd {iip},3128 tcp from {MyLan} to not {MyLan} 80,443 in via {iif}
#{fwcmd} add allow tcp from {MyLan} to any 80,443 in via {iif}
#{fwcmd} add allow tcp from any 80,443 to {MyLan} out via {iif}
#{fwcmd} add allow ip from {MyLan} to {MyLan} via {iif}
#Так подробно расписано специально чтобы была видна разница в правилах.
#Разрешаем входящие соединения к роутеру,
#вообще эти правила напрямую к связке IPFW-SQUID отношения не имеют,
#правда с DNS не все так однозначно.
{fwcmd} add allow ip from any to {oip} 53 in via {oif}
{fwcmd} add allow ip from any 53 to {oip} in via {oif}
#Правила для SQUID, тут чтобы опять не попасть в засаду с портами,
#извернемся следующим образом
{fwcmd} add deny tcp from any to {oip} in via {oif} tcpflags syn,!ack
{fwcmd} add allow tcp from any to {oip} in via {oif}
#Завершим традиционно
{fwcmd} add allow ip from {oip} to any out via {oif}
{fwcmd} add deny ip from any to any
#!/bin/sh -
fwcmd=/sbin/ipfw
# Внешний интерфейс
oif=xxx
oip=xxx.xxx.xxx.xxx
# Внутренний интерфейс
iif=xxx
iip=xxx.xxx.xxx.xxx
MyLan=xxx.xxx.xxx.0/24
# Хосты сети, которым разрешим свободно ходить в инет через роутер
pdc=xxx.xxx.xxx.xxx,xxx.xxx.xxx.xxx
${fwcmd} flush -f
#Стандартное средство защиты от спуффинга :-)
${fwcmd} add deny ip from any to any not verrevpath in
# Убьем фрагменты
${fwcmd} add deny ip from any to any frag
${fwcmd} add allow ip from any to any via lo
${fwcmd} add denny ip from any to 127.0.0.0/8
${fwcmd} add denny ip from 127.0.0.0/8 to any
${fwcmd} add allow ip from ${MyLan} to ${MyLan} via {iif}
${fwcmd} add allow ip from ${pdc} to any in via ${iif}
${fwcmd} add allow ip from any to ${pdc} out via ${iif}
${fwcmd} add divert natd ip from ${MyLan} to any out via ${oif}
${fwcmd} add allow ip from ${oip} to any out via ${oif}
${fwcmd} add divert natd ip from any to ${oip} in via {oif}
${fwcmd} add allow ip from any to ${MyLan} in via {oif}
#Правила для демонов перенесли ниже потому что они
# перекрывают входящие пакеты для NATD
#Следующие два правила равносильны одному
#${fwcmd} add allow tcp from any to ${oip} in via ${oif} established
${fwcmd} add deny tcp from any to ${oip} in via ${oif} tcpflags syn,!ack
${fwcmd} add allow tcp from any to ${oip} in via ${oif}
${fwcmd} add allow udp from any to ${oip} 53 in via ${oif}
${fwcmd} add allow udp from any 53 to ${oip} in via ${oif}
${fwcmd} add allow icmp from any to ${oip} in via ${oif} icmptype 0,3,4,8,11,12
${fwcmd} add deny log ip from any to any
Очень хочется думать, что статья поможет вам в создании безопасных, а главное осознанных правил IPFW, спасибо всем кто сумел сие прочитать, за сим откланиваюсь. -cat- P.S. Автор сознательно не использовал конструкции setup-established и check-state keep-state. setup-established запутали бы процесс понимания правил, keep-state же напустил бы туману еще больше. P.P.S. В процессе сочинения сего использовались логи реально работающего роутера, а также различные виртуальные машины, логи собраны при помощи строки {fwcmd} add count log all from any to any. Совпадения IP - реальных случайны, случайных - не реальны. |
| Ответить |
| Опции темы | |
| Опции просмотра | |
|
|
Похожие темы
|
||||
| Тема | Автор | Раздел | Ответов | Последнее сообщение |
| Обсуждаем Лучший интернет браузер. | Vector | Софт: Интернет и сеть | 288 | 10.06.2016 23:09 |
| Обсуждаем Играем в NFS Underground 2 по сети Интернет | Бродяга | Симуляторы, гонки | 18 | 20.12.2012 02:08 |
| Инфо Что такое FreeBSD? | Vector | FreeBSD | 4 | 06.05.2010 12:47 |
| FAQ Установка FreeBSD 7 | Vector | FreeBSD | 2 | 01.05.2010 03:55 |
| Инфо О битах, байтах и скорости интернет соединения | Vector | Разное | 0 | 19.10.2009 18:09 |