Сервер для виртуальных машин

Сервер для виртуальных машин

Гипервизоры (технологии виртуализации) существуют более 30 лет и за это время сумели стать одним из главных «винтиков» в составе облачной экосистемы. Многие компании, подбирающие решения для виртуализации, останавливают свой выбор на двух популярных гипервизорах — VMware и KVM. Предлагаем разобраться какой же из них лучше. Но для начала немного теории.

Что такое гипервизор?

Гипервизор — это программа, отделяющая операционную систему от железа. Гипервизоры виртуализируют ресурсы сервера (процессор, память, диск, сетевые интерфейсы и др.), позволяя использовать их как свои собственные, и создают на основе одного сервера несколько отдельных виртуальных машин. Каждая созданная виртуальная машина изолируется от соседей, чтобы не влиять на работу других. Для работы гипервизора необходима поддержка виртуализации: для процессоров Intel на процессоре Intel VT, а для процессоров AMD на AMD-V.

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

Гипервизоры второго типа, также известные как размещенные гипервизоры (Hosted Hypervisor), работают с операционной системой, установленной на сервере. А операционные системы для новых пользователей создаются поверх гипервизора.

Настольные гипервизоры, такие как Oracle VirtualBox или VMware Workstation, являются гипервизорами второго типа, а VMware и KVM – первого. VMware и KVM устанавливаются непосредственно на сервер и не требуют установки какой-либо операционной системы.

VMware vSphere

Перед покупкой VMware vSphere можно попробовать поработать в пробной версии (60 дней), после чего необходимо покупать лицензию, либо мириться с ограничениями бесплатной версии.

В бесплатной версии, которая называется VMware Free vSphere Hypervisor, нет ограничений для хоста по процессорам и памяти, зато есть ряд других:

  • API продукта доступно только для чтения;
  • виртуальная машина не может иметь более 8 ядер;
  • ее нельзя использовать вместе с Veeam для создания резервных копий;
  • подключение к vCenter Server не поддерживается;
  • не поддерживается и высокая доступность, а также технологии VM Host Live Migration и VM Storage Live Migration.

Продукт от VMware отличается от аналогов поддержкой большого количества операционных систем — Windows, Linux, Solaris, FreeBSD, Netware, MacOS и других.

Установка дистрибутива VMware на сервер очень проста: достаточно загрузиться с CD, флешки или через PXE. К тому же поддерживаются сценарии, позволяющие автоматизировать процесс инсталляции программного обеспечения, настройку сети и подключения к vCenter Server.

Немаловажно и наличие специального конвертера VMware vCenter Converter, позволяющего использовать в ESXi образы MS Virtual Server, Virtual PC, Hyper-V, а также физические серверы и образы дисковых разделов, созданных такими программами как Acronis True Image, Norton Ghost и другими.

У VMware vSphere есть встроенная интеграция с Microsoft Active Directory, то есть аутентификацию пользователей в частном или гибридном облаке можно производить при помощи доменных служб Microsoft. Гибкое распределение ресурсов позволяет использовать горячее добавление CPU, ОЗУ и жесткого диска (в том числе изменять размер текущего жесткого диска без перезагрузки).

VMware Fault Tolerate — технология VMware, предназначенная для защиты виртуальных машин с помощью кластеров непрерывной доступности. При отказе хоста (сервера ESXi) с основной (Primary) рабочей копией виртуальной машины, защищенная виртуальная машина мгновенно переключится на «вторичную» (Secondary) или «теневую» копию, работающую на другом сервере ESXi. Для машин, защищенных VMware Fault Tolerance, происходит постоянное (в реальном времени) копирование всего состояния памяти и процессорных инструкций с основной копии на «теневую». При сбое основного хоста ESXi, пользователи даже не заметят процесса переключения на второй узел. Именно этим Fault Tolerance отличается от High Availability. В High Availability при отказе физического сервера виртуальные машины будут перезапущены на других узлах, и пока операционные системы перезагружаются пользователи не смогут получить доступ к виртуальным серверам.

Кроме VMware Foult Tolerate, лицензия VMware vCloud Suite Enterprise обеспечивает высокую доступность, отказоустойчивость и восстановление после аварий с помощью функций vSphere HA, vMotion, Storage vMotion, и vCenter Site Recovery Manager.

Для уменьшения плановых остановок в обслуживании серверов или систем хранения данных (СХД), функции vMotion и Storage vMotion в онлайн-режиме переносят виртуальные машины и их диски без остановки работы приложений и пользователей. Функция vSphere Replication поддерживает разные варианты репликации vCenter Site Recovery Manager (SRM) для защиты от крупных аварий. SRM обеспечивает централизованное планирование послеаварийного восстановления, автоматические Failover и Failback с резервного сайта или из облака vCloud, а также тестирование послеаварийного восстановления без прерывания работы приложений.

К особенностям этого гипервизора стоит отнести избирательность к железу — перед установкой необходимо тщательно проверить имеющееся оборудование на совместимость с нужной версией ESXi. Для этого на сайте VMware есть специальная страница.

Лицензирование продуктов VMware имеет свои особенности. Дополнительную путаницу добавляют периодические изменения (от версии к версии vSphere) в лицензионной политике VMware. Существует несколько пунктов, которые нужно учесть перед приобретением лицензий VMware vSpere:

  • лицензирование гипервизора выполняется по числу физических процессоров (CPU). Каждый CPU сервера требует отдельной лицензии vSphere (ядра не являются физическими процессорами и не учитываются в лицензировании);
  • доступный функционал сервера ESXi определяется установленной на нем лицензией vSphere. Подробное руководство по лицензиям есть на сайте VMware;
  • для каждой купленной лицензии vShpere необходимо приобретать пакет сервисной поддержки (минимум на год);
  • VMware не накладывает ограничения на количество памяти (RAM), установленной на сервере, и на количество запущенных виртуальных машин.

Управлять множеством хостов с гипервизорами ESXi, СХД и сетевым оборудованием можно с помощью еще одного продукта VMware — Vcenter Server. Подключаемые модули клиента vSphere, предоставляемые партнерами VMware, дают IT-администраторам возможность управлять сторонними элементами в дата-центре непосредственно из этой консоли. Поэтому пользователи vCenter могут выполнять резервное копирование, защищать данные, управлять серверами, сетями и безопасностью непосредственно из интерфейса vCenter. В этой же консоли можно настроить триггеры, которые оповестят о возникших проблемах, и получить данные о работе всей инфраструктуры в виде графиков или таблиц.

KVM — простой в использовании, легкий, нетребовательный к ресурсам и довольно функциональный гипервизор. Он позволяет за минимальные сроки развернуть площадку виртуализации и организовать виртуализацию под управлением операционной системы Linux. В процессе работы KMV осуществляет доступ к ядру операционной системы через специальный модуль (KVM-Intel или KVM-AMD). Изначально KVM поддерживал только процессоры x86, но современные версии KVM поддерживают самые разные процессоры и гостевые операционные системы, в том числе Linux, BSD, Solaris, Windows и др. Кстати, все Wiki-ресурсы (MediaWiki, Wikimedia Foundation, Wikipedia, Wikivoyage, Wikidata, Wikiversity) используют именно этот гипервизор.

Читайте также:  Как на диске установить две windows xp

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

KVM позволяет виртуальным машинам использовать немодифицированные образы дисков QEMU, VMware и другие образы, содержащие операционные системы. Каждая виртуальная машина имеет своё собственное виртуальное аппаратное обеспечение: сетевые карты, диск, видеокарту и другое железо.

Благодаря поддержке немодифицированных образов VMware, физический сервер можно легко виртуализовать при помощи все той же утилиты VMware vServer Converter, а затем перенести полученный файл в гипервизор.

Установка KVM в операционной системе Linux заключается в инсталляции пакета KVM и библиотеки виртуализации Libvirt, а также в тщательной настройке среды виртуализации. В зависимости от используемой на хосте операционной системы необходимо настроить мост или подключение к VNC-консоли, с помощью которой виртуальные машины будут взаимодействовать с хостом.

Администрировать KVM сложнее, так как прозрачный доступ к файлам, процессам, консолям и сетевым интерфейсам отсутствует, это приходится настраивать самостоятельно. Перестройка параметров VM в KVM (CPU, RAM, HDD) не очень удобна и требует дополнительных действий, включающих перезагрузку ОС.

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

У KVM нет встроенных инструментов, подобных Fault Tolerate для VMware, поэтому единственный способ создать кластер высокой доступности — использовать сетевую репликацию при помощи DRDB. Кластер DRBD поддерживает только два узла, а узлы синхронизируются без шифрования. То есть для более безопасной связи необходимо использовать VPN-соединение.

