In message <580F19BF.2070002@vaxination.ca>, Jean-Francois Mezei <jfmezei_nanog@vaxination.ca> wrote:
One way around this is for the pet feeder to initiate outbound connection to a central server, and have the pet onwer connect to that server to ask the server to send command to his pet feeder to feed the dog.
This way, there need not be any inbound connection to the pet feeder.
Right. And even that one outbound connection (from the pet feeder to the central server) isn't going to need much in the way of bandwidth. So if the kernel wakes up and notices "Whoa! Wait a minute here! This box is sending out in excess of 100 kilobits per second!" then something is REALLY wrong here. Time to let that ethernet interface take a little nap. Likewise if the kernel notices that the box has just sent out in excess of, say, 100 outbound UDP packets with destination port set to 53 in the last 60 seconds. Time to send DNS to its room for a little "bad behavior" time out! Because in practice, for most or all of the kinds of IoT devices I can think of, (a) they shouldn't be sending out DNS -responses-, ever, and (b) if they are sending out more than, say, 100 outbound DNS -queries- per minute, then the only possible reason they would be doing so is that the box itself has been enslaved and is participating in a DNS reflection attack. The point is that for many (most?) types of IoT devices the engineers who designed the box should be able to tell... or at least predict... what the maximum theoretical outbound bandwidth usage and/or the maximum theoretical outbound packets per second for various protocols and ports ought to be... assuming that the box is functioning "normally", as the original design engineers intended, and not as some miscreant's slave. So then they, the original design engineers, can hard code limits into the kernel... limits that are, say, 25% above these worst case "normal operation" limits, thus allowing for a healthy margin of error. The result would be a box that can't be turned into a weapon, no matter what, at least not without loading up all new (and malicious) firmware, a task which should require at least some direct, hands-on manually fiddling (such as pressing and holding the reset button) in any event. I refer again to the Ford Pinto, and also to the Apollo 1 fire. I don't think that there's really a problem with engineering belt-and-suspenders safeguards into the firmware of IoT things. The only real problem is providing both companies and engineers with the motivation necessary to insure they will do so. Let's hope that nobody has to die before we find a way to manufacture that motivation. (A little temporary bad press for one Chinese manu- facturer of CCTV cameras isn't going to be sufficient, I'm afraid.) Regards, rfg