[36913] in North American Network Operators' Group
Re: Information from an FTP violation this weekend
daemon@ATHENA.MIT.EDU (Adam Rothschild)
Wed Apr 25 18:44:44 2001
Date: Wed, 25 Apr 2001 18:42:44 -0400
From: Adam Rothschild <asr@latency.net>
To: Roger Marquis <marquis@roble.com>
Cc: nanog@merit.edu
Message-ID: <20010425184244.F7757@og.latency.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.BSF.4.21.0104251416370.19188-100000@roble.com>; from marquis@roble.com on Wed, Apr 25, 2001 at 02:17:52PM -0700
Errors-To: owner-nanog-outgoing@merit.edu
On Wed, Apr 25, 2001 at 02:17:52PM -0700, Roger Marquis wrote:
> I think the point was (inadvertently made) that this site
> (209.123.52.40, NAC-NETBLK02, nac.net, running NEPTUNE Microsoft
> FTP) has a security problem.
Yeah, I'd say:
% telnet 209.123.52.40 21
[...]
220 NEPTUNE Microsoft FTP Service (Version 5.0).
Looks like the compromised (?) machine belongs to a NAC customer; have
you tried contacting this customer offline?
> It is not standard practice to have listable AND writable directories
> on anonymous ftp servers.
I'm not sure what standard practice dictates, but I'd hope the norm
isn't to run FTP at all for such things.
> If customers need to upload files they should also have individual
> directories under an unreadable directory tree i.e.,
>
> /upload/a9-ns/custX
> /upload/0igm19/custY
> ...
Why not have them ssh/scp over the data, possibly using a sufficiently
tight configuration that only allows a given RSA/DSA key to execute
what's absolutely necessary, or something? Or for the severely
stubborn and clue-impaired, use a https-based web upload tool?
Need I mention why clear text file transfers of sensitive data are bad?
:-)
-adam
