nanog mailing list archives
RE: Spitballing IoT Security
From: Steve Mikulasik <Steve.Mikulasik () civeo com>
Date: Mon, 24 Oct 2016 20:42:53 +0000
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-bounces () 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-7d22ab83516c () nuclearfallout net>, John Weekes <jw () 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
Current thread:
- Re: Spitballing IoT Security, (continued)
- Re: Spitballing IoT Security Pierre Lamy (Oct 31)
- Re: Spitballing IoT Security Doug Barton (Oct 30)
- Re: Spitballing IoT Security Rich Kulawiec (Oct 30)
- Re: Spitballing IoT Security Jim Hickstein (Oct 30)
- Re: Spitballing IoT Security Eliot Lear (Oct 27)
- RE: Spitballing IoT Security Keith Medcalf (Oct 28)
- Re: Spitballing IoT Security Alan Buxey (Oct 29)
- Re: Spitballing IoT Security Chris Boyd (Oct 25)
- Re: Spitballing IoT Security Eliot Lear (Oct 28)
- Re: Spitballing IoT Security bzs (Oct 25)
- RE: Spitballing IoT Security Steve Mikulasik (Oct 24)
- Re: Spitballing IoT Security J. Oquendo (Oct 24)
- Re: Spitballing IoT Security Mike Hammett (Oct 24)
- Re: Spitballing IoT Security Hugo Slabbert (Oct 24)
- Re: Spitballing IoT Security Mike Hammett (Oct 24)
- Re: Spitballing IoT Security bzs (Oct 24)
- Re: Spitballing IoT Security Rich Kulawiec (Oct 26)
- Re: Spitballing IoT Security Eric S. Raymond (Oct 26)
- Re: Spitballing IoT Security Mel Beckman (Oct 26)
- Re: Spitballing IoT Security Eric S. Raymond (Oct 26)
- Re: Spitballing IoT Security Mel Beckman (Oct 26)
