блокировка ip адреса mikrotik

Блокировка ip адреса mikrotik

Бесплатный чек-лист
по настройке RouterOS
на 28 пунктов

Блокировка IP-адресов которые стучатся на Mikrotik

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

1) Erik_U прав, я выскажу кратко: если сервис не нужен на внешнем адресе,
надо явно значит запретить. В линуксе местами было проще, в некоторых
хорошо развитых сервисах явно можно было указать на каком интерфейсе
работать. Поэтому ограничьте или запретите снаружи всё лишнее

Источник

Легкий способ защитить свой Mikrotik от атак

Хочу поделиться с сообществом простым и рабочим способом, как при помощи Mikrotik защитить свою сеть и «выглядывающие» из-за него сервисы от внешних атак. А именно всего тремя правилами организовать на Микротике honeypot.

Итак, представим, что у нас небольшой офис, внешний IP за которым стоит RDP сервер, для работы сотрудников по удаленке. Первое правило это конечно сменить порт 3389 на внешнем интерфейсе на другой. Но это ненадолго, спустя пару дней журнал аудита терминального сервера начнет показывать по несколько неудачных авторизаций в секунду от неизвестных клиентов.

Другая ситуация, у Вас за Mikrotik спрятан asterisk, естественно не на 5060 udp порту, и через пару дней также начинается перебор паролей… да да, знаю, fail2ban наше вcё, но над ним еще попыхтеть придется… вот я например недавно поднял его на ubuntu 18.04 и с удивлением обнаружил, что из коробки fail2ban не содержит актуальных настроек для asterisk из той же коробки того же ubuntu дистрибутива… а гуглить быстрые настройки готовых «рецептов» уже не получается, цифры у релизов с годами растут, а статьи с «рецептами» для старых версий уже не работают, а новых почти не появляется… Но что-то я отвлекся…

Итак, что такое honeypot в двух словах — это приманка, в нашем случае какой-либо популярный порт на внешнем IP, любой запрос на этот порт от внешнего клиента отправляет src адрес в черный список. Все.

Первое правило на популярных TCP портах 22, 3389, 8291 внешнего интерфейса ether4-wan отправляет IP «гостя» в список «Honeypot Hacker» (порты для ssh, rdp и winbox заблаговременно отключены или изменены на другие). Второе делает то же самое на популярном UDP 5060.

Третье правило на стадии прероутинга дропает пакеты «гостей» чей srs-address попал в «Honeypot Hacker».

Спустя две недели работы моего домашнего Mikrotik список «Honeypot Hacker» включил в себя около полутора тысяч IP адресов любителей «подержать за вымя» мои сетевые ресурсы (дома своя телефония, почта, nextcloud, rdp) Brute-force атаки прекратились, наступило блаженство.

На работе не все так просто оказалось, там rdp сервер продолжают ломать перебором паролей.

Судя по всему номер порта определили сканером за долго до включения honeypot, а во время карантина не так-то легко перенастроить более 100 пользователей, из которых 20% старше 65 лет. В случае когда порт менять нельзя, есть небольшой рабочий рецепт. Подобное в интернете встречал, но тут присутствует допил и тонкая настройка:

За 4 минуты удаленному клиенту разрешается сделать только 12 новых «запросов» к RDP серверу. Одна попытка входа — это от 1 до 4 «запросов». При 12-ом «запросе» — блокировка на 15 минут. В моем случае злоумышленники сервер взламывать не перестали, подстроились под таймеры и теперь делают это очень медленно, такая скорость подбора сводит эффективность атаки к нулю. Сотрудники предприятия от принятых мер никаких неудобств в работе практически не испытывают.

Это правило включается по расписанию в час ночи и выключается в 5, когда живые люди точно спят, а автоматизированные подборщики продолжают бодрствовать.

Уже на 8ом по счету соединении IP злоумышленника отправляется в черный список на неделю. Красота!

Ну и в довесок к вышесказанному добавлю ссылку на Wiki статью, с рабочей настройкой защиты Микротика от сетевых сканеров. wiki.mikrotik.com/wiki/Drop_port_scanners

На моих устройствах эта настройка работает вместе с вышеописанными honeypot правилами, неплохо их дополняя.

UPD: Как подсказали в комментариях, правило дропа пакетов перемещено в RAW, для снижения нагрузки на роутер.

Источник

Создание домашней сети на базе устройств MikroTik: Часть 6 – Firewall защита доступа

Продолжение предыдущих статей по организации единой локальной сети.

В прошлых частях мы с Вами настроили единую локальную сеть через EoIP туннель построенном поверх OpenVPN.

