8.6. 보안
PKCS #11 토큰이 원시 RSA 또는 RSA-PSS 서명 생성을 지원하는 경우 OpenSSL 은 이를 감지하지 않습니다.
TLS 1.3 프로토콜은 RSA-PSS 서명을 지원해야 합니다. PKCS #11 토큰이 원시 RSA 또는 RSA-PSS 서명을 지원하지 않는 경우 OpenSSL 라이브러리를 사용하는 서버 애플리케이션은 PKCS #11 토큰에서 키를 보유하는 경우 RSA 키로 작동하지 않습니다. 그 결과 설명된 시나리오에서 TLS 통신이 실패합니다.
이 문제를 해결하려면 TLS 버전 1.2를 사용 가능한 최고 TLS 프로토콜 버전으로 사용하도록 서버와 클라이언트를 구성합니다.
(BZ#1681178)
OpenSSL 이 raw RSA 또는 RSA-PSS 서명을 지원하지 않는 PKCS #11 토큰을 잘못 처리
OpenSSL 라이브러리는 PKCS #11 토큰의 키 관련 기능을 감지하지 않습니다. 결과적으로 원시 RSA 또는 RSA-PSS 서명을 지원하지 않는 토큰으로 서명이 생성될 때 TLS 연결 설정이 실패합니다.
이 문제를 해결하려면 /etc/pki/tls/openssl.cnf 파일의 crypto_policy 섹션 끝에 .include 행 뒤에 다음 행을 추가합니다.
SignatureAlgorithms = RSA+SHA256:RSA+SHA512:RSA+SHA384:ECDSA+SHA256:ECDSA+SHA512:ECDSA+SHA384 MaxProtocol = TLSv1.2
결과적으로 설명된 시나리오에서 TLS 연결을 설정할 수 있습니다.
(BZ#1685470)
FIPS가 승인되지 않은 암호화는 FIPS 모드에서 OpenSSL에서 작동하지 않음
FIPS가 승인되지 않은 암호화는 시스템 설정에 관계없이 OpenSSL 툴킷에서 작동합니다. 따라서 시스템이 FIPS 모드에서 실행될 때 비활성화해야 하는 암호화 알고리즘 및 암호를 사용할 수 있습니다. 예를 들면 다음과 같습니다.
- RSA 키 교환 작업을 사용하는 TLS 암호화 제품군.
- PKCS #1 및 SSLv23 패딩을 사용하거나 2048비트보다 짧은 키를 사용하더라도 공개 키 암호화 및 암호 해독을 위한 RSA 기반 알고리즘이 작동합니다.
OpenSSL은 FIPS 모드에서 엔진을 사용할 수 없습니다.
engine API는 OpenSSL 3.0에서 더 이상 사용되지 않으며 OpenSSL Federal Information Processing Standards (FIPS) 구현 및 기타 FIPS 호환 구현과 호환되지 않습니다. 따라서 OpenSSL은 FIPS 모드에서 엔진을 실행할 수 없습니다. 이 문제에 대한 해결방법은 없습니다.
PSK ciphersuites는 FUTURE 암호화 정책에서 작동하지 않습니다.
PSK(Pre-shared key) 암호화suites는 PFS(Smart forward secrecy) 키 교환 방법을 수행하는 것으로 인식되지 않습니다. 결과적으로 ECDHE-PSK 및 DHE-PSK 암호suites는 FUTURE 암호화 정책 (예: FUTURE crypto policy)과 함께 구성된 OpenSSL에서 작동하지 않습니다. 이 문제를 해결하려면 덜 제한적인 암호화 정책을 설정하거나 PSK 암호suites를 사용하는 애플리케이션에 대해 낮은 보안 수준(ECLEVEL)을 설정할 수 있습니다.
GnuPG를 잘못 사용하면 암호화에서 허용되지 않는 경우에도 SHA-1 서명을 사용할 수 있습니다.
GnuPG(GNUPG) 암호화 소프트웨어는 시스템 전체의 암호화 정책에 정의된 설정과 관계없이 SHA-1 알고리즘을 사용하는 서명을 생성하고 확인할 수 있습니다. 따라서 DEFAULT 암호화 정책의 암호화 목적에 SHA-1을 사용할 수 있으며 이는 서명에 대해 이 안전하지 않은 알고리즘의 시스템 전체 사용 중단과 일치하지 않습니다.
이 문제를 해결하려면 SHA-1과 관련된 GnuPG 옵션을 사용하지 마십시오. 결과적으로 보안되지 않은 SHA-1 서명을 사용하여 GnuPG가 기본 시스템 보안을 낮추지 않도록 합니다.
일부 OpenSSH 작업은 FIPS 승인 인터페이스를 사용하지 않습니다.
OpenSSH에서 사용하는 OpenSSL 암호화 라이브러리는 레거시 및 최신의 두 가지 인터페이스를 제공합니다. OpenSSL 내부가 변경되어 최신 인터페이스만 암호화 알고리즘의 FIPS 인증 구현을 사용합니다. OpenSSH는 일부 작업에 기존 인터페이스를 사용하므로 FIPS 요구 사항을 준수하지 않습니다.
GPG-agent 가 FIPS 모드에서 SSH 에이전트로 작동하지 않음
gpg-agent 툴은 FIPS 모드에서 MD5 다이제스트를 비활성화하더라도 ssh-agent 프로그램에 키를 추가할 때 MD5 지문을 생성합니다. 결과적으로 ssh-add 유틸리티에서 키를 인증 에이전트에 추가하지 못했습니다.
이 문제를 해결하려면 gpg-agent --daemon --enable-ssh-support 명령을 사용하지 않고 ~/.gnupg/sshcontrol 파일을 만듭니다. 예를 들어 < FINGERPRINT> 0 형식으로 gpg --list-keys 명령의 출력을 ~/.gnupg/sshcontrol 에 붙여넣을 수 있습니다. 결과적으로 gpg-agent 는 SSH 인증 에이전트로 작동합니다.
SELinux staff_u 사용자가 unconfined_r로 잘못 전환할 수 있습니다.
secure_mode 부울이 활성화되면 staff_u 사용자가 unconfined_r 역할로 잘못 전환할 수 있습니다. 결과적으로 staff_u 사용자는 시스템의 보안에 영향을 미치는 권한 있는 작업을 수행할 수 있습니다.
기본 SELinux 정책을 통해 제한되지 않은 실행 파일로 스택을 실행할 수 있습니다.
SELinux 정책에 있는 selinuxuser_execstack 부울의 기본 상태는 에 있습니다. 즉, Bitbucket 실행 파일이 스택을 실행 가능하게 만들 수 있습니다. 실행 파일은 이 옵션을 사용하지 않아야 하며 잘못 코딩된 실행 파일이나 가능한 공격을 나타낼 수 있습니다. 그러나 Red Hat은 다른 툴, 패키지 및 타사 제품과의 호환성으로 인해 기본 정책에서 부울의 값을 변경할 수 없습니다. 시나리오가 이러한 호환성 측면에 의존하지 않는 경우 명령 setsebool -P selinuxuser_execstack을 입력하여 로컬 정책에서 부울을 켤 수 있습니다.
Kickstart 설치 중 서비스 관련 규칙 수정에 실패할 수 있습니다.
Kickstart 설치 중에 OpenSCAP 유틸리티에서 서비스 활성화 또는 비활성화 상태 수정이 필요하지 않은 것으로 잘못 표시되는 경우가 있습니다. 그 결과 OpenSCAP에서 설치된 시스템의 서비스를 비준수 상태로 설정할 수 있습니다. 이 문제를 해결하려면 Kickstart 설치 후 시스템을 스캔하고 수정할 수 있습니다. 이렇게 하면 서비스 관련 문제가 해결됩니다.
ImageStreamTag 프로필의 SSH 시간 초과 규칙 구성 잘못된 옵션
OpenSSH 업데이트는 다음과 같은 Defense 정보 시스템국(DISAonnectionFactory) 프로필의 규칙에 영향을 미쳤습니다.
-
DISA STIG for RHEL 9 (
xccdf_org.ssgproject.content_profile_stig) -
RHEL 9용 GUI(
xccdf_org.ssgproject.content_profile_stig_gui)
이러한 각 프로필에서는 다음 두 가지 규칙이 영향을 받습니다.
Title: Set SSH Client Alive Count Max to zero CCE Identifier: CCE-90271-8 Rule ID: xccdf_org.ssgproject.content_rule_sshd_set_keepalive_0 Title: Set SSH Idle Timeout Interval CCE Identifier: CCE-90811-1 Rule ID: xccdf_org.ssgproject.content_rule_sshd_set_idle_timeout
SSH 서버에 적용할 때 이러한 각 규칙은 더 이상 이전처럼 작동하지 않는 옵션(ClientAliveCountMax 및 ClientAliveInterval)을 구성합니다. 결과적으로 이러한 규칙에서 구성한 타임아웃에 도달하면 OpenSSH는 더 이상 유휴 SSH 사용자의 연결을 끊지 않습니다. 해결 방법으로 이러한 규칙은 솔루션이 개발될 때까지 RHEL 9용 GUI를 사용하여 DISA organization에서 임시로 제거되었으며, RHEL 9용 GUI를 사용하여 이러한 규칙이 일시적으로 제거되었습니다.
fagenrules --load 가 제대로 작동하지 않음
fapolicyd 서비스는 SIGHUP(SIGHUP) 신호를 올바르게 처리하지 않습니다. 결과적으로 SIGHUP 신호를 수신한 후 fapolicyd 가 종료됩니다. 따라서 fagenrules --load 명령이 제대로 작동하지 않으며 규칙 업데이트에서는 fapolicyd 를 수동으로 다시 시작해야 합니다. 이 문제를 해결하려면 규칙이 변경된 후 fapolicyd 서비스를 다시 시작하고 결과적으로 fagenrules --load 가 올바르게 작동합니다.
Ansible 수정에는 추가 컬렉션이 필요합니다.
ansible-core 패키지에서 Ansible Engine을 교체하면 RHEL 서브스크립션과 함께 제공되는 Ansible 모듈 목록이 줄어듭니다. 결과적으로 scap-security-guide 패키지에 포함된 Ansible 콘텐츠를 사용하는 수정을 실행하려면 rhc-worker-playbook 패키지의 컬렉션이 필요합니다.
Ansible 수정을 위해 다음 단계를 수행합니다.
필수 패키지를 설치합니다.
# dnf install -y ansible-core scap-security-guide rhc-worker-playbook
-
/usr/share/scap-security-guide/ansible디렉토리로 이동합니다. # cd /usr/share/scap-security-guide/ansible 추가 Ansible 컬렉션 경로를 정의하는 환경 변수를 사용하여 관련 Ansible 플레이북을 실행합니다.
# ANSIBLE_COLLECTIONS_PATH=/usr/share/rhc-worker-playbook/ansible/collections/ansible_collections/ ansible-playbook -c local -i localhost, rhel9-playbook-cis_server_l1.ymlcis_server_l1을 시스템을 수정하려는 프로필의 ID로 바꿉니다.
결과적으로 Ansible 콘텐츠가 올바르게 처리됩니다.
rhc-worker-playbook 에 제공된 컬렉션 지원은 scap-security-guide 에서 제공되는 Ansible 콘텐츠를 사용하도록 제한됩니다.
