절차

1. 시스템 전체 암호화 정책을 LEGACY 수준으로 전환하려면 root로 다음 명령을 입력합니다.

   # update-crypto-policies --set LEGACY
   Setting system policy to LEGACY

절차

1. 시스템을 FIPS 모드로 전환하려면 다음을 수행합니다.

   # fips-mode-setup --enable
   Kernel initramdisks are being regenerated. This might take some time.
   Setting system policy to FIPS
   Note: System-wide crypto policies are applied on application start-up.
   It is recommended to restart the system for the change of policies
   to fully take place.
   FIPS mode will be enabled.
   Please reboot the system for the setting to take effect.

2. 커널이 FIPS 모드로 전환되도록 시스템을 다시 시작하십시오.

   # reboot

검증

1. 다시 시작한 후 FIPS 모드의 현재 상태를 확인할 수 있습니다.

   # fips-mode-setup --check
   FIPS mode is enabled.

절차

1. /etc/crypto-policies/policies/modules/ 디렉토리로 체크아웃합니다.

   # cd /etc/crypto-policies/policies/modules/

2. 조정을 위한 하위 정책을 생성합니다. 예를 들면 다음과 같습니다.

   # touch MYCRYPTO-1.pmod
   # touch SCOPES-AND-WILDCARDS.pmod

   중요

   정책 모듈의 파일 이름에 대문자를 사용합니다.

3. 선택한 텍스트 편집기에서 정책 모듈을 열고 시스템 전체 암호화 정책을 수정하는 옵션을 삽입합니다. 예를 들면 다음과 같습니다.

   # vi MYCRYPTO-1.pmod

   min_rsa_size = 3072
   hash = SHA2-384 SHA2-512 SHA3-384 SHA3-512

   # vi SCOPES-AND-WILDCARDS.pmod

   # Disable the AES-128 cipher, all modes
   cipher = -AES-128-*
   
   # Disable CHACHA20-POLY1305 for the TLS protocol (OpenSSL, GnuTLS, NSS, and OpenJDK)
   cipher@TLS = -CHACHA20-POLY1305
   
   # Allow using the FFDHE-1024 group with the SSH protocol (libssh and OpenSSH)
   group@SSH = FFDHE-1024+
   
   # Disable all CBC mode ciphers for the SSH protocol (libssh and OpenSSH)
   cipher@SSH = -*-CBC
   
   # Allow the AES-256-CBC cipher in applications using libssh
   cipher@libssh = AES-256-CBC+

4. 모듈 파일의 변경 사항을 저장합니다.

5. DEFAULT 시스템 전체 암호화 정책 수준에 정책 조정을 적용합니다.

   # update-crypto-policies --set DEFAULT:MYCRYPTO-1:SCOPES-AND-WILDCARDS

6. 이미 실행 중인 서비스 및 애플리케이션에 암호화 설정을 적용하려면 시스템을 다시 시작하십시오.

   # reboot

절차

1. DEFAULT 암호화 정책에 SHA1 하위 정책을 적용합니다.

   # update-crypto-policies --set DEFAULT:SHA1
   Setting system policy to DEFAULT:SHA1
   Note: System-wide crypto policies are applied on application start-up.
   It is recommended to restart the system for the change of policies
   to fully take place.

2. 시스템을 다시 시작하십시오.

   # reboot

절차

1. 사용자 지정 정책 파일을 생성합니다.

   # cd /etc/crypto-policies/policies/
   # touch MYPOLICY.pol

   또는 사전 정의된 4가지 정책 수준 중 하나를 복사하여 시작합니다.

   # cp /usr/share/crypto-policies/policies/DEFAULT.pol /etc/crypto-policies/policies/MYPOLICY.pol

2. 다음과 같은 요구 사항에 맞게 선택한 텍스트 편집기에서 사용자 지정 암호화 정책으로 파일을 편집합니다.

   # vi /etc/crypto-policies/policies/MYPOLICY.pol

3. 시스템 전체 암호화 정책을 사용자 지정 수준으로 전환합니다.

   # update-crypto-policies --set MYPOLICY

4. 이미 실행 중인 서비스 및 애플리케이션에 암호화 설정을 적용하려면 시스템을 다시 시작하십시오.

   # reboot

절차

1. 다음 내용으로 새 playbook.yml 파일을 생성합니다.

   ---
   - hosts: all
     tasks:
     - name: Configure crypto policies
       include_role:
         name: rhel-system-roles.crypto_policies
       vars:
         - crypto_policies_policy: FUTURE
         - crypto_policies_reboot_ok: true

   예를 들어 FUTURE 값을 선호하는 암호화 정책으로 교체할 수 있습니다. DEFAULT,LEGACY 및 FIPS:OSPP.

   crypto_policies_reboot_ok: true 변수를 사용하면 시스템 역할에서 암호화 정책을 변경한 후 시스템이 재부팅됩니다.

   자세한 내용은 Policies Policies System Role variables and facts 를 참조하십시오.

2. 선택 사항: 플레이북 구문을 확인합니다.

   # ansible-playbook --syntax-check playbook.yml

3. 인벤토리 파일에서 플레이북을 실행합니다.

   # ansible-playbook -i inventory_file playbook.yml

검증

1. 제어 노드에서 verify_playbook.yml과 같은 다른 플레이북을 생성합니다.

   - hosts: all
     tasks:
    - name: Verify active crypto policy
      include_role:
        name: rhel-system-roles.crypto_policies
   
    - debug:
        var: crypto_policies_active

   이 플레이북은 시스템의 구성을 변경하지 않고 관리 노드의 활성 정책만 보고합니다.

2. 동일한 인벤토리 파일에서 플레이북을 실행합니다.

   # ansible-playbook -i inventory_file verify_playbook.yml
   
   TASK [debug] **************************
   ok: [host] => {
       "crypto_policies_active": "FUTURE"
   }

   "crypto_policies_active": 변수는 관리 노드에서 정책을 활성으로 표시합니다.

절차

1. PKCS #11 URI를 포함하여 OpenSC PKCS #11 모듈에서 제공하는 모든 키를 나열하고 출력을 keys.pub 파일에 저장합니다.

   $ ssh-keygen -D pkcs11: > keys.pub
   $ ssh-keygen -D pkcs11:
   ssh-rsa AAAAB3NzaC1yc2E...KKZMzcQZzx pkcs11:id=%02;object=SIGN%20pubkey;token=SSH%20key;manufacturer=piv_II?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so
   ecdsa-sha2-nistp256 AAA...J0hkYnnsM= pkcs11:id=%01;object=PIV%20AUTH%20pubkey;token=SSH%20key;manufacturer=piv_II?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so

2. 원격 서버(example.com)에서 스마트 카드를 사용하여 인증을 활성화하려면 공개 키를 원격 서버로 전송합니다. 이전 단계에서 만든 keys.pub와 함께 ssh-copy-id 명령을 사용하십시오.

   $ ssh-copy-id -f -i keys.pub username@example.com

3. 1단계에서 ssh-keygen -D 명령의 출력에서 ECDSA 키를 사용하여 example.com 에 연결하려면 다음과 같이 키를 고유하게 참조하는 URI의 하위 집합만 사용할 수 있습니다.

   $ ssh -i "pkcs11:id=%01?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so" example.com
   Enter PIN for 'SSH key':
   [example.com] $

4. ~/.ssh/config 파일에서 동일한 URI 문자열을 사용하여 구성을 영구적으로 만들 수 있습니다.

   $ cat ~/.ssh/config
   IdentityFile "pkcs11:id=%01?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so"
   $ ssh example.com
   Enter PIN for 'SSH key':
   [example.com] $

   OpenSSH는 p11-kit-proxy 래퍼를 사용하고 OpenSC PKCS #11 모듈은 PKCS#11 Kit에 등록되므로 이전 명령을 간소화할 수 있습니다.

   $ ssh -i "pkcs11:id=%01" example.com
   Enter PIN for 'SSH key':
   [example.com] $

절차

1. /etc/polkit-1/rules.d/ 디렉토리에 새 파일을 생성합니다.

   # touch /etc/polkit-1/rules.d/00-test.rules

2. 선택한 편집기에서 파일을 편집합니다. 예를 들면 다음과 같습니다.

   # vi /etc/polkit-1/rules.d/00-test.rules

3. 다음 행을 삽입합니다.

   polkit.addRule(function(action, subject) {
     if (action.id == "org.debian.pcsc-lite.access_pcsc" ||
     	action.id == "org.debian.pcsc-lite.access_card") {
   	polkit.log("action=" + action);
   	polkit.log("subject=" + subject);
     }
   });

   파일을 저장하고 편집기를 종료합니다.

4. pcscd 및 polkit 서비스를 다시 시작합니다.

   # systemctl restart pcscd.service pcscd.socket polkit.service

검증

1. pcscd 에 대한 권한 부여 요청을 만듭니다. 예를 들어 Firefox 웹 브라우저를 열거나 opensc 패키지에서 제공하는 pkcs11-tool -L 명령을 사용합니다.

2. 확장 로그 항목을 표시합니다. 예를 들면 다음과 같습니다.

   # journalctl -u polkit --since "1 hour ago"
   polkitd[1224]: <no filename>:4: action=[Action id='org.debian.pcsc-lite.access_pcsc']
   polkitd[1224]: <no filename>:5: subject=[Subject pid=2020481 user=user' groups=user,wheel,mock,wireshark seat=null session=null local=true active=true]

절차

1. 간단한 PEM 또는 DER 파일 형식의 인증서를 시스템에서 신뢰하는 CA 목록에 추가하려면 인증서 파일을 /usr/share/pki/ca-trust-source/anchors/ 또는 /etc/pki/ca-trust/source/anchors/ 디렉터리에 복사합니다.

   # cp ~/certificate-trust-examples/Cert-trust-test-ca.pem /usr/share/pki/ca-trust-source/anchors/

2. 시스템 전체 신뢰 저장소 구성을 업데이트하려면 update-ca-trust 명령을 사용합니다.

   # update-ca-trust

절차

1. --remediate 옵션과 함께 oscap 명령을 사용합니다.

   $ sudo oscap xccdf eval --profile hipaa --remediate /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

2. 시스템을 다시 시작합니다.

검증

1. HIPAA 프로파일로 시스템 규정 준수를 평가하고 hipaa_report.html 파일에 검사 결과를 저장합니다.

   $ oscap xccdf eval --report hipaa_report.html --profile hipaa /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

절차

1. Ansible을 사용하여 RuntimeClass에 맞게 시스템을 조정합니다.

   # ansible-playbook -i localhost, -c local /usr/share/scap-security-guide/ansible/rhel9-playbook-hipaa.yml

2. 시스템을 다시 시작합니다.

검증

1. HIPAA 프로파일로 시스템 규정 준수를 평가하고 hipaa_report.html 파일에 검사 결과를 저장합니다.

   # oscap xccdf eval --profile hipaa --report hipaa_report.html /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

절차

1. 시스템을 스캔하고 결과를 저장합니다.

   # oscap xccdf eval --profile hipaa --results hipaa-results.xml /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

2. 이전 단계에서 생성한 파일을 기반으로 Ansible 플레이북을 생성합니다.

   # oscap xccdf generate fix --fix-type ansible --profile hipaa --output hipaa-remediations.yml hipaa-results.xml

3. hipaa-remediations.yml 파일에는 1단계에서 수행된 검사 중에 실패한 규칙에 대한 Ansible 수정 사항이 포함되어 있습니다. 생성된 이 파일을 검토한 후 ansible-playbook hipaa-remediations.yml 명령을 사용하여 적용할 수 있습니다.

절차

1. oscap 명령을 사용하여 시스템을 스캔하고 결과를 XML 파일에 저장합니다. 다음 예에서 oscap은 hipaa 프로필에 대해 시스템을 평가합니다.

   # oscap xccdf eval --profile hipaa --results hipaa-results.xml /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

2. 이전 단계에서 생성한 결과 파일을 기반으로 Bash 스크립트를 생성합니다.

   # oscap xccdf generate fix --profile hipaa --fix-type bash --output hipaa-remediations.sh hipaa-results.xml

3. hipaa-remediations.sh 파일에는 1단계에서 수행한 검사 중에 실패한 규칙 수정이 포함되어 있습니다. 생성된 이 파일을 검토한 후 이 파일과 동일한 디렉터리에 있는 경우 ./hipaa-remediations.sh 명령을 사용하여 적용할 수 있습니다.

절차

1. 시스템에 대한 최신 RHSA OVAL 정의를 다운로드합니다.

   # wget -O - https://www.redhat.com/security/data/oval/v2/RHEL9/rhel-9.oval.xml.bz2 | bzip2 --decompress > rhel-9.oval.xml

2. 컨테이너 또는 컨테이너 이미지의 ID를 가져옵니다. 예를 들면 다음과 같습니다.

   # podman images
   REPOSITORY                            TAG      IMAGE ID       CREATED       SIZE
   registry.access.redhat.com/ubi9/ubi   latest   096cae65a207   7 weeks ago   239 MB

3. 컨테이너 또는 컨테이너 이미지에서 취약점을 스캔하고 결과를 vulnerability.html 파일에 저장합니다.

   # oscap-podman 096cae65a207 oval eval --report vulnerability.html rhel-9.oval.xml

   oscap-podman 명령에는 root 권한이 필요하며 컨테이너 ID는 첫 번째 인수입니다.

절차

1. 컨테이너 또는 컨테이너 이미지의 ID를 가져옵니다. 예를 들면 다음과 같습니다.

   # podman images
   REPOSITORY                            TAG      IMAGE ID       CREATED       SIZE
   registry.access.redhat.com/ubi9/ubi   latest   096cae65a207   7 weeks ago   239 MB

2. RuntimeClass 프로필을 사용하여 컨테이너 이미지의 규정 준수를 평가하고 검사 결과를 report.html HTML 파일에 저장합니다.

   # oscap-podman 096cae65a207 xccdf eval --report report.html --profile hipaa /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

   OSPP 또는 PCI-DSS 기준의 보안 준수 여부를 평가하는 경우 096cae65a207 을 컨테이너 이미지의 ID와 hipaa 값을 ospp 또는 pci-dss 로 바꿉니다. oscap-podman 명령에는 root 권한이 필요합니다.

절차

1. aide 패키지를 설치하려면 다음을 수행합니다.

   # dnf install aide

2. 초기 데이터베이스를 생성하려면 다음을 수행합니다.

   # aide --init

   참고

   기본 구성에서 aide --init 명령은 /etc/aide.conf 파일에 정의된 디렉터리와 파일 집합만 확인합니다. AIDE 데이터베이스에 추가 디렉터리 또는 파일을 포함하고 감시 매개 변수를 변경하려면 그에 따라 /etc/aide.conf 를 편집합니다.

3. 데이터베이스 사용을 시작하려면 초기 데이터베이스 파일 이름에서 .new 하위 문자열을 제거합니다.

   # mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

4. AIDE 데이터베이스의 위치를 변경하려면 /etc/aide.conf 파일을 편집하고 DBDIR 값을 수정합니다. 추가 보안을 위해 데이터베이스, 구성 및 /usr/sbin/aide 바이너리 파일을 읽기 전용 미디어와 같은 안전한 위치에 저장합니다.

절차

1. 수동 검사를 시작하려면 다음을 수행합니다.

   # aide --check
   Start timestamp: 2018-07-11 12:41:20 +0200 (AIDE 0.16)
   AIDE found differences between database and filesystem!!
   ...
   [trimmed for clarity]

2. 최소한 AIDE 를 매주 실행하도록 시스템을 구성합니다. 최적의 경우 AIDE 를 매일 실행합니다. 예를 들어 cron 명령을 사용하여 AIDE 의 일일 실행을 04:05 a.m.에서 예약하려면 /etc/crontab 파일에 다음 행을 추가합니다.

    05 4 * * * root /usr/sbin/aide --check

절차

1. 기본 AIDE 데이터베이스를 업데이트합니다.

   # aide --update

   aide --update 명령은 /var/lib/aide/aide.db.new.gz 데이터베이스 파일을 생성합니다.

2. 무결성 검사를 위해 업데이트된 데이터베이스를 사용하려면 파일 이름에서 .new 하위 문자열을 제거합니다.

절차

1. 암호화하려는 장치에서 모든 파일 시스템을 마운트 해제합니다. 예를 들면 다음과 같습니다.

   # umount /dev/sdb1

2. LUKS 헤더를 저장할 여유 공간을 만듭니다. 시나리오에 적합한 다음 옵션 중 하나를 선택합니다.

   • 논리 볼륨을 암호화하는 경우 파일 시스템의 크기를 조정하지 않고 논리 볼륨을 확장할 수 있습니다. 예를 들면 다음과 같습니다.

     # lvextend -L+32M vg00/lv00

   • parted 와 같은 파티션 관리 도구를 사용하여 파티션을 확장합니다.
   • 장치에서 파일 시스템을 축소합니다. ext2, ext3 또는 ext4 파일 시스템에 resize2fs 유틸리티를 사용할 수 있습니다. XFS 파일 시스템을 축소할 수 없습니다.

3. 암호화를 초기화합니다. 예를 들면 다음과 같습니다.

   # cryptsetup reencrypt \
                --encrypt \
                --init-only \
                --reduce-device-size 32M \
                /dev/sdb1 sdb1_encrypted

   이 명령은 암호를 요청하고 암호화 프로세스를 시작합니다.

4. 장치를 마운트합니다.

   # mount /dev/mapper/sdb1_encrypted /mnt/sdb1_encrypted

5. 온라인 암호화를 시작합니다.

   # cryptsetup reencrypt --resume-only /dev/sdb1

절차

1. 장치의 모든 파일 시스템을 마운트 해제합니다. 예를 들면 다음과 같습니다.

   # umount /dev/sdb1

2. 암호화를 초기화합니다.

   # cryptsetup reencrypt \
                --encrypt \
                --init-only \
                --header /path/to/header \
                /dev/sdb1 sdb1_encrypted

   /path/to/header 를 파일의 경로로 분리된 LUKS 헤더로 바꿉니다. 나중에 암호화된 장치를 잠금 해제할 수 있도록 분리된 LUKS 헤더에 액세스할 수 있어야 합니다.

   이 명령은 암호를 요청하고 암호화 프로세스를 시작합니다.

3. 장치를 마운트합니다.

   # mount /dev/mapper/sdb1_encrypted /mnt/sdb1_encrypted

4. 온라인 암호화를 시작합니다.

   # cryptsetup reencrypt --resume-only --header /path/to/header /dev/sdb1

절차

1. 파티션을 암호화된 LUKS 파티션으로 설정합니다.

   # cryptsetup luksFormat /dev/sdb1

2. 암호화된 LUKS 파티션을 엽니다.

   # cryptsetup open /dev/sdb1 sdb1_encrypted

   이렇게 하면 파티션 잠금이 해제되어 장치 매퍼를 사용하여 새 장치에 매핑됩니다. 이 경고 커널은 암호화된 장치이며 암호화된 데이터를 덮어쓰지 않도록 /dev/mapper/ device _mapped_name 을 사용하여 LUKS를 통해 처리해야 합니다.

3. 암호화된 데이터를 파티션에 쓰려면 장치 매핑 이름을 통해 액세스해야 합니다. 이렇게 하려면 파일 시스템을 만들어야 합니다. 예를 들면 다음과 같습니다.

   # mkfs -t ext4 /dev/mapper/sdb1_encrypted

4. 장치를 마운트합니다.

   # mount /dev/mapper/sdb1_encrypted mount-point

절차

1. 다음 내용으로 새 playbook.yml 파일을 생성합니다.

   - hosts: all
     vars:
       storage_volumes:
         - name: barefs
           type: disk
           disks:
            - sdb
           fs_type: xfs
           fs_label: label-name
           mount_point: /mnt/data
           encryption: true
           encryption_password: your-password
     roles:
      - rhel-system-roles.storage

2. 선택 사항: 플레이북 구문을 확인합니다.

   # ansible-playbook --syntax-check playbook.yml

3. 인벤토리 파일에서 플레이북을 실행합니다.

   # ansible-playbook -i inventory.file /path/to/file/playbook.yml

절차

1. 암호화된 볼륨이 있는 시스템에 Clevis 및 해당 핀을 설치하려면 다음을 수행합니다.

   # dnf install clevis

2. 데이터의 암호를 해독하려면 clevis decrypt 명령을 사용하고 JSON Web Encryption(JWE) 형식으로 암호화 텍스트를 제공합니다. 예를 들면 다음과 같습니다.

   $ clevis decrypt < secret.jwe

절차

1. tang 패키지 및 해당 종속 항목을 설치하려면 root 로 다음 명령을 입력합니다.

   # dnf install tang

2. 할당되지 않은 포트 (예: 7500/tcp )를 선택하고 tangd 서비스가 해당 포트에 바인딩하도록 허용합니다.

   # semanage port -a -t tangd_port_t -p tcp 7500

   포트는 한 번에 하나의 서비스에서만 사용할 수 있으므로 이미 사용 중인 포트를 사용하려는 시도는 ValueError를 의미합니다. 포트 이미 정의 오류 메시지입니다.

3. 방화벽에서 포트를 엽니다.

   # firewall-cmd --add-port=7500/tcp
   # firewall-cmd --runtime-to-permanent

4. tangd 서비스를 활성화합니다.

   # systemctl enable tangd.socket

5. 덮어쓰기 파일을 생성합니다.

   # systemctl edit tangd.socket

6. /etc/systemd/system/tangd.socket.d/ 디렉터리에 있는 빈 override.conf 파일을 여는 다음 행을 추가하여 Tang 서버의 기본 포트를 80에서 이전에 선택한 번호로 변경합니다.

   [Socket]
   ListenStream=
   ListenStream=7500

   파일을 저장하고 편집기를 종료합니다.

7. 변경된 구성을 다시 로드합니다.

   # systemctl daemon-reload

8. 구성이 작동하는지 확인합니다.

   # systemctl show tangd.socket -p Listen
   Listen=[::]:7500 (Stream)

9. tangd 서비스를 시작합니다.

   # systemctl restart tangd.socket

   tangd 는 systemd 소켓 활성화 메커니즘을 사용하므로 첫 번째 연결이 들어오는 즉시 서버가 시작됩니다. 새 암호화 키 집합이 처음 시작될 때 자동으로 생성됩니다. 수동 키 생성과 같은 암호화 작업을 수행하려면 jose 유틸리티를 사용합니다.

절차

1. /var/db/tang 키 데이터베이스 디렉터리의 모든 키의 이름을 로 변경하여 알림에서 숨깁니다 . 다음 예제의 파일 이름은 Tang 서버의 키 데이터베이스 디렉터리에서 고유한 파일 이름과 다릅니다.

   # cd /var/db/tang
   # ls -l
   -rw-r--r--. 1 root root 349 Feb  7 14:55 UV6dqXSwe1bRKG3KbJmdiR020hY.jwk
   -rw-r--r--. 1 root root 354 Feb  7 14:55 y9hxLTQSiSB5jSEGWnjhY8fDTJU.jwk
   # mv UV6dqXSwe1bRKG3KbJmdiR020hY.jwk .UV6dqXSwe1bRKG3KbJmdiR020hY.jwk
   # mv y9hxLTQSiSB5jSEGWnjhY8fDTJU.jwk .y9hxLTQSiSB5jSEGWnjhY8fDTJU.jwk

2. 이름을 변경했는지 확인한 후 Tang 서버 알림의 모든 키를 hid합니다.

   # ls -l
   total 0

3. Tang 서버의 /var/db/tang 에 있는 /usr/libexec/tangd-keygen 명령을 사용하여 새 키를 생성합니다.

   # /usr/libexec/tangd-keygen /var/db/tang
   # ls /var/db/tang
   3ZWS6-cDrCG61UPJS2BMmPU4I54.jwk zyLuX6hijUy_PSeUEFDi7hi38.jwk

4. Tang 서버가 새 키 쌍의 서명 키를 알리는지 확인합니다. 예를 들면 다음과 같습니다.

   # tang-show-keys 7500
   3ZWS6-cDrCG61UPJS2BMmPU4I54

5. RuntimeClass 클라이언트에서 clevis luks report 명령을 사용하여 Tang 서버에서 광고하는 키가 동일하게 남아 있는지 확인합니다. 예를 들어 clevis luks list 명령을 사용하여 관련 바인딩으로 슬롯을 식별할 수 있습니다.

   # clevis luks list -d /dev/sda2
   1: tang '{"url":"http://tang.srv"}'
   # clevis luks report -d /dev/sda2 -s 1
   ...
   Report detected that some keys were rotated.
   Do you want to regenerate luks metadata with "clevis luks regen -d /dev/sda2 -s 1"? [ynYN]

6. 새 키에 대한 LUKS 메타데이터를 다시 생성하려면 이전 명령의 프롬프트에서 y 를 클릭하거나 clevis luks regen 명령을 사용합니다.

   # clevis luks regen -d /dev/sda2 -s 1

7. 이전 클라이언트가 모두 새 키를 사용하는지 확인하면 Tang 서버에서 이전 키를 제거할 수 있습니다. 예를 들면 다음과 같습니다.

   # cd /var/db/tang
   # rm .*.jwk

절차

1. 웹 브라우저에서 다음 주소를 입력하여 RHEL 웹 콘솔을 엽니다.

   https://localhost:9090

   원격 시스템에 연결할 때 localhost 부분을 원격 서버의 호스트 이름 또는 IP 주소로 교체합니다.

2. 자격 증명을 제공하고 스토리지 를 클릭합니다. Tang 서버를 사용하여 잠금 해제하려는 암호화된 장치의 세부 정보를 확장하려면 > 암호화를 클릭합니다.

3. Keys 섹션에서 + 를 클릭하여 Tang 키를 추가합니다.

   

4. Tang 서버의 주소와 LUKS 암호화 장치의 잠금을 해제하는 암호를 제공합니다. 추가를 클릭하여 확인합니다.

   

   다음 대화 상자 창에서 키 해시와 일치하는지 확인하는 명령을 제공합니다.

5. Tang 서버의 터미널에서 tang-show-keys 명령을 사용하여 비교를 위해 키 해시를 표시합니다. 이 예에서 Tang 서버는 포트 7500 에서 실행 중입니다.

   # tang-show-keys 7500
   fM-EwYeiTxS66X3s1UAywsGKGnxnpll8ig0KOQmr9CM

6. 웹 콘솔 의 키 해시와 이전에 나열된 명령의 출력에 동일한 경우 신뢰 키를 클릭합니다.

   

7. 초기 부팅 시스템에서 디스크 바인딩을 처리할 수 있도록 하려면 왼쪽 탐색 모음 하단에서 Terminal 을 클릭하고 다음 명령을 입력합니다.

   # dnf install clevis-dracut
   # grubby --update-kernel=ALL --args="rd.neednet=1"
   # dracut -fv --regenerate-all

8. Clevis를 활성화하여 부팅 프로세스 늦은 볼륨도 잠금 해제하도록 하려면 시스템을 다시 시작하기 전에 클라이언트에서 다음 명령을 사용합니다.

   # systemctl enable clevis-luks-askpass.path

검증

1. 새로 추가된 Tang 키가 키 서버 유형의 Keys 섹션에 나열되어 있는지 확인합니다.

   

2. 바인딩이 초기 부팅에 사용 가능한지 확인합니다. 예를 들면 다음과 같습니다.

   # lsinitrd | grep clevis
   clevis
   clevis-pin-sss
   clevis-pin-tang
   clevis-pin-tpm2
   -rwxr-xr-x   1 root     root         1600 Feb 11 16:30 usr/bin/clevis
   -rwxr-xr-x   1 root     root         1654 Feb 11 16:30 usr/bin/clevis-decrypt
   ...
   -rwxr-xr-x   2 root     root           45 Feb 11 16:30 usr/lib/dracut/hooks/initqueue/settled/60-clevis-hook.sh
   -rwxr-xr-x   1 root     root         2257 Feb 11 16:30 usr/libexec/clevis-luks-askpass

절차

1. 기존 LUKS 암호화 볼륨을 자동으로 잠금 해제하려면 clevis-luks 하위 패키지를 설치합니다.

   # dnf install clevis-luks

2. PBD의 LUKS 암호화된 볼륨을 식별합니다. 다음 예에서 블록 장치는 /dev/sda2 라고 합니다.

   # lsblk
   NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
   sda                                             8:0    0    12G  0 disk
   ├─sda1                                          8:1    0     1G  0 part  /boot
   └─sda2                                          8:2    0    11G  0 part
     └─luks-40e20552-2ade-4954-9d56-565aa7994fb6 253:0    0    11G  0 crypt
       ├─rhel-root                               253:0    0   9.8G  0 lvm   /
       └─rhel-swap                               253:1    0   1.2G  0 lvm   [SWAP]

3. clevis luks bind 명령을 사용하여 볼륨을 Tang 서버에 바인딩합니다.

   # clevis luks bind -d /dev/sda2 tang '{"url":"http://tang.srv"}'
   The advertisement contains the following signing keys:
   
   _OsIk0T-E2l6qjfdDiwVmidoZjA
   
   Do you wish to trust these keys? [ynYN] y
   You are about to initialize a LUKS device for metadata storage.
   Attempting to initialize it may result in data loss if data was
   already written into the LUKS header gap in a different format.
   A backup is advised before initialization is performed.
   
   Do you wish to initialize /dev/sda2? [yn] y
   Enter existing LUKS password:

   이 명령은 다음 네 가지 단계를 수행합니다.

   1. LUKS 마스터 키와 동일한 엔트로피를 사용하여 새 키를 생성합니다.
   2. Clevis로 새 키를 암호화합니다.
   3. Clevis JWE 오브젝트를 LUKS2 헤더 토큰에 저장하거나 기본이 아닌 LUKS1 헤더가 사용되는 경우 LUKSMeta를 사용합니다.
   4. LUKS에 사용할 새 키를 활성화합니다.
   참고

   바인딩 절차에서는 빈 LUKS 암호 슬롯이 하나 이상 있다고 가정합니다. clevis luks bind 명령은 슬롯 중 하나를 사용합니다.

   이제 기존 암호와 Clevis 정책을 사용하여 볼륨을 잠금 해제할 수 있습니다.

4. Clevis를 활성화하여 부팅 프로세스 늦은 볼륨도 잠금 해제하도록 하려면 시스템을 다시 시작하기 전에 클라이언트에서 다음 명령을 사용합니다.

   # systemctl enable clevis-luks-askpass.path

5. 초기 부팅 시스템이 디스크 바인딩을 처리하도록 활성화하려면 이미 설치된 시스템에서 dracut 툴을 사용합니다.

   # dnf install clevis-dracut

   RHEL에서 Clevis는 호스트별 구성 옵션 없이 일반 initrd (initial ramdisk)를 생성하고 rd.neednet=1 과 같은 매개 변수를 커널 명령줄에 자동으로 추가하지 않습니다. 구성이 초기 부팅 중에 네트워크가 필요한 Tang 핀을 사용하는 경우 --hostonly-cmdline 인수를 사용하고 dracut 은 Tang 바인딩을 감지하면 rd.neednet=1 을 추가합니다.

   # dracut -fv --regenerate-all --hostonly-cmdline

   또는 /etc/dracut.conf.d/ 에 .conf 파일을 만들고 hostonly_cmdline=yes 옵션을 파일에 추가합니다.

   # echo "hostonly_cmdline=yes" > /etc/dracut.conf.d/clevis.conf

   참고

   Clevis가 설치된 시스템에서 grubby 툴을 사용하여 초기 부팅 중에 Tang 핀의 네트워킹을 사용할 수도 있습니다.

   # grubby --update-kernel=ALL --args="rd.neednet=1"

   그런 다음 --hostonly-cmdline 없이 dracut 을 사용할 수 있습니다.

   # dracut -fv --regenerate-all

검증

1. Clevis JWE 오브젝트가 LUKS 헤더에 성공적으로 배치되었는지 확인하려면 clevis luks list 명령을 사용합니다.

   # clevis luks list -d /dev/sda2
   1: tang '{"url":"http://tang.srv:port"}'

절차

1. 기존 LUKS 암호화 볼륨을 자동으로 잠금 해제하려면 clevis-luks 하위 패키지를 설치합니다.

   # dnf install clevis-luks

2. PBD의 LUKS 암호화된 볼륨을 식별합니다. 다음 예에서 블록 장치는 /dev/sda2 라고 합니다.

   # lsblk
   NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
   sda                                             8:0    0    12G  0 disk
   ├─sda1                                          8:1    0     1G  0 part  /boot
   └─sda2                                          8:2    0    11G  0 part
     └─luks-40e20552-2ade-4954-9d56-565aa7994fb6 253:0    0    11G  0 crypt
       ├─rhel-root                               253:0    0   9.8G  0 lvm   /
       └─rhel-swap                               253:1    0   1.2G  0 lvm   [SWAP]

3. clevis luks bind 명령을 사용하여 TPM 2.0 장치에 볼륨을 바인딩합니다. 예를 들면 다음과 같습니다.

   # clevis luks bind -d /dev/sda2 tpm2 '{"hash":"sha256","key":"rsa"}'
   ...
   Do you wish to initialize /dev/sda2? [yn] y
   Enter existing LUKS password:

   이 명령은 다음 네 가지 단계를 수행합니다.

   1. LUKS 마스터 키와 동일한 엔트로피를 사용하여 새 키를 생성합니다.
   2. Clevis로 새 키를 암호화합니다.
   3. Clevis JWE 오브젝트를 LUKS2 헤더 토큰에 저장하거나 기본이 아닌 LUKS1 헤더가 사용되는 경우 LUKSMeta를 사용합니다.

   4. LUKS에 사용할 새 키를 활성화합니다.

      참고

      바인딩 절차에서는 빈 LUKS 암호 슬롯이 하나 이상 있다고 가정합니다. clevis luks bind 명령은 슬롯 중 하나를 사용합니다.

      또는 특정 플랫폼 구성 등록 (PCR) 상태에 데이터를 바인딩하려는 경우 pcr_ llowedRegistries 및 pcr_ids 값을 clevis luks bind 명령에 추가합니다.

      # clevis luks bind -d /dev/sda2 tpm2 '{"hash":"sha256","key":"rsa","pcr_bank":"sha256","pcr_ids":"0,1"}'

      주의

      PCR 해시 값이 봉인 및 해시를 다시 작성할 수 있는 경우 사용된 정책과 일치할 때만 데이터를 해제할 수 있으므로 PCR의 값이 변경될 때 수동으로 암호화된 볼륨을 잠금 해제할 수 있는 강력한 암호를 추가합니다.

      shim-x64 패키지 업그레이드 후 암호화된 볼륨을 자동으로 잠금 해제할 수 없는 경우 Clevis TPM2의 단계에 따라 KCS를 다시 시작한 후 LUKS 장치의 암호를 해독하지 않습니다.

4. 이제 기존 암호와 Clevis 정책을 사용하여 볼륨을 잠금 해제할 수 있습니다.

5. 초기 부팅 시스템이 디스크 바인딩을 처리하도록 활성화하려면 이미 설치된 시스템에서 dracut 툴을 사용합니다.

   # dnf install clevis-dracut
   # dracut -fv --regenerate-all

검증

1. Clevis JWE 오브젝트가 LUKS 헤더에 성공적으로 배치되었는지 확인하려면 clevis luks list 명령을 사용합니다.

   # clevis luks list -d /dev/sda2
   1: tpm2 '{"hash":"sha256","key":"rsa"}'

절차

1. 볼륨에 바인딩된 LUKS 버전(예: /dev/sda2 )을 확인하고 Clevis에 바인딩된 슬롯과 토큰을 식별합니다.

   # cryptsetup luksDump /dev/sda2
   LUKS header information
   Version:        2
   ...
   Keyslots:
     0: luks2
   ...
   1: luks2
         Key:        512 bits
         Priority:   normal
         Cipher:     aes-xts-plain64
   ...
         Tokens:
           0: clevis
                 Keyslot:  1
   ...

   이전 예에서 Clevis 토큰은 0 으로 식별되고 연결된 키 슬롯은 1 입니다.

2. LUKS2 암호화의 경우 토큰을 제거합니다.

   # cryptsetup token remove --token-id 0 /dev/sda2

3. 장치가 LUKS1로 암호화된 경우 Version으로 표시됩니다. 1 cryptsetup luksDump 명령의 출력에 있는 문자열은 luksmeta quotation 명령을 사용하여 이 추가 단계를 수행합니다.

   # luksmeta wipe -d /dev/sda2 -s 1

4. Clevis 암호가 포함된 키 슬롯을 만듭니다.

   # cryptsetup luksKillSlot /dev/sda2 1

절차

1. 임시 암호로 /boot 이외의 모든 마운트 지점에 LUKS 암호화가 활성화되도록 Kickstart에 지시하십시오. 등록 프로세스의 이 단계에서는 암호가 임시적입니다.

   part /boot --fstype="xfs" --ondisk=vda --size=256
   part / --fstype="xfs" --ondisk=vda --grow --encrypted --passphrase=temppass

   예를 들어 OSPP 호환 시스템에는 더 복잡한 구성이 필요합니다.

   part /boot --fstype="xfs" --ondisk=vda --size=256
   part / --fstype="xfs" --ondisk=vda --size=2048 --encrypted --passphrase=temppass
   part /var --fstype="xfs" --ondisk=vda --size=1024 --encrypted --passphrase=temppass
   part /tmp --fstype="xfs" --ondisk=vda --size=1024 --encrypted --passphrase=temppass
   part /home --fstype="xfs" --ondisk=vda --size=2048 --grow --encrypted --passphrase=temppass
   part /var/log --fstype="xfs" --ondisk=vda --size=1024 --encrypted --passphrase=temppass
   part /var/log/audit --fstype="xfs" --ondisk=vda --size=1024 --encrypted --passphrase=temppass

2. %packages 섹션에 나열하여 관련 Clevis 패키지를 설치합니다.

   %packages
   clevis-dracut
   clevis-luks
   clevis-systemd
   %end

3. 필요한 경우 암호화된 볼륨의 잠금을 해제할 수 있도록 임시 암호를 제거하기 전에 강력한 암호를 추가합니다. 자세한 내용은 기존 LUKS 장치 문서에 암호, 키 또는 키 파일을 추가하는 방법을 참조하십시오.

4. clevis luks bind 를 호출하여 %post 섹션에서 바인딩을 수행합니다. 임시 암호를 제거합니다.Remove the temporary password:

   %post
   clevis luks bind -y -k - -d /dev/vda2 \
   tang '{"url":"http://tang.srv"}' <<< "temppass"
   cryptsetup luksRemoveKey /dev/vda2 <<< "temppass"
   dracut -fv --regenerate-all
   %end

   구성이 초기 부팅 중에 네트워크를 요구하는 Tang 핀을 사용하거나 고정 IP 구성으로 RuntimeClass 클라이언트를 사용하는 경우 LUKS 암호화 볼륨의 수동 등록 구성에 설명된 대로 dracut 명령을 수정해야 합니다.

   clevis luks bind 명령의 -y 옵션은 RHEL 8.3에서 사용할 수 있습니다. RHEL 8.2 이상에서 clevis luks bind 명령에서 -y 를 -f 로 바꾸고 Tang 서버에서 알림을 다운로드합니다.

   %post
   curl -sfg http://tang.srv/adv -o adv.jws
   clevis luks bind -f -k - -d /dev/vda2 \
   tang '{"url":"http://tang.srv","adv":"adv.jws"}' <<< "temppass"
   cryptsetup luksRemoveKey /dev/vda2 <<< "temppass"
   dracut -fv --regenerate-all
   %end

   주의

   cryptsetup luksRemoveKey 명령을 사용하면 적용하는 LUKS2 장치를 추가로 관리할 수 있습니다. LUKS1 장치에 대해서만 dmsetup 명령을 사용하여 제거된 마스터 키를 복구할 수 있습니다.

절차

1. LUKS 암호화된 이동식 스토리지 장치(예: USB 드라이브)의 잠금을 자동으로 잠금 해제하려면 clevis-udisks2 패키지를 설치합니다.

   # dnf install clevis-udisks2

2. 시스템을 재부팅한 다음 LUKS 암호화 볼륨의 수동 등록 구성에 설명된 대로 clevis luks bind 명령을 사용하여 바인딩 단계를 수행합니다. 예를 들면 다음과 같습니다.

   # clevis luks bind -d /dev/sdb1 tang '{"url":"http://tang.srv"}'

3. LUKS 암호화 이동식 장치는 이제 GNOME 데스크탑 세션에서 자동으로 잠금 해제할 수 있습니다. Clevis 정책에 바인딩된 장치도 clevis luks 잠금 해제 명령을 통해 잠금 해제할 수 있습니다.

   # clevis luks unlock -d /dev/sdb1

절차

1. registry.redhat.io 레지스트리에서 tang 컨테이너 이미지를 가져옵니다.

   # podman pull registry.redhat.io/rhel9/tang

2. 컨테이너를 실행하고 해당 포트를 지정하고 Tang 키의 경로를 지정합니다. 이전 예제에서는 tang 컨테이너를 실행하고 포트 7500 을 지정하고 /var/db/tang 디렉터리의 Tang 키의 경로를 나타냅니다.

   # podman run -d -p 7500:7500 -v tang-keys:/var/db/tang --name tang registry.redhat.io/rhel9/tang

   Tang은 기본적으로 포트 80을 사용하지만, Apache HTTP 서버와 같은 다른 서비스와 충돌할 수 있습니다.

3. [선택 사항] 보안을 강화하려면 Tang 키를 주기적으로 회전합니다. tangd-rotate-keys 스크립트를 사용할 수 있습니다. 예를 들면 다음과 같습니다.

   # podman run --rm -v tang-keys:/var/db/tang registry.redhat.io/rhel9/tang tangd-rotate-keys -v -d /var/db/tang
   Rotated key 'rZAMKAseaXBe0rcKXL1hCCIq-DY.jwk' -> .'rZAMKAseaXBe0rcKXL1hCCIq-DY.jwk'
   Rotated key 'x1AIpc6WmnCU-CabD8_4q18vDuw.jwk' -> .'x1AIpc6WmnCU-CabD8_4q18vDuw.jwk'
   Created new key GrMMX_WfdqomIU_4RyjpcdlXb0E.jwk
   Created new key _dTTfn17sZZqVAp80u3ygFDHtjk.jwk
   Keys rotated successfully.

절차

1. Tang 서버에 대한 설정이 포함된 플레이북을 준비합니다. 처음부터 시작하거나 /usr/share/ansible/roles/rhel-system-roles.nbde_server/examples/ 디렉터리에서 예제 플레이북 중 하나를 사용할 수 있습니다.

   # cp /usr/share/ansible/roles/rhel-system-roles.nbde_server/examples/simple_deploy.yml ./my-tang-playbook.yml

2. 선택한 텍스트 편집기에서 플레이북을 편집합니다. 예를 들면 다음과 같습니다.

   # vi my-tang-playbook.yml

3. 필수 매개 변수를 추가합니다. 다음 예제 Playbook은 Tang 서버와 키 교체를 배포합니다.

   ---
   - hosts: all
   
     vars:
       nbde_server_rotate_keys: yes
   
     roles:
       - rhel-system-roles.nbde_server

4. 완료된 플레이북을 적용합니다.

   # ansible-playbook -i inventory-file my-tang-playbook.yml

   여기서: * inventory-file 은 인벤토리 파일입니다. * logging-playbook.yml 은 사용하는 플레이북입니다.

절차

1. Clevis 클라이언트에 대한 설정이 포함된 플레이북을 준비합니다. 처음부터 시작하거나 /usr/share/ansible/roles/rhel-system-roles.nbde_client/examples/ 디렉터리에서 예제 플레이북 중 하나를 사용할 수 있습니다.

   # cp /usr/share/ansible/roles/rhel-system-roles.nbde_client/examples/high_availability.yml ./my-clevis-playbook.yml

2. 선택한 텍스트 편집기에서 플레이북을 편집합니다. 예를 들면 다음과 같습니다.

   # vi my-clevis-playbook.yml

3. 필수 매개 변수를 추가합니다. 다음 예제 Playbook은 두 개 이상의 Tang 서버를 사용할 수 있는 경우 두 개 이상의 LUKS 암호화 볼륨을 자동으로 잠금 해제하도록 Clevis 클라이언트를 구성합니다.

   ---
   - hosts: all
   
     vars:
       nbde_client_bindings:
         - device: /dev/rhel/root
           encryption_key_src: /etc/luks/keyfile
           servers:
             - http://server1.example.com
             - http://server2.example.com
         - device: /dev/rhel/swap
           encryption_key_src: /etc/luks/keyfile
           servers:
             - http://server1.example.com
             - http://server2.example.com
   
     roles:
       - rhel-system-roles.nbde_client

4. 완료된 플레이북을 적용합니다.

   # ansible-playbook -i host1,host2,host3 my-clevis-playbook.yml

파일 시스템 규칙 예

1. 모든 쓰기 액세스 권한을 기록하는 규칙과 의 모든 속성 변경 사항을 정의하려면 /etc/passwd 파일:

   # auditctl -w /etc/passwd -p wa -k passwd_changes

2. /etc/selinux/ 디렉토리에 있는 모든 쓰기 액세스 권한과 의 모든 속성 변경을 기록하는 규칙을 정의하려면 다음을 실행합니다.

   # auditctl -w /etc/selinux/ -p wa -k selinux_changes

시스템 호출 규칙 예

1. adjtimex 또는 settimeofday 시스템 호출이 프로그램이 사용될 때마다 로그 항목을 생성하는 규칙을 정의하려면 64비트 아키텍처를 사용합니다.

   # auditctl -a always,exit -F arch=b64 -S adjtimex -S settimeofday -k time_change

2. 파일이 삭제되거나 ID가 1000 이상인 시스템 사용자에 의해 이름이 변경될 때마다 로그 항목을 생성하는 규칙을 정의하려면 다음을 수행합니다.

   # auditctl -a always,exit -S unlink -S unlinkat -S rename -S renameat -F auid>=1000 -F auid!=4294967295 -k delete

   -F auid!=4294967295 옵션은 로그인 UID가 설정되지 않은 사용자를 제외하는 데 사용됩니다.

절차

1. /usr/lib/systemd/system/auditd.service 파일을 /etc/systemd/system/ 디렉터리에 복사합니다.

   # cp -f /usr/lib/systemd/system/auditd.service /etc/systemd/system/

2. 원하는 텍스트 편집기에서 /etc/systemd/system/auditd.service 파일을 편집합니다. 예를 들면 다음과 같습니다.

   # vi /etc/systemd/system/auditd.service

3. augenrules 가 포함된 행을 주석 처리하고 auditctl -R 명령의 주석 처리를 해제합니다.

   #ExecStartPost=-/sbin/augenrules --load
   ExecStartPost=-/sbin/auditctl -R /etc/audit/audit.rules

4. systemd 데몬을 다시 로드하여 auditd.service 파일에서 변경 사항을 가져옵니다.

   # systemctl daemon-reload

5. auditd 서비스를 다시 시작하십시오.

   # service auditd restart

절차

1. /usr/share/audit/sample -rules/ 디렉토리에서 사전 설정된 규칙 파일 44-installers. rules를 /etc/ audit/rules.d/ 디렉터리에 복사합니다.

   # cp /usr/share/audit/sample-rules/44-installers.rules /etc/audit/rules.d/

2. 감사 규칙을 로드합니다.

   # augenrules --load

검증

1. 로드된 규칙을 나열합니다.

   # auditctl -l
   -p x-w /usr/bin/dnf-3 -k software-installer
   -p x-w /usr/bin/yum -k software-installer
   -p x-w /usr/bin/pip -k software-installer
   -p x-w /usr/bin/npm -k software-installer
   -p x-w /usr/bin/cpan -k software-installer
   -p x-w /usr/bin/gem -k software-installer
   -p x-w /usr/bin/luarocks -k software-installer

2. 설치를 수행합니다. 예를 들면 다음과 같습니다.

   # dnf reinstall -y vim-enhanced

3. 감사 로그에서 최근 설치 이벤트를 검색합니다. 예를 들면 다음과 같습니다.

   # ausearch -ts recent -k software-installer
   ––––
   time->Thu Dec 16 10:33:46 2021
   type=PROCTITLE msg=audit(1639668826.074:298): proctitle=2F7573722F6C6962657865632F706C6174666F726D2D707974686F6E002F7573722F62696E2F646E66007265696E7374616C6C002D790076696D2D656E68616E636564
   type=PATH msg=audit(1639668826.074:298): item=2 name="/lib64/ld-linux-x86-64.so.2" inode=10092 dev=fd:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
   type=PATH msg=audit(1639668826.074:298): item=1 name="/usr/libexec/platform-python" inode=4618433 dev=fd:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:bin_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
   type=PATH msg=audit(1639668826.074:298): item=0 name="/usr/bin/dnf" inode=6886099 dev=fd:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:rpm_exec_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
   type=CWD msg=audit(1639668826.074:298): cwd="/root"
   type=EXECVE msg=audit(1639668826.074:298): argc=5 a0="/usr/libexec/platform-python" a1="/usr/bin/dnf" a2="reinstall" a3="-y" a4="vim-enhanced"
   type=SYSCALL msg=audit(1639668826.074:298): arch=c000003e syscall=59 success=yes exit=0 a0=55c437f22b20 a1=55c437f2c9d0 a2=55c437f2aeb0 a3=8 items=3 ppid=5256 pid=5375 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=3 comm="dnf" exe="/usr/libexec/platform-python3.6" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="software-installer"

절차

1. fapolicyd 패키지를 설치합니다.

   # dnf install fapolicyd

2. fapolicyd 서비스를 활성화하고 시작합니다.

   # systemctl enable --now fapolicyd

검증

1. fapolicyd 서비스가 올바르게 실행 중인지 확인합니다.

   # systemctl status fapolicyd
   ● fapolicyd.service - File Access Policy Daemon
      Loaded: loaded (/usr/lib/systemd/system/fapolicyd.service; enabled; vendor p>
      Active: active (running) since Tue 2019-10-15 18:02:35 CEST; 55s ago
     Process: 8818 ExecStart=/usr/sbin/fapolicyd (code=exited, status=0/SUCCESS)
    Main PID: 8819 (fapolicyd)
       Tasks: 4 (limit: 11500)
      Memory: 78.2M
      CGroup: /system.slice/fapolicyd.service
              └─8819 /usr/sbin/fapolicyd
   
   Oct 15 18:02:35 localhost.localdomain systemd[1]: Starting File Access Policy D>
   Oct 15 18:02:35 localhost.localdomain fapolicyd[8819]: Initialization of the da>
   Oct 15 18:02:35 localhost.localdomain fapolicyd[8819]: Reading RPMDB into memory
   Oct 15 18:02:35 localhost.localdomain systemd[1]: Started File Access Policy Da>
   Oct 15 18:02:36 localhost.localdomain fapolicyd[8819]: Creating database

2. root 권한이 없는 사용자로 로그인하여 fapolicyd 가 작동하는지 확인합니다. 예를 들면 다음과 같습니다.

   $ cp /bin/ls /tmp
   $ /tmp/ls
   bash: /tmp/ls: Operation not permitted

절차

1. 사용자 정의 바이너리를 필요한 디렉터리에 복사합니다. 예를 들면 다음과 같습니다.

   $ cp /bin/ls /tmp
   $ /tmp/ls
   bash: /tmp/ls: Operation not permitted

2. 사용자 지정 바이너리를 신뢰할 수 있는 것으로 표시하고 해당 항목을 /etc/fapolicyd/trust.d/ 의 myapp 파일에 저장합니다.

   # fapolicyd-cli --file add /tmp/ls --trust-file myapp

   --trust-file 옵션을 건너뛰면 이전 명령은 해당 행을 /etc/fapolicyd/fapolicyd.trust 에 추가합니다.

3. fapolicyd 데이터베이스를 업데이트합니다.

   # fapolicyd-cli --update

4. fapolicyd 를 다시 시작합니다.

   # systemctl restart fapolicyd

검증

1. 예를 들어 사용자 정의 바이너리를 실행할 수 있는지 확인합니다.

   $ /tmp/ls
   ls

절차

1. 사용자 정의 바이너리를 필요한 디렉터리에 복사합니다. 예를 들면 다음과 같습니다.

   $ cp /bin/ls /tmp
   $ /tmp/ls
   bash: /tmp/ls: Operation not permitted

2. fapolicyd 서비스를 중지합니다.

   # systemctl stop fapolicyd

3. 디버그 모드를 사용하여 해당 규칙을 식별합니다. fapolicyd --debug 명령의 출력은 자세한 정보이며 Ctrl+C 눌러만 중지하거나 해당 프로세스를 종료한 후 오류 출력을 파일로 리디렉션할 수 있습니다. 이 경우 --debug: 대신 --debug-deny 옵션을 사용하여 출력에 액세스 거부만 제한할 수 있습니다.

   # fapolicyd --debug-deny 2> fapolicy.output &
   [1] 51341

   또는 다른 터미널에서 fapolicyd debug 모드를 실행할 수 있습니다.

4. fapolicyd denied 명령을 반복합니다.

   $ /tmp/ls
   bash: /tmp/ls: Operation not permitted

5. 백그라운드에서 이를 다시 시작하고 Ctrl+C 눌러 디버그 모드를 중지합니다.

   # fg
   fapolicyd --debug 2> fapolicy.output
   ^C
   ...

   또는 fapolicyd 디버그 모드의 프로세스를 종료합니다.

   # kill 51341

6. 애플리케이션 실행을 거부하는 규칙을 찾습니다.

   # cat fapolicy.output | grep 'deny_audit'
   ...
   rule=13 dec=deny_audit perm=execute auid=0 pid=6855 exe=/usr/bin/bash : path=/tmp/ls ftype=application/x-executable trust=0

7. 사용자 지정 바이너리의 실행을 방해하는 규칙이 포함된 파일을 찾습니다. 이 경우 deny_audit perm=execute 규칙은 90-deny-execute.rules 파일에 속합니다.

   # ls /etc/fapolicyd/rules.d/
   10-languages.rules  40-bad-elf.rules	   72-shell.rules
   20-dracut.rules     41-shared-obj.rules    90-deny-execute.rules
   21-updaters.rules   42-trusted-elf.rules   95-allow-open.rules
   30-patterns.rules   70-trusted-lang.rules
   
   
   # cat /etc/fapolicyd/rules.d/90-deny-execute.rules
   # Deny execution for anything untrusted
   
   deny_audit perm=execute all : all

8. /etc/fapolicyd/rules.d/ 디렉터리에서 사용자 지정 바이너리의 실행을 거부한 규칙이 포함된 규칙 파일의 사전 우선 순위를 파일에 새 allow 규칙을 추가합니다.

   # touch /etc/fapolicyd/rules.d/80-myapps.rules
   # vi /etc/fapolicyd/rules.d/80-myapps.rules

   80-myapps.rules 파일에 다음 규칙을 삽입합니다.

   allow perm=execute exe=/usr/bin/bash trust=1 : path=/tmp/ls ftype=application/x-executable trust=0

   또는 /etc/fapolicyd/rules.d/:의 규칙 파일에 다음 규칙을 추가하여 /tmp 디렉토리에 있는 모든 바이너리의 실행을 허용할 수 있습니다.

   allow perm=execute exe=/usr/bin/bash trust=1 : dir=/tmp/ all trust=0

9. 사용자 정의 바이너리의 콘텐츠가 변경되지 않도록 하려면 SHA-256 체크섬을 사용하여 필요한 규칙을 정의합니다.

   $ sha256sum /tmp/ls
   780b75c90b2d41ea41679fcb358c892b1251b68d1927c80fbc0d9d148b25e836  ls

   규칙을 다음 정의로 변경합니다.

   allow perm=execute exe=/usr/bin/bash trust=1 : sha256hash=780b75c90b2d41ea41679fcb358c892b1251b68d1927c80fbc0d9d148b25e836

10. 컴파일된 목록이 /etc/fapolicyd/rules.d/ 의 규칙 세트와 다른지 확인하고 /etc/fapolicyd/ compiled.rules 파일에 저장된 목록을 업데이트합니다.

    # fagenrules --check
    /usr/sbin/fagenrules: Rules have changed and should be updated
    # fagenrules --load

11. 사용자 지정 규칙이 실행을 방해하기 전에 fapolicyd 규칙 목록에 있는지 확인합니다.

    # fapolicyd-cli --list
    ...
    13. allow perm=execute exe=/usr/bin/bash trust=1 : path=/tmp/ls ftype=application/x-executable trust=0
    14. deny_audit perm=execute all : all
    ...

12. fapolicyd 서비스를 시작합니다.

    # systemctl start fapolicyd

검증

1. 예를 들어 사용자 정의 바이너리를 실행할 수 있는지 확인합니다.

   $ /tmp/ls
   ls

절차

1. 선택한 텍스트 편집기에서 /etc/fapolicyd/fapolicyd.conf 파일을 엽니다. 예를 들면 다음과 같습니다.

   # vi /etc/fapolicyd/fapolicyd.conf

2. 무결성 옵션의 값을 none 에서 sha256 로 변경하고 파일을 저장하고 편집기를 종료합니다.

   integrity = sha256

3. fapolicyd 서비스를 다시 시작합니다.

   # systemctl restart fapolicyd

검증

1. 확인에 사용되는 파일을 백업합니다.

   # cp /bin/more /bin/more.bak

2. /bin/more 바이너리의 내용을 변경합니다.

   # cat /bin/less > /bin/more

3. 변경된 바이너리를 일반 사용자로 사용합니다.

   # su example.user
   $ /bin/more /etc/redhat-release
   bash: /bin/more: Operation not permitted

4. 변경 사항을 되돌립니다.

   # mv -f /bin/more.bak /bin/more

절차

1. usbguard 패키지를 설치합니다.

   # dnf install usbguard

2. 초기 규칙 세트를 생성합니다.

   # usbguard generate-policy > /etc/usbguard/rules.conf

3. usbguard 데몬을 시작하고 부팅 시 자동으로 시작되는지 확인합니다.

   # systemctl enable --now usbguard

검증

1. usbguard 서비스가 실행 중인지 확인합니다.

   # systemctl status usbguard
   ● usbguard.service - USBGuard daemon
      Loaded: loaded (/usr/lib/systemd/system/usbguard.service; enabled; vendor preset: disabled)
      Active: active (running) since Thu 2019-11-07 09:44:07 CET; 3min 16s ago
        Docs: man:usbguard-daemon(8)
    Main PID: 6122 (usbguard-daemon)
       Tasks: 3 (limit: 11493)
      Memory: 1.2M
      CGroup: /system.slice/usbguard.service
              └─6122 /usr/sbin/usbguard-daemon -f -s -c /etc/usbguard/usbguard-daemon.conf
   
   Nov 07 09:44:06 localhost.localdomain systemd[1]: Starting USBGuard daemon...
   Nov 07 09:44:07 localhost.localdomain systemd[1]: Started USBGuard daemon.

2. USBGuard 에서 인식하는 USB 장치를 나열합니다.

   # usbguard list-devices
   4: allow id 1d6b:0002 serial "0000:02:00.0" name "xHCI Host Controller" hash...

절차

1. USBGuard 에서 인식하는 USB 장치를 나열합니다.

   # usbguard list-devices
   1: allow id 1d6b:0002 serial "0000:00:06.7" name "EHCI Host Controller" hash "JDOb0BiktYs2ct3mSQKopnOOV2h9MGYADwhT+oUtF2s=" parent-hash "4PHGcaDKWtPjKDwYpIRG722cB9SlGz9l9Iea93+Gt9c=" via-port "usb1" with-interface 09:00:00
   ...
   6: block id 1b1c:1ab1 serial "000024937962" name "Voyager" hash "CrXgiaWIf2bZAU+5WkzOE7y0rdSO82XMzubn7HDb95Q=" parent-hash "JDOb0BiktYs2ct3mSQKopnOOV2h9MGYADwhT+oUtF2s=" via-port "1-3" with-interface 08:06:50

2. 시스템과 상호 작용하도록 장치 6 을 인증합니다.

   # usbguard allow-device 6

3. 장치 6 의 인증을 해제하고 제거 :

   # usbguard reject-device 6

4. 장치의 인증을 해제하고 장치 6 을 유지합니다.

   # usbguard block-device 6

절차

1. usbguard 데몬이 규칙을 작성할 수 있도록 SELinux를 구성합니다.

   1. usbguard 와 관련된 semanage 부울을 표시합니다.

      # semanage boolean -l | grep usbguard
      usbguard_daemon_write_conf     (off  ,  off)  Allow usbguard to daemon write conf
      usbguard_daemon_write_rules    (on   ,   on)  Allow usbguard to daemon write rules

   2. 선택 사항: usbguard_daemon_write_rules 부울이 꺼지면 전원을 켭니다.

      # semanage boolean -m --on usbguard_daemon_write_rules

2. USBGuard 에서 인식하는 USB 장치를 나열합니다.

   # usbguard list-devices
   1: allow id 1d6b:0002 serial "0000:00:06.7" name "EHCI Host Controller" hash "JDOb0BiktYs2ct3mSQKopnOOV2h9MGYADwhT+oUtF2s=" parent-hash "4PHGcaDKWtPjKDwYpIRG722cB9SlGz9l9Iea93+Gt9c=" via-port "usb1" with-interface 09:00:00
   ...
   6: block id 1b1c:1ab1 serial "000024937962" name "Voyager" hash "CrXgiaWIf2bZAU+5WkzOE7y0rdSO82XMzubn7HDb95Q=" parent-hash "JDOb0BiktYs2ct3mSQKopnOOV2h9MGYADwhT+oUtF2s=" via-port "1-3" with-interface 08:06:50

3. 시스템과 상호 작용하도록 장치 6 을 영구적으로 인증합니다.

   # usbguard allow-device 6 -p

4. 장치를 영구적으로 인증 해제하고 6:를 제거하십시오.

   # usbguard reject-device 6 -p

5. 영구적으로 장치의 인증을 해제하고 장치 6 을 유지합니다.

   # usbguard block-device 6 -p

검증

1. USBGuard 규칙에 변경 사항이 포함되어 있는지 확인합니다.

   # usbguard list-rules

절차

1. 현재 연결된 USB 장치를 인증하는 정책을 생성하고 생성된 규칙을 rules.conf 파일에 저장합니다.

   # usbguard generate-policy --no-hashes > ./rules.conf

   --no-hashes 옵션은 장치에 대한 해시 속성을 생성하지 않습니다. 영구적이 아닐 수 있으므로 구성 설정에서 해시 속성을 사용하지 않도록 합니다.

2. 선택한 텍스트 편집기를 사용하여 rules.conf 파일을 편집합니다. 예를 들면 다음과 같습니다.

   # vi ./rules.conf

3. 필요에 따라 규칙을 추가, 제거 또는 편집합니다. 예를 들어 다음 규칙은 단일 대용량 스토리지 인터페이스가 있는 장치만 시스템과 상호 작용할 수 있습니다.

   allow with-interface equals { 08:*:* }

   자세한 규칙 언어 설명 및 자세한 예제는 usbguard-rules.conf(5) 매뉴얼 페이지를 참조하십시오.

4. 업데이트된 정책을 설치합니다.

   # install -m 0600 -o root -g root rules.conf /etc/usbguard/rules.conf

5. usbguard 데몬을 다시 시작하여 변경 사항을 적용합니다.

   # systemctl restart usbguard

검증

1. 사용자 지정 규칙이 활성 정책에 있는지 확인합니다. 예를 들면 다음과 같습니다.

   # usbguard list-rules
   ...
   4: allow with-interface 08:*:*
   ...

절차

1. 현재 연결된 USB 장치를 인증하는 정책을 만들고 생성된 규칙을 새 .conf 파일(예: policy.conf )에 저장합니다.

   # usbguard generate-policy --no-hashes > ./policy.conf

   --no-hashes 옵션은 장치에 대한 해시 속성을 생성하지 않습니다. 영구적이 아닐 수 있으므로 구성 설정에서 해시 속성을 사용하지 않도록 합니다.

2. 선택한 텍스트 편집기로 policy.conf 파일을 표시합니다. 예를 들면 다음과 같습니다.

   # vi ./policy.conf
   ...
   allow id 04f2:0833 serial "" name "USB Keyboard" via-port "7-2" with-interface { 03:01:01 03:00:00 } with-connect-type "unknown"
   ...

3. 선택한 행을 별도의 .conf 파일로 이동합니다.

   참고

   파일 이름 시작 부분에 있는 두 자리는 데몬이 구성 파일을 읽는 순서를 지정합니다.

   예를 들어 키보드의 규칙을 새 . conf 파일에 복사합니다.

   # grep "USB Keyboard" ./policy.conf > ./10keyboards.conf

4. 새 정책을 /etc/usbguard/rules.d/ 디렉터리에 설치합니다.

   # install -m 0600 -o root -g root 10keyboards.conf /etc/usbguard/rules.d/10keyboards.conf

5. 나머지 행을 기본 rules.conf 파일로 이동합니다.

   # grep -v "USB Keyboard" ./policy.conf > ./rules.conf

6. 나머지 규칙을 설치합니다.

   # install -m 0600 -o root -g root rules.conf /etc/usbguard/rules.conf

7. usbguard 데몬을 다시 시작하여 변경 사항을 적용합니다.

   # systemctl restart usbguard

검증

1. 활성 USBGuard 규칙을 모두 표시합니다.

   # usbguard list-rules
   ...
   15: allow id 04f2:0833 serial "" name "USB Keyboard" hash "kxM/iddRe/WSCocgiuQlVs6Dn0VEza7KiHoDeTz0fyg=" parent-hash "2i6ZBJfTl5BakXF7Gba84/Cp1gslnNc1DM6vWQpie3s=" via-port "7-2" with-interface { 03:01:01 03:00:00 } with-connect-type "unknown"
   ...

2. /etc/usbguard/rules.d/ 디렉터리에 있는 rules.conf 파일과 모든 .conf 파일의 내용을 표시합니다.

   # cat /etc/usbguard/rules.conf /etc/usbguard/rules.d/*.conf

3. 활성 규칙에 파일의 모든 규칙과 올바른 순서로 포함되어 있는지 확인합니다.

절차

1. 텍스트 편집기로 /etc/usbguard/usbguard-daemon.conf 파일을 편집합니다.

   # vi /etc/usbguard/usbguard-daemon.conf

2. 예를 들어, wheel 그룹의 모든 사용자가 IPC 인터페이스를 사용할 수 있도록 허용하는 규칙과 함께 행을 추가하고 파일을 저장합니다.

   IPCAllowGroups=wheel

3. usbguard 명령을 사용하여 사용자 또는 그룹을 추가할 수도 있습니다. 예를 들어 다음 명령을 사용하면 joesec 사용자가 Devices 및 Exceptions 섹션에 대한 전체 액세스 권한을 가질 수 있습니다. 또한 joesec 은 현재 정책을 나열하고 수정할 수 있습니다.

   # usbguard add-user joesec --devices ALL --policy modify,list --exceptions ALL

   joesec 사용자에 대해 부여된 권한을 제거하려면 usbguard remove-user joesec 명령을 사용합니다.

4. usbguard 데몬을 다시 시작하여 변경 사항을 적용합니다.

   # systemctl restart usbguard

절차

1. 선택한 텍스트 편집기를 사용하여 usbguard-daemon.conf 파일을 편집합니다.

   # vi /etc/usbguard/usbguard-daemon.conf

2. FileAudit 에서 LinuxAudit 로 AuditBackend 옵션을 변경합니다.

   AuditBackend=LinuxAudit

3. usbguard 데몬을 다시 시작하여 구성 변경 사항을 적용합니다.

   # systemctl restart usbguard

검증

1. USB 권한 부여 이벤트의 감사 데몬 로그를 쿼리합니다. 예를 들면 다음과 같습니다.

   # ausearch -ts recent -m USER_DEVICE

절차

1. 선택 사항: rsyslog 트래픽에 다른 포트를 사용하려면 syslogd_port_t SELinux 유형을 포트에 추가합니다. 예를 들어 포트 30514 를 활성화합니다.

   # semanage port -a -t syslogd_port_t -p tcp 30514

2. 선택 사항: rsyslog 트래픽에 다른 포트를 사용하려면 해당 포트에서 들어오는 rsyslog 트래픽을 허용하도록 firewalld 를 구성합니다. 예를 들어 포트 30514 에서 TCP 트래픽을 허용하십시오.

   # firewall-cmd --zone=<zone-name> --permanent --add-port=30514/tcp
   success
   # firewall-cmd --reload

3. /etc/rsyslog.d/ 디렉토리에 라는 새 파일을 만듭니다(예: remotelog.conf ).

   # Define templates before the rules that use them
   # Per-Host templates for remote systems
   template(name="TmplAuthpriv" type="list") {
       constant(value="/var/log/remote/auth/")
       property(name="hostname")
       constant(value="/")
       property(name="programname" SecurePath="replace")
       constant(value=".log")
       }
   
   template(name="TmplMsg" type="list") {
       constant(value="/var/log/remote/msg/")
       property(name="hostname")
       constant(value="/")
       property(name="programname" SecurePath="replace")
       constant(value=".log")
       }
   
   # Provides TCP syslog reception
   module(load="imtcp")
   
   # Adding this ruleset to process remote messages
   ruleset(name="remote1"){
        authpriv.*   action(type="omfile" DynaFile="TmplAuthpriv")
         *.info;mail.none;authpriv.none;cron.none
   action(type="omfile" DynaFile="TmplMsg")
   }
   
   input(type="imtcp" port="30514" ruleset="remote1")

4. 변경 사항을 /etc/rsyslog.d/remotelog.conf 파일에 저장합니다.

5. /etc/rsyslog.conf 파일의 구문을 테스트합니다.

   # rsyslogd -N 1
   rsyslogd: version 8.1911.0-2.el8, config validation run (level 1), master config /etc/rsyslog.conf
   rsyslogd: End of config validation run. Bye.

6. rsyslog 서비스가 로깅 서버에서 실행 중이고 활성화되어 있는지 확인합니다.

   # systemctl status rsyslog

7. rsyslog 서비스를 다시 시작합니다.

   # systemctl restart rsyslog

8. 선택 사항: rsyslog 가 활성화되지 않은 경우 재부팅 후 rsyslog 서비스가 자동으로 시작되는지 확인하십시오.

   # systemctl enable rsyslog

절차

1. /etc/rsyslog.d/ 디렉토리에 라는 새 파일을 만듭니다(예: 10-remotelog.conf ).

   *.* action(type="omfwd"
         queue.type="linkedlist"
         queue.filename="example_fwd"
         action.resumeRetryCount="-1"
         queue.saveOnShutdown="on"
         target="example.com" port="30514" protocol="tcp"
        )

   다음과 같습니다.

   • queue.type="linkedlist" 는 LinkedList in-memory 큐를 활성화합니다.
   • queue.filename 은 디스크 스토리지를 정의합니다. 위의 글로벌 workDirectory 지시문으로 지정된 작업 디렉터리에서 example_fwd 접두사를 사용하여 백업 파일이 생성됩니다.
   • action.resumeRetryCount -1 설정을 사용하면 서버가 응답하지 않는 경우 연결을 다시 시도할 때 rsyslog 에서 메시지를 삭제하지 않습니다.
   • 활성화된 queue.saveOnShutdown="on" 은 rsyslog 가 종료되면 in-memory 데이터를 저장합니다.

   • 마지막 줄은 수신된 모든 메시지를 로깅 서버에 전달합니다. 포트 사양은 선택 사항입니다.

     이 구성을 사용하면 rsyslog 가 서버로 메시지를 전송하지만 원격 서버에 연결할 수 없는 경우 메모리에 메시지를 유지합니다. rsyslog 가 구성된 메모리 대기열 공간이 부족하거나 시스템 성능을 높여야 하는 경우에만 디스크의 파일이 생성됩니다.

   참고

   rsyslog는 사전 순서로 구성 파일 /etc/rsyslog.d/ 를 처리합니다.

2. rsyslog 서비스를 다시 시작합니다.

   # systemctl restart rsyslog

1. 클라이언트 시스템에서 테스트 메시지를 보냅니다.

   # logger test

2. 서버 시스템에서 /var/log/messages 로그를 확인합니다. 예를 들면 다음과 같습니다.

   # cat /var/log/remote/msg/hostname/root.log
   Feb 25 03:53:17 hostname root[6064]: test

   여기서 hostname 은 클라이언트 시스템의 호스트 이름입니다. 로그에는 logger 명령을 입력한 사용자의 사용자 이름이 포함됩니다(이 경우 루트 ).

절차

1. 클라이언트 시스템에서 암호화된 로그를 수신하도록 서버를 구성합니다.

   1. /etc/rsyslog.d/ 디렉토리에 라는 새 파일을 만듭니다(예: securelogser.conf ).

   2. 통신을 암호화하려면 구성 파일에 서버의 인증서 파일 경로, 선택한 인증 방법 및 TLS 암호화를 지원하는 스트림 드라이버가 포함되어야 합니다. /etc/rsyslog.d/securelogser.conf 파일에 다음 행을 추가합니다.

      # Set certificate files
      global(
        DefaultNetstreamDriverCAFile="/etc/pki/ca-trust/source/anchors/ca-cert.pem"
        DefaultNetstreamDriverCertFile="/etc/pki/ca-trust/source/anchors/server-cert.pem"
        DefaultNetstreamDriverKeyFile="/etc/pki/ca-trust/source/anchors/server-key.pem"
      )
      
      # TCP listener
      module(
        load="imtcp"
        PermittedPeer=["client1.example.com", "client2.example.com"]
        StreamDriver.AuthMode="x509/name"
        StreamDriver.Mode="1"
        StreamDriver.Name="ossl"
      )
      
      # Start up listener at port 514
      input(
        type="imtcp"
        port="514"
      )

      참고

      GnuTLS 드라이버를 선호하는 경우 StreamDriver.Name="gtls" 구성 옵션을 사용합니다. x509/name 보다 덜 엄격한 인증 모드에 대한 자세한 내용은 rsyslog-doc 패키지와 함께 설치된 설명서를 참조하십시오.

   3. /etc/rsyslog.d/securelogser.conf 파일에 변경 사항을 저장합니다.

   4. /etc/rsyslog.conf 파일의 구문과 /etc/rsyslog.d/ 디렉토리에 있는 파일을 확인합니다.

      # rsyslogd -N 1
      rsyslogd: version 8.1911.0-2.el8, config validation run (level 1), master config /etc/rsyslog.conf
      rsyslogd: End of config validation run. Bye.

   5. rsyslog 서비스가 로깅 서버에서 실행 중이고 활성화되어 있는지 확인합니다.

      # systemctl status rsyslog

   6. rsyslog 서비스를 다시 시작합니다.

      # systemctl restart rsyslog

   7. 선택 사항: Rsyslog가 활성화되지 않은 경우 재부팅 후 rsyslog 서비스가 자동으로 시작되는지 확인하십시오.

      # systemctl enable rsyslog

2. 암호화된 로그를 서버로 전송하도록 클라이언트를 구성합니다.

   1. 클라이언트 시스템에서 /etc/rsyslog.d/ 디렉토리에 새 파일을 만듭니다(예: securelogcli.conf ).

   2. /etc/rsyslog.d/securelogcli.conf 파일에 다음 행을 추가합니다.

      # Set certificate files
      global(
        DefaultNetstreamDriverCAFile="/etc/pki/ca-trust/source/anchors/ca-cert.pem"
        DefaultNetstreamDriverCertFile="/etc/pki/ca-trust/source/anchors/client-cert.pem"
        DefaultNetstreamDriverKeyFile="/etc/pki/ca-trust/source/anchors/client-key.pem"
      )
      
      
      # Set up the action for all messages
      *.* action(
        type="omfwd"
        StreamDriver="ossl"
        StreamDriverMode="1"
        StreamDriverPermittedPeers="server.example.com"
        StreamDriverAuthMode="x509/name"
        target="server.example.com" port="514" protocol="tcp"
      )

      참고

      GnuTLS 드라이버를 선호하는 경우 StreamDriver.Name="gtls" 구성 옵션을 사용합니다.

   3. /etc/rsyslog.d/securelogser.conf 파일에 변경 사항을 저장합니다.

   4. /etc/rsyslog.d/ 디렉토리에 있는 '/etc/rsyslog.conf 파일 및 기타 파일의 구문을 확인합니다.

      # rsyslogd -N 1
      rsyslogd: version 8.1911.0-2.el8, config validation run (level 1), master config /etc/rsyslog.conf
      rsyslogd: End of config validation run. Bye.

   5. rsyslog 서비스가 로깅 서버에서 실행 중이고 활성화되어 있는지 확인합니다.

      # systemctl status rsyslog

   6. rsyslog 서비스를 다시 시작합니다.

      # systemctl restart rsyslog

   7. 선택 사항: Rsyslog가 활성화되지 않은 경우 재부팅 후 rsyslog 서비스가 자동으로 시작되는지 확인하십시오.

      # systemctl enable rsyslog

1. 클라이언트 시스템에서 테스트 메시지를 보냅니다.

   # logger test

2. 서버 시스템에서 /var/log/messages 로그를 확인합니다. 예를 들면 다음과 같습니다.

   # cat /var/log/remote/msg/hostname/root.log
   Feb 25 03:53:17 hostname root[6064]: test

   여기서 hostname 은 클라이언트 시스템의 호스트 이름입니다. 로그에는 logger 명령을 입력한 사용자의 사용자 이름이 포함됩니다(이 경우 루트 ).

절차

1. 선택 사항: 기본 포트 514 이외의 rsyslog 트래픽에 다른 포트를 사용하려면 다음을 수행합니다.

   1. syslogd_port_t SELinux 유형을 SELinux 정책 구성에 추가하고, portno 를 rsyslog 가 사용할 포트 번호로 대체합니다.

      # semanage port -a -t syslogd_port_t -p udp portno

   2. 들어오는 rsyslog 트래픽을 허용하고 portno 를 rsyslog 가 사용할 영역으로 대체하도록 firewalld 를 구성합니다.

      # firewall-cmd --zone=zone --permanent --add-port=portno/udp
      success
      # firewall-cmd --reload

   3. 방화벽 규칙을 다시 로드합니다.

      # firewall-cmd --reload

2. /etc/rsyslog.d/ 디렉토리(예: remotelogserv .conf )에 새 .conf 파일을 만들고 다음 내용을 삽입합니다.

   # Define templates before the rules that use them
   # Per-Host templates for remote systems
   template(name="TmplAuthpriv" type="list") {
       constant(value="/var/log/remote/auth/")
       property(name="hostname")
       constant(value="/")
       property(name="programname" SecurePath="replace")
       constant(value=".log")
       }
   
   template(name="TmplMsg" type="list") {
       constant(value="/var/log/remote/msg/")
       property(name="hostname")
       constant(value="/")
       property(name="programname" SecurePath="replace")
       constant(value=".log")
       }
   
   # Provides UDP syslog reception
   module(load="imudp")
   
   # This ruleset processes remote messages
   ruleset(name="remote1"){
        authpriv.*   action(type="omfile" DynaFile="TmplAuthpriv")
         *.info;mail.none;authpriv.none;cron.none
   action(type="omfile" DynaFile="TmplMsg")
   }
   
   input(type="imudp" port="514" ruleset="remote1")

   여기서 514 는 기본적으로 rsyslog 가 사용하는 포트 번호입니다. 대신 다른 포트를 지정할 수 있습니다.

3. /etc/rsyslog.conf 파일 및 /etc/rsyslog. d/ 디렉토리에 있는 모든 . conf 파일의 구문을 확인합니다.

   # rsyslogd -N 1
   rsyslogd: version 8.1911.0-2.el8, config validation run (level 1), master config /etc/rsyslog.conf
   rsyslogd: End of config validation run. Bye.

4. rsyslog 서비스를 다시 시작합니다.

   # systemctl restart rsyslog

5. 선택 사항: rsyslog 가 활성화되지 않은 경우 재부팅 후 rsyslog 서비스가 자동으로 시작되는지 확인하십시오.

   # systemctl enable rsyslog

절차

1. /etc/rsyslog.d/ 디렉토리에 새 .conf 파일을 만듭니다(예: 10-remotelogcli.conf ).

   *.* action(type="omfwd"
         queue.type="linkedlist"
         queue.filename="example_fwd"
         action.resumeRetryCount="-1"
         queue.saveOnShutdown="on"
         target="example.com" port="portno" protocol="udp"
        )

   다음과 같습니다.

   • queue.type="linkedlist" 는 LinkedList in-memory 큐를 활성화합니다.
   • queue.filename 은 디스크 스토리지를 정의합니다. 위의 글로벌 workDirectory 지시문으로 지정된 작업 디렉터리에 example_fwd 접두사를 사용하여 백업 파일이 생성됩니다.
   • action.resumeRetryCount -1 설정은 서버가 응답하지 않는 경우 연결을 재시도할 때 rsyslog 가 메시지를 삭제하지 못하도록 합니다.
   • rsyslog 가 종료되면 활성화된 queue.saveOnShutdown="on" 은 메모리 내 데이터를 저장합니다.
   • portno 는 rsyslog 가 사용할 포트 번호입니다. 기본값은 514 입니다.

   • 마지막 줄은 수신된 모든 메시지를 로깅 서버에 전달합니다. 포트 사양은 선택 사항입니다.

     이 구성을 사용하면 rsyslog 가 서버로 메시지를 전송하지만 원격 서버에 연결할 수 없는 경우 메모리에 메시지를 유지합니다. rsyslog 가 구성된 메모리 대기열 공간이 부족하거나 시스템 성능을 높여야 하는 경우에만 디스크의 파일이 생성됩니다.

   참고

   rsyslog는 사전 순서로 구성 파일 /etc/rsyslog.d/ 를 처리합니다.

2. rsyslog 서비스를 다시 시작합니다.

   # systemctl restart rsyslog

3. 선택 사항: rsyslog 가 활성화되지 않은 경우 재부팅 후 rsyslog 서비스가 자동으로 시작되는지 확인하십시오.

   # systemctl enable rsyslog

1. 클라이언트 시스템에서 테스트 메시지를 보냅니다.

   # logger test

2. 서버 시스템에서 /var/log/remote/msg/hostname/root.log 로그를 확인합니다. 예를 들면 다음과 같습니다.

   # cat /var/log/remote/msg/hostname/root.log
   Feb 25 03:53:17 hostname root[6064]: test

   여기서 hostname 은 클라이언트 시스템의 호스트 이름입니다. 로그에는 logger 명령을 입력한 사용자의 사용자 이름이 포함됩니다(이 경우 루트 ).