Книги: "Создание сайтов" - "Доменные войны". Защита информации: техническое описание TLS, тестовый сервер TLS 1.3. Ресурсы: LaTeX
Блокирование по IP-адресу – проще некуда
Кстати, для провайдера, заблокировать доступ к сайту по IP-адресу – это самое простое решение, потому что IP-маршрутизация большей частью работает, примерно, на аппаратном уровне. То есть, очень быстро и прозрачно. А вот блокирование на уровне прикладных протоколов (DNS, HTTP), позволяющее сделать блокировку более избирательной – это уже сильно другая задача. Тут требуется анализ содержимого пакетов, а не заголовков, который тянет за собой дополнительное ПО и заметные вычислительные мощности.
Хотя, надо заметить, блокирование по прикладным протоколам математически выглядит куда более правильным – ведь для чтения сайтов используют именно их. В плане реализации особенно занимательно выглядит инспектирование HTTPS, да. Ну а верный способ построить эффективную систему, это строгий контроль пользовательского ПО, служащего для просмотра Интернета.
Адрес записки: https://dxdt.ru/2012/07/02/4976/
Похожие записки:
- Десятилетие DNSSEC в российских доменах
- Браузеры и перехват TLS без участия УЦ
- Трафик на тестовом сервере TLS 1.3 и ESNI
- Дирижабли в 2008 году
- Про цепочки, RSA и ECDSA
- Симметричные ключи, аутентификация и стойкость в TLS
- DNS как транспорт для сигналов и данных
- S/MIME-сертификаты ТЦИ
- "Пасхалки" в трафике
- Возможное обновление алгоритмов DNSSEC в корне DNS
- Вращение Солнца и соцопросы
Комментарии читателей блога: 4
1. 2nd July 2012, 13:07 // Читатель jno написал:
чёй-то инспекция HTTP-запроса не выглядит особенно затратной…
и, при некотором желании, она ещё и “проблемы” (прозрачных) прокси лечит.
2. 2nd July 2012, 15:22 // Читатель sarin написал:
не особенно затратной по сравнению с чем? инспекцией IP?
что проще сравнить: 4 байта, или строки произвольной длинны? инспекция HTTP-запроса может и не выглядит затратной когда проводится вэб-сервером который этот запрос и должен обрабатывать. а когда нужно на лету проверять одновременно миллионы пакетов то всё становится немного по-другому.
3. 2nd July 2012, 20:27 // Читатель jno написал:
Понятно, что проще сравнить двоичное число!
Вопрос не в этом.
Просто (да, “на глаз”) доступные вычислительные мощности выглядят _достаточными_ для такого рода фильтрации on the fly.
Пусть не на бэкбонах (там, вроде, и не надо), но на уровне ISPшных серверов доступа – вполне.
Опять же, законодатель будет ставить раком в первую очередь “розничных” ISP, а не “магистральных” (у которых нет никаких юридических отношений с гражданами, которым чего-то там запрещено, но есть договора межоператорские, где никакой фильтрации не предусмотрено).
Даже если эти “розничные” и “магистральные” – разные отделы одной конторы :)
4. 2nd July 2012, 20:36 // Читатель jno написал:
А ещё можно сделать “национальный NAT”, практикуемый уже какими-то арабами, чтобы “белых” адресов юзера не получали в принципе. Вот и будет сразу всё в одном стакане, включая “рубильник”.
Конечно, есть туннели-випиэны всякие, да. Но 98% юзеров это дело накроет вполне.