[atlas] management access...?
Nigel Titley nigel.titley at easynet.com
Mon Dec 16 16:58:53 CET 2013
Of course it was an exaggeration.... but think about it.... 5000 identical machines with the same software. An exploit would go through them like a curry and a couple of pints of lager. Your half way house might be acceptable though Nigel -----Original Message----- From: Dario Ciccarone [mailto:dario.ciccarone at gmail.com] Sent: 16 December 2013 15:53 To: Nigel Titley; Robert Kisteleki; Gert Doering Cc: ripe-atlas at ripe.net Subject: Re: [atlas] management access...? I think that's a bit of an exaggeration :) I agree with Gert that probes need better diagnostic capabilities - and tcpdump just doesn't cut it. And probe or not probe, small form factor or not - it's a Linux box. I would like to be able to troubleshoot it like any other *nix box. There IS a middle ground here, I think. The current firmware image could stay as it is - no SSH, no incoming connections. A "full" image could be provided, that would allow: A) starting the SSH daemon B) configuring key-based authentication for SSH, allow importing of public keys C) configuring IP-based restrictions (iptables, or AllowUsers) As none of those would be the default configuration, and would NOT be enable thru the web-based admin interface, they shouldn't have a security impact on anyone that does NOT choose to enable them - but would be available for "power users", so to speak. On 12/16/13 10:23 AM, "Nigel Titley" <nigel.titley at easynet.com> wrote: >Speaking with my Board hat on at the moment, I do not want to wake up >one morning and read the headline "RIPE NCC deploys world's largest botnet" > >Keep them simple, keep them safe > >Nigel >-----Original Message----- >From: ripe-atlas-bounces at ripe.net [mailto:ripe-atlas-bounces at ripe.net] >On Behalf Of Robert Kisteleki >Sent: 16 December 2013 15:14 >To: Gert Doering >Cc: ripe-atlas at ripe.net >Subject: Re: [atlas] management access...? > >Hi Gert, > >> Better diagnostics at the atlas dashboard would have helped me, too, >> but for cases like "I think I have network by my DNS isn't working" >> or "I think I have network but can't connect to my controllers" >> errors, local data might still be beneficial. > >This is reasonable, but it leads to a place where probes *do* run >services that are open to "all". I guess it's possible to redefine "all" >to be "my local network" or "the same /24 or /64 as the probe" or such, >but that adds complexity and I'd be reluctant to go that way. > >What we're trying to do is what you describe above -- based on signals >sent by the probe we're trying to give useful clues to the hosts about >what's going on. We can look at the current diagnostics and see if we >already squeeze out as much diagnostics as possible. We also plan to >include IPv6 PMTU problems, broken local resolvers and such in an >upcoming iteration. > >Regards, >Robert > > >