Mikrotik как источник атак типа "усиления DNS" В последнее время натыкаюсь на все больше сообщений о том, что Mikrotik маршрутизаторы используются для проведения атак типа "усиления DNS". Это очень печально, потому что в основном это происходит из-за неп

+1 У меня тоже была атака, так как разрешены удаленные запросы. Я привык работать с djbdns или bind, которые более безопасны. Им стоит добавить разрешенные подсети в их DNS-сервере. К тому же, если память меня не подводит, в более ранних версиях разрешенный удаленный запрос был отключен по умолчанию. Теперь он включен по умолчанию, получается, открытый резолвер получается (верно?). Им нужно четко указать в руководстве или вики о том, как использовать разрешенный удаленный запрос.

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

Пожалуй, возможность разрешать удаленные запросы по интерфейсу (или диапазону IP-адресов) решила бы проблему. Это позволило бы нам настроить ее только для сетевых интерфейсов, и тогда это было бы наиболее полезно, очевидно и очень просто в использовании. Но эй, если я хочу, чтобы это было проще в использовании, значит я не профессионал…

Чем отличаются эти команды (просто примеры!)? /ip dns allow-remote-requests-from=ether2 /ip firewall filter in-interface=ether1 protocol=tcp port=53 action=reject Если добавить первую, это будет ещё одно место, где стоит искать, почему что-то не работает. А в Firewall все ограничения в одном месте. Не нужно пробираться по куче меню, чтобы понять, почему не работает DNS.

Текущая стандартная конфигурация вполне себе хороша, она блокирует всё, что приходит с WAN (я понятия не имею, с какой версии RouterOS это происходит). Вот эта – с SXT, где беспроводной интерфейс по умолчанию должен быть WAN: /ip firewall {
 filter add chain=input action=accept protocol=icmp comment="default configuration"
 filter add chain=input action=accept connection-state=established,related comment="default configuration"
 filter add chain=input action=drop in-interface=wlan1-gateway comment="default configuration"
 ...
} Как видите, входящим пакетам на 53 порту просто не выжить. И если сделать полный сброс до заводских настроек, удалённые DNS-запросы отключаются полностью по умолчанию, так что это тоже нормально. Проблема начинается, когда пользователи начинают ковыряться в конфигурации (я вообще-то не против вас, конечно). И ковыряются, потому что, например, переадресация порта – это распространённая практика. Посмотрите на форум, сколько там тем про проблемы с переадресацией порта. Уверен, что на каждую такую тему здесь, есть тысячи пользователей по всему миру, делающих то же самое и совершенно ломая свою файрвол в процессе. Если они случайно отключат правило блокировки, то никогда и не заметят, потому что с их точки зрения ничего не сломается. Так что, как бы безопасно ни была стандартная конфигурация, это не значит много. Люди всё равно сломают её, и MikroTik тут мало что может сделать. Разве что эта старая идея могла бы немного помочь: Feature request: DNS setup for local networks, к сожалению, на неё не последовало никакой обратной связи от MikroTik. Но если бы в стандартную конфигурацию была включена предлагаемая опция allow-remote-requests=localnets, то было бы не так просто открыть DNS-разрешитель всему миру. Это бы не остановило тех, кто хочет этого сделать, но случайного открытия не произошло бы, если бы кто-то просто играл с правилами файрвола.

Да, но не потому, что пришло с WAN. Запрос DNS, возникший в LAN, тоже будет новым. В цепочке ввода соединение новое, потому что оно возникло извне «мозга» Mikrotik. Новое соединение — это новое соединение, независимо от того, из какого интерфейса оно произошло. Помни – WAN или LAN-интерфейса как такового на самом деле нет. Роутер — это просто «комната, полная дверей», и это просто условность, которая говорит: «это передняя дверь», а «это задняя дверь». Типичная базовая цепочка ввода брандмауэра выглядит так:

1. Разрешить установленные и связанные соединения (т.е. разрешить ответы на сокеты, которые я запросил).
2. Разрешить in-interface=not wan (т.е. разрешить все новое, но не с интерфейса, обращенного к интернету).
3. Отбрасывать все (если пакет доходит до этого этапа, это новый или недействительный пакет на wan-интерфейсе — отбросить его).

Опция allow-remote-request=yes на DNS-прокси не будет небезопасной с вышеуказанными правилами, потому что если Mikrotik делает DNS-запрос, то ответ разрешается правилом 1, но если ботнет-зомби отправляет пакет DNS-amp запроса к Mikrotik, он не соответствует правилу 1 (tik не запрашивал его) и не соответствует правилу 2 (интерфейс ЯВЛЯЕТСЯ wan), поэтому он доходит до правила 3, которое говорит отбрасывать все.

Жалко, что Mikrotik "из коробки" всё ещё имеет настройки по умолчанию, которыми можно злоупотреблять. Там кто-то должен быть невероятно упёртым, чтобы продолжать устанавливать эту галочку по умолчанию. Как человек, который и чинил Mikrotik у клиентов, и имел дело с DDoS-атаками на 20+ Gb/s (уверен, там участвовало много Miks), просто смешно, что в 2016 году это всё ещё конфигурация по умолчанию. Если отключение resolver ломает что-то, ну что ж, пусть те, кто не может использовать resolvers своего провайдера, разберутся сами, вместо того чтобы быть ещё одним источником мусорного трафика в интернете. #mikrotik #security #ddos