Почему при настройке роутера мы выбираем block bogon networks

Обновлено: 10.01.2025

C WIKI mikrotik пропал список BOGON сетей, сохраню его тут и дам краткое описание:

Цитата
/ip firewall address-list add list="BOGONS" address=0.0.0.0/8 add list="BOGONS" address=10.0.0.0/8 add list="BOGONS" address=100.64.0.0/10 add list="BOGONS" address=127.0.0.0/8 add list="BOGONS" address=169.254.0.0/16 add list="BOGONS" address=172.16.0.0/12 add list="BOGONS" address=192.0.0.0/24 add list="BOGONS" address=192.0.2.0/24 add list="BOGONS" address=192.168.0.0/16 add list="BOGONS" address=198.18.0.0/15 add list="BOGONS" address=198.51.100.0/24 add list="BOGONS" address=203.0.113.0/24 add list="BOGONS" address=224.0.0.0/3

Цитата

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

Описание BOGON сетей:
Bogon IP или Bogon network - это зарезервированные диапазоны IP адресов, которые не маршрутизируются в Интернет:

0.0.0.0/8
Диапазон описан в RFC1122 , RFC3330 и RFC1700 как "Этот хост в этой сети" (this host on this network), хотя, учитывая варианты применения, правильнее было бы назвать его как "любой адрес". В частности, IP-адрес 0.0.0.0 используется для:
- обозначения в конфигурационных файлах серверов и выводе netstat информации о том, что определенный сервис "слушает" запросы на всех IP-адресах данного сервера;
- конфигурации маршрута по умолчанию на активном сетевом оборудовании;
- использования в качестве src address в запросах на получение IP-адреса (DHCPDISCOVER);
- обозначения IP-адреса в суммаризованных событиях безопасности IDS/IPS/WAF/etc (например, TCP Host Sweep - обозначение dst host в случае инициации коннектов к большому количеству IP-адресов).

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
Три вышеописанных диапазона не маршрутизируются в Интернет, поскольку зарезервированы под организацию локальных сетей ИТ-инфраструктуры компаний. Описаны изначально в RFC1918 . При этом любая организация вправе использовать любой из вышеописанных диапазонов для IP-адресного плана либо все вместе на свое усмотрение. Для взаимодействия с внешними ресурсами и партнерами во избежание пересечения адресного пространства должен использоваться NAT.

100.64.0.0/10
В соответствии с RFC6598 , используется как транслируемый блок адресов для межпровайдерских взаимодействий и Carrier Grade NAT. Особенно полезен как общее свободное адресное IPv4-пространство RFC1918, необходимое для интеграции ресурсов провайдеров, а также для выделения немаршрутизируемых адресов абонентам. Конечно, в последнем случае никто не мешает использовать RFC1918 - на откуп сетевым архитекторам.

127.0.0.0/8
В случае, если сервису необходим для работы функционирующий сетевой стек, который не будет давать сбоев при отключении от сети, используются loopback-адреса. Выделение 127.0.0.0/8 под внутренние loopback-адреса определено в RFC1122 . В отличие от адресов RFC1918 и RFC6598, адреса для loopback не должны присутствовать и обрабатываться ни в одной сети, только во внутренней таблице маршрутизации хоста.

169.254.0.0/16
В соответствии с RFC3927 , определен как Link-Local для автоматической конфигурации. Думаю, каждый человек хоть раз в жизни, но успел столкнуться с ситуацией, когда ПК, не получив IP-адрес от DHCP-сервера, присваивает сам себе непонятный и нигде не прописанный ранее IP, начинающийся на 169.254. Это и есть реализация рекомендаций из RFC3927.

192.0.0.0/24
Блок не встречается в повседневной жизни, поскольку зарезервирован под IANA для нужд IETF в соответствии с RFC6890 .

198.18.0.0/15
Диапазон выделен под лаборатории нагрузочного тестирования (Benchmarking) в соответствии с RFC2544 и уточнением в RFC6815 , что данный диапазон не должен быть досутпен в Интернет во избежание конфликтов. Опять же, никто при этом не отменяет использование RFC1918, но для больших сетей с крупными лабораториями лишний блок /15 явно не помешает.

224.0.0.0/4
Этот диапазон в исторической классификации еще называется как Class D. Выделен под Multicast, уточнение специфики работы которого тоже вроде как отдельная заметка. В RFC5771 подробно расписано использование подсетей внутри блока, но суть остается той же: эти адреса не закреплены ни за каким провайдером, и, соответственно, через Интернет не должны светиться.

240.0.0.0/4
В соответствии с RFC1122 , данный диапазон IP-адресов, исторически также известный как Class E, зарезервирован под использование в будущем. Юмор ситуации в том, что RFC1122 издавался еще в августе 1989 года, сейчас 2016 год, IPv4-адреса закончились, но для IETF будущее еще не наступило, потому что из всей большой подсети /4 до сих пор используется только один адрес. Но, наверное, если посчитать статистику по всем подсетям всех организаций мира, этот адрес окажется в лидерах, потому что сервисы, использующие broadcast, обращаются к адресу 255.255.255.255, который и принадлежит описанному диапазону.

Межсетевой экран:Лженастройки и ошибки при настройке файрвола

Предупреждение: В статье описана информация о том как НЕ надо настраивать файрвол и статья не содержит информацию о том как надо настраивать файрвол.

Содержание

Введение

Лженастройки

Эту категорию лженастроек я характеризую так: «Эта статья в Интернет выглядит умной. Я тоже хочу внедрить у себя такое». Администраторы берут какие-то настройки и абсолютно не понимая, что это, зачем это и с чем это едят копируют настройки к себе. Чаще всего встречаются следующие чудо-настройки.

BOGON

Описание

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

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

Развенчание мифа

У таких сетей есть один очень важный нюанс, который я еще ни разу не встречал что бы учитывали: Ни 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-трафик.

Правило, блокирующее invalid-трафик обязательно должно идти вторым сразу за правилом, которое разрешает established и трафик. Если сделать, например, так:

то мы рискуем получить уязвимость в виде возможности посылать на нас нелегитимный ICMP-трафик. И произойдет это следующим образом:

Первый вредоносный пакет у которого в качестве источника будет указан адрес из любой сети, в т. ч. и из BOGON, будет обработан на втором правиле, которое разрешает ICMP-трафик. Простым языком: кто-то будет слать якобы ответ на ping-запросы, которые на самом деле не отправлялись.
Все дальнейшие пакеты будут обработаны самым первым правилом, которое разрешает established & трафик.
До правила блокирующего invalid трафик дело уже не дойдет. А именно оно должно было бы остановить атаку не зависимо от того откуда идет атака из BOGON сети или из какой-то другой.

Резюме

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

Блокировка TCP-соединений по флагам

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

Правила пустышки

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

Описание

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

Развенчание мифа

С пакетом, который попадает в файервол с таким набором правил происходит одно из двух:

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

Т. е. в любом случае пакет оказывается разрешенным.

Резюме

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

Ошибки

Использование нормально открытого файервола

Описание

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

Проблема

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

Решение

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

Первое правило снижает нагрузку на процессор, т. к. 99% трафика будет проходить через него.
Второе правило блокирует invalid трафик. Что будет если его поместить хотя бы на одну позицию ниже описано в этой статье выше.
Последнее правило блокирует все, что явным образом не разрешено правилами, расположенными между вторым и последним правилом.

Неверный порядок правил

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

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

В этой ситуации правило, которое блокирует SSH-трафик (22-ой порт TCP) не сработает потому, что выше есть правило, которое разрешает любой TCP-трафик.

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

Если рассматривать эту конфигурацию в отрыве от остальных настроек, то кажется, что трафик из «Guest» в «LAN» должен быть заблокирован, но если посмотреть конфигурацию целиком, то можно обнаружить, что сеть 192.168.15.0/24 принадлежит интерфейсу LAN:

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

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

В этом примере есть правило, которое разрешает TCP-трафик с портом назначения 80 и 443. Если рассматривать правило отдельно от остальных, то можно предположить, что из DMZ можно будет попасть в LAN с таким видом трафика. Но по факту это сделать не получится, т. к. выше есть запрещающее правило, которое блокирует любой трафик из DMZ в LAN.

Некорректное использование FastTrack

Многие читали про то, что с помощью FastTrack можно в разы увеличить производительность маршрутизатора. Как правило эту возможность используют в таком виде:

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

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

FastTrack можно и нужно использовать, но не для всего подряд, а точечно выделяя какой-то конкретный вид трафика и пропуская этот выделенный трафик через FastTrack.

Настройка firewall на mikrotik

Firewall на микротик состоит из следующих составляющих, это цепочки (chain) и действия в этих цепочках (Action), а также различные фильтры к трафику который обрабатывается в цепочках.

Firewall Chain

В Mikrotik существуют следующие цепочки

Из описания понятно, что для защиты маршрутизатора нужно использовать цепочку input. А для обработки трафика от пользователей и к пользователям использовать chain forward. Использование Output мне не приходилось.

Firewall Action

В цепочках можно осуществлять следующие действия

Параметр	Действие
Accept	Разрешить
add-dst-to-address-list	Добавить ip назначение в список адресов указанный в Address List
add-src-to-address-list	Добавить ip источника в список адресов указанный в Address List
Drop	запретить
fasttrack-connection	Обрабатывать пакеты включив FastTrack т.е пакеты будут проходить по самому быстрому маршруту, минуя остальные правила firewall и обработку в очередях
Jump	Прыжок, переход на другую цепочку заданную в Jump target
log	Запись в лог
passthrough	Перейти к следующему правилу не делая никаких действий(полезно для сбора статистики)
Reject	Отбить пакет с причиной указанной в Reject with
Return	Вернуть пакет в цепочку из который он пришел
tarpit	захватывает и поддерживает TCP-соединения (отвечает с SYN / ACK на входящий пакет TCP SYN)

Фильтрация в firewall

Фильтрация пакетов которые могут попасть в цепочки может осуществляться по

Dst.Port -порт назначения

In.Interface -входящий интерфейс

Connection.Mark -метка соединения

Примеры настройки firewall

Рассмотрим некоторые примеры по настройки firewall на маршрутизаторе микротик.

Настройка безопасности Микротик

Для начала настроим безопасность на наше маршрутизаторе, Для этого сделаем следующие

1.Запретим пинговать наше устройство

2.Запретим доступ к микротику всем кроме локальной сети и разрешенных ip адресов

Для настройки подключаемся к роутеру с помощью утилиты winbox и идем в меню IP-Firewall. Вкладка Filter Rules и нажимаем добавить.

Запрещаем пинги на наше устройство, для этого, на вкладке general, chain выбираем input protocol icmp

На вкладке Action выбираем drop

Запрещаем доступ к управлению маршрутизатора. Для начала создаем лист с нашими разрешенными адресами, переходим в IP-Firewall, вкладка Address Lists, добавляем новый лист

Дальше создаем новое правило, снова переходим в Filter rules и добавляем его

Затем переходим на вкладку Advanced и в качестве Src. List выбираем созданный лист

В действии Action выбираем разрешить accept.

Можно было не создавать лист, а на вкладке General в параметре Src. Address прописать нашу сеть, просто мне удобнее работать со списками адресов, в будущем для добавления нового адреса нужно его просто добавить в лист allow_ip.

Следующим шагом запрещаем все входящие соединения. Добавляем правило на chain input, и в действии ставим drop. Должно получится следующие

Здесь следует отметить что обработка правил идет сверху вниз, т.е правило запрещающее все подключения должно находится внизу, иначе разрешающие правила не сработают.

Для того что бы поменять местами правило, нужно кликнуть по строке и с зажатой левой кнопкой мыши перетащить его на нужное место.

На самом деле, правило по запрете ping можно было не создавать, т.к последнее правило блокирует все попытки доступа к роутеру, в том числе и пинг.

Доступ пользователей в интернет

Допустим нам нужно дать доступ в интернет только для определенной сети. Для этого создаем два разрешающих правила в chain forward. Первое правило разрешает исходящий трафик из нашей сети

Action ставим accept. Можно как указать Src. Address, так и использовать Address Lists, как мы это делали выше. Следующим правилом разрешаем прохождение пакетов в нашу сеть.

B следующим правилом запрещаем все остальные сети,

Action выбираем drop. В результате получится следующее

Запрет доступа пользователя в интернет

Если нам нужно запретить доступ в интернет определенным пользователям, давайте сделаем это через Address Lists, что бы в дальнейшем проще было добавлять или удалять правила, переходим на вкладку address Lists и создаем список block в который добавим адреса для блокировки.

Создаем запрещающее правило firewall в chain forward, в котором на вкладке Advanced в Src. Address List выбираем наш список для блокировки

В Action выбираем Drop. Теперь, наше правило нужно поставить выше разрешающего правила, иначе оно не сработает, как это сделать я писал выше, в результате получится следующая картина

Аналогично можно запретить доступ к внешним ресурсам, так же создаем список для блокировки, но в настройка firewall уже указываем его в качестве Dst. Address List. Кроме ip адреса в список можно вносить и доменные имена, например если мы хотим запретить доступ пользователей в соцсети, одноклассники или вконтакте.

Доступ только к сайтам

В следующим примере рассмотрим как разрешить пользователям выход в интернет только по 80 и 443 порту и запретить все остальные, для этого создадим разрешающее правило в chain forward, Protocol выбираем tcp и в параметре Dst.Prort указываем разрешенные порты

Тоже самое можно сделать с помощью запрещающего правила, используя оператор отрицания «!», а Action установить drop

Это означает, запретит все порты кроме 80 и 443.

Конечно, все возможности firewall на микротик я показать не смогу, но основные параметры думаю понятны.

Внимание! при настройке firewall на MikroTIK, настоятельно рекомендую проводить их в «Safe Mode» как ее включить описано здесь, в противном случае вы рискуете потерять доступ к маршрутизатору.

Обучающий курс по настройке MikroTik

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Немаршрутизируемые в Интернет адреса (bogon networks) и безопасность

После прочтения заметки о даркнетах , у многих, наверное, возник вопрос: а какие именно IP-адреса не должны маршрутизироваться в Интернет и почему? И немалая часть публики, естественно, может ответить на этот вопрос, не задумываясь, но я, на всякий случай, перечислю список наиболее статичных диапазонов, которые IETF предписывает не использовать в глобальной сети Интернет. Зарезервированные диапазоны также называются Bogon/bogus networks. Официальный перечень описан в RFC6890 , RFC5735 и некоторых других. Также по ссылкам (english) доступны описание и перечень bogon подсетей от Team Cymru.

Три вышеописанных диапазона не маршрутизируются в Интернет, поскольку зарезервированы под организацию локальных сетей ИТ-инфраструктуры компаний. Описаны изначально в RFC1918 . При этом любая организация вправе использовать любой из вышеописанных диапазонов для IP-адресного плана либо все вместе на свое усмотрение. Для взаимодействия с внешними ресурсами и партнерами во избежание пересечения адресного пространства должен использоваться NAT.

В случае, если сервису необходим для работы функционирующий сетевой стек, который не будет давать сбоев при отключении от сети, используются loopback-адреса. Выделение 127.0.0.0/8 под внутренние loopback-адреса определено в RFC1122 . В отличие от адресов RFC1918 и RFC6598, адреса для loopback не должны присутствовать и обрабатываться ни в одной сети, только во внутренней таблице маршрутизации хоста.

Блок не встречается в повседневной жизни, поскольку зарезервирован под IANA для нужд IETF в соответствии с RFC6890 .

Диапазон выделен под лаборатории нагрузочного тестирования (Benchmarking) в соответствии с RFC2544 и уточнением в RFC6815 , что данный диапазон не должен быть досутпен в Интернет во избежание конфликтов. Опять же, никто при этом не отменяет использование RFC1918, но для больших сетей с крупными лабораториями лишний блок /15 явно не помешает.

Этот диапазон в исторической классификации еще называется как Class D. Выделен под Multicast, уточнение специфики работы которого тоже вроде как отдельная заметка. В RFC5771 подробно расписано использование подсетей внутри блока, но суть остается той же: эти адреса не закреплены ни за каким провайдером, и, соответственно, через Интернет не должны светиться.

В соответствии с RFC1122 , данный диапазон IP-адресов, исторически также известный как Class E, зарезервирован под использование в будущем. Юмор ситуации в том, что RFC1122 издавался еще в августе 1989 года, сейчас 2016 год, IPv4-адреса закончились, но для IETF будущее еще не наступило, потому что из всей большой подсети /4 до сих пор используется только один адрес. Но, наверное, если посчитать статистику по всем подсетям всех организаций мира, этот адрес окажется в лидерах, потому что сервисы, использующие broadcast, обращаются к адресу 255.255.255.255, который и принадлежит описанному диапазону.

Если собрать воедино описанный перечень, чем он будет полезен для безопасности сети? Рассматриваем только голый Интернет, а не локальные сегменты корпоративной сети. В корпоративных сетях, построенных на адресах RFC1918 и выходящих в Интернет через firewall, правила определения нелегитимности трафика будут несколько иными.

Мы рассказываем о самых актуальных угрозах и событиях, которые оказывают влияние на обороноспособность стран, бизнес глобальных корпораций и безопасность пользователей по всему миру в нашем телеграм канале.

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

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

Лженастройки

Эту категорию лженастроек я характеризую так: "Эта статья в Интернет выглядит умной. Я тоже хочу внедрить у себя такое". Администраторы берут какие-то настройки и абсолютно не понимая, что это, зачем это и с чем это едят копируют настройки к себе. Чаще всего встречаются следующие чудо-настройки.

BOGON

Описание

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

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

Развенчание мифа

Прежде всего определимся, что такое "BOGON". BOGON — это IP-адреса, которые не должны встречаться в таблицах маршрутизации в Интернет. Этим термином описываются частные и зарезервированные диапазоны адресов. Список этих сетей описывается в RFC 1918, RFC 5735 и RFC 6598. Обратите внимание, что речь идет именно про таблицы маршрутизации устройств у Интернет-провайдеров, а не про все подряд таблицы маршрутизации. Такие адреса часто могут использоваться при DDoS атаках в качестве IP-адреса источника. Помимо просто BOGON есть еще и FULLBOGON про которые почему-то забывают.

Здесь я люблю задавать вопрос. Почему Вы решили заблокировать сеть 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-трафик.

Правило, блокирующее invalid-трафик обязательно должно идти вторым сразу за правилом, которое разрешает established и related трафик. Если сделать, например, так:

Первый вредоносный пакет у которого в качестве источника будет указан адрес из любой сети, в т. ч. и из BOGON, будет обработан на втором правиле, которое разрешает ICMP-трафик. Простым языком: кто-то будет слать якобы ответ на ping-запросы, которые на самом деле не отправлялись.
Все дальнейшие пакеты будут обработаны самым первым правилом, которое разрешает established & related трафик.
До правила блокирующего invalid трафик дело уже не дойдет. А именно оно должно было бы остановить атаку не зависимо от того откуда идет атака из BOGON сети или из какой-то другой.

Резюме

Блокировка TCP-соединений по флагам

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

Правила пустышки

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

Описание

Развенчание мифа

С пакетом, который попадает в файервол с таким набором правил происходит одно из двух:

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

Т. е. в любом случае пакет оказывается разрешенным.

Резюме

