IoT is not a well-defined term. IoT implementations depend on system constraints. These constraints may relate to security (problems/solutions). It would be helpful to be more specific. See https://tools.ietf.org/html/rfc7228, for example.
Cheers matthias On Mon, 24 Oct 2016, Jared Mauch wrote: > Top posting to provide some clarity: > > 1) Many IoT devices are connected via some cloud service, think Nest (for > example) > 2) Many IoT devices have cloud management, think of Ruckus, UBNT UniFi, etc > that > phone out to a site via DHCP option or otherwise. > 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. > 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. > 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. > As a usenet operator, this baffled me as they had insufficient memory, > storage > etc to do this task, and left security surface quite wide. > > We must promote secure by default. 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. > 6) Devices need to prompt for updates. > > Apple has sorted this nicely, people are prompted for supported upgrades, > disjoint > from carriers and other issues. Contrast this with other ecosystems where > upgrades > require extra steps or have a non-OEM partner involved (eg: Cell Carrier, > Cable Co). > > These devices get less frequent updates, ostensibly for testing but also > leave known > issues exposed for months or years. > 7) Malware can damage systems making them require extra steps to recover > them. Whitehats > may know some mitigation techniques, but can’t protect you either. Some > people have > taken a more aggressive approach, eg: > https://gitlab.com/rav7teif/linux.wifatch > > They will block others from infecting your device until it’s rebooted. > > - Jared > > > On Oct 24, 2016, at 4:24 PM, Ronald F. Guilmette <r...@tristatelogic.com> > > wrote: > > > > > > In message <e364fcea-7105-b3b9-63a9-7d22ab835...@nuclearfallout.net>, > > John Weekes <j...@nuclearfallout.net> wrote: > > > >> On 10/23/2016 4:19 PM, Ronald F. Guilmette wrote: > > jw>>> ... The ISPs behind those IP addresses have > > jw>>> received notifications via email... > > rfg>> Just curious... How well is that working out? > >> > >> For the IoT botnets, most of the emails are ignored or rejected, because > >> most go to providers who either quietly bitbucket them or flat-out > >> reject all abuse emails. Most emails sent to mainland China, for > >> instance, are in that category (Hong Kong ISPs are somewhat better)... > > > > So, given the apparently impracticality of trying to clean up all of these > > kinds of messes via the good old-fashioned tedious and laborious method > > of emailing the relevant providers and then just sort-of vaguely hoping > > that they will -do something- responsible with it, I am just sitting here > > trying to dream up some sort of generalized long-term fix for -all- of > > these IoT DDoS type problems. > > > > Maybe there just plain isn't any such thing as a general solution to the > > problem, because it may perhaps be just technically too complex. But I hope > > no one will begrudge me if I yearn for some sort of Grand Unified Field > > Theory of IoT security. > > > > So, I have a thought... probably worth what you paid for it... and I'm just > > brave enough to throw it out on the table and then everybody can pile on > > and tell me what an idiot I am, for this or that perfectly sound technical > > reason. (I'll say up front that I don't even pretend to understand many > > of the protocols in use these days, in particular UPnP, and to be frank, > > I'd never even heard of SSDP until yesterday. So I can't and won't begrudge > > anybody who tells me that I have my head up... ummm... in the clouds.) > > > > So anyway, here are the assumptions/assertions, perhaps wrong, which are my > > starting point: > > > > 1) I am not persuaded that IoT devices have a compelling need to them- > > selves initiate outbound TCP sessions, ever. (If I'm wrong about > > this, then I'm sure people here will tell me.) > > > > 2) Likewise, I am not persuaded that IoT devices have an absolute and > > compelling need to do very much in the way of UDP. Yes, I would > > like my smart XYZ device to always know what time it is, so, you > > know, a modest amount of NTP traffic is reasonable and to be > > expected. > > Other than that however, I don't see a compelling need. If you want > > to either control or get data out of your IoT device, you can make > > an inbound TCP connection to it. > > > > (Somebody will probably say "Oh, no. We need to stream real-time > > video out of some of these things, and for that we absolutely have > > to send the stuff via outbound high-bandwidth UDP." but I am not > > persuaded that this is either absolutely necessary or even Good, > > i.e. from the point of view of the legitimate security concerns of > > the owner of the device.) > > > > So, based on the above perhaps flawed assumptions, here is my idea. It is > > composed of two simple parts: > > > > 1) First, I will successfully complete my campaign to be elected King > > of the World. (Given the current poltical climate, worldwide, this > > should not be a problem, because I lie a lot.) > > > > 2) Second, once elected I will decree that in future all new IoT devices, > > and also all updates to firmware for existing IoT devices will have, > > BUILT IN TO THE KERNEL, code/logic which (a) prevents all outbound TCP > > session initiation and which also (b) strictly rate-limits all other > > protocols to some modest value. > > > > Remember, we're going to have a few billion of these devices online in the > > coming years. If even and modest subset of these can ever be tricked by an > > attacker into spewing non-rate-controlled traffic towards an attacker- > > selected target, then we're gonna have a problem. > > > > > > Regards, > > rfg > -- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl
