mirror of
https://github.com/healthchecks/healthchecks.git
synced 2026-04-25 06:55:53 +03:00
[GH-ISSUE #725] Webhooks not working #519
Labels
No labels
bug
bug
bug
feature
good-first-issue
new integration
pull-request
question
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/healthchecks#519
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @lettore on GitHub (Nov 3, 2022).
Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/725
From Version 2.4 webhooks are not working anymore, trying inside the container I'm able to ping and curl remote side.
Testing from web-ui I always receive Connection Failed, but nothing in the logs also with debug on.
I'm using the linuxserver image.
@cuu508 commented on GitHub (Nov 4, 2022):
Do you by any chance have
http_proxyorhttps_proxyenvironment variables set?Can you test webhook delivery using a throwaway healthchecks/healthchecks container? You can copy/paste the snippets from the "Quick Start using Docker CLI" section in README to get running quickly.
@lettore commented on GitHub (Nov 5, 2022):
I don't have http_proxy env variable set.
As I said webhooks are working with version 2.3 and not in 2.4. Nothing is changed in compose file.
Testing using with a throwaway healthchecks/healthchecks container is not working either.
You can test yourself with a GET request to any webserver, in this case I tried also to contact itself (exposed to port 9150).
With the server with 2.3 version is working.
@cuu508 commented on GitHub (Nov 5, 2022):
From v2.4 onwards, to allow requests to private IP ranges, set
INTEGRATIONS_ALLOW_PRIVATE_IPS=Trueenv var.https://healthchecks.io/docs/self_hosted_configuration/#INTEGRATIONS_ALLOW_PRIVATE_IPS
@lettore commented on GitHub (Nov 5, 2022):
That's resolved, not totally sure why by default a private address inside a secure network should be a security issue. It's the first time I have faced this kind of problem, usually, only local addresses are allowed not otherwise.
@cuu508 commented on GitHub (Nov 6, 2022):
It is a security issue if you let untrusted people create accounts on your Healthchecks instance. They can set up webhooks that probe your internal network. Of course, if you are the only user, or if you fully trust all your users, then that is not a concern, and you can set
INTEGRATIONS_ALLOW_PRIVATE_IPS=True.@lettore commented on GitHub (Nov 6, 2022):
What if I don't fully trust only one user? Until 2.3 no one cared about this "issue" now you made by default a change that disrupt the webhook functionality, with just a setting that applies to the whole system and not per user or address. I had blocked by your rule https domain names that resolves also from the Internet with user authentication or token enabled. Just because the server is inside my Lan and it's resolved by local dns as a local address. Which kind of security risk is involved in a GET call to a local address with authentication enabled? In this way I have to disable your protection because is blocking every call to secure servers as well to unsecured one's. It wouldn't be better, if you take care of security, to make a more complex system where, for example, admins have full access to local lan, and other users should use address in a whitelist?
@lettore commented on GitHub (Nov 6, 2022):
I'm using Healthchecks for personal use, I'm quite sure that the majority of the users do the same. Personally I don't use webhooks for notifications, I use webhooks for calling a "repair" script when a check is falling, to do things like restart a container or a service etc. This software can be really powerful, but it's quite limited in many parts, like this one. May happens that the Admin needs to use a local script or a local webhook. Enabling this features will allow anyone to use a local script. This is not a good practice for me. Because of this I think that every instance of Healthchecks should be treated as a single user instance, or at least you should trust any other user. It should be much better to have an admin console where you can grant privileges per user basis.
@cuu508 commented on GitHub (Nov 6, 2022):
Sorry about that :-/ In the hindsight, I should have called attention to this behavior change in the release notes.
https://portswigger.net/web-security/ssrf
I don't self-host any notification delivery services (aside from signal-cli), and so don't have a need for this. But I can see how it could be useful in selfhosting scenarios.