Live data from Hacker News

Stupidly Simple DDoS Protocol (SSDP) Generates 100 Gbps DDoS

blog.cloudflare.com

51–60 of 112 posts

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

#51
post #12
post #10

Why is IP spoofing STILL an issue? Why?

1) Hardware. ALL routers performance degrades. Sometimes up to unsuitability. 2) Software. No commonly agreed way to maintain route and route6 object. No federation for them 3) Administrative. Lack of network hygiene. Keyword: BCP38 Relevant document https://tools.ietf.org/pdf/bcp38.pdf

BCP 38 on ingress at edges is trivial performance-wise (a few ACL entries in TCAM).

It's just that there is no incentive to stop lazy ISPs from allowing everything since that's easier.

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

#52
More casualties from BCP 38 failures. This article mentions it but then dilutes the importance of it by suggesting SSDP is a problem. If IP spoofing did not work on the Internet, none of these UDP reflection attacks would work.

A scheme to strong arm the adoption of BCP 38 is key to stopping these attacks from growing. IoT has shown us that expecting device updates to disable these UDP protocols is a lost battle.

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

#53
post #50
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…

IP spoofing is the problem. Even if you completely ban UDP protocols, it still allows for anonymous unamplified attacks. Attacking every single protocol that dares to respond to a query is a pretty stupid approach IMO. Look how well it's worked so far. Additionally, unless we switch DNS to TCP only, root and authoritative name servers are always going to provide and amplification factor and there are still more than…

Who are these ISPs? I would love to see a treemap apportioning blame to the worst offenders...

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

#54
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…

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.

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

#55
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…

Isn't that normal UDP behavior? Source port on responses can always be anything?

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

#56
post #54
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…

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

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

#57
post #53
post #50

Earlier quoted context omitted.

IP spoofing is the problem. Even if you completely ban UDP protocols, it still allows for anonymous unamplified attacks. Attacking every single protocol that dares to respond to a query is a pretty stupid approach IMO. Look how well it's worked so far. Additionally, unless we switch DNS to TCP only, root and authoritative name servers are always going to provide and amplification factor and there are still more than…

Who are these ISPs? I would love to see a treemap apportioning blame to the worst offenders...

Hard to tell unless you're a large ISP like CloudFlare that has direct routes to most of the internet.

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

#58
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)

Much harder to do network scans with IPv6 though.

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

#59

    More on the SSDP servers
    
    Since we probed the vulnerable SSDP servers, here are the most common Server header values we received:
    
     104833 Linux/2.4.22-1.2115.nptl UPnP/1.0 miniupnpd/1.0
      77329 System/1.0 UPnP/1.0 IGD/1.0
      66639 TBS/R2 UPnP/1.0 MiniUPnPd/1.2
      12863 Ubuntu/7.10 UPnP/1.0 miniupnpd/1.0
      11544 ASUSTeK UPnP/1.0 MiniUPnPd/1.4
What an earth is internet facing and running 2.4 Linux kernels?

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

#60
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…

Isn't that normal UDP behavior? Source port on responses can always be anything?

Not really - DNS, DHCP, NTP, etc, all respond from the source port the service is bound to.
Post reply on HN