По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
DNS спуфинг (spoofing), так же известный как отравление DNS кэша (cache poisoning), вид атаки, когда DNS кэш заполняется поддельными данными, в результате чего пользователь перенаправляется на вредоносный сайт.
Отравление DNS-кэша является результатом уязвимостей, которые позволяют преступникам отправлять поддельные DNS-ответы, которые серверы доменных имен (DNS - Domain Name Server) сохраняют в своих кэшах.
Обычно скомпрометированная запись перенаправляет пользователя на поддельный веб-сайт, который злоумышленники используют для совершения преступных действий, таких как распространение вредоносных программ или кража реквизитов кредитных карт, паролей, финансовых данных или другой конфиденциальной и частной информации.
При отравлении DNS-кэша сервер кэша DNS сохраняет нелегитимный адрес, предоставленный злоумышленником, а затем выдает его пользователям, запрашивающим подлинный веб-сайт. В большинстве случаев он может выглядеть аналогично аутентичному веб-сайту, поэтому посетителям становится сложнее отличить поддельный сайт от настоящего.
Влияние отравления DNS-кэша
DNS спуфинг, обычно трудно обнаружить и может оказать большое негативное влияние, особенно для популярных веб-сайтов или веб-приложений со большим количеством посещений или зарегистрированными пользователями. Это представляет большой риск, особенно в некоторых чувствительных отраслях, таких как банковская, медицинская, онлайн-ритейл, электронная коммерция и другие.
Например, предполагается, что злоумышленникам удается изменить DNS-записи и IP-адреса для Amazon. Затем они направляют запрос на другой сервер с поддельным IP, который контролируют или принадлежит злоумышленникам. Любой человек, пытающийся получить доступ к подлинному сайту Amazon, будет перенаправлен на неправильный адрес, который может содержать вредоносные программы для кражи конфиденциальной информации.
Кроме веб-сайтов, злоумышленник может вставить поддельный адрес для сервера электронной почты или других веб-приложений, таких как банковские приложения.
Поскольку изменения в DNS регулярно распространяются с одного сервера на другой, отравленный кэш может распространяться на другие DNS-серверы и системы, что приводит к большому ущербу. Например, поддельная запись может быстро распространяться на другие машины, такие как DNS-серверы Интернет-провайдеров, которые затем будут хранить ее в своем кэше. Отсюда он распространяется дальше на оборудования пользователей, такое как браузеры, мобильные телефоны и маршрутизаторы, которые также будут хранить поддельную запись в своих кэшах.
Как работает атака отравление DNS-кэша?
Преступники могут отравить кэш DNS с помощью различных методик.
Во время обычных операций DNS-запросы хранятся или кэшируются в базе данных, которую пользователи веб-сайтов могут запрашивать в режиме реального времени. Как правило, база данных DNS содержит список имен Интернета и соответствующих IP-адресов. И это облегчает поиск и доступ к веб-сайтам с использованием имен в отличие от IP-адресов, что может быть очень сложным и запутанным.
Например, без системы DNS пользователям потребуется запомнить строку чисел, составляющих IP-адреса для всех веб-сайтов, которые они хотят посетить.
К сожалению, DNS имеет несколько недостатков в безопасности, которые злоумышленники могут использовать и вставлять в систему поддельные записи адресов интернет-домена. Обычно преступники отправляют на DNS-сервер поддельные ответы. Затем сервер отвечает пользователю, сделавшему запрос, и одновременно законные серверы кэшируют поддельную запись. Как только сервер кэша DNS сохранит поддельную запись, все последующие запросы на скомпрометированную запись получат адрес сервера, управляемого злоумышленником.
Отравление DNS-кэша в целом состоит из внедрения поврежденных записей в базу данных кэша сервера имен, и злоумышленники используют различные методы. К ним относятся:
Когда пользователь веб-сайта или веб-приложения отправляет запрос на определенный домен через браузер или онлайн-приложение, DNS-сервер сначала проверяет, существует ли запись в кэше. Если он не сохранен, он запросит информацию у авторитетных DNS-серверов, а затем ждет ответа. В течение некоторого времени злоумышленники будут использовать этот узкий период ожидания, временно брать на себя роль исходного DNS и выдавать поддельный ответ до того, как авторитетный сервер отправит подлинный адрес. Однако, поскольку период ожидания обычно очень короткий, показатель успеха очень низкий.
Другой способ включает отправку поддельных ответов от DNS-сервера, олицетворяющего легитимный. Поскольку проверка DNS обычно не выполняется, злоумышленники могут подделать ответ от DNS-распознавателя по мере запроса сервера имен. Это также становится возможным благодаря тому, что DNS-серверы используют протокол пользовательских датаграмм (UDP) вместо TCP. Обычно связь DNS небезопасна из-за незашифрованной информации в пакетах UDP и отсутствия аутентификации. Это облегчает злоумышленникам вставлять в ответы поддельные адреса.
Уязвимости DNS используемые злоумышленниками
Уязвимости безопасности в определенных веб-приложениях, а также отсутствие надлежащей аутентификации DNS-записей позволяют киберпреступникам легко скомпрометировать ответы DNS и остаться незамеченными. Некоторые из этих уязвимостей включают в себя:
Отсутствие проверки и валидации
DNS имеет первую структуру доверия, которая не требует проверки IP-адреса для подтверждения его подлинности перед отправкой ответа. Поскольку DNS-распознаватели не проверяют данные в кэше, там остается неверная запись, пока она не будет удалена вручную или не истечет срок действия TTL.
Уязвимость рекурсивного DNS-сервера
Когда рекурсивный запрос активен, DNS-сервер получает запрос и выполняет всю работу по поиску правильного адреса и отправке ответа пользователю. Если у него нет записи в кэше, он будет запрашивать ее у других DNS-серверов от имени клиента, пока не получит адрес и не вернет его пользователю. Включение рекурсивного запроса представляет уязвимость безопасности, которую злоумышленники могут использовать для отравления кэша DNS.
Поскольку сервер ищет адрес, он предоставляет злоумышленнику возможность перехватить трафик и предоставить поддельный ответ. Затем рекурсивный DNS-сервер отправит ответ пользователю и одновременном сохранит поддельный IP-адрес в кэше.
Отсутствие шифрования
Как правило, протокол DNS не зашифрован, и это облегчает злоумышленникам перехват его трафика. Кроме того, серверы не должны проверять IP-адреса, на которые они направляют трафик, следовательно, они не могут определить, является ли он подлинным или поддельным.
Как предотвратить DNS спуфинг?
Мониторинг данных DNS в реальном времени может помочь установить наличие в трафике необычных шаблонов, действий пользователей или поведения, таких как посещение вредоносных веб-сайтов. И хотя обнаружение отравления DNS-кэшем затруднено, существует несколько мер безопасности, и компании и поставщики услуг могут принять меры, чтобы предотвратить это. Некоторые из мер, предотвращающих отравление DNS-кэша, включают использование DNSSEC, отключение рекурсивных запросов и многое другое.
Предельный уровень отношений доверия
Одной из уязвимостей DNS-транзакций являются отношения высокого доверия между различными DNS-серверами. Это означает, что серверы не проверяют подлинность получаемых ими записей, что позволяет злоумышленникам даже отправлять поддельные ответы со своих нелегитимных серверов.
Чтобы злоумышленники не использовали этот недостаток, группы безопасности должны ограничить уровень доверительных отношений, которые имеют их DNS-серверы с другими. Настройка DNS-серверов таким образом, чтобы они не опирались на доверительные отношения с другими DNS-серверами, затрудняет использование киберпреступниками DNS-сервера для компрометации записей на законных серверах.
Существует множество инструментов для проверки наличия угроз безопасности DNS.
Использование протокола DNSSEC
Расширения безопасности системы доменных имен (DNSSEC - Domain Name System Security Extensions) используют криптографию с открытым ключом для подписи DNS-записей, поэтому они добавляют функцию проверки и позволяют системам определять, является ли адрес законным или нет. Это помогает проверять и аутентифицировать подлинность запросов и ответов и тем самым предотвращать подделку.
При обычной работе протокол DNSSEC связывает уникальную криптографическую подпись с другой информацией DNS, такой как записи CNAME и A. Затем DNS-распознаватель использует эту подпись для проверки подлинности DNS-ответа перед отправкой его пользователю.
Подписи безопасности гарантируют, что ответы на запросы, которые получают пользователи, проверяются законным исходным сервером. Хотя DNSSEC может предотвратить отравление кэша DNS, он имеет такие недостатки, как сложное развертывание, предоставление данных и уязвимость перечисления зон в более ранних версиях.
Не уверены, что в вашем домене включен DNSSEC? Немедленно проверьте с помощью инструмента DNSSEC Test.
Используйте последние версии программного обеспечения DNS и BIND (Berkeley Internet Name Domain)
BIND версии 9.5.0 или выше обычно имеет расширенные функции безопасности, такие как криптографически безопасные идентификаторы транзакций и рандомизация портов, что помогает минимизировать отравление DNS-кэша. Кроме того, ИТ-специалисты должны поддерживать программное обеспечение DNS в актуальном состоянии и гарантировать, что оно является самой последней и безопасной версией.
Помимо вышеизложенного, ниже приведены другие эффективные способы или практики предотвращения отравления DNS-кэшем.
Настройка DNS-сервера для ответа только информацией, относящейся к запрошенному домену
Убедитесь, что на сервере кэша хранятся только данные, относящиеся к запрошенному домену
Принудительно использовать сети IP для всего трафика
Отключить функцию рекурсивных запросов DNS
Заключение
Отравление кэш-памяти DNS приводит к перенаправлению пользователей домена на вредоносные адреса. Некоторые серверы, управляемые злоумышленниками, могут обманывать ничего не подозревающих пользователей, которые загружают вредоносные программы или предоставляют пароли, информацию о кредитных картах и другие конфиденциальные личные данные. Для предотвращения этого важно использовать передовые методы обеспечения безопасности.
OSPF (Open Shortest Path First) – дословно переводится как «Сперва открытый короткий путь» - надежный протокол внутренней маршрутизации с учетом состояния каналов (Interior gateway protocol, IGP). Как правило, данный протокол маршрутизации начинает использоваться тогда, когда протокола RIP уже не хватает по причине усложнения сети и необходимости в её легком масштабировании.
OSPF наиболее широко используемый протокол внутренней маршрутизации. Когда идёт речь о внутренней маршрутизации, то это означает, что связь между маршрутизаторами устанавливается в одном домене маршрутизации, или в одной автономной системе. Представьте компанию среднего масштаба с несколькими зданиями и различными департаментами, каждое из которых связано с другим с помощью канала связи, которые дублируются с целью увеличения надежности. Все здания являются частью одной автономной системы. Однако при использовании OSPF, появляется понятие «площадка», «зона» (Area), которое позволяет сильнее сегментировать сеть, к примеру, разделение по «зонам» для каждого отдельного департамента.
Видео: протокол OSPF (Open Shortest Path First) за 8 минут
Для понимания необходимости данных «зон» при проектировании сети, необходимо понять, как OSPF работает. Есть несколько понятий, связанных с этим протоколом, которые не встречаются в других протоколах и являются уникальными:
Router ID: Уникальный 32-х битный номер, назначенный каждому маршрутизатору. Как правило, это сетевой адрес с интерфейса маршрутизатора, обладающий самым большим значением. Часто для этих целей используется loopback интерфейс маршрутизатора.
Маршрутизаторы-соседи: Два маршрутизатора с каналом связи между ними, могут посылать друг другу сообщения.
Соседство: Двухсторонние отношения между маршрутизаторами-соседями. Соседи не обязательно формируют между собой соседство.
LSA: Link State Advertisement – сообщение о состоянии канала между маршрутизаторами.
Hello сообщения: С помощью этих сообщений маршрутизаторы определяют соседей и формируют LSA
Area (Зона): Некая иерархия, набор маршрутизаторов, которые обмениваются LSA с остальными в одной и той же зоне. Зоны ограничивают LSA и стимулируют агрегацию роутеров.
OSPF – протокол маршрутизации с проверкой состояния каналов. Представьте себе карту сети – для того, чтобы ее сформировать, OSPF совершает следующие действия:
Сперва, когда протокол только запустился на маршрутизаторе, он начинает посылать hello-пакеты для нахождения соседей и выбора DR (designated router, назначенный маршрутизатор). Эти пакеты включают в себя информацию о соседях и состоянии каналов. К примеру, OSPF может определить соединение типа «точка-точка», и после этого в протоколе данное соединение «поднимается», т.е. становится активным. Если же это распределенное соединение, маршрутизатор дожидается выбора DR перед тем как пометить канал активным.
Существует возможность изменить Priority ID для, что позволит быть уверенным в том, что DR-ом станет самый мощный и производительный маршрутизатор. В противном случае, победит маршрутизатор с самым большим IP-адресом. Ключевая идея DR и BDR (Backup DR), заключается в том, что они являются единственными устройствами, генерирующими LSA и они обязаны обмениваться базами данных состояния каналов с другими маршрутизаторами в подсети. Таким образом, все не-DR маршрутизаторы формируют соседство с DR. Весь смысл подобного дизайна в поддержании масштабируемости сети. Очевидно, что единственный способ убедиться в том, что все маршрутизаторы оперируют одной и той же информацией о состоянии сети – синхронизировать БД между ними. В противном случае, если бы в сети было 35 маршрутизаторов, и требовалось бы добавить еще одно устройство, появилась бы необходимость в установлении 35 процессов соседства. Когда база централизована (т.е существует центральный, выбранный маршрутизатор - DR) данный процесс упрощается на несколько порядков.
Обмен базами данных – крайне важная часть процесса по установлению соседства, после того как маршрутизаторы обменялись hello-пакетами. При отсутствии синхронизированных баз данных могут появиться ошибки, такие как петли маршрутизации и т.д. Третья часть установления соседства – обмен LSA. Это понятие будет разобрано в следующей статье, главное, что необходимо знать – нулевая зона (Area 0) особенная, и при наличии нескольких зон, все они должны быть соединены с Area 0. Так же это называется магистральной зоной.
Типы маршрутизаторов OSPF
Разберем различные типы маршрутизаторов при использовании протокола OSPF:
ABR
Area Border Router – маршрутизатор внутри нулевой зоны, через который идет связь с остальными зонами
DR, BDR
Designated Router, Backup Designated Router – этот тип маршрутизаторов обсуждался выше, это основной и резервирующий маршрутизаторы, которые ответственны за базу данных маршрутизаторов в сети. Они получают и посылают обновления через Multicast остальным маршрутизаторам в сети.
ASBR
Autonomous System Boundary Router – этот тип маршрутизаторов соединяет одну или несколько автономных систем для осуществления возможного обмена маршрутами между ними.
Подведем итоги
OSPF является быстро сходящимся протоколом внутренней маршрутизации с контролем состояния каналов
Процесс соседства формируется между соседними маршрутизаторами через DR и BDR, используя LSA
Зоны в данном протоколе маршрутизации используются для ограничения LSA и суммирования маршрутов. Все зоны подключаются к магистральной зоне.
Несмотря на доступ к все более эффективному и мощному оборудованию, операции, выполняемые непосредственно на традиционных физических (или «чистых») серверах, неизбежно сталкиваются со значительными практическими ограничениями. Стоимость и сложность создания и запуска одного физического сервера говорят о том, что эффективное добавление и удаление ресурсов для быстрого удовлетворения меняющихся потребностей затруднено, а в некоторых случаях просто невозможно. Безопасное тестирование новых конфигураций или полных приложений перед их выпуском также может быть сложным, дорогостоящим и длительным процессом.
Исследователи-первопроходцы Джеральд Дж. Попек и Роберт П. Голдберг в статье 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) иногда может оказаться немного сложнее. Даже создание клонированного образа простого физического сервера и его импорт в пустую виртуальную машину может сопровождаться определенными трудностями. И как только все это будет выполнено, вам, возможно, придется внести некоторые корректировки в системную архитектуру, чтобы можно было использовать возможности, предлагаемые виртуализацией, в полную силу. В зависимости от операционной системы, которую вы перемещаете, вам также может потребоваться использование паравиртуализированных драйверов для того, чтобы ОС могла корректно работать в своем «новом доме».
Как и в любых других ситуациях управления сервером: тщательно все продумывайте заранее.