Pull to refresh

Comments 67

К сожалению в RouterOS нельзя создать правило
блокировать все TCP соединения на порт 80 по адресу example.com

Да ладно. add action=drop chain=forward content=«Host: habrahabr.ru»
На 500 друг за другом идущих таких правилах, я думаю микротик скажет: «фу таким быть» и скорость будет страдать, не? :)
Подтверждаю. Будет страдать, а если ещё какой-нибудь ipsec параллельно работает — вообще загнуться может. Да и самому в них довольно сложно ориентироваться будет.
В данном случае немного неправильно применение (неплохого, кстати) инструмента.
Если вам нужно блокировать 10+ доменных имён — впору задуматься о настройке прозрачного squid.
Как вы сквидом будете ssl трафик обрабатывать? А если на 443 порту не https? А если на 80 — не http?
Подразумевается работа http(s) прокси сервера. Работа с https через него ведётся путём запроса метода CONNECT hostname у прокси-сервера. На что сервер отвечает denied.
Но это в случае если вы обеспечиваете корпоративный выход в инет на предприятии, где запрет социалочек регламентирован. Если же Вы пытаетесь «втихую» блокировать сайты в маленькой конторке, то да, костыли — вариант.
Подразумевается работа http(s) прокси сервера. Работа с https через него ведётся путём запроса метода CONNECT hostname у прокси-сервера.

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

А как же BYOD? На всех смартфонах-ноутбуках будете настройки бегать прописывать?
А в таком случае это решается корпоративным DNS и запретом соединяться с другими внешними DNS серверами.

Вполне годно. Работает.
UFO just landed and posted this here
в Mikrotik есть свой web-прокси… https он конечно не может, но в общем весьма пригодный.
Точнее:
/ip firewall filter
add action=drop chain=forward content=«Host: habrahabr.ru» dst-port=80 protocol=tcp
Это если у вас http. Этого-то в условии задачи не было сказано :)
В условии был 80 порт, это и есть http :)
Наверное, я пример не удачный привёл. С https ваше правило не сработает.
Разумеется, это только для http. Этот способ покрывает большинство сайтов и намного проще написания скриптов, только и всего.
Вы зря так, 80 порт — это не только http.

Минимум вы путаете уровни модели 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 ), но тут опять встаёт два вопроса:
— производительность, т.к. анализ принадлежности трафика основан на анализе содержимого пакетов
— качество точности определения типа трафика
Большое спасибо за подсказку! не знал. вы пробовали сами реальные возможности?
Нет, не пробовал, т.к. микротик домашний, и у меня нет необходимости в L7-фильтрах.
Как дешевый вариант — заверните трафик 80 порта в прозрачный прокси. Что через него пройдет — то уже http :) Остальное просто не пройдет.

Надо однако понимать цель определения 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, я понял вас. Спасибо за помощь.
> Спасет — ну вот инспекцией и спасет, в данном вопросе. Разбирая, как минимум, какой еще трафик кроме необходимого пойдет по порту.

Вы меньше верьте в чудеса и в идеальной инспекции «из коробки». Я как-то поставил инспекцию ESMTP трафика — а сервер у меня почему-то перестал часть писем получать. Расследование показало, что что-то циске в иных SMTP-диалогах не нравилось…

Повторюсь, http вы и на микротиковском прокси обработаете (IP -> Webproxy), а вот с https будут вопросы, да. Не из-за Микротика, а из-за протокола.
На грани оффтопа, но, думаю, кому-то кроме меня пригодится.
Я сделал на микротике в офисе гостевую Wi-Fi сеть для интернета без доступа к локалке. Доступ ограничил так: на бридже в цепочке forward создал правило дропать все, что идёт с wlan2 НЕ на ether1-gateway. Это надёжно с точки зрения безопасности? Вообще, есть какие-нибудь причины так не делать?
Единственная проблема на первый взгляд, это что не будут работать сайты, которые хостятся у вас в офисе, даже по dns имени, которое смотрит на внешний ип офиса.
Что бы это обойти надо прикрутить еще тройку костылей…
можно загнать в address-list (например, local-servers) адреса серверов, на которые нужно попадать с wi-fi и положить правило, пропускающее пакеты с dst-address-list равным local-servers, до правила с DROP'ом
Кстати хороший вариант, мне же в голову пришел более изощренный костыль, это snat'ом подменять адрес из wifi-range на внешний ip офиса при dst адресе веб сервера…
Вы в курсе, что тогда сервера будут видеть один и тот же адрес от всех клиентов — адрес шлюза? Думаю, что не нужно объяснять чем это плохо с точки зрения безопасность (выявления вредителя, находящегося в той же подсети).

Правильнее всего вынести сервара в dmz-зону (отдельную подсеть), тогда и лишний раз nat'ить не нужно, и фаерволить проще.
Думаю, что «выявления вредителя, находящегося в той же подсети» это не самая правильная формулировка. По сути гостевая wi-fi сеть в офисе, которая будет ходить к серверам по внешнему адресу, ничем не отличается от любого другого публичного wi-fi или провайдера с серыми адресами. Сервис торчит наружу, к нему приходят снаружи…
Не совсем понимаю чем это небезопасно?
ок. Давайте представим себе такую ситуацию…

В офис приезжает важный по какой-то причине человек, который подстёгивается в вафле, и начинает работать с серверами из Вашей локалки и ходить наружу (почта, скайпик, 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»)}
а тут разве не резолв?
Он нужен, чтобы сделать запрос к днс-серверу. В кэш попадут все записи, относящиеся к этому домену.
В какой момент в ДНС-кеш микротика попадут ВСЕ записи нужного домена?
Просто проверил. От пинга на тике и нслукапа на виндовом клиенте в ДНСе микротика записи для всех адресов даного домена не появились.
В момент резолва на микротике
[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. Чем вам микротики не угодили? Если от другого вендора, то Cisco, Juniper какие-нибудь.
2. Бэкап микротика — это хорошо. Но у меня редко вносятся изменения в конфигурацию, а все конфигурации достаточно типовые и однообразные. В случае чего дольше будут искать (покупать/заказывать/везти) микротик на замену, чем я его буду настраивать. А там где требуется всегда можно иметь абсолютно идентичный роутер с такой же конфигурацией на замену.
NOC отличный проект, который в том числе позволяет автоматически собирать конфиги и следить за их изменениями. Подробнее было в выпуске LinkMeUp #9 и #10.

У себя делаю это по расписанию на scheduler`е и отправляю на ftp сервер. Позже делаю еще один запрос на CGI скрипт, который создает commit в git`е если были сделаны были изменения.
свежий mikrotik чего то не ставится на виртуальную машину (vmware work на esxi не пробовал еще.)… а то проверять бекапы и вообще много всего делать можно было.
Можно метароутер использовать
ставится, ставится )) на том же kvm живет и не переживает

и бекапится отлично образом/снапшотом.
:lua — Lua язык в скриптах — это была прекрасная идея версии 4.0 b3, но к сожалению в v4 RC1 удалили поддержку Lua так вот и сидим ждем может появится это счастье…

Вот какой синтаксис был:

[:lua "require 'customprint'\n print('hello from custom print function')"]
Еще не хватает таких примочек как :break и :continue для циклов (я по крайней мере не нашел их поддержки и реализации), ну и ужасного :goto
да тоже… запускайте через консоль скрипт там хоть позиция ошибки указывается…
Так и делаю, но в винбоксе не хватает CTRL+A в окне скрипта, чтобы заменить исправленной версией быстро. А пишу я скрипты в notepad++, у меня есть файлик с синтаксиса подсветкой.
все тоже самое, но я приучил себя к консоли… по SSH удобнее стало в разы.
Хочу поправить: :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-записи. Только если кэш обновить не успели.
бывает. Не так часто, но случается.
Для простых сайтов ip в основном одинаковые, а для серьезных могут например сеть akamai использовать для надежности и безопасности, в таких случаях ip серверов для разных регионов отличаются. Можете пропинговать www.jw.org.
У меня через dns провайдера ip адрес не меняется, что доказывает: сервер google(8.8.8.8) может (в зависимости от нагрузки или маршрута пакета) выдавать ip серверов разной локализации, что в нашем случае не есть гуд.
а вы кэш чистили у себя? а ваш провайдер?
У себя — да. У провайдера нет. Во всяком случае необходимо для скрипта указать, что ip dns сервера должен быть тот, который указан в микротике первым. Я на эту проблему вышел когда попробовал ваш скрипт применить, так вот через 8.8.8.8 все глючило, когда в скрипте прописал dns провайдера(который в микротике прописан первым) проблемы исчезли.
Кто написал эту статью он много сам скриптов то написал? Это просто?
Only those users with full accounts are able to leave comments. Log in, please.

Articles