In message <FD166608-2C42-415D-B6F7-FD6921263E09@puck.nether.net>, Jared Mauch <jared@puck.nether.net> wrote:
Top posting to provide some clarity:
That's funny. Personally, I have always felt that top posting -destroys- clarity. But as Chaplin Tapman said in Catch-22 "I'm not here to judge you."
1) Many IoT devices are connected via some cloud service, think Nest
Yea. And? Are you saying that there is no way to make that connection happen without a kernel that's going to allow unlimited outbound bandwidth to entirely arbitrary targets?
2) Many IoT devices have cloud management, think of Ruckus, UBNT UniFi etc that phone out to a site via DHCP option or otherwise.
I admit that I -was not- thinking about such things when I posted my trivial proposal, in large part because I'd never heard of either before now. But that's OK. I've just googled them and I don't think either type of device really negates my simple proposal. Via the simple expedient of redefining the scope of the problem being addressed, I would still like to claim that what I proposed may have some merit, but only for "real" IoT devices. I will now define what I'd like to call "real IoT" devices as "stuff that isn't either general purpose computers *or* stuff like routers." The Ruckus thing and that UBNT UniFi thing appear to me to fall more into the class of devices I'd prefer to call "routers", i.e. stuff whose job it is to move quite a lot of packets, on a routine basis, in the outbound (Internet) direction. (Yes, I'm cheating by definining and/or re-defining my terms, on-the-fly, to exclude stuff that I don't want to be bothered thinking about right now. But maybe that isn't such a bad thing, or even such an intellectually dishonest thing as it may at first appear. It's best not to bite off more than you can chew, and I think it might be useful to solve the problem for a big swath of common "IoT" devices that either are now, or that will soon be on the Internet, even if I can't offer you a solution for, you know, poverty and world hunger at the same time.)
3) Many IoT devices are something like a set top box, these need access to a CDN or similar to get the content for the users.
I thought a bit about that since I posted, and here's my response... Yeabut traffic for -those- things is goona be 99.99% inbound. My Roku needs to connect out to get stuff, and maybe it is even is doing that via TCP. (I really don't know, cuz I never even thought about it before.) But even if my Roku is sucking down content via TCP connections which *it* initiated (i.e. "outbound" TCP connections) if there were a low fixed, maximum -outbound- bandwidth rate limit implemented for this thing, directly in its kernel, I believe that it could still do everything it is supposed to do with no problem. So fuggetabout what I said about totally disallowing outbound TCP. For many IoT devices, actually and totally disallowing outbound TCP connections might be workable... and for those, it would be a prudent and useful kernel-enforced limitation...,but for many others, like my Roku, maybe not. But neither your refrigerator nor my Roku really ever has any need to be sending multi megabits per second outbound. They just don't. I'm -not- suggesting that we put all these things on a diet and give them only 9600 baud to work with. I'm just saying that if they ever hit more than, say, .2 Mbps outbound, in total, over any short period of time, then I think their kernels would be doing the world a favor if they displayed some sort of an error code (where feasible) and if they then started just dropping outbound packets on the floor until things settle down and the -requested- outbound bandwidth drops back below the hard limit. (Of course, all traffic to internal interfaces, local loopback, and RFC1918 addresses should be utterly exempt from the cap.)
4) Many IoT consumers don't read NANOG, so they also won't set up a firewall other than to know it is a service impairing tool that must be disabled for their devices to work.
Well, yea, there's that, but also, with IPv6, as I understand the plan, every single device, no matter how lowly or absurd, is gonna get itself plugged right straight into the neural backbone of the entire planet. None of this NAT router or firewall stuff anymore! That's so last millenium. So there's not gonna be nothin' in our bright bright future for Luci and Desi to either enable or disable anymore, even if they wanted to. But here it seems that you're agreeing with me, and even making the case for me. The device itself should be fail-safe. It shouldn't need outside help in order to avoid bursting into flames and endangering innocents like a 1970's Ford Pinto.
5) There are few/no new lessons here compared to the default install of Redhat 3.0.3 from the late-1990s. I recall it by default installed INN a usenet news server.
An IoT is -not- a general purpose computer. In the latter case, it is assumed that the owner will "pop the hood" when it comes to the software configuration. In the former case it is assumed that the owner -won't- be doing that, or will have only a very minimalist ability to do so. (CAUTION! Risk of electrical shock! There are NO user-servicable components in this box.)
We must promote secure by default.
I love it when people agree with me.
This means some sort of secondary authentication such as a sticker on the device with default password or requiring the entering of a serial number or basic setup information to work.
Well, yea. That would be nice too. Force the user to set a unique password. How novel! Swell idea. Marvelous. I'm all for it. And we know that will work, absolutely 100%, until it doesn't, until the day when some pimply-faced teenager in Minsk figures out how to engineer a maliciously crafted JPEG, then uploads it to his Picassa album, and then gets his pal to spam out 50 million spams encouraging Joe Wankers everywhere to view the latest nude photos of Jennifer Lawrence on their Rokus, whereupon we'll all be right back where we were on Friday.
6) Devices need to prompt for updates.
See above. That would be nice too. I'm not persuaded that it will actually solve the problem though. (Think about this too: If the software minions hired by the manufacturer to code up the original firmware were careless enough to have created a serious security flaw in the -original- firmware, what makes you think that they are suddenly going to develop superior coding skills and that, thus, any update released by the company will be any more secure than the original flawed version? And that's even assuming that the same guys who coded up the original firmware are tasked to do maintenance fixes, which is most companies, they're not. The original coders all get moved over to the latest project in development, and the company hires one or two 19 year old H1-Bs just off the boat to handle all software maintenance on the "old" products. So nine times out of ten, the guys tasked with fixing the security problem(s) in the "old" products are even more inept dumbasses than the ones who coded up the original security flaws in the first place. How many securty fixes have had to have -their own- subsequent security fixes applied? Plenty.)
Apple has sorted this nicely, people are prompted for supported upgrades...
Umm, I'm getting the book off my shelf that purports to tell me how to disagree without being diagreeable. But I can't seem to find it so I'll just say what I mean: Rubbish! "Apple has sorted this nicely"??? You must be joking! I've got an iPhone 3GS. I went into the local Apple store more than a year ago and asked them how I could get the bloody thing to read and display PDF files. They were very polite, and tried hard to avoid snickering directly in front of me. And they were, of course, only too happy to show me a brand new iPhone 6 while telling me how little it would probably cost in conjunction with "my plan". (Hint: I don't have a plan. I have GoPhone dollars, which don't cost me anything if I don't use them, which, in general, I don't. And if Apple really thinks that I'm going to shell out several hundred real bucks for a piece of electronics that might accidentally end up in the washing machine or simply get ripped off they got another thing coming.) So, it turns out that Apple can't (or rather won't) give me any version of any of the last -3- major releases of IOS for my phone, because they quite rightly have figured out that it is not in their economic interest to do so. So I now own the Apple equivalent of Windows XP. No security fixes, no nothing. So when you say "Apple has sorted this nicely', you'll just have to forgive me if I take issue with that. More to the point however, this illustrates part of the overall problem. Manufacturers and vendors sell stuff to you with the expectation (and hope?) that it's all gonna end up in a landfill someplace within 5 years. They certainly don't plan on releasing any security updates past those five years, and that's even assuming that the company itself lasts that long. (Many don't.) So, six years from today we'll all wake up one morning, turn on CNN, and find out that a maliciously crafted packet sent to 35 million vacation pet feeders has just resulted in the disapperaance from the Internet of the entire continent of South America. So Wolf Blitzer or Brian Krebs will pick up the phone to call the manufacturer to ask if they're going to be releasing a security update for this massive problem, only to find out that the phone number is dead and the company declared bankruptcy three years earlier. This is not a happy ending. If all of the *&^%$# damn stupid vacation pet feeders had originally shipped with outbound rate limits hard-coded in the kernel, maybe this could have been avoided.
7) Malware can damage systems making them require extra steps to recover them. Whitehats may know some mitigation techniques, but can't protect you
I do so love to end on a note of agreement. I reiterate, fail-safe by design, and outbound rate limits for all IoT things to which such limits can be sensibly applied without damaging or materially degrading functionality... which is to say most of them. Regards, rfg