Deep Packet Inspection. Сравним парочку дрын…

Posted: 2017-06-22 in IT, Networks
Метки:,

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

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

Если вам интересно — вэлкам, постараюсь рассказать о том, как появились такие системы, какие бывают и что вообще там интересного.

Сама идея обрабатывать траффик на основании данных протоколов высоких уровней родилась достаточно давно, и родилась она прежде всего в недрах корпоративных сетей, где всегда были озабочены сетевой безопасностью. С ростом объемов траффика, пиринговых сетей и прочего, системы DPI пришли и в телеком-индустрию, особенно к мобильным операторам, где пропускные способности и емкости сетей в зоне покрытия конечны по определению, а протоколы типа торрента в состоянии положить каналы любой емкости. Ну и только сильно позже, по мере расчёсывания воспалившейся цензуры (да и желания продать больше полосы, чем реально есть), DPI стали приходить и в прочий телеком разной степени крутости. Применение подобной магии дома остаётся пока уделом редких затейников — топовые роутеры популярностью особой не пользуются.

Самыми простейшими предшественниками систем DPI были решения класса «packet match» — они просто искали заданный шаблон в теле пакета, в особо тяжелых случаях даже без учёта фрагментации.

Примеры: D-Link Packet Content ACL, модуль string для iptables, iptables L7-Filter, первые версии Cisco NBAR.

Самой жуткой является d-link-овский Packet Content ACL. Да, теоретически мы можем задать бинарные маски и шаблоны, и с их помощью даже выделить что-то там из общего траффика, но получаемые правила с шестнадцатеричными магическими числами совершенно нечитаемы уже в момент создания, а попытка через полгода по конфигу понять, что же отлавливает такая строчка — могла убить массу клеток мозга. Да и небольшой лимит числа ACL заставляет применять такие настройки лишь от совсем полной безнадёги.
Кроме того, такие системы не учитывают всё существующее многообразие сетевых протоколов, а любые виды инкапсуляции (mpls, qinq, gre, mac-in-mac и ещё масса других, которые и не вспомнить), равно как и попадание длинного шаблона на фрагментированный пакет, запросто могли поломать всю логику работы и вызывать самые неожиданные и трудно диагностируемые глюки. Даже IPv6 может стать внезапным источником сильной анальной боли. В случае применения поиска по шаблону в том же iptables получается ещё хуже — пропускная способность и живучесть под нагрузкой резко падают, при этом не гарантируя надёжности работы и отсутствия ложных срабатываний. Плюс ровно один — такие штуки могут работать на скорости физлинка даже на самом дешевом железе, но на этом их плюсы заканчиваются. То есть если остро приперло дропнуть строго один вид траффика, и применить такой конфиг временно — вполне допустимо, но постоянно таким пользоваться — ну его нафиг.

Поэтому дальнейшее развитие пошло двумя путями — где надо было дешево, но не быстро (не в промышленных масштабах), стали развиваться надстройки к линуксовому ядру — OpenDPI, bwdpi и им подобные, а где надо было быстро — развитие пошло в сторону специализированного (и крайне дорогого) железа, умеющего обрабатывать сетевой траффик специализированными ASIC-чипами без задержек на огромной скорости и на аппаратном уровне, но в связке с мощными процессорами, поскольку асики конечно очень быстры, но абсолютно не гибки.

В процессе развития IOS появилось нечто среднее — NBAR2:
NBAR2

NBAR-2 штука интересная, но есть далеко не во всех железках, ресурсоёмок и требует отдельного глубокого изучения. Если есть железка, которая его умеет, можно серьёзно улучшить сетевую защиту и вообще много интересного узнать.

В процессе написания этой заметки нарыл огромную презентацию по DPI :
http://static.webra.ru/meeting.intertax.ru/slides/meeting-37-1.pdf
Там есть много интересных моментов.

Ну а мы рассмотрим пару конкретных представителей из семейства аппаратных DPI промышленного применения.

