Вопрос: Переустановить после корневого компромисса?


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

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

Я надеюсь получить лучшее представление о том, почему больше людей не просто взлетают и ядерное оружие система с орбиты.

Вот несколько моментов, которые я хотел бы рассмотреть.

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

56
2018-05-08 09:32


Источник




Ответы:


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

Вот что обычно входит в это деловое решение:

  • Сколько будет стоить нам время простоя в измеримой сумме?
  • Сколько это будет стоить нам, когда нам нужно немного рассказать клиентам о том, почему мы были внизу?
  • Какие еще действия я должен буду отвлечь людей от переустановки? Какова цена?
  • У нас есть правильные люди, которые знают, как воспитывать систему без ошибок? Если нет, что это будет стоить мне, поскольку они устраняют ошибки?

И поэтому, когда вы добавляете такие затраты, можно считать, что продолжение «потенциально» все еще скомпрометированной системы лучше, чем переустановка системы.


30
2018-05-08 09:58



Пожалуйста, найдите время и прочитайте отличный пост Ричарда Бейтлиха на тему "Дешевый ИТ в конечном счете дорогой" Подводить итоги, «Не стоит оставлять скомпрометированные системы, работающие на предприятии, из-за« повышения производительности », когда система должна быть прервана для обеспечения анализа безопасности». - Josh Brower
Я подумал об этом некоторое время и не могу придумать причины, по которым было бы разумнее развернуть систему, которая может быть скомпрометирована. - duffbeer703
Я бы не хотел разворачивать или держать в сети систему, которую я знаю, тоже был скомпрометирован. Но это я как техник. И я не согласен с Бейтлихом в этом, потому что, хотя он говорит, что это упражнение по предотвращению потерь, бизнес не рассматривает его как таковой. Бизнес смотрит на это с точки зрения риска, и это справедливо. Например, они могут рассчитывать на страхование, чтобы покрыть их в случае судебного разбирательства, и именно так они справляются с риском. И Ричард не взвешивает это в своих аргументах. Я не сказал, что согласен с этим мышлением, но именно так вы это понимаете, о чем спрашивает OP. - K. Brian Kelley
Я также не соглашусь в определенной степени с Бейтилихом, но позвольте мне хотя бы процитировать его последний комментарий, потому что он добавляет еще одно измерение в эту дискуссию: «измерение» риска - это шутка. Измерение потерь в основном невозможно. (Скажите, сколько вы теряете, когда конкурент крадет ваши данные, чтобы улучшить свои продукты в течение следующих 10 лет). Измерительная стоимость - это упражнение, которое, скорее всего, принесет заслуживающие доверия результаты, поскольку вы можете отслеживать деньги, оставив компанию. Стоимость измерения - это то, что я называю в этом посте. Я бы хотел измерить потери, но это не принесет реальных чисел. Измерение риска - гигантская догадка ». - Josh Brower
... и все же вся наша страховая отрасль и гражданская судебная система основаны на измерении риска и определении долларовых показателей по убыткам. Таким образом, очевидно, что подход является приемлемый для ответственных лиц. - Brian Knoblauch


Основываясь на сообщении I написал много лет назад когда я все еще мог беспокоиться о блоге.

Этот вопрос постоянно повторяется жертвами хакеров, взломавших их веб-сервер. Ответы очень редко меняются, но люди продолжают задавать вопрос. Я не знаю, почему. Возможно, людям просто не нравятся ответы, которые они видели при поиске помощи, или они не могут найти кого-то, кому они доверяют, чтобы дать им советы. Или, возможно, люди читают ответ на этот вопрос и слишком сильно сосредотачиваются на 5% того, почему их случай является особенным и отличается от ответов, которые они могут найти в Интернете, и пропустить 95% вопроса и ответа, где их случай близок к тому же как тот, который они читают в Интернете.

Это подводит меня к первому важному самородку информации. Я действительно ценю, что ты особенная уникальная снежинка. Я ценю, что ваш сайт тоже, поскольку это отражение вас и вашего бизнеса или, по крайней мере, ваша напряженная работа от имени работодателя. Но кому-то извне, глядя на вопрос о том, будет ли человек компьютерной безопасности искать проблему, чтобы попытаться помочь вам или даже самому нападающему, очень вероятно, что ваша проблема будет по меньшей мере на 95% идентична каждому другому делу, когда-либо смотрел.

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

Вы только что узнали, что ваш сервер (ы) взломан. Что теперь?

Без паники. Абсолютно не спешите, и абсолютно не пытайтесь притворяться, что никогда не происходило и не действовало вообще.

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

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

Остановите проблему от ухудшения, чем она уже есть:

  1. Первое, что вам нужно сделать, это отключить затронутые системы из Интернета. Каковы бы ни были другие проблемы, если система, подключенная к сети, позволит продолжить атаку. Я имею в виду это буквально; заставить кого-то физически посещать сервер и отключать сетевые кабели, если это то, что требуется, но отключите жертву от своих грабителей, прежде чем пытаться сделать что-нибудь еще.
  2. Измените все свои пароли для всех учетных записей на всех компьютерах, находящихся в той же сети, что и скомпрометированные системы. Нет. Все счета. Все компьютеры. Да, вы правы, это может быть излишним; с другой стороны, это может и не быть. Вы не знаете в любом случае, не так ли?
  3. Проверьте другие системы. Уделите особое внимание другим службам, обращенным к Интернету, и тем, у кого есть финансовые или другие коммерчески чувствительные данные.
  4. Если система содержит личные данные пользователя, сделайте полное и откровенное раскрытие информации любому потенциально затронутому сразу. Я знаю, что это сложно. Я знаю, что это будет больно. Я знаю, что многие компании хотят поднять эту проблему под ковром, но я боюсь, что вам просто придется с этим справиться.

Все еще не решался сделать этот последний шаг? Я понимаю, я знаю. Но посмотрите на это вот так:

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

Помните, что я сказал ранее? Плохая вещь уже произошла, Теперь единственный вопрос, насколько хорошо вы справляетесь с этим.

Полностью понять проблему:

  1. НЕ помещайте затронутые системы обратно в сеть до тех пор, пока этот этап не будет полностью завершен, если вы не хотите быть тем человеком, чей пост стал решающим моментом для меня, фактически решая написать эту статью. Я не привязываюсь к почте, чтобы люди могли смеяться дешево; Я свяжусь, чтобы предупредить вас о последствиях неудачи после этого первого шага.
  2. Изучите «атакуемые» системы, чтобы понять, как атаки удались скомпрометировать вашу безопасность. Приложите все усилия, чтобы узнать, откуда происходят атаки », чтобы вы поняли, какие проблемы у вас есть, и вам нужно обратиться, чтобы сделать вашу систему безопасной в будущем.
  3. Изучите «атакуемые» системы еще раз, на этот раз, чтобы понять, куда пошли атаки, чтобы вы поняли, какие системы были скомпрометированы в атаке. Убедитесь, что вы следите за указателями, которые предполагают, что скомпрометированные системы могут стать трамплином для дальнейшей атаки на ваши системы.
  4. Убедитесь, что «шлюзы», используемые при любых атаках, полностью понятны, чтобы вы могли начать их правильно закрывать. (например, если ваши системы были скомпрометированы атакой SQL-инъекции, то вам не только нужно закрыть конкретную ошибочную строку кода, в которую они вошли, вы бы хотели проверить весь свой код, чтобы узнать, не ошибся ли тот же тип ошибки был сделан в другом месте).
  5. Поймите, что атаки могут быть успешными из-за нескольких ошибок. Часто атакам удается не найти одну серьезную ошибку в системе, а навязать несколько проблем (иногда незначительных и тривиальных сами по себе), чтобы скомпрометировать систему. Например, при использовании SQL-инъекций для отправки команд на сервер базы данных обнаружение атакующего веб-сайта / приложения выполняется в контексте административного пользователя и использование прав этой учетной записи в качестве шага для компрометации других частей система. Или как хакеры любят называть это: «Еще один день в офисе, пользуясь распространенными ошибками, которые делают люди».

Сделайте план восстановления и верните свой веб-сайт онлайн и придерживайтесь его:

Никто не хочет быть в сети дольше, чем должен быть. Это данность. Если этот веб-сайт является механизмом генерации доходов, то давление на его возвращение в оперативном режиме будет интенсивным. Даже если на карту поставлена ​​единственная репутация вашей компании / вашей компании, это все еще вызывает сильное давление, чтобы быстро восстановить ситуацию.

