Как мне работать с взломанным сервером?

601

Это канонический вопрос о безопасности сервера - реагирование на события взлома (взлом)
См. Также:

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

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

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

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. Как и в случае выпуска обновлений для системы безопасности, весь мир узнает об этой уязвимости. - Всегда делайте резервные копии и делайте резервные копии. - Нанять или организовать кого-то, кто будет там в такие времена. Чтобы никто не полагался на паническое сообщение о сбое сервера.

gunwin
источник
7
Я знаю, что вы чувствуете - нам очень повезло с «полезными» хакерами на этом сайте, где они рассказывают нам, что они сделали! Я с нетерпением жду отличных ответов на этот вопрос, на случай, если в будущем мы получим «не очень полезных» гостей.
Джаррод Диксон
186
Позвоните профессионалу, чтобы помочь!
Marcog
103
Я не хочу показаться умным или несимпатичным (я тоже), и, конечно, я не знаю подробностей вашей ситуации, но если вы единственный человек, ответственный за настройку 500-600 сайтов, возможно, быть фундаментальным недостатком в работе этого сервера. Некоторые компании используют специального системного администратора, который больше ничего не делает в течение всего дня, но обслуживает серверы - задача, которая автоматически не входит в компетенцию программиста, даже если так может показаться. Может быть, это стоит рассмотреть, когда кризис закончится. Во всяком случае, прямо сейчас, удачи в разрешении ситуации под рукой.
Пекка,
Не обязательно предполагать, что у вас есть полноценный корневой набор ядра и что ваш пароль root скомпрометирован. Возможно, это всего лишь подлый сценарий bash / perl, и его можно очистить, не форматируя, несмотря на то, что здесь говорит
Hayden Thring

Ответы:

1015

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

Не паникуйте

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Например:

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

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

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

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

... И наконец

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

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

Роб Моир
источник
8
+1 за отличный пост, чтобы иметь под рукой, чтобы люди начали в направлении. Я знаю, как часто администраторы-любители переходят в этот режим паники, когда с ними впервые происходит «взлом». Быть в этом месте - огромная ошибка, но это случается. Надежда будет состоять в том, что это не случится с одним и тем же человеком, дважды.
Эндрю Барбер
33
+1 "... но сейчас не время, чтобы ваше эго мешало тому, что вам нужно делать". Это важно для системных администраторов, чтобы понять иногда. Независимо от того, насколько вы осведомлены, всегда есть те (иногда злонамеренные), которые более осведомлены или умны, чем вы.
Grahamux
11
Отличный ответ. Я не уверен, почему все рассматривают шаг "вызова правоохранительных органов" как дополнительный. Если вы несете ответственность за данные других людей (и беспокоитесь о судебных разбирательствах), это должно быть одним из первых дел в вашем списке действий.
WDS
8
Очень хорошая запись, только одна ошибка - «сделайте полное и откровенное раскрытие любому, кто может быть затронут сразу». Благородно, но не всегда правильно. Реагируя на компромисс, вам, возможно, придется сократить некоторые углы управления, и ваша компания, как правило, снизит вам некоторую слабость, однако ... раскрытие информации или нет, особенно в тех случаях, когда последствия для защиты данных могут значительно превышать уровень оплаты и может иметь юридические последствия. Может быть лучше предложить немедленно сообщить лицу, ответственному за защиту данных (если это не вы), и НАСТОЯТЕЛЬНО ПРИЗНАТЬ полное раскрытие информации.
TheoJones
5
Хосты виртуальных машин @GilesRoberts обычно имеют панель управления, которая позволяет вам управлять настройками их гостей и даже удаленно управлять ими, не используя RDP или SSH для фактического входа в систему гостя. Вы должны быть в состоянии изолировать гостя, используя для этого средства управления хоста, а затем использовать его инструменты удаленного просмотра, чтобы исследовать гостя на досуге.
Роб Мойр
204

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

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

Тогда вам нужно ...

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

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

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

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

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

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

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

У вас есть мои утешения для вашей ситуации. Удачи.

blueben
источник
19
+1 Отличный ответ. Похоже, что у ОП нет заранее определенного «экстренного реагирования», и ваш пост, помимо прочего, должен указывать на их настройку.
Роб Мойр
109

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

Краткое описание основных шагов:

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

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

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

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

Zoredache
источник
26
Даже тогда tripwire может быть одурачен модулями ядра и тому подобным. Переустановка.
переназначить
Связанный с этим вопрос о том, как реагировать на кризис, также может быть полезен здесь.
Зоредаче
67
  1. Определите проблему. Читайте журналы.
  2. Содержать . Вы отключили сервер, так что все готово.
  3. Искоренить . Переустановите уязвимую систему, скорее всего. Не стирайте жесткий диск взломанного, используйте новый. Это безопаснее, и вам может понадобиться старый, чтобы восстановить уродливые хаки, которые не были скопированы, и провести экспертизу, чтобы выяснить, что произошло.
  4. Восстановление . Установите все необходимое и восстановите резервные копии, чтобы подключить своих клиентов к сети.
  5. Последующая деятельность . Выясните, в чем была проблема, и предотвратите ее повторение.
