Mikrotik hex rb750gr3 настройка firewall

Создание домашней сети на базе устройств MikroTik: Часть 3 — Настройка RB750Gr3 hEX

Мы настроили наш основной роутер hAP ac для работы со статическим IP провайдера и провели базовую настройку не затрагивая настройку защищенного туннеля (VPN).
Произведем настройку для роутера hEX RB750Gr3. (hEX S похож на него)
Суть и методика настройки не особо отличается от настройки модели hAP ac. В этой модели просто нет Wi-Fi.

Подключим роутер к ПК/Ноутбуку через порт 2, а кабель провайдера в порт Internet.
Красным — интернет / Синим — локальный

На ПК для сетевого интерфейса устанавливаем статический IP 192.168.88.5 и маску сети 255.255.255.0
Это нужно если у роутера отсутствует IP адрес.

Открываем утилиту WinBox (Подробнее: Тут и Тут). Сбрасываем все заводские настройки, они нам не понадобятся!
Сброс настроек Консольно:
/system reset-configuration no-defaults=yes skip-backup=yes
Подтверждаем сброс настроек.
После этой процедуры, у роутера не будет IP адреса, поэтому подключаемся по MAC адресу.
Все настройки будут сброшены, начнем настройку:

1. Настраиваем сетевые интерфейсы
Все также, как и для hAP ac.
Данный роутер будет располагаться территориально далеко, например в другом городе, соответственно все настройки делаем для используемого провайдера.
Все интерфейсы RJ45 входят в один свич(switch1) поэтому нам нужно отделить порт для провайдера, и порты для локальных соединений.
Выбираем интерфейс ether1 и переименовываем его в WAN
Меняем имя порта ether1 Консольно:
/interface ethernet
set [find default-name=ether1] name=WAN

Выбираем интерфейс ether2 и переименовываем его в LAN1-Ethernet
Т.к все сетевые порты у нас находятся в свиче, мы можем сделать один из портов ведущим(Мастер порт), а остальные ведомыми(Слейв порты). По сути получится, как будто каждый из портов это один и тот же порт.
Из-за изменений в прошивке 6.41 в работе Сетевых мостов старый метод не работает. У сетевых портов исключили параметр Master Port.
Теперь в сетевой мост необходимо добавлять интерфейсы по отдельности.
Меняем имя порта ether2 Консольно:
/interface ethernet
set [find default-name=ether2] name=LAN1-Ethernet
Остальные ether3, ether4 и ether5 переименовываем соответствующе LAN2-Ethernet, LAN3-Ethernet, LAN4-Ethernet
Для остальных делаем по аналогии Консольно:
/interface ethernet
set [find default-name=ether3] name=LAN2-Ethernet
set [find default-name=ether4] name=LAN3-Ethernet
set [find default-name=ether5] name=LAN4-Ethernet

2. Создадим сетевой мост
Сетевой мост будет служить основным интерфейсом, который соберет в себе все наши локальные интерфейсы. Т.е. нужно добавить к новому сетевому мосту все нужные интерфейсы.
Также мы помним, что мы сделали мастер порт и часть портов привязали к нему, соответственно все второстепенные порты добавлять не нужно.

Создадим сам сетевой мост. Назовем его LAN-Bridge
В этом меню можно создавать сетевые мосты Настраиваем сетевой мост Начнем добавлять порты.
Добавляем все наши локальные порты На данный момент в сетевой мост мы добавим только Мастер порт. В дальнейшем мы добавим в этот мост специальный интерфейс туннеля, но об этом позже.
В момент добавления интерфейса LAN1-Master Вас может отключить от роутера, в этом нет ничего страшного, просто подключаемся снова.

Консольно:
/interface bridge
add name=»LAN-Bridge» comment=»LAN» mtu=1500 fast-forward=no igmp-snooping=yes protocol-mode=none
/interface bridge port
add interface=LAN1-Ethernet disabled=no
add interface=LAN2-Ethernet disabled=no
add interface=LAN3-Ethernet disabled=no
add interface=LAN4-Ethernet disabled=no

3. Разрешим нашему роутеру обрабатывать DNS
Разрешаем обработку DNS запросов

Консольно:
/ip dns set allow-remote-requests=yes cache-size=4096

4. Подключение к провайдеру
У меня и второй Интернет провайдер предоставляет интернет по DHCP. Т.е. необходимо настроить DHCP клиент на порт в который вставлен кабель провайдера (WAN)
Находим нужное меню и добавляем новое правило Параметров не много В столбце IP Address мы должны увидеть IP от провайдера.

