Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 54
Сколько печенек вам предложили за переход на тёмную сторону?
Т.е. использовать специальные ДНС (типа семейного фильтра от яндекса) ваши клиенты не могут?
А почему вы не хотите сделать заглушку в стиле
Сайт %domain% заблокирован по ращению власти
Способы как обойти блокировку расписаны вот тут: (ссылки на tor/i2p/мануалы)
Сайт %domain% заблокирован по ращению власти
Способы как обойти блокировку расписаны вот тут: (ссылки на tor/i2p/мануалы)
Потому что они хотят зарабатывать деньги, а не бороться с огромной системой…
Можно и совместить приятное с полезным)
Общая схема работы была выработана следующая:
- iptables на NAT перехватывает все DNS-запросы и перенаправляет их на наш DNS-сервер;
- DNS-сервер держит зоны в том числе и запрещенных ресурсов, не пытаясь их обновить через recursor;
- Эти зоны единственным адресом данных ресурсов указывают адрес сервера с nginx.
Т.е. какую бы зону я не резолвил — получу адрес вашей прокси?
Или адрес вашей прокси я получу только для URL, находящихся в реестре?
Только для доменов URL, находящихся в реестре. Для того и первый скрипт: он поднимает эти зоны (без www, domain.ru и *.domain.ru) в наших DNS, не давая рекурсору разрешать их дальше. Остальные зоны обрабатываются рекурсором как положено.
Т.е. получается, что при блокировке site.com, на котором у меня находится почта, я не смогу пользоваться почтой по smtp, pop3 и imap (т.к. я получил IP вашей прокси)?
Ведь можно же пробрасывать только 80-й порт для данных IP на свою проксю.
Ведь можно же пробрасывать только 80-й порт для данных IP на свою проксю.
Правильно. Должен сказать, что на сегодняшний день подобных случаев (сочетания веб-сервиса и каких-либо еще) в реестре запрещенных сайтов нет. Однако, у нас в кармане лежит и kernel routing+iptables, на которых это вполне возможно реализовать.
Ну однозначно про отсутствие подобных случае говорить нельзя. Возможно на каком-то из серверов реализован port knocking для служебных целей)
Да и вы проверялили\проверяете наличие других сервисов?
Да и вы проверялили\проверяете наличие других сервисов?
Конечно нельзя. Однако, человек использующий port knocking наверняка ознакомлен и, например, с технологиями VPN, которые по закону мы глушить совершенно не обязаны. А самодеятельность в нашем случае совершенно не нужна.
Как только поступит первая жалоба на невозможность использования какого-либо сервиса мы с удовольствием подумаем, как разрешить возникшую проблему.
Как только поступит первая жалоба на невозможность использования какого-либо сервиса мы с удовольствием подумаем, как разрешить возникшую проблему.
на адрес eais.rkn.gov.ru — реестра запрещенных сайтов
А 398-fz, nap и список минюста?
>только с гуглом?
а с не-гугл сайтами указанными в src.chromium.org/viewvc/chrome/trunk/src/net/http/transport_security_state_static.json проблем не будет?
или если сайт уже пользователю сказал что надо HTSTS
что будет с Firefox'ом? судя по blog.mozilla.org/security/2012/11/01/preloading-hsts/ — там HSTS тоже реализован
что будет с приложениями под мобильные платформы где используется certificate pinning?(пример — ABBY Lingvo Dictionaries for iOS, если трафик перехватывается, то по моему опыту — восстановить покупки просто не возможно. сообщение про ошибку сети, даже если сертификат перехватывающего CA установлен на устройство)
что будет с играми вроде SecondLife, где идет трафик в том числе и по https, как на 443-й порт так и на кучу левых (и при этом если делать подмену то диагностика вылетает самая разнообразная, вроде предложения пользователю проверить часы. добавить руками перехватывающий сертификат нельзя)
а с не-гугл сайтами указанными в src.chromium.org/viewvc/chrome/trunk/src/net/http/transport_security_state_static.json проблем не будет?
или если сайт уже пользователю сказал что надо HTSTS
что будет с Firefox'ом? судя по blog.mozilla.org/security/2012/11/01/preloading-hsts/ — там HSTS тоже реализован
что будет с приложениями под мобильные платформы где используется certificate pinning?(пример — ABBY Lingvo Dictionaries for iOS, если трафик перехватывается, то по моему опыту — восстановить покупки просто не возможно. сообщение про ошибку сети, даже если сертификат перехватывающего CA установлен на устройство)
что будет с играми вроде SecondLife, где идет трафик в том числе и по https, как на 443-й порт так и на кучу левых (и при этом если делать подмену то диагностика вылетает самая разнообразная, вроде предложения пользователю проверить часы. добавить руками перехватывающий сертификат нельзя)
Уж как хотите, но вмешиваться в трафик пользователя — свинство. (закон само собой долбанутый, и корпоративные сети совсем другая история)
Мне кажется маловероятным, что подобные сайты попадут в данный реестр. Youtube — да, возможно. С остальными — вероятность невысока. После вдумчивого изучения того, что же действительно находится в данном реестре, я хочу ответственно заявить, что данный ФЗ излишне демонизируют, по крайней мере на сегодняшний день. Например, декларированные в СМИ блокировки grani.ru, kasparov.ru, блог Навального и сайт эха Москвы в нем до сих пор не оказались — все решилось на стороне.
Никто не мешает добавить в список исключений сайты с HSTS, в результате чего данные зоны никогда не окажутся у нас в DNS. С другой стороны — что с ними делать, если они все-же попадут в данный список? Блокировать полностью? Кстати, я всегда хотел знать, как фильтруют подобный трафик покупные DPI решения: не брутфорсят же они, в самом деле, private key сервера?
С точки зрения айтишника, мне и самому не нравится наличие данного реестра как такового. Лично мое мнение, что происходит подмена причины на следствие: преступников не ищут, а делают вид что их нет. Однако, как говорилось в других комментариях, сегодня выбор вариантов у провайдеров неширок — либо мы работаем, соответствуя законодательству, либо платим штрафы, и через некоторое время не работаем, а на наше место приходит Ростелеком с его блокировками по IP.
P.S. Отвечал vikarti, не туда нажал.
Никто не мешает добавить в список исключений сайты с HSTS, в результате чего данные зоны никогда не окажутся у нас в DNS. С другой стороны — что с ними делать, если они все-же попадут в данный список? Блокировать полностью? Кстати, я всегда хотел знать, как фильтруют подобный трафик покупные DPI решения: не брутфорсят же они, в самом деле, private key сервера?
С точки зрения айтишника, мне и самому не нравится наличие данного реестра как такового. Лично мое мнение, что происходит подмена причины на следствие: преступников не ищут, а делают вид что их нет. Однако, как говорилось в других комментариях, сегодня выбор вариантов у провайдеров неширок — либо мы работаем, соответствуя законодательству, либо платим штрафы, и через некоторое время не работаем, а на наше место приходит Ростелеком с его блокировками по IP.
P.S. Отвечал vikarti, не туда нажал.
а что делать пользователям банк-клиентов? для которых передача данных не по HTTPS просто опасна? вы же отнимаете у них один из основных эшелонов защиты?
а что с пользователями сервисов, которые производят HTTPS-авторизацию?
хитрецы, а что с пользователями хабра в вашей сети?
ведь хабраюзеры не так давно вытребовали защищённую авторизацию (HTTPS, да) для защиты реквизитов доступа к хабру
а что с пользователями сервисов, которые производят HTTPS-авторизацию?
хитрецы, а что с пользователями хабра в вашей сети?
ведь хабраюзеры не так давно вытребовали защищённую авторизацию (HTTPS, да) для защиты реквизитов доступа к хабру
Разве хабр и адреса, к которым подключаются банк-клиенты УЖЕ в реестре запрещенных сайтов?
простите, а список эксклудов у вас включет хабр и другие ресурсы?
$excl = array();
$excl[] = 'youtube.com';
$excl[] = 'google.ru';
$excl[] = 'google.com';
$excl[] = 'badsite.org';
или это для примера, а на самом деле у вас в эксклудах пол-инета?
или же это инклуды?
$excl = array();
$excl[] = 'youtube.com';
$excl[] = 'google.ru';
$excl[] = 'google.com';
$excl[] = 'badsite.org';
или это для примера, а на самом деле у вас в эксклудах пол-инета?
или же это инклуды?
Есть небольшой нюанс: запросы к доменным зонам НЕ состоящим в данном списке, будут традиционно обрабатываться dns-recursor и резолвиться как обычно, а не на адрес прокси. Потому данный список исключений предназначен как раз исключительно для вариантов позапрошлой пятницы с youtube.com
так или иначе — это не оправдывает ваш самодельный sslstrip, какие бы благие намерения вы не пропагандировали
и не исключает добавление к нему новых ресурсов «по личной инициативе» или инициативе по звонку из «xxКН»
доверять подобному подключению к Сети просто нельзя by design
это небезопасное, практически незащищеное от инсайда и очень топорное решение
и не исключает добавление к нему новых ресурсов «по личной инициативе» или инициативе по звонку из «xxКН»
доверять подобному подключению к Сети просто нельзя by design
это небезопасное, практически незащищеное от инсайда и очень топорное решение
а вот этот ньюанс (с тем что заворачивается только то что на DNS из реестра)… не очевиден по крайней мере на первый взгляд из статьи. это упрощает ситуацию.
хотя… я правильно понимаю что если в реестр попадет допустим sites.google.com/site/rasamahlab/ (ну — допустим) то на mail.google.com хромом я не попаду через вас?
хотя… я правильно понимаю что если в реестр попадет допустим sites.google.com/site/rasamahlab/ (ну — допустим) то на mail.google.com хромом я не попаду через вас?
и да:
> Волевым решением руководства провайдера домены google.com, google.ru, youtube.com были вынесены в
> список исключений, а еще один из сайтов был внесен в список «исключений наоборот»: по нему есть давнее
> решение блокировать целиком, однако в данном реестре он выгружается только с двумя запрещенными URL
$excl = array();
$excl[] = 'youtube.com';
$excl[] = 'google.ru';
$excl[] = 'google.com';
> Есть небольшой нюанс: запросы к доменным зонам НЕ состоящим в данном списке, будут традиционно
> обрабатываться dns-recursor и резолвиться как обычно, а не на адрес прокси
Кажется, вы уже просто начали лгать.
> Волевым решением руководства провайдера домены google.com, google.ru, youtube.com были вынесены в
> список исключений, а еще один из сайтов был внесен в список «исключений наоборот»: по нему есть давнее
> решение блокировать целиком, однако в данном реестре он выгружается только с двумя запрещенными URL
$excl = array();
$excl[] = 'youtube.com';
$excl[] = 'google.ru';
$excl[] = 'google.com';
> Есть небольшой нюанс: запросы к доменным зонам НЕ состоящим в данном списке, будут традиционно
> обрабатываться dns-recursor и резолвиться как обычно, а не на адрес прокси
Кажется, вы уже просто начали лгать.
Установите powerdns для эксперимента (из репозиториев debian, компилировать не обязательно). Выполните первый скрипт и посмотрите что он делает. Вопрос с ложью должен решиться в пользу того из нас, кто действительно прав. Задача ровно на 15 минут.
>Выполните первый скрипт и посмотрите что он делает
1. Если уж буквоедствовать, то Вы же пишете в статье:
>Первый скрипт я приводить не буду: провайдеры сами знают как получить информацию,
>а обычным пользователям ее разглашать не рекомендуется.
2. Для того, чтобы понимать, что система, перехватывающая DNS-запросы и совершающая MITM для расшифровки пользовательского HTTPS-трафика — небезопасна для пользователей, не обязательно её устанавливать.
1. Если уж буквоедствовать, то Вы же пишете в статье:
>Первый скрипт я приводить не буду: провайдеры сами знают как получить информацию,
>а обычным пользователям ее разглашать не рекомендуется.
2. Для того, чтобы понимать, что система, перехватывающая DNS-запросы и совершающая MITM для расшифровки пользовательского HTTPS-трафика — небезопасна для пользователей, не обязательно её устанавливать.
В статье написано:
Общая схема работы была выработана следующая:
iptables на NAT перехватывает все DNS-запросы и перенаправляет их на наш DNS-сервер;
DNS-сервер держит зоны в том числе и запрещенных ресурсов, не пытаясь их обновить через recursor;
Эти зоны единственным адресом данных ресурсов указывают адрес сервера с nginx.
Дальше написано, что:
По итогам исполнения третьего скрипта мы получаем конфигурацию для nginx, которая проксирует те доменные имена, которые получила. В случае, если адрес заблокирован, то осуществляется безусловный редирект (301) на адрес eais.rkn.gov.ru — реестра запрещенных сайтов.
Согласен, что недостаточно прозрачно написал. Правильной фразой про DNS было бы следующее:
«DNS сервер содержит наши зоны, а также зоны, подлежащие запрету, адрес которых подменен на адрес нашего прокси. Остальные зоны обрабатываются recursor-ом и по запросу возвращаются их действительные адреса».
Т.е. система состоит из двух компонентов:
а) DNS, записи в котором корректируются согласно списку запрещенных ресурсов (в том числе и удаляются, после удаления из этих списков). А кроме записей есть нормальный recursor.
б) nginx, который уже проксирует именно то, что на него придет. Заглушка стоит «на всякий случай», если сайт уже вынесен из реестра, но у клиента его адрес закеширован.
С HTTPS можно поступить либо:
а) закрыть доступ полностью;
б) предоставить доступ, но путем MITM и своего сертификата, в котором честно написано чей он (наш).
Предположим, что вы клиент, который регулярно посещает 2chru.net, на котором заблокировано несколько ссылок. Что вы предпочтете: забыть про 2chru.net или все же его видеть, но с подмененным сертификатом, в котором написано что он провайдерский?
Лично я бы подумал, взвесил риски, и понял, что если мне так уж интересно, то бог с ним с сертификатом и пусть мой трафик читается — я же не делаю ничего противозаконного?
И все же, если действительно буквоедствовать: как работают настоящие, дорогие DPI системы? Как они проверяют HTTPS трафик, если это необходимо? Объясните принцип и мы с удовольствием уйдем от технологии MITM.
Общая схема работы была выработана следующая:
iptables на NAT перехватывает все DNS-запросы и перенаправляет их на наш DNS-сервер;
DNS-сервер держит зоны в том числе и запрещенных ресурсов, не пытаясь их обновить через recursor;
Эти зоны единственным адресом данных ресурсов указывают адрес сервера с nginx.
Дальше написано, что:
По итогам исполнения третьего скрипта мы получаем конфигурацию для nginx, которая проксирует те доменные имена, которые получила. В случае, если адрес заблокирован, то осуществляется безусловный редирект (301) на адрес eais.rkn.gov.ru — реестра запрещенных сайтов.
Согласен, что недостаточно прозрачно написал. Правильной фразой про DNS было бы следующее:
«DNS сервер содержит наши зоны, а также зоны, подлежащие запрету, адрес которых подменен на адрес нашего прокси. Остальные зоны обрабатываются recursor-ом и по запросу возвращаются их действительные адреса».
Т.е. система состоит из двух компонентов:
а) DNS, записи в котором корректируются согласно списку запрещенных ресурсов (в том числе и удаляются, после удаления из этих списков). А кроме записей есть нормальный recursor.
б) nginx, который уже проксирует именно то, что на него придет. Заглушка стоит «на всякий случай», если сайт уже вынесен из реестра, но у клиента его адрес закеширован.
С HTTPS можно поступить либо:
а) закрыть доступ полностью;
б) предоставить доступ, но путем MITM и своего сертификата, в котором честно написано чей он (наш).
Предположим, что вы клиент, который регулярно посещает 2chru.net, на котором заблокировано несколько ссылок. Что вы предпочтете: забыть про 2chru.net или все же его видеть, но с подмененным сертификатом, в котором написано что он провайдерский?
Лично я бы подумал, взвесил риски, и понял, что если мне так уж интересно, то бог с ним с сертификатом и пусть мой трафик читается — я же не делаю ничего противозаконного?
И все же, если действительно буквоедствовать: как работают настоящие, дорогие DPI системы? Как они проверяют HTTPS трафик, если это необходимо? Объясните принцип и мы с удовольствием уйдем от технологии MITM.
ну а у ваших клиентов вы спрашивали, что думают они? просили их взвесить риски?
уверен, что нет
полагаю, что вы взвесили только свои риски и сделали так, чтобы минимизировать
исключительно свои риски и для себя
на одной чаше весов — предписания РКН, на другой — безграмотность большинства пользователей (расчёт на то, что они не поймут, что происходит)
этим вы ничем не лучше Webnames, печально известных тут
задам вопрос — а для своих пользователей вы публиковали информацию о новых фильтрах?
если да, то в каком виде? в прозрачном и понятном или в запутанном и сложном для понимания?
кстати, если не секрет, как называется ваша организация?
очень интересно посмотреть на ваш сайт, спасибо
уверен, что нет
полагаю, что вы взвесили только свои риски и сделали так, чтобы минимизировать
исключительно свои риски и для себя
на одной чаше весов — предписания РКН, на другой — безграмотность большинства пользователей (расчёт на то, что они не поймут, что происходит)
этим вы ничем не лучше Webnames, печально известных тут
задам вопрос — а для своих пользователей вы публиковали информацию о новых фильтрах?
если да, то в каком виде? в прозрачном и понятном или в запутанном и сложном для понимания?
кстати, если не секрет, как называется ваша организация?
очень интересно посмотреть на ваш сайт, спасибо
Утверждение про ложь, было, наверное, слишком эмоционально. Прошу простить благороднейше.
Но всё же обращаю внимание на тот факт, что у вас в описании работы с одним и тем же набором данных…
$excl = array();
$excl[] = 'youtube.com';
$excl[] = 'google.ru';
$excl[] = 'google.com'
… замечены взаимоисключающие параграфы.
Сначала утверждается (в статье), что MITM производится по всем HTTPS-запросам, кроме (цитата):
> а с подмененным сертификатом браузеры их отображать не хотели.
> Волевым решением руководства провайдера домены google.com,
> google.ru, youtube.com были вынесены в список исключений
а потом в комментарии Вы пишете (цитата):
> Есть небольшой нюанс: запросы к доменным зонам НЕ состоящим в данном списке,
> будут традиционно обрабатываться dns-recursor и резолвиться как обычно,
> а не на адрес прокси.
Если осмыслить вышенаписанное, то выходит, что вы противоречите сами себе.
Но всё же обращаю внимание на тот факт, что у вас в описании работы с одним и тем же набором данных…
$excl = array();
$excl[] = 'youtube.com';
$excl[] = 'google.ru';
$excl[] = 'google.com'
… замечены взаимоисключающие параграфы.
Сначала утверждается (в статье), что MITM производится по всем HTTPS-запросам, кроме (цитата):
> а с подмененным сертификатом браузеры их отображать не хотели.
> Волевым решением руководства провайдера домены google.com,
> google.ru, youtube.com были вынесены в список исключений
а потом в комментарии Вы пишете (цитата):
> Есть небольшой нюанс: запросы к доменным зонам НЕ состоящим в данном списке,
> будут традиционно обрабатываться dns-recursor и резолвиться как обычно,
> а не на адрес прокси.
Если осмыслить вышенаписанное, то выходит, что вы противоречите сами себе.
за такое отвратительное и топорное техническое решение искренне желаю вам поскорее растерять побольше клиентов
хотя бы для того, чтобы вы помнили, что содержит вашу организацию совсем не Роскомнадзор, а те, над кем вы ставите свои эксперименты
хотя бы для того, чтобы вы помнили, что содержит вашу организацию совсем не Роскомнадзор, а те, над кем вы ставите свои эксперименты
Я так понимаю в заголовке речь всё же про 139-ФЗ, а не про 193-ий?
Спасибо, поправил.
Да и не только 139-ый.
Вы же еще и 187-ой исполняете («антипиратский») и 398-ой («политический»).
А скоро и новое))
Вы же еще и 187-ой исполняете («антипиратский») и 398-ой («политический»).
А скоро и новое))
Интересно, а за перехват и изменение [DNS] трафика пользователи могут пожаловаться куда-нибудь?
Кстати, да. Получается, пользователи не могут пользоваться тем же DNS от Яндекса.
Мне больше интересно использование моего личного DNS с плюшками и чаем, может я хочу, что бы у меня лично (и моих домочадцев) по адресу microsoft.com открывался сайт kernel.org (например) и для этого я использую DNS сервер на своей VDS'ке (конечно логичнее для этого использовать DNS дома, но это не суть), да и еще могу придумать тысячи случаев, когда мне хочется обратиться к конкретному DNS-серверу (например узнать, почему у половины клиентов моего сайта сайт не работает).
Ну и наконец может я вообще организовал себе VPN over DNS (Такая же уже есть, правда?) или на 53й порт повесил на своей VDSке другой сервер (зачем? потому что могу, вот почему).
Ну и наконец может я вообще организовал себе VPN over DNS (Такая же уже есть, правда?) или на 53й порт повесил на своей VDSке другой сервер (зачем? потому что могу, вот почему).
Перехватывать DNS — совсем не путь самурая.
Я конечно понимаю, что иначе нормально блокировать не получится и вообще выбора не оставили, но как-то это уж очень неправильно. Да и криво местами. Когда список станет большой — будут вылезать проблемы с другими протоколами пачками.
Кстати — есть, у того же гугла, некоторые хитрости, например для chromecast — там вшиты DNS 8.8.8.8 / 8.8.4.4 и в редких случаях ответ не очень соответствует реальному DNS (так надо).
Я конечно понимаю, что иначе нормально блокировать не получится и вообще выбора не оставили, но как-то это уж очень неправильно. Да и криво местами. Когда список станет большой — будут вылезать проблемы с другими протоколами пачками.
Кстати — есть, у того же гугла, некоторые хитрости, например для chromecast — там вшиты DNS 8.8.8.8 / 8.8.4.4 и в редких случаях ответ не очень соответствует реальному DNS (так надо).
Согласен по обоим пунктам.
Был и второй вариант, который соответствует рекомендациям Роскомнадзора (да-да, есть и такие): разрешать имена запрещенных доменов в адреса, а весь трафик на эти адреса адреса заворачивать в «сегмент анализа сети», чем в нашем случае является наш же прокси. Возможно, мы на данный вариант и перейдем: будем заворачивать только трафик по портам (согласно схеме либо порту из URL) и адресу. Но с HTTPS другого варианта просто мы просто не видим, к сожалению.
Был и второй вариант, который соответствует рекомендациям Роскомнадзора (да-да, есть и такие): разрешать имена запрещенных доменов в адреса, а весь трафик на эти адреса адреса заворачивать в «сегмент анализа сети», чем в нашем случае является наш же прокси. Возможно, мы на данный вариант и перейдем: будем заворачивать только трафик по портам (согласно схеме либо порту из URL) и адресу. Но с HTTPS другого варианта просто мы просто не видим, к сожалению.
ещё хотел добавить с позиции «лягушки», что не хочу обсуждать, как лучше варить лягушку
я хочу, чтобы огонь выключили, а лягушку отпустили назад в леса-поля-болота
я хочу, чтобы огонь выключили, а лягушку отпустили назад в леса-поля-болота
Блокировать весь https-трафик на сайты с запрещёнными страницами и то лучше, чем подменять сертификат. Можно перенаправлять на страницу, на которой рекомендовать заходить по http.
Автор, пожалуйта, дайте ссылку на вашу страничку
То, что вы сделали для пользователей — отвратительно.
То. что вы прикрываете свой заработок отношениями с «коллегой с четырьмя детьми», вдвойне мерзко.
То, что вы наговорили мне в личке — отвратительно втройне.
То. что вы прикрываете свой заработок отношениями с «коллегой с четырьмя детьми», вдвойне мерзко.
То, что вы наговорили мне в личке — отвратительно втройне.
Парни, разве вы не понимаете, что этот вредный мануал будет раскопирован и применен тысячами мелких админов?
а потом эти ограничения распространятся и на вас и на меня и на всех остальных. и это будет считаться нормальным поведением?
а потом наш интернет мы будем вынуждены защищать?
куда мы катимся со всеми этими толерантными ограничениями?
нас уже плющат и прессуют по всем фронтам.
а потом эти ограничения распространятся и на вас и на меня и на всех остальных. и это будет считаться нормальным поведением?
а потом наш интернет мы будем вынуждены защищать?
куда мы катимся со всеми этими толерантными ограничениями?
нас уже плющат и прессуют по всем фронтам.
server_name badsite.com *.badsite.com
А насколько корректно использовать тут маску? В реестре ведь указаны вполне конкретные доменные имена.
Однако, у нас в кармане лежит и kernel routing+iptables, на которых это вполне возможно реализовать.
Вот только ip-адрес получателя будет потерян.
Слушайте, а почему редирект 301? Он же кэшируется намертво. А из реестра могут же и убрать. Почему не 302?
server_name badsite.com *.badsite.com;
location ~* \Q/forum/viewforum.php\E* {
if ($args ~* "\Qf=6\E*") {
…
} #args
}
Всё бы хорошо, но такое правило сработает и на, например, badsite.com/pupkin/own/private/forum/viewforum.php?biff=667
Насколько я помню, HAProxy хорошо подходит для высоких нагрузок и может работать в режиме прозрачного прокси. Можно было бы в iptables перенаправлять на HAProxy только определённые порты определённых IP, а DNS не трогать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Закон №139-ФЗ: взгляд со стороны небольшого провайдера