Любой, кто читает новости информационной безопасности заметит, что новостные ленты пестрят сообщениями об успешных атаках крупнейших компаний ИТ-индустрии. Sony, Google, Nortel, RSA были вынуждены во всеуслышание заявить о неслыханном ранее. Кроме них множество других компаний заявило о том, что они подверглись атакам в стиле APT. Термин APT последние несколько лет на слуху у всех. Переводят его по-разному:
· изощренные постоянные угрозы
· постоянные прицельные атаки
· продвинутые постоянные угрозы
Видя разброд и шатание в дискуссиях об APT, а иногда и использование APT как нового способа продавать дорогостоящие товары и услуги в сфере ИБ я написал статью о том, что же такое APT и чем они отличаются от привычных нам атак.
Многие говорящие об атаке в стиле APT предполагают использование сложных средств или ранее неизвестных уязвимости. Другие верят, что если вы не гигантская корпорация, то вам нечего опасаться. Оба утверждения ошибочны. Чаще всего во время атаки применяются очень простые средства, известные каждому специалисту ИБ, такие как Windows Credential Editor, minkatz, pwdump.
Раньше было принято считать, что достаточно построить защиту, отражающую атаки случайных злоумышленников, и они уйдут атаковать соседа, то теперь так просто отделаться не удастся. С приходом APT модель атакующего кардинально изменилась. Теперь они отличаются чрезвычайной усидчивостью, настойчивостью и наличием больших ресурсов. Никаких технологически продвинутых приемов в APT не используется, поэтому Microsoft предлагает применять новый термин Determined Adversaries – настойчивые противники (атакующие). Это позволит более точно отразить происходящее в ИБ индустрии и вписать в единую картину такие явления как Stuxnet.
Если ваша компания работает над инновационными решениями, владеет ценной интеллектуальной собственностью, выполняет правительственные заказы или связана с политическими партиями, то скорее всего вам нужно тщательно проверить свою инфраструктуру и готовиться к отражению настойчивых и прицельных атак. Корпоративный шпионаж был всегда, но сейчас мы вошли в новую эру.
Как защищаться от атак в стиле APT рассказывается во второй статье. В ней я рассматриваю мифы, связанные с уязвимостями, рассказываю о быстром развертывании обновлений, говорю об инструментах проведения аудита инфраструктуры, таких как MSAT, MBSA и заканчиваю вариантами сегментирования сети с помощью IPsec.
Даже если вы не считаете, что ваша организация подвержена APT рекомендую посмотреть вебкаст про Advanced Persistent Threat с конференции Teched Russia. Он поможет вам научиться защищаться от наиболее часто применяемых атак актуальных для Windows инфраструктуры.
Решили с Алексеем Голдбергсом поэкспериментировать с новым форматом общения с вами, дорогие читатели. Cтали записывать подкаст о том, что происходит в мире ИБ. В нем мы делимся своим взглядом на происходящее сфере ИБ и стараемся давать некоторую долю аналитики. Называется сие начинание Russian Security Audioblog. Предполагается, что будут как новостные подкасты, так и целиком посвященные обсуждению одной темы из сферы ИБ. В общем, должно получаться интересно и разнообразно.
На данный момент готово два пилотных выпуска. Планируем записывать новые выпуски каждые две недели. Впрочем, если вы захотите слушать нас чаще, можем перейти и на еженедельный график.
Надеюсь, вы послушаете, о чем мы рассказываем. А в ответ хотелось бы получить ваши мысли и предложения о том, что стоит добавить, изменить или улучшить. Так же любопытно будет узнать, о каких темах вам интересно слушать и кого из экспертов вы хотели бы видеть у нас в гостях.
Пожелания и комментарии можно оставлять тут, писать в твиттер или в группу RSA Blog на Facebook.
Вот RSS лента подкаста для желающих подписаться и QR код для мобильных устройств.
Сегодня провел вебинар “За кулисами Windows Update. От уязвимости к обновлению.” Рассказал о близких каждому ИТ специалисту и разработчику вещах, о том, как Microsoft ищет уязвимости в своих и чужих продуктах. Как организовано взаимодействие Microsoft с исследователями безопасности и брокерами уязвимостей? Как классифицируются и обрабатываются уязвимости, выявленные сотрудниками Microsoft и партнерами?
Насколько сильно влияют 0-day уязвимости на общий ландшафт безопасности продуктов Microsoft?
Поговорили, как организован SSIRP — процесс реагирования на инциденты ИБ в сфере разработки программного обеспечения. Каким образом тестируются и выпускаются обновления. Обсудили почему они выпускаются ежемесячно, а не еженедельно или ежедневно.
Затем я рассказал о тех уроках, которые Microsoft извлек в процессе построения и поддержки сервиса Windows Update обслуживающего 1 миллиард клиентов.
Мы посмотрели на типичные пути появления эксплоитов, атакующих уязвимости в первые 30 дней после выхода обновлений. Затем узнали как Microsoft обменивается данными об уязвимостях и зловредном коде с крупнейшими производителями систем безопасности. Это позволяет им с помощью обновлений к IDS/IPS и антивирусов защищать тех клиентов, кто не успевает обновиться за первый месяц.
Получилась увлекательная экскурсия на внутреннюю кухню Microsoft.
Так же для всех желающих доступна презентация для просмотра и скачивания.
Для резервирования я выложил презентацию на Slideshare.
Если вам захочется обсудить то что вы увидели в вебинаре, задавайте вопросы здесь.
Пока у нас с вами были новогодние каникулы 10 января 2012 у заслуженного ветерана и одного из самых безопасных продуктов Microsoft ISA Server 2006 закончился срок основной поддержки. Он перешел в разряд расширенной поддержки. Прочитайте пожалуйста подробности о сроках поддержки ISA Server. Это означает что организации не имеющие контракта на расширенную поддержку ISA Server не смогут получить поддержку в Microsoft.
Предполагаю что таким организациям пора начать планировать миграцию с ISA Server на новые продукт, например такой как Forefront TMG. Следующие документы объясняют почему именно Forefront TMG и как выполнять миграцию на него.
Не мешкайте, подумайте о миграции уже сегодня.
У нас очередное радостное событие все желающие могут скачать Windows 8 Developer Preview , начиная с 7:00 по Московскому времени 14 сентября 2011 . Раздавать будут 32-битные (x86) и 64-битные (x64) версии Windows 8. Так же будет доступна версия со встроенным Visual Studio и набором приложений примеров.
Я надеюсь, вы понимаете, что это очень ранняя версия ОС и ее не стоит использовать в рабочей инфраструктуре. Она предназначена для ознакомления и первичного тестирования. Поэтому никакой поддержки для нее оказываться не будет.
Система не требует активации, вы сможете ставить ее столько раз сколько вам необходимо, на то оборудование, которое вы желаете проверить.
С течением времени мы будем выпускать обновления для самой ОС и драйверов. Так мы протестируем телеметрию и раздачу обновлений.
Завтра я напишу подробный пост о новинках Windows 8. Так что следите за анонсами.
Наступил радостный момент. Мы можем показать два нововведения из сотен ожидающих Вас в финальной версии Windows Server 8. Они помогут строить более надежные виртуальные ЦОД и частные облака.
Посмотрите демо Windows Server 8 начиная с 36 минуты. Более подробные про новинки Windows Server 8 можно будет узнать 13-16 сентября этого года на конференции Microsoft BUILD.
Сегодня у нас радостная новость обновился антивирусный движок в самом популярном на планете, бесплатном антивирусе Microsoft Security Essential. Обновленный движок так же появится в Forefront Client Security, Forefront Endpoint Protection и Windows Intune Endpoint Protection. Это обновление поможет точнее распознавать зловредный код.
Популярность MSE не удивительна, он прост в установке и управлении, а с недавних пор может использоваться для защиты малого бизнеса имеющего не более 10 ПК.
Скачивайте новый Microsoft Security Essential. Теперь единый установочный пакет подходит для Windows 7, Windows Vista и Windows XP. Обратите внимание что вирусные базы рекомендуется обновить сразу же после установки нового антивируса. Сделать это можно из консоли управления антивирусом. Если же у вас слабый канал в Интернет или вам нужно обновить ПК без подключения к Интернету можно скачать базы MSE отдельно.
Я неоднократно писал о том, как работать с Linux под управлением системы виртуализации Hyper-V. Тема виртуализации Linux/Unix всегда вызывает горячие дебаты. Судя по откликам читателей занятие это довольно популярное.
Не смотря на то, что под Hyper-V стабильно работают практически все популярные Linux дистрибутивы, официально поддерживались только SuSE Linux Enterprise Server и Red Hat Enterprise Linux.
Отныне в список поддерживаемых гостевых систем добавляется CentOS. Таким образом, многие предприятия смогут консолидировать и унифицировать свои смешанные Windows + Linux инфраструктуры и снизить стоимость владения. Мы предполагаем, что особенно актуально это будет для телеком провайдеров и хостеров.
Для того чтобы прояснить тонкости оказания поддержки CentOS написал этот краткий FAQ:
В: Какие версии CentOS поддерживаются для запуска под Hyper-V? О: 32-x и 64-х битные CentOS с версии 5.2 по версию 5.6. Получить поддержку можно по проблемам установки, конфигурирования и функционирования CentOS под Hyper-V.
О: Какие версии сервисов интеграции с Hyper-V будут поддерживаться в CentOS? В: На данный момент поддерживается Hyper-V Linux Integration Services for Linux версии 2.1. Он дает следующие возможности:
o Symmetric Multi-Processing (SMP) Support: Гостевая машина CentOS может работать с 4-мя виртуальными процессорами.
o Driver support for synthetic devices: Сервисы интеграции добавляют в гостевую ОС поддержку высокоскоростных синтетических устройств сети, жестких дисков Hyper-V.
o Fastpath Boot Support for Hyper-V: Загрузочные диски CentOS смогут пользоваться Virtualization Service Client (VSC) для повышения скорости дисковых операций.
o Timesync: Синхронизация времени между родительским разделом Hyper-V и гостевой CentOS.
o Integrated Shutdown: Корректное завершение работы гостевой системы CentOS из Hyper-V Manager, System Center Virtual Machine Manager или скриптов Powershell и WMI.
o Heartbeat: Отслеживание статуса гостевой ОС из родительского раздела Hyper-V.
В: Будет ли Hyper-V официально поддерживать другие Linux дистрибутивы? О: Мы работаем на этим. В связи с включением модулей Hyper-V в новые ядра Linux ожидаем упрощения процесса поддержки и расширения списка дистрибутивов Linux работающих под Hyper-V.
С приходом SP1 у Windows Server 2008 R2 появилось множество интересных возможностей. Самыми известными из них являются Dynamic Memory и RemoteFX. Так же произошли изменения во многих других компонентах ОС. Для того чтобы вы могли комфортно удаленно управлять функциями Windows Server 2008 R2 SP1, сегодня мы выпустили новую версию Remote Server Administration Tools. В пакет включено управление следующими ролями и компонентами:
Role Administration Tools:
Feature Administration Tools:
Скачать новый RSAT можно тут http://www.microsoft.com/downloads/en/details.aspx?FamilyID=7d2f6ad7-656b-4313-a005-4e344e43997d
Давайте продолжим наши упражнения в виртуализации Linux систем под Hyper-V. Сегодня мы займемся установкой и настройкой Debian 6 под Hyper-V. Все что я буду писать ниже можно применять не только к Debian 6, но и к Debian 5 и к остальным дистрибутивам основанным на Debian таким как Ubuntu, Kubuntu, Xubuntu, Ebuntu.
Debian не входит в список официально поддерживаемых Microsoft систем Linux для запуска под Hyper-V. Не смотря на это он работает в виртуальном окружении очень даже хорошо. В связи с тем, что официального пакета компонентов интеграции Hyper-V для Debian нет, мы воспользуемся драйверами Hyper-V встроенными в новейшие ядра Linux.
Установка Debian 6 под Hyper-V довольно банальна. Единственное что нужно сделать на этапе создания виртуальной машины это добавить в систему эмулируемый сетевой интерфейс Legacy. Он нам понадобится для первоначального обновления системы и установки новейшего ядра Linux.
После завершения установки Debian 6 у нас будет ядро 2.6.32 конечно оно не блещет новизной, но в тоже время вполне нормально с многопроцессорными виртуальными машинами.
Для того чтобы виртуальная машина смогла работать быстрее и воспользоваться всеми преимуществами Hyper-V нужно обновить ядро как минимум до 2.6.36. Перед сборкой нового ядра обновляем систему, устанавливаем исходные тексты текущего ядра и все необходимые инструменты для компиляции нового.
# apt-get update
# aptitude update
# apt-get install build-essential ncurses-dev kernel-package fakeroot install linux-headers-2.6 linux-source-2.6.32
Теперь приступим к сборке нового ядра 2.6.36 взятого с kernel.org
# cd /usr/src
# wget -c http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.36.tar.bz2
# bzip2 -d linux-2.6.36.tar.bz2
# tar xf linux-2.6.36.tar
# cd linux-2.6.36
# cp /boot/config* ./.config
# make menuconfig
В меню выбираем Device Drivers -> Stagging Drivers –> Microsoft Hyper-V Client Drivers
На этом этапе так же можно удалить лишние драйвера для устройств, которых никогда не будет в виртуальной машине, таких как wi-fi, звуковые карты, USB, PCI. Впрочем, это не обязательно, если не желаете, можете не делать.
После этого можем начать сборку deb пакетов ядра. Для того чтобы лучше отличать ядра добавляем в название символы hyper-v.
# make-kpkg clean # fakeroot make-kpkg --initrd --append-to-version=-hyper-v kernel_image kernel_headers
Компиляция ядра занимает довольно продолжительное время. После этого в /usr/src появятся два deb пакета которые можно установить в систему командой dpkg –i.
Так же эти пакеты можно будет перенести и установить в другие виртуальные машины с Debian дабы не повторять процесс компиляции.
Редактируем /etc/initramfs-tools/modules и добавляем следующие строки указывающие загружать нужные модули при старте системы:
hv_vmbus
hv_storvsc
hv_blkvsc
hv_netvsc
Обновляем initramfs:
# update-initramfs –u –k 2.6.36-hyper-v
Выключаем виртуальную машину, удаляем сетевой адаптер Legacy, добавляем синтетический сетевой адаптер и загружаем машину с новым ядром.
После этого проверяем с помощью lsmod | grep hv что все нужные для работы Hyper-V модули загрузились.
Обратите внимание, в новых версиях ядер Linux сетевой синтетический интерфейс Hyper-V переименован из seth в eth. Это может вводить в заблуждение.
Как обычно я протестировал устойчивость виртуальной машины прокачав через нее в течении нескольких дней с помощью scp почти сотню гигабайт трафика. Виртуальные жесткие диски работают также достаточно быстро.
Виртуальная машина работает стабильно в 4-х процессорной конфигурации с 44 гигабайтами ОЗУ. В общем можно сделать вывод, что Debian и основанные на нем дистрибутивы способны отлично работать под Hyper-V и применяться для реализации инфраструктурных элементов работающих с большой нагрузкой.
Windows Server 2008 R2 и Windows 7 SP1 теперь доступны всем. В ближайшее время вы можете обновиться с помощью Windows Update. Если же вам не терпится скачивайте SP1.
Если вам нужна версия ОС со встроенным SP1 вы можете взять ее тут
Если вы еще не читали какие новые возможности принес SP1 рекомендую обратить внимание на следующие документы:
Так же рекомендую прочитать вот эту заметку.
Давайте продолжим серию статей о запуске Unix и Linux систем под Hyper-V R2. Сегодня посмотрим, как устанавливать и настраивать CentOS 5.5 под управлением нашей системы виртуализации. Почему именно CentOS? Все очень просто он является самым популярным среди любителей RedHat подобных дистрибутивов.
Для тех, кому лень читать могу сказать что CentOS работает под Hyper-V очень хорошо и готов к применению в производственной среде. Кстати, все, что я напишу ниже можно с таким же успехом применять и для RHEL.
Ну что приступим?
Создаем виртуальную машину. И добавляем в нее сетевой адаптер Legacy. Он пригодится нам для обновления CentOS и для установки компонентов интеграции Hyper-V.
Запускаем установку ОС. Для того чтобы сценарий тестирования был наиболее реалистичным будем использовать динамические жесткие диски VHD. Обратите внимание, что гостевая система вполне нормально работает с дисками размера до 2 ТБ. Использование динамических дисков автоматически расширяющихся при необходимости поможет нам реалистичнее посчитать среднюю производительность дисковых операции.
Так же в процессе установки можно настроить сетевой интерфейс Legacy.
После этого установка ОС выполняется, так же как и на обычном физическом оборудовании. После завершения установки и первой перезагрузки, входим в гостевую систему и проверяем работу сети.
Сейчас нам доступен сетевой адаптер со скоростью 100 МБит/c. Для многих задач этого достаточно, но ведь хочется более высоких скоростей? Скоро мы и до этого дойдем.
Обратите внимание, что даже без сервисов интеграции с Hyper-V система способна работать с несколькими виртуальными процессорами. Максимальное количество виртуальных процессоров 4.
Как видите базовый функционал работает вполне нормально. Теперь давайте приступим к установке сервисов интеграции Hyper-V. Что это даст нам?
Перед установкой сервисов интеграции Hyper-V обновляем гостевую ОС через графический интерфейс или с помощью команд:
# yum update
# reboot
После перезагрузки неплохо было бы сделать мгновенный снимок (snapshot) средствами Hyper-V, если что-то пойдет не так, всегда сможем откатиться назад.
После перезагрузки неплохо было бы сделать мгновенный снимок (
snapshot
) средствами
Hyper
-
V
, если что-то пойдет не так, всегда сможем откатиться назад.
Теперь устанавливаем заголовки ядра и инструменты разработчика
# yum install kernel-devel
# yum
install
kernel-devel
# yum groupinstall "development tools"
# yum groupinstall
"development tools"
Скачиваем интеграционные сервисы для Hyper-V распаковываем их и подключаем ISO к гостевой CentOS.
Собираем и устанавливаем модули ядра для синтетических устройств
# mkdir /opt/linux_is
# cp -R /media/CDROM/* /opt/linux_is
# cd /opt/linux_is
# make
# make install
Проверяем что модули загрузились с помощью команды
# lsmod | grep vsc
Выключаем гостевую ОС с помощью poweroff. Удаляем из нее сетевой адаптер Legacy и добавляем синтетический адаптер. Запускаем ОС и настраиваем новый сетевой адаптер seth0.
Теперь можно провести тестирование скорости работы синтетического сетевого адаптера с помощью iperf.
Как видите скорость на сетевом интерфейсе seth0 в среднем составляет 492,5 Мбит/c. Довольно неплохой результат для виртуальной машины.
К сожалению, выполнять загрузку гостевой ОС Hyper-V умеет только с IDE дисков поэтому рекомендуется на них располагать только раздел /boot. Для всех остальных разделов рекомендуется в качестве жестких дисков использовать SCSI диски. В этом случае мы сможем добиться гораздо более высокого быстродействия.
Если вам нужно сделать так чтобы, подключаясь через RDP к консоли Hyper-V вы могли управлять CentOS с помощью мыши в графическом режиме ставим драйвера синтетического устройства мыши.
Скачиваем их со страницы проекта Citrix Satori, присоединяем ISO файл к виртуальной машине, копируем исходники и устанавливаем скомпилированный драйвер.
# mkdir /opt/mouse_is
# cp -R /media/CDROM/* /opt/mouse_is
# cd /opt/mouse_is
# ./setup.pl inputdriver
На этом установку всех компонентов интеграции можно считать законченной.
Давайте посмотрим, как CentOS чувствует себя в настоящих больших производственных средах. Для этого я дал ему те ресурсы, что были в наличии на тестовом сервере - 44 Гб ОЗУ и 4 процессора. К сожалению больше ресурсов у меня не было. Интересно было бы глянуть, как CentOS чувствует себя, если дать ему 2ТБ ОЗУ.
Затем в течении нескольких дней с помощью скриптов запущенных в несколько потоков создавал командой dd файлы размером до 2ТБ и перекачивал их по ftp и scp на другой сервер. Каких либо проблем и сбоев не обнаружилось.
Поэтому я делаю вывод, что CentOS может использоваться как виртуальная система под Hyper-V для проектов с довольно большой нагрузкой.
Пару лет назад я писал про запуск FreeBSD 6.3 и 7.0 под Hyper-V версии 1. FreeBSD развивается, да и Hyper-V не стоит на месте. Проблемы, которые я описывал ранее, исчезли и теперь FreeBSD гораздо лучше работает в нашей системе виртуализации.
Сегодня мы будем устанавливать FreeBSD 8.1 и 7.3, потому что именно они являются официально рекомендуемыми на данный момент. Так же проверим, как система работает в многопроцессорной конфигурации, и какие скорости устройства показывают во время тестов.
В связи с тем, что компонентов интеграции для FreeBSD не существует, нам будут доступны только эмулируемые устройства. Поэтому перед установкой ОС удаляем из виртуальной машины синтетический сетевой адаптер и добавляем сетевой адаптер Legacy.
После этого можно запускать установку. Здесь все банально и происходит, так же как и на реальном оборудовании. После окончания установки видим, что ОС загрузилась нормально и проблем с управлением питанием, которые были 2 года назад нет. Поэтому накладывать патчи на ядро нет необходимости.
После перезагрузки добавляем в /etc/rc.conf описание сетевого интерфейса de0 чтобы он мог работать с DHCP:
ifconfig_de0=”DHCP media 100baseTX mediaopt full-duplex”
Выполняем команды:
# ifconfig de0 down
# ifconfig de0 up
# dhclient de0
И наслаждаемся работающей сетью.
Скорость работы сети в среднем 95.57 Мбит/с хотя иногда получаются пики до 103 Мбит/c. Результат десяти тестов можно видеть на снимке экрана.
Если скорость в 100 Мбит/c недостаточна для ваших задач, то можно дать виртуальной машине 4 сетевых адаптера по 100 Мбит/c и связать их в один скоростной интерфейс с помощью механизма агрегации соединений.
Скорость работы жестких дисков можно увидеть на следующем экране.
Hyper-V позволяет дать каждой гостевой машине до 4-х виртуальных процессоров. FreeBSD отлично работает в такой конфигурации.
С работой видеоадаптера тоже нет проблем. Xorg запустился с первой попытки, распознал все нужные устройства и работал без каких либо проблем.
Вопреки распространенному мему патчить KDE под FreeBSD не пришлось. KDE заработала так же с первой попытки.
Как видите FreeBSD запущенная под Hyper-V работает стабильно и может использоваться для реализации инфраструктурных сервисов, обучения, разработки или тестирования.
Выдалось немного свободного времени, поэтому сегодня я решил написать, как обстоят дела с работой Ubuntu 10.04 под Hyper-V.
Не смотря на то, что Ubuntu не входит в список официально поддерживаемых Linux дистрибутивов работает он под Hyper-V отлично. Более того никаких дополнительных компонентов интеграции ставить не пришлось. Все что нужно для работы с Hyper-V давно находится в свежих ядрах Linux.
Итак, приступим. Берем Linux Ubuntu 10.04 LTS, подойдет как 64-х битная, так и 32-x битная версия. Создаем стандартную виртуальную машину, подключаем DVD с ОС и начинаем установку. Обратите внимание, что мы оставляем синтетический сетевой интерфейс, созданный по умолчанию внутри виртуальной машины. Больше нет необходимости использовать устаревший и более медленный сетевой интерфейс Legacy. Рекомендуется использовать статический Mac адрес сетевого интерфейса, если эта виртуальная машина будет мигрировать между физическими узлами кластера с помощью механизма Live migration.
Выполнять установку можно в текстовом или в графическом режиме. Я рекомендую делать это с помощью графики т.к в текстовом режиме перерисовка каждого меню занимает секунд 20-30. Это довольно сильно раздражает, хотя и не мешает завершить установку удачно.
Сразу же после старта установки в течение минуты, другой можно наблюдать ворох предупредительны сообщений о нестандартном BIOS. Смело игнорируем их и продолжаем установку до тех пор пока не увидим следующее лаконичное сообщение.
После первой перезагрузки смотрим с помощью lsmod список загруженных модулей. Обнаруживаем, что загружен лишь модуль шины Hyper-V под названием hv_vmbus.
Этого недостаточно, поэтому редактируем файл /etc/initramfs-tools/modules и добавляем в него строки разрешающие загрузку остальных необходимых нам модулей.
hv_vmbus hv_storvsc hv_blkvsc hv_netvsc hv_utils
Сохраняем файл и выполняем команду:
$ sudo update-initramfs -u
Прописываем в /etc/network/interfaces ваш новый синтетический сетевой интерфейс seth0. Если бы у вас использовался устаревший сетевой интерфейс Legacy, то он назывался бы eth0.
Для статической адресации:
Auto seth0 iface seth0 inet static address x.x.x.x netmask x.x.x.x Gateway x.x.x.x
Для получения адреса по DHCP:
Auto seth0 iface seth0 inet dhcp
Я проверял оба способа сетевой адресации, они работают.
Перезагружаемся и в процессе видим вот такие сообщения о том что устройства связанные с vmbus найдены.
После загрузки с помощью lsmod проверяем загруженные модули и смотрим, какие сетевые интерфейсы у нас есть в системе.
Как видите, сетевой интерфейс seth0 работает вполне нормально.
Так же стоит отметить, что Ubuntu нормально работает как в однопроцессорной, так и в многопроцессорной конфигурации. Система без проблем масштабируется до 4-х процессоров.
К сожалению, ресурсы ОЗУ моего тестового сервера ограниченны, поэтому дать более 14 ГБ ОЗУ виртуальным машинам с Ubuntu я не смог. Впрочем, для большинства задач такого объема вполне достаточно.
Стоит отметить, что поддержки синтетической мыши в Ubuntu нет, а проект Satori пока что не портирован под этот дистрибутив, поэтому для удаленного управления в графическом режиме я использовал VNC.
На всякий случай внутри виртуальных машин с Ubuntu я настроил веб сервер и FTP сервер. В течение недели с помощью скриптов периодически скачивал с них довольно большие объемы данных. Деградации быстродействия, каких либо проблем и сбоев замечено не было.
Вывод – несмотря на то, что официально о поддержке Ubuntu не заявлено этот дистрибутив работает под Hyper-V весьма надежно и, по моему мнению, может использоваться в производственной среде.
2-3 декабря в Киеве прошла конференция MS SWIT 2010. Выступал на ней с докладами и ваш покорный слуга. Рассказывал слушателям о виртуализации Linux и Unix, новых возможностях Windows Server 2008 R2, обеспечении безопасности инфраструктуры с помощью Forefront Endpoint Protection и System Center. Впечатления осталась самые теплые несмотря на холодную погоду. Было очень приятно приятно со всеми с вами общаться. Надеюсь в следующем году сможем повторить.
А у меня тем временем наконец-то дошли руки опубликовать презентации. Думаю они будут полезны тем кто хотел бы освежить увиденное или не смог присутствовать на конференции. Благо запросов на раздачу презентации было много.
Скачать pptx файлы всех моих презентаций можно тут http://cid-d489fb91b2112580.office.live.com/browse.aspx/MS%20SWIT%202010
Надеюсь что в ближайшее время организаторы опубликуют видеозаписи выступлений. А пока можно следить за анонсами и обсуждением конференции в twitter.
Некоторое время назад пришла в голову идея проверить как будет чувствовать себя Solaris под Hyper-V после того как он перешел в руки Oracle. Проще всего сделать это было скачав Solaris Express 11. Результат оказался вполне хорошим, ОС работает стабильно и с приемлимой производительностью даже несмотря на отсутствие компонентов интеграции для Hyper-V
Итак приступим к установке. Скачиваем дистрибутив Solaris Express 11, создаем новую виртуальную машину, подключаем дистрибутив в качестве загрузочного DVD, удаляем синтетический сетевой адаптер и добавляем Legacy Network адаптер.
Запускаем виртуальную машину и даем ответы на все стандартные вопросы вроде разбиения жесткого диска, настройки имени хоста, назначения пароля root. Для получения IP адреса был выбран DHCP. Статическое присвоение IP адресов сетевомму интерфейсу так же нормально работает. Оно было протестировано после установки ОС.
После этого начнется установка которая займет минут 15-20. Затем ОС перезагрузится и вы увидите приглашение grub. Здесь ничего настраивать не нужно, поэтому жмем “Enter” и смело продолжаем наблюдать загрузку ОС.
После загрузки входим и видим что сетевой интерфейс dnet0 отлично работает в режиме эмуляции и позволяет работать с сетью со скоростью не более 100 мбит. В режиме простоя нагрузка на ЦПУ менее 1%.
Так же я протестировал переключение между статической IP адресацией и DHCP. Потом провел нагрузочное тестирование сети передав через FTP примерно десяток гигабайт данных. В режиме передачи данных через сеть нагрузка на процессор гостевой поднимается до 3%.
С момента запуска ОС проработала в таком режиме четыре дня. Каких либо ошибок и отклонений в поведении ОС не замечено. В журналах записей об ошибках тоже нет. Думаю, можно предположить что она и дальше будет работать стабильно.
Как видите работать с Unix под Hyper-V совсем не сложно даже если у вас нет компонентов интеграции Hyper-V.
Обновление
После публикации заметки решил попробовать, что будет, если гостевой ОС дать не один процессор, а два или четыре. В результате перехода к двухпроцессорной конфигураци система начинает замедляться. Не сильно, но все же на глаз заметно. Добавление четырех процессоров приводит к торможению гостевой ОС настолько сильному, что пользоваться ею становится некомфортно.
Это позволяет нам сделать вывод, что на данный момент используя Solaris Express 11 под Hyper-V создать высокопроизводительные многопроцессорные системы не удастся. Получается что систему можно применять для обучения, тестирования и консолидации унаследованнх инфраструктурных сервисов.
12-го октября мы вместе с коллегами из HP будем проводить довольно интересную конференцию в Санкт-Петербурге. Называется она “Практика построения ЦОД нового поколения”. Расказывать будут много нового. Регистрироваться можно здесь.
Если будет свободный день то, постараюсь поехать на эту конференцию, чтобы пообщаться с коллегами и посмотреть на новые чудеса ИТ технологий.
Виртуализация становится все более распространенной технологией консолидации серверного парка. Многие организации к ее широкому применению подтолкнул кризис. По данным IDC в последнем квартале 2009 года было выпущено 350000 серверов, из которых было виртуализировано 18,2%.
На первый взгляд виртуализация замечательна со всех сторон т.к. позволяет оптимизировать утилизацию оборудования и повышает гибкость инфраструктуры. Но если присмотреться внимательно, то выясняется, что у нее есть и неочевидные отрицательные эффекты.
Давайте посмотрим на один из них. Как только технологии виртуализации становятся доступны достаточно большому количеству людей в организации, возникает эйфория. Теперь развернуть набор виртуальных машин с нужными сервисами на порядок легче, чем физический сервер. Ресурсы кажутся практически неограниченными, поэтому каждый отдел начинает разворачивать свои виртуальные машины. В этот момент начинается бесконтрольное размножение виртуальных машин. Через какое то время все запутываются в том кому, что теперь принадлежит, кто отвечает за конкретную виртуальную машину и где она находится. В результате с течением времени внутри вашей инфраструктуры появляется очень много бесхозных виртуальных машин. Часть из них продолжает работать бесконтрольно, какие то из них выключены, а некоторые месяцами находятся в спящем состоянии. В связи с тем, что обновление этих тестовых виртуальных машин не настроено, получается, что внутри инфраструктуры появляются точки не подверженные действию корпоративной политики безопасности. Если в организации не налажен процесс управления конфигурациями и изменениями довольно скоро в ней начнутся инциденты с безопасностью.
Все методы, о которых я буду писать ниже, в основном относится к Windows виртуальным машинам, но частично применимы и для Linux/Unix.
Бороться с проблемой отсутствия обновлений внутри виртуальных машин можно комбинацией нескольких способов. Внедрением единой системы хранения образов развертывания виртуальных машин, например библиотеки SCVMM. В шаблонах виртуальных машин уже заранее должны быть прописаны способы автоматического обновления. Для того чтобы владелец виртуальной машины не мог отключить в ней агент обновления можно применять технологию Network Access Protection которая позволяет помешать физические и виртуальные машины в карантин если они не соответствуют политикам нашей сети. Одной из политик может быть работа в системе агента обновлений и срок последнего обновления не старше чем X дней или часов. Таким же образом можно контролировать наличие в системе антивируса, его обновления и статус и прочих необходимых нам системных процессов.
Проблему поддержания включенных виртуальных машин в обновленном состоянии эти меры решают. К сожалению, на данный момент ни WSUS, ни SCCM умеют обновлять лишь системы находящиеся во включенном состоянии. А как быть с эталонными виртуальными машинами, хранящимися в библиотеке SCVMM или машинами, находящимися на хостах Hyper-V в состоянии паузы? Обычно на сленге такие машины называются “спящими”. Они могут пребывать в таком состоянии месяцами. Все это время обновления на них не устанавливаются. В момент включения такие машины потенциально могут послужить плацдармом для атаки или распространителями эпидемии.
Для поддержания этих систем в актуальном состоянии нам как раз пригодится Microsoft Offline Virtual Machine Servicing Tool он же OVMST. Этот инструмент позволяет выполнять следующие задачи:
Чтобы понять, как работает OVSMT, давайте посмотрим на типовую архитектуру инфраструктуры необходимой для обслуживания “спящих” виртуальных машин.
Как видите в нашей инфраструктуре присутствуют библиотека и сервер SCVMM, сервер для обслуживания виртуальных машин, сервер обновлений WSUS или SССM. Стоит отметить, что все эти хосты обычно изолированы от основной сети с помощью VLAN. Доступ в основную сеть имеет только хост с SCVMM. В этом случае он является шлюзом между VLAN.
Сделано это для того чтобы виртуальные машины которые мы будем обновлять не смогли подвергнуть риску основную сеть обмениваясь в ней данными в процессе установки обновлений.
Давайте пошагово посмотрим как происходит обновление виртуальных машин?
1. Чтение данных из библиотеки SCVMM и выбор виртуальных машин, шаблонов, дисков
2. Поиск «спящих» виртуальных машин на хостах Hyper-V подключенных к SCVMM
3. Создание групп обслуживания и помещение в них виртуалных машин, шаблонов дисков собраных на первом и втором шагах
4. Перенос «спящих» виртуальных машин с хостов Hyper-V или развертывание их из шаблонов хранящихся в библиотеке SCVMM на хостах Hyper-V предназначенных для обновления гостевых ОС.
5. Пробуждение или включение обновляемых машин на обслуживающем хосте Hyper-V
6. Принудительная проверка обновлений необходимых виртуальной машине
7. Применение обновлений к виртуальной машине
8. Проверка статуса обновлений
9. Выключение виртуальной машины, при необходимости подготовка к помещению ее обратно в библиотеку SCVMM с помощь sysprep
10. Возвращение вирт. машины на хост где она первоначально находилась или помещение ее в библиотеку откуда мы ее взяли
Итак мы разбрались в механизмах работы OVMST пошаговый алгоритм настройки этого коплекса я опишу в следующей части статьи, а пока вы можете ознакомиться с вебкастом об OVMST.
У меня наконец-то дошли руки написать о том, как виртуализировать SCO OpenServer. Все что я буду писать ниже актуально и для SCO UnixWare.
Когда я решил заняться виртуализацией этой ОС многие коллеги недоумевали над тем какая муха меня укусила. Понятно, что ты периодически рассказываешь о жизни Linux под Hyper-V, но зачем берешься за такую древность как системы от SCO? Некоторые ИТ специалисты даже удивлялись, что компания SCO до сих пор жива и чувствует себя вполне нормально. Они думали, что после банкротства в 2007 году компания перестала существовать.
Ответ на эти вопросы очень прост. История компании SCO насчитывает не один десяток лет и хранит в себе следы взлетов и головокружительных падений. Долгое время SCO была одним из главных поставщиков Unix ОС для крупнейших компаний этой планеты. В результате деятельности SCO ее ОС внедрены и работают по сей день в 87 странах. Общее количество ныне работающих серверов OpenServer приблизительно 2 миллиона. Традиционно потребителями продукции этой компании являются финансовые учреждения, силовые структуры, государственные организации и телеком компании.
Думаю вы согласитесь что перечисленные выше организации весьма консервативны и зачастую не склонны тратить деньги в погоне за новыми веяниями в ИТ индустрии. Поэтому у многих из них до сих пор функционирует SCO OpenServer или SCO UnixWare. Под эти ОС написано множество ПО, которое успешно работает. Переписывать его никто не собирается. Более того часто складывается ситуация что миграция на более современные ОС и портирование ПО потребует таких затрат что затея становится экономически невыгодной.
Но есть одна проблема аппаратное обеспечение серверов на которых установлена ОС OpenServer постепенно изнашивается и приходит в негодность. Находить сменные комплектующие не так уж и просто, да и цены на сертифицированное SCO оборудование не выглядят дешевыми. А тем временем производители аппаратного обеспечения на основе серверов с процессорной архитектурой x86 не зря едят свой хлеб и выпускают все более мощные конфигурации серверов, постоянно снижая цены. Получается, что удобнее консолидировать экземпляры работающих ОС от SCO на более мощном оборудовании с помощью виртуализации. Вдобавок к выгодам от оборудования мы получаем резервное копирование с помощью SC DPM, отказоустойчивую кластеризацию с Live migration и централизованное управление с помощью SC VMM.
Делается это довольно легко. Читаем документ вот тут http://www.sco.com/products/openserver507v/hyperv/
Скачиваем эталонный образ виртуальной машины SCO OpenServer 5.0.7V для Hyper-V
Обратите внимание на букву V в названии версии она означает что данная версия ОС содержит драйвера необходимые для работы под управлением системы виртуализации.
После скачивания распаковываем виртуальную машину и импортируем ее в Hyper-V
Как видите по умолчанию ресурсов ей выдано довольно мало. Версия 5.0.7V поддерживает до 4ГБ ОЗУ так что если для выполнения ваших задач необходимо больше памяти дайте ее виртуальной машине..
После запуска система начинает автоконфигурирование
Сетевые настройки можно задавать статически или с помощью DHCP. Оба способа работают одинаково хорошо.
Затем нужно настроить систему безопасности, создать пароли и при желании установить дополнительные языки. Делается это очень просто поэтому останавливаться на этом не буду.
После окончания установки и перезагрузки на экране увидим следующее.
Сеть, видео и прочие устройства работают вполне надежно и отлично справляются со своими функциями.
Сеть я тестировал побродив по сайту Microsoft. Затем установил пакет Samba и с помощью него передал между SCO OpenServer и Windows несколько десятков гигабайт разных файлов. На это пришлось потратить довольно внушительное время т.к внутри виртуальной машины доступен сетевой адаптер с пропускной способностью 100 мбит которого вполне хватает для выполнения большинства задач. Зато теперь могу сказать что сетевая подсистема работает как часы.
Обратите внимание что потребление ресурсов процессора при этом минимально.
Как мигрировать приложение из существующих в вашей инфраструктуре серверов в виртуальные описано тут http://ds45.blogspot.com/2009/07/sco-p2v-in-real-life.html
На этом рассказ о виртуализации SCO OpenServer можно заканчивать. Надеюсь он пригодися вам если вы решите сэкономить на поддержке унаследованных Unix систем.
Виртуализация основных бизнес приложений все сильнее и прочнее входит в нашу жизнь, меняя привычные методы управления инфраструктурой. Еще пару лет назад я рекомендовал слушателям на семинарах Techdays виртуализировать SQL Server только в случае крайней необходимости и если нагрузка на SQL не велика. Технологии не стоят на месте, и теперь виртуализация БД становится обыденностью. Более того официальную поддержку получает сценарий переноса SQL Server работающего в виртуальной машине с одного узла кластер на другой без прерывания обслуживания клиентов. Делается это с помощью механизма Live Migration. Таким образом, мы легко повышаем отказоустойчивость SQL Server.
Все это описано в документе "Planning, Implementing and Supporting SQL Server Virtualization with Windows Server 2008 R2 Hyper-V and Live Migration"
Внутри документа вы найдете четыре секции позволяющие легко выполнить планирование, внедрение в виртуальной среде или миграцию существующего SQL Server из физической среды в виртуальную. В заключении вы прочитаете о том как лучше всего управлять виртуальным SQL.
Надеюсь все что я описал, поможет вам легко и беспроблемно виртуализировать SQL
Вышло очередное обновления для Microsoft Forefront Unified Access Gateway (UAG). Установив его можно получить следующую новую функциональность:
Скачать обновление можно тут http://www.microsoft.com/downloads/en/details.aspx?FamilyID=9dcccebc-accb-4229-901a-792cc66791de.
Так же рекомендуется посетить страницу документации UAG.
Хорошо известный набор продуктов Microsoft Office Communications обрел новое имя. Таблица сответствия названия продуктов ниже.
О новых возможностях наиболее полно написано в блогах коллег. Соревноваться с ними смысла нет поэтому просто приведу ссылки.
http://blogs.technet.com/b/ai/archive/2010/09/14/rc-microsoft-lync-server-2010-ocs-vnext.aspx
http://blogs.technet.com/b/uc/archive/2010/09/13/introducing-microsoft-lync-the-next-ocs.aspx
http://blogs.technet.com/b/dodeitte/archive/2010/09/13/microsoft-lync-server-2010-rc-now-available.aspx
http://blogs.technet.com/b/ucedsg/archive/2010/09/13/next-generation-of-office-communications-server-named-microsoft-lync-server-2010-and-release-candidate-now-available-for-download.aspx
Скачать RC-версию Lync можно здесь.
Так же мы можете посмотреть демо продуктов Lync с конференции Voicecon
Рекомендуется посетить следующие сайты
Поддержка данного продукта до момента выхода RTM версии будет осуществляться через форумы:
Для развертывания в Lync в вашей инфраструктуре вам пригодится инструмент Microsoft Lync Server 2010, Planning Tool (RC). Он позволяет:
Так же рекомендую прочитать блог об управлении Lync Server с помощью Powershell.
Партнерам будут интересны следующие ресурсы:
Partner Launch-in-a-Box
MPN Lync Product Page
Надеюсь этот скромный набор ресурсов поможет вам начать работать с Lync более плодотворно.
Если вы отвечаете за компьютеры, установленные в общественные местах, то знаете, что поддерживать их в порядке - довольно трудоемкая задача. Нам нужно сделать так, чтобы пользователи не могли вносить изменения в операционную систему и установленные приложения, не могли запускать принесенные с собой приложения, получали доступ только к набору разрешенных приложений, автоматически завершали сеанс работы с системой в указанное время. А после завершения текущего сеанса или перезагрузки система возвращалась в свое эталонное состояние. Еще одна проблема - своевременное обновление системы, не мешающее работать пользователям.
Для Windows XP и Windows Vista такие функции выполняла программа Windows SteadyState. Время идет, меняются технологии, применяемые для решения насущных задач. Мы видим, что компании, использующие Windows XP и Windows Vista, постепенно мигрируют на Windows 7. Процесс еще не завершен, но идет довольно хорошими темпами. Есть надежда, что завершится он достаточно скоро. В связи с этим приложение Windows SteadyState обновляться больше не будет, в текущем состоянии оно будет доступно для скачивания до 31-го декабря 2010 года. Поддержка данного решения продлится до 30-го июня 2011 года. Так что если вам нужно это приложение, советую скачать его сейчас.
У вас наверно возник вопрос, как проблема защиты и обслуживания общедоступных ПК решается в Windows 7? Довольно просто. Практически весь функционал SteadyState теперь встроен в Windows 7. Чтобы правильно его настроить и эффективно управлять им, в дальнейшем вам пригодятся следующие документы:
Многое из того, что описано в этих документах, может пригодиться не только администраторам общественных компьютеров, но и тем, кто управляет парком ПК на предприятиях. Эти знания также можно применять для домашних компьютеров, которыми могут пользоваться ваши дети.
Надеюсь, это позволит упростить обслуживание ваших систем, сократит количество рутинной работы и даст возможность потратить время на что-то более увлекательное и полезное.
В рамках Московской User Group 13 сентября мы будем поздравлять программистов с профессиональным праздником. В рамках этого собрания выступят легендарные докладчики из команды Microsoft Patterns&Practices. Они очень хотят пообщаться с локальным сообществом и обсудить ключевые вопросы архитектуры приложений.
План встречи:
Докладчики:
Участие бесплатное.
Подробнее узнать о мероприятии и зарегистрироваться можно здесь.
Недавно я писал о выходе версии 2.1 сервисов интеграции Linux для Hyper-V. Изменений и улучшений по сравнению с прошлой версией довольно много. С появлением нового функционала изменилась и процедура установки сервисов интеграции в гостевые машины на основе Linux. Поэтому, сегодня я опишу, как устанавливать их в SLES 11. Все, что вы встретите в этом тексте одинаково актуально как для 32-х битных так и для 64-х битных версий SLES 11.
Начальная установка SLES 11 под Hyper-V довольно тривиальна. Главное не забыть выбрать опцию “Physical machine (Also for Fully Virtualized Guests)” и установить инструменты разработки “C/C++ Compiler and Tools”. Они пригодятся нам в дальнейшем для сборки модулей ядра.
Пока сервисы интеграции не будут установлены синтетический сетевой адаптер будет не доступен. Если вам нужно в этот промежуток времени работать с сетью, добавьте виртуальной машине сетевой адаптер “Legacy Network”.
После этого можно продолжать установку гостевой ОС в обычном режиме. По окончанию установки можно настроить сеть и проверить как работает доступ в Интернет.
Как видите, все отлично работает и нам доступна сеть через Legacy адаптер. На этом можно считать начальную установку гостевой ОС завершенной.
Поэтому переходим к самой сложной части – установке интеграционных сервисов, которые дадут нам возможность использовать быстрые виртуальные HDD и гигабитные синтетические сетевые адаптеры.
Скачиваем пакет Linux Integration Services 2.1. Распаковываем его и внимательно читаем инструкцию. Обратите внимание, что установка интеграционных сервисов для SLES 11 и SLES 10 SP3 довольно сильно отличается. Про установку под SLES 10 SP3 я напишу отдельную заметку позже.
Процедура установки интеграционных сервисов в официальной документации описана, по моему мнению, несколько запутано. Это затрудняет ее понимание и правильное применение. Поэтому рекомендую пользоваться мгновенными снимками Hyper-V, на случай если захочется отменить сделанные по ошибке изменения.
Отредактируйте файл /etc/modprobe.d/unsupported-modules так чтобы в нем была следующая строка:
allow_unsupported_modules 1
Перезагружаем виртуальную машину. Подключаем пакет с сервисами интеграции как DVD в виртуальную машину. В моей системе включено автоматическое монтирование, если в вашей системе не так, то возможно придется воспользоваться командой mount.
Создаем служебную директорию /opt/linux_ic и копируем исходные тексты модулей. Проводим компиляцию, устанавливаем их и перезагружаемся.
# mkdir /opt/linux_ic # cp –R /mnt/cdrom/* /opt/linux_ic # cd /opt/linux_ic # make # make install # reboot
После перезагрузки можно увидеть, что в системе появился новый сетевой адаптер seth0.
Плюс к этому нужно проверить все ли модули загрузились с помощью команд
# modinfo vmbus
· Как видите, в системе появились модули netvsc, storvsc, blkvsc, vmbus.
Затем отредактируйте файл /etc/fstab и замените все секции, начинающиеся с /dev/disk/* на эквиваленты в формате /dev/hd* чтобы содержимое файла выглядело примерно так:
/dev/hda1 swap swap defaults 0 0 /dev/hda2 / ext3 acl,user_xattr 1 1
Отредактируйте файл /boot/grub/menu.lst и измените, опции загружаемого по умолчанию ядра, так чтобы они указывали на дисковые устройства с новым наименованием:
root=/dev/hda2 resume=/dev/hda1
Приведите файл /etc/modprobe.d/unsupported-modules в первоначальное состояние, установив 0 в качестве значения опции allow_unsupported_modules.
Перезагрузите систему и наслаждайтесь выросшим быстродействием.
Для того чтобы у вас не возникло сомнений в том что SLES нормально чувствует себя под Hyper-V не только в лабораторных условиях, и пригоден для серьезных вычислительных задач, я дал виртуальным машинам по 4 процесора и как можно больше оперативной памяти. К сожалению в моем физическом сервере всего 16 гигабайт памяти, поэтому виртуальной машине удалось дать максимум 15. Что из этого получилось вы можете посмотреть ниже.
Как видите процедура установки интеграционных сервисов не так уж и сложна. Чтобы, в дальнейшем избежать ее рекомендуется клонировать виртуальную машину и в дальнейшем использовать ее как шаблон для новых машин.