So you consider IPv4, IPv6 and Tor as equal. So your vote is 33/33/33 although you are afraid to admit it.My vote would be every node must support IPv4, IPv6 and Tor, or not get paid at all.
Of course voting with numbers is bullshit, in your case.My vote would be every node must support IPv4, IPv6 and Tor, or not get paid at all. And voting with numbers is bullshit.
No, it's not. I consider every one of them a REQUIREMENT.So you consider IPv4, IPv6 and Tor as equal. So your vote is 33/33/33 although you are afraid to admit it.
No. IF the node supports all protocols, THEN pay it 100 ELSE pay nothing.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
You have just voted with numbers! 100 is a number, remember?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?
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.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
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.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.
I understood his system. But my vote doesn't translate into that system, so I'm not using it.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.
If we vote "Should masternodes be required to support all protocols? (yes/no)" there will be a clear decision one way or the other.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.
Yes of course, you can use interdependent polls.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.
Stop hijacking the thread.Yes of course, you can use interdependant polls.
But even in that case, you have to decide the selection process.
This is not hijacking.Stop hijacking the thread.
I don't have to decide anything. Any one of us can make a proposal, and it will either pass or it won't.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.
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.I don't have to decide anything. Any one of us can make a proposal, and it will either pass or it won't.
Thats exactly the problem. You only discuss and always discuss, but no decision is made.And this is hijacking. We are discussing possible Dash improvements in regards to the DDoS attack, not general governance.
Yes, they do.But does camosoul or udjinm6 agree with your proposed selection process?
I doubt ricardo spagni would participate in such activity.I just watched a youtube video published on 6 March where Fluffypony from Monereo talks to Tone Vays about a DDoS attack on DASH.
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.
I'm interested if anyone is following up on these suggestions by @Figlmüller and @camosoul ?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.
Make sense, just accept tcp 9999 and drop icmp/udp/all other tcp.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 --
#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
sudo apt-get install tor
sudo nano /etc/tor/torrc
#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/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
sudo cat /var/lib/tor/ssh/hostname
16randomlettersandnumbers.onion
torify ssh [email protected]
https://www.online.net/en/dedicated-server/dedibox-xc for exampleI 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.I think in the future masternode operators can be able to afford to maintain a powerful dedicated server (with the eth0 interface ofcause)
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.Why do you think MNs are more profitable than VPS?
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).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.
sudo ufw limit ssh/tcp
sudo ufw limit 9999/tcp
#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