Это канонический вопрос о безопасности серверов – реагирование на инциденты по нарушению безопасности (взлом)
Также смотрите:

• Советы по защите сервера LAMP
• Переустановить после компрометации корневой учетной записи?

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

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

Оригинальная версия

2011.01.02 – Я еду на работу в 21:30 в воскресенье, потому что наш сервер каким-то образом был скомпрометирован, что явилось причиной атаки DOS на нашего провайдера. Доступ серверов к Интернету был отключен, что означает, что более 5-600 сайтов наших клиентов сейчас не работают. Это мог быть хак FTP или какая-то уязвимость в коде где-то. Я не уверен, пока не доберусь туда.

Как я могу быстро выяснить, что случилось? Нам предстоит много судебных разбирательств, если я не восстанавливаю сервер как можно скорее. Любая помощь будет оценена. Мы используем Open SUSE 11.0.

---

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

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

Сначала мы пытались выяснить, откуда на сервере пришел этот трафик; учитывая, что на сервере более 500 сайтов, мы ожидали, что это займёт некоторое время. Однако, получив доступ по SSH, мы запустили команду для поиска всех файлов, которые были отредактированы или созданы с момента начала атак. К счастью, проблемный файл был создан во время зимних праздников, что означало, что в то время на сервере было создано не так много других файлов.

Затем мы смогли идентифицировать проблемный файл, который находился в папке с загруженными изображениями на сайте ZenCart.

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

Это означало, что можно было загружать любые файлы, включая PHP-файл для атаки. Мы закрыли уязвимость в ZenCart на зараженном сайте и удалили проблемные файлы.

Работа была сделана, и я добрался домой к 2 часам ночи.

---

Мораль
– Всегда устанавливайте патчи безопасности для ZenCart или любой другой системы CMS. Когда выходят обновления безопасности, весь мир становится осведомленным о уязвимости.
– Всегда делайте резервные копии и резервируйте ваши резервные копии.
– Наймите или договоритесь с кем-то, кто будет на месте в такие моменты. Чтобы никто не полагался на панический пост на Server Fault.

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

Не паникуйте

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

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

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

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

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

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

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

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

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

Остановите проблему от усугубления:

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

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

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

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

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

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

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

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

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

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

Тем не менее, не поддавайтесь искушению вернуться в онлайн слишком быстро. Вместо этого двигайтесь как можно быстрее, чтобы понять, что вызвало проблему и решить ее, прежде чем вы вернетесь в онлайн, в противном случае вы почти наверняка снова станете жертвой вторжения, и помните, “попасться хакерам один раз можно считать несчастьем; попасться снова сразу после этого выглядит как неосторожность” (извините, Оскар Уайльд).

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

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

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

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

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

Например:

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

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

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

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

… И, наконец

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

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

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

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

Итак, вам нужно…

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

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

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

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

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

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

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

Приношу соболезнования в вашей ситуации. Удачи.

CERT имеет документ Шаги по восстановлению после компрометации систем UNIX или NT, который хорош. Конкретные технические детали этого документа несколько устарели, но многие общие советы все же напрямую применимы.

Быстрое резюме основных шагов:

• Консультируйтесь с вашей политикой безопасности или руководством.
• Возьмите под контроль (выключите компьютер)
• Проанализируйте вторжение, получите журналы, выясните, что пошло не так
• Ремонтируйте вещи
  • Установите чистую версию вашей операционной системы!!! Если система была скомпрометирована, вы не можете ей доверять, пункт.
• Обновите системы, чтобы это не могло произойти снова
• Возобновите операции
• Обновите вашу политику для будущего и задокументируйте это

Я хотел бы специально указать на раздел E.1.

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

Если у вас нет системы, уже установленной, например tripwire, нет никакой возможности быть на 100% уверенным в том, что вы очистили систему.

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

Ответ Роберта “горькая пилюля” абсолютно точен, но совершенно общий (что, в общем, имелось в виду в вашем вопросе). Похоже, у вас проблема управления и в насущной необходимости в системном администраторе, если у вас есть один сервер и 600 клиентов, но это вас не утешит.

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

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

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

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

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

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

Вам нужно переустановить. Сохраните то, что вам действительно нужно. Но помните, что все ваши исполняемые файлы могут быть заражены и подменены. Я написал следующее на Python: http://frw.se/monty.py, который создает MD5-хеши всех ваших файлов в указанной директории, и в следующий раз, когда вы его запустите, он проверит, были ли внесены изменения и выведет, какие файлы изменились и что в файлах изменилось.

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

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

ПРИМЕЧАНИЕ: Это не рекомендация. Мой конкретный Протокол реагирования на инциденты вероятно, не не применяется без изменений в случае Гранта Уинна.

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

Первоначальные шаги в нашем Протоколе на случай компрометации сервера следующие:

1. Убедитесь, что злоумышленник смог получить корневой доступ (повышенные привилегии)
2. Отключите затронутые серверы. Сеть или питание? Пожалуйста, смотрите отдельную дискуссию.
3. Проверьте все остальные системы
4. Загрузите затронутые серверы с живого CD
5. (дополнительно) Снимите образы всех системных дисков с помощью dd

6. Начните проводить судебно-медицинскую экспертизу. Изучите журналы, выясните время атаки, найдите файлы, которые были изменены в это время. Постарайтесь ответить на вопрос Как?.

   • Параллельно планируйте и выполняйте восстановление.
   • Сбросьте все корневые и пользовательские пароли перед восстановлением службы.

