ClickCease KernelCare의 비하인드 스토리: 릴리스 전 패치 테스트 방법 - TuxCare

인기 뉴스레터 구독하기

4,500명 이상의 Linux 및 오픈소스 전문가와 함께하세요!

한 달에 두 번. 스팸이 없습니다.

KernelCare의 비하인드 스토리: 릴리스 전 패치 테스트 방법

2020년 10월 23일 TuxCare 홍보팀

KernelCare의 비하인드 스토리: 릴리스 전 패치 테스트 방법

테스트는 패치를 포함한 모든 소프트웨어 업데이트에 필수적이지만, 수익에 영향을 미치는 서비스를 구동하는 중요한 인프라를 변경하는 경우에는 더욱 중요합니다. 철저한 테스트를 거치지 않은 보안 업데이트를 배포하면 Kernel 충돌, 운영 체제 재부팅, 시스템 또는 서비스 수준 장애가 발생할 수 있으며, 이러한 후유증 중 일부는 중요하고 일부는 불쾌하지만 모두 비즈니스 및 서비스 수준 계약에 피해를 줄 수 있습니다. KernelCare는 모든 패치를 프로덕션에 배포하기 전에 엄격한 테스트 프로세스를 거치며, 이 문서에서는 패치 배포 후 고객 인프라의 안정성과 가동 시간을 보장하는 방법을 자세히 설명합니다.

 

콘텐츠:

  1. 패치 적용 지연은 위험합니다
  2. KernelCare 개발 및 테스트
  3. KernelCare의 네 가지 테스트 유형
  4. 결론

 

패치 적용 지연은 위험합니다

패치 적용 지연은 위험합니다

개발자가 보안 업데이트를 릴리스할 때 Linux Kernel을 포함한 모든 소프트웨어에 패치를 적용하는 것이 필수적입니다. 익스플로잇 코드와 함께 취약점이 공개되면 가능한 한 빨리 패치를 적용하는 것이 더욱 중요합니다. 서버에 패치가 적용되지 않은 상태로 오래 방치할수록 다음 대규모 데이터 유출 사고의 피해자가 될 위험이 커집니다. 관리자가 패치를 적용하기 전에 테스트를 하고 예정된 날짜를 기다리는 것은 드문 일이 아닙니다. 이 기간 내에 공격자가 서버를 스캔하여 취약점을 찾아 악용할 수 있습니다.

 

패치 관리를 KernelCare에 맡기면 관리자의 오버헤드가 많이 줄어들지만, 고객은 타사가 중요한 인프라에 배포하기 전에 적절한 테스트가 수행되었다는 확신을 가질 수 있어야 합니다. KernelCare의 패치 솔루션은 고객 서버에 배포하기 전에 엄격한 테스트를 거칩니다. 당사의 테스트는 대규모 조직의 관리 오버헤드를 상당 부분 줄여주므로 더 이상 버그 없는 깔끔한 패치 환경을 보장하기 위해 다양한 공급업체의 운영 체제가 설치된 여러 대의 머신이 필요하지 않습니다.

 

 

KernelCare 개발 및 테스트

KernelCare 개발 및 테스트

버그가 있는 코드는 새로운 취약성 도입을 비롯한 여러 문제를 일으킬 수 있습니다. 패치를 배포하기 전에 테스트하는 것이 왜 중요한지 보여주는 한 가지 예는 2020년 5월에 발견된 2020년 5월에 발견된 사소하게 악용될 수 있는 취약점. 패치의 이름은 Huawei Kernel 자체 보호 이라는 이름의 이 패치는 Linux Kernel에 일련의 보안 강화 옵션을 제공해야 했습니다. 하지만 이 패치는 운영 체제를 백도어 가능성에 개방하고, 위협 수준의 프로그래밍을 제공하지 않으며, Kernel 메모리를 공개할 수 있도록 허용했습니다. 이 패치는 테스트를 거쳤기 때문에 Linux 팀은 패치가 Kernel의 보안을 약화시키는 것을 막을 수 있었습니다. 이 사례는 패치를 설치하기 전에 테스트하는 것이 중요한 이유를 보여주는 한 가지 예이며, KernelCare는 클라이언트 서버에 배포하기 전에 여러 가지 유형의 테스트를 수행합니다.

 

고객이 팀에서 요구하는 높은 수준의 테스트에 대한 이해를 돕기 위해 아래에 프로세스를 자세히 설명했습니다.

 

  1. 대상 운영 체제가 설치된 베어메탈 물리적 서버 또는 가상 머신을 프로비저닝합니다. 특정 CVE(공통 취약점 노출)에 대한 패치가 특정 하드웨어 구성 요소(예: CPU 취약점)에 대한 패치인 경우, 해당 하드웨어 구성 요소를 서버에 프로비저닝합니다. Kernel 기반 가상 머신(KVM)의 경우, 중첩된 가상 머신과 필요한 하드웨어 기능을 프로비저닝합니다.
  2. 테스트에 사용할 Kernel을 공급업체로부터 가져와 프로비저닝된 테스트 서버에 설치합니다.
  3. 새로 설치된 Kernel로 서버를 재부팅합니다.
  4. 저희는 고객이 설치하는 것과 동일한 방식으로 KernelCare를 설치합니다. 지침을 게시합니다. 여기.
  5. KernelCare 패치 명령($ /usr/bin/kcarectl -update)을 실행합니다.
  6. 패치용으로 생성된 Kernel 모듈을 로드합니다.
  7. 모듈의 변경된 모든 기능을 검증하고 테스트합니다. 
  8. 익스플로잇 코드를 사용할 수 있는 경우 이 코드를 사용하여 서버에서 코드를 재현하고 패치로 취약점이 해결되는지 테스트합니다.
  9. 네 가지 테스트(아래 참조).
  10. 패치가 테스트를 통과하면 프로덕션에 배포합니다.
  11. 테스트에 실패하면 로그를 분석하여 실패 원인을 찾고 문제를 해결한 다음 패치가 테스트를 통과할 때까지 이 단계를 다시 반복합니다.

 

 

KernelCare의 네 가지 테스트 유형

KernelCare의 네 가지 테스트 유형

성공적인 배포를 위해서는 철저한 테스트가 중요하며, 버그로 인해 고객에게 영향을 받는다는 것을 잘 알고 있습니다. 각 Kernel에 대해 동시에 실행되는 네 가지 테스트를 통해 패치가 중요한 문제를 일으키지 않도록 합니다. 

 

패치를 배포하기 전에 프로덕션 환경에서 패치가 얼마나 빨리 필요한지, 취약점의 중요도에 따라 다음과 같은 자동화된 테스트를 거칩니다:

 

  1. 실행 중인 Kernel에 패치를 적용한 다음 패치를 해제하여 롤백을 테스트합니다. 이 프로세스는 Kernel당 약 10분 정도 소요됩니다.
  2. 패치를 적용한 다음 운영 체제에 약간의 부하를 추가하는 Linux 테스트 프로젝트(LTP) 테스트 스위트의 하위 테스트 집합을 수행합니다. 이 테스트는 Kernel당 약 15분 정도 소요됩니다.
  3. 2와 동일하지만 전체 LTP 테스트가 포함됩니다. 이 테스트는 Kernel당 4시간에 걸친 철저한 프로세스입니다:
    1. 파일 시스템 스트레스 테스트
    2. 스토리지 I/O 테스트
    3. 메모리 관리 스트레스 테스트
    4. IPC 스트레스 테스트
    5. 스케줄러 테스트
    6. 기능 검증 테스트 명령
    7. 시스템 호출 기능 검증 테스트
  4. LTP 추가. 이 테스트는 테스트 내내 지속적으로 패치를 적용하고 해제하는 고부하 테스트입니다. 이 테스트는 Kernel당 4시간이 소요됩니다.

 

결론

고객에게 안정적이고 신뢰할 수 있는 패치 서비스, 즉 서버에 패치가 있다는 사실조차 잊어버릴 수 있는 서비스를 제공하기 위해 영향을 받는 각 Kernel에 대해 Kernel당 최소 4시간 동안 패치를 테스트하고 운영에 지장을 주지 않는다고 100% 확신하는 경우에만 패치를 릴리스합니다. 와 KernelCare를 사용하면 관리자는 시스템을 재부팅할 필요 없이 패치를 적용할 수 있을 뿐만 아니라 패치를 설치하기 전에 철저한 테스트를 거쳤다는 사실도 알 수 있습니다.

Kernel 재부팅, 시스템 다운타임 또는 예정된 유지 보수 기간 없이 취약성 패치를 자동화하고 싶으신가요?

TuxCare로 라이브 패치에 대해 알아보기

TuxCare 게스트 작가 되기

시작하기

메일

가입

4,500

Linux & 오픈 소스
전문가!


뉴스레터 구독하기