11.2. 보안
PKCS #11 토큰이 원시 RSA 또는 RSA-PSS 서명 생성을 지원하는 경우 OpenSSL이 탐지되지 않음
TLS 1.3 프로토콜은 RSA-PSS 서명을 지원해야 합니다. PKCS #11 토큰이 원시 RSA 또는 RSA-PSS 서명을 지원하지 않는 경우 PKCS #11 토큰이 있는 경우 OpenSSL 라이브러리를 사용하는 서버 애플리케이션이 RSA 키로 작동하지 않습니다. 결과적으로 설명된 시나리오에서 TLS 통신이 실패합니다.
이 문제를 해결하려면 TLS 버전 1.2를 사용 가능한 최고 TLS 프로토콜 버전으로 사용하도록 서버 및 클라이언트를 구성합니다.
Bugzilla:1681178[1]
OpenSSL 이 원시 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 연결을 설정할 수 있습니다.
Bugzilla:1685470[1]
특정 구문을 사용하여 자체적으로 복사된 파일을 scp empties합니다.
scp 유틸리티는 SCP(Secure copy protocol)에서 더 안전한 SSH 파일 전송 프로토콜(SFTP)으로 변경되었습니다. 결과적으로 위치에서 동일한 위치로 파일을 복사하면 파일 콘텐츠가 지워집니다. 이 문제는 다음 구문에 영향을 미칩니다.
SCP localhost:/myfile localhost:/myfile
이 문제를 해결하려면 이 구문을 사용하여 소스 위치와 동일한 파일을 대상에 복사하지 마십시오.
다음 구문에 대한 문제가 해결되었습니다.
-
scp /myfile localhost:/myfile -
scp localhost:~/myfile ~/myfile
OSCAP Anaconda 애드온은 그래픽 설치에서 맞춤형 프로필을 가져오지 않습니다.
OSCAP Anaconda 애드온은 RHEL 그래픽 설치에서 보안 프로필의 맞춤을 선택하거나 선택 해제할 수 있는 옵션을 제공하지 않습니다. RHEL 8.8부터는 아카이브 또는 RPM 패키지에서 설치할 때 애드온은 기본적으로 고려되지 않습니다. 결과적으로 설치 시 OSCAP 맞춤형 프로필을 가져오는 대신 다음 오류 메시지가 표시됩니다.
There was an unexpected problem with the supplied content.
이 문제를 해결하려면 Kickstart 파일의 %addon org_fedora_oscap 섹션에 경로를 지정해야 합니다. 예를 들면 다음과 같습니다.
xccdf-path = /usr/share/xml/scap/sc_tailoring/ds-combined.xml tailoring-path = /usr/share/xml/scap/sc_tailoring/tailoring-xccdf.xml
결과적으로 해당 Kickstart 사양에서만 OSCAP 맞춤형 프로필에 대해 그래픽 설치를 사용할 수 있습니다.
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 콘텐츠를 활성화하는 것으로 제한됩니다.
Keylime이 연결된 PEM 인증서를 허용하지 않음
Keylime이 단일 파일에 연결된 PEM 형식의 여러 인증서로 인증서 체인을 수신하면 keylime-agent-rust Keylime 구성 요소가 서명 확인 중에 제공된 모든 인증서를 올바르게 사용하지 않아 TLS 핸드셰이크 오류가 발생합니다. 결과적으로 클라이언트 구성 요소(keylime_verifier 및 keylime_tenant)는 Keylime 에이전트에 연결할 수 없습니다. 이 문제를 해결하려면 여러 인증서 대신 하나의 인증서만 사용하십시오.
Jira:RHELPLAN-157225[1]
Keylime은 다이제스트가 백슬래시로 시작하는 런타임 정책을 거부합니다.
런타임 정책 생성을 위한 현재 스크립트인 create_runtime_policy.sh 에서는 SHA 체크섬 함수(예: sha256sum )를 사용하여 파일 다이제스트를 계산합니다. 그러나 입력 파일 이름에 백슬래시 또는 \n 이 포함된 경우 체크섬 함수는 출력의 다이제스트 앞에 백슬래시를 추가합니다. 이러한 경우 생성된 정책 파일이 잘못된 형식으로 표시됩니다. 잘못된 형식의 정책 파일을 제공하면 Keylime 테넌트에서 다음과 같은 오류 메시지를 생성합니다 . me.tenant - ERROR - 응답 코드 400: 런타임 정책은 잘못된 형식 입니다. 이 문제를 해결하려면 다음 명령을 입력하여 잘못된 정책 파일에서 백슬래시를 수동으로 제거하십시오. sed -i 's/^\\//g' <malformed_file_name>.
Jira:RHEL-11867[1]
Keylime 에이전트는 업데이트 후 확인자 요청 거부
Keylime 에이전트의 API 버전 번호(keylime-agent-rust)가 업데이트되면 에이전트는 다른 버전을 사용하는 요청을 거부합니다. 결과적으로 Keylime 에이전트가 확인자에 추가된 후 업데이트되면 확인자가 이전 API 버전을 사용하여 에이전트에 연결을 시도합니다. 에이전트는 이 요청을 거부하고 인증에 실패합니다. 이 문제를 해결하려면 에이전트를 업데이트하기 전에 검증자(keylime-verifier)를 업데이트합니다(keylime-agent-rust). 결과적으로 에이전트가 업데이트되면 검증기에서 API 변경을 감지하고 그에 따라 저장된 데이터를 업데이트합니다.
Jira:RHEL-1518[1]
fapolicyd 유틸리티에서 변경된 파일을 잘못 실행할 수 있습니다.
올바르게 파일의 IMA 해시는 파일을 변경한 후 업데이트해야 하며 fapolicyd 는 변경된 파일의 실행을 방지해야 합니다. 그러나 이는 IMA 정책 설정의 차이점과 evctml 유틸리티의 파일 해시로 인해 발생하지 않습니다. 결과적으로 IMA 해시는 변경된 파일의 확장된 속성에서 업데이트되지 않습니다. 결과적으로 fapolicyd 에서 변경된 파일을 잘못 실행할 수 있습니다.
Jira:RHEL-520[1]
기본 SELinux 정책을 사용하면 제한되지 않은 실행 파일이 스택을 실행 가능하게 만들 수 있습니다.
SELinux 정책에서 selinuxuser_execstack 부울의 기본 상태는 on입니다. 즉, 제한되지 않은 실행 파일이 스택을 실행 가능하게 만들 수 있습니다. 실행 파일은 이 옵션을 사용하지 않아야 하며 잘못 코딩된 실행 파일 또는 가능한 공격을 나타낼 수 있습니다. 그러나 다른 툴, 패키지 및 타사 제품과의 호환성으로 인해 Red Hat은 기본 정책의 부울 값을 변경할 수 없습니다. 시나리오가 이러한 호환성 측면에 의존하지 않는 경우 setsebool -P selinuxuser_execstack off 명령을 입력하여 로컬 정책에서 부울을 끌 수 있습니다.
STIG 프로필의 SSH 시간 제한 규칙에서 잘못된 옵션 구성
OpenSSH 업데이트는 다음 Defense Information Systems Agency Security Technical Implementation Guide (DISA STIG) 프로파일의 규칙에 영향을 미쳤습니다.
-
DISA STIG for RHEL 9 (
xccdf_org.ssgproject.content_profile_stig) -
DISA STIG with GUI for RHEL 9 (
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용 DISA STIG 및 GUI for RHEL 9 프로필의 DISA STIG에서 일시적으로 제거되었습니다.
GnuPG는 crypto-policies에서 허용하지 않는 경우에도 SHA-1 서명을 잘못 사용할 수 있습니다.
GNU Privacy Guard(GnuPG) 암호화 소프트웨어는 시스템 전체 암호화 정책에 정의된 설정과 관계없이 SHA-1 알고리즘을 사용하는 서명을 생성하고 확인할 수 있습니다. 결과적으로 DEFAULT 암호화 정책의 암호화 목적으로 SHA-1을 사용할 수 있습니다. 이는 서명에 대해 안전하지 않은 알고리즘의 시스템 전체 사용 중단과 일치하지 않습니다.
이 문제를 해결하려면 SHA-1과 관련된 GnuPG 옵션을 사용하지 마십시오. 결과적으로 GnuPG가 비보안 SHA-1 서명을 사용하여 기본 시스템 보안을 낮추지 않도록 합니다.
OpenSCAP 메모리 사용량 문제
메모리가 제한된 시스템에서 OpenSCAP 스캐너가 미리 중지되거나 결과 파일을 생성하지 못할 수 있습니다. 이 문제를 해결하려면 전체 / 파일 시스템에 대한 재귀와 관련된 규칙을 선택 해제하도록 스캔 프로필을 사용자 지정할 수 있습니다.
-
rpm_verify_hashes -
rpm_verify_permissions -
rpm_verify_ownership -
file_permissions_unauthorized_world_writable -
no_files_unowned_by_user -
dir_perms_world_writable_system_owned -
file_permissions_unauthorized_suid -
file_permissions_unauthorized_sgid -
file_permissions_ungroupowned -
dir_perms_world_writable_sticky_bits
자세한 내용 및 해결 방법은 관련 지식 베이스 문서를 참조하십시오.
Kickstart 설치 중 서비스 관련 규칙 수정에 실패할 수 있습니다.
Kickstart 설치 중에 OpenSCAP 유틸리티에서 서비스 활성화 또는 비활성화 상태 수정이 필요하지 않은 것으로 잘못 표시되는 경우가 있습니다. 그 결과 OpenSCAP에서 설치된 시스템의 서비스를 비준수 상태로 설정할 수 있습니다. 이 문제를 해결하려면 Kickstart 설치 후 시스템을 스캔하고 수정할 수 있습니다. 이렇게 하면 서비스 관련 문제가 해결됩니다.
