☰

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

tag-icon • tag-icon apache-2.2 log-files hacking binary
Странные вещи в журнале 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

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

решение1

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

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

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

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

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

  • Защитите свой сервер брандмауэром.Или нет, но знайте, что вы делаете.)

  • Запустите систему обнаружения вторжений, напримерПОМОЩНИК,ОССЕЦ, илисамайн. Это предупредит вас о неожиданном изменении системных файлов, что часто является признаком того, что ваш сервер был скомпрометирован.

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

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

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

решение2

Какой сервер вы используете? Apache?

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

решение3

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

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

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

решение4

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

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

Связанный контент