+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Запрос на функцию: «Группа обслуживания»

Запрос на функцию: «Группа обслуживания», RouterOS

tomaskir

Guest

04.05.2012 10:38:00

Ребята, я видел, что несколько человек спрашивали про возможность разрешать TCP и UDP в одном правиле для firewall/nat/mangle, но почему бы не зайти чуть дальше? Мне очень хотелось бы иметь опцию, похожую на Address Lists, но для разных протоколов/портов. Например: я создаю «Service Group» под названием «IPSec_VPN». В эту группу сервисов вошли бы: протокол UDP, порт назначения 500; протокол IPSec-ESP; протокол IP-Encap. Тогда я мог бы создать правило firewall/NAT/Mangle, использующее эту «Service Group» с такой же функциональностью, как мы используем Address Lists для адресов. Одно правило, которое срабатывает на множество условий, определённых в «Service Group».

Пример конфигурации firewall:

/ip firewall filter
# цепочка input
add action=accept chain=input connection-state=established,related
add action=drop chain=input connection-state=invalid
add action=accept chain=input limit=5,5 service-group="ICMP WAN"
add action=accept chain=input service-group="ROS Management WAN" in-interface=ether1-WAN
add action=accept chain=input service-group="ROS Management LAN" in-interface=ether2-LAN
add action=accept chain=input service-group="ROS VPN" src-address-list="VPN Partners"
add action=drop chain=input

# цепочка forward
add action=accept chain=forward connection-state=established,related
add action=drop chain=forward connection-state=invalid
add action=accept chain=forward in-interface=ether2-LAN out-interface=ether1-WAN comment="Allow LAN -> WAN"
add action=accept chain=forward dst-address=XXX.XXX.XXX.XXX service-group="HTTP"
add action=accept chain=forward dst-address=XXX.XXX.XXX.XXY service-group="DNS"
add action=accept chain=forward dst-address-list=Servers limit=2,2 service-group="ICMP Servers"
add action=drop chain=forward

Address Lists будут определены так:
Address List «Servers» содержит IP:
XXX.XXX.XXX.YYY
XXX.XXX.XXX.ZZZ

Address List «VPN Partners» содержит IP:
XXX.XX.X.YZ
XXX.XX.XYZ.YZ
XX.XYZ.XY.XY

А Service Groups определены так:
Service Group «ROS Management LAN» содержит:
dst-port=5678,20561 protocol=udp
dst-port=22,8291 protocol=tcp

Service Group «HTTP» содержит:
dst-port=80 protocol=tcp
dst-port=443 protocol=tcp

Service Group «DNS» содержит:
dst-port=53 protocol=tcp
dst-port=53 protocol=udp

Service Group «ICMP Servers» содержит:
icmp-options=0:0-255 protocol=icmp
icmp-options=3:3 protocol=icmp
icmp-options=3:4 protocol=icmp
icmp-options=8:0-255 protocol=icmp
icmp-options=11:0-255 protocol=icmp

Service Group «ROS Management WAN» содержит:
dst-port=8291 protocol=tcp

Service Group «ICMP WAN» содержит:
icmp-options=0:0-255 protocol=icmp
icmp-options=3:3 protocol=icmp
icmp-options=3:4 protocol=icmp
icmp-options=8:0-255 protocol=icmp
icmp-options=11:0-255 protocol=icmp

Service Group «ROS VPN» содержит:
protocol=UDP dst-port=500
protocol=ipsec-esp
protocol=encap
protocol=ipip

Это всего лишь примеры. Лично для меня это реально очистило бы цепочки firewall и таблицу NAT. Буду рад любой дискуссии на эту тему! Спасибо, tom

Sob

Guest

13.03.2018 16:15:00

Было бы здорово добавить поддержку более продвинутых списков — это особенно помогло бы при большом количестве элементов. Но и решение с цепочками тоже неплохое:

/ip firewall filter
# базовый файрвол
add action=accept chain=forward comment="принять установленные и связанные" connection-state=established,related
add action=drop chain=forward comment="отбросить недействительные" connection-state=invalid
add action=accept chain=forward comment="worknet имеет неограниченный доступ" in-interface=work-lan
add action=jump chain=forward comment="гости могут пользоваться только вебом" in-interface=guest-lan jump-target=service_web
add action=accept chain=forward comment="разрешить dstnat-соединения" connection-nat-state=dstnat
add action=jump chain=forward comment="соединения из интернета" in-interface=wan jump-target=incoming
add action=reject chain=forward comment="блокировать всё остальное" reject-with=icmp-admin-prohibited

# входящие соединения
add action=jump chain=incoming comment="почтовый сервер" dst-address=1.2.3.4 jump-target=service_mail
add action=jump chain=incoming comment="dns-сервер" dst-address=1.2.3.5 jump-target=service_dns
add action=jump chain=incoming comment="отдельный веб-сервер" dst-address=1.2.3.6 jump-target=service_web
add action=jump chain=incoming comment="другие веб-серверы из списка адресов" dst-address-list=web-cluster1 jump-target=service_web
add action=jump chain=incoming comment="ещё одна группа веб-серверов" dst-address-list=web-cluster2 jump-target=service_web
add action=jump chain=incoming comment="ipsec-соседи" jump-target=service_ipsec src-address-list=ipsec-peers

# повторно используемые цепочки для сервисов
add action=accept chain=service_web dst-port=80,443 protocol=tcp
add action=accept chain=service_mail dst-port=25,110,143,465,587,993,995 protocol=tcp
add action=accept chain=service_ipsec dst-port=500,4500 protocol=udp
add action=accept chain=service_ipsec protocol=ipsec-esp
add action=accept chain=service_ipsec protocol=ipsec-ah
add action=accept chain=service_dns dst-port=53 protocol=tcp
add action=accept chain=service_dns dst-port=53 protocol=udp

brotherdust

Guest

27.05.2012 20:40:00

Оборудование SonicWall тоже так работает. Группы упрощают управление (чем все, кстати, должны заниматься). Тем временем, я нашёл… ну, скажем так, обходной путь: использовать цепочки как «группы сервисов». Объясню на ваших примерах: создайте цепочку с именем «IPSec_VPN» с такими правилами:

/ip firewall filter add chain="IPSec_VPN" protocol="UDP" dst-port="500" action="accept"
add chain="IPSec_VPN" protocol="ipsec-esp" action="accept"
add chain="IPSec_VPN" protocol="encap" action="accept"
add chain="IPSec_VPN" action="jump" jump-target=SOME_OTHER_LIST_THAT_DENIES_ACCESS_TO_UNINITIATED_INCOMING_TRAFFIC

Если вы хотите явно разрешить VPN-доступ к роутеру, нужно добавить переход (jump) на эту новую цепочку в вашей цепочке input. Пакеты, подходящие под это правило, будут прыгать в новую цепочку. По сути, вы даёте контекст цепочке IPSec_VPN, указывая, какие пакеты туда переходят. Вот как это выглядит:

/ip firewall filter add chain="input" dst-address=WAN_IP action="jump" jump-target="IPSec_VPN"

Если нужно, например, группу машин, которым предоставляется доступ, используйте address-list. Если всё ещё непонятно, вот кусок из моего рабочего конфига:

/ip firewall filter
add action=jump chain=forward disabled=no dst-address-list=LAN jump-target=conn.in.est

# ---
# Используем address list, чтобы задать контекст для перехода в цепочку DMZ
add action=jump chain=forward comment=DMZ disabled=no dst-address-list=DMZ jump-target=DMZ src-address-list=!LAN
# --- ---
# В этом контексте используем dst-address для более точного перехода в цепочку DMZ.WWW
add action=jump chain=DMZ comment=DMZ.WWW disabled=no dst-address=XXX.XXX.XXX.XXX jump-target=DMZ.WWW
# В цепочке DMZ.WWW разрешаем нужный трафик
# Трафик, который не подходит под эту цепочку, остаётся в родительском контексте DMZ
add action=accept chain=DMZ.WWW disabled=no dst-port=80 protocol=tcp
add action=accept chain=DMZ.WWW disabled=no dst-port=443 protocol=tcp
# Эта строка для моего лимитера SSH
add action=jump chain=DMZ.WWW disabled=no dst-port=22 jump-target=limit_block protocol=tcp
# --- ---
# В этом контексте используем dst-address для более точного перехода в цепочку DMZ.DNS
add action=jump chain=DMZ comment=DMZ.DNS disabled=no dst-address=XXX.XXX.XXX.XXX jump-target=DMZ.DNS
# В цепочке DMZ.DNS разрешаем нужный трафик
# Трафик, не подходящий под эту цепочку, остаётся в родительском контексте DMZ
add action=accept chain=DMZ.DNS disabled=no dst-port=53 protocol=udp
add action=accept chain=DMZ.DNS disabled=no dst-port=53 protocol=tcp
# Эта строка для моего лимитера SSH. Возможно, можно было бы это как-то обобщить в цепочке DMZ, но не все хосты используют SSH. Зачем тогда давать доступ туда, где он не нужен?
add action=jump chain=DMZ.DNS disabled=no dst-port=22 jump-target=limit_block protocol=tcp
# ---
# Эта часть относится ко всему, что прошло через контекст DMZ, включая WWW и DNS, так как цепочка продолжается вниз (напомню, порядок сверху вниз!)
# Разрешаем пинг, переходя в цепочку ICMP
add action=jump chain=DMZ disabled=no jump-target=ICMP protocol=icmp
# Предоставляем контекст для всего остального трафика, чтобы он шел в цепочку conn.in.est (входящие установленные соединения)
add action=jump chain=DMZ disabled=no jump-target=conn.in.est

# Входящие установленные соединения
add action=accept chain=conn.in.est comment=conn.in.est connection-state=established disabled=no
add action=accept chain=conn.in.est connection-state=related disabled=no
add action=drop chain=conn.in.est connection-state=invalid disabled=no
# Все остальные прыгают в цепочку drop
add action=jump chain=conn.in.est disabled=no jump-target=drop

add action=drop chain=drop comment="Drop all" disabled=no

# Лимит ICMP, но разрешаем
add action=accept chain=ICMP comment="0:0 and limit for 5pac/s" disabled=no icmp-options=0:0-255 limit=5,5 protocol=icmp
add action=accept chain=ICMP comment="3:3 and limit for 5pac/s" disabled=no icmp-options=3:3 limit=5,5 protocol=icmp
add action=accept chain=ICMP comment="3:4 and limit for 5pac/s" disabled=no icmp-options=3:4 limit=5,5 protocol=icmp
add action=accept chain=ICMP comment="8:0 and limit for 5pac/s" disabled=no icmp-options=8:0-255 limit=5,5 protocol=icmp
add action=accept chain=ICMP comment="11:0 and limit for 5pac/s" disabled=no icmp-options=11:0-255 limit=5,5 protocol=icmp
add action=jump chain=ICMP comment="Drop everything else" disabled=no jump-target=drop

# Общий тарпит, обычно применяю для SSH
add action=accept chain=limit_block disabled=no src-address-list=limit_block_exempt
add action=accept chain=limit_block connection-state=new disabled=no limit=3/1m,2
add action=log chain=limit_block connection-state=new disabled=yes log-prefix=""
add action=add-src-to-address-list address-list=limit_block address-list-timeout=1w chain=limit_block connection-state=new disabled=no
add action=reject chain=limit_block disabled=no reject-with=icmp-host-unreachable src-address-list=limit_block

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

Дополнение: я подготовил визуальную «логическую цепочку», чтобы помочь вам. Смотрите:

Надеюсь, это немного поможет.

tomaskir

Guest

29.05.2012 13:12:00

Спасибо за информацию, но даже в твоём примере у тебя всё равно остаётся 3 правила фаервола для одного сервиса, ведь по-другому это не сделаешь.

/ip firewall filter
add chain="IPSec_VPN" protocol="UDP" dst-port="500" action="accept"
add chain="IPSec_VPN" protocol="ipsec-esp" action="accept"
add chain="IPSec_VPN" protocol="encap" action="accept"
add chain="IPSec_VPN" action="jump" jump-target=SOME_OTHER_LIST_THAT_DENIES_ACCESS_TO_UNINITIATED_INCOMING_TRAFFIC

То есть нужно создавать 3 отдельные записи в фаерволе для одного сервиса (VPN).

Если использовать Service Groups, то это была бы одна запись в фаерволе, где сервисы просто ссылаются на “Service group”, состоящую из нескольких сервисов. Прямо как с “Address Lists”, где в правилах фаервола можно указывать сразу несколько IP-адресов.

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

Например, гораздо чище фаервол выглядел бы так: (взято с одного из моих боевых конфигов, только подкорректировано для наглядности, как именно помогают Service Groups)

/ip firewall filter
# input цепочка
add action=accept chain=input connection-state=established,related
add action=drop chain=input connection-state=invalid
add action=accept chain=input limit=5,5 service-group="ICMP WAN"
add action=accept chain=input service-group="ROS Management WAN" in-interface=ether1-WAN
add action=accept chain=input service-group="ROS Management LAN" in-interface=ether2-LAN
add action=accept chain=input service-group="ROS VPN" src-address-list="VPN Partners"
add action=drop chain=input

# forward цепочка
add action=accept chain=forward connection-state=established,related
add action=drop chain=forward connection-state=invalid
add action=accept chain=forward in-interface=ether2-LAN out-interface=ether1-WAN comment="Allow LAN -> WAN"
add action=accept chain=forward dst-address=XXX.XXX.XXX.XXX service-group="HTTP"
add action=accept chain=forward dst-address=XXX.XXX.XXX.XXY service-group="DNS"
add action=accept chain=forward dst-address-list=Servers limit=2,2 service-group="ICMP Servers"
add action=drop chain=forward

Address Lists определяются так:

Address List "Servers" содержит IP-адреса
XXX.XXX.XXX.YYY
XXX.XXX.XXX.ZZZ

Address List "VPN Partners" содержит IP-адреса
XXX.XX.X.YZ
XXX.XX.XYZ.YZ
XX.XYZ.XY.XY

Service Groups определяются так:

Service Group "ROS Management LAN" содержит
dst-port=5678,20561 protocol=udp
dst-port=22,8291 protocol=tcp

Service Group "HTTP" содержит
dst-port=80 protocol=tcp
dst-port=443 protocol=tcp

Service Group "DNS" содержит
dst-port=53 protocol=tcp
dst-port=53 protocol=udp

Service Group "ICMP Servers" содержит
icmp-options=0:0-255 protocol=icmp
icmp-options=3:3 protocol=icmp
icmp-options=3:4 protocol=icmp
icmp-options=8:0-255 protocol=icmp
icmp-options=11:0-255 protocol=icmp

Service Group "ROS Management WAN" содержит
dst-port=8291 protocol=tcp

Service Group "ICMP WAN" содержит
icmp-options=0:0-255 protocol=icmp
icmp-options=3:3 protocol=icmp
icmp-options=3:4 protocol=icmp
icmp-options=8:0-255 protocol=icmp
icmp-options=11:0-255 protocol=icmp

Service Group "ROS VPN" содержит
protocol=UDP dst-port=500
protocol=ipsec-esp
protocol=encap
protocol=ipip

С таким подходом фаервол получается простой и понятный, и не нужно рисовать никаких схем логики цепочек, при этом он работает точно так же.

К тому же, если мне понадобится разрешить SSH с WAN к определённому ресурсу в сети, мне просто нужно добавить “dst-port=22 protocol=tcp” в нужную Service Group.

anav

Guest

11.03.2018 18:40:00

Какой статус у этого очевидного и логичного запроса — группировка портов/сервисов, похожая на подход с адресами для объектов, чтобы уменьшить путаницу в правилах файрвола и позволить изменять список без необходимости возиться с самими правилами. Кстати, такой же запрос по группировке портов/сервисов одинаково важен и для правил переадресации портов. Меня просто поражает, что чего-то подобного списку адресов (IP) для портов/сервисов до сих пор нет. Я пытаюсь перейти с роутера Zyxel и очень ценю логику и методы других проверенных производителей!

tomaskir Guest	#6 0 13.03.2018 10:36:00 Как видите, этот пост датируется ещё 2012 годом. С тех пор ничего не изменилось, что, конечно, огорчает. До сих пор невозможно задать какие-либо группы для протоколов, портов или сервисов в RouterOS.

anav

Guest

13.03.2018 11:39:00

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

anav

Guest

13.03.2018 18:07:00

Привет, Sob, мне понадобится время, чтобы врубиться, что ты тут делаешь. Совсем не шарю в JUMP, только начинаю разбираться с input и forward правилами (к маршрутизатору, через маршрутизатор). Любые быстрые объяснения будут очень кстати! Ещё меня запутало, как ты используешь FW правила без указания forward, input или output, но с = Service?? И, если говорить в общем, ты определяешь Chain=service как что-то вроде списка адресов для IP, но для сервисов? (ведь у них сами по себе нет IP, интерфейса или указания источника/назначения) В этом, конечно, есть смысл и это лучше, чем куча отдельных правил.

Sob

Guest

14.03.2018 03:50:00

Всё просто. Межсетевой экран использует цепочки правил, и пакеты проходят через них, пока не найдётся подходящее правило. Есть стандартные цепочки, например, «forward» или «input», но можно создавать и свои собственные. Маршрутизатор не будет учитывать их просто так, только потому что они существуют — нужно перейти к ним из стандартных цепочек. Когда это происходит, либо в кастомной цепочке находится подходящее правило (и обработка на этом заканчивается), либо, если такого нет, управление возвращается в исходную цепочку и продолжается там. И, к слову, приведённая конфигурация — это просто простой пример для forward, обычно ещё есть правила для input.

anav Guest	#10 0 14.03.2018 15:24:00 Итак, JUMP используется, по сути, чтобы перехватывать определённые пакеты в нужный момент и ПЕРЕНАПРАВЛЯТЬ их на другое кастомное правило фаервола (или набор правил). Если пакет совпадает с кастомным правилом(ами), то выполняется действие и на этом всё, если пакет не совпадает — он возвращается к следующему правилу после цепочки JUMP (то есть к упорядоченному набору правил). По сути, цепочка JUMP — это как условие IF: ЕСЛИ это, то сделать вот это, иначе продолжать дальше… ++++++++++++++++++++++++++++++++++++++++++++++++++++++ Похожим на JUMP я теперь открыл для себя MANGLE. (Медленно, знаю.) Он похож тем, что тоже используется для идентификации трафика, но с ним можно творить самые разные странные и удивительные вещи с этими пакетами. Сейчас я пытаюсь (безуспешно) использовать его, чтобы направить весь мой почтовый трафик с обеих LAN на WAN2, при том что WAN1 — основной (ближе, меньше пинг). Стоит ли мне ставить IP адрес почтового сервера WAN2 в правило mangle (или просто указать порт и список LAN интерфейсов)? Надо ли ставить IP адрес только в правило IP маршрутизации или в оба места? (Использую mark route и новую маршрутизацию по меткам). Проблема решилась — я не указал исходный адрес. Я думал, что если оставить поле пустым, то это значит все возможные IP в LAN, но почему-то прописывание 0.0.0.0 в источник сработало. Хотя не понимаю почему.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры