-
Notifications
You must be signed in to change notification settings - Fork 238
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
[BUG] whitelist bypass not effective #959
Comments
for the time being I had to create a cronjob which is running every minute to trigger bwcli unban to avoid another ban of this IP address and prevent collabora to stop working (dirty fix) note#1 - nextcloud 28 is using HTTP method REPORT in webdav calls now - which seems to be new - this method is not yet included into the sample files for bunkerweb as "allowed" note#2 (as always) I seems I'm not smart enough to discover WHY bunkerweb is considering the nextcloud internal traffic as "bad behaviour" by digesting logfiles in INFO level - and fixing the root cause - it would be very helpful if this could be seen (more clearly) in logfiles which rule/violation led to mark it as "bad behaviour" |
Hi, sorry for the late response. Thank you for opening this issue, could you send the logs when the 403 (or other bad behavior status code) occurred ? Thanks 🙏 |
Hello @chrismade, Yep we need access logs from |
I selected a single second from the logfiles where the issue appears pretty much in the middle: first the access log (stdout):
then the error.log (stderr):
if needed I can also send the unmodified complete logfiles on a secure channel - let me know if this is needed and to which target I can upload the files? |
Looks like we had a bug introduced in 1.5.5 regarding the whitelisting feature. It will be fixed in the next release ! |
Hello @chrismade, Fix should be available on the testing version, more info here : https://docs.bunkerweb.io/testing/ Don't hesitate to test it and tell us if everything is ok ! |
Hello @chrismade, Fix is now available in the v1.5.6 release. Thanks for your feedback ! |
What happened?
I'm trying to bypass nextcloud 28 internal traffic to avoid "bad behaviour" bans - which would led to collabora not working any more. unlike #922 which was concluded that whitelist bypass is not working for standalone server I'd rather assume it is not working in multisite as well -
expected behaviour is that any bypass rule - global or site-specific - by IP address, by CIDR network pattern (e.g. 0.0.0.0/0), by RDNS pattern or by User Agent pattern should bypass any rule checking and should not lead to ban this traffic due to bad behaviour
note: in config file and logfiles I replaced the the real domainname by "example.com" and the real IP address by 88.77.53.190
How to reproduce?
It should be easy to reproduce - just create a simple multisite setup e.g. with "www" and "nxcloud" - I assume it is not even necessary to forward this traffic or use websockets to reproduce - then try to use any whitelist based on network, single IP, UserAgent or RDNS and check logfiles on level INFO if there is any bypass or full evaluation of traffic. You may want to create some requests which trigger "bad behavior" to see the IP is banned soon thereafter
Configuration file(s) (yaml or .env)
Relevant log output
BunkerWeb version
1.5.5
What integration are you using?
Docker
Linux distribution (if applicable)
debian12
Removed private data
Code of Conduct
The text was updated successfully, but these errors were encountered: