По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Несмотря на доступ к все более эффективному и мощному оборудованию, операции, выполняемые непосредственно на традиционных физических (или «чистых») серверах, неизбежно сталкиваются со значительными практическими ограничениями. Стоимость и сложность создания и запуска одного физического сервера говорят о том, что эффективное добавление и удаление ресурсов для быстрого удовлетворения меняющихся потребностей затруднено, а в некоторых случаях просто невозможно. Безопасное тестирование новых конфигураций или полных приложений перед их выпуском также может быть сложным, дорогостоящим и длительным процессом.
Исследователи-первопроходцы Джеральд Дж. Попек и Роберт П. Голдберг в статье 1974 года («Формальные требования к виртуализируемым архитектурам третьего поколения» (“Formal Requirements for Virtualizable Third Generation Architectures”) - Communications of the ACM 17 (7): 412–421) предполагали, что успешная виртуализация должна обеспечивать такую среду, которая:
Эквивалента физическому компьютеру, поэтому доступ программного обеспечения к аппаратным ресурсам и драйверам должен быть неотличим от невиртуализированного варианта.
Обеспечивает полный контроль клиента над аппаратным обеспечением виртуализированной системы.
По возможности эффективно выполняет операции непосредственно на базовых аппаратных ресурсах, включая ЦП.
Виртуализация позволяет разделить физические ресурсы вычислений, памяти, сети и хранилища («основополагающая четверка») между несколькими объектами. Каждое виртуальное устройство представлено в своем программном обеспечении и пользовательской среде как реальный автономный объект. Грамотно настроенные виртуальные изолированные ресурсы могут обеспечить более защиту приложений приложений без видимой связи между средами. Виртуализация также позволяет создавать и запускать новые виртуальные машины почти мгновенно, а затем удалять их, когда они перестанут быть необходимыми.
Для больших приложений, поддерживающих постоянно меняющиеся бизнес-требования, возможность быстрого вертикального масштабирования с повышением или понижением производительности может означать разницу между успехом и неудачей. Адаптивность, которую предлагает виртуализация, позволяет скриптам добавлять или удалять виртуальные машины за считанные секунды, а не недели, которые могут потребоваться для покупки, подготовки и развертывания физического сервера.
Как работает виртуализация?
В невиртуальных условиях, архитектуры х86 строго контролируют, какие процессы могут работать в каждом из четырех тщательно определенных уровней привилегий (начиная с Кольца 0 (Ring 0) по Кольцо 3).
Как правило, только ядро операционной системы хоста имеет какой-либо шанс получить доступ к инструкциям, хранящимся в кольце под номером 0. Однако, поскольку вы не можете предоставить нескольким виртуальным машинам, которые работают на одном физическом компьютере, равный доступ к кольцу 0, не вызывая больших проблем, необходим диспетчер виртуальных машин (или «гипервизор»), который бы эффективно перенаправлял запросы на такие ресурсы, как память и хранилище, на виртуализированные системы, эквивалентные им.
При работе в аппаратной среде без виртуализации SVM или VT-x все это выполняется с помощью процесса, известного как ловушка, эмуляция и двоичная трансляция. На виртуализированном оборудовании такие запросы, как правило, перехватываются гипервизором, адаптируются к виртуальной среде и возвращаются в виртуальную машину.
Простое добавление нового программного уровня для обеспечения такого уровня организации взаимодействия приведет к значительной задержке практически во всех аспектах производительности системы. Одним из успешных решений было решение ввести новый набор инструкций в ЦП, которые создают, так называемое, «кольцо 1», которое действует как кольцо 0 и позволяет гостевой ОС работать без какого-либо влияния на другие несвязанные операции.
На самом деле, при правильной реализации виртуализация позволяет большинству программных кодов работать как обычно, без каких-либо перехватов.
Несмотря на то, что эмуляция часто играет роль поддержки при развертывании виртуализации, она все же работает несколько иначе. В то время как виртуализация стремится разделить существующие аппаратные ресурсы между несколькими пользователями, эмуляция ставит перед собой цель заставить одну конкретную аппаратную/программную среду имитировать ту, которой на самом деле не существует, чтобы у пользователей была возможность запускать процессы, которые изначально было невозможно запустить. Для этого требуется программный код, который имитирует желаемую исходную аппаратную среду, чтобы обмануть ваше программное обеспечение, заставив его думать, что оно на самом деле работает где-то еще.
Эмуляция может быть относительно простой в реализации, но она почти всегда несет за собой значительные потери производительности.
Согласно сложившимся представлениям, существует два класса гипервизоров: Type-1 и Type-2.
Bare-metal гипервизоры (исполняемые на «голом железе») (Type-1), загружаются как операционная система машины и – иногда через основную привилегированную виртуальную машину – сохраняют полный контроль над аппаратным обеспечением хоста, запуская каждую гостевую ОС как системный процесс. XenServer и VMWare ESXi – яркие примеры современных гипервизоров Type-1. В последнее время использование термина «гипервизор» распространилось на все технологии виртуализации хостов, хотя раньше оно использовалось только для описания систем Type-1. Первоначально более общим термином, охватывающим все типы систем, был «Мониторы виртуальных машин». То, в какой степени люди используют термин «мониторы виртуальных машин» все это время, наводит меня на мысль, что они подразумевают «гипервизор» во всех его интерпретациях.
Гипервизоры, размещенные на виртуальном узле (Type-2) сами по себе являются просто процессами, работающими поверх обычного стека операционной системы. Гипервизоры Type-2 (включая VirtualBox и, в некотором роде, KVM) отделяют системные ресурсы хоста для гостевых операционных систем, создавая иллюзию частной аппаратной среды.
Виртуализация: паравиртуализация или аппаратная виртуализация
Виртуальные машины полностью виртуализированы. Иными словами, они думают, что они обычные развертывания операционной системы, которые живут собственной счастливой жизнью на собственном оборудовании. Поскольку им не нужно взаимодействовать со своей средой как-то иначе, чем с автономной ОС, то они могут работать с готовыми немодифицированными программными стеками. Однако раньше за такое сходство приходилось платить, потому что преобразование аппаратных сигналов через уровень эмуляции занимало дополнительное время и циклы.
В случае с паравиртуализацией (PV – Paravirtualization) паравиртуальные гости хотя бы частично осведомлены о своей виртуальной среде, в том числе и том, что они используют аппаратные ресурсы совместно с другими виртуальными машинами. Эта осведомленность означает, что хостам PV не нужно эмулировать хранилище и сетевое оборудование, и делает доступными эффективные драйверы ввода-вывода. На первых порах это позволяло гипервизорам PV достигать более высокой производительности для операций, требующих подключения к аппаратным компонентам.
Тем не менее, для того, чтобы предоставить гостевой доступ к виртуальному кольцу 0 (т.е. кольцу -1), современные аппаратные платформы – и, в частности, архитектура Intel Ivy Bridge – представили новую библиотеку наборов инструкций ЦП, которая позволила аппаратной виртуализации (HVM – Hardware Virtual Machine) обойти узкое место, связанное с ловушкой и эмуляцией, и в полной мере воспользоваться преимуществами аппаратных расширений и немодифицированных операций ядра программного обеспечения.
Также значительно повысить производительность виртуализации может последняя технология Intel – таблицы расширенных страниц (EPT – Extended Page Tables).
В связи с этим, в большинстве случаев можно обнаружить, что HVM обеспечивает более высокую производительность, переносимость и совместимость.
Аппаратная совместимость
Как минимум, несколько функций виртуализации требуют аппаратную поддержку, особенно со стороны ЦП хоста. Именно поэтому вы должны убедиться, что на вашем сервере есть все, что вам необходимо для задачи, которую вы собираетесь ему дать. Большая часть того, что вам нужно знать, храниться в файле /proc/cpuinfo и, в частности, в разделе «flags» (флаги) каждого процессора. Однако вам нужно знать, то искать, потому что флагов будет очень много.
Запустите эту команду, чтобы посмотреть, что у вас под капотом:
$ grep flags /proc/cpuinfo
Контейнерная виртуализация
Как мы уже видели ранее, виртуальная машина гипервизора – это полноценная операционная система, чья связь с аппаратными ресурсами «основополагающей четверки» полностью виртуализирована – она думает, что работает на собственном компьютере.
Гипервизор устанавливает виртуальную машину из того же ISO-образа, который вы загружаете и используете для установки операционной системы непосредственно на пустой физический жесткий диск.
Контейнер в свою очередь фактически представляет собой приложение, запускаемое из скриптообразного шаблона, которое считает себя операционной системой. В контейнерных технологиях, таких как LXC и Docker, контейнеры – это не что иное, как программные и ресурсные (файлы, процессы, пользователи) средства, которые зависят от ядра хоста и представления аппаратных ресурсов «основополагающей четверки» (т.е. ЦП, ОЗУ, сеть и хранилище) для всего, то они делают.
Конечно, с учетом того, что контейнеры фактически являются изолированными расширениями ядра хоста, виртуализация Windows (или более старых или новых версий Linux с несовместимыми версиями libc), например, на хосте Ubuntu 16.04 будет сложна или невозможна. Но эта технология обеспечивает невероятно простые и универсальные вычислительные возможности.
Перемещение
Модель виртуализации также позволяет использовать широкий спектр операций перемещения, копирования и клонирования даже из действующих систем (V2V). Поскольку программные ресурсы, определяющие виртуальную машину и управляющие ею, очень легко идентифицировать, то обычно не требуется очень много усилий для дублирования целых серверных сред в нескольких местах и для разных целей.
Иногда это не сложнее, чем создать архив виртуальной файловой системы на одном хосте, распаковать его на другом хосте по тому же пути, проверить основные сетевые настройки и запустить. Большинство платформ предлагают единую операцию командной строки для перемещения гостей между хостами.
Перемещение развертываний с физических серверов на виртуализированные среды (P2V) иногда может оказаться немного сложнее. Даже создание клонированного образа простого физического сервера и его импорт в пустую виртуальную машину может сопровождаться определенными трудностями. И как только все это будет выполнено, вам, возможно, придется внести некоторые корректировки в системную архитектуру, чтобы можно было использовать возможности, предлагаемые виртуализацией, в полную силу. В зависимости от операционной системы, которую вы перемещаете, вам также может потребоваться использование паравиртуализированных драйверов для того, чтобы ОС могла корректно работать в своем «новом доме».
Как и в любых других ситуациях управления сервером: тщательно все продумывайте заранее.
Привет! Сегодня мы оговорим немного о базовой сетевой безопасности, а именно о Port-Security и о том, как его настроить на коммутаторах Cisco.
Для начала разберемся, что же вообще такое Port-Security. Port-Security – это функция коммутатора, при помощи которой мы можем указать каким устройствам можно пропускать трафик через определенные порты. Устройство определяется по его MAC-адресу.
Эта функция предназначена для защиты от несанкционированного подключения к сети и атак, направленных на переполнение таблицы MAC-адресов. При помощи нее мы можем указывать конкретные адреса, с которых разрешен доступ или указывать максимальное количество MAC-адресов, которые могут передавать трафик через порт.
Типы Port-Security
Существует несколько способов настройки port-security:
Статические MAC-адреса – MAC-адреса, которые вручную настроены на порту, из режима конфигурации порта при помощи команды switchport port-security mac-address [MAC-адрес] . MAC-адреса, сконфигурированные таким образом, сохраняются в таблице адресов и добавляются в текущую конфигурацию коммутатора.
Динамические MAC-адреса - MAC-адреса, которые динамически изучаются и хранятся только в таблице адресов. MAC-адреса, сконфигурированные таким образом, удаляются при перезапуске коммутатора.
Sticky MAC-адреса - MAC-адреса, которые могут быть изучены динамически или сконфигурированы вручную, затем сохранены в таблице адресов и добавлены в текущую конфигурацию.
Sticky MAC-адреса
Если необходимо настроить port-security со sticky MAC-адресами, которые преобразуются с из динамически изученных адресов и добавляются в текущую конфигурацию, то необходимо настроить так называемое sticky изучение. Для того чтобы его включить необходимо на интерфейсе коммутатора выполнить команду switchport port-security mac-address sticky из режима конфигурации интерфейса.
Когда эта команда введена, коммутатор преобразует все динамически изученные MAC-адреса (включая те, которые были динамически изучены до того, как было включено sticky обучение) к sticky MAC-адресам. Все sticky MAC-адреса добавляются в таблицу адресов и в текущую конфигурацию.
Также sticky адреса можно указать вручную. Когда sticky MAC-адреса настроены при помощи команды switchport port-security mac-address sticky [MAC-адрес], все указанные адреса добавляются в таблицу адресов и текущую конфигурацию.
Если sticky MAC-адреса сохранены в файле конфигурации, то при перезапуске коммутатора или отключении интерфейса интерфейс не должен будет переучивать адреса. Если же sticky адреса не будут сохранены, то они будут потеряны.
Если sticky обучение отключено при помощи команды no switchport port-security mac-address sticky , то эти адреса будут оставаться в таблице адресов, но удалятся из текущей конфигурации.
Обратите внимание, что port-security не будут работать до тех пор, пока не будет введена команда, включающая его - switchport port-security
Нарушение безопасности
Нарушением безопасности являются следующие ситуации:
Максимальное количество MAC-адресов было добавлено в таблицу адресов для интерфейса, а устройство, MAC-адрес которого отсутствует в таблице адресов, пытается получить доступ к интерфейсу.
Адрес, полученный или сконфигурированный на одном интерфейсе, отображается на другом интерфейсе в той же VLAN.
На интерфейсе может быть настроен один из трех режимов реагирования при нарушении:
Protect - когда количество MAC-адресов достигает предела, разрешенного для порта, пакеты с неизвестными исходными адресами отбрасываются до тех пор, пока не будет удалено достаточное количество MAC-адресов или количество максимально допустимых адресов для порта не будет увеличено. Уведомление о нарушении безопасности отсутствует в этом случае.
Restrict – то же самое, что и в случае Protect, однако в этом случае появляется уведомление о нарушении безопасности. Счетчик ошибок увеличивается
Shutdown – стандартный режим, в котором нарушения заставляют интерфейс немедленно отключиться и отключить светодиод порта. Он также увеличивает счетчик нарушений. Когда порт находится в этом состоянии (error-disabled), его можно вывести из него введя команды shutdown и no shutdown в режиме конфигурации интерфейса.
Чтобы изменить режим нарушения на порту коммутатора, используется команда port-security violation {protect | restrict |shutdown} в режиме конфигурации интерфейса.
.tg {border-collapse:collapse;border-spacing:0;}
.tg td{font-family:Arial, sans-serif;font-size:14px;padding:10px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;border-color:black;}
.tg th{font-family:Arial, sans-serif;font-size:14px;font-weight:normal;padding:10px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;border-color:black;}
.tg .tg-fymr{font-weight:bold;border-color:inherit;text-align:left;vertical-align:top}
.tg .tg-0pky{border-color:inherit;text-align:left;vertical-align:top}
Режим реагирования
Передача траффика
Отправка сообщения syslog
Отображение сообщения об ошибке
Увеличение счетчика нарушений
Выключение порта
Protect
Нет
Нет
Нет
Нет
Нет
Restrict
Нет
Да
Нет
Да
Нет
Shutdown
Нет
Нет
Нет
Да
Да
Настройка
Рассмотрим пример настройки:
Switch#interface fa0/1 – заходим в режим конфигурации порта
Switch(config-ig)#switchport mode access – делаем порт access
Switch(config-ig)#switchport port-security – включаем port-security
Switch(config-ig)#switchport port-security maximum 50 – задаем максимальное количество адресов на порту
Switch(config-ig)#switchport port-security mac-address sticky – включаем sticky изучение
Если мы не будем ничего уточнять и просто включим port-security командой switchport port-security в режиме конфигурации интерфейса, то максимальное количество адресов на порту будет один, sticky изучение будет выключено, а режим нарушения безопасности будет shutdown.
Проверка порта
Чтобы отобразить параметры port-security используется команда show port-security [номер_интерфейса] .
Чтобы отобразить все защищенные MAC-адреса используется команда show port-security address.
Первые два типа систем (IPS - intrusion prevention system & IDS - intrusion detection system) появились в 1986 году как результат научной работы, и их базовые принципы до сих пор используются повсюду – в системах предотвращения и обнаружения, в NGIPS и NGFW – словом во всех системах, которые были упомянуты в заголовке. В статье мы расскажем, как IPS/IDS изменялись со временем, с какими проблемами сталкивались разработчики и что можно от них ожидать в будущем.
Итак, как мы уже сказали, системы обнаружения угроз и системы предотвращения угроз появились после написания научной статьи некой Дороти Деннинг, и называлась эта статья «Модель обнаружения угроз», и благодаря этой статье Стэнфордский Исследовательский Институт разработал нечто под названием Intrusion Detection Expert System/ (IDES). Вольно это можно перевести как экспертная система обнаружения угроз. Она использовала статистическое обнаружений аномалий, сигнатуры и хостовыепользовательские профили для детектирования редискового поведения у систем. Таким образом, она могла определить если такие протоколы как FTP или HTTP были использованы некорректно и даже могла определять атаки с отказом обслуживания (DoS).
2000 - 2005: Обнаружение предпочтительнее предотвращения
В ранних 2000х системы обнаружения считались хорошим тоном. А до этого межсетевые экраны были очень эффективны для ландшафта угроз безумных 90х годов. Фаерволы обрабатывали трафик относительно быстро, так как в них не было глубокой инспекции пакетов, то есть вы не знали, что это за трафик приходит к вам в сеть – фаерволы реагировали только на установленные в правилах (листах контроля доступа) порты, протоколы иили сетевые адреса. В начале 2000х появились новые атаки, такие как SQL-инъекции и прочие, и они моментально завоевали место на подиуме в арсенале взломщиков. И вот на этом этапе IDS системы и пригодились – а время систем предотвращения угроз еще не настало.
В то время некоторые организации боялись использовать IPS так как такая система потенциально могла заблокировать безвредный трафик. Как мы более подробно описывали в нашей статье про IPS и IDS, IPS ставится «в разрыв» и блокирует подозрительные соединения, полностью разрывая коннект и связь между отправляющей и принимающими сторонами. Но как вы могли понять, такое соединение могло стать подозрительным просто по причине какой-то аномалии в подключении и грубо говоря «глюке». Таким образом, IDS системы просто сообщали о такой аномалии и ничего не блокировали, чтобы сисадмин мог среагировать и проверить - правда ли это что-то плохое или же это просто доброкачественная аномалия. По этой причине в то время рынок для систем предотвращения угроз был настолько мал, что существовало всего несколько IPS вендоров. То есть идеей было что нужно пропускать любой трафик, а разберемся, мол, уже опосля – риск потери хорошего трафика был страшнее угрозы взлома.
В это время сигнатуры писались для обнаружения эксплойтов, но не уязвимостей – то есть для каждой уязвимости было 100 разных способов эксплойта. Как только злоумышленники находили уязвимость, они заставляли разработчиков IDS исходить потом и писать сотни разных сигнатур для эксплойтов – все только для того, чтобы система обнаружения отправила тревогу админу. И вендоры IDS хвастались количеством имеющихся у них сигнатрур, будто это выгодно отличало их от конкурентов – но как вы понимаете, это не было корректным критерием оценки. В общем и целом, механизмы тогда насчитывали следующее полчище методов – совпадение по паттернам, строкам, аномалиям и даже эвристический анализ.
Принятие IPS - год 2005
Когда в 2005 году системы предотвращения начали становится популярнее, большее количество вендоров стали соревноваться за место под солнцем на растущем рынке, и перестали хвастать самыми длинными сигнатурами. Опять же, по причине установки «в разрыв», клиенты боялись, что все эти сигнатуры будут замедлять сеть, так как каждое соединение должно быть пропущено через них. Таким образом, было решено сменить вектор написания сигнатур на другие – те, которые будут базироваться не на эксплойте, а на самой уязвимости. Было получено опытным путем, что если в системе более 3500 сигнатур, то это будет заметно сказываться на производительности. Сегодня производители все еще помещают в систему как новые сигнатуры, так и некую классику уязвимостей, которую злоумышленники могут использовать.
2006 – 2010: Настает время производительных IPS/IDS комбайнов
Вендоры, которые предлагали гибридные системы, быстро обошли конкурентов – они предлагали гораздо более производительные системы, вплоть до 5 Гбитсек, и могли мониторить сегментированные сети, DMZ, серверные фермы с веб-приложениями и площадь внутри периметра. К примеру, сегодня производительные IPS устройства легко дают более 40 гигабит в секунду.
В итоге, клиенты начали массово переходить на системы предотвращения вторжений и рынок начал очень быстро расти. А когда появился стандарт безопасности PCI DSS начал требовать от организаций поддержу оплаты картами установки или IDS, или МСЭ с возможностью фильтрации веб-приложений, очень много организаций купили гибридные системы. И прошло уже много лет с момента рождения технологии, так что технологию порядочно оттюнинговали и подрихтовали, так что, ложно-положительных срабатываний стало гораздо меньше. Однако, в этот же момент начала расползаться эпидемия ботнетов. И самым популярным способом стало помещение зловредных приложений на популярных сайтах, и, если какой-нибудь браузерный плагин вроде Java или Adobe Flash был с уязвимостью, при клике на соответствующий документ вредонос тихонько скачивался на компьютер. Кроме того, в 2008 году злоумышленники активно использовали перенаправляющие ссылки на вредоносные сайты, так что IDS/IPS вендоры начали также добавлять списки IP-адресов вредоносных командных центров и их веб-адресов – если эти ресурсы содержали на себе вредоносы.
2011 – 2015: Системы предотвращения вторжений следующего поколения
В эти годы был переломный момент для вендоров в сфере ИБ – так как они стали выпускать системы предотвращения угроз следующего поколеня, которые включали в себя такие фичи как контроль пользователей и приложений. Таким образом, традиционный IPS смотрит в сетевой трафик на предмет известных аттак и что-то делает с этим трафиком, в зависимости от модели развертывания, а IPS следующего поколения делает тоже самое, но кроме того он покрывает гораздо больше протоколов (вплоть до 7 уровня) для защиты от большего количества атак. Кроме того, он также позволяет гибко контролировать доступ к приложениям – то есть, например, чтобы можно было лайкать фотки в VK, но нельзя было их заливать. И более того – чтобы это могли делать только определенные группы пользователей.
Следующее дополнение к IDS/IPS системам появилось после взлома RSA (компании, которая занимается мультифакторной аутентификацией) в 2011 году – тогда новостные ресурсы назвали это APT (Advanced Persistent Threat)-атакой, то есть сложной постоянной угрозой. Позже было сказано, что это была фишинговая атака, в которой содержался документ с вредоносом внутри. Клиенты стали спрашивать ИБ вендоров, могут ли они их защитить от подобных вещей, если у вендора нет сигнатуры на данный конкретный вредонос, и ответом вендоров было предоставление такой фичи как эмуляция и песочницы – но это потребовало около 18 месяцев для большинства вендоров. Так что компании FireEye и Fidelis оказались в фазе бурного роста, так как они предоставляли такие технологии песочницы, до которых всем было очень далеко. Только подумайте, песочницы впервые за всю историю могли обнаружить до сих пор неизвестную атаку нулевого дня.
Как работает песочница: неизвестный исполняемый файл или документ сначала попадает в песочницу, где он запускается в разных операционных системах и алгоритм пытается имитировать действия пользователя – клавиши стучат, мышка елозит и кликает, время прокручивается – все в надежде на то, что вредонос вылупится и себя покажет.
Вендоры пошли чуть дальше. Если вредонос себя проявлял, то его хэш-сумма (MD5 или SHA) сохранялась для того, чтобы в будущем всегда ловить такие файлы. Соответственно, если другой клиент на такой же системе получал тот же файл – то он не пропускался в сеть и звучала тревога. Такие системы получили название Next Generation Firewall – межсетевых экранов следующего поколения.
Конечно, Гартнер использовал этот термин еще в 2003 году и предсказал, что они межсетевые экраны будут содержать внутри себя сложную IPS систему, но индустрия не принимала подобные устройства вплоть до 2013 года.
2018 – и далее: Межсетевые экраны следующего поколения
Сегодня большинство организаций используют NGFW и список их фич только растет. Так как эти МСЭ отличаются различными фичами, организациям придется выбирать в зависимости от точности поставленной задачи и их требований.
Опять же, есть за и против МСЭ следующего поколения: за – нужно купить только пару железяк вместо почти десятка. Против – это все один вендор, и его мудрость ограничена, то есть не существует лучшего вендора, который знал бы все и сразу. Таким образом очень неплохой практикой является комбинировать устройства защиты от разных производителей и разбавлять их «мудрость» между собой. Важно помнить, что любое устройство защиты всегда хорошо только настолько, насколько богаты знания и опыт, стоящие за этим устройством. Есть даже специальный термин – Threat Intelligence. Такие системы и базы знаний есть у всех больших ИБ вендоров. Более того, они есть полностью бесплатные и открытые – например, VirusTotal.
Сегодня ландшафт угроз постоянно меняется и большинство вендоров сконцентрировано на машинном обучении, чтобы алгоритмы анализа файлов всегда улучшались, а количество шума и ложных срабатываний стремилось к минимуму.
Но это бесконечная игра в кошки-мышки, и на каждый ход производителей хакеры придумают что-нибудь новое, что позже смогут нейтрализовать вендоры.