Open TheForcer opened 1 year ago
Am I right to assume that hostname will come from this line https://github.com/corazawaf/coraza-caddy/blob/main/http.go#L44 @M4tteoP ?
I think that around the hostname, and server name, we have to clarify a bit the logic and maybe do still some work around them:
Hostname
The hostname
field of the error logs has been aligned with https://github.com/corazawaf/coraza/pull/517/ to the ModSecurity behavior. It means that we expect that the field is populated with the server IP. The latter is provided by the connector via ProcessConnection (func (tx *Transaction) ProcessConnection(client string, cPort int, server string, sPort int)
. Currently, in the Caddy connector we are missing this last step, resulting in a hostname always empty.
Server name
https://github.com/corazawaf/coraza/pull/572 is meant to fix the SERVER_NAME
variable that was never been populated and therefore was never matching. For that purpose, we are providing SetServerName
to the connectors, and we expect that it is populated with the Host header. It is the header provided as-is by the client and the SERVER_NAME
variable itself is indeed meant to be used to perform checks on it.
The discussion/actions we should take are: 1) fix the ProcessConnection in the Caddy connector providing the server string. It could be the IP, or via some config providing a way to propagate the hostname that the coraza module is intercepting. 2) Evolve the conversation that we had in https://github.com/corazawaf/coraza/pull/517, and take into account the idea of performing a name resolution to provide more meaningful values for the hostname field.
Thanks @TheForcer for raising it!
Any hint on how to obtain the right server name @mholt?
Are you talking about the user-given name of the server in the JSON config as keys here? https://caddyserver.com/docs/json/apps/http/servers/
Sometimes users might bind ip address or just a port. We will have to cover all flanks
FYI, related conversation ModSecurity side: https://github.com/SpiderLabs/ModSecurity/pull/2906
Any idea on how to continue? The problem is we are not filling ProcessConnection and that is the variable we are using to display the logs.
I don't want to be this dude but are there any plans? Afaik it's this line: https://github.com/corazawaf/coraza/blob/dc778126cf458b6a832ced0cffce077f1653147c/internal/corazarules/rule_match.go#L198
And I could create a PR with it being the host header if available. But it looks like it's being blocked at a 'higher level'.
For me specifically it would be nice to have the hostname because we have a single WAF for multiple domains. (And is also what we used to have with Apache)
Please give it a stab @ErazerBrecht
Hi everyone,
I am currently trying to implement Coraza into my Caddy setup, but for some reason the hostname of blocked requests does not get logged. As you can see in the log samples below, the hostname is recorded as
[hostname ""]
According to #35 this should be fixed, so I am not sure if there is a possible misconfiguration at play also.
I've compiled Caddy 2.6.4 with xcaddy in several ways, with the most recent command seen as below. AFAIK these versions should contain the servername fixes.
xcaddy build --with github.com/corazawaf/coraza-caddy/@v2.0.0-rc.2 --with github.com/corazawaf/coraza/@v3.0.0
My current Caddyfile looks like this. I am using the current rule files from coraza-coreruleset, haven't made any changes except additionaly allowing HTTP/3 & HTTP/3.0 versions in crs-setup.conf.
Would be happy about some hints. Thank you 😀