У меня есть сервер с 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 . Он посылает мне сводки журналов, и они фильтруются и группируются. Таким образом, вы можете легко отделить важное от неважного.
Спасибо всем за помощь, и я надеюсь, что этот пост может быть полезен и для кого-то еще.
источник
Фильтрация IP-адресов не очень хорошая идея, имхо. Почему бы не попробовать отфильтровать строку, которую вы знаете?
Я имею в виду:
источник
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
Фильтр
источник
w00tw00t.at.blackhats.romanian.anti-sec является попыткой взлома и использует поддельные IP-адреса, поэтому при поиске, таких как VisualRoute, будет сообщаться Китай, Польша, Дания и т. д. в соответствии с IP-адресом, который был прикомандирован в то время. Поэтому установка запрещенного IP-адреса или разрешимого имени хоста практически невозможна, так как он изменится в течение часа.
источник
Я лично написал скрипт Python для автоматического добавления правил IPtables.
Вот несколько сокращенная версия без регистрации и прочего барахла:
источник
Я считаю, что причина того, что mod_security не работает для вас, заключается в том, что Apache не смог проанализировать запросы самостоятельно, они не соответствуют спецификации. Я не уверен, что у вас есть проблема здесь - apache регистрирует странное дерьмо, которое происходит в сети, если он не регистрирует это, вы не будете знать, что это даже происходит. Ресурсы, необходимые для регистрации запросов, вероятно, минимальны. Я понимаю, что расстраивает то, что кто-то заполняет ваши журналы, но это будет более расстраивающим, если вы отключите ведение журнала только для того, чтобы обнаружить, что он вам действительно нужен. Как будто кто-то взломал ваш веб-сервер, и вам нужны логи, чтобы показать, как они взломали.
Одним из решений является настройка ErrorLogging через syslog, а затем с помощью rsyslog или syslog-ng вы можете специально отфильтровать и отбросить эти нарушения RFC в отношении w00tw00t. Или же вы можете отфильтровать их в отдельный файл журнала просто, чтобы ваш основной ErrorLog легко читался. Rsyslog невероятно мощный и гибкий в этом отношении.
Так что в httpd.conf вы можете сделать:
тогда в rsyslog.conf у вас может быть:
Имейте в виду, что этот подход будет использовать во много раз больше ресурсов, чем при первоначальном ведении журнала непосредственно в файл. Если ваш веб-сервер очень занят, это может стать проблемой.
В любом случае рекомендуется отправлять все журналы на удаленный сервер регистрации как можно скорее, и это поможет вам в случае взлома, так как намного труднее удалить контрольный журнал того, что было сделано.
Блокировка IPTables - это идея, но вы можете получить очень большой список заблокированных iptables, который может повлиять на производительность. Есть ли шаблон в IP-адресах или он поступает из большого распределенного ботнета? Для получения выгоды от iptables потребуется X% дубликатов.
источник
Вы говорите в обновлении 2:
Из моего предыдущего ответа мы узнали, что 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? Что-то вроде этого:
источник
Я вижу, что большинство решений уже описаны выше, однако я хотел бы отметить, что не все клиентские запросы HTTP / 1.1, отправленные без атак на имя хоста , направлены непосредственно на ваш сервер. Существует много разных попыток отследить и / или использовать сетевую систему, предшествующую вашему серверу, т.е. использовать:
нацеливание на маршрутизаторы Linksys и т. д. Поэтому иногда это помогает расширить ваш фокус и разделить ваши усилия по защите между всеми системами с равным разделением, а именно: внедрить правила маршрутизатора, внедрить правила брандмауэра (надеюсь, в вашей сети есть такой), внедрить брандмауэр сервера / таблицу IP правила и связанные службы, например, mod_security, fail2ban и так далее.
источник
как насчет этого ?
отлично работает для меня
источник
Если вы используете
hiawatha
веб-сервер как этот,reverse proxy
эти сканы автоматически отбрасываются как мусор иclient
забанены. Он также фильтруетXSS
иCSRF
использует.источник