IPFS is doing port scanning, without indicating that in logs #5418
Comments
|
enable the server profile during your init statement. also I don't think it's doing port scanning I suspect the bitswap traffic might be detected as port scanning. |
|
@postables , I did enable server profile. I did it with Is it expected that bitswap would attempt to connect to multiple ports of a peer (without indicating that in logs)? To start with, I'd be surprised if a peer advertises themselves listening on 8 different ports, why would they do so? I'm not that familiar with internals of how bitswap works, but is it normal for it to attempt to connect to 700 different TCP ports of a given IP address (which is what I've received in initial abuse report)? |
|
Another example:
In this case we've had an incoming connection from After that my node just started dialing random ports of This time there are logs from ipfs for this session (intersting part at 16:54:51): https://ipfs.io/ipfs/QmRKhMz6vtftti5PFaCqQAGESBNjBWmEqaE5TCbXfgpn88/ Particularly worrying part is below: It seems in this situation, after connection has been lost (maybe remote node was restarting, or temporarily went offline), we bombarded It appears that node is behind NAT, as this is what they are advertising: For some reason I'm also getting TONS of ports of It would appear that this giant list of ephemeral ports is just because node behind Why are we connecting to so many ports? Can I configure IPFS daemon to only connect to port 4001 (which would work for nodes with public IP)? If some other node does not have public IP, and is behind the NAT, I won't connect to them, but they could dial me any time. |
|
If you're node is advertising all locally connected interfaces then it doesn't appear that the server profile config change persisted as it is designed to stop this kind of advertisement edit: it appears I misread your comment and that the node advertising all those addresses is a remote node edit2: what I think might be happening is that the node you're dialing to on multiple ports is advertising content that your node needs so it's attempting to connect to to that peer on all known interfaces. edit 3: the inverse could be true your node has content which that peer needs so that peer and your node are constantly trying to talk to each other edit4: this issue may also be worth checking out #1226 edit5: this is another issue worth looking at #4343 |
My node doesn't need anything, and nobody can need stuff from it, since I'm not using it yet, it is a fresh new node. So this is purely a DHT traffic. I don't mind that, but I want to make sure that it only attempts to connect peers in reasonable way, and not by spamming them on dozens of ports. I've read #1226 and #4343 and those are about node attempting to connect to local addresses. That is mitigated by server profile (which populates Swarm.AddrFilters), and isn't the case in my issue, as my node is attempting to connect to public addresses but on too many ports. |
|
You might be able to mitigate this routing the |
|
The problem is likely that the node is advertising too many ports, like in #3780. |
|
Same issue here. |
|
Same here. Why is this not the default? Currently it's HIGHLY DANGEROUS (for business) to run IPFS. |
|
To be clear, this particular issue is not about the following two things:
It is rather about why after enabling server profile, ipfs still attempts to connect to the same node (public IP) at dozens different ports, and how do we prevent this from triggering ISP abuse detection. It might be a bug in the logic of how ports of that node are advertised and forwarded between peers (i.e. if node A is behind NAT and connects to dozens of peers, and all of them remember and forward the public host:port that they receieved connection from, at the end DHT will contain many records of the same public ip at different ports). If we aren't able to identify why this is happening and fix it quickly, there are some remediations. Remediation 1. On firewall allow outgoing connections to any port except 4001. This potentially hurts connectivity somewhat, but does help to prevent any activity that can resemble port scanning. This is what I've chosen. Remediation 2. Change code of IPFS such that it only attempts to connect to new port of an IP address not more than once per day. Maybe also add limitation that it attempts to connect to an IP address not more than once per hour. Of course those limitations should be configurable. Once that is in place, even if some misbehaving node advertises thousands of closed ports on the same IP address, IPFS won't attempt to "scan" all of them in search of the one that is open. It wouldn't hurt connectivity with good peers, as they are likely advertising just one port. |
Does IPFS use STUN server? |
|
Closing in favor of the meta issue #6932. |
Version information:
go-ipfs version: 0.4.15-
Repo version: 6
System version: amd64/linux
Golang version: go1.9.7
Type:
Bug
Description:
IPFS randomly connects to addresses in a way that resembles port scanning, without any indication of what is happening in the logs (level=debug).
A few days after installing IPFS daemon on my public server, I've got email from provider (AWS) with abuse report, indicating that sombeody received a port scan from my address (700 TCP ports scanned in total).
To be safer and not get banned, I've done the following steps:
This is my full config: https://ipfs.io/ipfs/QmQUWSFqV9bDckgpzBaKBBZsPSwHCxVAjKRx31TD5zuLVV/
This is how I generate the config (start script of my Docker image): https://raw.githubusercontent.com/burdakovd/dapps.earth/master/ipfs/start.sh
Now, I started looking into rejected outgoing connections, and indeed I see behavior resembling port scan, despite all my settings. Luckily this time, my local firewall prevented another abuse report.
Here are logs indicating my node (internal IP is show in logs) connecting to 54.186.184.82. First connection is OK, and then 10 minutes later it starts connecting to random ports of 54.186.184.82.
Schema: [version, account, eni, source, destination, srcport, destport, protocol, packets, bytes, windowstart, windowend, action, flowlogstatus]
ACCEPT/REJECT means just whether the connection was accepted/rejected by my firewall, not necessarily means that the connection successfully went through, as it could've been rejected on the other side.
In the meantime, in ipfs logs (debug level of logging enabled), there is no mention of 54.186.184.82 whatsoever!
(note: 01:42:00 is the moment when I have restarted my node, after having updated log level to "debug")
Furthermore, I see that in third line of network logs 54.186.184.82 was attempting to connect to me at port 1024, despite me advertising only 4001.
The text was updated successfully, but these errors were encountered: