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.
It is not standard practice to have listable AND writable directories
on anonymous ftp servers. 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
...
In this case none of the directories under /pub should be listable
except perhaps //custX. Whether or not //custX needs to be
listable depends on the technical skills of the customer.
It is also standard practice to keep detailed logs of all ftp access
and monitor, run IDS, and reports on those periodically. Since
this is not typically practical using Microsoft software it looks
like a straightforward case of 3 strikes you're hacked.
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