Смерть классического антивируса

[Dmitry Perets 30]

Если верить аналитикам из ЛК, то овчинка не стоит выделки. Скорость проверки файлов при наличии 100 тысяч сигнатур примерно равна скорости при наличии 400 тысяч сигнатур. Разница слишком мала.

[Valery Ledovskoy 1082]

Если верить аналитикам из ЛК, то овчинка не стоит выделки.

Более того, этот вариант "для проапдейченных систем" всё равно не пройдёт. Если, например, взять почтовый сервер, то заранее угадать, пропатчена у конечного пользователя почты система или нет, практически невозможно. Заставить всех пользователей почты или антивируса апдейтить свои системы тоже малореально.

[Dmitry Perets 30]

Если верить аналитикам из ЛК, то овчинка не стоит выделки.

Более того, этот вариант "для проапдейченных систем" всё равно не пройдёт. Если, например, взять почтовый сервер, то заранее угадать, пропатчена у конечного пользователя почты система или нет, практически невозможно. Заставить всех пользователей почты или антивируса апдейтить свои системы тоже малореально.

Угу, согласен... Потом отговорки в стиле "Дык что ж вы хотите, у вас же не установлен KB8366452!" вряд ли кого-то успокоят...=)

[TiX 0]

Как известно,апдейты ОС закрывают дыры,которыми до этого (да и после,кто не апдейтывается) пользовались многие вирусы и их разновидности.Интересно,если было бы возможно те сигнатуры в базах для ускорения отключать,без которых вирусы и так не пройдут на по последнему уровню апдейтованную систему,то насколько бы в процентном отношении уменьшились размер сигнатур?И повлияло бы это на то,как realtime-защита систему загружает или нет?Ускорился бы заметно скан по требованию?

А если какойнит м-дак принесет вирус на флоппи и просто запустит Ж)

Вирус он и в африке вирус.. сам не придет так друг принесет Ж)

[nones 5]

Мм .. если обратиться к теоретической стороне вопроса, то существуют (простейшие, да просто бинарное дерево тоже подойдет) алгоритмы сигнатурного поиска, время работы которых НЕ ЗАВИСИТ от количества сигнатур (а только от длины сигнатуры). Сигнатуры просто надо специальным образом преобразовать перед применением.

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

[Z 0]

Мм .. если обратиться к теоретической стороне вопроса, то существуют (простейшие, да просто бинарное дерево тоже подойдет) алгоритмы сигнатурного поиска, время работы которых НЕ ЗАВИСИТ от количества сигнатур (а только от длины сигнатуры). Сигнатуры просто надо специальным образом преобразовать перед применением.

к сожалению это верно только для данных размещаемых в ОЗУ. но при современных ценах на память не так критично. но у цен есть другая сторона - пошли жалобы что файлы размером 64G проверяются не быстро

[TiX 0]

Ну значит надо сменить алгоритм Ж)

Если у каспа отсчет идет от EP+offset|offset то у доктора идет сравнение в виде маски от 0 и до конца файла (в основном). Поэтому при совпадении 3х кусков поиск 4того может занять время пока пропарсится Н кб файла.

У каждого метода свои + и минусы.

У доктора например этот алгоритм позволяет более проще применять его для Generic-Detection / Streaming scana.

[nones 5]

nones писал(а):

Мм .. если обратиться к теоретической стороне вопроса, то существуют (простейшие, да просто бинарное дерево тоже подойдет) алгоритмы сигнатурного поиска, время работы которых НЕ ЗАВИСИТ от количества сигнатур (а только от длины сигнатуры). Сигнатуры просто надо специальным образом преобразовать перед применением.

к сожалению это верно только для данных размещаемых в ОЗУ. но при современных ценах на память не так критично. но у цен есть другая сторона - пошли жалобы что файлы размером 64G проверяются не быстро

Ну так сигнатуры можно и попреобразовывать и алгоритм выбрать посложнее .. :-) Но даже, если брать "в лоб", то, например, для 100K сигнатур по 100b надо всего 10M - сравнимо с размерами AV баз у всех AV вендоров.

За 64G файлы надо убивать.. однозначно .. :-))

Добавлено спустя 2 минуты 15 секунд:

Если у каспа отсчет идет от EP+offset|offset то у доктора идет сравнение в виде маски от 0 и до конца файла (в основном). Поэтому при совпадении 3х кусков поиск 4того может занять время пока пропарсится Н кб файла.

Не совсем понял насчем кусков - куски сигнатуры?

[Z 0]

Ну значит надо сменить алгоритм Ж)

