Ongoing DDoS attack on masternode network

I'm a little curious, did they handpicked some IP addresses to attack? or all 4176 ip?
Some serious amount of computer power there.

In any case this demonstrates the strength of the Dash network :) they failade hard. ;)
 
Does Vultr's DDOS protection ($10 extra per month) help with these kind of DDOS attacks?
 
Dash4Ever said:
I'm a little curious, did they handpicked some IP addresses to attack? or all 4176 ip?
Some serious amount of computer power there.

In any case this demonstrates the strength of the Dash network :) they failade hard. ;)
Click to expand...

The attack was against all MNs as far as we know, from 2,000 individual IPs mostly in Asia, i.e. a botnet
 
What exactly happens when a server is DDoS'ed? Does it just crash and restart? If that's the case, if i have my VPS set up with auto restart of dashd upon crash with dashcentral will the problem automatically solve itself if i get DDoS'ed?
 
edificio said:
What exactly happens when a server is DDoS'ed? Does it just crash and restart? If that's the case, if i have my VPS set up with auto restart of dashd upon crash with dashcentral will the problem automatically solve itself if i get DDoS'ed?
Click to expand...

It won't be able to answer any request from other peers/masternodes, so after a while it'll disappear form the masternode list due inactivity.

A possible crash is just the extra bonus you might get.
 
be careful when copy pasting iptables scripts. You might end up locking yourself out if you got ssh on another port like i do. So look through the script and look for port 22 and change it to your own.
 
crowning said:
It won't be able to answer any request from other peers/masternodes, so after a while it'll disappear form the masternode list due inactivity.

A possible crash is just the extra bonus you might get.
Click to expand...
this DDoS attack seem to focus on just port 9999, maybe if we all choose different ports instead of the default port this type of attack could be mitigated in the future ?
 
crowning said:
It won't be able to answer any request from other peers/masternodes, so after a while it'll disappear form the masternode list due inactivity.

A possible crash is just the extra bonus you might get.
Click to expand...

Ah i see. Is there a way to make it reboot automatically if all system resources are suddenly being used up?

Is it likely that the attacker would immediately start DDoS'ing the server again after that reboot? Of course ufw or iptables is the better option - But it would be nice to know the server would just reboot and start dashd again, should an attack slip through
 
AndyDark said:
The attack was against all MNs as far as we know, from 2,000 individual IPs mostly in Asia, i.e. a botnet
Click to expand...
I just watched a youtube video published on 6 March where Fluffypony from Monereo talks to Tone Vays about a DDoS attack on DASH.
 
qwizzie said:
i hope this does not mean we end up having to thank fluffypony for accelerating our hardware upgrade process ;)
Click to expand...
I think its great. The fluffster has in a way joined the dash development team by helping us test the network.

Good work fluffy.
 
qwizzie said:
this DDoS attack seem to focus on just port 9999, maybe if we all choose different ports instead of the default port this type of attack could be mitigated in the future ?
Click to expand...
This wouldn't help in the slightest, since every node (and hence everyone) would still have a list of all masternodes and ports.
 
Sapereaude said:
For those less technologically savvey there are step by step instructions below for Ubuntu 16.04. If you followed TAO's set up guide this will work for you.

**************
Enter root and enter the following commands

******* First Remove ufw
sudo ufw disable
sudo apt-get -y remove ufw
sudo apt-get -y purge ufw

****** Now install persistant ip tables and say yes when the purple screen appears
apt-get install -y iptables-persistent
invoke-rc.d netfilter-persistent save
service netfilter-persistent stop
service netfilter-persistent start

***** Now remove the old iptables file and paste in the new rules
rm /etc/iptables/rules.v4
joe /etc/iptables/rules.v4

