Ongoing DDoS attack on masternode network

[lynx]

@camosoul votes IPv4/IPv6/Tor = 40/40/20
@UdjinM6 votes IPv4/IPv6/Tor = 100/0/0

What is your vote? Is this "All nodes must do it all" translated to 33.33/33.33/33.33 ?

My vote would be every node must support IPv4, IPv6 and Tor, or not get paid at all. And voting with numbers is bullshit.

 

[demo]

My vote would be every node must support IPv4, IPv6 and Tor, or not get paid at all.

So you consider IPv4, IPv6 and Tor as equal. So your vote is 33/33/33 although you are afraid to admit it.

 

[demo]

My vote would be every node must support IPv4, IPv6 and Tor, or not get paid at all. And voting with numbers is bullshit.

Of course voting with numbers is bullshit, in your case.
Your vote is not a simple number vote. It is a conditional number vote.

IF the node supports all protocols, THEN pay it 33/33/33 ELSE pay nothing

 

[lynx]

So you consider IPv4, IPv6 and Tor as equal. So your vote is 33/33/33 although you are afraid to admit it.

No, it's not. I consider every one of them a REQUIREMENT.

Of course voting with numbers is bullshit, in your case.
Your vote is not a simple number vote. It is a conditional number vote.

IF the node supports all protocols, THEN pay it 33/33/33 ELSE pay nothing

No. IF the node supports all protocols, THEN pay it 100 ELSE pay nothing.

 

[demo]

No, it's not. I consider every one of them a REQUIREMENT.

No. IF the node supports all protocols, THEN pay it 100 ELSE pay nothing.

You have just voted with numbers! 100 is a number, remember?

You should also take into account how the others express their number vote, in order to be able to extract a result. Thats why this 100 should be translated to the way the others are voting, which is in @camosoul's system the 33/33/33

So we have 3 votes until now:
@camosoul votes IPv4/IPv6/Tor = 40/40/20
@UdjinM6 votes IPv4/IPv6/Tor = 100/0/0
@lynx IF the node supports all protocols, THEN pay it 100 ELSE pay nothing

How can we extract a result from this vote? Do you want to decide something as a community, or you will fork to three pieces? This is were governance stands.

 

[lynx]

You have just voted with numbers! 100 is a number, remember?

You should also take into account how the others express their number vote, in order to be able to extract a result. Thats why this 100 should be translated to the way the others are voting, which is in @camosoul's system the 33/33/33

No, because it makes no sense. It could just as easily be translated to 0/0/100. Because the node will either get paid, or it won't.

 

[demo]

No, because it makes no sense. It could just as easily be translated to 0/0/100. Because the node will either get paid, or it won't.

0/0/100 in @camosoul's system means that you support only the Tor network. This is not the case. You didnt understand his system.

1. Camosoul pays 20 if someone supports only tor.
2. Camosoul pays 40 if someone supports only IPv4.
3. Camosoul pays 40 if someone supports only IPv6.
4. Udjinm6 pays 100 if someone supports only IPv4

You pay nothing in the above four cases.

1. Udjinm6 pays 0 if someone does not support IPv4.

You do the same in that case. So you have something in common with Udjinm6.

And the question is: Do you want to decide something as a community, or you will fork to three pieces? This is where governance stands. This is where vote with numbers, and conditional votes stands.

 

[lynx]

0/0/100 in @camosoul's system means that you support only the Tor network. This is not the case. You didnt understnad his system.

I understood his system. But my vote doesn't translate into that system, so I'm not using it.

So we have 3 votes until now:
@camosoul votes IPv4/IPv6/Tor = 40/40/20
@UdjinM6 votes IPv4/IPv6/Tor = 100/0/0
@lynx IF the node supports all protocols, THEN pay it 100 ELSE pay nothing

How can we extract a result from this vote? Do you want to decide something as a community, or you will fork to three pieces? This is were governance stands.

If we vote "Should masternodes be required to support all protocols? (yes/no)" there will be a clear decision one way or the other.

 

[demo]

I understood his system. But my vote doesn't translate into that system, so I'm not using it.


If we vote "Should masternodes be required to support all protocols? (yes/no)" there will be a clear decision one way or the other.

Yes of course, you can use interdependent polls.
But even in that case, you have to decide the selection process.

 

[lynx]

Yes of course, you can use interdependant polls.
But even in that case, you have to decide the selection process.

Stop hijacking the thread.

 

[demo]

Stop hijacking the thread.

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.

 

[lynx]

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.

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.

 

[demo]

I don't have to decide anything. Any one of us can make a proposal, and it will either pass or it won't.

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.

 

[demo]

And this is hijacking. We are discussing possible Dash improvements in regards to the DDoS attack, not general governance.

Thats exactly the problem. You only discuss and always discuss, but no decision is made.
Discussing is hijaking, deciding is not.

 

[lynx]

But does camosoul or udjinm6 agree with your proposed selection process?

Yes, they do.

 

[Dash4Ever]

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!

 

[rustycase]

I just watched a youtube video published on 6 March where Fluffypony from Monereo talks to Tone Vays about a DDoS attack on DASH.

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

 

[GrandMasterDash]

@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.

 

[TroyDASH]

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.

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.

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 --

 

[chaeplin]

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 --

Make sense, just accept tcp 9999 and drop icmp/udp/all other tcp.
Usually done by ips/ddos protection gear. But needs inside ntp/dns server.

 

[camosoul]

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)

#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.

 

[camosoul]

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

sudo apt-get install tor

ssh into, or use some form of console access, to access your server.

sudo nano /etc/tor/torrc

Find the section about tor hidden services. The samples look like this:

#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:

#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.

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:

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...

 

[vitaly]

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 )

 

[Balych]

I think in the future masternode operators can be able to afford to maintain a powerful dedicated server (with the eth0 interface ofcause )

https://www.online.net/en/dedicated-server/dedibox-xc for example

 

[camosoul]

I think in the future masternode operators can be able to afford to maintain a powerful dedicated server (with the eth0 interface ofcause )

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]

Why do you think MNs are more profitable than VPS?

 

[jimbursch]

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.

 

[aleix]

Why do you think MNs are more profitable than VPS?

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.

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.

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,

 

[cibrigue]

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

 

[cibrigue]

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:

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:

#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?