ЛК обновила защиту виртуальных сред и реализовала поддержку VMware NSX

ЛК обновила защиту виртуальных сред и реализовала поддержку VMware NSX

ЛК обновила защиту виртуальных сред и реализовала поддержку VMware NSX

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

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

Усовершенствованное взаимодействие центра обработки данных (ЦОД) на базе VMware NSX с защитным продуктом Kaspersky Security для виртуальных сред открывает перед пользователями и системными администраторами новые возможности. Так, решение «Лаборатории Касперского» распознает и предотвращает сетевые вторжения (IDS/IPS), сложные угрозы и уязвимости нулевого дня на всех виртуальных хостах под управлением VMware NSX. При этом процесс развертывания всех компонентов защитного решения полностью автоматизирован, а у каждой виртуальной машины появляются индивидуальные и точно настроенные средства защиты. 

Также Kaspersky Security для виртуальных сред и платформа VMware NSX обмениваются тегами безопасности, которые могут изменяться по заданным правилам, например, при обнаружении нового типа вредоносного ПО в сети. Такое постоянное взаимодействие между виртуальной инфраструктурой и защитным решением означает, что ЦОД может в режиме реального времени реагировать на любой инцидент информационной безопасности и при необходимости автоматически изменять конфигурацию всей виртуальной сети. В то же время функционал проверки включенных и выключенных виртуальных машин позволяет обеспечить защиту всего корпоративного программно-определяемого ЦОД вне зависимости от технологических и бизнес-процессов, в нем протекающих. 

«Производительность и безопасность виртуальных сред представляют собой дилемму для IT-специалистов с тех пор, как виртуализация начала «завоевывать» корпоративный сектор. Наше сотрудничество с VMware позволило решить эту дилемму без каких-либо «жертв» с обеих сторон. Обновленное решение Kaspersky Security для виртуальных сред обеспечивает высокий уровень кибербезопасности виртуальной инфраструктуры и не оказывает практически никакого воздействия на производительность платформы VMware NSX. В итоге те средства защиты, которые мы теперь предлагаем для VMware NSX и VMware vShield Endpoint, позволяют IT-специалистам решать любые задачи по обеспечению безопасности виртуальных машин и сетей», – рассказывает Виталий Мзоков, руководитель направления защиты ЦОД и облачных сред «Лаборатории Касперского».

«Новая версия решения Kaspersky Security для виртуальных сред поддерживает полную интеграцию с платформой VMware NSX – это означает, что наши пользователи могут продолжать задействовать все возможности виртуализации и при этом быть уверенными в надежной защите своей виртуальной инфраструктуры. Мы уже давно сотрудничаем с «Лабораторией Касперского» и рады, что с каждым новым обновлением наших решений они становятся все более эффективными и удобными для пользователей», – отмечает Александр Василенко, глава представительства компании VMware в России и СНГ.

Проводник Windows падал не из-за Microsoft, виноват оказался деинсталлятор

Инженер Microsoft Рэймонд Чен рассказал любопытную историю отладки загадочных падений Проводника. Сначала всё выглядело так, будто в Windows внезапно появился неприятный баг. Но виновником оказалась вовсе не Microsoft, а сторонний деинсталлятор.

Проблема проявилась как резкий всплеск сбоев Проводника. Инженеры начали изучать дампы и заметили странную деталь: падала 32-битная версия программы, запущенная на 64-битных системах Windows.

Такая версия Проводника всё ещё есть в Windows ради совместимости со старыми приложениями. Обычно современные системы почти не используют этот путь. Но в данном случае сторонний деинсталлятор каким-то образом заставлял систему обращаться именно к этому устаревшему компоненту.

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

Поскольку процесс повторялся в цикле, повреждение памяти постепенно накапливалось. В какой-то момент указатель стека уезжал в область активного кода, и Проводник падал.

Со стороны всё выглядело как типичная системная ошибка: софт снова и снова аварийно завершал работу, создавая ощущение, что проблема в самой Windows. На деле операционная система лишь показывала последствия ошибки в стороннем ПО.

Чен напомнил важную вещь: в экосистеме Windows с миллиардами устройств и огромным количеством приложений далеко не каждый сбой компонента Microsoft означает баг в Windows. Сторонние программы тоже могут ломать системные процессы, особенно если неправильно используют низкоуровневые API.

RSS: Новости на портале Anti-Malware.ru