spin



Offline



Activity: 361

Merit: 254







Sr. MemberActivity: 361Merit: 254 Re: Is someone monitoring large parts of the network? (evidence+firwall rules) March 06, 2015, 10:06:11 AM #7 Quote from: Evil-Knievel on March 06, 2015, 08:41:10 AM Quote from: spin on March 06, 2015, 08:35:09 AM Quote from: Evil-Knievel on March 06, 2015, 07:19:08 AM

EDIT: My suggestion would be to go the same way as it is implemented in tor's circuit building algorithm,

and disallow multiple connections to IP addresses on the same /24 subnet.





This is already part of bitcoin AFAIK (at least for outgoing connections and over /16).

This is already part of bitcoin AFAIK (at least for outgoing connections and over /16).

We should identify the portions of the code, that do this.

What happens when the seed nodes only return IPs from one /16 subnet? Will it connect anyway or will it refuse service?

What happens if a malicious node is connected "outbound", then It disconnects itself, adds an inbound connection from itself, and uses "GETADDRS" to create a subsequent connection to the same subnet? This way it could slowly fill the connection list with inbound connections from itself?



Not sure what is going on there, but at least my bitcoin node somehow keeps ending up with connections only with 46.105.X.X.

We should identify the portions of the code, that do this.What happens when the seed nodes only return IPs from one /16 subnet? Will it connect anyway or will it refuse service?What happens if a malicious node is connected "outbound", then It disconnects itself, adds an inbound connection from itself, and uses "GETADDRS" to create a subsequent connection to the same subnet? This way it could slowly fill the connection list with inbound connections from itself?Not sure what is going on there, but at least my bitcoin node somehow keeps ending up with connections only with 46.105.X.X.

Also (dns) seed nodes are only rarely used. Maybe on a brand new bitcoin installation. On restart it should revert to the peers.dat. This file contains data on peers your node has previously seen/connected to. On restart bitcoin should try and connect to these. You should check whether your outgoing connections are also just from this subnet. Incoming I understand. But outgoing should be fine.



This is my lay understanding of how it works. Seems there is something wrong at your end. Also (dns) seed nodes are only rarely used. Maybe on a brand new bitcoin installation. On restart it should revert to the peers.dat. This file contains data on peers your node has previously seen/connected to. On restart bitcoin should try and connect to these. You should check whether your outgoing connections are also just from this subnet. Incoming I understand. But outgoing should be fine.This is my lay understanding of how it works. Seems there is something wrong at your end. If you liked this post buy me a beer. Beers are quite cheap where I live!

194YjsiwmGm3hcbPcJWWyzRAS9CQLX1fJL

laurentmt



Offline



Activity: 386

Merit: 251







Sr. MemberActivity: 386Merit: 251 Re: Is someone monitoring large parts of the network? (evidence+firwall rules) March 06, 2015, 02:54:47 PM #8

Usually, OVH provides a bunch of IP addresses with a single server. Very useful for a sybil attack...

These nodes seem active since a few months (see this



EDIT: Just checked my full node (hosted by OVH ) and I've found 1 ip from this subnetwork (among 56 connections) 46.105.210.* are addresses managed by OVH, a major french hosting provider.Usually, OVH provides a bunch of IP addresses with a single server. Very useful for a sybil attack...These nodes seem active since a few months (see this post ).EDIT: Just checked my full node (hosted by OVH) and I've found 1 ip from this subnetwork (among 56 connections)

gmaxwell

Legendary





Offline



Activity: 3178

Merit: 4298









ModeratorLegendaryActivity: 3178Merit: 4298 Re: Is someone monitoring large parts of the network? (evidence+firwall rules) March 07, 2015, 01:26:52 AM #14 Quote from: Evil-Knievel on March 06, 2015, 10:03:28 AM Latest Bitcoin Core with 2000 connections allowed

2000 connections is not possible, you'll run out of file descriptors. If you edit the code remove the limits you'll end up with arbitrary memory corruption.



The code that limits outbound counts to one host per /16 is trivial, it's in net.cpp:1207. Can you please get a getpeerinfo on the effected host while the naughty peers are connected and send me the diff with whatever changes you're running?



Quote What happens if a malicious node is connected "outbound", then It disconnects itself, adds an inbound connection from itself, and uses "GETADDRS" to create a subsequent connection to the same subnet? This way it could slowly fill the connection list with inbound connections from itself? Nothing? Outbound and inbound connections do not compete with each other. You will still be limited in the number of outbound connections you have to a single /16. 2000 connections is not possible, you'll run out of file descriptors. If you edit the code remove the limits you'll end up with arbitrary memory corruption.The code that limits outbound counts to one host per /16 is trivial, it's in net.cpp:1207. Can you please get a getpeerinfo on the effected host while the naughty peers are connected and send me the diff with whatever changes you're running?Nothing? Outbound and inbound connections do not compete with each other. You will still be limited in the number of outbound connections you have to a single /16.

gmaxwell

Legendary





Offline



Activity: 3178

Merit: 4298









ModeratorLegendaryActivity: 3178Merit: 4298 Re: Is someone monitoring large parts of the network? (evidence+firwall rules) March 07, 2015, 10:59:52 AM

Last edit: March 13, 2015, 08:59:06 AM by gmaxwell #17 Quote from: Evil-Knievel on March 07, 2015, 10:29:47 AM well I have a maximum of 3100 file descriptors on my system.

Select has a maximum of FD_SETSIZE (1024) FDs in use, and you will end up totally screwed up if you are beyond that. It doesn't matter what you've set your ulimit to.



When you run hacked up versions that which changes that you do not understand you waste everyone's time (including yours), and you provide bad service to other nodes. I shouldn't have to read between the lines to troubleshoot your private code based on the subtle implications of your offhand comments.



Quote maybe some session hijacking method is used to set up a connection from an unsuspicious (but also malicious) node and then taking it over by one of the 40.xxx nodes with some TCP session hijacking method. This would be pointless. If you are both hosts A and B, why bother having B pretend to be host A? Also if you were having B pretend to be A your host would still think it was connected to A even if it were now B talking. I'm doubtful any retail hosting provider of any scale is failing to run URPF these days in any case, since they'd constantly be a source of DOS attacks.





All that aside-- even ignoring what looks like some broken behavior in your node, this is moderately concerning. What it looks like to me is a rather ham-fisted sybil attack trying to trick nodes into leaking private data to them, the nodes seem to fail to relay transactions too which hurts performance some-- it may even completely disrupt some less sophisticated wallets that don't have any protection against multiple output connections to the same /16. The Bitcoin protocol, when implemented correctly, has a degree of sybil resistance when it comes to partitioning and double-spend risk as an attacker must get _all_ your connections for those attacks, but this kind of activity can really violate user privacy since privacy attacks don't need to get all your connections; especially for SPV nodes which liberally broadcast their wallet addresses to nodes that they're using as servers.



We've been working slowly on some improvements in this space in Bitcoin Core but Bitcoin community (outside of core devs) interest level is pretty low, and due to not being SPV Core already has much better privacy. (In general I've be disappointed by how few people realize how important privacy and fungibility is for Bitcoin's viability as a currency). It's not as simple as just blocking them (though you're free to do that yourself), as blocking on a global basis (instead of each user deciding for themselves) has significant collateral risk and would be easily evaded by anyone who thought it was okay to breach normal network behavior to violate user privacy in the first place; and then you have even less information about the attack. Making it so the attack is harder to see doesn't make it go away.



This is also a reminder to always use tor with Bitcoin 100% of the time (and to use a full node if you can), as that reduces the incentives to pull this kind of stunt. Select has a maximum of FD_SETSIZE (1024) FDs in use, and you will end up totally screwed up if you are beyond that. It doesn't matter what you've set your ulimit to.When you run hacked up versions that which changes that you do not understand you waste everyone's time (including yours), and you provide bad service to other nodes. I shouldn't have to read between the lines to troubleshoot your private code based on the subtle implications of your offhand comments.This would be pointless. If you are both hosts A and B, why bother having B pretend to be host A? Also if you were having B pretend to be A your host would still think it was connected to A even if it were now B talking. I'm doubtful any retail hosting provider of any scale is failing to run URPF these days in any case, since they'd constantly be a source of DOS attacks.All that aside-- even ignoring what looks like some broken behavior in your node, this is moderately concerning. What it looks like to me is a rather ham-fisted sybil attack trying to trick nodes into leaking private data to them, the nodes seem to fail to relay transactions too which hurts performance some-- it may even completely disrupt some less sophisticated wallets that don't have any protection against multiple output connections to the same /16. The Bitcoin protocol, when implemented correctly, has a degree of sybil resistance when it comes to partitioning and double-spend risk as an attacker must get _all_ your connections for those attacks, but this kind of activity can really violate user privacy since privacy attacks don't need to get all your connections; especially for SPV nodes which liberally broadcast their wallet addresses to nodes that they're using as servers.We've been working slowly on some improvements in this space in Bitcoin Core but Bitcoin community (outside of core devs) interest level is pretty low, and due to not being SPV Core already has much better privacy. (In general I've be disappointed by how few people realize how important privacy and fungibility is for Bitcoin's viability as a currency). It's not as simple as just blocking them (though you're free to do that yourself), as blocking on a global basis (instead of each user deciding for themselves) has significant collateral risk and would be easily evaded by anyone who thought it was okay to breach normal network behavior to violate user privacy in the first place; and then you have even less information about the attack. Making it so the attack is harder to see doesn't make it go away.This is also a reminder to always use tor with Bitcoin 100% of the time (and to use a full node if you can), as that reduces the incentives to pull this kind of stunt.