Running IPFS on VPS providers triggers netscan detection, risking account termination #4343
Comments
|
Same as: #1226
IPFS is not quite that evil, it doesn't just blindly scan to those addresses (we use mdns for local peer discovery). Someone (or, probably, many someones) have advertised those addresses in the DHT. To make IPFS ignore all such advertisements, you can configure the address filters. You can either configure them manually (#1226 (comment)) or initialize your profile with |
|
There is also an open PR for |
|
@Stebalien thanks! Edited peer filtering in ipfs config. What should be done with this github issue? Close? I wasn't able to find an existing open issue for this easily (looked for 'scan' and 'local'), since it wasn't obvious that it was DHT misadvertisment. And I didn't search for closed issues since closed issue means that it was fixed, therefore I assumed it was new development. Since the email I've received seemed quite urgent that I need to explain myself to Hetzner as soon as possible -- and if this issue will be closed -- anyone else who runs IPFS on VPS will likely trigger scan alert again and won't be able to find easily what the underlying issue is during quick glance on issues page and searching for words like 'scan' and 'local network'. |
|
Users can (and often do) still search through closed issues. However, I'd argue that issues aren't really the place for documentation. We usually just put FAQs in the forum (which isn't linked to from the readme...) but something like this should probably be documented in the "getting started" document; that is, it should probably mention profiles and use-cases for each. Mind filing an issue for that and closing this one? I'll ping those currently working on documentation on that issue. |
|
related: #4029 (comment) |
|
This is the solution I came up with (I don't had any other nodes in a private net) up: down: |
|
@mguentner you can tell IPFS to not dial certain addresses by using the You can also specify the Note: Your current filters won't be quite sufficient. Users can (and do) run and advertise IPFS nodes on ports other than 4001. |
|
I ran into the same issue a few days ago. Luckily my provider unlocked the server after I shutdown the ipfs service. IMO at least a note on this should be somewhere prominent on the ipfs website. Somewhere like here. It's my fault for not researching properly, but I think quite a few people that like the idea of ipfs might do the same thing as I did. I. e. just put ipfs on their server to help the network grow. What can possibly go wrong after all. I think people shouldn't be punished for trying to help the network. Also my provider claimed that:
Whatever that may mean, I just thought I'd let you guys know. |
|
Yeah, definitely makes sense to put it on the getting started guide. "If you're running ipfs in a hosted environment, use |
|
I've had the similar problem with Hetzner. Looks like blocking these 3 network is not enough. Just got a message from them. |
|
Please apply the server profile: |
|
@Stebalien thank you, this works fine. Just to explain how it happened to me as a regular user. The flow is this:
Hopefully @Stebalien reply will help someone in a similar situation. |
|
Closing in favor of a meta issue: #6932. |
|
@dadittoz ahahah same here! |
Version information:
go-ipfs version: 0.4.11-
Repo version: 6
System version: amd64/linux
Golang version: go1.9
Type: Bug
Severity: High
Description:
Right after launching ipfs daemon, I've received an automated email:
According to the log, automated systems might have been triggered because it tries to connect to addresses that are usually reserved to local networks, as it scans for peers in local network.
I tend to agree, though, that blindly connecting to all RFC 1918 and 6890 addresses is poor practice.
If IPFS is looking for local peers this way, it should use broadcast packets instead of blindly trying to connect to every possible combination of IP addresses in that reserved space.
Temporary solution, since there is no local network on that machine:
But I'd rather not have to do that.
This is serious enough that made me instantly reconsider running IPFS.
The text was updated successfully, but these errors were encountered: