I followed the recent IOT DDOS against Dyn and noticed that the attack seemed have three rounds of attack and mitigation. Since I'm not well versed in infosec I did some reasearch around DDOS mitigation techniques. From what I could tell it seems mitigation is essential heuristic traffic analysis to filter out humans from bots then IP banning. Separately, I also noticed that in almost all the media had the same conclusion that IOT devices are insecure and can't/won't be patched for years. If these two assumptions are true, DDOS mitigation in its rawest since is IP filtering, and we are stuck with millions of infected IOT devices (and adding millions more devices that will one day likely be infected), wouldn't it make sense to start giving IOT devices a static IP, and then when it's detected as participating in a DDOS share the IP to others and block it?
Almost all IoT devices of the sort we are talking here (ie, consumer level) are deployed behind home grade routers (or ARE home grade routers) and are using IPv4 and NAT/uPNP to reach the internet. That means they are sharing an IP with legitimate traffic for one and for another are using a dynamic IP, not a static IP, meaning there's even more opportunities for innocent parties to be caught up in such a blacklist.
Once the glorious world of IPv6 comes, we can likely do just that - assign each one a routable IP address and blacklist them as they get shown to be vulnerable.
One legitimate thing that CAN be done is for ISPs to perform source IP filtering - that is, don't let spoofed packets out, only let packets from IPs within the network. That will help. Some.
wouldn't it make since to start giving IOT devices a static IP
No, because IPs only work in the proper network context.
An device's IP needs to be routable, which is to say, sitting on a network with routers that know how to communicate with other networks and are willing to do so on behalf of the device.
First of all, if you hardwire IPs and send them out, you'd have to use RFC1918 IPs (non-routable) to avoid conflicting with IPs owned by other people. So you're already stuck with a narrow slice of addresses you can use. And those IPs would need to be translated when they hit the Internet, thus removing the ability of the target to filter on them.
Second of all, you'd be handing people devices with IPs that may or may not match their networks. They wouldn't want to rework their networks to accommodate your cheap IOT devices.
In short, a device's IP is set to allow it to work on the network. Setting the IP and expecting the network to work with it breaks things.
The way IP addressing is done for IOT devices doesn't matter in a DDOS attack. Here is the reason why.
- IOT devices may not always be exposed to network with an external IP address.
- It can also be device behind a NAT which has only an internal IP address.
- So irrespective of whether it is DHCP or some static IP, provided by the router to the device, from the DDOS attack victim's perspective, the source of the attack is the external IP of the router.
- In other words, if you have an IP cam at home, The packets from your IP cam as well as your laptop will have the same source IP address, ie the public IP address of your router.
- So filtering the packets based on source IP of the packet can deny service for your laptop as well.
No, as dynamic addressing isn't the attack vector when IoT devices get abused. It's poorly written software! On the DoS side, we have the 'underpowered' device vs. powerful computer problem, and on the connectivity side we have the ease of use vs. security problem.
Ironically, the only way to do proper IoT is to not connect them to the internet! At least a gateway plus locally configured outgoing tunnel would be needed before they can be connected at some sort of safe level.
A static IP would not help; as crovers mentions, due to ipv4 exhaustion, its just not practical. Although IPV6 provides a large enough address space for each device to have a staic IP address, there will still be a lit of overlap with the IPV4 world - where a server will just see lots of traffic arising from a point of presence for IPV6 nodes.
But there are a lot of things manufacturers and governments can do (to make up for the lack of skills on the part of the buying public). Blocking traffic ther than from/to the local network on an appliance by default, forcing a change of admin password before the device, using encryption appropriately, supporting open standards.
The goverment part is more tricky - the obvious solution isproviding an accreditation framework which is easily auditable but minimally invasive with minimum standards, the problem is that they tend to listen to either the "experts" advocating (for example) that all such devices should be fips-140 certified or the vendors bleating about customer freedom and over-regulation rather than seeking pragmatic solutions.
Maybe someone might set up an IETF to look at the classification problem.