11.6. 보안
OpenSSL 은 PKCS #11 토큰이 원시 RSA 또는 RSA-PSS 서명 생성을 지원하는지 탐지하지 않습니다.
TLS 1.3 프로토콜은 RSA-PSS 서명을 지원해야 합니다. PKCS #11 토큰이 원시 RSA 또는 RSA-PSS 서명을 지원하지 않는 경우, OpenSSL 라이브러리를 사용하는 서버 애플리케이션은 PKCS #11 토큰에서 키를 보유하는 경우 RSA 키로 작동하지 않습니다. 따라서 설명된 시나리오에서는 TLS 통신이 실패합니다.
이 문제를 해결하려면 TLS 버전 1.2를 사용 가능한 최고 TLS 프로토콜 버전으로 사용하도록 서버 및 클라이언트를 구성합니다.
(BZ#1681178)
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 연결을 설정할 수 있습니다.
(BZ#1685470)
SCP empties 파일은 특정 구문이 사용될 때 자체적으로 복사됩니다.
scp 유틸리티는 보안 복사 프로토콜(SCP)에서 더 안전한 SSH 파일 전송 프로토콜(SECDHE)으로 변경되었습니다. 결과적으로, 위치에서 동일한 위치에 파일을 복사하면 파일 내용이 삭제됩니다. 이 문제는 다음 구문에 영향을 미칩니다.
SCP localhost:/myfile localhost:/myfile
이 문제를 해결하려면 이 구문을 사용하여 소스 위치와 동일한 대상에 파일을 복사하지 마십시오.
다음 구문에 대해 문제가 해결되었습니다.
-
SCP /myfile localhost:/myfile -
SCP localhost:~/myfile ~/myfile
PSK 암호화 제품군은 FUTURE 암호화 정책에서 작동하지 않습니다.
PSK(Pre-shared key) 암호가 완전한 전달 보안(PFS) 키 교환 방법을 수행하는 것으로 인식되지 않습니다. 결과적으로 ECDHE-PSK 및 DHE-PSK 암호화 적합성은 예를 들어 FUTURE 암호화 정책과 같이ECDHE LEVEL=3 으로 구성된 OpenSSL에서 작동하지 않습니다. 해결 방법으로 PSK 암호를 사용하는 애플리케이션에 대해 덜 제한적인 암호화 정책을 설정하거나 더 낮은 보안 수준(ECDHELEVEL)을 설정할 수 있습니다.
GnuPG는 crypto-policies에서 허용하지 않더라도 SHA-1 서명을 잘못 사용할 수 있음
GnuPG(GNU 개인 정보 보호 ECDHE) 암호화 소프트웨어는 시스템 전체의 암호화 정책에 정의된 설정과 관계없이 SHA-1 알고리즘을 사용하는 서명을 생성하고 확인할 수 있습니다. 결과적으로 DEFAULT 암호화 정책의 암호화 목적으로 SHA-1을 사용할 수 있으며, 이는 서명에 대해 이 비보안 알고리즘의 사용 중단과 일치하지 않습니다.
이 문제를 해결하려면 SHA-1과 관련된 GnuPG 옵션을 사용하지 마십시오. 결과적으로 GnuPG는 비보안 SHA-1 서명을 사용하여 기본 시스템 보안을 낮추지 않습니다.
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 정책을 사용하면 제한되지 않은 실행 파일이 스택을 실행할 수 있습니다.
SELinux 정책에서 selinuxuser_execstack 부울의 기본 상태는 on입니다. 즉, 제한되지 않은 실행 파일이 스택을 실행할 수 있습니다. 실행 파일은 이 옵션을 사용하지 않아야 하며, 잘못 코딩된 실행 파일 또는 가능한 공격을 나타낼 수 있습니다. 그러나 Red Hat은 다른 도구, 패키지 및 타사 제품과의 호환성으로 인해 기본 정책에서 부울 값을 변경할 수 없습니다. 시나리오가 이러한 호환성 측면에 의존하지 않는 경우 setsebool -P selinuxuser_execstack 명령을 입력하여 로컬 정책에서 부울을 해제할 수 있습니다.
Kickstart 설치 중 서비스 관련 규칙 수정에 실패할 수 있습니다.
Kickstart 설치 중에 OpenSCAP 유틸리티에서 서비스 활성화 또는 비활성화 상태 수정이 필요하지 않은 것으로 잘못 표시되는 경우가 있습니다. 그 결과 OpenSCAP에서 설치된 시스템의 서비스를 비준수 상태로 설정할 수 있습니다. 이 문제를 해결하려면 Kickstart 설치 후 시스템을 스캔하고 수정할 수 있습니다. 이렇게 하면 서비스 관련 문제가 해결됩니다.
SCAP 감사 규칙을 잘못 수정하지 못했습니다.
감사 구성과 관련된 일부 SCAP 규칙의 Bash 수정은 수정 시 감사 키를 추가하지 않습니다. 이는 다음 규칙에 적용됩니다.
-
audit_rules_login_events -
audit_rules_login_events_faillock -
audit_rules_login_events_lastlog -
audit_rules_login_events_tallylog -
audit_rules_usergroup_modification -
audit_rules_usergroup_modification_group -
audit_rules_usergroup_modification_gshadow -
audit_rules_usergroup_modification_opasswd -
audit_rules_usergroup_modification_passwd -
audit_rules_usergroup_modification_shadow -
audit_rules_time_watch_localtime -
audit_rules_mac_modification -
audit_rules_networkconfig_modification -
audit_rules_sysadmin_actions -
audit_rules_session_events -
audit_rules_sudoers -
audit_rules_sudoers_d
결과적으로 관련 감사 규칙이 이미 존재하지만 OVAL 검사를 완전히 따르지 않는 경우 수정은 감사 규칙의 기능적 부분, 즉 경로 및 액세스 비트이지만 감사 키는 추가하지 않습니다. 따라서 결과 감사 규칙이 올바르게 작동하지만 SCAP 규칙이 FAIL를 잘못 보고합니다. 이 문제를 해결하려면 감사 규칙에 올바른 키를 수동으로 추가합니다.
STIG 프로파일의 SSH 타임아웃 규칙으로 잘못된 옵션을 구성합니다.
OpenSSH의 업데이트는 다음과 같은 정보 시스템 기관 보안 기술 구현 가이드(DISA STIG) 프로필의 규칙에 영향을 미쳤습니다.
-
RHEL 9 용 DISA STIG (
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 및 RHEL 9 프로파일용 GUI를 사용하는 DISA STIG에서 이러한 규칙이 일시적으로 제거되었습니다.
Keylime은 여러 IMA 측정 파일에 액세스하는 시스템을 검증하지 못할 수 있습니다.
Keylime 에이전트를 실행하는 시스템에서IMA( Integrity Measurement Architecture)에 의해 측정된 여러 파일에 빠른 연속으로 액세스하면 Keylime 검증기가 IMA 로그 추가를 잘못 처리할 수 있습니다. 결과적으로 실행 중인 해시가 올바른 PCR(Platform Configuration Register) 상태와 일치하지 않으며 시스템을 검증하지 못합니다. 현재는 해결방법이 없습니다.
Keylime 측정 부팅 정책 생성 스크립트로 인해 세그먼트 오류 및 코어 덤프가 발생할 수 있습니다.
Keylime에서 부팅시 측정 정책을 생성하는 create_mb_refstate 스크립트는 제공된 입력에 따라 tpm2_eventlog 툴의 출력을 처리할 때 LengthOf 필드의 값을 사용하는 대신 DevicePath 필드의 데이터 길이를 잘못 계산할 수 있습니다. 결과적으로 스크립트는 잘못 계산된 길이를 사용하여 잘못된 메모리에 액세스하려고 시도하여 세그먼트 오류와 코어 덤프가 발생합니다. Keylime의 주요 기능은 이 문제의 영향을 받지 않지만 측정된 부팅 정책을 생성할 수 없습니다.
DevicePath
이 문제를 해결하려면 측정된 부팅 정책을 사용하거나 tpm2-tools 패키지의 tpm2_eventlog 툴을 사용하여 얻은 데이터에서 정책 파일을 수동으로 쓰지 마십시오.
일부 TPM 인증서로 인해 Keylime 등록 기관 충돌
프로덕션 배포에서 활성화해야 하는 tenant.conf 의 require_ek_cert 구성 옵션은 TPM(Relime) 테넌트에 TPM(Trusted Platform Module)의 승인 키(EK) 인증서가 필요한지 여부를 결정합니다. require_ek_cert 가 활성화된 초기 ID 인용을 수행할 때 Kelime은 에이전트의 TPM 장치를 Keylime TPM 인증서 저장소에 있는 신뢰할 수 있는 인증서와 비교하여 EK 인증서를 유효한지 여부를 확인합니다. 그러나 저장소의 일부 인증서는 잘못된 형식의 x509 인증서이며 Keylime 등록 기관이 충돌하게 됩니다. 현재 require_ek_cert 를 false 로 설정하고 EK 검증을 수행할 ek_check_script 옵션에 사용자 지정 스크립트를 정의하는 것을 제외하고 이 문제에 대한 간단한 해결 방법이 없습니다.
