Mikrotik arp reply only

Mikrotik arp reply only

Что такое Quick Set?

Quick Set — это мастер автоматической конфигурации, который помогает быстро, не погружаясь в глубины тонкой настройки RoS, настроить роутер и начать им пользоваться. В зависимости от устройства, вам могут быть доступны несколько шаблонов:

  • CAP — Режим управляемой точки доступа, требует наличия настроенного CAPsMAN
  • CPE — Режим WiFi клиента, когда интернет вам приходит по WiFi
  • HomeAP [dual] — Режим домашней точки доступа, тут количество настроек уменьшено, а их названия приближены к сленгу «домашних пользователей»

  • PTP Bridge APCPE — Режим организации беспроводного моста, одна точка настраивается в AP, остальные в CPE
  • WISP AP — Почти то-же, что и HomeAP, но настроек больше, и названия более «профессиональные»
  • Basic AP — Почти пустая конфигурация, подходит для развертывания автономно управляемых точек доступа (без CAPsMAN)
  • Дальше мы будем в основном настраивать HomeAPWISP AP, но советы пригодятся и в других конфигурациях.

    Безопасность

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

    Доступность на внешних интерфейсах

    Отключаю не нужные в домашней сети (и не во всех не домашних сетях) сервисы, а оставшиеся ограничиваю областью действия, указывая адреса, с которых можно к этим сервисам подключится.

    Следующим шагом, будет ограничение на обнаружение роутера с помощью поиска соседей. Для этого, у вас должен быть список интерфейсов, где данный протокол может работать, настроим его:

    Добавим в список discovery интерфейсы, на которых мы хотим, чтобы протокол Neighbors Discovey работал.

    Теперь настроим работу протокола, указав список discovery в его настройках:

    В простой, домашней конфигурации, в списке discovery могут быть интерфейсы, на которых может работать протокол доступа по MAC адресу, для ситуаций, когда IP не доступен, поэтому настроим и эту функцию:

    Теперь, роутер станет «невидимым» на внешних интерфейсах, что скроет информацию о нем (не всю конечно), от потенциальных сканеров, и даже, лишит плохих парней легкой возможности получить управление над роутером.

    Защита от DDoS

    Теперь, добавим немного простых правил в пакетный фильтр:

    И поместим их после правила defcon для протокола icmp.

    Результатом будет бан на сутки для тех, кто пытается открыть более 15 новых соединений в секунду. Много или мало 15 соединений, вопрос спорный, тут уже сами подбирайте число, я выбрал 50 для корпоративного применения, и таких банит у меня 1-2 в сутки. Вторая группа правил гораздо жестче, блокирует попытки соединений на порт ssh(22) и winbox(8291), 3-и попытки за минуту, и отдыхай сутки ;). Если вам необходимо выставить DNS сервер в интернет, то подобным правилом можно отсекать попытки DNS Amplification Attacks, но решение не идеальное, и ложно-положительных срабатываний бывает много.

    RFC 1918

    RFC 1918 описывает выделение адресных пространств для глобально не маршрутизируемых сетей. Поэтому, имеет смысл блокировать трафик отк таким сетям, на интерфейсе, который смотрит к провайдеру, за исключением ситуаций, когда провайдер выдает вам «серый» адрес.

    Поместите эти правила ближе к началу и не забудьте, добавить в список WAN интерфейс, смотрящий в сторону провайдера.

    А вот набор маршутов в «черную дыру»

    Этот набор маршрутов направит весь трафик до сетей RFC 1918 в «черную дыру», однако, если будут маршруты с меньшей метрикой, то такой трафик пойдет через эти маршруты. Полезно для гарантии того, что приватный трафик не просочится во внешнюю сеть.
    За совет благодарим achekalin

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

    SIP Conntrack

    Кроме всего прочего, стоит отключить модуль conntrack SIP, который может вызывать неадекватную работу VoIP, большинство современных SIP клиентов и серверов отлично обходятся без его помощи, а SIP TLS делает его окончательно бесполезным.

    IPv6 туннели

    Если вы не используете IPv6 или не хотите что-бы рабочие машины с Windows поднимали IPv6 туннели без спроса, тогда заблокируйте следующий трафик:

    За совет опять благодарим achekalin

    Динамические и вложенные списки интерфейсов

    Эта функция появилась совсем недавно (с версии 6.41), и она очень удобная. Однако, есть неприятный баг (я о нём сообщил, но его еще не исправили), суть в том, что после презапуска роутера, правила файрволла, которые используют эти списки, не работают для интерфейсов входящих в дочернии списки. Лечится передобавлением дочерних списков. Автоматизация простая:

    В Sheduler на событие start пишем скрипт (списки интерфейсов для конфигурации с балансировкой):

    Читайте также:  Как можно восстановить данные с жесткого диска

    В городской среде, когда эфир крайне зашумлен, имеет смысл отказаться от каналов в 40MGhz, это увеличивает удельную мощность сигнала на канале, так как 40MGHz канал по сути, это два канала по 20MGHz.

    Bridge & ARP

    Если у вас роутер раздает интернет и дает клиентам настройки по DHCP, имеет смысл установить настройку arp=reply-only, а в DHCP Server включить add-arp=yes

    Такая настройка помешает выставить IP адрес вручную, так как роутер согласится работать только с той парой MAC-IP, которую выдавал сам.

    В Mikrotik уже неоднократно напоминали о необходимости своевременно обновления. К сожалению, большинство владельцев пропускают данную информацию мимо ушей и не уделяют ей должного внимания.

    Ситуация, с которой я столкнулся, вынуждает еще раз написать о необходимости обновления RouterOS, а также использования «правильных» настроек RouterOS. Также мы поговорим о том, чем чревато невыполнение этих рекомендаций.

    Всё началось с одного из уведомлений Mikrotik, в котором говорилось о массовом сканировании сети на предмет использования маршрутизаторов под управлением RouterOS. Что это дает? Во-первых, возможность эксплуатации более старых уязвимостей, во-вторых – формирование базы с IP-адресами устройств RouterBOARD.

    И вот, буквально на днях, Mikrotik заговорили о критическом баге версий 6.29-6.42, который позволяет заполучить файл базы данных и расшифровать связку логин@пароль администратора устройства. Собственно подробностей в компании не сообщили, в интересах клиентов.

    Многие успешно обновились и попросту забыли про данный баг. Но на этом история не заканчивается. Буквально вчера я наткнулся на специализированное программное обеспечение для поиска уязвимостей внутри сети.

    Свои устройства я давно обновил, так что настроен был очень скептически.

    Изначально я запустил процесс сканирования для своей сети, которая состоит из 9 подсетей. Поиск принес первые «плоды» – один из доверенных клиентских Mikrotik’ов, подключенный по L2TP+IPsec оказался со старой версией ROS. Но это не все… программа отобразила для него логин и пароль. Устройство было не наше, а одной из фирм, которая разрабатывает для фирмы, в которой я работаю, программное обеспечение. Логин и пароль подошли, что позволило мне успешно авторизоваться на чужом устройстве.

    Пакостить я, конечно же, не стал и сразу же уведомил владельцев данного устройства.

    Далее было принято решение запустить поверхностный скан локальной подсети местного провайдера (пара подсетей 192.168.х.х). То, что я увидел, меня шокировало – 58 устройств с критическими проблемами безопасности. Сам софт сканирует уязвимость не только микротиков, но и других устройств.
    Структура проблемных устройств, которые мне удалось обнаружить в локальной сети, следующая:

    • ASUS – 24;
    • Mikrotik – 16;
    • TP-Link – 5;
    • Edimax – 3;
    • Totolink – 2;
    • Камеры Hikvision – 2;
    • Камеры Hipcam – 2;
    • DD-WRT – 1;
    • Tenda – 1;
    • Upvel – 1;

    Как видим, абсолютный рекордсмен ASUS, в частности это модели RT-N10, RT-N10E, RT-N10P, RT-N10PV2, RT-N10U, RT-N12, RT-N12+, RT-N12E, RT-N12LX, RT-N12VP и даже топовые RT-AC51U и RT-N66U. Я не думаю, что пользователи намеренно открывали доступ к WebUI из WAN, скорее всего это баг прошивок.

    Второе место по количеству уязвимых устройств занимает Mikrotik. Забавно, правда? И корень проблемы даже не в баге RouterOS. К сожалению, большинство пользователей попросту не разбираются в правилах Firewall.

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

    Многие из тех, кто считают себя «продвинутыми» пользователями, начинают бороздить просторы интернета в поисках «идеальных» и «правильных» правил для Firewall. В процессе такой настройки пользователи сносят стандартную конфигурацию, заменяя её правилами из публикаций. Зачастую пользователи даже не понимают суть правил, которые добавляют. Как итог, пользователь получает открытые наружу порты WebFig и winbox! Неожиданно, правда?

    Ради интереса я зашел на несколько устройств, найденных софтом – все учетные данные давали успешный вход. Наибольший интерес у меня вызвали устройства с нестандартными логинами и очень сложными паролями для входа. Владельцы данных устройств явно имеют более высокий уровень понимания RouterOS.

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

    На одном из таких устройств я обнаружил PPP-подключение, и не просто на IP, а на доменное имя очень крупной и известной компании. Нужно срочно уведомить владельца, но как это сделать? В параметрах RouterOS я обнаружил настройки e-mail, что и позволило мне найти контакты владельца, копию письма я отправил администратору компании, к ресурсам которой подключено устройство.

    Какими могли быть последствия? Как минимум, некий школьник мог без проблем сбросить конфигурацию – потеря не велика и клиент списал бы все на ошибку ПО. Мог быть и другой сценарий – настройка прокси-сервера, подмена DNS, перехват личных данных и слив файлов на внешнем накопителе (если он подключен к Mikrotik). При желании, злоумышленник может даже поднять VPN-сервер, настроить маршрутизацию и заходить в вашу сеть.

    Читайте также:  Candy gc4 1061d 07

    Худший сценарий? Злоумышленник выгружает конфигурацию в RSC-файл и начинает изучение. Что интересного можно найти в файле конфигурации? Очень много… в том числе пароль для PPP-подключения, статические маршруты в удаленную сеть, DNS-записи при их наличии.

    Все это было в конкретном случае – и данные VPN, и записи DNS для доступа к сервисам компании в удаленной сети, и все маршруты. По сути, сочетание неправильных правил Firewall и баг в RouterOS позволили бы потенциальному злоумышленнику получить полный доступ в удаленную сеть предприятия.

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

    Владелец был незамедлительно уведомлен, после чего выполнил обновление ROS и полную смену паролей.

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

    Сейчас вы, наверное, подумаете, мол, это локальная сеть (все устройства за NAT провайдера) и тут никто не станет рисковать, да и в случае чего злоумышленника можно вычислить по логам. Во-первых, если к WAN есть доступ из локальной сети, значит при использовании «белого IP», будет доступ из Интернет, c любой точки мира. Во-вторых, при перезагрузке RouterOS по-умолчанию очищает логи, если не указано хранение на диск, либо не настроена выгрузка на внешний сервер.

    Осознаете суть и масштаб проблемы?

    В этом плане провайдеры, предоставляющие выход в сеть через NAT хотя-бы частично защищают клиента, те же клиенты у кого на WAN-интерфейсе сразу белый IP – могут рассчитывать только на себя.

    Вот пример сканирования внешней подсети того же провайдера:

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

    Но и это еще не все. по одному из логинов я заподозрил маршрутизатор одного из провайдеров, и не ошибся… собственно смотрите сами:

    Да, это CCR1036. Названия интерфейсов скрыты в интересах пострадавшей стороны.

    В логах видно, что кто-то из Интернет упорно брутфорсит маршрутизатор… Собственно, представители компании уже оповещены.

    Возникает закономерный вопрос, что делать дальше?

    Рекомендации по повышению защиты RouterOS и Mikrotik

    #1: обновитесь до версии RouterOS 6.42.1 и выше

    Первым делом обновите версию RouterOS на ВСЕХ ваших устройствах, критический баг исправлен в 6.42.1. Если же у вас версия ниже 6.29, о безопасности паролей волноваться не стоит, тем не менее, в старых версиях есть и другие уязвимости, так что в любом случае выполняйте обновление.

    Регулярно следите за выпуском обновлений.

    #2: смените ВСЕ пароли

    На текущий момент не существует возможности гарантированно определить, была ли утечка данных. Единственный способ – просмотр логов на предмет успешных входов со сторонних IP и подсетей. Следует понимать, что ROS очищает лог при каждой перезагрузке устройства.

    Правильное действие – полная смена всех паролей, которые использовались на устройстве, начиная с пароля админа, заканчивая паролем Wi-Fi и паролями VPN-подключений.

    #3: используйте стандартные правила Firewall

    Всё предельно просто – если вы не разбираетесь в тонкостях работы Firewall и не понимаете сути правил, воздержитесь от сторонних инструкций, используйте стандартную конфигурацию RouterOS со стандартными правилами Firewall. Они самодостаточные.

    Стандартные правила имеют следующий вид:
    Где ether1 – это ваш WAN-интерфейс.

    Иногда имеет смысл добавить блокировку доступа к DNS роутера, делает это запретом доступа к 53-му порту на WAN-интерфейсе.
    Само запрещающее правило надо поднять выше других разрешающих правил.

    В случае, когда используется функционал VPN-сервера, потребуется открыть дополнительные порты. К примеру, для L2TP+IPsec потребуется следующее правило:
    Порт 4500 открывать не требуется, если ваши VPN-клиенты не находятся за NAT провайдера. В идеале, порты следует открывать только для IP из «Address List», который заранее необходимо создать и внести в него подсети провайдера, из которого будут подключаться ваши клиенты. Если же вы в разъездах, данный вариант вам не подойдет.

    RSC-файл для удобного импорта правил:

    #4: отключите все неиспользуемые сервисы

    #5: используйте www-ssl вместо www

    Обычный HTTP можно заменить на HTTPS, делается это все там же в подменю IP – Services.

    Заранее вам потребуется создать самоподписный сертификат, делается это в разделе System – Certificates.

    После заполнения формы нажмите последовательно Apply (применить) и Sign (подписать), в появившемся окне нажмите Start.

    При заполнении формы можно указывать как IP роутера, так и его DNS-имя. В поле Days Valid необходимо указать период действия сертификата в днях, по желанию можно сразу создать сертификат на несколько лет.

    Читайте также:  Простые программы для работы с видео

    Далее созданный сертификат укажите в выпадающем списке для www-ssl.

    #6: ограничивайте доступ к сервисам

    Также рекомендуется ограничивать список IP и подсетей, с которых разрешено подключение к сервисам управления. В подменю IP – Services при редактировании сервисов заполните поля Available From.

    При заполнении будьте внимательны, т.к. установив неправильный IP или подсеть, вы потеряете возможность управления устройством. Также можно указывать несколько подсетей и/или IP, что будет удобно в больших предприятиях.

    Обратите внимание, при использовании VPN, например L2TP, в качестве IP/подсети следует указывать адресное пространство, используемое внутри туннеля, а не удаленную подсеть! В противном случае вы не получите доступ. Собственно тут все просто, для роутера важен первый промежуточный узел, с которого осуществляется доступ. Если запутались – воспользуйтесь трассировкой маршрута (tracert).

    #7: отключите admin

    #8: отключите UPnP

    #9: для Wi-Fi используйте исключительно WPA2-PSK + AES

    #10: управляйте сетью при помощи DHCP

    В больших сетях имеет смысл не просто отказаться от «ручных» настроек сети, но и вовсе запрещать подобные действия. Многие правила могут основываться на IP, поэтому в больших сетях следует доверять назначение IP исключительно DHCP-серверу.

    Заходим в IP – DHCP Server и устанавливаем опцию «Add ARP for Leases».

    Далее в настройках бриджа установите «ARP: reply only». После установки этих параметров, микротик будет обрабатывать запросы только от тех устройств, для которых IP выдан DHCP-сервером и они внесены в таблицу ARP.

    С hAP ac2 данный трюк у меня не прошел, устройства попросту не имели доступа к сети. Как вариант решения – установка reply-only непосредственно на wan-интерфейсах.

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

    В случаях, когда требуется статический IP, просто привяжите IP-адрес к MAC-адресу устройства. Делается это в разделе IP- DHCP Server – Leases, выбираете нужное устройство и нажимаете Make Static, после этого можно будет задать для устройства любой IP.

    Каждый раз при подключении к сети, ваше устройство будет получать один и тот же IP.

    #11: не давайте гостям пароль от своего Wi-Fi

    #12: обезопасьте гостевой Wi-Fi

    #13: изолируйте гостей друг от друга

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

    Делается это в настройках wlan, путем отключения опции «Default Forward».

    Обратите внимание, для внутренней домашней сети этого делать не стоит.

    #14: изолируйте гостей от внутренней подсети

    Одна из самых главных рекомендаций, которые касаются гостевой подсети – её полная изоляция от основной сетевой инфраструктуры.

    Один из вариантов описан в моей публикации по Guest Wi-Fi. Если коротко, гости используют отдельный бридж и отдельную подсеть, дополнительно настроены правила, запрещающие доступ из одной сети в другую (IP – Routes – Rules, правило с «action: unreachable»).

    Видеокурс «Настройка оборудования MikroTik» (аналог MTCNA)

    Учитесь работать с MikroTik? Рекомендую видеокурс «Настройка оборудования MikroTik». В курсе разобраны все темы из официальной учебной программы MTCNA и много дополнительного материала. Курс сочетает теоретическую часть и практику – настройку маршрутизатора по техническому заданию. Консультации по заданиям курса ведет его автор Дмитрий Скоромнов. Подойдет и для первого знакомства с оборудованием MikroTik, и для систематизации знаний опытным специалистам.

    Сайт обо мне и обо всем

    Mikrotik — Dynamic ARP Inspection

    Dynamic ARP Inspection — технология (by Cisco), позволяющая пропускать ARP-запросы только для тех адресов, которые были выданы по DHCP. Данная технология помогает защититься от атак с использованием протокола ARP (например, ARP-spoofing) и ограничивает пользователей в возможности указания IP адреса «вручную».

    Суть технологии сводится к двум этапам:
    1) Перехват всех ARP-запросов и ARP-ответов прежде чем перенаправлять их;
    2) Проверка соответствия MAC-адреса и IP-адреса из статической ARP таблицы, либо таблицы выданных адресов DHCP.

    Как оказалось, в маршрутизаторах от Mikrotik нашлась возможность реализовать данную технологию.

    Для настройки необходимо:
    1. В конфигурации «IP -> DHCP Server» поставить галочку «Add ARP For Leases». При выборе этой опции DHCP сервер будет автоматически добавлять записи в ARP-таблицу маршрутизатора;
    2. В настройки интерфейса (бриджа) необходимо для ARP выставить reply-only. Эта опция переведет таблицу ARP на выбранном интерфейсе (бридже) в режим «только чтение» и не будет принимать ARP-запросы.

    Таким образом, маршрутизатор будет коммутировать только те пакеты, для которых DHCP добавит ARP запись.

    Ссылка на основную публикацию
    Adblock detector