1

Randomly, the modsecurity blocks legitimate clients requests giving the error 403. Here is para of the modsec_audit.log:

    ---d6e99f36-A--
[21/Jun/2020:07:14:45 +0100] Xu761X8AAAEAADI1YrAAAABQ xxx.xxx.xxx.xxx 60036 xxx.xxx.xxx.xxx 443
--d6e99f36-B--
GET /s/p.json?eyJ0IjoyLjksImYiOnsiZmxpX3BsIjoiYXNwZXJzb3IiLCJmbGlfZyI6LTEsImZsaV9jIjotMSwiZmxpX20iOjAsImZsaV9hIjoyMDE1fSwiY3NyZiI6ImE5MDMwMDkxLTBlZjg$
Host: fneon.eu
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0
Accept: */*
Accept-Language: pt-PT,pt;q=0.8,en;q=0.5,en-US;q=0.3
Accept-Encoding: gzip, deflate, br
Referer: https://example.com/
Content-Type: application/json,charset=UTF-8
DNT: 1
Connection: keep-alive
Cookie: jwt=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIyYzMwOGQwYTc5NGEyZWU2MjMxYzI2M2EyYWMzNjkwMCIsImV4cCI6MTU5MzY0NDQwMCwiaWF0IjoxNTkyNzE5ODg1$
Pragma: no-cache
Cache-Control: no-cache

--d6e99f36-F--
HTTP/1.1 403 Forbidden
X-FRAME-OPTIONS: DENY
X-Content-Type-Options: nosniff
Content-Length: 199
Keep-Alive: timeout=5, max=89
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1

--d6e99f36-E--
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access this resource.</p>
</body></html>

--d6e99f36-H--
Apache-Error: [file "mod_evasive20.c"] [line 259] [level 3] client denied by server configuration: %s
Apache-Handler: proxy-server
Stopwatch: 1592720085355364 815 (- - -)
Stopwatch2: 1592720085355364 815; combined=42, p1=35, p2=0, p3=1, p4=0, p5=5, sr=0, sw=1, l=0, gc=0
Response-Body-Transformed: Dechunked
Producer: ModSecurity for Apache/2.9.0 (http://www.modsecurity.org/).
Server: Apache
Engine-Mode: "ENABLED"

--d6e99f36-Z--

Here is my configuration (only the changes):

/etc/modsecurity/modsecurity.conf

SecRuleEngine On 
SecResponseBodyAccess Off 
SecRequestBodyLimit 5242880 (15Mb)

/etc/apache2/mods-enabled/evasive.conf
<IfModule mod_evasive20.c>
    DOSHashTableSize    3097
    DOSPageCount        10
    DOSSiteCount        75
    DOSPageInterval     5
    DOSSiteInterval     1
    DOSBlockingPeriod   3000
    DOSWhitelist 127.0.0.1 
    DOSWhitelist xxx.xxx.xxx.xxx 
    DOSWhitelist  xxx.xxx.xxx.xxx 
    DOSWhitelist xxx.xxx.xxx.xxx
    DOSLogDir           "/var/log/mod_evasive"
</IfModule>

/etc/apache2/conf-enabled/security.conf 
ServerTokens Prod

One way to reproduce the problem is when the client makes this type of request:

https://example.com/s/p.json?eyJ0IjoyLjksImYiOnsiZmxpX3BsIjoiYXNwZXJzb3IiLCJmbGlfZyI6LTEsImZsaV9jIjotMSwiZmxpX20iOjAsImZsaV9hIjoyMDExfSwiY3NyZiI6ImE5MDMwMDkxLTBlZjgtNDcyOC05YjQ1LTU1MWY3M2U5YjQ5MCJ9

...which in my case is a legitimate request. Can anyone tell me how to solve this problem? Thank you.

Kaspacainoombro
  • 13
  • 1
  • 5

2 Answers2

1

It's normal that ModSecurity causes false positives with all the default rules enabled. That's why you should disable the rules that are causing problems, preferably only for the URLs that wouldn't work without disabling them. As your citations from the logs are missing the rule IDs it's hard to give an exact answer, but here's an example of the process:

  1. First find the rules causing problems. If e.g. the IP address of the legitimate client is 198.51.100.123, you might:

    grep "198.51.100.123" /var/log/apache2/example.com-error.log

    It's important you limit the searches to known good IPs; otherwise you'd end up allowing something actually malicious!

  2. Look at the ModSecurity: Warning lines and concentrate on [id ""] and [uri ""]. Let's say you find lines that have [uri "/s/p.json"] and they are firing rules [id "941100"] and [id "941120"].

  3. Configure your Apache either globally or virtual host based to disable those rules, e.g.

    <LocationMatch "/s/p.json">
    SecRuleRemoveById 941100 941120
</LocationMatch>

Some articles on ModSecurity & handling false positives:

Esa Jokinen
  • 43,252
  • 2
  • 75
  • 122
  • It does not appear that in the log of apache. But appears his: [Sun Jun 21 06:55:42.455242 2020] [evasive20:error] [pid 12304:tid 139674330769152] [client xxx.xxx.xxx.xxx:59782] client denied by server configuration: proxy:http://127.0.0.1:300/p.json, referer: https://example.com/. Does the tid is the id to use in your exampel code for SecRuleRemoveByID? – Kaspacainoombro Jun 22 '20 at 10:10
  • No, that is not the rule ID. Could it be that the proxy denies the connection, instead? Have you considered this might not be related to ModSecurity at all? – Esa Jokinen Jun 22 '20 at 11:15
  • 1
    Thank you, this response was very helpful to me. I just add that, in my case, the log to consult is in `/var/log/apache2/modsec_audit.log` and the file where to insert the rules is `/etc/modsecurity/modsecurity.conf`. – Francesco Galgani Jun 15 '21 at 00:22
0

I have a strange issue with this also

When I have modsec turned on. My Google News RSS feeds wont work, And I cannot get instant indexing to work because the feeds wont show in my publisher centre.

if I turn modsec off. It works. RSS feeds show in my publisher centre and I can get instant indexing in google

Matts Cloud
  • 1