How to prevent SSDP reflection / amplification attacks correctly?

Question

I'm implementing a device that ought to respond to SSDP M-SEARCH queries.

I'm a device vendor and I don't have control where these devices will be deployed.

There's a known DDoS attack that uses SSDP search amplification, that is attacker sends search requests from a fake address and poorly coded SSDP server responds to that fake address. Fake address ends up hammered.

What should I do to prevent my device from being used in such an attack?

1. Only set TTL=2 and rely on routers to drop the packets
2. Only respond to requests from own subnet
3. Add configuration option for valid query origin subnets
4. Guess what IP addresses are "local" and "global"
5. Add a response throttle, hope for the best
6. Your suggestions?

Wrt 1. TTL ought to configurable per SSDP spec; Even if it's quite low responses still leak out of local network. If there's a bridged VPN on the network, responses leak out quite far.

Wrt 2. I can imagine corporate networks where multiple subnets are reachable (e.g. one subnet for wireless clients, another for desktops, yet another for servers) and thus my device must be searchable across subnets (though subject to TTL per spec).

Wrt 3. Configuration and maintenance hassle.

Wrt 4. Is there a reliable way to do that? What about IPv6? What about networks that have e.g. /28 slice of global addresses?

Wrt 5. A trickle from a myriad devices still amounts to a torrent...

Ref: https://blog.sucuri.net/2014/09/quick-analysis-of-a-ddos-attack-using-ssdp.html

Paragrapher

UPnP protocols were never designed to be exposed to the public Internet, do you have any reason to respond to external queries?! – Birthmark

Good point @goitaca, how to detect then if one of my interfaces happens to be on public internet (e.g. dumb user or firewall misconfiguration) – Paragrapher

Answer 1

Another option would be not to reply to unicast requests at all. I cannot give you a source explicitly stating that this is allowed, though. One of the drafts certainly reads as if it was, and it'd make sense if it was, too: It's a discovery protocol, after all.

Since multicast is not routed by default in any sane default configuration and 239.0.0.0/8 is organization-local, you can safely assume that requests arriving on the multicast address are genuine. (Unless of course you have an attacker in your own network, but that's a different problem.)

On Linux, incoming UDP packet can be inspected using IP_PKTINFO socket option to validate that it was in fact sent to a multicast address:

https://mcmap.net/q/518132/-get-destination-address-of-a-received-udp-packet http://www.linuxquestions.org/questions/programming-9/how-to-get-destination-address-of-udp-packet-600103/

Milson

AFAIK there's no way to tell if the request was sent on a multicast or unicast address (presume that attacker found my unicast address). All socket IP gives me is the unicast source address in either case. Right? – Paragrapher

You can obtain the packet's detination address by using IP_PKTINFO/recvmsg. – Milson

I'm going to let SO auto-award the bounty, because this is a valid hack; However it does not seem like a canonical answer. – Paragrapher