Еще забыл упомянуть: в статье не помечено, но т.к. переезд осуществляется на ssd, то уже на перенесенной системе нужно не забыть включить функционал trim'а (например так: systemctl enable fstrim.timer, для trim'а раз в неделю в рассматриваемом дистрибутиве).
Для того, чтобы разрешить удалённый доступ, необходимо задать пароль для пользователя root и запустить SSH демон
Если говорить о redhat-производных дистрибитивах, то можно на этапе загрузки добавить опции в commandline ядра: inst.sshd inst.vnc inst.vncpassword=pass. Ssh, правда, будет беспарольный, и если сеть недоверенная, то после первого захода лучше установить пароль. Этот способ удобней, если используется не livecd, а какой-нибудь minimal/netinstall и не будет подготовленных конфигов для запуска ssh с помощью systemd/init сервиса + есть vnc, если хочется графики.
задача могла бы быть ещё проще — в логический том добавляется новый диск, после чего с использованием команды pvmove данные переносятся на другой физический носитель внутри логического тома
Тут небольшая путаница. Новый диск (его раздел) добавляется в физичесий том, физический том в логическую группу томов (расширяется существующая), и затем логический том переносится внутри логической группы на другий физический носитель (физичесий том).
Единственное, что осталось сделать, это переустановить загрузчик. Это необходимо делать с использованием chroot
Можно и без chroot, у grub2-install есть опция --boot-directory. В том числе актуально, если под рукой есть только x86 live, а препарируемая система — x86_64 и chrot'нуться не получится.
Ну и как говорили выше, намного универсальней будет использовать rsync, например с опциями --delete --numeric-ids -aHAXS (сохраняем все возможные атрибуты в неизменном виде), тогда мы не зависим от фс между которыми перенос. Если сервер выключен, то ничего exclud'ить не надо. А если нужно минимизировать время простоя, то обычно делают 3ой rsync (в live режиме с exclud'ами, еще раз, чтобы синхронизировать разницу, которая накопилась во время первого прогона и 3ий раз после выключения).
Зря минусуют предыдущего комментатора, т.к. это на самом деле разные операции для разных целей. ioctl BLKDISCARD (ATA TRIM) не гарантирует какого-то общего поведения на всех устройствах, все зависит от firmware конкретно диска. После discard'а контроллер диска может возвращать нули, прошлые данные, случайные данные, а может поведение вообще не быть четко описанным. Также есть и другие ata комманды: ATA SECURE TRIM (ioctl BLKSECDISCARD, blkdiscard -s), ATA SECURITY ERASE UNIT (hdparm --security-erase), но опять же их поведение может быть по разному реализовано в firmware различных дисков.
Поэтому топикастер заполняет сначала весь диск случайными данными, чтобы точно нельзя было достать прошлые данные напрямую с диска. После чего делается blkdiscard уже для других целей — помечаем все блоки как свободные, чтобы вернуть показатели производительности ssd диска к изначальным. При этом мы уже не волнуемя, что с диска можно будет достать старые данные при любом поведение discard'а.
Ну и для dd лучше поднять bs хотя бы до 1M-2M — меньше write iops на диск будет, больше по скорости можно будет разогнаться. И oflag=direct добавить, мы же хотим быть уверены, что сразу по факту все перезаписано. Ну или можно использовать специализированную утилиту — shred.
Ничего, сессия завершится. Но как уже обращали внимание выше, для этого случая есть специально разработанный механизм — pam, его и нужно использовать. Можно как свой модуль написать так и использовать pam_exec для запуска срипта/программы.
Ловим что-нибудь типа «debug2: shell request accepted on channel 0» и посылаем в этот момент «Ctrl+c»:
Last failed login: Tue Mar 20 02:41:12 EDT 2018 from 58.242.83.24 on ssh:notty
There were 23 failed login attempts since the last successful login.
Last login: Tue Mar 20 02:40:14 2018 from 95.154.75.23
^C-bash-4.2# cat /root/README
Привет всемогущий инжинер. Пароль.
"Другой жизни не будет"
Можно автоматизировать с помощью expect или правкой ssh клиента. Вручную тоже очень быстро ловится нужный момент.
Meltdown позволяет читать всю память со скоростью 500кб / сек
Meltdown никак не позволяет читать память за пределами гостевой ОС (если речь идет об аппаратной виртуализации).
Единственный вектор атаки для guest->hypervisor или guest<->guest — это Spectre v2. А в этом случае единственное, что можно будет сделать, это при удачном стечении обстоятельств «натренировать» процесс за пределами ВМ обращаться к своей же памяти, но по незапланированному адресу. После чего все еще будет нужен сторонний способ для обращения в ту же область памяти этого процесса, чтобы попытаться сделать какой-либо вывод о содержимом памяти по интересующему адресу. Все это в совокупности сводит такой тип атаки в случае стандратной конфигурации (в частности отстутсвуют нестандартные опции ядра, облегчающие вторую часть эксплуатации уязвимости) к крайне маловероятной.
И какой уровень деградации под этим понимается в абсолютной и относительной велечине? +19 us на io, например, это много? А какой уровень тогда у VMware или Hyper-V?
Еще для RedHat находятся «лишние» уязвимости, из-за того парсятся бюллетени не только для «Red Hat Enterprise Linux Server», а и для всех остальных дистрибутивов заданной ветки (например Red Hat Gluster Storage Server).
systemctl enable fstrim.timer, для trim'а раз в неделю в рассматриваемом дистрибутиве).Если говорить о redhat-производных дистрибитивах, то можно на этапе загрузки добавить опции в commandline ядра:
inst.sshd inst.vnc inst.vncpassword=pass. Ssh, правда, будет беспарольный, и если сеть недоверенная, то после первого захода лучше установить пароль. Этот способ удобней, если используется не livecd, а какой-нибудь minimal/netinstall и не будет подготовленных конфигов для запуска ssh с помощью systemd/init сервиса + есть vnc, если хочется графики.Тут небольшая путаница. Новый диск (его раздел) добавляется в физичесий том, физический том в логическую группу томов (расширяется существующая), и затем логический том переносится внутри логической группы на другий физический носитель (физичесий том).
Можно и без
chroot, у grub2-install есть опция--boot-directory. В том числе актуально, если под рукой есть только x86 live, а препарируемая система — x86_64 и chrot'нуться не получится.Ну и как говорили выше, намного универсальней будет использовать rsync, например с опциями
--delete --numeric-ids -aHAXS(сохраняем все возможные атрибуты в неизменном виде), тогда мы не зависим от фс между которыми перенос. Если сервер выключен, то ничего exclud'ить не надо. А если нужно минимизировать время простоя, то обычно делают 3ой rsync (в live режиме с exclud'ами, еще раз, чтобы синхронизировать разницу, которая накопилась во время первого прогона и 3ий раз после выключения).blkdiscard -s), ATA SECURITY ERASE UNIT (hdparm --security-erase), но опять же их поведение может быть по разному реализовано в firmware различных дисков.Поэтому топикастер заполняет сначала весь диск случайными данными, чтобы точно нельзя было достать прошлые данные напрямую с диска. После чего делается
blkdiscardуже для других целей — помечаем все блоки как свободные, чтобы вернуть показатели производительности ssd диска к изначальным. При этом мы уже не волнуемя, что с диска можно будет достать старые данные при любом поведение discard'а.Ну и для dd лучше поднять bs хотя бы до 1M-2M — меньше write iops на диск будет, больше по скорости можно будет разогнаться. И oflag=direct добавить, мы же хотим быть уверены, что сразу по факту все перезаписано. Ну или можно использовать специализированную утилиту — shred.
Ничего, сессия завершится. Но как уже обращали внимание выше, для этого случая есть специально разработанный механизм — pam, его и нужно использовать. Можно как свой модуль написать так и использовать pam_exec для запуска срипта/программы.
Никто не мешает послать sigint в нужный момент. Легко проверить на чем-нибудь типа «sleep 10;echo hello».
Возможно не на всех версиях openssh.
Ловим что-нибудь типа «debug2: shell request accepted on channel 0» и посылаем в этот момент «Ctrl+c»:
Можно автоматизировать с помощью expect или правкой ssh клиента. Вручную тоже очень быстро ловится нужный момент.
Пример для expect:
Meltdown никак не позволяет читать память за пределами гостевой ОС (если речь идет об аппаратной виртуализации).
Единственный вектор атаки для guest->hypervisor или guest<->guest — это Spectre v2. А в этом случае единственное, что можно будет сделать, это при удачном стечении обстоятельств «натренировать» процесс за пределами ВМ обращаться к своей же памяти, но по незапланированному адресу. После чего все еще будет нужен сторонний способ для обращения в ту же область памяти этого процесса, чтобы попытаться сделать какой-либо вывод о содержимом памяти по интересующему адресу. Все это в совокупности сводит такой тип атаки в случае стандратной конфигурации (в частности отстутсвуют нестандартные опции ядра, облегчающие вторую часть эксплуатации уязвимости) к крайне маловероятной.
И какой уровень деградации под этим понимается в абсолютной и относительной велечине? +19 us на io, например, это много? А какой уровень тогда у VMware или Hyper-V?
Еще для RedHat находятся «лишние» уязвимости, из-за того парсятся бюллетени не только для «Red Hat Enterprise Linux Server», а и для всех остальных дистрибутивов заданной ветки (например Red Hat Gluster Storage Server).
Пример:
В то время как RHSA-2016:0015 актуален только для Red Hat Gluster Storage Server.
Т.е. или нужно связать redhat только с «Red Hat Enterprise Linux Server» или добавить возможность указать более точно версию RedHat.
Получаем «OSVersion»: «any» для всех пакетов, хотя тут видим, что этот RHSA-announce актуален только для RedHat версий 7.*.