gridcoin-community / Gridcoin-Research

Gridcoin-Research
MIT License
585 stars 173 forks source link

/src/net.cpp seed node issues - dead nodes , redundant nodes , forced nodes , hard coded nodes , node security issues #764

Closed dopeshitnetworks-irc-dopeshit-net closed 6 years ago

dopeshitnetworks-irc-dopeshit-net commented 6 years ago

This is an issue I have been looking into and at for the past few months after seeing 1 user having 260+ connections on single nodes.. Additionally it has been brought up on freenode #gridcoin and on the mumble sessions but lets put it into the light! So upon working on the PPC64 GNU Linux porting of the wallet I ran into lines 1477 - 1488 of /src/net.cpp while perusing the source code. These are the Gridcoin hard coded seed nodes compiled both into the windows client distributed from the website www.gridcoin.us and the source code here on github so check it yourself I did not write it , change it or edit it. Please note , additionally the default .conf packaged with the windows client install also has dead nodes and a new updated ( we do update the wiki regularly for our community ) version of the default nodes used in the default client created .conf should be replaced and repackaged " example listed in this as its a hard coded seed node that is dead along with the old node entry under the domain magnatude.tld. Here is the source , I will create a new issue per updating the default packaged gridcoinresearch.conf nodes if needed , they are way outdated...

// DNS seeds // Each pair gives a source name and a seed name. // The first name is used as information source for addrman. // The second name should resolve to a list of seed addresses. static const char *strDNSSeed[][2] = { {"node.gridcoin.us", "node.gridcoin.us"}, {"gridcoin.asia", "gridcoin.asia"}, {"amsterdam.grcnode.co.uk", "amsterdam.grcnode.co.uk"}, {"london.grcnode.co.uk", "london.grcnode.co.uk"}, {"frankfurt.grcnode.co.uk", "frankfurt.grcnode.co.uk"}, {"", ""}, };

Now lets take at a look at these seed nodes and if they resolve and if so where to! Lets also point out the obvious problem and issues! We may just need some new network savvy dev's on the team , along with audits of entires like these?

1 node.gridcoin.us - A record ( ipv4 ) resolves to: 47.188.231.176 - Sweet! Should , its the main node!

2 gridcoin.asia - No A record ( ipv4 ) no AAA record ( ipv6 ) = DEAD , does not resolve to an ip!

3 amsterdam.grcnode.co.uk - A record ( ipv4 ) resolves to: 45.76.142.167 - Good!

4 london.grcnode.co.uk - A record ( ipv4 ) resolves to: 45.76.142.167 - Um , do you see it????

5 frankfurt.grcnode.co.uk A record ( ipv4 ) resolves to: 45.76.142.167

 frankfurt.grcnode.co.uk A record ( ipv4 ) resolves to: 45.76.173.179
 frankfurt.grcnode.co.uk A record ( ipv4 ) resolves to: 45.76.182.98
 frankfurt.grcnode.co.uk A record ( ipv4 ) resolves to: 45.32.75.233

So after just a quick look via " dig " and the Linux cli and checking both for A and AAAA records we see that the hard coded or " seed nodes " and you should be able to see the issue yourself but I have provided the results myself to make your life easier. Why does the single owner of those 3 node entries #3 , #4 and #5 even exist in the source code and nobody else? I tried almost a year ago to correct this , but I do not code and messed up on my first attempt but latter fixed the errors and resubmitted a fix to correct this by removing the redundant nodes and replacing them with ones that have been around a while and shown stable that are provided by the community. Makes sense when that person whom is our fearless team leader investor brags about his node user count as if the rest of us whom do not have 260 users per node are helping our their share at carrying the network load or even needed or useful when he hordes the connections the Gridcoin wallets spider out. Especially when its hidden and very VERY much not de-decentralized and being used in a very deceptive and devious way.Many of us pay out of our own pockets , not from foundation expenses to provide VPS's or dedicated servers as nodes on the Gridcoin network along with paying for our own domains so this does not sit well with me and I know it does not for others.

Moving on , lets look further at the redundancy of the entries?? Recently gridcoin.is.dopeshit.net the round robin dns entry hosted on cloudflare and ddos mitigated accessible by myself and a few other node providers was removed by Bryan - Neuralminer for his own personal dislike for me but he listed it on the wiki as " security issue " but that means too in fact with that logic that customminers hard coded round robin multiple A record DNS entry too is a security issue as he controls those 3 sub domains off his domain grcnode.co.uk and is the ONLY one with access ( or foundation domain with only his access? ) and can force ALL of the Gridcoin network users into his own nodes FORCED ( as he is doing and its plain to see , i provided the evidence both code and network ) only and make the other nodes provided almost useless because he can dominate the network and user load by changing , adding , removing and editing DNS entries to his agenda and motives along with the above by making other nodes under those DNS entires with multiple A records and force the majority of the Gridcoin network onto using his and only his nodes.

iFoggz commented 6 years ago

my two prod nodes support ipv6 ive noticed an increase amount of users on that.

tomasbrod commented 6 years ago

Could be written with less anger, but ok. Thanks for pointing out.

Mercosity commented 6 years ago

I for one have your nodes in my config file @Foggyx420 and I also have yours @grcjamezz but I'm in complete agreement that the 'hard coded' nodes issue does need to be resolved as it is a risk that we shouldn't be taking anymore. I understand the 'initial' need/requirement for seed nodes in the 'earlier days of Gridcoin' but there are better ways to do this which are much more secure. As @grcjamezz says round robin DNS certainly could be a solution to the initial new user startup requirement. This situation does need to be looked at by the 'network savvy' devs as it definitely highlights a basic weakness in our infrastructure similar to the 'data scraper' controlled by Rob Halford on which we base the dissemination of CPID data of BOINC projects. Forced centralisation for retrieval or transmission of data constitutes an inherent security weakness and can also be viewed as a 'control' issue and 'unfair advantage' in the eyes of 'savvy' users. I trust that this will be reviewed and a solution discussed and found by our devs in the very near future.

The last time this was brought up it was 'passed over' as inconsequential and unimportant since it was simply grcjamezz and myself who highlighted it and thus was ignored and 'brushed under the mat'. Hence the slightly aggressive tone of these posts by myself and grcjamezz. Nothing was done ..

Peppernrino commented 6 years ago

for the record, i DID remove amsterdam and frankfurt nodes from the official node list a good bit ago when @grcjamezz originally brought this up. link to change. @grctest had no problems with the idea and agreed immediately when i showed him the IP's. if i had to say, i'm pretty sure he had no idea. i just puchased a new VPS, and it has its own DNS (4 locations), which might be kind of the same thing he had and would get confusing for me as well.

this is why i said i missed @grcjamezz. he's good at sniffing out network things... but i think discussing anybody's attitude should be avoided. i don't see anybody else being called out on that as much as him. maybe me... lol... but it's not as though anybody's like, "hey rob. watch your tone!" word? ;)

Peppernrino commented 6 years ago

and after further reading here: i was told that the round-robin entry was to be used by itself in the config file, and that it wouldn't work properly in the presence of the other nodes. and i think i was the one that omitted it... from the autonode script at least. clearly, i have more to learn about DNS.

barton2526 commented 6 years ago

@denravonska Can this issue be closed?

denravonska commented 6 years ago

@grcjamezz Are the changes sufficient?

denravonska commented 6 years ago

Closing this until there is a vote pointing elsewhere.