Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Configuration sample improvements #39

Open
Emeric-hub opened this issue Feb 12, 2024 · 4 comments
Open

Configuration sample improvements #39

Emeric-hub opened this issue Feb 12, 2024 · 4 comments

Comments

@Emeric-hub
Copy link

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
Copy link
Owner

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants