PfSense для средней сети и настройка правил.

Rearden · May 23, 2014, 6:53 AM

Добрый день!
Коллеги, планирую развернуть pfSense для сети ~100 абонентов (на пике 50mbit download). Схема простая - два аплинка, статически смаршрутизированы ip-адреса. До каждого абонента VLAN. На pfSense будет работать DNS Forwarder, 70% абонентов будут отначиваться. У меня возникают два вопроса:

Справится ли с такой нагрузкой pfSense? CPU: Xeon 2.33GHz; Ram 512 mb; NIC bge;
Как красиво создать правила для запрета http, ssh из внутренней сети?
Дело в том, что действия по созданию и удалению VLAN'ов происходят достаточно часто и использовать Floating Rules, в котором выбирать все интерфейсы, кроме админского и указывать что им запрещено обращаться к http, ssh не очень хороший вариант. Опять же, даже при использовании Floating Rues не ясно как указать запрет доступа ко всем айпи-адресам маршрутизатора не создавая сотню правил (Я имею ввиду то, что создавая VLAN и присваивая ему ип адрес, на нем начинает работать http, ssh, ибо *:80 *:22)

Пока только такие мысли на счет правил:
На каждом интерфейсе сделать так:
(sorry for ipfw syntaxis)


deny ip from $interface_net to me 22,80 in recv $int
allow udp from $interface_net to me 53 in recv $int
allow all from any to not me via $int

Хотя в идеале надо сделать одно правило такого вида:


deny ip from any to me 22,80

и разрешить доступ на эти порты только из админской сети.

Либо повесить ssh, http на конкретные айпишники из админсокго VLAN'а

dvserg · May 23, 2014, 7:25 AM

Добрый день.

Думаю желательно увеличить память до гигабайта.
При составлении правил воспользуйтесь возможностями Alias для группировки IP/портов. Это должно обеспечить более простой вид правил и более простое изменение списков IP/портов в группах через добавление/удаление из через алиасы.

dr.gopher · May 23, 2014, 8:53 AM

@Rearden:

Как красиво создать правила для запрета http, ssh из внутренней сети?

Посмотрите подобное (гтовое) решение обсуждаемое на форуме
http://www.thin.kiev.ua/router-os/50-pfsense/589-pfsense-20-nat.html

обсуждение тут
https://forum.pfsense.org/index.php/topic,47168.0.html

Возможно найдете рациональное зерно.

Rearden · May 23, 2014, 10:41 AM

Господа, спасибо за ответы!

dr.gopher, на данный момент это не то, что требуется. За ссылки спасибо, это определенно пригодится в дальнейшем.

Возможно я не совсем корректно выразился на счет блокирования 22,80. Имеется ввиду, что закрыть эти порты чтобы клиенты не имели доступ к портам конфигурирования роутера.

По умолчанию, при создании VLAN и создании интерфейса, в разделе Firewall/Rules появляется закладка с именем интерфейса, в которой нету правил (запрещено всё). Для того, чтобы работал интернет (НАТ у нас уже настроен) в этом VLAN необходимо прописать правило "Allow on $INTERFACE, source $INTERFACE_NET, dest any, port range other".

Соответственно появляется доступ к портам, на которых весит ssh, http-конфигуратор pfSense.

Подскажите пожалуйста, как сделать следующие правила:

1). "Разрешить доступ на порты 22,80 только на интерфейсе $MANAGEMENT_VLAN и только с $MANAGEMENT_ADDRESS."
и
2). "Запретить доступ на $ALL_ROUTER_ADDRESS порты 22,80 на всех VLAN."
По умолчанию, каждый новый VLAN должен попадать под второе правило.

dvserg · May 23, 2014, 11:23 AM

На сколько я помню раньше доступ на 80/22 порты pfSense был разрешен по умолчанию только для интерфейса LAN, на остальных интерфейсах нужно было разрешать явно. Сейчас разве это не так?

Rearden · May 24, 2014, 7:30 AM

Верно, по умолчанию запрещено всё. Но как только делаем "правило разрешение интернета" на этом интерфейсе появляется доступ и к портам 22/80.

dvserg · May 24, 2014, 7:38 AM

@Rearden:

Верно, по умолчанию запрещено всё. Но как только делаем "правило разрешение интернета" на этом интерфейсе появляется доступ и к портам 22/80.

Ну тогда в чем проблема? Вам подсказать как правильно сделать эти правила? Тогда показывайте, что у Вас есть. Скриншот прикрепляем к посту.

Rearden · May 24, 2014, 7:53 AM

Подскажите пожалуйста.

dvserg · May 24, 2014, 8:19 AM

Для того, чтобы Ваши юзеры не могли попасть на 80/22 порты pfsense в правиле Destination
должно содержать !адрес_интерфейса(ов)
Для того, чтобы Вы со своего IP адреса могли иметь доступ к pfSense - на Вашем рабочем интерфейсе (к которому подключен Ваш компьютер) первым правилом добавить правило разрешения
Source = ваш IP
Destination = IP адрес интерфейса(ов).

Rearden · May 24, 2014, 8:45 AM

Таким образом, если будет сотня VLANов, необходимо на каждом интерфейсе прописать сотню правил, запрещающих доступ на $адрес_интерфейса, 22/80?

dvserg · May 24, 2014, 8:54 AM

@Rearden:

Таким образом, если будет сотня VLANов, необходимо на каждом интерфейсе прописать сотню правил, запрещающих доступ на $адрес_интерфейса, 22/80?

Вы не так поняли. В своем правиле, которое Вы все равно создаете на каждом из интерфейсов,
делайте Destination = !адрес_интерфейса
а не '*'

Rearden · May 24, 2014, 9:46 AM

dvserg, я Вас понял.
Верно, что при указании Destination = !адрес_интерфейса нет возможности коннекта на этот адрес, но сохраняется возможность подключаться к адресам других интерфейсов.

dvserg · May 24, 2014, 10:03 AM

@Rearden:

dvserg, я Вас понял.
Верно, что при указании Destination = !адрес_интерфейса нет возможности коннекта на этот адрес, но сохраняется возможность подключаться к адресам других интерфейсов.

Зависит от доступности из одной локальной подсети в другую. Лучше проверить на рабочем сервере.

Rearden · May 24, 2014, 10:27 AM

Зависит от доступности из одной локальной подсети в другую

dvserg, что Вы имеете ввиду?

Лучше проверить на рабочем сервере.

Давайте проверим.

rubic · May 24, 2014, 11:15 AM

@Rearden:

Подскажите пожалуйста.

@Rearden:

dvserg, я Вас понял.
Верно, что при указании Destination = !адрес_интерфейса нет возможности коннекта на этот адрес, но сохраняется возможность подключаться к адресам других интерфейсов.

В pfSense 2.1.x правило, где явно указан gateway, не пропустит такого подключения, а вот без gateway - пожалуйта. "Weak End System Model" со всеми вытекающими.
Для сведения, в pfSense есть специальная скрытая таблица (алиас со списком IP/mask) <negate_networks>, где прописаны все сети, подключенные к системе. Если в System: Advanced: Firewall and NAT снят флажок "Disable Negate rules" (по умолчанию снят), то перед каждым правилом, где явно указан gateway (policy based routing - PBR), создается скрытое правило разрешающее доступ в эти сети (<negate_networks>).
В pfSense 2.1.x в отличие от 2.0.x таблица <negate_networks>не заполняется и, таким образом, эти правила не работают. Доступа в подключенные сети (и на адреса других интерфейсов pfSense) через правило PBR нет. Скорее всего это просто баг, т.к. в современной версии руководства раздел про Negate Rules присутствует (могут и исправить).

Я лично стараюсь избегать штуковин, которые за сценой что-то делают "для моего же блага". Поэтому флажок System: Advanced: Firewall and NAT -> Disable Negate rules у меня установлен и с правилом подобным вашему я в домике)</negate_networks></negate_networks></negate_networks>

pigbrother · May 24, 2014, 12:01 PM

@rubic

Прошу извинить за вопрос не по теме ветки.

Правильно ли я понимаю, что некорректная обработка Disable Negate rules в 2.1.х (с задействованным PBR) вынуждает добавлять на LAN разрешающие правила для доступа к сетям, подключеныых через, например, OVPN?

rubic · May 24, 2014, 12:31 PM

@pigbrother:

@rubic

Прошу извинить за вопрос не по теме ветки.

Правильно ли я понимаю, что некорректная обработка Disable Negate rules в 2.1.х (с задействованным PBR) вынуждает добавлять на LAN разрешающие правила для доступа к сетям, подключеныых через, например, OVPN?

Ну да, просто ставите это правило выше PBR и все

pigbrother · May 29, 2014, 10:50 AM

@rubic:

@pigbrother:

@rubic

Прошу извинить за вопрос не по теме ветки.

Правильно ли я понимаю, что некорректная обработка Disable Negate rules в 2.1.х (с задействованным PBR) вынуждает добавлять на LAN разрешающие правила для доступа к сетям, подключенных через, например, OVPN?

Ну да, просто ставите это правило выше PBR и все

Следует ли создавать аналогичное правило на OVPN-клиенте 2.1.х для доступа в сеть за сервером?
Клиент без MultiWan\PBR - это пока. Или стоит его добавить заранее - на перспективу?

werter · May 29, 2014, 12:56 PM

@ pigbrother

А что мешает проверить ? Дело одной минуты.

pigbrother · May 29, 2014, 1:31 PM

@werter:

@ pigbrother

А что мешает проверить ? Дело одной минуты.

Клиент и сервер сечас работают в режиме PSK. Я от них далеко, переводить на PKI планирую позже вместе с апгрейдом сервера с 2.0.х до 2.1.3.
Не хочется, чтобы сработала поговорка - "удаленная настройка маршрутизатора - к дальней дороге".