У цій статті ми розглянемо мережеві інтерфейси 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, ви можете перевірити 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, якщо 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.
// Для того, щоб бути доступним до мережі, помітити цей варіант, 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. Щоб отримати доступ до мережі, specify
// an IPv6 address, або the keyword "any".
// listen-on-v6 (::1; );

/ / Ці області є виконані за межами empty zones.
// Якщо ви поєднуєте 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.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.IP6.ARPA";

// In addition to the "forwarders" clause, ви можете force your name
// Server до невідомих творів з його майна, але завжди ask its
/ / forwarders тільки, щоб обмежити following line:
// forward only;

// If you"ve got a DNS server навколо вашого 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 для IPv6
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 і 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";
};
файл "dynamic/example.org";
};
*/

/* Example of a slave reverse zone
zone "1.168.192.in-addr.arpa" (
type slave;
файл "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-й порт.// Якщо параметр не заданий, то слухає все. 192.168.0.1;XXX.XXX.XXX.XXX;)) // Цікава опція: Розкажу в кінці конфіга, // де вона може виручити. Визначимо, від до таких мереж обробляти // рекурсивні запити. Використовуємо тут // створений нами раніше Access Control // List на ім'я IN_NET allow-recursion ("IN_NET"; ); // Якщо в кеші немає запису про зону, яка нам потрібна, // що робити? Відразу починати пошук імені починаючи // від кореневих DNS серверів, або спробувати // "уточнити" цю інформацію у найближчих DNS (зазвичай // свого провайдера), перенаправивши запит? // Так, переспрямувати. forward first; // Щоб перенаправити, треба знати, // кому перенаправляти. Вкажемо тут DNS"и // свого провайдера (можна кілька). ) кому будемо // віддавати інформацію?Усім Даний параметр // можна перевизначити для кожної конкретної // зони в конфігураційному файлі зони .allow-query ( any; ); // Параметр для вказівки версії сервера. version "SuperPuper DNS"; );// Глобальні налаштування закінчилися.// Далі йдуть необов'язкові параметри // ведення логів. Можна писати, а можна // не писати. ; print-severity yes; ); category xfer-in ( syslog; ); "віддаленого" // управління 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; );

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

// - ім'я зони zone "zone1.com" ( // - тип зони - вона у нас "майстер" - первинна type master; // - шлях до файлу конфігурації зони file "master/zone1.com"; // - кому можна відповідати за запити одержання // інформації про імена в цій зоні? серверів для зони 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, а з адміністратором цього сервера можна зв'язатися електронною поштою [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 веб-сервер. 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:6 . 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: * 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 ; на цій адресі буде резолвуватися наш домен myns.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; ), category default ( default_ch; ); // все, для чого немає власного каналу category security ( security_ch; ); // події безпеки category xfer-in ( transfer_ch; ); // віддача зон category xfer-out ( transfer_ch; ) // прийом зон категорії notify (transfer_ch;); // повідомлення та факти реєстрації категорії 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 # $(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 $(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 $(oi nt) $(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) 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