While searching on the internet, I found an exposed http://<IP>:14002 (note the HTTP) server, where I could see the admin webpage of the node. I won’t say the IP-addr or the node id (to not expose them here), but I’m sure they don’t want this all to be publicly accessible. How I can contact them to notify, that this is publicly accessible?
While I am not aware of any problematic API calls strangers could make from outside, I think it’s generally a security risk, to have this dashboard exposed when it doesn’t need to be. Also, they probably don’t want the admin-interface info (storage size, past payments etc.) publicly available anyways.
Dear storj team: How can I contact a SNO given their Node-ID? Or can I share the node id with you and you contact them (as you’ll have their email address)?
Additionally, I am surprised, that I found it via internet search in the first place. Ideally, the HTML should have instructions telling search-bots to NOT index the page. If anyone accidentally makes their admin interace publicly accesible - at least it shouldn’t be on a search webpage then.
Hi @GollyTicker
This has been discussed before and there’s nothing you can do to contact the node operator in question. If the node operator opened their dashboard to the whole internet they did that outside of any Storj instruction and only have themselves to blame, although as you say the risk is very low.
You could run a simple port scan on every IP v4 address checking for a response from that port. It wouldn’t take long, but I’m sure Storj don’t recommend it.
I agree with you, that I can’t contact them without an email address. But with Storj Labs having the table for NodeID->email, it would be possible for them to send these automated emails.
I mean, I am even willing to write a small script which checks the node addresses whether the admin interface is also exposed and prepares the email. I don’t care about having the data, as the script can simply be run by storj once per month/week.
But again, what does the storj team think about that?
We trying to minimize using of provided email address for anything except notifications like suspension or disqualification.
And we know, that even these notifications are not perfect, but we are working on a fix: [Tech Preview] Storage node email notification on QA satellite
So I’m not sure, should we made a notification like you suggesting.
@Alexey Thanks for the response. Perhaps we can keep this in the backlog. Maybe it can be added lateron. As storj grows, I can imagine, that it’s important to keep its security high. Even if strictly speaking storj doesn’t trust the SNO with unencrypted customer data, it’s still sensible to reduce the attack surface. This is especially true, as many people who are SNOs are not necessarily the most informaed about security and the general tech.
@striker43 I could imagine implementing that, but I don’t know, whether storj woul accept the PR atm.
Any openly accessible service on your server is a security risk. If you have the web interface openly accessible, and there is a weakness in it, e.g. allowing SQL injection, someone could ruin your node or worse.
@GollyTicker you could see if there is something running on port 80/443 on the same IP that maybe has an email address mentioned. Or you could check DNS, maybe they have an MX record?
I manually checked 80 and 443. No response there. There is the normal HTTP response on 28967 - which makes sense, as storj is running there.
I rever DNS lookup’ed the IP and found, that the server belongs to some cloud provider in some place in or near Europe.
I don’t dig deeper into this, as it seems, that the best we can do now is to simply add some basic check to the Web Interface (which we can as it’s all open-source).
“Security risk” might be an overstatement for some people, in depends on the point of view.
But the sure thing is that you are exposing you crypto address to the world, which reveals all your transactions from it and to it, which some people may not want.
As long as there is no way to link the address to the person, one might think it’s fine, but on the internet, the less clue you give, the more secure you are…
You open yourself to denial of service attacks against the web server, which given most nodes tend to be on minimal hardware, it wouldn’t take much to overload one with requests.