Re: Logging enhancement

Circa 2007-04-26 13:44 dixit Anderson Russell D (Andy):

: I think you read way to deep.
: I'm not talking about every keystroke.
: I'm talking basic syslog connection monitoring here.

I understand what you're talking about. I pointed out that your
"auditing" doesn't really accomplish that much; in fact, savvy attackers
could not only circumvent your auditing completely, but perhaps even use
it to hide what they're actually doing.

: There sure doesn't seem to be a problem with sshd logging connection
: info!

sshd is able to be controlled by the system administrator. It's the
place where logging should occur.

: There sure doesn't seem to be a problem populating client environment
: variables with connection info!
: SSH_CLIENT='10.10.10.100 2926 22'
: SSH_CONNECTION='10.10.10.100 2926 10.20.20.100 22'

These environment variables are set up by sshd, not by a client.

: I'm just asking why ssh can't do a basic sylog entry on a user like
: "su".

As i pointed out, the ssh client is the wrong spot to do the logging.

The 'su' program is the right spot for its logging, because the system
administrator can control what executables are owned by root and have
setuid permissions, and because those are the only executables that are
supposed to be able to grant a user additional privileges. That is,
there are a limited number of entry points to what is effectively an
'su' service.

The ssh client, however, is only one of a large possible number of entry
points into the sshd service.

: Maybe a ssh_config option that provides it for any ssh aware client
: (sftp, scp, etc).

Not all ssh clients read ssh_config. Not all ssh clients read the
ssh_config file controlled by the system administrator. Not all ssh
clients can be trusted to comply with options set in the system
administrator's ssh_config.

: And yes, your right, anyone can compile and run anything on any port.
: (including the sshd daemon).

Red herring. Users running sshd without root privileges can only
acquire their own credentials. A system administrator can stop users
from allowing remote connections to sshd processes they run using
firewall/packet-filter rules.

: I'm just talking about the probable 99% of users that use ssh
: out-of-the-box.
: The ssh client is always the starting point for most uses I'm aware of.

What's your goal with this auditing? Are you trying to track 99% of the
remote logins to your network, or 100%? If it's not 100%, you might as
well write a wrapper script for your ssh/scp/sftp clients which does the
logging and leave it at that.

: There are plenty of log analysis packages and correlation tools (sec.pl)
: that could take advantage of it. I guess I do not understand the
: reluctance, especially considering the nature of the product.

I'm not an OpenSSH developer (although I have contributed packaging,
testing, and the x11-ssh-askpass program). I don't speak for the
OpenSSH development team. I merely pointed out the flaws in your
proposal. These flaws make it rather unlikely that the OpenSSH
developers would incorporate your proposal into OpenSSH. Most folks who
use OpenSSH don't want to rely on auditing that only leaves an audit
trail for "dumb" people, letting attackers circumvent the auditing
completely.

I also made suggestions which take advantage of OpenSSH's current
logging which would be more effective and require no code changes on
your part. They would, however, require setting policies, which any
network concerned with auditing ought to do anyway.

: sshd server host syslog entry:
: Apr 26 09:26:01 hostB sshd[11486]:
: Accepted password for userB from 10.10.10.100 port 2926 ssh2
:
: Could be anyone, can't even make a stab in the dark.

Actually, setting up your firewall to log TCP packets containing a SYN
flag destined for port 22 any host, together with the user ID of the
process generating the packet, goes a long way toward correlating sshd's
entry with a user on the source machine. Linux's iptables is capable of
doing this with the LOG action and the '--log-uid' option.

Or, if connections are coming only from machines you control, set up an
ident server which you trust on those machines, and use TCP wrappers to
log the response from identd. Even easier to configure.

Both of these approaches capture information about every connection to
sshd servers from inside your network, except for tunneled connections.
In contrast, your approach captures only information from clients which
cooperate with your logging scheme.

Neither approach---nor your approach---is able to capture reliable
information about connections from untrusted machines outside your
network.

Using public key authentication together with administrator-controlled
authorized_keys files, however, allows you to capture information about
which identity is used to log in via sshd's normal logging, in every
case.

You still need policies to keep users from sharing private keys and
their passphrases, and to deal with subverted private keys. You need
these same policies in any case, including with your approach, to keep
users from sharing accounts and to deal with subverted user accounts.

: Sounded like hack your own or go commercial or other options:
: http://www.balabit.com/products/scb/

If you're willing to spring for something like the above, then fine ...
but that sounds to me like you're moving from a skateboard directly to a
rocket-propelled car. Not knowing more about your goals or
requirements, i'd recommend trying something in the middle first.

Good luck.

--
jim knoble | jmknoble@pobox.com | http://www.pobox.com/~jmknoble/
(GnuPG key ID: 6F39C2CC >>>>>> http://www.pobox.com/~jmknoble/keys/ )
(GnuPG fingerprint: 5024:D578:7CF4:5660:7269::F6F3:B919:9307:6F39:C2CC )
+----------------------------------------------------------------------+
|[L]iberty, as we all know, cannot flourish in a country that is perma-|
| nently on a war footing, or even a near-war footing. --Aldous Huxley|
+----------------------------------------------------------------------+
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
http://lists.mindrot.org/mailman/lis...enssh-unix-dev