Cisco SCE 2020.
Это одна из первых аппаратных платформ DPI, которая стала широко известна в РФ. Применяется как мобильными операторами, так и провайдерами для умного (или не очень умного) процесса упраления траффиком. Самое главное — задание границ пропускной способности каждому абоненту + назначение приоритетов и лимитов пропускной способности по видам траффика. Очень помогает, когда каналы без особо крупного запаса, а у клиентов начали массовов качаться виндовс-апдейты, новый фильм или какой-нить мега-апдейт для танков. Скайп и IP-телефония особенно позитивно реагируют на повышение приоритетат своего траффика.
Из важного — данная дрына изначально разрабатывалась для нужд корпоративных сетей израильской компанией P-Cube, и только позже пришла в провайдинг, уже когда P-Cube была куплена циской.

Отсюда получилось такое раздвоение сознания при настройке:

— базовые настройки (mgmt-интерфейс, пароли) прописываются в Cisco-подобной консоли, как на классической циско IOS.

— правила шейпинга и собственно DPI-функции настраиваются отдельной написанной на джаве мега-тулзой, и потом сгенерированное нечто заливается в SCE. Для работы SCE потребуется также поднять ВМ с управляющим софтом (SCE Subscriber Manager) и при желании — отдельную ВМ для сохранения статистики и накопления данных с отчетами по траффик-статистике (SCE Reporter).

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

http://sergey-zelyukin.livejournal.com/1785.html

Что можно ещё сказать про SCE из личных впечатлений ?

— Есть функция защиты от DDoS (детектор атак). Настраивается ручками, задается протокол и границы в вида числа-сессий на абонента в интервал времени. Имеет смысл защищать только взломо- или флудо- опасные протоколы типа NTP, SSH, SNMP, Telnet или SSDP. Практическая полезность оказалась вполне себе. Функция позволяет обнаруживать инфицированных терранов в вашей сети, но не при всяких атаках и не всегда. Но реально обнаруживает только достаточно массовые сканирования или брутфорсинг. Точечные атаки не ловит, ясен фиг.

— Антиспам. Заточен был ещё под теплый ламповый нешифрованный SMTP, поскольку анализирует почтовые хидеры. По мере перехода SMTP под TLS-покровительство и применения иных техник спама эффективность данного решения неуклонно снижалась. Ловит только тупые запредельно массовые рассылки нешифрованным SMTP, и ничего более.

— Детект вредоносного ПО в траффике. Очень модно смотрится на презентациях, но на практике — редкостный фуфел. Причин фуфловости этой функции много: во-первых, файлы часто идут шифрованным траффиком. SCE может отличить HTTPS от SFTP, но не может влезть внутрь и понять, что это. Во-вторых, даже если файл пролетит через HTTP, FTP или иной некриптованный протокол, то SCE не имеет возможности делать глубокое эвристическое изучение, как это может себе позволить какой-нибудь касперский на 8-ядерном домашнем компьютере с 16 гб памяти, из которых он сожрал весомый процент =). Остается только сигнатурный анализ, но базы для этого анализа приходят безбожно устаревшими, от тех же антивирусных вендоров, а глядя на разгул ванна-краев, Петь и прочих троянов — можно констатировать, что аверы явно уступают вирусописателям. Да и вирусописатели научились обфусцировать свои поделия так, что их и более серьезные средства не детектят. Короче, это не работает.

— Блокировка по URL. Одно время из-за этой функции SCE даже была рекомендована роскомпозором. Требует очень аккуратной настройки параметра HTTP Inspection, не умеет HTTPS, не умеет в русскоязычные домены, часто не способна обработать длинные или кривые URL.

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

— Срыв шейпера. При большой загрузке может перестать шейпить траффик вообще. Например, для SCE 2020 при работе обоих линков (LACP 2xGBE) критичным является значение 1.7-1.9 Гбит. При подходе к этим значениям вероятность срыва резко возрастает. Сервис у вас, конечно, окончательно не упадёт, но шейпинг может внезапно перестать нормально работать, при отсутствии запаса могут начаться потери пакетов в канале.

— По железу — набор ASIC + три CPU под более сложные задачи. За утилизацией CPU и памяти надо следить — при перегрузке некоторые функции могут перестать работать.

— для стыкования нужны двухволоконные оптические модули на 850 нм и провода вида 2xLC===2xSC.

— Автоматический бэкап настроек затруднён.

