Взломан сервер – что делать?

Я подозреваю, что один или несколько моих серверов взломаны хакером, вирусом или другим механизмом:

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

• Как мне возобновить работу служб?

• Как мне предотвратить повторение этого снова?

• Есть ли лучшие практики или методики извлечения уроков из этого инцидента?

• Если бы я хотел составить план реагирования на подобное, с чего бы я начал? Должно ли это быть частью моего плана аварийного восстановления и обеспечения непрерывности бизнеса?

 

Ответ 1

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

 

Не паникуйте.

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

 

Трудно определить, когда произошло вторжение.

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

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

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

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

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

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

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

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

 

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

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

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

Проверьте другие системы. Обратите особое внимание на другие службы, работающие в интернете, и на те, в которых хранятся финансовые или другие коммерчески важные данные.

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

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

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

 

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

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

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

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

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

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

 

Почему бы просто не "починить" обнаруженный эксплойт или руткит и не вернуть систему в рабочее состояние?

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

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

 

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

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

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

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

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

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

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

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

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

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

 

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

Например:

Был ли недостаток, который позволил людям проникнуть на ваш сайт, известной ошибкой в коде производителя, для которой было доступно исправление? Если да, то нужно ли вам пересмотреть свой подход к исправлению приложений на серверах, выходящих в интернет?

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

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

Был ли дефект вызван проблемой, связанной с тем, как был развернут сервер или прикладное программное обеспечение? Если да, то используете ли вы автоматизированные процедуры для создания и развертывания серверов, где это возможно? Это очень помогает поддерживать постоянное "базовое" состояние на всех ваших серверах, минимизируя объем пользовательской работы, которую приходится выполнять на каждом из них, и, следовательно, уменьшать возможность совершения ошибки. То же самое касается развертывания кода: если для развертывания последней версии вашего веб-приложения требуется выполнить что-то "особенное", постарайтесь автоматизировать это и обеспечить последовательность действий.

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

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

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

 

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

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

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

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

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

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

 

...И наконец

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

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

 

Ответ 2

Похоже, что вы немного не в себе; это нормально. Позвоните своему начальнику и начните переговоры о выделении бюджета на обеспечение безопасности в чрезвычайных ситуациях. Затем вам нужно попросить кого-нибудь (PFY, коллегу, менеджера) начать обзванивать компании, которые специализируются на реагировании на инциденты безопасности. Многие из них могут ответить в течение 24 часов, а иногда и быстрее, если у них есть офис в вашем городе.

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

 

Затем вам нужно...

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

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

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

Самое важное – остановить потери. Определите и перекройте доступ к скомпрометированным сервисам, данным и машинам. Желательно выдернуть сетевой кабель, а если это невозможно, то отключить питание.

Затем необходимо выявить злоумышленника и закрыть дыру (дыры). Предположительно, у злоумышленника больше нет интерактивного доступа, поскольку вы отключили сеть. Теперь вам нужно идентифицировать, задокументировать (с помощью резервных копий, скриншотов и собственных заметок; а лучше даже извлечь диски из пострадавших серверов и сделать полную копию образа диска), а затем удалить весь код и процессы, которые он оставил после себя. Эта следующая часть будет неудачной, если у вас нет резервных копий; вы можете попытаться отсоединить злоумышленника от системы вручную, но вы никогда не будете уверены, что получили все, что он оставил. Руткиты очень скрытны, и не все из них можно обнаружить. Лучшей реакцией будет определение уязвимости, которую он использовал для проникновения, создание копий образов пораженных дисков, а затем удаление пораженных систем и перезагрузка с заведомо исправной резервной копией. Не доверяйте слепо своей резервной копии; проверьте ее! Устраните или закройте уязвимость до того, как новый узел снова войдет в сеть, а затем выведите его в режим онлайн.

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

 

Ответ 3

У CERT есть документ Steps for Recovering from a UNIX or NT System Compromise, который является хорошим руководством. Конкретные технические детали в этом документе несколько устарели, но многие общие советы по-прежнему применимы.

Краткое изложение основных шагов таково.

1. Проконсультируйтесь с политикой безопасности или руководством.

2. Отключите компьютер от сети.

3. Проанализируйте вторжение, просмотрите журналы, выясните, что пошло не так.

4. Восстановите все.

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

6. Обновите системы, чтобы это не повторилось.

7. Возобновите работу.

8. Обновите свою политику безопасности на будущее и задокументируйте ее.