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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мешайте проблеме стать хуже, чем это уже:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Например:

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

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

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

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

... И наконец

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

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