— Управляющий софт и интеграция — это пиздец. Все настройки тарифов, политик и сервисов делаются мышкой в джава-софтине. Это приемлимо в корпоративной сети, где политики надо менять редко, но очень криво при использовании у провайдера.
Обязательно надо отдельно где-то вести список id-тарифов из SCE, это важно. Консольно можно залить лишь новый список абонентов и правила URL-блокировок. Для этой радости нужен отдельный FTP-сервер. То есть сперва заходим на SCE телнетом, делаем enable, и даем команды такого типа:

del users.csv
copy-passive ftp://ftpuser:ftppasswd@data-server.local/users.csv overwrite
copy-passive ftp://ftpuser:ftppasswd@data-server.local/rkn.csv rkn.csv overwrite
conf
int line 0
subs imp csv users.csv
sce-url-database import cleartext-file rkn.csv flavor-id 148

Тут users.csv — файл со списком внутренних IP клиентов и их тарифами, rkn.csv — файл с URL для блокировки, 148 — iD сервиса, взятый из интерфейса настройки самой SCE.
В users.csv через запятую указывается id абонента, выделенныая подсеть, iD тарифа из SCE. Если есть возможность, лучше чтобы iD тарифа в биллинге и SCE совпадали — будет сильно проще жить.
Для rkn.csv просто пишем каждый URL на своей строчке.

Если хотим нормальную обработку событий — велкам курить местное Java-API. Читал где-то в документации, что мол «middle-level Java programmer can easy write Java application for API-intercact with SCE/SM», как-то так. Писать что-то на яве, чтобы интегрироваться с DPI — это вне добра и зла однозначно. Да и удобство поддержки такого метода стыкования — под большим вопросом.

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

CKAT.
Эта дрына построена сильно иначе. Берется весьма мощный x86-сервер, туда втыкается оптическая сетевая карта с ASIC-ами и оптическим байпассом, на сервер ставится CentOS 6.9, проприетарный драйвер бешеной сетевухи и комплект отечественного DPI-софта (ПО СКАТ «Севастополь»), главная часть которого — утилита fastdpi.

Поскольку основная управляющая ОС — линукс, а не кастрированная недо-циско-прошивка, да и сам интерфейс управления — в основном построен на конфигах и консольных командах, то управлять и ингрироваться со скатом — намного проще и приятнее, чем с SCE. Никаких ебанутых ВМ с виндовс, никаких Java-програмимздов и никакой ёбли с id-шниками тарифов. Эта дрына разрабатывалась для провайдеров, для двух основных целей — пошейпить траффик и порешать вопрос с гребаным надзором. Тут нет никаких левых обвесов типа «детектора атак», «антиспама», «детектора вредоносного ПО» и прочей неработающей буллшитовой херни.
Управление целиком работает через SSH на ключах, никакой возни с Telnet и FTP тут не потребуется.

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

Ядро, как и положено центоси, палеозойское:
$ uname -a
Linux scat 2.6.32-642... x86_64

Самое первое — аварийный стоп-кран, он же байпасс. Управляется софтово:

bpctl_util all get_bypass
bpctl_util all set_bypass on
bpctl_util all set_bypass off

При bypass = on оптоволокна на сетевухе соединяются напрямую, физически через призмочку, и свет между волокнами пролетает напрямую, не заходя в DPI вообще. Если что-то сломалось настолько, что упало всё что можно и нельзя — первым делом кидаем DPI в байпасс и смотрим, что произошло (если вы в кндр рф — не забудьте погасить линк к «ревизору» на время работ). Нам режим байпасса ни разу не потребовался.

Главная утилита управления называется fdpi_ctrl, и через неё делается если и не всё, то очень многое.

$ fdpi_ctrl -v
FastDPI Ctrl 6.2 (May 16 2017)

Все ключевые конфиги лежат в каталоге /etc/dpi, этот каталог надо бэкапить обязательно.

# ls /etc/dpi/ -1
asnum.bin
fastdpi.conf <— главный конфиг
fastdpi.lic <— открытые данные лицензии
fastdpi.sig <— подпись лицензии
fastpcrf.conf <— настройки клиента Radius
init.d <— пустой каталог для доп-конфигов
No_Money.cfg <— конфиг тарифа для выключенных абонентов
protocols.dscp <— файл приоритетов протоколов
Tariffs <— каталог с конфигами тарифов
whitelist_ip.cfg <— IP, доступные целиком при минусе
whitelist_SSL.cfg <— HTTPS-адреса, доступные при минусе
whitelist.cfg <— HTTP-адреса, доступные при минусе

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

