Bitcoin Forum
April 23, 2018, 06:32:38 AM *
News: Latest stable version of Bitcoin Core: 0.16.0  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: [1] 2 3 4 5 6 »  All
  Print  
Author Topic: This message was too old and has been purged  (Read 37561 times)
Evil-Knievel
Legendary
*
Offline Offline

Activity: 1134
Merit: 1142



View Profile
March 06, 2015, 07:19:08 AM
 #1

This message was too old and has been purged
1524465158
Hero Member
*
Offline Offline

Posts: 1524465158

View Profile Personal Message (Offline)

Ignore
1524465158
Reply with quote  #2

1524465158
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1524465158
Hero Member
*
Offline Offline

Posts: 1524465158

View Profile Personal Message (Offline)

Ignore
1524465158
Reply with quote  #2

1524465158
Report to moderator
Evil-Knievel
Legendary
*
Offline Offline

Activity: 1134
Merit: 1142



View Profile
March 06, 2015, 07:53:01 AM
 #2

This message was too old and has been purged
spin
Sr. Member
****
Offline Offline

Activity: 360
Merit: 250


View Profile
March 06, 2015, 08:35:09 AM
 #3


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). 

If you liked this post buy me a beer.  Beers are quite cheap where I live!
194YjsiwmGm3hcbPcJWWyzRAS9CQLX1fJL
Evil-Knievel
Legendary
*
Offline Offline

Activity: 1134
Merit: 1142



View Profile
March 06, 2015, 08:41:10 AM
 #4

This message was too old and has been purged
goregrind
Full Member
***
Offline Offline

Activity: 148
Merit: 100


View Profile
March 06, 2015, 09:11:24 AM
 #5

That is pretty weird behavior. Just checked my nodes and each had only one connection to that subnet ( as expected).
I blocked it anyway, but I'm curious whats going on in your case.
What version of bitcoin core do you run ?

woot?
Evil-Knievel
Legendary
*
Offline Offline

Activity: 1134
Merit: 1142



View Profile
March 06, 2015, 10:03:28 AM
 #6

This message was too old and has been purged
spin
Sr. Member
****
Offline Offline

Activity: 360
Merit: 250


View Profile
March 06, 2015, 10:06:11 AM
 #7


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). 

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.

If you liked this post buy me a beer.  Beers are quite cheap where I live!
194YjsiwmGm3hcbPcJWWyzRAS9CQLX1fJL
laurentmt
Sr. Member
****
Offline Offline

Activity: 386
Merit: 250


View Profile
March 06, 2015, 02:54:47 PM
 #8

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  Cheesy) and I've found 1 ip from this subnetwork (among 56 connections)
spin
Sr. Member
****
Offline Offline

Activity: 360
Merit: 250


View Profile
March 06, 2015, 08:53:26 PM
 #9

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  Cheesy) and I've found 1 ip from this subnetwork (among 56 connections)
Also had 1. Blocked it also.

If you liked this post buy me a beer.  Beers are quite cheap where I live!
194YjsiwmGm3hcbPcJWWyzRAS9CQLX1fJL
2112
Legendary
*
Offline Offline

Activity: 2058
Merit: 1002



View Profile
March 06, 2015, 11:59:14 PM
 #10

