Xpoint
   [напомнить пароль]

Проблема с получением REMOTE_ADDR в Apache2 + mod_security от frontend reverse proxy

Метки: [без меток]
2007-08-21 20:21:06 [обр] VLAD(0/5)[досье]

Использую Nginx (IP x.x.x.x) как frontend и Apache-2.2.4 (IP 127.0.0.1) + mod_security-2.1.1-r1 как backend. OS Gentoo Linux.
При помощи mod_rpaf беру "X-Forwarded-For" от Nginx и устанавливаю REMOTE_ADDR на Apache.
Apache видит все запросы с настоящего клиентского IP.
Но вот mod_security почему-то не видит этот новый REMOTE_ADDR. Все запросы идут со 127.0.0.1 и поэтому их невозможно отфильтровать по клиентскому IP.

Аналогичная конфигурация с Nginx, Apache-1.3.37 и mod_security-1.9.4 работает правильно.

спустя 21 час [обр] Dennis F. Latypoff aka funky_dennis(3/84)[досье]
патч для 2.1.2:
--- modsecurity-apache_2.1.2/apache2/mod_security2.c    2007-07-24 05:00:17.000000000 +0700
+++ modsecurity-apache_2.1.2-patched/apache2/mod_security2.c        2007-08-22 20:22:30.000000000 +0700
@@ -985,6 +985,7 @@
         NULL
     };
     static const char *postread_beforeme_list[] = {
+        "mod_rpaf-2.0.c",
         "mod_unique_id.c",
         NULL
     };
спустя 29 минут [обр] VLAD(0/5)[досье]

Dennis F. Latypoff aka funky_dennis[досье]: спасибо, вроде бы помогло.
Только теперь странная ошибка появилась: пытаюсь разрешить любые действия со своего ИПа вот таким правилом

SecRule REMOTE_ADDR "^1\.2\.3\.4$" "phase:1,allow,log,ctl:ruleEngine=Off"

(взято из документации) и получаю сразу "403 Access Denied".
При этом сообщение в error_log:

ModSecurity: Access allowed (phase 1). Pattern match "^1\\\\.2\\\\.3\\\\.4$" at REMOTE_ADDR.

Комментарю вышеприведённое правило - всё нормально работает.

спустя 1 час [обр] Dennis F. Latypoff aka funky_dennis(3/84)[досье]

http://www.modsecurity.org/doc......page/04-processing-phases.html

у Вас только фаза 1 (Request headers, обработка заголовков запроса) разрешена для Вашего IP, остальные фазы похоже подчиняются другим правилам.

спустя 30 минут [обр] VLAD(0/5)[досье]

Всё оказалось хитрее.
Вот мои настйроки: сначала идёт действие по умолчанию

SecDefaultAction "phase:2,log,deny,status:403,t:replaceNulls,t:compressWhitespace"

потом настройки модуля, потом мой whitelist для нескольких ИП и все остальные запретительные правила.
Проблема заключалась в статусе ответа сервера. mode_sec разрешал прохождение запроса, но вместе с этим выдавал 403, поэтому надо явно прописать статус 200 для "белых" ИПов.

SecRule REMOTE_ADDR "^(1\.2\.3\.4)|(5\.6\.7\.8)$" allow,status:200,nolog,ctl:ruleEngine=Off

Огромное спасибо за помощь. Попробую протолкнуть этот патч к разработчикам модуля; я не единственный с подобной проблемой.

спустя 18 часов [обр] VLAD(0/5)[досье]
А вот и разработчики модуля подоспели, обещают завтра выпустить релиз 2.1.3-rc2, в котором проблема с модулями mod_rpaf и mod_extract_forwarded2 решена.
http://article.gmane.org/gmane.comp.apache.mod-security.user/3721
спустя 8 часов [обр] VLAD(0/5)[досье]
Ещё один комментарий, чтобы не вводить в заблуждение читателей.
Потратил сегодня поллдня, чтобы досконально разобраться в проблеме с 403 ошибкой. В логе, после всех проверок и разрешения полного доступа для белового ИПа всё равно появлялась ошибка "Phase REQUEST_BODY subrequest already intercepted with code 403." и клиент получал 403.
Как оказалось, ошибка эта была внесена разработчиками Gentoo в свою ветку модуля, пишущими свои патчи для в т.ч. и для mod_security. Конкретно изменение появилось в последней версии mod_security-2.1.1-r1.
Патч mod_security-2.1.1-request_interception.patch должен был решить проблему несовместимости mod_security и mod_limitipconn.
Powered by POEM™ Engine Copyright © 2002-2005