К каким результатам мы пришли:
У нас встает вопрос безопасности нашей локальной сети, ведь китайские боты не спят и постоянно сканируют доступное сетевое пространство на наличие дыр и уязвимостей.
Имея статический IP мы подвержены риску быть взломанными. Т.к. наш статический IP доступен в интернете, он может подвергаться различного рода «атакам из вне».
Поэтому нам нужно сделать так, чтобы только мы могли подключаться к нашим роутерам и другим сервисам в локальной сети.
В принципе жесткую защиту мы делать не будем. У нас ведь не корпоративная сеть, а домашняя. Данной статьей мы попробуем закрыть самые распространенные пробелы в защите нашего роутера и локальной сети в общем. Не будем допускать банальных ошибок.

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

За все операции обработки трафика в сетевых устройствах отвечает так называемый “Межсетевой экран” (Eng – Firewall)
Именно он определяет куда отправлять тот или иной пакет, как обрабатывать соединения и многое, многое другое…
Чтобы охватить весь спектр работы Firewall-а не хватит не только одной статьи, но и 10 или 20 статей точно. Настолько велики его возможности и вариации применения.
Кстати это касается не только MikroTik RouterOS, а принципа фильтрации трафика в общем в операционных системах (даже на Windows)!

Официальные данные на MikroTik Wiki: IP/Firewall/Filter [ENG]

Кратко пробежимся по основным вкладкам Firewall:
1 – Filter Rules – тут основные разрешающие и блокирующие правила.
2 – NAT – тут формируются перенаправления трафика.
3 – Mangle – тут происходит маркировка соединений и пакетов, отлов определенного вида трафика для дальнейшей его обработки.
Остальные вкладки пока рассматривать не будем, они нам не пригодятся.
4 – Raw – тут можно правилами отловить паразитный трафик и тем самым снизить нагрузку на CPU. Полезно для смягчения DOS атак.
5 – Service Ports – Для некоторых сетевых протоколов требуется прямое двустороннее соединение между конечными точками. Это не всегда возможно, поскольку трансляция сетевых адресов широко используется для подключения клиентов к сети. Это подменю позволяет настроить «помощники отслеживания соединений» для вышеупомянутых протоколов. Эти «помощники» используются для обеспечения правильного обхода NAT.
6 – Connections – тут отображаются все текущие соединения проходящие через маршрутизатор.
7 – Address List – тут списки адресов брандмауэра позволяют пользователю создавать списки IP-адресов, сгруппированных под общим именем. Затем фильтры брандмауэра, Mangle и NAT могут использовать эти списки адресов для сопоставления пакетов с ними.
8 – Layer7 Protocols – тут можно создавать шаблоны для поиска в потоках ICMP / TCP / UDP. L7 собирает первые 10 пакетов соединения или первые 2KB соединения и ищет шаблон в собранных данных.

Часть терминов может показаться непонятной, но в этом нет ничего страшного, мы будем работать только с первым пунктом Filter Rules. Хотя в нем тоже, очень много вариантов создания правил.
Сразу нужно оговориться, что полной безопасности Вам никто не обеспечит и это важно понимать! Но боятся не стоит, мы ведь не популярная корпорация за которой ведется промышленный шпионаж, нам достаточно превентивных мер ))))

Конфигурация по умолчанию:

На MikroTik Wiki представлена базовая конфигурация в таком виде: Basic universal firewall script [ENG]

Вы можете использовать её или нет )
Я делаю несколько по своему, возможно что-то тут не идеально, и Вы обладая большим опытом подскажите мне в комментариях, как сделать лучше ))

1. Перейдем к созданию правил в Firewall Filter Rules

1.1. Перво наперво нам нужно разрешить уже установленные(Established) и связанные(Related) соединения и сбросить некорректные(Invalid) соединения для проходящих (маршрутизируемых) пакетов в цепочке Forward и предназначенных локальной системе в цепочке Input.
Так мы снизим нагрузку на маршрутизатор обработав эти данные сразу.
Зачем повторно обрабатывать эти соединения если они уже и так установлены или неизвестны. Экономим ресурсы процессора. Т.е. эти правила будут в самом начале нашей таблицы.

1.2. Далее необходимо обеспечить защиту. Продолжим мы с Лимита входящих соединений.
Это даст нам некоторую защиту от DDoS атак.

1.3. Следом идет защита от SYN флуда.
Что это такое можно почитать тут: https://ru.wikipedia.org/wiki/SYN-флуд или в более профильных изданиях.
Защищать мы будем, как проходящий трафик, так и входящий трафик. Путем создания отдельной цепочки SYN-Protect

