О нашумевшей истории с стиранием данных с NAS от Western Digital можно почитать в посте @ZlodeiBaal: Western Digital стер данные с большинства пользовательских NAS
Здесь же будет об исправлении уязвимости, которой, как оказалось, 7 лет (2014), пусть Western Digital 3 дня назад отписались следующим параграфом:
"Серия My Book Live была представлена на рынок в 2010-м, и эти устройства получили последнее обновление прошивки в 2015-м году.
The My Book Live series was introduced to the market in 2010 and these devices received their final firmware update in 2015. [1]
17 часов назад пользователь dracenmarx опубликовал следующие инструкции для исправления ошибки с удаленным выполнением кода (RCE):
Заходим по SSH и редактируем файл (например с nano):
/var/www/Admin/webapp/includes/languageConfiguration.php
Первое изменение, находим:
exec("sudo bash -c '(echo \"language {$changes["language"]}\">/etc/language.conf)'", $output, $retVal);
Заменяем на:
if (!preg_match('/^[a-z]{2}_[A-Z]{2}$/', $changes["language"], $dummy)) return 'BAD_REQUEST';
exec("sudo bash -c '(echo '\"'\"".escapeshellarg("language {$changes["language"]}")."\"'\"'>/etc/language.conf)'", $output, $retVal);
Второе изменение, находим:
exec("sudo bash -c '(echo \"language {$lang["language"]}\">/etc/language.conf)'", $output, $retVal);
Заменяем на:
if (!preg_match('/^[a-z]{2}_[A-Z]{2}$/', $lang["language"], $dummy)) return 'BAD_REQUEST';
exec("sudo bash -c '(echo '\"'\"".escapeshellarg("language {$lang["language"]}")."\"'\"'>/etc/language.conf)'", $output, $retVal);
Больше, по его словам, он похожих ошибок не нашел.
Ну что ж, элементарно забыли не знали, что надо экранировать параметры, которые будем выполнять прямиком в системе, да ещё из под sudo c sudoers. А может знали, но верили?, что в переменных-то точно не будет ереси! Это я уж не буду ехидничать, что можно было вместо полноценного exec с внешними данными в командной строке, записать данные по STDOUT.
Всё бы было ничего, но dracenmarx под своим сообщением пишет, что уязвимость была известна с 2018-го года, так ведь? https://cve.circl.lu/cve/CVE-2018-18472 (оригинальный блог-пост от WizCase)
Western Digital WD My Book Live (все версии) имеет баг с удаленным выполением команд под рутом через метасимволы шелла в параметре language через /api/1.0/rest/language_configuration. Может быть вызвано любым, кто знает адрес устройства.
Да, некрасиво, но пользователи — сами себе злые буратины. Устройство не на гарантии? — Выкидывайте. Сами WizCase приводят такой PoC:
curl -kX GET -d ‘bim=param`whoami`’ https:///panel/rest/configuration
Так что WD знали о уязвимости в 2018-ом, что есть очень, очень большая дыра в безопасности, которая сотрёт все данные и ничего не сделали. А теперь, когда её эксплуатируют, делают вид, что удивлены. - dracenmarx, 26 июня.
Всё бы хорошо, если не дальнейшее копание самого dracenmarx:
Пока искал информацию по CVE-2018-18472, обнаружил, что эксплоит был уже известен в марте 2014-го! (WDMyCloud Command Injection CSRF) Получается, эксплоит на иньекцию команд от рута был в онлайне пока MyBookLive ещё поддерживались и WD ничего не сделали?! - dracenmarx, 26 июня
Давайте посмотрим на этот код. Опубликован 20-го марта 2014г. Выполнен как модуль для Metasploit. Описание модуля и код:
Name: WDMyCloud NAS Command Injection CSRF
Description: This module exploits a command injection vulnerability in the web interface of the WDMyCloud NAS device, via CSRF. It will submit the CSRF request to RHOST, as well as wdmycloud and wdmycloud.local.
DisclosureDate: 0 day, yo
То есть элементарно отсылаем запрос на 3 адреса, двое из них известны и статичны, и в теории должны в локальной сети идти прямиком на NAS, а третий адрес можно задать самому.
params = "format=xml&rest_method=PUT&language=" + Rex::Text.uri_encode("`#{payload.encoded}`")
...
<html>
<body>
<h1>Redirecting... Please Wait</h1>
<div style='display:none'>
<img src='http://wdmycloud.local/api/1.0/rest/language_configuration?#{params}' />
<img src='http://wdmycloud/api/1.0/rest/language_configuration?#{params}' />
<img src='http://#{datastore['RHOST']}/api/1.0/rest/language_configuration?#{params}' />
</div>
Как видим, всё то же самое. Параметр language и вжух! 2014г.
Примечательно, что два других пользователя создали себе форки этого кода. 11 июня 2014-го и 29-го августа 2015-го. Утверждать, что о нём никто не знал... ну PR и не на такое способны :)
Получается, "неофициально", но вполне находимо (> https://gist.github.com/phikshun) эксплоит был публично доступен 7 лет, самое позднее, когда WD получили официальный пинок репорт - 2018-ый. Но когда код пишется на тяп-ляп (или матерную форму сего выражения, иначе бы уязвимости не было), а задача поддержки — не ведение базы данных и введение причастных лиц в курс дела, то и получаем отписки типа:
The vulnerability report CVE-2018-18472 affects My Book Live devices originally introduced to the market between 2010 and 2012. These products have been discontinued since 2014 and are no longer covered under our device software support lifecycle. We encourage users who wish to continue operating these legacy products to configure their firewall to prevent remote access to these devices, and to take measures to ensure that only trusted devices on the local network have access to the device.
Western Digital takes the security of our customers’ data seriously, and we provide security updates for our products to address issues from both external reports and regular security audits. Additionally, we welcome the opportunity to work with members of the security research community through responsible disclosure to help protect our users. [...]
Только обычные пользователи — не B2B, и вой и вонь поднять могут. И тогда вдруг репутационный ущерб появляется на сводках и диаграммах мудрых MBA, и неожиданно выделяется и время и деньги на безопасность и IT.
Странно только, что один единственный пользователь за пару дней не только создал патч, но и нашел всю историю по багу — то, чем должна была заняться сама многомиллиардная компания.
Пока гром не грянет — мужик не перекрестится.
А потерпевшим можно только позавидовать, видно стирались просто файлы и TestDisk/PhotoRec вполне восстанавливает утраченное. Будь я злодеем — прошелся бы с dd, а будь хипстерским злодеем — openssl с публичным ключиком. Но не будем о плохом, его и так хватает:
I got a quote for data recovery and it was $2,000 to $5,000. Unbelievable. - mkennedy
Another affected user here in Canada. I had no idea there was an issue until I read the email from WD this afternoon. I checked the drive and sure enough, only the default folders were there. I unplugged the drive and here we are. I’m a hobby photographer, approximately 80,000 photos gone. I’m on the support chat waitlist, it’s been 11 seconds remaining for the past 20 minutes so I’m not holding my breath. - damack604
igrushkin
Понятно, что смысл статьи не в этом, но последний чувак удивил. Если у тебя 80,000 дорогих тебе фото находятся лишь на одном девайсе, который и без хакерской атаки может сам по себе кирдыкнуться, то что-то не так с твоей бекап стратегией. Особенно, во времена дешевых облаков.
shyneko
Тут определенно нужно искать баланс между безопасностью файлов и их бэкап копиями, если бэкапить на дешевых облаках, может оказаться что:
А) Файлов нет нигде,
Б) Файлы есть там, где их не должно быть.
igrushkin
Очевидно, что именно у него баланс никакой
wtigga
У меня на одном девайсе находятся 200 тысяч фотографий (фулсайзы в RAW, несколько терабайт). Это RAID-массив в NAS (слава богу, не WD). Куда мне положить бэкап бэкапов и не разориться?
Не иронизирую, серьёзный вопрос: ширина канала не позволяет залить на какой-нибудь Amazon Glacier; положить всё на отдельный жёсткий диск — не спасёт от пожара; ну и так далее.
phtaran
я покупаю место у Google Drive но только 100Гб и бэкаплю самое важное. Дисковое место дешевое как для компаний, но не как для отдельного юзера.
Evengard
Попробуйте opendrive.com. У них персональный тариф 99$ в год, и по их условиям он рассчитан на объём хранения около 10 TB (после чего они начинают зарезать скорость). Он конечно немного тормозной и родной клиент у них так себе, но для долговременного хранения нормально, и rclone решает проблему с клиентом. Тот же rclone позволяет дополнительно при загрузке файлов шифровать их собственным ключом, который не улетает на сервер.
CaptainFlint
Evengard
Не уверен что они как-то это определяют, если честно, вдобавок если прижать ещё шифрованием. Но дело ваше.
alex_shpak
Я бы на Вашем месте постарался найти место, куда можно отнести положить жесткий диск (возможно, зашифрованный): к друзьям, на работу в офис, ячейку камеры хранения.
acklamterrace
Можно бэкапить на разные HDD, и хранить их в разных местах, с ротацией.
Ну и облачное хранилище я бы не отметал по причине ширины канала. У меня 0.5 mbit/s (да, пол-мегабита), свои 300 GB пришлось закачивать больше недели, зато теперь есть инкрементально обновляемый бэкап (через restic). Цена вопроса – $5/месяц.
slepnoga
LTO-4 стоит относительно недорого
Fahrain
А вы с ним вживую работали? Я почему спрашиваю — судя по описаниям, полноценная работа начинается только с LTO-5 (только там появляется поддержка нормальной эмуляции файловой системы), а работать с LTO-4 будет так же удобно, как раньше было с компакт-дисками.
В целом, я давно уже задумался о покупке соотв. девайса, но пока толком информации не нашел. Особенно волнует, как потом этот девайс с SAS на обычную SATA-материнку подключать.
vvzvlad
А зачем работать там с файлами? Архив сформировали, записали, положили на полку. Через месяц сформировали новый архив, записали, положили рядом. И так пока не кончатся картриджи, после этого переписываем первый.
Это же холодный архив, вытаскивать из него случайно перезаписанный документ будет неудобно в любом случае, тут лучше внешний жесткий.
Fahrain
Ну потому что так, архивами — неудобно. Я еще помню времена Nero и CD-RW. Да, так тоже жить можно, но…
Как я понял, LTO-5 обещает чуть-ли не банальную работу с лентой в проводнике, как с обычным диском
MakiwariB
Пользуюсь LTO-5.
Из под Linux/FreeBSD можно писать обычным tar прямо на ленту и перематывать её командой mt.
tar, кстати, поддерживает многотомность (в FreeBSD — по умолчанию, не поддерживает, но там есть gtar, который умеет), за счёт чего можно сразу выгрузить на ленты хоть целый raid-массив.
Из минусов такого решения, нужно помнить, что записано на картридже, чтобы не перетереть случайно данные.
Пробовал и LTFS, драйвера для неё есть как для Linux, так и для Windows. Кучу мелких файлов всё-таки писать не стоит, постоянный старт/стоп для стримера не особенно полезен, да и просто очень долго получается. Кроме того, при чтении с LTFS желательно читать файлы в том порядке как они были записаны (можно смотреть по ID в LTFS Cartridge Brwser), иначе больше времени уйдёт на перемотку (до 90 секунд, если мотать от начала до конца ленты), чем на собственно чтение.
Поэтому, на мой взгляд, всё-таки предпочтительнее писать большими файлами, даже используя LTFS.
Ещё при записи мелких файлов, жёсткий диск может банально не поспевать за лентой, чтобы немного сгладить этот эффект использую mbuffer.
К SATA-контроллеру материнской платы стример подключить не получится, к SAS RAID контроллерам — может не заработать (зависит от наличия поддержки режима JBOD и размера блока, поддерживаемого RAID-контроллером), так что лучше сразу смотреть на SAS HBA вроде LSI 9200 или LSI 9300 и их аналогов.
Кроме того, желательно обеспечить стримеру нормальное охлаждение, во время работы он ощутимо греется, что тоже не полезно для него.
Ещё у лент есть аппаратное сжатие, позволяющее уместить немного больше, чем реальный объём ленты (для LTO-5 — 1.5 ТБ), реальная степень сжатия зависит от типа записываемых данных.
В целом лентой доволен, но пользуюсь ей скорее как архивным носителем, а не для ежедневных бэкапов.
Если же нужен быстрый доступ к мелким файлам — только жёсткий диск на полке (что, впрочем, не мешает хранить копию этого диска на ленте).
Fahrain
У меня, в общем-то, конечная цель именно забэкапить все мои ~20 тб данных с винтов. Надежность современных емких винтов как-то резко падать начала, делать рейд на такой объем — это под 100 тыс выйдет, дорого. А ленты относительно дешевые, основные затраты только на стример получаются. Вот я и думаю, стоит ли заморачиваться. В основном у меня достаточно большие файлы, в крайнем случае мелкие можно по архивам распихать, так что проблемы с производительностью чтения/записи меня не очень волнуют, в принципе.
Am0ralist
С учетом, сколько сейчас жесткие стоят… имеет смысл)
Учтите, что у лент при чтении по сути ресурс так же расходуется, поэтому по каждому чиху на ленту лезть не есть гуд.
Ещё плюс, что сами бекапы получаются ооочень легкими и не особо боятся тряски и падений. Но вот иметь лучше два стримера и проверить как читается с второго записанное первым.
MakiwariB
Стоит или не стоит, это всё-таки индивидуально, техника немного специфическая, к этому нужно быть готовым.
Из личного опыта, пользуюсь и tar и LTFS:
tar для периодического архивирования недельных бэкапов,
LTFS для выгрузки отдельных архивов, которые удалять жалко, но в ближайшем будущем они вряд ли потребуются.
Стараюсь дублировать записанное на две ленты сразу (ленты тоже могут выходить из строя, вообще, думаю, к любому носителю информации стоит относиться как к потенциально ненадёжному), если данные предполагается относительно часто читать, лучше продублировать их на жёсткий диск (в том числе и внешний) и использовать его для чтения, а ленты как резервную копию этих данных.
С проблемами, когда стример не видит записанное другим стримером сталкиваться не доводилось. Умершие кассеты попадались, правда обнаруживалось при проверке свежекупленных б/у.
Также желательно обзавестись чистящей кассетой. Просто так её использовать не стоит (она рассчитана на 15 использований, RFID внутри картриджа не даст обмануть это ограничение), только если загорелся соответствующий индикатор на стримере, или если есть проблемы с чтением записью.
Кстати, чистящие кассеты универсальны и с некоторыми оговорками подходят для любого LTO.
При выборе стримера советую запрашивать у продавца Support Ticket с информацией о состоянии стримера (если он согласится его предоставить, конечно), для его просмотра может понадобиться Library & Tape Tools, доступный бесплатно (возможно, потребуется регистрация), для работы с LTFS есть утилиты LTFS Cartridge Browser (просмотр списка файлов на лентах) и это относится к HP. У Tandberg и Quantum, если не путаю, те же утилиты (вроде даже взаимозаменяемые), с IBM дела не имел, возможно, всё то же самое, не в курсе.
Ленты можно найти на вторичном рынке. Если поискать, встречаются даже вполне живые за вполне разумные деньги (купил в своё время большую партию лент с 87% остаточного ресурса, согласно L&TT).
У LTO достаточно продвинутая система самодиагностики, в том числе сразу после записи выполняется проверка записанных данных, если в блоке есть ошибки, он пишется повторно. Из-за этого и из-за аппаратного сжатия ёмкость ленты может ощутимо плавать.
screwer
а расскажите, пожалуйста, чуть подробнее. Про 8kb RFID видел инфу в доках. Но как её читать, что там лежит и как узнать остаточный ресурс ленты — не знаю.
MakiwariB
RFID считывается встроенным в стример считывателем. Сама метка находится в передней части картриджа, с противоположной стороны от переключателя защиты от записи.
Если используется LTFS, посмотреть состояние картриджа можно прямо в проводнике Windows, в свойствах «диска» есть соответствующая вкладка.
Также можно посмотреть в Library & Tape Tools, можно создать Support Ticket, в нём будет подробная информация о стримере и последних 5 картриджах.
Кроме того, в ней же есть диагностические утилиты, позволяющие оценить состояние картриджа.
Возможно, есть и другие способы, но они мне неизвестны. Когда в следующий раз буду записывать данные, если не забуду попробую поковыряться в L&TT, может быть, найду ещё что-нибудь интересное.
Точной информации, что и как лежит на RFID у меня нет, только предположения исходя из информации, которую стример может получить о картридже.
Как минимум, судя по L&TT, о картридже известно:
Штрихкод на наклейке, серийный номер, информация о разделах и что-то вроде смарта на HDD, количество ошибок разных видов, максимальная зафиксированная температура картриджа (хотя кто её измеряет — не понял), объём записанной/прочитанной информации, количество перемоток, общий пробег ленты (на всякий случай, длина ленты у LTO-5 860м, картридж записывается полностью за 80 проходов).
И если информация о последней сессии записи, вполне может хранится в стримере, то такие вещи как суммарный пробег, серийные номера, данные о разделах и т. д., явно хранятся в картридже.
screwer
А почему не на FibreChannel? 4GB Контроллеры на авито от 500р
MakiwariB
В сообщении на которое я отвечал, человек спрашивал
Поэтому написал про SAS HBA.
А так да, можно и по FC подключить, если у стримера соответствующий интерфейс
Oxyd
Купить LTO драйв, предыдущих поколений и картриджи к нему. Холодные бэкапы, на картриджах, хранить в другом, по отношению к NAS, месте (банковская ячейка, квартира подруги etc).
MahMahoritos
У меня аналогичная ситуация - RAID1 для всего дорого душе и сердцу. Для бэкапа периодически просто делаю rsync на диск, 90% времени лежащий в ящике стола. Причем сам файловый сервер стоит у родителей, а ящик стола с диском находится у меня в квартире. Диск на 4 ТБ, пока хватает, но в случае нехватки, думаю, совсем неразорительно купить просто три диска на нужный объем и собрать новую конфигурацию RAID1+оффлайн диск.
tendium
Дропбокс за вполне доступные деньги дает 5ТБ. А за еще чуть большую сумму может дать условный безлимит (условный, потому что повышение квоты надо запрашивать).
tendium
Хотелось бы пояснений, что не так с дропбоксом. Я использую, удобно. Было даже, что случайно удалил файл, так смог его восстановить из бекапа на дропбоксе (там можно в течение определенного периода восстановить измененный или удаленный файл).
cepera_ang
Не стоит недооценивать каналы на длительном промежутке времени. 10мбит закачает 1тб за 10 дней, даже если у вас 10Тб и 5мбит, то это за полгода потихоньку зальётся. Тот же Backblaze в фоне очень упорно будет лить столько времени сколько потребуется, чтобы залить. Если даже столько нет (какой-нибудь адсл 512кбит или мобильный), то можно на недельку к знакомым каким-нибудь унести с 500мбитным интернетом :)
Как вариант, уже порекомендовали — два внешних диска (типа wd passport 4tb), на один постоянный бэкап, другой положить в надёжное место (от знакомых, до ближайшего сбербанка — самая маленькая ячейка обойдётся там в несколько тысяч в год всего), менять диски местами периодически, раз в пару недель или хотя бы раз в месяц. Тогда в случае полной катастрофы будет копия с ожидаемым возрастом --(период_смены/2), что гораздо лучше, чем ничего. Итоговая стоимость — 3-5тыс*2 за диски разово + 4-10 тыс за сейф в год, вполне посильно. Заодно в этот сейф можно документы всякие положить и заначку от жены.
wtigga
У меня LTE, и после ~100 гигабайт исходящего трафика в месяц начинаются проблемы.
На мои 10 ТБ мне в текущей ситуации понадобится ~8 лет. Поэтому действительно нужно иметь пару внешних дисков у знакомых, не забывать их регулярно забирать и обновлять бэкапы.
SignFinder
Родственников нет, которым можно отдать на хранение шифрованный жесткий диск?
Тогда ячейка в банке.
Насколько я понял - облако не рассматривается, а то бы предложил Microsoft 365 для семьи. 6 аккаунтов по по терабайту в OneDrive, менеджмент данных через rclone.
buldo
Используйте backblaze b2. В этом облаке цены что-то типа 1 цент за гигабайт. А недавно ещё появился S3 интерфейс. Так что возможно ваш NAS может сам автоматом делать бекап в это облако.
ovalsky
Купи ещё диск, храни в несгораемом сейфе. Диск обновляй после истечения гарантии
Paskin
В Амазон можно отослать физический диск и они его зальют в S3/Glacier
bolk
А что, облака данные не теряют что ли?
cepera_ang
Не одновременно с локальной копией же.
fedorro
Да, они там могут подпортиться\потеряться задолго до локальной копии, ну или криво залиться) Сам сталкивался с амазоновым облаком. Вывод — известен давно, надо бэкапы не только делать но и проверять периодически…
bolk
Тогда зачем туда лить? Можно остаться на NAS.
cepera_ang
И как это спасёт от подобного описанному в статье или хотя бы банального пожара/воров? Облако-то не сгорит/не украдут. А если с ним что-то случится, то это не произойдёт в тот же день, когда локально проблемы возникли и будет време перезалить или ещё что-нибудь сделать.
bolk
Почему когда говорим про облака, то вы приводите аргумент локальной копии, а когда я говорю про NAS, этот аргумент внезапно не работает?
cepera_ang
Я вообще уже не понимаю о чём вы говорите. Я говорю о том, что нужно три копии — оригинал, локальная копия (бэкап на внешний диск, NAS или куда угодно) и удалённая копия (облако, внешний диск в ячейке и т.д.). Почему так? Потому что риски угрожающие всем этим копиям тогда будут декоррелированы, то есть то, что угрожает локальной копии/насу/оригиналу данных (а это к примеру, пожары, воры, шифровальщик, разбущевавшая жена и т.д.) не угрожает удалённой копии. И наоборот — хакеры, бан на облаке, что угодно, не угрожают локальной копии.
bolk
Я про одновременное использование не уловил.
igrushkin
Ниже правильно написали: вероятность того, что два события случатся одновременно, очень мала и уж точно намного меньше, чем одного.
bolk
Тогда зачем туда лить? Можно остаться на NAS.
igrushkin
Вы правда не понимаете или это такой троллинг изысканный? Зачем вообще бекапы делают?
bolk
Мы как будто на две разные темы говорим. Я не вижу плюсов облака перед НАСом, вижу минусы: отдаёшь инфу куда-то, что никак не контролируешь.
MahMahoritos
Плюс облака в том, что при пожаре/ограблении квартиры бэкап на НАС пропрадет вместе с оригинальными данными, в отличие от облака. Альтернативно вопрос решается установкой НАС у родственников/друзей или использование съемных дисков с ротацией, когда один из этих дисков хранится в депозитной ячейке или в сейфе в гараже.
bolk
А минус — что любая хакерская собака может его увести кучей способов.
Да, пожар — аргумент, а ограбление — ну можно его поставить куда-то, где его и видно не будет.
screwer
пусть уводит, данные шифрованные же!
mkll
Кажется, вы написали комментарий об отсутствии контроля в облаке под статьей, которая более чем наглядно говорит и об отсутствии контроля в NAS.
Кроме того, я не заметил, чтобы кто-нибудь из ваших оппонентов противопоставлял облака и NAS. А некоторые комментарии прямо говорят о подразумеваемом их одновременном использовании.
bolk
Я про одновременное использование не уловил.