Ошибки

Использование нормально открытого файервола

Описание

Проблема

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

Решение

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

Первое правило снижает нагрузку на процессор, т. к. 99% трафика будет проходить через него.
Второе правило блокирует invalid трафик. Что будет если его поместить хотя бы на одну позицию ниже описано в этой статье выше.
Последнее правило блокирует все, что явным образом не разрешено правилами, расположенными между вторым и последним правилом.

Неверный порядок правил

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

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

Если рассматривать эту конфигурацию в отрыве от остальных настроек, то кажется, что трафик из "Guest" в "LAN" должен быть заблокирован, но если посмотреть конфигурацию целиком, то можно обнаружить, что сеть 192.168.15.0/24 принадлежит интерфейсу LAN:

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

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

Некорректное использование FastTrack

После прочтения заметки о даркнетах, у многих, наверное, возник вопрос: а какие именно IP-адреса не должны маршрутизироваться в Интернет и почему? И немалая часть публики, естественно, может ответить на этот вопрос, не задумываясь, но я, на всякий случай, перечислю список наиболее статичных диапазонов, которые IETF предписывает не использовать в глобальной сети Интернет. Зарезервированные диапазоны также называются Bogon/bogus networks. Официальный перечень описан в RFC6890, RFC5735 и некоторых других. Также по ссылкам (english) доступны описание и перечень bogon подсетей от Team Cymru.

Диапазон описан в RFC1122, RFC3330 и RFC1700 как "Этот хост в этой сети" (this host on this network), хотя, учитывая варианты применения, правильнее было бы назвать его как "любой адрес". В частности, IP-адрес 0.0.0.0 используется для:

- обозначения в конфигурационных файлах серверов и выводе netstat информации о том, что определенный сервис "слушает" запросы на всех IP-адресах данного сервера;

- конфигурации маршрута по умолчанию на активном сетевом оборудовании;

- использования в качестве src address в запросах на получение IP-адреса (DHCPDISCOVER);

- обозначения IP-адреса в суммаризованных событиях безопасности IDS/IPS/WAF/etc (например, TCP Host Sweep - обозначение dst host в случае инициации коннектов к большому количеству IP-адресов).

Три вышеописанных диапазона не маршрутизируются в Интернет, поскольку зарезервированы под организацию локальных сетей ИТ-инфраструктуры компаний. Описаны изначально в RFC1918. При этом любая организация вправе использовать любой из вышеописанных диапазонов для IP-адресного плана либо все вместе на свое усмотрение. Для взаимодействия с внешними ресурсами и партнерами во избежание пересечения адресного пространства должен использоваться NAT.

В соответствии с RFC6598, используется как транслируемый блок адресов для межпровайдерских взаимодействий и Carrier Grade NAT. Особенно полезен как общее свободное адресное IPv4-пространство RFC1918, необходимое для интеграции ресурсов провайдеров, а также для выделения немаршрутизируемых адресов абонентам. Конечно, в последнем случае никто не мешает использовать RFC1918 - на откуп сетевым архитекторам.

В случае, если сервису необходим для работы функционирующий сетевой стек, который не будет давать сбоев при отключении от сети, используются loopback-адреса. Выделение 127.0.0.0/8 под внутренние loopback-адреса определено в RFC1122. В отличие от адресов RFC1918 и RFC6598, адреса для loopback не должны присутствовать и обрабатываться ни в одной сети, только во внутренней таблице маршрутизации хоста.

В соответствии с RFC3927, определен как Link-Local для автоматической конфигурации. Думаю, каждый человек хоть раз в жизни, но успел столкнуться с ситуацией, когда ПК, не получив IP-адрес от DHCP-сервера, присваивает сам себе непонятный и нигде не прописанный ранее IP, начинающийся на 169.254. Это и есть реализация рекомендаций из RFC3927.

Блок не встречается в повседневной жизни, поскольку зарезервирован под IANA для нужд IETF в соответствии с RFC6890.

Читайте также: