О контентной фильтрации в учебных заведениях. Проблемы. Ростелеком фильтры


Как мы писали URL-фильтрацию Ростелекому / Хабр

Недавно на Хабре была статья о внедрении URL фильтрации «Ростелекомом» (РТК). Так случилось, что мы предлагали им решить эту задачу года полтора назад и год назад сделали решение, которое прошло все тесты и которое «Ростелеком» готов был включать. К тому моменту лавка наша выпала из милости, ну да это не вопрос техники. Посему все изложенное далее – это детали предложенного нами решения. Что точно внедрят, бог весть.
DPI и блокировка по IP
Начать видимо стоит с DPI. Они в некотором количестве на сети имеются, но поставить их на весь трафик стоило бы РТК несколько десятков миллионов долларов и постоянно требовало бы новых инвестиций в связи с ростом потребления скучающим населением. Ни предыдущие, ни теперешние руководители на такое не решились (возможно лишь пока), потому как никаких новых услуг с осязаемыми объемами доходов внедрение DPI не обещает.

Поскольку блокировать разные ресурсы РТК должен был и раньше (суды вершат без оглядки на законы), то и делал это по IP’ческим адресам. Соответственно, простейшая фильтрация на границах решала проблему. Аналогично стали решать и проблему с реестром запрещенных ресурсов: специально обученный человек выгружал реестр, там есть и URL и IP и дальше добавлял записи в списочек, а скрипт правил access list.

ПО управления фильтрацией
Мы автоматизировали общение с реестром и тут, как всем понятно, магии никакой (ее и дальше то особо нет). Запротоколировали внесение изменений в реестре и реализацию цензуры на сети. Добавили мелкие рюшечки, связанные с распределенной структурой ответственности на сети РТК, исключением из действия фильтра части абонентов (в частности запредельных операторов). Ну и суды никто не отменял, поэтому есть возможность внести любой ресурс из судебного решения. Помимо этого, управляющее ПО настраивает перенаправление трафика на узлы фильтрации, готовит отчеты о поисковых запросах пользователей, мониторит узлы фильтрации и протоколирует все активности.

Поворот трафика и фильтрация
Трафик направляемый абонентами на IP адреса соответсвующие блокированным URL'ам на PE поворачивали в специальный VPN, где defult смотрит на пару рутеров в центре. Используя SCU/DCU (похожая функциональность вроде и на кисках имеется) на границе же исключали по адресам источника трафик от абонентов, фильтрации не подлежащих. Софт управления формировал /32 маршруты по IP адресам реестра, правил конфиг на центральном маршрутизаторе и изменения вступали в силу. От посылки BGP апдейтов, помнится, отказались, потому как нехорошо это.

На двух центральных маршрутизаторах настраивали копирование проходящего трафика уже с учетом портов. Соответственно на весь РТК получалось от силы несколько мегабит. Копировать можно было либо на внешний сервер, либо на MS-DPC. И там и там принцип дальнейшей обработки был одинаков. ПО фильтрации ловит пакет, если в нем get с URL’ом из списка, то в сторону сервера шлем сброс, а в сторону браузера редирект на сайт с рассказом про то, как важны моральные принципы для современного российского общества.

Минимальное время ответа от серверов, входивших в реестр год назад, превышало 100 мс, а софтина, анализирующая URL, выдавала ответ за 5-6 мс при нагрузке в 3 Гб/с. Посему решили, что городить прокси, обеспечивать его надежность и прочее в том же духе смысла не имеет. При сбое ПО фильтрации все будет работать, кроме фильтрации понятно. Правда по просьбе РТК запроектировали все равно по паре серверов фильтрации.

Сейчас понятно, что можно было и чуть проще сделать, использовать маленький DPI в центре вместо своего ПО фильтрации. Но так мы уже другому оператору сделали. Может статься, что выбранные внедренцы скомбинируют свое ПО работы с реестром с обычным DPI, через который пойдет только выбранный трафик. Нам же на тот момент хотелось понять есть ли хоть какая-то задача, которую стоило бы реализовывать на сервисных модулях в маршрутизаторе, а не снаружи. То, что Juniper закрыл для внешних разработчиков доступ к модулям, дает четкий ответ на этот вопрос, но нас тогда еще мучили сомнения.

Что касается стоимости, то из того миллиона, о котором идет речь, больше половины составляли серверы, так что большой прибыли на софте там не планировалось.

habr.com

О контентной фильтрации в учебных заведениях. Проблемы / Хабр

image

Доброго времени суток, уважаемые сохабровцы! Я работаю системным администратором в одном из ссузов России. С недавних пор, как уже многим известно, учебные учреждения обязали ограничивать интернет-контент своим учащимся. На мой взгляд, дело это, конечно, нужное, но вот реализация… Под катом будет небольшое описание из серии «как я это понял», немного личного опыта по общению с прокуратурой и вопросы к сообществу.

Как я это понимаю
Для выполнения требований по ограничению доступа к ресурсам сети интернет, содержащим информацию, не совместимую с задачами образования и воспитания(ст.14 124-ФЗ, ст. 10 149-ФЗ) необходимо ограничить доступ к интернет-ресурсам, где есть порнография, «реклама» суицида и способы его осуществления, ненормативная лексика, способы изготовления взрывчатых веществ, наркотиков(и их реклама), терроризм, экстремизм и все такое прочее.
Как предлагают ограничивать
Существует реестр запрещенных сайтов РОСКОМНАДЗОРа и список экстремистских материалов минюста, коими и предлагается руководствоваться при ограничении контента
Проблемы
Получить полный список ресурсов единого реестра РОСКОМНАДЗОРа нельзя(не считая не всегда актуального и непонятно насколько легального ресурса). Можно только проверить определенный сайта на «непригодность», вбив его в строку запроса сайта реестра. Поскольку фильтрация в моем учебном учреждении осуществляется при помощи связки squid+dansguardian, то: — В черный список внести все сайты я не могу, поскольку этот список нельзя получить — Список запрещенных фраз для фильтрации я тоже не могу полноценно использовать, поскольку нет официально утвержденного списка — Кроме того по https мой фильтр тоже не умеет работать, поэтому некоторые ресурсы(соц-сети, например) я вынужден банить по ip, используя IPFW

Как результат, в данный момент мы используем «белые» списки + бан https-ресурсов по ip, но это, во-первых, очень НЕУДОБНО для студентов(я мечтал, что преподаватели снабдят меня списками сайтов, которые им нужны для работы, и я накоплю базу белых списков… но этого, конечно, не случилось), а, во-вторых, это, пожалуй, и не законно…

После написания статьи, нашелся способ с блокированием «рукамивбитых» https-url-ов (напомню, что dansguardian их не блокировал). Нужно в браузерах пользователей указать прокси-сервер(даже если он прозрачный) и порт 8080. Я сделал это с помощью GPO.

Прокурорская проверка
Вынудила написать этот пост меня именно она. Поскольку имела место быть, и имело место быть предписание по устранению выявленных нарушений(попыткой устранить нарушения и является фильтрация по белым спискам). Выглядело это так: Пришла девушка в форме, посетила библиотеку. На компьютерах библиотеки посмотрела историю браузера, прошла по ссылке из истории на анонимайзер-вконтакте, затем набрала в поиске «суицид» — получила пару ссылок, затем нашла что-то по изготовлению бомб и все. После этого был милый разговор с моим начальником о том, что «работа у вас, мы видим ведется… просто нужно доделать то да се… и т.д.». Затем выписали предписание, где «не похвалили» директора и ссуз. Через некоторое время было собрано совещание при директоре с участием этой представительницы прокуратуры. На совещании мной были заданы все выше перечисленные вопросы про списки и фразы, на которые ответа я, конечно, не получил. Были сказаны общие фразы типа «ну, вы отслеживайте», «вы вносите», «историю проверяйте раз в неделю» и все…
Вопросы к сообществу
Поскольку я вполне допускаю, что могу не знать о уже работающих каких-то решениях или неправильно понимать суть требований, или еще чего-то не знать/не уметь, то прошу помощи. Как не нарушать закон, удовлетворить «свободу доступа к информации» студентов, желательно решить все силами open source и без крови? :)

habr.com

Защита от DDoS-атак с точки зрения оператора связи. Часть 1

Мы активно следим за всеми статьями по теме DDoS, которые публикуются на Хабрахабре, и несмотря на то, что поиск по всем потокам на момент написания статьи показывал 820 публикаций, решили, что было бы неплохо от лица оператора связи поделиться видением проблематики выявления и борьбы с DDoS-атаками.

В первой статье попробуем познакомить читателей с базовыми понятиями. Статья рассчитана скорее на новичков, которые в базе понимают сетевые технологии, но никогда не сталкивались с промышленными решениями по защите от DDoS, и если данный материал вызовет интерес, то в следующем цикле статей начнем подробно раскрывать технические детали.

Чем характерно решение по защите от DDoS-атак для операторов связи?

Особенность построения решений по анализу трафика и выявления DDoS-атак для оператора связи неразрывно связана с архитектурой построения его сетей, а также с возможностями сетевого оборудования. Давайте рассмотрим это на примере: упрощенно архитектура магистральной IP/MPLS сети Ростелеком (AS12389) выглядит следующим образом.

Здесь upstream — вышестоящий оператор связи, peer — равноправный оператор связи или также крупный контент-генератор, а customer — клиент AS12389 А теперь давайте мысленно переложим дизайн сети на географию:

И, наконец, в цифрах представим количество взаимосвязей с upstream/peer/customer (https://radar.qrator.net)

Таким образом, даже никогда не имевшему дело с проектированием или эксплуатацией операторской сети легко понять: сеть имеет множество стыков и подключений, а природа маршрутизации трафика асимметрична, т. е. трафик в направлении к какому-либо IP-префиксу и от него идет по разным маршрутам. В отличии от дата-центров или корпоративных сетей у операторов связи нет границы в классическом понимании, и поставить средства анализа в одной или нескольких точках на границе не представляется возможным. Поэтому архитектурно эффективно строить AntiDDoS систему, состоящую из двух подсистем:

  1. Подсистема выявления аномалий: осуществляет сбор и анализ данных о трафике.
  2. Подсистема фильтрации:  осуществляет блокировку паразитного трафика.

Как происходит детектирование DDoS-атак?

Для возможности анализировать трафик и выявлять аномалии по отношению к любому IP-адресу — принадлежащему, напрямую подключенному или транзитом проходящему через AS12389 - необходимо анализировать весь трафик (каждого маршрутизатора, каждого IP-интерфейса). Чтобы решить данную задачу эффективно (с экономической точки зрения), информацию о трафике собираем с помощью протоколов сетевой телеметрии (J-Flow v5/9, Netstream, IPFIX). Далее для простоты все семейство этих протоколов будем называть NetFlow. Данные протоколы не позволяют анализировать информацию прикладного уровня и передают информацию до 4-го уровня модели OSI, например, J-Flow v5 имеет следующую структуру заголовка:где:
  • Source IP address — IP-адрес источника
  • Destination IP address — IP-адрес назначения
  • Next-Hop IP address — IP-адрес следующего маршрутизатора, на который будет передан сетевой поток.
  • Input ifIndex — SNMP индекс интерфейса, через который маршрутизатор получает flow
  • Output ifIndex — SNMP индекс интерфейса, через который маршрутизатор передает flow
  • Packets — общее количество полученных пакетов в рамках потока
  • Bytes — общее количество байт полученных в рамках потока
  • Start time of flow — время начала потока
  • End time of flow — время окончания потока
  • Source port — порт источника
  • Destination port  - порт назначения
  • TCP Flags — TCP флаги
  • IP protocol — номер  IP протокола
  • ToS — тип сервиса
  • Source AS — номер автономной системы IP источника
  • Destination AS — номер автономной системы IP назначения
  • Source Mask  - маска сети IP источника
  • Destination Mask — маска сети IP назначения
  • Padding — отступы для эффективного использования всей длины заголовка
J-Flow v9 и IPFIX дополнительно добавляют информацию об:
  • ICMP type/code
  • IPv6
  • MPLS
  • BGP Peer AS
Но ключевое отличие v9 и IPFIX от v5 в том, что пользователь сам может определить какие поля хочет анализировать посредством создания шаблона. NetStream мы пока не используем в продуктивной системе, но планируем в ближайшее время добавить.

На данный момент AS12389 — это более 300 маршрутизаторов, поэтому для сбора NetFlow развернута инфраструктура коллекторов, которые позволяют на высокой скорости принимать, обрабатывать и писать в базу данных. С учетом того, что по сети передаются терабиты в секунду, то даже при использовании механизма сэмплирования с высоким коэффициентом (>4k) маршрутизаторы генерируют более 300 тыс NetFlow записей в секунду. Сэмплинг позволяет анализировать не каждый прошедший через маршрутизатор пакет, а выборочно в соответствии с проприетарным алгоритмом, который реализуют вендоры в своем оборудовании, что снижает нагрузку на Control Plane или на сервисную карту маршрутизатора.

На коллекторах создаются так называемые Binning Table, в которые мапится NetFlow и собирается статистика по объектам защиты. Под объектом защиты мы понимаем сущность в системе, которая описывается каким-либо из следующих признаков:

  1. IP prefix list (CIDR блоки и группы)
  2. ASN, в том числе с возможностью задания атрибутов AS-Path и community
  3. Сетевые интерфейсы
  4. Flow Filter — логическое выражение, описывающие различные парметры и комбинации полей IP и транспортного заголовка. Например, "dst host 1.1.1.1 and proto tcp and dst port 80".

    Список доступных полей:

    • Average packet lengths
    • Destination addresses
    • Destination ports
    • ICMP codes
    • ICMP types
    • Protocols
    • Source addresses
    • Source ports
    • TCP flags
    • TOS bits
На основании полученной статистики система формирует динамический профиль нормального поведения трафика для объекта защиты. Также вручную можно задать статический профиль в форме пороговых значений для наиболее популярных сигнатур атак. Например, большинство DDoS-атак типа Amplification (NTP, DNS, Chargen, SSDP и.т.д.) отлично детектируются данным методом. В случае отклонения трафика от пороговых значений система генерирует сообщение об аномалии.

В зависимости от процента превышения порога аномалии разделяются на три типа по уровню критичности: low, medium и high. Чаще всего low-аномалии характеризуются всплеском легитимного трафика, например, запущенная маркетинговая компания, в ходе которой пользователей на защищаемый веб-сайт пришло больше, чем обычно. Поэтому специалисты дежурной смены более пристально следят за medium и high аномалиями.

Как происходит фильтрация DDoS-атак?

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

Существует несколько методов фильтрации:

  1. Flow Specification фильтры;
  2. Black-Hole Routing — при оказании AntiDDoS сервиса мы его не используем, поэтому в этой статье уделим совсем немного места;
  3. Интеллектуальная фильтрация в Центрах очистки трафика (ЦОТ).
Всего на сети развернуто два гео-резервируемых ЦОТ в отказоустойчивом варианте на каждой площадке (GR + HA).

Перенаправление осуществляется путем анонсирования внутри AS12389 more-specific маршрута к защищаемому объекту через ЦОТ. Тем самым весь трафик, включая паразитный, стягивается в ЦОТ, где происходит его фильтрация, затем «чистый»  трафик доставляется в сеть клиента. Для того чтобы избежать петель маршрутизации, мы используем механизм доставки трафика через MPLS, передавая маршрутные метки через BGP Labeled-Unicast (механизмам доставки очищенного трафика будет посвящена отдельная статья). Выбрав данный метод, а также единожды настроив свое оборудование, мы исключаем необходимость дополнительных настроек на стороне клиента. Таким образом, любой, кто имеет подключение к AS12389, может быть защищен. Ответный трафик от клиента маршрутизируется по best-path, т.е. без изменения в маршрутизации, и тем самым не попадает в ЦОТ. Поэтому образуется безусловная асимметрия, у которой есть как свои недостатки (возможность в применении определенных контрмер и анализе ответов приложения), так и преимущества (не увеличивает задержку для ответного трафика).

Асимметрия в способе доставке трафика влияет на набор возможных контрмер (правил фильтрации), что заставляет разработчиков системы искать такие варианты определения паразитного трафика и ботов, которые бы основывались только на входящем трафике.

Несмотря на то, что детектирование атак не включает в себя прикладной уровень, фильтрация трафика происходит вплоть до уровня L7 модели OSI, с применением как сигнатурных, так и поведенческих методов.

ЦОТ построен на специализированном оборудовании на базе ATCA-платформ, что позволяет получать высокую производительность фильтрации (включая прикладной уровень) на одно шасси. В последние годы, с появлением таких технологий, как Intel DPDK, HyperScan, сетевых карт 10G и 40G,  а также увеличением количества ядер CPU, появилась возможность достаточно эффективно распараллеливать обработку сетевых потоков, поэтому в ближайшее время мы планируем уходить с ATCA на сервера x86 архитектуры.

Для чего тогда нужен Flow Specification и как его использовать?

Все современные маршрутизаторы операторского класса имеют встроенные механизмы фильтрации вплоть до L4 OSI, которые могут называться у разных производителей по-своему, но в общем случае принято называть Access Control List (ACL). ACL реализован аппаратно в линейных картах и способен фильтровать как транзитные пакеты, так и те, что предназначены самому маршрутизатору на скорости канала или на близкой к ней (line-rate), что делает эту технологию достаточно полезной в случае, если нам нужно срезать паразитный трафик как можно ближе к источнику атаки, т.е. на границе нашей сети. Но т.к. ACL конфигурируется локально на каждом маршрутизаторе, а как мы говорили, у нас их больше 300, то в случае атаки оперативное применение фильтров становиться невозможным. С целью централизованного управления (создание, удаление) ACL был разработан протокол BGP Flow Specification (RFC 5575).

Некоторые операторы предоставляют FlowSpec как сервис своим клиентам, Ростелеком пока это не делает, т.к. активно использует его в собственных целях, а количество правил, поддерживаемых маршрутизаторами, пока еще недостаточно велико. Мы рекомендуем вам обратиться к своему оператору и узнать о наличие подобного сервиса, т.к. FlowSpec реализован в таких проектах, как ExaBGP, что позволяет получить доступный инструмент для установки фильтров на сети оператора и защищаться от атак, направленных на канал, не покупая дорогостоящий сервис. Этот вариант защиты устроит далеко не всех, но может оказаться достаточной и недорогой альтернативой полноценного AntiDDoS сервиса.

Система, которую используем мы, позволяет распространять эти фильтры напрямую из web-интерфейса. Таким образом мы можем настроить тригеры и создавать задания фильтрации из задетектированной системой аномалии автоматически.

Разные производители сетевого оборудования, а также разные версии операционных систем этих производителей могут применять данные фильтры либо ко всем интерфейсам, либо к выборочным, таким образом снижая нагрузку на оборудование, не прогоняя каждый пакет из каждого интерфейса через цепочку правил.

В основном FlowSpec мы используем как первый эшелон фильтрации для тех атак, которые хорошо поддаются шаблонизации до L4: сюда отлично укладываются почти все UDP-based Amplification атаки. Это позволяет не гнать паразитный трафик до ЦОТ, а срезать его как можно раньше, и уже для оставшегося трафика выполнять «тонкую» очистку.

Есть ли место для Blackhole?

В самом базовом случае, в том числе, когда паразитный трафик направлен в сторону ресурса, на котором ничего не опубликовано (а такое тоже бывает), в распоряжении оператора есть возможность отправить весь трафик к этому ресурсу в Blackhole. Для этого на каждом маршрутизаторе задается маршрут, next-hop которого смотрит в discard, т.е. трафик попросту сбрасывается.  При необходимости централизованного распространения Blackhole используют систему route-reflector’ов, трафик к префиксу прописывают на одном из них, и в результате данный маршрут получают все маршрутизаторы.

А что насчет Blackhole community?

Хорошим тоном для оператора является использование различных BGP CommunitiesAttribute для возможности клиента управлять своим трафиком. Одним из таких community является Blackhole Community. Обычно данную информацию операторы публикуют в ремарках базы данных маршрутной информации к своей автономной системе, например, RIPE. Для «Ростелекома» данным community является 12389:55555. Префиксы с данным community принимаются вплоть до /32, при этом с другими – не специфичнее, чем /24.

Взаимодействуют ли операторы между собой в части защиты от DDoS-атак?

В каких-то вопросах — да, в основном это касается включения BGP FlowSpec на своих стыках, но делают это довольно осторожно, т.к. периодически выявляются баги в реализации протокола на оборудовании того или иного вендора.  В остальных случаях, т.к. услуга защиты от DDoS атак все-таки является коммерческой, то в силу конкуренции отсутствуют технические и организационные методы взаимодействия обмена информацией об атаках (такие как IoC).

На базе каких решений строятся операторские системы выявления и защиты от DDoS-атак?

В России наибольшую популярность снискали следующие решения:
  1. Arbor Networks "SP" и "TMS"
  2. Radware "DefensePro"
  3. МФИ Софт  "Периметр"
  4. Иновентика технолоджес "InvGuard"
  5. NSFocus "ADS" и «NTA»
  6. Huawei  "AntiDDoS8000/10000"
Однако не все из представленных выше производителей имеют end-to-end решение  (коллектора NetFlow для анализа трафика и устройства фильтрации) и часто поставляются в паре с другим вендором, например, таким как Genie Networks "GenieATM". А некоторые поддерживают работу с разными решениями для сбора NetFlow. Сравнение представленных решений заслуживает отдельной статьи, поэтому не будем подробно останавливаться на каждом из них.

Чем отличаются операторы от облачных сервисов?

Оператор связи предоставляет сервис только тем клиентам, которые физически подключены к его сети, потому что, как вы уже поняли, собирать статистику по трафику и перенаправить на фильтрацию в ЦОТ оператор может только внутри своей сети. Подключение к услуге по защите от DDoS-атак не требует каких-либо действий со стороны клиента (в нашем случае). Также оператор защищает весь канал, а не отдельно взятые приложения и сервисы, что позволяет получить полноценную защиту для всей IT-инфраструктуры.

На начальном этапе своего развития облачные сервисы брали под защиту только web-сайты. Перенаправление трафика происходило путем изменения А-записи в DNS на IP адрес из IP-пула облака. Очищенный трафик до клиентов доставлялся методом reverse-proxy. Этот метод перенаправления и доставки до сих пор актуален и является наиболее популярным. Но в случае, если у заказчика помимо web-сайта имелись и другие критичные ресурсы (DNS, почтовые сервера и т.д.), которые необходимо было защищать, данный метод не позволял перенаправить в облако весь трафик. Тогда облачные сервисы начали подключать сети заказчиков по VPN, что по сути сделало их оверлейными интернет-провайдерами, которые начали фильтровать не отдельно взятое приложение, а весь канал.

В последнее время операторы также начинают разворачивать на своей сети кластеры с reverse-proxy и WAF, что позволяет брать под защиту клиентов, расположенных вне их сети. Тем самым мы видим, что условная граница между операторами и облачными сервисами начинает стираться.

Пожалуй, не имеет большого смысла сравнивать сферического оператора со сферическим облаком, т.к. даже последние могут значительно отличаться между собой. Например, одни разрабатывают систему самостоятельно, вторые строят на базе готовых промышленных решений различных вендоров, третьи имеют распределенную по миру сеть ЦОТ, подключенных к разным upstream операторам, четвертые имеют один или несколько ЦОТ на территории одной страны с подключением к одному из местных операторов связи, пятые требуют обязательной установки сенсоров на площадке заказчика, шестые специализируются только на web-трафике. Данную тему мы постараемся раскрыть в своих будущих статьях.

Подводя итоги, как мы увидели выше, для оператора связи характерны следующие черты:

  • вследствие своего размера оператор связи имеет возможность «получить» большое количество трафика для фильтрации;
  • большому оператору связи его архитектура позволяет фильтровать на входе в сеть;
  • после первоначальной фильтрации поток «грязного» трафика становится гораздо меньше, и его уже можно анализировать в ЦОТ;
  • качество фильтрации зависит от ряда параметров, среди них основные —  это возможности системы фильтрации и опыт NOC/SOC;
  • оператору связи, если клиент уже пользуется его услугами, зачастую проще и быстрее подключить его на защиту и начать фильтрацию трафика.
В заключение хотелось бы сказать, что наша компания с 2008 года занимается развитием инфраструктуры по анализу трафика и защиты от DDoS-атак, за это время мы несколько раз модернизировали подходы как в части сбора аналитики, фильтрации трафика, доставки очищенного трафика, так и реализовали дополнительные опции, такие как CloudSignaling. В следующих статьях, рассказывая об используемых нами технологиях, мы обязательно покажем ретроспективу и раскроем причины, которые управляли нами при выборе пути развития.

habr.com


Смотрите также