☰

Структура брандмауэра Vyatta и направление интерфейса

tag-icon • tag-icon router firewall
Структура брандмауэра Vyatta и направление интерфейса

Я только что купилМаршрутизатор Ubiquity Edge ER-8, и я работаю над настройкой брандмауэра. В частности, я запутался в направлении "Local" для интерфейса, который я определил как WAN, и как я могу использовать его, чтобы предотвратить раскрытие протоколов управления маршрутизатором (ssh/https) для внешнего мира.

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

  • В: Трафик, прибывающий в порт
  • Out: Трафик, выходящий из порта.
  • Локальный: трафик, предназначенный для самого маршрутизатора.

У меня есть вопросы:

  1. Будет ли какой-либо "локальный" трафик, кроме как на интерфейсы управления web/ssh? Будет ли ответный трафик, такой как NTP, RIP, DNS masq и т. д., исходящий от самого маршрутизатора, поступать через "локальное" направление?

  2. Если я применю правило, отбрасывающее все пакеты в WAN_LOCAL, заблокирует ли это запросы к интерфейсам управления из WAN, но разрешит запросы из LAN (поскольку набора правил LAN_LOCAL нет)?

  3. Фильтруется ли трафик, поступающий на WAN_LOCAL, сначала WAN_IN? Если у меня есть стандартный фильтр с отслеживанием состояния на WAN_IN (например, принимать ответы NAT, отбрасывать все остальное), устраняется ли необходимость в наборе правил на WAN_LOCAL вообще?

решение1

Симпатичный маршрутизатор.

В1 Ответ: Нет. Единственным трафиком, который будет считаться локальным, будет, как вы упомянули, трафик ssh и webui, а также трафик DHCP-сервера, если вы используете функцию DHCP-сервера маршрутизатора.

Q2 Ответ: Да. Это отбросит весь трафик, предназначенный для маршрутизатора из WAN. Я предлагаю создать правило с именем MgmtAccess (закажите его выше правила сброса), которое разрешает трафик TCP из внешнего источника в случае, если вам нужно удаленно управлять им из другого места. Например, из центра обработки данных или из вашего дома.

Ответ на вопрос 3: Нет. Наборы правил обрабатывают свои правила отдельно друг от друга.

Мне нравится подходить к брандмауэрам с паранойей. Я бы начал с создания трех наборов правил для каждого интерфейса (входящий, исходящий, локальный), с действием по умолчанию для входящего и локального «отбрасывать». Исходящий может быть принят. Затем я бы добавил правила (соблюдая порядок), чтобы разрешить трафик по мере продвижения оттуда. Дайте им хорошие имена. Если eth0 идет в WAN, назовите эти наборы правил WAN_IN, WAN_LOCAL, WAN_OUT. Если eth7 идет в сеть хранения данных, назовите его STORAGE_IN... Вы поняли. Дайте правилам также описательные имена, чтобы упростить управление в дальнейшем.

Уничтожение учетной записи по умолчанию: создайте нового пользователя и удалите исходного. Это предотвратит атаки методом подбора на учетную запись по умолчанию. Относитесь к своим именам пользователей как к паролям. Держите их в секрете. Держите их в безопасности.

решение2

  1. Потенциально. Например, если вы используете маршрутизатор в небольшой сети для кэширования DNS-запросов, то DNS-трафик попадет на ЛОКАЛЬНЫЙ интерфейс. То же самое, если вы используете его для DHCP и любой другой сетевой службы.
  2. См. выше. Если вы хотите использовать маршрутизатор для кэширования DNS-запросов, то вам придется разрешить его LOCAL общаться с WAN, как это делает LAN.
  3. Наборы правил независимы, и для ясности конфигурации может быть полезно явно указать, что именно блокируется. Поэтому я бы предпочел, чтобы все правила указывали намерение. Учитывая это, я бы выбрал WAN_LOCAL.

Некоторое время назад я визуализировал процесс мышления для случая, когда внутри маршрутизатора нет служб, которым требуется доступ к WAN для ER POE8.

Он все еще есть на GitHub, можете посмотреть, поможет ли он вам.

решение3

Чтобы предотвратить несанкционированный доступ к службам маршрутизатора через интерфейс WAN, просто измените пароль по умолчанию для учетной записи администратора (ubnt).

Смотреть статьюСкорость восстановления пароля. Он описывает максимальное время взлома случайного пароля в зависимости от длины пароля и используемых символов.

Например, время, необходимое для взлома B33r&Mugраспределенной сети суперкомпьютеров (NSA), оценивается в 83 дня, в то время как высокопроизводительной рабочей станции потребуется более 2 лет. Это связано с тем, что этот пароль использует заглавные и строчные буквы, а также цифры и специальные символы, при этом оставаясь довольно коротким (8 символов).

Связанный контент