Якоб Борг
источник
52

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

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

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

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

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

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

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

Мэтью Блох
источник
41

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

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

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

Филип Экберг
источник
13
Итак ... вы реализовали tripwire.
womble
13
Да, что-то не так с этим?
Филипп Экберг
1
+1 за отключение, проанализируйте (заставьте кого-то сделать реальную экспертизу над этим) и сотрите
Оскар Дюверборн
4
Учитывая выбор между анонимным скриптом Python и документированным (несколько) поддерживаемым, хорошо понятым стандартным решением, вы надеетесь, что они выберут первое?
tripleee
37

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

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

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

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

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

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

Александр Левчук
источник
23
-1 Отключить сервер от питания? Вы только что потеряли половину своих судебных данных!
Джош Брауэр
@ Джош, я поправил свой ответ - теперь он нейтрален в вопросе «Что отключить».
Александр Левчук
5
Экспертиза ОЗУ (например, / dev / shm) может быть полезна. Я предпочитаю отключать кабель питания (но попробуйте войти в систему и rsync/ proc прямо перед этим). Мы также можем вводить частые снимки виртуальных машин, чтобы была возможна экспертиза оперативной памяти. Причины для кабеля питания: (1) Когда вы проводите судебную экспертизу в взломанной системе, вы «переступаете через все место преступления»; (2) Корневой комплект продолжает работать - злоумышленнику не так сложно выполнить что-либо (например, очистку системы) в случае события Network Link Down . Кайл Ранкин в своем прекрасном выступлении «Введение в судебную экспертизу» ( goo.gl/g21Ok ) рекомендовал тянуть кабель питания.
Александр Левчук
4
Не существует единого размера, подходящего для всех протоколов IR. Некоторым организациям может потребоваться некоторое время поддерживать скомпрометированную систему в сети по любой причине. (Судебная экспертиза оперативной памяти и временных журналов, взаимодействие с злоумышленниками и т. Д.) Моя точка зрения заключается в том, что было бы лучше рекомендовать общий протокол IR (как Jakob Borgs выше), а не тот, который начинается с «Отключите штепсель скомпрометированного сервера. "
Джош Брауэр
31

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

Отформатируйте этого щенка.

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

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

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

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

sysadmin1138
источник
2
«Отформатируйте этого щенка.» +1, мудрый совет. Читайте также: «Сбросьте его с орбиты, это единственный способ быть уверенным».
Эйвери Пейн
31

Я бы сказал, что @Robert Moir, @Aleksandr Levchuk, @blueben и @Matthew Bloch - все в своих ответах.

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

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

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

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

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

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

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

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

Захария Ханна
источник
1
Да, это зависит, мы знаем. Сказать, что это не очень помогает.
DOK
27

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

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

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

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

gunwin
источник
Грант, я рад, что это сработало для тебя очень гладко. Это было что-то незначительное - гораздо менее серьезное, чем предполагали многие из нас. Эта дискуссия научила меня урокам общения, дала много хороших советов и пищи для размышлений о непристойных ответах.
Александр Левчук
3
Спасибо, что вернулись и сообщили нам, как вы продвинулись - как вы видите, ваш вопрос вызвал много дискуссий. Я рад, что вы, кажется, не слишком сильно пострадали от этого, и в итоге ваше решение было довольно простым.
Роб Мойр
5
Это должен быть комментарий (или текст в вашем вопросе), а не ответ на ваш вопрос.
Techboy
5
@Techboy: Кажется, он еще не связал свои учетные записи SO и SF, поэтому он не может редактировать свой вопрос. @Grant: Вы можете связать свои учетные записи через панель «Учетные записи» на своей странице пользователя.
Бегемот
1
без базовой конфигурации, как вы знаете, не работает руткит?
Дворник Unix
18

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

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

  • Сообщите об инциденте изнутри.
    Если у вас еще нет плана реагирования на инциденты, который может показаться техникой CYA, но ИТ-отдел не является единственным и зачастую даже не лучшим местом для определения влияния взломанного сервера на бизнес .
    Бизнес-требования могут превзойти ваши технические проблемы. Не говорите «я вам так сказал», и что приоритетность бизнес-задач - это причина, по которой вы имеете этот скомпрометированный сервер. (« Оставьте это для отчета о последствиях ».)

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

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

HBruijn
источник
16

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

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

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

Здесь есть еще одна (несколько заштрихованная) поговорка: профилактика лучше лечения .

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

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

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

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

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

Аарон Мейсон
источник
15

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

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

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

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


ah83
источник