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

Первоначальная настройка фаервола

Первоначальная настройка фаервола, RouterOS

sls

Guest

21.02.2016 20:01:00

Привет, ребята, я новичок в настройке роутеров Mikrotik и мне нужна помощь с моей первой конфигурацией файрвола. У меня Mikrotik RouterBOARD RB2011UIAS-2HND-IN, он стоит за Fritzbox 7490 (для VDSL), который настроен как «Exposed Host», чтобы обойти NAT и файрвол Fritzbox.

На Mikrotik я создал LAN (192.168.0.0/24). Вот что я настроил, опираясь на руководство Mikrotik:

/ip firewall filter
add chain=input connection-state=established
add chain=input connection-state=related
add chain=input in-interface=br-lan
add action=log chain=input
add action=drop chain=input
add chain=forward connection-state=established
add chain=forward connection-state=related
add chain=forward dst-address=!192.168.0.0/24 dst-port=80,443 in-interface=br-lan protocol=tcp
add chain=forward dst-address=!192.168.0.0/24 in-interface=br-lan protocol=icmp
add action=drop chain=forward

Короче, я хочу принимать только уже установленные, связанные и локальные подключения с интерфейса br-lan, который у меня - мостовой интерфейс. Нужно ли мне что-то еще учесть? Я понимаю, что невалидные пакеты должны отбрасываться, так как для них нет правил разрешения.

По цепочке forward хочу то же самое — сначала сбрасывать всё, кроме установленных, связанных и конкретных правил вроде «просмотр веб-страниц или пинг». Это мои первые шаги, так что не судите строго ;D

Думал, что будет полезно показать базовую конфигурацию, чтобы точнее разобраться. Большое спасибо заранее!

С уважением, sls

sls

Guest

09.03.2016 19:52:00

Ладно, я не уверен, что если нет ответа, значит, что вся эта конфигурация в порядке. Просто пробую кое-что, почитав кучу тем туда-сюда.

/ip firewall filter
add action=drop chain=input connection-state=invalid
add chain=input connection-state=established
add chain=input connection-state=related
add chain=input in-interface=lan src-address=192.168.10.0/24
add action=log chain=input
add action=drop chain=input

add action=drop chain=forward connection-state=invalid
add chain=forward connection-state=established
add chain=forward connection-state=related
add chain=forward in-interface=lan protocol=tcp src-address=192.168.10.0/24
add action=log chain=forward
add action=drop chain=forward

Это будет «хорошая» настройка? Или лучше подумать об удалении правила «drop» и «tcp forward», ведь нежелательный трафик всё равно отфильтрует правило «drop invalid packets»?

Sob

Guest

09.03.2016 20:32:00

Похоже, неплохое начало. Оставь правило с универсальным сбросом в конце, потому что сбрасывать некорректные пакеты в начале тебя не защитит. С точки зрения маршрутизатора, несанкционированные входящие подключения из интернета — это не проблема, они просто новые, а не некорректные. Несколько советов: established и related можно объединить в одно правило, так как именно эти соединения будут встречаться чаще всего, поэтому хорошая идея — сделать это первым правилом. Скорее всего, тебе не нужно специально ограничивать принятые входящие/форвардные подключения для 192.168.10.0/24, обычно достаточно указать входящий интерфейс, если ты хочешь, чтобы твои пользователи могли полноценно пользоваться интернетом. Не стоит ограничивать их только tcp.

sls

Guest

17.03.2016 20:10:00

Привет, большое спасибо! Чтобы мои пользователи могли свободно серфить в интернете, я бы настроил правила для tcp и udp вот так: add chain=forward comment="Browse" in-interface=lan protocol=tcp add chain=forward comment="Browse" in-interface=lan protocol=udp Или просто сделал бы прыжок в правило, где можно задать кастомный набор tcp-правил, если это рекомендуют больше, а в нем уже блокировать некоторые tcp-порты. Кстати, я думал, что достаточно просто сбрасывать невалидные пакеты и разрешать только связанные и установленные соединения, чтобы не задавать отдельные tcp/udp правила… Пока спасибо! С уважением, sls

Sob

Guest

17.03.2016 23:19:00

Обычно ничего особенного не требуется. Моя исходная конфигурация выглядит так: для forward разрешаю established и related, отбрасываю invalid, разрешаю всё с LAN (если только нет причины что-то блокировать; если такая есть, то все исходящие подключения совпадают только один раз и пересылаются в отдельную цепочку для детального фильтра — именно так, как ты писал), разрешаю проброшенные порты (connection-nat-state=dstnat), остальное отклоняю. Для input разрешаю established и related, отбрасываю invalid, разрешаю всё с LAN (если только нет причины запретить доступ некоторым хостам к роутеру), разрешаю выбранные внешние адреса (для удаленного администрирования, если нужно; использую src-address-list), разрешаю icmp (ненавижу, когда некоторые думают, что блокировка icmp, то есть ping, сделает роутер «невидимым» и более защищённым — это не так, и это раздражает при отладке проблем), остальное отклоняю (не сбрасываю, если клиенту не разрешён доступ к порту, просто говорю об этом прямо и не даю клиенту бессмысленно пытаться). Если нужен port forwarding, особенно если много портов для разных внутренних хостов, адрес совпадает только один раз и пересылается в отдельную цепочку (это оценишь, когда публичный адрес изменится — достаточно будет сменить его в одном месте, а не в каждом правиле port forwarding). Добавляю универсальное правило hairpin NAT для всех портов, чтобы любые публичные сервисы, которые фактически работают на внутренних хостах, просто работали. Это не «единственная и лучшая конфигурация», такого вообще не существует, у разных людей — разные потребности. Но я бы сказал, что это простая и разумная настройка.

nxs02 Guest	#6 0 17.03.2016 23:53:00 По моему мнению, не нужно убирать правило отбрасывания недопустимых пакетов, потому что без этого правила в итоге недопустимые пакеты всё равно будут отброшены правилом drop/reject для остальных.

Sob Guest	#7 0 18.03.2016 00:21:00 Вам этого делать не обязательно. Но тогда роутер будет пытаться сопоставить их со всеми последующими правилами. А вы же уже знаете, что они неверные, так почему бы не избавиться от них сразу?

jarda Guest	#8 0 18.03.2016 17:09:00 Разве оно действительно попытается совпасть, если его сбросить в конце?

Sob

Guest

18.03.2016 17:33:00

Если у вас, например:
#1: accept established & related
#2: accept from interface ether1
#3: accept to 192.168.1.100
#4: drop

Тогда некорректные пакеты с ether1 будут приняты правилом #2, некорректные пакеты, направленные на 192.168.1.100 — правилом #3, а только остальные некорректные пакеты дойдут до правила #4 и будут отброшены. Такого бы не произошло, если бы в правилах #2 и #3 стояло connection-state=new, но именно это мне нравится в том, чтобы отбрасывать invalid в начале: как только от них избавишься (и примешь established & related), всё остальное — новое, и нет нужды добавлять проверку состояния в каждое правило.

jarda

Guest

#10

18.03.2016 20:18:00

Да, может быть. Я тоже обычно отбрасываю недействительные пакеты в начале, но, глядя на статистику, отбрасываемые недействительные пакеты составляют примерно 0,05% от всех окончательно отброшенных пакетов. Стоит ли вводить дополнительное правило, которое придётся проверять для всех пакетов, но 99,99% из них всё равно пройдут через него? С этой точки зрения мне это кажется неэффективным, так как это зря нагружает фаервол.

Sob

Guest

#11

18.03.2016 21:29:00

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

sls

Guest

#12

20.03.2016 19:03:00

Итак, цепочка Forward похожа на цепочку input, она установлена и связана, и разрешает всё с моего LAN (то есть мне не приходится указывать конкретные протоколы и порты, верно?). Но я не понимаю правило connection-nat-state=dstnat. Я не уверен, что оно делает. Я читал примеры для цепочки input, чтобы настроить OpenVPN сервер, например так: /ip firewall filter add chain=input dst-port=1194 protocol=tcp. А можно ли так же использовать tcp порт 443 (он больше подходит для прокси), если на LAN стоят и веб-сервер, и OpenVPN сервер, которые слушают на порту 443? Я тут много полезного подсмотрел и стараюсь разобраться, как работает RouterOS, так что большое спасибо! С уважением, sls

Sob

Guest

#13

20.03.2016 19:50:00

