Udplite mikrotik что это

Manual:IP/Services

Applies to RouterOS: v3, v4

Contents

Summary

Sub-menu: /ip service

This document lists protocols and ports used by various MikroTik RouterOS services. It helps you to determine why your MikroTik router listens to certain ports, and what you need to block/allow in case you want to prevent or grant access to the certain services. Please see the relevant sections of the Manual for more explanations.

The default services are:

Properties

Note that it is not possible to add new services, only existing service modifications are allowed.

Example

For example allow telnet only from specific IPv6 address range

Service Ports

Sub-menu: /ip firewall service-port

Hosts behind a NAT-enabled router do not have true end-to-end connectivity. Therefore some Internet protocols might not work in scenarios with NAT.

To overcome these limitations RouterOS includes a number of NAT helpers, that enable NAT traversal for various protocols.

Note: If connection tracking is not enabled then firewall service ports will be shown as inactive

Protocols and ports

Table below shows the list of protocols and ports used by RouterOS.

Источник

Для чего хакерам Микротик и как я спрятал 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\
\_3*\»];/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 — как услуга провайдеров

Рынок «умных» устройств очень бурно развиваются и они далеко не все хорошо защищены. Большинство людей, которые их приобретают, так же не владеют специальными знаниями, чтобы самостоятельно защитить свои гаджеты.

Поэтому интернет провайдерам пора создать коммерческую услугу по защите таких гаджетов. Банально пользователь в личном кабинете указывает какие порты открыть из интернета.
Так же провайдеры могут создать централизованную базу по существующим устройствам и их нормальным потребностям. Пользователь указывает в ЛК какие устройства у него используются. В случае нестандартного поведения такого устройства — уведомлять пользователя.
Я считаю, что рынок уже созрел для такой услуги.

В этой услуге есть следующие плюсы:

Немного о себе

Попытаюсь ответить на вопросы, которые наверняка мне зададут.

Источник

Мой MikroTik – моя цифровая крепость (часть 1)

1. Введение

В комментариях опубликованной ранее статьи один из пользователей спросил: «А можно добавить раздел про то, как нужно защитить свой, микротик чтобы управление им не ушло на сторону?». Один из пользователей написал на это следующее: «Универсальных принципов для любого сетевого устройства два – администрирование только с внутреннего интерфейса (снаружи закрыто все) и регулярно обновлять прошивку» (сохранена авторская орфография). А мы сразу поняли, что одним коротким ответом здесь не обойтись, и этот вопрос заслуживает полноценного отдельного рассмотрения с учётом широких возможностей операционной системы RouterOS, а также сопрягаемых с ней opensource решений, комплексно завершающих проблемный вопрос информационной безопасности. Кроме непосредственно настройки безопасности доступа до маршрутизатора, необходимо использовать его как полноценный барьер для разноуровневых атак, которые могут быть нацелены на защищаемую сеть. Технологий реализации этого достаточно много, поэтому разделим применяемые возможности на логические уровни и представим предметные рекомендации по администрированию сетей на базе оборудования MikroTik.

2. Общие рекомендации

Первое, что мы всегда делаем с железкой — это обновляем прошивку:

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

Если паранойя зашкаливает, тогда используем SSH вход без ввода пароля (и пользователя admin можно заменить на другого). Сгенерим пару RSA ключей, размер укажем 4096 бит, что уж мелочиться:

На выходе будет закрытый ключ test_user:

И открытый ключ test_user.pub:

Привяжем открытый ключ к пользователю RouterOS:

Добавляем хардкор, запретив логиниться по паролю:

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

Можно поменять прослушиваемый порт для SSH сервера. Особенно на значение, не входящее в сканируемые по умолчанию nmap-ом, но мы в этом защиты не видим, скорее маскировка:

Сканируем роутер и видим, что всё работает корректно. Сервер SSH будет недоступен, пока на роутер не пройдут попытки установления соединения на 28 порт, затем в течение 30 секунд на 29 порт, затем в течение 30 секунд на 30 порт. Если последовательность обращений верна и временные лимиты соблюдены, то IP адрес источника сможет в течение 30 секунд установить SSH сессию, а иначе drop:

Необходимо отметить, что если вы укажете порты стука примерно в таком порядке: 21, 80, 443, а прослушиваемый SSH порт перенесете на значение 8080 (все четыре входят в список по умолчанию для сканирования nmap), то ваш секретный порт 8080 определится при первом же сканировании. Если вы действительно хотите использовать технологию port knocking, то выбирайте порты в порядке уменьшения, а сами значения портов на «не сканируемые» nmap-ом: ни в режиме top 100, ни в режиме top 1000. Кроме этого, можно ограничить IP адреса, с которых доступны протоколы управления, на диапазон доверенных:

Таким образом, несмотря на то, что 22 порт готов принимать TCP соединение, однако с не доверенных IP адресов оно будет сброшено SSH сервером:

Как общие рекомендации, лучше не использовать протоколы, не имеющие шифрования для передачи защищаемой информации. Если такой возможности нет, тогда старайтесь пускать трафик по шифрованным VPN туннелям. Но лучше даже внутри таких соединений использовать безопасные протоколы, ведь VPN сеть может уходить далеко за пределы периметра, контролируемого вами. Если есть возможность, не используйте протоколы pap, http (в том числе при реализации API), ftp, smtp и т.д. Всегда используйте их безопасные аналоги: chap, mschap2, https, smtps.

Делайте регулярные резервные копии конфигураций ваших устройств. В RouterOS есть два типа backup: бинарный *.backup

и текстовый конфигурационный файл *.rsc

Первый рекомендуется откатывать только на полностью идентичных устройствах, и не подлежит редактированию (при откате восстанавливается точный образ операционной системы). Второй же, наоборот, можно вручную контролируемо построчно обрабатывать (до получения необходимо результата), однако он может содержать чувствительную информацию (если не делать /export hide-sensitive), поэтому рекомендуем обезопасить хранение такого рода backup файлов. Ставить ли регулярный backup в планировщик заданий, или нет, тут уже каждый решает сам. Главное — не запутаться во всех резервных копиях и не передавать их на удалённый сервер по открытому интернет каналу посредством ftp.

3. Защита L1

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

Сюда же пойдёт организация безопасности беспроводных соединений. В идеале, конечно, следует настроить WPA2-Enterprise (подробно о настройке RADIUS сервера мы напишем во второй части статьи), так как реальных угроз безопасности таких сетей пока не известно:

Если такой вариант вам не подходит, тогда используйте WPA2-PSK со словарно неподбираемым паролем, который держите в тайне от третьих лиц, и отключённый PMKID:

Ещё можно запретить подключаться к точке доступа с низким уровнем сигнала, т.е. физически удалённым пользователям, которые, можно предположить, находятся за контролируемым периметром и не легитимны:

На этом свои рекомендации по поводу L1 безопасности остановим и перейдём к более интересным вещам.

4. Защита L2

Для начала ограничим работающие сервисы уровня L2:

Первый скрипт позволяет осуществлять mac-ping только для внутренней сети. Второй ограничивает L2 подключение посредством службы Winbox:

RouterOS поддерживает работу таких протоколов, как CDP, LLDP и MNDP. Чтобы не осуществлять широковещательную рассылку пакетов указанных протоколов во все стороны, ограничиваем их работу:

Чтобы со стороны провайдера не догадывались, что у вас стоит роутер MikroTik, можно сменить MAC адрес WAN интерфейса, но это скорее баловство:

Если в вашем L2 сегменте появится второй или более незаконный DHCP сервер, то это может здорово навредить работе всей сети. Так в примере видно, что работают две указанные службы (192.168.1.1 и 192.168.3.1), раздавая по факту разные сетевые настройки:

Для защиты от такого рода атак (ведь хакер может назначить и своё устройство в качестве шлюза) существует технология «DHCP snooping». После её активации бридж пропускает DHCP пакеты только в доверенную сторону:

Защита оконечных устройств выходит за рамки данной статьи, но декларируем, что многие антивирусы справляются с этой задачей, детектируя манипуляции с ARP пакетами. На скрине видно, что действиями выше мы организовали MITM для хоста 192.168.1.3 и перехватили его HTTP запросы:

В следующем примере показаны ложные записи ARP таблицы маршрутизатора, а ведь так намеренно можно заполнить весь имеющейся пул и втупить работу легитимного DHCP сервера:

Для защиты от таких действий в RouterOS необходимо, первым делом, настроить DHCP сервер, что позволит активировать функцию заполнения ARP таблицы, либо в результате его работы, либо в ручном режиме:

После этого настраиваем бридж, переводя маршрутизатор в режим только ответа на ARP запросы (если у вас работает hotspot, то от этой идеи придётся отказаться, так как он перестанет нормально функционировать), таким образом, сторонние манипуляции будут бессильны:

Дополнительно следует выключить режим обучения портов MAC адресам:

Если ваш маршрутизатор гоняет пакеты для логически разделённых сетей, в том числе с точки зрения безопасности, то их следует разнести по различным VLAN. Важно понимать, что если через ваше устройство проходят несколько VLAN, то в случае несанкционированного доступа к роутеру или коммутатору, могут быть скомпрометированы устройства во всех этих подсетях. Здесь всё понятно. Дополнительно можно указать устройству проверять tag трафика и дропать пакеты, у которых VLAN ID не найден в его таблице VLAN:

5. Заключение

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

Источник

Настройка Firewall в Mikrotik

RouterOS — сетевая ОС, изначально предназначенная для устройств RouterBoard латвийской компании Mikrotik, но в дальнейшем перекочевавшая на x86 и в облака (версия Cloud Hosted Router). В этой статье поговорим о том, как грамотно настроить межсетевой экран в этой ОС.

Безопасность периметра локальной сети — одна из приоритетных задач любого системного администратора и в компании Mikrotik это прекрасно понимают. Так что как только вы включили устройство на RouterBoard с настройками по умолчанию — там уже будет некоторое количество преднастроенных правил. В случае Mikrotik CHR — по умолчанию правил не будет, но Mikrotik настоятельно рекомендует их настроить.

Сразу оговоримся, что в рамках этой статьи мы будет пользоваться исключительно интерфейсом командной строки (CLI) и облачной версией RouterOS CHR. Логика настройки точно такая же, как и при использовании WinBox или WebFig, но предпочтительнее изначально пользоваться CLI.

Немного теории: настройка firewall

Одним из базовых понятий настройки файервола Mikrotik является цепочка (chain). По умолчанию их 3, но есть возможность и создания собственных цепочек:

Если к нам должен прийти какой-либо трафик извне, например, из интернета, то мы его будем обрабатывать цепочкой INPUT. Чтобы обработать правилами трафик, уходящий наружу (например, в тот же интернет), задействуем цепочку OUTPUT. Если же наш маршрутизатор не находится на границе сети, а служит промежуточным узлом между сетями, то тогда для обработки трафика применяем цепочку FORWARD.

Причем тут странное название «‎цепочка‎‎»‎? Все элементарно. Все создаваемые правила обработки действуют не вместе, а строго по очереди одно за другим. Точно также, как формируется цепь — одно звено следует за другим. Именно поэтому списки правил стали именовать «‎цепочками»‎.

Теперь коснемся статусов соединения. Каждое соединение условно можно разделить на 4 категории:

И сразу к практике: фильтрация

Открываем консольный интерфейс и посмотрим на существующие правила:

Пока что правил нет, отображается только «‎легенда»‎ про флаги. Переходим в раздел настройки фильтров:

Полезный чит-код: узнать все варианты команд в любом разделе можно, нажав клавишу со знаком вопроса «?«

Теперь создадим несколько правил и расскажем для чего они нужны:

Эту команду можно читать прямо дословно. Разберем прямо по пунктам:

Таким образом эта длинная команда всего лишь превращается во вполне логичную фразу «‎Принимать извне все пакеты со статусом соединения Established и Related»‎. Это правило позволяет четко указать маршрутизатору что если из внешней сети прилетают соединения с указанными статусами, то их следует принять.

Теперь переходим к следующему правилу, рекомендуемому Mikrotik:

Тут мы заострим внимание только на параметре src-address-list=allowed_to_router. При обработке трафика мы можем формировать различные списки IP-адресов. Каждый список будет иметь имя. Так что дословный «‎перевод»‎ этого правила всего лишь «‎Принять пакеты, если IP-адрес с которого обращаются, есть в списке allowed_to_router. Нам это правило пригодится для дальнейшего формирования списка разрешенных IP-адресов.

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

Теперь следующее правило, оно достаточно спорное. Мы разрешим маршрутизатору отвечать на команду ping, приходящую извне. С одной стороны — это потенциально раскрывает то, что на нашем IP-адресе есть действующее устройство, а с другой это часто требуется для организации мониторинга. У нас в Selectel, к примеру есть услуга «‎Мониторинг состояния сервисов»‎, которая позволяет отслеживать доступность любого хоста из разных стран мира. Если вам нужно, отключить ping, то в action надо прописать не accept, а drop.

Тут все просто — эта команда разрешает принимать извне и обрабатывать ICMP-пакеты. И завершающая команда:

Этим в финале цепочки INPUT мы будем отбрасывать (дропать) все оставшиеся пакеты, не подпадающие под правила выше. Посмотрим как у нас сформировались правила:

Рассмотрим как же это работает. Представим, что мы пингуем маршрутизатор извне. Это выглядит примерно так:

Рассмотрим еще один случай. На этот раз к нам на маршрутизатор извне прилетел некий неизвестный UDP-пакет с данными. Как будет действовать маршрутизатор:

Надеемся, что столь подробный разбор логики немного прояснил как именно работает файервол в Mikrotik RouterOS, поэтому приступим к дальнейшей настройке. Сформируем список разрешенных адресов. Для этого вернемся в главное меню, нажав символ / и подтвердив нажатием клавиши Enter. Теперь перейдем в раздел консольного интерфейса Mikrotik – ip firewall и посмотрим какие адресные списки у нас существуют:

Как видим, список пока пустой. Добавим туда адреса из стандартной локальной подсети 192.168.88.0/24 за исключением 192.168.88.1 (адрес маршрутизатора). Эта подсеть обычно используется по умолчанию на устройствах Mikrotik и именно ее чаще всего используют для раздачи адресов в локальной сети. Выполним добавление:

Команда максимально проста для понимания мы говорим, что нам нужно добавить адреса 192.168.88.2-192.168.88.254 в список с именем allowed_to_router. Подразумевается то, что если списка с таким именем не существует, то при выполнении команды он будет создан. Проверим:

Теперь, когда файервол в цепочке INPUT дойдет до правила номер 1, то в случае поступления данных с IP-адресом отправителя из диапазона 192.168.88.2-192.168.88.254 — правило сработает и маршрутизатор будет знать, что данные следует принять. Этим мы будем пользоваться для обращений к маршрутизатору из локальной сети.

Разделяем и властвуем

Списки адресов — крайне полезная штука при настройке файервола. Тут важно следовать стандартам, разработанным такой крутой организацией, как IETF (Internet Engineering Task Force) — Инженерный совет Интернета. Это международное сообщество с конца 80-х годов занимается развитием протоколов и архитектуры интернета.

Результаты работы IEFT публикуются в виде RFC (Request for Comments) — информационных документов, содержащих в себе детальное описание спецификаций и стандартов. Этих документов уже создано несколько тысяч, все они представлены на английском языке. Один из них поможет нам корректно сформировать списки адресов, а именно RFC6890.

Наша задача при настройке файервола четко разделить адреса, относящиеся к локальному сегменту и адреса глобальной сети интернет. Именно их мы возьмем из RFC и пропишем в нашем маршрутизаторе списком с названием not_in_internet. В дальнейшем это поможет нам сформировать правила в которых будут абстракции «‎это адрес из интернета»‎ и «‎это адрес не из интернета»‎.

Поочередно выполняем команды, создавая и дополняя список not_in_internet, помимо всего прочего указывая в комментарии номер RFC, которым мы руководствовались:

Есть еще две важные подсети, которые тоже стоит добавить в этот список. Первая подсеть — это 224.0.0.0/4. Эта подсеть зарезервирована для технологии многоадресного вещания (мультикаст) и это зафиксировано в соответствующем RFC2780. Вторая подсеть специфична для переходного механизма 6to4, позволяющего передавать IPv6 трафик через IPv4 сети. Этот механизм реализован в подсети 192.88.99.0/24, что также зафиксировано в отдельном RFC3068.

Теперь, когда мы все сделали «‎по фен-шую»‎, у нас есть список всех адресов, которые будут опознаваться как локальные, т.е. пришедшие не из интернета. Проверим:

Теперь, используя эти листы, создадим еще правила уже в цепочке FORWARD, которые защитят устройства в локальной сети от различных посягательств. Возвращаемся в раздел с правилами:

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

Обрабатываем установленные соединения в цепочке Forward:

Отбрасываем «‎битые»‎ соединения:

Отбрасываем пакеты, исходящие из локальной сети к частным IP-адресам и фиксируем срабатывание правила в логах:

Отбрасываем входящие пакеты, которые не подходят для NAT и фиксируем срабатывание:

Отбрасывать пакеты из сети интернет, пришедшие не с публичных IP-адресов и заносить информацию в лог:

Отбрасывать пакеты из локальной сети, не имеющие IP-адресов этой локальной сети, и также отправляем сообщение в лог:

Защита от атак перебором

Брутфорс-атаки давно стали повседневностью. Десятки тысяч ботов регулярно сканируют весь интернет в поисках открытых портов SSH и затем начинают весьма активно «‎стучаться»‎ на внешний интерфейс и перебирать пароли в попытке захватить контроль над подключенным устройством. У тех, кто контролирует эти сети есть весьма обширные словари паролей, использующие как дефолтные реквизиты доступа большинства устройств.

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

Вначале создадим правило firewall по которому все входящие соединения с IP-адресов, находящихся в списке ssh_blacklist будут сбрасываться:

Теперь сформируем сам список ssh_blacklist. Любой имеет право на ошибку, поэтому если легитимный пользователь три раза ошибся во вводе пароля — это нормально. Так что позволим пользователю сделать 3 ошибки с интервалом в 1 минуту. Большее количество будет свидетельствовать о переборе паролей и IP-адрес атакующего будет попадать в черный список и включается блокировка на 10 дней.

Так что нам потребуется создать еще три списка IP-адресов. Первый назовем ssh_stage1. Как только создается новое соединение на порт SSH мы вносим IP-адрес источника в список. При этом задаем удаление через 1 минуту. Это гарантирует нам то, что если соединение прошло успешно — IP-адрес будет удален из списка.

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

Если пользователь ошибется второй раз, то закидываем IP-адрес источника из списка ssh_stage2 в список ssh_stage3.

Третья ошибочная попытка приводит к копированию IP из списка ssh_stage3 в список ssh_blacklist и все входящие соединения с этого IP будут заблокированы сроком на 10 дней.

Для разблокировки адреса будет достаточно его удалить из черного списка.

NAT: базовая настройка и проброс портов

Технология трансляции сетевых адресов (NAT — Network Address Translation) используется во многих случаях. Чаще всего с ней можно встретиться при организации широкополосного доступа к сети интернет. Смысл технологии в том, чтобы дать возможность выходить в сеть множеству устройств, используя всего лишь один внешний IP-адрес.

Все устройства в этом случае будут иметь локальные IP-адреса, например, 192.168.XXX.XXX. Когда устройство запрашивает какой-либо внешний ресурс, то маршрутизатор точно знает от какого адреса в локальной сети пришел запрос и соответственно знает куда направлять обратный поток данных. Но если из внешней сети придет какой-либо запрос, то маршрутизатор его отбросит, поскольку не знает какому устройству в локальной сети его направить.

Решением проблемы является так называемый проброс портов (Port Forwarding). Создавая правило проброса портов мы даем маршрутизатору указания какому устройству перенаправить запрос извне. На логическом уровне подобный запрос может выглядеть как «‎Если на порт XXX придет TCP-запрос, то перенаправь его на локальный адрес 192.168.XXX.XXX на порт YYY»‎. Давайте посмотрим 2 способа как нам настроить NAT на Mikrotik.

Способ 1. Когда выходной IP-адрес может меняться

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

где ether1 — интерфейс, смотрящий в интернет. Также можно задать не один выходной интерфейс, а сразу несколько, заранее сформировав список out-interface-list.

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

Способ 2. Когда выходной IP-адрес статический и не меняется

Теперь еще один вариант организации NAT. Рассмотрим пример:

где XXX.XXX.XXX.XXX — статический IP-адрес, а ether1 — выходной интерфейс.

Теперь переходим к пробросу портов. Для примера предположим, что у нас в локальной сети 192.168.88.0/24 есть небольшой сервер по адресу 192.168.88.10 с поднятым SSH. Нам нужно подключаться к серверу удаленно, используя номер порта 1122. Для этого выполним проброс портов, созданием правила:

Почему мы взяли такой странный номер порта 1122? Все просто — чтобы затруднить злоумышленникам нахождение номера порта и последующего перебора реквизитов. Таким образом, мы создали правило, однозначно позволяющее маршрутизатору понять, что все TCP-пакеты, пришедшие на порт 1122 следует переадресовывать на локальный адрес 192.168.88.10 на порт 22.

Вместо заключения

Мы рассмотрели основные команды для выстраивания базовой защиты для устройств на базе RouterBoard, а также облачной версии Mikrotik CHR и взглянули на то, как можно парой команд настроить NAT. Разумеется, для каждого неиспользуемого сервиса можно закрыть доступ извне, исходя из используемых портов, протоколов и типа трафика.

Угроз безопасности с каждым днем становится все больше и каждая из них заслуживает внимания и адекватного ответа.

Источник