У меня есть сервер с 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 решения, может кто-нибудь прокомментировать их, хорошие они или нет.
Первое решение, которое приходит мне на ум, - исключить эти атаки из моих журналов ошибок apache. Это облегчит мне выявление других срочных ошибок по мере их возникновения, и мне не придется выплевывать длинный журнал.
Я думаю, что второй вариант лучше, и это блокировка хостов, которые отправляются неправильно. В этом примере атака w00tw00t отправляется без имени хоста, поэтому я думаю, что могу заблокировать хосты, которые находятся в неправильной форме.
Обновление 2
Пройдя ответы, я пришел к следующим выводам.
Чтобы иметь настраиваемое ведение журнала для apache, потребуются некоторые ненужные ресурсы, и если действительно есть проблема, вы, вероятно, захотите просмотреть полный журнал, чтобы ничего не пропало.
Лучше просто игнорировать попадания и сконцентрироваться на лучшем способе анализа журналов ошибок. Использование фильтров для ваших журналов - хороший подход для этого.
Заключительные мысли по этому поводу
Упомянутая выше атака не достигнет вашего компьютера, если у вас, по крайней мере, есть последняя версия системы, так что в принципе не о чем беспокоиться.
Через некоторое время может быть трудно отфильтровать все фиктивные атаки от реальных, поскольку журналы ошибок и доступа становятся чрезвычайно большими.
Любое предотвращение этого будет стоить вам ресурсов, и рекомендуется не тратить ресурсы на неважные вещи.
Решение, которое я использую сейчас, это 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
подвиги.