Если у каспа отсчет идет от EP+offset|offset то у доктора идет сравнение в виде маски от 0 и до конца файла (в основном). Поэтому при совпадении 3х кусков поиск 4того может занять время пока пропарсится Н кб файла.

У каждого метода свои + и минусы.

У доктора например этот алгоритм позволяет более проще применять его для Generic-Detection / Streaming scana.

Саня, я понимаю что вы ничего не знаете, но все же - зачем же писать всякую чушь не имея никакого представления?

Добавлено спустя 2 минуты 22 секунды:

За 64G файлы надо убивать.. однозначно .. :-))

640k should be enough for everyone, так?

расскажите это владельцам файлов

[TiX 0]

>Саня, я понимаю что вы ничего не знаете, но все же - зачем же писать всякую чушь не имея никакого представления?

Докажи что я неправ.. вперед.

[Z 0]

>Саня, я понимаю что вы ничего не знаете, но все же - зачем же писать всякую чушь не имея никакого представления?

Докажи что я неправ.. вперед.

оно мне нада? © амплуа бени хила вам к лицу, мне нравится, продолжайте.

[TiX 0]

Если ненадо то и неначинайте а то "пустой треп".

[Dmitry Perets 30]

Если ненадо то и неначинайте а то "пустой треп".

Не указывай джону что делать! Он этого не любит! =)))))

[nones 5]

TiX писал(а):

Ну значит надо сменить алгоритм Ж)

Если у каспа отсчет идет от EP+offset|offset то у доктора идет сравнение в виде маски от 0 и до конца файла (в основном). Поэтому при совпадении 3х кусков поиск 4того может занять время пока пропарсится Н кб файла.

У каждого метода свои + и минусы.

У доктора например этот алгоритм позволяет более проще применять его для Generic-Detection / Streaming scana.

Саня, я понимаю что вы ничего не знаете, но все же - зачем же писать всякую чушь не имея никакого представления?

Было бы интересно услышать ваш вариант .. :-) В двух словах, все равно это не секрет .. :-)

640k should be enough for everyone, так?

расскажите это владельцам файлов

640K это уже слишком много .. при запущенной OS в оперативку не влазит .. :-))

[Z 0]

TiX писал(а):

Ну значит надо сменить алгоритм Ж)

Если у каспа отсчет идет от EP+offset|offset то у доктора идет сравнение в виде маски от 0 и до конца файла (в основном). Поэтому при совпадении 3х кусков поиск 4того может занять время пока пропарсится Н кб файла.

У каждого метода свои + и минусы.

У доктора например этот алгоритм позволяет более проще применять его для Generic-Detection / Streaming scana.

Саня' date=' я понимаю что вы ничего не знаете, но все же - зачем же писать всякую чушь не имея никакого представления? [/quote']

Было бы интересно услышать ваш вариант .. :-) В двух словах, все равно это не секрет .. :-)

640k should be enough for everyone' date=' так?

расскажите это владельцам файлов [/quote']

640K это уже слишком много .. при запущенной OS в оперативку не влазит .. :-))

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

[nones 5]

что бы наконец-то движок KAV перестал быть в 4е раза медленее Dr.Web? в КЛ есть свои математики неплохие, пусть сами придумывают только у меня не вариант, а Знание и делиться я им не намерен

Про скорость спорить не буду, т.к. таких тестов не видел.

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

[Dr.Golova 55]

> что бы наконец-то движок KAV перестал быть в 4е раза медленее Dr.Web?

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

[Z 0]

что бы наконец-то движок KAV перестал быть в 4е раза медленее Dr.Web? в КЛ есть свои математики неплохие, пусть сами придумывают только у меня не вариант, а Знание и делиться я им не намерен

Про скорость спорить не буду, т.к. таких тестов не видел.

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

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

[A. 876]

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

бугага. жжошь, детка!

[Сергей Ильин 1538]

Пациент (классический антивирус) мертв или еще как-то выживает?

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

Если смотреть на компонентную начинку продуктов, которые продаются, то скорее мертв. Чистые антивирус без всего уже не встречаются, как минимум есть или встроенный фаервол, или HIPS или что-нибудь еще. Хотя младшие в линейках персональных продуктов пока что пользуются большим спросом и не становятся маргинальными, несмотря на переходы на IS и TS нет.

[broker 30]

скорее мертв

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

[Black Angel 125]

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

[Umnik 997]

А разве существуют классические антивирусы еще?

[Илья Рабинович 521]

А разве существуют классические антивирусы еще?

А Security Essentials?

[sergeynmsk 25]

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

Ставьте Win 7 х64 и все у Вас будет в порядке, с любым антивирусом.