PATCH: sftp-server logging.

[Jason A. Dour]

On Mon, Mar 18, 2002 at 04:02:50AM -0800, Dan Kaminsky wrote:
> look.  the logs useful to programmers are not the logs useful to
> sysadmins, and just as it'd be rather disrespectful to tell you,
> the developer, that you could do *your* job without knowing what
> the hell the system was doing, it's just as wrong for you to tell
> the administrator deploying your code that he should be able to do
> his job without a clear and concise view of who transferred what.

This is exactly my point.  Thank you, Dan.

> there are of course issues in that users can execute their own
> sftp-server processes.  if you push it, that's a really good
> reason for somebody to stand up and say "sftp is less secure than
> ftp".  the solution is a sftp only ssh daemon with a locked build
> of sftp-server that logs to syslog(thus conveniently avoiding the
> user executed/root logged problem).

And this is where an overall picture comes into play, with usage of
chroot, limited shells, authorized commands, removal of
file-transfer other than sftp, et cetera.

Ultimately it could be that Open-SSH could take the (current) stance
that the bundled sftp-server is sufficient to meet the basic
standards set forth in the RFCs, and thus it is not necessary to add
anything such as logging.

Doing so would eventually necessitate a forking of the code,
however, and a separate project devoted to maintaining Open-SFTP,
leading to increased likelihood of flaws and increasing confusion
among the userbase.

This is silly, since sftp-server could easily be extended while
remaining integrated with the Open-SSH core, and would please a lot
of current and potential Open-SSH admins.

And this is not the only step to improving Open-SSH's design from an
ADMINSITRATOR'S point of view.  Technically, it is a great product,
written by great developers.  However, there are some things (such
as SFTP/SCP logging, authentication/authorization being mish-mashed
together, et cetera), that make it less than ideal.  This is just
the easiest to implement, and thus the first that I've tackled and
submitted.

> if you *must* have a security justification, fine.  dos attacks
> are a little easier to see when you're not getting 3498573985
> lines of debug a day anyway.

And it is easier to track intrustion vectors when you can track new
data that has been brought into your machine by utilities you
manage.  [XYZ]modem and FTP log...there's no reason sftp-server
shouldn't log as well.


Cheers,
Jason
# "Jason A. Dour" <jason at dour.org>                  http://dour.org/
# Founder / Executive Producer - PJ Harvey Online - http://pjh.org/