Назад | Перейти на главную страницу

Странные вещи в журнале apache

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

***.***.***.** - - [19/Dec/2010:19:47:47 +0100] "\x99\x91g\xca\xa8" 501 1054
**.***.***.** - - [19/Dec/2010:20:14:58 +0100] "<}\xdbe\x86E\x18\xe7\x8b" 501 1054
**.**.***.*** - - [21/Dec/2010:15:28:14 +0100] "J\xaa\x9f\xa3\xdd\x9c\x81\\\xbd\xb3\xbe\xf7\xa6A\x92g'\x039\x97\xac,vC\x8d\x12\xec\x80\x06\x10\x8e\xab7e\xa9\x98\x10\xa7" 501 1054

Черт возьми ... что это ?!

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

Почему они это сделали? Что ж, некоторые веб-серверы имеют известные уязвимости, которые можно использовать, отправив им «правильный» запрос. Таким образом, вы, возможно, видите исследования известных (или даже неизвестных) уязвимостей. Если это заставит вас чувствовать себя в большей безопасности, вы можете взять ретроактивный меры, такие как блокировка / запрет IP-адресов, которые отправляют неверные или неизвестные запросы (с использованием iptables, fail2ban и т. д.).

Лично я придерживаюсь мнения, что заносить в черный список «плохие» IP-адреса не стоит, поскольку к тому времени, когда вы увидите их следы в своих лог-файлах, они либо узнают, что вы не уязвимы, либо вас уже взломали. Я верю лучший подход - быть активным с охраной:

  • Полностью обновляйте и обновляйте программное обеспечение сервера. Всегда. Придирчиво. Религиозно.

  • Сохраняйте свой профиль атаки как можно меньше: не устанавливайте / не запускайте на сервере ненужное программное обеспечение. И, как Уильям Оккам однажды сказал: «Не множите без надобности учетные записи пользователей».

  • Брандмауэр вашего сервера. (Или не, но знайте, что делаете.)

  • Запустите систему обнаружения вторжений, например Помощник, OSSEC, или Самайн. Это предупредит вас, когда системные файлы неожиданно изменятся, часто это указывает на то, что ваш сервер был скомпрометирован.

  • Запустите программное обеспечение для мониторинга / построения графиков системы, например Мунин, кактусы, собирать или т.п. Регулярно следите за графиками, чтобы понять, как выглядят обычные нагрузки системы и как выглядят ваши регулярные тенденции. Затем, когда ваши графики показывают что-то, чего вы никогда раньше не видели, у вас появляется стимул для дальнейшего исследования.

  • Запустите анализатор / графер веб-журналов, например Webalizer или awstats. Опять же, ознакомьтесь с тем, как выглядят обычные операции, чтобы вы могли быстро распознать, когда что-то не так.

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

Каждый общедоступный веб-сервер получает подобные запросы в течение всего дня. Они просто слепо пытаются использовать известные эксплойты против вашего сервера. Я часто настраиваю веб-сервер для отображения пустой страницы при получении запросов на свой IP-адрес (т.е. http://10.0.0.1). Я разрешаю сайтам появляться только тогда, когда запрашивается правильный домен виртуального хоста.

Посмотрите, какой сайт появляется при доступе к веб-серверу по IP, а не по имени домена. Большинство сценариев эксплойтов, просматривающих netter-tube, не выполняют допустимые запросы виртуального хоста (правильные заголовки виртуального хоста).

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

Какой у вас сервер? Апач?

Похоже на эксплойт IIS .... Code Red / NIMDA

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

Это напоминает ситуацию, когда я видел данные журнала PHP в UTF8, а затем они кодировались / экранировались в ASCII, что составляло очень похожие сообщения.