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