Remote Access и правила FW. Логический тупик.

RIP, OSFP, BGP, MPLS/VPLS
Аватара пользователя
Sweik
Сообщения: 77
Зарегистрирован: 14 июн 2018, 11:05
Откуда: Оттуда

Remote Access и правила FW. Логический тупик.

Сообщение Sweik »

Добрый день, уважаемое сообщество.
Настраивал Remote Access и немного загнал сам себя в тупик настройками безопасности :)

Если вкратце, то верхними правилами в FW у меня идет блокировка соединений от BOGON-сетей извне (с интерфейса, который смотрит наружу, eth1-WAN). До развертывания Remote Access-a никакого дискомфорта от такого подхода я не ощущал - не должны быть соединений с интернет-интерфейса от адреса 192.168.20.5, это был бы явный фейк.

Однако, после развертывания Remote Access-a такой подход только вредит. Сотрудник подключился, получил адрес для виртуального адаптера из диапазона 192.168.20.0/26 и соединения стали блокироваться по признаку BOGON :(
Отключать правила rule_01 и rule_02 (см. экспорт) не хотелось бы. Выводить дипазон 192.168.20.0/26 из BOGON-a тоже не хотелось бы - это, как никак, дырка.

Код: Выделить всё

# jul/10/2018 17:30:57 by RouterOS 6.41
# software id = XXXX
#
# model = RouterBOARD 3011UiAS
 

/ip firewall address-list
add address=0.0.0.0/8 list=BOGON
add address=10.0.0.0/8 list=BOGON
add address=100.64.0.0/10 list=BOGON
add address=127.0.0.0/8 list=BOGON
add address=169.254.0.0/16 list=BOGON
add address=172.16.0.0/12 list=BOGON
add address=192.0.0.0/24 list=BOGON
add address=192.0.2.0/24 list=BOGON
add address=192.168.0.0/16 list=BOGON
add address=198.18.0.0/15 list=BOGON
add address=198.51.100.0/24 list=BOGON
add address=203.0.113.0/24 list=BOGON
add address=224.0.0.0/4 list=BOGON
add address=240.0.0.0/4 list=BOGON
add address=192.168.40.0/26 list=LAN
add address=192.168.0.0/16 list=FALSE_INTERNAL
add address=192.168.20.0/26 list=VPN_range


add action=drop chain=input comment="Router: Drop connections from BOGON networks" \
    in-interface=eth1-WAN log=yes log-prefix="rule_01: drop from_bogon" src-address-list=BOGON
	
add action=drop chain=forward comment="Drop invalid outgoing" \
    dst-address-list=FALSE_INTERNAL log=yes log-prefix=\
    "rule_02: drop from_false_internal" out-interface=eth1-WAN
	
add action=accept chain=input comment="Allow establish Remote Access" in-interface=\
    eth1-WAN log=yes log-prefix="rule_03: ipsec sys" port=500,1701,4500 protocol=udp
	
add action=accept chain=input comment="Allow establish Remote Access" in-interface=\
eth1-WAN log=yes log-prefix="rule_04: ipsec sys" protocol=ipsec-esp
	
add action=accept chain=input in-interface=eth1-WAN log=yes \
    comment="Allow Use Remote Accesss" log-prefix="rule_05: ipsec ping" protocol=icmp
	
add action=accept chain=input comment="Router: Allow incoming PING - WAN" \
    in-interface=eth1-WAN limit=50/5s,2:packet log=yes log-prefix=\
    "rule_06: allow ping" protocol=icmp

add action=drop chain=input comment=\
    "Router: Drop any new incoming from WAN " connection-state=new \
    in-interface=eth1-WAN log=yes log-prefix="rule_07 drop new_incoming"
	
add action=accept chain=forward comment="Transit: accept from LAN to WAN" \
    connection-state=new in-interface=LAN-Bridge log=yes log-prefix=\
    "rule_08: allow outgoing" out-interface=eth1-WAN
В голове крутятся мысли о создании отдельного VLAN-a, тогда входящий трафик (уже после установки защищенного соединения) будет идти не на внешний интерфейс eth1-WAN, а на вирутальный, что позволит схитрить с правилами FW. Но я не уверен, что это - верный (правильный ) способ, не уверен, что разумно (безопасно) вешать VLAN со внутренней адресацией на внешний интерфейс и не имею в голове четкого плана на этот счет.

Вопрос больше глобального характера - а что посоветует в данном случае уважаемое сообщество? Нужна не по-шаговая инструкция, а, скорее, вектор развития.

Заранее и с уважением.
С уважением
Аватара пользователя
Chupaka
Сообщения: 3880
Зарегистрирован: 29 фев 2016, 15:26
Откуда: Минск
Контактная информация:

Re: Remote Access и правила FW. Логический тупик.

Сообщение Chupaka »

Добрый.

Какие соединения и как у вас стали блокироваться "по признаку BOGON"? Ваши правила 01 и 02 действуют на пакеты через eth1-WAN и только через него, на трафик внутри тоннеля VPN они никак не влияют. В других правилах упоминания BOGON нет.
Аватара пользователя
Sweik
Сообщения: 77
Зарегистрирован: 14 июн 2018, 11:05
Откуда: Оттуда

Re: Remote Access и правила FW. Логический тупик.

Сообщение Sweik »

Добрый день.
Блокироваться стали попытки пинговать адрес 192.168.40.1 - шлюз сегмента, выделенного под внутреннюю сеть. На стадии экспериментов я решил не прокидывать трафик внутрь сети. Если удаленный пользователь "увидит" шлюз внутренней сети - это уже хорошо.

Когда я же временно отключаю правила 01 и 02, то пинг становится доступен.
С уважением
Аватара пользователя
Sweik
Сообщения: 77
Зарегистрирован: 14 июн 2018, 11:05
Откуда: Оттуда

Re: Remote Access и правила FW. Логический тупик.

Сообщение Sweik »

я прекрасно понимаю, что
Ваши правила 01 и 02 действуют на пакеты через eth1-WAN и только через него, на трафик внутри тоннеля VPN они никак не влияют
пока ничего путного у меня не выходит.

Логи у меня выводятся в Spunk, смоделировать ситуацию могу в любое время.

С уважением
С уважением
Аватара пользователя
Chupaka
Сообщения: 3880
Зарегистрирован: 29 фев 2016, 15:26
Откуда: Минск
Контактная информация:

Re: Remote Access и правила FW. Логический тупик.

Сообщение Chupaka »

У вас на обоих правилах log=yes - посмотрите в Логе, что именно там блокировалось. 192.168.40.1 - это адрес данного роутера? Тогда данный трафик обрабатывается в chain=input, т.е. rule_01. А данное правило влияет только на трафик из Интернета. Загадка :)
Аватара пользователя
Sweik
Сообщения: 77
Зарегистрирован: 14 июн 2018, 11:05
Откуда: Оттуда

Re: Remote Access и правила FW. Логический тупик.

Сообщение Sweik »

Вот что получается
Изображение
https://a.radikal.ru/a38/1807/89/ef459b3f2bb8.png

Удаленный пользователь установил шифрованное соединение, получил адрес 192.168.20.1 и пытался пинговать шлюз 92.168.40.1
Микротик заблокировал соединение по самому первому правилу FW
Последний раз редактировалось Sweik 10 июл 2018, 19:29, всего редактировалось 1 раз.
С уважением
Аватара пользователя
Sweik
Сообщения: 77
Зарегистрирован: 14 июн 2018, 11:05
Откуда: Оттуда

Re: Remote Access и правила FW. Логический тупик.

Сообщение Sweik »

192.168.40.1 - это адрес данного роутера?
Да, одного из интерфейсов, который смотрит внутрь LAN-a
С уважением
Аватара пользователя
Chupaka
Сообщения: 3880
Зарегистрирован: 29 фев 2016, 15:26
Откуда: Минск
Контактная информация:

Re: Remote Access и правила FW. Логический тупик.

Сообщение Chupaka »

Так, eth1-WAN — это кто и как туда попал трафик этого VPN?.. Routing Marks/Rules на роутере не используются? Трассировку бы с клиента... Ещё и drop на reject заменить для проверки.
Аватара пользователя
Sweik
Сообщения: 77
Зарегистрирован: 14 июн 2018, 11:05
Откуда: Оттуда

Re: Remote Access и правила FW. Логический тупик.

Сообщение Sweik »

Доброе утро.
eth1-WAN - это WAN-интерфейс. Именно по нему пользователи изначально подключаются к рутеру для установки VPN-канала. Как на этом порту оказывается трафик от VPN - это мне самому интересно :)
Маршрутизацию кастомно не настравивал, там все автоматом создавалось
Изображение
https://b.radikal.ru/b36/1807/83/b4f8c418634b.jpg

Трассировку - речь идет о tracert -d 192.168.40.1 или нужен WireShark?
С уважением
Аватара пользователя
Sweik
Сообщения: 77
Зарегистрирован: 14 июн 2018, 11:05
Откуда: Оттуда

Re: Remote Access и правила FW. Логический тупик.

Сообщение Sweik »

Drop заменил на reject.

Код: Выделить всё

C:\Windows\system32>ping 192.168.40.1
Pinging 192.168.40.1 with 32 bytes of data:
Reply from 192.168.40.1: Destination net unreachable.
Reply from 192.168.40.1: Destination net unreachable.
Reply from 192.168.40.1: Destination net unreachable.
Reply from 192.168.40.1: Destination net unreachable.
Ping statistics for 192.168.40.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
C:\Windows\system32>tracert -d 192.168.40.1
Tracing route to 192.168.40.1 over a maximum of 30 hops
  1  192.168.40.1  reports: Destination net unreachable.
Trace complete.
C:\Windows\system32>
Временно отключил это правило

Код: Выделить всё

C:\Windows\system32>ping 192.168.40.1
Pinging 192.168.40.1 with 32 bytes of data:
Reply from 192.168.40.1: bytes=32 time=38ms TTL=64
Reply from 192.168.40.1: bytes=32 time=50ms TTL=64
Reply from 192.168.40.1: bytes=32 time=37ms TTL=64
Reply from 192.168.40.1: bytes=32 time=397ms TTL=64
Ping statistics for 192.168.40.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 37ms, Maximum = 397ms, Average = 130ms
C:\Windows\system32>
C:\Windows\system32>tracert -d 192.168.40.1
Tracing route to 192.168.40.1 over a maximum of 30 hops
  1    49 ms    37 ms    29 ms  192.168.40.1
Trace complete.
C:\Windows\system32>
при этом, в логах FW, по прежнему, фигурирует input: in:eth1-WAN
С уважением
Аватара пользователя
Chupaka
Сообщения: 3880
Зарегистрирован: 29 фев 2016, 15:26
Откуда: Минск
Контактная информация:

Re: Remote Access и правила FW. Логический тупик.

Сообщение Chupaka »

Так, стоп, а VPN какой используется? А то я всегда работал только с тоннелями, а тут вдруг вспомнил про IPSec... Может, в правило достаточно какой "ipsec-policy=!in,ipsec" добавить?.. Ну, и по аналогии.
Аватара пользователя
Sweik
Сообщения: 77
Зарегистрирован: 14 июн 2018, 11:05
Откуда: Оттуда

Re: Remote Access и правила FW. Логический тупик.

Сообщение Sweik »

Используется client-server (Remote Access) топология IPSec / IKEv2
Нужен ли экспорт?

Код: Выделить всё

Может, в правило достаточно какой "ipsec-policy=!in,ipsec" добавить?
не совсем понимаю, в какое поле надо добавлять?
С уважением
Аватара пользователя
Chupaka
Сообщения: 3880
Зарегистрирован: 29 фев 2016, 15:26
Откуда: Минск
Контактная информация:

Re: Remote Access и правила FW. Логический тупик.

Сообщение Chupaka »

В поле IPSec Policy на вкладке Advanced в rule_01 же :)
Аватара пользователя
Chupaka
Сообщения: 3880
Зарегистрирован: 29 фев 2016, 15:26
Откуда: Минск
Контактная информация:

Re: Remote Access и правила FW. Логический тупик.

Сообщение Chupaka »

Блин, там отрицания в этом параметре нет... Значит, надо, например, добавить выше правило, которое будет ipsec-policy=in,ipsec Accept'ить...
Аватара пользователя
Sweik
Сообщения: 77
Зарегистрирован: 14 июн 2018, 11:05
Откуда: Оттуда

Re: Remote Access и правила FW. Логический тупик.

Сообщение Sweik »

Так, я писал именно о том, что в правиле нет отрицания и даже прикладывал скриншот :)
Стер за ненадобностью.

Сейчас у меня на FW правила выглядят так:

Код: Выделить всё

add action=drop chain=input comment="Router: Drop connections from BOGON networks" \
    in-interface=eth1-WAN log=yes log-prefix="rule_01: drop from_bogon" src-address-list=BOGON
	
add action=drop chain=forward comment="Drop invalid outgoing" \
    dst-address-list=FALSE_INTERNAL log=yes log-prefix=\
    "rule_02: drop from_false_internal" out-interface=eth1-WAN
	
add action=accept chain=input comment="Allow establish Remote Access" in-interface=\
    eth1-WAN log=yes log-prefix="rule_03: ipsec sys" port=500,1701,4500 protocol=udp
	
add action=accept chain=input comment="Allow establish Remote Access" in-interface=\
eth1-WAN log=yes log-prefix="rule_04: ipsec sys" protocol=ipsec-esp
	
add action=accept chain=input in-interface=eth1-WAN log=yes \
    comment="Allow Use Remote Accesss" log-prefix="rule_05: ipsec ping" protocol=icmp
	
add action=accept chain=input comment="Router: Allow incoming PING - WAN" \
    in-interface=eth1-WAN limit=50/5s,2:packet log=yes log-prefix=\
    "rule_06: allow ping" protocol=icmp

add action=drop chain=input comment=\
    "Router: Drop any new incoming from WAN " connection-state=new \
    in-interface=eth1-WAN log=yes log-prefix="rule_07 drop new_incoming"
правильно ли я понимаю Вашу рекомендацию:
- правило rule_05 перенести на самый верх (это правило моделирует полезную нагрузку в VPN-канале)
- правило rule_05 модернизировать, указав там ipsec-policy=in,ipsec
???

Но при всем при этом, VPN трафик все равно окажется на интерфейсе eth1-WAN, т.е. там, где ему быть не надо....
С уважением
Аватара пользователя
Sweik
Сообщения: 77
Зарегистрирован: 14 июн 2018, 11:05
Откуда: Оттуда

Re: Remote Access и правила FW. Логический тупик.

Сообщение Sweik »

Проверить смогу после 18:00 по восточно-европейскому времени.
С уважением
Аватара пользователя
Chupaka
Сообщения: 3880
Зарегистрирован: 29 фев 2016, 15:26
Откуда: Минск
Контактная информация:

Re: Remote Access и правила FW. Логический тупик.

Сообщение Chupaka »

Sweik писал(а): 11 июл 2018, 16:34 правильно ли я понимаю Вашу рекомендацию:
- правило rule_05 перенести на самый верх (это правило моделирует полезную нагрузку в VPN-канале)
- правило rule_05 модернизировать, указав там ipsec-policy=in,ipsec
???

Но при всем при этом, VPN трафик все равно окажется на интерфейсе eth1-WAN, т.е. там, где ему быть не надо....
Да, что-то вроде того. В зависимости от поставленных целей :) Если нужна дополнительная обработка с разной логикой - добро пожаловать в кастомные очереди, например:

Код: Выделить всё

/ip firewall filter
add chain=input in-interface=eth1-WAN ipsec-policy=in,ipsec action=jump jump-target=ipsec-input
add chain=ipsec-input protocol=icmp comment="allow icmp from VPN"
add chain=ipsec-input action=drop comment="drop everything else from VPN"
Аватара пользователя
Sweik
Сообщения: 77
Зарегистрирован: 14 июн 2018, 11:05
Откуда: Оттуда

Re: Remote Access и правила FW. Логический тупик.

Сообщение Sweik »

Выполнил следующее:

Код: Выделить всё

- правило rule_05 перенести на самый верх (это правило моделирует полезную нагрузку в VPN-канале)
пинг сразу же пошел. Что, в принципе, логично - правило, запрещающее BOGON, оказалось ниже. Правда, трафик, по прежнему, определялся на интерфейсе eth1-WAN, чего быть не должно

далее, сделал так:

Код: Выделить всё

- правило rule_05 модернизировать, указав там ipsec-policy=in,ipsec 
но не изменилось ничего.
С уважением
Аватара пользователя
Chupaka
Сообщения: 3880
Зарегистрирован: 29 фев 2016, 15:26
Откуда: Минск
Контактная информация:

Re: Remote Access и правила FW. Логический тупик.

Сообщение Chupaka »

Sweik писал(а): 11 июл 2018, 17:30 Правда, трафик, по прежнему, определялся на интерфейсе eth1-WAN, чего быть не должно
Увы, должно. Добро пожаловать в IPSec. Отдельных тоннельных интерфейсов для него (пока?) не реализовали.
Sweik писал(а): 11 июл 2018, 17:30 далее, сделал так:

Код: Выделить всё

- правило rule_05 модернизировать, указав там ipsec-policy=in,ipsec 
но не изменилось ничего.
А что должно было измениться? Пинг не должен был пропасть. Теперь пинг это правило разрешает, а всё остальное (попытки подключиться Telnet, WinBox, etc) должно дропаться BOGON-правилом.
Аватара пользователя
Sweik
Сообщения: 77
Зарегистрирован: 14 июн 2018, 11:05
Откуда: Оттуда

Re: Remote Access и правила FW. Логический тупик.

Сообщение Sweik »

Нужно взять паузу на подумать :)
С уважением
Аватара пользователя
Sweik
Сообщения: 77
Зарегистрирован: 14 июн 2018, 11:05
Откуда: Оттуда

Re: Remote Access и правила FW. Логический тупик.

Сообщение Sweik »

По сути, вопрос можен считаться закрытым.
1) VPN-трафик оказывается видимым на внешнем интерфейсе - это нормально.
2) в настройках FW нет опции, которая применяла бы то или иное правило FW только для VPN-community
3) описанная мною в первом сообщении проблема решается либо перемещением BOGON-правил ниже апликационных правил для Remote Access, либо более тонкой настройкой этих правил (использовать Source Address List / Destination Address List)
3a) Как вариант - подумать за использование VLAN-a, но я пока даже не представляю, удастся ли инициировать Remote Access на интерфейсе eth1-WAN (внешний интерфейс), а потом перенаправлять трафик в VLAN.

Спасибо за помощь!
С уважением
Аватара пользователя
Chupaka
Сообщения: 3880
Зарегистрирован: 29 фев 2016, 15:26
Откуда: Минск
Контактная информация:

Re: Remote Access и правила FW. Логический тупик.

Сообщение Chupaka »

Sweik писал(а): 12 июл 2018, 19:02 1) VPN-трафик оказывается видимым на внешнем интерфейсе - это нормально.
В случае с IPSec - да, оно так работает
Sweik писал(а): 12 июл 2018, 19:02 2) в настройках FW нет опции, которая применяла бы то или иное правило FW только для VPN-community
Не совсем понимаю, что за community имеется в виду, но в целом - я же написал, как отделить vpn от не-vpn: viewtopic.php?p=4435#p4435
Sweik писал(а): 12 июл 2018, 19:02 3a) Как вариант - подумать за использование VLAN-a, но я пока даже не представляю, удастся ли инициировать Remote Access на интерфейсе eth1-WAN (внешний интерфейс), а потом перенаправлять трафик в VLAN.
Опять же, не совсем понятно, что в данном случае понимается под VLAN'ом. VLAN 802.1q - это лишь способ пометить пакеты тегами, отправляя их по сети. Внутри устройства работают немного другие сущности: на втором уровне, например - bridge, на третьем - VRF...
Sweik писал(а): 12 июл 2018, 19:02 Спасибо за помощь!
Всегда пожалуйста =)
Аватара пользователя
Sweik
Сообщения: 77
Зарегистрирован: 14 июн 2018, 11:05
Откуда: Оттуда

Re: Remote Access и правила FW. Логический тупик.

Сообщение Sweik »

VPN-community - это со мной пришло от Checkpoint-a :)
там отдельно описывается некое "сообщество" - тип соединение (сервер-сервер или клиент - сервер), алгоримы шифрования, длина ключа и прочее. Очень похоже на то, что в Микротике расположено в IP --> IPSec --> Policies, похоже, но не то :)
А далее при конфигурации правил можно указать, оно будет общее (т.е. применяется для всех) или срабатывает только для определенного комьюнити.
Это, если вкратце :)

По VLAN-aм сразу признаюсь, что не являюсь сетевиком :) Так, немного сбоку.
Идеология была такая (пока мысли, без обкатки):
- развернуть VLAN-интерфейс. Разместить его на физическом вот тут затык - то ли на внешнем размещать (а можно ли???)), то ли на тех, что смотрят в LAN)
- дать этому VLAN-у тот же пул адресов, что у vpn_range
- после того, как пользватели установят удаленное подключение, перебрасывать их (как???) в этот VLAN
- дальше доступ можно будет спокойно регулировать правилами FW

Но это пока лишь сухая теория. :) В Wiki Mirotik-a ничего похожего не нашел. Возможно, идея утопическая.

С уважением.
С уважением
Аватара пользователя
Chupaka
Сообщения: 3880
Зарегистрирован: 29 фев 2016, 15:26
Откуда: Минск
Контактная информация:

Re: Remote Access и правила FW. Логический тупик.

Сообщение Chupaka »

Да, насчёт "сервер-сервер или клиент-сервер" - это в IPSec Policies, видимо.

Считайте VLAN таким же интерфейсом, как и Ethernet. А VLAN, который не терминируется с другой стороны провода - интерфейсом Ethernet, к которому ничего не подключено. Ничем они вам не помогут :)

Так что проще всего всё же доступ спокойно регулировать правилами FW, как я и написал выше.
Аватара пользователя
Sweik
Сообщения: 77
Зарегистрирован: 14 июн 2018, 11:05
Откуда: Оттуда

Re: Remote Access и правила FW. Логический тупик.

Сообщение Sweik »

А еще нужно иметь в виду, что в тестах использовалась цепочка input.
В реальной среде жеудаленным пользователям (речь идет про бизнес-часть компании) на самом рутере делать нечего. Их надо будет пробросить внутрь локальной сети. Следовательно, цепочка будет forward.
С уважением
Ответить