5.7.4. 보안

symlink의 감사 실행 파일이 작동하지 않음

w 옵션이 제공하는 파일 모니터링은 경로를 직접 추적할 수 없습니다. 실행된 프로그램을 비교하려면 장치와 inode의 경로를 확인해야 합니다. 실행 가능한 symlink를 모니터링하는 감시는 symlink 해상도에서 발견되는 메모리에서 실행되는 프로그램이 아닌 symlink 자체의 inode를 모니터링합니다. 감시에서 symlink를 확인하여 결과 실행 프로그램을 가져오더라도 규칙이 다른 symlink에서 호출된 multi-call 바이너리에 대해 트리거됩니다. 이로 인해 잘못된 양의 로그가 급증하게 됩니다. 결과적으로 symlink의 감사 실행 파일 감시가 작동하지 않습니다.

/etc/selinux/config 에서 SELINUX=disabled 가 제대로 작동하지 않음

/etc/selinux/config 에서 SELINUX=disabled 옵션을 사용하여 SELinux를 비활성화하면 커널이 SELinux가 활성화된 상태로 부팅되고 부팅 프로세스 후반부에서 비활성화 모드로 전환됩니다. 이로 인해 메모리 누수가 발생할 수 있습니다.

libselinux-python 은 모듈을 통해서만 사용할 수 있습니다

libselinux-python 패키지에는 SELinux 애플리케이션 개발을 위한 Python 2 바인딩만 포함되어 있으며 이전 버전과의 호환성에 사용됩니다. 이러한 이유로 libselinux-python 은 dnf install libselinux-python 명령을 통해 기본 RHEL 8 리포지토리에서 더 이상 사용할 수 없습니다.

udica 는 --env container=podman으로 시작되는 경우에만 UBI 8 컨테이너를처리합니다.

Red Hat Universal Base Image 8(UBI 8) 컨테이너는 컨테이너 환경 변수를 podman 값이 아닌 oci 값으로 설정합니다. 이렇게 하면 udica 툴에서 컨테이너 JSON(JavaScript Object Notation) 파일을 분석하지 못합니다.

rpm-plugin-selinux 패키지를 제거하면 시스템에서 모든 selinux-policy 패키지가 제거됩니다.

rpm-plugin-selinux 패키지를 제거하면 시스템에서 SELinux가 비활성화됩니다. 또한 시스템에서 모든 selinux-policy 패키지를 제거합니다. 그런 다음 rpm-plugin-selinux 패키지를 반복적으로 설치한 후 selinux-policy- targeted 정책이 시스템에 있는 경우에도 selinux-policy- minimum SELinux 정책을 설치합니다. 그러나 반복적으로 설치하면 정책 변경 사항을 고려하여 SELinux 구성 파일이 업데이트되지 않습니다. 결과적으로 rpm-plugin-selinux 패키지를 다시 설치해도 SELinux가 비활성화됩니다.

SELinux는 corosync에서 만든 공유 메모리 파일에서 newfstatat() 를 호출하도록 systemd-journal-gatewayd 를 방지합니다.

SELinux 정책에는 systemd-journal-gatewayd 데몬이 corosync 서비스에서 생성한 파일에 액세스할 수 있도록 하는 규칙이 포함되지 않습니다. 그 결과 SELinux는 systemd-journal-gatewayd 를 거부하여 corosync 에서 만든 공유 메모리 파일에 newfstatat() 함수를 호출합니다.

SELinux는 auditd 가 시스템을 중단하거나 전원을 끄지 않도록 방지합니다.

SELinux 정책에는 감사 데몬이 power_unit_file_t systemd 장치를 시작할 수 있는 규칙이 포함되어 있지 않습니다. 결과적으로 auditd 는 로깅 디스크 파티션에 남은 공간 없음과 같은 경우 이를 수행하도록 구성된 경우에도 시스템을 중지하거나 전원을 끌 수 없습니다.

사용자는 잠긴 사용자로 sudo 명령을 실행할 수 있습니다.

sudoers 권한이 ALL 키워드로 정의된 시스템에서 권한이 있는 sudo 사용자는 계정이 잠겨 있는 사용자로 sudo 명령을 실행할 수 있습니다. 따라서 잠김 및 만료된 계정은 명령을 실행하는 데 계속 사용할 수 있습니다.

성능에 대한 기본 로깅 설정의 부정적인 영향

기본 로깅 환경 설정은 rsyslog 를 사용하여 systemd-journald를 실행할 때 4GB 메모리를 사용하거나 rate- limit 값을 조정하는 작업이 복잡할 수 있습니다.

config.enabled 가 포함된 rsyslog 출력의 매개 변수가 알 수 없는 오류

rsyslog 출력에서는 config.enabled 지시문을 사용하여 구성 처리 오류에서 예기치 않은 버그가 발생합니다. 결과적으로 include() 문을 제외하고 config.enabled 지시문을 사용하는 동안 매개 변수가 알 수 없는 오류가 표시됩니다.

특정 rsyslog 우선 순위 문자열이 올바르게 작동하지 않음

암호화를 세밀하게 제어할 수 있는 imtcp 에 대한 GnuTLS 우선순위 문자열 지원은 완료되지 않습니다. 결과적으로, rsyslog 에서 다음 우선 순위 문자열이 제대로 작동하지 않습니다 :

SHA-1 서명이 있는 서버에 대한 연결이 GnuTLS에서 작동하지 않음

인증서의 SHA-1 서명은 GnuTLS 보안 통신 라이브러리에서 안전하지 않은 것으로 거부됩니다. 결과적으로 GnuTLS를 TLS 백엔드로 사용하는 애플리케이션은 이러한 인증서를 제공하는 피어에 TLS 연결을 설정할 수 없습니다. 이 동작은 다른 시스템 암호화 라이브러리와 일치하지 않습니다. 이 문제를 해결하려면 SHA-256 또는 더 강력한 해시로 서명된 인증서를 사용하거나 LEGACY 정책으로 전환하도록 서버를 업그레이드합니다.

TLS 1.3이 FIPS 모드에서 NSS에서 작동하지 않음

FIPS 모드에서 작동하는 시스템에서는 TLS 1.3이 지원되지 않습니다. 따라서 상호 운용성에 TLS 1.3이 필요한 연결은 FIPS 모드에서 작동하는 시스템에서 작동하지 않습니다.

OpenSSL 에서 원시 RSA 또는 RSA-PSS 서명을 지원하지 않는 PKCS #11 토큰을 잘못 처리합니다.

OpenSSL 라이브러리는 PKCS #11 토큰의 키 관련 기능을 탐지하지 않습니다. 결과적으로 원시 RSA 또는 RSA-PSS 서명을 지원하지 않는 토큰으로 서명이 생성되면 TLS 연결 설정에 실패합니다.

OpenSSL은 TLS 1.3의 CertificateRequest 메시지에 잘못된 형식의 status_request 확장을 생성합니다.

status_request 확장 및 클라이언트 인증서 기반 인증을 지원하는 경우 OpenSSL 서버는 CertificateRequest 메시지에 잘못된 형식의 status_request 확장을 전송합니다. 이러한 경우 OpenSSL은 RFC 8446 프로토콜을 준수하는 구현과 상호 운용되지 않습니다. 결과적으로 CertificateRequest 메시지의 확장을 올바르게 확인하는 클라이언트는 OpenSSL 서버와의 중단 연결을 중단합니다. 이 문제를 해결하려면 연결 측에서 TLS 1.3 프로토콜에 대한 지원을 비활성화하거나 OpenSSL 서버에서 status_request 에 대한 지원을 비활성화합니다. 이렇게 하면 서버가 잘못된 형식의 메시지를 보내지 못합니다.

ssh-keyscan 은 FIPS 모드에서 RSA 키를 검색할 수 없습니다

FIPS 모드에서 RSA 서명에 대해 SHA-1 알고리즘이 비활성화되어 ssh-keyscan 유틸리티가 해당 모드에서 작동하는 서버의 RSA 키를 검색하지 못하게 합니다.

Libreswan 이 모든 설정에서 seccomp=enabled 에서 제대로 작동하지 않음

현재 Libreswan SECCOMP 지원 구현에서 허용되는 syscall 세트가 완료되지 않았습니다. 결과적으로 ipsec.conf 파일에서 SECCOMP를 활성화하면 syscall 필터링이 pluto 데몬이 제대로 작동하는 데 필요한 syscall도 거부합니다. 데몬이 종료되고 ipsec 서비스가 다시 시작됩니다.

SSG의 특정 상호 의존 규칙 세트는 실패할 수 있습니다.

규칙 및 해당 종속 항목의 정의되지 않은 순서로 인해 벤치마크의 SCAP 보안 가이드 (SSG) 규칙 수정이 실패할 수 있습니다. 예를 들어, 한 규칙이 구성 요소를 설치하고 다른 규칙이 동일한 구성 요소를 구성하는 경우와 같이 두 개 이상의 규칙을 특정 순서로 실행해야 하는 경우 해당 규칙을 잘못된 순서로 실행하고 수정을 통해 오류를 보고할 수 있습니다. 이 문제를 해결하려면 수정을 두 번 실행하고 두 번째는 종속 규칙을 수정합니다.

SCAP Workbench가 사용자 정의 프로파일에서 결과를 기반으로 한 수정을 생성하지 못함

SCAP Workbench 툴을 사용하여 사용자 정의된 프로파일에서 결과 기반 수정 역할을 생성하려고 할 때 다음과 같은 오류가 발생합니다.

킥스타트에서는 RHEL 8에서 com _redhat_oscap 대신 org_fedora _oscap 을 사용합니다.

Kickstart는 OSCAP(Open Security Content Automation Protocol) Anaconda 애드온을 com_redhat _oscap 대신 org_fedora _oscap 으로 참조하여 혼동을 일으킬 수 있습니다. 이는 Red Hat Enterprise Linux 7과 이전 버전과의 호환성을 유지하기 위해 수행됩니다.

OSCAP Anaconda 애드온은 모든 패키지를 텍스트 모드에 설치하지 않음

OSCAP Anaconda Addon 플러그인은 설치가 텍스트 모드에서 실행 중인 경우 시스템 설치 프로그램에서 설치에 대해 선택한 패키지 목록을 수정할 수 없습니다. 결과적으로 Kickstart를 사용하여 보안 정책 프로필을 지정하고 설치가 텍스트 모드로 실행되는 경우 보안 정책에 필요한 추가 패키지는 설치 중에 설치되지 않습니다.

OSCAP Anaconda 애드온 이 사용자 지정 프로파일을 올바르게 처리하지 않음

OSCAP Anaconda 애드온 플러그인은 별도의 파일의 사용자 지정으로 보안 프로필을 올바르게 처리하지 않습니다. 따라서 해당 Kickstart 섹션에서 적절하게 지정하는 경우에도 RHEL 그래픽 설치에서 사용자 지정된 프로필을 사용할 수 없습니다.

Gnutls가 NSS 서버로 현재 세션을 다시 시작하지 못했습니다

TLS(Transport Layer Security) 1.3 세션을 다시 시작할 때 GnuTLS 클라이언트는 60밀리초 동안 서버에 세션 재개 데이터를 보낼 때까지 예상 왕복 시간을 기다립니다. 서버가 이 시간 내에 재사용 데이터를 전송하지 않으면 클라이언트는 현재 세션을 다시 시작하지 않고 새 세션을 만듭니다. 이로 인해 정기적인 세션 협상에 약간의 성능에 영향을 미치는 것을 제외하고는 심각한 부정적인 영향이 발생하지 않습니다.

oscap-ssh 유틸리티는 --sudo를 사용하여 원격 시스템을 스캔할 때 실패합니다.

oscap-ssh 툴을 --sudo 옵션과 함께 사용하여 원격 시스템을 SCAP(Security Content Automation Protocol) 스캔을 수행할 때 원격 시스템의 oscap 툴은 스캔 결과 파일을 저장하고 파일을 root 사용자로 임시 디렉터리에 보고합니다. 원격 시스템의 umask 설정이 변경되면 oscap-ssh 가 해당 파일에 액세스하지 못할 수 있습니다. 이 문제를 해결하려면 이 솔루션 "oscap -ssh --sudo"에 설명된 대로 oscap -ssh 툴을 수정하십시오. "scp: …​: 권한이 거부되었습니다" error. 결과적으로 oscap 은 파일을 대상 사용자로 저장하고 oscap-ssh 는 일반적으로 파일에 액세스합니다.

OpenSCAP은 YAML 여러 줄 문자열에서 빈 줄을 제거하여 발생하는 오탐을 생성합니다.

OpenSCAP에서 데이터 스트림에서 Ansible 해결을 생성하면 YAML 다중 줄 문자열에서 빈 행을 제거합니다. 일부 Ansible 수정에는 리터럴 구성 파일 내용이 포함되어 있으므로 빈 행을 제거하면 해당 수정 사항에 영향을 미칩니다. 이로 인해 openscap 유틸리티가 빈 줄에 영향을 미치지 않더라도 해당 OVAL(Open Vulnerability and Assessment Language) 검사에 실패합니다. 이 문제를 해결하려면 규칙 설명을 확인하고 빈 줄이 누락되어 실패한 스캔 결과를 건너뜁니다. 또는 Bash 수정으로 인해 잘못된 긍정적인 결과가 생성되지 않으므로 Ansible 해결 대신 Bash 수정을 사용하십시오.

OSPP 기반 프로필은 GUI 패키지 그룹과 호환되지 않습니다.

GUI 패키지 그룹과 함께 서버에서 설치한 GNOME 패키지에는 OSPP(Operating System Protection Profile)와 호환되지 않는 nfs-utils 패키지가 필요합니다. 결과적으로 OSPP 또는 OSPP 기반 프로필(예: STIG(Security Technical Implementation Guide))을 사용하여 시스템을 설치하는 동안 GUI 패키지 그룹이 포함된 서버를 선택하면 설치가 중단됩니다. OSPP 기반 프로필이 설치 후 적용되는 경우 시스템을 부팅할 수 없습니다. 이 문제를 해결하려면 GUI 패키지 그룹이나 OSPP 프로파일과 OSPP 기반 프로필을 사용할 때 GUI를 설치하는 다른 그룹을 사용하여 서버를 설치하지 마십시오. 대신 Server 또는 Minimal Install 패키지 그룹을 사용하는 경우 시스템이 문제 없이 설치되고 올바르게 작동합니다.

GUI 패키지 그룹이 포함된 RHEL 8 시스템은 e8 프로파일을 사용하여 수정할 수 없습니다.

OpenSCAP Anaconda 애드온을 사용하여 Verify Integrity with RPM(RPM 그룹과 무결성 확인)에서 규칙을 선택하는 프로필이 있는 GUI 패키지 그룹과 함께 서버에서 시스템을 강화하려면 시스템의 RAM 크기가 극도로 필요합니다. 이 문제는 OpenSCAP 스캐너로 인해 발생합니다. 자세한 내용은 OpenSCAP로 많은 파일 스캔을 통해 시스템에 메모리가 부족하게 됩니다. 결과적으로 RHEL8 Essential Eight(e8) 프로필을 사용하여 시스템 강화에 성공하지 못했습니다. 이 문제를 해결하려면 더 작은 패키지 그룹(예: Server)을 선택하고 설치 후 필요한 추가 패키지를 설치합니다. 결과적으로 시스템에 더 적은 수의 패키지가 생기므로 검사에 메모리가 적게 필요하므로 시스템을 자동으로 강화할 수 있습니다.

OpenSCAP로 많은 수의 파일을 스캔하면 시스템에 메모리가 부족합니다.

OpenSCAP 스캐너는 검사가 완료될 때까지 수집된 모든 결과를 메모리에 저장합니다. 그 결과 시스템에는 많은 수의 파일을 스캔할 때 RAM이 적은 시스템에서 메모리가 부족할 수 있습니다(예: GUI 및 워크스테이션 을 사용한 대규모 패키지 그룹). 이 문제를 해결하려면 더 작은 패키지 그룹(예: RAM이 제한된 시스템에 Server 및 Minimal Install )을 사용하십시오. 대규모 패키지 그룹을 사용해야 하는 경우 시스템에 가상 또는 스테이징 환경에서 메모리가 충분한지 테스트할 수 있습니다. 또는 전체 / 파일 시스템에 대한 재귀가 필요한 규칙을 선택 취소하도록 검사 프로필을 조정할 수 있습니다.