Чек-лист по MikroTik: обратная связь и полезные ссылки

Советы и подсказки по софту, работе в операционных системах, комплектующих и сборок компьютеров.
Аватара пользователя
toxi
Администратор
Администратор
Articles: 0
Сообщения: 504
Зарегистрирован: 12-04-2008 07:58:25
Ваш пол: Мужской
Имя: Роман
Откуда: Украина, г. Житомир
Контактная информация:

Чек-лист по MikroTik: обратная связь и полезные ссылки

Сообщение toxi »

Лженастройки и другие ошибки при настройке файервола
В этом и нескольких следующих постах я расскажу про лженастройки и ошибки при настройке файервола. В тексте будут использованы выдержки из настроек, которые сделаны с помощью командной строки. Если вы привыкли работать с графическим интерфейсом, то просто постарайтесь уделить несколько минут и прочесть, что в них настроено. В своем курсе «Настройка оборудования MikroTik» я учу делать настройки и через графический интерфейс, и через консоль. Но в тексте поста настройки проще описывать в виде выдачи консоли.

На написание этого поста меня навело то, что регулярно, два-три раза в неделю ко мне приходят письма с просьбой оценить настройку файрвола. Как правило, основная масса таких настроек содержит одни и те же ошибки, которые я решил собрать в этом посте. Условно их можно разделить на следующие категории:
  • Лженастройки. Как правило, такие правила никак не влияют на работоспособность сети. Только замусоривают конфигурацию и этим затрудняют ее дальнейший анализ. Иногда могут и навредить. Основной признак этой категории – использование каких-то замысловатых параметров. Иногда такие правила называют "фуфломицином".
  • Правила пустышки. Как правило ничего не делают. Ни хуже, ни лучше. Разве, что потребляют ресурсы процессора на обработку бессмысленных правил. Принципиальное отличие от лженастроек это отсутствие использования замысловатых параметров. Такие правила очень хорошо описываются определением "масло масляное".
  • Ошибки. Название говорит само за себя. Условно можно разбить на подкатегории:
    • Результат, который дают такие настройки не соответствует тому, что изначально ожидалось.
    • Отсутствие понимания того как должен быть настроен файрвол. В результате получается то, что хотели получить изначально, но могут быть проблемы или уязвимости.
Лженастройки
Эту категорию лженастроек я характеризую так: "Эта статья в Интернет выглядит умной. Я тоже хочу внедрить у себя такое". Администраторы берут какие-то настройки и абсолютно не понимая, что это, зачем это и с чем это едят копируют настройки к себе. Чаще всего встречаются следующие чудо-настройки.

Лженастройка №1. Блокировка TCP-соединений по флагам
Эта лженастройка имеет много разных вариаций. В общих чертах она выглядит как попытка заблокировать что-то на основании флага TCP-соединения с помощью опции "tcp-flag". Выглядит это очень умно, можно сказать «прикосновение к таинству». Но зачем это делается никто внятно объяснить не может. У этой лженастройки файрвола на MikroTik много разных вариаций. Обычно их объединяет то, что есть несколько правил в которых обязательно будет встречаться что-то на подобие:

Код: Выделить всё

... protocol=tcp tcp-flags=fin,syn
... protocol=tcp tcp-flags=fin,psh,urg,!syn,!rst,!ack
... protocol=tcp tcp-flags=fin,syn,rst,psh,ack,urg
В следующем посте я расскажу Вам о своей любимой лженастройке файервола под названием «Блокируем BOGON сети».

С уважением, Дмитрий Скоромнов.,
сертифицированный тренер MikroTik,
автор проекта «Курсы-по-ит.рф»
https://курсы-по-ит.рф
+7 499 653-76-01


Чат в Телеграме по MikroTik и не только: @kursy_po_it
Правила форума :: Выполняем сканирование сайтов на наличие вредоносного кода, обращайтесь либо задавайте вопросы в тикет.
Аватара пользователя
toxi
Администратор
Администратор
Articles: 0
Сообщения: 504
Зарегистрирован: 12-04-2008 07:58:25
Ваш пол: Мужской
Имя: Роман
Откуда: Украина, г. Житомир
Контактная информация:

Чек-лист по MikroTik: обратная связь и полезные ссылки

Сообщение toxi »

Моя любимая лженастройка, или "блокируем BOGON сети"
В предыдущем посте я рассказал про классификацию лженастроек файервола (лженастройки, правила пустышки и ошибки) и про лженастройку «Блокировка TCP-соединений по флагам».

В этом посте мы поговорим по мою любимую лженастройку по блокировке BOGON сетей.
Лженастройка №2. BOGON

Описание
Эта настройка находится в топе по популярности среди всевозможных лженастроек файервола. Выглядит она следующим образом: вначале делается список адресов с названием "BOGON" и после этого в файерволе этот самый "BOGON" запрещают для входящего интерфейса.

Через консоль это выглядит примерно так:

Код: Выделить всё

/ip firewall address list
add address=0.0.0.0/8 list=BOGON
add address=10.0.0.0/8 list=BOGON
add address=100.64.0.0/10 list=BOGON
add address=127.0.0.0/8 list=BOGON
add address=169.254.0.0/16 list=BOGON
add address=172.16.0.0/12 list=BOGON
add address=192.0.0.0/12 list=BOGON
add address=192.0.2.0/24 list=BOGON
add address=192.168.0.0/16 list=BOGON
add address=198.18.0.0/15 list=BOGON
add address=198.51.100.0/24 list=BOGON
add address=203.0.113.0/24 list=BOGON
add address=217.67.177.164 list=BOGON
add address=224.0.0.0/3 list=BOGON 

/ip firewall filter
add action=drop chain=input in-interface=WAN src-address-list=BOGON
Развенчание мифа
Прежде всего определимся, что такое "BOGON". BOGON — это IP-адреса, которые не должны встречаться в таблицах маршрутизации в Интернет. Этим термином описываются частные и зарезервированные диапазоны адресов. Список этих сетей описывается в RFC 1918, RFC 5735 и RFC 6598. Обратите внимание, что речь идет именно про таблицы маршрутизации устройств у Интернет-провайдеров, а не про все подряд таблицы маршрутизации. Такие адреса часто могут использоваться при DDoS атаках в качестве IP-адреса источника. Помимо просто BOGON есть еще и FULLBOGON про которые почему-то забывают.

У таких сетей есть один очень важный нюанс, который я еще ни разу не встречал что бы учитывали: Ни BOGON, ни FULLBOGON списки не являются статическими. Диапазоны IP-адресов могут, как добавляться, так и убираться из этих списков. Поэтому BOGON-список актуальный сегодня завтра может оказаться неактуальным и файервол начнет блокировать легитимный трафик.

Здесь я люблю задавать вопрос. Почему Вы решили заблокировать сеть 192.0.2.0/24, но при этом не стали блокировать 192.0.3.0/24 или 192.0.4.0/24 или 192.0.5.0/24? На этот вопрос обычно не могут ответить. Более знающие ссылаются на rfc1166 в котором говорится, что сеть 192.0.2.0/24 зарезервирована для "TEST-NET-1", которая может быть использована в документации или в примерах. На встречный вопрос: "Чем не устраивает нормально закрытый файервол?" как правило ответить уже не могут, т. к. нормальной закрытый файрвол скорее всего уже используется и с этим вопросом приходит понимание, что такое правило это "масло маслянное".

Идем дальше. Допустим, каким-то образом мы получили динамические "BOGON" и "FULLBOGON" списки, которые всегда будут находиться в актуальном состоянии. Может быть тогда блокирование этих самых БОГОНОВ будет иметь смысл? Возможно тогда и будет иметь, но куда проще настроить файервол правильно так, чтобы не требовалось создавать дополнительные правила. Для этого нам достаточно настроить файервол в нормально закрытом режиме и заблокировать invalid-трафик.

В следующем посте я расскажу про правила пустышки.

С уважением, Дмитрий Скоромнов.,
сертифицированный тренер MikroTik,
автор проекта «Курсы-по-ит.рф»
https://курсы-по-ит.рф
+7 499 653-76-01


Чат в Телеграме по MikroTik и не только: @kursy_po_it
Правила форума :: Выполняем сканирование сайтов на наличие вредоносного кода, обращайтесь либо задавайте вопросы в тикет.
Аватара пользователя
toxi
Администратор
Администратор
Articles: 0
Сообщения: 504
Зарегистрирован: 12-04-2008 07:58:25
Ваш пол: Мужской
Имя: Роман
Откуда: Украина, г. Житомир
Контактная информация:

Чек-лист по MikroTik: обратная связь и полезные ссылки

Сообщение toxi »

Продолжаем: "правила пустышки"
В предыдущих двух постах я рассказал про: В этом посте мы поговорим про правила пустышки.

Правила пустышки
В основной своей массе эти правила сводятся к одному: разрешению того, что и так не запрещено.

Описание
Эта категория лженастроек не делает ничего кроме бессмысленного потребления ресурсов маршрутизатора. Выглядит это все примерно так:

Код: Выделить всё

/ip firewall filter
add action=accept chain=input protocol=icmp
add action=accept chain=input dst-port=161 protocol=udp src-address-list=zabbix
add action=accept chain=input dst-port=8291 protocol=tcp
add action=accept chain=input port=500,1701,4500 protocol=udp
add action=accept chain=input protocol=ipsec-esp
...
Далее нет ни одного запрещающего правила

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

Резюме
Рекомендую сделать файервол нормально закрытым. Т. е. в зависимости от конкретной конфигурации в конце должно быть правило, запрещающее все, что отдельно не разрешено. Использовать нормально открытый файервол нельзя, т. к. в этом случае устройство оказывается уязвимым.

В следующем после я расскажу про распространенные ошибки при настройке файервола.

С уважением, Дмитрий Скоромнов.,
сертифицированный тренер MikroTik,
автор проекта «Курсы-по-ит.рф»
https://курсы-по-ит.рф
+7 499 653-76-01


Чат в Телеграме по MikroTik и не только: @kursy_po_it
Правила форума :: Выполняем сканирование сайтов на наличие вредоносного кода, обращайтесь либо задавайте вопросы в тикет.
Аватара пользователя
toxi
Администратор
Администратор
Articles: 0
Сообщения: 504
Зарегистрирован: 12-04-2008 07:58:25
Ваш пол: Мужской
Имя: Роман
Откуда: Украина, г. Житомир
Контактная информация:

Чек-лист по MikroTik: обратная связь и полезные ссылки

Сообщение toxi »

Ошибка N1 в настройке файервола
В предыдущих трех постах я рассказывал про: В этом посте я расскажу про распространенные ошибки при настройке файервола.

Ошибки

Ошибка №1. Использование нормально открытого файервола

Описание
Очень часто неопытные инженеры используют нормально открытый файервол. Например, для цепочки Input правила могут выглядеть так:

Код: Выделить всё

/ip firewall filter
add action=drop chain=input dst-port=53 protocol=tcp
add action=drop chain=input dst-port=53 protocol=udp
add action=drop chain=input dst-port=22 protocol=tcp
add action=drop chain=input dst-port=80 protocol=tcp
add action=drop chain=input ...
add action=drop chain=input ...
add action=drop chain=input ...
add action=drop chain=input ...
...
Прочие запрещающие правила

Проблема
В приведенном выше примере для цепочки Input используется нормально открытый файервол и блокируется то, что по мнению администратора представляет риск. Действительно держать 53-ий порт (DNS) открытым для Интернета это очень большой риск попасть на атаку типа "DNS Resolve" и получить загрузку процессора службой DNS под 100%.

Проблема в том, что при использовании нормально открытого файервола администратор устанет запрещать. Даже, если предположить, что администратор на 100% знает все, что надо запретить, то такую схему лучше не использовать потому, что значительно увеличится количество правил, через которые будет проходит пакет. А чем большее количество правил будет пройдено пакетом, тем выше будет нагрузка на процессор устройства.

Решение
Сделать файервол нормально закрытым. Т. в нем должно быть запрещено все кроме того, что разрешено и будет небольшой "белый" список доступных сервисов. Например, так:

Код: Выделить всё

/ip firewall filter
add action=accept chain=input connection-state=established,related
add action=drop chain=input connection-state=invalid
add action=accept chain=input protocol=icmp
add action=accept chain=input dst-port=8291 protocol=tcp
add action=accept chain=input port=500,1701,4500 protocol=udp
add action=accept chain=input protocol=ipsec-esp
add action=drop chain=input in-interface=WAN
  • Первое правило снижает нагрузку на процессор, т. к. 99% трафика будет проходить через него. Правило обязательно должно быть первым.
  • Второе правило блокирует invalid трафик. Что будет, если его поместить хотя бы на одну позицию ниже описано в этой статье выше. Правило обязательно должно быть вторым.
  • Последнее правило блокирует все, что явным образом не разрешено правилами, расположенными между вторым и последним правилом. Правило обязательно должно быть последним.
В следующем посте я расскажу про ошибку, связанную с неверным порядком правил.

С уважением, Дмитрий Скоромнов.,
сертифицированный тренер MikroTik,
автор проекта «Курсы-по-ит.рф»
https://курсы-по-ит.рф
+7 499 653-76-01


Чат в Телеграме по MikroTik и не только: @kursy_po_it
Правила форума :: Выполняем сканирование сайтов на наличие вредоносного кода, обращайтесь либо задавайте вопросы в тикет.
Аватара пользователя
toxi
Администратор
Администратор
Articles: 0
Сообщения: 504
Зарегистрирован: 12-04-2008 07:58:25
Ваш пол: Мужской
Имя: Роман
Откуда: Украина, г. Житомир
Контактная информация:

Чек-лист по MikroTik: обратная связь и полезные ссылки

Сообщение toxi »

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

Неверный порядок правил
Мне часто присылают какое-то одно правило и спрашивают почему оно не работает. При анализе настроек файервола надо учитывать, что правила обрабатываются по порядку и порядок правил играет роль. Поэтому вполне возможна ситуация, когда мы имеем запрещающее правило и оно не работает потому, что выше есть правило, которое разрешает этот трафик. Либо наоборот: что-то, что разрешено не работает, т. к. выше есть запрещающее правило. Разберем ряд таких ситуаций.

Пример №1
Пример ситуации, когда блокирующее правило не сработает:

Код: Выделить всё

/ip firewall filter
...
add action=accept chain=input protocol=tcp
...
add action=drop chain=input dst-port=22
...
В этой ситуации правило, которое блокирует SSH-трафик (22-ой порт TCP) не сработает потому, что выше есть правило, которое разрешает любой TCP-трафик.

Пример №2
Еще один пример ситуации, когда блокирующее правило не сработает:

Код: Выделить всё

/ip firewall filter
...
add action=accept chain=forward dst-address=192.168.15.0/24
...
add action=drop chain=forward in-interface=Guest out-interface=LAN
...
Если рассматривать эту конфигурацию в отрыве от остальных настроек, то кажется, что трафик из "Guest" в "LAN" должен быть заблокирован, но, если посмотреть конфигурацию целиком, то можно обнаружить, что сеть 192.168.15.0/24 принадлежит интерфейсу LAN:

Код: Выделить всё

/ip address
add address=192.168.15.254/24 interface=LAN network=192.168.15.0
Таким образом мы получаем, что у нас есть разрешающее правило выше запрещающего.

Пример №3
Пример ситуации, когда разрешающее правило не сработает потому, что выше есть запрещающее правило.

Код: Выделить всё

/ip firewall filter
...
add action=drop chain=forward in-interface=DMZ out-interface=LAN
...
add action=accept chain=forward dst-port=80,443 protocol=tcp
В этом примере есть правило, которое разрешает TCP-трафик с портом назначения 80 и 443. Если рассматривать правило отдельно от остальных, то можно предположить, что из DMZ можно будет попасть в LAN с таким видом трафика. Но по факту это сделать не получится, т. к. выше есть запрещающее правило, которое блокирует любой трафик из DMZ в LAN. А вот, если поменять правила местами, то доступ из DMZ в LAN и наоборот по портам 80 и 443 уже будет доступен.

С уважением, Дмитрий Скоромнов.,
сертифицированный тренер MikroTik,
автор проекта «Курсы-по-ит.рф»
https://курсы-по-ит.рф
+7 499 653-76-01


Чат в Телеграме по MikroTik и не только: @kursy_po_it
Правила форума :: Выполняем сканирование сайтов на наличие вредоносного кода, обращайтесь либо задавайте вопросы в тикет.
Ответить