Mikrotik RouterOS, использование Layer7 протокола
Всем известно, что Mikrotik RouterOS, это достаточно гибкая, сетевая операционная система с обширным функционалом и достаточно большим количеством разнообразных функций и протоколов. Одной из таких функций, относящихся к разделу Firewall, является Layer7 protocol. И она не заслужена обделена вниманием, о ней мало информации и даже не все знают зачем она. Вот именно этот пробел, мы сегодня и постараемся заполнить, ведь данная особенность, открывает достаточно широкие возможности по определению вида трафика и его последующей сортировке.
Чаще всего, L7 используют для блокировки тех или иных сайтов или же работы тех или иных программ. Рассмотрим например блокировку сайтов социальных сетей при помощи данной функции.
Предположим, что нам нужно заблокировать посещение сайтов ВКонтакте, Одноклассники, Facebook и Twitter. Для этого мы сперва создаем регулярное выражение вида:
Где в поле Name, вписываем имя новой записи, а в поле Regexp, вставляем наше регулярное выражение.
И теперь, на его основе, мы можем создавать правила Firewall, на соответствующей вкладке.
И теперь, если в заголовке запроса, будет упоминаться тот или иной URL, перечисленный в регулярном выражении, этот запрос будет отклонен.
Однако, спектр возможного применения Layer7 protocol, не ограничивается только запретами. Можно и наоборот, дать приоритет тому или иному виду соединений, определенных при помощи этой функции. Например, определить телефонное соединение по протоколу SIP, при помощи регулярного выражения вида:
После чего, пометить все пакеты данного типа при помощи правила на вкладке Mangle.
И создать правило, в соответствии с которым, данным пакетам будет предоставлена приоритетная ширина канала в 25Mbit/s в разделе Queues.
Интересные факты о протоколе седьмого уровня в маршрутизаторах Mikrotik
Есть в маршрутизаторах Mikrotik такая функция, как layer7-protocol, если кто не знает, находится она в меню IP Firewall, где есть соответствующая вкладка.
Рис.1. Меню IP FireWall. Вкладка Layer7 protocol
Layer7 protocol – это метод поиска по определенным параметрам в ICMP/TCP/UDP потоках. И при помощи правильно составленных регулярных выражениях посредством этого протокола можно очень гибко управлять всем проходящим через маршрутизатор трафиком. В частности, данная опция получает первые 10 пакетов или 2KB каждого установленного соединения и ищет совпадения по регулярному выражению. Если совпадений нет, то дальнейший поиск прекращается и соединение, считается неизвестным. Если же совпадения находятся, то в дальнейшем на вкладах Filter Rules, NAT или Mangle можно создавать цепочки правил с необходимыми действиями, которые вы хотели бы совершить над данным типом трафика.
Внимание! Чрезмерное злоупотребление данной функцией и большое число записей layer7-protocol может привести к серьезной нагрузке на устройство, так как все без исключения потоки трафика обрабатываются.
Область применения L7 протокола крайне велика. Приведем пример, в котором определим соединение по SSH протоколу. Для этого мы создадим новую запись, которая будет содержать такое регулярное выражение: ^ssh-[12]\.8
Сделать это можно через командную строку, как показано на изображении.
Рис.2. Результат командной строки – ip firewall layer7 protocol
Или же, через GUI в меню IP Firewall на вкладке Layer7 Protocol.
Рис.3. GUI, в меню Firewall 7 Protocol
После чего на вкладке Filter Rules можно создать правила Firewall, в котором допустим, запретить данный вид трафика входящего в маршрутизатор в цепочке input.
Рис.4. Создаём правила Firewall в цепочке input
И при попытке подключиться к Mikrotik по этому протоколу, Вы увидите, что пакеты блокируются.
Рис.5. Пакет блокируется при подключении к Mikrotik
Похожим образом можно определять, помечать, фильтровать и сортировать практически любой вид трафика. Достаточно только правильно определить его. Для этого уже написан целый ряд регулярных выражений. Некоторые из них мы приводим в таблице ниже:
]*ftp
]*\x0d\x0a)
Таблица регулярных выражений
Так же можно самостоятельно составить регулярное выражение, допустим, для определения соединения с сайтами социальных сетей. Такой Regexp будет выглядеть примерно так: ^.*(get|GET).+(vk.com|odnoklassniki.com|twitter.com).*$ И это только малая часть возможных регулярных выражений. Однако, хочется заметить, что наш мир, а уж тем более Интернет, постоянно меняется, поэтому возможен вариант, что приведенный Regexp может не работать.
И если добавить такую запись в разделе Layer7 Protocol, то в дальнейшем можно запретить этот трафик или перенаправить в другое место. Тем самым заблокировав доступ к этим сайтам.
Рис.6. Regexp – соединения с сайтами социальных сетей
Рис.7. Можно запретить или заблокировав доступ к социальным сетям
Если Вы нашли ошибку в тексте, то выделите ее мышкой и нажмите Ctrl + Enter или нажмите здесь.
Большое спасибо за Вашу помощь! Мы скоро исправим ошибку!
Сообщение не было отправлено. Пожалуйста, попробуйте еще раз.
Записки IT специалиста
Технический блог специалистов ООО»Интерфейс»
Настройка черного и белого списков в роутерах Mikrotik
Ограничение доступа к тем или иным ресурсам сети интернет на основе списков достаточно популярный способ фильтрации, несмотря на его недостатки. Действительно, в большинстве случаев требуется заблокировать достаточно небольшой список ресурсов, скажем, соцсети, с чем данный метод вполне успешно справляется. В данной статье мы поговорим о том, как настроить фильтрацию по спискам на роутерах Mikrotik, тем более что RouterOS предоставляет нам для этого достаточно широкие возможности.
Из этого следует, что мы не можем блокировать отдельные страницы, но можем заблокировать домен целиком. Для большинства сценариев этого вполне достаточно. Но здесь нас подстерегает другая неприятность, многие сайты используют CDN (Content Delivery Network, сеть доставки контента), такие как CloudFlare и заблокировав нужный вам сайт вы можете также ограничить доступ к большому количеству сторонних ресурсов. Что из этого может выйти все мы видели во время ковровых блокировок РКН против Телеграм.
Также следует понимать, что блокировка посредством черных списков применима лишь к небольшому числу ресурсов, например, популярные соцсети, попытка таким образом фильтровать весь нежелательный трафик выливается в необходимость постоянной актуализации списков и может привести к высокой нагрузке на оборудование. Для таких целей лучше использовать специализированные сервисы.
Создаем списки
В командной строке это же действие можно выполнить так:
Таких списков мы можем создать сколько нам нужно, причем один и тот же адрес может входить сразу в несколько списков. Это удобно, если нужно обеспечить для разных групп пользователей доступ к разному набору сайтов. В итоге у вас должно получиться примерно следующее:
С доменами разобрались, остались пользователи. Существуют две политики применения правил: разрешено всем, кроме группы пользователей и запрещено всем, кроме группы пользователей. В любом случае у нас имеется группа пользователей, которая либо подвергается ограничениям, либо выводится из-под их действия. В грамотно спроектированной системе такая группа должна являться меньшинством, что обеспечит минимальную нагрузку на сетевое оборудование.
После чего закрываем и снова открываем запись и в поле Address List вводим, если это первая запись, или выбираем имя списка, куда будет добавлен IP-адрес данного компьютера, в нашем случае это список USER.
Либо через командную строку:
Таким образом мы получаем список пользователей, либо несколько списков, в которых указанные адреса будут находиться до тех пор, пока на сервере активно резервирование.
Черный список
И наконец на закладке Action указываем действие, обычно везде в интернете указывают drop, хорошо, укажем и мы.
Данное правило должно располагаться самым первым в цепочке FORWARD, выше FastTrack.
Теперь попробуем посетить запрещенный сайт:
После замены действия при повторной попытке посетить ресурс мы сразу увидим сообщение о его недоступности:
Быстро добавить правило через командную строку можно так:
Или в командной строке:
Таким образом фильтрация по черным спискам не представляет особых сложностей. Все упирается в эти самые списки, которые нужно составлять и поддерживать в актуальном состоянии. Загрузить в роутер готовые списки из интернета также не очень хорошая идея, потому как каждый пакет будет проверяться на вхождение в список, что может вызвать серьезную нагрузку на роутер, при том, что подавляющее большинство адресов из этого списка ваши пользователи могут никогда не посещать. Поэтому следует трезво оценивать собственные ресурсы и возможности и применять списки там, где это действительно нужно.
Белые списки
На первый взгляд организация доступа в сеть по белым спискам ничем принципиально не отличается от черных, однако это не так, выше мы уже говорили почему и далее покажем это на примерах. А пока реализуем схему с доступом по белым спискам для всех, кроме группы USER.
И на закладке Action указываем действие reject. Таким образом данное правило будет блокировать все соединения, если адрес отправителя не входит в группу USER и адрес назначения не входит в белый список WL.
Аналогичное действие через консоль:
Данное правило также следует располагать первым в цепочке FORWARD.
Добавим к разрешенным несколько адресов, в нашем случае yandex.ru и interface31.ru и попробуем открыть один их них. Яндекс открывается, но выглядит довольно непривычно.
Многие картинки, которые располагаются на иных серверах, включая сервера самого Яндекса, но имеющего другие IP-адреса просто не подгружаются. Хотя никаких фатальных последствий это не несет, как поисковик Яндекс работает. А вот в почту войти уже не получится, для этого придется разрешить как минимум mail.yandex.ru и passport.yandex.ru.
Теперь попробуем открыть наш сайт. А вот тут первый неприятный сюрприз:
Что это значит? Браузер не может проверить подлинность сертификата, а так как наш сайт использует HSTS, то доступ к нему будет невозможен, потому как подобные действия могут указывать на атаку с понижением степени защиты, чему HSTS должен препятствовать.
Для того, чтобы браузер смог проверить сертификат нам нужно разрешить доступ к сведениям центра сертификации, адреса нужных узлов можно найти в самом сертификате сайта:
В нашем случае оказалось достаточно добавить узел ocsp.int-x3.letsencrypt.org, сайт загрузился, но без комментариев, так как они реализованы на стороннем ресурсе и разрешение доступа к нему не решило проблемы. В этом случае вам придется либо заниматься долгим и кропотливым выяснением необходимых для работы ресурсов и занесением их в белый список, либо отказываться от части функционала сайтов.
Либо в командной строке:
Как видим, технически организовать доступ по белым спискам не так уж сложно, гораздо сложнее обеспечить полноценную работу разрешенных сайтов, что требует достаточно долгой и кропотливой работы по выявлению и добавлению в список связанных ресурсов.
Layer 7 protocol
Использовать L7 для блокировки сайтов не рекомендуют сами разработчики Mikrotik, справедливо замечая, что в большинстве случаев это не будет работать так, как задумано, но при этом вы будете впустую растрачивать вычислительные ресурсы роутера. На наш взгляд использовать L7 для задач, связанных с доступом к сайтам вообще бессмысленно. Современный трафик в подавляющем большинстве шифрованный и различного рода конструкции для анализа URL просто не будут работать, а управлять доступом на основе доменного имени вполне можно и на L3 (чем мы занимались выше).
По этой же самой причине не будут работать многие размещенные в интернете инструкции, где трафик фильтровался по содержимому, типам файлов или потоков, использовал параметры запросов и т.д. и т.п. Хотя мы до сих пор встречаем статьи, в которых по L7 пытаются блокировать соцсети или Youtube, мотивируя это большим числом адресов, использованием CDN, поддоменов и т.д. и т.п. Однако все это не выдерживает никакой критики, соцсети и видеохостинги прекрасно блокируются по доменному имени.
Мы не рекомендуем использовать L7 во всех тех случаях, когда задачу можно решить иным образом, применяя его только для решения специфичных задач. Например, выявления и блокировки какого-либо вида трафика.
Где брать паттерны? Опытные пользователи могут запустить сетевой сканер (tcpdump, Wireshark) и проанализировать доступное содержимое пакетов и на основании полученной информации составить регулярное выражение. Либо воспользоваться сайтом l7-filter.sourceforge.net, однако большая часть паттернов оттуда работать не будет. Во-первых, сайт достаточно старый, последний раз обновлялся в 2009 году, во-вторых, очень многие протоколы перестали использоваться в открытом виде, а используют SSL-шифрование. В этом случае вы просто увидите SSL-поток, блокировать который бессмысленно, так как вы заблокируете практически весь интернет.
Также можно выполнить команду в терминале:
Все тоже самое быстро делается в командной строке:
Многие читатели не работают с брандмауэром дальше таблицы Filter, поэтому что, что мы сейчас сделали в Mangle может показаться им какой-то особой магией. Коротко поясним наши действия. Первое правило проверяет все немаркированные соединения и те из них, которые сосуществуют фильтру L7, т.е. SSH-соединения получают метку SSH-CONN и продолжают движение по цепочке. Следующее правило проверяет соединения и все пакеты соединений, промаркированных как SSH-CONN снабжает меткой SSH-PCK.
На закладке Action ставим действие drop. То же самое в консоли:
Ставим это правило также в начало цепочки FORWARD и если вы все сделали правильно, то установить SSH-соединение из вашей сети больше никому не удастся.
Следует понимать, что выше был лишь пример того, как можно использовать Layer 7 protocol на Mikrotik, в реальной ситуации следует несколько раз подумать и прибегать к возможностям L7 только тогда, когда все остальные варианты исчерпаны. Также старайтесь как можно более подробно описывать условия, для правил использующих L7 фильтры, чтобы максимально уменьшить нагрузку на процессор роутера.
Фильтрация по MAC-адресам
Наши читатели с завидным постоянством спрашивают нас как можно организовать фильтрацию по MAC-адресам. Мы уже говорили и повторим еще раз, что считаем такую фильтрацию не самым оптимальным способом, потому что для идентификации следует использовать более высокоуровневые параметры: пользователя или IP-адрес. Но если сильно хочется, то почему бы и нет.
Среди условий в правилах брандмауэра есть опция MAC-адреса, но в одном правиле можно указать только один адрес, т.е. для каждого MAC вам придется создать свою копию правила, что увеличит нагрузку на устройство и сделает набор правил трудночитаемым.
И на закладке Action добавим действие add src to address list, где в поле Address List укажем требуемый список пользователей, в нашем случае USER, а в поле Timeout укажите требуемое время жизни записи, это нужно для того, чтобы запись обновилась при смене обладателем MAC IP-адреса. На скриншоте мы, в тестовых целях, использовали 5 секунд, в реальной жизни руководствуйтесь здравым смыслом и выбирайте более высокие значения.
Это же правило в командной строке:
Теперь первый пришедший с данного устройства пакет добавит его IP-адрес в указанный нами список, тем самым связав его с текущим MAC на время указанное в Timeout. Для каждого следующего устройства необходимо создать подобное правило, также не забывайте снабжать каждое из них комментарием, чтобы впоследствии вам и вашим коллегам было понятно о каком именно устройстве идет речь.
Заключение
Как видим возможности RouterOS позволяют решать достаточно сложные задачи используя даже недорогие роутеры. Но следует понимать ограничения всех вышеперечисленных методов, осознавая их достоинства и недостатки. А также соотносить свои требования с возможностями оборудования. Если понимать и принимать во внимание эти факторы, то фильтрация по спискам на Mikrotik будет эффективным инструментом в руках администратора. В противном случае вы получите только разочарование и иные негативные последствия. Поэтому пожелаем вам благоразумия и напомним: хороший администратор выбирает для каждой задачи наиболее подходящий инструмент, что является признаком профессионализма. А фанатизм еще никого до добра не доводил.
Дополнительные материалы:
Mikrotik
The Dude
Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Layer 7 DoS: атаки на отказ от обслуживания веб-приложения
Распределенные атаки на отказ в обслуживании, которым подвергаются популярные сайты обычно происходят с тысяч и тысяч взломанных устройств. Эти атаки в основном направлены на подавление целевой системы масштабным трафиком, забиванием канала связи. Эти атаки относятся к layer 3 (сетевой уровень модели ISO/OSI) DoS/DDoS и характеризуются большим количеством пакетов, которыми атакуется ресурс. Layer 7 (прикладной уровень модели ISO/OSI) DoS/DDoS обычно направлен на «слабые» места веб-приложения.
Для начала приведу немного статистики из исследования компании Incapsula — начиная с 2016 года DoS/DDoS атаки на прикладном уровне превалируют над классическими атаками на отказ от обслуживания на сетевом уровне:
Сложность в определении таких атак в том, что веб-приложение не может легко отличить атаку от обычного трафика. Есть много факторов, которые способствуют этой трудности, но одним из наиболее важных является то, что по ряду причин IP-адреса не могут быть полезны в качестве идентификационных данных. При сетевой атаке можно различить нелегитимный трафик и заблокировать атакующие IP-адреса, в случае атак на уровень приложений это сделать затруднительно: необходимо определить именно атакующие признаки, не заблокировав легитимных пользователей. Также, простое использование ресурса (без атак), может привести к исчерпанию его ресурсов — это может быть известный здесь многим Хабраэффект.
Основные типы DoS/DDoS атак:
Volumetric: объемные атаки нацелены на переполнение полосы пропускания веб-приложения хостинговой инфраструктуры, направляя большие объемы сетевого трафика. Обычно такой трафик представлен UDP/ICMP флудом.
Layer 3: эти атаки нацелены на недостатки архитектуры стека протоколов TCP. Атакующий отсылает пакеты, предназначенные для переполнения, искажения или разрушения информация о состоянии соединения, вызывающие дополнительную работу для функций сетевой обработки на целевом устройстве и замедлении ответов. Наиболее распространенными векторами таких атак является TCP SYN flood, фрагментация TCP, teardrop и т.д.
Layer 7: эти атаки ориентированы на логику веб-приложения и нацелены на исчерпание ресурсов веб-сервера при обработке «тяжелых» запросов, интенсивных функций обработки или памяти.
Ресурсы приложения
Большинство веб-серверов могут обрабатывать несколько сотен одновременных пользователей при нормальном использовании ресурса. Проблема заключается в том, что один атакующий может генерировать достаточный трафик с одного хоста для отказа в обслуживании веб-приложения. Балансировка нагрузки в таком случае не поможет от слова «совсем».
Основные проблемы выглядят следующим образом: утилизация CPU — использование 99% CPU заставляет другие критические процессы останавливаться; RAM — недопустимое распределение памяти, утечки, исчерпание памяти — недостаток для других критичных процессов; процессы и потоки — deadlock (заморозка процессов), форки, race condition (состояние гонки); диск — переполнение диска.
Одним из важных ресурсов веб-сервера является RAM. Атаками на исчерпание этого ресурса могут быть следующие:
Рекурсия. Вот неплохой пример рекурсивного кода — include(‘current_file.php’). PHP выделяет новую память для каждого включения и повторяет процесс до тех пор, пока не останется памяти. Эту уязвимость можно обнаружить в виде классического LFI (local file inclusion).
Zip-бомбы. Веб-приложения, которые позволяют загружать сжатые файлы и извлекать содержимое, могут быть восприимчивы к такой атаке, особенно если приложение (или библиотека, которая обрабатывает декомпрессию) не проведет надлежащую проверку файла.
XML-бомбы. Именованные сущности могут раскрываться не только в символьные строки, но и в последовательности других сущностей. Рекурсия запрещена стандартом, но ограничений на допустимую глубину вложенности нет. Это позволяет добиться компактного представления очень длинных текстовых строк (аналогично тому, как это делают архиваторы) и составляет основу атаки «billion laughs».
Десереализация. Сравнительно новый тип атак, но достаточно серьезный, что внесен в OWASP TOP 10 2017 A8-Insecure Deserialization. Представляет из себя процесс восстановление начального состояния структуры данных из битовой последовательности. При ненадлежащем контроле пользовательского ввода может привести к исчерпанию ресурсов.
Файловые заголовки. Манипулирование значениями файловых заголовков может привести к исчерпанию ресурсов. Если вычисление выполняется во входном файле, где размер файла находится в его заголовке. Это могут быть изображения, видеофайлы, документы и т.д. Пример — pixel flood attack.
Чтение бесконечных потоков данных. Чтение /dev/zero или /dev/urandom через LFI, использование 1TB speedtest и т.д.
Немаловажным параметром веб-сервера является CPU, атаки на исчерпание процессорных мощностей могут привести к неработоспособности веб-приложения.
reDOS — Regular Expression Denial of Service. Сравнительно свежий тип атаки, впервые был выявлен на Stackoverflow. Это была не атака злоумышленника, а действия пользователя, который включил 20 000 пробельных символов в фрагмент кода. Регулярное выражение было написано таким образом, что оно заставляло систему проверять строку из 20000 символов на в 200.010.000 шагов (20 000 + 19 000, +… + 2 + 1). Если веб-приложение позволяет использовать регулярные выражения — стоит тщательно проверять входящие данные.
SQL-инъекции. Эксплуатация SQL-инъекций может значительно снизить работоспособность веб-приложения, особенно при использовании функций типа sleep, benchmark и т.д.
Форк-бомбы. Процессы, которые повторяются снова и снова, используя все ресурсы системы. Наиболее известной является :()< :|:& >;:.
Злоупотребление ресурсами/функциями. Злоумышленник может выявить ресурсоемкую операцию на веб-приложении и послать множество запросов исчерпание ресурсов. Таким примером может служить злоупотребление функциями хэширования паролей.
SSRF. Эксплуатация server side request forgery уязвимостей может позволить злоумышленнику исчерпать ресурсы атакуемого веб-сервера.
Дисковое пространство также является критичным параметром веб-сервера.
Загрузка больших файлов. Наиболее очевидным способом заполнения системы данными является загрузка больших файлов на сервер. Если приложение не применяет надлежащие ограничения, злоумышленник может загружать в систему данные до того момента, пока веб-сервера не исчерпает ресурсы.
Переполнение системных журналов. При отсутствии функций ротации логов атакующий может «забить» системные журналы или послужить катализатором создания огромного количества этих журналов, что приведет к исчерпанию ресурсов дискового пространства.
Утилиты для тестирования веб-приложений:
Я намеренно не буду рассматривать узкоспециализированные утилиты типа LOIC/HOIC, нацеленные как правило на дестабилизацию работу определенных веб-приложений.
Вредоносное использование данных инструментов запрещено и может преследоваться законодательными мерами страны, резидентом который вы являетесь. Используйте данные инструменты для тестирования исключительно собственных серверов, либо серверов, тестирование которых согласовано с их владельцем на законном основании.
Slowloris — довольно известная утилита для тестирования. Существует nse скрипт для nmap.
HULK (HTTP Unbearable Load King) — генерирует большой поток уникальных запросов, который максимально потребляет ресурсы веб-сервера. Чтобы осложнить задачу по фильтрации потока, HULK для каждого запроса подставляет разные user agent, обфусцирует referrer, использует в запросах атрибуты no-cache и keep-alive, а также уникальные URL.
OWASP DoS HTTP POST — утилита от консорциума OWASP для генерации «медленных» http запросов.
GoldenEye HTTP Denial of Service Tool — эксплуатирует векторы HTTP Keep Alive + NoCache.
Превентивные меры защиты
Хорошей практикой превентивной защиты веб-приложения будет нагрузочное тестирование веб-ресурса. Для исследования времени отклика системы на высоких или пиковых нагрузках производится «стресс-тестирование», при котором создаваемая на систему нагрузка превышает нормальные сценарии её использования.
Основная цель нагрузочного тестирования заключается в том, чтобы, создав определённую ожидаемую в системе нагрузку (например, посредством виртуальных пользователей или их действий), наблюдать за показателями производительности системы. Это позволит выявить и усилить узкие/слабые места вашего веб-приложения и избежать возможных рисков недоступности приложения в будущем.
