Как работают алгоритмы оптимизации в продуктах ЛК

[IStogov]

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

 

Подробное описание технологий IChecker и ISwift вы можете найти здесь http://support.kaspersky.ru/faq/?qid=180593876

Если кратко, то эти технологии позволяют антивирусу понимать изменился ли файл с прошлой проверки и при определенных условиях не проверять этот файл заново.

 

В интерфейсе продуктов Касперского есть следующие настройки:

 

1. В файловом антивирусе (мониторе, который постоянно в памяти) есть настройка "проверять только новые и измененные файлы"

 

2. В проверке на вирусе (сканере по требованию) есть настройки:

"проверять только новые и измененные файлы"

и

"включить технологии IChecker и ISwift"

 

 

Рассмотрим различные варианты использования этих настроек:

 

 

A.IChecker и ISwift выключены, галка “проверять только новые файлы” выключена

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

 

 

B. IChecker и ISwift включены, а галка “проверять только новые файлы” выключена:

1. в период до следующего обновления баз файл не проверяется

2. после того как базы обновились, в течении некоторого периода с момента первой проверки файла (для сканера - n1 дней, для монитора – n2 дня) файл будет проверяться в любом случае.

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

Т.е.чем дольше файл лежит на диске без всяких изменений, тем больше к нему доверия. В начале доверия нет вообще.

 

 

C. IChecker и ISwift включены и Галка “проверять только новые файлы” включена

1.Проверяются только новые и измененные после последней проверки файлы.

2.Причем понятие новый и измененный трактуется широко: файлы, дата создания которых, отличается от текущей не более чем на n3 дня считаются новыми и проверяются также как и новые файлы.

3.Проверка новых и измененных файлов производиться в соответствии с алгоритмами ICheker и ISwift, описанными выше.

 

 

По умолчанию в продуктах Касперского технологии IChecker и ISwift включены.

Галка “проверять только новые и измененные файлы” в файловом антивирусе (мониторе) по умолчанию включена - т.е. монитор работатет по варианту С.

В проверке на вирусы (сканере) эта галка выключена, т.е. он работатет по варианту B.

 

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

 

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

Дальше произошло обновление баз, сигнатура этого зловреда попала в базу. И при очередном сканировании системы или перезагрузке зараза будет поймана и обезврежена. В этом случае ни IChecker и ISwift, ни проверка только новых измененных никак не влияют на ситуацию.

 

2.Юзер скачал зловреда под видам картинки неопределенного содержания, но заподозрил неладное. При этом в базах касперского этого зловреда не было, поэтому файловый антивирус (монитор) молчит. Юзер проверил файл зловреда на вирусы (сканером), но так сигнатуры нет - нулевой результат.

Далее либо он его запускает, тогда пукт первый.

Либо ждет пока придет новое обновление баз в надежде, что там уже будет сигнатура этого зловреда (может быть юзер даже сам послал подозрительный файл в вирлаб на анализ).

Вот пришло обновление, в котором есть сигнатура зловреда.

Нормальный пользователь снова проверяет вирус сканером, в сканере включены только IChecker и ISwift (галка тока новые и измененные не стоит), поэтому т.к. призошло обновление баз, файл будет проверен и зловред пойман.

Больной на голову пользователь файл запустит, вроде бы в файловом антивирусе (мониторе) включена проверка тока новых и измененных и файл не будет проверен и случится заражение!! Но нет, помните что файл считается новым аж n3 дня.Так что все поймается, зловред погибнет.

 

3.Юзер скачал зловреда под видам картинки неопределенного содержания

Файловый Антивирус молчит, так как нету сигнатуры. Юзер спешит и решил посмотреть картинку позже. Через какое-то время он возвращается. За время его отсутствия антивирус обновился и получил сигнатуру данного зловреда. Юзер открывает папку, и запускает файл. Вроде бы в файловом антивирусе (мониторе) включена проверка тока новых и измененных и файл не будет проверен и случится заражение!! Но нет, помните что файл считается новым аж n3 дня.Так что все поймается, зловред погибнет.

 

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

 

Некоторые мне возразят: "нет нет этот случай вполне обычный, я постоянно так делаю. Скачаю бывалыча файл, а потом через месяц про него вспомню." Но друзья мои, почему вы тогда не ругаетесь, что в настройках по-умолчанию не стоит в файловом антивирусе проверка составных инсталляционных пакетов? Или же галка проверять Все файлы не стоит? Ведь существуют случаи, когда эти нестоящие галки могут привести к заражению, другой вопрос какова вероятность этих случаев. А она мала, так же как мала вероятность погореть из-за включенных алгоритмов оптимизации(IChecker и ISwift, проверка тока новых и измененных).

Эксперты ЛК считают, что эта вероятность находится в таких пределах, что можно рекомендовать пользователю использовать именно такие настройки (рекомендации эта выражена в настройках по умолчанию продуктов ЛК). Для тех, кто с рекомендацией не согласен: используйте уровень защиты Высокий или же задавайте настройки сами.

 

 

Теперь о случаях, когда юзер говорит: нет у меня этот файл все таки не детектится при повторной проверке, алгоритмы все же дырявые.Тогда совет такому юзеру таков:

1.Убедитесь, что вы используете настройки по умолчанию или по крайней мере не ослабили защиту своими эксперментами с настройками

2.Если все настройки выставлены, то это бага, но бага не в логике работы алгоритомов оптимизации, а в их реализации. Чтож от баг не застрахован никто, обращайтесь к разработчику и давайте максимум доступной вам информации по вашей ситуации. Разработчики готовы слушать: http://forum.kaspersky.com/index.php?showt...mp;#entry318603

[Pipkin]

1. Хороший материал. Осталось уточнить эффективность iChecker/iSwift при обновлениях, например, ежечасных.

2. Ну и рекомендаций. Например, наиболее предпочтителен вариант С, как наиболее оптимальный по соотношению надежность детекта—ресурсопотребление (тормоза). В таком роде.

3. Все это нужно в Хэлп к кисе пусть и мелким шрифтом (петитом).

[IStogov]

1. Хороший материал. Осталось уточнить эффективность iChecker/iSwift при обновлениях, например, ежечасных.

2. Ну и рекомендаций. Например, наиболее предпочтителен вариант С, как наиболее оптимальный по соотношению надежность детекта—ресурсопотребление (тормоза). В таком роде.

3. Все это нужно в Хэлп к кисе пусть и мелким шрифтом (петитом).

 

плохой материал раз есть такие вопросы

1.эффективность iChecker/iSwift высока так ка во-первых их данные проверка тока новых и измененных использует, чтоб понимать чего проверять, чего нет

2. как я уже говорил, но видно недостаточно четко, iChecker/iSwift работают так:

a.вы проверили файл

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

в.базы обновяться хотя бы один раз и после этого файл будет обязательно проверяться некоторое время (дни)

г.по истечении этого периода (дней) вне зависимости от обновления баз файл будет проверяться уже не всегда и причем чем дольше он лежит без изменений, тем реже проверяется