ENOG'14 — влияние блокировок контента на инфраструктуру интернета
Qrator Labs выражает благодарность программному комитету ENOG за разрешение опубликовать на Хабре расшифровку круглого стола, посвященного блокировкам запрещенного к распространению контента. Мероприятие проходило в Минске 9–10 октября. Внимание! Текст длинный, тема чувствительная — просьба отнестись серьёзно к комментарию, который вы захотите оставить под публикацией.
ENOG («Евразийская группа сетевых операторов», в оригинале European Network Operators Group) представляет собой региональный форум интернет-специалистов, занимающихся важнейшими аспектами работы интернета. В рамках форума они имеют возможность обмениваться опытом и знаниями по вопросам, присущим Российской Федерации, странам СНГ и Восточной Европы.
Очередность выступлений и темы докладов:
- Техническая сторона блокировок, Алексей Семеняка — RIPE NCC
- Обзор технической ситуации с блокировками в России — Филипп schors Кулин, DIPHOST
- Проблемы deep packet inspection в транспортных сетях — Артем ximaera Гавриченков, Qrator Labs
- Перспективы блокирования контента в условиях дальнейшего развития технологий интернет — Антон Басков, AB Architecture Bureau
- Административные вопросы блокировок — Юрий Каргаполов, UANIC
Блокировки контента, введение
Юрий Каргаполов (модератор дискуссии):
Давайте, наверное, начнем нашу очень необычную, для ENOG, панельную дискуссию. Эта панель связана с тем, что сегодня привыкли называть «блокировками», которые, уже и мы это чувствуем, влияют на качество наших сетей, на качество предоставляемого сервиса. В конечном итоге блокировки влияют на архитектуру сетей, которые мы строим. Накопился некоторый комплекс вопросов, которые особенно актуальны для России. Но, как оказалось, он стал набирать силу и для Украины, и для Белоруссии и для многих других стран региона. Мы до сих пор не понимаем, как на это реагировать адекватно, а потому данная дискуссия будет посвящена попытке понять как реагировать на блокировки, какие выбрать стратегии и как мы можем адекватно ответить на данный вызов.
Техническая сторона блокировок, Алексей Семеняка, RIPE NCC
Наша задача — понять, как делать блокировки так или как жить с блокировками так, чтобы получить технически минимальный вред. И, надо сказать, что это не новая проблема — это новая проблема только для региона, но в целом в мире эту булочку жевали уже много раз. Первая дискуссия на достаточно высоком уровне появилась более 15 лет назад, система блокировок, скажем, в Великобритании начала работать масштабно примерно примерно в 2003 году.
Вот список международных организаций, которые выпускали те или иные документы: отчеты, рекомендации, обзоры по тому, как блокируется трафик в интернете. Вы видите, что список начинается с Генеральной Ассамблеи ООН — действительно, есть документ Генассамблеи по блокировкам в разных странах мира. Есть Европейский суд по правам человека, есть Совет Европы, есть ОБСЕ.
Есть и интернет-организации: ISoC, IETF, который выпустил целый RFC 7754 по этому поводу, а на подходе еще и драфт. Мягко говоря, эта проблема не остается без внимания. Есть также EFF, естественно, не оставшийся в стороне — у них тоже важные и интересные документы.
Когда я готовился к сессии, я почитал документы еще и тех организаций, которые приведены на слайде — это порядка 800 страниц. Это огромный объем информации, накопленный к настоящему моменту. Огромное количество проблем уже обсуждено в мире — теперь дошла очередь и до нас.
Моя задача сейчас — озвучить те договоренности, на основе которых мы будем работать в этой дискуссии. Некоторые нулевые аксиомы, с которых мы сейчас начинаем и принимаем их как данность.
Более или менее принятая в мире терминология содержит три понятия: блокировка, фильтрация, цензурирование.
Мы будем говорить о блокировках — по статическим признакам. Это отличается от фильтрации, когда трафик, к примеру, P2P-сетей фильтруется по подписям для обнаружения защищенного авторским правам контента. Это также отличается от цензурирования, что, согласно юридическому определению, является «предварительным согласованием информации перед тем, как сделать её публичной». То есть это ограничение свободы распространения информации.
Какие предпосылки есть у этого обсуждения?
Блокировка является распространенной практикой во всём мире. Мало стран, где она отсутствует, и нет ни одной более-менее развитой страны, где бы она полностью отсутствовала. В том или ином виде во всех странах мира есть какие-то ограничения противоправного контента, размещенного в сетевой среде.
Соответственно, на текущий момент сформулированы общие признаки, считающиеся универсальными в международном праве и позволяющие действительно блокировать контент. Враг номер один — распространение детской порнографии, это причина, по которой контент блокируется практически везде. Это разжигание ненависти, розни, призывы к геноциду и так далее. Это также диффамация. В Европе и в некоторых других странах, но в основном в Европе, на уровне Европейского суда следят за нарушением авторских прав.
На нынешний момент, если сформулировать — и это предпосылка, из которой мы исходим в текущем обсуждении, если сформулировать лучшую практику или лучшую ситуацию, которую можно описать, это:
- Система, в которой блокировки происходят не закрытым, а открытым способом, в результате состязательной процедуры, например, в суде. Где другая сторона может оспорить и привести свою аргументацию того, почему блокировка не должна быть реализована.
- Критерии, по которым осуществляются блокировки, сформулированы заранее и соответствуют тому консенсусу, что есть в обществе. Это не давление на общество, это то, что общество сформулировало для себя как приемлемую норму жизни.
- При этом суд опирается на грамотную экспертизу со стороны профессионального сообщества для предотвращения технически опасных действий — тех, которые несут слишком серьезные последствия и исходят из понимания профессиональных компетенций сетевого сообщества. При этом то, что может быть решено до суда, то есть все меры по досудебному урегулированию, принимаются. Есть система договоренностей между потенциальным обидчиком и потенциально обиженным.
Это та система, в которой мы считаем, что некоторые случаи, когда блокировки являются легитимными, разумными и объяснимыми — в такой системе это можно обсуждать и она может существовать, имеет право на жизнь. Еще раз — мы хотели бы видеть интернет полностью нефильтрованным и прозрачным, однако мы живём в той ситуации, которая есть сегодня в мире — мы пытаемся найти точку минимального вреда. Собственно, эта точка сейчас приведена на экране — та ситуация, к которой необходимо стремиться.
Если мы посмотрим на судебную практику ЕСПЧ, который регулярно рассматривает иски по делам о блокировках, что мало известно в нашем регионе, хотя были иски даже из бывшего СССР и в том числе из России. Хорошей иллюстрацией являются два иска граждан Турции против, собственно, Турции, о блокировках.
Один суд был по поводу вещи, описываемой хорошим термином collateral censorship, когда был заблокирован некий нелегальный ресурс, вместе с ним под запрет попали некоторые ресурсы Google. Суд встал на сторону гражданина и попросил Турцию так не делать. Это совсем недавний кейс, опубликованных результатов дела я ещё не видел.
Во втором случае были заблокированы ресурсы, содержащие контент, защищенный авторским правом — музыка. Суд встал на сторону государства и заявил, что данный случай не является нарушением прав человека. То есть по факту принят дифференцированный подход — это та реальность, которой стоит придерживаться.
European Court of Justice (Европейский суд) в 2001 году принял решение о безусловной блокировке ресурсов за нарушение авторских прав. За последние 16 лет он принял огромное количество частных решений о том, что недопустимо проводить чрезмерную блокировку в связи с тем, что таковая нарушает права человека, и это чётко указано.
При этом формулировки ECJ для национальных судов Европы достаточно мягкие, что создает проблемы в интерпретации, потому что не очень понятно, каковы критерии и как не выйти за эти рамки. Вот используемые формулировки: «принимать разумные меры по блокировке», «в достаточной степени затруднять доступ к запрещенным ресурсам» и «не лишать без необходимости возможности доступа к законной информации». То есть формулировки достаточно расплывчатые, но частных определений при этом достаточно много. Скажем так, проблема четких формулировок даже на этом уровне к нынешнему моменту не решена.
Что делать сетевому сообществу? Это не та вещь, которую мы сегодня сможем решить и не та вещь, которую мы можем сегодня обсуждать. Хотя бы потому, что большинство присутствующих в зале не могут официально представлять свою организацию, не имеют права голоса (в смысле совета директоров) или права подписи.
Но безусловно то, что надо искать формы взаимодействия с государством там, где это возможно. Не всегда возможно, но там, где возможно — надо делать.
Формировать профессиональные объединения, чтобы давление было общим. Чтобы точка зрения была интегрированной. И участвовать как на уровне законодательного процесса, так и на уровне участия в судебных процедурах.
Там, где это возможно, а я понимаю, что страны разные, ситуации тоже разные, поэтому абсолютных обязательств быть не может.
Ну и коротко я сейчас пройдусь по мировой практике, объяснив, как это выглядит.
Есть три вектора, которые образуют систему координат:
- Как принимается решение о блокировке?
- Как осуществляется блокировка?
- Какой у блокировки ареал? То есть, среди кого блокируется контент.
Принятие решения.
Самая мягкая ситуация — это когда блокировки не описаны в законодательстве, деятельность в интернете рассматривается как абсолютный аналог офлайновой деятельности и выносится частное решение.
Три разных примера стран, где всё работает именно так, это: Япония, Латвия и Хорватия. Необходимо сказать, что в Латвии очень мало примеров блокировки было — по-моему, лишь единственное решение суда о блокировании фильма, которое ни к чему не привело, потому что фильм был заблокирован в одном месте, но к тому моменту существовал уже примерно в миллионе других мест.
Но у операторов этих стран есть некоторые проблемы с исполнением решений судов, скажем так, потому что никаких правил относительно того, как это делать, единых — нет. Ни на уровне государства, ни на уровне индустрии.
Вторая ситуация — когда блокировки не описаны в законодательстве, но их вопрос решен на уровне профессиональных объединений операторов. Операторы между собой самостоятельно договариваются о том, как они это делают. И на добровольной основе по предоставлению госорганов или судов операторы осуществляют блокирование контента. Так работает практически вся Европа.
Самая продвинутая, в плохом смысле, ситуация с блокировками в, скажем так, традиционной Европе в Великобритании. Но даже там решение принимается ассоциацией, которая была специально для этого создана. Это ассоциация операторов связи, негосударственное объединение.
Следующий тип принятия решения — это когда блокировки есть и они описаны в законодательстве, но осуществляются по решению суда, то есть в результате некой гласной и состязательной процедуры. Примеры приведены на слайде, стоит сказать, что здесь тоже не без «вывертов», например, в Бельгии решение обязательно не только для конечного оператора, но и для транзита. Транзит обязан не передавать какой-то запрещенный контент, что вызывает проблемы. Сетевое бельгийское сообщество уже несколько лет уже пытается объяснить государству, что передачу защищенного копирайтом фильма на транзите отследить практически невозможно — это не работает. Но такой кейс есть и он вызывает определенное напряжение. Хотя, казалось бы, Бельгия достаточно технологически развитая страна с хорошим гражданским обществом.
И последнее — когда блокировки описаны в законодательстве и осуществляются без какой-либо состязательной процедуры. Список стран большой, я специально привёл самые разные страны — как можно видеть, здесь есть Туркменистан, но есть и Эстония, есть Турция, есть Украина, есть Индия. Это тоже, к сожалению, достаточно популярная практика, постоянно вызывающая технические проблемы.
Как работают платформы блокировок? Есть случаи, когда государство требует использовать некоторую централизованную государственную платформу — прогонять трафик через какой-то центр. Яркие примеры: Китай, Саудовская Аравия, Туркменистан.
Есть типовое решение, которое используется основными операторами в стране. Здесь неожиданный пример — Великобритания со системой Clean Feed, которая сначала отлаживалась на British Telecom«е, сейчас ее используют все крупные операторы Великобритании. Как я говорил, при том, что это типовое решение, которое стало стандартом де-факто, ресурсы в этом решении появляются на основе представления общественной организации, в которую входят операторы связи. То есть финальное решение о включении в черный список принимает не государство, а общественная организация.
Или самостоятельная реализация операторами, либо наличие на рынке множества решений и т.д.
Какие механизмы есть?
Самый тяжелый механизм, который недавно использовала Украина массово, то есть большинство операторов блокировало запрещенные ресурсы именно так — это блокировка по автономной системе. То есть все ресурсы автономной системы отправляются в черную дыру.
Следующий способ — это блокировка по IP. Очень популярный способ в России — куча мелких операторов работает именно так. Так работает Турция, так работает Пакистан и многие другие, можно привести разнообразные примеры вроде Бурунди, Конго и так далее. То есть бедные страны Африки тоже очень любят именно такой способ блокирования.
Блокировка на уровне DPI. Здесь возможен разный уровень анализа, начиная с простого анализа host«а в HTTP-заголовке или поля SNI в HTTPS. И кончая достаточно хитрым анализом пакетов. Естественно, чем дальше — тем тяжелее это работает, здесь война меча и щита, потому что все большее количество трафика оказывается зашифрованным, тем не менее Великобритания и Китай идут именно по этому пути.
И достаточно интересный пример — блокировка по DNS. Что это значит? Это значит, что, внимание, только провайдерский DNS направляет пользователя на заглушку. При этом все понимают, что пользователь может прописать четыре восьмерки в хосте DNS«а, и все будет работать — это, скажем так, рассматривается как тот компромисс, который допустим в данном случае. Практически вся континентальная Европа осуществляет блокировки вот таким мягким способом.
И последнее — ареал блокировки.
Это либо все пользователи сети, либо какие-то отдельные группы. Можно посмотреть, как эти группы описаны — например, в Великобритании это группы пользователей «по умолчанию». То есть пользователь может обратиться с просьбой о снятии блокировок с групп ресурсов, куда, для примера, входят вся порнография. Но по умолчанию она отключена — это та система, которая сейчас в процессе внедрения.
В Соединенных Штатах это библиотеки и школы — там есть фильтрация, и достаточно жесткая. Хорватия, Литва, Польша — это только школы. И во Франции был закон о фильтрации в публичных местах, публичного интернета. То есть у себя дома можно получать нефильтрованный интернет, с точностью до тех вещей, о которых я говорил, но в публичных местах интернет должен быть отфильтрован.
На этом моя часть закончена.
Обзор распространенных методов блокирования
Юрий Каргаполов:
Алексей, спасибо за задание некой системы координат относительно того, что происходит с блокировками в мире. Помимо этого, мы бы хотели вам также представить ситуацию, которая происходит в конкретной стране — Российской Федерации. Эту ситуацию мы разберем с помощью Филиппа Кулина, который подробно и детально расскажет о своем опыте в этом вопросе.
Обзор технической ситуации с блокировками в России, Филипп Кулин, DIPHOST
Законодательно установлено, что есть некоторый реестр запрещенных сайтов, который наполняется надзорным органом: Прокуратора, Потребнадзор, суд, правообладатели и так далее. Закон постоянно дополняется, чуть ли не на каждой сессии его обсуждения появляются новые государственные органы, которые могут что-то туда, скажем так, предложить. И всё это предоставляется надзорному органу — «Роскомнадзору», который ведет реестр запрещенных ресурсов. По результатам принятия решения «Роскомнадзор» предоставляет реестр операторам связи — провайдерам, они используют его для блокировок. Отмечу, что закон немножко не техничен, нет объекта блокировки — провайдеры как бы делают это сами, есть какие-то рекомендации и играть можно самим.
Как выглядит реестр запрещенных сайтов? Реестр запрещенных сайтов это набор функций, которые провайдеры по своему усмотрению или рекомендациям регулятора должны выполнить. Соответственно, блокируются URL, домен и маска, то есть шаблон. В то же время есть и статические записи, предоставляющие и доменное имя, и IP. Если протокол шифрованный, то тут есть варианты: или провайдер разбирает server indication, то есть заголовок TLS, или он блокирует по IP — такие провайдеры есть и их достаточно много, или true DNS. Тут я опять же отмечу, что у нас предполагается, что DNS полностью перехватывается и подставляет нужный ответ, если ответ из реестра.
Также есть фильтрация по IP полностью и фильтрация по блокам IP, коих не так много, на самом деле.
Как сейчас принято в общем у операторов связи осуществлять фильтрацию по реестру? По рекомендациям и некоторым собственным соображениям.
Первое — выборочная фильтрация IP из реестра или полный перехват DNS и подстановка ответа, или фильтрация всего канала в разрыв. Канал полностью просматривается и фильтруется. Первые два способа могут по разным причинам комбинироваться.
Как контролируется фильтрация?
С конца 2016 года государство бесплатно для операторов связи предоставляет некий прибор «Ревизор». Это такая коробочка, которая до боли напоминает RIPE Atlas и сделана абсолютно на той же базе. Устанавливается на абонентской стороне, то есть имитирует абонента и контролирует качество блокировки по количеству пропусков. То есть просто считает, сколько раз она смогла достичь какого-то запрещенного сайта.
Побочный эффект такого контроля в том, что эта точка сама берет IP-адреса. Перед проверкой она где-то берет адреса тех ресурсов, которые находятся в реестре. Которые могут совпадать, а могут и не совпадать с тем, что написано в реестре. Опять же, DNS не обязан всем отдавать один и тот же IP-адрес и, соответственно, у операторов связи возникает с этим проблема. Второй проблемный момент заключается в том, что оператор несёт ответственность за неограничение доступа, и любой человек, имеющий доступ к управлению доменом, включенным в список запрещенных ресурсов, может управлять IP-адресами, которые испытают деградацию связи, если блокировка не по IP.
В начале лета было множество с этим связанных проблем, вплоть до блокировок банковских платежей, потому что кто-то указал IP процессинговых центров.
Что мы видим в реестре в цифрах?
Тут много цифр, но главное, что интересно — записей на сегодняшний день более 90 000. Они меняются каждый день, и когда я вчера ночью смотрел, было 92 000, сегодня уже, наверное, 93–94 тысячи. Это всех записей в реестре.
Из них наиболее всего интересны блокировки по маске — это когда провайдер должен бегать за каждым доменом и делать шаблон. 1000 доменов убегают, Роскомнадзор это заметил и применил к ним блокировку по маске. Блокировка по блокам IP — это восемь случаев, и там сервисы Blackberry, заблокированные в реестре.
Токсичность реестра — это то, какая ерунда там бывает. Избыточность реестра 13%, что это такое? Есть блокировка по домену, есть блокировка по URL. И если есть блокировка по домену, то бессмысленно держать URL, потому что провайдер уже не будет на них смотреть — он будет смотреть на весь домен. То есть вот таких лишних записей в реестре 13% — он более пухлый, чем надо.
Уникальных IP в реестре 60 000, но на самом деле реально уникальных IP, которые превращаются в домены — 35 000. Реестр ведется в этом плане крайне неаккуратно и там множество лишней информации, не соответствующей действительности.
Еще из интересного — в реестре содержится URL, который не соответствует никаким стандартам. То есть кто-то от руки написал URL, который как-то надо интерпретировать или никак. Подобных URL в реестре целых 2, но они держатся там уже полгода и они, по-моему, там прописались.
Актуальность реестра. 51% реестра не соответствует действительности — IP-адреса не соответствуют ничему, то есть более половины реестра это полный фарш.
Каждый из вас, подкупив меня или украв мой ноутбук, или сделав предложение, от которого я не смогу отказаться, может получить список доменов, доступных для регистрации, и использовать его для каких-то своих целей, блокируя какие-то произвольные ресурсы в России. Таких доменов больше двух тысяч, прямо вчера я посчитал их специально для нас.
Есть ли убегающие от блокировок домены? Да, такие домены есть. Их больше тысячи, но по факту, когда я посмотрел, что это за домены и почему они убегают, оказалось, что 30% доменов это некие записи CNAME на некие домены в неких CDN, у которых стоит TTL 60 секунд. То есть это не специальное убегание, а в случае с некоторыми CDN зачем-то вот так делают.
И, опять же, это приводит к проблемам у операторов связи, которые вынуждены бегать за этими доменами. Причём никто об этом не знает — я первый человек, говорящий об этом публично.
Соответственно, выводы. Реестр токсичен, неактуален. Если кто-то хочет делать блокировки эффективно, то эффективность страдает. Есть проблема с деградацией связи — есть опыт с банковскими платежами. И чтобы обслуживать реестр, надо затратить силы, время, деньги, но, к сожалению, у надзорного органа таких средств, видимо, нет.
Я описал ситуацию — как ситуация развивается прямо сейчас? За несколько дней до ENOG«а при надзорном органе был создан специальный департамент, который будет заниматься рассмотрением проблем блокировок и ограничения доступа, то есть на это потрачены средства. Сейчас идет активная рекомендация с решением по перехвату всего DNS-трафика и подстановкой соответствующих ответов при совпадении с реестром.
Решение сомнительно — я сразу скажу, это приведет к тому, что будут использовать другой способ. Но все это осознают, включая и надзорное ведомство, поэтому идёт навязывание DPI на всю ширину канала, чтобы не надо было вести в реестре список IP-адресов и актуализировать его. То есть они считают, что это сложно, и перекладывают вопрос обслуживания на провайдеров — это уже звучит в проектах нормативно-правового документа, который уже опубликован.
На этой ноте я передаю микрофон следующему выступающему.
Юрий Каргаполов:
Спасибо, Филипп. Сейчас мы подошли вплотную к техническим решениям, которые предлагаются и о них нам расскажет Артем Гавриченков. Однако, суммируя сказанное к текущему моменту, можно сказать что текущая ситуация не приведет к желаемому властями результату. Это некоторый тупик, о выходах из которого мы попробуем поговорить. Или даже не тупик, а начало пути — предложить решение и далее его обдумывать.
Проблемы deep packet inspection в транспортных сетях, Артем Гавриченков, Qrator Labs
Что мы обсудим в докладе, который сейчас начнется — это вопросы возникающие при разработке и внедрении dpi-решений. То есть цель доклада это формирование, может быть, некоторого чеклиста к оборудованию dpi при его внедрении в транспортной транзитной сети.
Этот доклад построен на опыте. Каком опыте? Я уже восемь лет занимаюсь в числе команды сотрудников построением глобальной anycast-сети, задачей которой является (и это типичная задача) deep packet inspection, это защита от ddos-атак.
Глобальная сеть представляет собой кучу точек присутствия по всему миру: от Северной Америки до Юго-Восточной Азии через СНГ и Европу, где каждая точка присутствия представляет это некое железо, причем железо, которое можно купить на рынке. То есть в этом железе нет ничего кастомного.
Кастомный там software, то самое DPI-решение, которое полностью разрабатывается у нас. Этот процесс идет уже восемь лет, это восемь лет дизайна, от выбора железа до настройки софта. То есть дизайн, исследование, развертывание, в том числе на сетях операторов, в том числе у энтерпрайз-заказчиков.
Главной задачей решения является доступность, во всех смыслах. То есть это и анализ трафика, и мониторинг доступности, работоспособности различных сервисов. В конце концов, это и решение по защите от DDoS-атак.
Что представляет собой решение по защите от DDoS-атак на сегодняшний день?
Это анализ, возвращаясь к термину deep packet inspection, анализ трафика на всех уровнях. От примитивного анализа по, допустим, IP-адресам, портам, до отслеживания потоков трафика, сессий, соединений и вплоть до анализа поведения каждого отдельного пользователя с применением различных инструментов big data.
Что мы вынесли из опыта построения такого решения?
Многие из вас, наверное, слышали про термин который вынесен в заголовок этого слайда. Этот термин звучит как «фильтрация пакетов на седьмом уровне» — именно в такой формулировке его можно услышать много где. В эту формулировку закладывается некая гипотеза, которая закладывается и в архитектуру некоторых решений.
Гипотеза следующая — пакетный анализ, то есть анализ каждого отдельного пакета, это мера, достаточная для определения проблем с трафиком, в том числе на седьмом уровне, то есть с третьего по седьмой. Эта гипотеза появилась, в первую очередь, потому, что она очень удобна для построения.
Нужно понимать, что при построении DPI-решений вы сталкиваетесь с целым рядом проблем. Во-первых, если вы хотите из пакета пересобирать TCP-сессию, TLS-сессию и что-то в ней анализировать, то вам нужно на это дело выделять кучу оперативной памяти, это очень сложная задача с поиском каждого отдельного соединения. Растет вычислительная сложность и это нужно делать на каждый пакет, пролетающий мимо.
Далее, сетевые инженеры, которых в зале много и они не дадут мне соврать, очень не любят решения, которые ставятся в сеть, что называется, «в разрыв». Когда весь трафик гоняется через решение по безопасности, потому что сетевые инженеры прекрасно знают, что все эти решения в большинстве случаев ненадежны. Основная задача сетевого инженера это непрерывная доступность — у него SLA, ответственность перед заказчиками по непрерывной работе сервиса, решение по безопасности негативно влияет на доступность сервера: пока оно перезагружается, пока с ним проблемы, и так далее.
Поэтому в основном решение по безопасности, в частности по DPI, работает на копии трафика — где-то в зеркальном порте. И совсем уж желательно, чтобы оно ограничивалось Netflow/IPFIX и больше ничего не делало.
Это очень удобный подход для построения, проблема в том, что уровневая система сети у нас не просто так. Это не чья-то прихоть, уровневая структура сети принципиально важна для ее функционирования. Сеть работает именно на уровнях, пакет — это единица данных именно третьего уровня, уровня протокола IP. Уже на уровне протокола TCP у нас нет понятия «пакет», есть понятие «сегмент» — это разные вещи, каждый, кто сталкивался с mssclamping, это знает.
А на самом деле, на уровне TCP у нас есть сессии, то есть соединения — выше есть TLS-сессии, еще выше имеется уже просто поток данных седьмого уровня. Поэтому игнорирование уровневой структуры сети делает решение теоретически уязвимым. Делало подобное решение уязвимым даже тогда, когда все в интернете передавалось открытым текстом. Впрочем, почему «теоретически».
Три месяца назад на Github«е появился репозиторий с говорящим названием GoodbyeDPI. Этот репозиторий включает в себя ПО, которое предназначено для установки на windows-машину клиента, то есть любого пользователя сети, которое использует ряд примитивных, умных при этом, но все-таки простых техник, таких как:
- Анализ поля Identification протокола IP
- Фрагментация TCP
- Некоторые упражнения с HTTPS-header«ами, в том числе игра с casing, то есть изменение регистра букв в заголовках и тому подобные вещи.
То есть это очень простая техника, которой оказалось достаточно, причем даже не всего комплекса, а одной-двух комбинированных, для того, чтобы обойти абсолютное большинство DPI-решений, уже внедренных на сетях операторов.
И это когда мы говорим про что-то, передающееся в cleartext, как HTTP-заголовки. Но сейчас 2017 год, и у нас есть протокол HTTPS.
Согласно статистике, запущенный в конце 2015-го года бесплатный провайдер TLS-сертификатов Let«s Encrypt выпустил уже порядка 60 миллионов сертификатов.
Согласно телеметрии Firefox, которую публикует Mozilla Foundation, более 60% — две трети, из всей массы сайтов посещаются пользователями данного браузера исключительно по HTTPS.
Соответственно, концепт фильтрации пакетов на седьмом уровне был уязвим даже тогда, когда у нас был cleartext. С современным уровнем и степенью развертывания TLS и с развертыванием механизмов подобным perfect forward secrecy анализ трафика per packet бесполезен даже для целей, которыми мы занимаемся — защиты от DDoS-атак.
Кстати, что такое PFS. Perfect forward secrecy — это концепт, который реализован в эфемерных разновидностях шифра Диффи Хеллмана. Он работает уже сейчас, он работал и в SSL«е — протоколе, которого уже нет, он работает в TLS«е и он обязателен в новой версии TLS 1.3, которая сейчас готовится к релизу.
Суть perfect forward secrecy в том, что установленное TLS-соединение с шифром, например, эфемерными разновидностями Диффи Хеллмана невозможно расшифровать, имея даже приватный ключ. Это невозможно сделать, если вы смотрите на копию трафика — клиент и сервер согласовывают шифры между собой, приватный ключ здесь используется исключительно как подпись этого шифра, соответственно, с его помощью ничего толком не шифруется и расшифровать это нельзя. Это делает невозможной такую красивую ситуацию, когда мы запис
