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

Борьба с 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 hostname 80
GET /blahblahblah.html HTTP/1.1  (enter)
(enter)

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

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

GET /blahblahblah.html HTTP/1.1
Host: blah.com

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

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

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

Я имею в виду:

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

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