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

Host header in the logs #128

Open
fprina opened this issue Nov 12, 2024 · 11 comments
Open

Host header in the logs #128

fprina opened this issue Nov 12, 2024 · 11 comments

Comments

@fprina
Copy link

fprina commented Nov 12, 2024

Hi All,

Does anyone know if it’s possible to include the Host header in Coraza logs?

I’m using a container that logs to stdout and need a way to assign each matched rule to the site the request is coming from.
Lookup the coraza id in the haproxy logs need too much effort for the current needs

Before the last change, I was generating an ugly unique-id in haproxy that included the Host header, but now that Coraza generates the ID, I’ve lost that ability.

Any suggestions would be appreciated.

Thanks

@superstes
Copy link

superstes commented Dec 28, 2024

I too would find that useful.

But as the logs are generated by https://github.com/corazawaf/coraza this may not be the right place for this issue.

You can log all headers using die AuditLogs. If that's not overkill for you..
https://coraza.io/docs/seclang/directives/#secauditlogparts

Related to: #111, #142

@superstes
Copy link

Related to: corazawaf/coraza-caddy#75

@hedgieinsocks
Copy link
Contributor

That's indeed very inconvenient. But it looks like we are still able to pass id if we want. I wonder if one could hack it by setting id to domain name. Or is it mandatory to be unique for each request?

@fionera
Copy link
Contributor

fionera commented Mar 13, 2025

That's indeed very inconvenient. But it looks like we are still able to pass id if we want. I wonder if one could hack it by setting id to domain name. Or is it mandatory to be unique for each request?

It has to be unique.

@hedgieinsocks
Copy link
Contributor

@fprina Could you please clarify why you said that your solution stopped working? I believe that id is optional. And please share your host+id hack :)

@fionera
Copy link
Contributor

fionera commented Mar 13, 2025

I guess they used the domain as prefix in the id as it is not limited by length

@fprina
Copy link
Author

fprina commented Mar 13, 2025

Yes, it's a quite stupid hack.

I define my ugly custom ID in haproxy and pass it in coraza-req

# haproxy.cfg
defaults
    ...
    unique-id-format %[uuid()]:%[req.hdr(Host)]   
	...
# coraza-spoe-engine.cfg 	

spoe-message coraza-req
    ... 
    args id=unique-id	
	...

Then I use Fluentd to parse and split the id and host parts in the logs.
It's a workaround, but it allows me to identify the hosts in the WAF events.

PS
#142 solved the auto-generated ID problem.

@hedgieinsocks
Copy link
Contributor

Thank you! But why did you say it stopped working? Either I misread the source code or I'm missing something

@fprina
Copy link
Author

fprina commented Mar 13, 2025

Looking at the commits, my implementation did not work from 577b335 to bfd8b24.
Tomorrow I'll make some tests, then I'll close the Issue.

@fionera
Copy link
Contributor

fionera commented Mar 14, 2025

please keep it open as i would like that feature too

@fprina
Copy link
Author

fprina commented Mar 14, 2025

I confirm it works, in the Coraza SPOA logs I see my crafted ID.
unique_id "f220c678-c03b-4f5f-94b4-383c3bad537f:www.example.com"

I used the current main source with CRS v4.11.0

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

No branches or pull requests

4 participants