Shovels: restrict where HTTP destinations can connect.

[snichme]

Describe the bug

HTTP destination URI validation is insufficient, allowing SSRF attacks

Impact: An authenticated user with Policymaker privileges can create a shovel
with an HTTP destination pointing to internal services, potentially retrieving
cloud metadata credentials or accessing internal APIs.

Example: A shovel with dest-uri set to http://169.254.169.254/latest/meta-data/
would cause LavinMQ to make requests to the AWS metadata endpoint.

---

LavinMQ shovels support HTTP/webhook destinations, where messages from a queue are forwarded via HTTP POST to a user-specified URI. There is currently no validation preventing connections to internal/private addresses.

Suggestions on what to block

• Loopback: 127.0.0.0/8, ::1
• Private networks: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
• Link-local: 169.254.0.0/16 (includes cloud metadata 169.254.169.254)
• IPv6 link-local: fe80::/10
• IPv6 unique local: fc00::/7

Possibly even more ranges need to be blocked. And this list would also be valuable if the user could configure.

Important: enforce on every request

It is not enough to validate the hostname/IP only when the shovel is created. DNS can change after creation, so the check must happen on every outgoing HTTP request. The resolved IP must be validated before the connection is established.

Error handling

When a connection is blocked due to SSRF protection, the shovel should report a clear error (e.g. "connection to private/internal address not allowed") rather than silently failing.

[snichme]

An enhancement to LavinMQ could also be to limit what IPs the shovels can connect to, so instead of a blocklist you have an allowlist so you can limit the shovels to only connect to local network. This could apply for both amqp and http shovels

[kickster97]

Should be optional and configurable, and should probably not be applied by default in the next version. Some users may be using these IPs so we would be breaking their stacks.

[spuun]

Should this be limited to http destination? Why not all outgoing connections that can be made by lavinmq?

[jage]

One could also argue this is up to the operator, one could filter outgoing connections for the user running LavinMQ. Regardless of how we decide, it should be clearly documented.

[spuun]

One could also argue this is up to the operator, one could filter outgoing connections for the user running LavinMQ. Regardless of how we decide, it should be clearly documented.

Yes, I think this is the way. I think it would be "impossible" to create configuration for this in LavinMQ.