null

Фильтрация трафика, запрещённого Роскомнадзор

В последнее время ужесточились требования к провайдерам и поставщикам услуг связи в отношении правил обработки сетевого трафика между пользователями и сетью Интернет. 
В частности, повсеместно в эксплуатацию было введено программно-аппаратное средство анализа сетевой конфигурации “Ревизор”, осуществляющее контроль исполнения распоряжений Роскомнадзора. 
Средство, согласно официальной документации, в период 00:00 - 02:00 выполняет проверку доступа ко всем запрещённым ресурсам, а также в остальное время (как показал опыт, ежечасно) выполняет опрос порядка двух тысяч различных ресурсов (включая разрешённые). 
Вместе с тем, в разного рода jabber-конференциях, irc-каналах и группах vk всё чаще начали поднимать вопрос о фильтрации по такому нехилому списку URL-ов и IP-адресов. 
Мы с коллегой занимались тем, что комплексно организовывали сервис фильтрации для одного нашего заказчика. 
Продукт, который получился в ходе разработки/оптимизации/сопровождения наша компания скромно представляет на рынке аналогов; а пока я бы хотел осветить основные принципы фильтрации в целом.

Начать, думаю, следует с того, что фильтрация магическим способом выполняться не может. 
Сейчас многие провайдеры с целью снижения нагрузки реализуют неэффективные и “легко обходимые” алгоритмы фильтрации, включая, например, отправку TCP RST или типа того. 
Нам же хотелось реализовать фильтрацию, обход которой не будет таким тривиальным, как большинство существующих. 
А значит, надо делать честную и полноценную фильтрацию. 
Следовательно, в решении будет использоваться прокси сервер, анализирующий HTTP заголовки и умеющий перехватывать HTTPS. 
Честно говоря, с последним вообще мутка-мутная, потому как HTTPS, как известно, задуман для избежания MITM и при фильтрации будет показывать сообщения о неправильном сертификате. 
Поэтому нам либо на ёлку залезть, либо не уколоться; вместе – не получится. 
Этот прокси сервер должен быстро проверять запросы на предмет наличия их в списке запрещённых ресурсов. 
Мы рассмотрели несколько кандидатов на это место; оказалось, что правильно порезанный squid вполне справляется с нашей нагрузкой (суммарно в 400 МБит/с). 
Поэтому на первом этапе работы мы минимализировали затраты squid на всё, что не входит в описанные выше требования.

Следующей частью стала задача проверки доступа к ресурсу. 
И тут, увы, функциональность squid недостаточна. 
Испокон веков подобную фильтрацию можно было сделать через url_regex (кстати говоря, как я делал у другого заказчика примерно лет пять назад; но не для Роскомнадзора). 
Но он крайне медленный. 
Есть также и другая возможность – squidGuard; но он тоже не шибко быстрый и подходящий для фильтрации ТОГО, что приходит из Роскомнадзора (например, wildcard url-ы). 
Поэтому проще всего оказалось написать собственное решение, ориентированное и на фильтрацию HTTPS, и на IDN, и на wildcard. 
А заодно и приводящее список от Роскомнадзора (на текущий момент около 74 тысяч записей) в вид, позволяющий быстро определять наличие проверяемого URL в списке; а не линейно обходить каждый запрещённый URL. 
Кроме того, как оказалось, в squid завезли свежий и более быстрый способ выполнения внешних проверок, который ещё и умеет кеширование и многопоточность, что ещё больше ускоряет его работу. 
Таким образом получился довольно производительный прокси сервер. Медиана задержки на прокси составляет 14,2 мс. У распределения большой коэффициент ассиметрии, это, видимо, объясняется тем, что в одни моменты времени преобладают разрешенные ресурсы, в другие (когда Ревизор начинает DoS-ить сервер) -- запрещённые. Результаты остаются впечатляющими даже с большими URL-ами:

http://www.google-analytics.com/r/collect?v=1&_v=j49&a=1083721000&t=pageview&_s=1&dl=http%253A%252F%252Fblabla%252Fmac%252Ftop100.html&dr=http%253A%252F%252Fsheshoogle.ru%252Fclck%252Fjsredir%253Ffrom%253Dblabla.com%25253Bbla%25252F%25253Bweb%25253B%25253B%2526text%253D%2526etext%253D1360.WCTeDB5flXkdr36KQ7USwV5VizccRsVQ0KwmANBEfcFg1EcYtHWtrZunbZCHRVKnl3V4r8i7YvUYLhfVNvNv-eYGDMXlVkzuZ5w5KKWB1jVKOcABZuZURs3aR4TVqnVua-c7cOF-V-XKr9Oh-BCDsw.1496190ef14ac58d1da4c27a5dabe403019ffafe%2526uuid%253D%2526state%253DPEtFfuTeVD5kpHnK9lio9dp88zwjJi-A9wwjDIux7f8Zuv0g6oZ30w%2526data%253DUlNrNmk5WktYejR0eWJFYk1LdmtxcHE1aHQzNjFGZWlTWU5LQjhHVkxIOWYyWTZvenRlQ0Y4Wl9uUmVHSGNpdGlmcmMyaFNKM3ZwdjlKaXByYzFjMVgzdF80RmJkRUo0RW50dFZ0SnVQMllERXBzVi1RLUEwQjZkNGpvaE1BWWk%2526b64e%253D2%2526sign%253Db5d6c37ca499e56ed5ae0f8cd56ce2dc%2526keyno%253D0%2526cst%253DAiuY0DBWFJ5Hyx_fyvalFNz58xYh-YdhB85VZ6ZIVL1ycU1yulcoj20VGY0p8J3GMipLpBYrReMsmyChilwoXhUDAHJ9Etvm1BpHtaZsP8voPHBrioPV8U280WuQeDhj24fejHYZ_gcwhu4yj9YXUbt93LRHu4acgAkY6bJzUxe44oeRObl7-CgPSPxJzXKeFGLdHSU9sp8gpggVbN1R7Q%2526ref%253DorjY4mGPRjk5boDnW0uvlrrd71vZw9kpdTa2XXnv8b-c4OU8hi_VB6OWQQCo0sUBejvFrQLQKLRaBTKpr3_RVVK0vH5JNwo3ejNtS2Ut4FCK_35j3JjoTb1u884pW0pezdQbyGk...................................vGPYrKOxR5jtKKb9tirEaz2iVO76lHA2JGsX-n6fUMAvW96FwDZemi1sFJwhhN1eALJtQkSmom6vKDFd3HRlSVLoQ8NjH2i9CkimzB9phcUw5T8fqH8YFA81UbsVc9L5fTAASnxfEZrA76hxLQwA4mxmweiaGEcVX467wMzKvWAfVY4P7TAI56QsDZHSKxetFWIbBTWVgfxt-va6tp3OJzC7ainKh7Up2rNZg1wK0DAgGzQ%2526l10n%253Dru%2526cts%253D1489495148341%2526mc%253D3.197159723424149&ul=ru-ru&de=UTF-8&dt=TOP%2520100%2520%25D0%259B%25D1%2583%25D1%2587%25D1%2588%25D0%25B8%25D0%25B5%2520%25D0%25BF%25D1%2580%25D0%25BE%25D0%25B3%25D1%2580%25D0%25B0%25D0%25BC%25D0%25BC%25D1%258B%2520%25D0%25B4%25D0%25BB%25D1%258F%2520Mac%2520OS%2520-%2520%25D1%2581%25D0%25BA%25D0%25B0%25D1%2587%25D0%25B8%25D0%25B2%25D0%25B0%25D0%25B9%25D1%2582%25D0%25B5%2520%25D0%25B1%25D0%25B5%25D1%2581%25D0%25BF%25D0%25BB%25D0%25B0%25D1%2582%25D0%25BD%25D0%25BE&sd=24-bit&sr=1366x768&vp=1264x616&je=1&_u=AEAAAEQAI%7E&jid=149625139&gjid=844450806&cid=901252400.1489495151&tid=UA-4459188-4&_r=1&z=2004775977

Далее мы перешли к сетевому уровню. Очевидно, заворачивать в прокси весь трафик – не комильфо. 
Это и тормозить будет больше, и качество сервиса пострадает из-за HTTPS. 
В частности, перестанут работать все сервисы, требующие валидного сертификата (например, банк-клиент Сбербанка). 
Для решения проблемы мы обратились к ipset-ам, которые, благодаря алгоритмическому улучшению, без остановки осуществляют перенаправление запрещённого/подозреваемого трафика на прокси. 
IP-адреса для ipset-ов формируются в специальном демоне, который анализирует прошлую статистику, опрашивает URL-ы из запрещённого списка, оптимизирует подсети и другими способами приводит к ускорению работы предварительной фильтрации. 
При обновлении Роскомнадзором списка запрещённых ресурсов или при изменении базы IP адресов изменения быстро попадают “в продакшен”.

После того, как мы реализовали всё, что задумали, Ревизор показал отличные результаты, а сама система оказалась производительной и не сильно требовательной к ресурсам. 
Мы экономим деньги заказчиков развернув её на green-aware оборудовании и даже внутри виртуальной машины (4 ядра по 3.1 GHz и 8 Гб ОЗУ)!

korg

 

Коротко о себе

Работаю в компании Tune-IT, администрирую инфраструктуру компании и вычислительную сеть кафедры Вычислительной ТехникиСПбНИУ ИТМО.

Интересы: администрирование UNIX и UNIX-like систем и активного сетевого оборудования, написание shell- и perl-скриптов, изучение технологий глобальных сетей.
Люблю собирать GNU/Linux и FreeBSD, использовать тайлинговые оконные менеджеры и писать системный софт.