[atlas] management access...?
Dario Ciccarone dario.ciccarone at gmail.com
Mon Dec 16 16:52:59 CET 2013
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 > > >