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