Верно. Все условия — это дополнительные ограничения. Если не добавлять никаких, подойдут все пакеты. Если указать входящий интерфейс, подойдут все пакеты с него. Это актуально, когда вы перенаправляете порты на внутренние хосты. Например, у вашего роутера есть публичный адрес, но вы хотите запустить сайт на внутреннем сервере. Тогда вы делаете так:
/ip firewall nat
add action=dst-nat chain=dstnat dst-address=<public ip> dst-port=80 protocol=tcp \
to-addresses=192.168.0.10 — и все пакеты на порт :80 будут перенаправлены на 192.168.0.10:80. Но их заблокируют в цепочке forward, потому что разрешены только соединения, идущие из локальной сети. Правило Accept с connection-nat-state=dstnat позволяет просто принимать все перенаправленные соединения. Иначе пришлось бы создавать отдельные правила для каждого внутреннего хоста и порта.

Если у вас только один публичный адрес, нельзя одновременно использовать порт 443 и для OpenVPN, и для веб-сервера. Стандартный OpenVPN поддерживает такую опцию, но в RouterOS её нет. Приходится выбирать. Либо ставить стандартный OpenVPN-сервер на внутреннем хосте, перенаправлять порт 443 на него и пусть он уже пересылает HTTPS-трафик на веб-сервер.

lapsio

Guest

#14

21.03.2016 14:47:00

Раньше я тоже никогда сам не настраивал фаервол, но недавно начал читать про fasttrack и понял, что сначала нужно разобраться с самим фаерволом. Вот моя конфигурация RB2011:
0 chain=input action=accept connection-state=established,related
1 chain=input action=accept protocol=icmp
2 chain=input action=drop in-interface=ether1-gateway
3 chain=input action=accept protocol=udp port=53 <-- это же DNS, правильно?
4 chain=input action=accept src-address=192.168.1.0/24
5 chain=input action=reject reject-with=icmp-port-unreachable
6 chain=forward action=accept connection-state=established,related
7 chain=forward action=drop connection-state=invalid
8 chain=forward action=drop dst-address=192.168.0.0/24
9 chain=forward action=drop src-address=192.168.3.0/24 dst-address=192.168.0.0/16

Эта конфигурация была создана моим другом, который как раз и познакомил меня с оборудованием MT на базе заводских настроек. В начале фаервол казался мне чем-то «совсем непонятным», чтобы разбираться самому, так как я тогда только учил основы сетей в школе на этом роутере. Но теперь я считаю, что пора двигаться вперёд.

У меня есть несколько вопросов по этому поводу:
- У меня нет такого правила, как: add chain=forward in-interface=lan protocol=tcp src-address=192.168.10.0/24
- Также нет этого правила, несмотря на использование NAT.
- И нет правила drop all в самом конце.

В доме у меня много сетей:
- 192.168.4.0 — частная Wi-Fi
- 192.168.3.0 — публичный Wi-Fi
- 192.168.2.0 — DMZ для веб-сервера
- 192.168.1.0 — частная проводная сеть с NAS
- 192.168.0.0 — сеть между неисправным, уязвимым роутером провайдера и моим RB2011

Поэтому я не очень хочу прописывать каждую src-address вручную… С другой стороны, я не знаю, что происходит «ниже» правил фаервола, если в конце нет правила drop all, и не понимаю, что с этим делать.

Плохо ли, что нет drop all в конце?

Меня больше всего интересует правило NAT. В чём разница между наличием этого правила и drop all в конце и отсутствием drop all? Влияет ли это как-то на пировую сеть (p2p), Tor или i2p-роутеры?

Если у меня сервер настроен как DMZ (например, dst-nat перенаправляет весь трафик, не пойманный более ранними правилами NAT), реально ли, что что-то может не попасть под это правило?

P.S. По аналогии с твоими постами я изменил конфиг так:
0 ;;; input
chain=input action=accept connection-state=established,related
1 chain=input action=drop connection-state=invalid
2 chain=input action=accept protocol=icmp
3 chain=input action=drop in-interface=ether1-gateway
4 chain=input action=accept protocol=udp port=53
5 chain=input action=accept src-address=192.168.1.0/24
6 chain=input action=reject reject-with=icmp-port-unreachable

7 ;;; forward
chain=forward action=accept connection-state=established,related
8 chain=forward action=drop connection-state=invalid
9 chain=forward action=drop dst-address=192.168.0.0/24
10 chain=forward action=drop src-address=192.168.3.0/24 dst-address=192.168.0.0/16
11 chain=forward action=accept src-address=192.168.0.0/16
12 chain=forward action=accept connection-nat-state=dstnat in-interface=ether1-gateway
13 chain=forward action=drop

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

Sob

Guest

#15

21.03.2016 18:13:00

Не обязательно добавлять все возможные комбинации. Если какие-то подсети могут идти куда угодно (.1, .2 и .4), достаточно трёх правил с указанием только src-address. Потом четвёртое правило с src-address=192.168.3.0/24 и dst-address=!192.168.0.0/16 — и всё готово. Если ни одно правило не подходит под пакет, действие по умолчанию — принять.

В твоей исходной конфигурации подсеть .3 не имела доступа к другим 192.168.x.x, что логично для публичного Wi-Fi. А вот доступ к подсети .0 был запрещён для всех, что мне не понятно. Зачем никому запрещать доступ к «проблемному, уязвимому роутеру провайдера», но при этом разрешать этому роутеру доступ ко всем внутренним сетям? Логично было бы наоборот, то есть src-address=192.168.0.0/24.

Всё остальное было разрешено. Безусловный drop в конце — подход с белым списком: либо ты что-то явно разрешаешь, либо нет. Можно работать и по чёрному списку — специально блокировать всё, что не хочешь разрешать, а остальное принимать по умолчанию. Мне нравится белый список больше, но нельзя сказать, что один способ всегда лучше другого.

Правило accept с connection-nat-state=dstnat пропускает только перенаправленные порты. Отсутствие drop в конце позволяет принимать всё, что не блокируется предыдущими правилами. Если у тебя какой-то порт проброшен на p2p-программу, он будет принят этим правилом. Хотя разницы ты и не заметишь, потому что раньше такие пакеты принимались по умолчанию.

Да, если какой-то злодей умудрится доставить пакет с исходным адресом, например, 192.168.1.10, и назначением 192.168.2.10 на твой WAN-интерфейс, то твоя исходная конфигурация его примет. Но на практике это крайне маловероятно.

Если ты обращаешься к случайным портам на роутере из интернета, это обычно проходит по входящей цепочке (input chain). Если же ты перенаправляешь всё в DMZ, то это принимается правилом номер 12.

lapsio

Guest

#16

21.03.2016 20:14:00

Спасибо за объяснение. Кажется, я забыл упомянуть — .0.0/24 подключён к ether1-gateway. Значит, он изолирован правилами ether1, да? То есть у него такой же уровень прав, как у трафика, приходящего с WAN, правильно? Тогда особой нужды блокировать такой трафик нет. Или я что-то забыл? Этот неисправный роутер на самом деле мой шлюз в WAN…

По поводу правил dst-address — дело в том, что этот роутер Thomson TWG870 позволяет скачать резервную копию с открытым логином и паролем администратора, если зайти на http://192.168.0.1/Backup.bin… Кроме того, если зайти по адресу http://192.168.0.1/xxxxxxx… (длинный URL длиной более 512 символов), роутер зависает и сбрасывается к заводским настройкам с открытым Wi-Fi и доступом к админке через Wi-Fi…

Технически можно вставить оба упомянутых адреса, например, в качестве src изображения на сайт, и я смог бы открыть их, например, с компьютера в сети .1.0/24 — и это было бы очень плохо, на мой взгляд…

Сейчас роутер настроен просто отправлять весь трафик в DMZ на MT. На самом деле у меня уже был опыт, когда роутер сбрасывался к заводским настройкам без моего ведома, и у меня пропадал интернет. Поэтому я решил, что лучше заблокировать любой входящий трафик.

К сожалению, мой провайдер никак не хочет менять этот хлам или даже разрешить использовать простой преобразователь coax->RJ45. При этом менять провайдера я не хочу, ведь этот даёт мне бесплатный статический публичный IP даже при самом дешёвом тарифе. К тому же он очень надёжный — за всю жизнь у меня никогда не было сбоев в интернете. В общем, ситуация довольно неудачная…

Sob

Guest

#17

21.03.2016 23:00:00

У тебя отличный роутер. С таким знанием твое правило действительно имеет смысл. Но внутренние сети от этого всё равно не защищены. Нет. У тебя нет правил для «ether1». Ну да, есть action=drop, in-interface=ether1-gateway, но это только для входящего трафика. Так что если злоумышленники взломают твой роутер Thompson, они не смогут добраться до твоего MikroTik. Но они смогут получить доступ ко всему, что внутри любой внутренней сети, потому что ничто не блокирует трафик с 192.168.0.1 на 192.168.x.x в цепочке forward. Правило drop #13 в конце вроде бы должно это сделать, но оно туда просто не доходит, потому что такие пакеты принимаются правилом #11. Даже правило #9 тебя не спасет, потому что ответные пакеты для соединения, инициированного с 192.168.0.1, уже будут установлены и допускаются правилом #7.

sls

Guest

#18

25.03.2016 19:07:00

Ладно, я попытался подключиться к OpenVPN-серверу на Mikrotik, и вроде бы всё нормально, но есть одна проблема. Во-первых, у моего RoadWarrior при установке VPN-соединения остаётся тот же публичный IP-адрес. Во-вторых, я не могу зайти на Mikrotik через VPN без этого правила:
/ip firewall filter
add action=accept chain=input comment="OpenVPN" disabled=no dst-port=1194 protocol=tcp

Что я хочу сделать — это чтобы мой RoadWarrior был в одной из локальных сетей, чтобы иметь доступ к внутренним шарингам и серфить «через» внутреннюю LAN. Поэтому я настроил кучу маленьких /30 пулов IP, как указано в документации https://openvpn.net/index.php/open-source/documentation/howto.html#policy,%20OpenVPN

В OpenVPN GUI (на стороне клиента) я маршрутизирую 192.168.17.0 255.255.255.0 (целевая подсеть на Mikrotik), но, ну да, это не работает.

С уважением, sls

Sob

Guest

#19

27.03.2016 00:45:00

Если OpenVPN-сервер работает на роутере, то да, очевидно, нужно добавить правило разрешения для его порта, если другие правила по умолчанию блокируют все соединения с WAN. Чтобы получить доступ к вашей внутренней локальной сети, вы можете сделать следующее:

- Настроить всю LAN как мост и добавить клиент в качестве порта моста. Тогда клиент станет прямой частью LAN.
- Держать клиента полностью отдельным, без моста и в другой подсети. Это удобно, если вы хотите просто фильтровать трафик между LAN и VPN-клиентом, потому что это стандартная маршрутизация между интерфейсами. Но тут могут возникнуть проблемы с настройками фаервола на хостах, например, Windows позволяет доступ к общим ресурсам только с той же подсети.
- Разделить интерфейсы, но использовать меньшую часть текущей подсети (например, /30) для клиента и включить Proxy ARP на LAN-интерфейсе. Тогда адрес клиента будет выглядеть как часть LAN (хотя широковещательные пакеты не будут работать), и проблем с фаерволами не возникнет.

Если вы хотите «серфить через LAN», то есть сделать так, чтобы казалось, что интернет используется с адреса роутера, VPN-клиент должен иметь маршрут по умолчанию через VPN. Тогда нужен форвард-правило, разрешающее доступ с VPN-клиента в WAN, и какой-то srcnat или masquerade для этих соединений. И это должно работать нормально.

Я не могу дать конкретные настройки OpenVPN на автомате, потому что не часто его настраиваю. Для этого сначала нужно сделать тестовую сеть, а сейчас нет желания этим заниматься.

sls Guest	#20 0 17.04.2016 09:10:00 Привет, Sob! Спасибо за твои советы, они очень помогли! Итак, у меня есть 3 порта на мосту: 2 порта разделены и настроены с разными подсетями, а также есть отдельная подсеть для OpenVPN. Всё работает отлично, но остался один вопрос. У меня есть пользовательские tcp и udp цепочки, куда попадают все пакеты, приходящие на роутер или проходящие через него, через правило jump. Я не уверен, будет ли разумнее создать правило «connection-state=new» после пользовательских tcp цепочек, чтобы использовать их только для блокировки определённых портов. Ах да, чуть не забыл: слышал, что весь трафик между интерфейсами с разными подсетями обычно маршрутизируется, верно? Я как раз пытаюсь это предотвратить, потому что есть локальные ресурсы, к которым не должны иметь доступ все подсети. Возможно, я создам новые правила межсетевого экрана, чтобы это ограничить. Спасибо пока что — Mikrotik просто класс! С уважением, sls

Читают тему

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