Linux 1 years nbd

NBD (Network Block Devices) в качестве SAN

Есть такая хорошая штука как nbd.

Если расшареный nbd винт использовать с одного клиента, то никаких вопросов не возникает.

Но у меня вот такой вопрос: Возможно-ли при подключении nbd винта на разные клиенты использовать его на всех для записи/чтения, например, поставив на него файловую систему GFS?

И попутный вопрос: Если это возможно, будет-ли такое работать если поставить GFS на lvm раздел организованный на нескольких nbd?

Re: NBD (Network Block Devices) в качестве SAN

Нет.
Да, но зачем тогда nbd?
Да, но блин усточивость внушает сомнения

Re: NBD (Network Block Devices) в качестве SAN

> Да, но зачем тогда nbd?

Не совсем понял. nbd будет раздавать винты клиентам. А GFS будет обеспечивать корректную работу такой конфигурации. Прощще всего конечно использовать все nbd на одном сервере и раздавать файлы на нем по nfs, но в данном случае возникает двойной сетевой трафик.

> Да, но блин усточивость внушает сомнения

Устойчивость чего вызывает сомнение? nbd+lvm у меня уже используется, но только в монопольном режиме без раздачи по нескольким клиентам.

Re: NBD (Network Block Devices) в качестве SAN

>Не совсем понял. nbd будет раздавать винты клиентам. А GFS будет обеспечивать корректную работу такой конфигурации. Прощще всего конечно использовать все nbd на одном сервере и раздавать файлы на нем по nfs, но в данном случае возникает двойной сетевой трафик.

Так GFS же может своими средствами преоставлять ФС клиентам. Или storage у тебя принципиально не должен сам GFS иметь?

>Устойчивость чего вызывает сомнение? nbd+lvm у меня уже используется, но только в монопольном режиме без раздачи по нескольким клиентам.

Чего угодно поверх nbd. он сам по себе стремен, но не дай бог еще уровень абстракции поверх — в случае сбоя кто собирать будет кости?

Re: NBD (Network Block Devices) в качестве SAN

> Так GFS же может своими средствами преоставлять ФС клиентам. Или storage у тебя принципиально не должен сам GFS иметь?

Хм. Когда я ее изучал, я у нее таких возможностей не заметил.

Вот ситуация. У меня в локалке есть куча серверов с винтами и мне нужно получить единое хранилище состоящие из этих винтов. Это средствами GFS делается?

Re: NBD (Network Block Devices) в качестве SAN

Неважно, кто будет раздавать блочное устройство по сети — хоть NBD, хоть ENBD, хоть iSCSI. Главное, чтобы этот протокол был рассчитан на одновременное использование (не делал лишнего кеширования и отложенной записи).

Но NBD пользоваться сильно не рекомендуется — оно очень плохо отрабатывает сетевые проблемы. Как минимум ENBD, а лучше всё-таки iSCSI попробовать.

Сверху такого блочного устройства, насколько я понимаю, может быть, по сути, любая кластерная файловая система — GFS, OCFS (лучше OCFS2), ещё были каких-то парочка.

Я точно знаю примеры использования iSCSI+OCFS2, они подробно описаны на околооракловых ресурсах.

А вообще это уже не SAN, это NAS. 🙂

Ну естественно, что для очень уж серьёзных применений такую конструкцию использовать нельзя — латентность блочных сетевых устройств на порядок, а то и на два выше, чем у обычных SCSI или FiberChannel-устройств (зато цена на порядок, а то и на два — ниже).

Re: NBD (Network Block Devices) в качестве SAN

С iscsi я задолбался бороться. 🙁 Пока enbd мне представляется наиболее реальным вариантом.

Re: NBD (Network Block Devices) в качестве SAN

> Возможно-ли при подключении nbd винта на разные клиенты
> использовать его на всех для записи/чтения, например, поставив на
> него файловую систему GFS?
Может и опоздал но ответ будет ДА. В GFS для nbd есть даже реализация fenced.
Только рекомендуется использовать не nbd а другую реализацию, читай
http://www.redhat.com/docs/manuals/csgfs/browse/rh-cs-en/index.html

Re: NBD (Network Block Devices) в качестве SAN

Re: NBD (Network Block Devices) в качестве SAN

Вы исполььзуете iscsi target железный или софтовый? В данном варианте меня больше всего интересует нагрузка на проц. Что-то мне подсказывает что без спец. железа она будет очень высокой.

Re: NBD (Network Block Devices) в качестве SAN

Попробовал enbd скомпилить под свое ядро. При загрузке модуля kernel panic. Нафиг такую надежность!

Re: NBD (Network Block Devices) в качестве SAN

Сейчас тестирую поведение nbd девайсов при обрыве связи. На периодах в несколько минут операции на клиенте с этим разделом замирают. При этом по top видно i/o waiting под 100%. Когда связь восстанавливается, через небольшое время все отмирает и корректно продолжает работать дальше. Если время побольше — тогда да. С lvm происходит сбой и фс монтируется только для чтения. Мне кажеться что это не настолько смертельно что-бы вообще отказываться от nbd.

Re: NBD (Network Block Devices) в качестве SAN

Использую две ISCSI QLogiq 4010c, до этого экпериментировал на софтовом.
По глючности разница как небо и земля 🙂

Re: NBD (Network Block Devices) в качестве SAN

Про нагрузку: тормозов на софтовой реализации не замечал,
процессор стандартный P4 3.00GHz с кешем 2Мб.
Основная бага, при выдергивании шнурка выпадал в кернел паник.

Re: NBD (Network Block Devices) в качестве SAN

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

Источник

📑 Работаем с образами дисков KVM с помощью NBD

Достаточно часто возникает необходимость посмотреть или подправить что нибудь в образе диска виртуальной машины KVM, не запуская саму виртуальную машину. Существует несколько способов подмонтировать диск образа виртуальной машины.

Самый простейший — использовать механизм NBD (Network Block Device) — протокол работы с блочным устройством по сети. В состав пакета виртуализации KVM уже входит qemu-nbd (или, как еще называют kvm-nbd), который позволяет используя протокол NBD расшаривать образ диска по сети. В Debian-подобных системах qemu-nbd входит в состав qemu-utils .

В Ubuntu (да и в большинстве других Linux-подобных системах) драйвер Network Block Device должен быть загружен вручную:

qemu-nbd будет использовать драйвер nbd для создания блочных устройств и осуществления ввода/вывода при работе с ними. Теперь можно приконнектить образ диска:

Здесь вместо nbd0 может быть и nbd1, nbd2, то-есть любое свободное блочное устройство. Если устройство уже занято, то выдается ошибка, что-то типа:

При успешном подключении qemu-nbd завершается и осталяет работать демон, который позволяет осуществлять с /dev/nbd0 стандартный набор функций присущих любому блочному устройству: mount, fdisk, fsck и так далее.

Перед монтированием нужно посмотреть разделы на блочном устройстве nsd0:

Теперь можно монтировать и работать с nbd0p1 как с обычным примонтированным диском:

После завершения работы с образом диска KVM отмонтируем его:

Если при попытке коннекта выдается невразумительная ошибка:

значит не загружен драйвер nbd. После всех манипуляций можно выгрузить nbd:

ВАЖНО. Нельзя проводить все эти действия при запущенной виртуальной машине. Данные на ней будут безвозвратно потеряны.

Файл образа виртуальной машины может быть любого формата, поддерживаемого QEMU: raw, qcow2, qed, vdi, vmdk, vpc, и т.д.

Источник

linux NBD: Introduction to Linux Network Block Devices

Sep 16, 2019 · 3 min read

Network block devices (NBD) are used to access remote storage device that does not physically reside in the local machine. Using Network Block Device, we can access and use the remote storage devices in following three ways on the local machine:

NBD presents a remote resource as local resource to the client. Also, NBD driver makes a remote resource look like a local device in Linux, allowing a cheap and safe real-time mirror to be constructed.

you dont need to com p are NFS with NBD because both are totally different ways of solutions of network storage system

Why NBD ? usecase scenario

For example, maybe you want to format the device. Or you want to modify or copy entire partitions. These tasks would be impossible to accomplish with a network file system, because they would require you to have the file system unmounted in order to perform them — and if you unmount your network file system, it’s no longer connected.

But if your remote storage device is mounted as a block device (NBD), you can do anything to it that you’d be able to do to a local block device.

In other words, with NBD, you can take a device like /dev/sda on one machine and make it available to another machine as if it were a local device there connected via a SCSI or SATA cable, even though in actuality it is connected over the network.

Sometimes you may want to complete operations on a storage device at a lower level than a network file system(NFS) would support.

You can also boot complete OS from NBD over network.(e.g. scaleway.com users boots everytime from nbd)

Getting started with NBD

I used debian OS for my example below (would works also with all derivates like ubuntu)

NBD works according to a client/server architecture. You use the server to make a volume available as a network block device from a host, then run the client to connect to it from another host.

ServerSide

apt-get install nbd-server
modprobe nbd

after installation you can begin to export a device or file now

Export device
Example: export ServerSide Disk Device like /dev/sda on port 9999

Export img file
Example: export ServceSide .img file like vmdisk.img on port 9998

