이 게시물에서는 암호 블록 체인(Cipher Block Chaining, CBC)을 삭제하기 위해 Red Hat Enterprise Linux(RHEL) 8 암호화 정책을 구성하는 방법에 대한 예제를 살펴볼 것입니다. 하지만 그 전에 CBC에 관한 간략한 배경과 RHEL 8의 기본 암호화 정책부터 살펴보겠습니다.

운영 수준에서 우리 중 대부분은 시스템에 복잡한 구성이 있고 모든 것을 이해하기에는 정보가 너무 많거나 너무 적은 상황을 경험한 바 있습니다. 

예를 들어, "귀사의 서버는 더 이상 권장되지 않고 취약한 CBC 암호를 지원합니다"와 같은 문구를 보고 새로운 취약점으로부터 보호받고 있는지에 대한 질문과 함께 전체 자산에 걸쳐 일부 시스템이 영향을 받고 있는 경우 최대한 빨리 보고하고 해결해 달라는 요청을 보낸 적이 있나요? 

어떤 툴을 사용할 예정인가요? 어떤 점검을 할 예정인가요? 시스템을 올바르게 구성했나요? 서버에 알려진 취약점이 없나요?

다행히도 RHEL 8에서 사용할 수 있는 기술을 통해 이러한 질문에 대한 답을 얻어 운영 효율성을 높이고 암호화 정책 툴에 대한 신뢰도와 이해를 높일 수 있습니다. 

문제 분석

이제 한 걸음 뒤로 물러나서 이 Wikipedia 항목의 도움을 받아 당면한 문제를 분석해 보겠습니다. 

해당 항목에는 CBC가 블록 암호를 사용하는 여러 모드 중 하나이며, 현재 암호문 블록을 암호화하기 전에 이전 암호문 블록을 사용하여 XORing하는 모드라고 설명되어 있습니다. 또한 '가장 일반적으로 사용되는 운영 모드', 그리고 'Niels Ferguson과 Bruce Schneier가 권장하는 두 가지 블록 암호 모드 중 하나'라고 되어 있습니다. 

1976년에 개발되어서 오래되고 안전하지 않을 수 있다는 말도 덧붙였습니다. 그러나 오래되었다고 해서 필연적으로 안전하지 않은 것은 아닙니다. Diffie–Hellman 키 교환도 1976년에 시작되었지만 여전히 널리 사용되며 안전하지 않은 것으로 여겨지지 않습니다.

이러한 모든 정보는 당시 상황을 이해하는 데 실제로 도움이 되지는 않습니다. 이 조사는 OpenSSH 서버가 CBC 암호 모드를 사용할 용의가 있음을 알리는 자동화된 취약점 스캐너 경고로부터 시작되었을 가능성이 높으며, 그 이유로 CVE-2008-5161을 언급합니다. 어쩌면 이 문서나 다른 비슷하게 애매한 문서에 대한 또 다른 언급이 있었을 수도 있습니다. "따라서 인터랙티브 세션이 이 프로토콜 취약점을 사용하여 유용하게 공격을 받을 가능성은 매우 낮습니다. 공격자는 약 11,356번의 연결 중단 시도 후에 성공할 것으로 예상됩니다."와 같은 문장이 위로가 될 수는 있지만, 이것이 이 10년 묵은 보안 문제가 RHEL에서 해결되지 않았음을 의미하는 것일까요?

Security icon thumbnail

다행히 Red Hat은 제품에 존재하는 취약점을 선제적으로 모니터링하고 완화하기 위한 노력을 하고 있습니다. 실제로, 앞에서 언급한 CVE-2008-5161에 대한 NIST 페이지에는 RHEL 5에서 문제가 해결되었다는 Red Hat 공급업체의 설명이 눈에 잘 띄게 표시되어 있습니다. 또한 Red Hat은 sshd 구성에서 CBC 암호를 비활성화하는 해결 방법을 제공했습니다.

또한 해당 문서는 문제의 완화 방법이 업스트림 패치를 적용하여 공격을 성공적으로 수행할 확률을 더욱 낮추는 것임을 명시하고 있습니다. 취약점 스캐너는 이러한 정보를 알지 못합니다. 스캐너는 특정 패키지 버전이 있는지 확인하고 영향을 받는 알려진 버전과 매칭한 다음 결과를 보고합니다. 이러한 툴은 완벽하지 않으며 그러한 완화 방법이 있는지 감지할 수 없습니다. 

특정 알고리즘의 보안이 의심되는 경우 추가 조치를 취해 알고리즘을 비활성화할 수 있습니다. 이러한 변경 사항은 호환성 문제와 균형을 이루어야 합니다. 

이러한 CBC 암호는 이전 SSH 클라이언트 및 서버와의 상호운용성과 관련하여 사용할 수 있는 유일한 공통 언어일 수 있으며, 더 안전한 기본값과 호환성 간의 균형을 유지하는 것은 배포판 빌더의 책임입니다. 

예를 들어 Fedora 33은 이 병합 요청 업스트림에서 볼 수 있듯이 SSH에서 사용할 수 있도록 CBC 암호를 비활성화합니다. 1년 전에 릴리스된 엔터프라이즈 배포판인 RHEL 8은 이 1818103 – SSH 서버 CBC 모드 암호가 RHCOS에서 활성화됨 버그질라에서 볼 수 있듯이 완화 방법의 존재와 호환성 이유를 둘 다 언급하며 기본적으로 활성화된 상태로 유지하기로 결정했습니다.

균형 잡힌 기본값도 중요하지만 기본값은 변경할 수 있도록 되어 있습니다. 각 사용자의 상황은 고유하며 적절하다고 판단되는 결정을 내리는 것은 그들의 몫입니다. 이러한 요구 사항을 충족하기 위해 RHEL 8은 암호화 알고리즘 사용을 활성화/비활성화하는 새로운 중앙 집중식 메커니즘인 암호화 정책으로 전환했습니다. 이를 기회로 삼아 암호화 정책을 사용하여 CBC 암호를 비활성화하는 방법을 살펴보겠습니다.

RHEL 8 암호화 정책 관련 기능 및 구성

RHEL 8의 기본 정책을 보면 상황을 더 잘 이해할 수 있습니다.

sudo less /usr/share/crypto-policies/policies/DEFAULT.pol 
# A reasonable default for today's standards. It should provide
# 112-bit security with the exception of SHA1 signatures needed for DNSSec
# and other still prevalent legacy use of SHA1 signatures.

암호화 정책과 관련된 추가 보안 요구 사항에 맞게 RHEL 8에서 설정할 수 있는 다른 정책이 있습니다. 

  • FIPS.pol: 승인된 FIPS 알고리즘만 사용하는 정책입니다.

  • FUTURE.pol: 가까운 미래의 모든 공격을 견딜 수 있는 보수적인 수준의 보안을 제공하는 수준입니다. 

  • LEGACY.pol: 레거시 시스템과의 호환성을 극대화하기 위한 설정을 제공합니다.

하위 정책을 생성하여 이러한 정책을 수정하거나 처음부터 자체 정책을 생성할 수 있는 유연성도 있습니다. 이전에 update-crypto-policies 툴과 기능, 사용 방법에 대한 설명을 제공하는 Red Hat 블로그 포스트를 올렸습니다.

여기에 주제와 관련된 RHEL 8에 대한 중요한 추가 문서인 '시스템 전반 암호화 정책 사용 Red Hat Enterprise Linux 8(Using system-wide cryptographic policies Red Hat Enterprise Linux 8)'이 있습니다.

CBC를 삭제하도록 RHEL 8 암호화 정책을 구성하는 방법

초기 문제로 돌아와서, 감사자는 추가 증빙 사실을 제공하며 취약성 평가 툴이 다음과 같이 문제를 보고합니다. “Vulnerability Name: SSH CBC Mode Ciphers Enabled, Description: CBC Mode Ciphers are enabled on the SSH Server.”

온라인 댓글에서 볼 수 있듯이 구분해야 할 점이 있는데, 많은 사람들이 취약점 스캔을 통과한 후 문제를 해결하도록 시스템을 구성할 수 있습니다. 실제로는 CBC 관련 암호를 사용하지 않도록 sshd 프로세스를 구성하기 때문에 sshd에서 해당 암호를 사용할 수 없습니다. 이러한 유형의 해결 방법을 적용하는 방법에 대한 일부 지침도 있습니다. 

이는 전체 서버가 아닌 sshd 프로세스에만 해당합니다. 시스템 수준이 아닌 프로세스 수준에서 유효합니다. 즉, SSH CBC 모드에 대한 검사는 통과하지만 일부 CBC 암호는 여전히 서버에 남아 있습니다. 모범 사례는 시스템 수준에서 변경하는 것인데, update-crypto-policies 툴은 정확히 이 작업을 수행할 수 있습니다.

먼저 RHEL 8 서버에서 현재 사용 중인 암호화 정책을 확인할 수 있습니다.

update-crypto-policies --show 
DEFAULT

RHEL 8에서 DEFAULT 암호화 정책을 사용하고 있음을 확인했으므로 /usr/share/crypto-policies/policies/DEFAULT.pol에서 CBC 관련 암호를 찾아볼 수 있습니다.

tls_cipher = ... AES-256-CBC ...AES-128-CBC 
cipher = ... AES-256-CBC CAMELLIA-256-CBC AES-128-CBC CAMELLIA-128-CBC

(관련이 없는 암호는 명확성을 위해 삭제되었습니다.)

DEFAULT 정책에서 사용 중인 CBC와 관련된 6개의 암호가 있습니다.

여기서 상황이 복잡해집니다. 이 게시물을 작성하는 시점에는 추가 암호화 정책 설정 ssh_cipher의 예시를 보여주는 정책 파일이 없습니다. 이는 매뉴얼 페이지: 매뉴얼 암호화 정책에 언급되어 있습니다(... ssh_cipher: 선택 사항, SSH 프로토콜과 함께 사용하도록 허용된 대칭 암호화 알고리즘(모드 포함) 목록. 없는 경우 값은 cipher에서 파생됩니다...). 

해당 ssh_cipher가 존재하며 DEFAULT 정책에 명시적으로 표시되지 않지만 모든 CBC 관련 암호를 효과적으로 삭제하려면 하위 정책에서 명시적으로 제외해야 합니다.

사용 중인 DEFAULT 정책을 수정하는 하위 정책을 생성할 수 있습니다. 이 작업을 수행하려면 하위 정책 파일을 생성해야 합니다.

 /etc/crypto-policies/policies/modules/DISABLE-CBC.pmod

참고: 이름 지정 규칙이 중요합니다. 하위 정책 이름은 모두 대문자여야 하고 확장자 이름은 소문자로 된 .pmod여야 합니다.

해당 파일에는 DEFAULT 정책에서 수행하려는 수정 사항이 포함되어야 합니다.

DEFAULT 프로필을 수정하여 서버에서 CBC 암호를 삭제하려면 다음을 추가해야 합니다.

tls_cipher = -AES-256-CBC -AES-128-CBC 
cipher = -AES-128-CBC -AES-256-CBC -CAMELLIA-256-CBC -CAMELLIA-128-CBC
ssh_cipher = -AES-128-CBC -AES-256-CBC

sshd용 서버에서만 CBC 알고리즘을 삭제하려면 다음을 추가합니다.

ssh_cipher = -AES-128-CBC -AES-256-CBC

참고: ssh_cipher에 대한 예시가 없기 때문에 값이 다음과 같을 수 있다고 가정할 수 있습니다.

ssh_cipher = -AES-128-CBC -AES-256-CBC -CAMELLIA-256-CBC -CAMELLIA-128-CBC

실제로는 sshd에서 실제로 알리거나 사용하는 것으로 보이지 않으므로 -CamELLIA를 지정하지 않습니다. 참조: man sshd_config | grep -i cbc

                   3des-cbc                    
aes128-cbc
aes192-cbc
aes256-cbc )

ssh -vv를 사용하여 '해당 어포링'을 확인할 수 있듯이 3des-cbc는 RHEL 8.2 서버에서 광고되지 않습니다. aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes128-gcm@openssh.com,aes128-ctr).

CBC 암호를 제거하는 구성으로 하위 정책을 설정해야 합니다.

sudo update-crypto-policies --set DEFAULT:DISABLE-CBC

다음을 통해 정책이 올바르게 설정되었는지 확인할 수 있습니다. 

sudo update-crypto-policies --show  
DEFAULT:DISABLE-CBC

그런 다음 서버를 재부팅해야 정책 및 하위 정책이 적용됩니다.

이때 서버에서 사용 중인 CBC 암호가 없어야 합니다. 이를 쉽게 확인할 수 있는 한 가지 방법은 RHEL 8 서버에서 이 명령을 실행하여 sshd로 실제로 확인하는 것입니다.

ssh -vv -oCiphers=aes128-cbc,aes256-cbc 127.0.0.1 

로그인 정보가 표시되어야 하며 사용자가 유효한 자격 증명을 사용하여 연결할 수 있어야 합니다.

sshd에 대한 CBC 암호가 없는 경우 다음과 같이 표시되어야 합니다.

Unable to negotiate with 127.0.0.1 port 22: no matching cipher found. 

그러면 sshd 프로세스는 다음과 같이 해당 서버에서 제공하는 암호를 표시합니다. “Their offer: aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes128-gcm@openssh.com,aes128-ctr”

요약

이 블로그에서는 지정된 암호화 정책 요구 사항을 준수하도록 RHEL 8 서버를 구성하는 방법을 살펴보았습니다. 보안 우려 사항을 검증한 후 서버에서 CBC 관련 암호를 삭제하는 방법을 보여주었습니다. update-crypto-policies와 같은 툴을 사용하여 개별 구성 요소 수준에서 작업해야 하는 대신 서버 수준에서 적절한 방식으로 일부 보안 컴플라이언스 요구 사항을 충족했습니다.


저자 소개

Jean-Sébastien Tougne has more than 14 years of experience as an engineer in DTV, Oil and Gas, Computer Systems and Finance industries. He is currently a Red Hat consultant.

UI_Icon-Red_Hat-Close-A-Black-RGB

채널별 검색

automation icon

오토메이션

기술, 팀, 인프라를 위한 IT 자동화 최신 동향

AI icon

인공지능

고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트

open hybrid cloud icon

오픈 하이브리드 클라우드

하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요

security icon

보안

환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보

edge icon

엣지 컴퓨팅

엣지에서의 운영을 단순화하는 플랫폼 업데이트

Infrastructure icon

인프라

세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보

application development icon

애플리케이션

복잡한 애플리케이션에 대한 솔루션 더 보기

Virtualization icon

가상화

온프레미스와 클라우드 환경에서 워크로드를 유연하게 운영하기 위한 엔터프라이즈 가상화의 미래