May as well throw in my idea here too. Can ISPs just block their clients from being reached by CNC servers? If we could get a service like Spamhaus for botnets and have service providers automatically blackhole those CNC IPs. Having this done at the tier 1 level would probably cause some pain to the botnets out there. Rather than pushing customers to secure their stuff (impossible), how about we try to stop communication to the CNC. For example, these guys https://zeustracker.abuse.ch/monitor.php keep track of Zeus, if we automatically blackholed those IPs as they get updated it could put a big dent in the effectiveness of Zeus.
It won't solve the problem, but it could put a dent in it. ISP's might like to implement it since it could cut down on transit costs due to DDoS traffic. -----Original Message----- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Ronald F. Guilmette Sent: Monday, October 24, 2016 2:25 PM To: nanog@nanog.org Subject: Spitballing IoT Security 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 received notifications jw>>> 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
