Подробная настройка unbound в freebsd 10.3. Получение настроек сети по DHCP

В этой статье мы рассмотрим сетевые интерфейсы в FreeBSD 11.1 , покажем настройку сети через файл конфигурации /etc/rc.conf , а именно назначение статических настроек и получение их по DHCP. Пропишем адреса DNS -серверов, настроем hosts и рассмотрим указание временных настроек сети .

Просмотр сетевых интерфейсов.

Для начала проясним: Есть два состояния сетевой карты UP (задействована) и DOWN (не задействована).

Первым делом стоит посмотреть наши сетевые интерфейсы, смотреть будем командой ifconfig .(Рис.1) Вывод команды показывает все интерфейсы UP и DOWN.

Ifconfig

ifconfig -a покажет вам тоже самое.

Ifconfig -a

Вот тут есть некоторые отличия от ifconfig в Ubuntu server .(в Ubuntu server "ifconfig" показывает только интерфейсы UP , "ifconfig -a" показывает все интерфейсы и UP и DOWN )

Рис.1 - Результат ввода команды ifconfig.

И так что же мы видим:

em0 - наша сетевая карта, с IP адресом 192.168.3.11 .
em1 - вторая сетевая карта, не настроенная.
lo - локальная петля, она у всех присутствует по умолчанию.

Для того чтобы посмотреть интерфейсы только UP , используется команда ifconfig -u (Рис.2):

Ifconfig -u

а для просмотра интерфейсов только DOWN , используется команда ifconfig -d (Рис.3):

Ifconfig -d
Рис.2 - Результат ввода команды ifconfig -u.
Рис.3 - Результат ввода команды ifconfig -d.

В дальнейшем я буду показывать примеры настройки на интерфейсе "em0" .

Для включения интерфейса используется команда ifconfig "НАЗВАНИЕ-ИНТЕРФЕЙСА " up.

Ifconfig em0 up

Для выключения интерфейса используется команда ifconfig "НАЗВАНИЕ-ИНТЕРФЕЙСА " down.

Ifconfig em0 down

"Поиграйтесь" с интерфейсом, если вы конечно же не подключены по ssh , и оставьте его в состоянии UP .

Настройка сети через файл конфигурации.

Для настройки статического или динамического IP адреса нам надо отредактировать файл конфигурации сетевых интерфейсов - /etc/rc.conf мы будем редактировать его с помощью текстового редактора vi .(Рис.4) Сразу скажу, для того чтобы редактировать в vi нужно нажать букву "i" , а чтобы сохранить и закрыть документ надо нажать "Esc" ввести ":wq!" и нажать "Enter" .

Рис.4 - vi /etc/rc.conf.

Получение настроек сети по DHCP.

Чтобы назначить получение настроек по DHCP, нужно вписать(или изменить существующую) строчку в файл /etc/rc.conf .(Рис.5)

ifconfig_ НАЗВАНИЕ-ИНТЕРФЕЙСА ="DHCP"

Ifconfig_em0="DHCP"
Рис.5 - Получение сетевых настроек по DHCP.

Перезапускаем сетевую службу netif .(Рис.6)

/etc/rc.d/netif restart Рис.6 - Перезапуск сетевой службы FreeBSD.

Смотрим активные сетевые интерфейсы, видим, полученный по DHCP, IP адрес интерфейса em0 - 192.168.3.6 (Рис.7)

Ifconfig -u

Ping 8.8.8.8
Рис.7 - Проверка активных интерфейсов и доступа к сети.

Пинги идут. Всё отлично!

Указание настроек сети вручную.

Чтобы назначить статичный адрес для нашей Freebsd нужно в файл /etc/rc.conf вписать две строки(Рис.8)

ifconfig_ НАЗВАНИЕ-ИНТЕРФЕЙСА ="inet IP-АДРЕС-FREEBSD netmask МАСКА-СЕТИ "

defaultrouter=" IP-АДРЕС-ШЛЮЗА "

Ifconfig_em0="inet 192.168.3.11 netmask 255.255.255.0" defaultrouter="192.168.3.1"
Рис.8 - Статичные настройки сетевого интерфейса.

Перезапускаем сетевую службу.

/etc/rc.d/netif restart

Проверяем активные интерфейсы

Ifconfig -u

Проверяем выход в интернет пингуем гугловские восьмёрки.

Ping 8.8.8.8

Настройка DNS.

IP адреса DNS серверов хранятся в файле /etc/resolv.conf (Рис.9)

Открываем resolv.conf в редакторе vi .

Vi /etc/resolv.conf

Вписываем IP адрес DNS сервера. (Можно указать сколько угодно адресов.)

Nameserver 192.168.3.1 nameserver 8.8.8.8 nameserver 8.8.4.4

Если у вас нет файла resolv.conf то создайте его в каталоге /etc

Touch /etc/resolv.conf
Рис.9 - Содержимое файла resolv.conf.

Файл /etc/hosts.

Файл /etc/hosts содержит таблицы сопоставления DNS имен с IP адресами. В первую очередь ваш сервер будет обращаться к файлу hosts , а потом уже к DNS-серверу.

Лично для себя я отметил полезным внести в hosts запись этого freebsd (IP адрес локальной сети - имя сервера). Теперь мы можем во всех конфигурационных файлах указывать DNS имя, а не IP адрес, а в случае необходимости за кротчайшее время изменить свой IP адрес поправив hosts и настройки интерфейса в /etc/rc.conf .

Это просто для примера вам этого делать не обязательно .

Приступаю к редактированию(Рис.10):

Vi /etc/hosts

Вписываю:

192.168.3.11 freebsd.itdeer.loc Рис.10 - Содержимое файла hosts.

Проверю попинговав имена из hosts .(Рис.11)

Ping localhost ping freebsd.itdeer.loc
Рис.11 - Пингуем имена из hosts.

Временное назначение ip адреса.

Честно говоря я не знаю для чего может пригодиться временное назначение сетевых настроек. Разве что допустим у вас какой-нибудь сервер который предназначен только для вашей локальной сети и вы вдруг решили быстренько обновить ПО через интернет на этом сервере, чтобы не ходить к шлюзу не раздавать интернет на нужный IP адрес итд. Вы можете обойтись парой команд.

Например, мы знаем что на 192.168.3.109 точно есть доступ в интернет, назначаем этот IP адрес нашему интерфейсу, так же нужно указать маску сети(Рис.12):

Ifconfig em0 192.168.3.109 netmask 255.255.255.0

