-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Internal scan of rfc6598 using --no-private-ipv4 #9922
Comments
CC @tomaka |
Unfortunately we need Maybe also try |
@tomaka , does --no-private-ipv4 exclude 100.64.0.0/10 range? |
Yes |
@tomaka Ok, did something change in the latest release regarding this? Because the problem is occurring to me from the latest version. The node are scanning the 100.64.0.0/10 range |
Same problem on latest version; temporary solved adding this rule:
|
I'm having the same problem with the latest release
|
Please do not spam this issue. |
@tomaka this is the cmd: /root/polkadot --validator --name testing_noprivateipv4 --chain=kusama --database=RocksDb --unsafe-pruning --pruning=1000 --telemetry-url 'wss://telemetry-backend.w3f.community/submit 1' --no-private-ipv4 --log sub-libp2p=trace These are some grepped logs:
|
I think I've found the problem; substrate uses Ipv4Addr.is_private to check if the ip is a local address ( substrate/client/network/src/discovery.rs Line 517 in 700c9e2
https://doc.rust-lang.org/beta/src/std/net/ip.rs.html#557-564 This could be fixed by using (!is_global) instead of (is_private): https://doc.rust-lang.org/beta/std/net/struct.Ipv4Addr.html#method.is_global |
@dakk is this solved? |
I think it is; @gregorst3 can you confirm that? |
Using Polkadot v0.9.10
Hello, after the fix paritytech/polkadot#543 #4042 the problem of scanning internal IP was gone.
However, also using the cli option, --no-private-ipv4 , since days I'm receiving abuse email from my provider, regarding the node that tried to scan 100.64.0.0/10 range (attached logs), 100.64.0.0/10 is part of rfc6598 that should be prevented to be scanned from --no-private-ipv4 but seems like something is wrong.
--no-private-ipv4 should prevent scans of
https://tools.ietf.org/html/rfc1918
https://tools.ietf.org/html/rfc6598
https://tools.ietf.org/html/rfc3927
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
100.64.0.0/10
169.254.0.0/16
The text was updated successfully, but these errors were encountered: