Комментарии 67
К сожалению в RouterOS нельзя создать правило
блокировать все TCP соединения на порт 80 по адресу example.com
Да ладно. add action=drop chain=forward content=«Host: habrahabr.ru»
На 500 друг за другом идущих таких правилах, я думаю микротик скажет: «фу таким быть» и скорость будет страдать, не? :)
Подтверждаю. Будет страдать, а если ещё какой-нибудь ipsec параллельно работает — вообще загнуться может. Да и самому в них довольно сложно ориентироваться будет.
В данном случае немного неправильно применение (неплохого, кстати) инструмента.
Если вам нужно блокировать 10+ доменных имён — впору задуматься о настройке прозрачного squid.
Если вам нужно блокировать 10+ доменных имён — впору задуматься о настройке прозрачного squid.
Как вы сквидом будете ssl трафик обрабатывать? А если на 443 порту не https? А если на 80 — не http?
Подразумевается работа http(s) прокси сервера. Работа с https через него ведётся путём запроса метода CONNECT hostname у прокси-сервера. На что сервер отвечает denied.
Но это в случае если вы обеспечиваете корпоративный выход в инет на предприятии, где запрет социалочек регламентирован. Если же Вы пытаетесь «втихую» блокировать сайты в маленькой конторке, то да, костыли — вариант.
Но это в случае если вы обеспечиваете корпоративный выход в инет на предприятии, где запрет социалочек регламентирован. Если же Вы пытаетесь «втихую» блокировать сайты в маленькой конторке, то да, костыли — вариант.
Подразумевается работа http(s) прокси сервера. Работа с https через него ведётся путём запроса метода CONNECT hostname у прокси-сервера.
Это же будет работать только если прокси в браузере явно прописать, Вы же сначала прозрачный прокси предлагали.
Но это в случае если вы обеспечиваете корпоративный выход в инет на предприятии, где запрет социалочек регламентирован. Если же Вы пытаетесь «втихую» блокировать сайты в маленькой конторке, то да, костыли — вариант.
А как же BYOD? На всех смартфонах-ноутбуках будете настройки бегать прописывать?
НЛО прилетело и опубликовало эту надпись здесь
в Mikrotik есть свой web-прокси… https он конечно не может, но в общем весьма пригодный.
Точнее:
/ip firewall filter
add action=drop chain=forward content=«Host: habrahabr.ru» dst-port=80 protocol=tcp
/ip firewall filter
add action=drop chain=forward content=«Host: habrahabr.ru» dst-port=80 protocol=tcp
Это если у вас http. Этого-то в условии задачи не было сказано :)
В условии был 80 порт, это и есть http :)
Наверное, я пример не удачный привёл. С https ваше правило не сработает.
Вы зря так, 80 порт — это не только http.
Минимум вы путаете уровни модели OSI: посмотрите, на какой уровне появляются в ней «порты» (80/tcp, для точности), а на каком — HTTP как протокол.
Во-вторых, заголовок «Host: ...» (такая строчка, конечно, не только в http может пролететь) впервые появился только в HTTP/1.1, так что блочить ваше правило даже из http-серверов будет не все.
В-третьих, если какая-то добрая душа повесит на 80 порт Скайп, SMTP либо что-то подобное (что, кстати, подпадает под условие задачи), то ваш ответ, опять-таки, машинку напрягать будет (текстовый поиск все же), а пользы от него — нуль.
:)
Минимум вы путаете уровни модели OSI: посмотрите, на какой уровне появляются в ней «порты» (80/tcp, для точности), а на каком — HTTP как протокол.
Во-вторых, заголовок «Host: ...» (такая строчка, конечно, не только в http может пролететь) впервые появился только в HTTP/1.1, так что блочить ваше правило даже из http-серверов будет не все.
В-третьих, если какая-то добрая душа повесит на 80 порт Скайп, SMTP либо что-то подобное (что, кстати, подпадает под условие задачи), то ваш ответ, опять-таки, машинку напрягать будет (текстовый поиск все же), а пользы от него — нуль.
:)
Понятно, что повесить на 80 порт можно что угодно, я говорил о реальном мире, в котором 99% сайтов подойдут под это правило. Для остальных пригодится этот топик.
Так вы условие прочтите: не блочить http-трафик, а трафик на 80/tcp. Скажем, блочить трафик вируса, который на 80 порт некого хоста (по имени) своим протоколом (не http!) гонит украденные у юзера пароли.
Ваш вариант хорош как «затычка» на скорую руку, но… знаете, в сети с такими защитами, как предложенное вами правило я бы с удовольствием пользовался инетом, зная, что другие юзеры (не включившие свой мозг) той же сети не имеют доступа к вебу. При этом о моем доступе к вебу админ с вашим подходом был бы не в курсе, и был бы счастлив, что у него «все схвачено» ))
Вас плюсуют — так что, полагаю, вы не один такой «внимательный» к условиям задач. Ничего личного, но, как в том анекдоте — «побольше бы таких, как вы, у меня всегда работа будет».
Ваш вариант хорош как «затычка» на скорую руку, но… знаете, в сети с такими защитами, как предложенное вами правило я бы с удовольствием пользовался инетом, зная, что другие юзеры (не включившие свой мозг) той же сети не имеют доступа к вебу. При этом о моем доступе к вебу админ с вашим подходом был бы не в курсе, и был бы счастлив, что у него «все схвачено» ))
Вас плюсуют — так что, полагаю, вы не один такой «внимательный» к условиям задач. Ничего личного, но, как в том анекдоте — «побольше бы таких, как вы, у меня всегда работа будет».
У меня к Вам вопрос про «в-третьих» поделитесь опытом, как вы отловите трафик не http на 80 порту? ;) Очень мне интересно т.к. насущно.
как вариант — L7-фильтры ( goo.gl/ZFAEyy ), но тут опять встаёт два вопроса:
— производительность, т.к. анализ принадлежности трафика основан на анализе содержимого пакетов
— качество точности определения типа трафика
— производительность, т.к. анализ принадлежности трафика основан на анализе содержимого пакетов
— качество точности определения типа трафика
Как дешевый вариант — заверните трафик 80 порта в прозрачный прокси. Что через него пройдет — то уже http :) Остальное просто не пройдет.
Надо однако понимать цель определения http-трафика: вспомните, OpenVPN отлично проходит через прокси-сервера, создавая http-трафик, и заворачивая уже любые данные внутри создаваемого туннеля. Так что (грубо говоря) цель «не дать в офисе никакого трафика кроме http» при помощи прокси/фильтрации по признакам http-трафика не совсем чтобы прокатит, надо отдельно ловить признаки туннелирования внутри http чего-то другого.
А если задача — настроить QoS, дав http-трафику определенный приоретет/ширину канала, то какие проблемы, проще метить пакеты, хотя бы более-менее похожие на http. Особенно если сеть — доверенная, и вы не ждете «подлянок» от пользователей, а просто хотите пропустить VoIP вперед http.
Ну а если прокси не сильно нравится, и хочется сделать QoS — метьте (mangle) пакеты (а затем — соединения) по формальным признакам (80 порт tcp, те или иные строки в заголовке) — этого хватит.
Надо однако понимать цель определения http-трафика: вспомните, OpenVPN отлично проходит через прокси-сервера, создавая http-трафик, и заворачивая уже любые данные внутри создаваемого туннеля. Так что (грубо говоря) цель «не дать в офисе никакого трафика кроме http» при помощи прокси/фильтрации по признакам http-трафика не совсем чтобы прокатит, надо отдельно ловить признаки туннелирования внутри http чего-то другого.
А если задача — настроить QoS, дав http-трафику определенный приоретет/ширину канала, то какие проблемы, проще метить пакеты, хотя бы более-менее похожие на http. Особенно если сеть — доверенная, и вы не ждете «подлянок» от пользователей, а просто хотите пропустить VoIP вперед http.
Ну а если прокси не сильно нравится, и хочется сделать QoS — метьте (mangle) пакеты (а затем — соединения) по формальным признакам (80 порт tcp, те или иные строки в заголовке) — этого хватит.
Цель скорее «не дать в офисе никакого трафика кроме http» и его варианты. Вариантов масса, как пример торрент который свободно пролазит по 80 порту, внешний DNS. ASA оно конечно хорошо, но для фирмы дорого :(
А чем вас ASA, если по-честному, спасет? :) Она, как и много других классификаторов, что-то может, что-то нет.
С http вам поможет проки. Только с методом connect разбирайтесь глубже, или вообще его запретите (ой!). Но что бы вы не сделали, https перекрыть нельзя, по нему сейчас полинтернета работает. А разрешите его — любой самый функциональный DPI (не то что решение на Mikrotik) летит в никуда, он просто не будет знать, что внутри.
Так что тут остается разбираться в http-трафике, а https пускать только на хосты те, где есть https и нет OpenVPN, например. Или уже переносить борьбу с https на ПК (точнее, в браузеры) юзеров.
Я бы начал с DNS. SkyDNS тот же вам в помощь! )
С http вам поможет проки. Только с методом connect разбирайтесь глубже, или вообще его запретите (ой!). Но что бы вы не сделали, https перекрыть нельзя, по нему сейчас полинтернета работает. А разрешите его — любой самый функциональный DPI (не то что решение на Mikrotik) летит в никуда, он просто не будет знать, что внутри.
Так что тут остается разбираться в http-трафике, а https пускать только на хосты те, где есть https и нет OpenVPN, например. Или уже переносить борьбу с https на ПК (точнее, в браузеры) юзеров.
Я бы начал с DNS. SkyDNS тот же вам в помощь! )
Да, вы правы, запретить это конечно не выход совсем :)
Спасет — ну вот инспекцией и спасет, в данном вопросе. Разбирая, как минимум, какой еще трафик кроме необходимого пойдет по порту.
Про http, я понял вас. Спасибо за помощь.
Спасет — ну вот инспекцией и спасет, в данном вопросе. Разбирая, как минимум, какой еще трафик кроме необходимого пойдет по порту.
Про http, я понял вас. Спасибо за помощь.
> Спасет — ну вот инспекцией и спасет, в данном вопросе. Разбирая, как минимум, какой еще трафик кроме необходимого пойдет по порту.
Вы меньше верьте в чудеса и в идеальной инспекции «из коробки». Я как-то поставил инспекцию ESMTP трафика — а сервер у меня почему-то перестал часть писем получать. Расследование показало, что что-то циске в иных SMTP-диалогах не нравилось…
Повторюсь, http вы и на микротиковском прокси обработаете (IP -> Webproxy), а вот с https будут вопросы, да. Не из-за Микротика, а из-за протокола.
Вы меньше верьте в чудеса и в идеальной инспекции «из коробки». Я как-то поставил инспекцию ESMTP трафика — а сервер у меня почему-то перестал часть писем получать. Расследование показало, что что-то циске в иных SMTP-диалогах не нравилось…
Повторюсь, http вы и на микротиковском прокси обработаете (IP -> Webproxy), а вот с https будут вопросы, да. Не из-за Микротика, а из-за протокола.
На грани оффтопа, но, думаю, кому-то кроме меня пригодится.
Я сделал на микротике в офисе гостевую Wi-Fi сеть для интернета без доступа к локалке. Доступ ограничил так: на бридже в цепочке forward создал правило дропать все, что идёт с wlan2 НЕ на ether1-gateway. Это надёжно с точки зрения безопасности? Вообще, есть какие-нибудь причины так не делать?
Я сделал на микротике в офисе гостевую Wi-Fi сеть для интернета без доступа к локалке. Доступ ограничил так: на бридже в цепочке forward создал правило дропать все, что идёт с wlan2 НЕ на ether1-gateway. Это надёжно с точки зрения безопасности? Вообще, есть какие-нибудь причины так не делать?
Единственная проблема на первый взгляд, это что не будут работать сайты, которые хостятся у вас в офисе, даже по dns имени, которое смотрит на внешний ип офиса.
Что бы это обойти надо прикрутить еще тройку костылей…
Что бы это обойти надо прикрутить еще тройку костылей…
можно загнать в address-list (например, local-servers) адреса серверов, на которые нужно попадать с wi-fi и положить правило, пропускающее пакеты с dst-address-list равным local-servers, до правила с DROP'ом
Я просто оставлю это здесь.
Вы в курсе, что тогда сервера будут видеть один и тот же адрес от всех клиентов — адрес шлюза? Думаю, что не нужно объяснять чем это плохо с точки зрения безопасность (выявления вредителя, находящегося в той же подсети).
Правильнее всего вынести сервара в dmz-зону (отдельную подсеть), тогда и лишний раз nat'ить не нужно, и фаерволить проще.
Правильнее всего вынести сервара в dmz-зону (отдельную подсеть), тогда и лишний раз nat'ить не нужно, и фаерволить проще.
Думаю, что «выявления вредителя, находящегося в той же подсети» это не самая правильная формулировка. По сути гостевая wi-fi сеть в офисе, которая будет ходить к серверам по внешнему адресу, ничем не отличается от любого другого публичного wi-fi или провайдера с серыми адресами. Сервис торчит наружу, к нему приходят снаружи…
Не совсем понимаю чем это небезопасно?
Не совсем понимаю чем это небезопасно?
ок. Давайте представим себе такую ситуацию…
В офис приезжает важный по какой-то причине человек, который подстёгивается в вафле, и начинает работать с серверами из Вашей локалки и ходить наружу (почта, скайпик, vpn'ы, ...) чтобы быть и здесь, и там.
В это же время какой-то заражённый клиент или просто нехороший человек начинает брутфорсить, допустим, web-ресурс одного из серверов.
По правилам хорошего тона на этом сервере сработает fail2ban, но заблокриует не IP брутфорсера, а IP шлюза… В итоге — все за wifi «отрезаны» от web-ресурса, а важный гость негодует и жалуется Вашему начальнику.
Не могу говорить за Вас, но в моём случае могла бы иметь место попоболь…
Ну, а если никаких мер не принимать (не бороться с брутфорсером) — кто знает какие методы он пользует?.. Может ведь и проломить «стену»…
В общем, я ни кого не заставляю принимать мою точку зрения, но и не мной было придумано понятие DMZ.
Как говорится, каждый сам выбирает методы защиты, а потОм — лекарства, для залечивания ран :)
В офис приезжает важный по какой-то причине человек, который подстёгивается в вафле, и начинает работать с серверами из Вашей локалки и ходить наружу (почта, скайпик, vpn'ы, ...) чтобы быть и здесь, и там.
В это же время какой-то заражённый клиент или просто нехороший человек начинает брутфорсить, допустим, web-ресурс одного из серверов.
По правилам хорошего тона на этом сервере сработает fail2ban, но заблокриует не IP брутфорсера, а IP шлюза… В итоге — все за wifi «отрезаны» от web-ресурса, а важный гость негодует и жалуется Вашему начальнику.
Не могу говорить за Вас, но в моём случае могла бы иметь место попоболь…
Ну, а если никаких мер не принимать (не бороться с брутфорсером) — кто знает какие методы он пользует?.. Может ведь и проломить «стену»…
В общем, я ни кого не заставляю принимать мою точку зрения, но и не мной было придумано понятие DMZ.
Как говорится, каждый сам выбирает методы защиты, а потОм — лекарства, для залечивания ран :)
А как планируется быть для случаев когда за одним именем сидит AS(несколько адресов)? Сравните вывод nslookup в Windows и resolve в микротике для того же vk.com
Вы статью то читали? Вывод команды resolve тут вообще не используется.
:foreach addr in $DNSList do={
:do {:resolve server=8.8.8.8 $addr} on-error={:log debug («failed to resolve $addr»)}
а тут разве не резолв?
:do {:resolve server=8.8.8.8 $addr} on-error={:log debug («failed to resolve $addr»)}
а тут разве не резолв?
Он нужен, чтобы сделать запрос к днс-серверу. В кэш попадут все записи, относящиеся к этому домену.
В какой момент в ДНС-кеш микротика попадут ВСЕ записи нужного домена?
Просто проверил. От пинга на тике и нслукапа на виндовом клиенте в ДНСе микротика записи для всех адресов даного домена не появились.
Просто проверил. От пинга на тике и нслукапа на виндовом клиенте в ДНСе микротика записи для всех адресов даного домена не появились.
В момент резолва на микротике
[admin@MikroTik GW] > /ip dns cache flush
[admin@MikroTik GW] > /ip dns cache all print
Flags: S - static, N - negative
# NAME TYPE DATA TTL
[admin@MikroTik GW] > :resolve vk.com
[admin@MikroTik GW] > /ip dns cache all print
Flags: S - static, N - negative
# NAME TYPE DATA TTL
0 vk.com A 87.240.131.99 6m50s
1 vk.com A 87.240.143.241 6m50s
2 vk.com A 87.240.131.117 6m50s
C:\Users\Александр>nslookup vk.com 8.8.8.8
╤хЁтхЁ: google-public-dns-a.google.com
Address: 8.8.8.8
Не заслуживающий доверия ответ:
╚ь : vk.com
Addresses: 2a00:bdc0:3:103:1:0:403:907
2a00:bdc0:3:103:1:0:403:908
2a00:bdc0:3:103:1:0:403:909
87.240.131.97
87.240.131.99
87.240.143.241
Коллеги, микротиководы! Можно я, пользуясь случаем, задам пару вопросов:
1. Есть ли альтернативы микротику с 10+ Ethernet-портами? OpenWRT в metarouter-e не в счёт, т.к. фича не для продакшена.
2. Когда вы делаете (скриптом) автобекапы микротика (а ведь вы их делаете, правда?) — вы проверяете их целостность? Как?
1. Есть ли альтернативы микротику с 10+ Ethernet-портами? OpenWRT в metarouter-e не в счёт, т.к. фича не для продакшена.
2. Когда вы делаете (скриптом) автобекапы микротика (а ведь вы их делаете, правда?) — вы проверяете их целостность? Как?
А зачем его автоматически бэкапить? Туда изменения очень редко вносятся. Или вы каждый день сеть переконфигурируете?
А зачем его автоматически бэкапить? Туда изменения очень редко вносятся. Или вы каждый день сеть переконфигурируете?
1. Чем вам микротики не угодили? Если от другого вендора, то Cisco, Juniper какие-нибудь.
2. Бэкап микротика — это хорошо. Но у меня редко вносятся изменения в конфигурацию, а все конфигурации достаточно типовые и однообразные. В случае чего дольше будут искать (покупать/заказывать/везти) микротик на замену, чем я его буду настраивать. А там где требуется всегда можно иметь абсолютно идентичный роутер с такой же конфигурацией на замену.
2. Бэкап микротика — это хорошо. Но у меня редко вносятся изменения в конфигурацию, а все конфигурации достаточно типовые и однообразные. В случае чего дольше будут искать (покупать/заказывать/везти) микротик на замену, чем я его буду настраивать. А там где требуется всегда можно иметь абсолютно идентичный роутер с такой же конфигурацией на замену.
NOC отличный проект, который в том числе позволяет автоматически собирать конфиги и следить за их изменениями. Подробнее было в выпуске LinkMeUp #9 и #10.
У себя делаю это по расписанию на scheduler`е и отправляю на ftp сервер. Позже делаю еще один запрос на CGI скрипт, который создает commit в git`е если были сделаны были изменения.
У себя делаю это по расписанию на scheduler`е и отправляю на ftp сервер. Позже делаю еще один запрос на CGI скрипт, который создает commit в git`е если были сделаны были изменения.
свежий mikrotik чего то не ставится на виртуальную машину (vmware work на esxi не пробовал еще.)… а то проверять бекапы и вообще много всего делать можно было.
:lua — Lua язык в скриптах — это была прекрасная идея версии 4.0 b3, но к сожалению в v4 RC1 удалили поддержку Lua так вот и сидим ждем может появится это счастье…
Вот какой синтаксис был:
Вот какой синтаксис был:
[:lua "require 'customprint'\n print('hello from custom print function')"]
Еще не хватает таких примочек как :break и :continue для циклов (я по крайней мере не нашел их поддержки и реализации), ну и ужасного :goto
Хочу поправить: :local DNSServer «8.8.8.8» тут используется сервер google, соответственно ip серверов (:resolve server=$DNSServer $addr) дает для того участка интернет в котором сервер 8.8.8.8 находится. Если на микротике стоит dns сервер(а) провайдера, то часто ip адреса будут отличаться от выданных сервером 8.8.8.8. Поэтому нужно обязательно указать, чтобы в скрипте указывали тот dns который уже настроен в микротике.
В данном случае, на микротике DNS провайдера не используются, а используются, как раз восьмёрки.
Если честно, ни разу не сталкивался, чтобы разные DNS отдавали разные A-записи. Только если кэш обновить не успели.
Если честно, ни разу не сталкивался, чтобы разные DNS отдавали разные A-записи. Только если кэш обновить не успели.
бывает. Не так часто, но случается.
Для простых сайтов ip в основном одинаковые, а для серьезных могут например сеть akamai использовать для надежности и безопасности, в таких случаях ip серверов для разных регионов отличаются. Можете пропинговать www.jw.org.
Насколько я понял, он разные ip выдаёт каждый раз.
У меня через dns провайдера ip адрес не меняется, что доказывает: сервер google(8.8.8.8) может (в зависимости от нагрузки или маршрута пакета) выдавать ip серверов разной локализации, что в нашем случае не есть гуд.
а вы кэш чистили у себя? а ваш провайдер?
У себя — да. У провайдера нет. Во всяком случае необходимо для скрипта указать, что ip dns сервера должен быть тот, который указан в микротике первым. Я на эту проблему вышел когда попробовал ваш скрипт применить, так вот через 8.8.8.8 все глючило, когда в скрипте прописал dns провайдера(который в микротике прописан первым) проблемы исчезли.
Кто написал эту статью он много сам скриптов то написал? Это просто?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Писать скрипты для Mikrotik RouterOS — это просто