Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 3129 сообщений
Cообщения с меткой

ubuntu - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

Аудит уязвимостей Linux c Vulners.com

Понедельник, 22 Августа 2016 г. 14:39 (ссылка)

Vulners задумывался как поисковик для Security Content-а: уязвимостей, бюллетеней безопасности, эксплоитов, плагинов детекта и прочей полезной информации. Но мы подумали: если у нас уже есть разобранные бюллетени безопасности для основных Linux-дистрибутивов, почему бы нам не сделать сервис, который будет брать данные о системе, а на выходе отдавать список уязвимостей. Также, как это делают привычные сканеры уязвимостей, только быстрее и бесплатно.







Откуда мы получаем информацию об уязвимостях Linux? Для этого мы парсим бюллетени вендоров. Покажем процедуру разбора на примере бюллетеня безопасности Debian DSA-3638.



Изначальная информация на странице вендора:



https://security-tracker.debian.org/tracker/DSA-3638-1







Мы видим, что уязвим source пакет curl на операционной системе версии jessie и уязвимость исправлена в пакете версии 7.38.0-4+deb8u4. Но этой информации не достаточно, чтобы правильно определить уязвимость. curl в данном случае является source-пакетом, то есть на его основе собираются бинарные пакеты. Поэтому нужно найти все бинарные пакеты, собранные из пакета curl:



packages.debian.org/source/jessie/curl





В итоге мы считаем, что уязвимость есть для всех перечисленных пакетов версии меньше 7.38.0-4+deb8u4



https://vulners.com/api/v3/search/id?id=DSA-3638


{
"result": "OK",
"data": {
"documents": {
"DSA-3638": {
"objectVersion": "1.0",
"modified": "2016-08-03T00:00:00",
"affectedPackage": [
{
"packageName": "libcurl3-nss",
"packageVersion": "7.38.0-4+deb8u4",
"packageFilename": "libcurl3-nss_7.38.0-4+deb8u4_all.deb",
"arch": "all",
"operator": "lt",
"OSVersion": "8",
"OS": "Debian GNU/Linux"
},
{
"packageName": "curl",
"packageVersion": "7.38.0-4+deb8u4",
"packageFilename": "curl_7.38.0-4+deb8u4_all.deb",
"arch": "all",
"operator": "lt",
"OSVersion": "8",
"OS": "Debian GNU/Linux"
...




Как работает Аудит? Сначала нам нужно собрать и отправить на сервер информацию о пакетах и ОС. Версия ос содержится в файлах /etc/os-release, /etc/centos-release и других файлах, специфичных для тех или иных операционных систем. В качестве источника информации об установленных пакетах для rpm-based систем достаточно стандартной команды rpm -qa. В случае deb-based системы нужен вывод команды посложнее — dpkg-query -W -f='${Package} ${Version} ${Architecture}\n'



В ответ сервер вернет нам информацию о найденных уязвимостях. Рассчет происходит очень быстро. Мы обрабатываем 750 пакетов за 160ms! Можно подумать, что на сервере происходит какая-то магия. Но это не так, все на самом деле очень просто и так работаю практически все сканеры уязвимостей.



Рассмотрим пакет — curl 7.38.0-4+deb8u3 amd64 для Debian Linux. Имя пакета curl. Мы ищем в системы все бюллетени, которые содержат это пакет среди списка уязвимых пакетов. После того, как все такие бюллетени найдены, нужно пройтись по каждому из них и проверить, выполняется ли хотя бы одно из условие из перечисленных в поле affectedPackage. Возьмем для примера пакет DSA-3638:




{
"OS": "Debian GNU/Linux",
"operator": "lt",
"packageFilename": "libcurl3-nss_7.38.0-4+deb8u4_all.deb",
"OSVersion": "8",
"packageVersion": "7.38.0-4+deb8u4",
"packageName": "libcurl3-nss",
"arch": "all"
}




Здесь указано, что уязвимость имеет место быть в случае, если:

— Операционная система — Debian GNU/Linux («OS»: «Debian GNU/Linux»)

— Версия этой операционной системы — 8 («OSVersion»: «8»)

— Установлен пакет с именем libcurl3-nss («packageName»: «libcurl3-nss»)

— Архитектура уязвимого пакета — любая

— И версия этого пакета меньше, чем 7.38.0-4+deb8u4 («operator»: «lt» и «packageVersion»: «7.38.0-4+deb8u4»)



Если все условия выполнились — пакет подвержен данной уязвимости DSA-3638. Для каждого пакета в системе мы проверяем все условия из бюллетеней и получаем список уязвимостей для системы. Как видите, какой-то сложности или магии в этом нет.



Важно отметить, ни в коем случае нельзя сравнивать версии как числа или строки. Для каждой из систем (debian, redhat, solaris) структура версий отличается. И соответственно отличается механика их сравнения. Для того, чтобы обеспечить достоверность сканирования, необходимо реализовывать сравнение версий ровно по тому же алгоритму, как он сделан в самой операционной системе. К счастью, какой-то тайны в этом нет, есть готовые примеры функций сравнения для того же debian.



На сегодняшний день мы готовы вам предложить веб-интерфейс, с помощью которого можно проверить свой сервер на уязвимости, полноценное API для автоматизации и PoС агента для нашего будущего облачного решения по управлению уязвимостями. Поддерживаются следующие дистрибутивы Linux: RedHat, CentOS, Fedora, Oracle Linux, Ubuntu, Debian.



Графический интерфейс доступен на вкладке Audit.







Найденные уязвимости:







Аналогично можно работать через Audit API. Задайте список установленных пакетов и версию ОС, а в ответ получите список уязвимостей и описание того почему мы считаем, что уязвимость действительно есть. Вы можете сравнить результаты с результатами своего сканера и попросите своего вендора объяснить расхождения. Ну или пните нас, что мы где-то накосячили ;-)




curl -H "Accept: application/json" -H "Content-Type: application/json" -X POST -d '{"os":"centos","package":["pcre-8.32-15.el7.x86_64", "samba-common-4.2.3-11.el7_2.noarch", "gnu-free-fonts-common-20120503-8.el7.noarch", "libreport-centos-2.1.11-32.el7.centos.x86_64", "libacl-2.2.51-12.el7.x86_64", "sos-3.2-35.el7.centos.noarch" ],"version":"7"}' https://vulners.com/api/v3/audit/audit/
{
"result": "OK",
"data": {
"reasons": [
{
"providedPackage": "sos-3.2-35.el7.centos.noarch",
"operator": "lt",
"bulletinID": "CESA-2016:0188",
"providedVersion": "0:3.2-35.el7.centos",
"bulletinPackage": "sos-3.2-35.el7.centos.3.noarch.rpm",
"bulletinVersion": "3.2-35.el7.centos.3",
"package": "sos-3.2-35.el7.centos.noarch"
},
{
"providedPackage": "pcre-8.32-15.el7.x86_64",
"operator": "lt",
"bulletinID": "CESA-2016:1025",
"providedVersion": "0:8.32-15.el7",
"bulletinPackage": "pcre-8.32-15.el7_2.1.x86_64.rpm",
"bulletinVersion": "8.32-15.el7_2.1",
"package": "pcre-8.32-15.el7.x86_64"
},
{
"providedPackage": "samba-common-4.2.3-11.el7_2.noarch",
"operator": "lt",
"bulletinID": "CESA-2016:1486",
"providedVersion": "0:4.2.3-11.el7_2",
"bulletinPackage": "samba-common-4.2.10-7.el7_2.noarch.rpm",
"bulletinVersion": "4.2.10-7.el7_2",
"package": "samba-common-4.2.3-11.el7_2.noarch"
},
{
"providedPackage": "samba-common-4.2.3-11.el7_2.noarch",
"operator": "lt",
"bulletinID": "CESA-2016:0612",
"providedVersion": "0:4.2.3-11.el7_2",
"bulletinPackage": "samba-common-4.2.10-6.el7_2.noarch.rpm",
"bulletinVersion": "4.2.10-6.el7_2",
"package": "samba-common-4.2.3-11.el7_2.noarch"
},
{
"providedPackage": "samba-common-4.2.3-11.el7_2.noarch",
"operator": "lt",
"bulletinID": "CESA-2016:0448",
"providedVersion": "0:4.2.3-11.el7_2",
"bulletinPackage": "samba-common-4.2.3-12.el7_2.noarch.rpm",
"bulletinVersion": "4.2.3-12.el7_2",
"package": "samba-common-4.2.3-11.el7_2.noarch"
}
],
"vulnerabilities": [
"CESA-2016:1486",
"CESA-2016:1025",
"CESA-2016:0448",
"CESA-2016:0612",
"CESA-2016:0188"
],
"cvelist": [
"CVE-2015-5370",
"CVE-2015-7560",
"CVE-2016-2119",
"CVE-2016-2118",
"CVE-2015-7529",
"CVE-2016-2112",
"CVE-2016-2113",
"CVE-2016-3191",
"CVE-2015-8386",
"CVE-2015-8388",
"CVE-2015-8385",
"CVE-2016-2110",
"CVE-2015-5073",
"CVE-2015-8391",
"CVE-2015-2328",
"CVE-2016-2115",
"CVE-2015-3217",
"CVE-2016-2114",
"CVE-2016-2111"
],
"cvss": {
"vector": "AV:NETWORK/AC:LOW/Au:NONE/C:PARTIAL/I:PARTIAL/A:COMPLETE/",
"score": 9.0
},
"packages": {
"pcre-8.32-15.el7.x86_64": {
"CESA-2016:1025": [
{
"providedPackage": "pcre-8.32-15.el7.x86_64",
"operator": "lt",
"bulletinID": "CESA-2016:1025",
"providedVersion": "0:8.32-15.el7",
"bulletinPackage": "pcre-8.32-15.el7_2.1.x86_64.rpm",
"bulletinVersion": "8.32-15.el7_2.1",
"package": "pcre-8.32-15.el7.x86_64"
}
]
},
"sos-3.2-35.el7.centos.noarch": {
"CESA-2016:0188": [
{
"providedPackage": "sos-3.2-35.el7.centos.noarch",
"operator": "lt",
"bulletinID": "CESA-2016:0188",
"providedVersion": "0:3.2-35.el7.centos",
"bulletinPackage": "sos-3.2-35.el7.centos.3.noarch.rpm",
"bulletinVersion": "3.2-35.el7.centos.3",
"package": "sos-3.2-35.el7.centos.noarch"
}
]
},
"samba-common-4.2.3-11.el7_2.noarch": {
"CESA-2016:1486": [
{
"providedPackage": "samba-common-4.2.3-11.el7_2.noarch",
"operator": "lt",
"bulletinID": "CESA-2016:1486",
"providedVersion": "0:4.2.3-11.el7_2",
"bulletinPackage": "samba-common-4.2.10-7.el7_2.noarch.rpm",
"bulletinVersion": "4.2.10-7.el7_2",
"package": "samba-common-4.2.3-11.el7_2.noarch"
}
],
"CESA-2016:0448": [
{
"providedPackage": "samba-common-4.2.3-11.el7_2.noarch",
"operator": "lt",
"bulletinID": "CESA-2016:0448",
"providedVersion": "0:4.2.3-11.el7_2",
"bulletinPackage": "samba-common-4.2.3-12.el7_2.noarch.rpm",
"bulletinVersion": "4.2.3-12.el7_2",
"package": "samba-common-4.2.3-11.el7_2.noarch"
}
],
"CESA-2016:0612": [
{
"providedPackage": "samba-common-4.2.3-11.el7_2.noarch",
"operator": "lt",
"bulletinID": "CESA-2016:0612",
"providedVersion": "0:4.2.3-11.el7_2",
"bulletinPackage": "samba-common-4.2.10-6.el7_2.noarch.rpm",
"bulletinVersion": "4.2.10-6.el7_2",
"package": "samba-common-4.2.3-11.el7_2.noarch"
}
]
}
}
}




И, наконец, агент для будущего облачного решения по управлению уязвимостями. Мы выступаем за прозрачность работы всех компонент, поэтом сделали агент полнофункциональным. Он не только собирает данные с системы и отправляет их на сервер Vulners-а для анализа и отображения, но и принимает с сервера рассчитанные списки уязвимостей и отображает их в консоли. Агентное решение выбрано не случайно. Оно дает наиболее быстрый и надежный результат, если один раз решить проблемы с автоматической разливкой агентов. Не нужно создавать какие-то учетные записи, открывать сетевые доступы для сканеров и разбираться, высчитывать параметры, и время, когда сканирование не будет забивать канал и тд. На текущий момент это всего лишь python-скрипт, но в дальнейшем будет полноценный пакет для системы.




$ git clone https://github.com/videns/vulners-scanner
$ cd vulners-scanner
$ ./linuxScanner.py

_
__ ___ _| |_ __ ___ _ __ ___
\ \ / / | | | | '_ \ / _ \ '__/ __|
\ V /| |_| | | | | | __/ | \__ \
\_/ \__,_|_|_| |_|\___|_| |___/

==========================================
Host info - Host machine
OS Name - centos, OS Version - 7
Total found packages: 1026
Vulnerable packages:
krb5-libs-1.13.2-10.el7.x86_64
CESA-2016:0532 - 'Moderate krb5 Security Update', cvss.score - 6.8
openssh-server-6.6.1p1-23.el7_2.x86_64
CESA-2016:0465 - 'Moderate openssh Security Update', cvss.score - 7.7
libtdb-1.3.6-2.el7.x86_64
CESA-2016:0612 - 'Critical ipa Security Update', cvss.score - 0.0
kernel-tools-3.10.0-327.4.5.el7.x86_64
CESA-2016:1033 - 'Important kernel Security Update', cvss.score - 0.0
CESA-2016:1633 - 'Important kernel Security Update', cvss.score - 4.3
CESA-2016:0185 - 'Important kernel Security Update', cvss.score - 7.2
CESA-2016:1539 - 'Important kernel Security Update', cvss.score - 7.2
CESA-2016:1277 - 'Important kernel Security Update', cvss.score - 7.2
openssl-libs-1.0.1e-51.el7_2.2.x86_64
CESA-2016:0301 - 'Important openssl Security Update', cvss.score - 0.0
CESA-2016:0722 - 'Important openssl Security Update', cvss.score - 10.0
nss-softokn-3.16.2.3-13.el7_1.x86_64
CESA-2016:0685 - 'Moderate nss-softokn Security Update', cvss.score - 6.8
...




Как видите анализа защищенности Linux, можно делать эффективнее и быстрее и без дорогостоящих сканеров уязвимостей. Мы, конечно, рекомендуем Vulners. Но если вы не хотите отправлять ничего на наш сервер, например волнуетесь за приватность, ты вы можете реализовать данный функционал самостоятельно. Это сделать не сложно. Вам потрубется реализовать функцию сравнения, скачать у нас полный набор данных по операционной системы, например набор для CentOS, и обработать свои данные так, как мы показыли выше. Как делать сбор данных вы можете посмотреть в исходном коде нашего агента. Агент у нас открытый и мы были бы рады разивать его вместе с вами! Pull requests welcome! Ждем предложений и пожеланий!
Original source: habrahabr.ru.

https://habrahabr.ru/post/308236/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Из песочницы] Используем Secure Boot в Linux на всю катушку

Четверг, 18 Августа 2016 г. 13:00 (ссылка)





Технология Secure Boot нацелена на предотвращение исполнения недоверенного кода при загрузке операционной системы, то есть защиту от буткитов и атак типа Evil Maid. Устройства с Secure Boot содержат в энергонезависимой памяти базу данных открытых ключей, которыми проверяются подписи загружаемых UEFI-приложений вроде загрузчиков ОС и драйверов. Приложения, подписанные доверенным ключом и с правильной контрольной суммой, допускаются к загрузке, остальные блокируются.



Более подробно о Secure Boot можно узнать из цикла статей от CodeRush.





Чтобы Secure Boot обеспечивал безопасность, подписываемые приложения должны соблюдать некоторый «кодекс чести»: не иметь в себе лазеек для неограниченного доступа к системе и параметрам Secure Boot, а также требовать того же от загружаемых ими приложений. Если подписанное приложение предоставляет возможность недобросовестного использования напрямую или путём загрузки других приложений, оно становится угрозой безопасности всех пользователей, доверяющих этому приложению. Такую угрозу представляют загрузчик shim, подписываемый Microsoft, и загружаемый им GRUB.



Чтобы от этого защититься, мы установим Ubuntu с шифрованием всего диска на базе LUKS и LVM, защитим initramfs от изменений, объединив его с ядром в одно UEFI-приложение, и подпишем его собственными ключами.



Ограничения решений «из коробки»



Ubuntu, как и другие распространённые дистрибутивы, предлагает опцию шифрования всего диска с LVM во время установки. Дистрибутив в такой конфигурации без ошибок устанавливается на UEFI с активным Secure Boot.



Но Canonical в первую очередь заинтересована в работоспособности ОС на устройствах с включённым Secure Boot, а не в обеспечении безопасности за счёт него. Если вы хотите использовать Secure Boot как средство безопасности, то вы сами по себе.



Как Ubuntu реализует загрузку в Secure Boot с шифрованием всего диска и что с этим не так?



Red Hat разработали загрузчик shim, чтобы он работал на всех устройствах и служил на благо человечеству, соблюдая строгие предписания стандарта Secure Boot и загружая только доверенные UEFI-приложения. Canonical использует shim как прокси, встраивая в него свой публичный ключ и подписывая у Microsoft. Shim загружает GRUB, подписанный ключём Canonical, который затем загружает ядро, подписанное Canonical.




  • Начнём с того, что шифруется не весь диск — /boot остаётся незашифрованным, а значит и initramfs в нём. Доступ к initramfs означает root-доступ. Fail.




  • /boot остаётся незашифрованным, потому что устанавливаемый по умолчанию GRUB не может расшифровать диск без криптографических модулей. Которые почему-то не встроили в подписанный GRUB. GRUB'у запрещено загружать дополнительные модули в Secure Boot. Double Fail1.




  • GRUB должен верифицировать загружаемые ядра и отвергать неверно подписанные. Он этого не делает. Triple Fail.




  • GRUB загружает свои настройки из файла и по умолчанию предоставляет доступ к консоли. Подлинность конфигурационного файла не проверяется, с помощью его модификации или через консоль можно сделать что угодно: загрузить UEFI Shell, другое ядро, initramfs или передать аргументы ядру и получить root-доступ. Fatal Error2.



Что это всё означает?



Если в вашей системе есть ключ Microsoft3, то кто угодно может загрузиться с внешнего устройства, установить буткит и получить полный контроль над вашим устройством. Нет небходимости отключать Secure Boot: он уже не работает.







Согласно политике Microsoft о подписывании UEFI-приложений, все подписанные загрузчики GRUB и shim, используемые для загрузки GRUB, уже должны быть занесены в чёрный список.



Говорите, нужно просто отключить загрузку с внешних устройств? Это борьба с симптомами. Если у вас установлен незащищённый GRUB, то вас это не спасёт. Если на вашем устройстве стоит Windows, то вы можете выбрать из неё устройство для загрузки, и есть вероятность, что ваша прошивка это позволит4. Ещё остаётся PXE Network Boot. Поможет только пароль на включение устройства.



Вывод


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



Установка Ubuntu с шифрованием всего диска с помощью LUKS и LVM



LUKS — Linux Unified Key Setup — обёртка для криптографической системы dm-crypt, позволяющая создавать виртуальные зашифрованные устройства в файлах и на физических дисках. С помощью LUKS можно зашифровать данные на всём диске для того, чтобы перед загрузкой ОС требовалось ввести пароль.



LVM — Logical Volume Manager — менеджер логических томов, с помощью которого мы разделим криптоконтейнер на тома. Тома LVM автоматически монтируются после ввода пароля к криптоконтейнеру, отдельный ввод пароля для каждого тома не требуется.



Следующие инструкции должны быть применимы к любому дистрибутиву на базе Ubuntu, для других потребуются коррективы. Сперва загрузитесь с Live CD или установочного образа в режиме Try before installing.



Разметка и шифрование



Чтобы загружаться с диска в режиме UEFI, он должен быть размечен в формате GPT. Разметку диска рассмотрим с помощью KDE Partition Manager и GParted. Если у вас их нет, установите один, соответствующий вашей среде.



sudo apt-get install partitionmanager   # KDE
sudo apt-get install gparted # GNOME и другие


Запустите редактор разделов и выберите интересующий вас диск, обычно это первый в системе — /dev/sda. Посмотрите свойства диска.



KDE Partition Manager: Два раза кликните по диску,
GParted: View -> Device Information.


В строке Partition table указана используемая таблица разделов. Если диск размечен в формате dos/msdos (MBR), то его необходимо преобразовать в GPT. Это возможно сделать без потери данных, но здесь я этого описывать не буду, поищите инструкции в интернете. Если на диске нет важных данных и вы хотите форматировать его в GPT, создайте новую таблицу.



KDE Partition Manager: New Partition Table — GPT
GParted: Device -> Create Partition Table — gpt


На диске должен быть как минимум один раздел ESP (EFI System Partition), в котором будут храниться загрузчики. Если на этом диске установлена ОС в режиме UEFI, то один такой раздел уже есть. В любом случае я рекомендую создать новый размером не меньше 100 МБ. ESP должен быть отформатирован в один из FAT-форматов, предпочтительно в FAT32, а также помечен как загрузочный.



KDE Partition Manager: Кликнуть по неразмеченной области -> New
File system: fat32
Size: 128.00 MiB
Free space before: 0.00 — место после таблицы GPT
OK, Apply
Выбрать созданный раздел и открыть свойства (Properties), выставить флаг boot
OK, Apply

GParted: Кликнуть по неразмеченной области -> New
File system: fat32
New size: 128 MiB
Free space preceding: 1 MiB или больше — место под таблицу GPT
Add, Apply
Выбрать созданный раздел и открыть управление флагами (Manage Flags), выставить флаг boot
Close


Дальше нужно создать раздел для шифрования. Тем же образом, что и ESP, только без форматирования (unformatted), выставления флагов и размером побольше — так, чтобы вместил систему и раздел подкачки. Создадим в этом разделе криптоконтейнер LUKS через терминал, предварительно перейдя в режим суперпользователя.



sudo -i


Отформатируем раздел с указанием современных алгоритмов шифрования и хеширования. В режиме XTS длину ключа необходимо указывать в два раза больше, поэтому для AES-256 нужно указать ключ длиной 512 бит. Параметр --iter-time задаёт время в миллисекундах, затрачиваемое на генерацию ключа из вводимого пароля функцией PBKDF2. Большее количество итераций усложняет перебор пароля, но и увеличивает время ожидания после ввода верного пароля.



cryptsetup luksFormat --cipher aes-xts-plain64 --key-size 512 --hash sha512 --iter-time 2000 /dev/sda2


Подтвердите форматирование, написав YES, введите пароль. Теперь откройте криптоконтейнер (sda2_crypt — имя для маппинга) и введите тот же пароль.



cryptsetup luksOpen /dev/sda2 sda2_crypt


Контейнер должен стать доступным как блочное устройство /dev/mapper/sda2_crypt. Перейдём к разметке логических томов внутри криптоконтейнера. Инициализируем физический раздел LVM поверх /dev/mapper/sda2_crypt.



pvcreate /dev/mapper/sda2_crypt


Внутри этого физического раздела создадим группу томов с именем ubuntu.



vgcreate ubuntu /dev/mapper/sda2_crypt


Теперь мы можем создавать логические тома внутри этой группы. Первым делом создадим том для раздела подкачки и инициализируем его. Рекомендуемый размер — от sqrt(RAM) до 2xRAM в гигабайтах.



lvcreate -n swap -L 4G ubuntu # создать логический том с меткой swap размером 4 ГБ в группе ubuntu
mkswap /dev/ubuntu/swap


Добавим том для корня и создадим в нём файловую систему ext4. Хорошей практикой считается оставлять свободное место и расширять тома по мере необходимости, поэтому выделим для корня 20 ГБ. По желанию в свободном месте можно будет разметить дополнительные тома для home, usr, var и так далее. Выделить всё свободное место для тома можно с помощью параметра -l 100%FREE.



lvcreate -n root -L 20G ubuntu
mkfs.ext4 /dev/ubuntu/root


С разметкой закончено, можно перейти к установке.



Установка



Так как мы планируем создать загрузчик самостоятельно, да и установщик Ubuntu не поддерживает шифрование /boot, запустим установку без создания загрузчика.



ubiquity -b


На этапе разметки диска выберите Вручную.



Здесь нам необходимо указать точки монтирования. Выберите /dev/mapper/ubuntu-root, укажите использование в качестве журналируемой файловой системы Ext4, точку монтирования (Mount Point) в /, без форматирования. Ubiquity сама подхватит /dev/mapper/ubuntu-swap как раздел подкачки и запомнит один из системных разделов EFI. Экран разметки должен выглядеть так:







Закончите установку и не перезагружайтесь.



Настройка crypttab, fstab и resume



Смонтируйте корень установленной системы в /mnt, свяжите /dev, /sys и /proc с /mnt/dev, /mnt/sys и /mnt/proc соответственно, а также /etc/resolv.conf с /mnt/etc/resolv.conf, чтобы у вас был доступ к сети. Теперь смените корневой каталог с помощью chroot.



mount /dev/ubuntu/root /mnt
mount --bind /dev /mnt/dev
mount --bind /sys /mnt/sys
mount --bind /proc /mnt/proc
mount --bind /etc/resolv.conf /mnt/etc/resolv.conf
chroot /mnt


Вам необходимо вручную заполнить /etc/crypttab — файл, описывающий монтируемые при загрузке криптоконтейнеры.



nano /etc/crypttab


В него нужно добавить запись о /dev/sda2, монтируемом в /dev/mapper/sda2_crypt. Настроим монтирование по UUID, а не по имени устройства. Чтобы узнать UUID /dev/sda2, откройте другой терминал и воспользуйтесь командой:



sudo blkid


В строке, начинающейся с /dev/sda2, будет записан его UUID. Скопируйте его (Ctrl+Shift+C). В /etc/crypttab добавьте запись вида имя_маппинга UUID= none luks, вставив UUID (Ctrl+Shift+V). Закройте nano, нажав Ctrl+X и Y, подтвердив сохранение.







Проверьте, чтобы в /etc/fstab были правильно описаны монтируемые разделы, а в /etc/initrmfs-tools/conf.d/resume указан раздел для пробуждения из гибернации.







После всех изменений обновите образ initramfs.



update-initramfs -u


Не выходите из системы и chroot,



Создание загрузчика



Ядро Linux поддерживает загрузку напрямую из UEFI, если оно было скомпилировано с параметром CONFIG_EFI_STUB. В таком случае initramfs обычно хранится рядом в ESP, и путь к нему передаётся в аргументах к ядру.



Однако отсутствие верификации initramfs позволяет встроить в него вредоносный код, имея доступ на запись в ESP. Teddy Reed предлагает компилировать ядро, встраивая в него initramfs.



Процесс компиляции ядра достаточно длительный, её придётся производить после каждого изменения initramfs. К счастью, есть другой способ. В пакете systemd (ранее в gummiboot) находится linuxx64.efi.stub — заготовка UEFI-приложения, в которую можно встроить ядро, initramfs и аргументы, передаваемые ядру. Подписав это UEFI-приложение, мы защитим ядро и initramfs от изменений.



Для данной операции потребуется пакет binutils.



sudo apt-get install binutils


Запишем в /tmp/cmdline аргументы, которые будут передаваться ядру.



echo -n "quite splash" > /tmp/cmdline


В /boot хранятся образы ядра (vmlinuz-*-generic) и initramfs (initrd.img-*-generic). Определите последнюю версию и встройте их в заготовку.



objcopy \
--add-section .osrel=/etc/os-release --change-section-vma .osrel=0x20000 \
--add-section .cmdline=/tmp/cmdline --change-section-vma .cmdline=0x30000 \
--add-section .linux=/boot/vmlinuz-4.4.0-34-generic --change-section-vma .linux=0x2000000 \
--add-section .initrd=/boot/initrd.img-4.4.0-34-generic --change-section-vma .initrd=0x3000000 \
/usr/lib/systemd/boot/efi/linuxx64.efi.stub ubuntu.efi


Полученное UEFI-приложение ubuntu.efi необходимо расположить в ESP в каталоге *FI/BOOT/. Установщик Ubuntu должен был определить ESP и настроить монтирование в /boot/efi. Если в этом ESP нет других загрузчиков, то ubuntu.efi можно скопировать в /boot/efi/EFI/BOOT/BOOTX64.EFI, тогда он будет загружаться при выборе этого раздела в меню загрузки UEFI.



mkdir -p /boot/efi/EFI/BOOT
cp ubuntu.efi /boot/efi/EFI/BOOT/BOOTX64.EFI


Если в ESP уже записан загрузчик BOOTX64.EFI, то можно создать ещё один ESP, либо записать ubuntu.efi под другим именем и добавить соответствующую загрузочную запись через встроенную в вашу прошивку консоль UEFI (UEFI Shell). Использование efibootmgr не рекомендовано5.



Если у вас включён Secure Boot, то загрузиться с ubuntu.efi не получится, так как он не подписан. Временно отключите Secure Boot и загрузитесь, либо продолжите из chroot.



Настройка Secure Boot



Генерацию ключей, их установку в прошивку и подписывание UEFI-приложений описал CodeRush здесь, поэтому я буду считать, что вы всё понимаете и умеете.



Остаётся только подписать созданный нами загрузчик.



sbsign --key ISK.key --cert ISK.pem --output BOOTX64.EFI ubuntu.efi


Поместите BOOTX64.EFI в каталог EFI/BOOT/ раздела EFI, с которого вы планируете загружаться.



Автоматизация



Чтобы загрузчик автоматически обновлялся и подписывался при обновлении initramfs, создайте скрипт update-efi-loader в /etc/initramfs/post-update.d/, изменив пути где требуется.



echo -n "quiet splash" > /tmp/cmdline

objcopy \
--add-section .osrel=/etc/os-release --change-section-vma .osrel=0x20000 \
--add-section .cmdline=/tmp/cmdline --change-section-vma .cmdline=0x30000 \
--add-section .linux=/boot/vmlinuz-$(uname -r) --change-section-vma .linux=0x2000000 \
--add-section .initrd=/boot/initrd.img-$(uname -r) --change-section-vma .initrd=0x3000000 \
/usr/lib/systemd/boot/efi/linuxx64.efi.stub /tmp/ubuntu.efi

sbsign --key /root/keys/ISK.key --cert /root/keys/ISK.pem --output /boot/efi/EFI/BOOT/BOOTX64.EFI /tmp/ubuntu.efi


Дайте скрипту право на исполнение.



chmod a+x /etc/initramfs/post-update.d/update-efi-loader


При обновлении ядра придётся произвести эту операцию вручную.



Подписывание драйверов и модулей ядра



Если вам нужно установить сторонние или собственные драйвера и модули ядра, их необходимо подписать. Для подписи модулей ядра требуются сертификат в формате DER и ключ без пароля, то есть сгенерированный с параметром -nodes.



openssl req -new -nodes -utf8 -sha256 -days 36500 -batch -x509 \
-subj "/CN=Kernel Key" -outform DER -out kernel.der \
-keyout kernel.key


Для подписывания используется скрипт sign-file.



/usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 kernel.key kernel.der module.ko


Чтобы добавить этот сертификат в прошивку, его необходимо преобразовать в формат PEM, затем в ESL и подписать ключом KEK.



openssl x509 -inform der -in kernel.der -outform pem -out kernel.pem
cert-to-efi-sig-list -g "$(uuidgen)" kernel.pem kernel.esl
sign-efi-sig-list -k KEK.key -c KEK.pem kernel kernel.esl kernel.auth


Очевидные советы



Если вашей задачей стоит защита данных на устройстве, то Secure Boot выполнит свою работу и не больше. Остальное возлагается на вас.




  • Не добавляйте чужих ключей в прошивку. Даже от Microsoft. В первую очередь от Microsoft.




  • Не подписывайте UEFI Shell, KeyTool или другие приложения, имеющие доступ к записи в NVRAM. Используйте их в Setup Mode.




  • Не оставляйте устройство включённым без присмотра. Устройство в ждущем режиме (suspend to RAM) содержит в RAM расшифрованные данные и мастер-ключи от криптоконтейнеров.




  • Установите пароль на UEFI Setup не проще, чем от вашего криптоконтейнера.




  • При физическом доступе к внутренностям устройства можно отключить Secure Boot, сбросив память NVRAM или повредив её, а также оставить хардварную закладку. Такая атака успешна только тогда, когда она незаметна. Сделайте так, чтобы вы о ней могли узнать: заклейте винты на корпусе трудновоспроизводимыми стикерами, обмажьте их лаком с блёстками. Опечатайте своё устройство.




  • Поставьте первым в списке загрузки неподписанное приложение. Если вы однажды не увидите сообщение от Secure Boot, то ваше устройство однозначно скомпрометировано.




  • Надёжнее отключённого от интернета устройства, хранимого в сейфе, всё равно ничего не придумаешь. Уязвимости в реализации Secure Boot в конкретных прошивках не исключены.



Бонус: возвращение гибернации



При шифровании всего диска вместо ждущего режима для сохранения состояния и продолжения работы с места остановки обычно используется гибернация, она же спящий режим или suspend to disk.



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







Это верно в том случае, если initramfs не верифицируется и/или раздел подкачки не зашифрован. Однако независимо от использования гибернации при таких условиях initramfs может быть подменён, а чувствительные данные восстановлены из раздела подкачки. В нашей конфигурации initramfs верифицируется, будучи включённым в подписанный загрузочный файл, а раздел подкачки зашифрован. Значит, данное ограничение для нас бессмысленно.



Chung-Yi Lee ещё в 2013 предложил верифицировать образ восстановления, а в 2015 представил реализующий его идею патч. Но воз и ныне там. Поэтому предположим, что мы достаточно защищены с нашим шифрованием, и вернём нам гибернацию без верификации.



Способ 1. Отключить верификацию модулей ядра



Включённая верификация модулей ядра отключает гибернацию. По умолчанию верификация модулей ядра включается вместе с Secure Boot, однако она от Secure Boot не зависит. Её можно отключить, оставив только Secure Boot.



Большого ущерба безопасности это нанести не должно. Модули ядра устанавливаются из доверенного источника вместе с обновлением ядра и хранятся на зашифрованном диске и в верифицируемом initramfs. Сторонние драйвера устанавливаются вручную, и будут они подписаны нами или нет, значения не имеет, ведь мы им уже доверяем. SecureApt для ядра и TLS/HTTPS для сторонних драйверов должны защитить от MiTM, и тогда остаётся только root-доступ к расшифрованному диску. Но в таком случае у злоумышленника уже есть наши данные.



«Оставить заявку» на отключение верификации модулей можно с помощью mokutil, а подтвердит её загрузчик shim.



sudo apt-get install mokutil shim
sudo mokutil --disable-validation


Введите пароль, который затем потребуется посимвольно подтвердить. Теперь нужно загрузиться через shim и выбрать в нём Change Secure Boot state (sic!). Поместите /usr/lib/shim.efi в EFI/BOOT/BOOTX64.EFI на одном из ESP или добавьте загрузочную запись через UEFI Shell. Предварительно отключите Secure Boot, после верните обратно.





Сейчас Secure Boot и гибернация работают, UEFI-приложения верифицируются, но модули ядра нет.



В принципе, shim и mokutil больше не требуются, их можно удалить.





Способ 2. Использовать старую версию ядра



Патч, отключающий гибернацию, появился в версии Ubuntu-4.4.0-18.34. Ubuntu-4.4.0-17.33 должна быть от него свободна. Однако оставаться на старом ядре, игнорируя обновления безопасности, не лучший вариант.



Способ 3. Скомпилировать своё ядро



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



Инструкции

Получение исходного кода



apt-get


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



В /etc/apt/sources.list должны присутствовать указатели на репозитории исходных кодов. Обычно там уже есть закомменти­рованные записи с deb-src. Раскомментируйте их для репозиториев xenial main и xenial-security main, либо добавьте сами, а затем обновите индекс apt.



$ sudo nano /etc/apt/sources.list
...
deb-src http://ru.archive.ubuntu.com/ubuntu/ xenial main restricted
deb-src http://security.ubuntu.com/ubuntu xenial-security main restricted
...
$ apt-get update


Загрузите исходный код и перейдите в создавшуюся директорию.



apt-get source linux-image-$(uname -r)
cd linux-4.4.0


Обратите внимание на то, чтобы apt скачивал актуальную версию исходного кода. Проверьте номер версии у файла .dsc.



linux_4.4.0-34.53.dsc


git


Если вы хотите поддерживать ядро в актуальном состоянии и перекомпилировать его по мере выхода обновлений с сохранением своих изменений, выберите git. Первоначальная загрузка займёт продолжительное время.



Установите git.



sudo apt-get install git


Создайте локальную копию git-репозитория ядра текущего релиза Ubuntu и перейдите в создавшуюся директорию.



git clone git://kernel.ubuntu.com/ubuntu/ubuntu-xenial.git
cd ubuntu-xenial


По умолчанию git указывает на ветку master, соответствующую версии последнего релиза. Переключиться на другую версию можно по тегу релиза этой версии. Чтобы перечислить все теги по заданной маске, используйте git tag -l <маска>.



$ git tag -l Ubuntu-*
...
Ubuntu-4.4.0-33.52
Ubuntu-4.4.0-34.53
Ubuntu-4.4.0-35.54
...


Создайте ветку temp для тега, соответствующего вашей версии, и переключитесь на неё.



git checkout -b temp Ubuntu-4.4.0-34.53


Настройка



Загрузите пакеты, требуемые для компиляции (build dependencies).



sudo apt-get build-dep
sudo apt-get ccache fakeroot kernel-package libncurses5-dev


Убедитесь, что скриптам выставлено право на исполнение, запустите чистку.



chmod a+x debian/rules
chmod a+x debian/scripts/*
chmod a+x debian/scripts/misc/*
fakeroot debian/rules clean


Скопируйте старый файл конфигурации в текущую директорию, запустите конфигурацию, выберите Load и загрузите config. Больше изменять ничего не требуется, выйдите и сохраните конфигурацию — Exit -> Yes.



cp /boot/config-4.4.0-34-generic config
fakeroot debian/rules editconfigs


Измените файл kernel/power/hibernate.c, убрав проверку secure_modules().



--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -67,7 +67,7 @@ static const struct platform_hibernation_ops *hibernation_ops;

bool hibernation_available(void)
{
- return ((nohibernate == 0) && !secure_modules());
+ return (nohibernate == 0);
}

/**
--


Если вы используете git

Подготовьте файл к коммиту.



git add kernel/power/hibernate.c


Если вы ещё не совершали коммитов и не вводили свои данные, сделайте это сейчас.



git config --global user.email "you@example.com"
git config --global user.name "Your Name"


Сделайте коммит, введите комментарий.



$ git commit
...
Allow hibernation on Secure Boot


Теперь ваши изменения сохранены в новом снимке состояния (snapshot). Если вы захотите обновиться до следующей версии и применить к ней те же самые изменения, используйте git rebase <ветка или тег>



$ git rebase Ubuntu-4.4.0-35.54
Сначала перематываем указатель текущего коммита, чтобы применить ваши изменения поверх него…
Применение: Allow hibernation on Secure Boot


Скрипты компиляции определяют версию ядра по последней записи в истории изменений (changelog) в директории debian.master. Добавьте новую запись, чтобы изменить версию.



EDITOR=nano debchange -c debian.master/changelog -l "custom"


К версии будет добавлен суффикс custom1, что отразится при сборке пакетов .deb и позволит установить их при уже установленных пакетах той же версии без суффикса. Однако этот суффикс распространяется только на имя пакета, но не на его содержимое: ядро и директория с его модулями будут иметь ту же версию 4.4.0-34-generic, и при установке старые файлы перезапишутся новыми. Чтобы этого избежать, измените версию ABI c 34 на, например, 3400.



linux (4.4.0-3400.53custom1) UNRELEASED; urgency=medium

* Allow hibernation on Secure Boot
...


Компиляция



Запустите чистку ещё раз и скомпилируйте ядро. Если вы не опытный разработчик ядра и не понимаете, как работают проверки ABI и модулей (я вот не понимаю), отключите их (skipabi=true, skipmodule=true), иначе ваша компиляция сломается на одном из последних этапов. Здесь используется многопоточная сборка пакетов с количеством потоков, равным количеству ядер процессора. Цель binary-generic означает компиляцию обычной разновидности ядра, архитектура определяется автоматически.



fakeroot debian/rules clean
skipabi=true skipmodule=true DEB_BUILD_OPTIONS=parallel=$(getconf _NPROCESSORS_ONLN) do_tools=false no_dumpfile=1 \
fakeroot debian\rules binary-generic


Если компиляция прошла успешно, то в вашей домашней директории появятся три пакета .deb. Необходимо установить linux-image-.deb, а также желательно linux-image-extra-.deb. Это можно сделать с помощью dpkg -i <путь к пакету> или через QApt, открыв пакет в файловом менеджере, если он это поддерживает. Будьте осторожны: если вы не изменяли версию ABI, то старое ядро и модули перезапишутся.



Снова соберите загрузочный файл.



echo -n "quiet splash" > /tmp/cmdline

objcopy \
--add-section .osrel=/etc/os-release --change-section-vma .osrel=0x20000 \
--add-section .cmdline=/tmp/cmdline --change-section-vma .cmdline=0x30000 \
--add-section .linux=/boot/vmlinuz-4.4.0-34-generic --change-section-vma .linux=0x2000000 \
--add-section .initrd=/boot/initrd.img-4.4.0-34-generic --change-section-vma .initrd=0x3000000 \
/usr/lib/systemd/boot/efi/linuxx64.efi.stub /tmp/test.efi

sbsign --key /root/keys/my.key --cert /root/keys/my.pem --output /boot/efi/EFI/BOOT/BOOTX64.EFI /tmp/test.efi




Гибернация работает, но нестабильно. Как, впрочем, и без Secure Boot.





Способ 4. Отказ от гибернации и использование виртуализации



Если гибернация и работает, то это не делает её надёжным средством сохранения состояния. Это может быть проблемой моего железа, дистрибутива или, что более вероятно, KDE Plasma, но у меня Kubuntu просыпается через раз.



По уже описанной технологии в качестве хостовой ОС можно установить подходящий дистрибутив Linux, а гостевой — предпочитаемую для работы. При завершении работы автоматически останавливать виртуальную машину с сохранением состояния, а затем отключать устройство. При включении же восстанавливать состояние. Если ваше устройство поддерживает аппаратную виртуализацию, то для этого подойдёт Qemu KVM. Но это уже тема для отдельной статьи.



С большей надёжностью придёт и большая защищённость: чувствительные данные можно изолировать от опасной среды. Браузер и песочница для установки стороннних пакетов в одной виртуальной машине, важные персональные данные — в другой. Украсть мастер-ключ от зашифрованного диска в памяти хостовой ОС из гостевой гораздо сложнее. Кажется, для подобного существует Qubes OS. Но она данный момент не поддерживает Secure Boot. Fail.



На этом всё, приветствуются любые дополнения и замечания.



Примечания




  1. ^Решаемо путём сборки образа GRUB с нужными модулями с помощью grub-mkstandalone, но его придётся подписывать самому.




  2. ^Теоретически можно исправить, установив пароль, встроив grub.cfg в образ GRUB с помощью grub-mkstandalone и установив в grub.cfg prefix на невалидный путь, чтобы GRUB не мог найти второй grub.cfg на диске. Но опять же требуется подписывать образ самостоятельно.




  3. ^А он есть у всех кроме параноиковоправданно озабоченных своей безопасностью пользователей.




  4. ^У меня загрузиться с USB не даёт. Windows 8 и 10 также без пароля не пускают в безопасный режим или консоль.




  5. ^Говорят, некоторые прошивки он окирпичивает. Безопаснее создать по ESP на каждый загрузчик.


Original source: habrahabr.ru.

https://habrahabr.ru/post/308032/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Mirantis Unlocked validation program. Часть 2: Hard and Soft

Четверг, 11 Августа 2016 г. 10:03 (ссылка)

Авторы: Евгения Шумахер, Илья Стечкин



Представляем вашему вниманию второй материал, посвященный программам валидации, которые предлагает Mirantis своим партнерам. В прошлом посте мы рассказывали о том, кому и для чего нужно валидировать fuel-плагины. Сегодня поговорим о валидации приложений и “железа”.



“Железная” логика







Эта история, скорее, про Linux. Потому что главная задача Hardware compatibility program проверить, что Linux видит конкретное оборудование и может с ним работать. Казалось бы, все более-менее просто: если Linux видит, то и OpenStack видит. Однако...



Допустим, у нас есть модель сервера с определенными сетевыми картами и мы проверяем, что MOS (читай Ubuntu, потому что это хостовая ОС для облачной инфраструктуры в нашем дистрибутиве) видит это “железо” и эти сетевые (networking) карты. Есть принятый в индустрии термин HCL (Hardware Compatibility List) — список совместимости программного обеспечения и оборудования с операционной системой. Почему же мы не можем просто взять “внешний” список, например, от Canonical? Дело в том, что Fuel — основной инструмент развертывания MOS (Mirantis OpenStack), использует механизм bootstrap-images.



Итак, Fuel мастер-нода находит все серверы, которые к ней подключены и начинает процесс провижининга. Он заключается в том, что на ноду ставится бутстрап-имидж, который может быть задан оператором Fuel. Да-да, вы можете установить любой пользовательский пакет из репозитория по умолчанию или подключенного внешнего хранилища, используя скрипт fuel-bootstrap builder. Как это работает, можно узнать здесь (не бойтесь, английский по ссылке есть, конечно, но кода там много больше, чем пустой болтовни).



И только через несколько шагов после этого происходит установка хостовой операционной системы. Таким образом, проверки “классической версии” операционной системы бывает недостаточно, потому что свойства бутстрап-имиджа могут от нее порой отличаться. Возможна, возвращаясь к началу статьи, ситуация, при которой Ubuntu “видит” сетевую карту, а бутстрап — нет.



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



Но поскольку Mirantis OpenStack сегодня один из самых популярных дистрибутивов OpenStack, очевидно, вендоры, производящие “железо”, заинтересованы в попадании в наш список — это их способ отрекомендоваться пользователям. Процедура валидации для этих компаний довольно проста и подробно описана на нашем сайте. А пользователям можем порекомендовать познакомиться со списком “проверенных поставщиков” оборудования и проверить, попадают ли в него производители “железа”, имеющегося в вашем распоряжении.



Конечно, в 99% случаев Ubuntu HCL работает для MOS, тем более, что там содержится более подробная информация, чем в MOS HCL.



Поэтому мы всегда рекомендуем сначала заглянуть в наш HCL, но обязательно проверить и в Ubuntu HCL тоже. Все-таки Linux вендор знает лучше.



Приложения: “заоблачные” и облачные







Предисловие


Начнем с описания того, какие бывают “приложения” с точки зрения MOS (Mirantis OpenStack). С точки зрения того где “живут” приложения: запущены на виртуальных машинах в облаке (in cloud applications) и дополняющие MOS (running alongside cloud). Приложения, запускаемые в облаке, бывают двух основных типов: те, которые приспособлены для работы в облаке (cloud native applications), и те, которые создавались без учета роста популярности облачных решений. Последние можно интегрировать в OpenStack-клауд, но для этого придется потрудиться.



Поговорим про in-cloud приложения. Они “живут” на виртуальных машинах, которые соединены в облако, которое управляется, например, с помощью OpenStack, на серверах в ЦОДе, который построил Джек. Или Вася. Или еще кто-нибудь.



Как поставить приложение на виртуальную машину? Сперва нужно ее (ВМ) создать, потом — установить на нее операционную систему, а следующим шагом — установить приложение. Сделать это можно “дедовским способом” — с помощью Glance image, который содержит в себе и операционную систему, и приложение. Казалось бы, при чем тут валидация? Так вот…



Валидация in-cloud приложений


Предположим, что у вас есть приложение, которое вы хотели бы провалидировать. Мы предлагаем создать для него Glance image, а потом проделать упражнение, описанное выше, используя инфраструктуру, управляемую MOS (Mirantis OpenStack — кстати, только что вышла новая, девятая версия дистрибутива). Мы выступаем провайдером инфраструктуры. Вы предоставляете Glance image и разворачиваете его на ВМ под управлением MOS. Задача процесса валидации — подтвердить тот факт, что ваше приложение корректно работает с MOS.



Но ведь для некоторых приложений понадобится не одна виртуалка, а несколько запущенных сервисов. Как автоматизировать что-то на уровне приложений? На этом уровне стека на помощь придут Murano-образы и Heat-шаблоны.



Приложения-соседи


А как же другие приложения, те которые “соседи”?



Разберем пример приложений, которые живут рядом с OpenStack. Например, Talligent(биллинг). Для нас это тоже приложение, так как оно не внедряется в OpenStack на уровне инфраструктуры (через OpenStack драйверы), но взаимодействует с кластером на уровне API (по внешним протоколам). Talligent собирает статистику по использованию облака: он, например, обращается к Nova, чтобы получить информацию о количестве виртуальных машин, созданных в определенном тенанте конкретным пользователем.



Такого рода приложения прямого отношения к процессу application validation не имеют, но мы с ними работаем все равно. У них есть 2 способа интеграции с OpenStack вообще и с MOS в частности. Первый способ — можно поставить приложение в ручном режиме: развернуть кластер под управлением MOS, развернуть Talligent и попросить инженеров настроить взаимодейтсвие между ними. Второй способ — это fuel-плагин. Во втором случае — см. наши посты про разработку fuel-плагинов и их валидацию.



Границы возможностей




Если процесс валидации fuel-плагинов или опенстек-драйверов мы описали подробно, выступая с позиции экспертов, точно знающих как интегрироваться в OpenStack инфраструктуру, то в случае с приложениями мы (пока) не обладаем такой экспертизой. Валидация приложений предполагает четкое разделение ролей: мы предоставляем инфраструктуру, а вендор (разработчик приложения) тестирует свое детище на этой инфраструктуре. Поэтому на первом этапе валидации мы много общаемся с разработчиком/вендором приложений, обсуждаем, что нужно для того, чтобы показать, что приложение действительно стабильно работает.



Возьмем модный пример — NFV (Network Function Virtualization).Суть технологии в том, чтобы заменить телеком “железо” приложением, запущенным на виртуальной машине. Есть такое решение — Virtual SBC ( Session Border Controller — пограничный контроллер сессий) — очень востребованная телекоммуникационными компаниями разработка Metaswitch. Ее можно запускать на виртуальной машине, управляемой в том числе и OpenStack. Мы (Мирантис) не можем сказать, как проверить качество работы этого приложения (мы ведь не эксперты), но мы можем сделать так, чтобы OpenStack работал, как нужно этому приложению.

Вендор VNF приложения предъявляет определенные требования к инфраструктуре. Мы удовлетворяем эти требования, настраивая необходимую для тестирования приложения инфраструктуру. Далее партнер устанавливает приложение и тестирует его согласно написанному им Тест Плану. Мы же в итоге смотрим на результаты тестов, предоставляемые вендором.



В плане предоставления NVFI (Network Function Infrastructure) возможны такие сценарии: инфраструктуру для данного приложения можно настроить вручную или автоматически (например, включить опцию Huge Pages). Может быть и так, что вручную настроить инфраструктуру можно (пошаманив с конфигурационными файлами OpenStack), и приложение будет работать корректно, а автоматически настроить конфигурацию облака так как требует того VNF нельзя, то есть конкретная версия Fuel (инструмент развертывания OpenStack и последующего управления клаудом) может не поддерживать установку параметров, требуемых данным приложением. Такие детали всегда описываются в документе, который является важным артефактом процесса валидации — runbook.



Основная идея сертификации — мы говорим вендору: “Покажи нам цифры и тест-кейсы… Поставь свое приложение на нашу инфраструктуру и докажи, что оно на самом деле работает”.



Более подробно с процедурой валидации приложений можно познакомиться здесь.



Заключение: внешние признаки валидации





К сожалению, на сегодняшний день в Community Application Catalog не ставится никаких отметок о сертификации. Но мы планируем создание собственного каталога провалидированных приложений. А прямо сейчас эту информацию можно найти у нас на сайте в партнерском каталоге. Впрочем, мы убеждены в том, что отметка о сертификации под определенный дистрибутив повысит уровень удовлетворения пользователей (customer satisfaction) и позволит избежать конфликтов ожиданий и реальности. А потому надеемся, что команда Community App Catalog услышит наши рекомендации и добавит возможность маркировать провалидированные приложения.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/307470/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Сделай сам веб-сервис с асинхронными очередями и параллельным исполнением

Четверг, 04 Августа 2016 г. 21:03 (ссылка)

rq Каждый должен делать свою работу качественно и в срок. Допустим, вам нужно сделать веб-сервис классификации картинок на базе обученной нейронной сети с помощью библиотеки caffe. В наши дни качество — это асинхронные неблокирующие вызовы, возможность параллельного исполнения нескольких заданий при наличии свободных процессорных ядер, мониторинг очередей заданий… Библиотека RQ позволяет реализовать все это в сжатые сроки без изучения тонны документации.



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







Постановка задачи



Входными данными является файл (например, картинка в формате JPEG). Для простоты считаем, что ее уже разместили в выделенную директорию. Выходными данными является строка в формате JSON. Для солидности будем пользоваться стандартными кодами результатов HTTP.



Веб-сервис будет реализовывать два HTTP-вызова (назовём это API):




  • /process/[имя файла] — обработать файл (предварительно загружаем входной файл в выделенную директорию, возвращаем идентификатор задания)

  • /result/[идентификатор задания] — получить результат (если результат не готов, возвращаем код 202 «Not ready», если результат готов — возвращаем json, если идентификатор задания не существует, возвращаем код 404 «Not found»)



Инсталлируем компоненты в Ubuntu



В качестве HTTP-сервера будем использовать Flask. Установка:



Если не установлен pip:



sudo apt-get install python-pip
sudo apt-get install --upgrade pip


Собственно, установка Flask:



sudo pip install flask


Теперь нужно установить Redis — хранилище данных и брокер сообщений:



wget http://download.redis.io/redis-stable.tar.gz
tar xvzf redis-stable.tar.gz
cd redis-stable
make


Установка библиотеки RQ (Redis Queue):



sudo pip install rq


Для автоматического запуска и конфигурации всех компонентов будем использовать Supervisor:



sudo apt-get install supervisor


Пишем наш сервис



Это легко в Flask. Создадим файл deep_service.py:



#Путь к директории, выделенной под хранение входных файлов
BASEDIR = '/home/sergey/verysecure'

#Импортируем служебные библиотеки
import argparse
import os
import json

#Импортируем только что установленные компоненты нашего сервиса
from flask import Flask
app = Flask(__name__)
from redis import Redis
from rq import Queue

#Импортируем функцию, реализующую наш вычислительный процесс, который будет выполняться асинхронно
#classify.py - модуль, поставляемый с библиотекой машинного обучения caffe
#Естественно, вместо него можно импортировать собственные разработки
from classify import main

#Подключаемся к базе данных Redis
q = Queue(connection=Redis(), default_timeout=3600)

#Реализуем первый вызов нашего API

@app.route('/process/')
def process(file_path):
full_path = os.path.join(BASEDIR, file_path) #входной файл лежит в директории BASEDIR
argv = {'input_file': full_path,
'gpu': True}
args = argparse.Namespace(**argv)
r = q.enqueue_call(main, args=(args,), result_ttl=86400)
return r.id

#В порядке обмена опытом: ограничим 4-мя цифрами после запятой вещественные числа,
#при сериализации в JSON из массива numpy
def decimal_default(obj):
if isinstance(obj, float32):
return round(float(obj), 4)
else:
raise TypeError()

#Реализуем второй вызов нашего API

@app.route('/result/')
def result(id):
try:
job = q.fetch_job(id)
if job.is_finished:
return json.dumps(job.result, ensure_ascii=False, default=decimal_default)
else:
return 'Not ready', 202
except:
return "Not found", 404

if __name__ == '__main__':
app.run()
#app.run(debug=False, host='0.0.0.0')


Запуск вручную — проверяем как работает



На этом этапе можно проверить, работает ли наш веб-сервис. Запускаем Redis:



redis-server


Запускаем один рабочий процесс (их можно запускать несколько, например по количеству процессорных ядер или по наличию нескольких видеокарт, если они требуются для обработки данных). Процесс лучше запускать из той директории, в которой будут запускаться вычислительные функции, в нашем случае это там, где лежит classif.py:



rq worker


Запускаем http-сервер:



python deep_service.py


Записываем в директорию для входных данных картинку cat.jpg и выполняем запрос к сервису:



wget 127.0.0.1/process/cat.jpg


В ответ получаем идентификатор задания. Копируем идентификатор и выполняем второй запрос к сервису:



wget 127.0.0.1/result/[идентификатор]


В ответ получаем строку JSON с весовыми коэффициентами принадлежности картинки категориям IMAGENET.

Теперь осталось сконфигурировать автоматический запуск компонентов нашего сервера.



Автозапуск



Настройка supervisor — возможно, самая сложная часть этого пути. Хороший обучающий материал по настройке supervisor тут.



Прежде всего нужно понять, что supervisor запускает каждый процесс в собственном окружении. В большинстве случаев сложных вычислений программа, их реализующая, зависит от ряда настроек, например путей. Эти настройки обычно хранятся в файле /home/usersname/.bashrc



Например, библиотека нейросетевых вычислений caffe и питоновские модули к ней потребовали дописать в этот файл следующие строки:



export PATH=/usr/local/cuda-7.5/bin:$PATH
export LD_LIBRARY_PATH=/usr/local/cuda-7.5/lib64:$LD_LIBRARY_PATH
PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig
export PKG_CONFIG_PATH
LD_LIBRARY_PATH=/home/username/caffe/build/lib:$LD_LIBRARY_PATH
export PYTHONPATH="${PYTHONPATH}:/home/username/caffe/python"


Скопируйте эти строки в буфер обмена!



В директории /usr/local/bin создайте файл deep_worker.sh



#!/bin/bash
cd /home/username/caffe/python

export PATH=/usr/local/cuda-7.5/bin:$PATH
export LD_LIBRARY_PATH=/usr/local/cuda-7.5/lib64:$LD_LIBRARY_PATH
PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig
export PKG_CONFIG_PATH
LD_LIBRARY_PATH=/home/username/caffe/build/lib:$LD_LIBRARY_PATH
export PYTHONPATH="${PYTHONPATH}:/home/username/caffe/python"

rq worker


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



В директории /usr/local/bin создайте файл deep_flask.sh



#!/bin/bash
cd /home/username/caffe/python

export PATH=/usr/local/cuda-7.5/bin:$PATH
export LD_LIBRARY_PATH=/usr/local/cuda-7.5/lib64:$LD_LIBRARY_PATH
PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig
export PKG_CONFIG_PATH
LD_LIBRARY_PATH=/home/username/caffe/build/lib:$LD_LIBRARY_PATH
export PYTHONPATH="${PYTHONPATH}:/home/username/caffe/python"

python deep_service.py


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



Немного системного администрирования:



sudo chmod +x /usr/local/bin/deep_flask.sh
sudo chmod +x /usr/local/bin/deep_worker.sh
mkdir /var/log/deepservice


В директории /etc/supervisor/conf.d создайте файл deepservice.conf:



[program:redis]
command=/usr/local/bin/redis-server
autostart=true
autorestart=true
stderr_logfile=/var/log/deepservice/redis.err.log
stdout_logfile=/var/log/deepservice/redis.out.log

[program:worker1]
command=/usr/local/bin/deep_worker.sh
autostart=true
autorestart=true
stderr_logfile=/var/log/deepservice/worker1.err.log
stdout_logfile=/var/log/deepservice/worker1.out.log
user=username
directory=/home/username/caffe/python

[program:flask]
command=/usr/local/bin/deep_flask.sh
autostart=true
autorestart=true
stderr_logfile=/var/log/deepservice/flask.err.log
stdout_logfile=/var/log/deepservice/flask.out.log
user=username
directory=/home/username/caffe/python


Наконец, запустим всю эту конструкцию:



sudo supervisorctl reread
sudo supervisorctl update


Всё!


Original source: habrahabr.ru.

https://habrahabr.ru/post/307140/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Сделай сам веб-сервис с асинхронными очередями и параллельным исполнением

Четверг, 04 Августа 2016 г. 21:03 (ссылка)

rq Каждый должен делать свою работу качественно и в срок. Допустим, вам нужно сделать веб-сервис классификации картинок на базе обученной нейронной сети с помощью библиотеки caffe. В наши дни качество — это асинхронные неблокирующие вызовы, возможность параллельного исполнения нескольких заданий при наличии свободных процессорных ядер, мониторинг очередей заданий… Библиотека RQ позволяет реализовать все это в сжатые сроки без изучения тонны документации.



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







Постановка задачи



Входными данными является файл (например, картинка в формате JPEG). Для простоты считаем, что ее уже разместили в выделенную директорию. Выходными данными является строка в формате JSON. Для солидности будем пользоваться стандартными кодами результатов HTTP.



Веб-сервис будет реализовывать два HTTP-вызова (назовём это API):




  • /process/<имя файла> — обработать файл (предварительно загружаем входной файл в выделенную директорию, возвращаем идентификатор задания)

  • /result/<идентификатор задания> — получить результат (если результат не готов, возвращаем код 202 «Not ready», если результат готов — возвращаем json, если идентификатор задания не существует, возвращаем код 404 «Not found»)



Инсталлируем компоненты в Ubuntu



В качестве HTTP-сервера будем использовать Flask. Установка:



Если не установлен pip:



sudo apt-get install python-pip
sudo apt-get install --upgrade pip


Собственно, установка Flask:



sudo pip install flask


Теперь нужно установить Redis — хранилище данных и брокер сообщений:



wget http://download.redis.io/redis-stable.tar.gz
tar xvzf redis-stable.tar.gz
cd redis-stable
make


Установка библиотеки RQ (Redis Queue):



sudo pip install rq


Для автоматического запуска и конфигурации всех компонентов будем использовать Supervisor:



sudo apt-get install supervisor


Пишем наш сервис



Это легко в Flask. Создадим файл deep_service.py:



#Путь к директории, выделенной под хранение входных файлов
BASEDIR = '/home/sergey/verysecure'

#Импортируем служебные библиотеки
import argparse
import os
import json

#Импортируем только что установленные компоненты нашего сервиса
from flask import Flask
app = Flask(__name__)
from redis import Redis
from rq import Queue

#Импортируем функцию, реализующую наш вычислительный процесс, который будет выполняться асинхронно
#classify.py - модуль, поставляемый с библиотекой машинного обучения caffe
#Естественно, вместо него можно импортировать собственные разработки
from classify import main

#Подключаемся к базе данных Redis
q = Queue(connection=Redis(), default_timeout=3600)

#Реализуем первый вызов нашего API

@app.route('/process/')
def process(file_path):
full_path = os.path.join(BASEDIR, file_path) #входной файл лежит в директории BASEDIR
argv = {'input_file': full_path,
'gpu': True}
args = argparse.Namespace(**argv)
r = q.enqueue_call(main, args=(args,), result_ttl=86400)
return r.id

#В порядке обмена опытом: ограничим 4-мя цифрами после запятой вещественные числа,
#при сериализации в JSON из массива numpy
def decimal_default(obj):
if isinstance(obj, float32):
return round(float(obj), 4)
else:
raise TypeError()

#Реализуем второй вызов нашего API

@app.route('/result/')
def result(id):
try:
job = q.fetch_job(id)
if job.is_finished:
return json.dumps(job.result, ensure_ascii=False, default=decimal_default)
else:
return 'Not ready', 202
except:
return "Not found", 404

if __name__ == '__main__':
app.run()
#app.run(debug=False, host='0.0.0.0')


Запуск вручную — проверяем как работает



На этом этапе можно проверить, работает ли наш веб-сервис. Запускаем Redis:



redis-server


Запускаем один рабочий процесс (их можно запускать несколько, например по количеству процессорных ядер или по наличию нескольких видеокарт, если они требуются для обработки данных). Процесс лучше запускать из той директории, в которой будут запускаться вычислительные функции, в нашем случае это там, где лежит classif.py:



rq worker


Запускаем http-сервер:



python deep_service.py


Записываем в директорию для входных данных картинку cat.jpg и выполняем запрос к сервису:



wget 127.0.0.1/process/cat.jpg


В ответ получаем идентификатор задания. Копируем идентификатор и выполняем второй запрос к сервису:



wget 127.0.0.1/result/<идентификатор>


В ответ получаем строку JSON с весовыми коэффициентами принадлежности картинки категориям IMAGENET.

Теперь осталось сконфигурировать автоматический запуск компонентов нашего сервера.



Автозапуск



Настройка supervisor — возможно, самая сложная часть этого пути. Хороший обучающий материал по настройке supervisor тут.



Прежде всего нужно понять, что supervisor запускает каждый процесс в собственном окружении. В большинстве случаев сложных вычислений программа, их реализующая, зависит от ряда настроек, например путей. Эти настройки обычно хранятся в файле /home/.bashrc

Например, библиотека нейросетевых вычислений caffe и питоновские модули к ней потребовали дописать в этот файл следующие строки:



export PATH=/usr/local/cuda-7.5/bin:$PATH
export LD_LIBRARY_PATH=/usr/local/cuda-7.5/lib64:$LD_LIBRARY_PATH
PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig
export PKG_CONFIG_PATH
LD_LIBRARY_PATH=/home/username/caffe/build/lib:$LD_LIBRARY_PATH
export PYTHONPATH="${PYTHONPATH}:/home/username/caffe/python"


Скопируйте эти строки в буфер обмена!



В директории /usr/local/bin создайте файл deep_worker.sh



#!/bin/bash
cd /home/username/caffe/python

export PATH=/usr/local/cuda-7.5/bin:$PATH
export LD_LIBRARY_PATH=/usr/local/cuda-7.5/lib64:$LD_LIBRARY_PATH
PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig
export PKG_CONFIG_PATH
LD_LIBRARY_PATH=/home/username/caffe/build/lib:$LD_LIBRARY_PATH
export PYTHONPATH="${PYTHONPATH}:/home/username/caffe/python"

rq worker


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



В директории /usr/local/bin создайте файл deep_flask.sh



#!/bin/bash
cd /home/username/caffe/python

export PATH=/usr/local/cuda-7.5/bin:$PATH
export LD_LIBRARY_PATH=/usr/local/cuda-7.5/lib64:$LD_LIBRARY_PATH
PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig
export PKG_CONFIG_PATH
LD_LIBRARY_PATH=/home/username/caffe/build/lib:$LD_LIBRARY_PATH
export PYTHONPATH="${PYTHONPATH}:/home/username/caffe/python"

python deep_service.py


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



Немного системного администрирования:



sudo chmod +x /usr/local/bin/deep_flask.sh
sudo chmod +x /usr/local/bin/deep_worker.sh
mkdir /var/log/deepservice


В директории /etc/supervisor/conf.d создайте файл deepservice.conf:



[program:redis]
command=/usr/local/bin/redis-server
autostart=true
autorestart=true
stderr_logfile=/var/log/deepservice/redis.err.log
stdout_logfile=/var/log/deepservice/redis.out.log

[program:worker1]
command=/usr/local/bin/deep_worker.sh
autostart=true
autorestart=true
stderr_logfile=/var/log/deepservice/worker1.err.log
stdout_logfile=/var/log/deepservice/worker1.out.log
user=username
directory=/home/username/caffe/python

[program:flask]
command=/usr/local/bin/deep_flask.sh
autostart=true
autorestart=true
stderr_logfile=/var/log/deepservice/flask.err.log
stdout_logfile=/var/log/deepservice/flask.out.log
user=username
directory=/home/username/caffe/python


Наконец, запустим всю эту конструкцию:



sudo supervisorctl reread
sudo supervisorctl update


Всё!


Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/307140/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
SoftLabirint

Xubuntu 16.04 amd64 Theme Win7 v.2.1.3 (2016) ML/RUS » SoftLabirint.Ru: Скачать бесплатно и без регистрации - Самые Популярные Новости Интернета

Суббота, 23 Июля 2016 г. 12:01 (ссылка)
softlabirint.ru/soft/system...mlrus.html


Xubuntu 16.04 amd64 Theme Win7 v.2.1.3 (2016) ML/RUS

Представляю версию сборки с оформлением под Windows7 - Xubuntu 16.04 x64 theme win7 v.2.1.3. Сборка сделана программой Remastersys и основана на Xubuntu 16.04 amd64. Интерфейс сборки максимально приближен к Windows 7. Как показывают отзывы облегчает переход с Windows на Linux, новая версия сборки ещё больше похожа на Windows 7! Более подробнее о сборке и об изменениях в этой версии читайте ниже.



Особенность сборки:



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

• Таким образом переход с Windows на Linux будет очень простым и лёгким.



В частности, в предлагаемый образ уже включены:

• Всевозможные кодеки и плеер для просмотра видео;

• Разнообразные шрифты, в том числе и редкие старославянские;

• Два архиватора: Xarchiver 0.5.4 и Archive Manager 3.16.5;

• Два браузера для интернет сёрфинга;

• Средства по просмотру и редактированию фотографий;

• Всевозможные драйвера для принтеров и прочих переферийных устройств;

• И многое, многое, другое...



• Таким образом, установив данную систему, пользователь сразу получит готовую к работе машину. Причём установка занимает всего лишь 15-ть минут!



Установленные приложения:



Графика:

• GIMP 2.8.16 - Редактор изображений

• Incskape 0.91- векторный редактор

• LibreOffice 5.1.4.2 Draw - программа работы с векторными графическими изображениями

• Simple Scan - простое сканирование

• Evince - просмотр PDF и не только

• gThumb - просмотр изображений (поддержка gif-анимации)

• GPicView 0.2.5 - программа просмотра изображений



Игры:

• Тетрис

• Шахматы

• Шашки



Инструменты:

• Mousepad - Текстовый редактор

• GtkHash 0.7.0- программа вычисления контрольной суммы

• Midnight Commander - файловый менеджер

• Onboard - экранная клавиатура

• Archive Manager 3.16.5 - архиватор

• Xarchiver 0.5.4 - архиватор

• Xfburn - программа для записи дисков

• xfce4-notes - Заметки

• Запись образа диска Unetbootin

• Запись образа на USB-накопитель

• Запустить приложение

• gnome-calculator - Калькулятор

• file-roller - Менеджер архивов

• Orange - Мировое время

• Поиск приложений

• Catfish 1.4.2 - Поиск файлов

• Снимок экрана

• Таблица символов

• Thunar 1.6.10 - Файловый менеджер

• Форматирование USB-накопителя

• xfce4-terminal - Эмулятор терминала



Интернет:

• Firefox 47.0 - веб-браузер

• Google-Chrome 51.0.2704.106 - веб-браузер

• Skype 4.3

• Transmission 2.84 - торрент-клиент

• Pidgin - клиент обмена мгновенными сообщениями (ICQ и т.д)

• Thunderbird 38.8.0 - почтовый клиент



Мультимедиа:

• Audacious - проигрыватель музыки

• VLC 2.2.2 - мултимедиаплеер

• Регулятор громкости PulseAudio



Настройки:

• DocX - панель приложений

• Dockbarx Preference - настройка панели DocX

• Gparted - разметка HDD

• OpenjDK Java 8 Policy Tool

• Theme Configuration - настройка темы

• Xfce Panel Switch - запись/восстановление конфигурации панели

• Адаптеры Bluetooth

• Внешний вид

• Дата и время

• Диски

• Диспетчер окон

• Диспетчер окон (дополнительно)

• Дисплей

• Дополнительные драйверы

• Клавиатура

• Менеджер Bluetooth

• Менеджер пакетов Synaptic

• Менеджер питания

• Мышь и тачпад

• Настройки LightDM+Greeter

• Настройки Onboard

• Настройки Orange

• Обновление приложений

• Обо мне

• Оповещения

• Панель

• Пользователи и группы

• Предпочитаемые приложения

• Принтеры

• Программы и обновления

• Рабочие места

• Рабочий стол

• Редактор меню

• Редактор настроек

• Редактор типов MIME

• Сброс настроек рабочего стола

• Сеанс и запуск

• Сетевые соединения

• Сеть

• Создание загрузочного диска

• Специальные возможности

• Съёмные устройства и носители

• Язык системы



Офис:

• LibreOffice 5.1.4.2 Writer - текстовый процессор (аналог Word)

• LibreOffice 5.1.4.2 Calc - табличный процессор (аналог Exel)

• LibreOffice 5.1.4.2 Impress - программа работы с презентациями

• LibreOffice 5.1.4.2 Base - программа работы с базами данных

• LibreOffice 5.1.4.2 Math - редактор формул

• Календарь Orage

• Мировое время Orage

• Evince - просмотр документов

• Чтение электронных книг



Система:

• BleachBit - очистка системы

• Gigolo - Простой интерфейс для подключения локальных и удаленных файловых систем

• Htop - системный монитор (раскрашенный top)

• Remastersys - создание копии системы

• Hardinfo - System Profiler and Benchmark

• inxi - консольная утилита для сбора информации о системе и "железе"

• baobab - Анализатор использования дисков

• GDebi - Программа установки пакетов

• gconf-editor - Редактор конфигурации Gconf

• gnome-system-monitor - Системный монитор

• Центр приложений Ubuntu 15.12



Горячие клавиши:



• Alt+Esc - контекстное меню, то же как клик по правой клавиши мыши

• Alt+F1 - меню приложений (Пуск)

• Alt+F2 - выполнить программу

• Alt+F3 - поиск приложений со списком приложений

• Alt+F4 - закрыть окно

• Alt+F6 - развернуть окно по вертикали

• Alt+F7 - развернуть окно по горизонтали

• Alt+F9 - свернуть окно

• Win+F - файловый менеджер

• Win+M - почтовая программа

• Win+T - терминал

• Ctrl+Alt+T - терминал

• Win+W - веб-браузер

• Win+P - настройка монитора

• Win+L - заблокировать экран

• Win+CL - калькулятор

• Ctrl+Alt+Delete - заблокировать экран

• Print - скриншот всего экрана

• Alt+Print - скриншот активного окна

• Ctrl+Alt+Esc - убить зависшее приложение/окно

• Alt+Shift - переключение раскладки Рус/Англ



Дополнительная информация:



• Образ гибридный можно устанавливать как на флешку, так и на DVD.

• Во время установки НЕ СТАВИТЬ ГАЛОЧКИ на против "Загрузить обновления...." и "Установить стороннее программное...."

• Регулировка прозрачности в меню приложений Пуск (Whiskermenu): правой клавишей мыши на меню => Свойства => Вид => ползунок внизу.

• Включение/выключение значка сети/батареи в трее: Пуск => Настройки => Менеджер питания => посавить/убрать галочку "Отображать значок в системном лотке"



Основные изменения в v 2.1.3 от 2016.07.20:



По отношению к выпуску v 2.1 от 2016.07.13:

• В Firefox по умолчанию отключена плавная прокрутка, создающая тиринг во время прокрутки сайтов.

• восстановлены дополнительные темы для Libreoffice.

• восстановлена по умолчанию русская раскладка.



По отношению к выпуску v 2.1.1 от 2016.07.14:

• Установлена программа просмотра изображений gThumb, которая корректно показывает gif-анимацию.

• Изменен словарь орфографии в Libreoffice для русского языка. Теперь не подчеркивает букву "Ё" в словах.

• Исправлена ошибка Xubuntu "Не работает часть горячих клавиш при выборе русской раскладки по умолчанию". Теперь горячие клавиши работают и при русской раскладке и при английской.



По отношению к выпуску v 2.1.2 от 2016.07.16:

• Установлены пакеты работы с сетью Samba.

• Исправлена ошибка пакета настроек Samba. Окно настроек не запускалось.

• Обновление под текущую дату.

• Установлена читалка книг fb2 и т.д.



Запись образа на флешку:



Для записи образа на флешку для Ubuntu 14.04 и выше рекомендую:

- 1. Программу с графическим интерфейсом Rosa Image Writer. Пакет для ubuntu rosaimagewriter_2.6.0_amd64- 6,4 Мб Ссылка

- 2. Программу usb-creator-gtk в Ubuntu 16.04. По-русски в меню приложений название "Создание загрузочного диска". Есть в дистрибутивах Matuntu-X32-M114, Matuntu-X64-M112, Matuntu-X32-M112, Ubuntu 16.04, Xubuntu 16.04, Lubuntu 16.04.



Для тех, кто доверяет больше терминалу:

Код:

sudo dd oflag=direct if='/home/Путь до образа/xubuntu_16.04-theme_win7-amd64.iso' of=/dev/sdc bs=1M;sync



где sdc - Flash USB. У каждого своё имя. Для определения воспользуетесь кодом:

sudo fdisk -l

 



Xubuntu 16.04 amd64 Theme Win7 v.2.1.3 (2016) ML/RUS Xubuntu 16.04 amd64 Theme Win7 v.2.1.3 (2016) ML/RUS Xubuntu 16.04 amd64 Theme Win7 v.2.1.3 (2016) ML/RUS



Xubuntu 16.04 amd64 Theme Win7 v.2.1.3 (2016) ML/RUS Xubuntu 16.04 amd64 Theme Win7 v.2.1.3 (2016) ML/RUS Xubuntu 16.04 amd64 Theme Win7 v.2.1.3 (2016) ML/RUS



Xubuntu 16.04 amd64 Theme Win7 v.2.1.3 (2016) ML/RUS Xubuntu 16.04 amd64 Theme Win7 v.2.1.3 (2016) ML/RUS Xubuntu 16.04 amd64 Theme Win7 v.2.1.3 (2016) ML/RUS






Системные требования:

• ОЗУ - 1 Гб

• Процессор - 1 Ггц

• Свободное место на жестком диске - 10 Гб

• Архитектура: amd64/x64



Контрольные суммы:

CRC32: 4B4A494B

MD4: 4722278D228683DD6DF6DEE2641F66F5

MD5: 3B2F2AFEF81A10CF6F58AC8D63AC4AA4

SHA-1: 5CB34202491420FC0929A03B8CB0B3B33C48BB7F



Информация о софте:

Дата выпуска: 20 июля 2016 года

Название: Xubuntu 16.04 amd64 Theme Win7 v.2.1.3

Версия: Theme Win7 v.2.1.3

Разработчик/автор сборки: Xubuntu / BaaTLT

Архитектура: amd64/x64

Язык интерфейса: Русский, Английский и другие.

Таблэтка: Не требуется

Размер: 1.34 GB



Скачать: Xubuntu 16.04 amd64 Theme Win7 v.2.1.3 (2016) ML/RUS >>>



 



Подписка на новости сайта…

http://feeds.feedburner.com/Soft-Labirint

http://feeds.feedburner.com/Soft-Labirint?format=xml

https://feedburner.google.com/fb/a/mailverify?uri=Soft-Labirint

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Security Week 29: утечка на форуме Ubuntu, прокси-уязвимость в PHP, Go и Python, 276 заплаток Oracle

Пятница, 22 Июля 2016 г. 12:08 (ссылка)

14 июля в Canonical узнали, что кто-то владеет (возможно и пытается продать) базой логинов и паролей двух миллионов пользователей форумов Ubuntu. Расследование быстро показало, что информация похожа на правду, после чего форумы были просто временно отключены. Надо сказать, это очень правильный ход, хотя в другой компании и в другой ситуации на него могли бы и не решиться: как же так, ведь все узнают, что у нас проблемы с безопасностью, а так может никого и не взломают. Собственно, мы все это знаем благодаря подробному описанию инцидента на сайте разработчиков Ubuntu, так что вроде бы все закончилось хорошо.



Или нет? Утечка (подробное описание событий в этой новости) началась со эксплуатации уязвимости в плагине Forumrunner, установленного на vBulletin, при помощи SQL-инъекции. Атака стала возможной из-за использования устаревшей версии плагина. Инъекция открыла доступ на чтение ко всей базе данных форума, но, как утверждает Джейн Сильбер, директор Canonical, взломщику удалось скачать только часть пользовательской базы с «устаревшими» паролями, которые к тому же были захешированы с солью.



В том, что актуальные пароли не утекли, в Canonical уверены. Также там предполагают, что взломщику не удалось развить атаку и получить доступ к чему-то еще. При всем образцовом поведении компании данном случае, нельзя не отметить эту общую неуверенность. Иными словами — убедились там, где это позволяли сделать логи, а дальше — ну кто ж его знает. Вроде бы все хорошо, тем более, что прежде чем поднимать форум, его чуть ли не переустановили с нуля. История с хэппи-эндом, но пожалуй с чем нужно бороться в сфере ИБ, так именно с подобной неуверенностью. Ну и узнавать о взломе хочется не от доброжелателей, а самостоятельно, и сразу, но тут уж как повезет.



HTTPoxy: уязвимость в реализации интерфейса CGI затрагивает большое количество сетевого софта

Новость.



У нас еще одна уязвимость с привлекательным брендом и даже логотипом, но кажется мы к такому уже привыкли. Тем более, что уязвимость заслуживает внимания широченным охватом подверженного софта. Как правило такие универсальные дыры обнаруживаются в многократно используемых библиотеках: можно вспомнить прошлогодний пример с Apache Commons Collections. HTTPoxy (сайт уязвимости) круче по радиусу поражения, так как это уязвимость не в софте, а в реализации интерфейса CGI. Это, например, стандартные библиотеки для языков программирования PHP, Go и Python, и соответственно, реализованные на них веб-приложения и скрипты. Таких существует огромное количество, как готовых, так и самописных, и лучшее решение — заблокировать возможность эксплуатации уязвимости для всего сразу, внеся изменения в конфиги Apache, NGINX, lighttpd и прочего софта.







А суть уязвимости довольно простая. В ситуации, когда требуется задать рабочему окружению в Linux прокси-сервер для доступа к сети, для этого часто используется переменная HTTP_PROXY. В некоторых реализациях интерфейса CGI описывается заголовок Proxy, который может быть передан серверу во время обмена данными, и на стороне сервера эта информация сохраняется в переменную HTTP_PROXY. Собственно все, проблема как раз конфликте имен, и это позволяет во многих ситуациях направлять данные через прокси-сервер, который был задан снаружи. Кем угодно, что ведет к атаке типа Man in the middle. Что интересно, спецификации на переменную нигде толком (например в документе RFC 3875) не прописаны. Решение очевидно: нужно заблокировать передачу такого заголовка. Но это для начала, а вообще надо править реализацию обработки данной переменной везде, где только можно.



Fun fact на закуску: уязвимости 15 лет. Впервые ее обнаружили и пофиксили в библиотеке libwww_perl в марте 2001 года. В апреле того же года исправили аналогичную проблему в утилите curl. В 2012 году избежали уязвимой реализации стандарта разработчики Ruby (и написали об этом в документации). В 13-м и 15-м годах, по данным исследователей HTTPoxy, компании VendHQ, проблема несколько раз всплывала на форумах и в почтовых рассылках. В одном случае топикстартер был настолько поражен банальностью беды, что добавил «наверняка я здесь что-то упустил». Но нет. Хорошая история про особое направление в безопасности: правильный сбор, обработка и интерпретирование доступной всем (годами!) информации.



Oracle закрывает 276 уязвимостей в своих продуктах

Новость.



В январе этого года Oracle выпустила рекордный кумулятивный патч, закрыв одним махом 248 уязвимостей. В июле рекорд побит с запасом: ежемесячный security-апдейт закрывает 276 уязвимостей в 84 продуктах. Зная, как сложно тестировать сразу много продуктов в разных сценариях, эту новость нужно безусловно оценить как в положительную, хотя в конце года вендор наверняка попадет в очередной некорректный список самых небезопасных разработчиков. Впрочем, выявленные проблемы от этого проще не становятся: из 276 уязвимостей 159 могут быть эксплуатированы удаленно, 19 (в девяти продуктах) оценены в 9,8 балла по шкале CVSS.





Впрочем, в Java, некогда самой часто атакуемой программе, а ныне уступившей сомнительное лидерство Adobe Flash, обнаружено и закрыто всего 13 уязвимостей, из них 9 с возможностью удаленной эксплуатации. Это третья на сегодня новость с эффектом «ложечки нашлись, осадочек остался». Oracle, конечно, молодцы. Но не думаю, что администраторы корпоративного софта Oracle будут сильно рады необходимости все бросить и накатывать столь гигантские патчи. А ведь придется.



Что еще произошло:

Развивается тема поведенческого анализа и блокирования криптолокеров по характеру изменения шифруемых данных. Исследователи из двух американских университетов разработали алгоритм, который задетектировал все из 500 (не так уж много для серьезного теста) сэмплов троянов-вымогателей. Но, увы, с потерей файлов, видимо, по причине того, что алгоритм распознавал характерные изменения не сразу. В каждом из тестов трояны что-то, да успевали зашифровать. В зависимости от ситуации терялись от 3 до 29 файлов.



Закрыта уязвимость в сетевых устройствах Juniper.



В дарквебе нашли супердешевый троян-вымогатель, всего 39 долларов. С каждой жертвы требуют около 600 долларов и, что необычно, по истечении определенного времени начинают потихоньку удаляться зашифрованные файлы. Криминальный бизнес класса эконом.



Древности:

«V-1260»



Нерезидентный безобидный вирус-«призрак». Поражает .COM-файлы по алгоритму вирусов «Vienna». Зашифрован, при этом использует два интересных алгоритма. Первый алгоритм реализует свойство «призрака», благодаря чему два штамма этого вируса с большой вероятностью не будут совпадать ни на одном байте. Основное тело вируса шифруется в зависимости от таймера по 16777216 вариантам, а расшифровщик выбирается из более чем 3,000,000,000,000,000,000,000 вариантов (длина расшифровщика — 39 байт). Второй алгоритм достаточно успешно мешает трассировке вируса — используется динамическое рас/зашифрование кодов вируса при помощи int 1 и int 3.



Цитата по книге «Компьютерные вирусы в MS-DOS» Евгения Касперского. 1992 год. Страницa 90.



Disclaimer: Данная колонка отражает лишь частное мнение ее автора. Оно может совпадать с позицией компании «Лаборатория Касперского», а может и не совпадать. Тут уж как повезет.
Original source: habrahabr.ru.

https://habrahabr.ru/post/306190/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Из песочницы] Проброс USB-принтера в контейнер LXD

Среда, 20 Июля 2016 г. 21:30 (ссылка)

Хочу поделиться найденным решением по пробросу принтера HP LaserJet 1000 в контейнер, созданый при помощи LXD.



Немного предыстории



Есть домашний сервер на базе старого ноутбука Acer Aspire 5520G, который используется для всяких экспериментов. На нем была установлена Ubuntu 14.04 и создано несколько контейнеров при помощи LXC, один из которых использовался как принт-сервер.



Проброс принтера был осуществлен путем добавления в файл конфигурации гостя следующих строк:



lxc.cgroup.devices.allow = c 189:* rwm
lxc.mount.entry = /dev/bus/usb/003 dev/bus/usb/003 none bind,optional,create=dir
lxc.mount.entry = /dev/usb/lp0 dev/usb/lp0 none bind,optional,create=file


Все работало отлично, но захотелось обновиться до Ubuntu 16.04 и попробовать LXD.



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



Приступаем к пробросу



Итак, Ubuntu 16.04+LXD установлены, контейнер на базе той же Ubuntu 16.04 создан, приступаем к пробросу.

Для начала выясним, куда подключен принтер на хосте:



root@aspire-5520g:~# lsusb
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 004: ID 0bda:8197 Realtek Semiconductor Corp. RTL8187B Wireless Adapter
Bus 001 Device 003: ID 5986:0102 Acer, Inc Crystal Eye Webcam
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 03f0:0517 Hewlett-Packard LaserJet 1000
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub


Принтер подключен на Bus 003 Device 002, другими словами, ему соответствует unix-char файл /dev/bus/usb/003/002

Выясним, кто является его владельцем и с какими правами:



root@aspire-5520g:~# ls -l /dev/bus/usb/003/002
crw-rw-r-- 1 root lp 189, 257 Июл 15 16:02 /dev/bus/usb/003/002


Файл принадлежит пользователю root и группе lp, права на файл 0664. Данная информация пригодится нам в будущем.

Выясним, какой числовой идентификатор у группы lp:



root@aspire-5520g:~# cat /etc/group | egrep lp
lp:x:7:


Группа lp имеет числовой идентификатор 7.

Теперь выясним, кто является владельцем и с какими правами, файла lp0:



root@aspire-5520g:~# ls -l /dev/usb/lp0
crw-rw---- 1 root lp 180, 0 Июл 15 16:02 /dev/usb/lp0


Файл принадлежит пользователю root и группе lp с правами 0660.



Пробросим принтер в контейнер



На самом деле, все оказалось не сильно и сложно. В моем случае контейнер называется print, а устройство я решил назвать lj1000. Для проброса нужно выполнить несколько простых манипуляций:



root@aspire-5520g:~# lxc config device add print lj1000 unix-char path=/dev/bus/usb/003/002 mode=0664 gid=7
Устройство lj1000 добавляется к print
root@aspire-5520g:~# lxc config device add print lp0 unix-char path=/dev/usb/lp0 gid=7
Устройство lp0 добавляется к print


Первая команда осуществляет проброс unix-char устройства с правами 0664 и принадлежащего группе 7 (lp), вторая команда осуществляет проброс устройства lp0 с правами по умолчанию (0660) и принадлежащего той же группе 7.



Вот и все. Проброс устройства осуществлен. Далее необходимо установить принтер в контейнере:



root@aspire-5520g:~# lxc exec print -- apt update && apt upgrade -y && apt install hplip -y
root@aspire-5520g:~# lxc exec print -- hp-setup -i


Здесь просто следуем инструкции установщика. Результатом должна стать распечатанная пробная страница печати.



Вот и все, вот таким способом пробрасывается принтер внутрь контейнера созданного при помощи LXD. Думаю, что любое другое устройство пробрасывается подобным способом.



Всем спасибо за внимание.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/306074/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Как подключиться к серверу по RDP c Windows, Mac OS, iPhone, iPad, Android, Ubuntu или Debian (Linux ОС)

Четверг, 14 Июля 2016 г. 15:35 (ссылка)

Все сервера, создаваемые Windows сервера на UltraVDS по умолчанию сразу доступны для подключения по стандартному протоколу RDP (Remote Desktop Protocol) – обычное «Подключение к удалённому рабочему столу» в русскоязычных редакциях Windows.



В данной статье будет описано как подключиться к только что созданному виртуальному серверу на UltraVDS с различных устройств (операционных систем). Если вам требуется какой-либо другой способ подключения (RAdmin, TeamViewer и т.д.) после успешного подключения по RDP, вы сможете его настроить так же, как и любое другое программное обеспечение.



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







Подключение к виртуальному серверу с десктопной версии Windows (версии XP, 7, 8, 8.1, 10)



При использовании стандартной операционной системы Windows для подключения к серверу необходимо открыть следующий путь:

Пуск -> Программы -> Стандартные -> Подключение к удалённому рабочему столу
Либо просто нажмите комбинацию клавиш Win+R и в открывшемся окне наберите mstsc







В открывшемся окне необходимо указать IP-адрес созданного для вас VDS сервера. Если вы заказали сервер с несколькими IP-адресами, то можете использовать любой из них для подключения.

IP-адрес вашего сервера указан возле вашего сервера в личном кабинете в разделе «Мои сервера».







После ввода IP-адреса сервера нажмите кнопку «Подключить» и вы увидите окно с полями авторизации. Здесь нужно выходить под новым пользователем:







При создании каждого нового сервера система в автоматическом режиме генерирует случайный пароль пользователя Administrator. Этот пароль отображается также в личном кабинете возле вашего сервера:







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



Подключение к удалённому рабочему столу – очень удобная вещь, с её помощью можно переносить файлы с компьютера на сервер и обратно просто копируя и вставляя их, тоже самое с текстом в буфере обмена. Также можно с вашего компьютера, передать на сервер любые включенные в него USB-устройства и сетевые принтеры/сканнеры. Для этого при первом подключении к серверу выберите «Показать параметры» в левом нижнем углу.







В открывшемся окне перейдите на вкладку «Локальные ресурсы» и выберите требуемые вам параметры:







При подключении к серверу вы можете увидеть информацию о недоверенном сертификате безопасности. Причина этого заключается в том, что сервер шифрует передаваемые данные SSL-сертификатом, который он сгенерировал сам в автоматическом режиме. Данное уведомление не является свидетельством о проблеме с безопасностью, а только предупреждает вас о том, что соединение зашифровано с использованием сертификата, который не был выдан авторизованным центром.







Отметьте здесь галочкой поле «Больше не выводить запрос о подключениях к этому компьютеру» и нажмите «Да».








Подключение к VDS серверу с Mac OS



Для Mac OS компания Microsoft выпускает официальный RDP-клиент, который стабильно работает при подключении к любым версиям ОС Windows.

Скачать его можно с iTunes здесь: https://itunes.apple.com/gb/app/id715768417



Интерфейс программы простой и интуитивно понятный. Перед началом работы необходимо настроить параметры подключения. Для этого создаём новое:





В окне настроек соединения указываем произвольное название, например, «Сервер на UltraVDS», IP-адрес созданного сервера и данные для авторизации (логин Administrator и назначенный серверу в автоматическом режиме пароль) – эти данные отображаются в вашем личном кабинете.



После выхода из окна настроек всё сохранится автоматически и в списке подключений вы увидите новое созданное:







Кликните на него дважды мышкой, и вы подключитесь к вашему серверу.

При подключении к серверу вы можете увидеть информацию о недоверенном сертификате безопасности. Почему возникает такое уведомление и что оно означает этого описано выше.











Добавив самоподписанный сертификат вашего сервера в доверенные или просто приняв его единожды, вы увидите рабочий стол Windows вашего виртуального сервера.












Подключение к VPS серверу со смартфона или планшета на iOS (с iPhone или iPad)



Перед подключением к серверу необходимо скачать с Apple Store приложение Microsoft Remote Desktop (это официальный RDP-клиент от Microsoft):

https://itunes.apple.com/ru/app/id714464092







Запустите приложение после установки и нажмите на добавление нового подключения:







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







При подключении к серверу вы можете увидеть информацию о недоверенном сертификате безопасности. Причина этого описана выше.

Выберите «Больше не спрашивать для этого ПК» и нажмите «Принять».





Если авторизационные данные и IP-адрес сервера были введены без ошибок, вы успешно подключитесь к вашему серверу.












Подключение к виртуальному серверу со смартфона или планшета на Android



Прежде всего вам необходимо скачать с Google Play и установить программу Microsoft Remote Desktop (это официальный RDP-клиент от Microsoft):

https://play.google.com/store/apps/details?id=com.microsoft.rdc.android&hl=ru







Запустите приложение после установки и нажмите на добавление нового подключения







В окне создания нового подключения необходимо указать IP-адрес созданного VDS сервера и данные для авторизации (где их взять описано чуть выше).







При подключении к серверу вы можете увидеть информацию о недоверенном сертификате безопасности. Причина этого описана выше.

Выберите галочкой «Don’t ask me again for connections to this computer» и нажмите «Connect».







Если авторизационные данные и IP-адрес сервера были введены без ошибок, вы успешно подключитесь к вашему серверу.












Подключение к серверу по RDP из Ubuntu



RDP – это закрытый протокол компании Microsoft, она же в свою очередь не выпускает RDP-клиентов для операционных систем семейства Linux.

Однако всё же есть различные рабочие версии от тех или иных производителей.

Мы рекомендуем использовать клиент Remmina



Для пользователей Ubuntu есть специальный репозиторий с различными пакетами приложение, в числе которых есть Remmina и RDP.

Установка производится в 3 простые команды, которые вводятся по очереди в Терминале:



Для установки пакета Remmina
sudo apt-add-repository ppa:remmina-ppa-team/remmina-next


Устанавливаем обновления
sudo apt-get update


Устанавливаем плагин протокола RDP
sudo apt-get install remmina remmina-plugin-rdp libfreerdp-plugins-standard


Если вы до этого уже устанавливали или запускали существующую версию Remmina, то её необходимо перезапустить. Сделать это можно перехагружкой компьютера, либо выполнением следующей команды в том же терминале:

sudo killall remmina
Если процесс запущен не был, то появится сообщение об ошибке: процесс не найден, что тоже нас устраивает.



Открываем меню поиска и находим там свежеустановленный пакет Remmina







Нажимаем на добавление нового подключения и заполняем поля данными для подключения и авторизации к вашему серверу (где находятся данные для подключения к именно вашему серверу описано выше):







После сохранения ваш сервер будет всегда доступен в списке подключений для быстрого доступа. Для подключения к нему дважды кликните мышкой по строчке вашего сервера.







При первом подключении к серверу вы можете увидеть информацию о недоверенном сертификате безопасности. Причина этого описана выше. Просто нажмите «ОК» и вы увидите рабочий стол вашего сервера.
















Подключение к удаленному рабочему столу (RDP) из Debian



RDP (подключение к удалённому рабочему столу) – это закрытый протокол компании Microsoft, они же в свою очередь не выпускает RDP-клиентов для операционных систем семейства Linux.

Но всё же есть различные рабочие версии от тех или иных компаний-разработчиков.

Мы рекомендуем использовать RDP-клиент Remmina



Для установки приложения Remmina и плагина RDP к нему необходимо открыть менеджер установки пакетов:







Здесь в строке поиска вводим «Remmina» и выделяем все результаты для установки:







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

Находим его в главном меню и запускаем:







Перед началом работы необходимо создать новое подключения для удобства в дальнейшем:







В открывшемся окне необходимо задать корректные параметры RDP подключения и данные для авторизации (указаны в личном кабинете UltraVDS):







После сохранения ваш сервер будет всегда доступен в списке подключений для быстрого доступа. Для подключения к нему просто дважды кликните мышкой по строчке вашего сервера.







При первом подключении к серверу вы можете увидеть информацию о недоверенном сертификате безопасности. Причина этого описана чуть выше. Просто нажмите «ОК» или «Принять» и вы увидите рабочий стол вашего сервера.












Что делать если при попытке подключения с ОС семейства Linux сразу возникает ошибка?



По умолчанию на всех создаваемых на UltraVDS серверах разрешено только подключение по RDP с компьютеров (клиентов), на которых работает проверка подлинности на уровне сети. Некоторые RDP клиенты под Linux эту проверку подлинности могут не поддерживать. В таком случае перед подключением к серверу по RDP необходимо это требование отменить на самом VDS сервере.



На UltraVDS реализована возможность аварийного доступа к серверу в случае если вы не можете к нему подключиться, именно ею мы и воспользуемся для отключения требования обязательной проверки подлинности. Для открытия аварийного режима зайдите в ваш личный кабинет на страницу «Мои сервера» и кликните на скриншот требуемого сервера







В открывшемся окне необходимо активировать возможность авторизации пользователя. Это делается нажатием комбинации клавиш Ctr+Alt+Del, но так как такая комбинация через web передана быть не может, специальная кнопка была вынесена на верхнюю панель окна:







Далее вводим пароль администратора и нажимаем Enter:







Вы увидите стандартный рабочий стол Windows. Здесь нажмите кнопку «Пуск» (Start), найдите там «Мой компьютер» (This PC) и кликните на него правой кнопкой мыши:







Выберите в меню пункт «Свойства» (Properties) для открытия окна информации о системе







В меню слева необходимо найти кнопку управления параметрами удалённого рабочего стола (Remote settings).







Последним шагом снимаем флажок с параметра «Allow connections only from…» и нажимаем «ОК».
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/305672/

Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<ubuntu - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda