cloudflare VS crowdsec

If you're using Cloudflare then you might need the Cloudflare module which is a little annoying because you need to rebuild the Caddy executable (or Docker image) to include it. I just set up a GitHub repo that uses GitHub Actions to build and publish a Docker image that includes the Caddy Docker Proxy and Cloudflare modules, but I haven't figured out how automatically update the image when a new version of Caddy is released so it's still a manual process for now.

if domain.xyz is already pointed to cloudflare's nameservers, you'll want to use the cloudflare dns plugin with caddy for a wildcard tls cert from letsencrypt.

I'm on Cloudflare now, so I build my own image based on this Docker image to use SSL from Cloudflare.

Anyways, my end goal is to use cloudflare aswell, because I see that then you can get a wildcard DNS record. Have you tried that? Are you using https://github.com/caddy-dns/cloudflare ? Did you have to build it yourself, or is it included in dockerhub image?

> First, what versions am I getting? Does using `2.5.1-builder` result in a customer built binary that's version `2.5.1`? The command usage [1] of the `xcaddy` command says it falls back to the `CADDY_VERSION` environment variable if it's not set explicitly. Since it's not set explicitly, I go looking for that variable in the Dockerfile [2].

Yeah - the default version it'll build with is the version embedded in the builder image, so in that case, v2.5.1. But really, you can just use always use the latest builder image and specify the version you want in the xcaddy command, i.e. 'xcaddy build v2.5.1 --with ', or any other git ref if not a version (cause we're using Go to build and you can use any git ref, like a commit hash or branch name if you want to try a WIP pull request).

We set it up with a good default so most users wouldn't need to ask that question, it should "just work" for them. But it's a valid question to ask.

> That's some templating language I'm not familiar with and I can't track down where the variable gets set, at least not quickly.

Yeah we're using Gomplate for generating the Dockerfiles for the official Docker Library builds, since we need to make builds for every CPU architecture, and even Windows docker images (I still have no idea why anyone would want those, but alas). Either way, that's an implementation detail of how we automate this stuff, doesn't matter to users.

> Now, what version of `caddy-dns/cloudflare` am I getting?

The latest, if you don't specify a version. The https://github.com/caddy-dns/cloudflare repo doesn't have tagged releases, so it'll just be the latest commit on the master branch. You can specify a specific commit like '--with github.com/caddy-dns/cloudflare@8ea1cff' for (as of this writing) the commit just before the latest.

> What other risks come along with building and maintaining my own custom image?

Honestly, none. Maybe problems with plugins not being compatible with eachother, but Caddy's plugin design means that should rarely happen, except if two plugins have the same module ID. But that's up to you to make sure you don't pick two plugins that try to do the same thing.

Because of the way Go builds work, they can always be cross-compiled. We don't use CGO, so builds of Caddy are completely static and have zero dependencies. There's really no risk that it doesn't build in a specific environment, or whatever.

> If I build a custom image, do I let other people I help with the odd tech thing use it or is all the effort for me only? I don't want to become the maintainer of a Docker image others rely on, so I can't even re-use any related config if I help others in the future since they won't have access to the needed image.

Up to you. But that's the exact reason we don't maintain builds with plugins ourselves. There's literally an infinite amount of combinations possible. Some have suggested like "caddy-lite" and "caddy-full" sort of setups where we ship just a few vetted plugins or "yolo give me all the plugins" but that's silly. We don't have the time or resources to vet all the plugins.

From your perspective it might seem like "duh, there should be an official build with Cloudflare", but really it's a pretty small percentage of users who need this.

> Also, a 4 line Docker file looks nice in terms of being simple, but explicitly declaring or even adding comments describing some of the things I pointed out above can save people a lot of time. Even comments with links to the relevant portions of the docs would be super useful.

(as I wrote in my other comment, the docs for this are on https://hub.docker.com/_/caddy)

> The desire for wildcard certificates is to keep things from being discoverable via CTLogs.

It's really trivial for someone to scan until they hit subdomains that return a successful response, if they really cared. This doesn't really protect from anything. Using wildcards for that is a bit of an antipattern.

For more, see: https://github.com/caddy-dns/cloudflare

As default it does need port 80 open to renew certificates, but you can use DNS challenge instead. https://github.com/caddy-dns/cloudflare

Hey we actually built the second part as a product. Its a modern revamp of fail2ban combined with crowdsourcing aspect to deliver an up-to-date blocklist of active threats. You can check it out at https://github.com/crowdsecurity/crowdsec

Today we are pleased to announce the launch of CrowdSec Engine 1.5 - this is a huge milestone for the project and one that would not have been possible without the help of this community. You can read see the full change log over on GitHub here https://github.com/crowdsecurity/crowdsec/releases

wget https://github.com/crowdsecurity/crowdsec/releases/latest/download/crowdsec-release.tgz server:> tar xzvf crowdsec-release.tgz https://github.com/crowdsecurity/crowdsec/releases/latest/download/crowdsec-release.tgz server: > tar xzvf crowdsec-release.tgz server:> cd crowdsec-v* && sudo ./wizard.sh -i

This tool crowdsec.net is really interesting to mitigate and enact defense systems for different scenarios.

CrowdSec is licensed under MIT open source license, you can find a copy of the text here: “Copyright 2020, CrowdSec SAS (http://crowdsec.net), Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.” That’s all there is to it. Like in the case of Debian, you can do anything you want with it, for free, period. You just need to embed this license when you redistribute the product.

You should check out https://crowdsec.net. More advanced, uses crowdsources cti to block attacks even before they happen. Also both nginx and captcha is supported. Disclaimer: I am head of community. Visit /r/CrowdSec or our Discord at https://discord.gg/crowdsec if you have questions :-)

Do I need something like crowdsec, or is WireGuard secure enough on its own?

Before falling too much in love with Fail2Ban try taking a look at https://crowdsec.net. Similar functionality but way more advanced (but easier to configure). New project that leverages the power of the crowd and shares information of attacks among users so they help each other out protecting themselves.