Однако не поддавайтесь соблазну слишком быстро вернуться в Интернет. Вместо этого переместите как можно быстрее, чтобы понять, что вызвало проблему, и решить ее до того, как вы вернетесь в Интернет, иначе вы почти наверняка снова станете жертвой вторжения, и помните: «Чтобы получить взломанный один раз, можно классифицировать как несчастье; чтобы снова взломать сразу после этого выглядит как небрежность »(с извинениями перед Оскаром Уайльдом).

  1. Я предполагаю, что вы поняли все проблемы, которые привели к успешному вторжению в первую очередь, прежде чем вы начнете этот раздел. Я не хочу преувеличивать случай, но если вы этого не сделали, тогда вам действительно нужно. Сожалею.
  2. Никогда не платите деньги за шантаж / защиту. Это признак легкой метки, и вы не хотите, чтобы эта фраза когда-либо использовалась для описания вас.
  3. Не поддавайтесь соблазну вернуть один и тот же сервер (ы) в онлайн без полной перестройки. Скорее всего, нужно будет создать новую коробку или «вывести сервер с орбиты и выполнить чистую установку» на старом оборудовании, чем было бы проверять каждый угол старой системы, чтобы убедиться, что она чиста, прежде чем вернуть ее обратно онлайн снова. Если вы не согласны с этим, вы, вероятно, не знаете, что на самом деле означает, чтобы система была полностью очищена, или процедуры развертывания вашего сайта являются нечестивым беспорядком. Предположительно, у вас есть резервные копии и тестовые развертывания вашего сайта, которые вы можете использовать только для создания сайта в реальном времени, а если вы этого не сделаете, это не ваша самая большая проблема.
  4. Будьте очень осторожны с повторным использованием данных, которые были «живы» в системе во время взлома. Я не буду говорить «никогда не делай этого», потому что ты просто проигноришь меня, но, честно говоря, я думаю, что вам нужно учитывать последствия хранения данных, когда вы знаете, что не можете гарантировать его целостность. В идеале вы должны восстановить это из резервной копии, сделанной до вторжения. Если вы не можете или не будете этого делать, вы должны быть очень осторожны с этими данными, потому что это испорчено. Особенно вам следует знать о последствиях для других, если эти данные принадлежат клиентам или посетителям сайта, а не напрямую вам.
  5. Внимательно следите за системой (системами). Вы должны решить сделать это как непрерывный процесс в будущем (подробнее см. Ниже), но примите дополнительные усилия, чтобы быть бдительными в течение периода, сразу после вашего сайта, возвращающегося в Интернете. Злоумышленники почти наверняка вернутся, и если вы обнаружите, что они пытаются пробиться снова, вы, несомненно, сможете быстро увидеть, действительно ли вы закрыли все отверстия, которые они использовали, плюс все, что они сделали для себя, и вы можете собрать полезные информацию, которую вы можете передать своим местным правоохранительным органам.

Снижение риска в будущем.

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

Вы не можете устранить риск. Вы даже не должны пытаться это сделать. Однако вам следует понять, какие риски для безопасности важны для вас, и понять, как управлять и уменьшать влияние риска и вероятностьчто риск будет иметь место.

Какие шаги вы можете предпринять, чтобы уменьшить вероятность успешной атаки?

Например:

  1. Был ли недостаток, который позволил людям проникнуть на ваш сайт, известную ошибку в коде поставщика, для которой был доступен патч? Если да, вам нужно пересмотреть свой подход к тому, как вы устанавливаете приложения на своих серверах, обращенных к Интернету?
  2. Был ли недостаток, который позволил людям проникнуть на ваш сайт неизвестной ошибкой в ​​коде поставщика, для которого патч не был доступен? Я, безусловно, не выступаю за изменение поставщиков, когда что-то вроде этого укусит вас, потому что у всех есть свои проблемы, и вы преодолеете платформы в течение года максимум, если вы примете такой подход. Однако, если система постоянно позволяет вам спуститься, вы должны либо перейти на нечто более надежное или, по крайней мере, перестроить свою систему, чтобы уязвимые компоненты оставались завернутыми в вату и как можно дальше от враждебных глаз.
  3. Был ли недостаток ошибкой в ​​коде, разработанном вами (или подрядчиком, работающим на вас)? Если да, вам нужно пересмотреть свой подход к тому, как вы одобряете код для развертывания на своем сайте? Может ли ошибка быть поймана с улучшенной тестовой системой или с изменениями в вашем стандарте кодирования (например, в то время как технология не является панацеей, вы можете уменьшить вероятность успешной атаки SQL-инъекций, используя хорошо документированные методы кодирования ).
  4. Был ли недостаток из-за проблемы с развертыванием сервера или прикладного программного обеспечения? Если да, используете ли вы автоматические процедуры для сборки и развертывания серверов, где это возможно? Это отличная помощь в поддержании согласованного «базового» состояния на всех ваших серверах, что сводит к минимуму количество пользовательской работы, которая должна выполняться на каждом из них, и, следовательно, мы надеемся, минимизируем возможность ошибки. То же самое происходит с развертыванием кода - если вам требуется что-то «специальное» для развертывания последней версии вашего веб-приложения, тогда постарайтесь его автоматизировать и убедиться, что это всегда выполняется согласованным образом.
  5. Может ли вторжение было обнаружено ранее с лучшим мониторингом ваших систем? Разумеется, 24-часовой мониторинг или система «по вызову» для вашего персонала могут оказаться неэффективными с точки зрения затрат, но есть компании, которые могут отслеживать ваши услуги в Интернете для вас и предупреждать вас в случае возникновения проблемы. Вы можете решить, что не можете позволить себе это или не нуждаетесь в нем, и это просто прекрасно ... просто учтите это.
  6. Используйте инструменты, такие как tripwire и nessus, где это необходимо, но не используйте их вслепую, потому что я так сказал. Потратьте время, чтобы узнать, как использовать несколько хороших инструментов безопасности, подходящих для вашей среды, регулярно обновлять эти инструменты и регулярно их использовать.
  7. Подумайте о том, чтобы нанимать экспертов в области безопасности для регулярной проверки безопасности вашего веб-сайта. Опять же, вы можете решить, что не можете позволить себе это или не нуждаетесь в нем, и это просто прекрасно ... просто учтите это.

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

Если вы решите, что «риск» нижнего этажа вашего домашнего наводнения высок, но недостаточно высок, чтобы гарантировать перемещение, вы должны по крайней мере переместить незаменимые семейные реликвии наверху. Правильно?

  1. Можете ли вы уменьшить количество услуг, напрямую связанных с Интернетом? Можете ли вы сохранить какой-то разрыв между вашими внутренними услугами и услугами, связанными с Интернетом? Это гарантирует, что даже если ваши внешние системы будут скомпрометированы, вероятность использования этого в качестве трамплина для атаки на ваши внутренние системы ограничена.
  2. Вы храните информацию, которую вам не нужно хранить? Вы храните такую ​​информацию «в Интернете», когда ее можно архивировать где-то в другом месте. В этой части есть два момента; очевидным является то, что люди не могут украсть у вас информацию, которую у вас нет, и, во-вторых, чем меньше вы храните, тем меньше вам нужно поддерживать и кодировать, и поэтому шансов на ошибку ваш дизайн кода или систем.
  3. Используете ли вы принципы «наименьшего доступа» для своего веб-приложения? Если пользователям нужно только читать из базы данных, то убедитесь, что учетная запись, которую использует веб-приложение для обслуживания, имеет только доступ на чтение, не разрешает доступ на запись и, конечно, не доступ к системному уровню.
  4. Если вы не очень разбираетесь в чем-то, и это не важно для вашего бизнеса, подумайте об аутсорсинге. Другими словами, если вы запустите небольшой веб-сайт, рассказывающий о написании кода настольного приложения, и решите начать продажу небольших настольных приложений с сайта, тогда рассмотрите «аутсорсинг» вашей системы заказа кредитных карт кому-то вроде Paypal.
  5. Если это вообще возможно, сделайте практику восстановления системы скомпрометированных систем частью плана аварийного восстановления. Это, возможно, просто еще один «сценарий бедствия», с которым вы могли столкнуться, просто один с собственным набором проблем и проблем, которые отличаются от обычной «серверной комнаты, загоревшейся» / «был захвачен гигантским сервером, который ест кожуры». (редактировать, за XTZ)

... И наконец

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

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


28
2018-06-14 21:00



+1, очень хороший, очень полный. - Avery Payne
Спасибо, Эйвери, я не уверен, что твоя фотография не говорит о многом гораздо быстрее, но сейчас у меня нет голосов! - Rob Moir
Я бы хотел, чтобы у SF была возможность отмечать ответы в качестве избранных. Также кажется, что есть много ответов, которые я видел, что я хотел бы либо перекрестно, либо должен быть перекрестным. В любом случае, я поклонник тщательных ответов - вам лучше знать все, а не знать только некоторые из них. - Avery Payne
Одна вещь, которую вам нужно добавить, СДЕЛАЙТЕ ЭТО ЧАСТЬ ВАШЕГО ПЛАНА DR! У небольших компаний может быть только несколько серверов, об этом нужно подумать, прежде чем это произойдет, все, что вы можете сделать, когда это произойдет, - это изолировать, оценить, уничтожить, перестроить. - XTZ
Хороший XTZ, это происходит в списке. - Rob Moir


Всегда наносить его с орбиты. Это единственный способ быть уверенным.

alt text

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

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


18
2018-06-14 20:50





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

Это, как говорится, в системах, где я уверен, что знаю метод ввода и полную степень ущерба (сплошные журналы вне машины, как правило, с IDS, возможно, SELinux или что-то подобное, ограничивающее сферу вторжения), I сделали очистку без переустановки, не чувствуя себя слишком виноватой.


5
2018-05-08 09:40





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

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


2
2018-05-08 09:59





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

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

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

2
2018-05-08 11:16