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

Не паникуйте

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Например:

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

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

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

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

... И наконец

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

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

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

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

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

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

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

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

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

НОТА: Это не рекомендация. Мой конкретный Реагирование на инцидент протокол вероятно не будет не применяется без изменений к делу Гранта Увина.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В этом лайнере перечислены все файлы, отсортированные по ctime:

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

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

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

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

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

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

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

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

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

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

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