A “Bot-Net” composed largely of Internet-of-Things devices has taken major internet sites offline.

In three previous articles I’ve written about the challenges of managing Internet of Things (IoT) rollout while minmising risk.

Now the genie is out of the bottle, the Mirai Botnet today wreaked havoc by attacking a key DNS provider used by many major internet sites.

There are a lot of things we could have done better to ensure that IoT devices are designed to be secure, and deployed in a way that allows them to be managed and tracked. If any good comes of the several recent attacks involving compromised IoT devices, it may be that these will wake up the industry and cause market pressure on vendors to provide devices that are both safer and more manageble.

But for now, we have hundreds of thousands of devices out there that are already compromised, and according this article unable to be easily disinfected. So what can we do to mitigate this botnet? There are things we can do.

Cleaning up the mess

First, determine if you are infected. I’m sure we’ll be able to detect the command and control messages for the botnet(s) and at least alert infected device owners. Savvy folks can test themselves, and ISPs can test and alert their customers. Scan your network for TCP devices listening on port 23, and see if these passwords work.

Second, isolate vulnerable or infected devices from the botnet. Block the command and control messages at your firewall, or at your ISP. Put your IoT devices on a restricted network that restricts attack vectors. Block telnet (TCP port 23) on all your routers. Almost nobody needs it, and if you do, you’ll know.

Third, follow my recommendations on filter policy. If you have vulnerable IoT devices, work out what internet resources (if any) that they need to access, and only permit them to access those resources. If you have a security camera, it should either need no outbound connection, or connection only to a single cloud service. Examine the uPnP status on your router and see what ports your devices have opened up. Look for ports 23 and 22. Turn off uPnP or block those ports if you see them in use.

Fourth, if it is true that the bulk of affected devices are of a single brand, I hope the manufacturer will provide documentation to allow the OSS community to build a replacement firmware that fixes the vulnerability.

Preventing next time

Obviously we’ve suffered from stupidly poor security practices on the part of the manufacturers of these devices. It’s a no-brainer that we need to adopt practices to support safer IoT, by taking security seriously, and planning for ongoing maintenance of devices.

This botnet and the attacks it carried are a totally avoidable failure, caused by poor product design and terrible engineering practices. None of these devices needed a default password or a semisecret hardcoded backdoor. Many of the compromised #IoT devices didn’t need even need to ship a full Linux runtime; vendors should tailor their use of technologies to omit needless vulnerabilities. Don’t run server processes on IoT devices that aren’t essential. If you don’t need the power of Linux, don’t use Linux! There are good open source real-time #IoT platforms with much smaller threat surfaces.

Market pressure is on price, price, price. As Bruce Schneier writes neither users nor vendors have strong reasons to care about security. Hopefully they will have a reason to care about not being able to reach Netflix or Twitter for a whole weekend. I think that #IoT safety will and should be addressed by extending electrical safety certification to cover basic vulnerability assessment. Now as Matthew Garret writes we will never root out all the vulnerabilties no matter how deep we scan, but scanning for the stupidly obvious vulnerabilties is a necessary start, and the very act of doing it will have the effect of generally improving development practices.

The payment card industry sets a good example; businesses wishing to comply with PCI-DSS standards must pass regular port scans. Why not scan IoT devices for the most egregious stupidities during during pre-market certification testing?

If you are a business deploying IoT, have your IT person run an off the shelf vulnerability scanner on your network now. Heck do that quarterly for whole org. Put your IoT devices on a separate WiFi network, and limit what kinds of traffic can enter and leave it. I expect consumer routers to provide a separate WiFi network for household IoT in future, as some already do for guest networks.

If you are deploying IoT in business you need to defend in depth. Segregate your IoT devices, monitor for changes in traffic, and lock down egress to only needed destinations.

When you install an IoT device, work out what it needs to talk to, and set up your firewall to only let it talk to those places. I’ve written more here about how I think we can build a device registry framework to express these network egress policies, much as we did for spam with SPF.

Securing the internet of things against botnets isn’t going to be easy, but we have no option. The problem has been here since before IoT arrived — the Morris worm in 1988 used the very same techniques as Mirai in 2016 — we cannot wish the IoT away. Adapting our internet architecture to protect against armies of refrigerators and toasters will not be easy, but nor do I think it is in any way impossible. As Churchill said, this is not the end, nor even the beginning of the end, but perhaps it is the end of the beginning.

(This article originally appeared on Medium.)