Перед тем, как выбрать"надежный антивирус" стоит.. - Выбор домашних средств защиты - Форумы Anti-Malware.ru Перейти к содержанию
Евгений

Перед тем, как выбрать"надежный антивирус" стоит..

Recommended Posts

Евгений

Доброго дня! Мне на глаза попалась статья - что скажете коллеги?

Почему не срабатывают антивирусы?

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

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

Какой из этого выход? Разумеется разделение специализаций, с последующим обменом научными достижениями, принимая "на веру" достижения коллег. Может быть это немного утрировано, но все же недалеко от истины. Во всяком случае именно такая ситуация сложилась в антивирусной индустрии.

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

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

Поэтому следует с большим недоверием относиться к сообщениям антивирусов. Если вирусов не найдено, то это следует понимать буквально - т.е. их и в самом деле просто не найдено,но это не намек что их и в действительно нет. То же относится и к утверждениям о зараженности файлов. Достаточно часто случается, что антивирус находит вирус там, где нет и следа последнего.

Положение усугубляется ошибками разработчиков и пользователей. Очень часто антивирусами пользуются неправильно, чем и объясняется неудовлетворительный результат их работы. При этом руководства пользователя обычно содержат даже больше ошибок и упущений, чем сам продукт. К примеру рассмотрим рекомендацию запуска антивируса с "чистой" дискеты. Безусловно практически всегда так и следует поступать, потому что в противном случае трудно гарантировать,что антивирус корректно нейтрализует резидентную часть вируса. Несмотря на то, что современные антивирусы обычно это делают достаточно качественно, в некоторых случаях подобная процедура опускается или просто не срабатывает. Если это произойдет с вирусом, заражающим файлы при их открытии (закрытии), то после сканирования окажутся зараженными все проверяемые файлы. Особенно часто это происходит в новыми, не еще детектируемым вирусами, резидентную часть которых гарантированно ни обнаружить, ни нейтрализовать не представляется возможным. В общем случае можно утверждать, что детектированиелечение вируса не должно выполняться при активной резидентной части вируса.

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

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

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

Действительно, как мы видим использование современных антивирусов дело не простое. Пользователь постоянно оказывается на распутье выбора решения, особенно после сообщений в стиле "по адресу 9876:0102 возможно находится резидентный вирус". Специалисту достаточно по указанному адресу взглянуть дизассемблером, но даже и без оного по приведенным цифрам он уже может многое сказать о резиденте. Так например, расположение в верхних областях нижней памяти уже указывает на нестандартный способ посадки резидентной копии, а смещение 0x102 свидетельствует о том, что резидент с большой вероятностью "вылез" из com-фала - 0x100 - на PSP и 2 байта на короткий переход на процедуру инициализации.

Разумеется, что все это доходчиво объяснить простому пользователю не затратив кучу времени и усилий просто невозможно. Какой из этого выход? Предоставить лечение вирусов специалистам? Фактически так оно и есть, но мало кто может себе позволить оплатить выезд сотрудника антивирусный фирмы, особенно если ценность обрабатываемых данных оказывается меньше или сравнимой с стоимостью подобного сервиса.

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

Сегодня доминирует последняя тенденция. И даже некогда профессиональный "AVP PRO" сегодня уже лишен многих "вкусностей". Исчезла возможность ручного создания баз, в комплекте отсутствует утилита trsutil (интегрированный отладчикдизассемблер, разработанный для поиска и нейтрализации вирусов). С одной стороны в этом есть свои несомненно положительные черты, но и вместе с возникшей простотой использования (многие пользователи просто не знали что делать с trsutil, а уже вид команд ассемблера и вовсе вызывал полное недоумение) падает качество продукта. Почему? Да потому что автомат. Автомат, который действует каждый раз по одному и тому же шаблону и оказывается бессильным даже в простых, но нестандартных ситуациях. И уже нет никакой возможности "пройтись" по векторам прерываний или хотя бы карте памяти.

При этом пользователь оказывается лишен возможности не только вмешиваться в процесс, но даже контролировать происходящее. Допустим, некий файл подозревается эвристическим анализатором на вирус. Что с ним сделать? Стереть? Но уничтожит ли это вирус и кроме того как быть если отсутствует резервная копия? А вдруг это всего лишь безобидное "ругательство" антивируса? Хорошо бы узнать причину его возникновения. В противном случае подобная информация просто лишена смысла и попросту бесполезна. Большинство пользователей чаще встречаются с ложными срабатываниями эвристических анализаторов, нежели с точными попаданиями и рано или поздно отключают эвристический анализатор (при этом попутно выигрывая и в скорости сканирования).

