Веб сервер і поштовий сервер всередині – маршрутизовані адреси

Наскільки складна ваша мережа Наскільки складною вона має бути Ми почнемо з

базового сценарію і клієнтів з глави 3, того що ми створили за базовим брандмауером PF, що мають доступ до ряду сервісів, розміщених в інших місцях, а не сервісів,

працюють в локальній мережі

Ці клієнти отримують трьох нових сусідів: поштовий сервер, веб-сервер і файловий сервер У цьому сценарії ми використовуємо офіційні, маршрутизовані адреси, так як це робить життя трохи легше Іншим перевагою такого підходу є те, що з маршрутизуються адресами ми можемо дозволити двом новим машинам працювати в ролі DNS серверів для нашого домену examplecom: один в якості master, а інший в якості авторітатрного slave1

Зауваження:

Для DNS, завжди має сенс мати, принаймні, один авторитарний slave сервер десь за межами вашої мережі (фактично, деякі домени верхнього рівня не дозволяють зареєструватися без нього) Ви теж саме можете організувати для резервного поштового сервера, який буде в іншому місці Майте це на увазі, коли будуєте свою мережу

На цьому етапі, є досить просте фізичне розташування мережі Ми ставимо нові сервери в тій же локальній мережі, що і клієнти, можливо, в окремій кімнаті, але, безумовно, в тому ж сегменті мережі або на тому ж комутаторі, де підключені клієнти Концептуально нова мережа виглядає приблизно як на малюнку 5-1

1 Фактично, examplecom знаходиться в блоці 192020/24, які визначається в RFC 3330 використовуваний як зарезервований для використання прикладу і документації Ми використовуємо цей діапазон адрес в основному, щоб відрізняти від NAT прикладів в цій книзі, які використовують адреси в приватному адресному просторі RFC 1918

З базовими параметрами мережі ми можемо приступити до налаштування розумних наборів правил для обробки сервісів, які нам потрібні Ще раз, ми починаємо від базового набору правил і додаємо кілька макросів для зручності читання Макроси, які нам потрібні, природно, візьмемо із специфікації:

·&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Web server: webserver = &quot19202227&quot

·&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Web server services:

webports = &quot{ http, https }&quot

·&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Mail server: emailserver = &quot19202225&quot

·&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Mail server services:

email = &quot{ smtp, pop3, imap, imap3, imaps, pop3s }&quot

·&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Name servers:

nameservers = &quot{ 19202221, 19202223 }&quot

Будемо вважати, що файловий сервер недоступний для зовнішнього світу, якщо ми хочемо встановити його, як сервіс за межами локальної мережі, наприклад, авторитетний slave сервер імен для нашого домену З допомогою макросів ми додамо правила для проходження Почнемо з веб-сервера, і зробимо його доступним для світу з наступним правилом:

pass proto tcp to $webserver port $webports

Зі схожим правилом, ми дозволяємо світу спілкуватися з поштовим сервером:

pass proto tcp to $emailserver port $email

Це дозволить клієнтам звідки завгодно мати такий же доступ як і у тих, що знаходяться в нашій локальній мережі, включаючи кілька поштових протоколів, які працюють без шифрування Це звичайна річ в реальному світі, але ви можете взяти до уваги ваші опції, якщо налаштовуєте нову мережу

Поштовий сервер, щоб бути корисним, повинен мати можливість відправляти пошту для хостів також за межами локальної мережі:

pass log proto tcp from $emailserver to port smtp

Майте на увазі, що набір правил починається з блокування всіх правил, а це означає, що тільки поштовий сервер має право ініціювати SMTP-трафік з локальної мережі в інший світ Якщо яким-небудь іншим хостам в мережі потрібно буде послати пошту в зовнішній світ або отримати пошту, їм потрібно використовувати призначений поштовий сервер Це може бути хорошим способом для забезпечення, наприклад, того, що ви робите це так складно, наскільки можливо для будь-якої спам розсилки, які можуть зявитися у вашій мережі, що фактично підвищить навантаження на них

За ці роки, варіант опції syn-проксі отримало велику увагу як можливий оплот проти зловмисного трафіку ззовні Зокрема, опція syn-проксі призначена для захисту від syn-флудних атак, які можуть призвести до виснаження ресурсів на бекенда (back end) Ось як це працює: коли нове зєднання створено, PF нормально дозволяє зєднанню встановитися, просто пропускає пакети, якщо вони збігаються з набором правил дозволяють їх З включеним syn-проксі PF під час первісного соедіненеія дозволяє зєднатися з партнерами тільки один раз, підтверджуючи, що він правильно встановлений, по суті створюючи буфер між зєднанням з партнером Syn проксінг трохи затратнее, ніж стан за замовчуванням, але не завжди помітно, наскільки розумно далі масштабувати обладнання

Потенційні недоліки проявляються в налаштуваннях балансування навантаження де SYN-проксінг PF може приймати зєднання на бекенда не готовий до прийому, в деяких випадках короткого замикання резервування шляхом створення зєднання з іншими хостами, ніж обрана логіка балансування навантаження Це особливо очевидно в таких протоколах як SMTP, де вбудоване резервування підказує, що якщо основний поштовий сервер не приймає зєднання, ви повинні спробувати замість нього вторинний

При розгляді питання установки, де syn-проксі здається привабливим, майте ці питання на увазі і аналізуйте потенційний вплив на вашу установку, яка може надходити від syn-проксі додаючи мішанини Якщо ви вирішили, що SYN проксінг потрібно, просто лавірую на стану syn-проксі в кінці правил, в потрібних опціях

Нарешті, Серевера імен повинні бути доступні для клієнтів за межами нашої мережі, які дивляться на інформацію про examplecom і будь-яких інших доменів для яких ми є авторитетним:

pass inet proto { tcp, udp } to $nameservers port domain

Маючи, інтегрованими всі сервіси, які повинні бути доступні з поза, наш набір правил закінчиться приблизно так:

ext_if = &quotep0&quot # macro for external interface – use tun0 or pppoe0 for PPPoE int_if = &quotep1&quot # macro for internal interface

localnet = $int_if:network webserver = &quot19202227&quot webports = &quot{ http, https }&quot emailserver = &quot19202225&quot

email = &quot{ smtp, pop3, imap, imap3, imaps, pop3s }&quot nameservers = &quot{ 19202221, 19202223 }&quot client_out = &quot{ ssh, domain, pop3, auth, nntp, http,\ https, cvspserver, 2628, 5999, 8000, 8080 }&quot udp_services = &quot{ domain, ntp }&quot

icmp_types = &quot{ echoreq, unreach }&quot block all

pass quick inet proto { tcp, udp } from $localnet to port $udp_services pass log inet proto icmp all icmp-type $icmp_types

pass inet proto tcp from $localnet to port $client_out

pass inet proto { tcp, udp } to $nameservers port domain pass proto tcp to $webserver port $webports

pass log proto tcp to $emailserver port $email pass log proto tcp from $emailserver to port smtp

Це як і раніше досить проста настройка, але, на жаль, вона має один потенційно тривожний недолік безпеки Сервери, які пропонують сервіси в світі в цілому все в тієї ж локальної мережі, що і клієнти, і вам потрібно буде обмежувати будь-які внутрішні сервіси тільки для локального доступу

В принципі, це означає, що зловмисник повинен отримати доступ тільки до одного хосту в локальній мережі, щоб отримати доступ до будь-яких ресурсів там, встановивши лиходієві рівні права з будь-яким користувачем у вашій локальній мережі Залежно, від того, наскільки добре кожна машина і ресурс захищені від несанкціонованого доступу, це може бути що завгодно, починаючи від незначного подразнення на головний біль У наступному розділі, ми розглянемо деякі варіанти для розділення сервісів,

які повинні взаємодіяти з світом у цілому з локальної мережі

Джерело: Книга про PF, by Peter NM Hansteen, Переклад виконав Михайлов Олексій aka iboxjo

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*