Задай вопрос Виктору Яблокову-2!

[SevereK 5]

On 16.07.2023 at 20:01, Umnik said:

Как тестировщик могу сказать. Сценарии проверяются. Каждый релиз или нет — это на решение ответственного. Только задача тестировщика не устранить проблему, а обнаружить и сообщить о ней. Тестировщики гарантировано нашли плохое поведение, гарантировано записали это в багтрекер и поставили _низкую важность_. Почему низкую:

— Не является настройкой по умолчанию

— Не включается большинством пользователей

— Не ухудшает работу _защиты_. Лишь создаёт неудобство.

 

По типичной таблице уровней важности _недобство_, создаваемое _не стандартными_ и _не популярными_ настройками являются низкими по важности. Менеджер может поменять _приоритет_ (это его поле), но вряд ли это сделал. ТП не сообщает о массовых жалобах, а значит причин для изменения ситуации просто нет.

 

В общем, всё там проверяется. Все знают, что вот так. Но делать ничего не будут до тех пор, пока либо не наберётся критическая масса запросов в ТП, либо вы, как форумчане, не накапаете на мозг кому-то высокому. Но не Е.К., т.к. он не отвечает за продукты. Тут кто-то уровня Тимура или Сергея.

 

Да, мне тоже не нравится, когда в продуктах такое есть. Потому те продукты, на которые я могу влиять, не имеют настроек, которые не работают Лучше меньше галок, но всё, что есть - работает. А у продуктов ЛК исторически другой подход был - глубокая кастомизация. Они потихоньку пытаются скрывать галки, но не могут кардинально поменять UX, иначе вой до небес будет.

 

К тестированию вряд ли стоит предъявлять претензии Как раз тестирование-то знает, что и как работает _на самом деле_.

То есть на протяжении 10 лет(ДЕСЯТЬ ЛЕТ!) в продукте фактически отсутствует возможность использования фаервола в ручном режиме и это не считается проблемой потому что мало кто его использует в таком режиме?))))

Отличный ответ если бы речь шла про opensource продукт энтузиаста, который по мере появления свободного времени потихоньку пилит свой продукт, не давая никаких гарантий.

А вопрос рейтингов антивирусов и прочее совсем не заботит разработчиков одного из наиболее популярных продуктов? Вдруг платеж не пройдет рано или поздно?..

 

Почему в ответ на вопросы об этом не говорится прямо что продукт не поддается ручной настройке? И зачем вот это

 

On 11.07.2023 at 13:56, dkhilobok said:

Будем очень рады узнать подробнее про ваш опыт использования Firewall в ручном режиме. Детальное описание проблемы очень поможет нам в улучшении функционала Firewall’а.

 

Если все давно об этом осведомлены?

В общем да, читать это было очень печально

 

В совокупности с воспоминанием про баг с неправильный источник энтропии для ГПСЧ в KPM (а нафига об этом париться, ведь этого не видно пользователю!)))))) складывается четкая картинка что куда важнее маркетинговая составляющая в виде бесполезных напоминалок об находящейся под чуткой защитой касперского веб камере, защите клавиатуры и тд

 

В общем если впереди планируются интервью с экспертами ЛК, спешу задать свои вопросы:

1. Когда в KS появится тетрис?

2. Когда в KS будет интегрирован прогноз погоды?

3. Когда в KPM будет интегрирована возможность для указания ингридиентов  и их количества для кулинарных рецептов?

4. Надежно ли в KPM защищено поле Password, которое предназначено для указания секретного названия блюда?

5. Когда в KPM появится таймер, который можно будет использовать как помощник при приготовлении кулинарных блюд?

6. Когда в KS появится сверхзащищенный модуль просмотра с виду безобидных .txt файлов?

 

 

[Umnik 1 270]

48 minutes ago, SevereK said:

То есть на протяжении 10 лет(ДЕСЯТЬ ЛЕТ!) в продукте фактически отсутствует возможность использования фаервола в ручном режиме и это не считается проблемой потому что мало кто его использует в таком режиме?))))

Да. Именно так. Я более чем уверен, что многие в команде топят, чтобы галки вообще не было. Но, видимо, она нужна для каких-то имиджевых вещей.

50 minutes ago, SevereK said:

А вопрос рейтингов антивирусов и прочее совсем не заботит разработчиков одного из наиболее популярных продуктов?

