Referencing @exoboosters’s post about “Caddy” which seems relevant here:
2 Likes
It’s still exposing the dashboard to the internet.
But yeah, it’s at least an option to have it with https (wether that makes a difference in this case or not)
Forgive a newbie, but what are the implications/possible attack points on exposing the dashboard to the internet. Other than the fact that someone knows how much you are earning, is there any other way to get hacked?
When the developer says you shouldn’t expose something to the internet, that is a pretty good indication that they probably haven’t put in the effort to harden whatever it is to public exposure.
It’s like using a tiny lock from a toy or diary to lock your bike. Sure, the bike is locked. But it might not be all that hard to break it.
Worse case… Since they have always told people not to expose it, they might add some features to control aspects of your node to the dashboard, since it’s locked to local host anyway. So… You still sure you want to have that exposed? I’d say probably better not.
1 Like
I think we been though this many times your exposting an unsecure web server to the entire internet that is connected to your home network why would you wanna expose this to everyone? If you wanna expose a VPS that is in a data center to the internet who really cares about that but if your hosting nodes inside your home this is a danger to all of your network becoming compromised.
1 Like
This is interesting.
Authentication/proxy helps restrict access to the exposed port while exposing it to authorised user.
Https helps encrypt the data transferred between server and user so if anyone captures it (think wifi hotstpot/isp/vpn provider) they will not be able to read it, including the authentication credentials if used.
On one hand, indeed there doesn’t seem to be sensitive data or controls exposed on the dashboard (yet), unless you specifically want to keep your storj data secret. As long as this is the case and assuming the application/api behind the dashboard is bulletproof it might be fine to expose to the public without authentication. Without authentication or sensitive data being transmitted when using the dashboard it’s then also fine to not use https as there are no secrets we want to encrypt.
On the other hand though, the application/api is likely not bulletproof. It’s a relatively new, actively developed app with a relatively small team and unclear focus on security. I’m not aware of any third-party security audits happening. I think devs recommend not exposing it also. To me this suggests that it is very likely the app can be potentially compromised. Worst case scenario it will allow the intruder to execute commands on your system with application privileges. In case of Docker they would only mess with the insides of the container (unless version of docker is also compromised). Things to do would be use container/network resources, send spam, botnets, swapping the wallet address in the config, or just wiping all data for fun. If storagenode is running as a standalone process on the system, that system would be compromised similarly to some extent, depending on app privileges and software used. It might be your home server or workstation. Even if the app is actually 100% bulletproof today it doesn’t mean it will be tomorrow and it autoupdates frequently. Also new features may be added with the updates that may will expose sensitive data/controls via the dashboard, api. Like changing wallet address or restarting the node would be reasonable features to add, but it’s hardly a good idea to expose them to the internet. Lastly the exposed port can potentially let the bad actor render storagenode useless (DOS) flooding api calls for example. Some calls are fairly heavy on cpu and seems there’s no throttling. There might be more but this are all attack vectors I could think of so far.
I think considering the above there are still use-cases where it’s fine to not secure it currently, say if there’s not much to loose there. Otherwise I’d be concerned.
1 Like
Do you know any bulletproof app?
Browser get’s updated every few weeks (days?) and issues gets found all the time. But you still use them.
You can’t operate node without exposing port (just not dashboard port, SNO communication port). So, you can be DOS’ed either way.
But DOSing node is unlikely scenario.
Exactly. If you’re developing the bank application, then it make sense to be paranoid about security. Going crazy about security of node is … for someone, who has nothing else to do
Your points do not cancel what I said in any way and definitely don’t lead to this conclusion
Going crazy about security of node is … for someone, who has nothing else to do
No - which was exactly my point. Thanks.
How is this relevant? Browsers don’t have ports to expose and if they did I would consider risks.
There’s a difference with DOSing SNO communication port and api/dashboard port. You probably know that. Also you have to expose communication port but not the rest, so why increase the risk. I can agree this is unlikely scenario at the moment, but this might also change quickly.
I’m not trying to suggest everyone should secure their ports but rather sharing the things that are relevant to the discussion to help people decide.
2 Likes
So you’re argument is: If some parts of what you use/do are insecure, it doesn’t matter if the rest is? Where’s the logic in that? 
It’s like saying: If the airbag in your car is potentially broken, you can also loosen the tires on your wheels and drive with open doors because safety is already compromised.
Well, maybe a good argument for yolo generation 
you can also loosen the tire
I was never arguing for “loosening” anything.
The logic is that if part of the application doesn’t have critical-mission data, then it’s not worth the time to spend time “securing it”.
It’s like saying: since airbags in your car has explosives you need to make your car bullet-proof. Well, maybe a good argument for paranoid
@Alexey regularly refrains people from opening the dashboard to the public Web because it can provide personal pieces of info. Let me quote them:
I’m not sure where the e-mail address is hidden, but I guess one of the API calls returns it.
That’s why HTTPS would be a good thing + authentication.
2 Likes
It’s not about the data, but about the access. If there is a vulnerability it may give access to the entire system or network that system is on.
Now I’m not sure this is exactly what Alexey meant… but imma opt some people in if it is… (not really, don’t worry)
1 Like