Консольно:
/ip dhcp-client
add interface=WAN add-default-route=yes disabled=no default-route-distance=1 use-peer-dns=yes use-peer-ntp=yes

5. Доступ в интернет
Для того, чтобы наши клиенты могли выходить в сеть интернет, нам необходимо указать, через какой интерфейс они будут это делать.
Эти настройки делаются через Межсетевой экран (Firewall)
Переходим в межсетевой экран и добавляем правило Указываем основные параметры Указываем еще один параметр В принципе этого достаточно, чтобы на роутере уже появился интернет. Но у клиентов его не будет т.к. еще нет IP адреса и локального DHCP сервера.

Консольно:
/ip firewall nat
add chain=srcnat out-interface=WAN action=masquerade

6. IP адрес роутера
Теперь назначим нашему роутеру IP адрес.
Мы определили, что в Локации 2 будет следующий разброс:
IP адрес роутера: 192.168.88.2
IP адреса для клиентов: 192.168.88.30 — 192.168.88.59
29 адресов должно хватить для всех устройств в квартире, даже с избытком.
Переходим в меню IP адресов Добавляем IP адрес для нашего сетевого моста Так мы указываем, что IP адрес 192.168.88.2 привязать к интерфейсу LAN-Bridge

Консольно:
/ip address
add address=192.168.88.2/24 interface=LAN-Bridge

7. DHCP Сервер для локальных клиентов
Для того, чтобы наши клиенты могли подключаться к нашему роутеру и получать от него IP адреса и другие параметры, необходимо настроить DHCP сервер.
Первоначально укажем Pool IP адресов
Переходим в меню диапазонов IP адресов Добавляем обозначенный диапазон

Теперь добавляем сам DHCP сервер
Переходим в меню DHCP серверов Задаем настройки DHCP сервера Осталось еще указать для какой сети и какие дополнительные параметры будут получать подключенные клиенты.
Указываем дополнительные параметры Каждый подключенный клиент будет получать от DHCP сервера набор параметров:
Шлюз и DNS — В нашем случае и тем и другим будет выступать сам роутер.

Консоль:
/ip pool
add name=LAN-Pool ranges=192.168.88.30-192.168.88.59
/ip dhcp-server
add name=DHCP-Server interface=LAN-Bridge lease-time=12h address-pool=LAN-Pool bootp-support=dynamic bootp-lease-time=lease-time add-arp=yes authoritative=yes
/ip dhcp-server network
add address=192.168.88.0/24 gateway=192.168.88.2 netmask=24 dns-server=192.168.88.2

Настройка роутера hEX (RB750Gr3) завершена.
Далее мы рассмотрим создание туннеля для связки двух роутеров и организации единой локальной сети с сетевой маской 255.255.255.0 (24)
Создание домашней сети на базе устройств MikroTik: Часть 4 — Создание OpenVPN туннеля

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

Читайте также:  Zyxel gs1100 24 характеристики

UPD: 02.10.2018
Внесены правки в настройки проводных сетевых интерфейсов и сетевого моста из-за выхода прошивки 6.42.9 (Long-Term)
Как я уже рассказывал я пользуюсь исключительно прошивками ранее (Bugfix), которые сейчас изменены на ветку (Long-Term) т.е. длительной поддержки.
Подробнее прочитать про Bridge Hardware Offloading можно на Wiki MikroTik Switch_Chip_Features (Bridge_Hardware_Offloading) [ENG]

Важное замечание. На данном роутере Bridge Hardware Offloading поддерживается через switch chip MT7621
Но для его включения необходимо отключить у самого интерфейса бриджа IGMP Snooping и выбрать Protocol mode = none на вкладке STP
Поэтому если вы используете IGMP или STP/RSTP/MSTP и хотите получить аппаратную разгрузку бриджа, вам необходимо другое оборудование.

