- Необхідність захисту VDI
- Різні підходи до захисту і важливість контролю оперативної пам'яті
- Чому контроль оперативної пам'яті необхідний, але недостатній сам по собі
- Як повинна виглядати повноцінний захист
Використання віртуалізації робочих місць (Virtual Desktop Infrastructure, VDI) для багатьох організацій стало стандартом де-факто. Установка гипервизора дозволяє не виділяти кожному користувачеві окрему фізичну машину, а надавати повністю імітує таку віртуальний хост на сервері. Дві основні значущі бізнес-причини: скорочення витрат і спрощення частини завдань системного адміністрування. Крім цього VDI дозволяє миттєво створювати чисті робочі станції з нуля або організовувати мобільний доступ співробітників з самих різних пристроїв. Підприємства активно користуються цими можливостями. Розберемося докладніше, що особливого в побудові захисту інфраструктури VDI.
Необхідність захисту VDI
Причини інтересу бізнесу до VDI зрозумілі. Разом з тим співробітники компаній вже давно звикли до своїх стандартним робочим місцям і хочуть працювати з VDI точно так же, як і з встановленими локально операційними системами. Видимі співробітникам зміни при роботі в Інтернеті через браузер, копіювання даних з USB-флешки, якщо буде запущено програму повинні бути мінімальні. Звичайно, ІТ-підрозділу забезпечують таку плавність переходу. Але при цьому всі загрози для фізичної інфраструктури залишаються актуальними і для VDI.
Сама по собі віртуалізація не захищає ніяк. Операційна система, встановлена на віртуальну машину, володіє рівно тими ж уразливими, що і локальна ОС, - відомо безліч заражень віртуальних середовищ. Мало того, відомі випадки виходу шкідливого коду з-під управління гипервизора безпосередньо на хост. Для цього використовувалися уразливості вже самих гіпервізора. Все це призводить до необхідності повноцінного захисту віртуалізованих робочих місць. Детальніше про необхідність захисту VDI можна прочитати тут .
Різні підходи до захисту і важливість контролю оперативної пам'яті
Через специфіку віртуальних середовищ підходи до їх захисту відрізняються від методів, застосовуваних для традиційних фізичних інфраструктур. Варто окремо коротко зупинитися на тому, чому вони не можуть застосовуватися для віртуальних інфраструктур. В першу чергу віртуальні машини, як правило, менш потужні, і просте копіювання рішень для фізичних інфраструктур може привести до помітного збільшення часу відгуку хостів. Крім цього існують специфічні проблеми, такі як «шторм активності», при якому всі віртуальні машини з типовим ПО одночасно починають виконувати одну і ту ж задачу, наприклад оновлювати бази.
Розробники спеціалізованих рішень для забезпечення безпеки VDI прагнуть знизити навантаження на віртуальні машини, по можливості централізувати захисні функції, щоб не дублювати їх на кожному хості.
В ідеальному випадку виділяється окремий хост, що відповідає тільки за захист віртуальної інфраструктури, а на інші хости агенти не встановлюються. У такого підходу є цілий ряд обмежень, в першу чергу пов'язаних з доступом до оперативної пам'яті захищаються хостів. Навіть якщо сам доступ до пам'яті можливий (а за певних умов це дійсно так), то одне лише її вміст дає далеко не повну картину того, що відбувається на машині. Нижче ми докладніше опишемо, чому для повноцінного захисту необхідний більш глибокий динамічний поведінковий аналіз всього того, що відбувається на віртуальній машині.
Є й інший шлях, що знаходиться десь посередині між установкою «важких» рішень і безагентской захистом. Це установка «легких» агентів, які, з одного боку, мають доступ до оперативної пам'яті, а з іншого - вимагають менше ресурсів за рахунок того, що частина їх функціональності винесена в спеціально виділену захисну машину. Чому важливий саме доступ до оперативної пам'яті? Цього вимагає поширення «безтілесних» шкідливий, що не залишають ніяких слідів, крім як в оперативній пам'яті. Відомий приклад: програма Mimikatz, використовувана зловмисниками для отримання паролів користувачів в нешифрованому вигляді в ході цільових атак (вона, зокрема, застосовувалася в атаках групи Wild Neutron ).
Чому контроль оперативної пам'яті необхідний, але недостатній сам по собі
Індустрія ІБ знає про подібні прийоми давно, і сканування пам'яті захищаються фізичних і віртуальних машин не ново. «Лабораторія Касперського» реалізувала драйвер (який працює в тому числі і в «легкому» агента для захисту віртуальних хостів), скануючий завантажені в пам'ять драйвери, ядро ОС, пам'ять процесів, що працюють в режимі користувача, і т.д.
Однак просте сканування пам'яті не зможе замінити більш глибокий поведінковий аналіз того, що відбувається на машині. Сканування, безумовно, потрібний метод, але переоцінювати його не варто: він володіє скоріше точковим дією. Сам по собі, без зіставлення того, що відбувається в пам'яті з даними про події в файлової системі, реєстр, виклики API системи, цей метод або не буде «ловити» практично нічого, або буде видавати безліч помилкових спрацьовувань.
Наводячи аргументи на користь сканування оперативної пам'яті, часто говорять, що якщо шкідливий файл запакований, то в природному вигляді його можна побачити тільки в пам'яті. Однак сучасні антивірусні движки здатні аналізувати і заархівовані файли. Гірше справи йдуть з програмами-протекторами, які реалізують поліморфізм і інші технології, що утрудняють аналіз. Проте навіть в цьому випадку перегляд пам'яті сам по собі не принесе багато користі. Без поведінкового аналізу складно судити про призначення коду. Також незрозуміло, в який саме момент слід запускати сканування, тобто як визначити, що розшифровка закінчена (якщо вона взагалі не відбувається «на льоту»).
На ці особливості роботи протекторів накладаються механізми роботи з пам'яттю в сучасних ОС. У MS Windows безліч операцій відбувається асинхронно. У разі запису в файл дані спочатку осідають в пам'яті, а на диск записуються з буфера. Тобто момент скидання інформації на диск не визначений і незрозуміло, в контексті якого процесу це станеться.
Також всі сучасні ОС для поліпшення продуктивності працюють з файлом підкачки, в який вивантажується вміст віртуальної пам'яті. При несприятливому для захисного рішення розвитку подій віртуальна пам'ять може бути вивантажено до сканування фізичної пам'яті. Проблемою для безагентского рішення це стає тому, що воно має доступ лише до фізичної пам'яті. Таким чином, скидання віртуальної пам'яті в своп може серйозно перешкодити роботі рішення.
Нарешті, якщо шкідливий написаний на скриптовій мовою і виконується інтерпретатором, то сам скрипт в пам'яті може бути присутнім лише частково. В результаті шкідливих функцій в пам'яті не виявиться, але скрипт проте виконається.
Якщо говорити про специфіку захисту віртуальних середовищ, то тут на роботу з пам'яттю накладаються ще й особливості гипервизора. Він отримує управління в строго певні моменти, кількість яких обмежена. А це, в свою чергу, обмежує і можливі детектування зловредів в пам'яті.
Як повинна виглядати повноцінний захист
Отже, сканування оперативної пам'яті дуже корисно для боротьби з шкідливий, але захисне рішення повинно бути багаторівневим. Паралельно зі скануванням пам'яті необхідний і збір докладних даних про динаміку що відбуваються на хості подій. Зайве захоплення скануванням пам'яті може уповільнити роботу захисного рішення, що не принісши значного його посилення.
У будь-якому випадку, розуміючи різницю в потребах різних замовників, «Лабораторія Касперського» реалізувала обидва варіанти: безагентское рішення і рішення з «легким» агентом. Саме друга забезпечує збір всіх перерахованих вище поведінкових даних, що дозволяють надійніше захистити пристрій. Про порівняння цих двох рішень можна прочитати тут .
Дізнатися більше про підхід «Лабораторії Касперського» до захисту віртуальних середовищ і зв'язатися з нашими фахівцями можна на цій сторінці .
Чому важливий саме доступ до оперативної пам'яті?