VMUG #7 Belarus feedback.

7 декабря мы провели седьмую встречу VMUG Belarus.

Мероприятие посетили более 130 технических специалистов. Было подготовлено рекордное количество контента за историю VMUG Belarus: 12 докладчиков из Беларуси, России и Украины выступили с 13 техническими темами. 

Такое количество докладов привело нас к идее разделить мероприятие на два параллельных потока. Участники могли выбрать самое интересное и свободно перемещаться между залами в поисках это интересного. 

Чтобы разбавить такой поток информации, мы ввели тематические квизы. За правильные ответы участники получали ценные, и даже очень ценные призы.

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

Нашу встречу поддержал постоянный партнер Veeam и новый партнер Lenovo, с которыми мы планируем сотрудничать и в дельнейшем. 

Отдельная благодарность и признательность Дмитрию Степанову, Антону Новикову (B.E.E.R), Евгению Зосимову, Александру Купчинецкому и Ане Малаховой за помощь в организации и проведении мероприятия. Юле Дубиной (RRC BY) за организацию "шаверны" по нашей собственной рецептуре. 

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

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

До встречи в первую пятницу 2019. 

ниже фото

VMUG #7 Belarus.

7 декабря VMUG #7 Belarus

Место: #eventspaceby г. Минск, ул. Октябрьская 16/4

Время: начало регистрации 09:40, начало мероприятия 10:15

Что это: неофициальное, некоммерческое мероприятие, посвященное виртуализации и смежным технологиям.

О VMUG #1-6

Fb VMUG Belarus

Регистрация обязательна.

Зал #1

Техническая поддержка Veeam: в поисках ключевой причины.

Всеволод Зубарев. Ведущий инженер по техническому сопровождению ПО, Veeam.

Реальный кейс по внедрению Nutanix.

Александр Иващенко. Технический специалист, Lenovo DCG UAREE.

Кашко Сергей. IT архитектор, СЗАО "Безопасные дороги Беларуси".

Построение SDDC. Теория и практика.

Владислав Кирилин. CloudArchitect.

Путь от SDDCк CAN.

Григорий Прялухин. CloudArchitect.

Резервное копирование вне Veeam: vCenter, vCD, NSX, etc.

Харитонов Дмитрий. VMUG Leader Украина.

Общая теория сайзинга виртуальных датацентров.

Антон Жбанков. vExpert.

Зал #2

Опыт внедрения VMware DaaS Platform у сервис провайдера

Евгений Ясюк. Инженер по виртуализации, РУП "Национальный центр электронных услуг".

Контейнеры в Linux, реализация на нижнем уровне.

Роман Шишнев. Инженер.

Практика микросегментации с NSX. Demo.

Александр Купчинецкий. Senior Systems Engineer, VMware.

Применение рекомендаций и лучших практик Veeam на своем опыте.

Юрий Денисов. Архитектор, Ростелеком-ЦОД.

Евгений Зосимов. Технический консультант. Veeam.

Охота на ведьм или риски несоответствия требованиям. Что в голове у вашего специалиста по ИБ ?

Вячеслав Аксенов. IT Security Architect | Information Security Trainer. ActiveCloud.

v(62)

Горлинский Сергей. VMUG Leader РБ, vExpert.

Также в программе все традиционные ништяки и плюшки ;) 

VMware vCloud Director и сертификат со "звездочкой"

Для обладателей сертификатов со звездочкой *.zone.xxx есть достаточно удобный и быстрый способ подружить vCloud Director c таким сертификатом.

Для приготовления нам понадобятся: сertificate.crt - сам сертификат и кey_certificate.key закрытый ключик.

Используемый vCloud Director-ом JCEKS и keytool не умеют работать напрямую с *.crt и *.key, потому на первом этапе нам придется засунуть Certificate.crt и Key_certificate.key в какое-нибудь достойное хранилище сертификатов и закрытых ключей, например, PKCS#12 используя openssl:

> openssl pkcs12 -export -in Certificate.crt -inkey Key_certificate.key -out cert_http.p12 -passout pass:<PASSWORD> -name http

Обязательным условием является добавление алиаса -name http и consoleproxy, в дальнейшем этот шаг позволит нам экспортировать из PKCS#12 в JCEKS и добавить необходимые VMware vCloud Director alias.

> openssl pkcs12 -export -in Certificate.crt -inkey Key_certificate.key -out cert_consoleproxy.p12 -passout pass:<PASSWORD> -name consoleproxy

После этого подключаемся к VMware vCloud Director и переносим сертификаты из хранилища PKCS#12 в JCEKS

Для alias http:

> keytool -importkeystore -srckeystore cert_http.p12 -srcstoretype PKCS12 -srcstorepass <PASSWORD> -deststorepass <PASSWORD> -destkeypass <PASSWORD> -deststoretype JCEKS -destkeystore certificates.keystore -alias http

Для alias consoleproxy:

> keytool -importkeystore -srckeystore cert_consoleproxy.p12 -srcstoretype PKCS12 -srcstorepass <PASSWORD> -deststorepass <PASSWORD> -destkeypass <PASSWORD> -deststoretype JCEKS -destkeystore certificates.keystore -alias http

Корректность переноса из одного хранилища в другое проверяем

> keytool -keystore certificates.ks -storetype JCEKS -storepass <PASSWORD> - list

VMware vSphere and OpenStack "SelfPortal One for All"

Хорошие ребята из Altoros сделали небольшой Open-sourcing SelfPortal для работы с VMware vSphere и OpenStack.

Если вы предоставляете доступ вашим бизнес-подразделениям возможность деплоить себе машинки из шаблонов, то вполне может сгодиться.

На данный момент поддерживаются следующие штуки:

- An ability to create, modify, and delete VMs
- A web interface with a dashboard, containing a list of users
- Two access roles: a user and an administrator
- HTTP website proxy for external access
- Blacklist for preventing external access to sensitive resources
- Termination of unused VMs or web apps

но ребята обещают продолжить доработку и даже имеют на этот счет roadmap:

- HTTPS website proxy using wildcard certificates
- WebSocket proxy
- VM backups
- Mounting ISO images to vSphere VMs
- Error notifications

Подробнее почитать про SelfPortal можно тут, а скачать в этом месте.

И самое важное: если у вас есть идеи что добавить или что изменить - пишите в комментах или на почту.

Update VMware vCenter 6.0U3b to 6.5U1(c,d,e)

Дождавшись зелененькой галочки на пересечении 6.0U3 и 6.5U1(c,d,e), я решил выполнить обозначенное обновление в полном соответвии с матрицей обновлений от VMware

.... и на выходе получил:

"A problem has occurred. The source vCenter Server might have been Powered of durring this process..."

Огорчился, скачал 6.5U1d, повторил - результат аналогичный
Опять огорчился, скачал 6.5U1с, повторил - результат аналогичный

Решил посмотреть, что на эту тему пишут уважаемые люди. На vcdx133.com нашел "решение" аналогичной проблемы, которое заключается в следующем:

Rollback to vCSA 6.0

1. Verify the upgrade was a failure and you want to rollback to vCSA 6.0.

2. Power-off the vCSA 6.5 instance.

3. Power-on the vCSA 6.0 instance.

4. Verify the rollback was completely successful and all services that rely on vCSA 6.0 are correctly functioning.

5. Delete the vCSA 6.5 instance.

...and repeat

Repeat я уже делал - не помогло, действуем по следующей инструкции:

1. Громко с матами ругаемся на качество кода VMware

2. Игнорируем сообщение об ошибке

3. Перегружаем в ручном режиме "новый vCenter"

4. Получаем обновленный до 6.5U1(c,d,e) и корректно работающий vCenter (с успешно импортированными настройками, с/без статистикой по ивентам, тасками, статистикой производительности)

5. Громко с матами ругаемся на качество кода VMware

VMware vs CVE-2017-5715

09.01.2018 VMware зарелизила обновления на CVE-2017-5715, не смотря на предыдущее заявление о том, что уязвимость закрыта более ранним патчем  ESXi650-20172101-SG от 19.12.2017.

Информация на данный момент не доступна на блоге по безопасности VMware *) 

Выпущены обновления для следующих продуктов: 

- VMware vCenter Server (VC)

- VMware ESXi (ESXi)

- VMware Workstation Pro / Player (Workstation)

- VMware Fusion Pro / Fusion (Fusion)

Необходимо установить следующие обновления:

- VC 6.5 обновление 6.5 U1e

- VC 6.0 обновление 6.0 U3d  

- VC 5.5 обновление 5.5 U3g

- ESXi 6.5 обновления ESXi650-201801401-BG, ESXi650-201801402-BG 

- ESXi 6.0 обновления ESXi600-201801401-BG  ESXi600-201801402-BG

- ESXi 5.5 обновление ESXi550-201801401-BG

Обновления ESXi650-201801402-BG, ESXi600-201801402-BG, ESXi550-201801401-BG выпущены со следующим комментарием "These ESXi patches install the microcodes if present for your CPU,

see VMware Knowledge Base article 52085" 

- Workstation 14.x  обновление 14.1.1              
- Workstation 12.x  выпуск планируется в ближайшее время
- Fusion      10.x    обновление  10.1.1                
- Fusion      8.x    обновление  8.5.10 

Ссылки для загрузки и описания доступны по ссылке

ESXi и Reading privileged memory with a side-channel

Пока половина людей продолжает похмеляться после отмечания НГ, вторая половина истошно обсуждает отчет Google "Reading privileged memory with a side-channel" и хайпит на темы:

CVE-2017-5753
CVE-2017-5715
CVE-2017-5754

У VMware вроде все более менне ровно и выглядит примерно так

CVE-2017-5753, CVE-2017-5715 закрыты в ESX 6.5 обновлением от 19.12.2017 за именем ESXi650-20172101-SG

Для остальных версий (6.0 и 5.5) также есть соответсвующие KB и патчи.

А про CVE-2017-5754 написано примерно так: "It does not affect ESXi, Workstation, and Fusion because ESXi does not run untrusted user mode code, and Workstation and Fusion rely on the protection that the underlying operating system provides."