Skip to content
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

Update modsecurity.yaml to expect 'client:' OR 'remote:' in APACHEERRORPREFIX2: #1038

Open
Staene opened this issue May 7, 2024 · 6 comments · May be fixed by #1056
Open

Update modsecurity.yaml to expect 'client:' OR 'remote:' in APACHEERRORPREFIX2: #1038

Staene opened this issue May 7, 2024 · 6 comments · May be fixed by #1056
Assignees

Comments

@Staene
Copy link

Staene commented May 7, 2024

Describe the bug
In updating from AlmaLinux 9.3 to 9.4, Apache and a number of its modules were also updated. The Apache log format slightly changed, breaking both Fail2Ban and CrowdSec's modsecurity parsing. In my setup, the first iteration of [client: ...] in the logs was changed to [remote: ...]. Fail2Ban implemented a fix for this 3 months ago and I suggest that CrowdSec's modsecurity.yaml be edited to allow what is currently the first reference of [client: ...] to be either [client: ...] or [remote: ...] in APACHEERRORPREFIX2:

To Reproduce
Update Apache httpd to 2.4.57-8 as part of upgrading AlmaLinux 9.3 to AlmaLinux 9.4.

Expected behavior
I expected the Apache log format to stay consistent and for CrowdSec's modsecurity parser to continue to parse Apache error logs successfully.

Additional context
Editing the APACHEERRORPREFIX2: line in modsecurity.yaml, changing the first reference of [client: ...] to [remote: ...] fixed my problem.

@LaurenceJJones
Copy link
Contributor

Hey @Staene could you provide some example log lines so we can add some tests?

You can redact any PII information as needed

@LaurenceJJones LaurenceJJones self-assigned this Jun 13, 2024
@LaurenceJJones LaurenceJJones linked a pull request Jun 13, 2024 that will close this issue
@Staene
Copy link
Author

Staene commented Jun 14, 2024

[Fri Jun 14 04:48:20.094249 2024] [:error] [pid 1159:tid 1320] [client xx.xxx.xxx.xx:0] [client xx.xxx.xxx.xx] ModSecurity: Warning. Unconditional match in SecAction. [file "/etc/crs4/rules/RESPONSE-980-CORRELATION.conf"] [line "96"] [id "980170"] [msg "Anomaly Scores: (Inbound Scores: blocking=5, detection=5, per_pl=5-0-0-0, threshold=5) - (Outbound Scores: blocking=0, detection=0, per_pl=0-0-0-0, threshold=4) - (SQLI=0, XSS=0, RFI=0, LFI=5, RCE=0, PHPI=0, HTTP=0, SESS=0, COMBINED_SCORE=5)"] [ver "OWASP_CRS/4.0.0"] [tag "reporting"] [hostname "redacted.com"] [uri "/.git/config"] [unique_id "ZmwR5AebAO5-Tfs4FnXWuwAAigg"]
[Fri Jun 14 04:48:20.093994 2024] [:error] [pid 1159:tid 1256] [remote xx.xxx.xxx.xx:0] [client xx.xxx.xxx.xx] ModSecurity: Access denied with code 403 (phase 2). Operator GE matched 5 at TX:blocking_inbound_anomaly_score. [file "/etc/crs4/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "186"] [id "949110"] [msg "Inbound Anomaly Score Exceeded (Total Score: 5)"] [ver "OWASP_CRS/4.0.0"] [tag "anomaly-evaluation"] [hostname "redacted.com"] [uri "/.git/config"] [unique_id "ZmwR5AebAO5-Tfs4FnXWuwAAigg"]
[Fri Jun 14 04:48:20.092017 2024] [:error] [pid 1159:tid 1256] [remote xx.xxx.xxx.xx:0] [client xx.xxx.xxx.xx] ModSecurity: Warning. Matched phrase "/.git/" at REQUEST_FILENAME. [file "/etc/crs4/rules/REQUEST-930-APPLICATION-ATTACK-LFI.conf"] [line "143"] [id "930130"] [msg "Restricted File Access Attempt"] [data "Matched Data: /.git/ found within REQUEST_FILENAME: /.git/config"] [severity "CRITICAL"] [ver "OWASP_CRS/4.0.0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-lfi"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "capec/1000/255/153/126"] [tag "PCI/6.5.4"] [hostname "redacted"] [uri "/.git/config"] [unique_id "ZmwR5AebAO5-Tfs4FnXWuwAAigg"]

@LaurenceJJones
Copy link
Contributor

Perfect! thank you, I will update the tests shortly and issue an update to the official parser 🦙

@Staene
Copy link
Author

Staene commented Jun 14, 2024

Awesome. Thanks!!

Since you're here, wanted to point you here: Bouncer gets LAPI delete decisions but doesn't actually delete them from Cloudflare #34

You said on Discord you'd tag it. If you haven't had a chance, that's the error I was referring to a week or two ago. Again, thank you!

@LaurenceJJones
Copy link
Contributor

LaurenceJJones commented Jun 14, 2024

Awesome. Thanks!!

Since you're here, wanted to point you here: Bouncer gets LAPI delete decisions but doesn't actually delete them from Cloudflare #34

You said on Discord you'd tag it. If you haven't had a chance, that's the error I was referring to a week or two ago. Again, thank you!

Yeah we got a 2 hour slot next week to go over the issue and allocate some resources to get the remediation back up to scratch.

Apologizes for the delay in communication over the matter and ensure we want to resolve the issues.

@Staene
Copy link
Author

Staene commented Jun 14, 2024

No worries. Thanks so much!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants