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

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

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

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

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

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

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

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

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

Не дать проблеме стать хуже, чем она есть сейчас:

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

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

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

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

Полностью разобраться в проблеме:

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

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

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

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

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

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

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

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

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

Например:

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

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

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

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

... И наконец

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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