-
-
Notifications
You must be signed in to change notification settings - Fork 344
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Since 4.2.0 many Fediverse ActivityPub pushes to /inbox fail with rule 941100, 932130, 932260 and others #3698
Comments
Hi @ne20002, thank you for your feedback. Sorry to hear about these FP's. Rule 941100 uses the operator In case of other two rules, namely 932130 and 932260, as you can see the rules do what they are supposed to do (see comments - for 932260 please take a look at the comment of 932250 too). Unfortunately the only thing what you can do is the exclusions. Do you think these rules are too strict? May be we should move them to higher PL? |
I'm not sure. I have a few more FPs like this one on rule 932120:
Most are somehow related to elements of a json signature, some of a json object. All requests are of content-type 'application/activity+json'. I'm not in the details but it seems as if this is not a json only object and this is causing problems as they are treated as json by ModSecurity? I thought that ActivityPub is activity is only including links to the object on the original system and the system is then resolving/loading it. Seems as if there is also some data in there (and if so filtering will be really difficult). Edit: fascinating enough this might even have been good to be blocked as the given fediverse user is already not longer available aka is deleted. Which makes me suspect that someone tried to do some hack with this. |
Thank you for reporting @ne20002. We get relatively few reports given the amount of installations and supposed number of false positives. Lacking the exact payload, it is very difficult to help you though. If we have the individual payloads, we can check them against the patterns and see whether we can do something about it or not. Like this, it's too blurry. |
Hi @dune73 At least I find this in the Warning a bit suspicious: Findig enVTCsh as part of a string is triggering the rule? Same for Maybe I need to disable inspection of the request body for POSTs to /inbox? |
hi @ne20002, thanks for details,
this is the rule 932235, right? (You didn't mention the rule at the last example - I assume you use CRS on PL1 and only this rule has the quoted
Unfortunately yes. See the regex and it's included source, which has the sub-string May be this is too strict on PL1 (I mean a sub-string matches with a pattern, it's not necessarily an attack - not on PL at least). I think we have to investigate this.
Well,
Do you think about of using SecRequestBodyAccess in case of libmodsecurity3, please DON'T DO THAT. Libmodsecurity3 has a known bug: if you disable the request body inspection, the engine skips the whole Instead of this, please make an exclusion with |
Hi @airween
As could other strings .. this again is just a substring in the signature which possibly can include nearly any of the substrings checked by this kind of rules. I thought of checking for the path /inbox and then ctl:requestBodyAccess=Off. |
yes, eg:
|
@airween, thank you
I aggree. A simple substring match in PL1 seems to strict for me. At least as this check is not checking word boundaries. Maybe a PL1 rule should do a substring match on e.g. ' mkdir ' where a PL2 rule may check for 'mkdir'? |
I've added this issue to our next monthly meeting (20th of May, next Monday): #3694 (see "Separate 2nd Meeting" block)). Would you like to attend this meeting? |
I got another interessting one:
|
Here is another one:
|
Another one:
I'm not sure what exactly matched here, but the regex match for a Windows Command Injection muts be in here: PeerTube admins, you don't need to federate with entire instances. You can be a lot more selective if you want to: 1. Log in on PeerTube with your admin account #PeerTubeAdmin #PeerTube |
And another one:
|
Decisions taken in issue chat meeting on May 20 2024:
|
Can we close this issue? |
We can. |
Description
Since the update to CRS 4.2.0 I have a lot of false positives on rules 941100, 932130 or 932260.
I run owasp/modsecurity-crs in front of a Friendica server.
Logs
This is an example:
Your Environment
Confirmation
[x] I have removed any personal data (email addresses, IP addresses,
passwords, domain names) from any logs posted.
The text was updated successfully, but these errors were encountered: