RADIUS — немного о Mikrotik, NPS и не только
Определение, назначение, общие сведения
Позволяет повысить безопасность сети и централизованно управлять доступами.
Сервер RADIUS может иметь свою базу данных с учетными данными (например файлы или mysql) или работать в паре с другим сервером, например Active Directory.
Кроме AAA позволяет передать некоторые дополнительные данные (настройки) клиенту прошедшему аутентификацию, в том числе vendor-specific attributes (VSA). У Mikrotik такие тоже есть, позже пройдемся по самым интересным.
Существуют много популярных приложений радиус сервера, самый популярные: freeRADIUS и Служба NPS (Network Policy Server) Windows Server. Более подробно мы рассмотрим второй вариант.
Компоненты кейса
RADIUS сервер (он же радиус сервер, он же сервер аутентификации).
Настройка
Установку роли описывать не буду, существует 100500 статей в картинках, например: тыц
Добавление радиус клиента на радиус-сервере Нам нужно заполнить «понятное имя», IP адрес и придумать пароль (а.к.а. «секрет»), который понадобится при настройке аутентификатора (mikrotik в нашем случае)
Политики запросов на подключение и Стетевые политики очень похожи при настройке, и нужно понимать разницу между ними. Первые нужны для того что бы при определенных условиях определить сервер на котором будет проходить проверка аутентификации клиента (к примеру локально или на другом удаленном радиус сервере) а так же для некоторых манипуляций с атрибутами. Вторые же позволяют определить набор условий по которым возможно обозначить разрешить или отклонить запроос клиента на подключение.
Политики имеют порядок и обрабатываются по нему одна за другой. Если подключение не соответствует условиям политики, то проверяется следущая и так далее. К примеру, это поможет разделить правила обработки для проводных\беспроводных и впн клиентов.
Добавление политики запросов на подключение
Добавление сетевой политики
Некоторые типовые кейсы применения радиус сервера :
централизованная аутентификация на устройствах поддерживающих aaa
аутентификация для vpn (pptp\l2tp)
аутентификация в wifi
Итак подробнее, + некоторые плюшки. Для всех наших пунктов нам нужно настроить радиус клиента в mikrotik
Теперь можно начинать настраивать интересные вещи.
1. настроим вход на микротик
Стоит уделить внимание параметру default-group он означает группу по умолчанию, в которая применится к пользователю.
Теперь настроим NPS:
А вот так будет выглядеть настройка необходимого нам атрибута, из которого микротик определит в какую группу поместить подключенного пользователя.
Сразу попробуем авторизоваться и видим что попали в нужную группу read
В методах проверки подлинности указываем :
Политика mikrotik-admin-network будет отличаться тем что в условиях выберем группу admins-network а значение отрибута MIKROTIK_GROUP зададим как full Результат ожидаемый, мы залогинились в микротик под полными правами:
Перейдем к впн, и к стразу более интересному сценарию.
В настройки правил форейвола для ограничения доступа подсетей я пожалуй не буду углубляться, подразумевается что вы понимаете как из одной подсети запретить доступ к ресурсу и как разрешить. (с) предпологается, что вы немного сетевик. Касательно примера подсети 10.10.21.0/24 необходимо разрешить форвард в подсети серверов и management а подсети 10.10.22.0/24 необходимо разрешить только доступк корпоративным сервисам, но не к сетям управления.
Знакомым нам образом добавим атрибут указывающий какой профиль микротика использовать.
Методы проверки подлинности используем как и в прошлый раз. В настройках Сервера VPN рекомендуется указать точно такой же тип.
Настроим тестовое поключение и увидим что получили IP из пула для сетевых администраторов.
Теперь настроим политику для обычных пользователей:
Wifi и Dot1x
Прежде чем перети к самому вкусному, хочется сделать выбор как мы будем проходить авторизацию, можно выбрать по логину и паролю, компьютеру, использовать mac адрес как логин и пароль.. и наконец пойти самым сложным интересным путем, использовать сертификаты. В качестве предварительной подготовки нам необходимо:
настроить службу центра сертификации Windows тыц, актуально и для следующего пункта
настроить GPO для распространения CA сертификата домена тыц
GPO автоматического получения сертификата компьютера docs.microsoft
GPO включение службы dot1X (проводная автонастройка) и создать Политики проводных сетей (802.3) для выбора способа проверки подлинности тыц
GPO Автоматическое подключение к Wifi до логина пользователя тыц
Данные пункты не маленькие что бы включать их в эту статью, но достаточно освещены в статьях интернета.
Настройку WiFi каждый настраивает как ему удобно. Я к примеру, предпочитаю CapsMan, даже если это будет единственная AP в сети. В любом случае нас интересует только Security Profile/Security Cfg.
А в методах проверки подлинности следующее.
Какие радиус атрибуты могут быть нам полезны:
устанавливать лимиты по обьему или/и скорости трафика
и многие другие параметры из вики, либо их комбинации с условиями сетевой политики, смотря сколько у вас фантазии 🙂
dot1x
Зачем нужен dot1X и как его настроить.. очень много интересных слов можно было бы тут написать, но все сказано до нас. Например на канале одного прекрасного тренера или wiki
Начнем с микротика:
Настроим политики сети: В условиях необходимо отобрать проводные клиенты
В настройках атрибутами выдадим рабочий влан
К примеру вот так выглядит отказ в авторизации:
А вот так успешное подключение:
Диагностика
Не всегда наши настройки сразу работают так как надо, иногда что то идет не так, и очень хочется понять что именно. Для того что бы понять в чем причина у нас есть :
политики сети и доступа
возможны проблемы из за windows брандмауера починить можно
или для англоязычной версии:
radclient из пакета freeradius-utils. Позволяет из командной строки проверить некоторые типы авторизации, к примеру подключение к vpn
Выводы
RADIUS в сетевой среде очень полезен в плане безопасности и удобен в плане централизованного управления. Настраивать не так уж и сложно, главное читать, понимать документацию и логи.
Если какой то из пунктов непонятен, пишите. попробую показать или помочь разобраться.
Если в статье нашли ошибки, неточности или знаете как сделать лучше тоже пишите.
Благодарности:
Спасибо @aslancherkesov за злого редактора и свежий взгляд на буквы.
Мой MikroTik – моя цифровая крепость (часть 4)
Статья является продолжением первой, второй и третьей частей, посвящённых организации практической безопасности сетей, построенных на оборудовании MikroTik. Ранее были рассмотрены общие рекомендации, безопасность уровней L1, L2 и L3, реализация централизованного логирования. Настало время поговорить про развёртывание IDS и её интеграцию в инфраструктуру RouterOS.
11. Настройка IDS
Посредством зеркалирования информации, передающейся через конкретный порт роутера (для этого необходимо проверить на сайте производителя, умеет ли он так делать). Тип имеющейся микросхемы можно посмотреть так:
Этот вариант подойдёт, если вы развернёте Suricata внутри вашего LAN на железе, так как должно быть физическое соединение между зеркалируемым портом и его коллектором, тогда:
Сохранять передающийся трафик можно с помощью Tcpdump. Если такой вариант вас не устраивает, тогда рекомендую использовать арендованный VDS сервер более мощной конфигурации:
Для зеркалирования трафика можно использовать встроенное в RouterOS программное обеспечение Packet-sniffer:
Довольно грубое решение. Пакеты пересылать, разумеется, нужно по шифрованному VPN туннелю, который может быть достаточно узким, и тогда часть пакетов будет теряться. Для зеркалирования MikroTik применяет протокол TZSP, трафик будет обрамляться служебными заголовками и передаваться UDP пакетами, и тут уже без потерь никак. Для более точной настройки можно вместо Packet-sniffer использовать Firewall mangle (в примере отбираются пакеты для Winbox службы и SSH):
Firewall mangle подробно изучается на курсе MTCTCE (MikroTik Certified Traffic Control Engineer). Скажем только, что гибкость при его настройке достаточно высокая, и умелыми руками можно здорово дифференцировать пакеты. Сохранять передающийся трафик, конечно, можно с помощью Tcpdump, однако наличие служебных заголовков протокола TZSP доставляет хлопот:
Для обратного преобразования зеркалируемого трафика к первоначальному виду можно использовать программы: Trafr (настройка рассмотрена здесь) или Tzsp2pcap:
После этого создаем виртуальный интерфейс, поднимаем для него MTU, чтобы пакеты не обрезались (IP адрес 192.168.3.254 выбран случайно):
В режиме реального времени сервер будет принимать зеркалируемый трафик, снимать с него служебные заголовки протокола TZSP и ретранслировать его на виртуальный интерфейс eth10:
Трансмиссию привели в порядок, приступим к настройке IDS. С параметрами по умолчанию все будет хорошо работать (правила хранятся в /etc/suricata/rules/), не забудем только уточнить домашнюю сеть (192.168.15.9 – IP адрес роутера в VPN):
Лог всего трафика, проходящего через Suricata, можно посмотреть так:
Лог детектированных угроз лежит здесь /var/log/suricata/fast.log. Настало время испытаний.
12. Из IDS в IPS
IDS расшифровывается как Intrusion Detection System – система обнаружения вторжений. IPS (Intrusion Prevention System) – система предотвращения вторжений. На текущий момент наша Suricata анализирует зеркалируемый на нее трафик и, в случае обнаружения угроз, сохраняет их описание в лог. Посмотрим, справляется ли она со своими задачами. Попробуем развернуть bruteforce атаку на SSH службу нашего роутера:
Как мы видим, угроза была детектирована: «Potential SSH Scan». Попробуем выполнить nmap сканирование роутера:
Suricata и в этом видит угрозы:
Теперь наша задача обрабатывать получаемый лог, выделять угрозообразующие IP адреса и блокировать их на MikroTik-е. Для этого уже существует готовое решение: PHP скрипт fast2mikrotik по API добавляет их в /ip firewall address-list. Однако у нас он в итоге так и не заработал, поэтому далее мы представим вариант собственной реализации. Здесь немного отвлечемся от темы. Управлять роутером посредством API это очень заманчиво, так как уже имеется готовый PHP класс.
Активируем API в RouterOS:
И кидаем на маршрутизатор команды, примерно так:
Можно, конечно, работать через API по SSL, подготовив заранее сертификаты, чтобы все было безопасно, но мы решили выполнить интеграцию по-другому и пошли своим путем, может, не самым эффективным, но удобным, так как отсутствует необходимость запуска и настройки дополнительных сервисов, таких как база данных, например. Команды будем передавать примерно так, как показано ниже:
Полный Bash скрипт под спойлером.
Код прокомментирован и ясен. Результат его работы на RouterOS выглядит примерно так:
Мы пропускали неинтересные для нас сработки «TLS invalid handshake message» и «TLS invalid record/traffic». Можно переделать скрипт и пропускать сообщения с приоритетом 3, так как это не угрозы безопасности оберегаемой сети, и они носят скорее уведомительный характер. Блокировать IP адреса, обнаруживаемые IDS, будем посредством Firewall:
Лучше это делать в RAW filter, так как пакеты будут отброшены в самом начале обработки их маршрутизатором и не потратят зря имеющиеся ресурсы. Это хорошо видно в схеме прохождения трафика внутри RouterOS, взятой у этих ребят:
Попробуем повторить брутфорс службы SSH роутера:
Попробуем что-нибудь серьезнее, загрузим эксплоит для уязвимости службы Winbox (CVE-2018-14847):
Как видно, все было детектировано и соответственно заблокировано на маршрутизаторе. Поэтому можно говорить, что из IDS наша реализация превратилась в IPS. Здесь стоит еще упомянуть коммерческий проект, в котором уже все это решено за нас, можно брать и пользоваться. Поставляется в виде готовой сборки ISO.
13. Заключение
Вот и подошёл к концу цикл наших статей, посвящённый широким возможностям операционной системы RouterOS, а также сопрягаемых с ней opensource решений. В комплексе организованная безопасность уровней L1, L2 и L3, реализация централизованного логирования, интегрированное IPS решение позволяют говорить, что наш MikroTik – это полноценный барьер для разноуровневых угроз, нацеленных на защищаемую сеть. То, что не умеет делать RouterOS, можно допилить самому готовыми бесплатными решениями.
И вот еще о чем важном мы не упомянули. Всегда помните, что в любой, даже в самой технически защищённой системе, остаётся слабое место – человек её обслуживающий. Здесь использован перифраз известной цитаты Кевина Митника из книги «Искусство обмана»: «Человеческий фактор по-настоящему самое слабое звено в безопасности». Поэтому гигиена, в том числе цифровая, никогда не теряет актуальности, особенно в период пандемии.
03. 802.1x
Стандарт IEEE 802.1x определяет метод управления доступом к сети, он управляет аутентификацией и устройствами доступа на физическом уровне (порты коммутатора). Если пользовательские устройства, подключенные к этим портам, удается аутентифицировать, они получают доступ к ресурсам локальной сети, в противном случае доступ будет запрещен.
Стандарты IEEE 802.1x определяют протокол управления доступом к сети на основе портов. Протокол применим к соединению точка-точка между устройством доступа и портом доступа, при этом порт может быть логическим или физическим. В типичном случае один физический порт коммутатора присоединен только к одному терминирующему устройству (имеющему физические порты).
Архитектура IEEE 802.1x описана на рисунке ниже.
Надписи на рисунке:
Supplicant System – клиентская система;
Supplicant PAE – Порт клиентской системы;
Autenthicator system – система аутентификатора;
Autenthicator PAE – Порт аутентификатора;
Services offered by Autenthicator’s system – услуги, предоставляемые системой аутентификатора;
Controlled Port – управляемый порт;
Uncontrolled port – неуправляемый порт;
EAP protocol exchanges carried in higher layer protocol – обмен сообщениями протокола EAP происходит через протокол более высокого уровня;
Authentication Server system – система сервера аутентификации;
Authentication Server – сервер аутентификации.
802.1x имеет клиент-серверную архитектуру, которая имеет 3 составляющие: устройство, запрашивающее доступ, система аутентификации и сервер аутентификации.
Устройство, запрашивающее доступ представляет собой объект на одном конце сегмента сети, который должен быть аутентифицирован блоком управления доступом на другом конце сегмента сети. Пользователь запускает аутентификацию 802.1X через программное обеспечение запрашивающей системы. Система, запрашивающая доступ, должна поддерживать EAPOL;
Сервер аутентификации используется для аутентификации и авторизации пользователей. Обычно это сервер RADIUS, который может хранить информацию о пользователях (имя, пароль, VLAN, порт и т.д).
Система аутентификации (коммутатор доступа) предоставляет порты для доступа к сети запрашивающим пользовательским системам. Эти порты логически можно разделить на два вида: контролируемые и неконтролируемые:
Неконтролируемый порт всегда находится в режиме двунаправленного соединения и в основном используется для передачи пакетов протокола EAPOL, чтобы гарантировать, что запрашивающие системы всегда могут отправлять или получать сообщения аутентификации.
Контролируемый порт связан с состоянием аутентификации. При отсутствии аутентификации данные из запрашивающих доступ систем передаваться не могут. Данный коммутатор может осуществлять контроль только одного направления трафика.
Управляемые и неконтролируемые порты представляют собой две логические части одного физического порта.
Реализованы методы аутентификации пользователей на основе MAC, на основе порта и на основе пользователя. Только аутентифицированные пользовательские системы, подключенные к одному и тому же физическому порту, могут получать доступ к сети. Таким образом, даже если к одному физическому порту подключено множество хостов, коммутатор может аутентифицировать их и управлять доступом каждой пользовательской системой индивидуально.
Существует 2 режима пользовательском управлении доступом имеется два режима: стандартное управление и расширенное управление. При стандартном (standard) пользовательском управлении доступ к определенным ресурсам не ограничивается до аутентификации. После аутентификации пользователи получают доступ ко всем ресурсам. При расширенном (advanced) пользовательском управлении доступом только специальные пользователи до аутентификации получат доступ к ограниченным ресурсам.
Реализована возможность использования гостевой VLAN: если устройство, запрашивающее доступ, не получит аутентификацию успешно в течение определенного промежутка времени, устройство будет добавлено в эту VLAN.
3.2. Настройка 802.1x
Включить IEEE 802.1x;
Конфигурация свойств блока управления доступом;
Настроить метод контроля доступа на порту;
Настроить расширенные функции;
Конфигурация свойств зависимых устройств пользователя.
Включить IEEE 802.1x:
Команда
Описание
! В режиме глобальной конфигурации
Включить функцию dot1x на коммутаторе и портах
Выключить функцию dot1x.
dot1x privateclient enable
no dot1x privateclient enable
! В режиме глобальной конфигурации
Включить режим использования клиентским ПО специального формата сообщений 802.1x. Команда no включает режим использования стандартного формата (по-умолчанию)
dot1x user free-resource
# Включить функцию 802.1x
# Настроить порт Ethernet1/0/2
3.3.2. RADIUS
Хост пользователя подключен к порту коммутатора Ethernet1/0/2, на котором задействована функция аутентификации IEEE 802.1x. В качестве метода доступа используется MAC-based. IP-адрес коммутатора 10.1.1.2. Порт коммутатора Ethernet1/0/1 подключен к RADIUS серверу, который имеет IP-адрес 10.1.1.3 и испольует порт 1813 по-умолчанию для аутентификации и аккаунинга. Хост пользователя использует специализированное программное обеспечение для аутентификации IEEE 802.1x.
Конфигурация будет выглядеть следующим образом:
3.4. Решение проблем с настройкой 802.1x
Для включения 802.1x на порту должны быть выключены функции привязки MAC-адреса и агрегирования портов;
Проверьте связь между коммутатором и RADIUS-сервером, между коммутатором и устройством пользователя, а также конфигурацию их портов и VLAN;
Проверьте правильность указания ключа для RADIUS-сервера;
Для поиска возможных причин неисправности проверьте журнал событий на сервере RADIUS;
Manual:Interface
Applies to RouterOS: v3, v4 +
Contents
Sub Categories
List of reference sub-pages
Summary
MikroTik RouterOS supports a variety of Network Interface Cards as well as virtual interfaces (e.g. Bonding, Bridge, VLAN etc.). Each of them have their own sub-menu, but common properties of all interfaces can be configured and read in the general interface menu.
Properties
| Property | Description |
|---|---|
| l2mtu (integer; Default: ) | Layer2 Maximum transmission unit. Note that this property can not be configured on all interfaces. Read more>> |
| mtu (integer; Default: ) | Layer3 Maximum transmission unit |
| name (string; Default: ) | Name of an interface |
Read-only properties
| Property | Description |
|---|---|
| bindstr ( ) | |
| bindstr2 ( ) | |
| caps ( ) | |
| default-name ( ) | |
| dynamic (yes|no) | Whether interface is dynamically created |
| default-name ( ) | |
| fast-path (yes | no) | |
| flags ( ) | |
| id (integer) | interface id |
| ifindex (integer) | interface index |
| ifname (string) | interface name in Linux kernel |
| mac-address (MAC) | |
| max-l2mtu (integer) | Max supported L2MTU |
| running (yes|no) | Whether interface is running. Note that some interfaces may not have a ‘running check’ and they will always be reported as «running» (e.g. EoIP) |
| rx-byte (integer) | Number of received bytes. Read more>> |
| rx-drop (integer) | Number of received packets being dropped Read more>> |
| rx-errors (integer) | Packets received with some kind of an error. Read more>> |
| rx-packet (integer) | Number of packets received. Read more>> |
| slave (yes|no) | Whether interface is configured as a slave of another interface (for example Bonding) |
| status (string) | |
| tx-byte (integer) | Number of transmitted bytes. Read more>> |
| tx-drop (integer) | Number of transmitted packets being dropped Read more>> |
| tx-errors (integer) | Packets transmitted with some kind of an error. Read more>> |
| tx-packet (integer) | Number of transmitted packets. Read more>> |
Traffic monitor
The traffic passing through any interface can be monitored using following command:
/interface monitor-traffic [id | name]
For example monitor ether2 and aggregate traffic. Aggregate is used to monitor total ammount of traffic handled by the router:
Stats
RouterOS v3.22 introduces a new command:
All interfaces that support this feature will be displayed. Some interfaces are not supporting Error and Drop counters at the moment (RB4XX except RB450G ether 2-5), these devices will not display these counters.
Traffic monitor now also displays errors per second, in addition to the usual stats:
/interface ethernet print stats will display all kinds of other statistics if the interface is supporting them (currently only RB450G ether2-ether5 and also RB750 ether2-ether5).
