Был взломан один из наших веб-проектов. Злоумышленник изменил несколько файлов шаблонов в проекте и 1 файл ядра веб-фреймворка (это один из самых известных php-фреймворков). Мы нашли все поврежденные файлы с помощью git и восстановили их. Итак, теперь мне нужно найти слабое место.
С большой долей вероятности можно сказать, что дело не в похищении пароля ftp или ssh. Специалист службы поддержки хостинг-провайдера (после анализа логов) сказал, что это брешь в безопасности нашего кода.
Мои вопросы:
1) Какие инструменты мне следует использовать для просмотра журналов доступа и ошибок Apache? (Наш серверный дистрибутив - Debian).
2) Можно ли писать подсказки по обнаружению подозрительных линий в логах? Может быть, учебники или учебники по некоторым полезным регулярным выражениям или методам?
3) Как в логах отделить "нормальное поведение пользователя" от подозрительного.
4) Есть ли способ предотвратить атаки в Apache?
Спасибо за вашу помощь.
Как и HopelessNOOb, я бы порекомендовал получить профессиональную помощь с этим.
Когда вы знаете, что система была взломана, вы не можете полагаться на любой данные, хранящиеся на нем. Кроме того, если компрометация произошла через HTTP, то, вероятно, в стандартных журналах недостаточно информации, чтобы можно было изолировать, что произошло. Вот почему люди, серьезно относящиеся к безопасности веб-серверов, будут использовать что-то вроде mod_security для получения более подробных журналов и запускать IDS на основе хоста для обнаружения компромиссов.
Специалист службы поддержки хостинг-провайдера (после анализа логов) сказал, что это брешь в безопасности нашего кода.
Если он / она может сделать это утверждение, то он / она должны уже знать ответ на ваш вопрос - либо это, либо утверждение не обосновано, и они действительно хотят сказать, что не могут найти ничего плохого в своих материалах.
Ваша цель должна состоять в том, чтобы вернуть ваш сайт в оперативный режим и обеспечить безопасность. Чтобы сделать сайт безопасным, вам нужно заткнуть все дыры, но чтобы скомпрометировать сайт, вам нужно найти только одну дыру: вы знаете, что на вашем сайте есть хотя бы одна дыра, но вам нужно исправить любой которые существуют - а это значит, что вам нужно использовать совершенно другой подход к безопасности вашего сайта. Даже если вы можете идентифицировать и исправить уязвимость, которая была использована на этот раз, данные показывают, что у вас нет процессов и навыков, чтобы иметь хоть какую-то уверенность в том, что это был единичный инцидент.
Вы получили хороший ответ от JennyD, но я бы предложил другой подход.
Нанять эксперта.
Существуют эксперты по безопасности, которые на самом деле этим зарабатывают на жизнь и сделают гораздо лучше и быстрее работу по определению того, как вас взломали и где вы все еще уязвимы. Посетите местный рынок безопасности, и я буду удивлен, если вы не сможете найти достойную цену на консультационные услуги по анализу журналов для вас, а также выполнить хотя бы базовое сканирование на проникновение и уязвимости в вашей системе (-ах). ). Вы получите гораздо более полное представление о том, что вам нужно сделать, чтобы обезопасить себя, и сможете вернуться к тому, чтобы тратить свое время в своих областях знаний.
1) Вы можете посмотреть эти ссылки для некоторого программного обеспечения, которое могло бы вам помочь, хотя я сам не использовал большинство из них. Но учитывая, что у вас есть отметки времени для файлов, которые были изменены, начните с просмотра файлов журнала для этих дат и времени. Grep для имени файла одного из измененных файлов; это должно дать вам IP-адрес злоумышленника, после чего вы можете начать поиск с помощью grep.
2 и 3) Первое, что вам нужно сделать, это выяснить, что нормально для вашего собственного сайта. Один из способов сделать это - использовать стандартный инструмент анализа, такой как awstat, который ежедневно просматривает ваши журналы. Теперь ваша основная проблема заключается в том, что вы не знаете, что является нормальным для вашего сайта, поэтому у вас нет возможности узнать, что является ненормальным.
4) Есть способы предотвратить некоторые атаки, хотя, конечно, это гонка вооружений. Но просто удалив наиболее распространенные эксплойты, вы значительно снизите вероятность того, что вы станете целью случайной атаки. Вы должны убедиться, что в вашей установке установлены последние исправления безопасности для вашей ОС, для apache и для php. Вам также следует взглянуть на mod_security, что позволяет регистрировать подозрительную активность и, например, требуют, чтобы клиент отправлял заголовки, такие как User-Agent, чего не делают многие инструменты взлома.
Кроме того, я бы посоветовал вам рассмотреть возможность отправки ваших журналов, особенно журналов ошибок и любых журналов mod_security, на другой сервер, если это возможно, так что даже если кому-то удастся попасть на ваш сервер, он не сможет редактировать файлы журналов для скрыть свои следы.
В дополнение к приведенным здесь инструкциям, эти темы подробно обсуждаются на обмене стеками безопасности. Прочтите вопрос об усилении защиты Apache: https://security.stackexchange.com/questions/77/485
Возможно, вам стоит попробовать LORG - https://github.com/jensvoid/lorg - инструмент PHP-CLI (GPL), предназначенный для криминалистической экспертизы Apache access_logs после атак. Он использует несколько методов (на основе сигнатур, статистики, обучения) для обнаружения атак на веб-приложения в файлах журналов HTTPD.
Он пытается сгруппировать эти подозрительные действия в сеансы и применяет методы обнаружения роботов (как правило, злоумышленник может запустить автоматическое сканирование, а затем вернуться позже, чтобы вручную проверить, что он нашел). Кроме того, он использует геокартирование и DNSBL-поиск, чтобы узнать, исходят ли атаки из определенной страны или ботнета.
Впоследствии вы можете выбрать различные механизмы, чтобы определить, была ли атака успешной: активные повторы и сопоставление по сигнатурам, кодам ответа HTTP или нестабильности размера ответов (поле отправленных байтов).
Очевидно, что если файлы журнала были изменены или удалены, все может стать трудным (LORG имеет возможность выполнить простую проверку на вмешательство, чтобы найти необычные временные окна без активности, но это вам не поможет).
Что касается предотвращения атак, я бы выбрал mod_security (если это позволяет ваш хостинг-провайдер).
1) Какие инструменты мне следует использовать для просмотра журналов доступа и ошибок Apache? (Наш серверный дистрибутив - Debian).
Просмотрите страницу руководства для системного журнала и некоторых инструментов по ссылкам ниже.
2) Можно ли в логах писать подсказки по обнаружению подозрительных строк? Может быть, учебники или учебники по некоторым полезным регулярным выражениям или методам?
Это немного сложнее и само по себе будет огромной темой, но для начала я бы посмотрел на то, что вышеперечисленные инструменты делают для анализа журналов и что они ищут. Ссылка ниже должна указать вам общее направление для начала обучения.
3) Как в логах отделить "нормальное поведение пользователя" от подозрительного.
Практика, практика, практика. Также хорошо изучить набор инструментов и понять, что происходит «под капотом»
4) Есть ли способ предотвратить атаки в Apache?
Нет. Мир, в котором мы живем, хаотичен и возбужден. Пока людям постоянно нужны новые функции за меньшие деньги, будут сокращаться углы и переполняться буферы. При этом само программное обеспечение Apache, вероятно, довольно безопасно (тщательно проверено), но вы находитесь во власти тех библиотек, которые вы решите использовать, и разрешений, которые вы можете случайно или неосознанно установить.
Кроме того: я очень разочарован большинством ответов, которые указывают OP на то, чтобы нанять эксперта. Хотя это может быть разумным советом предварять ответ, он не отвечает ни на один из тщательно сформулированных вопросов OP.