MikroTik`s scripts спешат на помощь

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

Модернизируя сетевую инфраструктуру одного из заказчиков, мы столкнулись с настоящим телеком динозавром из семейства «for home use only». На границе периметра был засунут старенький роутер Asus, основное назначение которого было выполнение роли DDNS клиента. Так получилось, что в компании давно были настроены внутренние сетевые ресурсы и с интернет провайдером заключен договор о лизинге белого динамического IP. Со временем в инфраструктуре многое поменялось, но из-за твердого не желания заказчика вмешиваться в существующие, налаженные годами процессы, настройки клиентской стороны не менялись, и Asus работал себе и работал, сообщая внешнему DDNS сервису свой текущий адрес. В этом месте вспоминается разговор у костра с одним коллегой, который поведал мне о увиденном им лично коммутаторе Cisco с uptime в целых 11 лет, хотите верьте, хотите нет. Настал черед выйти Asus-у на пенсию и уступить место оборудованию от MikroTik. В этом месте мы столкнулись с инженерной задачей, готового решения которого в интернете найдено не было. В связи с чем, было проведено небольшое исследование, которое может кому-то поможет сэкономить время.

▍Техническая часть

Протокол DDNS отвечает за автоматизированное преобразование доменного имени в динамические IP адреса. Прошивки роутеров Asus имеют функционал по настройке DDNS клиента, в котором зашиты определенные сервисы.

Настройка DDNS клиента

В первую очередь, это, конечно, сервис от самой компании Asus. Из настроек можно указать только «Имя хоста», которое и будет резолвиться в IP. У оборудования MikroTik дела с этим обстоят по-другому. Встроенный функционал работает только со своим сервером cloud.mikrotik.com и, разумеется, никакого www.asus.com в нем нет. В интернете мы не нашли описание, как выкрутиться из этой истории и все-таки списать динозавра на пенсию. Имеются материалы, касающиеся настройки сервиса No-IP, но нам они не подходят, потому что не работают. Сразу стало понятно, что в такой ситуации решением будет регулярная отправка из скрипта необходимой информации на сервера Asus посредством HTTP клиента fetch. Осталось только разобраться что, куда и как. Запишем трафик, который передает Asus. Для этого отключим работу его DDNS клиента и брандмауэра, настроим DHCP клиент на WAN порту и подключим к подготовленному MikroTik с работающим DHCP сервером.

Отключение брандмауэра для WAN порта

Настройка DHCP клиента для WAN порта

Если все сделано верно, тогда в лизинге увидим нужный нам IP.

/ip dhcp-server lease print 
Flags: X — disabled, R - radius, D - dynamic, B - blocked 
 #   ADDRESS         MAC-ADDRESS       HOST-NAME   SERVER
 0 D 192.168.1.10    11:12:13:15:AA:BB Ubuntu      dhcp-server
 1 D 192.168.1.2     BC:EE:71:11:11:11 Asus        dhcp-server
 2 D 192.168.1.12    11:12:14:16:BB:AA Windows     dhcp-server

Настраивая на MikroTik снифер, мы выбрали наиболее простой вариант /tool sniffer с сохранением дампа в память роутера:

/tool sniffer
set file-limit=10000KiB file-name=TEST.pcap filter-ip-address=192.168.1.2/32

Активируем DDNS клиент на Asus и смотрим трафик, а там все как на ладони.

Работа DDNS клиента

Asus начинает запрашивает A запись для доменного имени ns1.asuscomm.com у MikroTik, выступающего для него DNS сервером, поэтому получает сразу прямой DNS ответ. Далее идет TCP handshake SYN -> SYN,ACK->ACK, затем служебные пакеты PSH,ACK->ACK и, наконец, начинается работа DDNS клиента. Видим обычный HTTP GET на сервер ns1.asuscomm.com:

GET /ddns/update.jsp?hostname=xxx.asuscomm.com&myip=192.168.1.2 HTTP/1.0
Authorization: Basic QkNFRTdCODFENEEwOkRERjBFQTM1xxxxxxxxxxxx5RjZFMTBCOEU4
User-Agent: ez-update-3.0.11b5

Все данные у нас есть, верстаем скрипт на RouterOS, заголовки Authorization и User-Agent пропускаем для простоты:

#Var list
:local OUTInterface WAN;
:local DDNS xxx.asuscomm.com;

#Get ip address of out interface
:local ip [/ip address get [find interface=$OUTInterface] address];
#Delete mask in ip
:local ipshort [:pick $ip 0 [:find $ip «/»]];

#HTTP get
do {/tool fetch url=«http://ns1.asuscomm.com/ddns/update.jsp?\
        hostname=$DDNS&\
        myip=$ipshort» \
        keep-result=no} on-error={};

Сервер нам выдает ошибку 401 Unauthorized, все понятно, добавляем в скрипт данные для аутентификации, как есть, в сыром виде. И DDNS сервис от Asus заработал, но уже на оборудовании MikroTik:

#HTTP get
do {/tool fetch url=«http://ns1.asuscomm.com/ddns/update.jsp?\
        hostname=$DDNS&\
        myip=$ipshort» \
        http-header-field=«Authorization: Basic QkNFRTdCODFENEEwOkRERjBFQTM1xxxxxxxxxx5RjZFMTBCOEU4» \
        keep-result=no} on-error={};

Не забываем скрипт засунуть в планировщик заданий:

/system scheduler
add interval=30s name=updateip on-event=»/system script run our_script» start-time=00:00:00

Как видно, мы пропустили User-Agent, но лучше так не делать, мало ли ребята из Asus рассердятся и начнут блокировать наше решение (http-header-field=«User-Agent: ez-update-3.0.11b5»). Осталось разобрать заголовок Authorization. Это связка логина и пароля, закодированные в Base64. После декодирования видно, что в качестве логина используется прошитый MAC адрес WAN интерфейса.

Декодированный заголовок Authorization

MAC адрес WAN порта

А вот откуда берется пароль, нам выяснить не удалось. В системных логах загрузки роутера ничего подобного не упоминалось. Даже не поленились посмотреть под корпусом, ничего похоже и там не нашли. После обновления версии операционной системы он не изменился, поэтому будем считать, что она берет эту информацию откуда-то изнутри железа. Что интересно, сервер DDNS проверяет на валидность только первые 6 знаков (для шестнадцатеричного представления, разумеется) и наличие ":" после 12 знака, остальное можно опустить или изменить, но аутентификацию так не пройти.

▍Заключение

В работе технических специалистов постоянно возникают различного рода нестыковки, иногда в самых неожиданных местах. Тогда в дело вступает светлая голова, ровные руки, везение и качественное оборудование, на котором приятно работать. Немного добавим про безопасность такой вот реализации DDNS клиента. На наш взгляд, все хорошо. Чтобы злоумышленнику попытаться стравить IP адрес, ему придется ввести данные для аутентификации. Если с MAC адресом вроде как все это проще, то пароль точно не подобрать. Да и вообще на дворе 2021 год и пора давно бы отказаться от DDNS, в корпоративной среде уж точно, как-то не серьезно.

Adblock test (Why?)