Трудно дать конкретный совет из того, что вы опубликовали здесь, но у меня есть несколько общих советов, основанных на посте, который я написал много лет назад, когда я все еще мог быть обеспокоен блогом.
Не паникуйте
Перво-наперво, нет никаких «быстрых исправлений», кроме восстановления вашей системы из резервной копии, сделанной до вторжения, и это имеет как минимум две проблемы.
- Трудно определить, когда произошло вторжение.
- Это не поможет вам закрыть «дыру», которая позволила им прорваться в прошлый раз, и не справиться с последствиями любой «кражи данных», которая также могла иметь место.
Этот вопрос постоянно задают жертвы хакеров, взломавших свой веб-сервер. Ответы очень редко меняются, но люди продолжают задавать вопрос. Я не уверен почему. Возможно, людям просто не нравятся ответы, которые они видели при поиске помощи, или они не могут найти того, кому доверяют, чтобы дать им совет. Или, возможно, люди читают ответ на этот вопрос и слишком много внимания уделяют 5% того, почему их дело особенное и отличается от ответов, которые они могут найти в Интернете, и пропускают 95% вопроса и отвечают, когда их дело достаточно близко как тот, который они читают в Интернете.
Это подводит меня к первому важному фрагменту информации. Я действительно ценю, что ты особенная уникальная снежинка. Я ценю, что ваш веб-сайт также является отражением вас и вашего бизнеса или, по крайней мере, вашей тяжелой работы от имени работодателя. Но кому-то со стороны, который занимается поиском, независимо от того, пытается ли специалист по компьютерной безопасности попытаться помочь вам или даже сам злоумышленник, очень вероятно, что ваша проблема будет, по крайней мере, на 95% идентична каждому другому случаю когда-либо смотрел на.
Не принимайте атаку лично, и не принимайте рекомендации, которые следуют здесь или которые вы получаете от других людей лично. Если вы читаете это после того, как просто стали жертвой взлома сайта, то мне очень жаль, и я очень надеюсь, что вы найдете здесь что-то полезное, но сейчас не время, чтобы ваше эго могло помешать тому, что вам нужно делать.
Вы только что узнали, что ваш сервер (ы) был взломан. Что теперь?
Без паники. Абсолютно не действуй в спешке, и абсолютно не пытайся притворяться, что ничего не произошло, и вообще не действовать.
Первое: понять, что катастрофа уже произошла. Это не время для отказа; настало время принять то, что произошло, быть реалистичным и предпринять шаги, чтобы справиться с последствиями воздействия.
Некоторые из этих шагов повредят, и (если ваш сайт не содержит копию моих данных), мне действительно все равно, если вы проигнорируете все или некоторые из этих шагов, это ваше дело. Но, следуя им должным образом, в конце концов все станет лучше. Лекарство может быть ужасным на вкус, но иногда вы должны игнорировать это, если вы действительно хотите, чтобы лекарство сработало.
Остановите проблему, чтобы она стала хуже, чем она есть:
- Первое, что вы должны сделать, это отключить уязвимые системы от Интернета. Какие бы другие проблемы у вас ни возникали, оставление системы, подключенной к сети, только позволит продолжить атаку. Я имею в виду это буквально; попросите кого-нибудь физически посетить сервер и отсоединить сетевые кабели, если это то, что нужно, но отсоединить жертву от ее грабителей, прежде чем пытаться делать что-либо еще.
- Измените все свои пароли для всех учетных записей на всех компьютерах, которые находятся в той же сети, что и скомпрометированные системы. Нет, правда. Все аккаунты. Все компьютеры. Да, вы правы, это может быть излишним; с другой стороны, это не так. Вы не знаете в любом случае, не так ли?
- Проверьте ваши другие системы. Обратите особое внимание на другие службы, имеющие отношение к Интернету, а также на те, которые хранят финансовые или другие коммерчески важные данные.
- Если в системе хранятся чьи-либо личные данные, немедленно сообщите об этом лицу, ответственному за защиту данных (если это не вы), и ПРИЗЫВАЙТЕ к полному раскрытию. Я знаю, что это сложно. Я знаю, что это будет больно. Я знаю, что многие компании хотят скрыть проблему подобного рода, но бизнесу придется с этим справиться - и он должен это делать, следя за любыми и всеми соответствующими законами о конфиденциальности.
Как бы ни раздражали ваши клиенты то, что вы рассказали им о проблеме, они будут гораздо более раздражены, если вы им не расскажете, и они узнают о себе только после того, как кто-то зарядит товары на сумму $ 8 000, используя данные кредитной карты, которую они украл с вашего сайта.
Помните, что я сказал ранее? Плохая вещь уже произошла. Единственный вопрос сейчас заключается в том, насколько хорошо вы справляетесь с этим.
Понять проблему полностью:
- НЕ переводите уязвимые системы в оперативный режим до тех пор, пока этот этап не будет полностью завершен, если только вы не хотите стать тем человеком, чей пост стал для меня переломным моментом, когда я решил написать эту статью. Я не буду ссылаться на этот пост, чтобы люди могли дешево посмеяться, но настоящая трагедия в том, что люди не учатся на своих ошибках.
- Изучите «атакованные» системы, чтобы понять, как атаки смогли поставить под угрозу вашу безопасность. Приложите все усилия, чтобы выяснить, откуда произошли атаки, чтобы вы понимали, какие проблемы у вас есть, и которые необходимо решить, чтобы обеспечить безопасность вашей системы в будущем.
- Снова изучите «атакованные» системы, на этот раз, чтобы понять, куда пошли атаки, чтобы понять, какие системы были скомпрометированы в ходе атаки. Убедитесь, что вы следите за любыми указателями, которые предполагают, что взломанные системы могут стать трамплином для дальнейших атак на ваши системы.
- Убедитесь, что «шлюзы», используемые в любой атаке, полностью понятны, чтобы вы могли начать их правильно закрывать. (Например, если ваши системы были скомпрометированы атакой SQL-инъекции, вам нужно не только закрыть конкретную некорректную строку кода, которую они взломали, вы захотите провести аудит всего кода, чтобы увидеть, нет ли ошибок того же типа было сделано в другом месте).
- Поймите, что атаки могут быть успешными из-за более чем одного недостатка. Зачастую атаки успешны не путем нахождения одной серьезной ошибки в системе, а путем объединения нескольких проблем (иногда незначительных и тривиальных самих по себе) для компрометации системы. Например, используя атаки с использованием SQL-инъекций для отправки команд на сервер базы данных, обнаружение сайта / приложения, которое вы атакуете, выполняется в контексте административного пользователя и использует права этой учетной записи в качестве отправной точки для компрометации других частей система. Или, как любят это называть хакеры: «еще один день в офисе, позволяющий воспользоваться общими ошибками, которые люди совершают».
Почему бы просто не «починить» обнаруженный вами эксплойт или руткит и снова включить систему?
В подобных ситуациях проблема в том, что вы больше не можете контролировать эту систему. Это больше не твой компьютер.
Единственный способ быть уверены , что у вас есть контроль системы , чтобы восстановить систему. Хотя поиск и исправление эксплойта, использованного для взлома системы, имеет большую ценность, вы не можете быть уверены в том, что еще было сделано с системой после того, как злоумышленники получили контроль (действительно, для хакеров, которые вербуют, это неслыханно). системы в ботнет для исправления эксплойтов, которые они использовали сами, для защиты «своего» нового компьютера от других хакеров, а также установки их руткитов).
Составьте план восстановления и верните свой веб-сайт в режим онлайн и придерживайтесь его:
Никто не хочет быть в автономном режиме дольше, чем они должны быть. Это дано. Если этот сайт является механизмом, приносящим доход, то давление, чтобы быстро вернуть его в оперативный режим, будет интенсивным. Даже если на карту поставлена только репутация вашей / вашей компании, это все равно будет создавать большое давление для быстрого восстановления.
Однако не поддавайтесь искушению слишком быстро вернуться в онлайн. Вместо этого двигайтесь как можно быстрее, чтобы понять, что вызвало проблему, и решить ее, прежде чем вернуться в Интернет, иначе вы почти наверняка станете жертвой вторжения еще раз и помните: «один раз взломать можно классифицировать как несчастье; снова взломанный сразу после этого выглядит как небрежность "(с извинениями перед Оскаром Уайльдом).
- Я предполагаю, что вы поняли все проблемы, которые привели к успешному вторжению, прежде чем вы даже начали этот раздел. Я не хочу преувеличивать дело, но если вы не сделали этого сначала, то вам действительно нужно. Сожалею.
- Никогда не платите шантаж / защиту денег. Это знак легкой отметки, и вы не хотите, чтобы эта фраза когда-либо использовалась для описания вас.
- Не поддавайтесь искушению снова подключить один и тот же сервер (ы) к сети без полной перестройки. Должно быть гораздо быстрее создать новую коробку или «сбросить сервер с орбиты и произвести чистую установку» на старом оборудовании, чем проверять каждый уголок старой системы, чтобы убедиться, что он чистый, прежде чем вернуть его обратно. снова в сети. Если вы не согласны с этим, то, вероятно, вы не знаете, что на самом деле означает обеспечить полную очистку системы, или что процедуры развертывания вашего сайта - ужасная путаница. Вероятно, у вас есть резервные копии и тестовые развертывания вашего сайта, которые вы можете просто использовать для создания живого сайта, и если вас не взломали, то это не самая большая проблема.
- Будьте очень осторожны с повторным использованием данных, которые были «живы» в системе во время взлома. Я не буду говорить «никогда не делай этого», потому что ты просто проигнорируешь меня, но, честно говоря, я думаю, тебе нужно учитывать последствия хранения данных, когда ты знаешь, что не можешь гарантировать их целостность. В идеале, вы должны восстановить это из резервной копии, сделанной до вторжения. Если вы не можете или не хотите этого делать, вы должны быть очень осторожны с этими данными, потому что они испорчены. Вы должны особенно знать о последствиях для других, если эти данные принадлежат клиентам или посетителям сайта, а не напрямую вам.
- Тщательно контролируйте систему (ы). Вы должны решить сделать это как непрерывный процесс в будущем (подробнее ниже), но вы прилагаете дополнительные усилия, чтобы быть бдительными в течение периода, следующего за тем, как ваш сайт снова подключается к сети. Злоумышленники почти наверняка вернутся, и если вы заметите, что они пытаются прорваться снова, вы наверняка сможете быстро увидеть, действительно ли вы закрыли все отверстия, которые они использовали ранее, плюс все, что они сделали для себя, и вы могли бы собрать полезные информацию, которую вы можете передать в местные правоохранительные органы.
Снижение риска в будущем.
Первое, что вам нужно понять, это то, что безопасность - это процесс, который вы должны применять на протяжении всего жизненного цикла проектирования, развертывания и обслуживания системы с выходом в Интернет, а не то, что вы можете потом пролить несколькими слоями на свой код, как дешево. покрасить. Чтобы быть должным образом защищенным, сервис и приложение должны быть спроектированы с самого начала, учитывая это как одну из основных целей проекта. Я понимаю, что это скучно, и вы уже слышали все это раньше, и я "просто не понимаю, что такое давление", когда ваш бета-сервис web2.0 (бета-версия) переводится в бета-статус в Интернете, но факт в том, что повторение, потому что это было правдой с первого раза, когда это было сказано, и это еще не стало ложью.
Вы не можете устранить риск. Вы не должны даже пытаться сделать это. Однако вы должны понять, какие риски безопасности важны для вас, и понять, как управлять и уменьшить как влияние риска, так и вероятность того, что риск произойдет.
Какие шаги вы можете предпринять, чтобы уменьшить вероятность успеха атаки?
Например:
- Была ли ошибка, которая позволяла людям проникать на ваш сайт, известной ошибкой в коде поставщика, для которой был доступен патч? Если да, нужно ли вам переосмыслить свой подход к исправлению приложений на серверах, выходящих в Интернет?
- Был ли недостаток, который позволял людям проникать на ваш сайт, неизвестной ошибкой в коде поставщика, для которой не было патча? Я, безусловно, не защищаю смену поставщиков, когда что-то вроде этого кусает вас, потому что у них у всех есть свои проблемы, и у вас не будет больше платформ в течение года, если вы воспользуетесь этим подходом. Однако, если система постоянно вас подводит, вам следует либо перейти на что-то более надежное, либо, по крайней мере, перестроить свою систему так, чтобы уязвимые компоненты оставались обернутыми в вату и как можно дальше от враждебных глаз.
- Была ли ошибка в коде, разработанном вами (или подрядчиком, работающим на вас)? Если да, нужно ли вам пересмотреть свой подход к утверждению кода для развертывания на своем действующем сайте? Возможно, ошибка была обнаружена в улучшенной тестовой системе или с изменениями в «стандартном» кодировании (например, хотя технология не является панацеей, вы можете уменьшить вероятность успешной атаки с использованием SQL-инъекций, используя хорошо документированные методы кодирования ).
- Был ли недостаток из-за проблемы с тем, как был развернут сервер или прикладное программное обеспечение? Если да, то используете ли вы автоматизированные процедуры для создания и развертывания серверов, где это возможно? Это большая помощь в поддержании согласованного «базового» состояния на всех ваших серверах, минимизации объема настраиваемой работы, выполняемой на каждом из них, и, следовательно, надеюсь, что минимизируется возможность допустить ошибку. То же самое касается развертывания кода - если вам требуется что-то «особенное» для развертывания последней версии вашего веб-приложения, тогда постарайтесь автоматизировать его и убедиться, что оно всегда выполняется согласованным образом.
- Возможно ли, что вторжение было обнаружено раньше благодаря лучшему мониторингу ваших систем? Конечно, круглосуточный мониторинг или система «по вызову» для ваших сотрудников могут быть неэффективными, но есть компании, которые могут отслеживать ваши услуги в сети и предупреждать вас в случае возникновения проблемы. Вы можете решить, что не можете себе этого позволить или не нуждаетесь, и это просто прекрасно ... просто примите это во внимание.
- При необходимости используйте такие инструменты, как tripwire и nessus, но не используйте их вслепую, потому что я так сказал. Потратьте время, чтобы узнать, как использовать несколько хороших инструментов безопасности, соответствующих вашей среде, постоянно обновлять эти инструменты и использовать их на регулярной основе.
- Подумайте о том, чтобы нанять экспертов по безопасности для регулярного аудита безопасности вашего сайта. Опять же, вы можете решить, что не можете себе этого позволить или не нуждаетесь, и это просто прекрасно ... просто примите это во внимание.
Какие шаги вы можете предпринять, чтобы уменьшить последствия успешной атаки?
Если вы решите, что «риск» затопления нижнего этажа дома высок, но недостаточно высок, чтобы оправдать переезд, вам следует хотя бы переместить незаменимые семейные реликвии наверх. Правильно?
- Можете ли вы уменьшить количество услуг, непосредственно подключенных к Интернету? Можете ли вы сохранить какой-то разрыв между вашими внутренними службами и службами, выходящими в Интернет? Это гарантирует, что даже если ваши внешние системы будут скомпрометированы, шансы использовать это как трамплин для атаки на ваши внутренние системы ограничены.
- Вы храните информацию, которую вам не нужно хранить? Вы храните такую информацию «онлайн», когда она может быть заархивирована в другом месте. Есть две точки к этой части; очевидным является то, что люди не могут украсть у вас информацию, которой у вас нет, а второй момент заключается в том, что чем меньше вы храните, тем меньше вам нужно поддерживать и кодировать, и, таким образом, меньше шансов попасть в ошибки. Ваш код или дизайн системы.
- Используете ли вы принципы "наименьшего доступа" для своего веб-приложения? Если пользователям требуется только чтение из базы данных, убедитесь, что учетная запись, которую веб-приложение использует для обслуживания, имеет только доступ для чтения, не разрешайте ему доступ для записи и, конечно, не доступ на уровне системы.
- Если вы не очень опытны в чем-то, и это не занимает центральное место в вашем бизнесе, подумайте об аутсорсинге. Другими словами, если вы управляете небольшим веб-сайтом, рассказывающим о написании кода приложений для настольных компьютеров, и решаете начать продажу небольших приложений для настольных компьютеров с этого сайта, то подумайте об "аутсорсинге" вашей системы заказов по кредитным картам кому-то, например Paypal.
- Если это вообще возможно, включите практику восстановления из скомпрометированных систем в свой план аварийного восстановления. Возможно, это просто еще один «сценарий катастрофы», с которым вы можете столкнуться, просто сценарий со своим собственным набором проблем и проблем, которые отличаются от обычного «загорелась серверная комната» / /, который был захвачен гигантскими вещами типа серверной еды.
... И наконец
Я, вероятно, не упустил ни одного конца материала, который другие считают важным, но вышеприведенные шаги должны, по крайней мере, помочь вам начать разбираться, если вам не повезло стать жертвой хакеров.
Прежде всего: не паникуйте. Думай прежде чем сделать. Действуйте твердо, как только вы приняли решение, и оставьте комментарий ниже, если у вас есть что добавить в мой список шагов.