*) bridge — ignore tagged BPDUs when bridge VLAN filtering is used;
*) bridge — improved packet handling when hardware offloading is being disabled;
*) crs317 — fixed packet forwarding on bonded interfaces without hardware offloading;
*) crs326/crs328 — fixed packet forwarding when port changes states with IGMP Snooping enabled;
*) defconf — properly clear global variables when generating default configuration after RouterOS upgrade;
*) dns — fixed DNS cache service becoming unresponsive when active Hotspot server is present on the router (introduced in 6.42);
*) filesystem — fixed NAND memory going into read-only mode (requires «factory-firmware» >= 3.41.1 and «current-firmware» >= 6.43);
*) health — added missing parameters from export;
*) health — fixed voltage measurements for RB493G devices;
*) hotspot — properly update dynamic «walled-garden» entries when changing «dst-host»;
*) ike2 — fixed rare authentication and encryption key mismatches after rekey with PFS enabled;
*) ike2 — improved subsequent phase 2 initialization when no child exist;
*) ipsec — improved invalid policy handling when a valid policy is uninstalled;
*) ipsec — improved stability when using IPsec with disabled route cache;
*) led — added «dark-mode» functionality for wsAP ac lite, RB951Ui-2nD, hAP, hAP ac lite and LtAP mini devices;
*) lte — fixed LTE interface not working properly after reboot on RBSXTLTE3-7;
*) lte — fixed LTE registration in 2G/3G mode;
*) ospf — improved link-local LSA flooding;
*) ospf — improved stability when originating LSAs with OSPFv3;
*) routerboard — fixed memory tester reporting false errors on IPQ4018 devices («/system routerboard upgrade» required);
*) routerboard — show «boot-os» option only on devices that have such feature;
*) routerboot — fixed RouterOS booting on devices with particular NAND memory;
*) sniffer — made «connection», «host», «packet» and «protocol» sections read-only;
*) supout — added «files» section to supout file;
*) upgrade — fixed RouterOS upgrade process from RouterOS v5 on PowerPC;
*) upnp — improved UPnP service stability when handling HTTP requests;
*) userman — fixed «shared-secret» parameter requiring «sensitive» policy;
*) w60g — added «frequency-list» setting;
*) w60g — fixed interface LED status update on connection;
*) w60g — fixed random disconnects;
*) w60g — general stability and performance improvements;
*) webfig — fixed time interval settings not applied properly under «IP/Kid Control/Kids» menu;
*) webfig — fixed www service becoming unresponsive;
*) winbox — show «System/RouterBOARD/Mode Button» on devices that has such feature;
*) wireless — accept only valid path for sniffer output file parameter;
*) wireless — fixed «/interface wireless sniffer packet print follow» output;

Источник

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

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

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

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

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

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

  1. Цепочка INPUT — входящий трафик, приходящий на маршрутизатор.
  2. Цепочка OUTPUT — исходящий трафик, создаваемый маршрутизатором.
  3. Цепочка FORWARD — трафик, проходящий сквозь через маршрутизатор.

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

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

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

  1. New — исходя из названия ясно, что это новое соединение, а не одно из существующих.
  2. Established — соединение установлено, по нему можно передавать пакеты данных.
  3. Related — соединение, которое относится уже к какому-либо из существующих, но используемое в иных целях. Пока не будем заострять на этом внимание, чтобы не усложнять.
  4. Invalid — некорректное соединение, то есть маршрутизатор понятия не имеет, что это за соединение и как его обрабатывать.

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

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

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

Читайте также:  Mikrotik nat rules order

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

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

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

  1. add action=accept — принимать пакеты.
  2. chain=input — правило будет работать в цепочке входящего трафика.
  3. comment=»default configuration» — это просто комментарий-напоминалка, в нашем случае указываем, что это конфигурация по умолчанию, но можно вообще этот параметр не указывать.
  4. connection-state=established,related — указываем какие статусы соединения будем принимать.

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

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

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

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

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

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

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

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

  1. Прилетел снаружи ICMP-пакет. Машрутизатор смотрит в правило номер 0 — есть ли уже установившееся соединение. Если нас пингуют впервые, то статус соединение будет New, а не Established или Related. Так что правило не срабатывает.
  2. Смотрим дальше — есть ли IP-адрес с которого пришел пакет в списке allowed_to_router. Поскольку мы этот список еще не формировали, то его еще не существует и, следовательно, правило также не срабатывает.
  3. Наконец доходим до правила 2, которое однозначно говорит маршрутизатору, что следует принять (Accept) и обработать по протоколу ICMP данный пакет. Маршрутизатор отвечает на ICMP-пакет соответствующим эхо-ответом. До четвертого правила пакет уже не добирается, т.к. процедура обработки фактически завершена.

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

  1. Смотрим правило 0. Существующего Established или Related соединения у нас нет, поэтому правило не срабатывает.
  2. Правило 1 — смотрим в список разрешенных адресов allowed_to_router, но там пусто. Еще одно правило не сработало.
  3. Дошли до правила 2 — является ли пришедший пакет ICMP-пакетом. Нет, не является, так что правило не срабатывает.
  4. И вот мы дошли до конца цепочки INPUT, где нас поджидает «‎правило-вышибала”. Поскольку у правила chain=input action=drop нет условий для срабатывания, то оно по умолчанию срабатывает всегда и наш неизвестный 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.

Читайте также:  Ttl exceeded mikrotik что это

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

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

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

Источник

Adblock
detector