[atlas] management access...?

I indeed agree that they would be a tempting target - IPv4 and IPv6 both.
However, they're low powered devices - DDoS sources, maybe - amplification
attacks. Don't see them doing any BitCoin mining any time soon :)

But yes, depending on where on the host network they sit, they could be
used as stepping stones . . . A good reason for people deploying a probe
to understand the inherent risks of deploying it.

And an opportunity for the Atlas community to share best
practices/deployment scenarios. My probe sits on a DMZ, w/o access to the
internal network. And I haven't implemented rate-limiting for it - but
come to think of it, it may be a good idea to do so - limit the probe to
512Kbps or less.



On 12/16/13 10:58 AM, "Nigel Titley" <nigel.titley at easynet.com> wrote:

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