ModSecurity 3 doesn't seem to be blocking anything sent through post (like forms).
Logs say:
ModSecurity: Access denied with code 200 (phase 2). detected XSS using
libinjection. [file
"/usr/local/coreruleset-3.3.0/rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf"]
[line "37"] [id "941100"] [rev ""] [msg "XSS Attack Detected via
libinjection"] [data "Matched Data: XSS data found within ARGS:text:
alert('XSS')"] [severity "2"] [ver "OWASP_CRS/3.3.0"]
[maturity "0"] [accuracy "0"] [tag "application-multi"] [tag
"language-multi"] [tag "platform-multi"] [tag "attack-xss"] [tag
"paranoia-level/1"] [tag "OWASP_CRS"] [tag "capec/1000/152/242"]
[hostname "fullserver.ru"] [uri "/support/ticket.php"] [unique_id
"1630221362"] [ref
"v1106,29t:utf8toUnicode,t:urlDecodeUni,t:htmlEntityDecode,t:jsDecode,t:cssDecode,t:removeNulls"]
But the request is being sent straight into database and added there.
GET requests like that are momentarily blocked in browser with 403.
I tried setting
SecDefaultAction "phase:1,log,auditlog,deny,status:403"
SecDefaultAction "phase:2,log,auditlog,deny,status:403"
But no luck there, nothing changed.
I don't know what to do, can anyone help?
Try searching your configuration for other SecDefaultAction and be sure there's no one with 'status:200'. Also be sure you are not running ModSecurity in DetectionOnly mode (see modsecurity.conf).
Related
I'm using mod_security 2.9.2 with OWASP Core Rule Set version 3.3 running under Apache 2.4.
To try to stop simple DOS attacks, I've enabled the rule 912-DOS-PROTECTION, but it's not having any effect.
To enable the rule, I added the following to my mod_security.conf as suggested by the documentation in REQUEST-912-DOS-PROTECTION.conf:
SecAction \
"id:900700,phase:1,nolog,pass,t:none,\
setvar:'tx.dos_burst_time_slice=3',\
setvar:'tx.dos_counter_threshold=50',\
setvar:'tx.dos_block_timeout=600',\
setvar:'tx.static_extensions=/.jpg/ /.jpeg/ /.png/ /.gif/ /.js/ /.css/ /.ico/'"
This rule should activate when the server gets more than 50 non-image requests over a 3-second period.
However, it doesn't have any effect on my server, and does not stop any incoming requests.
To simulate real traffic, I use the utility ab to create connections to my server.
For example, here's a test that uses 60 concurrent connections over a period of 6 seconds:
ab -c 60 -t 6 "[URL]"
I get the following output from a sample run:
Concurrency Level: 60
Time taken for tests: 6.018 seconds
Complete requests: 611
Failed requests: 0
Write errors: 0
Total transferred: 110954039 bytes
It appears all requests were successful. This is not what should happen. I would expect that, shortly after the test starts running, the DOS detection would be tripped, and subsequent requests would be blocked.
My modsec_audit.log does occasionally log some messages while I run these tests (but not on every run). Here's an example:
Message: Warning. Operator GE matched 2 at IP:dos_burst_counter. [file "/etc/httpd/modsecurity.d/activated_rules/REQUEST-912-DOS-PROTECTION.conf"] [line "269"] [id "912170"] [msg "Potential Denial of Service (DoS) Attack from [IP] - # of Request Bursts: 2"] [ver "OWASP_CRS/3.3.1"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "paranoia-level/1"] [tag "attack-dos"] [tag "OWASP_CRS"] [tag "capec/1000/210/227/469"]
Apache-Error: [file "apache2_util.c"] [line 273] [level 3] [client IP] ModSecurity: Warning. Operator GE matched 2 at IP:dos_burst_counter. [file "/etc/httpd/modsecurity.d/activated_rules/REQUEST-912-DOS-PROTECTION.conf"] [line "269"] [id "912170"] [msg "Potential Denial of Service (DoS) Attack from [IP] - # of Request Bursts: 2"] [ver "OWASP_CRS/3.3.1"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "paranoia-level/1"] [tag "attack-dos"] [tag "OWASP_CRS"] [tag "capec/1000/210/227/469"] [hostname "example.com"] [uri "/test.php"] [unique_id "Yu-n6NGj9kT3clHjZubuCQAAAM0"]
Apache-Handler: proxy:unix:/run/php-fpm/www.sock|fcgi://localhost
However, these messages appear only rarely, and it doesn't seem they indicate that any block occurred, as they are associated with log entries that show HTTP/1.1 200 OK. I assume this means that the request was successful, even if the threshold for DOS detection was reached.
Does anyone know how I can get the simple mod_security DOS protection to work as documented?
Thanks!
The mod_security configuration in Apache, on the CWP7.admin, generates a 403 access denied error when running Grav CMS:
[Thu Mar 21 15:40:47.967502 2019] [:error] [pid 21727:tid 140715786946304] [client 186.67.206.59:57900] [client 186.67.206.59] ModSecurity: Access denied with code 403 (phase 2). Pattern match "([\\~\\!\\#\\#\\$\\%\\^\\&\\*\\(\\)\\-\\+\\=\\{\\}\\[\\]\\|\\:\\;\"\\'\\\xc2\xb4\\\xe2\x80\x99\\\xe2\x80\x98\\`\\<\\>].*?){8,}" at REQUEST_COOKIES:grav-tabs-state. [file "/usr/local/apache/modsecurity-owasp-old/base_rules/modsecurity_crs_41_sql_injection_attacks.conf"] [line "157"] [id "981172"] [rev "2"] [msg "Restricted SQL Character Anomaly Detection Alert - Total # of special characters exceeded"] [data "Matched Data: \x22 found within REQUEST_COOKIES:grav-tabs-state: {\x22tab-content.options.advanced\x22:\x22data.content\x22,\x22tab-content.options\x22:\x22data.content\x22,\x22tab-content.options.advanced.blog\x22:\x22data.options\x22}"] [ver "OWASP_CRS/2.2.9"] [maturity "9"] [accuracy "8"] [tag "OWASP_CRS/WEB_ATTACK/SQL_INJECTION"] [hostname "xxxxxxxx.com"] [uri "/favicon.ico"] [unique_id "XJOwf0cQATwA6mgjE8O7AwAAANc"], referer: http://xxxxxxxx.com/
This error only happens when visiting the website a second time, making it very hard to solve.
Upon inspecting the logs, I found the same pattern of errors for Grav CMS based sites generated by mod_security. This answer by Barry Pollard guided my solution
The error noted the mod_security rule blocking my request:
/usr/local/apache/modsecurity-owasp-old/base_rules/modsecurity_crs_41_sql_injection_attacks.conf
the corresponding line
[line "157"]
And its ID
[id "981172"]
Using the advice from Barry , I added the following line after the rule:
SecRuleUpdateTargetById 981172 !REQUEST_COOKIES:grav-tabs-state
In this case I'm asking mod_security to omit REQUEST_COOKIES:grav-tabs-state from the rule 981172. This solved the issue.
Thanks from the bottom of my heart to #barrypollard
i ve a strange problem
i install prestashop library on symfony (iq2i/prestashop-webservice-bundle)
i can connect to two internet websites (one is http the other https)
but on the third i got the error:
{"message":"This call to PrestaShop Web Services returned an unexpected HTTP status of:403"}
i ve this website install localy too on my computer with the same files as the remote one, and i can connect with symfony to my local website, but nope on the internet one...
i check rights, .htaccess ...
so i enable the debug and i got:
You don't have permission to access /api/products
an idea please ?
if you have got the error:
[Fri Jun 15 16:28:52 2018] [error] [client 157.108.59.137] ModSecurity: Access denied with code 403 (phase 2). Operator EQ matched 0 at REQUEST_HEADERS. [file "/usr/local/apache2/conf/modsecurity/base_rules/modsecurity_crs_21_protocol_anomalies.conf"] [line "65"] [id "960009"] [rev "2.1.1"] [msg "Request Missing a User Agent Header"] [severity "NOTICE"] [tag "PROTOCOL_VIOLATION/MISSING_HEADER_UA"] [tag "WASCTC/WASC-21"] [tag "OWASP_TOP_10/A7"] [tag "PCI/6.5.10"]
with OVH provider
on the root folder, you ve got a filename .ovhconfig
you have to add the following line:
modsecurity == WAF === http.firewall=security
in our current environment, we have an internet facing web application and all the incoming traffic to the same is routed through an apache reverse proxy. On this reverse proxy we have configured ModSecurity as well.
Now, some of our inbound requests have content-type=text/plain. All these requests are being blocked by ModSec rule set with below logs :
[Tue Jan 10 11:14:31 2017] [error] [client 175.45.116.65] ModSecurity: [file "/etc/httpd/conf/crs/activated_rules/modsecurity_crs_30_http_policy.conf"] [line "64"] [id "960010"] [rev "2"] [msg "Request content type is not allowed by policy"] [data "text/plain"] [severity "CRITICAL"] [ver "OWASP_CRS/2.2.6"] [maturity "9"] [accuracy "9"] [tag "OWASP_CRS/POLICY/ENCODING_NOT_ALLOWED"] [tag "WASCTC/WASC-20"] [tag "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/EE2"] [tag "PCI/12.1"] Access denied with code 403 (phase 1). Match of "rx ^%{tx.allowed_request_content_type}$" against "TX:0" required. [hostname "hadToRemove"] [uri "hadToRemove"] [unique_id "WHQnZwoMD1QAACBlB70AAAAN"]
Now if we want to allow text/plain as an acceptable content-type, how should we add that. We already have a conf file where we have disabled/customized some rules. I just dont know how to add this one.
PS: according this post (https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/208), this issue is already fixed but for that we will have upgrade our ruleset.
You should have a modsecurity_crs_10_setup.conf file where these types of things are configured and then used by the various other rules.
That file has a line like the following:
#
# Set the following policy settings here and they will be propagated to the 30 rules
# file (modsecurity_crs_30_http_policy.conf) by using macro expansion.
# If you run into false positves, you can adjust the settings here.
#
SecAction \
"id:'900012', \
phase:1, \
t:none, \
setvar:'tx.allowed_methods=GET HEAD POST OPTIONS', \
setvar:'tx.allowed_request_content_type=application/x-www-form-urlencoded|multipart/form-data|text/xml|application/xml|application/x-amf|application/json', \
You can alter that last line to allow text/plain:
setvar:'tx.allowed_request_content_type=application/x-www-form-urlencoded|multipart/form-data|text/xml|application/xml|application/x-amf|application/json|text/plain', \
And then restart Apache.
I installed mod_security with an apache server, and now it's blocking only ie7/8/9 browser. (I can browse the web with firefox/chromium/etc)
The logs say:
Message: String match within "Proxy-Connection Lock-Token Content-Range Translate via if" at REQUEST_HEADERS_NAMES:Connection. [file "/etc/apache2/mod_security/modsecurity_crs_30_http_policy.conf"] [line "99"] [id "960038"] [msg "HTTP header is restricted by policy"] [data "Connection"] [severity "WARNING"] [tag "POLICY/HEADER_RESTRICTED"] [tag "POLICY/FILES_NOT_ALLOWED"] [tag "WASCTC/WASC-21"] [tag "OWASP_TOP_10/A7"] [tag "PCI/12.1"] [tag "WASCTC/WASC-15"] [tag "OWASP_TOP_10/A7"] [tag "PCI/12.1"]
Message: Access denied with code 403 (phase 2). [file "/etc/apache2/mod_security/modsecurity_crs_49_enforcement.conf"] [line "25"] [msg "Anomaly Score Exceeded (score 20): Common SPAM/Email Harvester crawler"]
Action: Intercepted (phase 2)
Stopwatch: 1337888078594451 2694 (918 2353 -)
Producer: ModSecurity for Apache/2.5.12 (http://www.modsecurity.org/); core ruleset/2.0.6.
Server: Apache
And the rule id "960038" is:
SecRule REQUEST_HEADERS_NAMES "#within %{tx.restricted_headers}""phase:2,t:none,pass,nolog,auditlog,msg:'HTTP header is restricted by policy',id:'960038',tag:'POLICY/HEADER_RESTRICTED',tag:'POLICY/FILES_NOT_ALLOWED',tag:'WASCTC/WASC-21',tag:'OWASP_TOP_10/A7',tag:'PCI/12.1',tag:'WASCTC/WASC-15',tag:'OWASP_TOP_10/A7',tag:'PCI/12.1',severity:'4',logdata:'%{matched_var}',setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.warning_anomaly_score},setvar:tx.policy_score=+%{tx.warning_anomaly_score},setvar:tx.%{rule.id}-POLICY/HEADERS_RESTRICTED-%{matched_var_name}=%{matched_var}"
I have one main question and two other derived from the first:
How do I know what this rule makes?
Is it safe to ignore this rule?
Is there any way to modify the rule in order to allow ie to navigate the web?
Answering Your First Question Mod-Security provide us a very
detailed documentation about the syntax of its Rule Language and
following is the link to its documentation. ModSecurity Rule Language
TX is for user defined variable tx.restricted_headers it defines
your HTTP policy like
SecAction "phase:1,t:none,nolog,pass,setvar:'tx.restricted_headers=/Proxy-Connection/ /Lock-Token/ /Content-Range/ /Translate/ /via/ /if/'"
for more detailed information refer this HTTP Policy
The Rule you have mentioned above is not blocking but it is
incrementing a numerial value maintained against suspicious header
name as mentioned in the HTTP policy i explained above.
The Rule that is blocking IE as seen from the logs mentioned
Message: Access denied with code 403 (phase 2). [file "/etc/apache2/mod_security/modsecurity_crs_49_enforcement.conf"] [line "25"] [msg "Anomaly Score Exceeded (score 20): Common SPAM/Email Harvester crawler"]
You can modify the anomaly score threshold or can change your HTTP policy.The Rule you have mentioned is correct and don't need to be commented.I hope you get my point