1. Для блокировка используем

[oleg_n]

12 hours ago, SyJet said:

 

Блин, когда уже реестр будет в csv и для загрузки вместо soap будет http get-запрос...

И да, utf-8 конечно же.

Изменено 1 февраля, 2018 пользователем oleg_n

[Bl_cK]

Quote

main.cpp: In member function ‘virtual void extFilter::initialize(Poco::Util::Application&)’:
main.cpp:819:32: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
    if(rc != 6 || mac.size() != last)
                                ^
...

notification.cpp: In member function ‘virtual void NotifyManager::runTask()’:
notification.cpp:118:41: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
       if(sub.second.repeat < sub.second.redirects)
                                         ^
...

notification.cpp: In member function ‘virtual void NotifyManager::runTask()’:
notification.cpp:118:41: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
       if(sub.second.repeat < sub.second.redirects)
                                         ^

плюс ещё во время ./configure несколько, но собирается и вроде даже работает. это нормально?

dpdk-stable-17.05.1 poco-1.7.7-all linux 3.10.0-514.el7.x86_64

Изменено 2 февраля, 2018 пользователем Bl_cK

[yKpon]

В 01.02.2018 в 10:40, oleg_n сказал:

Блин, когда уже реестр будет в csv и для загрузки вместо soap будет http get-запрос...

И да, utf-8 конечно же.

я вообще за http уведомления со стороны РКН об изменениях в реестре, пришло уведомление - дёргаем скрипт, а то дёргать по крону это всё же костыль ещё тот, у нас стабильно 25-30 пропусков по отчётам, выбираем любой url - заблокировано

 

и ещё

Цитата

Внимание! Изменяется формат файла выгрузки на версию 2.3 – для тегов content, url, domain, ip, ipSubnet добавляется необязательный атрибут с именем «ts», содержащий метку времени (timestamp) с указанием момента, когда произошли последние изменения данного объекта. В случае, если изменения произошли более 7 дней тому назад, данная метка времени будет отсутствовать. Эта информация необходима для определения того, какие изменения в ресурсах появились в выгрузке недавно.

Подробная информация по изменениям приведена в Памятке оператору связи.

Операторам связи необходимо доработать системы обработки файла выгрузки.
Формирование выгрузки с описанными изменениями в формате 2.3 будет производиться, начиная с 12.02.2018 12:00 МСК.

https://vigruzki.rkn.gov.ru/auto/

 

а по поводу дельт тоже очень интересно

[alibek]

40 тысяч уведомлений? Идея не айс.

[yKpon]

7 минут назад, alibek сказал:

40 тысяч уведомлений? Идея не айс.

а сколько запросов крон дёргает? думаю на порядки больше

[alibek]

Тут, кстати, глобальный мультикаст был бы в тему.

Ну или хотя бы RSS.

[oleg_n]

On 2/3/2018 at 11:02 AM, yKpon said:

я вообще за http уведомления со стороны РКН об изменениях в реестре, пришло уведомление - дёргаем скрипт, а то дёргать по крону это всё же костыль ещё тот, у нас стабильно 25-30 пропусков по отчётам, выбираем любой url - заблокировано

 

On 2/3/2018 at 12:36 PM, alibek said:

Тут, кстати, глобальный мультикаст был бы в тему.

Ну или хотя бы RSS.

 

Коллеги, всё делается проще. Делается нормальный RESTful-сервис, где для скачивания делается http get запрос:

 

GET /reestr HTTP/1.1

Host: vigruzki.rkn.gov.ru

If-None-Match: ETAG_ПОСЛЕДНЕГО_СКАЧИВАНИЯ

 

  И далее согласно стандарту, либо 304(если ничего не изменилось с  ETAG_ПОСЛЕДНЕГО_СКАЧИВАНИЯ), либо 200(если изменилось и тогда в теле реестр новый) в ответ. Крайне легковесный запрос, что для сервера, что для клиента.

  Насчёт крон-костыль - ну, не знаю. Вовсе нет. Нормальный подход. Другого не дано - либо мы опрашиваем сервер об изменениях, либо он сообщает их нам. Второй вариант может оказаться ещё геморойнее(вроде, сервер сообщил нам, но мы в этот момент были кратковременно не доступны и профукали это дело; поэтому надо всё равно раз в час опрашивать сервер самим, что в итоге приводит к первой схеме, только сложнее).

 

UPD: кайф этого всего в отличии от уёб#щного soap в том, что всё это очень естественно ложиться на механизмы кэширования http и может работать крайне быстро.

Изменено 5 февраля, 2018 пользователем oleg_n

[oleg_n]

On 2/3/2018 at 11:02 AM, yKpon said:

у нас стабильно 25-30 пропусков по отчётам, выбираем любой url - заблокировано

А, вот, что бы такого не было нужна модификация ревизора, которая скачивает для проверки копию реестра, скаченного последний раз провайдером. Тогда ревизор и провайдер будут иметь общий знаменатель. При чём, тут необходимо учесть ещё другие ньюансы, вроде ситуации, когда во время проверки ревизором провайдер скачивает новый реестр. Либо надо после проверки ревизору проверять различаются ли последний скаченный реестр от проверочного, в случае чего объявлять проверку недействительной и начинать заново; либо, т.к. реестр бывает меняется часто и т.о. подобная ситуация может приводить к бесконечным повторным проверкам без результата, со стороны РКН на время проверки ревизором отдавать провайдеру копию реестра, который в проверке сейчас. Но тут возникает ещё куча тонких моментов :-). Вроде того, если ревизор сдох и не смог сообщить о конце проверки(вводить какие-то таймауты на стороне РКН, короче, гимор), либо проверка идёт долго(например, как у нас, когда фильтруется не только http, но и dns DROP'ами; >4 часов может идти проверка полная). Все эти случаи в такой схеме приведут к нарушению закона в случае внесений новых ресурсов Генпрокуратурой - реакция по которым должна быть в пределах 1 часа.

Изменено 6 февраля, 2018 пользователем oleg_n

[oleg_n]

Хотя, можно всё это решить проще:

 

- ревизор так же берёт последную скаченную копию реестра провайдером;

- проверяя сохраняет результат каждой неудачной проверки со всеми данными(в идеале достаточно id записи);

- в конце проверки проверяет последную скаченную копию реестра провайдером; если не отличается от той, по которой шла проверка, то

  список составленный выше и есть список нарушений;

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

  убирая из списка нарушений те, которые не найдены в новой копии реестра;

- на выходе имеем список нарушений за вычетом ложных срабатываний(из-за смены в процессе проверки реестра)

[alkol]

Пробую nfqfilter в качестве блокировщика. 

Заметил одну странность: если пробовать проверить curl-ом, то nfqfilter детектит, а если те же хедеры отправить telnet-ом - нет.

Что я делаю не так ?

 

curl 

$ curl -v http://www.bet-52.com/

 

 curl -v http://www.bet-52.com/
* Hostname was NOT found in DNS cache
*   Trying 104.16.118.110...
* Connected to www.bet-52.com (104.16.118.110) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.38.0
> Host: www.bet-52.com
> Accept: */*
>
< HTTP/1.1 302 Moved Temporarily
< Location: http://10.10.10.2/
< Connection: close
* Closing connection 0
 

 

в логах

2018-02-07 11:48:39.414 [7903] Debug PktAnalyzer 2 - Guessing protocol...
2018-02-07 11:48:39.414 [7903] Debug PktAnalyzer 2 - Protocol is 0/7
2018-02-07 11:48:39.414 [7903] Debug PktAnalyzer 2 - nDPI protocol detection occupied 136 us
2018-02-07 11:48:39.414 [7903] Debug PktAnalyzer 2 - Got HTTP protocol
2018-02-07 11:48:39.414 [7903] Debug PktAnalyzer 2 - Host seek occupied 9 us
2018-02-07 11:48:39.414 [7903] Debug PktAnalyzer 2 - URL seek occupied 24 us for uri http://www.bet-52.com/
2018-02-07 11:48:39.415 [7903] Debug PktAnalyzer 2 - URL http://www.bet-52.com/ present in url (file pos 43174) list from ip 192.168.1.1
2018-02-07 11:48:39.415 [7903] Debug CSender - Trying to send packet to 192.168.1.1 port 49532
2018-02-07 11:48:39.415 [7903] Debug CSender - Trying to send packet to 104.16.118.110 port 80

telnet
$ telnet 104.16.120.110 80
GET / HTTP/1.1
host: www.bet-52.com
User-Agent: curl/7.38.0
Host: www.bet-52.com
Accept: */*
 

Собственно отдает отдает код сайта...

 

В логах 
 

2018-02-07 11:49:39.345 [7903] Debug PktAnalyzer 1 - Guessing protocol...
2018-02-07 11:49:39.346 [7903] Debug PktAnalyzer 1 - Protocol is 0/7
2018-02-07 11:49:39.346 [7903] Debug PktAnalyzer 1 - nDPI protocol detection occupied 123 us
2018-02-07 11:49:39.346 [7903] Debug PktAnalyzer 1 - Got HTTP protocol
2018-02-07 11:49:39.347 [7903] Debug nfqThread - Got the packet from queue
2018-02-07 11:49:39.347 [7903] Debug PktAnalyzer 2 - Got packet from queue

 

[zhenya`]

в dmesg ничего странного нет ? может трафика много 

[alkol]

@zhenya` нету ничего 
в mangle правило только для одного тестового IP, где и провожу данное тестирование 
 

Chain PREROUTING (policy ACCEPT 1614K packets, 1925M bytes)
 pkts bytes target     prot opt in     out     source               destination
  105  5192 NFQUEUE    tcp  --  *      *       192.168.1.1        0.0.0.0/0            tcp NFQUEUE num 0 bypass

т.е. трафика очень мало :)

[max1976]

27 минут назад, alkol сказал:

$ telnet 104.16.120.110 80
GET / HTTP/1.1
host: www.bet-52.com
User-Agent: curl/7.38.0
Host: www.bet-52.com
Accept: */*
 

Неправильно указываете формат заголовков. У вас 2 раза указано host: и Host:. Должен быть только один Host:

[alkol]

2 minutes ago, max1976 said:

Неправильно указываете формат заголовков. У вас 2 раза указано host: и Host:. Должен быть только один Host:

Действительно, ошибся, когда пробовал host: и Host: - думал в этом дело.
Но с правильным форматом тоже не детектит

 

telnet 104.16.120.110 80
Trying 104.16.120.110...
Connected to 104.16.120.110.
Escape character is '^]'.
GET / HTTP/1.1
User-Agent: curl/7.38.0
Host: www.bet-52.com
Accept: */*



HTTP/1.1 200 OK
Date: Wed, 07 Feb 2018 09:43:49 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Set-Cookie: __cfduid=dc1159d84c71b6d9aedabb9e18b10e3441517996629; expires=Thu, 07-Feb-19 09:43:49 GMT; path=/; domain=.bet-52.com; HttpOnly
Last-Modified: Fri, 01 Dec 2017 06:12:26 GMT
Vary: Accept-Encoding
Expires: Wed, 07 Feb 2018 09:44:49 GMT
Cache-Control: max-age=60
Set-Cookie: SERVERID=s2; path=/
Server: cloudflare
CF-RAY: 3e95682821d79041-DME

 

[max1976]

2 минуты назад, alkol сказал:

Действительно, ошибся, когда пробовал host: и Host: - думал в этом дело.
Но с правильным форматом тоже не детектит

Я уже не помню как точно разбирает пакеты nDPI, но зайдя telnet'ом вы отправляете только \n при нажатии Enter, а по стандарту должно быть \r\n.

 

[Tosha]

telnet шлет данные посимвольно. Т.е. не одним пакетом, а примерно 90 пакетов в данном случае.

[alkol]

16 minutes ago, max1976 said:

Я уже не помню как точно разбирает пакеты nDPI, но зайдя telnet'ом вы отправляете только \n при нажатии Enter, а по стандарту должно быть \r\n.

 

Попробовал

telnet> toggle crlf
Will send carriage returns as telnet <CR><LF>.

 

но тоже не работает.

 

Видимо что то с telnet-ом 

в дампе host вообще не прилетел

Hypertext Transfer Protocol
    GET / HTTP/1.1\r\n
        [Expert Info (Chat/Sequence): GET / HTTP/1.1\r\n]
            [GET / HTTP/1.1\r\n]
            [Severity level: Chat]
            [Group: Sequence]
        Request Method: GET
        Request URI: /
        Request Version: HTTP/1.1
    [HTTP request 1/1]

 

 

Проверил простым питонячим скриптом sock.send('GET / HTTP/1.1\r\nUser-Agent: curl/7.38.0\r\nHost: www.bet-52.com\r\nAccept: */*\r\n') - все детектит.

Спасибо, что помогли разобраться !

 

@max1976 Для https что можно придумать, что бы тоже получать редирект, вместо сброса соединения? 
 

[st_re]

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

[alkol]

4 minutes ago, st_re said:

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

Тем не менее делают же редирект :) Например, через squid и ssl-bump 

[st_re]

Для массового пользователя ? И как убедили их всех корневой ЦА поставить ? Это применимо только внутри корпоративных сетей. для внешних пользователей не работает.

[alkol]

22 hours ago, st_re said:

Для массового пользователя ? И как убедили их всех корневой ЦА поставить ? Это применимо только внутри корпоративных сетей. для внешних пользователей не работает.

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

[st_re]

ну и смысл в таком редиректе ? rst и баста

[oleg_n]

Раньше, когда браузеры хоть как-то отображали страницы с самоподписными сертификами это всё работало. Теперь для https и dns фильтров это бессмыслено.

[ne-vlezay80]

39 минут назад, oleg_n сказал:

Раньше, когда браузеры хоть как-то отображали страницы с самоподписными сертификами это всё работало. Теперь для https и dns фильтров это бессмыслено.

max1976

как идея реализовать MitM SSL в extfilter и где взять базу всех серверных SSL-сертификатов, чтобы браузер клиента не орал?

Изменено 8 февраля, 2018 пользователем ne-vlezay80

[st_re]

35 минут назад, ne-vlezay80 сказал:

max1976

и где взять базу всех серверных SSL-сертификатов, чтобы браузер клиента не орал?

Базу взять в любой ОС.. но это НЕ ПОМОЖЕТ. сертификат не секрет ни разу, серкрет закрытый ключ. а вот его вам точно не дадут. и в браузере его естественно нет.

 

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

 

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