Пользователь
0,0
рейтинг
18 марта 2014 в 13:17

Администрирование → Закон №139-ФЗ: взгляд со стороны небольшого провайдера из песочницы

Пару недель назад к моему хорошему знакомому (по совместительству системному администратору в городском, но не очень крупном провайдере) коллеги из Роскомнадзора поставили на вид, что по IP он, конечно, блокирует запрещенные сайты, но по URL или доменным именам совершенно нет, а при смене IP адреса запрещенным ресурсом тот снова начинает открываться. Товарищ пожаловался мне на судьбу, заодно намекнув, что один раз лично его уже штрафовали за невыполнение требований печально известного № 139-ФЗ.


Схема подключений у данного провайдера следующая:
  • Все пользователи (кроме купивших статический IP) находятся за NAT;
  • NAT реализован как обычный forwarding на не менее обычном debian;
  • На каждом NAT есть не менее обычный iptables;
  • Есть два своих DNS-сервера, работающих на том же debian и PowerDNS.


После некоторых раздумий, а также гугления информации о layer 7 filtering на коленке, гугл нам сказал, что подобные вещи — прерогатива дорогого оборудования, a l7-filter для iptables перестал развиваться достаточно давно. После этого мы начали думать в сторону прокси-серверов. Со squid в промышленных масштабах ни один из нас не работал, однако было довольно много экспериментов с nginx — очень мощным продуктом Игоря Сысоева.

Общая схема работы была выработана следующая:
  • iptables на NAT перехватывает все DNS-запросы и перенаправляет их на наш DNS-сервер;
  • DNS-сервер держит зоны в том числе и запрещенных ресурсов, не пытаясь их обновить через recursor;
  • Эти зоны единственным адресом данных ресурсов указывают адрес сервера с nginx.


Понятно, что конфигурацию nginx и список зон запрещенных ресурсов необходимо обновлять динамически: в требованиях Роскомнадзора указана частота 3 раза в сутки. Также очевиден и недостаток: доступ по HTTPS придется либо ограничивать, либо разрешать, но с использованием собственного сертификата, иначе трафик через наш nginx будет шифрован и свою основную функцию (фильтрацию) он осуществлять не сможет. Во втором варианте неизбежна ругань браузеров клиентов на неправильный сертификат. Более того, если под блокировку попадет адрес из списка доменов google, а у клиента установлен google chrome, то клиента на данные сайты не пустит в принципе. Но других наколенных вариантов мы в ограниченное время изобрести не смогли. Итак, что у нас получилось:
  1. Скрипт, загружающий список запрещенных сайтов (обычный XML, отдается SOAP-сервисом после соответствующего запроса. Необходима авторизация с помощью сертификата, уникального для каждого провайдера).
  2. Скрипт, загружающий список зон в DNS-сервера.
  3. Скрипт, создающий необходимую конфигурацию для nginx.


Первый скрипт я приводить не буду: провайдеры сами знают как получить информацию, а обычным пользователям ее разглашать не рекомендуется.

Второй скрипт (SQL для работы с базой PowerDNS):

USE pdns;

create temporary table if not exists dump(
        domain text
);

TRUNCATE TABLE dump;

load data local infile '/opt/zapret/dump.xml' into table dump
LINES STARTING BY '<domain>' TERMINATED BY '</domain>'
(@tmp)
SET domain = ExtractValue(@tmp, '/');

create temporary table if not exists locked(
        domain varchar(767) primary key
);

TRUNCATE TABLE locked;

INSERT INTO locked
SELECT DISTINCT domain FROM dump;

create temporary table if not exists locked1(
        domain varchar(767) primary key
);

TRUNCATE TABLE locked1;

INSERT INTO locked1
SELECT * FROM locked;

DELETE FROM l
USING locked l
INNER JOIN locked1 l1 ON l.domain=SUBSTR(l1.domain from 5);

UPDATE locked
SET domain=SUBSTR(LCASE(domain) FROM 5)
WHERE LEFT(LCASE(domain), 4) = 'www.';

DELETE FROM locked
WHERE domain LIKE '%youtube.com'
OR domain LIKE '%google.com'
OR domain LIKE '%google.ru';

create temporary table if not exists old_locked(
        id int,
        domain varchar(767) primary key
);

TRUNCATE TABLE old_locked;

INSERT INTO old_locked
SELECT DISTINCT d.id, d.name as domain
FROM domains d
INNER JOIN records r ON d.id=r.domain_id
WHERE r.content='1.2.3.4' AND d.name NOT LIKE '%provider.ru';

INSERT INTO domains (name, master, last_check, type, notified_serial, account)
SELECT n.domain, NULL, NULL, 'NATIVE', NULL, NULL
FROM locked n
LEFT JOIN old_locked o ON n.domain=o.domain
WHERE o.domain IS NULL;

INSERT INTO records (domain_id, name, type, content, ttl, prio, change_date, ordername, auth)
SELECT d.id AS domain_id, d.name, 'SOA' as type, 'ns.provider.ru dns.provider.ru 2014022701 28800 7200 604800 86400' as content, 86400 as ttl, 0 as prio, 1393508792 as change_date, '' as ordername, 1 as auth
FROM domains d
INNER JOIN locked l ON d.name=l.domain
LEFT JOIN old_locked o ON d.name=o.domain
WHERE o.domain IS NULL;

INSERT INTO records (domain_id, name, type, content, ttl, prio, change_date, ordername, auth)
SELECT d.id AS domain_id, CONCAT('*.', d.name), 'A' as type, '1.2.3.4' as content, 86400 as ttl, 0 as prio, 1393508820 as change_date, '' as ordername, 1 as auth
FROM domains d
INNER JOIN locked l ON d.name=l.domain
LEFT JOIN old_locked o ON d.name=o.domain
WHERE o.domain IS NULL;

DELETE FROM r, d
USING records r
INNER JOIN domains d ON r.domain_id=d.id
INNER JOIN old_locked o ON d.name=o.domain
LEFT JOIN locked l ON o.domain=l.domain
WHERE l.domain IS NULL;



После исполнения данного скрипта надо не забыть выполнить
# pdnssec rectify-all-zones

для того, чтобы powerdns осознал изменения.

Третий скрипт (формирование списка blocked):
<?php

$xml = simplexml_load_file ('/opt/zapret/dump.xml');

$dirty = array();

$excl = array();
$excl[] = 'youtube.com';
$excl[] = 'google.ru';
$excl[] = 'google.com';
$excl[] = 'badsite.org';

foreach($xml as $node) {
	if( strlen( (string)$node->domain )>0 ) {
		$parsed = parse_url((string)$node->url);
		if( $parsed!=false ) {
		    if( isset($parsed['path']) ) {
			if( isset($parsed['scheme']) )
				$scheme = $parsed['scheme'] . "://";
			else
				$scheme = "http://";

			if( isset($parsed['port']) ) {
				$port = ':' . $parsed['port'];
				if( $scheme=="https://" ) $port = $port . " ssl";
				}
			else {
                                if( $scheme=="https://" ) $port = ":443 ssl";
				else $port = ":80";
			}

			$port = $port . ";";

			$domain = (string)$node->domain;

			if( strcmp(strtolower(substr($domain, 0, 4)), 'www.') == 0 ) $domain = substr($domain, 4);

			if( isset($parsed['query']) )
				$que = $parsed['query'];
			else
				$que = '';

			$que = str_replace('\\E', '\\E\\\\E\\Q', $que);
			$que = '\\Q' . $que . '\\E';
			if ( strcmp($que, '\\Q\\E')==0 )
				$que = '';


			$path = $parsed['path'];

			$path = str_replace('\\E', '\\E\\\\E\\Q', $path);
			if ( strcmp($path, '/')<>0 ) {
				$path = '\\Q' . $path . '\\E';
				if ( strcmp($path, '\\Q\\E')==0 )
					$path = '';
			}

			$keys = preg_grep('/' . $domain . '/', $excl);

			if( count($keys)<1 )
				$dirty[] = array('domain'=>$domain, 'url'=>(string)$node->url, 'loc'=>$path, 'query'=>$que, 'port'=>$port, 'scheme'=>$scheme);
		    }
		}
	}
}

// Т.к. он забанен весь, а в списке фрагментарно
$dirty[] = array('domain'=>'badsite.org', 'url'=>'badsite.org', 'loc'=>'/', 'query'=>'', 'port'=>':80;', 'scheme'=>'http://');

$sort_func = function($obj_1, $obj_2) {
    	return strnatcasecmp($obj_1['domain'] . $obj_1['url'], $obj_2['domain'] . $obj_2['url']);
};

$domains = array_unique($dirty, SORT_REGULAR);

usort($domains, $sort_func);

$old_domain = "";
$old_loc = "";
$wasroot = false;
$alldomain = false;
$allloc = false;

foreach($domains as $node) {
	$domain = $node['domain'];
	$url = $node['url'];
	$loc = $node['loc'];
	$query = $node['query'];
	$port = $node['port'];
	$scheme = $node['scheme'];

// echo "\n1. Root " . (string)$wasroot . "; alldomain " . (string)$alldomain . "; alloc " . (string) $allloc . "; loc '" . $loc . "'; query '" . $query . "'\n";

	if( strcmp($domain, $old_domain) ) {
		loc_close( $old_loc, ($alldomain || $wasroot || $allloc));
		dom_close( $old_domain, $wasroot );
		dom_open( $domain, $port, $scheme );
		$old_loc = '';
		$alldomain = false;
		$wasroot = false;
	}

	if( !$alldomain ){
		if( strcmp($loc, $old_loc) ) {
			loc_close( $old_loc, ($alldomain || $allloc) );
			loc_open( $loc );
			$allloc = false;
		}

		if( strlen($loc)<2 && strlen($query)>0 )
			$wasroot = true;
		if( strlen($loc)<2 && strlen($query)<1 )
			{ $alldomain = true; $wasroot = true; }
		if( strlen($query)<1 )
			$allloc = true;
		if( !$allloc )
			args_check( $query );
	}
// echo "\n2. Root " . (string)$wasroot . "; alldomain " . (string)$alldomain . "; alloc " . (string) $allloc . "; loc '" . $loc . "'; query '" . $query . "'\n";

	$old_loc = $loc;
	$old_domain = $domain;
}

loc_close( $loc, ($alldomain || $wasroot || $allloc) );
dom_close( $domain, $wasroot );


function loc_close( $_loc, $_alldomain ) {
    if (strlen($_loc)>0 ) {
	if( $_alldomain ) {
?>
	return 301 http://eais.rkn.gov.ru/;
<?php
	}
	else { //if ( strcmp($_loc, '/')==0 ) {
?>

        include /etc/nginx/proxy_params;
        if ($args = '') {
                proxy_pass $scheme://$host$uri;
        }
        if ($args != '') {
                proxy_pass $scheme://$host$uri?$args;
        }
<?php
	}
	echo "    } # location\n";
    }
}

function dom_close( $_dom, $_wasroot )
{
    if( strlen($_dom)>0 ) {
	if( !$_wasroot ) {
?>

    location / {
        include /etc/nginx/proxy_params;

        if ($args = '') {
                proxy_pass $scheme://$host$uri;
        }
        if ($args != '') {
                proxy_pass $scheme://$host$uri?$args;
        }
    } #root location
<?php
	}
	echo "} #domain\n";
    }
}

function loc_open( $_loc )
{
?>

    location ~* <?php echo $_loc . "* {\n"; ?>
<?php
}

function dom_open( $_domain, $_port, $_scheme )
{
?>
server {
    listen  1.2.3.4<?php echo $_port;
	if( strcmp( $_scheme, 'https:\/\/' )==0 ) echo ' ssl';
?>

    server_name <?php echo $_domain . " " . "*." . $_domain . ";\n";

}

function args_check( $_query ) {
    if ( strlen($_query)>0 ) {
	echo "\t    if (\$args ~* \"";
        if(strlen($_query)>0) echo $_query;
        echo "*\") {\n";
        echo "\t\treturn 301 http://eais.rkn.gov.ru/;\n";
	echo "\t    } #args\n";
	}
    else echo "\treturn 301 http://eais.rkn.gov.ru/;\n";
}
?>


По итогам исполнения третьего скрипта мы получаем конфигурацию для nginx, которая проксирует те доменные имена, которые получила. В случае, если адрес заблокирован, то осуществляется безусловный редирект (301) на адрес eais.rkn.gov.ru — реестра запрещенных сайтов.
Блокировка может быть трех типов:

1. Весь домен. Для таких сайтов мы получаем следующую запись:
server {
    listen  1.2.3.4:80;
    server_name badsite.org *.badsite.org;

    location ~* /* {
        return 301 http://eais.rkn.gov.ru/;
    } # location
} #domain


2. Определенные URL в домене. В этом случае мы получаем другую запись:
server {
    listen  1.2.3.4:80;
    server_name badsite.hk *.badsite.hk;

    location ~* \Q/h/\E* {
        return 301 http://eais.rkn.gov.ru/;
    } # location

    location ~* \Q/h/res/214.html\E* {
        return 301 http://eais.rkn.gov.ru/;
    } # location

    location / {
        include /etc/nginx/proxy_params;

        if ($args = '') {
                proxy_pass $scheme://$host$uri;
        }
        if ($args != '') {
                proxy_pass $scheme://$host$uri?$args;
        }
    } #root location
} #domain


3. Определенные аргументы у определенного URL (например, конкретный пост в PHPBB):
server {
    listen  1.2.3.4:80;
    server_name badsite.com *.badsite.com;

    location ~* \Q/forum/viewforum.php\E* {
            if ($args ~* "\Qf=6\E*") {
                return 301 http://eais.rkn.gov.ru/;
            } #args
            if ($args ~* "\Qf=6&start=25\E*") {
                return 301 http://eais.rkn.gov.ru/;
            } #args

        include /etc/nginx/proxy_params;
        if ($args = '') {
                proxy_pass $scheme://$host$uri;
        }
        if ($args != '') {
                proxy_pass $scheme://$host$uri?$args;
        }
    } # location

    location / {
        include /etc/nginx/proxy_params;

        if ($args = '') {
                proxy_pass $scheme://$host$uri;
        }
        if ($args != '') {
                proxy_pass $scheme://$host$uri?$args;
        }
    } #root location
} #domain<


И, конечно, в default есть проброс всех запросов к соответствующим адресам (на всякий случай):
server {
        listen 1.2.3.4:80 default_server;

        location / {
                include /etc/nginx/proxy_params;
                if ($args = '') {
                        proxy_pass $scheme://$host$uri;
                }
                if ($args != '') {
                        proxy_pass $scheme://$host$uri?$args;
                }
        }
}

server {
        listen 1.2.3.4:443 ssl default_server;

        location / {
                include /etc/nginx/proxy_params;
                if ($args = '') {
                        proxy_pass $scheme://$host$uri;
                }
                if ($args != '') {
                        proxy_pass $scheme://$host$uri?$args;
                }
        }
}


После генерации конфигурации необходимо не забыть сказать
# service nginx reload

что сообщит nginx о необходимости перезагрузить конфигурацию, мягко погасив старые пулы.

Система с nginx проходила проверку на прочность неделю назад, когда в данный список был внесен один ролик с youtube.com. Кроме повышенного расхода памяти побочных эффектов замечено не было. С расходом памяти удалось побороться отключив keep-alive соединения с клиентами. А вот с удобством для пользователей вышло, конечно, не очень: просмотр и загрузка роликов на youtube.com в целом работала, но многие ролики были внедрены в другие страницы с помощью https, а с подмененным сертификатом браузеры их отображать не хотели. Волевым решением руководства провайдера домены google.com, google.ru, youtube.com были вынесены в список исключений, а еще один из сайтов был внесен в список «исключений наоборот»: по нему есть давнее решение блокировать целиком, однако в данном реестре он выгружается только с двумя запрещенными URL.
В целом данное решение показало себя вполне работоспособным для маленького провайдера, который хочет продолжать работать в непростых условиях нашего Российского законодательства.
Сергей Соколов @kolu4iy
карма
0,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Администрирование

Комментарии (54)

  • +22
    Сколько печенек вам предложили за переход на тёмную сторону?
    • +1
      В данном случае, видимо, идёт речь об «анти-печеньках» в случае выбора светлой стороны.
    • +7
      Только разрешение существовать. Печенек не давали. Хорошо хоть не отобрали ничего.
      • 0
        как говорится — «лучшее поощрение — это отмена наказания»
      • 0
        Мне вот интересно — а что, крупных провайдеров не штрафуют? Я знаю несколько провайдеров, которые хоть и говорят что они блокируют сайты, но на самом деле ничего у них не блокируется.
  • 0
    Т.е. использовать специальные ДНС (типа семейного фильтра от яндекса) ваши клиенты не могут?

    • 0
      К сожалению, не могут. Только VPN спасет клиентов.
      • 0
        А не проще было сделать бесконечный циклический nslookup ресурсов из списка, если ресурс переедет на новый ip, то вы его своевременно внесете в стоп-лист, тут роскомнадзор не подкопается.
        • 0
          В реестре много ресурсов, у которых блокируются один-два URL. Представляете, что бы было, если б в позапрошлую пятницу у нас оказался бы заблокирован youtube.com полностью?
          Потому ответ: «Да, проще, но не соответствует цели».
  • +3
    А почему вы не хотите сделать заглушку в стиле

    Сайт %domain% заблокирован по ращению власти
    Способы как обойти блокировку расписаны вот тут: (ссылки на tor/i2p/мануалы)
    • +4
      Потому что они хотят зарабатывать деньги, а не бороться с огромной системой…
  • 0
    Общая схема работы была выработана следующая:
    • iptables на NAT перехватывает все DNS-запросы и перенаправляет их на наш DNS-сервер;
    • DNS-сервер держит зоны в том числе и запрещенных ресурсов, не пытаясь их обновить через recursor;
    • Эти зоны единственным адресом данных ресурсов указывают адрес сервера с nginx.

    Т.е. какую бы зону я не резолвил — получу адрес вашей прокси?
    Или адрес вашей прокси я получу только для URL, находящихся в реестре?
    • 0
      Только для доменов URL, находящихся в реестре. Для того и первый скрипт: он поднимает эти зоны (без www, domain.ru и *.domain.ru) в наших DNS, не давая рекурсору разрешать их дальше. Остальные зоны обрабатываются рекурсором как положено.
      • 0
        Т.е. получается, что при блокировке site.com, на котором у меня находится почта, я не смогу пользоваться почтой по smtp, pop3 и imap (т.к. я получил IP вашей прокси)?
        Ведь можно же пробрасывать только 80-й порт для данных IP на свою проксю.
        • 0
          Правильно. Должен сказать, что на сегодняшний день подобных случаев (сочетания веб-сервиса и каких-либо еще) в реестре запрещенных сайтов нет. Однако, у нас в кармане лежит и kernel routing+iptables, на которых это вполне возможно реализовать.
          • 0
            Ну однозначно про отсутствие подобных случае говорить нельзя. Возможно на каком-то из серверов реализован port knocking для служебных целей)
            Да и вы проверялили\проверяете наличие других сервисов?
            • 0
              Конечно нельзя. Однако, человек использующий port knocking наверняка ознакомлен и, например, с технологиями VPN, которые по закону мы глушить совершенно не обязаны. А самодеятельность в нашем случае совершенно не нужна.
              Как только поступит первая жалоба на невозможность использования какого-либо сервиса мы с удовольствием подумаем, как разрешить возникшую проблему.
  • +1
    на адрес eais.rkn.gov.ru — реестра запрещенных сайтов

    А 398-fz, nap и список минюста?
  • +1
    >только с гуглом?
    а с не-гугл сайтами указанными в 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-й порт так и на кучу левых (и при этом если делать подмену то диагностика вылетает самая разнообразная, вроде предложения пользователю проверить часы. добавить руками перехватывающий сертификат нельзя)
  • +9
    Уж как хотите, но вмешиваться в трафик пользователя — свинство. (закон само собой долбанутый, и корпоративные сети совсем другая история)
  • 0
    Мне кажется маловероятным, что подобные сайты попадут в данный реестр. Youtube — да, возможно. С остальными — вероятность невысока. После вдумчивого изучения того, что же действительно находится в данном реестре, я хочу ответственно заявить, что данный ФЗ излишне демонизируют, по крайней мере на сегодняшний день. Например, декларированные в СМИ блокировки grani.ru, kasparov.ru, блог Навального и сайт эха Москвы в нем до сих пор не оказались — все решилось на стороне.
    Никто не мешает добавить в список исключений сайты с HSTS, в результате чего данные зоны никогда не окажутся у нас в DNS. С другой стороны — что с ними делать, если они все-же попадут в данный список? Блокировать полностью? Кстати, я всегда хотел знать, как фильтруют подобный трафик покупные DPI решения: не брутфорсят же они, в самом деле, private key сервера?
    С точки зрения айтишника, мне и самому не нравится наличие данного реестра как такового. Лично мое мнение, что происходит подмена причины на следствие: преступников не ищут, а делают вид что их нет. Однако, как говорилось в других комментариях, сегодня выбор вариантов у провайдеров неширок — либо мы работаем, соответствуя законодательству, либо платим штрафы, и через некоторое время не работаем, а на наше место приходит Ростелеком с его блокировками по IP.

    P.S. Отвечал vikarti, не туда нажал.
    • +1
      а что делать пользователям банк-клиентов? для которых передача данных не по HTTPS просто опасна? вы же отнимаете у них один из основных эшелонов защиты?

      а что с пользователями сервисов, которые производят HTTPS-авторизацию?

      хитрецы, а что с пользователями хабра в вашей сети?
      ведь хабраюзеры не так давно вытребовали защищённую авторизацию (HTTPS, да) для защиты реквизитов доступа к хабру
      • 0
        Разве хабр и адреса, к которым подключаются банк-клиенты УЖЕ в реестре запрещенных сайтов?
        • 0
          простите, а список эксклудов у вас включет хабр и другие ресурсы?

          $excl = array();
          $excl[] = 'youtube.com';
          $excl[] = 'google.ru';
          $excl[] = 'google.com';
          $excl[] = 'badsite.org';

          или это для примера, а на самом деле у вас в эксклудах пол-инета?
          или же это инклуды?
          • 0
            Есть небольшой нюанс: запросы к доменным зонам НЕ состоящим в данном списке, будут традиционно обрабатываться dns-recursor и резолвиться как обычно, а не на адрес прокси. Потому данный список исключений предназначен как раз исключительно для вариантов позапрошлой пятницы с youtube.com
            • +2
              так или иначе — это не оправдывает ваш самодельный sslstrip, какие бы благие намерения вы не пропагандировали

              и не исключает добавление к нему новых ресурсов «по личной инициативе» или инициативе по звонку из «xxКН»
              доверять подобному подключению к Сети просто нельзя by design

              это небезопасное, практически незащищеное от инсайда и очень топорное решение
            • 0
              а вот этот ньюанс (с тем что заворачивается только то что на DNS из реестра)… не очевиден по крайней мере на первый взгляд из статьи. это упрощает ситуацию.
              хотя… я правильно понимаю что если в реестр попадет допустим sites.google.com/site/rasamahlab/ (ну — допустим) то на mail.google.com хромом я не попаду через вас?

              • 0
                Конкретно google — попадете, именно из-за исключений в скриптах MySQL/PHP.
            • +2
              и да:
              > Волевым решением руководства провайдера домены google.com, google.ru, youtube.com были вынесены в
              > список исключений, а еще один из сайтов был внесен в список «исключений наоборот»: по нему есть давнее
              > решение блокировать целиком, однако в данном реестре он выгружается только с двумя запрещенными URL

              $excl = array();
              $excl[] = 'youtube.com';
              $excl[] = 'google.ru';
              $excl[] = 'google.com';

              > Есть небольшой нюанс: запросы к доменным зонам НЕ состоящим в данном списке, будут традиционно
              > обрабатываться dns-recursor и резолвиться как обычно, а не на адрес прокси

              Кажется, вы уже просто начали лгать.
              • 0
                Установите powerdns для эксперимента (из репозиториев debian, компилировать не обязательно). Выполните первый скрипт и посмотрите что он делает. Вопрос с ложью должен решиться в пользу того из нас, кто действительно прав. Задача ровно на 15 минут.
                • 0
                  >Выполните первый скрипт и посмотрите что он делает

                  1. Если уж буквоедствовать, то Вы же пишете в статье:
                  >Первый скрипт я приводить не буду: провайдеры сами знают как получить информацию,
                  >а обычным пользователям ее разглашать не рекомендуется.

                  2. Для того, чтобы понимать, что система, перехватывающая DNS-запросы и совершающая MITM для расшифровки пользовательского HTTPS-трафика — небезопасна для пользователей, не обязательно её устанавливать.
                  • –1
                    В статье написано:

                    Общая схема работы была выработана следующая:
                    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.
                    • +1
                      ну а у ваших клиентов вы спрашивали, что думают они? просили их взвесить риски?
                      уверен, что нет

                      полагаю, что вы взвесили только свои риски и сделали так, чтобы минимизировать
                      исключительно свои риски и для себя

                      на одной чаше весов — предписания РКН, на другой — безграмотность большинства пользователей (расчёт на то, что они не поймут, что происходит)

                      этим вы ничем не лучше Webnames, печально известных тут

                      задам вопрос — а для своих пользователей вы публиковали информацию о новых фильтрах?
                      если да, то в каком виде? в прозрачном и понятном или в запутанном и сложном для понимания?

                      кстати, если не секрет, как называется ваша организация?
                      очень интересно посмотреть на ваш сайт, спасибо
                • 0
                  Утверждение про ложь, было, наверное, слишком эмоционально. Прошу простить благороднейше.

                  Но всё же обращаю внимание на тот факт, что у вас в описании работы с одним и тем же набором данных…

                  $excl = array();
                  $excl[] = 'youtube.com';
                  $excl[] = 'google.ru';
                  $excl[] = 'google.com'

                  … замечены взаимоисключающие параграфы.

                  Сначала утверждается (в статье), что MITM производится по всем HTTPS-запросам, кроме (цитата):

                  > а с подмененным сертификатом браузеры их отображать не хотели.
                  > Волевым решением руководства провайдера домены google.com,
                  > google.ru, youtube.com были вынесены в список исключений

                  а потом в комментарии Вы пишете (цитата):

                  > Есть небольшой нюанс: запросы к доменным зонам НЕ состоящим в данном списке,
                  > будут традиционно обрабатываться dns-recursor и резолвиться как обычно,
                  > а не на адрес прокси.

                  Если осмыслить вышенаписанное, то выходит, что вы противоречите сами себе.
  • +13
    за такое отвратительное и топорное техническое решение искренне желаю вам поскорее растерять побольше клиентов

    хотя бы для того, чтобы вы помнили, что содержит вашу организацию совсем не Роскомнадзор, а те, над кем вы ставите свои эксперименты
  • 0
    Я так понимаю в заголовке речь всё же про 139-ФЗ, а не про 193-ий?
    • +1
      Спасибо, поправил.
      • 0
        Да и не только 139-ый.
        Вы же еще и 187-ой исполняете («антипиратский») и 398-ой («политический»).
        А скоро и новое))
  • +1
    Интересно, а за перехват и изменение [DNS] трафика пользователи могут пожаловаться куда-нибудь?
    • 0
      Кстати, да. Получается, пользователи не могут пользоваться тем же DNS от Яндекса.
      • 0
        Мне больше интересно использование моего личного DNS с плюшками и чаем, может я хочу, что бы у меня лично (и моих домочадцев) по адресу microsoft.com открывался сайт kernel.org (например) и для этого я использую DNS сервер на своей VDS'ке (конечно логичнее для этого использовать DNS дома, но это не суть), да и еще могу придумать тысячи случаев, когда мне хочется обратиться к конкретному DNS-серверу (например узнать, почему у половины клиентов моего сайта сайт не работает).

        Ну и наконец может я вообще организовал себе VPN over DNS (Такая же уже есть, правда?) или на 53й порт повесил на своей VDSке другой сервер (зачем? потому что могу, вот почему).
  • +1
    iptables на NAT перехватывает все DNS-запросы и перенаправляет их на наш DNS-сервер;

    В сад такого провайдера… Или VPN на худой конец, на время поисков другого…
  • 0
    Перехватывать DNS — совсем не путь самурая.

    Я конечно понимаю, что иначе нормально блокировать не получится и вообще выбора не оставили, но как-то это уж очень неправильно. Да и криво местами. Когда список станет большой — будут вылезать проблемы с другими протоколами пачками.

    Кстати — есть, у того же гугла, некоторые хитрости, например для chromecast — там вшиты DNS 8.8.8.8 / 8.8.4.4 и в редких случаях ответ не очень соответствует реальному DNS (так надо).
    • –1
      Согласен по обоим пунктам.
      Был и второй вариант, который соответствует рекомендациям Роскомнадзора (да-да, есть и такие): разрешать имена запрещенных доменов в адреса, а весь трафик на эти адреса адреса заворачивать в «сегмент анализа сети», чем в нашем случае является наш же прокси. Возможно, мы на данный вариант и перейдем: будем заворачивать только трафик по портам (согласно схеме либо порту из URL) и адресу. Но с HTTPS другого варианта просто мы просто не видим, к сожалению.
      • 0
        ещё хотел добавить с позиции «лягушки», что не хочу обсуждать, как лучше варить лягушку
        я хочу, чтобы огонь выключили, а лягушку отпустили назад в леса-поля-болота
      • +2
        Блокировать весь https-трафик на сайты с запрещёнными страницами и то лучше, чем подменять сертификат. Можно перенаправлять на страницу, на которой рекомендовать заходить по http.
      • 0
        Автор, пожалуйта, дайте ссылку на вашу страничку
  • 0
    То, что вы сделали для пользователей — отвратительно.
    То. что вы прикрываете свой заработок отношениями с «коллегой с четырьмя детьми», вдвойне мерзко.

    То, что вы наговорили мне в личке — отвратительно втройне.
  • +1
    Парни, разве вы не понимаете, что этот вредный мануал будет раскопирован и применен тысячами мелких админов?

    а потом эти ограничения распространятся и на вас и на меня и на всех остальных. и это будет считаться нормальным поведением?

    а потом наш интернет мы будем вынуждены защищать?
    куда мы катимся со всеми этими толерантными ограничениями?

    нас уже плющат и прессуют по всем фронтам.
  • 0
    server_name badsite.com *.badsite.com

    А насколько корректно использовать тут маску? В реестре ведь указаны вполне конкретные доменные имена.

    Однако, у нас в кармане лежит и kernel routing+iptables, на которых это вполне возможно реализовать.

    Вот только ip-адрес получателя будет потерян.
  • 0
    Слушайте, а почему редирект 301? Он же кэшируется намертво. А из реестра могут же и убрать. Почему не 302?
  • 0
    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
  • 0
    Насколько я помню, HAProxy хорошо подходит для высоких нагрузок и может работать в режиме прозрачного прокси. Можно было бы в iptables перенаправлять на HAProxy только определённые порты определённых IP, а DNS не трогать.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.