Now it’s official. The particular website that was hit by a record-breaking distributed denial of service (DDOS) attack that we covered a few days ago was that of white-hat security journalist [Brian Krebs]: Krebs on Security.
During the DDOS attack, his site got 600 Gigabits per second of traffic. It didn’t involve amplification or reflection attacks, but rather a distributed network of zombie domestic appliances: routers, IP webcams, and digital video recorders (DVRs). All they did was create HTTP requests for his site, but there were well in excess of 100,000 of these bots.
In the end, [Krebs’] ISP, Akamai, had to drop him. He was getting pro bono service from them to start with, and while they’ve defended him against DDOS attacks in the past, it was costing them too much to continue in this case. An Akamai exec estimates it would have cost them millions to continue defending, and [Brian] doesn’t blame them. But when Akamai dropped the shields, his hosting provider would get slammed. [Krebs] told Akamai to redirect his domain to localhost and then he went dark.
Brace yourselves. The rest of the media is going to be calling this an “IoT DDOS” and the hype will spin out of control. Hype aside, the facts on the ground make it look like an extremely large distributed denial-of-service attack (DDOS) was just carried out using mostly household appliances (145,607 of them!) rather than grandma’s old Win XP system running on Pentiums.
We can argue all day about whether a digital video recorder (DVR) or an IP webcam is an “IoT” device and whether this DDOS attack is the biggest to date or merely among them, but the class of devices exploited certainly are not traditional computers, and this is a big hit. Most of these devices run firmware out of flash, and it’s up to the end user (who is not a sysadmin) to keep it up to date or face the wrath of hackers. And it’s certainly the case that as more Internet-facing devices get deployed, the hacker’s attack surface will grow.
Why did the DDOS network use these particular devices? We’re speculating, but we’d guess it’s a combination of difficult-to-update firmware and user “convenience” features like uPnP. To quote the FBI “The UPnP describes the process when a device remotely connects and communicates on a network automatically without authentication.” You can see how this would be good for both the non-tech-savvy and hostile attackers, right? (Turn off UPnP on your router now.)
We alternate between Jekyll and Hyde on the IoT. On one hand, we love having everything in our own home hooked up to our local WiFi network and running on Python scripts. On the other hand, connecting each and every device up to the broader Internet and keeping it secure would be a system administration headache. Average users want the convenience of the latter without having to pay the setup and know-how costs of the former. Right now, they’re left out in the cold. And their toasters are taking down ISPs.
There are it seems no wireless-enabled light switches available in the standard form factor of a UK light switch. At least, that was the experience of [loldavid6], when he decided he needed one. Also, none of the switches he could find were open-source, or easy to integrate with. So he set out to design his own, and the Theia IoT light switch is the result.
In adapting a standard light switch, he was anxious that his device would not depend on the position of the switch for its operation. Therefore he had to ensure that the switch became merely an input to whichever board he designed, rather than controlling the mains power. He settled upon the ESP8266 wireless-enabled microcontroller as the brains of the unit, with a relay doing the mains switching. He first considered using an LNK304 off-line switching PSU chip to derive his low voltages, but later moved to an off-the-shelf switch-mode board.
So far two prototype designs have been completed, one for each power supply option. Boards have been ordered, and he’s now in the interminable waiting period for international postage. All the KiCad and other files are available for download o the project’s hackaday.io page, so you can have a look for yourselves if you are so inclined.
You might ask why another IoT light switch might be needed. But even though they are now available and inexpensive, there is still a gap for a board that is open, and more importantly does not rely on someone else’s cloud backend. Plus, of course, this board can be used for more than lighting.
Light bulb image: Осадчая Екатерина (Own work) [CC BY-SA 4.0], via Wikimedia Commons.
When we buy new shiny toys, we usually open them up to at least have a look. [Scott Gibson] does the same, apparently. He found an ESP8266 module inside the EcoPlug brand WiFi-controlled wall switches.
The original device was intended to be controlled by a (crappy) app. He sniffed the UDP packets enough to send the on-off signals to an unmodified device, but where’s the fun in that? [Scott] gave it an upgrade by replacing the ESP8266’s firmware with his own and now he’s got a much more capable remote switch, one that speaks MQTT like the rest of his home automation system.
Last time I showed you how to expose a web service on a Raspberry Pi (or, actually, any kind of device) by using a reverse proxy from Pagekite. On your Pi, you just need a simple Python script. However, it also depends on the Pagekite server, which isn’t always convenient. There are limits to the free service, and you don’t control the entire thing. The good news is twofold: the same Python script you use to set up the client-side can also set up a server. The other good news is the entire thing is open source.
In practical terms, then, if you have a computer that is always on and has an IP address that can be found on the public internet, you can run your own Pagekite server (they call it a front end) and service your own backends.
Everyone’s talking about the Internet of Things (IoT) these days. If you are a long-time Hackaday reader, I’d imagine you are like me and thinking: “so what?” We’ve been building network-connected embedded systems for years. Back in 2003, I wrote a book called Embedded Internet Design — save your money, it is way out of date now and the hardware it describes is all obsolete. But my point is, the Internet of Things isn’t a child of this decade. Only the name is.
The big news — if you can call it that — is that the network is virtually everywhere. That means you can connect things you never would have before. It also means you get a lot of data you have to find a reason to use. Back in 2003, it wasn’t always easy to get a board on the Internet. The TINI boards I used (later named MxTNI) had an Ethernet port. But your toaster or washing machine probably didn’t have a cable next to it in those days.
Today boards like the Raspberry Pi, the Beagle Bone, and their many imitators make it easy to get a small functioning computer on the network — wired or wireless. And wireless is everywhere. If it isn’t, you can do 3G or 4G. If you are out in the sticks, you can consider satellite. All of these options are cheaper than ever before.
There’s still one problem. Sure, the network is everywhere. But that network is decidedly slanted at letting you get to the outside world. Want to read CNN or watch Netflix? Sure. But turning your computer into a server is a little different. Most low-cost network options are asymmetrical. They download faster than they upload. You can’t do much about that except throw more money at your network provider. But also, most inexpensive options expose one IP address to the world and then do Network Address Translation (NAT) to distribute service to local devices like PCs, phones, and tablets. What’s worse is, you share that public address with others, so your IP address is subject to change on a whim.
What do you do if you want to put a Raspberry Pi, for example, on a network and expose it? If you control the whole network, it isn’t that hard. You usually use some kind of dynamic DNS service that lets the Pi (or any computer) tell a well-known server its current IP address (see figure below).
For his contribution to this modern vernacular atrocity, he first had to build an IR debugging tool and reverse engineer the signals coming from the air conditioner’s remote. He wrote up a really good summary of the process, and worth reading. He loads up an IR library onto an Arduino and dumps the resulting 32 bits of information to his computer. In a process much like filling in the blanks on a word puzzle, he eventually determines which blocks of the data correspond to the remote’s different buttons.
Next he throws an array of IR LEDS and an ESP8266 onto a bit of protoboard. After writing some code, available on GitHub, he could set the temperature of his room from anywhere on the planet. We take it on faith that [zeroflow] has a compelling reason for doing so.
Bolstered by this success, he didn’t stop there. [Zeroflow] admits to having more than one thing on the Internet. Boom! Internet of things.