Базовое конфигурирование — dpi.conf.

В fastdpi.lic должны быть прописаны корректные MAC-адреса сетевой мега-карты и серийники, а в fastdpi.conf правильно прописаны адреса сетевых адаптеров из ifconfig:

in_dev=dna0
out_dev=dna1

Немного про основные параметры в fastdpi.conf:

То, ради чего скат покупали в последнее время:

federal_black_list=true
timeout_check_new_bl=30
black_list_redirect=http://abon-inform.local/no-access.php?block=DPI&

Эта опция включает выкачку роскомпозорного списка каждые 30 минут и его применение на DPI. Выкачка идёт с серверов разработчика ската в уже адаптированном для платформы виде, так что для успокоения буйных демонов из ркн выкачивать гребаный блок-лист через сертификат всё равно надо, иначе ркн будет звонить, ругаться и штрафовать за несвоевременную выгрузку реестра. Последняя опция — это адрес внутреннего сервера с заглушкой. Амперсанд в конце указать обязательно — по нему платформа понимает, что надо дописать в адрес другие параметры. Это позволит вывести пользователю дополнительную инфу о запрошенной странице, контактные телефоны ведомства, учинившего непотребное, и прочее.
Хинт: после установки «ревизоров» и прочих приблуд, рвущихся за суицидальными наркотиками, данная страница может получать большое количество запросов, поэтому стоит подумать об nginx и кэшировании.

cp_server=http://abon-inform.local/nomoney.php?
Эта опция говорит, куда редиректить http-клиентов, у которых выключен интернет (CaptivePortal Server). Туда можно напихать ссылок на всякие интернет-банк-клиенты, можно сразу с номером договора для оплаты, будет удобно.

udr=1

Ведение статистики по траффику. Нужно в первую очередь не для сорма, как может показаться (хотя и такое применение теоретически возможно), а для разрешения спорных ситуаций с клиентами, в случае возникновения разногласий по оказанным услугам.


netflow=15 <-- версия протокола нетфлоу
netflow_dev=eth2 <-- статистика отправляется через MGMT!
netflow_timeout=600 <-- больше таймаут - меньше база.
netflow_as_direction=1 <-- номера AS пишем, позволяет оценить, соотношения траффика во вконтакт / ютуб / прочее.

netflow_collector=nfsen-stat.local:9997
netflow_as_collector=nfsen-stat.local:9998

netflow_bill_collector=core-utm5-billing.local:9996
netflow_bill_method=0

netflow_full_collector=nfsen-stat.local:9999

То есть можно отправлять в биллинг только данные по суммарному объёму траффика, без деталей (что во многие разы снизит объём ненужных данных), а в сервер статистики NFSEN — полные netflow-данные о траффике.

Ещё опция из главного конфига:

ad_server=ad-dpi-cutting.local

Задаёт адрес сервера, который будет отдавать подменённую/порезанную рекламу. Про резалку рекламы поговорим позже.

Протокол ipfix для работы расширенных сервисов и сиcтемы DPI-UI:


ipfix_dev=eth2
ipfix_udp_collectors=dpi-ui.local:1500

set_packet_priority=1

ntf_server=abon-inform.local/inform.php?

Последняя опция — адрес сервера для уведомлений клиентов.

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

# cat protocols.txt
http cs0
https cs0
dns cs0
mpeg cs1
bittorrent cs2
DirectConnect cs2
rtsp cs5
h323 cs5
skype cs6
sip cs6
rtp cs6
default cs1

Данный текстовый файлик надо собрать в бинарь для заливки и применить :

cat Protocols_Class.sh
#!/bin/bash

echo " ===== Protocol Classes : =====";
cat protocols.txt

echo " ===== DSCP DPI Data : =====";
cat protocols.txt | lst2dscp /etc/dpi/protocols.dscp

echo " ===== FastDPI Reload : =====";
service fastdpi reload

Команда service fastdpi reload срабатывает буквально за долю секунды и совершенно неопасна. Никакие сессии при этом не рвутся, клиентский траффик не теряется. Это позволяет отмаркировать траффик внутри платформы, и потом задать правила шейпирования по этим классам внутри каждого тарифа.

