Комментарии 150
Техслужба Rutube отрицает слух об утере исходного кода сайта сервиса
И далее по тексту
По предварительным оценкам сервиса, в результате атаки было поражено более 75% баз и инфраструктуры основной версии и 90% резервных копий и кластеров для восстановления баз данных.
Так с чего восстанавливать то?
Ну наверное еще бумажные копии были :)
В предыдущей новости цитировали, что
Мы уделяем особое внимание сохранности данных наших пользователей, они не повреждены
Т. е. пользовательские данные восстанавливать якобы есть с чего.
Т. е.всё, что осталось сделать, - это изолировать хранилище пользовательских данных от заразного живого кода (даже не обязательно прям совсем переносить, если возможно подключение извне), развернуть вне заразной инфраструктуры ЛЮБУЮ версию старого кода, подключить хранилище пользовательских данных и запустить пользователей обратно.
А потом в ещё не штатном, но уже не авральном режиме, пытаться актуализировать старый код и переносить пользовательский контент поближе к работающему коду сайта.
А вот "с чего восстанавливать", хехехе... На всю компанию обязан найтись старый вредный любитель поэкспериментировать на локальной копии, типа меня, у которого 100% есть чем БЫСТРО провернуть эти операции. Не менее одного такого. Даже если 100% разработки из 100% ведётся строго вне компьютера разработчика - какие-то готовые для развёртывания копии кода должны существовать.
Это, конечно, не сервер танков, но даже в самом тяжёлом случае за сутки вернуть работоспособность и хоть медленно, но всё же запускать на сайт пользователей можно успеть.
Но, блин, как всегда что-то пошло совсем не так...
Вот это новость так новость.
Разве на рынке серверных площадок такой нестандартизируемый зоопарк железа?
Разве проект такого калибра может от балды поменять себе привязку к архитектуре и стать несовместимым с востребованными конфигурациями железа?
Банальный HDMI CEC далеко не всегда работает полностью корректно, хотя казалось бы что сложного соблюсти стандарт.
Единственный фрагмент паззла, который, с моей точки зрения, МОЖЕТ начать кобениться в зависимости от железа на сервисе такого рода, действительно с многочасовым сексом по калибровке и доводке, - это распределение нагрузки на отдельные ноды. Если по какой-то причине нужно экономить железо и потому НАДО пытаться распределить нагрузку как можно аккуратнее.
И то при таком раскладе выигрышный вариант - заранее занизить нормы, но пользователя до контента допустить, пусть даже часть уйдёт в 50х, не вписавшись в заниженный лимит.
Если же такие мелочи, как авторизация пользователя или отдача 403 вместо контента неавторизованному коннекту, внезапно требуют патчей под конкретное железо - за такое надо хлестать ххх по щекам.
Если у Вас есть чего почитать поподробнее по Вашей точке зрения - с удовольствием гляну.
Я бы скорее поставил на то, что на данный момент у РуТуба нет железа с незаразным софтом СОВСЕМ - и по какой-то таинственной причине ни поштучная очистка с запуском незаразного софта, ни переиспользование резервных мощностей для запуска нового кластера не могут быть произведены.
Например, потому, что кому-то лень было документировать, а потому никто в организации не имеет полной документации на запуск всего кластера с нуля. И приходится идти на поклон к уже уволенным сотрудникам.
Если же Вы всё же правы и кластеру оказалось резко не наплевать на железо, на котором крутится ОСь... что ж, помянём!
Искать крайних это чисто российская традиция. А чем это увольнение поможет?
Может быть они там были в курсе и писали всякие тикеты мол у нас все плохо надо сделать вот так чтобы было хорошо. А эти тикеты задвигали на пятый квартал, потому что на взгляд топ менеджента есть более приоритетные задачи.
Или наоборот все безопасники это два калеки у которых трудовые обязанности оформлять все бумаги для взаимодействия с государством. И они вообще не в курсе этих ваших серверов.
Хорошая практика это найти причину причину почему это стало возможно и исправить причину. Это точно работает и делает лучше. А не найти стрелочника и показательно наказать его.
Этот никому не нужный видеохостинг работал бы и работал, если бы не некоторая первопричина, да... Исправить ее? Кто ж его посадит, он же памятник!
Вы точно уверены что это Путин запретил им делать нормальную инфраструктуру? Или вы точно уверены что с дырявой инфраструктурой можно долго и успешно работать на рынке потому что неуловимый джо?
Я вот как-то сильно сомневаюсь в этих утверждениях.
Сканеры рано или поздно найдут всех у кого сделано плохо. Шифровальщик посадить ради выкупа это милое дело для очень многих, несмотря ни на какую политику.
В "неуловимом Джо" я практически уверен, имею, что называется опыт, например с крупной российской нефтехимией, ритейлом и т.д. И тот факт что сервис работал много лет до, и перестал спустя всего пару месяцев после говорит об очень вероятной причине отказа.
И вы, видимо, не знаете что значит "По СНГ не работаем".
Рассчитывать на неуловимого джо, при размере бизнеса хотя бы в миллиард и 100% зависимости от IT это надо быть очень смелым и очень глупым. Хотя какое-то время это будет работать.
Не надо валить технические проблемы на какие-то внешние события. Не в событиях причина, а в том что сделано все плохо было. И исправлять надо технические проблемы, иначе может внезапно выяснится что и без любых вешних событий вам посадили шифровальщика и хотят миллионы денег.
Ну почему то же VK Video — работает. А из претензий к ним скорее "на смарттв не работает логин в аккаунт но обещали скоро исправить"(а на других платформах все заявленное — работает).
Или причина тут в том, что как у вконтакте так и Mail.Ru Group — изначально ИТшное происхождение, у rutube — менеджеры похоже от Газпрома?
Может причин
Вы опять пытаетесь найти виновного чтобы его наказать. Не надо так делать. Этот подход не поможет ничего исправить. Надо искать причины и исправлять их.
Людей не стоит вообще трогать, если там не было какого-то треша с сознательно разрушительными действиями или откровенной некомпетенцией тех кто должен разбираться. И то во втором случае лучше не наказывать людей, а разобраться как так получилось что вот такой отдел ИБ получился. И распутывать дальше. Наверно есть проблемы в найме, организации, целях и прочем в работе ИБ отдела. И стоит их все исправить.
так причина обозначена (мнением того ,кому ответили), что причина в некомпетентности директора
Это правильно — увольнять некомпетентных, тк компетентным нужно давать дорогу. Ваш "Этот подход не поможет ничего исправить" блокирует путь профессионалам и поощряет безграмотность, кумовство и разгильдяйство
То есть по вашей логике нужно узнать кто это все сделал и виноват и не наказывать их ?))
Не наказывать тех кто нанял некомпетентных людей ?)
Вот таким отношением безнаказанным и стимулируются такие кейсы ))
Суть не в наказании, а в исправлении проблемы: во главе угла система, а не человек, интересы системы важнее мелочных человеческих желаний, таких как желания мести, поисков козлов отпущения, закрытия проблем на бумаге для самоуспокоения. Системе пофиг если кого-то внутри нее накажут, казнят или даже приготовят и сожрут - от этого она лучше работать не станет, следовательно это непродуктивно и распыляет ресурсы и цели, следовательно суть глупо, и тратить на это время и ресурсы бессмысленно, а в условиях кризиса вообще непозволительно. Системе не пофиг совершенствование и работоспособность, а для этого нужно выявить отказавшее звено или звенья, и исправить их, прервав конкретно эту цепочку отказа, а также неплохо бы устроить внешний аудит: возможно назревают и другие цепочки отказа, которые только ждут подходящего триггера - каскады отказов системе явно не интересны. Что касается самих звеньев, тут во главе угла минимизация ущерба системе - в первую очередь их нужно запатчить: уже гарантированно рабочее звено с опытом выгоднее полного отсутствия звена - напоминаю, в мире острый дефицит квалифицированных кадров, включение нового звена в работу занимает до полугода, заменить никого не выйдет, как бы громко это всякие дурачки на планерках не кричали. И лишь если звено деструктивно по своей сути и сознательно приносит ущерб - тогда его выгоднее удалить из системы, сократив тем самым ущерб, а что с этим звеном будет далее вне системы - никому уже не интересно. Простые истины.
Да причём тут месть вообще?
Есть недобросовестное испольнение своих обязанностей и прочие штуки , люстрация и другие инструменты влияние. Просто так спускать все это тоже не вариант. Во главе системы как вы сказали стоит также люди)
Если от добросовестности конкретных людей зависят такие важные штуки и мы считаем что это нормально, то нужна многоуровневая система контроля добросовестности и контроля контролирующих. Видимо не нет и надо строить с нуля. И вопрос почему ее нет?
На практике как правило оказывается проще не полагаться на такие эфемерные штуки, а написать регламент. Который реально исполнять. И обязательно спросит это у исполнителей. Не мешает ли вам вот этот регламент работать? Не надо ли в нем что-то поправить? Иначе люди начнут срезать углы и опять все будет плохо.
Ок
Кто пишет регламент , правила , рабочие процессы ? Не люди ли ?)
Если они не справляются со своими обязанностями то что должно за этим следовать ? Ничего по вашему ?
А уж тем более если в результате таких писанин на бумаге потом вот такие случаи происходят. И на бумаге я уверен там все впорядке 100%
Регламент «как разворачивать софт» недостаточно просто написать. Нужна выстроенная система, этот процесс не должен раздражать разработчиков, нужно купить или написать всю инфру требуемую для такой работы. В конце концов надо мигрировать со старой системы на новую.
И опять любая часть этого процесса может застопориться по сотне причин. Если ИБ описал нормальную систему, но ее не не внедрили по причине «некогда рефакторить, и так все работает нужно срочно сделать вот эти фичи чтобы быть не хуже ютуба» то кто виноват? «Не хуже ютуба» допустим спускают от владельцев бизнеса.
Не пытайтесь искать виновных. Ищите сломанные процессы.
Вас что заело ?)
Я ещё раз спрашиваю кто пишет сами процессы и их приводит в действие? Не сами ли люди ?
С кого спрашивать если процесс неверный?
А ничего другого вам никто не скажет. Самые дорогие консультанты скажут тоже самое, но они будут в дорогих костюмах при этом.
Вероятность что был написан плохой регламент при этом писавший должен обладать компетенциями, но не обладал минимальная на самом деле.
Вероятность что на местах саботировали из-за личных качеств тоже минимальная.
Проблема где-то глобальнее. В организации, целеполагании, оценке рисков, может быть даже в структуре отделов. Вероятно везде понемногу. И править вот это все надо. А не увольнять кого-то. Вот тут консультанты в дорогих костюмах могут помочь и рассказать конкретнее. После аудита.
Если цель только в поиске виновного — запросто может оказаться что виновный кто-то кто написал служебку и успокоился (и виноват в том что он таки ее написал) начальство проигнорировало эту служебку. И все.
С вероятностью около 100 процентов виновного нет. Хотя найти его конечно можно. Это одновременно.
Виновен не человек. Есть неправильный процесс. И если цель сделать хорошо, надо найти этот процесс и исправить.
ИБ не пишет код. И даже не является прямыми руководителями людей которые пишут код и настраивают инфру. У тех кто пишет код есть свои руководители. А ещё есть коммерческий отдел который с деньгами на руках расскажет что мы тут обанкротимся, если срочно не допилим фич чтобы пользователи пришли. Задача сделать нормально может застрять на любом этапе.
Задачи отделы сами себе редко ставят. Может быть задачи ИБ были другими. Не знаю, шпионов и закладки ФБР искать во всем софте. Они этим и занимались.
Посмотрите как это сделано в авиации. Ошибка пилота и самолёт разбился это вообще не причина катастрофы и никак не поможет предотвратить следующую. Специальные люди всеми силами пытаются понять почему пилот ошибся и что надо сделать чтобы другие так же не ошиблись. Вот к такому надо всем стремиться.
Интересно по какой формуле вы считаете вероятности этих событий ?)
А процессы кто по вашему пишет , не человек ли ?)
Если процесс написан неграмотно, если он уязвим , если его не исполняют как нужно. То опять никто не виноват ни в чем ?)
Тогда ответсвенности вообще нет получается и мы имеем что имеем сегодня
Экспертная оценка исходя из аналогичных событий.
Написать мало. Надо внедрить, убедится что этим пользуются и регулярно проверять что ничего не сломалось, а людей для реализации хватает. И это все делают люди которые не подчиняются друг другу.
Именно так. Найти и наказать стрелочника это очень просто и приятно. Но это никак не помогает избежать следующего такого же проишествия. Потому что где гарантия что другой человек которого вы взяли вместо этого сможет сделать так что все заработает правильно? Как я писал выше ресурсов на рефакторинг всей инфры может по прежнему не быть. И самый грамотный человек будет биться лбом о том что реализовывать все его идеи некем.
Тогда следуя вашей парадигме выхода из этого порочного круга нет. Концы не сыскать. Никто отвественности не несет.
Причём тут стрелочник. Есть люди из высшего руководства которые несут отвественности , то есть ставят свои визы на этих регламентах и утверждают их . Как их могут утвердить если в них есть косяки ? Наверное так тоже нужно да?)
Никто не несёт. Вероятнее всего. Ответственность это если человек специально что-то сломал или специально дал доступ кому-то. Вероятность такого есть, но небольшая.
Топы не должны в этом всем разбираться вообще. И уж тем более не должны что-то там подписывать. Они про бизнес. Технические топы тоже могут быть не в курсе.э всех тонкостей. Вы опять ищете крайних. Нет их, смиритесь.
Отличные топы и технические и менеджмент которые вообще не в курсе дел внутри компании))
Вы очень похожи на одного из них кто дел натворил а теперь кричит везде что виноватых нет))
Именно. Руководители даже 50 человек уже не в курсе всех технических подробностей. У них другие задачи. Максимальная техническая компетенция или у сеньоров или на уровне лидов у которых группа в 5-10 человек.
Если заставить больших руководителей быть крайними за конкретные технические решения, то они вместо работы начнут подстилать соломку и работа встанет. Все завязнет в бесконечных согласованиях и подписях для размазывание ответсвенности. У вас останутся не технари, а те кто умеет в корпоративное конфу с перекладыванием ответсвенности.
Я не имею никакого отношения в рутубу, их аудитам, взломам и все что рядом.
На каждом уровне иерархии есть свои ответственные что вы тут затираете дичь какую то?)
Это вы его ставите
Я такого не говорил вроде )
Я такого не говорил вроде )Да это в каждом вашем сообщении сквозит, как бы кого наказать.
похожи на одного из них кто дел натворил а теперь кричит везде что виноватых нет
созразмернле наказание, должностное взыскание и другие инструменты влияния на недобросовестных сотрудников
Я все еще пытаюсь объяснить что охота ведьм которой вы так хотите заняться откровенно вредна.
Есть уровень сеньеров-лидов. Максимум технических компетенций, но очень мало ресурсов. Есть уровень топов много ресурсов и мало технических компетенций. Есть максимально плоская структура. Когда нет вот этих сложных и длинных цепочек подчинения когда вместе увязаны разные по деятельности отделы. Это все как-то интерферирует друг с другом.
И где-то там все сработало так что взлом с полным разрушением стал возможен. Разбираться как так вышло это долгий и сложный процесс. По итогу этого разбирательства должен появиться план что будет сделано чтобы такого не повторилось. Желательно с исполнителями и ресурсами на его выполнение. Если и сроки будут это вообще идеально.
Поиск виновных это вообще не задача. Ее не надо решать. Исключение это сознательные злонамеренные действия сотрудника.
Конечно разбор полетов никому не интересен потому что никто не хочет нести отвественность)
Ваш подход понятен
сработало так что взлом с полным разрушением стал возможен. Разбираться как так вышло это долгий и сложный процесс. По итогу этого разбирательства должен появиться план
потому что никто не хочет нести отвественностьРазумеется. А как вы себе это представляете? Вот например программист вообще не знает про какой-то класс уязвимостей и не написал контр-меру под него. Или написал, но опечатался, а QA сценарий не проверил, потому что он тоже не знал про такие уязвимости. Что делать-то? Нет людей, которые знают абсолютно всё, т.е. чтобы не ошибаться, нужно просто ничего не делать?
Я вам тут не буду расписывать как должен работать отдел ИБ , какие плановые и регулярные мероприятия они должны проводить для поддержания безопасности на должном уровне
Если вы это не понимаете , то разговорить особо не о чем
Здравствуйте, я прочитал весь ваш былинный тред, спасибо вам за него.
Вам, дорогой @pbo, оппоненты рассказывают про комплекс мероприятий, направленных на недопущение повторения случившегося, а Вы им в ответ лишь про одну из возможных мер в этом комплексе - наказание виновных. По моему мнению, наказание не то чтобы совсем не работает, но работает далеко не всегда, и на роль единственной меры не годится. При этом наказание мера больше реактивная, то есть ну накажете вы конкретного СТО/стрелочника/кого угодно, где системный эффект от этого? Только этот гражданин плохой, а остальные все отличники подготовки?
Правда, почитайте хотя бы два отчёта о расследовании авиакатастрофы с жертвами. Можно сразу к выводам и мероприятиям переходить, если времени немного.
Возможно, тут затесалась и терминологическая путаница в blame vs responsibility, ибо в треде местами эти понятия (вина и ответственность) используются довольно странным образом. И это мы ещё не подходили даже к вопросу, как менеджмент может понять, что технический специалист компетентен, и насколько у оного специалиста есть право и возможность предпринимать исключительно то, что он считает нужным, а не то, что ему начальник говорит.
Ну и я вот поработал в разных местах, но нигде прямо отличных процессов что ИБ, что в целом работы ИТ не видел, в основном только разговоры о них. Не подскажете ли пяток мест, куда можно резюме заслать и получить непосредственный опыт этих отличных процессов?
Да никто не говорит только о наказании
Я говорю о нормальном раздоре полетов , нахождения слабых мест и некомпетентных сотрудников а дальше что с ними делать доубучать или увольнять в виду некомпетентностям уже решить можно по факту
По поводу компании подскажу.
Positive Technologies Например
PT это чит, они же продают ИБ сами. Я потому и попросил пяток, ибо более-менее безопасники должны кончиться очень быстро.
Но я так понял, что вы тут спорите об одной и той же точке зрения, только выраженной разными словами, и отсюда и произрастает это дерево комментариев. Таки сойтись на терминах перед зарубой - важное дело.
Правда, бывает, что слова «не наказывать» понимают вообще буквально, и начинается «да как же мы Иннокентию скажем, что он застрял в 2010 году профессионально, он же такой молодец, 10 лет работает в конторе, с ним так прикольно пить водку у костра и петь песни под гитару». Обычно те же люди буквально в приказном порядке форсят на всякие безумные решения людей, которые работают чуть меньше 10 лет, и с которыми пить водку не так прикольно. П - процессы.
Ну провели они мероприятия. Выявили недостатки на пару человеколет работ. И что дальше?
Кто-то должен выделить эти годы на работу. Кто-то потом ее должен сделать, потом ещё кто-то мигрировать свои процессы на новые рельсы. И все эти люди вероятно будут из разных подразделений со своим руководством и своими задачи. Да и слонов могут раздавать за новые фичи, а не за переписывание того что и так работает.
В любой большой организации под это должен быть процесс организован. Безопасники иногда могут ставить блокирующие тикеты когда брось все и делай их задачу. Но это точно не переделка всей инфры, а что-то вроде обнови log4j.
А вы все кого-то наказать стараетесь. Не надо так делать. Это тяжкое наследие совка в его худшем варианте. И приводит такое только к бюрократии и тому что все будут стараться прикрыть себя. Вместо того чтобы работать и улучшать процессы.
Без разбора полётов и нахождения отвественных и слабых мест и людей никак не обойтись в этом процессе
Не наказать а найти ответвенных
И доубучить или уволить если совсем некомпетентны.
Разные есть варианты решения проблем и не только наказание.
Но года происходит беда такого масштаба то нужно что то предпринимать
С вероятностью около 100 процентов виновного нет. Хотя найти его конечно можноВсё наоборот )))
Виновные есть со 100% вероятностью — те, кто осуществил взлом.
А вот найти их нельзя.
Боюсь, для такого масштаба проблемы это слишком дешёвое решение - "просто уволить". Да и... хмм... "немного запоздалая" эта мера. И слегка не в ту сторону. Как показала практика на одном из прошлых моих мест работы, даже взрослые адекватные люди любят потыкать ссылочки от незнакомых контактов в Скайпе.
Безопасники, конечно, должны бдить - но как они могут повысить IQ рядовым сотрудникам, не устраивая диктатуры сесюрности?
"Крутить хвост" то надо не столько безопасникам (и примкнувшим к ним дежурным, пролюбившим сигналы от мониторинга), сколько "пациенту №0", впустившему заразу. Потому, что наверняка дело в том, что очередной упившийся смузи "молодой-перспективный-говорливый", весь из себя состоящий из "софт-скиллз" "профессионал" не соблюл элементарных требований сетевой гигиены и общих принципов информационной безопасности.
Впрочем, у дежурных, наверное, тоже теперь очень болит попа. Ведь настолько серьёзно ломающие инфраструктуру сервиса катастрофы не разражаются мгновенно, наверняка был какой-то сигнал накануне... сигнал, который проморгали...
И эти люди в своё время смеялись с того, что я отключаю системный блок рабочий на ночь...
Если у вас в угрозах есть "Проход с рабочего компа по какой-то ссылке с вероятностью полного разрушения всей инфраструктуры от этого действия", то вам можно фирму закрывать. Эта угроза реализуется 100% и от нее невозможно защитится.
Это все по другому исправлять надо. Люди могут идти по любым ссылкам. Это их право и это адекватное поведение в современном интернете. Задача безопасников сделать так чтобы это не приносило проблем.
Люди могут идти по любым ссылкам. Это их право и это адекватное поведение в современном интернете.
В рабочее время. В ITшной компании, работающей в удивительном мире хайлоада. Угу.
Ну, ходите на хотпуссидотком в рабочее время наздоровье. Это не привело к проблемам. Пока.
А я продолжу пользоваться доверием, благодаря которому в моих руках побывали и сорсы "танков" в полном объёме, и готовая к запуску копия альфа-версии будущего сервиса. И оправдывать его. В том числе потому, что я не придерживаюсь настолько халатного отношения к своей работе.
Какое-то рациональное зерно в Вашем рассуждении есть - только вот в контексте обсуждаемой ситуации увидеть его затруднительно.
В рабочее время. В ITшной компании, работающей в удивительном мире хайлоада. Угу.
Именно. И даже по рабочей необходимости бывает.
Ну, ходите на хотпуссидотком в рабочее время наздоровье. Это не привело к проблемам. Пока.
Люди смотрят порно. И куча технарей делают так чтобы это все работало и приносило денег владельцам порносайтов. Что вас тут удивляет? Откуда такая нелюбовь к порно?
Какое-то рациональное зерно в Вашем рассуждении есть - только вот в контексте обсуждаемой ситуации увидеть его затруднительно.
А в чем проблема? Вы серьезно рассчитываете что можно защитится административными мерами от 0-click атаки? В любой более-менее крупной фирме? Я вас расстрою. Это невозможно в принципе. Хотя стрелочника так найти просто. Если у вас именно такая цель, то без проблем.
Вся безопасность строится от модели угроз и средств защиты/реагирования на эти угрозы. 0-click атаку в модель включить можно при желании. А вот "административными мерами запретить ходить по интернету" как защиту от такой атаки включать не стоит. Это ни один аудит не пройдет.
Естественно без расследование, увольнение нельзя проводить. Т.к. всякое дерьмо может всплыть. А там вероятны и штрафы и даже уголовка. Снизу может давно стучали что есть проблемы, а до верха не доходило(серьёзность проблемы) или скрывалась/занижалась
не соблюл элементарных требований сетевой гигиены и общих принципов информационной безопасности.
Бывает и так конечно. Однажды меня попросили обеспечить временный доступ в Интернет для сотрудников организации, устанавливающей кассовые аппараты. Вроде бы можно было ожидать, что для них информационная безопасность не пустой звук. Но их искренне развеселил сложный пароль на WiFi.
их искренне развеселил сложный пароль на WiFi
Если это WPA - да. Что знают двое - знает и свинья. Какие гарантии, что кто угодно из неопределенного круга лиц не выложил этот пароль в онлайн базу WiFi точек, например?
Это был WPA2, и через ту точку доступа нельзя было попасть внутрь локальной сети. А реакцию вызвал именно длинный и достаточно безопасный пароль.
Ну, тогда можно задуматься, правда ли в том случае безопасный пароль действительно безопаснее чем 00000000. Неудобнее - да.
Сложный пароль, который знают несколько человек, лучше, чем простой пароль, который знают те же несколько человек. Если упростить пароли по причине того, что всё равно теоретически кто-то может слить пароль (зачем тогда использовать неудобные надёжные пароли?), тогда количество взломов увеличится.
Как это запоздала? То есть решать текущие проблем с этим же балбесом?
Тут вопрос в том, какими задачами был загружен условный балбес, и какие ресурсы ему выделялись. Сотрудник же не должен в свободное от работы время и за свой счёт организовывать и проверять систему резервного копирования? Хотя мне в принципе как-то приходилось приносить на работу свой личный внешний жёсткий диск чтобы скидывать резервные копии с сервера, потому что покупка запрошенного оборудования затягивалась. Но лучше по возможности предупредить проблемы, чем потом объяснять, что не виноват? Но в больших масштабах такое невозможно, и организация резервного копирования зависит в том числе от готовности руководства тратить деньги и оплачиваемое рабочее время сотрудников на то, что не приносит прибыли.
Вы любитель локальных копий размером в несколько петабайт?
Магнитная лента.
Поднимите мне веки, сударь. Не вижу предпосылок к наличию "нескольких петабайт" кода проекта.
Ну или Вы используете какой-то настолько молодёжный вид юмора, который я не могу распарсить и понять.
(впрочем, наличие гика, поднявшего локально чисто для того, чтобы "руку набить" полную копию слайса РуТуба вместе с "несколькими петабайтами" сгенерённой мусорной сэмпл даты, не окончательно исключена. Сам как-то баловался созданием .csv таблиц с произвольными данными на пару миллионов строк, чтобы тестировщикам было чем производительность импорта .csv (и самого модуля впоследствии) мерять - если на РуТубе не всё очень плохо с персоналом, такой кадр может быть и у них)
Там же в основном контент из телевизора, всякие российские сериалы и телешоу, телеканалы из своих архивов и перезальют заново.
то есть :
"исходники не утеряны - они есть со всеми багами в наличии
утеряны базы данных."
А Вас совсем не смущает что исходный код и базы, инфраструктура это абсолютно разные вещи?
Хотя куда там, Вам же главное написать, а не понять смысл написанного.
Нет времени думать, надо злорадствовать... Пока на волне хайпа можно словить лайков
исходный код и базы, инфраструктура это абсолютно разные вещи?
Отвечу без какого-либо троллинга, злорадства, итп. Только по существу.
Чаще всего, исходный код хранится в Git. В крупных компаниях, типа RuTube с высокой долей вероятности используется свой локальный git. Такой git, чаще всего, хранит всю историю изменений и каждый файл прямо в базе данных (практически в любой - mssql/mysql/pgsql/итд). Ну если не каждый файл, то историю изменений.
Так вот, судя по статье - пострадали базы данных. А значит, и исходный код с историями изменений вместе с ним. Да, наверняка кусочки кода остались на компах разработчиков, но его собирать - то ещё приключение.
Более того - в статье упоминается, что часть виртуалок тоже была удалена. А значит, и данные вместе с ними. Если среди них были шарды баз данных (вполне вероятно), то мы теряем ещё часть данных большого паззла, который надо будет как-то восстановить.
Вот и получается, что рутуб раз потерял виртуальные серверы и базы данных, то вполне возможно, на них располагался и исходный код. Возможно! Это нельзя опровергнуть или подтвердить, если ты не инсайдер.
Впрочем, гадать мы можем вечно, но посмотрим в итоге - как быстро смогут восстановить данные. В любом случае, 100% есть бэкапы, которые хранятся на магнитных лентах, но скорость чтения с них ужасно низкая. Даю прогноз, что данные будут восстанавливать до конца недели, и кучи видюшек не окажется на месте.
Вот в наличии холодных бэкапов на магнитной ленте я не уверен от слова совсем. Ленточные библиотеки любит кровавый энтерпрайз, а не эти ваши стильно-модно-молодёжные стартапы и примкнувшие к ним.
Даже они уже перестает любить. Проблем много, а толку чуть.
HDD копейки стоят. Обернуть хорошими системами гарантирующими неперезапись шифровальщиками и отлично выходит. Производительность выжимать не надо, можно огромные полки дисков ставить и совсем немного серверов.
Ну по ситуации с рутубом мы видим, как всё хорошо. А по соотношению цена/мб-надёжность хранения, ленточкам замены нет, как-бы аппологетам HDD хранения не хотелось обратного... Хотя от аппологетов тоже есть польза. Вполне себе живые ленточные накопители и картриджи к ним можно купить за относительный бесценок.
Тут вопрос не в том куда бекапы пишутся, а в процессе как все сделано. Ни одна самая надежная железка не дает ничего если ее неправильно использовать. И есть версия что любая система не использовалась вообще или использовалась неправильно.
А по соотношению цена/мб-надёжность хранения, ленточкам замены нет, как-бы аппологетам HDD хранения не хотелось обратного
Если у вас не петабайты данных, то цена дисков выходит смешной для любого энтерпрайза. Хранить все бекапы за последние 3 года это глупость. Для любой разумной системы без проблем.
Если петабайты, то про бекапы все забывают. Их даже просто копировать через сеть слишком долго и дорого. Появляется что-то вроде запасной реплики и всякие блочные s3 подобные хранилища. И много-много регламентов и процессов для того чтобы это было надежно.
Я однажды собирал куски продуктовой базы системы из более чем сотни писем (вот такой у нас был тогда процесс разработки - "мы там что-то поправили, накати на базу этот скрипт"). Самое страшное, что она тогда собралась и заработала. Чуть не поседели все нафиг.
git не svn - даже если уничтожили все данные на серверах - копия есть у каждого разработчика, а это как минимум близкая к последней версия master/main + потенциально все ветки разработки
Да, я же писал выше, что код есть на компах разработчиков, и что возникает сразу куча проблем, если этим заниматься:
1) Как быстро опросить всех разрабов, чтобы узнать, у кого была самая последняя ветка, и взять его версию?
2) Кто знает, какие проекты вообще были, чтобы можно было 100% сказать, что восстановили все?
3) Как восстановить настройки проектов, с выдачей прав - кто владелец, у кого должен быть доступ к проекту и веткам, кто может, а кто не может аппрувить?
И ещё 100500 проблем которые возникают. И заметьте - git это лишь одна из систем, которых нужно восстановить сотни. И здесь заниматься микроменеджментом по новой настройке всех проектов - такое себе занятие. Лучше потратить время и восстановить все серверы как они были, чем заниматься этим.
Git не хранит код в базе данных - у него своя база на диске (по крайней мере по умолчанию такой формат). И при клонировании репозитория выкачивается весь код целиком, так что вполне вероятно, что у программистов осталась полная локальная копия кода.
Это если программистам дозволялось программировать на локальных машинах напрямую, есть вероятность что для разработки использовались тонкие клиенты, и доступ тоже был уничтожен в процессе взлома. Тогда всё сложнее.
Другой вариант: код цел, файлы видео целы, однако SQL-база (или что они там использовали) хранилась на серверах и была уничтожена безвозвратно. В этом случае могли пропасть все данные о пользователях и т.д.
Предположим, что в компании больше N микросервисов, n (>0) из них "запилили и забыли" (т.е их больше не разрабатывают), а потому локальной копии нет ни у кого из разработчиков. И без этих n-микросервисов приложение работать не будет. Что тогда делать?
К сожалению не всегда — целиком (если конечно не монорепозиторий).
Вот решил кто-то что общий код надо выносить в библиотеки (например потому что якобы быстрее сборка) и грузить с локального nexus и все, теперь исходники этого общего кода уже не у всех разработчиков проекта, и совсем не факт что новые.
Строго говоря "90% резервных копий" и "резервные копии 90% данных" - совершенно разные вещи.
Например в случае пожара в серверной/датацентре может сгореть к чертям всё, включая сервера и хранилища резервного копирования с 90% резервных копий. Но если в IT dep не идиоты, то практически 100% данных можно восстановить из резервных копий, хранящихся offsite (коих может быть 10% от общего количества). Потеряются только те данные, копии которых в offsite хранилище отправить не успели (в современных реалиях, когда offsite-хранилище чаще не сурово охраняемый подвал с кассетами и службой доставки, а S3 glacier этот лаг совсем небольшой: знаю компании, которые хранят бэкапы только offsite)
Но я, естественно, совершенно не уверен, что журналисты и rutube именно это имели в виду
Строго говоря "90% резервных копий" и "резервные копии 90% данных" - совершенно разные вещи.
Строго говоря, не понятно, зачем рассказывать про "90% резервных копий". Кому это в рамках новостей (а не постмортема) интересно? Бэкап - он или есть (и насколько старый) или его нет, а 90%, 74 или 1% копий бэкапов - бессмысленная информация.
Похоже, что рутубовцам что-то хотелось сказать, но нечего было.
Да вообще в принципе непонятно, как сервис в наше время можно так наглухо положить, это какая-то проблема юного вконтактика года так 2009, когда там некоторые группы вайпали сотнями альбомов с разноцветным Онотоле. И то там через пару лет прикрутили возможность бэкапа в админку самих групп, то есть даже ТП ВК можно было не теребонькать по такой ерунде.
Очень печально, что наши сервисы так легко сломать =(
Хотя, против РФ всё мировое IT сообщество восстает . . .
Как бы ГосУслуги со всеми потрохами не взломали в обозримом будущем =(
Да ну нет же, "ваши" сервисы невозможно взломать, они же соответствуют сотням и тысячам пунктов в разных законах и подзаконных актах, сертификаты все есть и так далее. Что может мировое сообщество против буквы Закона и импортозамещения?!
Так это же не взлом, а специальная операция по оптимизации энергоэффективности "ваших" сервисов
Судя по всему там уже нечего восстанавливать. Все придётся переделывать
Какой-то бред написан, даже и обсуждать нечего. Понятно, что просто увиливают от ответа.
Поэтапное восстановление блоков файловой системы на некоторых серверах… Что? Поражено 90% бекапов… Что? Это значит, что копии есть только у 10% данных, или что это значит?
Как вообще может быть поражена вся инфраструктура? Ну, чисто технически, как?
Надеюсь, когда-то кто-то выложит нормальный постмортем. Пока кажется, что пресс релизы пишет маркетолог, который иногда ухом прижимается к двери инфраструктурного департамента и пытается и матерных воплей что-то перевести на русский.
У меня сложилось такое ощущение что был запущен вирус-шифровальщик, только после него обычно такие масштабные последствия.
Как должна быть устроена инфраструктура, чтобы шифровальщик скушал базы данных и бекапы?
Например бекапные сервера в домене, и отсутствие физических копий на лентах. А даже если они есть то пока для их развертывания сначала надо заново поднять Домен, поднять бекапные сервера и уже с них использовать ленты.
Рут доступ с одного аккаунта к большей части серверов. Получаем доступ к этому аккаунту и одному ноуту и все. За ночь можно пошифровать большую часть баз, инфры и бекапов.
Как-как, очень просто может быть поражена. Например, тем, что RTO восстановления из резервных копий «внезапно» оказался сильно больше, чем время толпы людей, руками восстанавливающей, допустим, разметку на дисках. Или тем, что оператор инфраструктуры и оператор СРК - одно и то же лицо/группа лиц. Или там совсем нет механики автоматической конфигурации новых серверов, потому что толпа людей, руками их настраивающая, для штатного случая «добавляем два сервера в неделю» дешевле. Или пароход; возможных причин много, можно каждый год по книге выпускать.
Но сейчас ждать от этих людей в огне какой-то осмысленной коммуникации с внешним миром действительно не стоит. Aviate, navigate, communicate.
В одной супер крупной по российским меркам организации я работал дежурным сисадмином. И был период, когда я имел рутовый доступ к почти всем серверам организации - просто знал пароли на каждый тип серверов, которых (типов) было не очень много. И в централизованную СРК доступ тоже имел абсолютный.
Все это достаточно быстро поменялось, и я сейчас с ужасом вспоминаю ту ситуацию. Но речь не о том.
Сейчас пытаюсь сконструировать и все равно не понимаю, как я мог в тех тепличных условиях устроить полное уничтожение. Ну может если в крон всех серверов запихать самоуничтожение (отключение ссх и удаление важных файлов по маске?) - и то бекапы на независимом носителе живы останутся. Ну, с них долго восстанавливаться, да и если там вместо лент обычные схд используются…
Ладно, убедили. Это возможно.
Проблема в том, что они всё же коммуницируют, но делают это крайне странно. Выдержки из их твиттера:
Мы продолжаем вести восстановительные работы. Напомним, что платформа легла утром 9 мая, а пресс-служба заявила о крупнейшей в истории компании кибератаке. Как известно, APT – это спланированные и - что важно - дорогостоящие атаки. Кто-то очень хотел помешать RUTUBE показать парад Победы и праздничный салют.
Не грех вспомнить, какие битвы выигрывали наши. Битва за RUTUBE продолжается. Держим за вас ??, ребята!
При всей серьёзности ситуации это не может не льстить: кто-то изо всех сил пытался помешать нам провести трансляцию главного события сегодняшнего дня – Парада Победы.
С радостью покажем его в записи и делаем все, чтобы в очередной раз победить.
От RUTUBE, как обычно, ожидают молниеносного решения всех проблем. Что ж, мы привыкли к завышенным требованиям.
Однако напомним, что волшебных палочек в реальной жизни не существует. Зато существует большая команда, которая более 15 часов работает над восстановлением платформы, которую, напомним, в последние месяцы посещают десятки миллионов пользователей и на которую грузят десятки тысяч видео.
Пресс-служба активно работает, на самом деле. По крайней мере со своей стороны могу сказать, что люди отзывчивые, отвечают практически сразу даже по ночам и, где могут, идут на контакт. Вопрос в другом. К сожалению, из сервиса и так тяжело было вытянуть фактические данные ещё до падения сайта. По неизвестной мне причине, информацию передают строго дозированно и без особых подробностей. Возможно, отчёт о поломке выпустят позже. Пока всё, что известно, я изложила в материале чуть ли не слово в слово, как нам передали.
Сложно открыто и подробно освещать факапы, когда название владельца твоего юрлица начинается на «Газпром».
Но, это вообще как минимум в России распространённое явление - до последнего рассказывать, что всё хорошо, что вот-вот, ещё немного, в принципе всё идёт по плану, а потерянный титан всё равно был нам не нужен (да и пилоту не нравилось его водить). При этом такое поведение встречается у всех: у государства и частников, больших и маленьких. В этой же теме, как и во многих других аналогичных (ну про тот же пожар в ДЦ OVH недавний), можно наблюдать очень заплюсованные язвительные комментарии, которые совершенно не помогают эту ситуацию даже начать исправлять.
Как вообще может быть поражена вся инфраструктура? Ну, чисто технически, как?
Как в Яндексе намедни было, физической сменой юрлица :)
^ это только пример. В душе не чаю, что там за кавардак на самом деле творится.
Как вообще может быть поражена вся инфраструктура? Ну, чисто технически, как?
Дайте мне в руки Терраформ, и я вам покажу!
P.S.: Если ваша компания не такая молодежная, то админский доступ к СХД тоже сканает.
В постмортеме напишут, что забыли вовремя обновить средства защиты:
![](https://habrastorage.org/getpro/habr/upload_files/b33/81b/7be/b3381b7be1d27ab421b880bd855f3403.jpeg)
Кстати, не исключено. В т. ч. не исключено, что это и есть реальная причина начала инцидента.
Иные мастодонты от IT умудряются по КД домены терять за неуплату, да сертификаты протухающие не менять, пока саппорт под валом заявок не треснет. А ведь это рутинные, но важнейшие, действия...
Иные мастодонты от IT умудряются по КД домены терять за неуплату, да сертификаты протухающие не менять, пока саппорт под валом заявок не треснет. А ведь это рутинные, но важнейшие, действия...
Да у всех такое было. И у Майкрософта домен отваливался, и у Гугла сертификаты протухали (на каких-то забытых side-полумёртвых-проектах).
Естественно, это же назовут не утеря, а байтоизменение.
такие взломы в последнее время достигалось одним и тем же приемом:
проникновение в сеть, горизонтальная эскалация и получение доступа над консолью управления систем виртуализации (VmWare или аналог), уничтожение серверов и блочных устройств с консоли виртуализации.
Обычно, для экономии средств системы бэкапирования размещается в той же виртуальной инфраструктуре, поэтому и бэкапы уничтожаются тоже. Ленты сейчас не в почете, они если и остались, то только в банках, телекомах и чем-то подобном.
Не потеряли данные, а агрессивно оптимизировали хранилище (с)
- У нас есть скриншот!
- Ты хотел сказать снепшот?
- Нет...
"У нас, в роте, был аналогичный случай..." как говорится в одном анекдоте. Серьезная система, бакап бакапов и сверху бакап состояния бакапов и бакап этих состояний... Ну все как обычно, больше бакапов богу бакапов. Ну и пришла беда откуда не знали и понадобилось восстановиться. Причем кусочек, всего лишь оперативную базу одного, не самого большого, завода. Ну, закончилось все как всегда. Бакапы не разворачиваются, сервера не стартуют... Уже и побайтовую копию хранилища с нужным бакапом привезли к месту происшествия и т.д. Нет! Все! Капец! Жопа!
А восстановилось все за 20-30 минут... Когда узнали что остался нормальный бакап, у стажера, которого взяли меньше месяца назад и у него был доступ к снапшоту базы, для тренировок на ней. Он на нем и бакапы тренировал. Вот только этот то бакап живым и остался.
Увы, это не исключение, а скорее правило: бэкапы без регулярных (и порой, как в армии - внезапных) учений по disaster recovery гораздо менее полезны, чем представляется.
" не исключение, а скорее правило: бэкапы без регулярных (и порой, как в армии - внезапных) учений по disaster recovery гораздо менее полезны, чем представляется. "
1) для понимания этого нужно иметь квалификацию - знания и опыт, который есть далеко не у всех начальников. Кресло есть, вальяжный зад в кресле тоже есть, а вот мозгов... как обычно.
2) вытекающее из 1) - далеко не все и не везде готовы платить за потраченные на это рабочее время и ресурсы.
В итоге получаются "ойц, ситуации".
Да неужели?
Ну вот так и блокируй ютуб) рутуб с перепоя сами сотрут, apt-атаки у них))
Говорят, что где-то в сети есть скриншот административной консоли... Никто не встречал? Интересно было бы посмотреть.
"...90% резервных копий..."
и вот это IT получает по 150к в месяц? а за что?!
Потерь данных нет
На 90% это сделал кто-то из работников, пусть ищут недовольных/уволенных и просто латентных неадекватов. А на хакеров можно все списать
Несколько лет назад официальный сайт "Зенита" лежал полдня из-за не оплаты домена. И это не чей-то персональный блог, а сайт известного футбольного клуба с немалым бюджетом. Это к вопросу про правильную инфру, бэкапы и прочее. И даже при самых крутых средствах защиты остается человеческий фактор.
Там в основном дублируются массовые ТВ-передачи. Думаю, телеканалам не будет проблемой их перезалить..
Техслужба Rutube отрицает слух об утере исходного кода сайта сервиса