(Please edit me. I'm a community wiki)
Summary
- Don't allow TCP request on port 8545 from the Internet to be forwarded to your
geth machine
- Don't enable
--rpc without checking that only your GPU mining computers can access TCP port 8545 on your Ethereum node geth computer
- Don't run the Ethereum Wallet on the same machine as your
geth computer.
- If you need a "solo mining pool", consider using the pool backend software that will restrict the instructions that will be forwarded to your
geth instance.
EDIT 31/05/2016 - SECURITY ALERT!
From blog.ethereum.org - Security Alert – cpp-ethereum keeps accounts unlocked:
Affected configurations: cpp-ethereum (eth, AlethZero, …) version 1.2.0 up to 1.2.5 (fixed in 1.2.6)
Note: Neither “geth” nor “Mist” nor the “Ethereum Wallet” (unless explicitly used together with cpp-ethereum) are affected by this, they lock accounts correctly again.
Severity: High
Possible Attacks: Attackers can spend funds from previously used accounts if they have access to the local machine or to an exposed json-rpc interface.
Details: Due to a bug in cpp-ethereum, accounts stay unlocked once their password has been entered until cpp-ethereum is closed. This includes accounts encrypted with the “master password” entered upon startup or any password entered through Mist. This means that an attacker can spend funds from the account as soon as they have access to the RPC interface. For that to happen, they either need access to the local filesystem or the exposed http-json-rpc interface (not the default setting). Using Mist in “Mist mode” (not the default setting) and navigating to a malicious website also provides that website access to the RPC interface.
Proposed temporary workaround: Restart eth after each transaction, do not expose the json-rpc interface via http and upgrade to version 1.2.6 as soon as binaries are released. A fix has already been merged to the develop branch.
Details
Here are some steps to reduce the chances of getting your Ethereum wallet hacked.
1. Restrict Access To RPC On Your Mining Computers
For most Ethereum miners, you will be using geth to running the blockchain node and ethminer to perform the mining calculations.
If you are running only one geth instance and the ethminers on just one computer, restrict your RPC port to only serve on the local computer. The option --rpcaddr 127.0.0.1 (which is the default setting) will restrict your RPC communications to just that computer.
If you are running only one geth instance on one computer and ethminer on the same computer plus ethminer on other computers that will need to communicate with the one geth instance, you will have to use your computer's local network IP, for example --rpcaddr 192.168.1.123. In this case, it is best set up a firewall to restrict communications via RPC to geth to your mining rigs only.
2. Don't Run The Ethereum Wallet (Mist) On Your Mining geth Node Computer
If you run Mist on your mining node, when you send a transaction with Mist, it will communicate via the IPC socket to instruct geth to unlock your account for 2 seconds.
If you have RPC turned on and this port is accessible from the Internet, scripts and bots will be able to send transactions on your geth node to snatch your coins in the short period of time that Mist unlocks your accounts, as happened to Patrick.
If you have RPC turned off and your mining computer has been compromised, any locally installed malware will be able to use the IPC socket to snatch your coins.
Don't run Mist on your mining computer. Use it on a separate secure computer instead.
3. Check You $HOME/.ethereum/history File And Erase If Necessary
The history of the commands you type into geth ... console is stored in $HOME/.ethereum/history. The following shows what I have just typed into the console:
> eth.mining
true
> personal.unlockAccount(eth.accounts[0], "invalidpassword", 2)
Decryption failed: MAC mismatch
at InvalidResponse (<anonymous>:-81662:-62)
at send (<anonymous>:-156322:-62)
at unlockAccount (<anonymous>:-133322:-62)
at <anonymous>:1:1
And here are the last two lines of my $HOME/.ethereum/history file:
eth.mining
personal.unlockAccount(eth.accounts[0], "invalidpassword", 2)
Check the contents of your history file using the command:
user@Kumquat:~$ grep unlock $HOME/.ethereum/history
personal.unlockAccount(eth.accounts[0], "invalidpassword", 2)
If you have ever used the command personal.unlockAccount(...), erase your history file:
rm $HOME/.ethereum/history
By default the directory in which your history file is located is only readable by your own user. But if your account is compromised, your password is in your history file:
user@Kumquat:~$ ls -al | grep .ethereum
drwx------ 9 user user 4096 May 14 00:28 .ethereum
4. Move Your Mining Rewards If They Are Too Much To Lose
Your mining computer is continually communication with other programs on the Internet and is at a higher-than-usual risk of getting compromised.
Hackers can easily find Ethereum nodes on the Internet and your computer may be targeted. Move your mining rewards to a more secure Ethereum account to reduce the size of your losses if you do get hacked.
5. Reduce Your Attack Surface If Possible
Run the server version of Ubuntu Linux if possible. It is a little bit harder to install, especially the GPU drivers, but you have a lower chance of getting hacked as fewer services run in this version compared to the desktop version.
Ubuntu Desktop has many more bits of software running continually with exposed ports. If you do have to use Ubuntu desktop, turn off unnecessary services, don't install untrusted software. You may want to use the privacy settings to reduce any leakage of information:
- Settings -> Security & Privacy -> Files and Applications OFF
- Settings -> Security & Privacy -> Search OFF
- Settings -> Security & Privacy -> Diagnostics ALL OFF
/etc/default/appport. Set enabled=0
Macs and Windows continually phone home and very likely have backdoors for Apple and Microsoft respectively. Even if Apple and Microsoft have little incentive to expose themselves by utilising the backdoors, the continuous chatter makes it hard to detect abnormal communications between your server and other computers.
6. Secure Your Network
- Check you have a relatively secure ADSL modem/router or networking device. Backdoors are sometimes installed by the manufacturer and your Internet Service Provider (if you got your modem from them as part of the service). While they may not want to cause any malicious damage by utilising the backdoors, hacker have exploited some of the poorly secured networking devices. For example, see Cisco, Linksys, Netgear backdoors.
- Run your mining computers in the DMZ (demilitarised zone) to separate your Internet exposed mining computers from your other networked devices. You should test your networking device's DMZ functionality if you use this as I have come across some networking devices that don't partition the DMZ properly.
- Firewall your mining computers so that the only incoming port from the Internet is TCP and UDP 30303, and if you have RPC switched on for your
geth instance, only allow communications on the RPC port from your mining computers.
7. Don't Use The User root (Or User With Administrator Privileges) To Run Your Miners
If your Internet facing programs (geth) has a vulnerability, a hacker can cause more damage if the program is running with administrator privileges.
8. Check Your Port Forwarding Rules On Your Router Or Firewall
Only the port 30303 for TCP and UDP traffic should be forwarded by your modem or firewall to your geth node computer. Port 8545 (or whatever you configured for your RPC port) should NOT be forwarded to your geth node computer.
My firewall rules are for my 2 mining rigs (.120 has the geth instance, .121 is just a GPU miner, .111.* is my DMZ):
* Allow Internet to DMZ geth machine TCP 30303
Protocol TCP, Source Any, Destination 192.168.111.120:30303
* Allow Internet to DMZ geth machine UDP 30303
Protocol UDP, Source Any, Destination 192.168.111.120:30303
* Allow Ethereum RPC 8545 traffic from GPU miner to geth machine
Protocol TCP, Source 192.168.111.121, Destination 192.168.111.120:8545
* Allow SSH traffic to mining rigs
Protocol TCP, Source 192.168.1.*, Destination 192.168.111.*:22
* Block everything else
Protocol *, Source Any, Destination 192.168.111.*:*
9. Test For Open Ports On Your Internet Connection
Use a service like GRC to probe for the open ports on your Internet connection. Click on grc.com, click on Shields UP!!, then click on ShieldsUP! again. Read the text and click Proceed.
On the web page shown below, I've typed in ports 8545, 30303 and clicked User Specified Custom Port Probe:
The probe results are shown below - Port 8545 (geth RPC) is not open to the Internet while port 30303 (Ethereum P2P port) is:
It's probably a good idea to test All Service Ports (Ports 0 to 1055) at the same time to confirm which ports you have open. The following results show that I only have port 443 (HTTPS) open:
10. Opening RPC Ports For Miners Outside Your Network (Your Own Solo Mining Pool With Your Own Distributed Miners)
Don't open up your RPC port 8545 if you have GPU miners outside your network.
Your alternatives if you have GPU miners outside your network with your geth instance:
- Run
geth locally within each of your GPU miner's networks pointing to the same coinbase account if necessary; or
- Consider running the
ether-pool component of open-ethereum-pool. You don't have to run the web frontend, the unlocking or the payout modules. Only safe instruction from/to the GPU miners to/from geth passes through the mining pool software. One advantage of running this software is that you get a better performance from the stratum mining proxy protocol. The ability to mine with a particular coinbase (payout address) is not contingent on the mining node having access to the coinbase's private keys; you can generate the address and private key on another machine and set the mining node's coinbase to the generated address. This reduces damage from a compromised node: past payouts cannot be stolen by merely compromising the node.
Best Answer
There are many possibles reasons that this happened and I will try to list them all.
First of all, the problematic transaction called the
transfer()function on the POLS token contract, not thetransferFrom()function. It means that this fraud has nothing to do with the approval you made earlier to Uniswap. The transaction must have been signed either by you or by someone who has access to your private key.Possible reasons:
My advice would be to create a new wallet (new mnemonic) on a different device and transfer everything you have to that new address. Assume that all the devices you used are compromised.