Некоторые антивирусы наподобие F-PROT выдают содержимое внутренних флагов эвристического анализатора, предоставляя пользователю возможность проанализировать причины "неудовольствия" антивируса самостоятельно. К сожалению для многих из них эта информация ни о чем не говорит, и они предпочитают антивирусы, работающие полностью в автоматическом режиме, и не задающие непонятных вопросов. Любопытно, что и у профессиональных пользователей подобные продукты не пользуются успехом. Для вынесения окончательного решения "вирус - не вирус" требуется взглянуть на подозреваемый файл в дизассемблере. Разумеется, что подобное для массового рынка не приемлемо и никогда и никем не было реализовано. (Единственным антивирусов содержащим интегрированный отладчик и ориентированным на профессионального пользователя вероятно является x-safe).

Заметно больше верят дисковым ревизорам, особенно работающими в обход 0x13 (наподобие ADinfo). Считается, что последние практически невозможно "обмануть" и на результаты сканирования можно положиться. Увы - это вывод основан не более чем на безосновательной вере и зиждется на незнании. На самом деле есть множество эффективных алгоритмов, которые позволяют вирусу остаться незамеченным. Например, если файлы будут заражаться через некоторые промежутки времени (скажем в несколько минут), то тогда в течении сканирования могут оказаться зараженными уже проверенные файлы. Запуск с чистой дискеты это мог бы предотвратить, но при этом ADInfo не сможет обнаруживать Staelth-вирусы, да и все же далеко не для всех случает такая загрузка возможна. Например в NT с дисковой системой NTFS грузиться с досовской дискеты просто бессмысленно, поскольку оттуда соответствующие разделы диска просто не будут видны.

При этом вирус Antiх8-ADinfo не смотря на постоянное сканирование диска ревизорами (и удаления всех загаженных файлов) будет обнаруживаться вновь и вновь до той поры пока пользователь в ярости не удалит с диска все файлы или разработчики антивирусов не включат его в базы данных. Впрочем, насколько мне известно последние версии AVP и DrWeb его не детектируют. К счастью пока данное "насекомое" с завидно медленной скоростью кочует с машины на машину, распространясь только через загрузочные сектора жестких дисков, но это не может служить поводом для беспечности. (Любой другой вирус, использующий те же алгоритмы может распространяться не в пример быстрее).

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

Быть может в этом виноваты не разработчики, а рекламные агенты? Ведь именно они, а ни кто другой приписали товару свойства, которыми он мягко говоря и не претендовал обладать. Действительно, искусство рекламы - это умение преподнести дезинформацию ни разу при этом ни солгав. Например, утверждается, что некий эвристический алгоритм находит 97% всех вирусов. Но означает ли это, что хотя бы в девяти из десяти случаев новый вирус будет обнаружен? Это зависит от того как была получена эта цифра "97". На самом деле новыми могут считаться только те вирусы, которые были написаны после выхода данного антивируса "в свет", т.к. большинство вирусописателей заботится об том, что бы их детища попали как раз в те самые "3%", которые эвристик не обнаруживает. Никто не спорит, что это удается не всем и какая-то часть вирусов все же будет обнаружена. Однако, разумеется, что результат будет далек от 97%, особенно учитывая быстрое развитие вирусных технологий и интенсивный обмен удачными решениями между вирусописателями. В последнее время растет доля вирусов, написанных на языках высокого уровня. Пока эвристики не способны различить и процента от таких созданий. Откуда же тогда взялась такая заманчивая цифра 97? Да очень просто - это процент обнаруженных вирусов от всех существующих в коллекции разработчика экземпляров. Разумеется, что большую часть из них представляют "академические" и ныне уже не встречаемые образцы наподобие сотен модификаций классической "Виенны".

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

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

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

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

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

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

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

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

У ранних версий антивируса Касперского был неприятный баг - с целью оптимизации автор реализовал проверку на вирус по двум контрольным суммам сигнатуры - первоначально сверялась короткая контрольная сумма, если она совпадала, то затем сверялась длинная. Но при разработке была допущена ошибка и при не совпадении второй контрольной суммы, файл считался незараженным вообще. Т.е. если у двух и более записей короткие CRC совпадали, то проверялась только первая из них! Пока объем базы был небольшим, в вероятность совпадения небольшой - этот баг никак внешне не проявлялся. С добавлением новых записей появились и такие, чьи короткие CRC совпадали и новые вирусы перестали определяться.

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

Остается надеяться только на результаты тестирования независимых лабораторий. Периодически отчеты последних появляются на страницах различных журналов и изданий.

Дисковые ревизоры имеют гораздо более высокую вероятность обнаружения новых вирусов и при этом обычно достаточно быстро работают. К сожалению главный их недостаток - невозможность распознать вирус в изначально зараженном файле (за тем исключением, когда он заражен Стелс вирусом). Это очевидно приводит к тому, что хотя бы один файл остается зараженным, образуя активный очаг распространения "инфекции". А учитывая, что практически все вирусы мы как правило получаем через "вновь прибывшие файлы" становится ясно, что ревизор будет бессилен различить в каком из них сидит "зараза".

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

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

Поскольку мы затронули получение программного обеспечения, то остановимся на этом моменте. Все наши беды происходят от того, что тот, у кого мы "скачиваем" файлы оказывается не "стерильным" человеком и вместе с собой заражает еще и нас. Уж сколько раз твердили миру - не копируйте файлы из ненадежных источников. Приобретайте ПО только у производителей и крупных диллеров. Избегайте BBS и не скачивайте все, что не встретиться из Интернета. К сожалению этими рекомендациями практически всегда пренебрегают, надеясь на "авось пронесет".

Заметим, что сегодня даже у крупных пиратов ПО большей частью свободно от вирусов и они в этом отношении ничуть не уступают легальным производителям, поскольку и тем и другим приходится бороться за свой авторитет. К сожалению того же нельзя сказать о многих "Домашних страничках" и держателей BBS. И те и другие уязвимы для взлома и подмены расположенного на них ПО, чем с успехом пользуются многие вирусописатели. Про конференции даже и говорить не стоит. Риск подхватить вируса или троянца в распространяемых вместе с письмами файлах невероятно велик.

Антивирус как и любое другое ПО точно так же может быть заражен. При этом злоумышленник мог отключить встроенный контроль своей целостности, так что бы конечный пользователь ничего не заподозрил. Поэтому ни в коем случае не рекомендуется копировать антивирус с непроверенных источников. Менее очевидным покажется запрет на копирование любого компонента антивирусного пакета - будь то пополнение базы или даже файл помощи! Дело в том, что в большинстве случает "апдейты" содержат бинарный код, в котором злоумышленник мог разместить все что угодно. Аналогично и файл помощи, в котором возможно наличие исполняемого бинарного кода. Например в Антивирусной Энциклопедии Касперского используется очень витиеватый формат файла помощи, который помимо текста может содержать ссылки на произвольные ресурсы, в том числе и исполняемый код.

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

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

Дело в том, что в большинстве случаев используется алгоритм "сетчатой решетки". Т.е. если некий объект обладает определенными признаками, то он "захватывается" узлом решетки или "проваливается" для уточненного анализа. В результате ошибок некая запись может захватить признаки остальных. Теоретически при этом объект должен "провалиться" для уточнения, но если в этом месте будет допущена ошибка, то этого не произойдет и остальные записи базы просто не получат управления! Рассмотрим это на следующем (хотя и "искусственном") примере. Пусть будет создана запись, которая, реагирует на сингартуру 'MZ' (заголовок любого exe файла). И пусть она отрапортует антивирусу, "этот файл вируса не содержит, и больше проверять его не надо". Или как вариант - "это не исполняемый файл", "это не exe файл, а com".

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

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

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

Кроме того некоторые вирусы содержат интересный деструктивный алгоритм, который заставляет некоторые антивирусы испортить диск пользователя. Достигается это очень просто - вирус содержит в себе штамм другого вируса, поэтому неправильно определяется, а значит и и лечиться антивирусом. Иногда последствия последнего становятся очень печальными.

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

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

Так же появилась информация об антивирусах, реализованных аппаратно и работающих через параллельный порт, однако пройдет еще немало времени пока они выйдут из лабораторий в массовое употребление. Будем надеяться, что их надежность заметно превзойдет лучшие программные реализаций, иначе их просто не будут покупать. Самое интересное, что это похоже на правду. В предлагаемой реализации есть по меньшей мере одна ошибка - с LPT порта невозможно взаимодействовать с жестким диском непосредственно, поэтому необходим драйвер, обеспечивающий такой обмен данными. Разумеется последний реализовывается чисто программно и легко может быть модифицирован вирусом. Трудно поверить, что разработчики об этом не догадываются - скорее всего просто они поступают так под давлением обстоятельств, ибо любое другое решение заметно удорожает конечный продукт (например, можно было его выполнить в виде PCI платы расширения).

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

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

На самом деле антивирус использует методы лечения, доставшиеся ему "по наследству" от предыдущих версий. При этом многие из них полагались на "чистый" запуск и не обезвреживали резидентный модуль вируса. Конечно, разработки по возможности учитывают перерабатывают подобные моменты, но маловероятно, что бы они отважились полностью переработать все базы. Слишком утомительно и неэффективно, кроме того всегда остается вероятность, что некоторые записи окажутся упущенными и не переработанными. С другой стороны, а нужно ли win32 антивирусу проверять DOS-файлы?

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

Вышесказанное относилось большей часть к полифагам, однако верно и для всех других антивирусов. Нет такого продукта, на который можно было бы положиться. Самое удивительное, что часто несложные и компактные утилиты малоизвестных фирм справляются с вирусами иной раз лучше, чем популярные пакеты (например KPRO, занимая всего 3 с небольшим килобайта, надежно удаляет все стелс вирусы из загрузочных секторов), используя их свойство маскировки или просто перезаписывают загрузчики на стандартные через порты вводавывода, т.е. таким способом, перехватить который вирус уже не в состоянии. С другой стороны как и любой другой продукт малоизвестных фирм этот антивирус не без ошибок, так например, пропущен один CLI в MBR-загрузчике и регион HMA отнесено почему-то к BIOS, поэтому этот антивирус начинает работать некорректно, если DOS загружена в верхнюю память.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Николай Головко

Сколько лет этой статье?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Денис Лебедев

Слуш-те, а в кратце кто-нить в двух словах может рассказать про что там? 8) :D

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Пит
Слуш-те, а в кратце кто-нить в двух словах может рассказать про что там?

Бесконечность и хаос... :lol:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Евгений
Сколько лет этой статье?

Вобшем статья минувших лет... :) и прошу прошения, что разместил столь длинный пост... но прочитать стоит... хотя для обшего развития не помешает.

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

Лично из своего опыта (F-Secure, NOD32 Enterprice, Trend Micro (OfficeSCAN), Panda (AdminSecure Corporate) + KAV 6 ) - все рано или поздно либо збоит на уровне сисемных ошибок, либо либо начинают выпускать обновления которые приводят в лучшем случае к отключению антивируса. За последние 5 лет наметились тенденции на улучшение, но до сих пор нет продукта, который бы обеспечивал должную зашиту, скорость работы и не возникало бы ситуаций с проблемными обновлениями....

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Олег Рагозин

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

:)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Николай Головко
Сколько лет этой статье?

Вобшем статья минувших лет... :) и прошу прошения, что разместил столь длинный пост... но прочитать стоит... хотя для обшего развития не помешает.

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

Лично из своего опыта (F-Secure, NOD32 Enterprice, Trend Micro (OfficeSCAN), Panda (AdminSecure Corporate) + KAV 6 ) - все рано или поздно либо збоит на уровне сисемных ошибок, либо либо начинают выпускать обновления которые приводят в лучшем случае к отключению антивируса. За последние 5 лет наметились тенденции на улучшение, но до сих пор нет продукта, который бы обеспечивал должную зашиту, скорость работы и не возникало бы ситуаций с проблемными обновлениями....

Правда? Ну не знаю, не знаю... ;)

Кое в чем автор прав. Например, при рассмотрении взаимодействия с пользователем. Я достаточно хорошо знаю и могу подтвердить: развитие продукта может сдерживаться целевым пользователем. Антивирусная компания не может польностью реализовать потенциал продукта, потому что конечный юзер тупой. Те же, кто решается делать мощный продукт, оказываются банкротами, потому что их программа интересует малочисленных профессионалов. Частично это можно было бы реализовать уровнями защиты, но это опять же делают не все.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Dr.Golova

> рассмотрим рекомендацию запуска антивируса с "чистой" дискеты. Безусловно практически всегда так и следует поступать

Ааа, я в панике, у меня уже года три как нет дисководов во всех системниах. Как же я буду лечить вирье? %-)

ЗЫ: интересно, а можно ли сделать загрузку с "чистого интернета". Даже банальный мегабит будет заметно быстрее дискеты. Надо запантетовать эту идею (хотя наверно уже давно кто-нить подсуетился) и продать ее БГ за безобразные бабки :-)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Dexter
продать ее БГ

Притормози. :)

Имя "БГ" Билли не принадлежит.

Оно ужо давным-давно запатентовано. ;)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Dr.Golova

> Имя "БГ" Билли не принадлежит.

Какая разница, кому принадлежит и в какой раскладке. Главное кто купит :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

  • Сообщения

    • Ego Dekker
      Домашние антивирусы для Windows были обновлены до версии 19.0.14.
    • PR55.RP55
      Microsoft ускоряет Проводник в Windows 11 с помощью предзагрузки https://www.comss.ru/page.php?id=18618
    • AM_Bot
      Вендор Crosstech Solutions Group выпустил решение для защиты контейнерной инфраструктуры Crosstech Container Security (CTCS). Оно обеспечивает безопасность контейнерных сред: от сканирования образов до контроля запуска рабочих нагрузок и реагирования на инциденты в средах выполнения.      ВведениеФункциональные возможности Crosstech Container Security2.1. Анализ и контроль безопасности образов2.2. Контроль запуска контейнеров2.3. Безопасность в средах выполнения (Runtime Security)2.4. Безопасность окружения2.5. Внешние интеграцииАрхитектура Crosstech Container Security3.1. Основные компоненты Crosstech Container SecurityСистемные требования и лицензирование Crosstech Container Security4.1. Лицензирование4.2. Требования к аппаратной части4.3. Требования к программной части4.4. Процесс установкиСценарии использования5.1. Сценарий №1. Сканирование образов5.2. Сценарий №2. Политики безопасности образов контейнеров5.3. Сценарий №3. Контроль запуска контейнеров5.4. Сценарий №4. Мониторинг безопасности сред выполненияВыводыВведениеРоссийский рынок контейнерных разработок постоянно растёт. В 2024 году затраты на ПО для контейнеризации достигли 3 млрд рублей — это на 66 % больше, чем в 2023. Контейнерные технологии ускоряют процессы разработки, экономят ресурсы компаний, поэтому их всё чаще внедряют в свою работу ИТ-департаменты.Вместе с ростом масштабов контейнеризации увеличивается и поверхность атак: уязвимости в образах, ошибки конфигураций, несанкционированные действия внутри контейнеров. Crosstech Container Security помогает компаниям выстраивать комплексную систему защиты контейнерной инфраструктуры.Функциональные возможности Crosstech Container SecurityCrosstech Container Security объединяет функции анализа, мониторинга и управления безопасностью контейнерных сред. Решение охватывает весь жизненный цикл контейнера — от момента его создания до удаления. Продукт помогает DevSecOps-командам выявлять уязвимости, проверять конфигурации, контролировать сетевую активность и реагировать на инциденты в режиме реального времени.Анализ и контроль безопасности образовCrosstech Container Security интегрируется с реестрами хранения образов и позволяет проводить их сканирование как в ручном режиме, так и по расписанию. В результате анализа система обнаруживает дефекты в образах: уязвимости, неправильные конфигурации, секреты, а также фиксирует используемые в образах OSS-лицензии для пакетов и библиотек. По каждому найденному дефекту предоставляется детальная информация.CTCS поддерживает экспорт SBOM в форматах SPDX и CycloneDx, что упрощает аудит и обмен данными с другими решениями. Интерфейс продукта предоставляет визуализацию образов с маппингом (сопоставлением данных) на дефекты безопасности. CTCS также осуществляет дискаверинг (обнаружение) образов, располагающихся в защищаемых кластерах и на standalone-хостах.Для автоматизации контроля доступны настраиваемые политики безопасности образов, разделяемые по критериям:наличие уязвимостей в образах контейнеров выше заданной оценки критичности;наличие уязвимостей в образах контейнеров согласно заданным идентификаторам;обнаружение root в Dockerfile;возможность указания перечня образов, на которые будет распространяться созданная политика безопасности образов.При нарушении хотя бы одного из критериев политики администратор получает уведомление в интерфейсе CTCS и может оперативно принять меры: заблокировать образ, исключить его из деплоя или добавить в список исключений с указанием причины. Такой подход обеспечивает прозрачность процессов и повышает уровень доверия к среде разработки и эксплуатации.Контроль запуска контейнеровРешение обеспечивает контроль запуска контейнеров как в средах Kubernetes, так и на отдельных standalone-хостах в соответствии с заданными политиками безопасности. Это позволяет предотвращать запуск рабочих нагрузок, не соответствующих требованиям безопасности компании, ещё на этапе их инициализации.В зависимости от настроек администратор может выбрать режим реагирования: блокирование или оповещение о нарушении политики безопасности. Информация обо всех срабатываниях отображается в интерфейсе системы, обеспечивая прозрачность и возможность оперативного реагирования.Политики безопасности включают следующие критерии:попытка запуска контейнеров на базе образов, не соответствующих политикам безопасности;попытка запуска контейнеров из-под пользователя root;попытка запуска контейнеров с повышенными привилегиями ядра Linux;контроль запуска контейнеров на базе образов, не прошедших сканирование CTCS.Дополнительно решение поддерживает интеграцию с OPA Gatekeeper и имеет возможность создания и импорта политик через интерфейс CTCS.Безопасность в средах выполнения (Runtime Security)CTCS использует возможности инструмента Tetragon для создания и применения кастомных политик безопасности, позволяющих контролировать сетевые взаимодействия внутри контейнеров. Администраторы могут выбрать набор кластеров для распространения политик, что обеспечивает гибкость при внедрении требований безопасности.Вся информация о срабатываниях политик фиксируется в интерфейсе CTCS, предоставляя специалистам по информационной безопасности прозрачную картину активности в средах выполнения и возможность оперативного реагирования на инциденты.Безопасность окруженияРешение выполняет сканирование кластеров на соответствие стандартам конфигурирования CIS Kubernetes Benchmarks. Аналогично система проводит проверку standalone-хостов на соответствие CIS Docker Benchmarks. Дополнительно CTCS поддерживает сканирование конфигурационных файлов, расположенных в директориях нод кластеров, выполняя роль сканера на основе IaC (Infrastructure as Code, управление инфраструктурой через использование кода).Внешние интеграцииРешение поддерживает интеграцию с реестрами хранения образов, что обеспечивает доступ к актуальным данным для анализа и контроля безопасности контейнеров. Также CTCS поддерживает передачу журналов событий в системы сбора по протоколу Syslog для их централизованного хранения и обработки.Доступна интеграция с системой идентификации, управления доступом Keycloak с поддержкой OAuth и доменными службами каталогов. Это позволяет пользователям авторизовываться в интерфейсе системы через доменные учётные записи. Рисунок 1. Планы по развитию Crosstech Container Security Архитектура Crosstech Container SecurityАрхитектура CTCS реализована в формате однонаправленных соединений со стороны ядра системы в сторону агентов защиты (протокол TCP/IP), располагающихся в защищаемых кластерах. Такой подход позволяет использовать инстанс ядра в единственном экземпляре для инфраструктур, сегментированных по уровням доверия. Рисунок 2. Логическая архитектура Crosstech Container Security Основные компоненты Crosstech Container SecurityCTCS состоит из 3 основных компонентов:CTCS Core — группа микросервисов, отвечающая за управление системой: хранение данных, настроек, создание политик безопасности, бизнес-логика продукта, а также взаимодействие со смежными системами.CTCS Agent-Manager: модуль агент-менеджера реализован в формате оператора Kubernetes с целью контроля за установкой и изменениями кастомных ресурсов (custom resource definition, CRD), а также управления и передачи информации агент-воркерам, устанавливаемым на каждую защищаемую ноду в формате DaemonSet.CTCS Scanner — модуль, сканирующий образы контейнеров на уязвимости, неправильные конфигурации, конфиденциальные данные, информацию по OSS-лицензиям для пакетов и библиотек из состава образа, а также сканирующий кластеры на соответствие стандартам конфигурирования.Системные требования и лицензирование Crosstech Container SecurityПеред выбором модели лицензирования заказчикам рекомендуется оценить масштаб защищаемой инфраструктуры и нагрузку на кластеры. Crosstech Container Security предусматривает гибкий подход: ядро и агенты могут разворачиваться в разных сегментах сети, включая тестовые и продуктивные среды. Такой принцип позволяет оптимально распределять ресурсы и лицензии, избегая избыточных затрат.ЛицензированиеCTCS лицензируется по количеству защищаемых нод, на которые распространяются агенты защиты.В продукте реализовано гибкое лицензирование, которое позволяет заказчикам самостоятельно выбирать перечень защищаемых объектов. При достижении лимита по количеству лицензий, предусмотренных договором, администратор может отключить часть текущих объектов защиты и переназначить лицензии на новые кластеры и ноды. Рисунок 3. Включение/выключение агентов защиты Рисунок 4. Лицензии CTCS На странице лицензирования доступна подробная информация о параметрах действующей лицензии. Пользователь видит:количество оставшихся дней действия лицензии;количество нод, предусмотренных лицензией;актуальные данные о числе используемых нод в рамках лицензии;сведения о типе лицензии;информация о поставщике;информация о владельце лицензии.Рисунок 5. Страница «Лицензирование» Требования к аппаратной частиКластер, на котором производится установка CTCS, должен соответствовать минимальным характеристикам, приведённым ниже. Для определения значений millicpu (единицы времени процессора, эквивалентной тысячной части работы, которую может выполнить одно ядро CPU) рекомендуется воспользоваться документацией Kubernetes.Кластер, на который будет установлен helm-чарт ядра (без учёта сканера) должен иметь характеристики не ниже 8190 millicpu, 7410 MiB RAM.Для каждого экземпляра сканера: 3 CPU, 6 GB RAM, при добавлении дополнительных экземпляров значения увеличиваются пропорционально.В случае использования большего количества реплик значения пропорционально умножаются на их число. По умолчанию в чарте допускается до 6 реплик, что требует 18 CPU, 36 GB RAM.Каждый кластер для развёртывания чарт-агента должен иметь 2 CPU, 8 GB RAM.Необходимый минимум для каждой используемой СУБД PostgreSQL: 4 CPU, 8 GB RAM, 100 GB.Приведённые требования указаны для усреднённой конфигурации и могут быть изменены в зависимости от количества одновременных сканирований образов, генерируемых событий, деплоев, пространств имён (namespaces) и подов.Требования к программной частиДля корректной интеграции и работы приложение CTCS должно быть развёрнуто в кластере Kubernetes. При настройке системы в конфигурационном файле helm-чарта должны быть настроены необходимые параметры.Поддерживаемые контейнерные среды CRI (container runtime interface): containerd и docker.В момент выполнения инструкции на хосте администратора должны быть установлены следующие утилиты для выполнения установки:tar;helm;kubectl.Необходимые сервисы в инфраструктуре:PostgreSQL: рекомендуется размещать базу данных для хранения логов на отдельном инстансе от основной БД, чтобы избежать падения производительности основных операций при большом объёме логируемых событий;Keycloak (опционально, имеется возможность поставки в составе дистрибутива);Vault (опционально, имеется возможность использования стандартного объекта Kubernetes Secret).Требования к операционной системе и ядру:рекомендуется использовать ОС с версией ядра 5.4 или выше для обеспечения поддержки Tetragon;в ядре должна быть включена функция BTF;должны быть активированы модули eBPF и cgroup, а также корректным образом настроены или отключены модули безопасности Linux (LSM), контролирующие запуск eBPF-программ (в соответствии с официальной документацией Tetragon).Требования к версиям Kubernetes:центральная управляющая часть кластера – не ниже версии 1.23;дочерние кластеры – версия 1.23 или выше.Дополнительные требования:В кластере Kubernetes должен быть установлен, подключён и настроен storage class, в котором будет минимум 10 GB свободного места.В master-кластер должен быть установлен External Secrets (опционально).В дочерние кластеры должен быть установлен External Secrets (опционально).Во всех кластерах, где развёртывается ядро и агенты CTCS, должен быть установлен ingress-контроллер.Совокупность этих требований обеспечивает стабильную работу системы и корректное взаимодействие всех модулей CTCS. При соблюдении указанных параметров производительность решения остаётся предсказуемой даже при высокой интенсивности сканирований и большом количестве событий безопасности. Такой подход гарантирует надёжность, масштабируемость и устойчивость контейнерной инфраструктуры.Процесс установкиДля развёртывания CTCS вендор предоставляет архив, содержащий helm-чарты и образы системных контейнеров. При необходимости может быть предоставлена учётная запись для выгрузки дистрибутивов из репозиториев вендора напрямую.Сценарии использованияCrosstech Container Security закрывает ключевые задачи обеспечения безопасности контейнерных платформ — от анализа уязвимостей до защиты на уровне среды выполнения. Решение органично интегрируется в процессы DevSecOps и помогает компаниям повысить устойчивость инфраструктуры к современным киберугрозам без потери скорости разработки.Сценарий №1. Сканирование образовCTCS позволяет выполнять сканирование образов контейнеров, хранящихся как в интегрированных реестрах образов, так и локально в защищаемых кластерах. Рисунок 6. Подключённые реестры После интеграции с реестрами образов на вкладке «Образы» – «Реестры» отображается подключённый реестр и информация о хранящихся в нём образах. Реализовано в формате иерархии:Реестры.Название образа и количество его версий (тегов).Название образа и его версии.Карточка конкретного образа.Рисунок 7. Образ и список его версий Рисунок 8. Карточка образа На каждом уровне иерархии есть возможность запуска сканирования по требованию с выбором типа дефектов, которые будут учитываться в процессе сканирования. Дополнительно предоставляется общая информация об образе, данные о его соответствии установленным политикам, сведения о слоях образов с маппингом на обнаруженные дефекты. Рисунок 9. Слои образа На странице интеграций с реестрами в настройках доступно выставление расписания для проведения автоматизированного сканирования. Рисунок 10. Сканирование по расписанию Для работы с образами, обнаруженными локально в защищаемых кластерах, доступна отдельная вкладка «Образы» – «Локальные образы». Рисунок 11. Таблица локальных образов При запуске процесса сканирования доступен выбор ноды, на которой он будет проводиться. Если обнаруженный образ находится в интегрированном реестре, сканирование будет приоритетно выполняться на стороне ядра системы в рамках интеграции с реестром. Рисунок 12. Выбор нода для проведения сканирования Сценарий №2. Политики безопасности образов контейнеровВ рамках Crosstech Container Security реализовано создание политик безопасности для образов контейнеров. После их настройки система автоматически проверяет все известные образы на соответствие заданным критериям. По результатам проверки на карточке каждого образа отображается информация о соответствии или несоответствии политикам безопасности (Рисунок 7). Если образ нарушает несколько политик безопасности одновременно, в карточке отображается, какие именно политики безопасности были нарушены. Рисунок 13. Создание политики безопасности образов Сценарий №3. Контроль запуска контейнеровВ CTCS доступна интеграция с OPA Gatekeeper, обеспечивающая валидацию контейнерных деплоев и реагирование в соответствии с заданными политиками безопасности.При настройке политик безопасности доступен выбор режима реагирования — оповещение либо блокировка — а также определение перечня критериев безопасности, по которым будет осуществляться контроль. Рисунок 14. Таблица политик валидации и контроля запусков Политики безопасности могут создаваться по выделенным критериям (Рисунок 13) или импортироваться в виде кастомных политик (Рисунок 14). Рисунок 15. Создание политики валидации и контроля запусков Рисунок 16. Импорт кастомных политик безопасности Результаты срабатывания политик доступны в интерфейсе системы, что позволяет оперативно анализировать инциденты и корректировать настройки безопасности. Рисунок 17. Срабатывание политик валидации и контроля запусков Сценарий №4. Мониторинг безопасности сред выполненияВ текущей версии реализован мониторинг безопасности сред выполнения на базе Tetragon, что позволяет контролировать эксплуатацию рабочих нагрузок.В CTCS доступна форма для создания или импорта готовых политик безопасности с возможностью выбора области применения. Рисунок 18. Создание политики среды выполнения При срабатывании политик система отображает перечень событий в формате таблицы. Для каждого события можно перейти в режим детального просмотра, где отображается его идентификатор, дата и время создания, короткое описание и содержание в формате json. Рисунок 19. Событие срабатывания политики среды выполнения ВыводыАнализ решения Crosstech Container Security показал, что в версии 3.0.0 продукт предоставляет широкие функциональные возможности для защиты контейнерной инфраструктуры: от обеспечения безопасности образов контейнеров до контроля запуска и реагирования на нелегитимные процессы в средах выполнения в соответствии с политиками безопасности. CTCS также предоставляет инструменты для проведения сканирований защищаемых кластеров на соответствие стандартам конфигурирования, что повышает уровень безопасности контейнерной инфраструктуры.Достоинства:Архитектура. Благодаря однонаправленным соединениям со стороны ядра системы в сторону агентов защиты обеспечивается соответствие требованиям заказчиков, которые используют «Zero Trust»-модель на уровне сегментов инфраструктуры.Широкая площадь покрытия. CTCS обеспечивает контроль запуска контейнеров не только в рамках оркестратора Kubernetes, но и на отдельных хостах контейнеризации за счёт использования standalone-агентов.Гибкие возможности при работе с API. Весь функционал из веб-интерфейса CTCS также доступен для вызова через API, что позволяет специалистам заказчика решать нетривиальные задачи в рамках своей рабочей деятельности и интегрировать продукт в существующие процессы.Удобство при работе со сканированием образов. Иерархический подход обеспечивает гибкость при выборе области сканирования и повышает прозрачность анализа.Недостатки:Отсутствие возможности встраивания в процесс сборки (CI/CD) (планируется к реализации в первом квартале 2026 года).Отсутствие данных по ресурсам Kubernetes (Workloads, RBAC, Custom Resources, Feature Gates): планируется в 4-м квартале 2025 – 1-м квартале 2026).Отсутствие настройки гибкого разграничения прав доступа пользователей в интерфейс системы (реализация запланирована на первый квартал 2026).Отсутствие отчётности по результатам работы с системой (планируется в первом квартале 2026).Реклама, 18+. ООО «Кросстех Солюшнс Групп» ИНН 7722687219ERID: 2VfnxvVGwXfЧитать далее
    • demkd
    • PR55.RP55
      И ещё это: https://www.comss.ru/page.php?id=18330 Это и на работе Образов с Live CD может сказаться ?
×