Для заливки тарифа нам надо сделать следующее:

1). Создать список пользователей тарифа, например такой:

# cat Tarif_113_20Mbit__UserList.cfg
10.45.3.45
10.45.36.48
10.45.36.49

Да, это просто IP-адреса, каждый на своей строчке.

2).Задать параметры шейпирования по классам траффика:

# cat Tarif_113_20Mbit.cfg

htb_inbound_root=rate 20480kbit
htb_inbound_class0=rate 2048kbit ceil 20480kbit
htb_inbound_class1=rate 2048kbit ceil 20480kbit
htb_inbound_class2=rate 8kbit ceil 16384kbit
htb_inbound_class3=rate 8kbit ceil 18432kbit
htb_inbound_class4=rate 8kbit ceil 18432kbit
htb_inbound_class5=rate 256kbit ceil 18432kbit
htb_inbound_class6=rate 2048kbit ceil 18432kbit
htb_inbound_class7=rate 8kbit ceil 18432kbit

htb_root=rate 20480kbit
htb_class0=rate 2048kbit ceil 20480kbit
htb_class1=rate 2048kbit ceil 20480kbit
htb_class2=rate 8kbit ceil 16384kbit
htb_class3=rate 8kbit ceil 18432kbit
htb_class4=rate 8kbit ceil 18432kbit
htb_class5=rate 256kbit ceil 18432kbit
htb_class6=rate 2048kbit ceil 18432kbit
htb_class7=rate 8kbit ceil 18432kbit

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

Обычно стараются выдать повышенный приоритет телефонии и онлайн-играм (в примеры выше выставлена минимальная гарантированная скорость в 10% от общей полосы тарифа), также не обидеть http(s), а на файлообмен пустить то, что от полосы останется. Это позволяет клиенту не выключать торренты и прочие файлозакачки, когда он гамится и трепется по скайпу одновременно.

Ну а теперь надо просто дать команду DPI прочитать параметры шейпера и применить их для заданных IP-адресов:

fdpi_ctrl load --policing Tarif_113_20Mbit.cfg --file Tarif_113_20Mbit__UserList.cfg

Это задаст параметры шейпера.

Для абонентов, у которых баланс кончился, пишем нечто такое:

# cat No_Money.cfg
# No-Money Users Blocked Users shaping with Inet=OFF

htb_inbound_root=rate 512kbit
htb_inbound_class0=rate 64kbit ceil 512kbit
htb_inbound_class1=rate 8bit ceil 8bit
htb_inbound_class2=rate 8bit ceil 8bit
htb_inbound_class3=rate 8bit ceil 8bit
htb_inbound_class4=rate 8bit ceil 8bit
htb_inbound_class5=rate 8bit ceil 8bit
htb_inbound_class6=rate 8bit ceil 8bit
htb_inbound_class7=rate 8bit ceil 8bit

htb_root=rate 512kbit
htb_class0=rate 64kbit ceil 512kbit
htb_class1=rate 8bit ceil 8bit
htb_class2=rate 8bit ceil 8bit
htb_class3=rate 8bit ceil 8bit
htb_class4=rate 8bit ceil 8bit
htb_class5=rate 8bit ceil 8bit
htb_class6=rate 8bit ceil 8bit
htb_class7=rate 8bit ceil 8bit

Оставим минимальные 512 кбит для http(s)+dns, чтобы работали сайты банков при оплате, остально выключим.
Применяем для всех, у кого кончился инет:

# fdpi_ctrl load --policing No_Money.cfg --file no_inet__UserList.cfg

Или только для заданного IP:

# fdpi_ctrl load --policing No_Money.cfg --ip 10.45.56.59/32

Самое интересное — это доп-сервисы. У СКАТ каждый доп-сервис имеет свой номер, и указывая этот номер, можно включать/выключать сервис абоненту или группе абонентов. Включение/выключение инета, редиректы, резалка рекламы, оповещения, ведение статистики — всё это доп-сервисы.

Service #5 — редирект на Captive Portal.
Применяется для оповещения абонентов, что у них кончились деньги на балансе.

Применяем сервис 5 для списка абонентов с выключенным инетом:

