Live data from Hacker News

Stupidly Simple DDoS Protocol (SSDP) Generates 100 Gbps DDoS

blog.cloudflare.com

91–100 of 112 posts

Re: Stupidly Simple DDoS Protocol (SSDP) Generates 100 Gbps DDoS

#92

Earlier quoted context omitted.

> If they didn't keep it the same then the OS wouldn't always be able to know packets are part of which connections UDP does not have connections. > and the only differentiation would be the source port. ... or some request/session/flow id in the application layer protocol. Some UDP protocols use UDP in this way, some don't, UDP itself doesn't care.

> UDP does not have connections. UDP does not have connections, but the OS does have a concept of UDP connections to a degree in the form of packet filtering/routing. Point being, if you send a DNS request (for example), the source IP/port and dest IP/port is how the OS will decide which packets to route back to you when the DNS server responds. If the responding DNS server changes the source port, the OS will not ro…

> UDP does not have connections, but the OS does have a concept of UDP connections to a degree in the form of packet filtering/routing.

The filtering is completely optional to use.

> Point being, if you send a DNS request (for example), the source IP/port and dest IP/port is how the OS will decide which packets to route back to you when the DNS server responds.

That depends on how the requesting resolver has configured the socket.

> If the responding DNS server changes the source port, the OS will not route that packet to the original socket because the source port does not match.

That depends on how the requesting resolver has configured the socket.

> You can still make it work, but you would have to be already listening for packets from that port (one way or another), so you would have to know beforehand they are going to be using a different port.

Yes, obviously you have to know the application protocol you are trying to speak and how it uses UDP before you try to speak it.

> You still have to get the packets though, and the OS had no idea about any application layer routing.

Which is why application layer routing is called application layer routing.

> If you want to get UDP packets from a bunch of different ports, you have to be listening on those ports.

No, you listen on local ports, not on remote ports.

> If you want to be more correct, replace "connection" with "socket" in my original comment.

Well, technically, some minor details would be more correct - but the fundamental assumption that you can only receive datagrams from one remote address/port with a given socket is just completely and utterly wrong, and not just in the sense that it's a theoretical possibility, but it's a perfectly normal use case. To take an obvious example, a common configuration for an OpenVPN server is to accept authenticated packets from any remote address and automatically switch to changing remote addresses for the sending direction, so when the client changes addresses, the OpenVPN session just keeps going.

As long as you don't connect() a datagram socket in the BSD sockets API, you will receive datagrams from any remote address (and you'll have to specify remote addresses using sendto() when transmitting).

Re: Stupidly Simple DDoS Protocol (SSDP) Generates 100 Gbps DDoS

#93
post #24

Earlier quoted context omitted.

So? Every single thread of this nature has a similar comment, and I really want to know (ie, I want to hear this fully fleshed out because I think your concerns are valid and worth exploring): is this demonstrative of a new (or in some way more valid) notion of the word "hacker" in "hacker news?" My sense of that word, and of the culture that underlying it, is that a critical part of its critique is that obscurity ,…

What? If there’s a question there, could you ask it in a straightforward manner, please?

OK, I'll try. :-)

Are there good reasons to believe that obscurity (ie, keeping secret the means and methods of attack) is likely to be a viable defense in favor of civility and justice in the age to come?

Re: Stupidly Simple DDoS Protocol (SSDP) Generates 100 Gbps DDoS

#94
post #93

Earlier quoted context omitted.

What? If there’s a question there, could you ask it in a straightforward manner, please?

OK, I'll try. :-) Are there good reasons to believe that obscurity (ie, keeping secret the means and methods of attack) is likely to be a viable defense in favor of civility and justice in the age to come?

No. Does the parent comment imply that somehow? (Did the reply end up on the wrong comment?)

Re: Stupidly Simple DDoS Protocol (SSDP) Generates 100 Gbps DDoS

#95
post #49

> Internet service providers should never allow IP spoofing to be performed on their network. IP spoofing is the true root cause of the issue. See the infamous BCP38. I don't see how it is at all reasonable to shift blame from a protocol that assumes the world can be trusted to the untraceable goal of "every single network in the entire world should only generate trusted data: then the problem would be solved". > Int…

I agree. Lots of ISPs block outbound port 25 on their residential connections which I applaud.

Re: Stupidly Simple DDoS Protocol (SSDP) Generates 100 Gbps DDoS

#96
post #56
post #54

Earlier quoted context omitted.

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

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

[deleted]

Re: Stupidly Simple DDoS Protocol (SSDP) Generates 100 Gbps DDoS

#97
post #56
post #54

Earlier quoted context omitted.

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

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

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

Re: Stupidly Simple DDoS Protocol (SSDP) Generates 100 Gbps DDoS

#98
post #73
post #42

Earlier quoted context omitted.

The same way people run p2p clients like BitTorrent from home, or the nerdier people run home servers with SSH, RDP or HTTP(S) exposed: they just use the port forwarding features available on every single consumer router. Sometimes software / hardware will automatically assign a port forward via uPnP[0] (this is what many P2P clients will do), sometimes it's done manually[1][2][3][4]. The only difference here is the…

Would a printer automatically decide to expose itself to the wider Internet in this way?

You're asking questions already covered in the article:

https://blog.cloudflare.com/ssdp-100gbps/#openssdpisavulnera...

Re: Stupidly Simple DDoS Protocol (SSDP) Generates 100 Gbps DDoS

#99
post #72
post #71

Earlier quoted context omitted.

NAT and pray still leaves you screwed under IPv4 these days - attackers know how to bypass NAT-without-filtering. (I don't think firewalls are a good solution in general, but I would agree that they might be the least-bad way to handle crappy embedded/IOT-type devices).

The reflector attack in question cannot bypass a NAT setup in any meaningful way. Yes, there are tricks that make some protocols NAT-inspectable. It's not perfect. But as a default behavior it's proven surprisingly strong. Typical IPv6 deployments are significantly less secure, sadly.

On the other hand the main reason we have UPnP at all is to deal with the need to work around NAT - maybe these vulnerable devices simply wouldn't be running a UPnP stack at all under IPv6.

Re: Stupidly Simple DDoS Protocol (SSDP) Generates 100 Gbps DDoS

#100
post #40

Author here. Allow me to extend the post a bit. It turns out that about 2.4% of the IPs that respond to SSDP queries, do so from a weird port number! For example: IP 192.168.1.75.50950 > 239.255.255.250.1900: UDP, length 95 IP 192.168.1.71.1026 > 192.168.1.75.50950: UDP, length 249 The first packet is SSDP M-SEARCH query. The second is a response from my printer. Notice - the source port for the response is not 1900…

hypothesis:

- listens on multicast/1900;

- response over unicast, thus ephemeral sport.

so we use DPI to drop SSDP DDoS-es.

Post reply on HN