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.
great discussions here please keep the tips and suggestions coming great learning curve for everybody involved
You should see the rules you pasted in, it will be easier to see if you make the putty window bigger.
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 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
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?!
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/5dabcef736f599f3bc64bdce7b62b817
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
Well , i upgraded already , this is my donation to the DASH Network... still i will setup IPTABLES as you recommended Thanks Andy !
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
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
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
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?
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?
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 A ddoscoin is the reverse of the proof of bandwidth coins. Ddoscoin is the virus, and PoW coins (like Torcoin) is the antivirus.
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."
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.
Let me add on a little more... tor exit nodes may be a contended point of observation, but tor's internal hidden service rendezvous mechanism is pretty damned cool. I am very disappointed to see the electrum-dash .onion server was taken down for exactly this reason. I believe DASH should be integrating tor directly into the infrastructure, not just having proxy settings in the client. masternode.conf should look like this: Code: mn01 j2t1dn2aa7bc3kld.onion 93HaYBVUCYjEMeeH1Y4sBGLALQZE1Yc1K64xiqgX37tGBDQL8Xg 7603c20a05258c208b58b0a0d77603b9fc93d47cfa403035f87f3ce0af814566 0 But, you say... This would make the nodes unreachable to "normal" clients. IPv4, IPv6, and Tor all need to be required on MNs so that clients can do as they please, or not. There is no need to create DASH's own obfuscation network. tor already exists. All of the arguments against it relate to exit nodes. As for acceptance into the iStore and other similar ramifications; tough cookies. Tor could/would simply be another supported protocol. No different from https. Modularity; make a no-tor version for China. MNs can bridge. I've done it effectively on 12.0 via my IPv6 experiments. No, it doesn't result in fragmentation and islanding. You end up with contiguous layers that route through vertical bridge columns. Your single-protocol observation point makes it look like islands and fragmentation. But, if your observe from both sides it becomes clear that IPv4 looks fragmented from the IPv6 side, and the IPv6 looks fragmented from the IPv4 side, because the view is limited to the bridge points. For a little more info on my research... I ran several dozen MNs. They were all bound to their IPv6, this is the key. I don't think the code was written intentionally to look this way, but it would prioritize IPv6, and still communicate by any other option available. 3 of the MNs were dual stacked, and they acted as a bridge to the remaining IPv6 nodes. In a small network, this seems isolated. But, they're not actually isolated because they were not the only IPv6 nodes out there. And those other IPv6 nodes were often dual-stacked bridges as well. So, what looks like islands from an IPv4 observer's perspective, was really just entry points to an entirely contiguous layer. If DASH implemented a deliberate "tunnelling" layer... It could solve several incompatibility problems at the same time. There needs to be a network identifier that is not tied to the network address. If a node finds that it has only IPv4 available, it still keeps track of all the IPv6 and .onion nodes that are shown to it, and it does not limit itself to same-protocol nodes. It tunnels by requesting through-nodes that support multiple protocols. From a sterile perspective, one might conclude that that this creates bottlenecks and constricted points of failure. But, it's more organic than that. We're not looking at 200 nodes. We're looking at 4000. This DDos is a perfect example. How are you going to coordinate a 3-protocol DDos? I'm not saying it's impossible, but what's really happening here is a deliberate increase in attack surface. You're creating a thing that needs to be attacked in so many ways at once that you just can't. Instead of reduicing points of entry, give them so many requirements for an attack that it's too hard to do. If you can flood out the IPv6 nodes, the IPv4s are a perpetual backup. If you flood out the .onions, the IPv6 and IPv4 are still there... And most of them are multiple protocol. Instead of having only one way to spiderweb, have 2 or 3. We shouldn't be looking at the "IPv6 fragmentation" as a problem because it's not really fragmentation. There was actually a complete functional ecosystem of IPv6 exactly like the IPv4. It simply communicated through limited IPv4 tunnels that looked like islands from the single-side perspective. If you required both and included a tunneling layer... Suddenly it's not just IP-layer routing. Instead of just distributing data shards on dashdrive, you can distribute the protocol itself across multiple transport layer types. Cloud protocol. Tor is not technically the same type of transport layer, but you could treat it as if it were by creating your own "superlayer." This lesson teaches us that DASH needs to be multi-protocol, and the layer for accomplishing that could accommodate tor's hidden service rendezvous system just the same. A token ring IPSEC hybrid. Require MNs to run EVERYTHING, not restrict to IPv4. Most ISPs that have a problem with tor, have a problem with exit nodes. Rarely do they care about hidden services, or even have a way to detect it. Most even have no problem with relays and bridges. And the best part: most of these tor-aware ISPs accept cryptocurrency for the same reasons they support tor. This creates a MN network that naturally gravitates towards the most suited ISPs and the most capable MN Operators. The end-user network is transparent to the layer. Use whatever you can and the MNs bridge you to the whole thing. Does eth0 have IPv4 and does it ping known addresses? Yes: use it. No: PoService penalty Does eth0 have IPv6 and does it ping known addresses? Yes: use it. No: PoService penalty Can we torify and reach known .onions? Yes: use it. No: PoService penalty 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. This penalty structure also incentivizes LEARNING; hte most important part, and the reason this DDoS did anything at all... MNOs need to become better admins. Right now, MNOs are mostly ex-miners who treat it like a bare-minimum effort fire-and-forget money hose. They make no effort to do the job properly. The costs to a middle-man service are going to increase to the point that they'll be taking 50% or more of your MN payments. Time to use your brain to get your money back; grow up and take care of it yourself, like a responsible adult. Node babysitting services may even outright refuse to support tor due to their bulk nature preventing them from being flexible, forfeiting 20% up front. Those node services also have the power to downvote such a change without even submitting a proposal... Greed and Power. MNs are reaching a point that they need to carry these burdens to give the client more options. This is how the privacy concepts of tor and cryptocurrency finally become a unified theory. If you're running a hidden service anyway, may as well be a relay node, too. there's your white noise for both sides. Tor would finally have incentivized pipes, and true science and analysis could be done on a meaningful scale that benefits both. Take safenet and distributed markets as an example. these are closed ecosystems that came about as a result of echo chambers. Couldn't reach the outside market, so they created their own internal market to make it look like a thing that matters when it still doesn't. Crypto projects always seem to turn in on themselves because they fail to do what is needed to include the outside world. I do not disagree with DASH's facebook-of-crypto features. I'm saying that you're building the roof before the foundation. You have to start at the bottom and work up, or you end up with re-engineering that is prohibitive, and you're stuck with limitations of a poorly-conceived legacy foundation. Wasn't the whole point of Evolution to re-engineer the mess? You're making the same mistake, again. I'm not saying it would be easy. I realize some of the hurdles needing be overcome are quite large. Did you get this far by doing the easy thing? This is why I respect the coding side of DASH, but not the "business" side. The coders are busting their ass while the "biz devs" fiddle fuck around looking busy with fluff and pork, laughing all the way to the bank... The irony. The worry of maintaining BTC backwards compatibility is holding you back in many areas. There's no reason to keep treating it as mandatory. If you want to do something better than BTC, you're going to have to break from it. The supposed advantage only exists inside the cryptosphere bubble. But that's the very problem. The whole point is to go outside of that bubble. Outside of the cryptosphere bubble, there is no BTC infrastructure to be compatible with. There's no need to be backwards compatible with something that functionally does not exist on the road you are traveling. If you are a leader, act like it. Stop deferring to something else that can't get traction for very good reasons. Stop holding on to those reasons. Bitclones have an ecosystem of support systems around them due to lack of feature set. An infection growing in an open wound is not a good thing no matter how well you word it... "Organic ecosystem" is just another way of saying "even more middle-man scum fixing all the it's-a-feature-not-a-bug problems; for a price." It's worse than Visa out there... Bitclones' arrogant refusal to adapt have made crypto into the worst option. Don't imitate it by deferring to it. If you want to lead, act like it.
Not again the same mistake! Magic numbers again? Why 40/40/20 and not 39/41/20? Is there a theory behind your proposed magic numbers? If not, then you are simply wrong. The 40/40/20 is not a solution, the solution is this. I have already told you the truth for the very beginning, but you refuse to accept it. The solution is to vote the number.
If you were able to understand the content of the post, then the question answered itself. Yes. But, the post was long enough already, and anyone who can understand the post can understand why. 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. 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. If I had my way, a lack of any of those 3 would result in removal from the MN list; no more payments at all. But snowflakes can't handle something that harsh. Lets whip them only hard enough... If you were looking for the understanding, instead of looking for a thing to troll about and post back to your silly vote with numbers crap, you would have understood and not asked such a stupid question. The beatings will continue until morale improves! This is the law of nature. Your situation will not improve until you do.
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...
Are you kidding me? Exact numbers is very very important! Unless you think that 98/1/1 is the same as 1/1/98. 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. And you may believe that the correct is 40/40/20 but @UdjinM6 believes that only IP4 is suitable and he votes 100/0/0. Why are you right, and why he is wrong? Exact numbers matter and are very very important. My point is that each masternode should SPECIALIZE in a network type and you should not expect for EVERY masternode to have both IP4 and IP6 and tor and whatever else network type will be available. And you should have some nodes that will behave as gateways.
You quotes are usefull, but you are usally wrong. But the below quote is right. 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).
Thats not brilliant, that is stupid. Every masternode should speciallize in a network type, and you should not expect every masternode to have all the network types. This will turn masternodes very heavy, and very hard to maintain. Kiss (keep it simple, stupid!) I had proposed that every new masternode should be randomly baptized by the protocol to serve a specific network type, and that some masternodes should be randomly baptized to behave as the gateways between two (or more) different network types. And I insist that this is the correct solution.
