Главная
Программы
Подробная настройка unbound в freebsd 10.3. Временное назначение ip адреса

Подробная настройка unbound в freebsd 10.3. Временное назначение ip адреса

В собственной локальной сети чаще всего возникает необходимость в своем DNS-сервере, который будет отвечать на запросы не только про хосты из внешнего мира, но и обслуживать внутреннюю сеть. Рассмотрим, как поднять такой сервер на базе Bind. Я буду описывать процесс во FreeBSD, но аналогичная конфигурация присутствует и в других операционных системах.

Как пересобрать ядро, описано в статье " "

2. Настройка и запуск
Конфигурационного файла «из коробки» достаточно для запуска и работы, но отвечать на запросы сервер будет к 127.0.0.1. Для проверки можем выполнить

# /usr/local/etc/rc.d/named onestart
Starting named.
# nslookup google.ru 127.0.0.1
Server: 127.0.0.1
Address: 127.0.0.1#53
Non-authoritative answer:
Name: google.ru
Address: 172.217.18.67
Name: google.ru
Address: 2a00:1450:400d:802::2003
Для полноценной работы его нужно настроить.
Исходные данные:
ИП-адрес нашего сервера10.10.0.1
Будем обслуживать запросы из подсетей 10.10.0.0/24 и 10.10.1.0/24
Прямая зонаexample.org
Обратные зоны будут для наших подсетей

Редактируем конфигурационный файл /usr/local/etc/namedb/named.conf
В самое начало файла добавляем строку
acl ACCESS { 127.0.0.1; 10.10.0.0/24; 10.10.1.0/24};
Указываем перечень ИП-адресов и подсетей, на запросы с которых будет отвечать, остальные будут получать отказ. Я обычно предпочитаю произвести подобное ограничение при помощи фаервола
Редактируем секцию options
listen-on { 127.0.0.1; 10.10.0.1; }; //# указываем IP-адреса интерфейсов которые будет слушать сервер
allow-recursion { ACCESS; };
forwarders {8.8.8.8;} //# Если у Вашего провайдер есть свои ДНС-сервера, здесь можно указать их ИП-адреса, тогда наш ДНС-сервер будет сразу обращаться к ним, иначе закомментируйте.
Добавляем секции для наших зон
zone "example.org" {
type master;
file "/usr/local/etc/namedb/master/example.org";
};
zone "0.10.10.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/0.10.10.in-addr.arpa";
};
zone "1.10.10.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/1.10.10.in-addr.arpa";
};

Создаем файл зоны /usr/local/etc/namedb/master/example.org
$TTL 3600;# Время жизни (сколько будет находиться в кэше) в секундах
@ IN SOA ns.example.org. test.test.com ;(# Имя DNS-сервера и e-mail адрес администратора (вместо @ ставим «.»)
2017061901; Serial
3600; Refresh
900; Retry
360000; Expire
3600; Minimum
@ IN NS ns.example.org.
@ IN A 10.10.0.1
localhost IN A 127.0.0.1
example.org. IN A 10.10.0.1
ns IN A 10.10.0.1
home IN A 10.10.0.1 ; Мой домен 3-го уровня home.example.org
svn IN A 10.10.1.2 ; Мой домен 3-го уровня svn.example.org
Создаем файлы с описанием обратных зон

$TTL 3600

2017061901 ;
3600 ;
600 ;
2419200 ;
86400)
@ IN NS ns.example.org.
1 IN PTR home.example.org
/usr/local/etc/namedb/master/0.10.10.in-addr.arpa
$TTL 3600
@ IN SOA ns.example.org. test.test.com. (
2017061901 ;
3600 ;
600 ;
2419200 ;
86400)
@ IN NS ns.example.org.
2 IN PTR svn.example.org
Добавляем в автозагрузку
# echo "named_enable="YES"" >> /etc/rc.conf
И запускаем
# /usr/local/etc/rc.d/named restart
Если нигде не допустили ошибок, у нас заработал кешируюший DNS-сервер с поддержкой внутренних зон.
Можем проверить работоспособность при помощи команды nslookup или dig
# nslookup 10.10.0.1 127.0.0.1
1.0.10.10.in-addr.arpa name = home.example.org.
nslookup home.example.org 127.0.0.1
Server: 127.0.0.1
Address: 127.0.0.1#53
Name: home.example.org
Address: 10.10.0.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 сервера абсолютно ничего сложного. Хотя, многим по началу кажется наоборот.

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

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

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

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

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

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

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

Пришла пора обновлять некоторые сервера с установленной на них FreeBSD 9.3. В FreeBSD 10 версии из базовой системы был удален сервер BIND, и если продолжать его использование и далее, то требуется установить его из портов.

После обновления системы у меня быстро изменив пару строк конфигов не получилось запустить BIND в chroot`e на FreeBSD 10, поэтому я и решил детально расписать этот процесс. Возможно кому-то это сэкономит время.

Устанавливаем BIND из портов.

cd /usr/ports/dns/bind99 && make install clean

Оставшаяся конфигурация от 9.Х находится по пути /var/named/etc/namedb. И если действовать в соответствии со стандартами, то конфигурацию перемещаем в /usr/local/var/named/etc/namedb, т.к. даже сама система нам говорит, что в /var/named/ у нас ничего не должно быть.

root@:/usr/src # make check-old
>>> Checking for old files
/var/named/etc/namedb/named.root
>>> Checking for old libraries
>>> Checking for old directories
/var/named/dev
/var/named/etc
/var/named/etc/namedb
/var/named/etc/namedb/dynamic
/var/named/etc/namedb/master
/var/named/etc/namedb/working
/var/named/etc/namedb/slave
/var/named/var
/var/named/var/dump
/var/named/var/log
/var/named/var/run
/var/named/var/run/named
/var/named/var/stats
/var/run/named
To remove old files and directories run "/usr/obj/usr/src/make.amd64/bmake delete-old".
To remove old libraries run "/usr/obj/usr/src/make.amd64/bmake delete-old-libs".

Создаем рабочую директорию для BIND.

mv /var/named /usr/local/var

Файлы конфигурации созданные инсталлятором будут находиться по пути /usr/local/etc/namedb. На всякий случай резервируем их.

mv /usr/local/etc/namedb /usr/local/etc/namedb.orig

ln -s /usr/local/var/named/etc/namedb /usr/local/etc/namedb

mkdir -p /usr/local/var/named/usr/local
cd /usr/local/var/named/usr/local ln -s ../../etc
cp /usr/local/etc/namedb.orig/named.root /usr/local/var/named/etc/namedb

Создаем правила для devfs. Правим /etc/devfs.conf.

# Custom rules for the named chroot dev
add hide
add path run unhide
add path random unhide

Добавляем в /etc/fstab.

devfs /usr/local/var/named/dev devfs rw,ruleset=4 0 0

Монтируем.

mount /usr/local/var/named/dev

Правим /etc/rc.conf примерно следующего содержания.

named_enable="YES" # Run named, the DNS server (or NO).
named_program="/usr/local/sbin/named" # path to named, if you want a different one.
named_chrootdir="/usr/local/var/named" # Chroot directory (or "" not to auto-chroot it)
named_conf="/usr/local/etc/namedb/named.conf" # Path to the configuration file
named_flags="-4" # Flags for named
named_uid="bind" # User to run named as
named_chroot_autoupdate="YES" # Automatically install/update chrooted
# components of named. See /etc/rc.d/named.
named_symlink_enable="YES" # Symlink the chrooted pid file
#named_wait="NO" # Wait for working name service before exiting
#named_wait_host="localhost" # Hostname to check if named_wait is enabled
#named_auto_forward="NO" # Set up forwarders from /etc/resolv.conf
#named_auto_forward_only="NO" # Do "forward only" instead of "forward first"

Правим конфигурационный файл /usr/local/etc/namedb/named.conf

directory "/usr/local/etc/namedb";

Выставляем правильные права доступа на конфигурационные файлы.

chown -R bind:wheel /usr/local/var/named/etc/namedb

На данный момент нужно еще поправить /usr/local/etc/rc.d/named иначе при остановке сервиса появляется ошибка.

Stopping named.
umount: /var/namedb/usr/local/lib/engines: statfs: No such file or directory
umount: /var/namedb/usr/local/lib/engines: unknown file system

Вносим следующие изменения

named_poststop()
{
- if [ -n "${named_chrootdir}" -a -c ${named_chrootdir}/dev/null ]; then
+ if [ -d ${_openssl_engines} -a -n "${named_chrootdir}" -a -c ${named_chrootdir}/dev/null ]; then

Запускаем BIND

/usr/local/etc/rc.d/named start

В статье использовались материалы.

В этой статье мы рассмотрим сетевые интерфейсы в 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.

Есть своя сеть с белыми 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

Программы

Вам также может понравиться