this post was submitted on 22 Oct 2023
1 points (100.0% liked)

Self-Hosted Main

515 readers
1 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

For Example

We welcome posts that include suggestions for good self-hosted alternatives to popular online services, how they are better, or how they give back control of your data. Also include hints and tips for less technical readers.

Useful Lists

founded 1 year ago
MODERATORS
[email protected]
1
Security Concerns: Exposing My Local RESTful API to the Internet via Cloudflare Tunnel – Is My Home Network at Risk? (alien.top)
submitted 1 year ago by [email protected] to c/[email protected]
17 comments fedilink hide all child comments
 

Hello guys, I'm have little to no experience when i have to deal with networking or cybersecurity.

I recently created a backend RESTful API on my Ubuntu VM on my personal desktop and dockerized the app, connecting it to a bridge network named 'tunnel.' I also have the Cloudflare Docker hosted in the same 'tunnel' network, which allows my local RESTful API Docker to be accessible via my domain and exposed to the internet.

Can anyone help me understand if this setup poses any security risks to my home network?

If so, what should I do to help reduce the risk? I have read that firewall helps, but does a restful api container developed with golang requires it?

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 1 points 1 year ago (9 children)

There’s nothing inherently insecure about exposing a service to the internet. But it does create an attack surface.

A firewall or proxy (Cloudflare, Nginx etc) allows you to restrict access via ip address or authentication, but if there’s a bug in your service it can still be exploited.

The good news about a service you write is that there are no ready built tools to exploit it. The bad news is that there are almost certainly more bugs.

So it really comes down to what your ap has access to (is it jailed or restricted in someway), is it read only or does it allow modifying file in the system? How confident are you with your code? If someone starts bashing in it, will you be alerted? Is it did get a coloured how serious would that be? There is no “right” answer, is a risk assessment you have to make based on your situation.

[–] [email protected] 1 points 1 year ago

> There’s nothing inherently insecure about exposing a service to the internet. But it does create an attack surface.
Way too many people I know work in security don't understand this. I've tried explaining to people that exposing a hardened SSH endpoint is almost the same thing as exposing a VPN endpoint.
Most people think that anything public facing with authentication is by design bad. (The VPN endpoint still handles authentication btw) but fail to acknowledge the thousands and thousands of secure systems running in that fashion today that they use on a daily basis (social media, web host control panels, etc.)

Making a service publicfacing is not by itself insecure. Generally if you can avoid doing it, you should, but hardening an endpoint to make the risk satisfactory is your goal when you need to.

Public SSH is not a bad thing. Password auth, root login allowed, and no ip ban mechanism (fail2ban) is a bad security configuration.

TL;DR

Public endpoints should be hardened to what you think is an acceptable risk.
With your API, your should fuzz it and consider the attack surface inside your API.
What inputs are you accepting? Are they sanitized? Can you lock down the endpoint with authentication?

load more comments (8 replies)