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

82

У меня есть сервер с 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 . Он посылает мне сводки журналов, и они фильтруются и группируются. Таким образом, вы можете легко отделить важное от неважного.

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

Саиф Бечан
источник

Ответы:

34

Из вашего журнала ошибок они отправляют запрос 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

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

Имо
источник
Теперь я вижу проблему. Рекомендуете ли вы решение, представленное в статье, или считаете, что лучше просто оставить все как есть. Это сканер для любых задних дверей в системе. Если я оставлю это только сканирование, я мог бы однажды напасть.
Саиф Бечан
1
Здравствуйте, Saif, я думаю, что если вы будете регулярно обновлять установку apache с помощью своих дистрибутивных (или ручных) исправлений безопасности, у вас все будет в порядке. Плохо структурированный HTTP / 1.1-запрос (как вы уже видели) не должен возвращать ничего, кроме ошибки 400 от apache. Похоже , что это может быть каким - то сканирование уязвимостей сосредоточена на маршрутизаторах DLink. (По некоторым другим источникам)
Имо
Есть хотя бы способ вытащить эти поля из моего apache error_log
Саиф Бечан,
Вы , может быть в состоянии сделать это с помощью mod_log :: httpd.apache.org/docs/2.2/mod/mod_log_config.html#customlog
Имо
Мой дополнительный совет : настройте виртуальный хост по умолчанию рядом с фактически используемым. Упомянутые выше попытки попадут в журналы для виртуального хоста по умолчанию .
Koos van den Hout
16

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

Я имею в виду:

iptables -I INPUT -p tcp --dport 80 -m string --to 60 --algo bm --string 'GET /w00tw00t' -j DROP
Des
источник
spamcleaner.org/en/misc/w00tw00t.html похожее решение, но более подробное.
Исаак
Одна проблема с фильтрацией строк в брандмауэре заключается в том, что он «довольно медленный».
Алексис Вилке
@AlexisWilke у вас есть доказательства того, что фильтрация строк iptables медленнее, чем фильтрация на уровне apache?
17
@jrwren На самом деле, это может быть довольно медленно, если и только если вы не передадите смещение пакета, чтобы прекратить поиск, то есть здесь «--to 60». По умолчанию он будет выполнять поиск по всему пакету, при этом максимальный лимит составляет 65 535 байт, максимальная длина IP-пакета: blog.nintechnet.com/… В руководстве четко сказано : «Если не пройден, то по умолчанию используется размер пакета».
gouessej
это теоретический макс. более реалистичная максимальная длина через интернет ~ 1500.
Jrwren
11

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 =
Джеки Крейг Спаркс
источник
2
Это правда, что вы можете заблокировать их, но в этом нет необходимости, потому что это просто плохие запросы. Лучше просто игнорировать их, сохранив свою работу, и вы освободите некоторые ресурсы.
Саиф Бечан
Правильно @ Saif Bechan, если кто-то беспокоится о том, что «тестирование атак» будет успешным, ему лучше вместо этого исправить собственное приложение, а не тратить время, чтобы найти способ заблокировать это.
Томас Бергер
Дали +1, спасибо за ответ.
Саиф Бечан
4
@SaifBechan, я не согласен. w00tw00t - это сканер уязвимостей, и машине, которая выдает такие запросы, нельзя доверять попытки других типов запросов, поэтому, если я являюсь системным администратором, и мне требуется 2 минуты, чтобы запретить таких клиентов на несколько дней, я сделал бы так. Я бы не стал основывать всю свою реализацию безопасности на таком подходе.
Исаак
3

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

PRW
источник
Эти сканирования уязвимостей не используют поддельные IP-адреса. Если они это сделают, трехстороннее рукопожатие TCP не будет завершено, и Apache не будет регистрировать запрос. Предостережения (мошеннические интернет-провайдеры, операторы маршрутизаторов и т. Д.) См. На security.stackexchange.com/q/37481/53422
Энтони Дж - правосудие для Моники
2

Я лично написал скрипт 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)
Xorlev
источник
Это чтобы предотвратить атаку w00tw00t
Саиф Бечан
Да, он сканирует журналы ошибок Apache для любых IP-адресов "w00tw00t" и добавляет их, если они не существуют, хотя для простоты я не добавил проверку на наличие дубликатов.
Xorlev
Этот сценарий, вероятно, должен использовать таблицу, добавление множества дополнительных правил в цепочки iptables значительно замедлит обработку.
Эрик
Он использует таблицу. Однако я многое упростил, поскольку он был адаптирован к моей системе.
Xorlev
Как вы думаете, это лучшее решение, чтобы использовать mod_security
Saif Bechan
2

Я считаю, что причина того, что 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% дубликатов.

hellomynameisjoel
источник
Хороший ответ, мне нравятся разные подходы. Размышляя об этом, наличие собственной регистрации создаст больше ресурсов, потому что сначала нужно проверить все, я думаю, эта опция также не работает. Теперь у меня включен logwatch. Это отправляет мне отчет 2 раза в день с кратким описанием всех систем. Журналы apache также проверяются, и он просто говорит, что w00tw00t пытается 300 раз. Я думаю, что я оставлю настройку, как это в настоящее время.
Саиф Бечан
1

Вы говорите в обновлении 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 для каждого запроса.

Имо
источник
Я не думаю, что Apache отклоняет их, он просто выдает ошибку, но поиск все еще проходит. У меня такой же w00tw00t.at.ISC.SANS.DFind в журнале доступа. Это делает GET. Итак, поиск завершен, и если у вас есть файл на вашем компьютере, он будет выполнен. Я могу опубликовать записи в журнале доступа, но они выглядят так же, как и в журнале ошибок, только с GET перед ними. Apache выдает ошибку, но запрос проходит. Вот почему я спросил, будет ли хорошей идеей заблокировать этот запрос без имен хостов. Но я не хочу блокировать обычных пользователей.
Саиф Бечан
1
Конечно, вы получаете ту же запись в журнале доступа, но посмотрите на код ошибки ... 400. Она не обрабатывается. HTTP / 1.1 (имя хоста) используется, чтобы сообщить apache, на какой виртуальный хост отправлять запрос ... без части имени хоста запроса HTTP / 1.1 apache не знает, куда отправить запрос и возвращает ошибку «400 неверных запросов» вернуться к клиенту.
Имо
Попробуйте сами ... создайте html-страницу на своем веб-сервере и попробуйте добраться до нее вручную, используя "telnet hostname 80" ... остальные шаги приведены в моем первом ответе. Я бы добавил большую награду за то, что вы не можете отобразить html-файл, используя HTTP / 1.1 без имени хоста.
Имо
Ах, да, да, что указал мне на это. Я всегда думал, что access_log - это записи, которые были пропущены через журнал ошибок и фактически введены на ваш компьютер. Спасибо за указание на это мне, и я буду редактировать свой пост. Я действительно ценю твою помощь.
Саиф Бечан
Привет, Сайф, никаких проблем, рад, что помог. С уважением, Имо
Имо
1

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

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

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

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

Милан
источник
1

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

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:

отлично работает для меня

Урбах-Webhosting
источник
я порекомендовал OWASP_CRS / 2.2.5 или набор правил терки для mod_security
Urbach-Webhosting
Это действительно не очень хорошая идея. Вы будете в конечном итоге с большим количеством висящих соединений. Кроме того, если на вашем сайте обсуждаются эти запросы, вы можете получить ложные срабатывания.
Касперд
0

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

Стюарт Кардалл
источник