Недавно на Хабре была статья о внедрении URL фильтрации «Ростелекомом» (РТК). Так случилось, что мы предлагали им решить эту задачу года полтора назад и год назад сделали решение, которое прошло все тесты и которое «Ростелеком» готов был включать. К тому моменту лавка наша выпала из милости, ну да это не вопрос техники. Посему все изложенное далее – это детали предложенного нами решения. Что точно внедрят, бог весть.
Начать видимо стоит с 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 закрыл для внешних разработчиков доступ к модулям, дает четкий ответ на этот вопрос, но нас тогда еще мучили сомнения.
Что касается стоимости, то из того миллиона, о котором идет речь, больше половины составляли серверы, так что большой прибыли на софте там не планировалось.
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 закрыл для внешних разработчиков доступ к модулям, дает четкий ответ на этот вопрос, но нас тогда еще мучили сомнения.
Что касается стоимости, то из того миллиона, о котором идет речь, больше половины составляли серверы, так что большой прибыли на софте там не планировалось.