Вроде в рейтингах постоянно всё норм. Значит заботит, раз постоянно побеждает

1 hour ago, SevereK said:

Почему в ответ на вопросы об этом не говорится прямо что продукт не поддается ручной настройке?

Не поддаётся там, где нужно тебе. Это не совсем тоже самое, что "нельзя настроить". Уверен, там в галках есть ещё ворох тех, которые работают не так, как хотелось бы, просто тебе они не нужны. Но нужны другому Васе и он тоже переживает. И вот вас двое - ты за одну галку, он за другую переживает.

 

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

 

// я не имею отношения к ЛК, если что. Я просто тестировщик в другой фирме и описываю, как обычно всё это устроено.

[SevereK 5]

20 minutes ago, Umnik said:

Не поддаётся там, где нужно тебе. Это не совсем тоже самое, что "нельзя настроить". Уверен, там в галках есть ещё ворох тех, которые работают не так, как хотелось бы, просто тебе они не нужны. Но нужны другому Васе и он тоже переживает. И вот вас двое - ты за одну галку, он за другую переживает.

Именно по этой причине я и спрашивал про сценарии тестирования с точки зрения ЛК

Потому что именно того режима, который есть во всех нормальных продуктах, нет в KIS/KS

И речь не о каких-то замысловатых сценариях, а о классическом ручном режиме

 

21 minutes ago, Umnik said:

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

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

22 minutes ago, Umnik said:

Вроде в рейтингах постоянно всё норм. Значит заботит, раз постоянно побеждает

Ну я ж говорю про случай, если платеж вдруг когда-то не пройдет

[Umnik 1 270]

Задача тестировщика — выяснить поведение. QA знает это поведение, QA завели баг в багтрекере с нужной важностью. На этом работа тестирования прекращена. Не у тех спрашиваешь. А норм им или нет — это вопрос на поболтать. Люди из тестирования, они такие. Ты им скажешь "вот это плохо" и на любое твое "это плохо" они засмеются и скажут, что ты даже не знаешь, ГДЕ И НА СКОЛЬКО РЕАЛЬНО ПЛОХО :)) На то это и тестировщики.

 

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

 

Я, кстати, живу без фаервола и не очень понимаю, зачем он мне нужен. Хотя могу установить тот же OpenSnitch. Но я и не на Windows, конечно.

[SevereK 5]

1 hour ago, Umnik said:

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

Конечно интересно было бы послушать кого и что не устраивало в работе фаервола в версии до 13 (включительно) и устроило в говнище в которое превратился KIS с версии 14. Прям без сарказма было бы интересно услышать

 

1 hour ago, Umnik said:

Задача тестировщика — выяснить поведение. QA знает это поведение, QA завели баг в багтрекере с нужной важностью. На этом работа тестирования прекращена. Не у тех спрашиваешь. А норм им или нет — это вопрос на поболтать. Люди из тестирования, они такие. Ты им скажешь "вот это плохо" и на любое твое "это плохо" они засмеются и скажут, что ты даже не знаешь, ГДЕ И НА СКОЛЬКО РЕАЛЬНО ПЛОХО :)) На то это и тестировщики.

Да я не конкретно к тестировщикам претензии предъявляю. Просто пытаюсь понять как так может получаться, про отсутствие тестировщиков закрались подозрения из-за этого:

Quote

1. При тестировании приложения прорабатываются сценарии использования компонента сетевой экран в ручном режиме? Есть шанс взглянуть на эти сценарии? Действительно ли был проработан сценарий, когда пользователь снимает галочку "Выбирать рекомендуемое действие автоматически"? Он без проблем отыскал ее в очень "подходящем" для нее разделе? И ему даже не потребовалось для этого смотреть на неправильную подсказку (в которой указано неверное расположение)? Мне кажется удивительнейшим что все это могло остаться незамеченным. Разве что такое тестирование вообще не проводится, во что сложно поверить, но, смотря на компонент Сетевой экран в версиях 13-22 - вполне себе начинает верится...

Или тикет на неверное расположение был создан с наименьшим приоритетом и его задвинули подальше с формулировкой "кто же в продуктах касперского кноку Настройки нажимает?"?)))))))))))))))))) Можете, как тестировщик, предположить?

В совокупности с отсутствием фаервола в продуктах на протяжении уже 10 лет версия об отсутствии тестирования мне кажется вполне логичной.

1 hour ago, Umnik said:

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

