I am trying to send transactions via web3.py interface that is connected to a local geth node. Having read some comments on why using RPC is bad, I am still wondering if using -rpc option is unsafe when port 8545 is closed. According to this article (https://www.zdnet.com/article/hackers-ramp-up-attacks-on-mining-rigs-before-ethereum-price-crashes-into-the-gutter/) the vulnerability is just on exposed ports, but since I am basically communicating with a node on local network this shouldn't be a problem right?
The article covers an attack vector, where the attackers look for machines with opened port 8545 and try to run JSON-RPC commands (on these machines) that would benefit them. This attack only works if:
The machine has the port 8545 opened to public
The port is used by an Ethereum node (and not some arbitrary app)
The node has enabled JSON-RPC
The node hasn't enabled the user/password credentials for JSON-RPC
So as long as your node is only accessible on a local network, you are pretty much safe from this attack vector (assuming there's no port forwarding etc. that would actually allow accessing your node from a public network and that there's no attacker on your local network).
Related
I am planning to run an SSIS ETL job , which has a sql server as SOURCE db , this is on a physical on-premise machine and the DESTINATION db (postegres/patroni) is running on Openshift platform as pod/containers. The issue I am facing now is like, DB hosted on openshift cannot be exposed via tcp port. As per few articles online, openshift only allows HTTP traffic via “routes”. Is this assumption right? If yes, how in real world people run ETL or bulk data transfer or migration to a db on openshift from outside. I am worried to use HTTP since I feel , it’s not efficient for ETL. Few folks mentioned like, use OC PORT FORWARDING. But for a production app, how an open shift port forwarding be stable? Please throw your comments
In a production environment it is a little questionable if you want to expose your database to the public internet. Normally you probably rather want to go with a site-to-site VPN.
That left aside it is correct that OCP is using routes for most use cases, which are then exposing an http(s) endpoint. If you need plain TCP however, you can create a service of type loadbalancer.
The regular setup with a route is stacked like
route --> service --> pods where the service is commonly of type clusterIP.
with a service of type loadbalancer, you eliminate the route and directly expose a TCP service.
If you run on a public cloud, OCP takes care of the leftover requirements for you. Namely that is to create a Loadbalancer with your cloudprovider. In the case of AWS for example, OCP would create an ELB (Elastic Loadbalancer) for you.
You can find more information in the documentation
I have deployed the Spring boot app on the OCI compute and its comping up nicely. Compute is created with public ip and have the security list updated to allow connections from internet. But, I wasn't able to hit the end point from internet. For that reason, I thought of configuring the load balancer.
Created load balancer in a separate subnet(10.0.1.0/24), routing table and security list. Configured the LB's security list to send all protocol packets to compute's CIDR(10.0.0.0/24) and configured compute's security list to accept the packets from LB. I was expecting LB to make connection with back end. But, its not.
I am able to hit the LB from internet :-
Lb's routing table with all ips routed through internet gateway. There is no routing defined for compute's CIDR as its in the VCN.
LB has its own security list, which has allowed out going packets to compute and incoming from internet as below:
Compute's security list accepting packet's from LB:
Let me know, if I am missing something here.
My internet gateway :-
My backend set connection configuration from LB:
LB fails to make connection with backend, there seems to be no logging info available :
App is working fine , if I access from the compute node :
The LB has a health check that tests the connection to your service. If it fails, the LB will keep your backend out of rotation and give you the critical health like you're seeing.
You can get to it by looking at the backend set and clicking the Update Health Check button.
Edit:
Ultimately I figured it out, you should run the following commands on your backend:
sudo firewall-cmd --permanent --add-port=8080/tcp
sudo firewall-cmd --reload
Use the port that you configured your app to listen on.
I used httpd instead of spring, but I also did the following
sudo semanage fcontext -a -t httpd_sys_content_t "/var/www/html(/.*)?"
sudo restorecon -F -R -v /var/www/html
I'm not really too familiar with selinux but you may need to do something similar for your application.
Additionally, setting up a second host in the same subnet to login to and test connecting to the other host will help troubleshooting, since it will verify if your app is accessible at all outside the host that it's on. Once it is, the LB should come up fine.
TL;DR In my case it helped to switch the Security List rules from stateful to stateless on the 2 relevant subnets (where the loadbalancer was hosted and where the backends were located).
In our deployment I had a loadbalancer with public IP located on one subnet, while the backend to this loadbalancer was on another subnet. Both subnets had one ingress and one egress rule - to allow everything (i.e. 0.0.0.0/0 and all ports allowed). The backends were still not reachable from the loadbalancer and the healthchecks were failing.
Even despite the fact that in my case as per the documentation switching between stateful and stateless should not have an effect, it solved my issue.
Im implementing a ethereum PoA network using go-ethereum
I have deployed a ERC20 Token on the network, and the idea is that the network must be accessed from any wallet on the internet (i.e metamask, myetherwallet, etc)
The idea for this network is:
Having N full nodes that are able to seal blocks (the nodes has the unlocked accounts)
Deploy a smart contract that is a ERC20 Token
Having one node that expose the network in order to be accessed from any origin, for example, Metamask, MyEtherWallet, a mobile app with a wallet, etc. The idea is that anybody can hit the ERC20 Token if they have the appropiate client.
In order to achive that, i create 2 full nodes that are in charge of sealing the blocks.
I run those nodes like this:
geth --datadir sealer1/ --syncmode 'full' --port 30351 --rpc --rpcaddr 'localhost' --rpcport 8502 --rpcapi='admin,personal,db,eth,net,web3,txpool,miner' --networkid 20 --gasprice '1' -unlock 'someaccount' --password s2/password.txt --mine
As you can see, there are some important things about those nodes:
Unlocks the accounts
Are only accessed from localhost (note the rpcaddres)
Those nodes are miners
If i expose a node like that to the internet (enabling RPC access from any origin) any hacker could send the ether to another account, so, i create a third node, a standard node, that doesnt expose rpc apis but allows connections on port 8545 (in order to be hitted from metamask, myetherwallet, etc)
I run the node with this command:
geth --datadir standard1/ --syncmode 'full' --port 30352 --rpc --rpcport 8545--rpccorsdomain '*' --rpcaddr 'SERVER_PUBLIC_IP' --networkid 20 --gasprice '1'
as you can see this node:
Doesnt unlock account
Allow rpc accesing from any origin
Doesnt expose rpc apis like personal, admin, etc
My questions are:
is this aproach secure?
Is there another way to allow anyone in the world to use Metamask to hit my smartcontract without open the RPC access on the standard node?
Why i have those questions?
Because there are a lot of places that doesnt recommend open RPC ports, so im not secure if:
Dont have a node exposed with unlocked accounts
Dont expose critical rpc apis like admin and personal
is enough to expose securely my node.
Here are some issues related with opening RPC access:
https://blog.blockdaemon.com/ethereum-geth-configuration-made-in-ireland-7ba2e876c6e3
https://www.reddit.com/r/ethereum/comments/4z0mvi/ethereum_nodes_with_insecure_rpc_settings_are/
https://www.reddit.com/r/ethereum/comments/3ird55/holy_shit_my_eth_accounts_been_hacked/
https://www.reddit.com/r/ethereum/comments/4jav5u/mist_wallet_has_2_sec_vulnerability_for_rpc/
https://blog.3or.de/internet-wide-ethereum-json-rpc-scans.html
https://www.bokconsulting.com.au/blog/7218-ethers-stolen-from-miner-with-rpc-port-open/
https://blog.ethereum.org/2015/08/29/security-alert-insecurely-configured-geth-can-make-funds-remotely-accessible/
Here the team lead of ethereum recomendation:
Ok, your setup seems insanely dangerous. --rpcaddr=external_address
essentially opens up the node to anyone in the world to access it.
Forthermore, --rpcapi 'admin,personal,db,eth,net,web3,txpool,miner'
permits anyone with access to do absolutely anything. I can imagine
someone from the internet is brute forcing the passwords.
https://github.com/ethereum/go-ethereum/issues/17417#issuecomment-413877558
is this approach secure?
You get the general idea, yes, but there is room for improvement.
First of all, I would never run a node that enables the personal API at the same time using -unlock which permanently makes the account accessible by anyone with access to your node. So imagine, someone has gained access to your node through some other doors, they would be able to immediately spend your funds from that account spawning transactions from localhost. Please, consider either only exposing safe APIs on that node or completely removing the unlock statement.
If you insist having the sealing nodes configurated as stated above, add some hardening. There are multiple options, you can use strong firewall rule sets to block basically everything from the outside network except for the node communications on port 30351. Or, what I would do, is hiding disconnecting this node completely from the public Internet and only wire through the p2p traffic from this node to some other proxy node which is connected to both, your node and the other nodes on the Internet. This could come with drawbacks in network stability though.
Is there another way to allow anyone in the world to use Metamask to hit my smartcontract without open the RPC access on the standard node?
Have you considered looking into public PoA networks such as poa.net? This basically allows your users to connect metamask or mycrypto to the already existing infrastructure of POA.
I have what is going to be a production MySQL database, and we want to access such remotely but haven't found a secure way to do it.
Docker Swarm do not have support for host bound ports such as 127.0.0.1:3303:3303, however normal mode does. Making a port public becomes also public in all swarm nodes.
Using firewalls is not really an option since we would have to configure these on every single node in the swarm.
We have on table only two options
Opening the port and only allowing connections through TLS and enforcing REQUIRE options Issuer and Subject, to only one single user and probably read_only. Still seems to be highly insecure due to having the open port.
Creating a temporary dockerized sshd service and making it available in the same network as MySQL service, it is more hazzle to manage these ssh containers. Still more secure since it would be turn on/off when needed
Question: Is there any other/better options to approach this? and how badly insecure is it to have open port + tls connections?
If you have a good argument against accessing MySQL remotely I would appreciate it
I have deployed a hadoop cluster on google compute engine. I then run a machine learning algorithm (Cloudera's Oryx) on the master node of the hadoop cluster. The output of this algorithm is accessed via an HTTP REST API. Thus I need to access the output either by a web browser, or via REST commands. However, I cannot resolve the address for the output of the master node which takes the form http://CLUSTER_NAME-m.c.PROJECT_NAME.internal:8091.
I have allowed http traffic and allowed access to ports 80 and 8091 on the network. But I cannot resolve the address given. Note this http address is NOT the IP address of the master node instance.
I have followed along with examples for accessing IP addresses of compute instances. However, I cannot find examples of accessing a single node of a hadoop cluster on GCE, that follows this form http://CLUSTER_NAME-m.c.PROJECT_NAME.internal:8091. Any help would be appreciated. Thank you.
The reason you're seeing this is that the "HOSTNAME.c.PROJECT.internal" name is only resolvable from within the GCE network of that same instance itself; these domain names are not globally visible. So, if you were to SSH into your master node first, and then try to curl http://CLUSTER_NAME-m.c.PROJECT_NAME.internal:8091 then you should successfully retrieve the contents, whereas trying to access from your personal browser will just fail to resolve that hostname into any IP address.
So unfortunately, the quickest way for you to retrieve those contents is indeed to use the external IP address of your GCE instance. If you've already opened port 8091 on the network, simply use gcutil getinstance CLUSTER_NAME-m and look for the entry specifying external IP address; then plug that in as your URL: http://[external ip address]:8091.
If you turned up the cluster using bdutil, a more involved but nicer way to access your cluster is by running the bdutil socksproxy command. This opens a dynamic-port-forwarding SSH tunnel to your master node as a SOCKS5 proxy, so that you can then configure your browser to use localhost:1080 as your proxy server, make sure to enable remote DNS resolution, and then visit your browser using the normal http://CLUSTER_NAME-m.c.PROJECT_NAME.internal:8091 URL.