회고
12월 마지막 주가 되었다. 항상 연말만 되면 무언가 끝났다라는 생각에 시원섭섭한 감정을 많이 느끼곤 했는데 올해는 정말 별 생각이 없는거 같았다. 사실 부트캠프가 끝난게 아니어서 그런가 당장 프로젝트 진행으로 굉장히 정신이 없기 때문에.. 크리스마스고 연말이고ㅋㅋㅋ 별 생각이 없다..
그리고 프로젝트 기간인데 2주 연속으로 수요일까지만 나가고 연휴여서 좀 나태해지지 않을까 걱정이 됐다. 일단 나부터.. 다들 성인인데 각자 할거 잘하겠지 했다. 역시 걱정이 무색하게 돌아와서 회의 해보니 다들 각자 맡은 부분 잘해와서ㅎㅎ 괜히 흐뭇했다.
이번주는 지난 포스트에서도 살짝 얘기한거처럼 나는 Tetragon 정책 설계를 맡아서 정책 설계를 어떻게 하고 있고, 수행과정에서 어떤 어려움이 있었는지 정리 해보도록 하겠다.
Tetragon이란?
Tetragon은 Cilium 프로젝트로 eBPF 기반의 보안 관측(Observability) 및 실시간 가동 중지(Runtime Enforcement) 도구이다. K8S 환경에서 시스템 내부의 동작을 user 레벨부터 커널 레벨까지 들여다보고, 위협이 발견되면 즉시 차단할 수 있는 강력한 기능을 제공한다.
Tetragon은 eBPF(extended Berkeley Packet Filter) 기술을 사용하여 운영체제의 커널 내부에서 이벤트를 직접 필터링하기 때문에 Context Switching에 의한 Overhead가 매우 적고, 프로세스 실행, 파일 접근, 네트워크 연결 등을 커널 수준에서 추적이 가능하다.
Context Switching?
하나의 프로세스가 컴퓨팅 리소스를 사용하고 있는 상태에서 다른 프로세스가 컴퓨팅 리소스를 사용하도록 하기 위해, 이전의 프로세스의 상태를 저장하고 새로운 프로세스를 실행하게 하는 작업을 의미한다.
기존 eBPF 기반 탐지 도구와 가장 큰 차이점은 집행(enforcement)이 가능하다는 점이다. 여기서 집행은 악의적인 프로세스를 강제 종료 시키거나 반환값을 조작하는 행위를 의미한다.
우리는 왜 Tetragon을 선택했을까?
우리팀은 프로젝트 수행을 위해 Tetragon 외에도 Falco, Tracee, KubeArmor 등 다양한 eBPF 기반 탐지 도구를 비교 실험한 결과 집행 기능을 가지고 있고, 탐지 포인트 설정의 유연성, 프로세스 계보 추적에 장점을 가지고 있는 Tetragon을 최종적으로 선택하게 됐다.
Tetragon이 지원하는 주요 기능은 다음과 같다.
- 프로세스 실행 추적 (Process Execution)
어떤 프로세스가 어떤 인자(Arguments)를 가지고 실행되었는지, 부모-자식 관계는 어떻게 되는지 상세히 기록한다. - 파일 시스템 모니터링 (File Access)
민감한 설정 파일(/etc/shadow 등)에 대한 읽기/쓰기 시도를 탐지한다. - 네트워크 가시성 (Network Observability)
소켓 생성, TCP 연결 상태, DNS 쿼리 등을 프로세스 정보와 결합하여 보여준다. - 런타임 강제 집행 (Runtime Enforcement)
허용되지 않은 시스템 콜(System Call)이 발생하면 프로세스를 즉시 차단한다.
system call, LSM(Linux Security Module) function 등 다양한 Hook Point 설정을 통해 위와 같은 기능을 제공한다.
미리 양해를 구해보자면..
아직 프로젝트가 종료하지 않았고, 고도화 작업이 한창이기 때문에 자세한 내용을 이 블로그에 작성하지 못 합니다.
나름 팀 내부 기밀사항(?)이기에..ㅎ 프로젝트 끝나고 프로젝트 리뷰를 진행할 때 하나씩 세세하게 짚어 보도록 하겠습니다!
정책 설계를 한다는 것의 의미
"정책 설계"는 시스템에서 일어나는 수만 가지 행위 중 '특정한 행동'을 감시하고 대응할지 선언하는 것이다.
예를 들어 마트에 가서 물건을 산다고 하자. 구매할 물건을 골라 매대에 올려놓는 행위는 시스템 내부의 특정 동작(ex. 파일 열기, 네트워크 연결 등)이다.
이때 우리가 "매대에 특정 물건(예: 위험물)이 올라오면 반드시 바코드를 찍고, 점원에게 알려라"라고 규칙을 정해두는 것이 바로 정책 설계입니다.
여기서 '매대'는 어디를 감시할 것인가?를 의미하고 이를 Hook Point라고 한다. 또, '바코드를 찍는 것'은 탐지(Detection), 그리고 만약 위험물일 때 판매를 거부하는 것은 차단(Enforcement)이다. 즉, 정책 설계란 목적을 가지고 감시할 대상과 대응 방식을 정의하는 과정을 말한다.
MITRE ATT&CK Matrix 활용
우리는 K8S 환경에서 프로젝트를 수행하기 때문에 컨테이너 대상 위협들을 탐지하는 정책을 설계해야한다. 따라서 MITRE ATT&CK Container 환경 대상 공격들을 테크닉 기준으로 세 파트로 나누어 정책 설계중에 있다. 그 중 나는 Inintial Access (TA0001), Execution (TA0002), Persistence(TA0003)을 맡아 Tetragon 정책을 설계하고 있다.
우선 이 메트릭스에 맞춰 탐지 정책을 1차로 세우고, 세운 정책에서 공통되는 부분을 뽑아내 정책을 재설계하여 정책의 관리적, 성능적 측면에서 고도화를 이룰 계획이다.
Reference의 중요성
정책 설계하면서 가장 크게 느낀건 레퍼런스의 부재다. 못 찾은거 아니냐고 할 수 있겠지만 진짜 믿고 볼게 공식 문서 하나라고 생각하면 된다. 아직 활발하게 사용되고 있는 Tool이 아니기에... 그냥 머리를 박는다는 표현이 맞다.
한 가지 희망적인건(?) Tetragon이 요즘 정말 핫한 도구라고 한다. 이 프로젝트를 통해 Tetragon 정책을 설계할 수 있는 능력을 갖춘다면? 하나의 경쟁력을 갖추게 되는 포인트가 되지 않을까..
정책 설계시 어려움과 했던 생각들
가장 먼저 어려움이 있었던 것들은 각 공격에 맞는 Hook Point와 함수 선정이었던거 같다. 예를 들어 리버스 쉘 공격을 탐지하는 공격을 탐지하겠다라고 하면 네트워크를 볼 수도 있고, 쉘이 떨어지고 난 이후 행위를 볼 수도 있을 것이다. 결론부터 말하면 둘 다 봐야하는데, 네트워크 연결을 보겠다고 하면 연결 수립할 때 call 되는 함수인 tcp_connect 함수를 사용할 수도 있고 소켓 바인딩 과정을 보겠다?라고 하면 inet_bind라는 함수를 사용할 수도 있고, sk_alloc 등 같은 네트워크라고 해도 정말 많은 함수들이 존재한다. 또, 함수의 어떤 인자값을 선택해서 탐지를 할 것인가도 정해야 하니 첩첩산중...이라는 표현이 맞는거 같다.
정책은 yaml파일로 작성하는데 얘가 진짜 민감한 친구라 뭐가 조금만 달라져도 바로 에러뜨고 동작 안한다. 여기서 또 문제가 kubectl apply 명령으로 정책을 적용하고 완료됐다라는 메세지가 떠도 Kernel 함수 로드되는걸 또 지켜보고 있어야 한다. 적용이 완료됐다고 떠도 커널에 로드될 때 에러나는 경우가 굉장히 많기 때문에 ... 처음에 이걸 몰랐어서 엄청 헤맸다.
RCE(Remote Command Execution)은 하나의 명령으로 공격을 수행해도 여러 가지 이벤트가 발생할 수 있다. 즉, 이 말은 여러 탐지 정책에 걸릴 수 있다는건데 문제는 정말 이게 공격 행위에 의해 남는 것인지 아니면 정책의 범위를 잘못 설정해서 오탐이 된건지 이를 어떻게 검증해야 하지?라는 생각이 들었다.
이거만 제대로 검증이 되면 여러 정책에 의해 탐지되는 것을 로그 분석시에 하나의 지표로서 활용할 수 있겠다라는 생각을 했다.
이와 관련해서 멘토님께 여쭤보니 "동일 이벤트에 대해 임계치 기반이 있을수 있고 말씀주신것 처럼 횟수를 활용하는 방안도 괜찮아보여요. 동일 컨테이너나 엔드포인트에서 동일 이벤트가 동시에 다수 발생한다? 이런 가정은 공격으로 간주하고 봐야겠죠 노이즈 보다는. "라고 하셨고 "상관 분석(Correlation) 단계에서 우선순위(priority) 및 가중치(scoring) 설정을 통해 하나의 통합 이벤트로 묶어서 보여주는 로직이 필요하다"는 피드백을 받았다.
우선 상관분석 단계까진 아직 가지 못했기 때문에 수행하는 과정에서 다시 질문 드리겠다고 했다🤯.
마무리
사실 TIL에 모든 내용을 정말 세세하게 녹여 작성하고 싶지만 앞서 말했듯이 아무래도 프로젝트고 마무리가 되지 않았기 때문에 입이 근질거리지만ㅋㅋㅋㅋ 참아야겠다..
어떻게 보면 우리 팀 프로젝트의 핵심적인 부분이기에 이런 공개된 공간에 내용을 전부 작성한다는거 자체가 되게 조심스럽다.
아직 작업이 마무리 되지 않았고, 사실 정책 설계하면서 이걸 내가 제대로 이해하면서 하고 있는건지 의심이 드는 순간이 오지만 있는 자료들을 최대한 활용해서... 최선을 다 하고 있다.
요즘 느끼는건데 시간이 지날수록 팀원들이 많이 지쳐 가는게 눈에 보인다. 다른 팀들도 마찬가지겠지만? 팀빌딩이 된 순간부터 지금까지 정말 쉴틈없이 달려오고 있고 벌려 놓은 일들을 하나씩 퀘스트 깨듯이 수행하고 있으니 어쩌면 당연한걸지도..? 컨디션이 안좋아보이는 팀원들도 있는데 참고 묵묵히 수행 해줘서 뭔가 팀장으로서 미안하면서 고마움을 많이 느끼는거 같다.
나도 사람인지라 지치고 막막한 순간들이 찾아오는데 팀원들 보면서 버티는거 같다. 나한테는 조금 특별히..? 부트캠프 시작부터 많은 시간을 보낸 희수랑 민송이가 우리 팀에 있어서 더 힘이 나는거 같다.
희수는 항상 냉정함을 유지 해줄 수 있는 친구라 팀 분위기가 조금 들뜨거나 침울해져도 냉정함을 갖고 정상 궤도에 오를 수 있도록 많이 도와주고 민송이는 팀 분위기가 쳐져 있을 때 많은 힘이 되어 주는 친구다. 좀.. 둥가둥가를 잘한다..?라고 해야하나 암튼ㅋㅋㅋㅋㅋ 이 둘이 있어서 힘을 많이 얻는다~
이번주에 오픈서치 대시보드에 탐지된 로그를 띄울 때 필터링 하는 부분에 있어서 변화가 있어서 정책 설계하는 부분에서도 수정이 필요할거 같다. 이 작업은 수행 완료하는대로 또 정리해서 다음주 TIL에 반영해서 써볼 생각이다.
이번주 TIL은 여기서 마치도록 하겠다. 다들 새해 복 많이 받으세요. 이번주도 고생 많으셨습니다!
