How do I detect a DDOS attack on my node? I have seen some posts on bitcointalk.org that there is a DDOS attack against nodes happening right now and they have instructions how to ban the attacking IPs.

How can I tell if my node is getting DDOS'ed? I did a getinfo command and everything looks normal.
The generic way to detect a DoS or DDoS attack against your node would be to connect to your node from an outside network.  For example, if you run a home node, you could use a remote Virtual Private Server (VPS) to connect to your node:

bitcoind -connect=&lt;your_home_nodes_ip_address&gt;


If that works, then you're not being attacked at the moment.  However, note that it could fail for legitimate reasons such as your home node not being configured to accept incoming connections or all of your node's incoming connection slots being legitimately filled.

Other ways of detecting an attack are more specific to the type of attack.  Some suggestions are provided below, but it's not an exhaustive list.

Bandwidth exhaustion

This is an attack against your entire network connection, not just your node.  It's one of the easiest attacks to notice because all of your normal traffic either ceases or slows to a crawl.  If you have bandwidth monitoring on your network (such as often provided by VPS services), you'll see the traffic spike.  If you don't, you can detect it easy by high latency and failure rates through ping:

ping example.com


This is the hardest attack to block, but it's can also be somewhat expensive for the attacker (not necessarily because they pay for the bandwidth---many of these attacks are performed with stolen resources---but because access to comprised networks for use in attacks is in high demand).

Connection slot exhaustion

By default Bitcoin Core and derived full nodes only allow a maximum of 117 incoming connections (another 8 connections are reserved for outgoing, bringing the total to 125).  Attackers have been known to attempt the fill all of these slots in order to prevent legitimate connections.

You can get information about your connections and peers from the Bitcoin daemon using the following commands:

bitcoin-cli getnetworkinfo
bitcoin-cli getpeerinfo


In the Bitcoin Core GUI, you can get much of the same information in a nice display by opening the Help menu and then clicking Debug.  The Information and Peers tab provide information, and you can right-click on a peer in the Peer tab to perform some actions:



Screenshot from my Bitcoin Core GUI wallet.  Not the best image since I connect solely to my border node, but hopefully you get the idea.

Keep in mind that your connection slots can also fill up with legitimate clients and other nodes.  Bitcoin Core has been getting better over the last few releases at dealing with people who attempt to attack this way and there are some nifty long-term ideas for making these attacks expensive for some classes of attackers but still affordable for regular users.

CPU and I/O exhaustion

BIP37 specifies Bloom filters for the Bitcoin peer-to-peer (P2P) protocol.  This may have originally worked fairly well, but as blocks have become larger and transactions have become more complex, full nodes are increasingly taxed by lightweight clients requesting filtered blocks.

Attackers can exploit this: for a very small amount of bandwidth on their part, they can ask full nodes to perform a modest amount of I/O retrieving old blocks from disk and a large amount of CPU filtering those blocks through a Bloom filter.

Detecting this attack is simple: your bitcoind will begin using a large amount of CPU for an extended period of time even though it is fully caught up to the best block chain.

If you find yourself under this type of attack (or wish to prevent it in the first place), you can start bitcoind or bitcoin-qt with the following option:

bitcoind -peerbloomfilters=0


Or add it to your bitcoin.conf file:

peerbloomfilters=0


Note that this means most P2P lightweight (SPV) clients will no longer connect to you if you disable bloom filters using the above option.

There has been discussion of disabling Bloom filtering by default in the past and encouraging SPV clients to use other methods of synchronization, such as downloading full blocks (high bandwidth but very good for privacy) or using committed Bloom filters (better privacy than BIP37 Bloom filters and probably reasonable bandwidth).