Ongoing DDoS attack on masternode network

Figlmüller said:
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.
Click to expand...

Crap yeah that's on me, I was modifying my original script by adding chaeplins better ddos rules and missed that. Removed the line.
 
Figlmüller said:
...you will get, as before, immediately spammed with invalid connection attempts or garbage data up to the connection limit of the dashd
Click to expand...

Hey Figl, do you recommend setting a low maxconnections setting in dash.conf or high? I have it on maxconnections=64 and some of my nodes went down even with good specs. Maybe better to set a lower value? Thanks for spreading the knowledge :)
 
Sapereaude said:
Crap yeah that's on me, I was modifying my original script by adding chaeplins better ddos rules and missed that. Removed the line.
Click to expand...

Sorry to bother you again, but I checked your rules once again and stumbled upon the first rules:

-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

It's already late here in central Europe, I'm dead tired and I might be wrong. But aren't those lines instantaneously rejecting any kind of UDP packets, followed by TCP packets, and finally rejecting ALL packets with a protocol unreachable icmp packet - thus effectively preventing all kinds of connections?!
 
Cofresí said:
Hey Figl, do you recommend setting a low maxconnections setting in dash.conf or high? I have it on maxconnections=64 and some of my nodes went down even with good specs. Maybe better to set a lower value? Thanks for spreading the knowledge :)
Click to expand...

I'm running all nodes at a limit of 256 connections. Depending on the kind of attack and measures taken to stop packets reaching the listening application, it still may be not enough. I don't really know the impact of allowing 256 connections on a dash node regarding memory allocation/usage and CPU load caused by the operating system or the daemon. Neither I know the effects on the networking stack in that case.

What I know, is that during the current attacks, I had 30-40 connections or connection attempts at a time on the affected machines using rate limiting and other measures. Temporarily disabling those measures (for science :) ) ended up in hitting the limit of 256 within seconds. I did not analyze the attacks and packets sent in detail, but I noticed a significant growth of used memory on the host. I did not check whether this was caused by the networking stack (Kernel) or the daemon (processing bogus data?! memory allocation for clients?!...), as I switched the firewall(s) back on after that.

I could not find any information whether the daemon itself is hardened against bogus input, and if so, how. Digging into the code isn't something I would like to do right now :)
 
Last edited:
Figlmüller said:
Sorry to bother you again, but I checked your rules once again and stumbled upon the first rules:

-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

It's already late here in central Europe, I'm dead tired and I might be wrong. But aren't those lines instantaneously rejecting any kind of UDP packets, followed by TCP packets, and finally rejecting ALL packets with a protocol unreachable icmp packet - thus effectively preventing all kinds of connections?!
Click to expand...

The next line down over-ruled that for connections on 9999 and then the next chain is chaeplin's new rules that handle the ddos, which seemed confirmed since my nodes are active and getting payed. Unless mine are an example of lazy masternodes, I am changing the rules on one of my nodes and will monitor the cpu usage.

Edited
 
Last edited:
Sapereaude said:
I think the next line over-ruled that for connections on 9999, which seemed confirmed since my nodes are active and getting payed. Unless mine are now an example of lazy masternodes, I am changing the rules on one of my nodes and will monitor the cpu usage.
Click to expand...

Correct me if 'm wrong, but already established connections should not be affected because of -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT before the mentioned lines, which may include existing masternode connections. At least as I understand it, you should not be able to establish any kind of (new) connection to a server using that iptables configuration. Did you try to SSH (new connection) into a server using that iptables config?
Maybe I'm failing to see something obvious and maybe I'm totally wrong. Will check back later, after some sleep :)
 
Figlmüller said:
Correct me if 'm wrong, but already established connections should not be affected because of -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT before the mentioned lines, which may include existing masternode connections. At least as I understand it, you should not be able to establish any kind of (new) connection to a server using that iptables configuration. Did you try to SSH (new connection) into a server using that iptables config?
Maybe I'm failing to see something obvious and maybe I'm totally wrong. Will check back later, after some sleep :)
Click to expand...

Yes that's true, but those are the rules I used as I was setting up my masternodes, so there were no connections to continue then and I can still ssh into them. As I understand it all connections run through all the rules in Iptables only those not changed by the following rules would remain rejected.

Sleep well mate, I'll recheck everything just to be sure
 
Last edited:
hi,
i try to set the iptables following tease intructions:


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, Note- change port 22 if you moved ssh to another port.
: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
-A INPUT -p tcp -m tcp --dport 9999 -j ACCEPT
# 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 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
Click to expand...

but
invoke-rc.d netfilter-persistent save
returns error
invoke-rc.d: unknown initscript, /etc/init.d/netfilter-persistent not found.

