Как найти шеллы на сайте

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

Одной из неприятностей может стать присутствие так называемого шелла (shell — оболочка) на сервере Вашего сайта. Шеллы представляют собой зловредные скрипты, которые каким-то образом оказались на сервере и могут запускаться на исполнение. В этом случае плохой человек может получить некоторые возможности, например, изменение файлов, загрузка собственных скриптов и соответственно возможность их исполнения, отправка спама и прочее, и прочее. Случается это по разным причинам, но как правило вследствие «дырявости» (читай «уязвимости») CMS или хостинга.

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

Опишу несколько простых примеров, от которых потом можно отталкиваться.

Поиск текста «eval» во всех файлах с расширением .php с заданной директории:

find /dir/to/find/ -type f -iname "*.php" -exec grep -Him1 'eval' {} ;

Поиск «eval» среди файлов, у которых выставлены права 777

find /dir/to/find/ -perm 2 -type f -iname "*.php" -exec grep -Him1 'eval' {} ;

Простой поиск php-скриптов в заданной папке

find /dir/to/find/ -perm 2 -type f -iname "*.php"

Поиск .php файлов, созданных или измененных за последние 7 дней, мне всегда помогала именно она:

find /dir/to/find/ -type f -iname "*.php" -mtime -7

Далее пробегаемся по списку файлов, смотрим их содержимое и, если найден shell удаляем его.

Не стоит пренебрегать безопасностью своего сайта. Удачи.

Автор: Артур Минимулин ⚫ 9 ноября 2011 г. ⚫ Тэги: Хостинг, Безопасность

В своих прошлых статьях я нередко упоминал об различного рода уявимостях на сайтах. Это «Уязвимость в AdsManager на практике» и «Пример уязвимости в JCE», а также более обобщенно в других материалах. Для тех, кто не знает чем бекдор отличается от XSS я посвящу уже следующую статью «Описание распространненых уязвимостей».

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

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

Как найти уязвимость по логам?

Допустим,что вирус уже проник на сайт. Мы успешно (наверно) удалили все вирусы с сайта и задумались над защитой от дальнейшего вторжения. Здесь могут помочь мои советы из статьи «Как защитить сайт от попадания вирусов». Многие владельцы веб-страниц хотят знать, как вирус попал на сайт и как предотвратить заражение в дальнейшем. В таком случае требуется более детальный анализ появления вирусов на сайте. И я расскажу простой метод  поиска уязвимости, который поможет даже начинающему веб-мастеру.

Итак, для начала нам надо найти логи сервера. По умолчанию они находятся в отдельной папке logs выше директории сайта. Чаще всего имеют имена файлов access_log и error_log. Что делать, если не смогли найти их?

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

— Вариант второй, запросить логи у техподдержки, они подскажут, как вам поступить дальше.

Ищем шеллы на сайте!

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

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

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

Проникновение вирусов через POST запросы

Наверное главным недостатком логов будет проблемность обнаружить данные, передаваемые через POST. Многие вирусы стали достаточно хитрыми и маскируются под модули и плагины системы управления сайтом. Как результат, в логах обычные обращение к страницам, будь то главная или внутренние ссылки. В таких случаях необходимо устанавливать на сервер дополнительные модули захвата пост-данных, либо переключать логирование в уровни trace. При этом будьте готовы, что файлы логов станут занимать ну очень много места! При таком анализе и дешифровке кода можно восстановить полную ситуацию взлома на сайте. Однако многие хостинги с неохотой идут на уступки в выдаче необхрдимых логов. Поэтому этот вариант больше подходит для выделенных серверов.

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

Поиск уязвимостей аудитом безопасности

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

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

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

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

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