Foxpup:
We have just shared our own experience. It's not a hired writer or some marketing b/s. The post has been written jointly by my software developer and myself. I've received thanks and comments from a telegram crypto community I've posted that into. I'm not sharing information here that I don't think is useful for community.
Under other blockchains I meant the multitude other blockchains that may have the same RPC vulnerability issue. I understand this forum has "bitcoin" in its name but for me in such cases Bitcoin is a symbol of blockchain (and values behind it) generally, not a specific cryptocurrency. I believe Ethereum and other blockchains developers shouldn't be herded into altcoins sub-forum here but that is obviously up to esteemed members and moderators here. Feel free to delete this topic.
Best regards
Taras
Topic: RPC vulnerability - protect your testnets (Read 229 times)
I've only had experience with Ethereum vulnerability here but assumed this would apply to other networks.
More details in our blog post here:
Quote
By default, the Ethereum RPC doesn’t have any authentication methods, unlike Bitcoin.
Would you please actually read what your writers contribute to your blog before repeatedly posting advertisements for it disguised as normal forum discussion? Thanks.
Thank you for your comments here ETFbitcoin and gmaxwell. I've only had experience with Ethereum vulnerability here but assumed this would apply to other networks.
RPC vulnerability is something that has been highlighted to me by cybersecurity experts when we discussed blockchain nodes vulnerability in general. Once you expose your RPC that is a threat.
Good to know Bitcoin Core is better protected there.
I think market needs some sort of OWASP top 10 / blockchain-specific vulnerability scanning solution to help developers protect their nodes and testnets here, not even mentioning production enterprise implementations.
RPC vulnerability is something that has been highlighted to me by cybersecurity experts when we discussed blockchain nodes vulnerability in general. Once you expose your RPC that is a threat.
Good to know Bitcoin Core is better protected there.
I think market needs some sort of OWASP top 10 / blockchain-specific vulnerability scanning solution to help developers protect their nodes and testnets here, not even mentioning production enterprise implementations.
Bitcoin Core's RPC interface is secure by default and at least slightly difficult to make insecure.
Hi all,
just wanted to warn those of you who like us are exposing your own blockchain / testnet via RPC, you need to take extra measures to protect against bot attacks there.
In our case someone (likely an automated script) has been able to access our Ethereum based development testnet via an open RPC port and transfer virtual Ether from a coinbase account. Luckily it wasn't a real currency and just a development testnet. However this shows are there are automated scripts / bots out there scanning for these kind of vulnerabilities.
Quick solution is to change port number from a default 8545 to some other arbitrary value.
Proper solution would be use Linux firewall and/or IP whitelisting.
More details in our blog post here:
https://www.dappros.com/201908/report-attack-on-dappros-platform-testnet/
just wanted to warn those of you who like us are exposing your own blockchain / testnet via RPC, you need to take extra measures to protect against bot attacks there.
In our case someone (likely an automated script) has been able to access our Ethereum based development testnet via an open RPC port and transfer virtual Ether from a coinbase account. Luckily it wasn't a real currency and just a development testnet. However this shows are there are automated scripts / bots out there scanning for these kind of vulnerabilities.
Quick solution is to change port number from a default 8545 to some other arbitrary value.
Proper solution would be use Linux firewall and/or IP whitelisting.
More details in our blog post here:
https://www.dappros.com/201908/report-attack-on-dappros-platform-testnet/
Jump to: