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

Насколько сложна  ваша сеть?  Насколько сложной  она  должна  быть?  Мы  начнем  с

базового сценария и клиентов из главы 3, того что мы создали за базовым брандмауэром PF, имеющих доступ к ряду сервисов, размещенных в других  местах, а не сервисов,

работающих в локальной сети.

Эти клиенты получают трех новых соседей: почтовый сервер, веб-сервер и  файловый сервер. В этом сценарии мы используем официальные, маршрутизируемые адреса, так как это делает жизнь немного легче. Другим преимуществом такого подхода является то, что с маршрутизируемыми адресами мы можем позволить двум новым машинам работать в роли DNS серверов для  нашего домена example.com: один в качестве master, а другой в качестве авторитатрного slave1.

Замечание:

Для DNS, всегда имеет смысл иметь, по крайней мере, один авторитарный  slave сервер где-то за пределами  вашей сети (фактически,  некоторые  домены  верхнего  уровня  не  позволяют  зарегистрироваться  без  него).  Вы  тоже  самое  можете организовать для резервного почтового сервера, который будет в другом месте. Имейте это ввиду, когда строите свою сеть.

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

1.   Фактически,  example.com  находится  в  блоке  192.0.2.0/24,  которые  определяется  в   RFC  3330   используемый  как зарезервированный для использования примера и документации. Мы используем этот  диапазон адресов в основном, чтобы отличать от NAT примеров в этой книге, которые используют адреса в частном адресном пространстве RFC 1918.

Рисунок 5-1. Базовая сеть с серверами и клиентами внутри одной сети

С базовыми параметрами сети мы можем приступить к настройке разумных  наборов правил для обработки сервисов, которые нам нужны. Еще раз, мы начинаем от базового набора правил и добавляем несколько макросов для удобства чтения. Макросы, которые нам нужны, естественно, возьмем из спецификации:

·                     Web server: webserver = "192.0.2.227"

·                     Web server services:

webports = "{ http, https }"

·                     Mail server: emailserver = "192.0.2.225"

·                     Mail server services:

email = "{ smtp, pop3, imap, imap3, imaps, pop3s }"

·                     Name servers:

nameservers = "{ 192.0.2.221, 192.0.2.223 }"

Будем считать, что файловый сервер недоступен для внешнего мира, если  мы хотим установить его, как сервис за пределами локальной сети, например, авторитетный 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-прокси предназначена для защиты от syn-флудных атак, которые могут привести к истощению ресурсов на бэкэнде(back end). Вот как это работает: когда  новое соединение создано, PF нормально позволяет соединению установиться, просто пропускает пакеты, если они совпадают с набором правил позволяющих их. С включенным syn-прокси PF во время первоначального соединенеия позволяет соединиться с партнерами только один раз, подтверждая, что он  правильно установлен, по существу создавая буфер между соединением с партнером. Syn проксирование немного затратнее, чем состояние по умолчанию, но не всегда заметно, насколько  разумно дальше масштабировать оборудование.

Потенциальные  недостатки  проявляются  в  настройках  балансировки  нагрузки  где  SYN-проксирование  PF  может принимать соединения на бэкэнд не готовый к приему, в некоторых случаях короткого замыкания резервирование путем создания соединения с другими хостами, чем выбранная логика балансировки нагрузки. Это особенно очевидно в таких протоколах как SMTP, где встроенное резервирование подсказывает, что если основной почтовый сервер не принимает соединения, вы должны попробовать вместо него вторичный.

При  рассмотрении  вопроса  установки,  где  syn-прокси  кажется  привлекательным,  имейте  эти  вопросы  ввиду  и анализируйте потенциальное влияние на вашу установку, которая может поступать от  syn-прокси добавляя мешанины. Если вы решили, что SYN проксирование нужно, просто лавируйте на состояния syn-прокси в конце правил, в нужных опциях.

Наконец, серевера имен должны быть доступны для клиентов за пределами нашей сети, которые смотрят на информацию о example.com и любых других доменов для которых мы являемся авторитетным:

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

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

ext_if = "ep0" # macro for external interface – use tun0 or pppoe0 for PPPoE int_if = "ep1" # macro for internal interface

localnet = $int_if:network webserver = "192.0.2.227" webports = "{ http, https }" emailserver = "192.0.2.225"

email = "{ smtp, pop3, imap, imap3, imaps, pop3s }" nameservers = "{ 192.0.2.221, 192.0.2.223 }" client_out = "{ ssh, domain, pop3, auth, nntp, http,\ https, cvspserver, 2628, 5999, 8000, 8080 }" udp_services = "{ domain, ntp }"

icmp_types = "{ echoreq, unreach }" 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 N.M. Hansteen, Перевод выполнил Михайлов Алексей aka iboxjo

Похожие посты:

Вы можете оставить комментарий, или ссылку на Ваш сайт.

Оставить комментарий