Did I miss something?
 
olymp said:
hi,
i try to set the iptables following tease intructions:




but
invoke-rc.d netfilter-persistent save
returns error
invoke-rc.d: unknown initscript, /etc/init.d/netfilter-persistent not found.

Did I miss something?
Click to expand...

Are you on Ubuntu 16.04 or 14.04?
 
on 16.04.2 # invoke-rc.d netfilter-persistent save fails for me:

# invoke-rc.d netfilter-persistent save
* Saving netfilter rules...
run-parts: executing /usr/share/netfilter-persistent/plugins.d/15-ip4tables save
run-parts: /usr/share/netfilter-persistent/plugins.d/15-ip4tables exited with return code 1
run-parts: executing /usr/share/netfilter-persistent/plugins.d/25-ip6tables save
run-parts: /usr/share/netfilter-persistent/plugins.d/25-ip6tables exited with return code 1
[fail]

solved forgot sudo ;)

iptables -L gives me
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Is that ok?
 
Last edited:
Some toughts I would like to add to the suggested ruleset by chaeplin:

The default policy on the INPUT chain there is ACCEPT. Going through the firewall will, as expected, reduce the impact of the current attacks. So far so good. But the firewall will still allow connections to any listening socket on the host, because the approach is to accept all packets, but drop/reject unwanted ones (blacklist). Although this approach will less likely disrupt other services or lock out operators from their machines and is more suitable for less tech-savvy admins just deploying the rules, I am more a supporter of a whitelisting approach. In my opinion it would be better to DROP by default, and only ACCEPT if the right conditions are met. You will then have to explicitly allow traffic to the services (without locking yourself out of course). This also includes UDP traffic used for DNS (answers to DNS requests), for example. More checks and rules will be needed, but the overall security will improve in my opinion, as the suggested configuration by chaeplin will not protect against attacks related to DNS, ICMP and other ones, or will not hide/restrict other listening services. Still, the rules by chaeplin are very useful regarding the current attack situation.
 
Buy it. Its a bargain!
https://github.com/ewust/DDoSCoin

DDoSCoin
DDoSCoin is a conceptual cryptocurrency with an "evil" proof-of-work. Rather than use a hash-based proof-of-work like Bitcoin, DDoSCoin allows miners to prove that they have contributed to a Distributed Denial of Service (DDoS) against a specific target.
Click to expand...

A ddoscoin is the reverse of the proof of bandwidth coins.
Ddoscoin is the virus, and PoW coins (like Torcoin) is the antivirus.
 
Last edited:
And what is the moral of this DDos attack?
You are 4000 representatives of the generation 2014-2016 and you hold most the dash for yourself.
In case the future generations will be pissed off from your richness , you have no hope.
People who do not own dash (due to its designed time-space assymetry) are more than 4000, they are almost 7000000000 (the earth population).
Imagine a DDos from 700000000 IPs and calculate your chance to survive.
Unless of course you ask the help of the state to protect you.
But if you are asking the protection of the state, then you belong to the state, and you cannot avoid the state's rules (to respect the state's money, to respect the holders of that money, and to pay the taxes of course!)
Because with those taxes, the state is capable to protect the 4000 dash masternode owners from the DDOs attack of the rest 7 billion people (who do not own a single dash-duff). Are you listening @camosoul?

"War is the father and king of all: some he has made gods, and some men; some slaves and some free."
 
Last edited:
Figlmüller said:
I am more a supporter of a whitelisting approach. In my opinion it would be better to DROP by default, and only ACCEPT if the right conditions are met. You will then have to explicitly allow traffic to the services (without locking yourself out of course).
Click to expand...
This. MNs should be Fort Knox, not Best Buy.

How about a more "hardcore" ruleset script?

There shouldn't be anything but dashd, sentinel, and immediate supporting services. Dashd is no longer a side service on a machine doing 100 other things.It pays enough to grow up and take it seriously with dedicated resources. Only ports 9999 and a non-standard SSH port should even be awake. Everything else should blackhole. Not even ICMP response. Masternodes have much better and more useful means of event failure notification. As a dedicated dashd node, it doesn't need to ping.

You can get even better by running tor, and routing ssh to a hidden service that only listens after a port knock. You can't DDoS a port you can't find. 9999 is still exposed, but iptables can do a hell of a job focusing for dashd specific traffic with a ban-all-then-add-whitelist mentality.

The only way to improve upon that would be to dump ubuntu for gentoo and run hardened.

MNs need to become a much more serious matter, and an iptables plan that permits only whitelist is it.
 
Last edited:
You must log in or register to reply here.
Back
Top