• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

Ongoing DDoS attack on masternode network

lynx said:
Stop hijacking the thread.
Click to expand...

This is not hijacking.
This is governance.
You are three people here: you, udjinm6 and camosoul and eachone proposes different solutions in order to solve the DDOS problem.
You have to decide a selection process in order to be able to decide what to do.
Otherwise you will fork and split to 3 parts.
 
demo said:
This is not hijacking.
This is governance.
You are three people here: you, udjinm6 and camosoul and eachone proposes different solutions in order to solve the DDOS problem.
You have to decide a selection process in order to be able to decide what to do.
Otherwise you will fork and split to 3 parts.
Click to expand...
I don't have to decide anything. Any one of us can make a proposal, and it will either pass or it won't.
And this is hijacking. We are discussing possible Dash improvements in regards to the DDoS attack, not general governance.
 
lynx said:
I don't have to decide anything. Any one of us can make a proposal, and it will either pass or it won't.
Click to expand...
Of course you have to decide something. You have just decided what your favorite selection process is. You have also described this selection process."Make proposals, vote yes/no and the most voted one wins". This is a selection process, this is a method to decide.

But does camosoul or udjinm6 agree with your proposed selection process?
If they do not agree with your proposed selection process, then you will spit in three parts.
This is again where governance stands, trying to find a common way in order to decide the selection process.
 
lynx said:
And this is hijacking. We are discussing possible Dash improvements in regards to the DDoS attack, not general governance.
Click to expand...
Thats exactly the problem. You only discuss and always discuss, but no decision is made.
Discussing is hijaking, deciding is not.
 
Lots of great talking here! Feels like the security of the network is taken to the next level!
Can any one just clarify for me what do to with Ubuntu 15.04 ? Just wanna make sure I got everything right!

Keep on Dashing!
 
halso said:
I just watched a youtube video published on 6 March where Fluffypony from Monereo talks to Tone Vays about a DDoS attack on DASH.
Click to expand...
I doubt ricardo spagni would participate in such activity.
He will readily admit to being an active troll, yet that is far different than maliciously hacking.
His clan seems to be most interested in a grass roots effort at fully implementing the Cryptonote anon feature for their coin.
At times it does seem the supporters are rabid.
rc
 
@demo I think all they're saying is, MNs should be neutral regarding the connection type, in the same way your existing stack continues to work when you enable a VPN etc. I think they're just saying MNOs decide the route(s).

Regarding the magic numbers, I agree, however, I'm also thinking this issue will be addressed in the future being Evan has escalated the decentralisation of sporks.
 
Figlmüller said:
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.
Click to expand...

camosoul said:
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.
Click to expand...

I'm interested if anyone is following up on these suggestions by @Figlmüller and @camosoul ?
I don't have the tech knowledge needed to contribute to an even more hardened set of rules but you've sold me on the concept --
 
BONED: Blocked from accessing your own server if SSH is your only way in.

I'm actually starting a new set of rules, but for those who want to "fort knox" their machines and need a starting clue, this will do:

This is my "setupiptables.sh" (chmod 764)
Code: 
#FLUSHES ALL CURRENT RULES
#DANGER: IF YOU ALREADY HAVE INPUT SET TO DROP BY DEFAULT, THIS WILL BONE YOU IF SOMETHING FAILS BEFORE THE HOLES ARE POKED IN IT!
#IT WILL RESULT IN ALL INCOMING TRAFFIC BEING BLOCKED.
sudo iptables -F

#ALLOW LOOPBACK TO DO ALL THE STUFFS
#YOU NEED THIS.
#THIS INCLUDES SOME DASHD COMMS.
sudo iptables -A INPUT -i lo -j ACCEPT

#ALLOW INCOMING CONNECTIONS TO GET IN IF THEY RESULT FROM AN OUTGOING REQUEST [RELATED]
#ALLOW ALREADY ESTABLISHED CONNECTIONS TO PERSIST AS WE DO THESE STUFFS [ESTABLISHED]
#I DROP THE ",ESTABLISHED" BECAUSE REASONS. YOU MIGHT NOT WANT TO, IT COULD BONE YOU.
sudo iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

#ALLOW STANDARD SSH PORT
#NOTICE THAT I HAVE THIS COMMENTED
#YOU WILL ALMOST CERTAINLY HAVE TO UN-COMMENT THIS LINE OR YOU *WILL* GET BONED!
#sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT

#ALLOW DASHD TO DO IT'S THING
sudo iptables -A INPUT -p tcp --dport 9999 -j ACCEPT

#THIS IS THE BONE-ALL COMMAND.
#THIS SETS DEFAULT INPUT POLICY TO DROP.
#READ THE SECOND LINE OF THIS FILE AGAIN.
sudo iptables -P INPUT DROP

#VERBOSE LISTING OF THE RULES SET SO FAR.
#PERUSE FOR CORRECTNESS/SANITY.
sudo iptables -L -v

#I COMMENT AND UN-COMMENT THE FOLLOWING AS I SEE FIT FOR FOOLING AROUND.

#SAVES THE EXISTING RULES
#sudo sh -c "iptables-save > /etc/iptables.rules"

#APPENDS A LINE TO THE END OF /etc/network/interfaces THAT RESTORES THE RULES WE JUST SAVED, AT BOOT TIME
#SAVES ME FROM WRITING IT
#sudo sh -c 'echo "pre-up iptables-restore < /etc/iptables.rules" >> /etc/network/interfaces'

#OPENS /etc/network/interfaces IN AMATEUR EDITOR THAT I LIKE SO I CAN MAKE THE INDENT MATCH OR FIX ANYTHING
#sudo nano /etc/network/interfaces
With these rules in effect, you can't even PING the server. You'll receive ICMP responses to your own PING attempts as a result of the [RELATED] line. This is also what allows you to wget and pull updates and such. Even your own requests to outside resources would be blocked from getting in without this.

The [RELATED] rule works automatically for people who leave port 22/SSH blocked, and use tor hidden services for ssh. With that setup, the only actively listening port is DASHD on 9999. Everything else is black-holed. DASHD ONLY. No one can even attempt SSH login unless they have the .onion address because the only interface receiving traffic on port 22 is lo.

I consider it a bonus that all logins now occur from 127.0.0.1. Your own server isn't spying on you anymore.

One could explicitly alter SSHD's bind/listen interface, but it would be redundant and just another thing you would have to undo if you needed to SSH directly. Simply leaving it blocked is just as effective and easier to revert if needed.

The new ruleset may not change from this. I'm working on modifying fail2ban's config instead of getting crazy complex in explicit iptables settings.
 
Last edited:
tor ssh

It's actually really simple.

I won't cover Windows/Apple/Android because that's like a screen door on a submarine...

install tor on both machines
Code: 
sudo apt-get install tor
ssh into, or use some form of console access, to access your server.
Code: 
sudo nano /etc/tor/torrc
Find the section about tor hidden services. The samples look like this:
Code: 
#HiddenServiceDir /var/lib/tor/hidden_service/
#HiddenServicePort 80 127.0.0.1:80

#HiddenServiceDir /var/lib/tor/other_hidden_service/
#HiddenServicePort 80 127.0.0.1:80
#HiddenServicePort 22 127.0.0.1:22
Add your own line underneath these so that it looks like this:
Code: 
#HiddenServiceDir /var/lib/tor/hidden_service/
#HiddenServicePort 80 127.0.0.1:80

#HiddenServiceDir /var/lib/tor/other_hidden_service/
#HiddenServicePort 80 127.0.0.1:80
#HiddenServicePort 22 127.0.0.1:22

HiddenServiceDir /var/lib/tor/ssh/
HiddenServicePort 22 127.0.0.1:22
The next time tor (you can just reboot the machine) starts, it will create the hash and .onion address for you. You should keep port 22 open until you have that.

This is how you get your .onion address.
Code: 
sudo cat /var/lib/tor/ssh/hostname
16randomlettersandnumbers.onion
You can now close port 22 (comment it out of the above iptables rules and re-run the script) and reboot for good measure.

It is your only way into the server other than some kind of console. If you have no console, this is now the only way in. Period.

Now, to ssh into the machine:
Code: 
torify ssh [email protected]
No one can even brute force your ssh now. They can't even get to a login without the .onion address. Can't spam it or use it as a DDoS port because it isn't one.

For those dumbass trolls that missed the point; I don't care if this obfuscates or not. Your tor hate is irrelevant. This isn't about obfuscation of the connection. That's just a convenient side-effect.

You could set up a low-pipe relay in tor for mutually beneficial white noise, but that's outside the scope of my brief, amateur-ish tutorial.

You can torify a lot of things (I was especially pleased to see it work with @chaeplin's dashmnb script), but the official dash download is actually blocking tor exit nodes. Same goes with a lot of repositories...
 
Last edited:
some point

VPS may not have eth0 interface but venet0:0 as rule (ifconfig will show)

in that case delete all '-i eth0'

I think in the future masternode operators can be able to afford to maintain a powerful dedicated server (with the eth0 interface ofcause :))
 
vitaly said:
I think in the future masternode operators can be able to afford to maintain a powerful dedicated server (with the eth0 interface ofcause :))
Click to expand...
Present reality is that is it already cheaper to run MNs on a dedicated box if you have more than 2x MNs to run. If you hold more than 2000 DASH, it's a no-brainer to bust out the proxmox.

You can rent an older 8GB single-socket system for about $30/mo. That'll easily run 4x MNs for less than the cost of individual VPSes of lower spec. It would be very healthy for the network if people started diversifying like this (instead of mobbing the VPS services or MN services), and more profitable.
 
AnythingDigital said:
Why do you think MNs are more profitable than VPS?
Click to expand...

Please open a new thread with your question or join the multiple threads we have with the same topic. This is not the right place.

jimbursch said:
The post above is very inappropriate because it raises this thread as if the ddos attack has resumed. This thread should be closed so that knuckleheads can't do this.
Click to expand...

I'm not closing the thread. This topic can be discussed in the future. The attack was a relevant issue and posting off topic replies by newbies is not reason enough to close an open discussion (just IMO).

best,
 
Thank you @camosoul for the script and the tutorial!

I've found two misspellings in the setupiptables.sh:
line 14: sudo iptables -A INPUT -m commtrack --ctstate RELATED,ESTABLISHED -j ACCEPT #commtrack -> conntrack
line 27: sudo iptables -P INPUT DROP. #DROP. -> DROP

And a few notes for novices like me who use Windows too:
* if you happen to use a Windows editor to create/edit the script file, make sure that you save it with Unix line endings, otherwise you will get "$'\r': command not found" error while running the script on Linux
* if you use the Tor Browser bundle, you must start the Tor Browser in order to start the Tor proxy which is needed to make the .onion addresses work with PuTTY
* in PuTTY, you need to set up the proxy with the following parameters: SOCKS5, 127.0.0.1, port 9150
* you need to use your .onion address in PuTTY, the IP address will not work
* if you can't connect, don't panic, just ask for a new identity in the Tor Browser and try to connect again a few times
 
As suggested in a previous post, connection rate limiting is a good protection against DDoS attacks for masternodes.

UFW supports rate limiting, and it's relatively easy to use:
http://manpages.ubuntu.com/manpages/precise/en/man8/ufw.8.html

To limit the SSH and Dash daemon ports:
Code: 
sudo ufw limit ssh/tcp  
sudo ufw limit 9999/tcp

If you use the more secure white-list approach, you probably don't even have UFW installed, so you need to set the values in your iptables. If you hid your SSH port as @camosoul suggested, you only need to worry about your public Dash port.
I would recommend to change camosoul's setupiptables.sh script slightly at line 22 to add rate limiting:
Code: 
#ALLOW DASHD TO DO IT'S THING
sudo iptables -A INPUT -p tcp --dport 9999 -m state --state NEW -m recent --set          # the IP address of the host which initiated the connection will be added to the "recent list"
sudo iptables -A INPUT -p tcp --dport 9999 -m state --state NEW -m recent --update --seconds 30 --hitcount 6 -j DROP    # the IP address is only going to match if the last connection was within the timeframe (30s) given and the given count of connection attempts is greater than or equal to the number given (6)
sudo iptables -A INPUT -p tcp --dport 9999 -j ACCEPT # otherwise accept it
(I used the https://debian-administration.org/article/187/Using_iptables_to_rate-limit_incoming_connections article to make the change. Here is the documentation of the recent patch of iptables, which makes this thing happen. I'm not an iptables/linux expert, so could someone more experienced confirm that this really works as intended?)

We also have more flexibility this way, because you can increase the acceptable rate if the ecosystem requires it. To be fair, ufw also allows you to change those parameters.

My questions are:
Are the values above (max. 6 attempts in 30 seconds) good for now?
Does it affect the amount of work a masternode can do?
Can we expect these numbers to change when the Dash network gets higher traffic?
 
Last edited:
You must log in or register to reply here.
Back
Top