hslatman / caddy-crowdsec-bouncer

A Caddy module that blocks malicious traffic based on decisions made by CrowdSec.
154 stars 4 forks source link

Configuration sample improvements #39

Open Emeric-hub opened 9 months ago

Emeric-hub commented 9 months ago

Hi,

Thks for this amazing works... My firsts tests were successful.

I now wanna go further in my configuration and i think a few more explanations may be needed.

Default configuration is working, as bouncer out of box... but i now wanna add some nice 403 bouncing error pages... and the route http handler required to add the crowdsec call is disabling my default error pges handlers...

If you find some spare time, it'll be nice if tou could provide examples...

I also try to captcha instead of ban ... but doesn't see any difference. Any idea?

hslatman commented 9 months ago

Hey @Emeric-hub,

Captcha support has been on my list of things to look into for a while: https://github.com/hslatman/caddy-crowdsec-bouncer?tab=readme-ov-file#things-that-can-be-done. I haven't had the need myself yet, so I haven't implemented support for it yet. I do have ideas how I want it to work, and I'd like it to be able to use a configurable captcha provider. Which one do you (want to) use?

Sending them to a custom error page sounds like a nice thing. I might incorporate that, as it's currently not supported.

Emeric-hub commented 9 months ago

Yeah, THKS, for the answer ... for now, i just provide error pages on my Caddyfile (which is mainly used as a mutualised proxy) ... but giving banned IP a nice error pages should be a good start ...

Emeric-hub commented 9 months ago

for now, i've got something like this snippet :

(error_handling) { handle_errors {

Error 4XX

        @401 {
            expression {http.error.status_code} == 401
        }
        handle @401 {
            header -server
            file_server
            root * /etc/caddy/error-pages
            rewrite @401 /401.html
        }
        @403 {
            expression {http.error.status_code} == 403
        }
        handle @403 {
            header -server
            file_server
            root * /etc/caddy/error-pages
            rewrite @403 /403.html
        }
        @404 {
            expression {http.error.status_code} == 404
        }
        handle @404 {
            header -server
            file_server
            root * /etc/caddy/error-pages
            rewrite @404 /404.html
        }
        #Error 5XX
        @500 {
            expression {http.error.status_code} == 500
        }
        handle @500 {
            header -server
            file_server
            root * /etc/caddy/error-pages
            rewrite @500 /500.html
        }
        @502 {
            expression {http.error.status_code} == 502
        }
        handle @502 {
            header -server
            file_server
            root * /etc/caddy/error-pages
            rewrite @502 /502.html
        }
        @503 {
            expression {http.error.status_code} == 503
        }
        handle @503 {
            header -server
            file_server
            root * /etc/caddy/error-pages
            rewrite @503 /503.html
        }
        handle {
            respond "{http.error.status_code} {http.error.status_text}"

        }
    }

}

That works for everything i need ... but ban IP just get an empty 403 error page ... So i can't defined it as production ready ...

if i may help on this thread / issue ... i'll be pleased ...

Emeric-hub commented 8 months ago

Hi there,

i was checking about this point ... after having a look at the appsec functionnality crowdsec.

Finally i found, in nginx bouncer, the following parameter... BAN_TEMPLATE_PATH=/var/lib/crowdsec/lua/templates/ban.html

I think it's the same need : Adding an extra and optional parameter in the global crowdsec section of the caddyfile configuration.

Because ban to a static pages is just enough to do the job ... and is probably really less complicated than what i provide earlier.