Справа з атаками 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. Для власного ведення журналу для апачу буде потрібно кілька непотрібних ресурсів, і якщо дійсно є проблема, ви, ймовірно, захочете подивитися на повний журнал, нічого не пропускаючи.

2. Краще просто ігнорувати звернення та сконцентруватися на кращому способі аналізу своїх журналів помилок. Використання фільтрів для ваших журналів - хороший підхід до цього.

Заключні думки з цього приводу

Згадана вище атака не охопить вашу машину, якщо ви принаймні маєте сучасну систему, тому в основному немає ніяких турбот.

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

Запобігання цього будь-яким способом коштуватиме вам ресурсів, і це хороша практика не витрачати свої ресурси на неважливі речі.

Я використовую зараз рішення - логвапут Linux . Він надсилає мені підсумки журналів, і вони фільтруються та групуються. Таким чином ви можете легко відокремити важливе від неважливого.

Дякую всім за допомогу, і я сподіваюся, що ця публікація може бути корисною і для когось іншого.

З вашого журналу помилок вони надсилають запит HTTP / 1.1 без частини запиту Host:. З того, що я прочитав, Apache відповідає на помилку 400 (поганий запит), перш ніж передавати mod_security. Отже, не схоже, що ваші правила будуть оброблені. (Apache займається цим, перш ніж вимагати передати mod_security)

Спробуйте самі:

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

Ви повинні отримати помилку 400 і побачити ту саму помилку у своїх журналах. Це поганий запит, і апаш дає правильну відповідь.

Належний запит повинен виглядати так:

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

Для вирішення цієї проблеми може бути виправлення mod_uniqueid, генерування унікального ідентифікатора навіть за невдалого запиту для того, щоб апаш передав запит на його обробники запитів. Наступна URL-адреса - це обговорення цієї роботи і включає виправлення для mod_uniqueid, який ви можете використовувати: http://marc.info/?l=mod-security-users&m=123300133603876&w=2

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

Фільтрування ІР - це не дуже гарна ідея, імхо. Чому б не спробувати фільтрувати відомий вам рядок?

Я маю на увазі:

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 повідомлення тюрма - регекс і фільтр === Тюрма

 [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 або дозволене ім'я хоста цілком неможливо, оскільки це зміниться протягом години.

Я особисто написав сценарій 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, де вони надають w00tw00t IP (або інші відомі шкідливі IP-адреси). Однак це означає, що mod_security здійснює пошук DNS для кожного запиту.

Як щодо додавання правила до забезпечення безпеки? Щось на зразок цього:

   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експлуатує.