Hacker News new | comments | show | ask | jobs | submit login

You commented on two points:

A) ip spoofing B) netflow

On IP spoofing I said plenty already https://idea.popcount.org/2016-09-20-strange-loop---ip-spoof... . There are two major points:

- We will always have DDoS vulnerable UDP protocols. In past we had DNS. Then we had NTP. Now we have SSDP. The next one is going to be some gaming protocol. We should fix them as we go, but a more comprehensive solution it to actually fight the spoofing.

- Even without using amplification, with IP spoofing it's possible to launch a direct attack, which will be untraceable. We regularly see 150Mpps+ packet floods going _direct_ from the attackers to our servers. The ISP's are clueless. There is no way for anyone to trace the true source of the attack. (without netflow, that is)

This brings us to second point - netflow. You say - the ISP's are incompetent, they do not have netflow and this is _good_. No it's not good. The ISP's can track you / deanonymize anyway, but when I ask them: "hey guys, I see this 150Mpps flood from your network, can you do something about it?" they say - "no, we can't identify the source because the IP's are spoofed". Yes, I herby recommend that each of the ISP's should take care of their network. Be able to answer historical questions about DDoS. That means the netflow collection point will have statistical metadata about customer connections (1 in 64k connections will have saved data - source port/ip, dest port/ip, length, packets, bytes). This might be used to attack your privacy - but the ISP can do much worse things anyway. Doing netflow right will allow us to finally trace the IP spoofing.

I really think that DDoS is a threat to the internet as we know it. Think about centralization that it causes: can your server sustain trivial 100Gbps SSDP attack? I really think that doing netflow right will allow us to keep the decentralized internet.




> We should fix them as we go, but a more comprehensive solution it to actually fight the spoofing.

The problem is that the Internet as designed simply supports this, and you can't fix it unless you fix the entire Internet at once; this problem is harder and less realistic to fix than any other place to poke at the problem, specifically due to the entire nature of the attack: it is an amplification attack... so I only need to find--somewhere, anywhere--a smattering of Internet that still supports spoofing, and use that to launch my attack.

> The ISP's can track you / deanonymize anyway...

They can, yes; the question is how much they do and if they should: I believe that it should be illegal for them to do this, and in a more perfect world on a more perfect network I believe it should be impossible for them to do this. The idea that you seriously think that not only is it OK that they do this but that they actively should do more of it, in all honesty, sickens me: we should be striving for a world where the list of reasons an ISP "should" track you--the list of reasons people feel they have to--is empty.

> That means the netflow collection point will have statistical metadata about customer connections (1 in 64k connections will have saved data - source port/ip, dest port/ip, length, packets, bytes).

No: that's not what this article says, and that's not how NetFlow works. You are proposing logging 1 out of every 64k packets, not 1 out of every 64k connections. Connections are made up of multiple packets--at least 4--and are sometimes made up of many many packets (the average I read was ~100 packets per connection, though I'm sure that falls into some inverse power loaw). So you are logging way more connections than 1 out of every 64k, and there are known attacks even on networks like Tor that are based on having this NetFlow data to correlate connections.

> Think about centralization that it causes: can your server sustain trivial 100Gbps SSDP attack?

The only force of centralization I'm seeing in either my experiences or your presentation is the marketing that comes out of CloudFlare and the, as far as many of us can tell, bending of the truth as to what even constitutes an attack that is used to up-sell existing CloudFlare customers. It is one of the reasons why the only websites you ever really notice being attacked are ones behind CloudFlare, because CloudFlare really really wants random other people to notice that they are "helping".

FWIW, I have absolutely been the target of SSDP attacks, and have been concerned about this protocol for a long long timeand it isn't obvious to me how "let's centralize more" is the real answer to the problem: if you really want to protect yourself from a DDoS attack, the obvious solution is to decentralize, not centralize... the more centralized you are the more you have a target that can actually be taken down. As a visceral demonstration of this, I dare you to use an SSDP attack to take down Bitcoin: the only reason that this attack is a conceptual problem in the first place is that people like to centralize things.


Right, sounds like our fundamental assumptions differ.

For the great majority of internet users buying more capacity around the globe to sustain a 100Gbps SSDP is not an option. If you run a mildly controversial website, you don't expect to pay much for idle bandwidth. You can go for hosted solutions, but then you will be charged for attack traffic. What I'm proposing is a solution to this problem - how can we make the internet safer for the most common use case. I propose: netflow (to identify the spoofing boxes), flowspec (as stop gap measure), and BCP38 (a fundamental issue) will get us a long way.

If we were to design HTTP from scratch we could discuss how to make it truly decentralized. This sounds like an academic discussion though.

Your second argument is that DDoS is not a real problem. I don't know how to assess it. Dyn was down. Krebs went down. These are facts. I'm definitely not the guy that shouts "we are all doomed! buy product A or you will go down". All I say is - this is what I see, this is what happened, here are the numbers. Read the data and assess it yourself I guess!

- stats for amplifications https://blog.cloudflare.com/reflections-on-reflections/

- numbers for some random syn flood https://blog.cloudflare.com/a-winter-of-400gbps-weekend-ddos...

- numbers from some unexplained L7 event https://blog.cloudflare.com/the-porcupine-attack-investigati...


> Even without using amplification, with IP spoofing it's possible to launch a direct attack, which will be untraceable.

A long time ago, there was a proposal (itrace, its latest draft was https://tools.ietf.org/html/draft-ietf-itrace-04; see also http://ccr.sigcomm.org/archive/2001/jul01/ccr-200107-paxson....) to make these attacks easier to trace, by having routers probabilistically emit ICMP packets towards the supposed target or source of a packet. From what I recall, as DDoS attacks moved from IP spoofing to zombies using their real IP address, the working group sort of lost its purpose and died.


Question for any network admins here: I enabled IPFIX on our Juniper MX series routers for that exact purpose, but it contains Layer 3 info only (no MAC addresses!).

What am I missing? For now, I'm getting the info I need from sFlow but I want to get rid of that ASAP.

You might be happy to hear that the ISP I work for can definitely identify where that 150Mpps flood came from :) We're even doing some automated outbound mitigation in order to be good net citizens. CloudFlare's blog articles definitely helped us improve our network-level DDoS mitigation, by the way! Thanks for that.


We worked extensively with the MX IPFIX export and I never saw mac addresses in any of the exports Juniper sent us: https://www.plixer.com/blog/virtual-netflow/juniper-vmx-ipfi...


> The next one is going to be some gaming protocol.

Quake 3 engine game servers have already been used in amplification attacks.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: