Host header in the logs

[fprina]

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]

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]

Related to: corazawaf/coraza-caddy#75

[hedgieinsocks]

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]

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]

@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]

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

[fprina]

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]

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

[fprina]

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]

please keep it open as i would like that feature too

[fprina]

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

[stardothosting]

Made a PR corazawaf/coraza-caddy#209 to include hostname in the waf logs if anyone is interested

[fionera]

I finally had time to read the whole context of this and yes this is a fairly annoying issue. As I understand it, the hostname field inside the logs is historically set to the destination server ip address of the connection thats being checked. There is no field inside the matched rule that has the actual hostname. The unique_id hack is probably the best way to go right now if you want to check directly. In a perfect world you would only use the normal unique ID and print the hostname inside haproxy and then use the unique_id field to combine haproxy and coraza logs. This sadly has to be fixed on a coraza level