Where to put a global header directive?

Help
1

1. The problem I’m having:

I would like to strip the Server header on every response.

2. Error messages and/or full log output:

N/A

3. Caddy version:

v2.6.4 h1:2hwYqiRwk1tf3VruhMpLcYTg11fCdr8S3jhNAdnPy8=

4. How I installed and ran Caddy:

a. System environment:

Docker image with :2 tag

b. Command:

N/A

c. Service/unit/compose file:

N/A

d. My complete Caddy config:

{
	admin 0.0.0.0:2015
	email <REDACTED>
	# acme_ca https://acme-staging-v02.api.letsencrypt.org/directory
	log {
		level ERROR
	}
}

# first import authelia config
import /etc/docker/authelia/caddy-authelia.conf

# import other config files
import /etc/docker/*/caddy.caddyfile

The config files all have the similar content:

https://something.swtk.eu {
	import authenticate-with-authelia
	reverse_proxy relevant-docker-container:3000
}

5. Links to relevant resources:

I was hoping for the header directive but I do not know where to put it so that it is globally set for all endpoints. Should this be in an import that would be added in each endpoint? (similarly to the authenticate-with-authelia one)

2

There’s no security benefit to doing that. If the Server header had any downsides, we wouldn’t have made Caddy set the header.

There’s no way to configure HTTP handlers globally, every handler must be in a site block. You can use snippets to reduce the amount of duplication if you like.

1 Like
3

Like @francislavoie says, there is no real reason to need to remove the “Server” header.
But, if you wanted to, then check out line 237 of the caddyhttp module :wink:

1 Like
4

I can fully understand the will to put an information about the name of the server for visibility reasons. Completely understandable, especially that Caddy is free for personal use and it is wonderful.

Now, this is a security problem because it reveals more than it should without any added value. In case there is a vulnerability that is detected it will be easier to target serves that have advertized who they are - some places keep that information ready (such as shodan).

Of course the attack can then be opportunistic and target anything that is on ports 80/443 and hope for the best, bu why giving a heads-up.

I still think this is something that ought to be optional (with an opt-out) but I can understand the motivations to have it hard-coded.

5

It reveals nothing.

No information is gained by an attacker from this header.

Any attacker could trivially figure out that Caddy is the server by observing TLS handshake patterns, or a variety of other things.

Seriously, this has been debated for many years, and the conclusion is always: show us proof that this is actually useful for a real attack. I’m certain you won’t be able to prove that.

6

Look, no need to be adversary, I was just asking a question.

You certainly know more than me regarding information security but I know that with https://www.shodan.io/search?query=caddy I have potential 250k servers ready to be attacked in case of a zero-day.

Yes, ultimately you can work out another way to identify whether a server is caddy or not but these 250k servers will be the first ones to be hit.

7

That’s not a security proposition.

Oh, it is very optional. You can always remove headers with header -FieldName in your Caddyfile. The only reason it’s hard-coded is because it’s useful for debugging and surveys and to be a good Internet citizen.

With nginx, you have to recompile from source to remove the header :scream:

They’d be attacked even without emitting the Server header :upside_down_face:

Attackers don’t even need to do that. They just… do the attack. :man_shrugging: They don’t care what server is on the other side.

That’s why you always see random bot requests in your logs trying to reach /wp-admin even though it’s not a WordPress site.

3 Likes
8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.