네트워크 보안
보안 네트워크 및 네트워크 통신 구성
초록
보다 포괄적 수용을 위한 오픈 소스 용어 교체
Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.
Red Hat 문서에 관한 피드백 제공
문서에 대한 피드백에 감사드립니다. 어떻게 개선할 수 있는지 알려주십시오.
특정 문구에 대한 의견 제출
- Multi-page HTML 형식으로 설명서를 보고 페이지가 완전히 로드된 후 오른쪽 상단 모서리에 피드백 버튼이 표시되는지 확인합니다.
- 커서를 사용하여 주석 처리할 텍스트 부분을 강조 표시합니다.
- 강조 표시된 텍스트 옆에 표시되는 피드백 추가 버튼을 클릭합니다.
- 의견을 추가하고 제출 을 클릭합니다.
Bugzilla를 통해 피드백 제출(등록 필요)
- Bugzilla 웹 사이트에 로그인합니다.
- 버전 메뉴에서 올바른 버전을 선택합니다.
- Summary (요약) 필드에 설명 제목을 입력합니다.
- Description (설명) 필드에 개선을 위한 제안을 입력합니다. 문서의 관련 부분에 대한 링크를 포함합니다.
- 버그 제출을 클릭합니다.
1장. OpenSSH로 두 시스템 간의 보안 통신 사용
SSH(Secure Shell)는 클라이언트-서버 아키텍처를 사용하여 두 시스템 간에 보안 통신을 제공하고 사용자가 서버 호스트 시스템에 원격으로 로그인할 수 있는 프로토콜입니다. FTP 또는 Telnet과 같은 다른 원격 통신 프로토콜과 달리 SSH는 로그인 세션을 암호화하여 침입자가 연결에서 암호화되지 않은 암호를 수집하지 못하게 합니다.
Red Hat Enterprise Linux에는 일반 openssh
패키지, openssh-server
패키지, openssh-clients
패키지 등 기본 OpenSSH
패키지가 포함되어 있습니다. OpenSSH
패키지에는 OpenSSH
가 암호화된 통신을 제공할 수 있는 몇 가지 중요한 암호화 라이브러리를 설치하는 OpenSSL
패키지 openssl-libs
가 있어야 합니다.
1.1. SSH 및 OpenSSH
SSH(Secure Shell)는 원격 시스템에 로그인하고 해당 시스템에서 명령을 실행하는 프로그램입니다. SSH 프로토콜은 비보안 네트워크를 통해 신뢰할 수 없는 두 호스트 간에 안전한 암호화된 통신을 제공합니다. 보안 채널을 통해 X11 연결 및 임의의 TCP/IP 포트를 전달할 수도 있습니다.
SSH 프로토콜은 원격 쉘 로그인 또는 파일 복사에 사용할 때 두 시스템 간 통신 가로채기 및 특정 호스트의 가장과 같은 보안 위협을 완화합니다. 이는 SSH 클라이언트와 서버가 디지털 서명을 사용하여 신원을 확인하기 때문입니다. 또한 클라이언트와 서버 시스템 간의 모든 통신이 암호화됩니다.
호스트 키는 SSH 프로토콜에서 호스트를 인증합니다. 호스트 키는 OpenSSH가 처음 설치될 때 또는 호스트가 처음 부팅될 때 자동으로 생성되는 암호화 키입니다.
OpenSSH는 Linux, UNIX 및 유사한 운영 체제에서 지원하는 SSH 프로토콜 구현입니다. OpenSSH 클라이언트와 서버 모두에 필요한 코어 파일을 포함합니다. OpenSSH 제품군은 다음 사용자 공간 툴로 구성됩니다.
-
SSH
는 원격 로그인 프로그램(SSH 클라이언트)입니다. -
sshd
는 OpenSSH SSH 데몬입니다. -
SCP
는 안전한 파일 복사 프로그램입니다. -
SFTP
는 안전한 파일 전송 프로그램입니다. -
SSH-agent
는 개인 키를 캐싱하기 위한 인증 에이전트입니다. -
ssh-add
는ssh-agent
에 개인 키 ID를 추가합니다. -
SSH-keygen은
에 대한 인증 키를 생성, 관리 및 변환합니다.ssh
-
ssh-copy-id
는 원격 SSH 서버의authorized_keys
파일에 로컬 공개 키를 추가하는 스크립트입니다. -
SSH-keyscan
은 SSH 공개 호스트 키를 수집합니다.
RHEL 9에서는 기본적으로 SFTP(Secure File Transfer Protocol)가 SSH 파일 전송 프로토콜(SCP)으로 교체됩니다. 이는 SCP가 이미 보안 문제를 발생했기 때문입니다(예: CVE-2020-15778).
사용자의 시나리오에서 SFTP를 사용할 수 없거나 호환되지 않는 경우 -O
옵션을 사용하여 원래 SCP/RCP 프로토콜을 강제로 사용할 수 있습니다.
자세한 내용은 Red Hat Enterprise Linux 9에서 OpenSSH SCP 프로토콜 사용 중단 문서를 참조하십시오.
SSH에는 현재 버전 1과 최신 버전 2의 두 가지 버전이 있습니다. RHEL의 OpenSSH 제품군은 SSH 버전 2만 지원합니다. 버전 1에서 알려진 악용에 취약하지 않은 향상된 key-exchange 알고리즘을 가지고 있습니다.
OpenSSH는 RHEL의 핵심 암호화 하위 시스템 중 하나로 시스템 전체 암호화 정책을 사용합니다. 이렇게 하면 기본 구성에서 약한 암호 제품군 및 암호화 알고리즘이 비활성화됩니다. 정책을 수정하려면 관리자는 update-crypto-policies
명령을 사용하여 설정을 조정하거나 시스템 전체 암호화 정책을 수동으로 비활성화해야 합니다.
OpenSSH 제품군은 클라이언트 프로그램(즉, ssh
,scp
, sftp
)과 서버( sshd
데몬)에 대한 두 가지 구성 파일 세트를 사용합니다.
시스템 전체 SSH 구성 정보는 /etc/ssh/
디렉토리에 저장됩니다. 사용자별 SSH 구성 정보는 사용자 홈 디렉터리의 ~/.ssh/
에 저장됩니다. OpenSSH 구성 파일의 자세한 목록은 sshd(8)
도움말 페이지의 FILES
섹션을 참조하십시오.
추가 리소스
-
man -k ssh
명령을 사용하여 나열된 도움말 페이지 - 시스템 전체 암호화 정책 사용
1.2. OpenSSH 서버 구성 및 시작
환경 및 OpenSSH 서버를 시작하는 데 필요할 수 있는 기본 구성에는 다음 절차를 사용합니다. 기본 RHEL 설치 후에는 sshd
데몬이 이미 시작되고 서버 호스트 키가 자동으로 생성됩니다.
사전 요구 사항
-
openssh-server
패키지가 설치되어 있어야 합니다.
절차
현재 세션에서
sshd
데몬을 시작하고 부팅 시 자동으로 시작되도록 설정합니다.# systemctl start sshd # systemctl enable sshd
/etc/ssh/sshd_config 구성 파일의 ListenAddress 지시문의 경우 기본값
0.0.0.0
(IPv4) 또는::
(IPv6) 이외의 다른 주소를 지정하고 느린 동적 네트워크 구성을 사용하려면network-online.target
대상 장치에 대한 종속성을sshd.service
장치 파일에 추가합니다. 이를 위해 다음 내용으로 사용하여/etc/systemd/system/sshd.service.d/local.conf
파일을 만듭니다.[Unit] Wants=network-online.target After=network-online.target
-
/etc/ssh/sshd_config
구성 파일의 OpenSSH 서버 설정이 시나리오 요구 사항을 충족하는지 검토합니다. 선택적으로
/etc/issue
파일을 편집하여 클라이언트를 인증하기 전에 OpenSSH 서버가 표시하는 시작 메시지를 변경합니다. 예를 들면 다음과 같습니다.Welcome to ssh-server.example.com Warning: By accessing this server, you agree to the referenced terms and conditions.
Banner
옵션이/etc/ssh/sshd_config
에서 주석 처리되지 않고 해당 값에/etc/issue
가 포함되어 있는지 확인하십시오.# less /etc/ssh/sshd_config | grep Banner Banner /etc/issue
로그인에 성공한 후 표시되는 메시지를 변경하려면 서버에서
/etc/motd
파일을 편집해야 합니다. 자세한 내용은pam_motd
도움말 페이지를 참조하십시오.systemd
구성을 다시 로드하고sshd
를 다시 시작하여 변경 사항을 적용합니다.# systemctl daemon-reload # systemctl restart sshd
검증
sshd
데몬이 실행 중인지 확인합니다.# systemctl status sshd ● sshd.service - OpenSSH server daemon Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2019-11-18 14:59:58 CET; 6min ago Docs: man:sshd(8) man:sshd_config(5) Main PID: 1149 (sshd) Tasks: 1 (limit: 11491) Memory: 1.9M CGroup: /system.slice/sshd.service └─1149 /usr/sbin/sshd -D -oCiphers=aes128-ctr,aes256-ctr,aes128-cbc,aes256-cbc -oMACs=hmac-sha2-256,> Nov 18 14:59:58 ssh-server-example.com systemd[1]: Starting OpenSSH server daemon... Nov 18 14:59:58 ssh-server-example.com sshd[1149]: Server listening on 0.0.0.0 port 22. Nov 18 14:59:58 ssh-server-example.com sshd[1149]: Server listening on :: port 22. Nov 18 14:59:58 ssh-server-example.com systemd[1]: Started OpenSSH server daemon.
SSH 클라이언트를 사용하여 SSH 서버에 연결합니다.
# ssh user@ssh-server-example.com ECDSA key fingerprint is SHA256:dXbaS0RG/UzlTTku8GtXSz0S1++lPegSy31v3L/FAEc. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added 'ssh-server-example.com' (ECDSA) to the list of known hosts. user@ssh-server-example.com's password:
추가 리소스
-
sshd(8)
및sshd_config(5)
도움말 페이지
1.3. 키 기반 인증을 위한 OpenSSH 서버 설정
시스템 보안을 강화하려면 OpenSSH 서버에서 암호 인증을 비활성화하여 키 기반 인증을 시행합니다.
사전 요구 사항
-
openssh-server
패키지가 설치되어 있어야 합니다. -
sshd
데몬이 서버에서 실행되고 있어야 합니다.
절차
텍스트 편집기에서
/etc/ssh/sshd_config
구성을 엽니다. 예를 들면 다음과 같습니다.# vi /etc/ssh/sshd_config
PasswordAuthentication
옵션을no
로 변경합니다.PasswordAuthentication no
새 기본 설치 이외의 시스템에서
PubkeyAuthentication no
가 설정되지 않았으며ChallengeResponseAuthentication
지시문이no
로 설정되어 있는지 확인합니다. 콘솔 또는 대역 외 액세스를 사용하지 않고 원격으로 연결하는 경우 암호 인증을 비활성화하기 전에 키 기반 로그인 프로세스를 테스트합니다.NFS로 마운트된 홈 디렉토리에서 키 기반 인증을 사용하려면
use_nfs_home_dirs
SELinux 부울을 활성화합니다.# setsebool -P use_nfs_home_dirs 1
sshd
데몬을 다시 로드하여 변경 사항을 적용합니다.# systemctl reload sshd
추가 리소스
-
sshd(8)
,sshd_config(5)
및setsebool(8)
도움말 페이지
1.4. SSH 키 쌍 생성
이 절차를 사용하여 로컬 시스템에 SSH 키 쌍을 생성하고 생성된 공개 키를 OpenSSH 서버에 복사합니다. 서버가 적절하게 구성된 경우 암호를 제공하지 않고 OpenSSH 서버에 로그인할 수 있습니다.
다음 단계를 root
로 완료하면 root
만 키를 사용할 수 있습니다.
절차
SSH 프로토콜의 버전 2에 대한 ECDSA 키 쌍을 생성하려면 다음을 수행합니다.
$ ssh-keygen -t ecdsa Generating public/private ecdsa key pair. Enter file in which to save the key (/home/joesec/.ssh/id_ecdsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/joesec/.ssh/id_ecdsa. Your public key has been saved in /home/joesec/.ssh/id_ecdsa.pub. The key fingerprint is: SHA256:Q/x+qms4j7PCQ0qFd09iZEFHA+SqwBKRNaU72oZfaCI joesec@localhost.example.com The key's randomart image is: +---[ECDSA 256]---+ |.oo..o=++ | |.. o .oo . | |. .. o. o | |....o.+... | |o.oo.o +S . | |.=.+. .o | |E.*+. . . . | |.=..+ +.. o | | . oo*+o. | +----[SHA256]-----+
ssh-keygen -t ed25519
명령을 입력하여ssh-keygen
명령 또는 Ed25519 키 쌍과 함께-t rsa
옵션을 사용하여 RSA 키 쌍을 생성할 수도 있습니다.공개 키를 원격 머신에 복사하려면 다음을 수행합니다.
$ ssh-copy-id joesec@ssh-server-example.com /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed joesec@ssh-server-example.com's password: ... Number of key(s) added: 1 Now try logging into the machine, with: "ssh 'joesec@ssh-server-example.com'" and check to make sure that only the key(s) you wanted were added.
세션에서
ssh-agent
프로그램을 사용하지 않는 경우 이전 명령은 가장 최근에 수정된~/.ssh/id*.pub
공개 키가 아직 설치되지 않은 경우 공개 키를 복사합니다. 다른 공개 키 파일을 지정하거나ssh-agent
로 메모리에 캐시된 키보다 파일의 키 우선 순위를 지정하려면ssh-copy-id
명령을-i
옵션과 함께 사용합니다.
시스템을 다시 설치하고 이전에 생성된 키 쌍을 유지하려면 ~/.ssh/
디렉터리를 백업합니다. 다시 설치한 후 홈 디렉터리로 복사합니다. root
를 포함하여 시스템의 모든 사용자에 대해 이 작업을 수행할 수 있습니다.
검증
암호를 제공하지 않고 OpenSSH 서버에 로그인합니다.
$ ssh joesec@ssh-server-example.com Welcome message. ... Last login: Mon Nov 18 18:28:42 2019 from ::1
추가 리소스
-
ssh-keygen(1)
및ssh-copy-id(1)
도움말 페이지
1.5. 스마트 카드에 저장된 SSH 키 사용
Red Hat Enterprise Linux를 사용하면 OpenSSH 클라이언트의 스마트 카드에 저장된 RSA 및 ECDSA 키를 사용할 수 있습니다. 다음 절차에 따라 암호 대신 스마트 카드로 인증을 활성화합니다.
사전 요구 사항
-
클라이언트 측에서
opensc
패키지가 설치되고pcscd
서비스가 실행 중입니다.
절차
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
원격 서버(example.com)에서 스마트 카드를 사용하여 인증을 활성화하려면 공개 키를 원격 서버로 전송합니다. 이전 단계에서 만든 keys.pub와 함께
ssh-copy-id
명령을 사용하십시오.$ ssh-copy-id -f -i keys.pub username@example.com
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] $
~/.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] $
PKCS #11 URI의 id=
부분을 건너뛰면 OpenSSH는 proxy 모듈에서 사용할 수 있는 모든 키를 로드합니다. 이렇게 하면 필요한 입력 횟수가 줄어듭니다.
$ ssh -i pkcs11: example.com
Enter PIN for 'SSH key':
[example.com] $
추가 리소스
- Fedora 28: OpenSSH에서 스마트 카드 지원 개선
-
p11-kit(8)
,opensc.conf(5)
,pcscd(8)
,ssh(1)
및ssh-keygen(1)
매뉴얼 페이지
1.6. OpenSSH의 보안 강화
다음 팁은 OpenSSH를 사용할 때 보안을 강화하는 데 도움이 됩니다. /etc/ssh/sshd_config
OpenSSH 구성 파일의 변경 사항을 적용하려면 sshd
데몬을 다시 로드해야 합니다.
# systemctl reload sshd
대부분의 보안 강화 구성 변경으로 최신 알고리즘 또는 암호 제품군을 지원하지 않는 클라이언트와의 호환성이 줄어듭니다.
비보안 연결 프로토콜 비활성화
- SSH를 효과적으로 사용하려면 OpenSSH 제품군으로 대체되는 안전하지 않은 연결 프로토콜을 사용하지 않도록 합니다. 그렇지 않으면 Telnet을 사용하여 로그인할 때 나중에 하나의 세션이 캡처되도록 SSH를 사용하여 사용자 암호를 보호할 수 있습니다. 이러한 이유로 telnet, rsh, rlogin 및 ftp와 같은 비보안 프로토콜을 비활성화하는 것이 좋습니다.
키 기반 인증 활성화 및 암호 기반 인증 비활성화
인증에 대한 암호 비활성화 및 키 쌍만 허용하면 공격 면적이 줄어들고 사용자의 시간도 절약할 수 있습니다. 클라이언트에서
ssh-keygen
툴을 사용하여 키 쌍을 생성하고ssh-copy-id
유틸리티를 사용하여 OpenSSH 서버의 클라이언트에서 공개 키를 복사합니다. OpenSSH 서버에서 암호 기반 인증을 비활성화하려면/etc/ssh/sshd_config
를 편집하고PasswordAuthentication
옵션을no
로 변경합니다.PasswordAuthentication no
키 유형
ssh-keygen
명령은 기본적으로 RSA 키 쌍을 생성하지만-t
옵션을 사용하여 ECDSA 또는 Ed25519 키를 생성하도록 지시할 수 있습니다. ECDSA(Elliptic Curve Digital Signature Algorithm)는 동등한 대칭 키 힘에서 RSA보다 더 나은 성능을 제공합니다. 또한 더 짧은 키를 생성합니다. Ed25519 공개 키 알고리즘은 RSA, DSA 및 ECDSA보다 더 빠르고 안전하며 더 빠릅니다.OpenSSH는 RSA, ECDSA 및 Ed25519 서버 호스트 키가 누락된 경우 자동으로 생성합니다. RHEL에서 호스트 키 생성을 구성하려면
sshd-keygen@.service
인스턴스화 서비스를 사용합니다. 예를 들어, RSA 키 유형의 자동 생성을 비활성화하려면 다음을 실행합니다.# systemctl mask sshd-keygen@rsa.service
참고cloud-init
가 활성화된 이미지에서ssh-keygen
단위가 자동으로 비활성화됩니다. 이는ssh-keygen 템플릿
서비스가cloud-init
툴을 방해하고 호스트 키 생성에 문제가 발생할 수 있기 때문입니다. 이러한 문제를 방지하려면cloud-init
가 실행 중인 경우etc/systemd/system/sshd-keygen@.service.d/disable-sshd-keygen-if-cloud-init-active.conf
드롭인 구성 파일에서ssh-keygen
장치를 비활성화합니다.SSH 연결에 대한 특정 키 유형을 제외하려면
/etc/ssh/sshd_config
에서 관련 행을 주석 처리하고sshd
서비스를 다시 로드합니다. 예를 들어 Ed25519 호스트 키만 허용하려면 다음을 수행합니다.# HostKey /etc/ssh/ssh_host_rsa_key # HostKey /etc/ssh/ssh_host_ecdsa_key HostKey /etc/ssh/ssh_host_ed25519_key
기본값 이외의 포트
기본적으로
sshd
데몬은 TCP 포트 22에서 수신 대기합니다. 포트를 변경하면 자동화된 네트워크 스캔을 기반으로 시스템이 공격에 노출되는 것을 줄이며 비만에 의해 보안이 향상됩니다./etc/ssh/sshd_config
구성 파일에서Port
지시문을 사용하여 포트를 지정할 수 있습니다.또한 기본이 아닌 포트를 사용할 수 있도록 기본 SELinux 정책을 업데이트해야 합니다. 이렇게 하려면
policycoreutils-python-utils
패키지에서semanage
툴을 사용합니다.# semanage port -a -t ssh_port_t -p tcp port_number
또한
firewalld
구성을 업데이트합니다.# firewall-cmd --add-port port_number/tcp # firewall-cmd --runtime-to-permanent
이전 명령에서 port_number를
Port
지시문을 사용하여 지정된 새 포트 번호로 바꿉니다.
Root 로그인
PermitRootLogin
은 기본적으로prohibit-password
로 설정됩니다. 이렇게 하면 root로 로그인하는 데 암호를 사용하는 대신 키 기반 인증을 사용하고 무차별 강제 공격을 방지하여 위험을 줄입니다.경고관리자가 권한이 있는 명령을 실행하는 사용자를 감사할 수 없기 때문에 root 사용자로 로그인 활성화는 안전한 방법이 아닙니다. 관리 명령을 사용하려면 로그인하고
sudo
를 대신 사용합니다.
X 보안 확장 사용
Red Hat Enterprise Linux 클라이언트의 X 서버는 X 보안 확장을 제공하지 않습니다. 따라서 클라이언트는 X11 전달을 사용하여 신뢰할 수 없는 SSH 서버에 연결할 때 다른 보안 계층을 요청할 수 없습니다. 대부분의 애플리케이션은 이 확장 기능을 사용하여 실행할 수 없습니다.
기본적으로
/etc/ssh/ssh_config.d/05-redhat.conf
파일의ForwardX11Trusted
옵션은yes
로 설정되어 있으며ssh -X remote_machine
(신뢰할 수 없는 호스트)과ssh -Y remote_machine
(신뢰할 수 있는 호스트) 명령 사이에 차이가 없습니다.시나리오에 X11 전달 기능이 전혀 필요하지 않은 경우
/etc/ssh/sshd_config
구성 파일의X11Forwarding
지시문을no
로 설정합니다.
특정 사용자, 그룹 또는 도메인에 대한 액세스 제한
/etc/ssh/sshd_config
구성 파일 서버의AllowUsers
및AllowGroups
지시문을 사용하면 특정 사용자, 도메인 또는 그룹만 OpenSSH 서버에 연결할 수 있습니다.AllowUsers
및AllowGroups
를 결합하여 보다 정확하게 액세스를 제한할 수 있습니다. 예를 들면 다음과 같습니다.AllowUsers *@192.168.1.*,*@10.0.0.*,!*@192.168.1.2 AllowGroups example-group
이전 구성 행은 192.168.1.2 주소가 있는 시스템을 제외하고 192.168.1.* 및 10.0.0.* 서브넷의 모든 사용자로부터의 연결을 허용합니다. 모든 사용자는
example-group
그룹에 있어야 합니다. OpenSSH 서버는 다른 모든 연결을 거부합니다.허용 목록(허용으로 시작하는 디렉터리)을 사용하는 것은 차단 목록(거부로 시작하는 옵션)을 사용하는 것보다 더 안전합니다. allowlists는 새로운 권한 없는 사용자 또는 그룹도 차단하기 때문입니다.
시스템 전체 암호화 정책 변경
OpenSSH는 RHEL 시스템 전체 암호화 정책을 사용하며 기본 시스템 전체 암호화 정책 수준은 현재 위협 모델에 대한 보안 설정을 제공합니다. 암호화 설정을 보다 엄격하게 수행하려면 현재 정책 수준을 변경합니다.
# update-crypto-policies --set FUTURE Setting system policy to FUTURE
-
OpenSSH 서버에 대한 시스템 전체 암호화 정책을 옵트아웃하려면
/etc/sysconfig/sshd
파일에서CRYPTO_POLICY=
변수로 행의 주석을 해제합니다. 이 변경 후/etc/ssh/sshd_config
파일의Ciphers
,MACs
,KexAlgoritms
,GSSAPIKexAlgorithms
섹션에 지정하는 값은 재정의되지 않습니다. 이 작업에는 암호화 옵션 구성에 대한 전문 지식이 필요합니다. - 자세한 내용은 보안 강화에서 시스템 전체 암호화 정책 사용을 참조하십시오.
추가 리소스
-
sshd_config(5)
,ssh-keygen(1)
,crypto-policies(7)
및update-crypto-policies(8)
도움말 페이지
1.7. SSH 건너뛰기 호스트를 사용하여 원격 서버에 연결
건너뛰기 호스트라고도 하는 중간 서버를 통해 로컬 시스템을 원격 서버에 연결하려면 다음 절차를 사용하십시오.
사전 요구 사항
- 건너뛰기 호스트는 로컬 시스템의 SSH 연결을 허용합니다.
- 원격 서버는 건너뛰기 호스트에서만 SSH 연결을 허용합니다.
절차
로컬 시스템에서
~/.ssh/config
파일을 편집하여 건너뛰기를 정의합니다. 예를 들면 다음과 같습니다.Host jump-server1 HostName jump1.example.com
-
Host
매개 변수는ssh
명령에서 사용할 수 있는 호스트의 이름 또는 별칭을 정의합니다. 이 값은 실제 호스트 이름과 일치할 수 있지만 임의의 문자열일 수도 있습니다. -
HostName
매개 변수는 건너뛰기 호스트의 실제 호스트 이름 또는 IP 주소를 설정합니다.
-
ProxyJump
지시문을 사용하여 원격 서버 건너뛰기를 로컬 시스템의~/.ssh/config
파일에 추가합니다. 예를 들면 다음과 같습니다.Host remote-server HostName remote1.example.com ProxyJump jump-server1
로컬 시스템을 사용하여 이동 서버를 통해 원격 서버에 연결합니다.
$ ssh remote-server
이전 명령은 구성 단계 1과 2를 생략하면
ssh -J jump-server1 remote-server
명령과 동일합니다.
더 많은 건너뛰기 서버를 지정할 수 있으며 전체 호스트 이름을 제공할 때 구성 파일에 호스트 정의 추가를 건너뛸 수도 있습니다. 예를 들면 다음과 같습니다.
$ ssh -J jump1.example.com,jump2.example.com,jump3.example.com remote1.example.com
건너뛰기 서버의 사용자 이름 또는 SSH 포트가 원격 서버의 이름과 포트와 다른 경우 이전 명령에서 호스트 이름 전용 표기법을 변경합니다. 예를 들면 다음과 같습니다.
$ ssh -J johndoe@jump1.example.com:75,johndoe@jump2.example.com:75,johndoe@jump3.example.com:75 joesec@remote1.example.com:220
추가 리소스
-
ssh_config(5)
및ssh(1)
도움말 페이지
1.8. ssh-agent를 사용하여 SSH 키가 있는 원격 시스템에 연결
SSH 연결을 시작할 때마다 암호를 입력하지 않으려면 ssh-agent
유틸리티를 사용하여 개인 SSH 키를 캐시할 수 있습니다. 개인 키와 암호는 안전하게 유지됩니다.
사전 요구 사항
- SSH 데몬이 실행되고 네트워크를 통해 연결할 수 있는 원격 호스트가 있습니다.
- IP 주소 또는 호스트 이름 및 인증 정보를 통해 원격 호스트에 로그인합니다.
- 암호를 사용하여 SSH 키 쌍을 생성하고 공개 키를 원격 시스템으로 전송했습니다.
절차
선택 사항: 키를 사용하여 원격 호스트에 인증할 수 있는지 확인합니다.
SSH를 사용하여 원격 호스트에 연결합니다.
$ ssh example.user1@198.51.100.1 hostname
개인 키에 대한 액세스 권한을 부여할 키를 만드는 동안 설정한 암호를 입력합니다.
$ ssh example.user1@198.51.100.1 hostname host.example.com
ssh-agent
를 시작합니다.$ eval $(ssh-agent) Agent pid 20062
ssh-agent
에 키를 추가합니다.$ ssh-add ~/.ssh/id_rsa Enter passphrase for ~/.ssh/id_rsa: Identity added: ~/.ssh/id_rsa (example.user0@198.51.100.12)
검증
선택 사항: SSH를 사용하여 호스트 시스템에 로그인합니다.
$ ssh example.user1@198.51.100.1 Last login: Mon Sep 14 12:56:37 2020
암호를 입력할 필요가 없습니다.
1.9. 추가 리소스
-
sshd(8)
,ssh(1)
,scp(1)
,sftp(1)
,ssh-keygen(1)
,ssh-copy-id(1)
,ssh_config(5)
,sshd_config(5)
,update-crypto-policies(8)
및crypto-policies(7)
도움말 페이지 - OpenSSH Home Page
- 비표준 구성을 사용하여 애플리케이션 및 서비스에 대한 SELinux 구성
- firewalld를 사용하여 네트워크 트래픽 제어
2장. ssh
시스템 역할을 사용하여 보안 통신 구성
관리자는 sshd
시스템 역할을 사용하여 SSH 서버 및 ssh
시스템 역할을 구성하여 Ansible Core 패키지를 사용하여 동시에 여러 RHEL 시스템에서 SSH 클라이언트를 일관되게 구성할 수 있습니다.
2.1. SSH
Server 시스템 역할 변수
sshd
시스템 역할 플레이북에서는 기본 설정 및 제한 사항에 따라 SSH 구성 파일의 매개변수를 정의할 수 있습니다.
이러한 변수를 구성하지 않으면 시스템 역할은 RHEL 기본값과 일치하는 sshd_config
파일을 생성합니다.
모든 경우에 부울이 sshd
구성에서 yes
및 no
로 올바르게 렌더링됩니다. 목록을 사용하여 여러 줄 구성 항목을 정의할 수 있습니다. 예를 들면 다음과 같습니다.
sshd_ListenAddress: - 0.0.0.0 - '::'
다음과 같이 렌더링됩니다.
ListenAddress 0.0.0.0 ListenAddress ::
sshd
시스템 역할에 대한 변수
sshd_enable
-
False
로 설정하면 역할이 완전히 비활성화됩니다. 기본값은True
입니다. sshd_skip_defaults
-
True
로 설정하면 시스템 역할이 기본값이 적용되지 않습니다. 대신sshd
dict 또는sshd_Key
변수를 사용하여 전체 구성 기본값 세트를 지정합니다. 기본값은False
입니다. sshd_manage_service
-
False
로 설정하면 서비스가 관리되지 않으므로 부팅 시 활성화되지 않으며 시작 또는 다시 로드되지 않습니다. Ansible service 모듈이 현재 AIX에 대해enabled
되지 않으므로 컨테이너 또는 AIX 내부에서 실행되는 경우를 제외하고 기본값은True
입니다. sshd_allow_reload
-
False
로 설정하면 구성이 변경된 후sshd
가 다시 로드되지 않습니다. 이는 문제 해결에 도움이 될 수 있습니다. 변경된 구성을 적용하려면sshd
를 수동으로 다시 로드합니다. 기본값은 AIX를 제외하고sshd_manage_service
와 동일한 값입니다. 여기서sshd_manage_service
기본값은False
이지만sshd_allow_reload
의 기본값은True
입니다. sshd_install_service
True
로 설정하면 역할은sshd
서비스에 대한 서비스 파일을 설치합니다. 이렇게 하면 운영 체제에 제공된 파일이 재정의됩니다. 두 번째 인스턴스를 구성하고sshd_service
변수도 변경하지 않는 한True
로 설정하지 마십시오. 기본값은False
입니다.역할은 다음 변수에서 가리키는 파일을 템플릿으로 사용합니다.
sshd_service_template_service (default: templates/sshd.service.j2) sshd_service_template_at_service (default: templates/sshd@.service.j2) sshd_service_template_socket (default: templates/sshd.socket.j2)
sshd_service
-
이 변수는 두 번째
sshd
서비스 인스턴스를 구성하는 데 유용한sshd
서비스 이름을 변경합니다. sshd
구성이 포함된 dict입니다. 예를 들면 다음과 같습니다.
sshd: Compression: yes ListenAddress: - 0.0.0.0
sshd_OptionName
dict 대신
sshd_
접두사와 옵션 이름으로 구성된 간단한 변수를 사용하여 옵션을 정의할 수 있습니다. simple 변수는sshd
dict의 값을 재정의합니다. 예를 들면 다음과 같습니다.sshd_Compression: no
sshd_match
및sshd_match_1
tosshd_match_9
-
dicts 목록 또는 일치 섹션의 경우 dict에 불과합니다. 이러한 변수는
sshd
dict에 정의된 대로 일치하는 블록을 재정의하지 않습니다. 결과 구성 파일에 모든 소스가 반영됩니다.
sshd
시스템 역할의 보조 변수
이러한 변수를 사용하여 지원되는 각 플랫폼에 해당하는 기본값을 재정의할 수 있습니다.
sshd_packages
- 이 변수를 사용하여 설치된 패키지의 기본 목록을 재정의할 수 있습니다.
sshd_config_owner
,sshd_config_group
, andsshd_config_mode
-
이 역할에서 이러한 변수를 사용하여 생성하는
openssh
구성 파일의 소유권 및 권한을 설정할 수 있습니다. sshd_config_file
-
이 역할이
openssh
서버 구성이 생성된 경로입니다. sshd_config_namespace
이 변수의 기본값은 null입니다. 즉, 역할이 시스템 기본값을 포함하여 구성 파일의 전체 콘텐츠를 정의함을 의미합니다. 또는 이 변수를 사용하여 드롭인 디렉터리를 지원하지 않는 시스템의 단일 플레이북에 있는 다른 역할 또는 여러 위치에서 이 역할을 호출할 수 있습니다.
sshd_skip_defaults
변수는 무시되며 이 경우 시스템 기본값이 사용되지 않습니다.이 변수를 설정하면 역할이 지정된 구성을 지정된 네임스페이스 아래에 기존 구성 파일의 구성 스니펫에 배치합니다. 시나리오에 역할을 여러 번 적용해야 하는 경우 각 애플리케이션에 대해 다른 네임스페이스를 선택해야 합니다.
참고openssh
구성 파일의 제한 사항은 계속 적용됩니다. 예를 들어 구성 파일에 지정된 첫 번째 옵션만 대부분의 구성 옵션에 적용됩니다.기술적으로, 역할은 기존 구성 파일의 이전 일치 블록과 관계없이 적용되도록 다른 일치 블록을 포함하지 않는 한 "Match all" 블록에 코드 조각을 배치합니다. 이를 통해 다양한 역할 호출에서 충돌하지 않는 옵션을 구성할 수 있습니다.
sshd_binary
-
openssh
의sshd
실행 파일의 경로입니다. sshd_service
-
sshd
서비스의 이름입니다. 기본적으로 이 변수에는 대상 플랫폼에서 사용하는sshd
서비스의 이름이 포함됩니다. 또한 역할에서sshd_install_service
변수를 사용하는 경우 사용자 지정sshd
서비스의 이름을 설정할 수도 있습니다. sshd_verify_hostkeys
-
기본값은
auto
입니다.auto
로 설정하면 생성된 구성 파일에 있는 모든 호스트 키가 나열되고 존재하지 않는 경로가 생성됩니다. 또한 권한 및 파일 소유자는 기본값으로 설정됩니다. 이 기능은 배포 단계에서 역할을 사용하여 첫 번째 시도에서 서비스를 시작할 수 있는지 확인하는 데 유용합니다. 이 확인을 비활성화하려면 이 변수를 빈 목록[]
으로 설정합니다. sshd_hostkey_owner
,sshd_hostkey_group
,sshd_hostkey_mode
-
이러한 변수를 사용하여
sshd_verify_hostkeys
에서 호스트 키에 대한 소유권 및 권한을 설정합니다. sshd_sysconfig
-
RHEL 기반 시스템에서 이 변수는
sshd
서비스에 대한 추가 세부 정보를 구성합니다.true
로 설정하면 이 역할은 다음 구성에 따라/etc/sysconfig/sshd
구성 파일도 관리합니다. 기본값은false
입니다. sshd_sysconfig_override_crypto_policy
-
RHEL에서
true
로 설정하면 이 변수가 시스템 전체 암호화 정책을 재정의합니다. 기본값은false
입니다. sshd_sysconfig_use_strong_rng
-
RHEL 기반 시스템에서 이 변수는
sshd
에서 인수로 지정된 바이트 수를 사용하여openssl
임의 번호 생성기를 다시 작성할 수 있습니다. 기본값은0
으로, 이 기능을 비활성화합니다. 시스템에 하드웨어 임의 번호 생성기가 없는 경우 이 값을 설정하지 마십시오.
2.2. sshd
시스템 역할을 사용하여 OpenSSH 서버 구성
Ansible 플레이북을 실행하여 sshd
시스템 역할을 사용하여 여러 SSH 서버를 구성할 수 있습니다.
SSH 및 SSHD 구성을 변경하는 다른 시스템 역할(예: Identity Management RHEL 시스템 역할)과 함께 sshd
시스템 역할을 사용할 수 있습니다. 구성을 덮어쓰지 않으려면 sshd
역할에서 네임스페이스(RHEL 8 및 이전 버전) 또는 드롭인 디렉터리(RHEL 9)를 사용하는지 확인합니다.
사전 요구 사항
-
sshd
시스템 역할로 구성하려는 시스템인 하나 이상의 관리형 노드에 대한 액세스 및 권한. Red Hat Ansible Core가 기타 시스템을 구성하는 시스템인 제어 노드 액세스 및 사용 권한.
제어 노드에서 다음이 있어야 합니다.
-
ansible-core
및rhel-system-roles
패키지가 설치됩니다.
-
RHEL 8.0-8.5는 Ansible 기반 자동화를 위해 Ansible Engine 2.9가 포함된 별도의 Ansible 리포지토리에 대한 액세스를 제공했습니다. Ansible Engine에는 ansible ,
, ansible
-playbookdocker
및 podman
과 같은 커넥터, 여러 플러그인 및 모듈과 같은 명령줄 유틸리티가 포함되어 있습니다. Ansible Engine을 확보하고 설치하는 방법에 대한 자세한 내용은 Red Hat Ansible Engine 지식베이스를 다운로드하고 설치하는 방법 문서를 참조하십시오.
RHEL 8.6 및 9.0에서는 Ansible 명령줄 유틸리티, 명령 및 소규모의 기본 제공 Ansible 플러그인 세트가 포함된 Ansible Core( ansible-core
패키지로 제공)를 도입했습니다. RHEL은 AppStream 리포지토리를 통해 이 패키지를 제공하며 제한된 지원 범위를 제공합니다. 자세한 내용은 RHEL 9 및 RHEL 8.6 이상 AppStream 리포지토리 지식 베이스에 포함된 Ansible Core 패키지에 대한 지원 범위를 참조하십시오.
- 관리 노드를 나열하는 인벤토리 파일.
절차
sshd
시스템 역할에 대한 예제 플레이북을 복사합니다.# cp /usr/share/doc/rhel-system-roles/sshd/example-root-login-playbook.yml path/custom-playbook.yml
텍스트 편집기를 사용하여 복사된 플레이북을 엽니다. 예를 들면 다음과 같습니다.
# vim path/custom-playbook.yml --- - hosts: all tasks: - name: Configure sshd to prevent root and password login except from particular subnet include_role: name: rhel-system-roles.sshd vars: sshd: # root login and password login is enabled only from a particular subnet PermitRootLogin: no PasswordAuthentication: no Match: - Condition: "Address 192.0.2.0/24" PermitRootLogin: yes PasswordAuthentication: yes
플레이북은 다음을 수행하도록 구성된 SSH 서버로 관리 노드를 구성합니다.
-
암호 및
root
사용자 로그인이 비활성화되어 있습니다 -
암호 및
root
사용자 로그인은 서브넷192.0.2.0/24
에서만 활성화됩니다.
환경 설정에 따라 변수를 수정할 수 있습니다. 자세한 내용은 SSH Server 시스템 역할 변수를 참조하십시오.
-
암호 및
선택 사항: 플레이북 구문을 확인합니다.
# ansible-playbook --syntax-check path/custom-playbook.yml
인벤토리 파일에서 플레이북을 실행합니다.
# ansible-playbook -i inventory_file path/custom-playbook.yml ... PLAY RECAP ************************************************** localhost : ok=12 changed=2 unreachable=0 failed=0 skipped=10 rescued=0 ignored=0
검증
SSH 서버에 로그인합니다.
$ ssh user1@10.1.1.1
다음과 같습니다.
-
user1
은 SSH 서버의 사용자입니다. -
10.1.1.1
은 SSH 서버의 IP 주소입니다.
-
SSH 서버에서
sshd_config
파일의 내용을 확인합니다.$ vim /etc/ssh/sshd_config # Ansible managed HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_ecdsa_key HostKey /etc/ssh/ssh_host_ed25519_key AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE AcceptEnv XMODIFIERS AuthorizedKeysFile .ssh/authorized_keys ChallengeResponseAuthentication no GSSAPIAuthentication yes GSSAPICleanupCredentials no PasswordAuthentication no PermitRootLogin no PrintMotd no Subsystem sftp /usr/libexec/openssh/sftp-server SyslogFacility AUTHPRIV UsePAM yes X11Forwarding yes Match Address 192.0.2.0/24 PasswordAuthentication yes PermitRootLogin yes
192.0.2.0/24
서브넷에서 root로 서버에 연결할 수 있는지 확인합니다.IP 주소를 확인합니다.
$ hostname -I 192.0.2.1
IP 주소가
192.0.2.1
-192.0.2.254
범위 내에 있는 경우 서버에 연결할 수 있습니다.root
로 서버에 연결합니다 :$ ssh root@10.1.1.1
추가 리소스
-
/usr/share/doc/rhel-system-roles/sshd/README.md
파일 -
ansible-playbook(1)
도움말 페이지.
2.3. SSH
시스템 역할 변수
ssh
시스템 역할 플레이북에서는 사용자의 기본 설정 및 제한 사항에 따라 클라이언트 SSH 구성 파일에 대한 매개변수를 정의할 수 있습니다.
이러한 변수를 구성하지 않으면 시스템 역할은 RHEL 기본값과 일치하는 글로벌 ssh_config
파일을 생성합니다.
모든 경우에 부울이 ssh
구성에서 yes
또는 no
로 올바르게 렌더링됩니다. 목록을 사용하여 여러 줄 구성 항목을 정의할 수 있습니다. 예를 들면 다음과 같습니다.
LocalForward: - 22 localhost:2222 - 403 localhost:4003
다음과 같이 렌더링됩니다.
LocalForward 22 localhost:2222 LocalForward 403 localhost:4003
구성 옵션은 대소문자를 구분합니다.
ssh
시스템 역할에 대한 변수
ssh_user
-
시스템 역할이 사용자별 구성을 수정하는 기존 사용자 이름을 정의할 수 있습니다. 사용자별 구성은 지정된 사용자의
~/.ssh/config
에 저장됩니다. 기본값은 모든 사용자에 대한 글로벌 구성을 수정하는 null입니다. ssh_skip_defaults
-
기본값은
auto
입니다.auto
로 설정하면 시스템 역할은 시스템 전체 구성 파일/etc/ssh/ssh_config
를 쓰고 여기에 정의된 RHEL 기본값을 유지합니다.ssh_drop_in_name
변수를 정의하여 드롭인 구성 파일을 생성하면ssh_skip_defaults
변수가 자동으로 비활성화됩니다. ssh_drop_in_name
시스템 전체 드롭인 디렉터리에 배치되는 드롭인 구성 파일의 이름을 정의합니다. 이름은
/etc/ssh/ssh_config.d/{ssh_drop_in_name}.conf
템플릿에서 수정할 구성 파일을 참조하는 데 사용됩니다. 시스템이 드롭인 디렉터리를 지원하지 않는 경우 기본값은 null입니다. 시스템이 드롭인 디렉터리를 지원하는 경우 기본값은00-ansible
입니다.주의시스템이 드롭인 디렉터리를 지원하지 않는 경우 이 옵션을 설정하면 플레이가 실패합니다.
제안된 형식은
NN-name
입니다. 여기서NN
은 구성 파일의 순서를 지정하는 데 사용되는 두 자리 숫자이고,name
은 파일의 콘텐츠 또는 소유자에 대한 설명이 포함된 이름입니다.ssh
- 구성 옵션과 해당 값이 포함된 dict입니다.
ssh_OptionName
-
dict 대신
ssh_
접두사 및 옵션 이름으로 구성된 간단한 변수를 사용하여 옵션을 정의할 수 있습니다. 단순 변수는ssh
dict의 값을 재정의합니다. ssh_additional_packages
-
이 역할은 가장 일반적인 사용 사례에 필요한
openssh
및openssh-clients
패키지를 자동으로 설치합니다. 추가 패키지를 설치해야 하는 경우(예: 호스트 기반 인증에openssh-keysign
) 이 변수에 지정할 수 있습니다. ssh_config_file
역할이 생성된 구성 파일을 저장하는 경로입니다. 기본값:
-
시스템에 드롭인 디렉터리가 있는 경우 기본값은
/etc/ssh/ssh_config.d/{ssh_drop_in_name}.conf
템플릿으로 정의됩니다. -
시스템에 드롭인 디렉터리가 없으면 기본값은
/etc/ssh/ssh_config
입니다. -
ssh_user
변수가 정의된 경우 기본값은~/.ssh/config
입니다.
-
시스템에 드롭인 디렉터리가 있는 경우 기본값은
ssh_config_owner
,ssh_config_group
,ssh_config_mode
-
생성된 구성 파일의 소유자, 그룹 및 모드입니다. 기본적으로 파일 소유자는
root:root
이며 모드는0644
입니다.ssh_user
가 정의되면 모드는0600
이고 소유자와 그룹은ssh_user
변수에 지정된 사용자 이름에서 파생됩니다.
2.4. ssh
시스템 역할을 사용하여 OpenSSH 클라이언트 구성
ssh
시스템 역할을 사용하여 Ansible 플레이북을 실행하여 여러 SSH 클라이언트를 구성할 수 있습니다.
SSH 및 SSHD 구성을 변경하는 다른 시스템 역할(예: Identity Management RHEL 시스템 역할)과 함께 ssh
시스템 역할을 사용할 수 있습니다. 구성을 덮어쓰지 않도록 하려면 ssh
역할이 드롭인 디렉토리(RHEL 8의 기본)를 사용하는지 확인합니다.
사전 요구 사항
-
ssh
시스템 역할을 사용하여 구성하려는 시스템인 하나 이상의 관리형 노드에 액세스하고 권한을 부여합니다. Red Hat Ansible Core가 기타 시스템을 구성하는 시스템인 제어 노드 액세스 및 사용 권한.
제어 노드에서 다음이 있어야 합니다.
-
ansible-core
및rhel-system-roles
패키지가 설치됩니다.
-
RHEL 8.0-8.5는 Ansible 기반 자동화를 위해 Ansible Engine 2.9가 포함된 별도의 Ansible 리포지토리에 대한 액세스를 제공했습니다. Ansible Engine에는 ansible ,
, ansible
-playbookdocker
및 podman
과 같은 커넥터, 여러 플러그인 및 모듈과 같은 명령줄 유틸리티가 포함되어 있습니다. Ansible Engine을 확보하고 설치하는 방법에 대한 자세한 내용은 Red Hat Ansible Engine 지식베이스를 다운로드하고 설치하는 방법 문서를 참조하십시오.
RHEL 8.6 및 9.0에서는 Ansible 명령줄 유틸리티, 명령 및 소규모의 기본 제공 Ansible 플러그인 세트가 포함된 Ansible Core( ansible-core
패키지로 제공)를 도입했습니다. RHEL은 AppStream 리포지토리를 통해 이 패키지를 제공하며 제한된 지원 범위를 제공합니다. 자세한 내용은 RHEL 9 및 RHEL 8.6 이상 AppStream 리포지토리 지식 베이스에 포함된 Ansible Core 패키지에 대한 지원 범위를 참조하십시오.
- 관리 노드를 나열하는 인벤토리 파일.
절차
다음 내용으로 새
playbook.yml
파일을 생성합니다.--- - hosts: all tasks: - name: "Configure ssh clients" include_role: name: rhel-system-roles.ssh vars: ssh_user: root ssh: Compression: true GSSAPIAuthentication: no ControlMaster: auto ControlPath: ~/.ssh/.cm%C Host: - Condition: example Hostname: example.com User: user1 ssh_ForwardX11: no
이 플레이북은 다음 구성을 사용하여 관리 노드에서
root
사용자의 SSH 클라이언트 기본 설정을 구성합니다.- 압축이 활성화됩니다.
-
ControlMaster 멀티플렉싱이
auto
로 설정되어 있습니다. -
example
.comuser1
입니다. -
예제
호스트 별칭은example.com
호스트에 대한 연결을 나타내는user1
사용자 이름으로 생성됩니다. - X11 전달이 비활성화되어 있습니다.
선택적으로 환경 설정에 따라 이러한 변수를 수정할 수 있습니다. 자세한 내용은
ssh
시스템 역할 변수를 참조하십시오.선택 사항: 플레이북 구문을 확인합니다.
# ansible-playbook --syntax-check path/custom-playbook.yml
인벤토리 파일에서 플레이북을 실행합니다.
# ansible-playbook -i inventory_file path/custom-playbook.yml
검증
텍스트 편집기에서 SSH 구성 파일을 열어 관리 노드에 올바른 구성이 있는지 확인합니다. 예를 들면 다음과 같습니다.
# vi ~root/.ssh/config
위에 표시된 예제 플레이북의 애플리케이션을 적용한 후에는 구성 파일에 다음 내용이 포함되어야 합니다.
# Ansible managed Compression yes ControlMaster auto ControlPath ~/.ssh/.cm%C ForwardX11 no GSSAPIAuthentication no Host example Hostname example.com User user1
2.5. 제외되지 않은 구성에 sshd
시스템 역할 사용
일반적으로 sshd
시스템 역할을 적용하면 전체 구성을 덮어씁니다. 이전에 구성을 조정한 경우(예: 다른 시스템 역할 또는 플레이북이 있는 경우) 문제가 될 수 있습니다. 다른 옵션을 유지하면서 선택한 구성 옵션에 대해서만 sshd
시스템 역할을 적용하려면 제외 구성을 사용할 수 있습니다.
RHEL 8 이전 버전에서는 구성 스니펫을 사용하여 비독점 구성을 적용할 수 있습니다. 자세한 내용은 Using the SSH Server System Role for non-exclusive configuration in RHEL 8 문서를 참조하십시오.
RHEL 9에서는 드롭인 디렉터리의 파일을 사용하여 비독점 구성을 적용할 수 있습니다. 기본 구성 파일은 드롭인 디렉터리에 이미 /etc/ssh/sshd_config.d/00-ansible_system_role.conf
로 배치되어 있습니다.
사전 요구 사항
-
sshd
시스템 역할로 구성하려는 시스템인 하나 이상의 관리형 노드에 대한 액세스 및 권한. Red Hat Ansible Core가 기타 시스템을 구성하는 시스템인 제어 노드 액세스 및 사용 권한.
제어 노드에서 다음이 있어야 합니다.
-
ansible-core
패키지가 설치되어 있습니다. - 관리 노드를 나열하는 인벤토리 파일.
- 다른 RHEL 시스템 역할에 대한 플레이북입니다.
-
절차
sshd_config_file
변수의 구성 스니펫을 플레이북에 추가합니다.--- - hosts: all tasks: - name: <Configure sshd to accept some useful environment variables> include_role: name: rhel-system-roles.sshd vars: sshd_config_file: /etc/ssh/sshd_config.d/<42-my-application>.conf sshd: # Environment variables to accept AcceptEnv: LANG LS_COLORS EDITOR
sshd_config_file
변수에서sshd
시스템 역할이 구성 옵션을 쓰는.conf
파일을 정의합니다.2자리 접두사를 사용합니다(예:
42-
)를 사용하여 구성 파일이 적용되는 순서를 지정합니다.인벤토리에 플레이북을 적용하면 역할은
sshd_config_file
변수에서 정의한 파일에 다음 구성 옵션을 추가합니다.# Ansible managed # AcceptEnv LANG LS_COLORS EDITOR
검증
선택 사항: 플레이북 구문을 확인합니다.
# ansible-playbook --syntax-check playbook.yml -i inventory_file
추가 리소스
-
/usr/share/doc/rhel-system-roles/sshd/README.md
파일 -
ansible-playbook(1)
도움말 페이지.
3장. TLS 키 및 인증서 생성 및 관리
TLS(Transport Layer Security) 프로토콜을 사용하여 두 시스템 간에 전송된 통신을 암호화할 수 있습니다. 이 표준은 개인 및 공개 키, 디지털 서명 및 인증서와 함께ECDHE 암호화를 사용합니다.
3.1. TLS 인증서
TLS(Transport Layer Security)는 클라이언트-서버 애플리케이션이 정보를 안전하게 전달할 수 있도록 하는 프로토콜입니다. TLS는 공개 및 개인 키 쌍의 시스템을 사용하여 클라이언트와 서버 간에 전송된 통신을 암호화합니다. TLS는 SSL(Secure Sockets Layer)의 후속 프로토콜입니다.
TLS는 X.509 인증서를 사용하여 호스트 이름 또는 조직과 같은 ID를 디지털 서명을 사용하여 공개 키에 바인딩합니다. X.509는 공개 키 인증서의 형식을 정의하는 표준입니다.
보안 애플리케이션의 인증은 애플리케이션 인증서의 공개 키 값의 무결성에 따라 달라집니다. 공격자가 공개 키를 자체 공개 키로 교체하면 실제 애플리케이션을 가장하고 데이터 보안 액세스 권한을 얻을 수 있습니다. 이러한 유형의 공격을 방지하려면 모든 인증서에 CA(인증 기관)의 서명이 있어야 합니다. CA는 인증서의 공개 키 값의 무결성을 확인하는 신뢰할 수 있는 노드입니다.
CA는 디지털 서명을 추가하고 인증서를 발행하여 공개 키에 서명합니다. 디지털 서명은 CA의 개인 키로 인코딩되는 메시지입니다. CA의 공개 키는 CA 인증서를 배포하여 애플리케이션에서 사용할 수 있습니다. 애플리케이션은 CA의 디지털 서명을 CA의 공개 키로 디코딩하여 인증서가 유효하게 서명되었는지 확인합니다.
CA에서 서명한 인증서를 사용하려면 공개 키를 생성하여 서명을 위해 CA로 보내야 합니다. 이를 CSR(인증서 서명 요청)이라고 합니다. CSR에는 인증서에 대한 고유 이름(DN)도 포함됩니다. 두 가지 유형의 인증서에 제공할 수 있는 DN 정보에는 해당 국가의 경우 2자리 국가 코드, 주/도, 시/도, 도시 이름, 조직 이름, 이메일 주소 등이 포함될 수 있습니다. 현재 많은 상용 CA는 주체 대체 이름 확장을 선호하고 CSR의 DN을 무시합니다.
RHEL은 TLS 인증서 작업을 위한 두 가지 주요 툴킷을 제공합니다. gnutls 및 OpenSSL. openssl 패키지에서
유틸리티를 사용하여 인증서를 생성, 읽기, 서명 및 확인할 수 있습니다. openssl
gnutls-utils
패키지에서 제공하는 certtool
유틸리티는 다른 구문과 백엔드의 다양한 라이브러리 세트를 사용하여 동일한 작업을 수행할 수 있습니다.
추가 리소스
- RFC 5280: Internet X.509 공개 키 인프라 인증서 및 인증서 해지 목록 (CRL) 프로필
-
OpenSSL(1)
,x509(1)
,ca(1)
,req(1)
및certtool(1)
매뉴얼 페이지
3.2. OpenSSL을 사용하여 개인 CA 생성
개인 인증 기관(CA)은 시나리오가 내부 네트워크 내의 엔티티를 확인해야 하는 경우에 유용합니다. 예를 들어, 컨트롤에서 서명된 인증서 또는 상용 CA를 구입하지 않으려면 개인 CA를 사용하여 인증으로 VPN 게이트웨이를 만들 때 사용합니다. 이러한 사용 사례의 인증서에 서명하기 위해 개인 CA는 자체 서명된 인증서를 사용합니다.
사전 요구 사항
-
sudo
를 사용하여 관리자 명령을 입력할 수 있는루트
권한 또는 권한이 있어야 합니다. 이러한 권한이 필요한 명령은#
으로 표시됩니다.
절차
CA의 개인 키를 생성합니다. 예를 들어 다음 명령은 256비트 Elliptic Curve Digital Signature Algorithm(ECDSA) 키를 생성합니다.
$ openssl genpkey -algorithm ec -pkeyopt ec_paramgen_curve:P-256 -out <ca.key>
키 생성 프로세스의 시간은 호스트의 하드웨어 및 엔트로피, 선택한 알고리즘 및 키 길이에 따라 달라집니다.
이전 명령에서 생성된 개인 키를 사용하여 서명된 인증서를 생성합니다.
$ openssl req -key <ca.key> -new -x509 -days 3650 -addext keyUsage=critical,keyCertSign,cRLSign -subj "/CN=<Example CA>" -out <ca.crt>
생성된
ca.crt
파일은 10년 동안 다른 인증서에 서명하는 데 사용할 수 있는 자체 서명된 CA 인증서입니다. 프라이빗 CA의 경우 <ECDHE CA>를 CN(일반 이름)으로 임의의 문자열로 교체할 수 있습니다.CA의 개인 키에 대해 보안 권한을 설정합니다. 예를 들면 다음과 같습니다.
# chown <root>:<root> <ca.key> # chmod 600 <ca.key>
다음 단계
자체 서명된 CA 인증서를 클라이언트 시스템의 신뢰 앵커로 사용하려면 CA 인증서를 클라이언트에 복사하고 클라이언트의 시스템 전체 신뢰 저장소에
root
로 추가합니다.# trust anchor <ca.crt>
자세한 내용은 4장. 공유 시스템 인증서 사용를 참조하십시오.
검증
CSR(인증서 서명 요청)을 생성하고 CA를 사용하여 요청에 서명합니다. CA는 CSR을 기반으로 인증서를 성공적으로 생성해야 합니다. 예를 들면 다음과 같습니다.
$ openssl x509 -req -in <client-cert.csr> -CA <ca.crt> -CAkey <ca.key> -CAcreateserial -days 365 -extfile <openssl.cnf> -extensions <client-cert> -out <client-cert.crt> Signature ok subject=C = US, O = Example Organization, CN = server.example.com Getting CA Private Key
자세한 내용은 3.5절. “개인 CA를 사용하여 OpenSSL과 함께 CSR의 인증서 발행”를 참조하십시오.
자체 서명된 CA에 대한 기본 정보를 표시합니다.
$ openssl x509 -in <ca.crt> -text -noout Certificate: … X509v3 extensions: … X509v3 Basic Constraints: critical CA:TRUE X509v3 Key Usage: critical Certificate Sign, CRL Sign …
개인 키의 일관성을 확인합니다.
$ openssl pkey -check -in <ca.key> Key is valid -----BEGIN PRIVATE KEY----- MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgcagSaTEBn74xZAwO 18wRpXoCVC9vcPki7WlT+gnmCI+hRANCAARb9NxIvkaVjFhOoZbGp/HtIQxbM78E lwbDP0BI624xBJ8gK68ogSaq2x4SdezFdV1gNeKScDcU+Pj2pELldmdF -----END PRIVATE KEY-----
추가 리소스
-
openssl(1)
,ca(1)
,genpkey(1)
,x509(1)
, andreq(1)
man pages
3.3. OpenSSL을 사용하여 TLS 서버 인증서의 개인 키와 CSR 생성
TLS 암호화 통신 채널은 CA(인증 기관)의 유효한 TLS 인증서가 있는 경우에만 사용할 수 있습니다. 인증서를 받으려면 먼저 서버의 개인 키와 CSR(인증서 서명 요청)을 만들어야 합니다.
절차
서버 시스템에서 개인 키를 생성합니다. 예를 들면 다음과 같습니다.
$ openssl genpkey -algorithm ec -pkeyopt ec_paramgen_curve:P-256 -out <server-private.key>
선택 사항: 선택한 텍스트 편집기를 사용하여 CSR 생성을 간소화하는 구성 파일을 준비합니다. 예를 들면 다음과 같습니다.
$ vim <example_server.cnf> [server-cert] keyUsage = critical, digitalSignature, keyEncipherment, keyAgreement extendedKeyUsage = serverAuth subjectAltName = @alt_name [req] distinguished_name = dn prompt = no [dn] C = <US> O = <Example Organization> CN = <server.example.com> [alt_name] DNS.1 = <example.com> DNS.2 = <server.example.com> IP.1 = <192.168.0.1> IP.2 = <::1> IP.3 = <127.0.0.1>
extendedKeyUsage = serverAuth
옵션은 인증서 사용을 제한합니다.이전에 생성한 개인 키를 사용하여 CSR을 생성합니다.
$ openssl req -key <server-private.key> -config <example_server.cnf> -new -out <server-cert.csr>
-config
옵션을 생략하면req
유틸리티에서 추가 정보를 입력하라는 메시지를 표시합니다. 예를 들면 다음과 같습니다.You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [XX]: <US> State or Province Name (full name) []: <Washington> Locality Name (eg, city) [Default City]: <Seattle> Organization Name (eg, company) [Default Company Ltd]: <Example Organization> Organizational Unit Name (eg, section) []: Common Name (eg, your name or your server's hostname) []: <server.example.com> Email Address []: <server@example.com>
다음 단계
- 서명하기 위해 선택한 CA에 CSR을 제출합니다. 또는 신뢰할 수 있는 네트워크 내의 내부 사용 시나리오의 경우 개인 CA를 사용하여 서명합니다. 자세한 내용은 3.5절. “개인 CA를 사용하여 OpenSSL과 함께 CSR의 인증서 발행”를 참조하십시오.
검증
CA에서 요청된 인증서를 가져온 후 인증서의 사람이 읽을 수 있는 부분이 요구 사항과 일치하는지 확인합니다.
$ openssl x509 -text -noout -in <server-cert.crt> Certificate: … Issuer: CN = Example CA Validity Not Before: Feb 2 20:27:29 2023 GMT Not After : Feb 2 20:27:29 2024 GMT Subject: C = US, O = Example Organization, CN = server.example.com Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) … X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Encipherment, Key Agreement X509v3 Extended Key Usage: TLS Web Server Authentication X509v3 Subject Alternative Name: DNS:example.com, DNS:server.example.com, IP Address:192.168.0.1, IP …
추가 리소스
-
openssl(1)
,x509(1)
,genpkey(1)
,req(1)
, andconfig(5)
man pages
3.4. OpenSSL을 사용하여 TLS 클라이언트 인증서의 개인 키와 CSR 생성
TLS 암호화 통신 채널은 CA(인증 기관)의 유효한 TLS 인증서가 있는 경우에만 사용할 수 있습니다. 인증서를 받으려면 먼저 클라이언트의 개인 키와 CSR(인증서 서명 요청)을 생성해야 합니다.
절차
클라이언트 시스템에서 개인 키를 생성합니다. 예를 들면 다음과 같습니다.
$ openssl genpkey -algorithm ec -pkeyopt ec_paramgen_curve:P-256 -out <client-private.key>
선택 사항: 선택한 텍스트 편집기를 사용하여 CSR 생성을 간소화하는 구성 파일을 준비합니다. 예를 들면 다음과 같습니다.
$ vim <example_client.cnf> [client-cert] keyUsage = critical, digitalSignature, keyEncipherment extendedKeyUsage = clientAuth subjectAltName = @alt_name [req] distinguished_name = dn prompt = no [dn] CN = <client.example.com> [clnt_alt_name] email= <client@example.com>
extendedKeyUsage = clientAuth
옵션은 인증서 사용을 제한합니다.이전에 생성한 개인 키를 사용하여 CSR을 생성합니다.
$ openssl req -key <client-private.key> -config <example_client.cnf> -new -out <client-cert.csr>
-config
옵션을 생략하면req
유틸리티에서 추가 정보를 입력하라는 메시지를 표시합니다. 예를 들면 다음과 같습니다.You are about to be asked to enter information that will be incorporated into your certificate request. … Common Name (eg, your name or your server's hostname) []: <client.example.com> Email Address []: <client@example.com>
다음 단계
- 서명하기 위해 선택한 CA에 CSR을 제출합니다. 또는 신뢰할 수 있는 네트워크 내의 내부 사용 시나리오의 경우 개인 CA를 사용하여 서명합니다. 자세한 내용은 3.5절. “개인 CA를 사용하여 OpenSSL과 함께 CSR의 인증서 발행”를 참조하십시오.
검증
사용자가 읽을 수 있는 인증서 부분이 요구 사항과 일치하는지 확인합니다. 예를 들면 다음과 같습니다.
$ openssl x509 -text -noout -in <client-cert.crt> Certificate: … X509v3 Extended Key Usage: TLS Web Client Authentication X509v3 Subject Alternative Name: email:client@example.com …
추가 리소스
-
openssl(1)
,x509(1)
,genpkey(1)
,req(1)
, andconfig(5)
man pages
3.5. 개인 CA를 사용하여 OpenSSL과 함께 CSR의 인증서 발행
시스템이 TLS 암호화 통신 채널을 설정할 수 있도록 하려면 CA(인증 기관)에서 유효한 인증서를 제공해야 합니다. 개인 CA가 있는 경우 시스템에서 인증서 서명 요청(CSR)에 서명하여 요청된 인증서를 생성할 수 있습니다.
사전 요구 사항
- 이미 개인 CA가 구성되어 있습니다. 자세한 내용은 3.2절. “OpenSSL을 사용하여 개인 CA 생성”를 참조하십시오.
- CSR이 포함된 파일이 있습니다. 3.3절. “OpenSSL을 사용하여 TLS 서버 인증서의 개인 키와 CSR 생성” 에서 CSR 생성의 예를 확인할 수 있습니다.
절차
선택 사항: 선택한 텍스트 편집기를 사용하여 인증서에 확장을 추가하기 위해 OpenSSL 구성 파일을 준비합니다. 예를 들면 다음과 같습니다.
$ vim <openssl.cnf> [server-cert] extendedKeyUsage = serverAuth [client-cert] extendedKeyUsage = clientAuth
x509
유틸리티를 사용하여 CSR을 기반으로 인증서를 생성합니다. 예를 들면 다음과 같습니다.$ openssl x509 -req -in <server-cert.csr> -CA <ca.crt> -CAkey <ca.key> -days 365 -extfile <openssl.cnf> -extensions <server-cert> -out <server-cert.crt> Signature ok subject=C = US, O = Example Organization, CN = server.example.com Getting CA Private Key
추가 리소스
-
OpenSSL(1)
,ca(1)
및x509(1)
매뉴얼 페이지
4장. 공유 시스템 인증서 사용
공유 시스템 인증서 스토리지를 사용하면 NSS, GnuTLS, OpenSSL 및 Java에서 시스템 인증서 앵커 및 블록 목록 정보를 검색할 기본 소스를 공유할 수 있습니다. 기본적으로 신뢰 저장소에는 긍정 및 부정적인 신뢰성을 포함한 Mozilla CA 목록이 포함되어 있습니다. 시스템을 사용하면 코어 Mozilla CA 목록을 업데이트하거나 다른 인증서 목록을 선택할 수 있습니다.
4.1. 시스템 전체 신뢰 저장소
RHEL에서 통합된 시스템 전체 신뢰 저장소는 /etc/pki/ca-trust/
및 /usr/share/pki/ca-trust-source/
디렉터리에 있습니다. /usr/share/pki/ca-trust-source/
의 신뢰 설정은 /etc/pki/ca-trust/
의 설정보다 우선 순위가 낮습니다.
인증서 파일은 설치된 하위 디렉터리에 따라 처리됩니다.
신뢰 앵커는 다음과 같습니다.
-
/usr/share/pki/ca-trust-source/anchors/
또는 -
/etc/pki/ca-trust/source/anchors/
.
-
신뢰할 수 없는 인증서는 에 저장됩니다.
-
/usr/share/pki/ca-trust-source/blocklist/
또는 -
/etc/pki/ca-trust/source/blocklist/
.
-
확장 BEGINTED 파일 형식의 인증서는 에 있습니다.
-
/usr/share/pki/ca-trust-source/
또는 -
/etc/pki/ca-trust/source/
.
-
계층적 암호화 시스템에서 신뢰 앵커는 다른 당사자가 신뢰할 수 있는 것으로 간주하는 신뢰할 수 있는 엔티티입니다. X.509 아키텍처에서 루트 인증서는 신뢰 체인이 파생되는 신뢰 앵커입니다. 체인 검증을 사용하려면 신뢰할 수 있는 당사자가 신뢰 앵커에 먼저 액세스할 수 있어야 합니다.
추가 리소스
-
update-ca-trust(8)
및trust(1)
도움말 페이지
4.2. 새 인증서 추가
새로운 신뢰 소스로 시스템에서 애플리케이션을 승인하려면 해당 인증서를 시스템 전체 저장소에 추가하고 update-ca-trust
명령을 사용합니다.
사전 요구 사항
-
ca-certificates
패키지가 시스템에 있습니다.
절차
간단한 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/
시스템 전체 신뢰 저장소 구성을 업데이트하려면
update-ca-trust
명령을 사용합니다.# update-ca-trust
Firefox 브라우저에서 update-ca-trust
를 이전에 실행하지 않고 추가된 인증서를 사용할 수 있지만 모든 CA를 변경한 후 update-ca-trust
명령을 입력합니다. 또한 Firefox, Chromium 및 GNOME 웹 캐시 파일과 같은 브라우저의 캐시를 지우거나 브라우저를 다시 시작하여 현재 시스템 인증서 구성을 로드해야 할 수도 있습니다.
추가 리소스
-
update-ca-trust(8)
및trust(1)
도움말 페이지
4.3. 신뢰할 수 있는 시스템 인증서 관리
trust
명령은 공유 시스템 전체의 신뢰 저장소에서 인증서를 관리하는 편리한 방법을 제공합니다.
신뢰 앵커를 나열, 추출, 추가, 제거 또는 변경하려면
trust
명령을 사용합니다. 이 명령에 대한 기본 도움말을 보려면 인수 없이 또는--help
지시문을 사용하여 입력합니다.$ trust usage: trust command <args>... Common trust commands are: list List trust or certificates extract Extract certificates and trust extract-compat Extract trust compatibility bundles anchor Add, remove, change trust anchors dump Dump trust objects in internal format See 'trust <command> --help' for more information
모든 시스템 신뢰 앵커 및 인증서를 나열하려면
trust list
명령을 사용합니다.$ trust list pkcs11:id=%d2%87%b4%e3%df%37%27%93%55%f6%56%ea%81%e5%36%cc%8c%1e%3f%bd;type=cert type: certificate label: ACCVRAIZ1 trust: anchor category: authority pkcs11:id=%a6%b3%e1%2b%2b%49%b6%d7%73%a1%aa%94%f5%01%e7%73%65%4c%ac%50;type=cert type: certificate label: ACEDICOM Root trust: anchor category: authority ...
신뢰 앵커를 시스템 전체 신뢰 저장소에 저장하려면
trust anchor
하위 명령을 사용하고 인증서 경로를 지정합니다. & lt;path.to/certificate.crt >를 인증서 및 파일 이름의 경로로 바꿉니다.# trust anchor <path.to/certificate.crt>
인증서를 제거하려면 인증서의 경로 또는 인증서의 ID를 사용합니다.
# trust anchor --remove <path.to/certificate.crt> # trust anchor --remove "pkcs11:id=<%AA%BB%CC%DD%EE>;type=cert"
추가 리소스
trust
명령의 모든 하위 명령은 상세한 기본 도움말을 제공합니다. 예를 들면 다음과 같습니다.$ trust list --help usage: trust list --filter=<what> --filter=<what> filter of what to export ca-anchors certificate anchors ... --purpose=<usage> limit to certificates usable for the purpose server-auth for authenticating servers ...
추가 리소스
-
update-ca-trust(8)
및trust(1)
도움말 페이지
5장. TLS 계획 및 구현
TLS(Transport Layer Security)는 네트워크 통신을 보호하는 데 사용되는 암호화 프로토콜입니다. 기본 키 교환 프로토콜, 인증 방법 및 암호화 알고리즘을 구성하여 시스템 보안 설정을 강화할 때 지원되는 클라이언트 범위를 넓혀 보안을 강화해야 합니다. 반대로 엄격한 보안 설정은 클라이언트와의 호환성이 제한되어 일부 사용자가 시스템에서 잠길 수 있습니다. 가장 엄격한 사용 가능한 구성을 대상으로 하고 호환성을 위해 필요한 경우에만 완화해야 합니다.
5.1. SSL 및 TLS 프로토콜
SSL(Secure Sockets Layer) 프로토콜은 원래 Netscape Corporation에서 인터넷을 통한 보안 통신을 위한 메커니즘을 제공하기 위해 개발되었습니다. 그 후 이 프로토콜은 IETF(Internet Engineering Task Force)에서 채택했으며 TLS(Transport Layer Security)로 이름이 변경되었습니다.
TLS 프로토콜은 애플리케이션 프로토콜 계층과 TCP/IP와 같은 신뢰할 수 있는 전송 계층 사이에 있습니다. 애플리케이션 프로토콜과 독립적이므로 다음과 같이 다양한 프로토콜 아래에 계층화할 수 있습니다. HTTP, FTP, SMTP 등.
프로토콜 버전 | 사용 권장 사항 |
---|---|
SSL v2 | 사용하지 마십시오. 심각한 보안 취약점이 있습니다. RHEL 7 이후 코어 암호화 라이브러리에서 제거되었습니다. |
SSL v3 | 사용하지 마십시오. 심각한 보안 취약점이 있습니다. RHEL 8 이후 핵심 암호화 라이브러리에서 제거되었습니다. |
TLS 1.0 | 사용하지 않는 것이 좋습니다. 상호 운용성을 보장하고 최신 암호화 제품군을 지원하지 않는 방식으로 완화할 수 없는 문제가 있습니다. RHEL 9에서는 모든 암호화 정책에서 비활성화됨. |
TLS 1.1 | 필요한 경우 상호 운용성을 목적으로 사용합니다. 최신 암호화 제품군을 지원하지 않습니다. RHEL 9에서는 모든 암호화 정책에서 비활성화됨. |
TLS 1.2 | 최신 AEAD 암호화 제품군을 지원합니다. 이 버전은 모든 시스템 전체 암호화 정책에서 활성화되지만, 이 프로토콜의 선택적 부분에는 취약점이 포함되어 있으며 TLS 1.2에서는 오래된 알고리즘도 허용합니다. |
TLS 1.3 | 권장 버전입니다. TLS 1.3은 문제가 있는 알려진 옵션을 제거하고, 협상 핸드셰이크를 더 많이 암호화하여 추가적인 프라이버시를 제공하며 보다 효율적인 최신 암호화 알고리즘을 사용하여 더 빠르게 사용될 수 있습니다. TLS 1.3은 모든 시스템 차원의 암호화 정책에서도 활성화됩니다. |
5.2. RHEL 9의 TLS에 대한 보안 고려 사항
RHEL 9에서 TLS 구성은 시스템 전체 암호화 정책 메커니즘을 사용하여 수행됩니다. 1.2 미만의 TLS 버전은 더 이상 지원되지 않습니다. DEFAULT
,FUTURE
, LEGACY
암호화 정책은 TLS 1.2 및 1.3만 허용합니다. 자세한 내용은 시스템 전체 암호화 정책 사용을 참조하십시오.
RHEL 9에 포함된 라이브러리에서 제공하는 기본 설정은 대부분의 배포에 충분히 안전합니다. TLS 구현에서는 가능한 경우 또는 기존 클라이언트 또는 서버의 연결을 방지할 수 없는 보안 알고리즘을 사용합니다. 보안 알고리즘 또는 프로토콜을 지원하지 않는 레거시 클라이언트나 서버가 연결되지 않거나 연결할 수 없는 엄격한 보안 요구 사항을 충족하는 환경에서 강화된 설정을 적용합니다.
TLS 구성을 강화하는 가장 간단한 방법은 update-crypto-policies --set FUTURE
명령을 사용하여 시스템 전체 암호화 정책 수준을 FUTURE
로 전환하는 것입니다.
LEGACY
암호화 정책에 대해 비활성화된 알고리즘은 Red Hat의 RHEL 9 보안 비전을 준수하지 않으며 보안 속성을 신뢰할 수 없습니다. 다시 활성화하는 대신 이러한 알고리즘 사용에서 벗어나는 것이 좋습니다. 예를 들어 이전 하드웨어와의 상호 운용성을 위해 다시 활성화하기로 결정한 경우, 이를 안전하지 않은 것으로 처리하고 네트워크 상호 작용을 별도의 네트워크 세그먼트에 격리하는 등의 추가 보호 조치를 적용합니다. 공용 네트워크에서 사용하지 마십시오.
RHEL 시스템 전체 암호화 정책을 따르거나 설정에 맞는 사용자 지정 암호화 정책을 생성하기로 결정한 경우 사용자 정의 구성에서 선호하는 프로토콜, 암호화 제품군 및 키 길이에 다음 권장 사항을 사용하십시오.
5.2.1. 프로토콜
최신 버전의 TLS는 최상의 보안 메커니즘을 제공합니다. TLS 1.2는 LEGACY
암호화 정책을 사용하는 경우에도 최소 버전입니다. 암호화 정책을 비활성화하거나 사용자 지정 정책을 제공하면 이전 프로토콜 버전을 다시 활성화할 수 있지만 결과적으로 생성되는 구성은 지원되지 않습니다.
RHEL 9는 TLS 버전 1.3을 지원하지만 RHEL 9 구성 요소에서 이 프로토콜의 일부 기능을 완전히 지원하는 것은 아닙니다. 예를 들어 연결 대기 시간을 줄이는 0-RTT(round Trip Time) 기능은 Apache 웹 서버에서 아직 완전히 지원하지 않습니다.
5.2.2. 암호화 제품군
보안이 강화된 최신 암호화 제품군을 안전하지 않은 이전 암호 제품군에 우선적으로 사용해야 합니다. 항상 암호화 또는 인증을 전혀 제공하지 않는 eNULL 및 aNULL 암호화 제품군 사용을 비활성화합니다. 가능한 경우 심각한 단점이 있는 RC4 또는 HMAC-MD5를 기반으로 하는 암호 제품군도 비활성화해야 합니다. 즉, 의도적으로 약해졌던 수출 암호 모음에도 동일하게 적용됩니다. 따라서 쉽게 중단할 수 있습니다.
즉시 안전하지 않지만 128비트 미만의 보안을 제공하는 암호화 제품군은 짧은 유효 기간 동안 고려해서는 안 됩니다. 128비트의 보안을 사용하는 알고리즘은 적어도 몇 년 동안 중단되지 않을 수 있으므로 강력하게 권장합니다. 3DES 암호화는 168비트 사용을 알리지만 실제로 112비트의 보안을 제공합니다.
항상 서버 키가 손상된 경우에도 암호화된 데이터의 기밀성을 보장하는 PFS(forward secrecy)를 지원하는 암호화 제품군을 선호합니다. 이 규칙은 빠른 RSA 키 교환을 제한하지만 ECDHE 및 DHE를 사용할 수 있습니다. 이 둘 중 ECDHE는 더 빠르고 선호되는 선택입니다.
또한 Oracle 공격에 취약하지 않으므로 CBC-GCM 이상의 AEAD 암호를 선호해야 합니다. 또한 대부분의 경우 AES-GCM은 특히 하드웨어에 AES용 암호화 가속기가 있는 경우 CBC 모드에서 AES보다 빠릅니다.
또한 ECDSA 인증서와 함께 ECDSA 키 교환을 사용할 때는 트랜잭션이 순수 RSA 키 교환보다 훨씬 빠릅니다. 레거시 클라이언트를 지원하기 위해 서버에 두 쌍의 인증서와 키(새 클라이언트용)와 RSA 키가 있는 키(기존 클라이언트의 경우)를 설치할 수 있습니다.
5.2.3. 공개 키 길이
RSA 키를 사용하는 경우 항상 적어도 SHA-256에 의해 서명된 3072 비트의 키 길이를 선호하며, 이는 실제 128비트의 보안에 충분히 큰 영향을 미칩니다.
시스템의 보안은 체인에서 가장 약한 링크만큼 강력합니다. 예를 들어 강력한 암호만으로는 좋은 보안이 보장되지 않습니다. 키와 인증서는 키에 서명하는 데 CA(인증 기관)에서 사용하는 해시 기능 및 키뿐만 아니라 중요합니다.
5.3. 애플리케이션에서 TLS 구성 강화
RHEL에서 시스템 전체 암호화 정책은 암호화 라이브러리를 사용하는 애플리케이션에서 알려진 안전하지 않은 프로토콜, 암호 또는 알고리즘을 허용하지 않도록 하는 편리한 방법을 제공합니다.
사용자 지정 암호화 설정으로 TLS 관련 구성을 강화하려면 이 섹션에 설명된 암호화 구성 옵션을 사용하고 필요한 최소 용량의 시스템 전체 암호화 정책을 재정의할 수 있습니다.
사용할 구성이 무엇이든 관계없이 서버 애플리케이션이 서버 측 암호 순서 를 강제 적용하므로 사용할 암호 모음은 구성하는 순서에 따라 결정됩니다.
5.3.1. TLS를 사용하도록 Apache HTTP 서버 구성
Apache HTTP Server
는 TLS 요구 사항에 따라 OpenSSL
및 NSS
라이브러리를 모두 사용할 수 있습니다. RHEL 9는 eponymous 패키지를 통해 mod_ssl
기능을 제공합니다.
# dnf install mod_ssl
mod_ssl
패키지는 Apache HTTP Server
의 TLS 관련 설정을 수정하는 데 사용할 수 있는 /etc/httpd/conf.d/ssl.conf
구성 파일을 설치합니다.
httpd-manual
패키지를 설치하여 TLS 구성을 포함하여 Apache HTTP Server
에 대한 전체 문서를 가져옵니다. /etc/httpd/conf.d/ssl.conf
구성 파일에서 사용 가능한 지시문은 /usr/share/httpd/manual/mod/mod_ssl.html
파일에 자세히 설명되어 있습니다. 다양한 설정의 예는 /usr/share/httpd/manual/ssl_howto.html
파일에 설명되어 있습니다.
/etc/httpd/conf.d/ssl.conf
구성 파일의 설정을 수정할 때 최소한 다음 세 가지 지시문을 고려해야 합니다.
SSLProtocol
- 이 지시문을 사용하여 허용하려는 TLS 또는 SSL 버전을 지정합니다.
SSLCipherSuite
- 이 지시문을 사용하여 선호하는 암호화 제품군을 지정하거나 허용하지 않을 암호화 제품군을 비활성화합니다.
SSLHonorCipherOrder
-
연결 클라이언트가 지정한 암호 순서를 준수하는지 확인하기 위해 이 지시문의 주석을
on
으로 설정합니다.
예를 들어 TLS 1.2 및 1.3 프로토콜만 사용하려면 다음을 수행합니다.
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
자세한 내용은 웹 서버 배포 및 역방향 프록시 문서의 Apache HTTP Server에서 TLS 암호화 구성 장을 참조하십시오.
5.3.2. TLS를 사용하도록 Nginx HTTP 및 프록시 서버 구성
Nginx
에서 TLS 1.3 지원을 활성화하려면 /etc/nginx/nginx.conf
구성 파일의 server
섹션에 있는 ssl_protocols
옵션에 TLSv1.3
값을 추가합니다.
server { listen 443 ssl http2; listen [::]:443 ssl http2; .... ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers .... }
자세한 내용은 웹 서버 배포 및 역방향 프록시 문서의 Nginx 웹 서버에 TLS 암호화 추가 장을 참조하십시오.
5.3.3. TLS를 사용하도록 Dovecot 메일 서버 구성
TLS를 사용하도록 Dovecot
메일 서버의 설치를 구성하려면 /etc/dovecot/conf.d/10-ssl.conf
구성 파일을 수정합니다. 해당 파일에서 사용 가능한 기본 구성 지시문 중 일부에 대한 설명은 /usr/share/doc/dovecot/wiki/SSL.DovecotConfiguration.txt
파일의 표준 설치와 함께 설치됩니다.
/etc/dovecot/conf.d/10-ssl.conf
구성 파일의 설정을 수정할 때 다음 세 지시문을 최소한으로 고려해야 합니다.
ssl_protocols
- 이 지시문을 사용하여 허용 또는 비활성화하려는 TLS 또는 SSL 버전을 지정합니다.
ssl_cipher_list
- 이 지시문을 사용하여 선호하는 암호화 제품군을 지정하거나 허용하지 않을 암호화 제품군을 비활성화합니다.
ssl_prefer_server_ciphers
-
연결 클라이언트가 지정한 암호 순서를 준수하는지 확인하기 위해 이 지시문의 주석을 제거하고
yes
로 설정합니다.
예를 들어 /etc/dovecot/conf.d/10-ssl.conf
의 다음 행에서는 TLS 1.1 이상만 허용합니다.
ssl_protocols = !SSLv2 !SSLv3 !TLSv1
추가 리소스
- 웹 서버 및 역방향 프록시 배포
-
config(5)
및ciphers(1)
도움말 페이지. - TLS( Transport Layer Security) 및 DTLS(Datagram Transport Layer Security)에 대한 보안 권장 사항입니다.
- Mozilla SSL 구성 생성기.
- SSL 서버 테스트.
6장. IPsec을 사용하여 VPN 구성
RHEL 9에서는 Libreswan
애플리케이션에서 지원하는 IPsec
프로토콜을 사용하여 VPN(가상 사설 네트워크)을 구성할 수 있습니다.
6.1. Libreswan as an IPsec VPN 구현
RHEL에서는 Libreswan 애플리케이션에서 지원하는 IPsec 프로토콜을 사용하여 VPN(Virtual Private Network)을 구성할 수 있습니다. Libreswan은 Openswan 애플리케이션에 대한 연속이며, Openswan 문서의 많은 예제는 Libreswan과 교환 가능합니다.
VPN용 IPsec 프로토콜은 IKEv(Internet Key Exchange) 프로토콜을 사용하여 구성됩니다. IPsec과 IKE라는 용어는 서로 바꿔 사용할 수 있습니다. IPsec VPN은 IKE VPN, IKEv2 VPN, XAUTH VPN, Cisco VPN 또는 IKE/IPsec VPN이라고도 합니다. L2TP( Layer 2 tunneling Protocol)도 사용하는 IPsec VPN의 변형은 일반적으로 선택적
리포지토리에서 제공하는 xl2tpd
패키지가 필요한 L2TP/IPsec VPN이라고 합니다.
Libreswan은 오픈 소스 사용자 공간 IKE 구현입니다. IKE v1 및 v2는 사용자 수준 데몬으로 구현됩니다. IKE 프로토콜도 암호화됩니다. IPsec 프로토콜은 Linux 커널에 의해 구현되며 Libreswan은 VPN 터널 구성을 추가 및 제거하도록 커널을 설정합니다.
IKE 프로토콜은 UDP 포트 500 및 4500을 사용합니다. IPsec 프로토콜은 다음 두 가지 프로토콜로 구성됩니다.
- 프로토콜 번호 50이 있는ESP(Security Payload)를 캡슐화합니다.
- 인증된 헤더(AH)는 프로토콜 번호 51이 있습니다.
AH 프로토콜은 사용하지 않는 것이 좋습니다. AH 사용자는 null 암호화를 사용하여 ESP로 마이그레이션하는 것이 좋습니다.
IPsec 프로토콜은 다음 두 가지 작업 모드를 제공합니다.
- 터널 모드(기본값)
- 전송 모드.
IKE 없이 IPsec을 사용하여 커널을 구성할 수 있습니다. 이를 Manual Keying이라고 합니다. ip xfrm
명령을 사용하여 수동 인증도 구성할 수 있지만 보안상의 이유로 이 방법은 권장되지 않습니다. netlink를 사용하여 Linux 커널과 Libreswan 인터페이스. Linux 커널에서 패킷 암호화 및 암호 해독이 수행됩니다.
Libreswan은 NSS(Network Security Services) 암호화 라이브러리를 사용합니다. Libreswan 및 NSS는 모두 연방 정보 처리 표준 (FIPS)Publication procedures와 함께 사용하도록 인증되었습니다.
Libreswan 및 Linux 커널에서 구현되는 IKE/IPsec VPN은 RHEL에서 사용할 수 있는 유일한 VPN 기술입니다. 위험을 이해 하지 않고 다른 VPN 기술을 사용 하지 마십시오.
RHEL에서 Libreswan은 기본적으로 시스템 전체 암호화 정책을 따릅니다. 이를 통해 Libreswan은 IKEv2를 기본 프로토콜로 포함한 현재 위협 모델에 대한 보안 설정을 사용할 수 있습니다. 자세한 내용은 시스템 전체 암호화 정책 사용을 참조하십시오.
Libreswan은 IKE/IPsec이 피어 프로토콜로 피어링되기 때문에 "source" 및 "destination" 또는 "server" 및 "client"라는 용어를 사용하지 않습니다. 대신 "left" 및 "right"라는 용어를 사용하여 엔드 포인트(호스트)를 나타냅니다. 또한 대부분의 경우 두 끝점 모두에서 동일한 구성을 사용할 수 있습니다. 그러나 일반적으로 관리자는 로컬 호스트에 "left"를 사용하고 원격 호스트에 대해 "right"를 사용하도록 선택합니다.
leftid
및 rightid
옵션은 인증 프로세스에서 해당 호스트를 식별하는 역할을 합니다. 자세한 내용은 ipsec.conf(5)
도움말 페이지를 참조하십시오.
6.2. Libreswan의 인증 방법
Libreswan은 각각 다른 시나리오에 맞는 여러 인증 방법을 지원합니다.
Pre-Shared 키(PSK)
PSK( Pre-Shared Key )는 가장 간단한 인증 방법입니다. 보안상의 이유로, 64개의 임의 문자보다 짧은 PSK를 사용하지 마십시오. FIPS 모드에서 PSK는 사용된 무결성 알고리즘에 따라 최소 요구 사항을 준수해야 합니다. authby=secret
연결을 사용하여 PSK를 설정할 수 있습니다.
원시 RSA 키
원시 RSA 키는 일반적으로 정적 host-host 또는 subnet-to-subnet IPsec 구성에 사용됩니다. 각 호스트는 다른 모든 호스트의 공개 RSA 키를 사용하여 수동으로 구성하고 Libreswan은 각 호스트 쌍 간에 IPsec 터널을 설정합니다. 이 방법은 많은 호스트에 대해 잘 확장되지 않습니다.
ipsec newhostkey
명령을 사용하여 호스트에서 원시 RSA 키를 생성할 수 있습니다. ipsec showhostkey
명령을 사용하여 생성된 키를 나열할 수 있습니다. CKA ID 키를 사용하는 연결 구성에는 leftrsasigkey=
행이 필요합니다. 원시 RSA 키에 authby=rsasig
연결 옵션을 사용합니다.
X.509 인증서
X.509 인증서 는 일반적으로 공통 IPsec 게이트웨이에 연결된 호스트로 대규모 배포에 사용됩니다. 중앙 인증 기관 (CA)은 호스트 또는 사용자의 RSA 인증서에 서명합니다. 이 중앙 CA는 개별 호스트 또는 사용자의 해지를 포함하여 신뢰를 중계합니다.
예를 들어 openssl
명령 및 NSS certutil
명령을 사용하여 X.509 인증서를 생성할 수 있습니다. Libreswan은 leftcert=
구성 옵션에서 인증서의 닉네임을 사용하여 NSS 데이터베이스에서 사용자 인증서를 읽기 때문에 인증서를 생성할 때 nickname을 제공합니다.
사용자 정의 CA 인증서를 사용하는 경우 NSS(Network Security Services) 데이터베이스로 가져와야 합니다. ipsec import
명령을 사용하여 PKCS #12 형식의 인증서를 Libreswan NSS 데이터베이스로 가져올 수 있습니다.
Libreswan에는 RFC 4945의 3.1 절에 설명된 모든 피어 인증서에 대한 주제 대체 이름(SAN)으로 인터넷 키 교환(IKE) 피어 ID가 필요합니다. require-id-on-certificated=
옵션을 변경하여 이 검사를 비활성화하면 시스템이 메시지 가로채기(man-in-the-middle) 공격에 취약해질 수 있습니다.
SHA-2의 RSA를 사용하는 X.509 인증서에 따라 인증에 authby=rsasig
연결 옵션을 사용합니다. authby=
를 ecdsa
및 RSA Probabilistic Signature Scheme(RSASSA-PSS)로 설정하여 SHA-2를 사용하여 ECDSA 디지털 서명에 대해 추가로 제한할 수 있습니다. authby=rsa-sha2
를 통해 SHA-2를 사용한 디지털 서명 기반 인증입니다. 기본값은 authby=rsasig,ecdsa
입니다.
인증서 및 authby=
서명 메서드가 일치해야 합니다. 이는 상호 운용성을 높이고 하나의 디지털 서명 시스템에서 인증을 보존합니다.
NULL 인증
NULL 인증은 인증없이 메시 암호화를 얻는 데 사용됩니다. 액티브 공격으로부터 보호하지만 활성 공격으로부터 보호하지 않습니다. 그러나 IKEv2는 비대칭 인증 방법을 허용하므로 Internetscale opportunistic IPsec에도 NULL 인증을 사용할 수 있습니다. 이 모델에서 클라이언트는 서버를 인증하지만 서버는 클라이언트를 인증하지 않습니다. 이 모델은 TLS를 사용하는 보안 웹 사이트와 유사합니다. NULL 인증을 위해 authby=null
을 사용합니다.
Quantum Computer에 대한 보호
앞에서 언급한 인증 방법 외에도 PPK( Post-quantum Pre-shared Key ) 방법을 사용하여 텀 컴퓨터가 통해 가능한 공격으로부터 보호할 수 있습니다. 개별 클라이언트 또는 클라이언트 그룹은 대역 외 구성된 사전 공유 키에 해당하는 PPK ID를 지정하여 자체 PPK를 사용할 수 있습니다.
IKEv1을 사전 공유 키와 함께 사용하면 취약성 공격자로부터 보호할 수 있습니다. IKEv2의 재 설계는 이러한 보호 기능을 기본적으로 제공하지 않습니다. Libreswan은 Quantum Pre-shared Key (PPK)를 사용하여 IKEv2 연결을 멱등 공격으로부터 보호합니다.
선택적 PPK 지원을 활성화하려면 연결 정의에 ppk=yes
를 추가합니다. PPK를 요구하려면 ppk=insist
를 추가합니다. 그런 다음 각 클라이언트에는 대역 외(및 바람직하게 안전한)로 통신하는 시크릿 값이 있는 PPK ID가 제공될 수 있습니다. PPK는 사전 단어를 기반으로 하지 않고 무작위로 매우 강력해야 합니다. PPK ID 및 PPK 데이터는 ipsec.secrets
에 저장됩니다. 예를 들면 다음과 같습니다.
@west @east : PPKS "user1" "thestringismeanttobearandomstr"
PPKS
옵션은 정적 PPK를 나타냅니다. 이 실험적 기능은 일회용 동적 PPK를 사용합니다. 각 연결에서 1회패드의 새 부분이 PPK로 사용됩니다. 사용하면 파일 내의 동적 PPK의 해당 부분을 다시 사용하지 않도록 0으로 덮어씁니다. 더 이상 일회성 편집기가 남아 있지 않으면 연결이 실패합니다. 자세한 내용은 ipsec.secrets(5)
도움말 페이지를 참조하십시오.
동적 PPK의 구현은 지원되지 않는 기술 프리뷰로 제공됩니다. 주의해서 사용하십시오.
6.3. Libreswan 설치
이 절차에서는 Libreswan IPsec/IKE VPN 구현 설치 및 시작 단계를 설명합니다.
사전 요구 사항
-
AppStream
리포지토리가 활성화되어 있어야 합니다.
절차
libreswan
패키지를 설치합니다.# dnf install libreswan
Libreswan을 다시 설치하는 경우 이전 데이터베이스 파일을 제거하고 새 데이터베이스를 만듭니다.
# systemctl stop ipsec # rm /var/lib/ipsec/nss/*db # ipsec initnss
ipsec
서비스를 시작하고 부팅 시 서비스를 자동으로 시작합니다.# systemctl enable ipsec --now
ipsec
서비스를 추가하여 IKE, ESP 및 AH 프로토콜에 500 및 4500/UDP 포트를 허용하도록 방화벽을 구성합니다.# firewall-cmd --add-service="ipsec" # firewall-cmd --runtime-to-permanent
6.4. 호스트 대 호스트 VPN 생성
원시 RSA 키의 인증을 사용하여 왼쪽 과 오른쪽 이라는 두 호스트 간에 호스트 간 IPsec VPN을 생성하도록 [애플리케이션]Libreswan을 구성하려면 두 호스트 모두에서 다음 명령을 입력합니다.
사전 요구 사항
-
Libreswan이 설치되어 있고
ipsec
서비스가 각 노드에 시작됩니다.
절차
각 호스트에 원시 RSA 키 쌍을 생성합니다.
# ipsec newhostkey
이전 단계에서 생성된 키의
ckaid
가 반환되었습니다. 왼쪽에서 다음 명령과 함께ckaid
를 사용하십시오. 예를 들면 다음과 같습니다.# ipsec showhostkey --left --ckaid 2d3ea57b61c9419dfd6cf43a1eb6cb306c0e857d
이전 명령의 출력에서 구성에 필요한
leftrsasigkey=
행을 생성했습니다. 두 번째 호스트(오른쪽)에서 동일한 작업을 수행합니다.# ipsec showhostkey --right --ckaid a9e1f6ce9ecd3608c24e8f701318383f41798f03
/etc/ipsec.d/
디렉터리에 새my_host-to-host.conf
파일을 만듭니다. 이전 단계에서ipsec showhostkey
명령의 출력에서 RSA 호스트 키를 새 파일로 작성합니다. 예를 들면 다음과 같습니다.conn mytunnel leftid=@west left=192.1.2.23 leftrsasigkey=0sAQOrlo+hOafUZDlCQmXFrje/oZm [...] W2n417C/4urYHQkCvuIQ== rightid=@east right=192.1.2.45 rightrsasigkey=0sAQO3fwC6nSSGgt64DWiYZzuHbc4 [...] D/v8t5YTQ== authby=rsasig
키를 가져온 후
ipsec
서비스를 다시 시작하십시오.# systemctl restart ipsec
연결을 로드합니다.
# ipsec auto --add mytunnel
터널을 설정합니다.
# ipsec auto --up mytunnel
ipsec
서비스가 시작될 때 터널을 자동으로 시작하려면 연결 정의에 다음 행을 추가합니다.auto=start
6.5. 사이트 간 VPN 구성
두 개의 네트워크에 참여하여 사이트 간 IPsec VPN을 생성하려면 두 호스트 간의 IPsec 터널을 생성합니다. 따라서 호스트는 하나 이상의 서브넷의 트래픽이 통과할 수 있도록 구성된 엔드포인트 역할을 합니다. 따라서 호스트를 네트워크의 원격 부분에 대한 게이트웨이로 간주할 수 있습니다.
사이트 간 VPN의 구성은 구성 파일에 하나 이상의 네트워크 또는 서브넷을 지정해야 한다는 점에서 호스트 투 호스트 VPN과만 다릅니다.
사전 요구 사항
- 호스트 간 VPN이 이미 구성되어 있습니다.
절차
호스트 투 호스트 VPN의 구성으로 파일을 새 파일로 복사합니다. 예를 들면 다음과 같습니다.
# cp /etc/ipsec.d/my_host-to-host.conf /etc/ipsec.d/my_site-to-site.conf
이전 단계에서 만든 파일에 서브넷 구성을 추가합니다. 예를 들면 다음과 같습니다.
conn mysubnet also=mytunnel leftsubnet=192.0.1.0/24 rightsubnet=192.0.2.0/24 auto=start conn mysubnet6 also=mytunnel leftsubnet=2001:db8:0:1::/64 rightsubnet=2001:db8:0:2::/64 auto=start # the following part of the configuration file is the same for both host-to-host and site-to-site connections: conn mytunnel leftid=@west left=192.1.2.23 leftrsasigkey=0sAQOrlo+hOafUZDlCQmXFrje/oZm [...] W2n417C/4urYHQkCvuIQ== rightid=@east right=192.1.2.45 rightrsasigkey=0sAQO3fwC6nSSGgt64DWiYZzuHbc4 [...] D/v8t5YTQ== authby=rsasig
6.6. 원격 액세스 VPN 구성
로드 전사는 사용자를 모바일 클라이언트 및 동적으로 할당된 IP 주소로 이동하고 있습니다. 모바일 클라이언트는 X.509 인증서를 사용하여 인증합니다.
다음 예제에서는 IKEv2
에 대한 구성을 보여주며 IKEv1
XAUTH 프로토콜 사용을 방지합니다.
서버에서 다음을 수행합니다.
conn roadwarriors ikev2=insist # support (roaming) MOBIKE clients (RFC 4555) mobike=yes fragmentation=yes left=1.2.3.4 # if access to the LAN is given, enable this, otherwise use 0.0.0.0/0 # leftsubnet=10.10.0.0/16 leftsubnet=0.0.0.0/0 leftcert=gw.example.com leftid=%fromcert leftxauthserver=yes leftmodecfgserver=yes right=%any # trust our own Certificate Agency rightca=%same # pick an IP address pool to assign to remote users # 100.64.0.0/16 prevents RFC1918 clashes when remote users are behind NAT rightaddresspool=100.64.13.100-100.64.13.254 # if you want remote clients to use some local DNS zones and servers modecfgdns="1.2.3.4, 5.6.7.8" modecfgdomains="internal.company.com, corp" rightxauthclient=yes rightmodecfgclient=yes authby=rsasig # optionally, run the client X.509 ID through pam to allow or deny client # pam-authorize=yes # load connection, do not initiate auto=add # kill vanished roadwarriors dpddelay=1m dpdtimeout=5m dpdaction=clear
모바일 클라이언트에서, 길 전사의 장치는 이전 구성의 약간의 변형을 사용합니다.
conn to-vpn-server ikev2=insist # pick up our dynamic IP left=%defaultroute leftsubnet=0.0.0.0/0 leftcert=myname.example.com leftid=%fromcert leftmodecfgclient=yes # right can also be a DNS hostname right=1.2.3.4 # if access to the remote LAN is required, enable this, otherwise use 0.0.0.0/0 # rightsubnet=10.10.0.0/16 rightsubnet=0.0.0.0/0 fragmentation=yes # trust our own Certificate Agency rightca=%same authby=rsasig # allow narrowing to the server’s suggested assigned IP and remote subnet narrowing=yes # support (roaming) MOBIKE clients (RFC 4555) mobike=yes # initiate connection auto=start
6.7. 메시 VPN 구성
임의 의 VPN이라고도 하는 메시 VPN 네트워크는 모든 노드가 IPsec을 사용하여 통신하는 네트워크입니다. 이 구성은 IPsec을 사용할 수 없는 노드에 대한 예외를 허용합니다. 메시 VPN 네트워크는 두 가지 방법으로 구성할 수 있습니다.
- IPsec이 필요합니다.
- IPsec을 선호하지만, 일반 텍스트 통신을 대체합니다.
노드 간 인증은 X.509 인증서 또는 DNSSEC(DNS Security Extensions)를 기반으로 할 수 있습니다.
다음 절차에서는 X.509 인증서를 사용합니다. 이러한 인증서는 Dogtag Certificate System과 같은 모든 종류의 CA(인증 기관) 관리 시스템을 사용하여 생성할 수 있습니다. Dogtag는 각 노드의 인증서를 개인 키, 노드 인증서 및 기타 노드의 X.509 인증서의 유효성을 검사하는 데 사용되는 루트 CA 인증서가 포함된 PKCS #12 형식(.p12 파일)에서 사용할 수 있다고 가정합니다.
각 노드에는 X.509 인증서를 제외하고 동일한 구성이 있습니다. 이를 통해 네트워크의 기존 노드를 재구성하지 않고 새 노드를 추가할 수 있습니다. PKCS #12 파일에는 이름 "노드"를 사용하는 "이름"이 필요하며, 이를 통해 친숙한 이름을 참조하는 구성 파일이 모든 노드에 대해 동일할 수 있습니다.
사전 요구 사항
-
Libreswan이 설치되어 있고
ipsec
서비스가 각 노드에서 시작됩니다.
절차
각 노드에서 PKCS #12 파일을 가져옵니다. 이 단계에서는 PKCS #12 파일을 생성하는 데 사용되는 암호가 필요합니다.
# ipsec import nodeXXX.p12
필요한 IPsec
(private)에 대해 다음 세 가지 연결 정의 (private-or-clear) 및No
(clear) 프로파일에 대해 다음 세 가지 연결 정의를 만듭니다.IPsec
# cat /etc/ipsec.d/mesh.conf conn clear auto=ondemand type=passthrough authby=never left=%defaultroute right=%group conn private auto=ondemand type=transport authby=rsasig failureshunt=drop negotiationshunt=drop # left left=%defaultroute leftcert=nodeXXXX leftid=%fromcert leftrsasigkey=%cert # right rightrsasigkey=%cert rightid=%fromcert right=%opportunisticgroup conn private-or-clear auto=ondemand type=transport authby=rsasig failureshunt=passthrough negotiationshunt=passthrough # left left=%defaultroute leftcert=nodeXXXX leftid=%fromcert leftrsasigkey=%cert # right rightrsasigkey=%cert rightid=%fromcert right=%opportunisticgroup
적절한 범주에 네트워크의 IP 주소를 추가합니다. 예를 들어 모든 노드가 10.15.0.0/16 네트워크에 있고 모든 노드는 IPsec 암호화를 준수해야 합니다.
# echo "10.15.0.0/16" >> /etc/ipsec.d/policies/private
예를 들어 특정 노드(예: 10.15.34.0/24)가 IPsec 없이 작동하도록 허용하려면 다음을 사용하여 해당 노드를 private-or-clear 그룹에 추가합니다.
# echo "10.15.34.0/24" >> /etc/ipsec.d/policies/private-or-clear
호스트 정의(예: 10.15.1.2)는 IPsec을 명확한 그룹으로 설정할 수 없는 경우 다음을 사용합니다.
# echo "10.15.1.2/32" >> /etc/ipsec.d/policies/clear
/etc/ipsec.d/policies
디렉터리의 파일은 각 새 노드의 템플릿에서 생성하거나 Puppet 또는 Ansible을 사용하여 프로비저닝할 수 있습니다.모든 노드에는 예외 또는 트래픽 흐름 예상과 동일한 목록이 있습니다. 따라서 두 개의 노드는 IPsec이 필요하고 다른 하나는 IPsec을 사용할 수 없기 때문에 통신할 수 없습니다.
노드를 재시작하여 구성된 메시에 추가합니다.
# systemctl restart ipsec
노드 추가를 완료한 후에는
ping
명령으로 IPsec 터널을 열 수 있습니다. 노드가 열린 터널을 확인하려면 다음을 수행하십시오.# ipsec trafficstatus
6.8. FIPS 호환 IPsec VPN 배포
Libreswan 기반의 FIPS 호환 IPsec VPN 솔루션을 배포하려면 다음 절차를 사용하십시오. 다음 단계를 사용하면 사용할 수 있는 암호화 알고리즘과 FIPS 모드에서 Libreswan에 대해 비활성화된 암호화 알고리즘도 식별할 수 있습니다.
사전 요구 사항
-
AppStream
리포지토리가 활성화되어 있어야 합니다.
절차
libreswan
패키지를 설치합니다.# dnf install libreswan
Libreswan을 다시 설치하는 경우 이전 NSS 데이터베이스를 제거하십시오.
# systemctl stop ipsec # rm /var/lib/ipsec/nss/*db
ipsec
서비스를 시작하고 부팅 시 서비스를 자동으로 시작합니다.# systemctl enable ipsec --now
ipsec
서비스를 추가하여 IKE, ESP 및 AH 프로토콜에 500 및 4500/UDP 포트를 허용하도록 방화벽을 구성합니다.# firewall-cmd --add-service="ipsec" # firewall-cmd --runtime-to-permanent
시스템을 FIPS 모드로 전환합니다.
# fips-mode-setup --enable
커널이 FIPS 모드로 전환되도록 시스템을 다시 시작하십시오.
# reboot
검증
Libreswan이 FIPS 모드에서 실행 중인지 확인하려면 다음을 수행합니다.
# ipsec whack --fipsstatus 000 FIPS mode enabled
또는
systemd
저널의ipsec
유닛 항목을 확인합니다.$ journalctl -u ipsec ... Jan 22 11:26:50 localhost.localdomain pluto[3076]: FIPS Mode: YES
FIPS 모드에서 사용 가능한 알고리즘을 보려면 다음을 수행합니다.
# ipsec pluto --selftest 2>&1 | head -6 Initializing NSS using read-write database "sql:/var/lib/ipsec/nss" FIPS Mode: YES NSS crypto library initialized FIPS mode enabled for pluto daemon NSS library is running in FIPS mode FIPS HMAC integrity support [disabled]
FIPS 모드에서 비활성화된 알고리즘을 쿼리하려면 다음을 수행합니다.
# ipsec pluto --selftest 2>&1 | grep disabled Encryption algorithm CAMELLIA_CTR disabled; not FIPS compliant Encryption algorithm CAMELLIA_CBC disabled; not FIPS compliant Encryption algorithm NULL disabled; not FIPS compliant Encryption algorithm CHACHA20_POLY1305 disabled; not FIPS compliant Hash algorithm MD5 disabled; not FIPS compliant PRF algorithm HMAC_MD5 disabled; not FIPS compliant PRF algorithm AES_XCBC disabled; not FIPS compliant Integrity algorithm HMAC_MD5_96 disabled; not FIPS compliant Integrity algorithm HMAC_SHA2_256_TRUNCBUG disabled; not FIPS compliant Integrity algorithm AES_XCBC_96 disabled; not FIPS compliant DH algorithm MODP1536 disabled; not FIPS compliant DH algorithm DH31 disabled; not FIPS compliant
FIPS 모드에서 허용되는 모든 알고리즘 및 암호를 나열하려면 다음을 수행합니다.
# ipsec pluto --selftest 2>&1 | grep ESP | grep FIPS | sed "s/^.*FIPS//" aes_ccm, aes_ccm_c aes_ccm_b aes_ccm_a NSS(CBC) 3des NSS(GCM) aes_gcm, aes_gcm_c NSS(GCM) aes_gcm_b NSS(GCM) aes_gcm_a NSS(CTR) aesctr NSS(CBC) aes aes_gmac NSS sha, sha1, sha1_96, hmac_sha1 NSS sha512, sha2_512, sha2_512_256, hmac_sha2_512 NSS sha384, sha2_384, sha2_384_192, hmac_sha2_384 NSS sha2, sha256, sha2_256, sha2_256_128, hmac_sha2_256 aes_cmac null NSS(MODP) null, dh0 NSS(MODP) dh14 NSS(MODP) dh15 NSS(MODP) dh16 NSS(MODP) dh17 NSS(MODP) dh18 NSS(ECP) ecp_256, ecp256 NSS(ECP) ecp_384, ecp384 NSS(ECP) ecp_521, ecp521
추가 리소스
6.9. 암호로 IPsec NSS 데이터베이스 보호
기본적으로 IPsec 서비스는 처음 시작하는 동안 비어 있는 암호를 사용하여 NSS(Network Security Services) 데이터베이스를 생성합니다. 다음 단계를 사용하여 암호 보호를 추가합니다.
사전 요구 사항
-
/var/lib/ipsec/nss/
디렉터리에는 NSS 데이터베이스 파일이 포함되어 있습니다.
절차
Libreswan에 대해
NSS
데이터베이스에 대한 암호 보호를 활성화합니다.# certutil -N -d sql:/var/lib/ipsec/nss Enter Password or Pin for "NSS Certificate DB": Enter a password which will be used to encrypt your keys. The password should be at least 8 characters long, and should contain at least one non-alphabetic character. Enter new password:
이전 단계에서 설정한 암호가 포함된
/etc/ipsec.d/nsspassword
파일을 만듭니다. 예를 들면 다음과 같습니다.# cat /etc/ipsec.d/nsspassword NSS Certificate DB:MyStrongPasswordHere
nsspassword
파일은 다음 구문을 사용합니다.token_1_name:the_password token_2_name:the_password
기본 NSS 소프트웨어 토큰은
NSS Certificate DB
입니다. 시스템이 FIPS 모드에서 실행 중인 경우 토큰 이름은NSS FIPS 140-2 Certificate DB
입니다.시나리오에 따라
nsspassword
파일을 완료한 후ipsec
서비스를 시작하거나 다시 시작합니다.# systemctl restart ipsec
검증
NSS 데이터베이스에 비어 있지 않은 암호를 추가한 후
ipsec
서비스가 실행 중인지 확인합니다.# systemctl status ipsec ● ipsec.service - Internet Key Exchange (IKE) Protocol Daemon for IPsec Loaded: loaded (/usr/lib/systemd/system/ipsec.service; enabled; vendor preset: disable> Active: active (running)...
선택적으로
Journal
로그에 초기화가 성공했는지 확인하는 항목이 포함되어 있는지 확인합니다.# journalctl -u ipsec ... pluto[6214]: Initializing NSS using read-write database "sql:/var/lib/ipsec/nss" pluto[6214]: NSS Password from file "/etc/ipsec.d/nsspassword" for token "NSS Certificate DB" with length 20 passed to NSS pluto[6214]: NSS crypto library initialized ...
추가 리소스
-
certutil(1)
도움말 페이지. - 정부 표준 지식베이스 문서.
6.10. TCP를 사용하도록 IPsec VPN 구성
Libreswan은 RFC 8229에 설명된 대로 IKE 및 IPsec 패킷을 TCP 캡슐화를 지원합니다. 이 기능을 사용하면 UDP를 통해 전송되는 트래픽을 방지하고 ESB(Security Payload)를 캡슐화하는 네트워크에서 IPsec VPN을 설정할 수 있습니다. TCP를 대체 또는 기본 VPN 전송 프로토콜로 사용하도록 VPN 서버와 클라이언트를 구성할 수 있습니다. TCP 캡슐화는 성능 비용이 늘어날 수 있으므로 시나리오에서 UDP가 영구적으로 차단된 경우에만 TCP를 기본 VPN 프로토콜로 사용하십시오.
사전 요구 사항
- 원격 액세스 VPN이 이미 구성되어 있습니다.
절차
config setup
섹션의/etc/ipsec.conf
파일에 다음 옵션을 추가합니다.listen-tcp=yes
UDP를 처음 시도하지 못하면 TCP 캡슐화를 대체 옵션으로 사용하려면 클라이언트의 연결 정의에 다음 두 옵션을 추가합니다.
enable-tcp=fallback tcp-remoteport=4500
또는 UDP가 영구적으로 차단되었음을 알고 있는 경우 클라이언트 연결 구성에서 다음 옵션을 사용합니다.
enable-tcp=yes tcp-remoteport=4500
6.11. IPsec 연결 속도를 높이기 위해 ESP 하드웨어 오프로드 자동 감지 및 사용 구성
하드웨어로 캡슐화된 보안 페이로드(ESP)를 오프로드하면 이더넷을 통해 IPsec 연결을 가속화할 수 있습니다. 기본적으로 Libreswan은 하드웨어가 이 기능을 지원하는지 감지하여 ESP 하드웨어 오프로드를 활성화합니다. 기능을 비활성화하거나 명시적으로 활성화한 경우 자동 탐지로 다시 전환할 수 있습니다.
사전 요구 사항
- 네트워크 카드는 ESP 하드웨어 오프로드를 지원합니다.
- 네트워크 드라이버는 ESP 하드웨어 오프로드를 지원합니다.
- IPsec 연결이 구성되고 작동합니다.
절차
-
ESP 하드웨어 오프로드 지원의 자동 검색을 사용해야 하는 연결의
/etc/ipsec.d/
디렉터리에서 Libreswan 구성 파일을 편집합니다. -
nic-offload
매개변수가 연결 설정에 설정되지 않았는지 확인합니다. nic-offload
를 제거한 경우ipsec
서비스를 다시 시작합니다.# systemctl restart ipsec
검증
네트워크 카드가 ESP 하드웨어 오프로드 지원을 지원하는 경우 다음 단계에 따라 결과를 확인하십시오.
IPsec 연결에 사용하는 이더넷 장치의
tx_ipsec
및rx_ipsec
카운터를 표시합니다.# ethtool -S enp1s0 | egrep "_ipsec" tx_ipsec: 10 rx_ipsec: 10
IPsec 터널을 통해 트래픽을 전송합니다. 예를 들어 원격 IP 주소를 ping합니다.
# ping -c 5 remote_ip_address
이더넷 장치의
tx_ipsec
및rx_ipsec
카운터를 다시 표시합니다.# ethtool -S enp1s0 | egrep "_ipsec" tx_ipsec: 15 rx_ipsec: 15
카운터 값이 증가하면 ESP 하드웨어 오프로드가 작동합니다.
추가 리소스
6.12. IPsec 연결 속도를 높이기 위해 본딩에서 ESP 하드웨어 오프로드 구성
하드웨어로 ESB(Security Payload)를 오프로드하면 IPsec 연결 속도가 빨라집니다. 장애 조치(failover) 이유로 네트워크 본딩을 사용하는 경우 ESP 하드웨어 오프로드 구성의 요구 사항과 절차는 일반 이더넷 장치를 사용하는 것과 다릅니다. 예를 들어, 이 시나리오에서는 본딩에서 오프로드 지원을 활성화하며 커널은 본딩 포트에 설정을 적용합니다.
사전 요구 사항
- 본딩의 모든 네트워크 카드는 ESP 하드웨어 오프로드를 지원합니다.
-
네트워크 드라이버는 본딩 장치에서 ESP 하드웨어 오프로드를 지원합니다. RHEL에서는
ixgbe
드라이버만 이 기능을 지원합니다. - 본딩이 구성되고 작동합니다.
-
본딩에서는
active-backup
모드를 사용합니다. 본딩 드라이버는 이 기능에 대해 다른 모드를 지원하지 않습니다. - IPsec 연결이 구성되고 작동합니다.
절차
네트워크 본딩에서 ESP 하드웨어 오프로드 지원을 활성화합니다.
# nmcli connection modify bond0 ethtool.feature-esp-hw-offload on
이 명령을 사용하면
bond0
연결에서 ESP 하드웨어 오프로드를 지원할 수 있습니다.bond0
연결을 다시 활성화합니다.# nmcli connection up bond0
ESP 하드웨어 오프로드를 사용해야 하는 연결의
/etc/ipsec.d/
디렉터리에서 Libreswan 구성 파일을 편집하고nic-offload=yes
문을 연결 항목에 추가합니다.conn example ... nic-offload=yes
ipsec
서비스를 다시 시작하십시오.# systemctl restart ipsec
검증
본딩의 활성 포트를 표시합니다.
# grep "Currently Active Slave" /proc/net/bonding/bond0 Currently Active Slave: enp1s0
활성 포트의
tx_ipsec
및rx_ipsec
카운터를 표시합니다.# ethtool -S enp1s0 | egrep "_ipsec" tx_ipsec: 10 rx_ipsec: 10
IPsec 터널을 통해 트래픽을 전송합니다. 예를 들어 원격 IP 주소를 ping합니다.
# ping -c 5 remote_ip_address
활성 포트의
tx_ipsec
및rx_ipsec
카운터를 다시 표시합니다.# ethtool -S enp1s0 | egrep "_ipsec" tx_ipsec: 15 rx_ipsec: 15
카운터 값이 증가하면 ESP 하드웨어 오프로드가 작동합니다.
추가 리소스
6.13. 시스템 전체 암호화 정책에서 비활성화된 IPsec 연결 구성
연결에 대한 시스템 전체 암호화 정책 덮어쓰기
RHEL 시스템 전체 암호화 정책은 %default
라는 특수 연결을 생성합니다. 이 연결에는 the ikev2
,esp
및 ike
옵션의 기본값이 포함되어 있습니다. 그러나 연결 구성 파일에 언급된 옵션을 지정하여 기본값을 재정의할 수 있습니다.
예를 들어 다음 구성에서는 AES 및 SHA-1 또는 SHA-2와 함께 IKEv1을 사용하고 IPsec(ESP)을 AES-GCM 또는 AES-CBC와 함께 사용하는 연결을 허용합니다.
conn MyExample ... ikev2=never ike=aes-sha2,aes-sha1;modp2048 esp=aes_gcm,aes-sha2,aes-sha1 ...
AES-GCM은 IPsec (ESP) 및 IKEv2에서는 사용할 수 있지만 IKEv1에는 사용할 수 없습니다.
모든 연결에 대한 시스템 전체 암호화 정책 비활성화
모든 IPsec 연결에 대한 시스템 전체 암호화 정책을 비활성화하려면 /etc/ipsec.conf
파일에서 다음 행을 주석 처리하십시오.
include /etc/crypto-policies/back-ends/libreswan.config
그런 다음 연결 구성 파일에 ikev2=never
옵션을 추가합니다.
추가 리소스
6.14. IPsec VPN 구성 문제 해결
IPsec VPN 구성과 관련된 문제는 여러 가지 주요 이유로 발생합니다. 이러한 문제가 발생하면 문제의 원인이 다음 시나리오에 해당하는지 확인하고 해당 솔루션을 적용할 수 있습니다.
기본 연결 문제 해결
VPN 연결에 대한 대부분의 문제는 관리자가 구성 옵션과 일치하지 않는 엔드포인트를 구성한 새로운 배포에서 발생합니다. 또한 작동 중인 구성은 새로 호환되지 않는 값 때문에 갑자기 작동을 중지할 수 있습니다. 이는 관리자가 구성을 변경한 결과일 수 있습니다. 또는 관리자가 암호화 알고리즘과 같은 특정 옵션에 대해 다양한 기본값을 사용하여 펌웨어 업데이트 또는 패키지 업데이트를 설치할 수 있습니다.
IPsec VPN 연결이 설정되었는지 확인하려면 다음을 수행하십시오.
# ipsec trafficstatus
006 #8: "vpn.example.com"[1] 192.0.2.1, type=ESP, add_time=1595296930, inBytes=5999, outBytes=3231, id='@vpn.example.com', lease=100.64.13.5/32
출력이 비어 있거나 연결 이름이 인 항목이 표시되지 않으면 터널이 손상됩니다.
문제가 연결에 있는지 확인하려면 다음을 수행하십시오.
vpn.example.com 연결을 다시 로드합니다.
# ipsec auto --add vpn.example.com 002 added connection description "vpn.example.com"
다음으로 VPN 연결을 시작합니다.
# ipsec auto --up vpn.example.com
방화벽 관련 문제
가장 일반적인 문제는 IPsec 끝점 중 하나 또는 끝점 간의 라우터에 있는 방화벽이 모든 인터넷 키 교환 (IKE) 패킷을 삭제하는 것입니다.
IKEv2의 경우 다음 예제와 유사한 출력은 방화벽에 문제가 있음을 나타냅니다.
# ipsec auto --up vpn.example.com 181 "vpn.example.com"[1] 192.0.2.2 #15: initiating IKEv2 IKE SA 181 "vpn.example.com"[1] 192.0.2.2 #15: STATE_PARENT_I1: sent v2I1, expected v2R1 010 "vpn.example.com"[1] 192.0.2.2 #15: STATE_PARENT_I1: retransmission; will wait 0.5 seconds for response 010 "vpn.example.com"[1] 192.0.2.2 #15: STATE_PARENT_I1: retransmission; will wait 1 seconds for response 010 "vpn.example.com"[1] 192.0.2.2 #15: STATE_PARENT_I1: retransmission; will wait 2 seconds for ...
IKEv1의 경우 시작 명령의 출력은 다음과 같습니다.
# ipsec auto --up vpn.example.com 002 "vpn.example.com" #9: initiating Main Mode 102 "vpn.example.com" #9: STATE_MAIN_I1: sent MI1, expecting MR1 010 "vpn.example.com" #9: STATE_MAIN_I1: retransmission; will wait 0.5 seconds for response 010 "vpn.example.com" #9: STATE_MAIN_I1: retransmission; will wait 1 seconds for response 010 "vpn.example.com" #9: STATE_MAIN_I1: retransmission; will wait 2 seconds for response ...
IPsec을 설정하는 데 사용되는 IKE 프로토콜이 암호화되어 있으므로 tcpdump
도구를 사용하여 문제의 제한된 하위 집합만 해결할 수 있습니다. 방화벽이 IKE 또는 IPsec 패킷을 삭제하는 경우 tcpdump
유틸리티를 사용하여 해당 원인을 찾을 수 있습니다. 그러나 tcpdump
는 IPsec VPN 연결의 다른 문제를 진단할 수 없습니다.
eth0
인터페이스에서 VPN과 암호화된 모든 데이터의 협상을 캡처하려면 다음을 수행합니다.# tcpdump -i eth0 -n -n esp or udp port 500 or udp port 4500 or tcp port 4500
일치하지 않는 알고리즘, 프로토콜 및 정책
VPN 연결에서는 엔드포인트에 IKE 알고리즘, IPsec 알고리즘 및 IP 주소 범위가 일치해야 합니다. 불일치가 발생하면 연결에 실패합니다. 다음 방법 중 하나를 사용하여 일치하지 않는 경우 알고리즘, 프로토콜 또는 정책을 조정하여 수정합니다.
원격 엔드포인트가 IKE/IPsec을 실행 중이 아닌 경우 이를 나타내는 ICMP 패킷이 표시됩니다. 예를 들면 다음과 같습니다.
# ipsec auto --up vpn.example.com ... 000 "vpn.example.com"[1] 192.0.2.2 #16: ERROR: asynchronous network error report on wlp2s0 (192.0.2.2:500), complainant 198.51.100.1: Connection refused [errno 111, origin ICMP type 3 code 3 (not authenticated)] ...
일치하지 않는 알고리즘의 예:
# ipsec auto --up vpn.example.com ... 003 "vpn.example.com"[1] 193.110.157.148 #3: dropping unexpected IKE_SA_INIT message containing NO_PROPOSAL_CHOSEN notification; message payloads: N; missing payloads: SA,KE,Ni
일치하지 않는 IPsec 알고리즘의 예:
# ipsec auto --up vpn.example.com ... 182 "vpn.example.com"[1] 193.110.157.148 #5: STATE_PARENT_I2: sent v2I2, expected v2R2 {auth=IKEv2 cipher=AES_GCM_16_256 integ=n/a prf=HMAC_SHA2_256 group=MODP2048} 002 "vpn.example.com"[1] 193.110.157.148 #6: IKE_AUTH response contained the error notification NO_PROPOSAL_CHOSEN
일치하지 않는 IKE 버전으로 인해 응답 없이 원격 끝점에서 요청을 삭제할 수도 있습니다. 이는 모든 IKE 패킷을 삭제하는 방화벽과 동일합니다.
IKEv2의 일치하지 않는 IP 주소 범위 예(트래픽 선택기 - TS)
# ipsec auto --up vpn.example.com ... 1v2 "vpn.example.com" #1: STATE_PARENT_I2: sent v2I2, expected v2R2 {auth=IKEv2 cipher=AES_GCM_16_256 integ=n/a prf=HMAC_SHA2_512 group=MODP2048} 002 "vpn.example.com" #2: IKE_AUTH response contained the error notification TS_UNACCEPTABLE
IKEv1의 일치하지 않는 IP 주소 범위 예:
# ipsec auto --up vpn.example.com ... 031 "vpn.example.com" #2: STATE_QUICK_I1: 60 second timeout exceeded after 0 retransmits. No acceptable response to our first Quick Mode message: perhaps peer likes no proposal
IKEv1에서 PreSharedKeys (PSK)를 사용하는 경우 양쪽이 동일한 PSK에 배치되지 않으면 전체 IKE 메시지가 읽을 수 없게됩니다.
# ipsec auto --up vpn.example.com ... 003 "vpn.example.com" #1: received Hash Payload does not match computed value 223 "vpn.example.com" #1: sending notification INVALID_HASH_INFORMATION to 192.0.2.23:500
IKEv2에서 mismatched-PSK 오류로 인해 AUTHENTICATION_FAILED 메시지가 표시됩니다.
# ipsec auto --up vpn.example.com ... 002 "vpn.example.com" #1: IKE SA authentication request rejected by peer: AUTHENTICATION_FAILED
최대 전송 단위
IKE 또는 IPsec 패킷을 차단하는 방화벽 이외의 네트워킹 문제의 가장 일반적인 원인은 암호화된 패킷의 증가된 패킷 크기와 관련이 있습니다. 네트워크 하드웨어 조각은 최대 전송 단위(MTU)보다 큰 패킷(예: 1500바이트)입니다. 종종 조각이 손실되고 패킷이 다시 조립되지 않습니다. 이로 인해 크기가 작은 패킷을 사용하는 ping 테스트가 작동할 때 간헐적으로 오류가 발생하지만 다른 트래픽은 실패합니다. 이 경우 SSH 세션을 설정할 수 있지만 원격 호스트에 'ls -al /usr' 명령을 입력하여 바로 터미널이 중지됩니다.
이 문제를 해결하려면 터널 구성 파일에 mtu=1400
옵션을 추가하여 MTU 크기를 줄입니다.
또는 TCP 연결의 경우 MSS 값을 변경하는 iptables 규칙을 활성화합니다.
# iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
이전 명령에서 시나리오의 문제를 해결하지 않으면 set-mss
매개변수에 더 작은 크기를 직접 지정합니다.
# iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1380
NAT(네트워크 주소 변환)
IPsec 호스트가 NAT 라우터 역할을 할 때 실수로 패킷을 다시 매핑할 수 있습니다. 다음 예제 구성은 문제를 보여줍니다.
conn myvpn left=172.16.0.1 leftsubnet=10.0.2.0/24 right=172.16.0.2 rightsubnet=192.168.0.0/16 …
주소가 172.16.0.1인 시스템에는 NAT 규칙이 있습니다.
iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
주소 10.0.2.33의 시스템이 패킷을 192.168.0.1로 보내는 경우 라우터는 IPsec 암호화를 적용하기 전에 소스 10.0.2.33을 172.16.0.1로 변환합니다.
그런 다음 소스 주소가 10.0.2.33인 패킷이 더 이상 conn myvpn
설정과 일치하지 않으며 IPsec은 이 패킷을 암호화하지 않습니다.
이 문제를 해결하려면 라우터의 대상 IPsec 서브넷 범위에 대해 NAT를 제외하는 규칙을 삽입합니다. 예를 들면 다음과 같습니다.
iptables -t nat -I POSTROUTING -s 10.0.2.0/24 -d 192.168.0.0/16 -j RETURN
커널 IPsec 하위 시스템 버그
예를 들어 버그로 인해 IKE 사용자 공간과 IPsec 커널이 동기화 해제되는 경우 커널 IPsec 하위 시스템이 실패할 수 있습니다. 이러한 문제를 확인하려면 다음을 수행합니다.
$ cat /proc/net/xfrm_stat
XfrmInError 0
XfrmInBufferError 0
...
이전 명령의 출력에 0이 아닌 값은 문제가 있음을 나타냅니다. 이 문제가 발생하면 새 지원 케이스를 열고 해당 IKE 로그와 함께 이전 명령의 출력을 연결합니다.
Libreswan 로그
기본적으로 syslog
프로토콜을 사용하는 Libreswan 로그입니다. journalctl
명령을 사용하여 IPsec과 관련된 로그 항목을 찾을 수 있습니다. 로그에 대한 해당 항목이 pluto
IKE 데몬에서 전송되므로 "pluto" 키워드를 검색합니다. 예를 들면 다음과 같습니다.
$ journalctl -b | grep pluto
ipsec
서비스에 대한 실시간 로그를 표시하려면 다음을 수행합니다.
$ journalctl -f -u ipsec
기본 로깅 수준에서 구성 문제가 표시되지 않는 경우 /etc/ipsec.conf
파일의 구성 설정
섹션에 plutodebug=all
옵션을 추가하여 디버그 로그를 활성화합니다.
디버그 로깅은 많은 항목을 생성하며 journald
또는 syslogd
서비스는 syslog
메시지를 제한할 수 있습니다. 전체 로그를 확인하려면 로깅을 파일로 리디렉션합니다. /etc/ipsec.conf
를 편집하고 config setup
섹션에 logfile=/var/log/pluto.log
를 추가합니다.
추가 리소스
- 로그 파일을 사용하여 문제 해결.
-
tcpdump(8)
및ipsec.conf(5)
도움말 페이지. - firewalld 사용 및 구성
6.15. 추가 리소스
-
IPsec(8)
,ipsec.conf(5)
,ipsec.secrets(5)
,ipsec_auto(8)
,ipsec_rsasigkey(8)
도움말 페이지. -
/usr/share/doc/libreswan-version/
directory. - 업스트림 프로젝트의 웹 사이트.
- Libreswan Project Wiki.
- 모든 Libreswan 도움말 페이지.
- NIST 특별 발행 800-77: IPsec VPN에 대한 가이드.
7장. vpn
RHEL 시스템 역할을 사용하여 IPsec으로 VPN 연결 구성
vpn
System Role을 사용하면 Red Hat Ansible Automation Platform을 사용하여 RHEL 시스템에서 VPN 연결을 구성할 수 있습니다. 이를 사용하여 host-to-host, network-to-network, VPN Remote Access Server 및 메시 구성을 설정할 수 있습니다.
호스트 간 연결의 경우 역할은 필요에 따라 기본 매개 변수를 사용하여 vpn_connections
목록에 있는 각 호스트 쌍 간에 VPN 터널을 설정합니다. 또는 나열된 모든 호스트 간에 opportunistic 메시 구성을 생성하도록 구성할 수 있습니다. 이 역할은 호스트에
있는 호스트의 이름이 Ansible 인벤토리에 사용된 호스트의 이름과 동일하고 해당 이름을 사용하여 터널을 구성할 수 있다고 가정합니다.
vpn
RHEL 시스템 역할은 현재 VPN 공급자로서 IPsec 구현인 Libreswan만 지원합니다.
7.1. vpn
시스템 역할을 사용하여 IPsec을 사용하여 호스트 간 VPN 생성
vpn
시스템 역할을 사용하여 제어 노드에서 Ansible 플레이북을 실행하여 호스트 간 연결을 구성할 수 있습니다. 그러면 인벤토리 파일에 나열된 모든 관리 노드를 구성할 수 있습니다.
사전 요구 사항
-
vpn
시스템 역할로 구성하려는 시스템인 하나 이상의 관리형 노드에 액세스하고 권한을 부여합니다. Red Hat Ansible Core가 기타 시스템을 구성하는 시스템인 제어 노드 액세스 및 사용 권한.
제어 노드에서 다음이 있어야 합니다.
-
ansible-core
및rhel-system-roles
패키지가 설치됩니다.
-
RHEL 8.0-8.5는 Ansible 기반 자동화를 위해 Ansible Engine 2.9가 포함된 별도의 Ansible 리포지토리에 대한 액세스를 제공했습니다. Ansible Engine에는 ansible ,
, ansible
-playbookdocker
및 podman
과 같은 커넥터, 여러 플러그인 및 모듈과 같은 명령줄 유틸리티가 포함되어 있습니다. Ansible Engine을 확보하고 설치하는 방법에 대한 자세한 내용은 Red Hat Ansible Engine 지식베이스를 다운로드하고 설치하는 방법 문서를 참조하십시오.
RHEL 8.6 및 9.0에서는 Ansible 명령줄 유틸리티, 명령 및 소규모의 기본 제공 Ansible 플러그인 세트가 포함된 Ansible Core( ansible-core
패키지로 제공)를 도입했습니다. RHEL은 AppStream 리포지토리를 통해 이 패키지를 제공하며 제한된 지원 범위를 제공합니다. 자세한 내용은 RHEL 9 및 RHEL 8.6 이상 AppStream 리포지토리 지식 베이스에 포함된 Ansible Core 패키지에 대한 지원 범위를 참조하십시오.
- 관리 노드를 나열하는 인벤토리 파일.
절차
다음 내용으로 새
playbook.yml
파일을 생성합니다.- name: Host to host VPN hosts: managed_node1, managed_node2 roles: - rhel-system-roles.vpn vars: vpn_connections: - hosts: managed_node1: managed_node2: vpn_manage_firewall: true vpn_manage_selinux: true
이 플레이북은 시스템 역할로 자동 생성되는 키와 사전 공유 키 인증을 사용하여
managed_node1-to-managed_node2
연결을 구성합니다.vpn_manage_firewall
및vpn_manage_selinux
는 모두 true로 설정되어 있으므로vpn
역할은firewall
및selinux
역할을 사용하여vpn
역할에서 사용하는 포트를 관리합니다.선택 사항: 다음 섹션을 호스트의
vpn_connections
목록에 추가하여 인벤토리 파일에 나열되지 않은 외부 호스트로의 연결을 구성합니다.vpn_connections: - hosts: managed_node1: managed_node2: external_node: hostname: 192.0.2.2
이렇게 하면
managed_node1-to-external_node및
의 두 개의 추가 연결이 구성됩니다.managed_node2-
to-external_node
연결은 관리형 노드에서만 구성되며 외부 노드에는 구성되지 않습니다.
선택 사항:
vpn_connections
내의 추가 섹션을 사용하여 관리형 노드에 대해 여러 VPN 연결을 지정할 수 있습니다(예: 컨트롤 플레인 및 데이터 플레인).- name: Multiple VPN hosts: managed_node1, managed_node2 roles: - rhel-system-roles.vpn vars: vpn_connections: - name: control_plane_vpn hosts: managed_node1: hostname: 192.0.2.0 # IP for the control plane managed_node2: hostname: 192.0.2.1 - name: data_plane_vpn hosts: managed_node1: hostname: 10.0.0.1 # IP for the data plane managed_node2: hostname: 10.0.0.2
-
선택 사항: 환경 설정에 따라 변수를 수정할 수 있습니다. 자세한 내용은
/usr/share/doc/rhel-system-roles/vpn/README.md
파일을 참조하십시오. 선택 사항: 플레이북 구문을 확인합니다.
# ansible-playbook --syntax-check /path/to/file/playbook.yml -i /path/to/file/inventory_file
인벤토리 파일에서 플레이북을 실행합니다.
# ansible-playbook -i /path/to/file/inventory_file /path/to/file/playbook.yml
검증
관리형 노드에서 연결이 성공적으로 로드되었는지 확인합니다.
# ipsec status | grep connection.name
connection.name을 이 노드의 연결 이름으로 교체합니다(예:
managed_node1-to-managed_node2
).
기본적으로 역할은 각 시스템의 관점에서 생성하는 각 연결에 대해 설명이 포함된 이름을 생성합니다. 예를 들어 managed_node1
과 managed_node2
간의 연결을 생성할 때 managed_node1
에서 이 연결의 설명적인 이름은 managed_node1-to-managed_node2
이지만, managed_node2
에서 연결 이름은 managed_node2-to-managed_node1
입니다.
관리형 노드에서 연결이 성공적으로 시작되었는지 확인합니다.
# ipsec trafficstatus | grep connection.name
선택 사항: 연결이 성공적으로 로드되지 않은 경우 다음 명령을 입력하여 연결을 수동으로 추가합니다. 이렇게 하면 연결 설정 실패 이유를 나타내는 더 구체적인 정보를 제공합니다.
# ipsec auto --add connection.name
참고연결을 로드하고 시작하는 동안 발생한 모든 오류는 로그에 보고되며,
/var/log/pluto.log
에서 확인할 수 있습니다. 이러한 로그는 구문 분석하기 어렵기 때문에 대신 표준 출력에서 로그 메시지를 가져오기 위해 수동으로 연결을 추가합니다.
7.2. vpn
시스템 역할을 사용하여 IPsec과 opportunistic mesh VPN 연결 생성
vpn
System Role을 사용하여 제어 노드에서 Ansible 플레이북을 실행하여 인증에 인증서를 사용하는 opportunistic 메시 VPN 연결을 구성할 수 있습니다. 그러면 인벤토리 파일에 나열된 모든 관리형 노드를 구성할 수 있습니다.
인증서를 사용한 인증은 플레이북에 auth_method: cert
매개변수를 정의하여 구성됩니다. vpn
시스템 역할은 /etc/ipsec.d
디렉터리에 정의된 IPsec 네트워크 보안 서비스(NSS) 암호화 라이브러리에 필요한 인증서가 포함되어 있다고 가정합니다. 기본적으로 노드 이름은 인증서 닉네임으로 사용됩니다. 이 예제에서는 managed_node1
입니다. 인벤토리의 cert_name
특성을 사용하여 다른 인증서 이름을 정의할 수 있습니다.
다음 예제 절차에서 Ansible 플레이북을 실행하는 시스템인 제어 노드는 관리형 노드(192.0.2.0/24)와 동일한 클래스의 도메인 간 라우팅(CIDR) 번호를 공유하며, IP 주소 192.0.2.7이 있습니다. 따라서 제어 노드는 CIDR 192.0.2.0/24에 대해 자동으로 생성되는 개인 정책에 속합니다.
플레이 중에 SSH 연결 손실을 방지하기 위해 제어 노드에 대한 명확한 정책이 정책 목록에 포함됩니다. CIDR이 기본값과 같은 정책 목록에도 항목이 있습니다. 이 플레이북은 기본 정책의 규칙을 재정의하여 private-or-clear 대신 비공개로 만들기 때문입니다.
사전 요구 사항
vpn
시스템 역할로 구성하려는 시스템인 하나 이상의 관리형 노드에 액세스하고 권한을 부여합니다.-
모든 관리형 노드에서
/etc/ipsec.d
디렉터리의 NSS 데이터베이스에는 피어 인증에 필요한 모든 인증서가 포함되어 있습니다. 기본적으로 노드 이름은 인증서 닉네임으로 사용됩니다.
-
모든 관리형 노드에서
Red Hat Ansible Core가 기타 시스템을 구성하는 시스템인 제어 노드 액세스 및 사용 권한.
제어 노드에서 다음이 있어야 합니다.
-
ansible-core
및rhel-system-roles
패키지가 설치됩니다.
-
RHEL 8.0-8.5는 Ansible 기반 자동화를 위해 Ansible Engine 2.9가 포함된 별도의 Ansible 리포지토리에 대한 액세스를 제공했습니다. Ansible Engine에는 ansible ,
, ansible
-playbookdocker
및 podman
과 같은 커넥터, 여러 플러그인 및 모듈과 같은 명령줄 유틸리티가 포함되어 있습니다. Ansible Engine을 확보하고 설치하는 방법에 대한 자세한 내용은 Red Hat Ansible Engine 지식베이스를 다운로드하고 설치하는 방법 문서를 참조하십시오.
RHEL 8.6 및 9.0에서는 Ansible 명령줄 유틸리티, 명령 및 소규모의 기본 제공 Ansible 플러그인 세트가 포함된 Ansible Core( ansible-core
패키지로 제공)를 도입했습니다. RHEL은 AppStream 리포지토리를 통해 이 패키지를 제공하며 제한된 지원 범위를 제공합니다. 자세한 내용은 RHEL 9 및 RHEL 8.6 이상 AppStream 리포지토리 지식 베이스에 포함된 Ansible Core 패키지에 대한 지원 범위를 참조하십시오.
- 관리 노드를 나열하는 인벤토리 파일.
절차
다음 내용으로 새
playbook.yml
파일을 생성합니다.- name: Mesh VPN hosts: managed_node1, managed_node2, managed_node3 roles: - rhel-system-roles.vpn vars: vpn_connections: - opportunistic: true auth_method: cert policies: - policy: private cidr: default - policy: private-or-clear cidr: 198.51.100.0/24 - policy: private cidr: 192.0.2.0/24 - policy: clear cidr: 192.0.2.7/32 vpn_manage_firewall: true vpn_manage_selinux: true
참고vpn_manage_firewall
및vpn_manage_selinux
는 모두 true로 설정되어 있으므로vpn
역할은firewall
및selinux
역할을 사용하여vpn
역할에서 사용하는 포트를 관리합니다.-
선택 사항: 환경 설정에 따라 변수를 수정할 수 있습니다. 자세한 내용은
/usr/share/doc/rhel-system-roles/vpn/README.md
파일을 참조하십시오. 선택 사항: 플레이북 구문을 확인합니다.
# ansible-playbook --syntax-check playbook.yml
인벤토리 파일에서 플레이북을 실행합니다.
# ansible-playbook -i inventory_file /path/to/file/playbook.yml
7.3. 추가 리소스
-
vpn
시스템 역할에 사용된 매개변수 및 역할에 대한 추가 정보는/usr/share/doc/rhel-system-roles/vpn/README.md
파일을 참조하십시오. -
ansible-playbook
명령에 대한 자세한 내용은ansible-playbook(1)
도움말 페이지를 참조하십시오.
8장. 네트워크 서비스 보안
Red Hat Enterprise Linux 9는 다양한 유형의 네트워크 서버를 지원합니다. 네트워크 서비스는 DoS(서비스 거부 공격), DDoS(Distributed Denial of Service Attack), 스크립트 취약점 공격, 버퍼 오버플로 공격과 같은 다양한 유형의 공격에 시스템 보안을 노출할 수 있습니다.
공격에 대한 시스템 보안을 강화하려면 사용하는 활성 네트워크 서비스를 모니터링하는 것이 중요합니다. 예를 들어 네트워크 서비스가 시스템에서 실행되는 경우 해당 데몬은 네트워크 포트의 연결을 수신 대기하므로 보안이 저하될 수 있습니다. 네트워크를 통한 공격에 대한 노출을 제한하려면 사용되지 않은 모든 서비스를 해제해야 합니다.
8.1. Diffiebind 서비스 보안
ResourceOverride bind
서비스는 원격 프로시저 호출(RPC) 서비스(Network Information Service) 및 NFS(Network File System)와 같은 서비스를 위한 동적 포트 할당 데몬입니다. 이 메커니즘은 약한 인증 메커니즘을 가지고 있으며 제어하는 서비스에 대해 광범위한 포트를 할당할 수 있으므로 Diffie bind를 보호하는 것이
중요합니다.
모든 네트워크에 대한 액세스를 제한하고 서버의 방화벽 규칙을 사용하여 특정 예외를 정의하여 Diffie bind
를 보호할 수 있습니다.
-
NFSv3
서버에는 Diffiebind
서비스가 필요합니다. -
NFSv4
에서는rpcbind 서비스가 네트워크에서
수신 대기할 필요가 없습니다.
사전 요구 사항
-
alice
bind
패키지가 설치되어 있어야 합니다. -
firewalld
패키지가 설치되었으며 서비스가 실행 중입니다.
절차
방화벽 규칙을 추가합니다. 예를 들면 다음과 같습니다.
TCP 연결을 제한하고
111
포트를 통해192.168.0.0/24
호스트에서 패키지를 수락합니다.# firewall-cmd --add-rich-rule='rule family="ipv4" port port="111" protocol="tcp" source address="192.168.0.0/24" invert="True" drop'
TCP 연결을 제한하고
111
포트를 통해 로컬 호스트에서 패키지를 수락합니다.# firewall-cmd --add-rich-rule='rule family="ipv4" port port="111" protocol="tcp" source address="127.0.0.1" accept'
UDP 연결을 제한하고
111
포트를 통해192.168.0.0/24
호스트에서 패키지를 수락합니다.# firewall-cmd --permanent --add-rich-rule='rule family="ipv4" port port="111" protocol="udp" source address="192.168.0.0/24" invert="True" drop'
방화벽 설정을 영구적으로 설정하려면 방화벽 규칙을 추가할 때
--permanent
옵션을 사용합니다.
방화벽을 다시 로드하여 새 규칙을 적용합니다.
# firewall-cmd --reload
검증 단계
방화벽 규칙을 나열합니다.
# firewall-cmd --list-rich-rule rule family="ipv4" port port="111" protocol="tcp" source address="192.168.0.0/24" invert="True" drop rule family="ipv4" port port="111" protocol="tcp" source address="127.0.0.1" accept rule family="ipv4" port port="111" protocol="udp" source address="192.168.0.0/24" invert="True" drop
추가 리소스
-
NFSv4 전용
서버에 대한 자세한 내용은 NFSv4 전용 서버 구성 섹션을 참조하십시오. - firewalld 사용 및 구성
8.2. Diffie.mountd 서비스 보안
rpc.mountd
데몬은 NFS 마운트 프로토콜의 서버 측을 구현합니다. NFS 마운트 프로토콜은 NFS 버전 3(RFC 1813)에서 사용됩니다.
서버에 방화벽 규칙을 추가하여 rpc.mountd
서비스를 보호할 수 있습니다. 모든 네트워크에 대한 액세스를 제한하고 방화벽 규칙을 사용하여 특정 예외를 정의할 수 있습니다.
사전 요구 사항
-
alice
.mountd
패키지가 설치되어 있습니다. -
firewalld
패키지가 설치되었으며 서비스가 실행 중입니다.
절차
서버에 방화벽 규칙을 추가합니다. 예를 들면 다음과 같습니다.
192.168.0.0/24
호스트에서mountd
연결을 수락합니다.# firewall-cmd --add-rich-rule 'rule family="ipv4" service name="mountd" source address="192.168.0.0/24" invert="True" drop'
로컬 호스트에서
mountd
연결을 수락합니다.# firewall-cmd --permanent --add-rich-rule 'rule family="ipv4" source address="127.0.0.1" service name="mountd" accept'
방화벽 설정을 영구적으로 설정하려면 방화벽 규칙을 추가할 때
--permanent
옵션을 사용합니다.
방화벽을 다시 로드하여 새 규칙을 적용합니다.
# firewall-cmd --reload
검증 단계
방화벽 규칙을 나열합니다.
# firewall-cmd --list-rich-rule rule family="ipv4" service name="mountd" source address="192.168.0.0/24" invert="True" drop rule family="ipv4" source address="127.0.0.1" service name="mountd" accept
추가 리소스
8.3. NFS 서비스 보안
Kerberos를 사용하여 모든 파일 시스템 작업을 인증하고 암호화하여 NFSv4(Network File System 버전)를 보호할 수 있습니다. NAT(Network Address Translation) 또는 방화벽으로 NFSv4를 사용하는 경우 /etc/default/nfs
파일을 수정하여 위임을 해제할 수 있습니다. 위임은 서버가 파일 관리를 클라이언트에 위임하는 기술입니다.
반면 NFSv3에서는 파일 잠금 및 마운트에 Kerberos를 사용하지 않습니다.
NFS 서비스는 모든 버전의 NFS에서 TCP를 사용하여 트래픽을 전송합니다. 이 서비스는 RPCSEC_GSS
커널 모듈의 일부로 Kerberos 사용자 및 그룹 인증을 지원합니다.
NFS를 사용하면 원격 호스트가 네트워크를 통해 파일 시스템을 마운트하고 로컬에 마운트된 것처럼 해당 파일 시스템과 상호 작용할 수 있습니다. 중앙 집중식 서버의 리소스를 병합하고 파일 시스템을 공유할 때 /etc/nfsmount.conf
파일에 NFS 마운트 옵션을 추가로 사용자 지정할 수 있습니다.
8.3.1. NFS 서버 보안을 위한 내보내기 옵션
NFS 서버에서는 /etc/exports
파일의 호스트로 내보낼 파일 시스템과 디렉터리의 목록 구조를 결정합니다.
내보내기 파일의 구문에 있는 추가 공백을 사용하면 구성이 크게 변경될 수 있습니다.
다음 예에서 /tmp/nfs/
디렉터리는 bob.example.com
호스트와 공유되며 읽기 및 쓰기 권한이 있습니다.
/tmp/nfs/ bob.example.com(rw)
다음 예제는 이전 항목과 동일하지만, bob.example.com
호스트와 동일한 디렉터리를 읽기 전용 권한으로 공유하고 호스트 이름 뒤의 단일 공백 문자로 인해 읽기 및 쓰기 권한으로 세계와 공유합니다.
/tmp/nfs/ bob.example.com (rw)
showmount -e <hostname> 명령을 입력하여 시스템의 공유 디렉토리를
확인할 수 있습니다.
/etc/exports
파일에서 다음 내보내기 옵션을 사용합니다.
파일 시스템의 하위 디렉터리 내보내기는 안전하지 않으므로 전체 파일 시스템을 내보냅니다. 공격자는 부분적으로 내보낸 파일 시스템의 내보내기 해제 부분에 액세스할 수 있습니다.
- ro
-
ro
옵션을 사용하여 NFS 볼륨을 읽기 전용으로 내보냅니다. - rw
rw
옵션을 사용하여 NFS 볼륨에서 읽기 및 쓰기 요청을 허용합니다. 쓰기 액세스를 허용하므로 이 옵션을 신중하게 사용하면 공격 위험이 높아집니다.참고시나리오에서
rw
옵션을 사용하여 디렉터리를 마운트해야 하는 경우 모든 사용자가 가능한 위험을 줄이기 위해 쓸 수 있는 권한이 없는지 확인합니다.- root_squash
-
root_squash
옵션을 사용하여uid
/gid
0의 요청을 anonymousuid
/gid
에 매핑합니다. 이는bin
사용자 또는staff
그룹과 같이 동일하게 민감할 수 있는 다른 지침 또는 gid에는 적용되지 않습니다. - no_root_squash
-
no_root_squash
옵션을 사용하여 루트 스쿼시를 끄십시오. 기본적으로 NFS 공유는root
사용자를 권한이 없는 사용자 계정인nobody
사용자로 변경합니다. 이렇게 하면 생성된 모든 파일의 소유자가nobody
로 변경되어setuid
bit가 설정된 프로그램의 업로드가 방지됩니다.no_root_squash
옵션을 사용하는 경우 원격 루트 사용자는 공유 파일 시스템의 파일을 변경하고 다른 사용자에게 트로이 목마에 의해 감염된 애플리케이션을 남길 수 있습니다. - 보안
-
예약된 포트로 내보내기를 제한하려면
secure
옵션을 사용합니다. 기본적으로 서버는 예약된 포트를 통해서만 클라이언트 통신을 허용합니다. 그러나 많은 네트워크에서 클라이언트의root
사용자가 되는 것은 누구나 쉽지 않으므로 예약된 포트를 통한 통신이 권한이 있다고 가정하는 것은 서버에서 안전하지 않습니다. 따라서 예약된 포트에 대한 제한은 제한된 값입니다. Kerberos, 방화벽 및 특정 클라이언트에 대한 내보내기 제한에 의존하는 것이 좋습니다.
또한 NFS 서버를 내보낼 때 다음과 같은 모범 사례를 고려하십시오.
- 일부 애플리케이션은 일반 텍스트 또는 약한 암호화 형식으로 암호를 저장하기 때문에 홈 디렉터리를 내보내는 것은 위험합니다. 애플리케이션 코드를 검토 및 개선하여 위험을 줄일 수 있습니다.
- 일부 사용자는 SSH 키에 암호를 설정하지 않아 홈 디렉터리의 위험이 다시 발생합니다. 암호를 강제 사용하거나 Kerberos를 사용하여 이러한 위험을 줄일 수 있습니다.
-
NFS 내보내기를 필수 클라이언트로만 제한합니다. NFS 서버에서
showmount -e
명령을 사용하여 서버가 내보내는 내용을 검토합니다. 특히 필요하지 않은 항목을 내보내지 마십시오. - 불필요한 사용자가 서버에 로그인하여 공격 위험을 줄이도록 허용하지 마십시오. 정기적으로 서버에 액세스할 수 있는 사용자 및 항목을 확인할 수 있습니다.
추가 리소스
- Red Hat Identity Management 사용 시 Kerberos로 NFS 보안
- NFS 서버 구성.
-
exports(5)
및nfs(5) 도움말
페이지
8.3.2. NFS 클라이언트 보안을 위한 마운트 옵션
다음 옵션을 mount
명령에 전달하여 NFS 기반 클라이언트의 보안을 강화할 수 있습니다.
- nosuid
-
nosuid
옵션을 사용하여set-user-identifier
또는set-group-identifier
비트를 비활성화합니다. 이렇게 하면 원격 사용자가setuid
프로그램을 실행하여 더 높은 권한을 얻지 못하며setuid
옵션 대신 이 옵션을 사용할 수 있습니다. - noexec
-
noexec
옵션을 사용하여 클라이언트의 실행 파일을 모두 비활성화합니다. 이를 사용하여 사용자가 공유 파일 시스템에 저장된 파일을 실수로 실행하지 못하도록 합니다. - nodev
-
nodev
옵션을 사용하여 클라이언트의 장치 파일을 하드웨어 장치로 처리하지 않도록 합니다. - resvport
-
resvport
옵션을 사용하여 예약된 포트로의 통신을 제한하고 권한 있는 소스 포트를 사용하여 서버와 통신할 수 있습니다. 예약된 포트는 권한 있는 사용자 및root
사용자와 같은 프로세스를 위해 예약됩니다. - 초
-
NFS 서버에서
sec
옵션을 사용하여 마운트 지점의 파일에 액세스하기 위해 RPCGSS 보안 플레이버를 선택합니다. 유효한 보안 플레이버는없음
,sys
,krb5
,krb5i
,krb5p
입니다.
krb5-libs
패키지에서 제공하는 MIT Kerberos 라이브러리는 새 배포에서 DES(Data Encryption Standard) 알고리즘을 지원하지 않습니다. 보안 및 호환성 때문에 DES는 더 이상 사용되지 않으며 Kerberos 라이브러리에서 기본적으로 비활성화되어 있습니다. 호환성 이유로 환경에서 DES가 필요하지 않은 최신 보안 알고리즘을 사용하십시오.
추가 리소스
8.3.3. 방화벽을 사용하여 NFS 보안
NFS 서버에서 방화벽을 보호하려면 필요한 포트만 열어 둡니다. 다른 서비스에 NFS 연결 포트 번호를 사용하지 마십시오.
사전 요구 사항
-
nfs-utils
패키지가 설치됩니다. -
firewalld
패키지가 설치되어 실행 중입니다.
절차
-
NFSv4에서 방화벽이 TCP 포트
2049
를 열어야 합니다. NFSv3에서
2049
로 4개의 추가 포트를 엽니다.rpcbind
서비스는 NFS 포트를 동적으로 할당하므로 방화벽 규칙을 생성할 때 문제가 발생할 수 있습니다. 이 프로세스를 단순화하려면/etc/nfs.conf
파일을 사용하여 사용할 포트를 지정합니다.-
port
= <value> 형식의
설정합니다.[
의 TCP 및 UDP 포트를mountd
-
port
= <value> 형식의
설정합니다.[
)에 대한 TCP 및 UDP 포트를statd
] 섹션에서 statd(framework.
-
port
/etc/nfs.conf
파일에서 NFS 잠금 관리자(nlockmgr
)의 TCP 및 UDP 포트를 설정합니다.-
port=value
형식의[lock
d )의 TCP 포트를 설정합니다. 또는d]
섹션에서nlockmgr
(authorization.stat/etc/modprobe.d/lockd.conf
파일에서nlm_tcpport
옵션을 사용할 수 있습니다. -
udp-port=value
형식의[lock
d )에 대해 UDP 포트를 설정합니다. 또는d]
섹션에서nlockmgr
(authorization.stat/etc/modprobe.d/lockd.conf
파일에서nlm_udpport
옵션을 사용할 수 있습니다.
-
검증 단계
NFS 서버의 활성 포트 및 RPC 프로그램을 나열합니다.
$ rpcinfo -p
추가 리소스
- Red Hat Identity Management 사용 시 Kerberos로 NFS 보안
-
exports(5)
및nfs(5) 도움말
페이지
8.4. FTP 서비스 보안
FTP(파일 전송 프로토콜)를 사용하여 네트워크를 통해 파일을 전송할 수 있습니다. 사용자 인증을 포함한 서버의 모든 FTP 트랜잭션은 암호화되지 않으므로 안전하게 구성되었는지 확인해야 합니다.
RHEL 9는 두 개의 FTP 서버를 제공합니다.
- Red Hat Content Accelerator(tux) - FTP 기능을 사용하는 커널 공간 웹 서버.
- FTP 서비스의 독립 실행형 보안 중심 구현인 매우 Secure FTP Daemon(chart)입니다.
다음 보안 지침은 vsftpd
FTP 서비스를 설정하기 위한 것입니다.
8.4.1. FTP 인사 배너 보안
사용자가 FTP 서비스에 연결하면 FTP에는 기본적으로 공격자가 시스템의 약점을 식별하는 데 유용할 수 있는 버전 정보가 포함되어 있습니다. 공격자는 기본 배너를 변경하여 이 정보에 액세스하지 못하도록 할 수 있습니다.
단일 줄 메시지를 직접 포함하거나 여러 줄 메시지를 포함할 수 있는 별도의 파일을 참조하도록 /etc/banners/ftp.msg
파일을 편집하여 사용자 지정 배너를 정의할 수 있습니다.
절차
한 줄 메시지를 정의하려면 다음 옵션을
/etc/COMPLETE/COMPLETE.conf
파일에 추가하십시오.ftpd_banner=Hello, all activity on ftp.example.com is logged.
별도의 파일에 메시지를 정의하려면 다음을 수행합니다.
배너 메시지가 포함된
.msg
파일을 만듭니다(예:/etc/banners/ftp.msg
):######### Hello, all activity on ftp.example.com is logged. #########
여러 배너의 관리를 단순화하려면 모든 배너를
/etc/banners/
디렉토리에 배치합니다./etc/COMPLETE/COMPLETE.conf 파일의
banner_file
옵션에 배너 파일 경로를 추가합니다.banner_file=/etc/banners/ftp.msg
검증
수정된 배너를 표시합니다.
$ ftp localhost Trying ::1… Connected to localhost (::1). Hello, all activity on ftp.example.com is logged.
8.4.2. FTP에서 익명 액세스 및 업로드 방지
기본적으로 vsftpd
패키지를 설치하면 디렉터리에 대한 읽기 전용 권한이 있는 익명 사용자의 경우 /var/ftp/
디렉터리와 디렉터리 트리가 생성됩니다. 익명 사용자는 데이터에 액세스할 수 있으므로 중요한 데이터를 이러한 디렉터리에 저장하지 마십시오.
시스템의 보안을 강화하기 위해 익명 사용자가 특정 디렉터리에 파일을 업로드하고 익명의 사용자가 데이터를 읽지 못하도록 FTP 서버를 구성할 수 있습니다. 다음 절차에서는 익명 사용자가 root
사용자가 소유한 디렉터리에 파일을 업로드할 수 있지만 변경할 수는 없어야 합니다.
절차
/var/ftp/pub/
디렉토리에 쓰기 전용 디렉토리를 만듭니다.# mkdir /var/ftp/pub/upload # chmod 730 /var/ftp/pub/upload # ls -ld /var/ftp/pub/upload drwx-wx---. 2 root ftp 4096 Nov 14 22:57 /var/ftp/pub/upload
다음 행을
/etc/COMPLETE/vsftpd.conf
파일에 추가합니다.anon_upload_enable=YES anonymous_enable=YES
-
선택 사항: 시스템에 SELinux를 활성화 및 적용하는 경우 SELinux 부울 속성
allow_ftpd_anon_write
및allow_ftpd_full_access
를 활성화합니다.
익명의 사용자가 디렉토리를 읽고 쓸 수 있도록 허용하면 서버가 손상되는 소프트웨어를 위한 저장소가 될 수 있습니다.
8.4.3. FTP용 사용자 계정 보안
FTP는 인증을 위해 안전하지 않은 네트워크를 통해 사용자 이름과 암호를 전송합니다. 사용자 계정에서 서버에 대한 시스템 사용자 액세스를 거부하여 FTP의 보안을 개선할 수 있습니다.
구성에 적용할 수 있는 만큼 다음 단계를 수행합니다.
절차
/etc/COMPLETE/COMPLETE.conf 파일에 다음 행을 추가하여
vsftpd
서버의 모든 사용자 계정을 비활성화합니다.local_enable=NO
-
사용자 이름을
/etc/pam.d/
COMPLETE PAM 구성 파일에 추가하여 특정 계정 또는 특정 계정 그룹(예:root
사용자 및sudo
권한이 있는 사용자)에 대한 FTP 액세스를 비활성화합니다. -
/etc/COMPLETE/ftpusers
파일에 사용자 계정을 추가하여 사용자 계정을 비활성화합니다.
8.4.4. 추가 리소스
-
ftpd_selinux(8)
도움말 페이지
8.5. HTTP 서버 보안
8.5.1. httpd.conf의 보안 강화
/etc/httpd/conf/httpd.conf
파일에 보안 옵션을 구성하여 Apache HTTP 서버의 보안을 강화할 수 있습니다.
프로덕션에 배치하기 전에 시스템에서 실행 중인 모든 스크립트가 올바르게 작동하는지 항상 확인하십시오.
root
사용자만 스크립트 또는 공통 게이트웨이 인터페이스(CGI)가 포함된 디렉터리에 쓰기 권한이 있는지 확인합니다. 쓰기 권한을 사용하여 디렉터리 소유권을 root
사용자로 변경하려면 다음 명령을 입력합니다.
# chown root directory-name # chmod 755 directory-name
/etc/httpd/conf/httpd.conf
파일에서 다음 옵션을 구성할 수 있습니다.
- FollowSymLinks
- 이 지시문은 기본적으로 활성화되어 있으며 디렉터리에 있는 심볼릭 링크를 따릅니다.
- Indexes
- 이 지시문은 기본적으로 활성화되어 있습니다. 사용자가 서버에서 파일을 검색하지 못하도록 이 지시문을 비활성화합니다.
- UserDir
-
이 지시문은 시스템에 사용자 계정이 있는지 확인할 수 있으므로 기본적으로 비활성화되어 있습니다. 사용자 디렉터리 검색
/root/
가 아닌 모든 사용자 디렉터리를 검색하려면 UserDir이활성화된 상태에서 UserDir
이비활성화된
root 지시문을 사용합니다. 비활성화된 계정 목록에 사용자를 추가하려면UserDir disabled
줄에 공백으로 구분된 사용자 목록을 추가합니다. - ServerTokens
이 지시문은 클라이언트에 다시 전송되는 서버 응답 헤더 필드를 제어합니다. 다음 매개변수를 사용하여 정보를 사용자 지정할 수 있습니다.
- ServerTokens Full
웹 서버 버전 번호, 서버 운영 체제 세부 정보, 설치된 Apache 모듈 등 사용 가능한 모든 정보를 제공합니다. 예를 들면 다음과 같습니다.
Apache/2.4.37 (Red Hat Enterprise Linux) MyMod/1.2
- ServerTokens Full-Release
릴리스 버전과 함께 사용 가능한 모든 정보를 제공합니다. 예를 들면 다음과 같습니다.
Apache/2.4.37 (Red Hat Enterprise Linux) (Release 41.module+el8.5.0+11772+c8e0c271)
- ServerTokens Prod / ServerTokens ProductOnly
웹 서버 이름을 제공합니다. 예를 들면 다음과 같습니다.
Apache
- ServerTokens Major
웹 서버 주요 릴리스 버전을 제공합니다. 예를 들면 다음과 같습니다.
Apache/2
- ServerTokens Minor
웹 서버 마이너 릴리스 버전을 제공합니다. 예를 들면 다음과 같습니다.
Apache/2.4
- ServerTokens Min / ServerTokens Minimal
웹 서버 최소 릴리스 버전을 제공합니다. 예를 들면 다음과 같습니다.
Apache/2.4.37
- ServerTokens OS
웹 서버 릴리스 버전과 운영 체제를 제공합니다. 예를 들면 다음과 같습니다.
Apache/2.4.37 (Red Hat Enterprise Linux)
ServerTokens Prod
옵션을 사용하여 공격자가 시스템에 대한 중요한 정보를 얻을 위험을 줄일 수 있습니다.
IncludesNoExec
지시문을 제거하지 마십시오. 기본적으로 Server Side Includes (SSI) 모듈은 명령을 실행할 수 없습니다. 이를 변경하면 공격자가 시스템의 명령을 입력할 수 있습니다.
httpd 모듈 제거
httpd
모듈을 제거하여 HTTP 서버의 기능을 제한할 수 있습니다. 이 작업을 수행하려면 /etc/httpd/conf.modules.d/
또는 /etc/httpd/conf.d/
디렉터리에서 구성 파일을 편집합니다. 예를 들어 프록시 모듈을 제거하려면 다음을 수행합니다.
echo '# All proxy modules disabled' > /etc/httpd/conf.modules.d/00-proxy.conf
8.5.2. Nginx 서버 구성 보안
Nginx는 고성능 HTTP 및 프록시 서버입니다. 다음 구성 옵션을 사용하여 Nginx 구성을 강화할 수 있습니다.
절차
버전 문자열을 비활성화하려면
server_tokens
구성 옵션을 수정합니다.server_tokens off;
이 옵션을 사용하면 서버 버전 번호와 같은 추가 세부 정보가 표시되지 않습니다. 이 구성은 Nginx에서 제공하는 모든 요청에 서버 이름만 표시합니다. 예를 들면 다음과 같습니다.
$ curl -sI http://localhost | grep Server Server: nginx
특정
/etc/nginx/
conf 파일의 특정 알려진 웹 애플리케이션 취약점을 완화하는 보안 헤더를 추가합니다.예를 들어
X-Frame-Options
헤더 옵션은 도메인 외부의 모든 페이지를 거부하여 Nginx에서 제공하는 콘텐츠를 프레임하고 클릭재킹 공격을 완화합니다.add_header X-Frame-Options "SAMEORIGIN";
예를 들어
x-content-type
헤더는 이전 브라우저의 MIME 유형 스니핑을 방지합니다.add_header X-Content-Type-Options nosniff;
예를 들어
X-XSS-Protection
헤더는 XSS(Cross-Site Scripting) 필터링을 활성화하여 브라우저에서 Nginx에 의해 응답에 포함된 잠재적으로 악의적인 콘텐츠를 렌더링하지 못하도록 합니다.add_header X-XSS-Protection "1; mode=block";
일반 대중에게 노출되는 서비스를 제한하고 자신이하는 것을 제한하고 방문자로부터 수락 할 수 있습니다. 예를 들면 다음과 같습니다.
limit_except GET { allow 192.168.1.0/32; deny all; }
스니펫은
GET
및HEAD
를 제외한 모든 메서드에 대한 액세스를 제한합니다.HTTP 메서드를 비활성화할 수 있습니다. 예를 들면 다음과 같습니다.
# Allow GET, PUT, POST; return "405 Method Not Allowed" for all others. if ( $request_method !~ ^(GET|PUT|POST)$ ) { return 405; }
- Nginx 웹 서버에서 제공하는 데이터를 보호하도록 SSL을 구성할 수 있으며 HTTPS를 통해서만 서비스를 제공하는 것이 좋습니다. 또한 Mozilla SSL 구성 생성기를 사용하여 Nginx 서버에서 SSL을 활성화하기 위한 보안 구성 프로파일을 생성할 수 있습니다. 생성된 구성을 사용하면 알려진 취약한 프로토콜(예: SSLv2 및 SSLv3), 암호 및 해시 알고리즘(예: 3DES 및 MD5)이 비활성화됩니다. SSL 서버 테스트를 사용하여 구성이 최신 보안 요구 사항을 충족하는지 확인할 수도 있습니다.
추가 리소스
8.6. 인증된 로컬 사용자에 대한 액세스를 제한하여 PostgreSQL 보안
PostgreSQL은 개체 관계형 데이터베이스 관리 시스템(DBMS)입니다. Red Hat Enterprise Linux에서 PostgreSQL은 postgresql-server
패키지에서 제공합니다.
클라이언트 인증을 구성하여 공격의 위험을 줄일 수 있습니다. 데이터베이스 클러스터의 데이터 디렉터리에 저장된 pg_hba.conf
구성 파일은 클라이언트 인증을 제어합니다. 호스트 기반 인증을 위해 PostgreSQL을 구성하려면 절차를 따르십시오.
절차
PostgreSQL을 설치합니다.
# yum install postgresql-server
다음 옵션 중 하나를 사용하여 데이터베이스 스토리지 영역을 초기화합니다.
initdb
유틸리티 사용:$ initdb -D /home/postgresql/db1/
-D
옵션이 있는initdb
명령은 해당 디렉터리가 아직 존재하지 않는 경우 지정한 디렉터리를 생성합니다(예:/home/postgresql/db1/
). 그러면 이 디렉터리에는 데이터베이스에 저장된 모든 데이터와 클라이언트 인증 구성 파일도 포함됩니다.postgresql-setup
스크립트 사용:$ postgresql-setup --initdb
기본적으로 스크립트는
/var/lib/pgsql/data/
디렉터리를 사용합니다. 이 스크립트는 시스템 관리자에게 기본 데이터베이스 클러스터 관리를 지원합니다.
인증된 모든 로컬 사용자가 사용자 이름이 있는 모든 데이터베이스에 액세스할 수 있도록
pg_hba.conf
파일에서 다음 행을 수정합니다.local all all trust
이 문제는 데이터베이스 사용자를 생성하고 로컬 사용자가 없는 계층화된 애플리케이션을 사용할 때 문제가 될 수 있습니다. 시스템의 모든 사용자 이름을 명시적으로 제어하지 않으려면
pg_hba.conf
파일에서로컬
행 항목을 제거합니다.데이터베이스를 다시 시작하여 변경 사항을 적용합니다.
# systemctl restart postgresql
이전 명령은 데이터베이스를 업데이트하고 구성 파일의 구문도 확인합니다.
8.7. Memcached 서비스 보안
Memcached는 오픈 소스 고성능 분산 메모리 개체 캐싱 시스템입니다. 데이터베이스 로드를 줄여 동적 웹 애플리케이션의 성능을 향상시킬 수 있습니다.
Memcached는 데이터베이스 호출, API 호출 또는 페이지 렌더링 결과에서 문자열 및 오브젝트와 같은 임의의 데이터의 작은 청크를 위한 메모리 내 키-값 저장소입니다. Memcached를 사용하면 활용도가 낮은 영역에서 더 많은 메모리가 필요한 애플리케이션에 메모리를 할당할 수 있습니다.
2018년, 공개 인터넷에 노출된 Memcached 서버를 악용하여 DDoS 개정 공격 취약점을 발견했습니다. 이러한 공격은 전송에 UDP 프로토콜을 사용하여 Memcached 통신을 활용합니다. 이 공격은 수 백바이트 크기의 요청이 몇 메가바이트 또는 수백 메가바이트 크기의 응답을 생성할 수 있는 높은 배율 비율로 인해 효과가 있었습니다.
대부분의 경우 memcached
서비스를 공용 인터넷에 노출할 필요가 없습니다. 이러한 노출에는 원격 공격자가 Memcached에 저장된 정보를 유출하거나 수정할 수 있는 자체 보안 문제가 있을 수 있습니다.
이 섹션에 따라 잠재적인 DDoS 공격에 대해 Memcached 서비스를 사용하여 시스템을 강화할 수 있습니다.
8.7.1. DDoS에 대한 Memcached 강화
보안 위험을 완화하려면 구성에 적용 가능한 한 많은 다음 단계를 수행하십시오.
절차
LAN에서 방화벽을 구성합니다. Memcached 서버에 로컬 네트워크에서만 액세스할 수 있어야 하는 경우
memcached
서비스에서 사용하는 포트로 외부 트래픽을 라우팅하지 마십시오. 예를 들어 허용되는 포트 목록에서 기본 포트11211
을 제거합니다.# firewall-cmd --remove-port=11211/udp # firewall-cmd --runtime-to-permanent
애플리케이션과 동일한 시스템에서 단일 Memcached 서버를 사용하는 경우
memcached
를 설정하여 localhost 트래픽만 수신 대기합니다./etc/sysconfig/memcached
파일에서OPTIONS
값을 수정합니다.OPTIONS="-l 127.0.0.1,::1"
SASL(Simple Authentication and Security Layer) 인증을 활성화합니다.
/etc/sasl2/memcached.conf
파일을 수정하거나 추가합니다.sasldb_path: /path.to/memcached.sasldb
SASL 데이터베이스에 계정을 추가합니다.
# saslpasswd2 -a memcached -c cacheuser -f /path.to/memcached.sasldb
memcached
사용자 및 그룹에 대한 데이터베이스에 액세스할 수 있는지 확인합니다.# chown memcached:memcached /path.to/memcached.sasldb
/etc/sysconfig/memcached
파일의OPTIONS
매개변수에-S
값을 추가하여 Memcached에서 SASL 지원을 활성화합니다.OPTIONS="-S"
Memcached 서버를 다시 시작하여 변경 사항을 적용합니다.
# systemctl restart memcached
- SASL 데이터베이스에서 생성된 사용자 이름과 암호를 애플리케이션의 Memcached 클라이언트 구성에 추가합니다.
TLS를 사용하여 Memcached 클라이언트와 서버 간 통신을 암호화합니다.
/etc/sysconfig/memcached
파일의OPTIONS
매개변수에-Z
값을 추가하여 Memcached 클라이언트와 서버 간 암호화된 통신을 활성화합니다.OPTIONS="-Z"
-
-o ssl_chain_cert
옵션을 사용하여 인증서 체인 파일 경로를 PEM 형식으로 추가합니다. -
-o ssl_key
옵션을 사용하여 개인 키 파일 경로를 추가합니다.
9장. MACsec을 사용하여 동일한 물리적 네트워크에서 layer-2 트래픽 암호화
MACsec을 사용하여 두 장치 간(point-to-point) 간의 통신을 보호할 수 있습니다. 예를 들어 분기 사무실은 중앙 사무실과 함께 Metro-Ethernet 연결을 통해 연결되며, 사무실을 연결하는 두 호스트에서 MACsec을 구성하여 보안을 강화할 수 있습니다.
Media Access Control Security (MACsec)는 다음을 포함하여 이더넷 링크를 통해 다양한 트래픽 유형을 보호하는 계층 2 프로토콜입니다.
- DHCP(Dynamic Host Configuration Protocol)
- ARP(Address resolution protocol)
-
인터넷 프로토콜 버전 4 / 6 (
IPv4
/IPv6
) - TCP 또는 UDP와 같은 IP를 통한 모든 트래픽
MACsec은 APP-AES-128 알고리즘으로 기본적으로 LAN의 모든 트래픽을 암호화 및 인증하고 사전 공유 키를 사용하여 참가자 호스트 간의 연결을 설정합니다. 사전 공유 키를 변경하려면 MACsec을 사용하는 네트워크의 모든 호스트에서 NM 구성을 업데이트해야 합니다.
MACsec 연결은 이더넷 네트워크 카드, VLAN 또는 터널 장치와 같은 이더넷 장치를 상위로 사용합니다. MACsec 장치에서만 IP 구성을 설정하여 암호화된 연결만 사용하여 다른 호스트와 통신하거나 상위 장치에 IP 구성을 설정할 수도 있습니다. 후자의 경우 상위 장치를 사용하여 암호화되지 않은 연결 및 암호화된 연결에 MACsec 장치를 사용하여 다른 호스트와 통신할 수 있습니다.
MACsec은 특별한 하드웨어가 필요하지 않습니다. 예를 들어 호스트와 스위치 간에만 트래픽을 암호화하려는 경우를 제외하고 모든 스위치를 사용할 수 있습니다. 이 시나리오에서는 스위치가 MACsec도 지원해야 합니다.
즉, MACsec을 구성하는 두 가지 일반적인 방법이 있습니다.
- 호스트 및 호스트
- 호스트를 전환한 후 다른 호스트로 전환
동일한 (물리적 또는 가상) LAN에 있는 호스트 간에만 MACsec을 사용할 수 있습니다.
9.1. nmcli를 사용하여 MACsec 연결 구성
nmcli
유틸리티를 사용하여 MACsec을 사용하도록 이더넷 인터페이스를 구성할 수 있습니다. 예를 들어 이더넷을 통해 연결된 두 호스트 간에 MACsec 연결을 생성할 수 있습니다.
절차
MACsec을 구성하는 첫 번째 호스트에서 다음을 수행합니다.
사전 공유 키에 대해 CAK(연결 연결 키) 및 연결 연결 키 이름(CKN)을 만듭니다.
16바이트 16바이트 16진수 CAK를 생성합니다.
# dd if=/dev/urandom count=16 bs=1 2> /dev/null | hexdump -e '1/2 "%04x"' 50b71a8ef0bd5751ea76de6d6c98c03a
32바이트 16진수 CKN을 생성합니다.
# dd if=/dev/urandom count=32 bs=1 2> /dev/null | hexdump -e '1/2 "%04x"' f2b4297d39da7330910a74abc0449feb45b5c0b9fc23df1430e1898fcf1c4550
- MACsec 연결을 통해 연결하려는 두 호스트 모두에서 다음을 수행합니다.
MACsec 연결을 생성합니다.
# nmcli connection add type macsec con-name macsec0 ifname macsec0 connection.autoconnect yes macsec.parent enp1s0 macsec.mode psk macsec.mka-cak 50b71a8ef0bd5751ea76de6d6c98c03a macsec.mka-ckn f2b4297d39da7330910a7abc0449feb45b5c0b9fc23df1430e1898fcf1c4550
이전 단계에서 생성된 CAK 및 CKN을
macsec.mka-cak
및macsec.mka-ckn
매개변수의 사용합니다. MACsec 보호 네트워크의 모든 호스트에서 값이 동일해야 합니다.MACsec 연결에서 IP 설정을 구성합니다.
IPv4
설정을 구성합니다. 예를 들어 정적IPv4
주소, 네트워크 마스크, 기본 게이트웨이 및 DNS 서버를macsec0
연결로 설정하려면 다음을 입력합니다.# nmcli connection modify macsec0 ipv4.method manual ipv4.addresses '192.0.2.1/24' ipv4.gateway '192.0.2.254' ipv4.dns '192.0.2.253'
IPv6
설정을 구성합니다. 예를 들어 정적IPv6
주소, 네트워크 마스크, 기본 게이트웨이 및 DNS 서버를macsec0
연결로 설정하려면 다음을 입력합니다.# nmcli connection modify macsec0 ipv6.method manual ipv6.addresses '2001:db8:1::1/32' ipv6.gateway '2001:db8:1::fffe' ipv6.dns '2001:db8:1::fffd'
연결을 활성화합니다.
# nmcli connection up macsec0
검증
트래픽이 암호화되었는지 확인합니다.
# tcpdump -nn -i enp1s0
선택 사항: 암호화되지 않은 트래픽을 표시합니다.
# tcpdump -nn -i macsec0
MACsec 통계를 표시합니다.
# ip macsec show
각 유형의 보호 유형에 대한 개별 카운터 표시: 무결성 전용 (encrypt off) 및 암호화 (encrypt on)
# ip -s macsec show
9.2. 추가 리소스
10장. FlexVolume 서비스 보안
FlexVolume은 SMTP(SimpleTransport Transfer Protocol)를 사용하여 다른 MTA와 이메일 클라이언트 또는 전달 에이전트 간에 전자 메시지를 전달하는 MTA(메일 전송 에이전트)입니다. MTA는 서로 간의 트래픽을 암호화할 수 있지만 기본적으로 그렇게 하지 않을 수 있습니다. 또한 설정을 보다 안전한 값으로 변경하여 다양한 공격에 대한 위험을 완화할 수 있습니다.
10.1. FlexVolume 네트워크 관련 보안 위험 감소
공격자가 네트워크를 통해 시스템에 침입하는 위험을 줄이려면 가능한 한 많은 작업을 수행합니다.
NFS(Network File System) 공유 볼륨에서
/var/spool/ECDHE/
메일 스풀 디렉터리를 공유하지 마십시오. NFSv2 및 NFSv3에서는 사용자 및 그룹 ID에 대한 제어 권한을 유지 관리하지 않습니다. 따라서 두 개 이상의 사용자가 동일한 UID를 사용하면 서로의 이메일을 수신하고 읽을 수 있으며 이는 보안 위험입니다.참고ECDHE
RPC_GSS
커널 모듈에서 UID 기반 인증을 사용하지 않기 때문에 Kerberos를 사용하는 NFSv4에는 이 규칙이 적용되지 않습니다. 그러나 보안 위험을 줄이기 위해 NFS 공유 볼륨에 메일 스풀 디렉터리를 배치해서는 안 됩니다.-
DestinationRule 서버 악용 가능성을 줄이기 위해 메일 사용자는 이메일 프로그램을 사용하여 DestinationRule 서버에 액세스해야 합니다. 메일 서버의 쉘 계정을 허용하지 말고
/etc/passwd
파일의 모든 사용자 쉘을 /sbin/nologin으로
설정합니다(root
사용자를 제외할 수 있음). -
네트워크 공격으로부터 DestinationRule을 보호하려면 기본적으로 로컬 루프백 주소만 수신하도록 설정됩니다.
/etc/ECDHE/main.cf
파일에서inet_interfaces = localhost
행을 확인하여 이를 확인할 수 있습니다. 이렇게 하면 DestinationRule이 로컬 시스템의 메일 메시지(예:cron
작업 보고서)만 수락하고 네트워크에서는 허용되지 않습니다. 이 설정은 기본 설정이며 네트워크 공격으로부터 DestinationRule을 보호합니다. localhost 제한을 제거하고 DestinationRule이 모든 인터페이스에서 수신 대기하도록 허용하려면inet_interfaces
매개변수를/etc/ECDHE/main.cf
의all
으로 설정합니다.
10.2. DoS 공격 제한에 대한 DestinationRule 구성 옵션
공격자는 트래픽을 통해 서버를 플러드하거나 충돌을 유발하는 정보를 전송하여 서비스 거부(DoS) 공격을 유발할 수 있습니다. /etc/ECDHE/main.cf
파일에 제한을 설정하여 이러한 공격의 위험을 줄이도록 시스템을 구성할 수 있습니다. 기존 지시문의 값을 변경하거나 < directive> = <value > 형식으로 사용자 지정 값을 사용하여 새 지시문을 추가할 수 있습니다.
DoS 공격을 제한하려면 다음 지시문 목록을 사용합니다.
- smtpd_client_connection_rate_limit
-
이 지시문에서는 클라이언트가 시간 단위당 이 서비스에 수행할 수 있는 최대 연결 시도 횟수를 제한합니다. 기본값은
0
입니다. 즉, DestinationRule이 수락할 수 있는 만큼의 시간 단위를 클라이언트가 연결할 수 있습니다. 기본적으로 지시문은 신뢰할 수 있는 네트워크에서 클라이언트를 제외합니다. - anvil_rate_time_unit
-
이 지시문은 속도 제한을 계산하는 시간 단위입니다. 기본값은
60
초입니다. - smtpd_client_event_limit_exceptions
- 이 지시문에서는 클라이언트를 연결 및 속도 제한 명령에서 제외합니다. 기본적으로 지시문은 신뢰할 수 있는 네트워크에서 클라이언트를 제외합니다.
- smtpd_client_message_rate_limit
- 이 지시문은 시간 단위당 요청할 클라이언트의 메시지 전달 수를 정의합니다(Velocate에서 실제로 해당 메시지를 수락하는지 여부 관련 없이).
- default_process_limit
-
이 지시어는 지정된 서비스를 제공하는 기본 최대EE 하위 프로세스 수를 정의합니다.
master.cf
파일의 특정 서비스에 대해 이 규칙을 무시할 수 있습니다. 기본적으로 이 값은100
입니다. - queue_minfree
-
이 지시문에서는 대기열 파일 시스템에서 이메일을 수신하는 데 필요한 최소 여유 공간을 정의합니다. 현재 이 지시어는 mail을 전혀 수락할지 여부를 결정하는 데 현재 DestinationRule SMTP 서버에서 사용합니다. 기본적으로, 사용 가능한 공간이
message_size_limit
인 1.5배 미만이면 DestinationRule SMTP 서버는MAIL FROM
명령을 거부합니다. 더 높은 최소 여유 공간 제한을 지정하려면message_size_limit
의 1.5배 이상인queue_minfree
값을 지정합니다. 기본적으로queue_minfree
값은0
입니다. - header_size_limit
-
이 지시문은 메시지 헤더를 저장하기 위한 최대 메모리 양(바이트)을 정의합니다. 헤더가 크면 초과 헤더를 삭제합니다. 기본적으로 값은
102400
바이트입니다. - message_size_limit
-
이 지시문은 정보를 바이트 단위로 포함하여 메시지의 최대 크기를 정의합니다. 기본적으로 값은
10240000
바이트입니다.
10.3. SASL을 사용하도록 DestinationRule 구성
ECDHE는 Simple Authentication and Security Layer (ECDHEL) 기반 SMTP 인증(AUTH)을 지원합니다. SMTP AUTH는 간단한 mail Transfer Protocol의 확장입니다. 현재 DestinationRule SMTP 서버는 다음과 같은 방식으로 SASL 구현을 지원합니다.
- dovecot SASL
- DestinationRule SMTP 서버는 UNIX 도메인 소켓 또는 TCP 소켓을 사용하여 Dovecot SASL 구현과 통신할 수 있습니다. 개별 머신에서 DestinationRule 및 Dovecot 애플리케이션이 실행되는 경우 이 방법을 사용합니다.
- Cyrus SASL
- 활성화하면 SMTP 클라이언트는 서버와 클라이언트 모두에서 지원 및 수락하는 인증 방법을 사용하여 SMTP 서버로 인증해야 합니다.
사전 요구 사항
-
dovecot
패키지가 시스템에 설치되어 있습니다.
절차
Dovecot를 설정합니다.
/etc/dovecot/conf.d/10-master.conf
파일에 다음 행을 추가합니다.service auth { unix_listener /var/spool/postfix/private/auth { mode = 0660 user = postfix group = postfix } }
이전 예에서는 DestinationRule과 Dovecot 간의 통신에 UNIX-domain 소켓을 사용합니다. 이 예제에서는
/var/spool/ECDHE/ 디렉터리에 있는 메일 대기열과
사용자 및 그룹에서 실행되는 애플리케이션을 포함하는 기본 DestinationRule SMTP 서버 설정도 가정합니다.postfix
선택 사항: TCP를 통해 DestinationRule 인증 요청을 수신 대기하도록 Dovecot를 설정합니다.
service auth { inet_listener { port = port-number } }
/etc/dovecot/conf.d/10-auth.conf
파일에서auth_mechanisms
매개변수를 편집하여 이메일 클라이언트가 Dovecot로 인증하는 방법을 지정합니다.auth_mechanisms = plain login
auth_mechanisms
매개변수는 다양한 일반 텍스트 및 일반 텍스트 인증 방법을 지원합니다.
/etc/ECDHE/main.cf 파일을 수정하여ECDHE를 설정합니다.
DestinationRule SMTP 서버에서 SMTP 인증을 활성화합니다.
smtpd_sasl_auth_enable = yes
SMTP 인증에 대해 Dovecot SASL 구현을 활성화합니다.
smtpd_sasl_type = dovecot
DestinationRule 큐 디렉터리를 기준으로 인증 경로를 제공합니다. 상대 경로를 사용하면 DestinationRule 서버가
chroot
에서 실행되는지 여부에 관계없이 구성이 작동합니다.smtpd_sasl_path = private/auth
이 단계에서는 DestinationRule과 Dovecot 간의 통신에 UNIX 도메인 소켓을 사용합니다.
통신에 TCP 소켓을 사용하는 경우 다른 시스템에서 Dovecot를 찾도록 DestinationRule을 구성하려면 다음과 유사한 구성 값을 사용합니다.
smtpd_sasl_path = inet: ip-address : port-number
이전 예에서 ip-address 를 Dovecot 시스템의 IP 주소로 바꾸고 포트 번호를 Dovecot의
/etc/dovecot/conf.d/10-master.conf
파일에 지정된 포트 번호로 바꿉니다.DestinationRule SMTP 서버가 클라이언트에서 사용할 수 있도록 SASL 메커니즘을 지정합니다. 암호화 및 암호화되지 않은 세션에 대해 다양한 메커니즘을 지정할 수 있습니다.
smtpd_sasl_security_options = noanonymous, noplaintext smtpd_sasl_tls_security_options = noanonymous
이전 지시문에서는 암호화되지 않은 세션 동안 익명 인증이 허용되지 않으며 암호화되지 않은 사용자 이름 또는 암호를 전송하는 메커니즘이 허용되지 않도록 지정합니다. TLS를 사용하는 암호화된 세션의 경우 비익명 인증 메커니즘만 허용됩니다.