By Mark 보안 업계에는 오래된 격언이 하나 있습니다. “도둑을 잡으려면 도둑처럼 생각하라.”
15년 전, 제가 OS 개발팀에 합류해 커널(Kernel)의 깊은 곳을 헤매고 있을 때, 이 말은 단순한 격언이 아니라 생존을 위한 유일한 기술이었습니다. 시스템의 신(God)이라 불리는 root 권한조차 막아내는 강력한 OS 접근제어 제품을 개발해야 했을 때, 저는 아이러니하게도 가장 악질적인 악성코드인 루트킷(Rootkit)에서 그 해답을 찾았습니다.
오늘은 공격자의 기술을 수비의 핵심으로 뒤바꾸어 성공적인 보안 제품을 만들어낸 경험과, 이 원칙이 2025년 현재의 보안 트렌드에서 어떻게 진화하고 있는지에 대해 이야기하려 합니다.
1. 절대 권력 root의 딜레마와 한계
당시 제가 맡은 미션은 명확하면서도 모순적이었습니다. “OS 레벨의 강력한 접근제어(Access Control) 시스템을 만들 것. 단, 슈퍼유저(Superuser)인 root조차 뚫을 수 없어야 한다.”
리눅스나 유닉스 시스템에서 root 계정은 전지전능합니다. 모든 파일을 읽고, 쓰고, 지울 수 있으며, 프로세스를 강제로 종료할 수 있는 생살여탈권을 쥐고 있습니다. 하지만 기업의 보안 환경에서는 이 root조차 통제의 대상이 되어야 했습니다. 관리자 계정이 탈취되더라도 기밀 데이터는 삭제되거나 유출되지 않아야 했기 때문입니다.
표준 개발 지식의 벽
처음에는 OS 개발의 정석(Standard)대로 접근했습니다.
- 리눅스 커널의 표준 파일 시스템 접근 권한(Permission) 체계
- 일반적인 접근 제어 리스트(ACL)
하지만 곧 벽에 부딪혔습니다. “정상적인 방법으로 OS를 개발하는 지식만으로는, 권한을 가진 자의 비정상적인 행위를 막을 수 없다”는 사실이었습니다. root 권한을 가진 사용자는 표준적인 제어 장치를 우회할 수 있는 수만 가지 방법을 알고 있습니다. 제가 문을 잠그면, 그들은 열쇠를 복사하거나 벽을 허물고 들어올 것이 뻔했습니다.
2. 흑마법을 백마법으로: 루트킷(Rootkit) 분석의 충격
방패를 더 단단하게 만들기 위해, 저는 ‘창’을 연구하기로 결심했습니다. 당시 시스템 깊숙이 침투해 자신을 숨기고 무소불위의 권한을 휘두르던 루트킷(Rootkit)의 소스 코드를 닥치는 대로 수집해 분석하기 시작했습니다.
그들의 코드는 소름 끼치도록 효율적이었습니다. 정상적인 OS 개발자들이 “하지 말아야 할 짓”이라고 규정한 영역을 그들은 자유자재로 넘나들고 있었습니다.
시스템 콜 후킹 (System Call Hooking)
루트킷은 운영체제가 사용자 요청을 처리하는 가장 핵심적인 관문인 시스템 콜 테이블(System Call Table)을 조작했습니다.
- 공격자의 논리: 관리자가
ls명령어로 파일 목록을 조회하려 할 때, 커널이 파일 시스템을 읽기 직전에 요청을 가로챕니다. 그리고 자신의 악성 파일 이름만 쏙 빼고 결과를 보여줍니다. 이것이 그들의 ‘은폐(Hiding)’ 기술이었습니다.
커널 구조체 조작 (DKOM)
또한, 직접 커널 메모리 상의 프로세스 구조체를 수정하여(DKOM: Direct Kernel Object Manipulation), 특정 프로세스의 권한을 root로 강제 상향하거나, 실행 중인 악성 프로세스를 작업 관리자 목록에서 지워버렸습니다.
저는 무릎을 쳤습니다. “이 기술을 거꾸로 뒤집으면 최고의 방패가 된다.”
3. 공격 기술로 완성한 철벽 방어 시스템
루트킷 분석을 통해 얻은 ‘공격의 메커니즘’을 방어 제품 개발에 그대로 적용했습니다.
VFS(Virtual File System) 계층 방어
루트킷이 자신을 숨기기 위해 시스템 콜을 가로채는 기술을 역이용하여, 중요 파일을 보호하는 로직을 짰습니다. sys_unlink (파일 삭제), sys_open (파일 열기) 같은 핵심 시스템 콜이 호출될 때, 커널 레벨에서 먼저 개입하여 접근 정책을 검사하도록 만들었습니다.
- Before:
root가 삭제 요청 -> 커널이 권한 확인(Pass) -> 파일 삭제 - After:
root가 삭제 요청 -> 보안 모듈이 가로챔(Hooking) -> 정책 확인(접근 불가 설정됨) -> “Permission Denied” 강제 리턴
PAM(Pluggable Authentication Modules)의 재해석
단순한 파일 보호를 넘어, 사용자 인증 단계인 PAM에도 이 로직을 결합했습니다. 정상적인 경로를 통하지 않은 인증 시도를 원천 차단하고, 권한 상승 시도 자체를 커널 레벨에서 모니터링했습니다.
결과는 성공적이었습니다. root 계정으로 로그인한 상태에서 rm -rf /important_data 명령어를 날려도, 시스템은 묵묵부답으로 방어해냈습니다. 공격 기술을 이해하지 못했다면 결코 구현할 수 없었던, 지금의 SELinux(Security-Enhanced Linux)와 유사한 강력한 강제 접근 제어(MAC) 시스템이 완성된 순간이었습니다.
4. 2025년의 시선: eBPF와 제로 트러스트로의 진화
15년이 지난 2025년, 보안 기술은 어떻게 변했을까요? 흥미롭게도 제가 과거에 루트킷을 분석하며 적용했던 원리는 현대 기술의 핵심 철학으로 계승되었습니다.
커널 모듈에서 eBPF로의 전환
과거에는 시스템 콜을 후킹하기 위해 커널 모듈(LKM)을 직접 수정하는 위험한 방식을 썼지만, 2025년 현재는 eBPF(Extended Berkeley Packet Filter)가 그 자리를 대체하고 있습니다. eBPF는 커널 소스 코드를 수정하거나 시스템을 재부팅하지 않고도, 샌드박스 환경에서 안전하게 커널 기능을 확장하고 관찰할 수 있게 해줍니다. 현대의 보안 솔루션들은 과거의 루트킷처럼 무겁게 커널을 건드리지 않으면서도, eBPF를 통해 시스템 콜을 감시하고 비정상 행위를 차단합니다. 기술의 구현 방식은 안전해졌지만, “커널의 흐름을 가로채 검사한다”는 본질은 변하지 않았습니다.
제로 트러스트(Zero Trust)의 실현
“Root 권한도 믿지 않는다”는 당시의 설계 철학은 현재 제로 트러스트(Zero Trust) 보안 모델의 핵심이 되었습니다. 2025년의 클라우드 네이티브 환경에서는 내부망이나 관리자 권한을 맹신하지 않습니다. 모든 접근은 매 순간 검증되어야 하며, 권한은 최소한으로 부여됩니다.
마치며: 방패를 깎는 자의 자세
OS 개발자로서, 그리고 보안 제품 개발자로서 얻은 교훈은 명확합니다. OS를 만드는 지식(Constructive Knowledge)과 **OS를 뚫는 지식(Destructive Knowledge)은 동전의 양면과 같습니다.
안전한 시스템을 만들고 싶으신가요? 그렇다면 “어떻게 안전하게 만들까”를 고민하기에 앞서, “어떻게 부술 수 있을까”를 먼저 공부하십시오. 루트킷이 어떻게 숨는지 알아야 숨겨진 것을 찾을 수 있고, 해커가 어떻게 권한을 훔치는지 알아야 그 손을 잡을 수 있습니다.
15년 전, 루트킷을 분석하던 그 밤들이 없었다면 제 방패는 종잇장처럼 뚫렸을 것입니다. 진짜 수비는 공격을 이해하는 것에서 시작됩니다.