Даже если “все бэкдоры и руткиты очищены”, не доверяйте этой системе – переустановите с нуля.

По моему ограниченному опыту, компрометации систем на Linux, как правило, бывают более ‘всеобъемлющими’, чем на Windows. Корневые наборы оболочки намного с большей вероятностью будут включать замену системных бинарных файлов на специально подготовленный код для сокрытия вредоносного ПО, а также барьер для горячей коррекции ядра немного ниже. Кроме того, это родная ОС для многих авторов вредоносного ПО. Общие рекомендации заключаются в том, чтобы восстанавливать затронутый сервер с нуля, и этому есть причина.

Отформатируйте этот гад!

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

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

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

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

Я думаю, что @Robert Moir, @Aleksandr Levchuk, @blueben и @Matthew Bloch абсолютно правы в своих ответах.

Тем не менее, ответы разных участников различаются – некоторые более высокоуровневые и обсуждают, какие процедуры вы должны иметь на месте (в общем).

Я предпочел бы выделить это на несколько отдельных частей:
1) Триаж, Т.е. Как справиться с клиентами и правовыми последствием, а также определить, куда идти дальше (очень хорошо описано Робертом и @blueben),
2) Снижение воздействия,
3) Реакция на инциденты,
4) Судебно-медицинская экспертиза после инцидента,
5) Меры по восстановлению и изменения архитектуры.

(Вставьте стандартное сообщение о сертификации SANS GSC здесь)
Основываясь на прошлом опыте, я бы сказал следующее:

Несмотря на то, как вы справляетесь с реакцией клиентов, уведомлениями, правовыми вещами и будущими планами, я бы предпочел сосредоточиться на основной проблеме.
Исходный вопрос ОП фактически касается только пункта #2 и #3, по сути, как остановить атаку, вернуть клиентов онлайн как можно скорее в их первом состоянии, что было хорошо затронуто в ответах.

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

Это действительно зависит от бюджета ОП и от отрасли, в которой они работают, какой у них желаемый итог и т.д.

Может, им нужно нанять выделенного системного администратора на месте. Может, им нужен специалист по безопасности.
Или, может, им нужно полностью управляемое решение, такое как Firehost или Rackspace Managed, Softlayer, ServePath и т.д.

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

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

Все проблемные файлы, похоже, находились в папке /images/ на некоторых наших старых сайтах zencart. Выясняется, что была уязвимость безопасности, которая позволяла (используя curl) любому идиоту загружать не-изображения в раздел загрузки изображений в административной части. Мы удалили проблемные .php файлы и исправили скрипты загрузки, чтобы запретить загрузку любых файлов, которые не являются изображениями.

Оглядываясь назад, это было довольно просто, и я задал этот вопрос на своем iPhone по пути на работу. Спасибо всем за вашу помощь, ребята.

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

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

Нетехнические действия:

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

• Скрытие инцидента безопасности не является вариантом.

• Сообщите местным властям.
  ServerFault НЕ место для юридических консультаций, но это что-то, что должно быть включено в план реагирования на инциденты.
  В некоторых местностях и/или регулируемых отраслях обязательно сообщать (определенные) инциденты безопасности либо местным правоохранительным органам, регулирующим органам, либо информировать затронутых клиентов/пользователей.
  Тем не менее, ни решение о сообщении, ни фактическое сообщение принимаются исключительно IT-отделом. Ожидайте вовлечения от руководства и юридических и корпоративных коммуникационных (маркетинговых) отделов.
  Вам, возможно, не следует ожидать слишком многого, интернет – это большое место, где границы имеют малое значение, но отделы киберпреступности, существующие во многих полиции, расследуют цифровые преступления и могут привести виновных к ответственности.

Недавний полезный скрипт помог мне выяснить, как атакующий может скомпрометировать систему. Некоторые хакеры пытаются скрыть свои следы, подделывая время изменения файлов. Изменяя время изменения, обновляется время изменения (ctime). Вы можете увидеть ctime с помощью stat.

Этот однострочник перечисляет все файлы, отсортированные по ctime:

find / -type f -print0 | xargs -0 stat --format '%Z :%z %n' | sort -nr > /root/all_files.txt

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

Я думаю, это сводится к следующему:

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

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

Существует еще одна (несколько избитая) пословица, которая здесь применима: Профилактика лучше, чем лечение.

Здесь было множество рекомендаций привлечь экспертов, чтобы провести аудит ваших существующих систем. Я считаю, что это неверный вопрос в данном месте. Этот вопрос следовало бы задать, когда система была установлена, и ответы задокументированы. Также вопрос не должен быть “Как мы можем остановить людей от взлома?” Он должен быть “Почему людям вообще должно быть позволено взламывать?” Аудит множества дыры в вашей сети будет работать только до тех пор, пока не будут обнаружены и эксплуатированы новые дыры. С другой стороны, сети, спроектированные с самого начала так, чтобы реагировать только определенным образом на определенные системы в тщательно хореографированном танце, не извлекут выгоды из аудита вообще, и средства будут потрачены зря.

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

Такое уже делалось – есть (или было) банковская система интернета, которая имеет прокси, направляющий к интернету, который собирались использовать, чтобы исключать атаки от их пула серверов. Эксперт по безопасности Маркус Ранум убедил их предпринять противоположный подход, используя обратный прокси, чтобы разрешить только известные действительные URL-адреса и отправить все остальное на сервер 404. Оно удивительно хорошо прошло испытание временем.

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

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