************** Now paste in these rules and save
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:LOGNDROP - [0:0]
:OUTPUT ACCEPT [0:0]
#
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p tcp -j REJECT --reject-with tcp-reset
-A INPUT -j REJECT --reject-with icmp-proto-unreachable
# some tcp ddos
-A INPUT -i eth0 -p tcp -f -m tcp -j DROP
-A INPUT -i eth0 -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,ACK -j DROP
-A INPUT -i eth0 -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j DROP
-A INPUT -i eth0 -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP
-A INPUT -i eth0 -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j DROP
-A INPUT -i eth0 -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
-A INPUT -i eth0 -p tcp -m tcp --dport 0 -j DROP
#
-A INPUT -i eth0 -p tcp -m tcp --dport 9998 -j REJECT --reject-with tcp-reset
-A INPUT -i eth0 -p tcp -m tcp --dport 9999 --tcp-flags FIN,SYN,RST,ACK SYN -m connlimit --connlimit-above 8 --connlimit-mask 24 --connlimit-saddr -j DROP
-A INPUT -i eth0 -p tcp -m tcp --dport 9999 --tcp-flags FIN,SYN,RST,ACK SYN -m connlimit --connlimit-above 2 --connlimit-mask 32 --connlimit-saddr -j DROP
-A INPUT -i eth0 -p tcp -m tcp --dport 9999 -m conntrack --ctstate NEW -m recent --set --name DEFAULT --mask 255.255.255.255 --rsource
-A INPUT -i eth0 -p tcp -m tcp --dport 9999 -m conntrack --ctstate NEW -m recent --update --seconds 30 --hitcount 3 --name DEFAULT --mask 255.255.255.255 --rsource -j DROP
#
-A INPUT -i eth0 -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -m recent --set --name DEFAULT --mask 255.255.255.255 --rsource
-A INPUT -i eth0 -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -m recent --update --seconds 30 --hitcount 3 --name DEFAULT --mask 255.255.255.255 --rsource -j DROP
#
-A INPUT -i eth0 -p tcp -m tcp --dport 9999 -j ACCEPT
#
-A INPUT -i eth0 -p tcp -j ACCEPT
-A OUTPUT -o eth0 -j ACCEPT
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
#
-A INPUT -j LOGNDROP
-A LOGNDROP -p tcp -m limit --limit 32/min -j LOG --log-prefix "Denied TCP: " --log-level 7
-A LOGNDROP -p udp -m limit --limit 32/min -j LOG --log-prefix "Denied UDP: " --log-level 7
-A LOGNDROP -p icmp -m limit --limit 32/min -j LOG --log-prefix "Denied ICMP: " --log-level 7
-A LOGNDROP -j DROP
COMMIT
#Remember to leave an extra space at the bottom

******* and save, then to check it is working
iptables -L

Viola :D

Edit- Credit to chaeplin for the far superior rules
Click to expand...

What should I see when I execute the iptables command below? I saved the rules you posted above.
iptables -L
 
edificio said:
Ah i see. Is there a way to make it reboot automatically if all system resources are suddenly being used up?

Is it likely that the attacker would immediately start DDoS'ing the server again after that reboot? Of course ufw or iptables is the better option - But it would be nice to know the server would just reboot and start dashd again, should an attack slip through
Click to expand...

No, rebooting will make it even worse because you will lose all existing, valid masternode connections. When rebooting, you will get, as before, immediately spammed with invalid connection attempts or garbage data up to the connection limit of the dashd, thus preventing connections from legitimate nodes.
The attack will usually not stop if the server turns out to be unreachable.

So limit the rate of connection attempts using a firewall and also limit the amount of new connections per IP and subnet as mentioned in the thread. One may also think about proper kernel configuration, such as usage of syn cookies, enabling of some checks, etc. This will squash a lot of invalid TCP connections, allowing the masternode to "breathe". A way larger attack (this current one only caused peak traffic at around 0.15 Mb/s at our nodes) will still either fill up your connection queue in the daemon or exhaust the server resources, even if packets get dropped at the local firewall. Thus, a DDoS mitigation service, as offered by many server providers, may help by blocking attacks before those packets reach your host (in addition to security measures on your server).
 
Sapereaude said:
...
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:LOGNDROP - [0:0]
:OUTPUT ACCEPT [0:0]
...
Click to expand...

The default behaviour for the INPUT chain is ACCEPT, which, at the end is redundantly repeated by the rule -A INPUT -i eth0 -p tcp -j ACCEPT

Basic invalid TCP packets are blocked, but you can still reach any other socket listening to the interface eth0 on any port. You can also flood any port other than 9999, which may cause a ton of half open connections on the host.

Also, I think this part, causing a jump to LOGNDROP will never be reached:
-A INPUT -j LOGNDROP
Why? Because A INPUT -i eth0 -p tcp -j ACCEPT at the end accepts any TCP packet on eth0 not matched by any rules above, and thus leaving the chain (if matched) and proceeding to the other tables (nat, etc.).

I would like to suggest, that you test your configuration before you simply trust a copy&paste solution.
 
You must log in or register to reply here.
Back
Top