fdpi_ctrl load --service 5 --file No_Money_UserList.cfg"

При включении не забываем снять сервис 5:
fdpi_ctrl del --service 5 --file Tarif_113_20Mbit__UserList.cfg

Важно не путать —policing и —service. Первое задает только скорость работы шейпера для того траффика, который может пройти через дпи, а сервисы определяют, какой именно траффик может проходить.

Можно посмотреть список всех тех, у кого включен сервис 5:

# fdpi_ctrl list --service 5 all
Autodetected fastdpi params : dev='lo', port=29000
connecting 127.0.0.1:29000 ...

================================
10.45.82.74 5 (0x10)
10.45.34.15 5 (0x10)
10.46.22.72 5 (0x10)

------------------
total: 3

Для этих IP будут доступны только ресурсы из «белого списка», во всех остальных случаях будет делаться редирект на http://abon-inform.local/nomoney.php? (параметр cp_server= из главного конфига). Что добавить в белый список, то есть оставить доступным даже при выключенном инете ? Как минимум — ключевые сервера (например, если у вас DNS лежит за DPI), сайт компании, интерфейс биллинга, и сайты банков, через которые клиент может оплатить услуги.

Для создания списка исключений идём в /etc/dpi и создаем списки:

# cat whitelist_ip.cfg
10.30.1.2
10.30.1.3

# cat whitelist_SSL.cfg
billing.provider.ru
provider.ru

online.vtb24.ru
online.sberbank.ru
stat.online.sberbank.ru
pscb.ru
*.pscb.ru
webmoney.ru
*.webmoney.ru
http://www.webmoney.ru
login.wmtransfer.com
passport.webmoney.ru
qiwi.ru
*.qiwi.com
qiwi.com
static.qiwi.com
*.elecsnet.ru
1.elecsnet.ru
elecsnet.ru

# cat whitelist_HTTP.cfg
provider.ru

Для HTTPS надо добавить строчки прямо из сертификата, как есть, и прописать все поддомены, задействованные платёжными системами. Теперь применяем написанное на DPI:

cat whitelist_ip.cfg | ip2bin whitelist_ip.dic && mv whitelist_ip.dic /var/lib/dpi/whlistip.bin

cat whitelist_HTTP.cfg | url2dic whitelist_HTTP.dic && mv whitelist_HTTP.dic /var/lib/dpi/whlist.bin

cat whitelist_SSL.cfg | url2dic whitelist_SSL.dic && mv whitelist_SSL.dic /var/lib/dpi/whlistcn.bin

cat whitelist_SSL.cfg | url2dic whitelist_SSL.dic && mv whitelist_SSL.dic /var/lib/dpi/whlistsni.bin

То есть текстовые конфиги сперва конвертируются во внутренний бинарный формат DPI, а потом атомарной операцией переноса mv ставятся в каталог /var/lib/dpi/ под нужным именем. Так что каталог /var/lib/dpi/ тоже имеет смысл добавить в бэкап. Использование mv тут важно, делать надо именно так !

Фильтрацию на captive portal по сертификатам можно выключить:
cp /usr/share/dpi/match_any.bin /var/lib/dpi/whlistcn.bin

Service 9. Статистика.
Должен быть навешен на те адреса, по которым мы хотим получать статистику по траффику в биллинг и nfsen.
NFSEN — стандартный опенсурсный пакет, ставится по мануалу:

http://www.natalink.ru/articles/analiz_statistiki_netflow_pri_pomoschi_nfsen

При большом объёме данных может сжирать изрядно места под базы в /usr/local/nfsen/profiles-data.
Ставить NFSEN однозначно в отдельную виртуалку.

Service 3. Резалка рекламы.

обновляем по крону готовый список, ставим, применяем:

wget vasexperts.ru/upload/adblock.bin -O adblock.bin
mv adblock.bin /var/lib/dpi/adlist.bin
fdpi_ctrl load --service 3 --ip 10.45.66.67
fdpi_ctrl load --service 3 --file advert_haters_ip.cfg

Список маленький, функция носит больше эскпериментальный характер. Зато режет баннеры как на http, так и на https, но именно режет, разрывая соединения.

Service 2. Подмена рекламы.

Опирается на тот же файл adlist.bin, но https-соединения не трогаются, а для HTTP происходит подмена hostname , и реклама отображается уже с нашего сервера (параметр ad_server= в главном конфиге) с сохранением относительного пути и параметров. Очень злодейская функция.

Service 6. Уведомление с редиректом.
Эта функция предназначена для разового уведомления пользователей путем редиректа на заданную страницу.
Сперва создаём профили редиректа:

fdpi_ctrl load profile --service 6 --profile.name Carantin_Port_Info --profile.json '{ \"redirect\" : \"http://abon-inform.local/carantin.php?\", \"check\" : false }'

fdpi_ctrl load profile --service 6 --profile.name Infected_Terrans --profile.json '{ \"redirect\" : \"http://abon-inform.local/virus.php?\", \"check\" : true }'

Список профилей можно посмотреть так:

# fdpi_ctrl list --service 6 profile all
Autodetected fastdpi params : dev='lo', port=29000
connecting 127.0.0.1:29000 ...

================================
type_pofile=1, ref_cnt=55 Carantin_Port_Info { "redirect" : "http://abon-inform.local/carantin.php?", "check" : false } 6 (0x20)
type_pofile=1, ref_cnt=2 Infected_Terrans { "redirect" : "http://abon-inform.local/virus.php?", "check" : true } 6 (0x20)

------------------

Если профиль не указать, то редирект будет сделан на адрес из значения ntf_server главного конфига.

Опция check позволяет проверять успешность переадресации, и влияет на автоматическое снятие сервиса. Если false — снимется по-любому после первого же срабатывания. Если же опция стоит true — то сервис снимется на первом срабатывании автоматически, если DPI увидит запрос к странице-заглушке, прошедший через DPI. Если же запрос будет идти в обход DPI и включена опция check=true , то снимать редирект потребуется дополнительным действием.

Добавление сервиса:

fdpi_ctrl load --service 6 --profile.name Carantin_Port_Info --ip 10.45.59.89

В этом случае первый же HTTP-запрос с адреса 10.45.59.89 будет перехвачен, клиент будет редиректнут на http://abon-inform.local/carantin.php?uid=10.45.59.89&v_tOKen=3…1&UrlRedir=http%3A%2F%2Frequested-url.net%2f

Срабатывание разовое, после срабатывания сервис автоматически снимется, и все последующие запросы пойдут как обычно. Хорошая практика — обработать параметры запроса, чтобы исходный адрес клиенту не пришлось вбивать снова, но при этом важно не создать у себя на странице-информере никаких XSS и прочих уязвимостей от получения нефильтрованных пользовательских данных.

Service 50 Рекламные компании.
Это единственный модуль, который в основном настраивается с дополнительной системы — сервера DPI-UI.
Он позволяет проводить полновесные рекламные компании не только с информированием абонентов, но и с глубоким анализом пользовательских запросов, ведением статистики и прочего.

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

Но надо понимать, что такое вмешательство может быть крайне негативно воспринято клиентами, и стоит очень хорошо подумать, а точно ли оно вам надо.

Есть в СКАТ и модуль DoS/DDoS защиты, способный отбить SYN-Flood. Впрочем, актуальность таких модулей под большим вопросом. Иногда оно помочь сможет, но сейчас DDoS всё чаще идут именно на исчерпание канала, благо интернет-кофейников на 100-мбитном линке всё больше. Так что единственный вариант при более-менее мощном ддосе — это обращение к сетям фильтрации траффика типа Qrator, способным переваривать многие десятки и сотни гигабит говнищща. Хотя и это может не помочь, когда в вас летит полтерабита мусорного траффика в секунду. DPI при такой «отаке» отправится отдыхать вслед за каналами аплинков.

Что ещё там есть опасного ? В новых версиях СКАТ есть возможность писать не только статистику NetFlow / Clickstream / ipfix (по сути детальный анальный досмотр HTTP / SIP траффика + статистика по всему остальному), но и писать сырые дампы траффика в pcap-формате. Это претензия сразу на СОРМ-4, не иначе.

Активное же применение подобного зла приведёт общество лишь к параноидальной шпиономании, и ничему более. Я как-то писал в одном из комментов к своей ранней заметке, почему DPI, несмотря на свои огромные возможности, таки в конечном счёте бессилен против террористов, педофилов и наркоторговцев.

Казалось бы, имея полные дампы траффика и статистику, прослушивая все каналы связи, можно отлавливать общение злодеев чуть ли не в реалтайме. Однако даже террористов, пользовавшихся обычными СМС без всякого шифрования, по этим данным не смогли даже обнаружить, а весь анализ сетевой активности делался уже сильно постфактум после совершения преступления, о предотвращении же не шло и речи, хотя местные разведки спилили на свои «призмы» и прочие «импланты» не один миллиард зелени.

Проблема в том, что даже СМС-ок (а это САМЫЙ халявный к перехвату вид связи) пролетает по сети слишком дохрена, чтобы реагировать на них в реальном времени. Даже если супер-пупер навороченный DPI у мобильного оператора перехватит смс с текстом типа «аллах-бабах пипец вам неверные», и успеет оповестить об этом кого только сможет, то это будет означать лишь то, что до теракта остались считанные минуты, если не секунды — поздняк метаться, называется. Кроме того, криминал ПРЕКРАСНО осведомлен, что связь прослушивается, и часто — сразу несколькими службами в разных странах. На этот случай меры противодействия были заготовлены ещё полвека назад.

И самое главное — самые серьёзные преступления совершаются не в интернете. Наркотики и оружие перевозят не в IP-пакетах, как ни странно.

Чтобы соотнести сетевую активность с чем-то происходящем в реальном мире, и выделить из неё что-то относящееся к криминалу, необходима огромная агентурная работа. Без этого можно собрать лишь кучу информационного мусора, в котором можно утонуть легко и непринужденно, даже несмотря на все биг-даты, анализ траффика, и прочие вещи.

Меня очень забавляет читать, как серьёзные, казалось бы, люди с умным видом вещают о том, что отловив в сетевом траффике слова «путин бомба вокзал», умная железка сразу же сообщит кому надо, найдет все причастные адреса-пароли-явки, и даже сама дело в суд направит. Ага, щаз.

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

Политики дружно выражают озабоченность, а если кровищи хватило журналистам больше чем на неделю — то могут даже выразить сильную озабоченность. Потом начинается шпиономания, беготня с металлодетекторами/собаками/видеокамерами/прослушками/пронюшками/рентген-девайсами и прочими чудо-дрынами, перекапывание статистики вызовов (это если удастся найти останки сим-карты среди останков террориста) под стоны АНБ и прочих о недостатке финансирования на прослушку. Блин, после 11 сентября и так уже пишется всё что можно и не нужно. Куда больше-то ?!

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

Казалось бы, а нафиг тогда писать и DPI-ить все эти тонны траффика ? Есть две, на мой взгляд, правдоподобные версии.

Первая — это желание получить как можно больше компромата на каждого человека. На всякий случай. Вдруг человек известным станет, а у нас тут дамп траффика есть. С запросом вида GET / hot-bdsm-girls.sex В разных юрисдикциях разная информация может иметь совершенно разный вес и влияние. Однако вычленение ЗНАЧИМОЙ информации из сетевого траффика — задача крайне сложная.

Вторая — промышленный шпионаж. Тут особенно подсуетились китайцы, которые хотят иметь прослушиваемый китайским правительством VPN, особенно корпоративный. Китайцы очень активно пасут свой сегмент сети, но корпоратившиков трогают очень аккуратно. Корпоративный VPN крупной компании несет внутри себя просто тонны вкуснятины для конкурентов и промышленных шпионов, и залезть в него под предлогом борьбы с терроризмом — вполне себе привлекательная идея.

Третья же версия, как раз и озвучиваемая публично как единственная, предлагает нам поверить в то, что поиск потерянного фантика со строчками про «бомбу, вокзал и путина» на городской мусорной свалке (а поиск ценных для разведки и служб данных в сетевом траффике именно это и напоминает) якобы улучшит безопасность! Причём даже после того, как всё уже свершилось.

Ярчайший пример.

Брюссель

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

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

И где был хвалёный DPI ? Мигал лампочкой ?

Реклама
- комментарии
  1. […] будет что-то отлавливать в реальном времени. Увы, но скорее всего нет. В настоящий момент та же ФСБ вполне нормально ловит […]