img over NDB can be useful if you’re working with virtual disk images, for example.

ClientSide

On the client machine that we want to use to connect to the NBD export we just created, we first need to install the NBD client package with:

apt-get install nbd-client
modprobe nbd-client

map/mount remote NBD exported device as local device /dev/nbd0

nbd-client 192.168.1.100 9999 /dev/nbd0
nbd-client 192.168.1.100 9998 /dev/nbd1

What you can do now on ClientSide with mounted NBD?
you can start doing cool things with the NBD export from the client machine by using /dev/nbd0 as the target.

now you are able to use /dev/nbd0 like local disk on clientSide

example: you can format it
mkfs.ext4 /dev/dbd0 )

other usage examples szenarios clientSide
+ You could resize partitions
+ You could create a filesystem (like local filesystem)
+ You could create btrfs /zfs/glusterfs storage pools

As long as the export that the client is using at /dev/nbd0 is mapped to a device like /dev/sda on the server, operations from the client on /dev/nbd0 will take effect on the server just as they would if you were running them locally on the server with /dev/sda as the target.

Important

use this case szenario only in protected Local Networks !

Never use NBD in Public networks (e.g over internet) without configure your security. (the same rules aplies NFS too ! )

All of the above said, NBD is a cool tool. It lets you do things that would otherwise not be possible. It doesn’t get much press these days (which is not surprising because NBD dates all the way back to the early 2000s, and hasn’t ever been important commercially), but it may be just the tool you need to solve some of the strange challenges that can arise in the life of a sysadmin.

Источник

Взлом и защита шифрования дисков LUKS

Шифрование дисков предназначено для защиты данных в компьютере от несанкционированного физического доступа. Бытует распространённое заблуждение, что дисковое шифрование с этой задачей действительно справляется, а сценарии, в которых это не так, представляются уж слишком экзотическими и нереалистичными. В этой статье показано, что извлечение мастер-ключа шифрованного тома LUKS легко осуществимо на практике, и предложен (давно не новый) метод защиты.

Суть проблемы

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

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

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

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

Практическая демонстрация

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

Установка Debian 9 с шифрованием создаёт загрузочный раздел и раздел с шифрованным LVM. Снимок экрана установленной системы с запросом пароля расшифровки для наглядности:

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

Монтируем диск машины, извлекаем инитрамдрайв:

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

1. Утилита для шифрованной отправки по сети. Добавляю её в /sbin
2. Шелл-скрипт для извлечения ключа и отправки. Отправляется в /scripts/local-top и добавляется в список /scripts/local-top/ORDER после cryptoroot .
3. Недостающий родной скрипт обработки событий udhcpc, чтобы запустить автонастройку сети прямо в рамдрайве, пользуясь встроенными средствами. Его законное место в /etc/udhcpc/default.script

Исполняемый файл secsend собран статически, чтобы устранить зависимости от каких-либо библиотек. При обычных условиях сборка даёт на выходе файл размером 2,7 МБ, что довольно ощутимо по сравнению с размером рамдрайва — 62 мегабайта в распакованном виде и 20 в сжатом. Однако, при сборке всех библиотек и исполняемого файла с минималистичной musl libc размер выходного файла получается

250 КБ и 120 КБ после сжатия UPX. Сам secsend просто читает стандартный вход, шифрует его cryptobox-ом из libsodium с использованием заданного публичного ключа Curve25519 и отправляет данные на заданный адрес по TCP. Его использование непринципиально для основной цели демонстрации, он скорее показывает что атакующий по сути ничем не ограничен: можно запускать код, который делает что хочет атакующий и как он этого хочет.

После добавления этих трёх файлов и редактирования ещё одного можно запаковывать всё обратно и возвращать изменённый файл на место:

Потребуется некоторый сервер для приёма зашифрованного мастер-ключа, например такой (Python 3.5.3+). Запустив его с указанием секретной части ключевой пары, дожидаемся, пока условная жертва включит свой компьютер:

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

А вот на стороне слушателя подключений появился секретный мастер-ключ:

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

Монтируем диски со снятой копии:

Меры защиты

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

Шифрование загрузочного раздела

Некоторые дистрибутивы предлагают и такую возможность при установке (например OpenSuSE). В таком случае загрузочный раздел расшифровывается загрузчиком, а затем с него загружаются ядро и инитрамдрайв. Такой подход не имеет особого смысла по следующим причинам:

• Самый главный вопрос с подменой кода всё равно остаётся открытым. Только теперь подменять нужно будет загрузчик.
• Для загрузочного раздела важнее не конфиденциальность данных, а целостность данных. Обычное шифрование LUKS не предоставляет такой гарантии. Некоторая выгода здесь заключается только в том, что на таком зашифрованном разделе трудно сформировать осмысленную подмену.
• И шифрование LUKS2 с проверкой целостности (dm-integrity) тоже не защищает от вмешательств, потому что оно не даёт гарантий против атак, связанных с повторным воспроизведением секторов. Например, имея дамп такого раздела и конфиг загрузчика на нём, всё равно можно взять и откатить ядро на состояние, скопированное ранее. Это не даёт преимуществ конкретно в вопросе извлечения ключа (разве что если старое ядро было уязвимо и это можно каким-то образом использовать), это скорее довод в пользу бесполезности шифрования загрузочного раздела.

Использование TPM для хранения ключа шифрования и валидации безопасной среды загрузки

Однако в линуксе поддержка TPM пока находится в зачаточном состоянии. Загрузчик TrustedGRUB2 (приспособленный для работы с TPM загрузчик) не поддерживает UEFI и от этого пропадает весь смысл затеи. Кроме того наличие рабочего TPM 2.0 только сейчас начинает появляться в железе, зачастую вместе с обновлениями BIOS. Большинство материнских плат не имеют дискретного TPM-модуля, вместо этого TPM программно реализован внутри Intel ME . По всем этим причинам я пока не рассматриваю такую конфигурацию как рабочую и пригодную для широкого использования.

Использование UEFI Secure Boot для полного покрытия загрузочной цепи электронной подписью

Существуют дистрибутивы (Fedora, OpenSuSE) и одиночные решения, которые позволяют использовать Secure Boot в Linux. Однако, коробочные решения зачастую не обеспечивают целостность кода в цепи загрузки. Они предназначены преимущественно для того, чтобы Linux просто запускался при включенном Secure Boot. Обычно просто используется EFI shim, подписанный сертификатом Microsoft, который дальше запускает всё что угодно. Соответственно, при использовании внешнего сертифицирования покрыть подписью инитрамдрайв, который генерируется прямо в установленной системе, просто невозможно.

1. Укрощаем UEFI SecureBoot — первая статья на хабре на эту тему, очень подробная.
2. Используем Secure Boot в Linux на всю катушку — здесь особенно хорошо написано, почему Secure Boot с установленными сертификатами Microsoft эквивалентен его отсутствию.

Требуемый результат получается во второй статье. Подпись инитрамдрайва достигается слиянием рамдрайва и ядра в одно EFI-приложение, без использования загрузчика, и UEFI напрямую проверяет подпись сразу оптом. Оба руководства требуют массу ручной работы на каждой защищаемой системе.

Доступное решение

Мне встретился подход к полноценному внедрению Secure Boot, совместимый с общепринятой схемой загрузки и не требующий серьёзного вмешательства в систему: отдельный загрузчик, отдельный рамдрайв, отдельное ядро. UEFI проверяет подпись только загрузчика GRUB2, загрузчик имеет вшитый конфиг с ключом для проверки подписи и паролем администратора, и дальше проверяет ядро и рамдрайв. Подписанный загрузчик устанавливается параллельно со старым и при необходимости сохраняется возможность запуститься обычным образом, выключив Secure Boot. Разумеется, эта возможность должна быть закрыта паролем администратора в меню настроек UEFI.

Я решил автоматизировать процесс внедрения Secure Boot с собственным PKI и сделать его простым и независимым от дистрибутива насколько возможно. В результате получился вот такой набор из рецепта Makefile и утилит: https://github.com/Snawoot/linux-secureboot-kit. Для debian, ubuntu, fedora и centos весь процесс требует всего несколько команд.

Конкретно на примере Debian 9 установка выглядит примерно следующим образом (предполагая, что UEFI уже в Setup Mode):

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

А вот как выглядит попытка подмены рамдрайва на такой инсталляции:

Подмена загрузчика (внешний вид зависит от платформы):

Одного лишь дискового шифрования недостаточно для обеспечения конфиденциальности данных. Подпись всей цепи загрузки с использованием UEFI Secure Boot и GPG позволяет достичь хорошего уровня защиты от подмены исполняемого кода при условии, что эксплуатант компьютера способен распознать сброс или подмену системной платы, или даже всего компьютера. В противном случае крайне трудно предложить адекватные способы защиты, если пользователь готов ввести пароль/передать ключ в любую машину, которая случайно оказалась на столе или в серверной.

ОБНОВЛЕНИЕ (2020-09-24 20:24:24+00:00): NSA опубликовало технический отчёт со схожими рекомендациями по усилению безопасности загрузочной цепи: ссылка, зеркало.

Источник