Кроме того, для построения кластера высокой доступности понадобится программа Heartbeat, которая позволяет обмениваться служебными сообщениями о своем состоянии узлам в кластере, и Pacemaker — менеджер ресурсов кластера.

Гипервизор KVM распространяется как продукт с открытым исходным кодом, а для корпоративных пользователей существует коммерческое решение Red Hat Virtualization (RHEL), основанное на KVM и платформе управления виртуальной инфраструктурой oVirt.

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

Следует учесть, что у KVM нет службы поддержки. Если что-то не получится, можно рассчитывать на форумы и помощь сообщества. Или перейти на RHEL.

Так что же выбрать?

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

KVM обычно более масштабируем, чем VMware, в первую очередь потому что vSphere имеет некоторые ограничения на серверы, которыми он может управлять. Кроме того, VMware добавила большое количество сетей хранения данных (SAN) для поддержки различных поставщиков. Эта функция означает, что VMware имеет больше вариантов хранения, чем KVM, но также усложняет поддержку хранилища VMware при расширении.

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

Исследования показали, что совокупная стоимость владения KVM, как правило, на 39 процентов ниже, чем у VMware, хотя фактическая совокупная стоимость владения зависит от специфичных факторов, таких как эксплуатационные параметры и рабочая нагрузка площадки.

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

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

Подскажите, как рассчитывается !примерное кол-во виртуальных машин, которые можно развернуть на сервере определенной производительности, например:
Intel® Core™ i7-4770 32 GB DDR3 RAM

Разворачиваться будет виндовс по SPLA, т.е. — Server 2012, из ПО — 1С, и , возможно — Mic. Office.

Расчет необходим для компаний (не для сервиса), нужно понимать сколько примерно серверов понадобится. Спасибо!

  • Вопрос задан более трёх лет назад
  • 1572 просмотра

150МБ на простого пользователя с одной базой. Сейчас двадцать человек в 1с потребляют около 5 ГБ.
Нужны подробности.

=== точное
не так ли?

32 GB — 1 GB (для хостовой ОС) = 31 GB / (RAM для виртуалки например 512MB) = 62 виртуалки

Но у тебя все скорее упрется в ЦПУ
ark.intel.com/compare/75124,75125,75610,76642,83505
# of Threads 8
отсюда следует, что одновременно "комфортно" будут работать 8 — 1 = 7 виртуалок

Но реального способа узнать сколько, кроме как натурного теста с поднятием виртуалок, нет

Это так же как рассчитать сколько блинчиков ты можешь скушать в обед , это зависит насколько ты голоден и вкусные ли блинчики так же и с сервером

что будет на сервере
сколько будут сервисы кушать озу и дисковой подсистемы
на таком конфиге у меня был терминальник 50 чел сители в инете офис и 1с скайп icq , комфортная работа была в приделе 45 чел

hetzner EX40, я так понимаю.
8 машинок (если полная виртуализация, а с виндой она такой будет), дальше машины начинают воевать за диск.
С трудом можно всунуть 16 машин, но если они что-то начнут делать с диском одновременно — все пользователи будут наслаждаться целыми 2IOPS на виртуалку.

Содержание статьи

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

Двери в виртуальный мир

За последние годы на рынке появилось множество виртуальных машин — от
узкоспециализированных (Bochs, eEye) до эмуляторов общего
назначения (VMware, VirtualBox, QEMU, XEN,
Virtual PC
). Интерес к виртуализации растет, а сами эмуляторы по ходу дела
осваивают новые профессии, становясь все более и более привлекательными
игрушками в глазах системных администраторов. Именно «игрушками» – потому что к
введению в промышленную эксплуатацию существующие эмуляторы еще не готовы. Ущерб
от их использования намного превышает стоимость живого железа, которое они
призваны заменять (не говоря уже о том, что большинство эмуляторов
распространяются на коммерческой основе или, попросту, стоят денег).

Читайте также:  Как открыть дбф файл на компьютере

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

Существует, по меньшей мере, три типа виртуальных машин (не считая
гибридов). К самым первым (и самым древним) относятся машины с полной
эмуляцией
. Классический пример — Bochs. Тормозит ужасно, зато позволяет
эмулировать «чужеродные» архитектуры, например, x86 на Мотороллере или x86-64 на
x86. Возвести многопроцессорную машину на однопроцессорной? Без проблем. Причем,
основная операционная система надежно изолирована от гостевых виртуальных машин
и причинить ей ущерб невероятно трудно. Bochs очень хорошо подходит для
экспериментов с вирусами, червями и прочим зловредным ПО. Также его можно
использовать для того, чтобы опробовать 64-разрядные операционные системы,
прежде чем решиться покупать x86-64 – но высокие накладные расходы на эмуляцию
(даже с учетом оптимизации и кэширования инструкций) предъявляют жесткие
требования к аппаратной оснастке базовой машины. И проблема здесь даже не в том,
что WinXP на P-4 под «Борщем» стартует около суток. Она вообще не стартует!
Поскольку куча операций отваливается по тайм-ауту, в частности, если процедура
инициализации драйвера выполняется свыше 10 секунд, система автоматически
выгружает драйвер со всеми вытекающими отсюда последствиями.

Динамические виртуальные машины (QEMU, VMware, VirtualBox) эмулируют
лишь привилегированные инструкции (равно, как и непривилегированные инструкции,
имеющие доступ к системным данным). За счет этого скорость эмуляции возрастает
на несколько порядков, и на P-III 733 уже можно комфортно работать в среде
виртуального Win2k3, а на P-4 все просто летает. Расплатой за скорость
становится принципиальная невозможность эмуляции «чужеродных» архитектур, плюс
потенциальный риск атаки на основную операционную систему из гостевой.
Теоретически, создать надежный динамический эмулятор вполне возможно, но
практически… это же тысячи строк на Си/Си++ и мегабайты кода! К тому же,
разработчики QEMU и VMware даже не пытались защитить основную систему от атаки
со стороны гостевых виртуальных машин, чем с успехом пользуются вирусы и черви.

Аппаратная виртуализация (поддерживаемая последними моделями
процессоров Intel и AMD) устраняет ляпы в x86-архитектуре, где системные данные
надежно защищены только от записи, но могут быть прочитаны с прикладного уровня
легальными непривилегированными командами. Это вынуждает эмулятор просматривать
блок кода перед его выполнением, на что расходуется время. В процессорах фирмы
Motorola таких дефектов нет, и потому динамическая эмуляция на них работает
намного быстрее (и без всякой новомодной аппаратной поддержки!). Но рынок
захватила x86-архитектура, вытеснив Motorol’у, и потому аппаратную виртуализацию
встречают с очень большим энтузиазмом. Теоретически, скорость эмуляции должна
вплотную приближаться к «живому» процессору, поскольку накладные расходы на
виртуализацию близки к нулю. Однако, помимо процессора, виртуальная машина
вынуждена эмулировать еще и оборудование. Без жестких дисков ведь не обойтись, а
давать прямой доступ к физическим хардам — самоубийство. В этом причина того,
что производительность виртуальных машин (даже с поддержкой аппаратной эмуляции)
существенно отстает от живого железа, но все-таки обгоняет динамическую
эмуляцию.

Естественно, за повышение скорости приходится платить. Во-первых, необходимо
приобрести процессор с поддержкой аппаратной виртуализации (ладно, это не
проблема, приобретем в ходе очередного планового апгрейда). Во-вторых (а вот это
уже действительно серьезно) — процессоры содержат кучу дефектов, позволяющих
воздействовать на основную операционную систему из гостевых виртуальных машин.
Исправить ошибку в процессоре намного сложнее, чем в полностью программном
эмуляторе! И что самое неприятное – спонтанные падения основной системы
происходят даже без всякой атаки со стороны вредоносного кода! Словом,
аппаратная виртуализация до сих пор остается плохо отлаженной игрушкой, не
готовой к промышленному внедрению. Несмотря на это, Microsoft уже включила
эмулятор с поддержкой аппаратной виртуализации в состав Win2k8, конкурирующий с
бесплатным проектом XEN.

Виртуальные сервера

Как можно использовать виртуальную машину в корпоративной или офисной сети?
Например, поднять виртуальный сервер. А что? Допустим, нам нужен публичный WEB и
приватный SQL. По соображениям безопасности, публичный сервер должен быть
расположен в так называемой демилитаризованной (DMZ) зоне, а приватный SQL –
внутри локальной сети, обнесенной по периметру глубоким защитным рвом
(брандмауэром). Что требует двух машин. А как быть, если в наличии имеется
только одна?

Теоретически (подчеркиваю!), можно поднять VMware или Virtual PC, разместив
публичный WEB-сервер на виртуальной машине, а приватный SQL – на основной. И это
как бы будет работать. «Как бы» – потому что для достижения приемлемого уровня
производительности даже при поддержке аппаратной виртуализации нам понадобится
довольно мощное железо, способное тянуть эмулятор с разумной скоростью. Значит,
много сэкономить все равно не удастся, а если добавить к этой сумме издержки от
неизбежных атак на виртуальную машину и сбои самой виртуальной машины, в
долгосрочной перспективе мы имеем весьма внушительные убытки. Купить два
отдельных физических сервера — дешевле, да и работать они будут намного
стабильнее. А если денег на железо нет, то лучше отказаться от DMZ-зон, поселив
публичные и приватные сервисы на одной машине и запретив приватным сервисам
принимать трафик с внешних интерфейсов. А для надежности – еще и закрыть порты
на брандмауэре. Как говорится, дешево и сердито, но это все-таки лучше, чем
возня с виртуальными машинами.

Загон для вирусов

Достаточно часто виртуальные машины используются для экспериментов с
потенциально небезопасным программным обеспечением, полученным из ненадежных
источников. Антивирусная проверка — не слишком-то хорошее средство для поиска
неизвестных или модифицированных червей, вирусов и руткитов. Вредителям хорошо
известно, как «ослепить» проактивные технологии и эвристические анализаторы.
Утилиты, ориентированные на поиск руткитов, хорошо работают лишь в первые дни
своего появления, а затем хакеры находят обходной путь.

Прямое сравнение дисковых образов палит все руткиты, червей и вирусы без
исключения (конечно, при условии, что они вносят изменения в файловую систему, а
не ограничиваются заражением одной лишь оперативной памяти, умирая при
перезагрузке). Алгоритм поиска заразы выглядит так: снимаем образ стерильной
системы, сохраняя его в надежном месте, устанавливаем новое программное
обеспечение, снимаем еще один образ. Монтируем оба образа на заведомо не
зараженную систему и сравниваем их. Тривиальное пофайловое сравнение выявляет
до 90% малвари
. Остальные 10% обнаруживает побайтовое сравнение,
«вытягивающее» вирусы, прячущиеся в NTFS-потоках или других местах (работая с
диском на низком уровне, мы должны знать все базовые структуры файловой системы,
подробно описанные в моей книге «Техника восстановления данных», электронную
копию которой можно бесплатно скачать здесь:

Читайте также:  Как зайти вконтакте без регистрации

nezumi.org.ru/recover-full-rus.zip).

Естественно, проводить подобные эксперименты лучше всего под эмулятором. Так
намного проще оперировать образами виртуальных жестких дисков, да и выделять
отдельную (физическую) машину не потребуется. Удобство, простота и экономия —
налицо. Но простота хуже воровства, и экономия на выделенной машине до добра не
доводит. Если виртуальная машина соединена с основной системой виртуальной
сетью, то черви могут атаковать базовую операционную систему, используя дыры в
сетевых службах. Администратору следует либо своевременно устанавливать все
заплатки, либо отключить вирусный загон от Сети вообще – не забывая про
расшаренные ресурсы. Виртуальная машина VMware поддерживает их в обход
Ethernet-адаптера. Шары продолжают работать даже после удаления виртуальной
сетевой карты, и подвержены сразу двум типам атак — через дыры в сервисе «общих
папок» и путем засылки червей, модифицирующих шаблон папки, автоматически
«подхватываемый» Проводником. То же самое относится и ко всем остальным типам
носителей. Это существенно затрудняет обмен данными между виртуальной и основной
машинами. Самое надежное — копировать данные через CD-ROM (не обязательно
физический — подойдет и виртуальный, просто берем любую программу для создания
iso-образов и монтируем ее на основную систему и на VMware).

Важно: по умолчанию VMware автоматически распознает все подключаемые
USB-устройства и дает виртуальным машинам к ним полный доступ. Допустим, мы
подключаем FLASH, внешний жесткий диск с USB-интерфейсом или другой девайс
подобного рода, на котором тут же поселяется вирус, вырвавшийся из застенков
виртуальной машины. Чтобы предотвратить вторжение, достаточно отключить
USB-контроллер в свойствах виртуальной машины.

Однако проблемы на этом не заканчиваются. Руткиты уже давно научились
распознавать виртуальные машины
, отказываясь от заражения в их присутствии,
что ломает весь концепт. Мы устанавливаем программное обеспечение с руткитом на
виртуальную машину, сравниваем образы, ничего не находим и, довольные собой,
запускаем руткита в основную систему. Выходит, гарантировано обнаружить
современных руткитов при помощи виртуальных машин невозможно! А если еще учесть
большое количество дыр в эмуляторах, то руткит имеет все шансы заразить основную
систему из гостевой машины. Выход? Либо использовать выделенную живую машину,
либо надежную виртуальную машину с полной эмуляцией (например, Bochs). Это
предотвратит вирусное вторжение, но, увы, не спасет от детекции виртуальной
машины руткитом. Bochs содержит множество мелких дефектов эмуляции (ведет себя
не как настоящий процессор), которые не препятствуют работе нормальных программ,
но могут быть использованы для детекта эмулятора. К тому же, ЛЮБОЙ эмулятор
несет на своем борту довольно специфический набор виртуального железа, по
которому его легко опознать. И хотя при наличии исходных текстов мы можем
воспрепятствовать этому — купить живой компьютер намного дешевле, чем корежить
виртуальное железо.

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

Инструмент выявления сетевых атак

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

С ростом сети появляется желание установить специализированную систему
обнаружения вторжений, например, Snort (бесплатный) или AMP (коммерческий). И
разместить ее на выделенном узле, поскольку для установки того же AMP
администратор должен предоставить его поставщикам удаленный shell на свою
машину. Причем, AMP будет не только автоматом скачивать свежие сигнатуры из
Сети, но и отправлять весь подозрительный трафик для анализа на серверы компании
Endeavor, которая и является его разработчиком.

Доверие — это прекрасно, но отдавать свой трафик в чужие руки… Нет, лучше
размесить эту штуку на отдельном узле, отключенном от основной локальной сети,
но запитанном от того же самого ISP – то есть ловящего тех же вирусов и червей,
что и основные узлы локальной сети. Можно ли использовать для этой цели
виртуальную машину? Конечно! Главное, надежно изолировать ее от корпоративной
сети.

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

Какую именно виртуальную машину следует использовать? VMware очень известна и
слишком дырява. Bochs невероятно медленно работает. Virtual PC – неплохой выбор,
но учитывая большое количество дыр в процессорах, его использование крайне
небезопасно. Реально остается только VirtualBox, XEN или QEMU, хотя первый из
них все еще достаточно сырой и до сих пор не отлаженный.

Зеркальный сервер

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

Аналогичным образом дела обстоят с кручением настроек, смысла которых
администратор до конца не понимает и действует методом тыка. Одно неверное
движение руки — и система отказывается загружаться, а чтобы поднять ее,
требуются знания и квалификация, вырабатываемые только в борьбе с вот такими
взлетами и падениями. По книжкам всего не выучишь… И здесь виртуальные машины –
незаменимы.

Просто устанавливаем систему со всеми приложениями и сервисными службами на
VMware/Virtual PC/VirtualBox/etc, и все новые заплатки, обновления, настройки, в
первую очередь, обкатываем на гостевой операционной системе, наблюдая за ее
реакцией. Если полет нормальный — переносим изменения на основную машину. Если
же нет — соображаем, что здесь не так, и где косяк.

Итого

Виртуальные машины открывают практически неограниченные возможности для
экспериментов. Главное — правильно ими воспользоваться, предусмотрев максимум
возможных побочных эффектов и разработав план по их устранению.


Полную версию статьи
читай в октябрьском номере
Хакера!

Ссылка на основную публикацию
Самые необычные вещи с алиэкспресс
Свежая подборочка прикольных и необычных товаров продающихся на Алиэкспресс. Чем же удивят китайцы сегодня? Смотрим. Зимняя шапка с Bluetooth гарнитурой....
Распиновка audio разъема на материнской плате
Внимание. Некоторые устройства могут иметь стандартные разъёмы и не стандартное подключение. Будьте бдительны. ПИТАНИЕ: Распиновка разъема блока питания формата AT...
Распиновка mini usb разъема
Распиновка USB-кабеля означает описание внутреннего устройства универсальной последовательной шины. Это устройство применяется для передачи данных и зарядки аккумуляторов любых электронных...
Самые популярные дистрибутивы linux
Лайфхакер выбрал лучшие операционные системы для самых разных задач. На что обратить внимание при выборе дистрибутива Linux Существует огромное количество...
Adblock detector