-
Notifications
You must be signed in to change notification settings - Fork 429
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
Parsing of caddy log fails with cannot fetch headers from <nil>, no decisions for nikto test #2921
Comments
@arminus: Thanks for opening an issue, it is currently awaiting triage. In the meantime, you can:
DetailsI am a bot created to help the crowdsecurity developers manage community feedback and contributions. You can check out my manifest file to understand my behavior and what I can do. If you want to use this for your project, you can check out the BirthdayResearch/oss-governance-bot repository. |
So here is the parsed details
So it is being poured to a bucket what scenario is triggering on apache, the warning you are seeing is because there was not authentication header sent by the client. Here are the filter around 40X response codes
Okay looks like the "auth_fail" for Caddy will be more complicated, I guess what we should do is look at the respone headers and also check if |
Doing some testing
First log is invalid credentials, Second is empty authentication and third is successful |
Can you try updating the
|
Thanks for the quick help! I just ran the update, restarted the crowdsec container, then ran nikto again from a remote box, now the error is different:
|
Also ensure your caddy installation is up to date to the github releases as using an old version may cause this error https://github.com/caddyserver/caddy/releases/tag/v2.7.6 |
Ok, going to caddy 2.8 fixed the problem.
There's one more, though I think:
|
Do you have the caddy logs, be surprised if there was no status response? |
I have the full caddy log, but it's kind of hard to dig the relevant line out of it since the timestamps there are in ms vs the zulu times in the crowdsec log. I'll try later. |
havent tried it but jq?
It depends if you have other things logging to the file such as debug logs for plugins they will also be attempted to be parsed |
Ok, that produces a bunch of lines with this pattern (primarily for gitea and jira for which caddy is a proxy here):
|
Makes sense context is canceled so there is no status code, hmmm let me think about this |
hello, I have the same problem, with Caddy 2.8.4 and Crowdsec 1.6.2, I don't manage to parse the logs. |
The error happens when the upstream service is not responding so there is no status code, this shouldnt be on every log unless you have a wider issue. |
You are right, I must have messed up something yesterday. I've started from scratch and it works fine it the status code is returned :) |
What happened?
I'm trying to test with nikto if my crowdsec setup for caddy logs works. Basically, that test produced a bunch of caddy log entries like this:
(remote IP anonymized here only)
crowdesc then produces this warning
(the timestamp might be slightly off, I'm not sure I picked the right warning line from the list of hundreds)
When I run the same nikto test against another box which crowdsec and apache logs, I get blocked, not with the caddy logs though, which is kind of in line with the warning that it cannot fetch headers - and so can't recognize the IP for the 401 ?
What did you expect to happen?
crowdsec to fully parse the caddy log line with the 401 errors
How can we reproduce it (as minimally and precisely as possible)?
acquis.yaml:
Anything else we need to know?
No response
Crowdsec version
OS version
Enabled collections and parsers
Related custom configs versions (if applicable) : notification plugins, custom scenarios, parsers etc.
The text was updated successfully, but these errors were encountered: