Контакт с нападениями HTTP w00tw00t

Я лично записал сценарий Python для автодобавления правил IPtables.

Вот немного сокращенная версия, не регистрируясь и другой спам:

#!/usr/bin/python
from subprocess import *
import re
import shlex
import sys

def find_dscan():
        p1 = Popen(['tail', '-n', '5000', '/usr/local/apache/logs/error_log'], stdout=PIPE)
        p2 = Popen(['grep', 'w00t'], stdin=p1.stdout, stdout=PIPE)

        output = p2.communicate()[0].split('\n')

        ip_list = []

        for i in output:
                result = re.findall(r"\b(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\b", i)
                if len(result):
                        ip_list.append(result[0])

        return set(ip_list)

for ip in find_dscan():
        input = "iptables -A INPUT -s " + ip + " -j DROP"
        output = "iptables -A OUTPUT -d " + ip + " -j DROP"
        Popen(shlex.split(input))
        Popen(shlex.split(output))

sys.exit(0)

Я полагаю, что причина mod_security не работает на Вас, то, что Apache не смог проанализировать сами запросы, они из спецификации. Я не уверен, что у Вас есть проблема здесь - апач регистрирует странное дерьмо, которое происходит в сети, если это не зарегистрирует его, то Вы не будете знать его даже случай. Ресурсы, требуемые зарегистрировать запросы, вероятно, минимальны. Я понимаю его срыв, что кто-то заполняет Ваши журналы - но будет более печально при отключении входа только, чтобы найти реальную необходимость в нем. Как кто-то ворвался в Ваш веб-сервер, и Вам нужны журналы, чтобы показать, как они ворвались.

Одно решение состоит в том, чтобы установить ErrorLogging через системный журнал, и затем использующий rsyslog или системный-журнал-ng, Вы могли конкретно отфильтровать и отбросить эти нарушения RFC относительно w00tw00t. Или альтернативно Вы могли проникнуть их в отдельный файл журнала просто, таким образом, Ваш основной ErrorLog легко считать. Rsyslog невероятно мощен и гибок в этом отношении.

Таким образом в httpd.conf Вы могли бы сделать:

ErrorLog syslog:user 

затем в rsyslog.conf Вы могли бы иметь:

:msg, contains, "w00tw00t.at.ISC.SANS.DFind" /var/log/httpd/w00tw00t_attacks.log

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

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

Блокирование IPTables является идеей, но можно закончить с очень большим iptables черным списком, который может иметь последствия производительности сам по себе. В IP-адресах существует ли шаблон, или он прибывает из большого распределенного ботнета? Должен будет быть X % дубликатов, прежде чем Вы извлечете пользу из iptables.

Вы говорите в Обновлении 2:

Проблема, которая все еще остается проблемой, которая все еще остается, следующие. Эти нападения от ботов, которые ищут определенные файлы на Вашем сервере. Этот конкретный сканер ищет файл/w00tw00t.at. ISC.SANS.DFind:).

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

От моего предыдущего ответа мы заключили, что Apache возвращает сообщения об ошибках из-за плохо сформированного запроса HTML 1.1. Все веб-серверы, поддерживающие HTTP/1.1, должны, вероятно, возвратить ошибку, когда они получают это сообщение (я не проверил RFC дважды - возможно, RFC2616 говорит нам).

Наличие w00tw00t.at. ISC.SANS.DFind: на Вашем сервере некоторые, где мистически не означает "Вас, находятся в некоторой проблеме"... Если Вы создаете w00tw00t.at. ISC.SANS.DFind: файл в Вашем DocumentRoot или даже DefaultDocumentRoot, это не имеет значения... сканер, отправляет поврежденный запрос HTTP/1.1, и апач говорит "нет, это - плохой запрос... до свидания". Данные в w00tw00t.at. ISC.SANS.DFind: файл не будет подаваться.

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

Другой вещью Вы могли возможно посмотреть на использование, является функция RBL в mod_security. Возможно, существует РУБЛЬ онлайн некоторые, где это обеспечивает w00tw00t дюйм/с (или другого известного злонамеренного дюйм/с). Это однако означало бы, что mod_security делает поиск DNS для каждого запроса.

w00tw00t.at.blackhats.romanian.anti-секунда является попыткой взламывания и использует IP имитации, таким образом, поиски, такие как VisualRoute сообщат о Китае, Польше, Дании и т.д. согласно IP, являющемуся временно назначенным в то время. Так установка Отклонять IP или разрешимого Имени хоста почти совсем невозможна, когда это изменится в течение часа.

Как насчет того, чтобы добавить правило к modsecurity? Что-то вроде этого:

   SecRule REQUEST_URI "@rx (?i)\/(php-?My-?Admin[^\/]*|mysqlmanager
   |myadmin|pma2005|pma\/scripts|w00tw00t[^\/]+)\/"
   "severity:alert,id:'0000013',deny,log,status:400,
   msg:'Unacceptable folder.',severity:'2'"

Ив также начал видеть эти типы сообщений в моих файлах журнала. Один из способов предотвратить эти типы атак - настроить fail2ban ( http://www.fail2ban.org/ ) и настроить специальные фильтры для внесения этих IP-адресов в черный список правил iptables.

Вот пример фильтра, который блокирует IP-адрес, связанный с отправкой этих сообщений

[Вт, 16 августа, 02:35:23 2011] [ошибка] [клиент] Файл не существует: /var/www/skraps/w00tw00t.at.blackhats.romanian.anti-sec :) === apache w00t w00t messages jail - регулярное выражение и фильтр === Тюрьма

 [apache-wootwoot]
 enabled  = true
 filter   = apache-wootwoot
 action   = iptables[name=HTTP, port="80,443", protocol=tcp]
 logpath  = /var/log/apache2/error.log
 maxretry = 1
 bantime  = 864000
 findtime = 3600

Фильтр

 # Fail2Ban configuration file
 #
 # Author: Jackie Craig Sparks
 #
 # $Revision: 728 $
 #
 [Definition]
 #Woot woot messages
 failregex = ^\[\w{1,3} \w{1,3} \d{1,2} \d{1,2}:\d{1,2}:\d{1,2} \d{1,4}] \[error] \[client 195.140.144.30] File does not exist: \/.{1,20}\/(w00tw00t|wootwoot|WootWoot|WooTWooT).{1,250}
 ignoreregex =

Фильтрация IP-адресов - не лучшая идея, imho. Почему бы не попробовать отфильтровать известную строку?

Я имею в виду:

iptables -I INPUT -p tcp --dport 80 -m string --to 60 --algo bm --string 'GET /w00tw00t' -j DROP

Я вижу, что большинство решений уже рассмотрено выше, однако я хотел бы отметить, что не все клиенты, отправившие HTTP/1.1 запрос без атак на имя хоста , нацелены непосредственно на ваш сервер. Есть много различных попыток перепечатать и/или использовать сетевую систему, предшествующую вашему серверу, т.е. используя:

client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /tmUnblock.cgi

для атаки на маршрутизаторы Linksys и т.д. Поэтому иногда это помогает расширить фокус и разделить усилия по защите между всеми системами с равным доступом, т.е.: реализовать правила маршрутизатора, реализовать правила брандмауэра (надеюсь, в вашей сети они есть), реализовать правила серверного брандмауэра/IP-таблицы и связанные с ними сервисы, т.е. mod_security, fail2ban и т.д.

как насчет этого?

iptables -I INPUT -p tcp --dport 80 -m string --to 70 --algo bm --string 'GET /w00tw00t.at.ISC.SANS.DFind' -j DROP
iptables -I INPUT -p tcp --dport 80 -m string --to 70 --algo bm --string 'GET /w00tw00t.at.ISC.SANS.DFind' -j LOG --log-level 4 --log-prefix Hacktool.DFind:DROP:

мне подходит.

Если вы используете hiawatha веб-сервер в качестве обратного прокси, то эти снимки автоматически сбрасываются как мусор, и клиент запрещен. Он также фильтрует XSS и CSRF эксплоиты.