ModSecurity на Apache (Хрипящий Debian), вход Аутентификации

Я плохо знаком с ModSecurity, он работает отлично на сервере, но я хотел бы управлять способом, которым он регистрирует вещи. Например, поскольку я диагностирую свой веб-сайт, чтобы добавить в белый список или исправить php кодирование проблем так, чтобы у меня могло быть чистое modsec_audit.log когда все работает правильно, я столкнулся со следующим.

Каждый раз, когда я запрашиваю URL, который защищен паролем любой basic или htdigest аутентификация ModSecurity регистрирует это в modsec_audit.log следующим образом:

Аутентификация htdigest:

--838e7b1b-A--
[17/Nov/2013:19:13:51 +0200] Uoj5T8CoAWQAABfMVE0AAAAA xxx.xxx.xxx.xxx XXXXX xxx.xxx.xxx.xxx XXXXX
--838e7b1b-B--
GET / HTTP/1.1
Host: XXX.XXX.com:XXXX
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:25.0) Gecko/20100101 Firefox/25.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive

--838e7b1b-F--
HTTP/1.1 401 Authorization Required
WWW-Authenticate: Digest realm="Members Only", nonce="XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX", algorithm=MD5, qop="auth"
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 290
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1

--838e7b1b-H--
Stopwatch: 1384708431494144 2002 (- - -)
Stopwatch2: 1384708431494144 2002; combined=32, p1=0, p2=0, p3=0, p4=0, p5=32, sr=0, sw=0, l=0, gc=0
Producer: ModSecurity for Apache/2.6.6 (http://www.modsecurity.org/); OWASP_CRS/2.2.5.
Server: Apache

--838e7b1b-Z--

или

стандартная аутентификация:

--b8248f7a-A--
[17/Nov/2013:19:28:11 +0200] Uoj8q8CoAWQAABgxs7kAAAAM xxx.xxx.xxx.xxx XXXXX xxx.xxx.xxx.xxx XXXXX
--b8248f7a-B--
GET / HTTP/1.1
Host: XXX.XXX.com
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:25.0) Gecko/20100101 Firefox/25.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Cookie: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX; XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Connection: keep-alive

--b8248f7a-F--
HTTP/1.1 401 Authorization Required
WWW-Authenticate: Basic realm="Members Only"
Content-Encoding: gzip
Vary: Accept-Encoding,User-Agent
Cache-Control: no-cache, private, no-transform, must-revalidate, proxy-revalidate, post-check=300, pre-check=300, max-age=300
Pragma: no-cache
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html

--b8248f7a-H--
Apache-Handler: x-httpd-suphp
Stopwatch: 1384709291811105 152463 (- - -)
Stopwatch2: 1384709291811105 152463; combined=54, p1=0, p2=0, p3=0, p4=0, p5=54, sr=0, sw=0, l=0, gc=0
Producer: ModSecurity for Apache/2.6.6 (http://www.modsecurity.org/); OWASP_CRS/2.2.5.
Server: Apache

--b8248f7a-Z--

Вышеупомянутый вход происходит прямо после запроса я не показываю то, что происходит на неудавшемся пароле или успешном вообще.

Мой вопрос состоит в том, если существует какой-либо способ мешать ему регистрировать это. Я пытался добавить свой IP в белый список, но он не имел никакого результата. Я не уверен - ли это хорошая идея мешать ему регистрировать такую вещь или нет, но я думаю, что это просто лавинно разошлет /var/log/apache2/modsec_audit.log с такой информацией каждый раз "I" даже запрашивают защищенный паролем URL.

Еще некоторая информация о моем сервере:

# apt-cache show libapache-mod-security | grep Version
Version: 2.6.6-6+deb7u1

Я использую следующие правила до сих пор:

/usr/share/modsecurity-crs/base_rules/

.. и modsecurity.conf-рекомендуемый как modsecurity.conf

Заранее спасибо. Удачи

Править:

Я думаю, что нашел обходное решение, которое решает проблему.

Для исключения состояния 401 из того, чтобы быть зарегистрированным, я изменился SecAuditLogRelevantStatus regex в modsecurity.conf от этого:

SecAuditLogRelevantStatus "^(?:5|4(?!04))"

к этому:

SecAuditLogRelevantStatus "^(?:5|4\d[^41])"

Я также внес дополнительное изменение, не уверенное, если это настолько релевантно, но я изменился SecDefaultAction в modsecurity_crs_10_setup.conf от этого:

SecDefaultAction "phase:2,deny,log"

к этому:

SecDefaultAction "phase:2,deny,log,noauditlog"

После тестирования на защищенном паролем URL я теперь ничего не вкладываю modsec_audit.log который является точно, что я хотел. Я не уверен, был ли намного намного более умный способ сделать это, но это работает. Любые комментарии ценятся.

5
задан 18 November 2013 в 04:08
1 ответ

1) Убедитесь, что ваше правило белого списка обходит фазу 1 и является наивысшим среди самых высоких правил в вашем наборе правил.

Вот пример правила:

SecRule REMOTE_ADDR "^111.222.333.444" phase:1,nolog,allow,ctl:ruleEngine=off

Обратите внимание, что оно не выполняется на этапе 1 и не продолжается дальше часть процесса сканирования, он настроен так, чтобы разрешить, не регистрировать вообще и не подчиняется механизму правил.

2) HTTP 401 - это код ошибки с двумя звеньями. Доступ к ресурсу URL требует аутентификации пользователя, 1) которая еще не была предоставлена ​​или 2) которая была предоставлена, но не прошла проверку авторизации. Это важно для корректирующих действий при попытках вторжения, таких как вход в систему методом грубой силы.

3) Действительно ли дата в этих журналах относится к ноябрю 2013 года? Возможно, вам потребуется обновить дату и время на вашем устройстве.

0
ответ дан 3 December 2019 в 02:10

Теги

Похожие вопросы