RE: Matching SSHD information in audit logs
-----Message d'origine-----
De : Steve Grubb [mailto:sgrubb@redhat.com]
Envoyé : mardi 17 décembre 2019 15:21
À : linux-audit(a)redhat.com
Cc : MAUPERTUIS, PHILIPPE
Objet : Re: Matching SSHD information in audit logs
On Tuesday, December 17, 2019 5:57:53 AM EST MAUPERTUIS, PHILIPPE
wrote:
> Hi,
> When setting the SSHD log level to verbose as recommended by the CIS, I
get
> the following in the secure log : Dec 17 11:32:29 myserver sshd[8456]:
> Connection from xx.xx.xx.xx port 44090 on xx.xx.xx.xx port 22 Dec 17
> 11:32:30 myserver sshd[8456]: Accepted key RSA SHA256: qhpzQKKbwaX8
found
> at /usr/bin/sss_ssh_authorizedkeys:1 Dec 17 11:32:30 myserver
sshd[8456]:
> Postponed publickey for myuser from xx.xx.xx.xx port 44090 ssh2
[preauth]
> Dec 17 11:32:30 myserver sshd[8456]: Accepted key RSA SHA256:
qhpzQKKbwaX8
> found at /usr/bin/sss_ssh_authorizedkeys:1 Dec 17 11:32:30 myserver
> sshd[8456]: Accepted publickey for myuser from xx.xx.xx.xx port 44090
> ssh2: RSA SHA256: qhpzQKKbwaX8 Dec 17 11:32:30 myserver sshd[8456]:
> pam_unix(sshd:session): session opened for user myuser by (uid=0) Dec 17
> 11:32:31 myserver sshd[8456]: User child is on pid 8460
> Dec 17 11:32:31 myserver sshd[8460]: Starting session: shell on pts/4 for
> myuser from xx.xx.xx.xx port 44090 id 0
>
> What are the corresponding events in audit ?
I don't think anyone has ever tried to map between syslog and audit. I also
think that CIS maybe doesn't understand audit and how it works. For quite
some time, there has been a requirement to log any key lifecycle in the audit
logs. This means that the DH key exchange and the session keys get logged
when they are created and when they are destroyed. Also, pam logs the
session
beginning and end. And sshd logs any keys that it accepts. So, I think the
information is there if one wanted or needed to map between them. But it
should be unnecessary. I'm not sure what CIS is looking for in syslog.
Because if there is something important in syslog that is not in the audit
logs, I'd like to know what it is.
> My main concern is with the bold line which indicates how the public key
> was granted
That should also be in the audit logs.
I find in the audit log which key has been
accepted but not that it has been accepted due to /usr/bin/sss_ssh_authorizedkeys (and not
a local authorized_keys file).
In the USER_AUTH message I can see a field grantors=auth-key but I don't know how to
interpret it.
I had a look at
https://github.com/linux-audit/audit-documentation/blob/master/specs/fiel...
but grantor is not mentioned there
I didn't other fields as well :
From SOFTWARE_UPDATE the fields sw, sw_type, key_enforce are not
listed.
The page
https://github.com/linux-audit/audit-documentation/blob/master/specs/mess...
doesn't mention the type SOFTWARE_UPDATE
Maybe I am looking at the wrong place, Where should I look ?
> Could you point me to a documentation showing which events a ssh login
> would generate ?
To my knowledge, there is no document that singles out what a sshd login
should look like. There are documents that explain what the record type are.
And you should be able to isolate them by ausearch -x sshd.
What I missed was this ausearch -x sshd which gives me the events
-Steve
Philippe
equensWorldline is a registered trade mark and trading name owned by the Worldline Group
through its holding company.
This e-mail and the documents attached are confidential and intended solely for the
addressee. If you receive this e-mail in error, you are not authorized to copy, disclose,
use or retain it. Please notify the sender immediately and delete this email from your
systems. As emails may be intercepted, amended or lost, they are not secure.
EquensWorldline and the Worldline Group therefore can accept no liability for any errors
or their content. Although equensWorldline and the Worldline Group endeavours to maintain
a virus-free network, we do not warrant that this transmission is virus-free and can
accept no liability for any damages resulting from any virus transmitted. The risks are
deemed to be accepted by everyone who communicates with equensWorldline and the Worldline
Group by email