Работа с HTTP w00tw00t атаками

У меня есть сервер с apache, и я недавно установил mod_security2, потому что меня сильно атакует это:

Моя версия apache - apache v2.2.3, и я использую mod_security2.c

Это были записи из журнала ошибок:

[Wed Mar 24 02:35:41 2010] [error] 
[client 88.191.109.38] client sent HTTP/1.1 request without hostname 
(see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)

[Wed Mar 24 02:47:31 2010] [error] 
[client 202.75.211.90] client sent HTTP/1.1 request without hostname 
(see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)

[Wed Mar 24 02:47:49 2010] [error]
[client 95.228.153.177] client sent HTTP/1.1 request without hostname
(see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)

[Wed Mar 24 02:48:03 2010] [error] 
[client 88.191.109.38] client sent HTTP/1.1 request without hostname
(see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)

Вот ошибки из access_log:

202.75.211.90 - - 
[29/Mar/2010:10:43:15 +0200] 
"GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 392 "-" "-"
211.155.228.169 - - 
[29/Mar/2010:11:40:41 +0200] 
"GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 392 "-" "-"
211.155.228.169 - - 
[29/Mar/2010:12:37:19 +0200] 
"GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 392 "-" "-" 

Я попытался настроить mod_security2 следующим образом:

SecFilterSelective REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind"
SecFilterSelective REQUEST_URI "\w00tw00t\.at\.ISC\.SANS"
SecFilterSelective REQUEST_URI "w00tw00t\.at\.ISC\.SANS"
SecFilterSelective REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind:"
SecFilterSelective REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind:\)"

Дело в mod_security2 в том, что SecFilterSelective не может быть использован, он дает мне ошибки. Вместо этого я использую правило, подобное этому:

SecRule REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind"
SecRule REQUEST_URI "\w00tw00t\.at\.ISC\.SANS"
SecRule REQUEST_URI "w00tw00t\.at\.ISC\.SANS"
SecRule REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind:"
SecRule REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind:\)"

Даже это не работает. Я не знаю, что делать дальше. У кого-нибудь есть совет?

Обновление 1

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

Я придумала 2 других решения, кто-то может прокомментировать их, чтобы быть хорошим или нет.

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

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

Обновление 2

Пройдя через ответы, я пришел к следующим выводам.

1. Чтобы иметь собственную регистрацию для apache, потребуются некоторые ненужные ресурсы, и, если действительно есть проблема, вы, вероятно, захотите просмотреть полный журнал без каких-либо пропусков.

2. Лучше просто игнорировать попадания и сосредоточиться на лучшем способе анализа журналов ошибок. Использование фильтров для ваших журналов хороший подход для этого.

Заключительные мысли по этому вопросу

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

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

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

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

Спасибо всем за помощь, и я надеюсь, что этот пост может быть полезен и для кого-то еще.

Из вашего журнала ошибок они отправляют запрос HTTP / 1.1 без части запроса Host :. Из того, что я прочитал, Apache отвечает 400 (плохой запрос) на этот запрос, прежде чем передать его mod_security. Так что не похоже, что ваши правила будут обработаны. (Apache разбирается с этим перед тем, как передать его mod_security)

Попробуй себя:

имя хоста telnet 80
GET /blahblahblah.html HTTP / 1.1 (введите)
(войти)

Вы должны получить ошибку 400 и увидеть ту же ошибку в своих журналах. Это плохой запрос, и Apache дает правильный ответ.

Правильный запрос должен выглядеть так:

GET /blahblahblah.html HTTP / 1.1
Ведущий: blah.com

Обойти эту проблему можно было бы путем исправления mod_uniqueid, чтобы сгенерировать уникальный идентификатор даже для неудачного запроса, чтобы apache передал запрос своим обработчикам запросов. Следующий URL-адрес представляет собой обсуждение этой работы и включает в себя исправление для mod_uniqueid, которое вы можете использовать: http://marc.info/?l=mod-security-users&m=123300133603876&w=2

Не удалось найти других решений для него и задаться вопросом, действительно ли решение требуется.

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

Я имею в виду:

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

Iv также начал видеть эти типы сообщений в моих файлах журнала. Одним из способов предотвращения атак такого типа является настройка 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 сообщения тюрьма - регулярное выражение и фильтр === 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 =

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

Я лично написал скрипт 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 не смог проанализировать запросы самостоятельно, они не соответствуют спецификации. Я не уверен, что у вас есть проблема здесь - apache регистрирует странное дерьмо, которое происходит в сети, если он не регистрирует это, вы не будете знать, что это даже происходит. Ресурсы, необходимые для регистрации запросов, вероятно, минимальны. Я понимаю, что расстраивает то, что кто-то заполняет ваши журналы, но это будет более расстраивающим, если вы отключите ведение журнала только для того, чтобы обнаружить, что он вам действительно нужен. Как будто кто-то взломал ваш веб-сервер, и вам нужны логи, чтобы показать, как они взломали.

Одним из решений является настройка ErrorLogging через syslog, а затем с помощью rsyslog или syslog-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-адресах или он поступает из большого распределенного ботнета? Для получения выгоды от iptables потребуется X% дубликатов.

Вы говорите в обновлении 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, а apache говорит: «Нет, это плохой запрос ... до свидания». Данные в файле w00tw00t.at.ISC.SANS.DFind: не будут обслуживаться.

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

Еще одна вещь, на которую вы могли бы обратить внимание - это функция RBL в mod_security. Возможно, в сети есть RBL, где есть IP-адреса w00tw00t (или другие известные вредоносные IP-адреса). Это, однако, означает, что mod_security выполняет поиск DNS для каждого запроса.

Как насчет добавления правила в 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'"

Я вижу, что большинство решений уже описаны выше, однако я хотел бы отметить, что не все клиентские запросы 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веб-сервер как этот, reverse proxyэти сканы автоматически отбрасываются как мусор и clientзабанены. Он также фильтрует XSSи CSRFиспользует.