Мне вот подумалось. А что если ЛК пошла не простым путем заимплементив фаервол как в нормальных продуктах, а решило сперва поднять уровень владения ПК пользователей, дождаться когда они попросят и тогда уже встречайте Kaspersky Imunno Supersecurity 35 с фаерволом на борту) да еще и со встроенной OS с защитой роутера (и отключенного, и соседского). Тогда и идея про Университет Касперского вполне логичной выглядит, и возвышенные рассуждения о киберимунной ОС 😅

Изменено 17 июля пользователем SevereK

[kmscom 2 206]

6 часов назад, SevereK сказал:

Конечно интересно было бы послушать кого и что не устраивало в работе фаервола

Если он должен спрашивать разрешение на каждое соединение, но не спрашивал, ограничившись вопросом на первое соединение, то это неправильно.

 

Настроить запрет или разрешение на соединения, можно. Но если это соединение не подпадает под условия в правиле запрета или разрешения , то должен спросить.

Я не вижу причин, почему должна быть другая логика? Потому что это неудобно вам?  

 

7 часов назад, Umnik сказал:

А норм им или нет — это вопрос на поболтать.

 

[SevereK 5]

10 часов назад, kmscom сказал:

Если он должен спрашивать разрешение на каждое соединение, но не спрашивал, ограничившись вопросом на первое соединение, то это неправильно.

Это правильно. Потому что если создается правило разрешающее любую сетевую активность, то какой смысл слать еще 20 алертов? С формальной точки зрения это может быть и неправильно, но этим удобно и МОЖНО пользоваться и именно таким путем реализован фаервол в нормальных продуктах.

В KIS/KS за все время когда я задаюсь этим вопросом я не встречал людей, которые бы сказали что процессят сотни алертов для одного приложения и им удобно. Только такие как вы - пользуются автоматическим режимом, а про ручной только слышали в теории и "им это не нужно"))

 

 

Но в общем-то именно по этой причине я и прошу тест-кейсы. Если для специалистов ЛК это действительно ОК и их устраивает что KIS/KS - это скорее сетевой дебаггер, чем комплексный антивирус с фаерволом, и они видят реальные сценарии использования продукта с миллионами алертов - у меня, пожалуй, отпадут все вопросы

 

[Destiny 6]

Возможно это любитель и/или разработчик WireShark'a у них на службу нанялся? Вот и переиначили они всё под "сетевой дебаггер"))))

Ибо файрволл разработать уже не судьба...

Хотя казалось бы - вокруг еще столько  этих "комплексных" продуктов и у большинства нормальный "путь самурая" при работе с их файрволами. Но тут решено сделать что-то ну уж очень своё....

[Umnik 1 270]

1 hour ago, SevereK said:

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

Никакого. Просто исправление поведения очень дорогое. Алерты УЖЕ выстроились в очередь. И таких алертов в очереди может быть множество, часто из которых тоже на любой коннект, часть - вообще о другом. Чтобы правильно отменить только те алерты, которые были вызваны в том же самом Context, нужно определиться:

• что будем считать одним контекстом? Брать просто процесс, наверное, нельзя, желательно брать процесс с родителями. Потому что одно дело, когда Хром запущен Проводником, а другое - когда проводник запустил троян.ехе, а тот запустил Хром, не так ли? Или всё же контекст - это 1 процесс?
• будем ли считать контекстом аргументы запуска процесса? К пример в Linux eBPF умеет это делать. В итоге просто перестановка аргументов запуска создаёт новый тип подключения, для которого нужны новые правила. То есть если Хром запущен с --verbose 1 каким-нибудь, а потом с --verbose 2 — это одно и тоже? А если --arg1 --arg2, а потом --arg2 --arg1 — это одно и тоже? Для eBPF это всё разные вещи, к примеру. И всё это требует своих правил
• если родительский процесс, тот же Хром, создаёт 100500 дочерних, какие правила к ним применяем? И, чтобы два раза не вставать будем ли учитывать аргументы для каждого из них?
• как нужно себя вести, если процесс биндится к запущенному сервису с уже надиктованными правилами?
• что делаем с каждым контекстом, пока по нему не принято решение? Можно не давать подключиться и это, вроде, правильно даже. Но как не давать - REJECT или DROP?
  • Какой бы вариант не выбрали. Пользователь ткнул в некое действие в алерте, но контекст решил к тому времени помереть. Что делаем с этим правилом? Записываем куда-то или забиваем и просто отбрасываем?

Это я ещё не все проблемы рассмотрел. Только то, что мне очень просто вспомнить, т.к. на прошлой неделе я как раз занимался именно сетевыми подключениями и как раз с этими вопросами разбирался.

 

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

 

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

• Запрет всего по умолчанию с записью конкретных данных конктекста в БД: адрес, порт, протокол, аргументы запуска, пользователь
• Запустить всё, что нужно в минимуме. Это само ОС, менеджер сетей и пакетный менеджер
• По созданным запретам в БД создать наиболее точные правила, но достаточно универсальные, чтобы в сумме их было не более 5-7 на программу
• Удалить все запреты
• Повторять цикл, пока запрещено будет только то, что мне правда не нужно, а всё остальное будет корректно разрешено

За неделю я не справился. Один запуск vscode создаёт миллион разных запретов, к примеру.

[SevereK 5]

48 minutes ago, Umnik said:

Никакого. Просто исправление поведения очень дорогое. Алерты УЖЕ выстроились в очередь. И таких алертов в очереди может быть множество, часто из которых тоже на любой коннект, часть - вообще о другом. Чтобы правильно отменить только те алерты, которые были вызваны в том же самом Context, нужно определиться:

• что будем считать одним контекстом? Брать просто процесс, наверное, нельзя, желательно брать процесс с родителями. Потому что одно дело, когда Хром запущен Проводником, а другое - когда проводник запустил троян.ехе, а тот запустил Хром, не так ли? Или всё же контекст - это 1 процесс?
• будем ли считать контекстом аргументы запуска процесса? К пример в Linux eBPF умеет это делать. В итоге просто перестановка аргументов запуска создаёт новый тип подключения, для которого нужны новые правила. То есть если Хром запущен с --verbose 1 каким-нибудь, а потом с --verbose 2 — это одно и тоже? А если --arg1 --arg2, а потом --arg2 --arg1 — это одно и тоже? Для eBPF это всё разные вещи, к примеру. И всё это требует своих правил
• если родительский процесс, тот же Хром, создаёт 100500 дочерних, какие правила к ним применяем? И, чтобы два раза не вставать будем ли учитывать аргументы для каждого из них?
• как нужно себя вести, если процесс биндится к запущенному сервису с уже надиктованными правилами?
• что делаем с каждым контекстом, пока по нему не принято решение? Можно не давать подключиться и это, вроде, правильно даже. Но как не давать - REJECT или DROP?
  • Какой бы вариант не выбрали. Пользователь ткнул в некое действие в алерте, но контекст решил к тому времени помереть. Что делаем с этим правилом? Записываем куда-то или забиваем и просто отбрасываем?

ну да, вопросы сложные. смотреть как это реализовано в нормальных продуктах и как это было в KIS 13 - не надо))))

Надо изобрести KIS 14, который формально будет давать полную свободу пользователю в настройке правил, заваливая миллионом аллертов с которыми не понятно что делать (даже не показывая родительский процесс, запустивший программу) )))))
То что свалились все существующие тест кейсы - то пофиг, когда-нибудь разберемся)))) ну и что 10 лет разобраться не можем - в принципе, не проблема)))))

В общем наша имплементация - плохой, которой нельзя пользоваться (но мы ее тестируем перед каждым релизом! но тест-кейсы или просто словесное описание КАК это делаем предоставить не можем - потому что это тайна!), конкуренты - ничего не понимающие дураки)

[Umnik 1 270]

тест кейсы — это часть внутренней документации. Документация защищена NDA. Ни одна компания в здравом уме не предоставит свои внутренние документы публично.

[SevereK 5]

7 minutes ago, Umnik said:

тест кейсы — это часть внутренней документации. Документация защищена NDA. Ни одна компания в здравом уме не предоставит свои внутренние документы публично.

Я уже упоминал что я не прошу тест-кейсы в явном виде. Я прошу просто сценарий в котором описывается как проверяется ручной режим

 

Изменено 18 июля пользователем SevereK

[kmscom 2 206]

16 минут назад, SevereK сказал:

Я прошу просто сценарий в котором описывается как проверяется ручной режим

Если запросы идут, то все в порядке. 

[SevereK 5]

4 minutes ago, kmscom said:

Если запросы идут, то все в порядке. 

Ну это у вас все в порядке))))))

Мне бы хотелось услышать ответ