или командой с короткой записью маски сети.

Ifconfig em0 192.168.3.109/24
Рис.12 - Указание временных настроек для сетевого интерфейса em0.

Интернет может не появиться, так как не указан шлюз по умолчанию. Прописываем его и пингуем гугловкие восьмёрки.(Рис.13)

Route add default 192.168.3.1 ping 8.8.8.8
Рис.13 - Указываем шлюз по умолчанию. Проверяем ping.

Правильно ли мы прописали наш шлюз по умолчанию можно посмотреть в таблице маршрутизации. Она выводится с помощью команды "netstat -rn" , Шлюз по умолчанию будет обозначен флагом UG .(Рис.14)

Netstat -rn
Рис.14 - Вывод таблицы маршрутизации.

Если вы где-то ошиблись в написании или у вас указан другой шлюз, то можно удалить шлюз по умолчанию .

Route del default

На этом временная настройка закончена, помните что после перезагрузки сервера или отдельно службы networking , все временные настройки исчезнут.

Добавляем маршрут в сеть 192.168.0.0/16 (Маска 255.255.0.0) через основной шлюз(gateway) 192.168.3.1/24

Route add 192.168.0.0/16 192.168.3.1

Вариант добавления маршрута с указанием полной маски.

Route add -net 192.168.0.0 -netmask 255.255.0.0 192.168.3.1

Переименовываем интерфейс em0 в wan0.

Для удобства некоторые админы переименовывают интерфейсы, чтобы сразу видеть для чего предназначен интерфейс. Допустим у нас шлюз с двумя сетевыми интерфейсами em0 (интернет) и em1 (локальная сеть) и работать с такими названиями неудобно, так как имея большое количество интерфейсов можно запутаться. Гораздо удобнее работать с интерфейсами wan0 и lan1 .

Мы покажем пример переименования интерфейса em0 в wan0 в файле /etc/rc.conf .(Рис.15)

Ifconfig_em0="inet 192.168.3.11 netmask 255.255.255.0"

Заменяем двумя строками:

Ifconfig_em0 _name="wan0 " ifconfig_wan0 ="inet 192.168.3.11 netmask 255.255.255.0"
Рис.15 - Переименовываем интерфейсы в файле /etc/rc.conf.

Не забываем перезапустить сетевую службу:

/etc/rc.d/netif restart

Проверю, введу команду ifconfig -u . Видим наш wan0 с нужным IP адресом .(Рис.16)

Ifconfig -u
Рис.16 - Проверяем новое название интерфейса. ifconfig -u.

// $FreeBSD: src/etc/namedb/named.conf,v 1.26.2.2.4.1 2009/04/15 03:14:26 kensmith Exp $
// Refer to the named.conf(5) and named(8) man pages, and the documentation
// in /usr/share/doc/bind9 for more details.
// If you are going to set up an authoritative server, make sure you
// understand the hairy details of how DNS works. Even with
// simple mistakes, you can break connectivity for affected parties,
// or cause huge amounts of useless Internet traffic.

key "rndc-key" {
algorithm hmac-md5;
secret "BYSzvbwt6grksw16bMIfrw==";
};

controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndc-key"; };
};

acl "trusted"
{
192.168.0.0/24;
127.0.0.1;
195.24.128.164;
192.168.200.20;
85.119.72.2;
};

