great discussions here
please keep the tips and suggestions coming
great learning curve for everybody involved
please keep the tips and suggestions coming
great learning curve for everybody involved
I would guess your are on ubuntu 14.04 and not 16.04invoke-rc.d: unknown initscript, /etc/init.d/netfilter-persistent not found.
You should see the rules you pasted in, it will be easier to see if you make the putty window bigger.What should I see when I execute the iptables command below? I saved the rules you posted above.
iptables -L
Crap yeah that's on me, I was modifying my original script by adding chaeplins better ddos rules and missed that. Removed the line.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.
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...you will get, as before, immediately spammed with invalid connection attempts or garbage data up to the connection limit of the dashd
Sorry to bother you again, but I checked your rules once again and stumbled upon the first rules:Crap yeah that's on me, I was modifying my original script by adding chaeplins better ddos rules and missed that. Removed the line.
Hey - please make sure to set the recommended IP tables too, that might be the cause and not the HW if you're on the recommended spec already: https://gist.github.com/chaeplin/5dabcef736f599f3bc64bdce7b62b817despite i had the requested hardware Dual Core CPU and 2 GB Ram i was kicked from the masternode list and lost 2 dash that i needed to get now !
Moving to Vultr $20 Quad CPU and 4GB RAM
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.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![]()
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.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?!
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?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.
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.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![]()
butFor 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
Are you on Ubuntu 16.04 or 14.04?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?
A ddoscoin is the reverse of the proof of bandwidth coins.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.
This. MNs should be Fort Knox, not Best Buy.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).
mn01 j2t1dn2aa7bc3kld.onion 93HaYBVUCYjEMeeH1Y4sBGLALQZE1Yc1K64xiqgX37tGBDQL8Xg 7603c20a05258c208b58b0a0d77603b9fc93d47cfa403035f87f3ce0af814566 0
Not again the same mistake! Magic numbers again?I'd even go so far as to suggest at 40/40/20 structure... No IPv4? You forfeit 40% of your MN payment. No IPv6? You forfeit 40% of your MN payment. No tor? You forfeit 20% of your MN payment.
The solution is to vote the number.It is very crucial to select randomly the IPbased and the anonymous new masternodes (according to the result of the appropriate poll that is always active, so that we can change the percentage of anonymous and IPbased new masternodes , according to the extend of the attack beeing made at the public dash network) because this randomness makes much more difficult the task of prohibiting the public dash network. The randomness can be calcutated using appropriate cryptographic protocols, among masternode owners.
The old mastenodes, as long as they are baptized and randomly toοκ their anonymous state, they can remain (or even they are forced to remain) anonymous for ever.
Yes.Is there a theory behind your proposed magic numbers?
That's brilliant! Not only we will be reachable by whatever protocol the user wants, we will have a much stronger, sturdier network.Let me add on a little more...
Require MNs to run EVERYTHING, not restrict to IPv4.
Are you kidding me? Exact numbers is very very important!2) Exact numbers are not that important.
The point is to punish lack of protocol support proportionally. Lack of IPv4/IPv6 is much worse than lack of Tor. It's also a lot easier, so there is no excuse NOT to do it. Thus, harsher punishment for being an obnoxiously lazy/stupid MNO. The desired outcome is boolean, so it doesn't have to have precision proportionality. "Whip them hard enough that they set it up properly." If 10% gets the job done, then so will 20%. Tor is a bit tougher. 20% is more of a "penalty I pay for not figuring it out yet, but I will because I want my 20% back!" 20% is more of a tax on being stupid. 40% is a true punitive measure for outright unacceptable behavior. Since 100% is the biggest number I have to work with... 40 + 40 + 20 = 100. It works out as intended. Lacking IPv4/IPv6 is outright unacceptable. Lack of Tor can be tolerated, but harshly discouraged.
As you can see in the above quote, I understood that 40+40+20 equals 100 as long as my new numbers 39+41+20 were also equal to 100.Not again the same mistake! Magic numbers again?
Why 40/40/20 and not 39/41/20?
Additionaly (and exactly because Tor is not a true transport layer which is a disadvantage) the Dash community should invest in bandwidth coins that are produced in independant wireless (wifi or optical) networks. At these networks there is a total control up to the physical transport layer and these networks cannot be easily controled by the state (especially the wireless optical networks are hard to discover).1) Tor is not a true transport layer. It's just being treated like one by the proposed "superlayer" concept. Lack of tor should be punished less severely than lack of true TCP.
Thats not brilliant, that is stupid.That's brilliant! Not only we will be reachable by whatever protocol the user wants, we will have a much stronger, sturdier network.
Also, should any jurisdiction try to ban the use of Dash, it will be immediately circumventable. That option alone will serve as a deterring factor...
@camosoul votes IPv4/IPv6/Tor = 40/40/20@demo
No, your "solution" is the one that is needlessly complex.
All nodes must do it all, and all wallets and backend services must support all connection types. That way we have a real bulletproof fail-safe for, well, anything short of turning the internet off.