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

Question

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

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

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

Мои вопросы:

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

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

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

Answer 1

Красиво выглядящий роутер.

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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