A patch for the SSH bug that bypassed the MaxAuthTries limit was just patched. Has MaxAuthTries been considered as a control in the security guide?
http://www.openssh.com/txt/release-7.0 https://threatpost.com/openssh-7-0-fixes-four-flaws/114265
I use pam_tally2 for that.
Paul Whitney email: paul.whitney@mac.com cell: 410.493.9448
Sent from my iPhone
On Aug 14, 2015, at 13:47, Ron Colvin Ron.Colvin@nasa.gov wrote:
A patch for the SSH bug that bypassed the MaxAuthTries limit was just patched. Has MaxAuthTries been considered as a control in the security guide?
http://www.openssh.com/txt/release-7.0 https://threatpost.com/openssh-7-0-fixes-four-flaws/114265
--
Ron Colvin CISSP, CAP, CEH Certified Security Analyst NASA - Goddard Space Flight Center ron.colvin@nasa.gov Direct phone 301-286-2451 NASA Jabber (rdcolvin@im.nasa.gov) AIM rcolvin13 NASA LCS (ronald.d.colvin@nasa.gov)
OK. I was mostly looking for a scorable control(s).
On 8/14/15 2:34 PM, Paul Whitney wrote:
I use pam_tally2 for that.
Paul Whitney email: paul.whitney@mac.com cell: 410.493.9448
Sent from my iPhone
On Aug 14, 2015, at 13:47, Ron Colvin Ron.Colvin@nasa.gov wrote:
A patch for the SSH bug that bypassed the MaxAuthTries limit was just patched. Has MaxAuthTries been considered as a control in the security guide?
http://www.openssh.com/txt/release-7.0 https://threatpost.com/openssh-7-0-fixes-four-flaws/114265
--
Ron Colvin CISSP, CAP, CEH Certified Security Analyst NASA - Goddard Space Flight Center ron.colvin@nasa.gov Direct phone 301-286-2451 NASA Jabber (rdcolvin@im.nasa.gov) AIM rcolvin13 NASA LCS (ronald.d.colvin@nasa.gov)
In my view, this would fall under CVEs -- SSG is used to verify configuration compliance (CCEs).
-- Paul C. Arnold IT Systems Engineer Cole Engineering Services, Inc.
________________________________________ From: scap-security-guide-bounces@lists.fedorahosted.org [scap-security-guide-bounces@lists.fedorahosted.org] on behalf of Ron Colvin [Ron.Colvin@nasa.gov] Sent: Friday, August 14, 2015 01:47 PM To: SCAP Security Guide Subject: OpenSSH patch
A patch for the SSH bug that bypassed the MaxAuthTries limit was just patched. Has MaxAuthTries been considered as a control in the security guide?
http://www.openssh.com/txt/release-7.0 https://threatpost.com/openssh-7-0-fixes-four-flaws/114265
--
******************************************************** Ron Colvin CISSP, CAP, CEH Certified Security Analyst NASA - Goddard Space Flight Center ron.colvin@nasa.gov Direct phone 301-286-2451 NASA Jabber (rdcolvin@im.nasa.gov) AIM rcolvin13 NASA LCS (ronald.d.colvin@nasa.gov) ********************************************************
The CVE in this case was to remedy a flaw that allowed the MaxAuthTries limit to be bypassed. The security guide has no control for MaxAuthTries. The CIS Benchmark control for RHEL 6 is 4.
On 8/14/15 2:41 PM, Arnold, Paul C CTR USARMY PEO STRI (US) wrote:
In my view, this would fall under CVEs -- SSG is used to verify configuration compliance (CCEs).
-- Paul C. Arnold IT Systems Engineer Cole Engineering Services, Inc.
From: scap-security-guide-bounces@lists.fedorahosted.org [scap-security-guide-bounces@lists.fedorahosted.org] on behalf of Ron Colvin [Ron.Colvin@nasa.gov] Sent: Friday, August 14, 2015 01:47 PM To: SCAP Security Guide Subject: OpenSSH patch
A patch for the SSH bug that bypassed the MaxAuthTries limit was just patched. Has MaxAuthTries been considered as a control in the security guide?
http://www.openssh.com/txt/release-7.0 https://threatpost.com/openssh-7-0-fixes-four-flaws/114265
--
Ron Colvin CISSP, CAP, CEH Certified Security Analyst NASA - Goddard Space Flight Center ron.colvin@nasa.gov Direct phone 301-286-2451 NASA Jabber (rdcolvin@im.nasa.gov) AIM rcolvin13 NASA LCS (ronald.d.colvin@nasa.gov)
On 8/14/15 2:44 PM, Ron Colvin wrote:
The CVE in this case was to remedy a flaw that allowed the MaxAuthTries limit to be bypassed. The security guide has no control for MaxAuthTries.
SSG configures authentication retries at a system level through PAM via the accounts_password_pam_retry rule. Ref: https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/6/input/sys...
The accounts_password_pam_retry is selected in most profiles (DoD STIG, CS2, CCP...) and should provide a scoreable/verifiable control that Ron referenced.
The CIS Benchmark control for RHEL 6 is 4.
The quality of the CIS hardening guides for Red Hat technologies is unknown; we do not formally review them.
Ideology differs between Red Hat and CIS. The purpose of SSG is to get security configuration guidance and automation into the public, into the technology natively (e.g. shipping in RHEL), and developed in an open community with open (in our case, public domain) licensing. CIS charges membership and licensing fees for their content which doesn't mesh.
On Friday, August 14, 2015 01:47:49 PM Ron Colvin wrote:
A patch for the SSH bug that bypassed the MaxAuthTries limit was just patched. Has MaxAuthTries been considered as a control in the security guide?
The default value for this is set to "no". We set UsePam to "yes". Some platforms do not have PAM and openssh replicates some of that functionality in their code. If you want to control the maximum number of login attempts, you should use the pam_faillock module. It is an improvement over pam_tally2 in that it tracks login attempts per user. Pam_tally2 is global. Both are hooked into the audit system while openssh's MaxAuthTries is not.
HTH...
-Steve
+1 to PAM over internal SSH controls.
SIMP ties it back to both the local system faillock as well as LDAP controls for full environment lockouts.
Trevor
On Fri, Aug 14, 2015 at 3:33 PM, Steve Grubb sgrubb@redhat.com wrote:
On Friday, August 14, 2015 01:47:49 PM Ron Colvin wrote:
A patch for the SSH bug that bypassed the MaxAuthTries limit was just patched. Has MaxAuthTries been considered as a control in the security guide?
The default value for this is set to "no". We set UsePam to "yes". Some platforms do not have PAM and openssh replicates some of that functionality in their code. If you want to control the maximum number of login attempts, you should use the pam_faillock module. It is an improvement over pam_tally2 in that it tracks login attempts per user. Pam_tally2 is global. Both are hooked into the audit system while openssh's MaxAuthTries is not.
HTH...
-Steve
SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
On 8/14/15 3:33 PM, Steve Grubb wrote:
On Friday, August 14, 2015 01:47:49 PM Ron Colvin wrote:
A patch for the SSH bug that bypassed the MaxAuthTries limit was just patched. Has MaxAuthTries been considered as a control in the security guide?
The default value for this is set to "no". We set UsePam to "yes". Some platforms do not have PAM and openssh replicates some of that functionality in their code. If you want to control the maximum number of login attempts, you should use the pam_faillock module. It is an improvement over pam_tally2 in that it tracks login attempts per user. Pam_tally2 is global. Both are hooked into the audit system while openssh's MaxAuthTries is not.
While we configure PAM controls, and assume SSH is using them via "UsePam yes", there isn't a validation check for "UsePam." Should there be?
+1 on Shawn's observation: "The purpose of SSG is to get security configuration guidance and automation into the public, into the technology natively (e.g. shipping in RHEL), and developed in an open community with open (in our case, public domain) licensing."
Greg
On Mon, Aug 17, 2015 at 12:18 PM, Shawn Wells shawn@redhat.com wrote:
On 8/14/15 3:33 PM, Steve Grubb wrote:
On Friday, August 14, 2015 01:47:49 PM Ron Colvin wrote:
A patch for the SSH bug that bypassed the MaxAuthTries limit was just patched. Has MaxAuthTries been considered as a control in the security guide?
The default value for this is set to "no". We set UsePam to "yes". Some platforms do not have PAM and openssh replicates some of that functionality in their code. If you want to control the maximum number of login attempts, you should use the pam_faillock module. It is an improvement over pam_tally2 in that it tracks login attempts per user. Pam_tally2 is global. Both are hooked into the audit system while openssh's MaxAuthTries is not.
While we configure PAM controls, and assume SSH is using them via "UsePam yes", there isn't a validation check for "UsePam." Should there be?
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
+1 from me as well.
On Mon, Aug 17, 2015 at 12:22 PM, Greg Elin gregelin@gitmachines.com wrote:
+1 on Shawn's observation: "The purpose of SSG is to get security configuration guidance and automation into the public, into the technology natively (e.g. shipping in RHEL), and developed in an open community with open (in our case, public domain) licensing."
Greg
On Mon, Aug 17, 2015 at 12:18 PM, Shawn Wells shawn@redhat.com wrote:
On 8/14/15 3:33 PM, Steve Grubb wrote:
On Friday, August 14, 2015 01:47:49 PM Ron Colvin wrote:
A patch for the SSH bug that bypassed the MaxAuthTries limit was just patched. Has MaxAuthTries been considered as a control in the security guide?
The default value for this is set to "no". We set UsePam to "yes". Some platforms do not have PAM and openssh replicates some of that functionality in their code. If you want to control the maximum number of login attempts, you should use the pam_faillock module. It is an improvement over pam_tally2 in that it tracks login attempts per user. Pam_tally2 is global. Both are hooked into the audit system while openssh's MaxAuthTries is not.
While we configure PAM controls, and assume SSH is using them via "UsePam yes", there isn't a validation check for "UsePam." Should there be?
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
On Monday, August 17, 2015 12:18:44 PM Shawn Wells wrote:
On 8/14/15 3:33 PM, Steve Grubb wrote:
On Friday, August 14, 2015 01:47:49 PM Ron Colvin wrote:
A patch for the SSH bug that bypassed the MaxAuthTries limit was just patched. Has MaxAuthTries been considered as a control in the security guide?
The default value for this is set to "no". We set UsePam to "yes". Some platforms do not have PAM and openssh replicates some of that functionality in their code. If you want to control the maximum number of login attempts, you should use the pam_faillock module. It is an improvement over pam_tally2 in that it tracks login attempts per user. Pam_tally2 is global. Both are hooked into the audit system while openssh's MaxAuthTries is not.
While we configure PAM controls, and assume SSH is using them via "UsePam yes", there isn't a validation check for "UsePam." Should there be?
In this particular case, it might be good to have in place. There could also be legitimate uses with it being no. The reason I go along with the check is because other checks are predicated with pam being in use,
That said, are there checks that /etc/pam.d/sshd is in the correct configuration? :-)
-Steve
scap-security-guide@lists.fedorahosted.org
-
Arnold, Paul C CTR USARMY PEO STRI (US) -
Greg Elin -
Paul Whitney -
Ron Colvin -
Shawn Wells -
Steve Grubb -
Trevor Vaughan