[atlas] management access...?

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
>
>
>