options {
// Relative to the chroot directory, if any
directory "/etc/namedb";
pid-file "/var/run/named/pid";
dump-file "/var/dump/named_dump.db";
statistics-file "/var/stats/named.stats";

Allow-transfer { trusted; }; allow-query { any; }; allow-recursion { any; };

// If named is being used only as a local resolver, this is a safe default.
// For named to be accessible to the network, comment this option, specify
// the proper IP address, or delete this option.
listen-on { 127.0.0.1; 192.168.200.10; };

// If you have IPv6 enabled on this system, uncomment this option for
// use as a local resolver. To give access to the network, specify
// an IPv6 address, or the keyword "any".
// listen-on-v6 { ::1; };

// These zones are already covered by the empty zones listed below.
// If you remove the related empty zones below, comment these lines out.
disable-empty-zone "255.255.255.255.IN-ADDR.ARPA";
disable-empty-zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
disable-empty-zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";

// In addition to the "forwarders" clause, you can force your name
// server to never initiate queries of its own, but always ask its
// forwarders only, by enabling the following line:
// forward only;

// If you"ve got a DNS server around at your upstream provider, enter
// its IP address here, and enable the line below. This will make you
// benefit from its cache, thus reduce overall DNS traffic in the Internet.
/*
forwarders {
127.0.0.1;
};
};

zone "." { type hint; file "named.root"; };

zone "localhost" { type master; file "master/localhost-forward.db"; };

zone "127.in-addr.arpa" { type master; file "master/localhost-reverse.db"; };

zone "255.in-addr.arpa" { type master; file "master/empty.db"; };

// RFC 1912-style zone for IPv6 localhost address
zone "0.ip6.arpa" { type master; file "master/localhost-reverse.db"; };

// "This" Network (RFCs 1912 and 3330)
zone "0.in-addr.arpa" { type master; file "master/empty.db"; };

// Private Use Networks (RFC 1918)
zone "10.in-addr.arpa" { type master; file "master/empty.db"; };
zone "16.172.in-addr.arpa" { type master; file "master/empty.db"; };
zone "17.172.in-addr.arpa" { type master; file "master/empty.db"; };
zone "18.172.in-addr.arpa" { type master; file "master/empty.db"; };
zone "19.172.in-addr.arpa" { type master; file "master/empty.db"; };
zone "20.172.in-addr.arpa" { type master; file "master/empty.db"; };
zone "21.172.in-addr.arpa" { type master; file "master/empty.db"; };
zone "22.172.in-addr.arpa" { type master; file "master/empty.db"; };
zone "23.172.in-addr.arpa" { type master; file "master/empty.db"; };
zone "24.172.in-addr.arpa" { type master; file "master/empty.db"; };
zone "25.172.in-addr.arpa" { type master; file "master/empty.db"; };
zone "26.172.in-addr.arpa" { type master; file "master/empty.db"; };
zone "27.172.in-addr.arpa" { type master; file "master/empty.db"; };
zone "28.172.in-addr.arpa" { type master; file "master/empty.db"; };
zone "29.172.in-addr.arpa" { type master; file "master/empty.db"; };
zone "30.172.in-addr.arpa" { type master; file "master/empty.db"; };
zone "31.172.in-addr.arpa" { type master; file "master/empty.db"; };
zone "168.192.in-addr.arpa" { type master; file "master/empty.db"; };

// Link-local/APIPA (RFCs 3330 and 3927)
zone "254.169.in-addr.arpa" { type master; file "master/empty.db"; };

// TEST-NET for Documentation (RFC 3330)
zone "2.0.192.in-addr.arpa" { type master; file "master/empty.db"; };

// Router Benchmark Testing (RFC 3330)
zone "18.198.in-addr.arpa" { type master; file "master/empty.db"; };
zone "19.198.in-addr.arpa" { type master; file "master/empty.db"; };

// IANA Reserved - Old Class E Space
zone "240.in-addr.arpa" { type master; file "master/empty.db"; };
zone "241.in-addr.arpa" { type master; file "master/empty.db"; };
zone "242.in-addr.arpa" { type master; file "master/empty.db"; };
zone "243.in-addr.arpa" { type master; file "master/empty.db"; };
zone "244.in-addr.arpa" { type master; file "master/empty.db"; };
zone "245.in-addr.arpa" { type master; file "master/empty.db"; };
zone "246.in-addr.arpa" { type master; file "master/empty.db"; };
zone "247.in-addr.arpa" { type master; file "master/empty.db"; };
zone "248.in-addr.arpa" { type master; file "master/empty.db"; };
zone "249.in-addr.arpa" { type master; file "master/empty.db"; };
zone "250.in-addr.arpa" { type master; file "master/empty.db"; };
zone "251.in-addr.arpa" { type master; file "master/empty.db"; };
zone "252.in-addr.arpa" { type master; file "master/empty.db"; };
zone "253.in-addr.arpa" { type master; file "master/empty.db"; };
zone "254.in-addr.arpa" { type master; file "master/empty.db"; };

// IPv6 Unassigned Addresses (RFC 4291)
zone "1.ip6.arpa" { type master; file "master/empty.db"; };
zone "3.ip6.arpa" { type master; file "master/empty.db"; };
zone "4.ip6.arpa" { type master; file "master/empty.db"; };
zone "5.ip6.arpa" { type master; file "master/empty.db"; };
zone "6.ip6.arpa" { type master; file "master/empty.db"; };
zone "7.ip6.arpa" { type master; file "master/empty.db"; };
zone "8.ip6.arpa" { type master; file "master/empty.db"; };
zone "9.ip6.arpa" { type master; file "master/empty.db"; };
zone "a.ip6.arpa" { type master; file "master/empty.db"; };
zone "b.ip6.arpa" { type master; file "master/empty.db"; };
zone "c.ip6.arpa" { type master; file "master/empty.db"; };
zone "d.ip6.arpa" { type master; file "master/empty.db"; };
zone "e.ip6.arpa" { type master; file "master/empty.db"; };
zone "0.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "1.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "2.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "3.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "4.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "5.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "6.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "7.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "8.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "9.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "a.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "b.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "0.e.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "1.e.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "2.e.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "3.e.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "4.e.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "5.e.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "6.e.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "7.e.f.ip6.arpa" { type master; file "master/empty.db"; };

// IPv6 ULA (RFC 4193)
zone "c.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "d.f.ip6.arpa" { type master; file "master/empty.db"; };

// IPv6 Link Local (RFC 4291)
zone "8.e.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "9.e.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "a.e.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "b.e.f.ip6.arpa" { type master; file "master/empty.db"; };

// IPv6 Deprecated Site-Local Addresses (RFC 3879)
zone "c.e.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "d.e.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "e.e.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "f.e.f.ip6.arpa" { type master; file "master/empty.db"; };

// IP6.INT is Deprecated (RFC 4159)
zone "ip6.int" { type master; file "master/empty.db"; };

/* An example dynamic zone
key "exampleorgkey" {
algorithm hmac-md5;
secret "sf87HJqjkqh8ac87a02lla==";
};
zone "example.org" {
type master;
allow-update {
key "exampleorgkey";
};
file "dynamic/example.org";
};
*/

/* Example of a slave reverse zone
zone "1.168.192.in-addr.arpa" {
type slave;
file "slave/1.168.192.in-addr.arpa";
masters {
192.168.1.1;
};
};

В данной публикации я хочу раскрыть настройку DNS сервера на машине под управлением операционной системы FreeBSD, с помощью которого можно было бы осуществлять поддержку несколько (в теории, неограниченного) количества доменных зон: первичных (primary) , вторичных (secondary) , а также обратных или реверсивных (reverse) . Но для начала изложу немного теории, для пояснения того, для чего нужны, какие бывают и чем отличаются между собой эти самые доменные зоны.

Первичная, или, как еще ее называют, Primary DNS зона представляет собой набор записей доменного имени, а также субимен, которые прописаны администратором этой зоны. Первичная DNS зона доменного имени является авторитативной или авторитетной для вторичной. Тоесть содержит в себе самую актуальную информацию о зоне и делится с нею со всеми вторичными зонами. Первичную зону поддерживает обычно первичный (primary) DNS сервер данной зоны. Администратор этого сервера отвечает за прописание записей зоны в конфигурационных файлах DNS сервера.

Вторичная (secondary) DNS зона является дублирующей и подчиненной первичной зоне. Она необходима для того, чтобы поддерживать и распространять записи для доменного имени, в том случае, если по каким-либо причинам первичный DNS сервер зоны станет недоступен в сети Интернет. Сервер, на котором прописана вторичная DNS зона для какого-либо доменного имени называют вторичным или альтернативным или secondary DNS сервером зоны. Вторичных DNS серверов для зоны может быть неограниченное количество. Единственное требование: все они должны быть настроены на получение информации об этой зоне с первичного DNS сервера. Соответственно, первичный DNS должен быть настроен так, чтобы отдавать данную информацию всем вторичным DNS серверам зоны. Обычно для поддержки доменных зон используется один DNS сервер и один-два – вторичных. В редких случаях возможна схема, когда для поддержки зоны использую два первичных DNS сервера, при этом настраивая их таким образом, чтобы информация на них всегда была синхронизирована.

Первичный и вторичные DNS для зоны должны находиться в разных сетях (автономных системах). И чем дальше они будут друг от друга в географическом отношении, тем лучше. Редко, но все же бывают в сети Интернет катаклизмы, при которых становятся “отрезанными от мира” целые страны. В этом случае, прописав зону на первичном DNS сервере в Украине, а в качестве вторичного использовав DNS в США можно не волноваться, что в случае проблем с магистральными каналами доменная зона “умрет”.

Реверсная зона используется для указания так называемых обратных DNS записей. Применяются они для указания соответствия IP адресов определенным именам. Сложно для понимания? Приведу пример.

Имеется IP адрес 213.180.204.8. Это IP адрес сервера, на котором работает всем известный http://ya.ru/ При выполнении поиска соответствия имени ya.ru IP адресу машины к которой “привязано” данное имя, можно выполнить команду:

$ host ya.ru ya.ru has address 213.180.204.8 ...

или в Windows

C:>nslookup ya.ru ... Name: ya.ru Address: 213.180.204.8

Имеем сопоставление имени IP адресу, или “прямое преобразование имени в IP адрес” (с использованием A записи). Однако, со временем в сети Интернет назрела необходимость сопоставления также IP адреса имени (пожалуй, это произошло в пылу борьбы с нарастающими объемами спам-трафика). И тогда придумали, так называемую “IN-ADDR.ARPA” зону, к которой были привязаны все адреса в сети Интернет, перевернутые наоборот. Как это выглядит?

$ host 213.180.204.8 8.204.180.213.in-addr.arpa domain name pointer ya.ru.

или в Windows

C:>nslookup -q=PTR 8.204.180.213.in-addr.arpa ... 8.204.180.213.in-addr.arpa name = ya.ru ...

Со всеми IP адресами в сети Интернет можно выполнить преобразование в вид XXX.XXX.XXX.XXX.in-addr.arpa Для этого нужно всего лишь написать сам адрес “задом-наперед” и дописать в конце “.in-addr.arpa”. Так вот, зона, прописанная для обратного преобразования IP адреса называется реверсивной или обратной или reverse zone. Как видим из последнего примера, для 8.204.180.213.in-addr.arpa прописано имя ya.ru

С давних времен так повелось, что программы для работы в качестве основных сетевых служб включены по-умолчанию в код операционной системы FreeBSD. Служба DNS не исключение. В FreeBSD роль DNS сервера выполняет программа bind (или named). Со временем было написано масса различного программного обеспечения, которое запросто может заменить bind, однако, поскольку bind является “родным” для FreeBSD его и будем использовать. Даже несмотря на количество критических уязвимостей, которые были обнаружены в bind за всю историю его существования, он остается одним из самых популярных серверов DNS в сети Интернет. К слову сказать, самую последнюю, не критичную ошибку в bind разработчики FreeBSD исправили накануне выхода релиза системы 6.3

Итак, работаем с операционной системой FreeBSD 6.3 RELEASE. Последняя версия bind на сегодняшний день:

# named -version BIND 9.3.4-P1

Все конфигурационные файлы нашего DNS располагаются в каталоге /etc/namedb/ который является ссылкой на каталог /var/named/etc/namedb Каталог /var/named/ является chroot окружением, в котором происходит запуск bind. В данном каталоге могут располагаться такие файлы:

# ls /etc/namedb/ dump -> /var/named/var/dump master/ named.conf named.root reverse/ rndc.key slave/ stats -> /var/named/var/stats zones.master zones.slave zones.reverse

named.conf – основной конфигурационный файл bind
zones.master, zones.slave, zones.reverse – конфигурационные файлы в которых прописаны поддерживаемые DNS зоны
slave/, master/, reverse/ – каталоги, в которых располагают конфигурационные файлы DNS зон
named.root – системный конфигурационный файл, содержащий информацию о всех корневых DNS серверах сети Интернет
rndc.key – файл ключом, который необходим для управления работой bind посредством утилиты rndc

От нашего будущего DNS сервера требуется:

Раздавать актуальную информацию о нашей зоне zone1.com, тоесть быть для нее первичным DNS.
Осуществлять поддержку зоны friends.com и быть для нее вторичным DNS.
Поскольку в локальной сети имеем энное количество машин, требуется прописать для каждой машины обратную DNS запись. Это нам нужно для того, чтобы в логи, например, Apache (который будет запущен на этом же сервере), записывались уже не IP адреса, а имена компьютеров нашей локальной сети.
Выполнять рекурсивный поиск в системе DNS для зон (имен), которых нет в настоящий момент в кеше и которые не прописаны на нашем DNS сервере.

Начнем с правки конфигурационного файла /etc/namedb/named.conf . Между прочим, man named.conf – отличное пособие для конфигурирования bind.

Рабочий пример, написанный по этому мануалу приведен ниже. Строки начинающиеся с // являются комментариями.

////////////////////////////////////// // Bind configuration file by Daemony ////////////////////////////////////// // 1. Глобальные настройки // // Создадим список доступа. Назовем // его IN_NET. Ниже пригодится. acl "IN_NET" { 127.0.0.1; 172.17.17.0/24; }; // // Далее следуют основные опции сервера options { // - имя хоста, в принципе оно и не нужно hostname "ns.mydns.net"; // - директория с конфигурационными файлами directory "/etc/namedb"; // БУДЬТЕ ВНИМАТЕЛЬНЫ! Дальше пути к файлам и каталогам // указываются в chroot"овом окружении /var/named // - где будет располагаться pid файл демона pid-file "/var/run/named/pid"; // - здесь мы можем (хотя и необязательно) указать файл // в который свалится кеш DNS после выполнения команды // rndc dumbdb dump-file "/var/dump/named_dump.db"; // - а в этот файл (тоже необязательно) свалится // статистика сервера, если исполнить rndc stats statistics-file "/var/stats/named.stats"; // // На каких интерфейсах слушать 53-й порт. // Если параметр не задан, то слушает все. listen-on { 127.0.0.1; 192.168.0.1; XXX.XXX.XXX.XXX; }; // Интересная опция. Расскажу в конце конфига, // где она может выручить. interface-interval 10; // Разрешать рекурсивные запросы? Да. recursion yes; // Определим, от каких сетей обрабатывать // рекурсивные запросы. Используем здесь, // созданный нами ранее Access Control // List по имени IN_NET allow-recursion { "IN_NET"; }; // Если в кеше нет записи о зоне, которая нам нужна, // что делать? Сразу начинать поиск имени начиная // от корневых DNS серверов, или же попробовать // "уточнить" эту информацию у ближайших DNS (обычно // своего провайдера), перенаправив запрос? // Да, перенаправить. forward first; // Чтобы перенаправить, надо знать, // кому перенаправлять. Укажем здесь DNS"ы // своего провайдера (можно несколько). forwarders { XXX.XXX.XXX.XXX; YYY.YYY.YYY.YYY; }; // О тех зонах, что мы поддерживаем // (и первичные и вторичные) кому будем // отдавать информацию? Всем. Данный параметр // можно переопределить для каждой конкретной // зоны в конфигурационном файле зоны. allow-query { any; }; // Параметр для указания версии сервера. // Зачем только не понятно. version "SuperPuper DNS"; }; // Глобальные настройки закончились. // Дальше идут необязательные параметры // ведения логов. Можно писать, а можно // не писать. logging { channel syslog { syslog daemon; severity info; print-category yes; print-severity yes; }; category xfer-in { syslog; }; category xfer-out { syslog; }; category config { syslog; }; category default { null; }; }; // // А здесь пропишем настройки "удаленного" // управления DNS сервером утилитой rndc. // Удаленное в кавычки взял, потому что управлять // нашим DNS мы будем только с локалхоста. // Хотя можно сделать так, чтобы bind открыл // "command chanel" на внешнем интерфейсе // и принимал команды от удаленных узлов. // Но я считаю это "дырой", а потому нефиг. // Пусть слушает только localhost и принимает // команды только с него. В данной секции нам // нужно прописать только лишь ключ, который // будет использоваться при работе с rndc. key "Daemony" { algorithm hmac-md5; secret "pPSvUGU4mRoD0vTuwpzvUg=="; }; // // Собственно, с конфигурацией сервера на этом // все. Далее идут настройки только DNS зон. // ////////////////////////////////////////////// // Эту секцию я условно обозвал "SYSTEM" zones ////////////////////////////////////////////// // ///// Корневая зона. Или зона "точка". // У Д А Л Я Т Ь Н Е Л Ь З Я! // Иначе Ваш DNS работать не будет. // zone "." { // - здесь описывается тип зоны type hint; // - здесь указан конфигурационный файл зоны. file "named.root"; }; // ///// Прямая зона для localhost zone "localhost" { // - следущий параметр указывает, что наш DNS // сервер для этой зоны является авторитативным type master; // - кому можно об этой зоне рассказывать - // понятное дело, что только самому себе allow-query { 127.0.0.1; }; // - файл с конфигурацией зоны file "master/localhost"; }; // ///// Обратная зона для localhost zone "0.0.127.IN-ADDR.ARPA" { type master; allow-query { 127.0.0.1; }; file "reverse/localhost.rev"; }; // Все аналогично предыдущему случаю. // // В конце named.conf мы с помощью конструкции include // подключим чтение остальных частей конфигурации // DNS, а именно информацию о поддерживаемых зонах, // которая содержится в следующих файлах. // include "/etc/namedb/zones.master"; include "/etc/namedb/zones.slave"; include "/etc/namedb/zones.reverse"; /// End of bind configuration

Что касается опции “interface-interval ” она может пригодиться на серверах, где внешний интерфейс динамический, например, tun0 . Если у Вас подключение к поставщику услуг сети Интернет посредством PPP или PPPoE при старте системы bind может стартовать быстрее, чем будет поднято PPP/PPPoE соединение. В купе с “listen-on ” это будет чревато тем, что bind не сможет слушать интерфейс, который появился после его запуска. Как это лечить, не знаю. Если кто-то подскажет, скажу спасибо. Но знаю, что с помощью “interface-interval N; ” можно заставить bind после запуска выждать N секунд до того, как он “прибиндится” на интерфейсы. При старте системы за 10 секунд, PPPoE интерфейс например, поднимается обычно без проблем и bind продолжает нормальную работу.

Файл zones.reverse подключается в конфиге named.conf и содержит информацию о реверсивных зонах. У нас она одна. Нам нужны PTR записи для машин в локальной сети, а в локальной сети у нас только одна подсеть 192.168.0.0/24

// - имя зоны zone "0.168.192.IN-ADDR.ARPA" { // - тип зоны - она у нас "первичная" но прописана для реверса type master; // - кому можно отвечать за запросы получения // информации об именах в этой зоне? Только нашей локальной сети. allow-query { 127.0.0.1; 192.168.0.0/24; }; // - путь к файлу конфигурации зоны file "reverse/in.0.168.192.rev"; };

Файл zones.master также подключается в конфиге named.conf и содержит информацию о том, какие праймэри (primary ) зоны мы будем поддерживать. Для примера, она у нас будет только одна. Зона zone1.com

// - имя зоны zone "zone1.com" { // - тип зоны - она у нас "мастер" - первичная type master; // - путь к файлу конфигурации зоны file "master/zone1.com"; // - кому можно отвечать за запросы получения // информации об именах в этой зоне? Всем. allow-query { any; }; // - кому можно отдавать полностью конфигурацию зоны // (осуществлять трансфер). Здесь укажем только IP // адреса наших вторичных DNS серверов для зоны zone1.com allow-transfer { 100.200.0.1; 200.100.0.2; }; };

Файл zones.slave опять таки подключается в конфиге named.conf и содержит информацию о том, какие вторичные (secondary ) зоны должен поддерживать наш DNS сервер. В данном примере, мы осуществляем поддержку одной зоны friends.com

// - указываем имя зоны zone "friends.com" { // - указываем, что зона эта вторичная (slave) type slave; // - в каком файле сохранить информацию об этой зоне file "slave/friends.com"; // - указываем IP адрес(а) первичного(ых) DNS сервера(ов) // Напомню, что первичных серверов может быть больше одного masters { 210.220.230.240; }; };

С конфигурацией зон покончили. Если необходимо добавить какую-то еще зону, правим соответствующий файл и даем указание bind’у перечитать настройки. Теперь опишем собственно сами зоны в соответствующих файлах. Начнем с локалхоста.

# cat /etc/namedb/master/localhost $TTL 1D localhost. IN SOA ns.mydns.net. root.ns.mydns.net. (2007042001 ;serial number 86400 ;refresh 3600 ;retry 3888000 ;expire 3600 ;minimum) localhost. IN NS ns.mydns.net. localhost. IN A 127.0.0.1

В этом примере второй строкой идут следующие параметры: “имя зоны ” – localhost, “тип записи ” – IN SOA – Start Of Authority – “Начало авторитативной зоны “, за которую отвечает авторитативный DNS сервер ns.mydns.net , а с администратором этого сервера можно связаться по e-mail [email protected] (точка заменяется “собакой”). Дальше следуют серийный номер зоны (serial number ), который всегда следует изменять при внесении изменений в зону, период обновления зоны (refresh ) вторичными DNS серверами (в секундах), период между попытками обновить зону вторичным DNS сервером (retry ), если предыдущая попытка оказалась безуспешной, срок жизни зоны (expire ) на вторичном DNS сервере, если первичный недоступен. Что означает параметр “minimum ” я, честно говоря, непомню.

Дальше следуют описания DNS записей зоны. Из примера видно, что для имени localhost прописана одна А запись и указывает она на IP адрес 127.0.0.1 За поддержку зоны отвечает сервер ns.mydns.net, тоесть наш локальный bind.

Пример конфигурации обратной DNS зоны для localhost

# cat /etc/namedb/reverse/localhost.rev $TTL 3600 @ IN SOA ns.mydns.net. root.ns.mydns.net. (2007042001 ; Serial 3600 ; Refresh 900 ; Retry 3600000 ; Expire 3600) ; Minimum IN NS ns.mydns.net. 1 IN PTR localhost.

Теперь наш bind будет знать, что для 127.0.0.1 прописана следующая PTR запись:

# host 127.0.0.1 1.0.0.127.in-addr.arpa domain name pointer localhost.

Теперь нам необходимо создать файл обратной DNS зоны /etc/namedb/reverse/in.0.168.192.rev в котором укажем PTR записи для машин в нашей локальной сети. Пример будет таким:

$TTL 3600 @ IN SOA ns.mydns.net. root.ns.mydns.net. (2007042001 ; Serial 3600 ; Refresh 900 ; Retry 3600000 ; Expire 3600) ; Minimum IN NS ns.mydns.net. 1 IN PTR router. 2 IN PTR mail-server. 3 IN PTR web-server. 4 IN PTR boss. 5 IN PTR buhgalter. // и так далее...

После того, как наш DNS перечитает такую конфигурацию, в локальной сети IP адреса начнут резолвиться приблизительно в таком виде:

$ host 192.168.100.1 1.0.168.192.in-addr.arpa domain name pointer router. $ host 192.168.100.2 2.0.168.192.in-addr.arpa domain name pointer mail-server. $ host 192.168.100.3 3.0.168.192.in-addr.arpa domain name pointer web-server. $ host 192.168.100.4 4.0.168.192.in-addr.arpa domain name pointer boss. $ host 192.168.100.5 5.0.168.192.in-addr.arpa domain name pointer buhgalter.

Честно скажу, при разборе логов (и не только во FreeBSD) имена гораздо удобнее, чем IP адреса.

Наконец, нам осталось создать файл поддерживаемой нами первичной DNS зоны zone1.com Для этого в каталоге /etc/namedb/master создаем файл, например, такой конфигурации:

$TTL 7200 @ IN SOA ns.mydns.net. hostmaster.ns.mydns.net. (2008020601 ; Serial 28800 ; Refresh 7200 ; Retry 2419200 ; Expire 86400) ; Negative Cache TTL ; @ IN NS ns.mydns.net. @ IN NS ns1.somedns.net. @ IN NS ns2.somedns.net. @ IN A 212.212.212.212 @ IN MX 1 ASPMX.L.GOOGLE.COM. @ IN MX 5 ALT1.ASPMX.L.GOOGLE.COM. @ IN MX 5 ALT2.ASPMX.L.GOOGLE.COM. @ IN MX 10 ASPMX2.GOOGLEMAIL.COM. @ IN MX 10 ASPMX3.GOOGLEMAIL.COM. @ IN MX 10 ASPMX4.GOOGLEMAIL.COM. @ IN MX 10 ASPMX5.GOOGLEMAIL.COM. www IN CNAME zone1.com. ftp IN A 213.213.213.213

В данном примере приведены записи (выдуманные, естественно) для зоны zone1.com : почту для этой зоны принимают сервера Google (семь MX записей – семь серверов для приема почты на этот домен); само имя zone1.com привязано A записью к хосту с IP адресом 212.212.212.212, а www.zone1.com является синонимом имени zone1.com ; при этом за зону отвечают DNS сервера ns.mydns.net , ns1.somedns.net и ns2.somedns.net . А по адресу 213.213.213.213 возможно находится FTP сервер ftp.zone1.com . По крайней мере, для этого имени есть соответствующая А запись.

Учтите, что сервера ns1.somedns.net и ns2.somedns.net , а точнее их IP адреса должны быть обязательно указаны в файле /etc/namedb/zones.master в “allow-transfer ” для этой зоны.

Обратите особое внимание на расстановку точек. Вообще, достаточно ошибиться в одном знаке препинания в конфиге или файлах зоны и DNS либо не запустится вообще, либо зона будет работать неправильно.

Конфигурирование DNS сервера окончено. Чтобы он начал работать следует в /etc/rc.conf добавить:

Named_enable="YES"

Все остальное что нам нужно, прописано по-умолчанию в файле /etc/defaults/rc.conf

# cat /etc/defaults/rc.conf | grep named_uid named_uid="bind" # User to run named as

Именно так. Неймд должен стартовать только от имени пользователя bind и ни в коем случае не от root’а. Иначе, рискуете стать жертвой глупости.

Bind можно запустить “родным” стартовым скриптом:

# /etc/rc.d/named start Starting named.

При этом в /var/log/messages он напишет:

Named: starting BIND 9.3.4-P1 -t /var/named -u bind named: command channel listening on 127.0.0.1#953

Для пущей уверенности, что все работает:

# sockstat | grep named bind named 33696 3 dgram -> /var/run/logpriv bind named 33696 20 udp4 192.168.0.1:53 *:* bind named 33696 21 tcp4 192.168.0.1:53 *:* bind named 33696 22 udp4 127.0.0.1:53 *:* bind named 33696 23 tcp4 127.0.0.1:53 *:* bind named 33696 24 udp4 XXX.XXX.XXX.XXX:53 *:* bind named 33696 25 tcp4 XXX.XXX.XXX.XXX:53 *:* bind named 33696 26 udp4 *:53 *:* bind named 33696 27 tcp4 127.0.0.1:953 *:* root syslogd 462 7 dgram /var/named/var/run/log

Bind работает и готов принимать запросы на всех интерфейсах. Если у Вас он их не обрабатывает, проверьте разрешили ли Вы доступ к своему DNS на фаерволле. На порт 53 и с него должны беспрепятственно бегать пакеты как по TCP так и по UDP.

И напоследок немного о том, как можно управлять bind’ом посредством rndc.

rndc reload – перезагрузит конфигурацию (если нет ошибок в конфигурации named.conf)
rndc stop – остановит DNS сервер
rndc stats – выведет статистику того, что накешировал Ваш DNS
rndc dump – выбросит свой кеш в дамп файл, прописанный в конфиге named.conf
rndc flush – сбросит свой кеш в ноль
rndc flushname zona.com – удалит у себя из кеша информацию о зоне zona.com
rndc halt – убиение named’а без сохранения всего того, что он хотел сохранить в этот момент
rndc reconfig – приведет к перезагрузке основной конфигурации файла, а также конфигурации новых зон и еще масса приятных и удобных вещей.

Как видите, в конфигурировании DNS сервера абсолютно ничего сложного. Хотя, многим по началу кажется наоборот.

Насколько полезным был этот пост?

Нажмите на звезду, чтобы оценить!

Пока оценок нет! Будьте первым, поставь свою оценку этому посту.

Мы сожалеем, что этот пост не был полезен для вас!

Давайте улучшим этот пост!

Отправить отзыв

Спасибо за ваш отзыв!

Есть своя сеть с белыми IP (111.222.333.0) и доменом (mydomain.ru). Требуется поднять DNS который смотрит в интернет.
Загружаем образ FreeBSD 10.0

Устанавливаем, назначаем сетевому интерфейсу адрес 111.222.333.2

Настраиваем синхронизацию времени раз в сутки. добавляем в crontab :

1 6 * * * root ntpdate -s 0.freebsd.pool.ntp.org

Устанавливаем bind 9.9 из репозитория:

Pkg install bind99

Правим конфиг
В начале конфига прописываем правила для allow-recursion allow-transfer allow-query

Acl "recursion-ip" { 127.0.0.1; 111.222.333.0/24; }; acl "trusted-dns" { 111.111.111.111; 222.222.222.222; }; acl "query-ip" { 127.0.0.1; 111.222.333.0/24; };

В секции options прописываем:

// разрешаем рекурсивные запросы allow-recursion { recursion-ip; }; // разрешаем передачу зоны доверенным DNS серверам // (указывает ns сервера регистратора домена) allow-transfer { trusted-dns; }; // разрешаем подавать запросы нашему серверу allow-query { query-ip; }; // скрываем версию нашего сервера version "MyDNS";

Указываем на каких интерфейсах работать.

Listen-on { 127.0.0.1; 111.222.333.2; };

В конце файла прописываем прямую и обратную зону:

Zone "mydomain.ru" { type master; file "/usr/local/etc/namedb/master/mydomain.ru-forward.db"; }; zone "333.222.111.in-addr.arpa" { type master; file "/usr/local/etc/namedb/master/mydomain.ru-333.222.111-reverse.db"; };

Теперь создаем файлы зон. Прописываем в файл mydomain.ru-forward.db

$TTL 3600 @ IN SOA ns1.mydomain.ru. root.ns1.mydomain.ru. (2014040101 ; Serial 3600 ; Refresh 900 ; Retry 360000 ; Expire 3600 ; Neg. cache TTL) IN A 111.222.333.1 ; по этому адресу будет резолвиться наш домен mydomain.ru IN NS ns1.mydomain.ru. IN NS ns1-your_registrator.ru. ; ns сервера вашего регистратора IN NS ns2-your_registrator.ru. IN MX 10 mail.mydomain.ru. ; если есть почта в домене ns1 IN A 111.222.333.2 ; IP адрес нашего DNS first IN A 111.222.333.10 ; далее пойдут домены second IN A 111.222.333.11 ; третьего уровня нашей сети

Затем прописываем в файл обратной зоны mydomain.ru-333.222.111-reverse.db следущее:

$TTL 3600 @ IN SOA ns1.mydomain.ru. root.ns1.mydomain.ru. (2014032801 ; Serial 3600 ; Refresh 900 ; Retry 360000 ; Expire 3600 ; Neg. cache TTL) IN NS ns1.mydomain.ru. IN NS ns1-your_registrator.ru. IN NS ns2-your_registrator.ru. 2 IN PTR ns1.mydomain.ru. 10 IN PTR first.mydomain.ru. 11 IN PTR second.mydomain.ru.

Значение Serial (Серийный номер версии файла зоны) нужно увеличивать при каждом изменении в зоне.
По этому значению вторичный сервер обнаруживает, что надо обновить информацию.

Теперь проверим файлы зон:

Named-checkzone mydomain.ru mydomain.ru-forward.db named-checkzone 333.222.111.in-addr.arpa mydomain.ru-333.222.111-reverse.db

Вывод команды должен быть вида:

Zone mydomain.ru/IN: loaded serial 2014040101 OK

Настроим логирование.
Прописываем в конфиг bind (/usr/local/etc/namedb/named.conf )

Logging { channel default_ch { file "/var/log/named/named.log" versions 3 size 500k; severity info; print-time yes; print-category yes; }; channel security_ch { file "/var/log/named/named-security.log" versions 3 size 500k; severity info; print-time yes; print-category yes; }; channel transfer_ch { file "/var/log/named/named-transfer.log" versions 3 size 500k; severity info; print-time yes; print-category yes; }; channel lame_ch { file "/var/log/named/named-lamers.log" versions 3 size 500k; severity info; print-time yes; print-category yes; }; category default { default_ch; }; // все, для чего нет собственного канала category security { security_ch; }; // события безопасности category xfer-in { transfer_ch; }; // отдача зон category xfer-out { transfer_ch; }; // прием зон category notify { transfer_ch; }; // уведомления и факты регистрации category lame-servers { lame_ch; }; // события от "кривых" DNS-серверов };

Выставим владельца на директорию /var/log/named

Chown bind:bind /var/log/named

Проверяем правильность конфига named.conf командой

Named-checkconf

Если результатом выполнения этой команды «ничего» то все ОК.
Теперь загрузим актуальный файл корневой зоны (named.root ).

Fetch ftp://ftp.internic.net/domain/named.root

Поместим его в каталог /usr/local/etc/namedb с заменой существующего.
Желательно периодически повторять эту процедуру, или настроить эту операцию посредством cron.
Все почти готово! Настроим утилиту управления — rndc
Переходим в каталог /usr/local/etc/namedb
Удаляем файл rndc.conf
Выполняем:

Rndc-confgen -a

Меняем владельца:

Chown bind:bind rndc.key

Задействуем автостарт сервера имен.
В файл /etc/rc.conf пропишем:

Named_enable="YES" # если нужен только IPv4, то named_flags="-4"

Настроим DNSSEC.
Создадим каталог keys для файлов ключей.
Создадим мастер ключ — Key Signing Key (KSK) и ключ для зоны — Zone Signing Key (ZSK) .

Команда создания KSK ключа:

Dnssec-keygen -f KSK -a RSASHA256 -b 2048 -n ZONE mydomain.ru

Команда для создания ZSK ключа:

Dnssec-keygen -a RSASHA256 -b 2048 -n ZONE mydomain.ru

удостоверьтесь что ваш регистратор домена поддерживает алгоритм RSASHA256

выставляем права на файлы ключей:

Chown bind:bind Kmydomain.ru*

Включим логирование. В конфиг /usr/local/etc/namedb/named.conf в секцию logging добавим:

Channel dnssec_ch { file "/var/log/named/named-dnssec.log" versions 3 size 500k; severity info; print-time yes; print-category yes; }; category dnssec { dnssec_ch; };

и добавим в описание зоны:

Key-directory "/usr/local/etc/namedb/keys"; inline-signing yes; auto-dnssec maintain;

теперь зона mydomain.ru выглядит так:

Zone "mydomain.ru" { type master; file "/usr/local/etc/namedb/master/mydomain.ru-forward.db"; key-directory "/usr/local/etc/namedb/keys"; inline-signing yes; auto-dnssec maintain; };

Для поддержки проверки DNSSEC на стороне резолвера добавте в секцию options :

Dnssec-enable yes; dnssec-validation yes;

После растарта демона в каталоге зон появятся файлы с расширением: .jbk, .jnl и.signed

Если вы используете DNSSEC Look-aside Validation (опцию dnssec-lookaside auto;), то можете наблюдать в логе множественные сообщения вида: got insecure response; parent indicates it should be secure. Чтобы предотвратить это установите значение dnssec-validation auto; и используйте в качестве forwarders серверов DNS с поддержкой DNSSEC, например от Google — 8.8.8.8

Чтобы заработал процесс верификации регистратору вашего домена нужно заверить созданный KSK ключ и подтвердить свое доверие.
для этого нужно прописать DS записи в панели управления доменом.
DS записи создаются на основе KSK ключа командой:

Dnssec-dsfromkey имя_файла_KSK_ключа

записи выданные этой командой прописываем в панели управления регистратора домена.

Mydomain.ru. IN DS 54808 5 1 0FC489EFD28C2...28EA985CAFBBC1 mydomain.ru. IN DS 54808 5 2 03B685D8003834B492F6...B134ABF9D41A28193171352F0280

У некоторых регистраторах также требуется прописать DSKEY из файла KSK ключа.

Mydomain.ru. IN DNSKEY 257 3 5 YthgRbNKP5P8e5cDJhYsCwFr7AK17m+SeV5pgW...bLVa2A0/dWXkPwi1TZ3lNfkjhhYFGR

И в заключении настроим файервол.
Создадим файл /etc/ipfw.my_rules следующего содержания:

#!/bin/sh cmd="/sbin/ipfw -q add" # команда добавления правил oint="vmx0" # интерфейс на котором запушен named ipo="111.222.333.2" # IP адрес этого интерфейса # Сбрасываем все правила: /sbin/ipfw -f flush # Проверяем на соответствие пакета динамическим правилам: ${cmd} check-state # Разрешаем весь траффик по внутреннему интерфейсу lo0 ${cmd} allow ip from any to any via lo0 # отсекаем попытки лезть от lo0 и к нему ${cmd} deny ip from any to 127.0.0.0/8 ${cmd} deny ip from 127.0.0.0/8 to any # блокируем частные сети и автоконфигурационную т.к. интерфейс смотрит в интернет. ${cmd} deny ip from any to 10.0.0.0/8 in via ${oint} ${cmd} deny ip from any to 172.16.0.0/12 in via ${oint} ${cmd} deny ip from any to 192.168.0.0/16 in via ${oint} ${cmd} deny ip from any to 0.0.0.0/8 in via ${oint} ${cmd} deny ip from any to 169.254.0.0/16 in via ${oint} # блокируем мультикастовые пакеты ${cmd} deny ip from any to 240.0.0.0/4 in via ${oint} # блокируем широковещательный и фрагментированный icmp ${cmd} deny icmp from any to any frag ${cmd} deny log icmp from any to 255.255.255.255 in via ${oint} ${cmd} deny log icmp from any to 255.255.255.255 out via ${oint} # траффик к частным сетям ${cmd} deny ip from 10.0.0.0/8 to any out via ${oint} ${cmd} deny ip from 172.16.0.0/12 to any out via ${oint} ${cmd} deny ip from 192.168.0.0/16 to any out via ${oint} ${cmd} deny ip from 0.0.0.0/8 to any out via ${oint} # автоконфигуреную частную сеть ${cmd} deny ip from 169.254.0.0/16 to any out via ${oint} # мультикастовые рассылки ${cmd} deny ip from 224.0.0.0/4 to any out via ${oint} ${cmd} deny ip from 240.0.0.0/4 to any out via ${oint} # разрешаем установленные соединения ${cmd} allow tcp from any to any established # разрешаем исходящий траффик от сервера ${cmd} allow ip from ${ipo} to any out xmit ${oint} # разрешаем синхронизацию времени через ntpdate ${cmd} allow udp from any 123 to any via ${oint} # разрешаем DNS ${cmd} allow udp from any 53 to any via ${oint} # разрешаем входящий DNS (протокол tcp нужен для трансфера зон) ${cmd} allow udp from any to any 53 via ${oint} ${cmd} allow tcp from any to any 53 via ${oint} # разрешаем ICMP - эхо-запрос, эхо-ответ, время жизни пакета истекло ${cmd} allow icmp from any to any icmptypes 0,8,11 # разрешаем 22 порт для определенного адреса и пишем в лог попытки соединиться с отличных адресов ${cmd} allow tcp from 111.222.333.3 to ${ipo} 22 via ${oint} ${cmd} deny log tcp from any to me 22 in via ${oint}

Для автостарта фаервола пропишем в файл /etc/rc.conf строки:

Firewall_enable="YES" firewall_script="/etc/ipfw.my_rules" firewall_logging="YES"

Логи будут писаться в файл /var/log/security