Live data from Hacker News

Stupidly Simple DDoS Protocol (SSDP) Generates 100 Gbps DDoS

blog.cloudflare.com

31–40 of 112 posts

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

#32
post #24

Pervasive IoT device deployment without in-the-wild security considerations and rapid updates is likely to add to DDoS bot farms.

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?

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

#33
post #4

It will be years and years until those vulnerable miniupnpd versions are updated. Most are in embedded devices which will never see another update. I'm glad to see miniupnp is still in active development: https://github.com/miniupnp/miniupnp but I can't work out if it's set to be vulnerable by default.

Vulnerable by default? If a device is listening to UPnP on the WAN interface, the fault is not on UPnP but on whoever configured it to be open on the WAN. IMO, all of these zeroconf protocols should be limited to responding back only to the local segment and not allowed to traverse gateways.

TR-064 is based on UPnP/SSDP, for example.

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

#34

Pervasive IoT device deployment without in-the-wild security considerations and rapid updates is likely to add to DDoS bot farms.

You're a little late - the Mirai botnet (Larget botnet at the time it became widely known) is exactly that. https://krebsonsecurity.com/2017/01/who-is-anna-senpai-the-m...

Ive always wondered if "anna senpai" is a play on "ono sendai" -- the infamous Cyberpunk EvilCorp deck...

I personally feel that it is. (maybe tis was already obvious to others - I just havent talked about it out oud to anyone prior...)

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

#35
post #28

>It's not a novelty that allowing UDP port 1900 traffic from the Internet to your home printer or such is not a good idea. How would this even be possible? Home routers have to NAT everything. Normally you have to set up reverse NAT to get ports forwarded to the LAN.

IPv6 (now you really need a real, properly configured firewall instead of NATting and praying)

Of course you can NAT with ipv6. There is a private address space in ipv6(fc00::/7) like there is in ipv4(192.168.0.0/16,...)

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

#36
post #28

>It's not a novelty that allowing UDP port 1900 traffic from the Internet to your home printer or such is not a good idea. How would this even be possible? Home routers have to NAT everything. Normally you have to set up reverse NAT to get ports forwarded to the LAN.

IPv6 (now you really need a real, properly configured firewall instead of NATting and praying)

I'm convinced there will be a lot of relearning everythign we already know with IPv6

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

#37
post #5

Earlier quoted context omitted.

One of the documented use cases for UPnP is IGD which expressly allows UPnP devices to configure fire wall rules and to set up NAT to map ports to the outside world. So a UPnP device that wishes to expose itself to the outside world is able to do so and this is by design, not by accident. Whether you agree with that or not is another matter.

Agreed - but can there ever be any legitimate use case for an home router to speak IGD over its WAN interface? IGD is typically meant to allow your Xbox on your LAN to set up forwarding rules.

None. Exposing miniupnpd on a public interface is always a misconfiguration. I'm disappointed that the application even allows it -- it has to know which one is public to set up IP forwarding rules, so it has no excuse.

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

#38
post #35
post #28

Earlier quoted context omitted.

IPv6 (now you really need a real, properly configured firewall instead of NATting and praying)

Of course you can NAT with ipv6. There is a private address space in ipv6(fc00::/7) like there is in ipv4(192.168.0.0/16,...)

There is additionally the link-local set of IPv6 addresses

fe80::/64

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

#39
post #29
post #23

Earlier quoted context omitted.

Because UDP is fire and forget, you don't have to be able to respond to packets you send; this is why you can't do the same with TCP packages. To impose fixes upstream, you'd have to do DPI on all data; which is not allowed under some laws (i.e. net neutrality).

In this case, you don't have to care about UDP or TCP, only IP. RFC2827, which should fix the problem where SSDP can be used for DDoS, was published in 2000: https://tools.ietf.org/html/rfc2827 Is ingress filtering on layer 3 considered DPI?

I am not this kind of network engineer, HOWEVER. Both IPv4 and IPv6 are versioned by the first 4 bits of the packet. Depending on that value the address size and location are fixed.

I would not consider the comparison of the source address of packets crossing an ingress link to be 'deep'. I consider that check to be very shallow. It needn't even be every packet from a set, merely picking a random (actually random) packet and testing for conformity is a good quality control measure that SHOULD be taken.

What would the comparison be against? Routers are supposed to know which links are on the other side of all down-stream connections so that they can effectively route.

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

#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 (but the dst port is okay). I'm not sure what the spec has to say about it, but it's pretty weird. What's worse - these responses won't be matched against "sport=1900" DDoS mitigation firewall rule.

I'm not sure what is the moral here. But if you ever see some UDP packets from a weird port, to a weird port - maybe it's this SSDP case.

Post reply on HN