This, on the first sight, looks to me as a large scale monitoring of the bitcoin network.
How about another hypothesis: an head-end of a CG-NAT (http://en.wikipedia.org/wiki/Carrier-grade_NAT) device for some large French MVNO (http://en.wikipedia.org/wiki/Mobile_virtual_network_operator) or some similar arrangement like Orange FunSpot (Free WiFi Internet access service).

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
Evil-Knievel
Legendary
*
Offline Offline

Activity: 1134
Merit: 1142



View Profile
March 07, 2015, 12:00:45 AM
 #11

This message was too old and has been purged
2112
Legendary
*
Offline Offline

Activity: 2058
Merit: 1002



View Profile
March 07, 2015, 12:40:19 AM
 #12

Yeah, but this would not explain why those nodes are neither relaying TX, nor replying to BitcoinPing messages, ...
Seems they save bandwith aggressively and prepare for something bigger.
OK, if they don't behave like a normal client behind a NAT that definitely confirms your suspicions. Large scale NAT farms are popping all over the world right now, and many programs tend to go berserk when receiving connections from those.

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2436
Merit: 1183



View Profile
March 07, 2015, 12:41:55 AM
 #13

What I noticed is, that the seed nodes (from time to time) return dozens of bitcoin addresses from the same subnet (from france).
Can you clarify what you mean by "the seed nodes". Do you mean DNS seeds?  Returning how? Need more details!

Edit: Okay, I see seed.bitcoin.sipa.be is returning a single 46.105/16 to me. Is this what you're referring to?

Bitcoin will not be compromised
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2436
Merit: 1183



View Profile
March 07, 2015, 01:26:52 AM
 #14

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.

Bitcoin will not be compromised
laurentmt
Sr. Member
****
Offline Offline

Activity: 386
Merit: 250


View Profile
March 07, 2015, 02:54:22 AM
 #15

This, on the first sight, looks to me as a large scale monitoring of the bitcoin network.
How about another hypothesis: an head-end of a CG-NAT (http://en.wikipedia.org/wiki/Carrier-grade_NAT) device for some large French MVNO (http://en.wikipedia.org/wiki/Mobile_virtual_network_operator) or some similar arrangement like Orange FunSpot (Free WiFi Internet access service).

Considering that OVH provides 256 IP for free with each dedicated server, I bet 10 satoshis that we have a single monitoring node behind all these IPs.
Evil-Knievel
Legendary
*
Offline Offline

Activity: 1134
Merit: 1142



View Profile
March 07, 2015, 10:29:47 AM
 #16

This message was too old and has been purged
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2436
Merit: 1183



View Profile
March 07, 2015, 10:59:52 AM
 #17

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. Smiley


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.

Bitcoin will not be compromised
2112
Legendary
*
Offline Offline

Activity: 2058
Merit: 1002



View Profile
March 07, 2015, 09:27:46 PM
 #18

Or maybe some kind of NAT problem is going on (i am on a full cone NAT here). Or maybe this is all stupid what I am talking about. I will double check shortly.
Ah, so there is a NAT device involved here. This basically invalidates all your previous observations, as they can be explained easily as the errors in the NAT implementation. Especially if somebody advertises "full cone NAT" (only relevant to UDP) when interfacing TCP application.

Please do us all a favor and tell us the manufacturer/model/version information for your NAT box. Everyone could then just add it to they "do not use/buy" list.

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
Cryptowatch.com
Full Member
***
Offline Offline

Activity: 196
Merit: 100


View Profile WWW
March 13, 2015, 01:14:32 AM
 #19

I noticed that one of those nodes were connected to my own node, then I scanned it:

Starting Nmap 6.00 ( http://nmap.org ) at 2015-03-13 01:48 CET
Nmap scan report for 46.105.210.179
Host is up (0.065s latency).
Not shown: 996 closed ports
PORT     STATE    SERVICE
22/tcp   open     ssh
445/tcp  filtered microsoft-ds
8080/tcp open     http-proxy
8333/tcp open     unknown

Seeing it had a http-proxy, I connected to it with a browser and got this message, in a typical login box you get with .htaccess restrictions:

A username and password are being requested by http://46.105.210.179:8080. The site says:

 "Please authenticate using your Chainalysis API-ID and API-Key". [sic]

I tried another IP, same result. These are the offending IP's that has connected to my node:

46.105.210.194, 46.105.210.11, 46.105.210.255, 46.105.210.138, 46.105.210.196, 46.105.210.246, 46.105.210.220, 46.105.210.204, 46.105.210.179, 46.105.210.189, 46.105.210.10, 46.105.210.42


And then a google search which gave me:

https://chainalysis.com/

"Providing technical solutions to automate crypto currency compliance"

"
Company

Chainalysis offers a service that provides financial institutions with the means to obtain regulatory compliance through real-time analysis of the blockchain. Chainalysis customers get access to an API that allows them to determine which entity a transaction originates from, and whether the flow of funds originate from someone they would want to do business with. In other words, it automates the travel rule.

Chainalysis achieves this by doing sophisticated in-depth real-time transaction analysis to determine unique entities within the blockchain.

Besides for API access, customers are provided with a web interface enabling them with easy transaction route investigation, private annotation of entities and transactions and automated report generation."


Michael Grønager
Chief Executive Officer

Jan Møller
Chief Technology Officer

Jens Hilligsøe
DevOps Engineer

Kresten Krab Throup
Consulting Architect

Jørn Larsen
Business Advisor


Personally I've perma-blocked these guys now. I should make the iptables rules persistent on my node. Also, is there a blacklist where bad actors are listed with a reason, so a node operator could chose to block such entities? Personally I don't like blacklists much, perhaps whitelists are better, but it's impossible to keep track of every time someone posts about bad nodes.

I understand the need for such a solution as chainalysis from a regulatory and business perspective, however I'm don't think this is in the true spirit of bitcoin, but I guess someone would've provided this kind of service no matter what. But this is akin to spying to be honest. And it is exactly that we're wanting to get away from with all the monitoring that goes on in the traditional financial system. If Joe pays Alice 10 bucks, it's noone's damn business how, where and what relates to that payment.
onemorexmr
Sr. Member
****
Offline Offline

Activity: 252
Merit: 250



View Profile
March 13, 2015, 01:17:51 AM
 #20

I noticed that one of those nodes were connected to my own node, then I scanned it:

Starting Nmap 6.00 ( http://nmap.org ) at 2015-03-13 01:48 CET
Nmap scan report for 46.105.210.179
Host is up (0.065s latency).
Not shown: 996 closed ports
PORT     STATE    SERVICE
22/tcp   open     ssh
445/tcp  filtered microsoft-ds
8080/tcp open     http-proxy
8333/tcp open     unknown

Seeing it had a http-proxy, I connected to it with a browser and got this message, in a typical login box you get with .htaccess restrictions:

A username and password are being requested by http://46.105.210.179:8080. The site says:

 "Please authenticate using your Chainalysis API-ID and API-Key". [sic]

I tried another IP, same result. These are the offending IP's that has connected to my node:

46.105.210.194, 46.105.210.11, 46.105.210.255, 46.105.210.138, 46.105.210.196, 46.105.210.246, 46.105.210.220, 46.105.210.204, 46.105.210.179, 46.105.210.189, 46.105.210.10, 46.105.210.42





nice find!

https://chainalysis.com/

"Chainalysis offers a service that provides financial institutions with the means to obtain regulatory compliance through real-time analysis of the blockchain. Chainalysis customers get access to an API that allows them to determine which entity a transaction originates from, and whether the flow of funds originate from someone they would want to do business with. In other words, it automates the travel rule.
Chainalysis achieves this by doing sophisticated in-depth real-time transaction analysis to determine unique entities within the blockchain.
Besides for API access, customers are provided with a web interface enabling them with easy transaction route investigation, private annotation of entities and transactions and automated report generation."

seems to be them....

XMR || Monero || monerodice.net || xmr.to || mymonero.com || openalias.org || you think bitcoin is fungible? watch this
Pages: [1] 2 3 4 5 6 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!