Перейти к содержимому
Калькуляторы

Опубликована Процедура блокировки некошерной инфо

Вон статья, какое ваше мнение о предложенном решении?

С точки зрения кармы и безопасности - давить нещадно. Пользователь начинает привыкать к предупреждениям браузера о несоответствии сертификатов и когда-нибудь в один не очень удачный момент нажмет 'все равно продолжить' там, где этого делать было не нужно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Мож какой другой компактный редактор-вьювер существует? Кто чем пользуется?

я "нормализую" исходный дамп, добавляя концы строк и приводя всё к единой кодировке utf-8

да, это потенциально чревато "потерей символов", но деваться особо некуда

 

"а дальше уже обычным текстовым редактором" (с) Tem

 

Те, кто блокирует по DNS, подскажите, что у вас за dns сервер стоит и как вы это на нем осуществляете ? Как блокируете по домену ?

unbound, через local-zone:

# 52358
local-zone: "pagesofpain.com." transparent
local-data: "pagesofpain.com. 14400 IN A 127.1.2.3"
local-data: "www.pagesofpain.com. 14400 IN A 127.1.2.3"
# 51014
local-zone: "wayaway.biz." transparent
local-data: "wayaway.biz. 14400 IN A 127.1.2.3"
local-data: "www.wayaway.biz. 14400 IN A 127.1.2.3"

 

С точки зрения кармы и безопасности - давить нещадно.

поддерживаю

Изменено пользователем lcgc

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

Запрос у меня такой, ну за исключением стертых ПД :) Надо что-то менять? В ручном режиме все проходит.

 

 

Та же история.

 

1)есть работающая перловая выгрузка

2)берем из её каталога рабочие request.xml и provider.pem

3)складываем это все в каталог с py-скриптом

4)делаем python zapret_checker.py -r request.xml -s provider.pem

5)получаем

2015-03-16 09:05:22,060  Starting script.
2015-03-16 09:05:22,075  Check if dump.xml already exists.
2015-03-16 09:05:22,075  dump.xml does not exist
2015-03-16 09:05:22,076  Check if dump.xml has updates since last sync.
2015-03-16 09:05:22,464  Current versions: webservice: 3.1, dump: 2.1, doc: 4.2
2015-03-16 09:05:22,464  New dump is available.
2015-03-16 09:05:22,464  Sending request.
2015-03-16 09:05:22,667  Checking request status.
2015-03-16 09:05:22,668  Got code 907eeb4ff46bf46ebc8975dcb3e7a7fe
2015-03-16 09:06:22,728  Waiting for a minute.
2015-03-16 09:06:22,730  Trying to get result...
2015-03-16 09:06:22,896  Not ready yet. Waiting for a minute.
2015-03-16 09:07:22,956  Trying to get result...
2015-03-16 09:07:23,144  Got an error, code -2: неверный формат ЭП (информация по обратной связи для разрешения проблем приведена в Памятке оператору связи в разделе http://eais.rkn.gov.ru/tooperators/)
2015-03-16 09:07:23,144  Script stopped.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

4)делаем python zapret_checker.py -r request.xml -s provider.pem

А если сделать python zapret_checker.py -r request.xml -s request.sign ??

Изменено пользователем sanitar666

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

4)делаем python zapret_checker.py -r request.xml -s provider.pem

А если сделать python zapret_checker.py -r request.xml -s request.sign ??

zapret_checker.py принимает .p7s

Различия форматов: https://myonlineusb.wordpress.com/2011/06/19/how-to-convert-certificates-between-pem-der-p7bpkcs7-pfxpkcs12/

На русском как-то навскидку не нагуглилось, но и тут достаточно кратко и прозрачно указано, что PEM не совсем P7S.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

4)делаем python zapret_checker.py -r request.xml -s provider.pem

А если сделать python zapret_checker.py -r request.xml -s request.sign ??

zapret_checker.py принимает .p7s

Различия форматов: https://myonlineusb.wordpress.com/2011/06/19/how-to-convert-certificates-between-pem-der-p7bpkcs7-pfxpkcs12/

На русском как-то навскидку не нагуглилось, но и тут достаточно кратко и прозрачно указано, что PEM не совсем P7S.

 

А что за .p7s ?

Попробовал с PKCS#7 .p7b, получил уже про неверный алгоритм:

2015-03-16 17:09:38,915  Got an error, code -1: неверный алгоритм ЭП (информация по обратной связи для разрешения проблем приведена в Памятке оператору связи в разделе http://eais.rkn.gov.ru/tooperators/)

 

Экспортировал в DER .crt, получил:

2015-03-16 17:24:55,021  Got an error, code -2: неверный формат ЭП (информация по обратной связи для разрешения проблем приведена в Памятке оператору связи в разделе http://eais.rkn.gov.ru/tooperators/)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Пришло письмо от ФГУП "РЧЦ ЦФО"

Уважаемый оператор связи!

 

С целью осуществления контроля за соблюдением операторами связи требований Федерального закона от 27 июля 2006 года № 149-ФЗ «Об информации, информационных технологиях и о защите информации» Федеральная служба по надзору в сфере связи, информационных технологий и массовых коммуникаций планирует создание автоматизированной системы контроля. Рассматриваемое техническое решение предполагает установку программных и программно-аппаратных технических средств контроля в сетях доступа операторов связи, предоставляющих телематические услуги связи.

 

В соответствии с Приказом Роскомнадзора от 17.07.2014 №103 «Об утверждении Порядка предоставления операторами связи технических средств контроля за соблюдением операторами связи требований Федерального закона от 27 июля 2006 года № 149-ФЗ «Об информации, информационных технологиях и о защите информации»» (зарегистрирован в Минюсте России 24.11.2014 №34896) оператор связи определяет необходимое ему количество технических средств контроля.

 

В целях оценки возможной потребности технических средств контроля прошу в срок до 20.03.2015 г. сообщить число узлов фильтрации ограничивающих доступ из ваших сетей доступа физическим и юридическим лицам к сайтам в сети «Интернет» содержащим информацию, распространение которой в Российской Федерации запрещено.

 

Информацию о количестве узлов фильтрации прошу направить на адрес электронной почты fz149@rfc-cfa.ru .

 

ЗЫ: Интересно, а когда они научатся использовать скрытую копию при массовых рассылках, а не херачить все в поле Кому

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

zapret_checker.py принимает и PEM и DER. Технически там вообще разницы нет, что отправлять, хоть jpeg. Если у вас получается получить реестр с двумя файликами в ручном режиме, то и при помощи zapret_zhecker.py все должно работать. Если это не так, можете в личку файлики сбросить, будем разбираться. В как минимум 5 уже известных случаях проблема была в особенностях отдельных используемых серверов.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Как выбрать из dump.xml все домены заблокированные через blockType="domain" с помощью xmlstarlet ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

xml sel -T -t -m '//content[@blockType="domain"]' -v domain -n dump.xml

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Добрый день, товарищи форумчане.

Вопрос к тем, кто использует cisco SCE для блокировки URL/доменов из РКН реестров.

При добавлении записи, например foo.bar, страница сайта http://foo.bar не отроется, а вот если попробовать открыть страницу http://foo.bar./, т.е. с указанием корневого домена url сайта, то страница откроется.

В итоге для блокировки одного домена foo.bar приходится добавлять 4 записи: *.foo.bar; foo.bar; *.foo.bar.; foo.bar. Наблюдал ли кто-нибудь подобное? Баг это или фича SCE? Как вылечить подобное?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Добрый день, товарищи форумчане.

Вопрос к тем, кто использует cisco SCE для блокировки URL/доменов из РКН реестров.

При добавлении записи, например foo.bar, страница сайта http://foo.bar не отроется, а вот если попробовать открыть страницу http://foo.bar./, т.е. с указанием корневого домена url сайта, то страница откроется.

В итоге для блокировки одного домена foo.bar приходится добавлять 4 записи: *.foo.bar; foo.bar; *.foo.bar.; foo.bar. Наблюдал ли кто-нибудь подобное? Баг это или фича SCE? Как вылечить подобное?

Блочим два варианта урлов - с трейлинг слешем и без. Проверяли - разные браузеры по-разному отсылают урл.

 

А все поддомены *.foo.bar не блочим. Имхо, в указаниях ркн не было про блочить "все поддомены домена". Поддомены могут быть делегированы совершенно другим лицам.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вопрос к тем, кто использует cisco SCE для блокировки URL/доменов из РКН реестров.

При добавлении записи, например foo.bar, страница сайта http://foo.bar не отроется, а вот если попробовать открыть страницу http://foo.bar./, т.е. с указанием корневого домена url сайта, то страница откроется.

В итоге для блокировки одного домена foo.bar приходится добавлять 4 записи: *.foo.bar; foo.bar; *.foo.bar.; foo.bar. Наблюдал ли кто-нибудь подобное? Баг это или фича SCE? Как вылечить подобное?

Блочим два варианта урлов - с трейлинг слешем и без. Проверяли - разные браузеры по-разному отсылают урл.

 

А все поддомены *.foo.bar не блочим. Имхо, в указаниях ркн не было про блочить "все поддомены домена". Поддомены могут быть делегированы совершенно другим лицам.

www.foo.bar тоже другим лицам? Не блочить?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если www.foo.bar это отдельная делегированная доменная зона (причем делегирована она может быть на тот же NS-сервер), то это одно.

Но это также может быть хост www в зоне foo.bar, и это другое.

Но поскольку РКН ясно давал знать, что оператор не должен заниматься изысканиями, нужно блокировать только то, что есть в реестре, без своей инициативе в блокировке поддоменов.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Существует ли документ РКН где расшифровывается как блокировать домен?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Интересно, у одного меня непонятки зачесались, с чего бы это столь повторючий текстовый XML так хреново сжат в выгрузках?

1677367 result.zip // исходный от РКН, сжатие всего 33% !

289192 result-9.zip // тем же зипом, но с "ниасиленным" РКН-школотой ключиком -9

289125 result.tar.gz // наверное самый распространенный в *NIX-like формат

233087 result.tar.7z // свободно-бесплатно, жмет круто, есть для всего

213593 result.tar.bz2 // линуксоидам наверное даже удобнее, и 7z в Винде умеет открывать

207852 result.tar.xz // до кучи -- совсем новая экзотика, но оказалось компактнее всех

Вот интересно, чего там на их сайте так долго считают по 2-3-5 минут, прежде чем отдать реестр? Не справляются?

Если это нагрузка тупо по массовому выкачиванию, то один тупой ключик архиватора мог бы в 5-8 раз все ускорить.

Или откаты в отрасли пропорциональны размерам напечатанного "бешеным принтером"?

Изменено пользователем Ansy

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вот интересно, чего там на их сайте так долго считают по 2-3-5 минут, прежде чем отдать реестр?

В реестре 38 тысяч лицензий. Примерно я бы прикинул, что это тысяч 15 операторов. Которые в среднем ежечасно получают реестры, т.е. примерно 4-5 запросов в секунду.

Нужно получить запрос, сверить валидность ЭЦП, сверить актуальность ЭЦП (проверить реестр и CRL), проверить корректность запроса, сформировать ответ (в перспективе — индивидуальный), заархивировать, подписать ЭЦП (в перспективе — зашифровать публичным ключом оператора) и отдать.

Пустяковая задача.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вот интересно, чего там на их сайте так долго считают по 2-3-5 минут, прежде чем отдать реестр?

В реестре 38 тысяч лицензий. Примерно я бы прикинул, что это тысяч 15 операторов. Которые в среднем ежечасно получают реестры, т.е. примерно 4-5 запросов в секунду.

Нужно получить запрос, сверить валидность ЭЦП, сверить актуальность ЭЦП (проверить реестр и CRL), проверить корректность запроса, сформировать ответ (в перспективе — индивидуальный), заархивировать, подписать ЭЦП (в перспективе — зашифровать публичным ключом оператора) и отдать.

Пустяковая задача.

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

Однако я не удивлюсь, если вдруг собственно подготовка выгрузки делается в РКН вручную. Причем теми же среднего возраста тетеньками-"экспертами по ДП". И наверное даже на компах среднего возраста. Каким-нить архаичным zip под MS-DOS ;) Хорошо, если на WinXP.

Такие вот косячки намекают на общий уровень выполнения задач, причем сами же говорили -- сильно непрофильных для РКН, привыкших работать с бумагами и НПА.

 

Будем надеяться, что версия 2.0 уже под крылышком (более технической) службы ГРЧЦ окажется адекватнее.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

...с чего бы это столь повторючий текстовый XML так хреново сжат в выгрузках?

Примерно с полгода пережимаю пачками за 10 дней в tar+gzip

 

# gunzip -l arch-2015-03-01-2015-03-09.tgz 
 compressed uncompressed  ratio uncompressed_name
   23319210    190371840  87.7% arch-2015-03-01-2015-03-09.tar

 

Подумал, сравнил и пережал по-другому:

 

# unxz -l arch-2015-03-01-2015-03-09.txz 
Strms  Blocks   Compressed Uncompressed  Ratio  Check   Filename
   1       1    245,3 KiB    181,6 MiB  0,001  CRC64   arch-2015-03-01-2015-03-09.txz

Изменено пользователем snvoronkov

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если это нагрузка тупо по массовому выкачиванию, то один тупой ключик архиватора мог бы в 5-8 раз все ускорить.

Или откаты в отрасли пропорциональны размерам напечатанного "бешеным принтером"?

А еще они rsync и git протокол забыли. Вообще бы только изменения передавались.

 

Нужно получить запрос, сверить валидность ЭЦП, сверить актуальность ЭЦП (проверить реестр и CRL), проверить корректность запроса, сформировать ответ (в перспективе — индивидуальный), заархивировать, подписать ЭЦП (в перспективе — зашифровать публичным ключом оператора) и отдать.

Пустяковая задача.

Вообще-то да. Если это не вручную делать, конечно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Но поскольку РКН ясно давал знать, что оператор не должен заниматься изысканиями, нужно блокировать только то, что есть в реестре, без своей инициативе в блокировке поддоменов.

А можно пруф?

Я писал письма по этому поводу в ТП РКН, в группе в контакте, но ответа не получил до сих пор.

С другой стороны сам РКН занимается ересью и каждый день добавляют новое зеркало mirrorN.graniru.info, сегодня уже вот 317-тое. Заблокировали бы *.graniru.info и добавляли бы только IP адреса, при поступлении постановлений. Лишняя ведь нагрузка на железо операторов зеркалов кучу подобных блочить...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Тем более, что запросы от одних и тех же товарищей идут. Результаты проверки можно тупо закэшировать. Или им "реалтайм" скорость реагирования на отзыва сертификата нужна?

 

Заблокировали бы *.graniru.info

А потом на очередном cats.graniru.info будут лежат котики... Которые блокировать нельзя. И про которых обязательно заявление в суд устроят и вообще шум поднимут.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Добрый день, господа, аналогичным образом получил следующее письмо:

 

Уважаемый оператор связи!

 

С целью осуществления контроля за соблюдением операторами связи требований Федерального закона от 27 июля 2006 года № 149-ФЗ «Об информации, информационных технологиях и о защите информации» Федеральная служба по надзору в сфере связи, информационных технологий и массовых коммуникаций планирует создание автоматизированной системы контроля. Рассматриваемое техническое решение предполагает установку программных и программно-аппаратных технических средств контроля в сетях доступа операторов связи, предоставляющих телематические услуги связи.

 

В соответствии с Приказом Роскомнадзора от 17.07.2014 №103 «Об утверждении Порядка предоставления операторами связи технических средств контроля за соблюдением операторами связи требований Федерального закона от 27 июля 2006 года № 149-ФЗ «Об информации, информационных технологиях и о защите информации»» (зарегистрирован в Минюсте России 24.11.2014 №34896) оператор связи определяет необходимое ему количество технических средств контроля.

 

В целях оценки возможной потребности технических средств контроля прошу в срок до 20.03.2015 г. сообщить число узлов фильтрации ограничивающих доступ из ваших сетей доступа физическим и юридическим лицам к сайтам в сети «Интернет» содержащим информацию, распространение которой в Российской Федерации запрещено.

 

Информацию о количестве узлов фильтрации прошу направить на адрес электронной почты fz149@rfc-cfa.ru .

 

Подскажите, пожалуйста, что в данной ситуации корректнее ответить при условии, что официально зарегистрирован только один узел связи и фильтрация осуществляется на уровне программного обеспечения под nix без использования таких решений как Cisco SCE?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Тем более, что запросы от одних и тех же товарищей идут. Результаты проверки можно тупо закэшировать. Или им "реалтайм" скорость реагирования на отзыва сертификата нужна?

Низзя же.

В сертифкате срок годности указан. Но ведь бывает досрочный отзыв ЭЦП -- компрометация, смена реквизитов и т.п. ахтунги.

Даже сам Удостоверяющий Центр в принципе может накрыться медным тазом, вместе со всеми своими немалыми гарантиями.

И в общем случае далее встаёт вопрос экономических рисков -- принять ли уже отозванную подпись, полагаясь на свой кэш.

 

Лично я согласен -- КОНКРЕТНО В ДАННОМ СЛУЧАЕ могли бы и не париться. Все равно в РКН на каждого оператора еще и лицензии есть, и много чего.

Но по факту -- у нас внеочередной отзыв сертификата уже происходил, и в получении выгрузки отказали СРАЗУ ЖЕ. Значит, проверяют в УЦ.

 

Заблокировали бы *.graniru.info

А потом на очередном cats.graniru.info будут лежат котики... Которые блокировать нельзя. И про которых обязательно заявление в суд устроят и вообще шум поднимут.

Какой-то уж очень тихий шум был, даже по поводу того, что нормальной процедуры снятия блокировки в законе не предусмотрено... 99.9% рунета даже ничего и не заметили наверное. Впрочем, 80% скорее всего и о наличии самих блокировок не догадываются.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Заблокировали бы *.graniru.info

А потом на очередном cats.graniru.info будут лежат котики... Которые блокировать нельзя. И про которых обязательно заявление в суд устроят и вообще шум поднимут.

О да, а если заблокировать по ip то лежать не будет? По заявлениям того же РКН 30% провайдеров блокируют по ip. Это уже проблема ресурса будет отделится от данного домена/ip, что нарушает законы РФ. Провайдер обязан ограничивать доступ, но имеет право выбрать удобный для себя метод. Я понимаю домены 1 и 2 уровня принципиальны, а дальше.. можно блочить любые. Тем более, что основные крупные ресурсы сотрудничают с РКН (про blogspot не уверен).

У нас был абонент, который жаловался на недоступность кооперативной почты, домен которой принадлежал букмекерам и находился в реестре.

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

Подскажите, пожалуйста, что в данной ситуации корректнее ответить при условии, что официально зарегистрирован только один узел связи и фильтрация осуществляется на уровне программного обеспечения под nix без использования таких решений как Cisco SCE?

Прокси, DNS или ещё какой вариант? Воопрос не про узел связи, а про узел фильтрации, т.е. (насколько я понимаю методы, которыми вы ограничиваете) например DNS, Прокси, DPI, ACL на головной станции/маршрутизаторе/ТКД и т.п.

Изменено пользователем MYA

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.