Live data from Hacker News

Stupidly Simple DDoS Protocol (SSDP) Generates 100 Gbps DDoS

blog.cloudflare.com

71–80 of 112 posts

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

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

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

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

#72
post #71
post #28

Earlier quoted context omitted.

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

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.

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

#73
post #42

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

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?

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

#74
post #51
post #12

Earlier quoted context omitted.

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.

It's not few. It's a very common mistake. Say I have 20 10G ports on line card. Mid size ISP has from hundreds to thousands routes. Thus we will end up with tens of hundreds ACLs per line card. That affects performance, dramatically. Say on older yet supported Cisco 7600 you can apply about 10k entries per port, ~ 100k totaling per card. That's limit, after that performance degrades. Another question what to do on peer-peer links, like say NTTCentrylink? Both on them have interconnects across the globe ad sending each other hundreds of thousands prefixes on 100G ports. That's the challenge as well. Hardware is not there, it's coming slowly but not yet there. Most of the big players DO one or another form of ingress filtering on some ports. Valid point is that smaller players are arrogant ob the issue and dump all all the garbage to the upstream.

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

#75
post #41

Earlier quoted context omitted.

You don't have to have a router. The apartment building where I live have fiber, with twisted pair to each apartment. DHCP leases from the apartment gives you an external IP. It's possible to hook up a switch and get DHCP leases for multiple devices. I assume there's an upper limit, I've only tried it with two devices. Now, let's say I hook up a printer to a switch in that configuration. Is it smart enough to not res…

> Now, let's say I hook up a printer to a switch in that configuration. Is it smart enough to not respond to UPnP coming from globally routable addresses? WTF? How would it not be utterly idiotic to not respond to UPnP requests from globally routable addresses? Why should it be impossible to print from some machine, just because it has a globally routable address?

"Why should it be impossible to print from some machine, just because it has a globally routable address?"

Because it's an Internet.

Sure, it's uncommon behavior and not what most people want, but let's not completely give up on the notion of being a peer on the network.

The printer serves up (printing) just like a web server serves up web pages. You should be able to run a web server and participate as a peer, globally.

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

#76
post #74
post #51

Earlier quoted context omitted.

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.

It's not few. It's a very common mistake. Say I have 20 10G ports on line card. Mid size ISP has from hundreds to thousands routes. Thus we will end up with tens of hundreds ACLs per line card. That affects performance, dramatically. Say on older yet supported Cisco 7600 you can apply about 10k entries per port, ~ 100k totaling per card. That's limit, after that performance degrades. Another question what to do on pe…

This is why handwaving and shouting "BCP38" is not sufficient. I could live with half-baked BC38 deployment as it is now, if only I had other tools to trace malicious actors - netflow.

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

#77

Earlier quoted context omitted.

You're half right. In most cases, programs have the OS pick their source port, but that's for the computer initiating the communication. So for example, in the communication he gave the 50950 was likely picked by the OS (by selecting a currently open port) and 1900 is the destination port. When the remote computer responds (his printer), they don't then pick a new random source port, they just swap the source/dest fr…

> 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 route that packet to the original socket because the source port does not match. 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.

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

You still have to get the packets though, and the OS had no idea about any application layer routing. If you want to get UDP packets from a bunch of different ports, you have to be listening on those ports.

Edit: It's true I was playing a bit loose with the terminology (UDP is connectionless), but the behavior of packet routing and how changing the source port would mess with that is what I was getting at. If you want to be more correct, replace "connection" with "socket" in my original comment.

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

#78
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,...)

The IETF never really liked NAT, and the IPv6 spec doesn't really support it. http://www.ipv6.com/articles/nat/NAT-Pros-and-Cons.htm

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

#79

Earlier quoted context omitted.

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

You're half right. In most cases, programs have the OS pick their source port, but that's for the computer initiating the communication. So for example, in the communication he gave the 50950 was likely picked by the OS (by selecting a currently open port) and 1900 is the destination port. When the remote computer responds (his printer), they don't then pick a new random source port, they just swap the source/dest fr…

When the OS picks a random port, it's from a pool of Ephemeral ports. Which can vary from OS to OS. My assumption is that printer responding with a different source port breaks the communication over NAT. Is it a possibility that this is intended?

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

#80

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

"The vulnerable IPs are seem to be mostly unprotected home routers."

I interpreted this as routers that themselves have uPnP implementations, probably intended to advertise themselves to clients on the local network, but that listen on all network interfaces by mistake.

Post reply on HN