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

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

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

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

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

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

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

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

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

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

Основанный на посте, который я написал давным-давно, когда я все еще мог быть обеспокоен блогом.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Например:

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

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

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

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

... И наконец

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

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

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

_{(источник: flickr.com )}

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

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

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

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

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

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

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

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

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