snvoronkov Опубликовано 18 апреля, 2018 · Жалоба Нету толку от timeout_check_new_bl=1 !!! У меня вон с их сервера blcache.bin уже 10 минут загружается!!! Upd: 16 минут!!! Цитата [COMMON ][2018/04/18-11:26:36:749782][0x7f92dbc19700] Check license : devices dna0 <--> dna1 ... [COMMON ][2018/04/18-11:26:36:750031][0x7f92dbc19700] Result 'check license', err_code=1 : Success: loaded [INFO ][2018/04/18-11:26:36:750040][0x7f92dbc19700] bl_updater_thread : downloading black list ... [INFO ][2018/04/18-11:41:01:601406][0x7f92dbc19700] bl_updater_thread : cloud url black list update with result, rc=0 : Success: loaded. [INFO ][2018/04/18-11:41:01:601450][0x7f92dbc19700] bl_updater_thread : URL black list download with result, rc=0 : Success: loaded. [INFO ][2018/04/18-11:41:05:446595][0x7f92dbc19700] bl_updater_thread : cloud cname black list download with result, rc=0 : Success: loaded. [INFO ][2018/04/18-11:41:10:695984][0x7f92dbc19700] bl_updater_thread : cloud sni black list download with result, rc=0 : Success: loaded. [INFO ][2018/04/18-11:41:10:696045][0x7f92dbc19700] bl_updater_thread : downloading black list IP ... [INFO ][2018/04/18-11:41:13:289062][0x7f92dbc19700] bl_updater_thread : cloud IP black list download with result, rc=0 : Success: loaded. [INFO ][2018/04/18-11:41:13:289112][0x7f92dbc19700] bl_updater_thread : Custom IP black list download with result, rc=1001 : Success: no change. [COMMON ][2018/04/18-11:42:13:291947][0x7f92dbc19700] Check license : devices dna0 <--> dna1 ... [COMMON ][2018/04/18-11:42:13:293988][0x7f92dbc19700] Result 'check license', err_code=1 : Success: loaded [INFO ][2018/04/18-11:42:13:293998][0x7f92dbc19700] bl_updater_thread : downloading black list ... [INFO ][2018/04/18-11:42:13:698026][0x7f92dbc19700] bl_updater_thread : cloud url black list update with result, rc=1001 : Success: no change. [INFO ][2018/04/18-11:42:13:698059][0x7f92dbc19700] bl_updater_thread : URL black list download with result, rc=1001 : Success: no change. [INFO ][2018/04/18-11:42:14:050011][0x7f92dbc19700] bl_updater_thread : cloud cname black list download with result, rc=1001 : Success: no change. [INFO ][2018/04/18-11:42:14:407561][0x7f92dbc19700] bl_updater_thread : cloud sni black list download with result, rc=1001 : Success: no change. [INFO ][2018/04/18-11:42:14:407603][0x7f92dbc19700] bl_updater_thread : downloading black list IP ... [INFO ][2018/04/18-11:42:14:832822][0x7f92dbc19700] bl_updater_thread : cloud IP black list download with result, rc=1001 : Success: no change. [INFO ][2018/04/18-11:42:14:832856][0x7f92dbc19700] bl_updater_thread : Custom IP black list download with result, rc=1001 : Success: no change. И как тут без пропусков??? Upd2: Открыл ТТ INC085635. Пора переписывать процедуру загрузки. Цитата [root@skat dpi]# ls -l blcache.bin -rw-r--r--. 1 root root 77405912 Апр 18 11:40 blcache.bin [root@skat dpi]# cat blcache.bin |gzip|wc -c 3359895 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ioann Опубликовано 18 апреля, 2018 · Жалоба В 17.04.2018 в 16:44, snvoronkov сказал: по проблеме пропусков в Full NetFlow Поделитесь, что за проблема? У меня тоже есть с этим неясности - считает по разному cisco и Скат. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
snvoronkov Опубликовано 18 апреля, 2018 · Жалоба 12 минут назад, ioann сказал: Поделитесь, что за проблема? У меня тоже есть с этим неясности - считает по разному cisco и Скат. Подловил на подлоге - сканы qrator вообще в статистику не попадают. Вангую, что "более равные" адреса и их потоки пропускаются сразу, без постобработки/статистики. Icmp отлупы с клиентской стороны - есть, а вот rst-сбросов уже нет. Как и всех сканов вообще. Сравнивал с кошкиным флоу и логом серверного фаервола. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Bigmazy Опубликовано 18 апреля, 2018 · Жалоба 8 часов назад, ioann сказал: Берем запись о нарушении из отчета Ревизора, находим соответствующий flow в дампе трафика Ревизора (по времени, ip, URL), видим, что контент действительно выдался и редиректа на заглушку не было, находим соответствующий flow в netflow, снятом со Ската (на nfsen). Наличие там такого flow однозначно свидетельствует о том, что трафик прошел через Скат, а не мимо, как нам пытаются доказать. Скажите - у Вас настроена ежеминутная проверка обновлений из облака? Нетфлоу там же нет информации что запрашивалось, домен только, и переадресации может не быть при https, надо смотреть то что я написал, какой был запрос и LOCKED признак. Как минимум это помогло в ситуации с одним из операторов то же такие же претензии к нам были. Выяснили все таки оно не к нам. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ioann Опубликовано 19 апреля, 2018 · Жалоба 9 часов назад, Bigmazy сказал: Нетфлоу там же нет информации что запрашивалось, домен только, и переадресации может не быть при https Что запрашивалось и что выдано видно из дампа трафика, ибо сочетание дата/время/srcip/srcport/dstip/dstport однозначно идентифицируют этот flow. Подскажите пожалуйста где я там упоминал про https? Я Вам привел 3 примера http незаблокированных Скатом, этого мало? 11 часов назад, snvoronkov сказал: Как и всех сканов вообще Имеете ввиду не фиксирует сканы tcp-портов? Аналогично. Еще udp похоже считает на оверхед больше, чем есть. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
uk2558 Опубликовано 19 апреля, 2018 (изменено) · Жалоба С 17.04 одни и те же адреса в отчётах Изменено 19 апреля, 2018 пользователем uk2558 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
snvoronkov Опубликовано 19 апреля, 2018 · Жалоба 3 часа назад, ioann сказал: Имеете ввиду не фиксирует сканы tcp-портов? Аналогично. Еще udp похоже считает на оверхед больше, чем есть. Кстати, да. За сегодня по сканам Qrator получил именно такую картинку. Но как минимум некоторые TCP-сканы "почему-то" в статистику попадают. На объемы внимания не заостряю - "Кто как хочет, тот так скочет". Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Bigmazy Опубликовано 20 апреля, 2018 (изменено) · Жалоба 23 часа назад, ioann сказал: Что запрашивалось и что выдано видно из дампа трафика, ибо сочетание дата/время/srcip/srcport/dstip/dstport однозначно идентифицируют этот flow. Подскажите пожалуйста где я там упоминал про https? Я Вам привел 3 примера http незаблокированных Скатом, этого мало? Имеете ввиду не фиксирует сканы tcp-портов? Аналогично. Еще udp похоже считает на оверхед больше, чем есть. Похоже нашли причину. Все переведены на механизм дельт, в субботу и воскресенье, дельты при обращении выдавали полный список, только иногда он был не совсем полный: полный список до проблемы>>>> Start download Sat Apr 14 14:21:01 MSK 2018 #url keys: 75842 #domain keys: 3568 #url keys: 258196 #domain keys: 7136 не полный пришел >>>> Start download Sat Apr 14 14:22:01 MSK 2018 #url keys: 67448 #domain keys: 3568 #url keys: 198567 #domain keys: 7136 Сразу за ним пришел полный, типовой для этого дня >>>> Start download Sat Apr 14 14:23:01 MSK 2018 #url keys: 75842 #domain keys: 3568 #url keys: 258196 #domain keys: 7136 соответственно до следующей загрузки действовал не полный список, будем выяснять в РКН Причем это не единственное время 14-го, когда пришел не полный список, еще были такие же проблемы 15-го числа Изменено 20 апреля, 2018 пользователем Bigmazy Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...