1.4. Защита от сканеров портов (PSD – Port Scan Detection).
На счет данного правила есть разные мнения, кто-то считает, что оно не нужно, кто-то, что нужно.
Я же предпочитаю немного себя подстраховать. Тем более, что благодаря данному правилу Address Lists заполняется какими-то забугорными IP адресами )

1.5. Защита WinBox порта от перебора.
Логика обработки тут следующая.
1. Когда мы подключаемся к роутеру на порт 8291, то мы имеет состояние соединения new, правило добавляет наш IP в список уровня 1
2. Если мы не авторизовались и отключились, а после снова пытаемся подключиться, то мы опять будем иметь состояние соединения new. При этом наш IP адрес уже будет в Списке 1
Соответственно наш IP попадет в список уровня 2 и т.д до тех пор пока нас не заблокирует Правило 13, и уже после этого Правило 12 не будет нам давать возможность новых подключений к роутеру по порту 8291.
3. А если мы авторизовались, то наше соединение перейдет из состояния new в состояние established и обработка соединения уже будет вестись самым верхним правилом 2, которое нам все разрешает.
По сути у злоумышленника может быть всего четыре возможности Авторизоваться у нас на роутере через порт WinBox

1.6. Защита OpenVPN порта от перебора.
Данная защита делается абсолютно аналогично пункту 1.5.
Единственным отличием будут названия OpenVPN вместо WinBox и входящий TCP порт 1194
Поэтому просто повторяем действия
Консольно:

1.7. Разрешающее правило для прохождения любого трафика по VPN туннелям.

1.8. Разрешающее правило для прохождения только нормальных PING запросов.

1.9. Запрещающее правило
Нормально закрытый Firewall должен обязательно обладать таким правилом. Иначе все бессмысленно.
Выше мы обрабатываем соединения и разрешаем только то, что нам необходимо. Все остальное блокируем.
Это намного правильней, чем Разрешить все и блокировать только нужное Вам. А всего, что нужно заблокировать Вы наверняка не знаете.

2. Для ленивых
Если Вы дочитали до конца, значит у Вас пытливый ум и Вы хорошо представляете с чем столкнулись. Вы молодец.
Еще раз хотелось бы обозначить, что данная конфигурация не является идеальной. Я просто старался показать некоторые способы фильтрации трафика. Вам решать, использовать это у себя простым копипастом или подумать и сделать лучше! Но я уверен, что моё решение тоже не плохое =)

Бонус:
Работая с Firewall на родительском hEx роутере, обнаружил большой объем заблокированного трафика.
Решил посмотреть, в чем дело, включил логирование в правилах и обнаружил интересную ситуацию.
Оказалось, что местный провайдер не закрыл широковещательный трафик службы имен NetBIOS Name Service – UDP порт 137 (Остальные порты и информация: https://ru.wikipedia.org/wiki/NetBIOS)
И какой-то “Сосед” воткнул интернет кабель в простой ПК с Windows, тем самым создав тот самый паразитный трафик. Такие запросы с одного ПК могут занимать около 30 кбит/сек на вашем WAN порту.
Думаю можно себе представить если таких ПК в сети будет 100-150. Написали провайдеру, а пока он латает свои дыры, добавил правило блокировки. Только не в Firewall Filter, а в Firewall Raw.
Данная таблица полезна для уменьшения нагрузки на CPU и позволяет блокировать трафик на этапе Prerouting-а
Вот это правило:

Бонус 2:

Всего хорошего на просторах Интернета 😉

Список всех статей в хронологическом порядке: История статей

UPD 11.10.2018:
Статья обновлена исходя из опыта эксплуатации и дальнейшего перехода на работу со Списками интерфейсов
Для понимания, что это такое, изучите статью MikroTik RouterOS – Списки интерфейсов “Interface List”

UPD 12.08.2019:
В начало статьи добавлена заметка. Ряд читателей почему-то думает, что эта статья это вся настройка Firewall и удивляется, что нет интернета 🙂
Будьте внимательней!

Читайте также: перенос котла в квартире

UPD 05.10.2019:
Для тех кого интересует финальный результат и более лучшая защита, то рекомендую после прочтения данной статьи перейти к статье: MikroTik : RouterOS : Стучимся к себе домой. Firewall Filter PortKnocking

UPD: 31.03.2020:
Добавлен “Бонус 2” с правилами для роутера за серым IP провайдера

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Источник

Настройка 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. Разумеется, для каждого неиспользуемого сервиса можно закрыть доступ извне, исходя из используемых портов, протоколов и типа трафика.

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

Источник