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@gmail.com] Sent: 16 December 2013 15:53 To: Nigel Titley; Robert Kisteleki; Gert Doering Cc: ripe-atlas@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@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@ripe.net [mailto:ripe-atlas-bounces@ripe.net] On Behalf Of Robert Kisteleki Sent: 16 December 2013 15:14 To: Gert Doering Cc: ripe-atlas@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