IoT 환경의 민감 정보 보호를 위한 자동화된 eBPF 기반 화이트리스트 시스템 설계 및 구현

Design and Implementation of an Automated eBPF-Based Whitelist Security Mechanism for Protecting Sensitive Data in IoT Environments

Abstract

IoT 기기의 활용 증가와 함께 데이터 탈취·악성코드 주입 등 비인가 행위가 확대되고 있다. 그러나 IoT 기기는 기능과 동작 범위가 고정되어 있으며 자원이 제한적인 특성이 있다. 따라서 높은 연산 비용과 지속적 업데이트가 필요한 시그니처 기반 기법이나 사용자 개입을 전제로 한 기존 화이트리스트 방식은 IoT 기기에 적합하지 않다. 또한 물리적으로 노출되기 쉬운 IoT 환경에서는 정책 변조 가능성을 최소화하기 위해 자동화된 정책 적용 구조가 요구된다. 이에 본 논문은 이러한 IoT 특성을 고려한 eBPF 기반 자동화 화이트리스트 기법을 제안한다. 제안 시스템은 개발 단계에서 정상 동작을 스냅샷으로 수집해 정책을 자동 생성하고, 운영 단계에서는 에이전트를 통해 정책을 커널에 적재하여 변조를 방지하고 비인가 실행 및 네트워크 연결을 실시간으로 차단한다. 해당 설계의 유효성과 성능 오버헤드를 실험을 통해 평가하였으며, 이를 통해 제안 기법이 IoT 환경에 적용 가능함을 보였다.

As IoT devices become more widely deployed, unauthorized activities such as data exfiltration and malware injection are increasing. However, their fixed functionality, limited resources, and physical exposure make traditional signature-based and user-dependent whitelist methods unsuitable. This paper proposes an eBPF-based automated whitelisting system that generates policies from normal behavior during development and enforces them in the kernel during operation. Experimental results demonstrate that the proposed approach effectively prevents unauthorized executions and network connections with low overhead, making it suitable for IoT environments.

I. 서론

IoT(Internet of Things) 시스템은 하드웨어와 이를 제어하는 소프트웨어로 구성되며, 특정 기능을 반복 수행하는 특징이 있다[1]. 최근 IoT 기기의 성능 향상으로 금융, 헬스 케어, 산업 제어 등 민감 정보를 다루는 분야에 널리 활용되고 있다[2]. 이에 따라 정보 탈취, 권한 상승, 악성코드 주입과 같은 IoT 기기 대상의 민감 정보 탈취를 목적으로 한 비인가된 행위가 증가하고 있다[3]. IoT 시스템은 일반적으로 개발, 배포, 운영 단계로 구성된 생명 주기를 갖고 있으며[4], 이러한 구조적 특성을 반영한 IoT 환경에 특화된 보안 기법의 필요성이 부각되고 있다.

기존 보안 기법으로는 침입 탐지·방지 시스템과 같은 시그니처 기반 탐지 기법이 제안되어 왔으나, 새로운 변종 공격이나 Zero-Day 공격에 대응이 어렵고 높은 자원을 소모한다[5]. 따라서 IoT 환경에서는 시스템에 허용된 동작만을 수행하도록 제한하는 화이트리스트 기반 보안 기법이 주로 사용된다.

대표적인 IoT 환경의 화이트리스트 연구로 White-Egret[6]이 있다. WhiteEgret은 LSM (Linux Security Module) 기반으로 커널 수준에서 실행 제어를 수행함으로써 강력한 보안을 제공한다. 하지만 LSM 활성화를 위해 커널 수정 및 재빌드가 요구되어, 이미 배포된 IoT 기기에 적용하기 어렵다. 또한 정책을 관리자가 수동 생성해야 하며 정책이 사용자 공간에 위치하고 커널 모듈이 이를 참조하기 때문에 정책이 사용자 공간에서 변조되어 적용될 위험이 있다.

다른 화이트리스트 연구인 OpenSnitch[7]는 애플리케이션 레벨의 네트워크 방화벽으로, eBPF(extended Berkeley Packet Filter)[8]를 활용하여 네트워크 연결을 모니터링하고 사용자가 직접 허용 및 차단 여부를 선택할 수 있도록 한다. eBPF는 기본적으로 커널 소스 코드 수정이나 재컴파일(recompile) 없이도 커널에 프로그램을 동적으로 로드하고 업데이트할 수 있다. OpenSnitch는 데스크탑이나 워크스테이션과 같은 일반 리눅스 시스템을 대상으로 하고 있어, 연결이 시도되는 네트워크에 대해 사용자가 정책 허용 여부를 결정하는 방식을 사용한다. 이 방법은 다양한 사용 패턴을 갖는 환경에서는 필요에 따라 정책을 설정할 수 있는 장점이 있다. 하지만 OpenSnitch를 IoT 기기에 적용할 경우 공격자가 IoT 기기를 확보한 후 정책을 허용하면 IoT 기기에 공격자가 요구하는 네트워크를 허용할 수 있다. 또한 IoT 기기는 출고 단계에서 모든 프로세스와 네트워크 사용 범위가 결정되고, 운영 중 이러한 동작이 변경되는 경우는 드물다[9]. 이러한 특성 때문에 보안 연구에서는 개발 단계에서 정상 동작을 기반으로 허용 목록(whitelist)을 생성하고, 운영 단계에서는 허용 목록에 없는 프로세스·네트워크 행위를 차단하는 정적 정책 모델이 적합한 방식으로 제안된다. 특히 물리적으로 노출되기 쉬운 IoT 기기에서는 공격자가 정책을 임의로 변경할 가능성을 줄이기 위해 사용자 개입 없이 자동 적용되는 화이트리스트 구조가 더 안전하다.

기존 화이트리스트 보안 기법들은 각기 장점을 갖고 있으나, 커널의 재컴파일을 요구하거나 사용자 개입 의존성과 같은 구조적 한계를 지닌다. 특히 IoT 기기의 자원 제약, 고정된 동작 특성, 물리적 노출 가능성을 충분히 고려하지 못해 실제 IoT 환경에서의 적용성이 떨어진다. 이러한 제약으로 인해 기존 방식만으로는 IoT 기기에서 안정적이고 자동화된 실행·통신 제어를 수행하기 어렵다.

본 논문에서는 IoT 시스템 환경을 대상으로 하는 자동화된 화이트리스트 보안 기법을 제안한다. 제안하는 시스템은 IoT 생명 주기[4] 중 개발과 운영 단계를 대상으로 보안 기법을 설계하고 구현하였다. 본 연구는 물리적으로 노출되기 쉬운 IoT 기기의 특성을 고려하여 사용자의 개입이 최소화된 자동 정책 적용 구조를 설계하였다. 또한 다양한 IoT 기기에 적용 가능하고, 저전력으로 설계되는 IoT의 특성을 반영하여 경량성을 제공하는 eBPF를 사용하여 모니터링 및 차단을 수행한다. 이로써 개발 단계에서 정책이 자동 생성되고, 운영 단계에서는 생성된 정책을 기반으로 비인가 행위가 자동으로 차단되는 eBPF 기반의 화이트리스트 보호 기법을 제안한다.

제안하는 시스템은 스냅샷(snapshot)과 에이전트(agent)로 구성된다. 스냅샷은 정상 동작 환경을 모니터링하여 프로세스 및 통신 행위를 수집하고 이를 정책 파일로 자동 생성하여 사용자의 개입 없이도 정책 생성을 가능하게 한다. 에이전트는 스냅샷에서 생성된 정책 파일을 eBPF 맵(map)[10]에 적재한다. 커널 내부에서 생성되는 자료구조인 eBPF 맵에 정책을 삽입함으로써 사용자 공간에서 발생하는 비인가 행위로부터 정책을 보호한다. 이후 사용자 상호작용 없이 소프트웨어의 실행 및 네트워크 연결을 실시간으로 감시하고 비인가 행위를 차단한다.

본 논문의 구성은 다음과 같다. 2장에서 IoT 시스템의 기존 보안 기법 연구와 한계를 분석하고, 3장에서는 제안한 eBPF 기반 화이트리스트 시스템 설계 내용을 기술한다. 4장에서는 제안된 기법의 기능을 실험하여 결과를 보이고, 마지막으로 5장에서는 결론과 향후 연구 방향을 제시한다.

II. 관련 연구

본 장에서는 제안하는 시스템에서 사용하는 eBPF기술과 기존 IoT 환경에서의 화이트리스트 기반 보안 연구의 장점과 한계점을 살펴본다.

2.1 extended Berkeley Packet Filter

eBPF[8]는 리눅스 커널 3.18 이후 확장된 BPF로, 커널 코드를 수정하거나 모듈을 추가할 필요 없이 프로그램을 OS 커널 공간에서 실행할 수 있는 기술이다. 커널이 BTF(BPF Type Format) 기능을 지원할 경우 CO-RE(Compile Once–Run Everywhere) 기법을 통해 다양한 환경에서 정책 변경과 배포를 더욱 유연하게 수행할 수 있다[11]. 또한 경량화를 목적으로 개발되어 안전한 가상 머신 실행 환경을 제공하고, JIT 컴파일러를 통해 성능 최적화되어 실시간 모니터링 및 제어에 적합하다. eBPF는 주로 리눅스 커널 내부에서 사용되는 기술이지만, 리눅스 외의 환경에서도 eBPF를 지원하려는 연구가 진행되고 있다[12]. Fig. 1은 eBPF 프로그램이 사용자 공간에서 작성되어 커널로 로드된 후, 검증과 컴파일을 거쳐 커널 내 다양한 훅에 연결되어 동작하는 전체 흐름을 보여준다.

Fig. 1. Process of eBPF Programs

① 고급 언어를 사용하여 사용자 공간에서 eBPF 프로그램 작성 후 clang 등으로 컴파일하여 바이트 코드를 생성한다.

② 사용자 공간의 libbpf, bcc, bpftool과 같은 eBPF 라이브러리를 통해 커널로 로드 요청한다.

③ 요청한 프로그램을 Verifier가 정적 분석을 수행하여 무한 루프, 포인터 접근 등을 검사한다. 검증 실패 시 로드되지 않는다.

④ ③번 과정을 통과하면, JIT 컴파일러가 eBPF 바이트코드를 Native 코드로 변환하여 실행 속도를 향상하고, 프로그램이 커널 훅(hook)에 attach 된다.

⑤ 보안 이벤트 발생 시 eBPF 프로그램이 매번 실행되며, 맵에 수집한 데이터를 저장한다. 사용자 공간에서는 맵에 저장된 데이터를 조회할 수 있다.

위와 같은 절차를 통해 eBPF 프로그램이 실행되기 전, 검증기로 코드의 안정성을 확인받고, 커널에 적재된다. 이후 이벤트가 발생하면 커널 공간에서 직접 처리하므로 사용자 공간과의 컨텍스트 전환(context switch) 비용을 줄임으로써 실행 오버헤드를 줄이고 성능을 향상할 수 있다.

또한 eBPF 프로그램의 배포와 실행을 단순화하기 위해 bpftool을 이용해 생성되는 스켈레톤(skeleton) 코드를 사용한다[13]. 스켈레톤은 libbpf를 기반으로 자동 생성되는 C API 인터페이스로, 사용자 공간 애플리케이션이 eBPF 프로그램과 맵을 로드·제어할 수 있도록 한다. 스켈레톤 파일을 포함한 소프트웨어를 배포하면 별도의 의존성 도구 설치 없이도 해당 실행 파일만으로 eBPF 프로그램의 로드와 실행이 가능하다.

2.2 IoT 환경에서의 화이트리스트 연구

2.2.1 LSM 기반 화이트리스트 기법

Koike 등[6]은 Linux 운영체제 커널에서 동작하는 WhiteEgret이라는 화이트리스트 기반 프로세스 실행 제어 기술을 제안하였다. WhiteEgret은 LSM 프레임워크를 활용하여, 리눅스 커널 수준에서 미리 정의된 정책에 따라 실행 제어 기능을 제공한다.

WhiteEgret은 크게 커널 모듈과 사용자 공간 애플리케이션으로 구분된다. LSM 훅을 통해 실행 요청을 가로채고, 이후 WEUA(WhiteEgret User Application)라는 사용자 애플리케이션에 저장된 정책을 확인하고 해당 이벤트가 화이트리스트에 포함되어 있는지 확인한다. WEUA는 화이트리스트 정책을 관리하고 업데이트하는 역할을 한다.

그러나 WhiteEgret을 설치·활용하려면 리눅스 커널을 재구성해야 한다. 이는 이미 배포된 IoT 기기에서 적용이 어렵고, 커널 버전 호환성 문제와 엔지니어링 비용이 발생한다. 또한 사용자가 직접 허용하고 싶은 정책을 정의해야 하므로 운영 부담이 크며, 정책이 사용자 공간에 위치해 있어 커널 내 삽입 방식보다 화이트리스트 변조가 쉽다.

2.2.2 eBPF 기반 화이트리스트 기법

Evilsocket 등[7]이 개발한 OpenSnitch는 GNU/Linux 플랫폼에서 동작하는 eBPF 기반 애플리케이션 수준의 대화형 방화벽이다. 이 시스템은 eBPF를 활용해 프로세스의 외부 네트워크 연결을 실시간으로 모니터링하고, 연결 시도 발생 시 사용자에게 허용 또는 차단 여부를 묻는 대화창을 표시하여 응용 프로그램별 네트워크 접근을 제어하도록 설계되었다. 또한 OpenSnitch는 포괄적인 규칙 설정 기능을 지원하며, GUI를 통해 특정 애플리케이션, 도메인, IP, 포트, 프로토콜 등에 대해 정교한 필터링 정책을 구성할 수 있다.

그러나 OpenSnitch는 GUI(Graphical User Interface) 기반 사용자 입력에 의존하는 대화형(interactive) 애플리케이션 방화벽으로 설계되었기 때문에, OpenSnitch를 IoT 기기에 적용할 경우 공격자가 IoT 기기를 확보한 후 정책을 허용하면 IoT 기기에 공격자가 요구하는 네트워크를 허용할 수 있다. 또한 정책을 직접 검토·관리하기 어려운 IoT 환경에서는 적용이 제한적이며, 정책 판단이 사용자 공간에서 이루어지므로 커널과의 컨텍스트 스위치 비용이 발생한다. 더불어 OpenSnitch는 네트워크 연결을 시도하는 프로세스만을 모니터링 대상으로 삼기 때문에, 네트워크를 사용하지 않는 프로세스나 시스템 호출 수준의 행위는 탐지할 수 없다. 즉, 애플리케이션 레벨의 네트워크 접근만을 감시하는 구조적 특성상, 프로세스 실행, 파일 접근, 시스템 호출 등 다른 보안 영역을 포괄적으로 보호하지 못한다. 이에 다양한 형태의 비인가 행위를 동시에 감시해야 하는 IoT 환경의 보안 요구사항을 충족하기에는 한계가 있다.

이와 같이 기존 보안 기법들은 사용자 상호작용 의존성, 커널 재구성 요구, 특정 영역에 한정된 모니터링 등 구조적 한계를 갖는다. IoT 시스템은 자원이 제한적이며, 운영 중 정책 변경이나 유지보수가 쉽지 않은 특성을 가지므로, 다양한 형태의 비인가 행위를 자동으로 차단할 수 있는 경량·자동화 보안 체계가 필수적이다. 따라서 커널 수준에서 여러 보안 이벤트를 통합적으로 감시하고, 사용자 개입 없이 정책을 생성·적용하며, 배포된 장치에서도 이식성과 유지보수성을 보장할 수 있는 새로운 보안 아키텍처가 요구된다.

아래의 Table 1.은 화이트리스트 연구의 기능적 특성(functional capabilities)을 기준으로 기존 화이트리스트 기반 보안 기법과 제안하는 보안 기법을 비교한 것이다. 표의 세부적인 내용은 WhiteEgret, OpenSnitch, 그리고 제안하는 eBPF 기반 화이트리스트 시스템을 대상으로 정책 자동 생성 여부, 모니터링 범위(프로세스/네트워크), 컨텍스트 스위치 비용 발생 여부, 커널 수정 필요성 등 구조적 차이를 정리하였다. 이를 통해 기존 기법이 IoT 환경에서 갖는 한계와 제약, 그리고 제안 기법을 IoT 환경에 적용했을 때 기능적 적합성을 확인할 수 있다.

Table 1. Comparison of Functional Capabilities Among Whitelisting

III. 시스템 구조

본 장에서는 IoT 환경을 대상으로 설계한 화이트 리스트 기반 보안 시스템의 구조를 설명한다. IoT 시스템은 일반적으로 개발, 배포, 운영 단계로 구분되며[4], 제안한 eBPF 기반 화이트리스트 시스템은 이 중 개발과 운영 단계의 IoT 개발 생태계를 반영해 설계하였다. Fig. 2는 시스템의 전체 구조를 나타내며 개발 단계에서는 스냅샷 프로그램을 통해 정상 동작 상태의 데이터를 수집하고 데이터 전처리 및 분석을 진행하여 화이트리스트 파일을 생성한다.

Fig. 2. eBPF Based Whitelist Flow Diagram

운영 단계에서는 생성된 화이트리스트 파일을 기반으로 에이전트 프로그램을 통해 비인가 행위를 탐지하고 차단한다.

제안하는 연구는 외부 접근이 가능한 IoT 기기의 특성을 고려하여 사용자의 개입이 최소화된 자동 정책 적용 구조로 설계되었다. 또한 IoT 환경의 저전력 특성을 반영한 경량형 보안 체계를 구현하기 위해 eBPF를 활용하였다. 이는 커널 수정이나 재컴파일 없이 커널 수준에서 동작할 수 있어, LSM 기반 방식보다 높은 적용성을 제공한다. 또한 사용자 개입 없이 정책 생성부터 적용까지 과정을 자동화함으로써 다양한 IoT 장치에서 운영이 가능하도록 설계하였다.

본 논문은 리눅스 기반의 IoT를 대상으로 연구를 진행했다. 다양한 커널 보안 이벤트 중에서 프로세스 실행과 네트워크 연결을 대상으로 하여 시스템을 구현하였다. 이는 실행 행위와 외부 통신을 우선적으로 감시하고 방어하기 위함이며, 향후에는 더 많은 이벤트를 지원할 수 있도록 확장 가능하다.

3.1 스냅샷(snapshot) 시스템

스냅샷 시스템은 개발 단계에서 정상 동작 정보들을 수집하고 이를 전처리 및 분석하여 화이트리스트 파일로 생성하는 역할을 수행한다. Fig. 3은 개발사가 수행해야 하는 초기 과정을 나타낸다.

Fig. 3. eBPF-Snapshot Compilation and Loading Process

스냅샷 코드는 먼저 컴파일되어 오브젝트 코드로 변환되고, 이후 eBPF 전용 도구를 통해 스켈레톤 헤더 파일로 생성된다.

이렇게 생성된 스켈레톤은 로더 프로그램에 포함되어 실행 파일로 빌드되며, 이후 개발 단계에 빌드 완료된 로더 프로그램이 제공된다. IoT 개발자는 해당 프로그램을 설치 및 실행만 하면 정책 생성이 자동으로 진행된다.

수집되는 이벤트는 프로세스의 실행 파일 경로, 전달된 인자, 그리고 인자의 순서이며, 이들 각각이 검증 대상이 된다. 즉, 동일한 실행 파일이라 하더라도 입력되는 인자의 종류와 순서까지 모두 검증 범위에 포함된다. 또한 네트워크에서는 IP와 Port를 수집하여 비인가된 연결을 차단한다.

개발 단계로 전달되는 스냅샷 시스템은 크게 커널 내부에서 정보를 수집하는 로더 프로그램과 수집된 데이터를 정제하는 정책 생성기(policy generator)가 있다. Fig. 4는 스냅샷 시스템의 구조도 흐름을 나타낸다.

Fig. 4. Workflow of eBPF-Snapshot in Development Phase

① 스켈레톤 헤더를 포함한 로더 프로그램인 eBPF-Snapshot을 커널로 로드한다. 이후 eBPF 맵을 선언하고 선언한 맵은 사용자 공간에서 참조할 수 있도록 고정한다.

② 커널에 로드된 스냅샷 프로그램은 지정된 커널 훅과 연결된 뒤 정상 행위를 수집한다. 수집한 데이터는 선언한 맵에 저장한다.

③ 정책 생성기는 커널에서 수집된 정상 행위 이벤트 정보가 저장된 맵을 참조한다.

④ 스냅샷 프로그램으로부터 추출된 정상 행위 이벤트들을 전처리 및 분석하여 화이트리스트 파일로 생성한다.

스냅샷 시스템은 안전한 개발 환경에서 시스템의 정상적인 동작을 지속적으로 모니터링한 후, 이를 기반으로 허용 목록을 생성한다. 본 시스템은 사용자의 개입 없이 프로세스 실행, 네트워크 연결, 시스템 호출 등의 행위를 탐지하여 정규화된 화이트리스트를 생성한다.

3.2 에이전트(agent) 시스템

에이전트 시스템은 스냅샷 시스템에서 생성된 화이트리스트를 기반으로 행위를 실시간으로 허용하거나 차단하는 역할을 수행한다. Fig. 5는 제안하는 eBPF 기반 화이트리스트 에이전트 시스템의 실행 흐름을 단계별로 나타낸 것이다. 스냅샷과 마찬가지로 eBPF-Agent C언어 코드를 컴파일러로 바이트 코드로 변환한 뒤 bpftool과 같은 도구를 통해 스켈레톤 헤더 파일을 생성한다. 이후 에이전트 스켈레톤 파일을 포함한 로더 프로그램(userspace loader)과 정책을 커널에 삽입할 화이트리스트 로더(whitelist loader)를 운영 환경에 배포한다.

Fig. 5. Workflow of eBPF-Agent in Production Phase

① 스켈레톤 헤더를 포함한 로더 프로그램으로 eBPF-Agent을 커널로 로드한다.

② 에이전트의 활성화 여부를 판단하는 활성화(activation) 맵과 정책을 저장하고 참조하는 화이트리스트 맵을 선언 및 고정한다.

③ 화이트리스트 로더는 스냅샷에서 생성된 정책 데이터를 화이트리스트 맵에 삽입한다. 정책 삽입 후, 활성화 맵에 플래그를 부여하여 에이전트에 정책 삽입이 완료되었음을 알린다. 한 번 정책이 삽입되면 맵을 Freeze하여 정책이 삽입·변조되는 것을 방지한다.

④ 커널에 적재된 eBPF-Agent는 먼저 활성화 맵을 참조하여 정책이 삽입되었는지 확인하고 비활성화 상태이면 행위 이벤트를 검증하지 않고 통과한다.

⑤ 활성화 맵을 참조했을 때 활성화 플래그가 선언되어 있으면 프로세스와 네트워크 이벤트를 정책과 비교하여 허용 및 차단을 수행한다.

에이전트 시스템은 커널 수준에서 동작하여 정책 기반의 실시간 탐지 및 차단 기능을 수행함으로써, 프로세스와 네트워크 통신의 비인가 행위를 방어할 수 있다.

IV. 실험

본 연구에서 제안한 eBPF 기반 화이트리스트 시스템의 유효성과 성능 오버헤드를 측정하는 실험을 수행하였다. 시스템이 자체적으로 수행하는 내부 프로세스와 백그라운드 활동을 모두 정상 행위로 간주하며, 실험 대상이 되는 정상 행위를 서버와 통신하며 연산을 수행하는 calculator 프로그램으로 설정하였다. 스냅샷 실험에서는 calculator를 포함한 정상 시스템 동작을 기반으로 화이트리스트가 자동 생성됨을 확인하고 에이전트 실험에서는 calculator 프로그램이 정상적으로 실행됨을 보이며, calculator 이외의 비인가 행위는 모두 차단되는 것을 보인다. 실험은 리눅스 기반 IoT 디바이스 환경에서 수행하였으며, Table 2.은 실험 환경을 나타낸다.

Table 2. Environment Specifications

4.1 스냅샷 시스템 실험

스냅샷 시스템이 정상적으로 모니터링을 수행하고 화이트리스트 파일을 생성하는지 확인하기 위해 개발 환경에서 스냅샷 시스템을 실행하였다. Fig. 6은 calculator 프로그램을 포함한 파일 경로, 인자, 인자 순서의 프로세스 실행 로그를 나타내고 Fig. 7은 calculator 프로그램에서 연결한 허용된 IP(192.168.4.134)와 Port(5000)를 포함한 네트워크 연결을 대상으로 IP와 Port를 수집한 로그를 나타낸다.

Fig. 6. Snapshot Process Whitelist Log

Fig. 7. Snapshot Network Whitelist Log

스냅샷 시스템은 정상 시나리오가 수행되는 동안 프로세스 실행과 네트워크 연결을 실시간으로 모니터링 하고 eBPF 맵에 저장한다. 이후 개발자가 원하는 시점 혹은 전체 동작이 끝나면 스냅샷 프로그램을 종료하고, 정책 생성기가 해당 맵을 참조하여 JSON 파일의 형태로 화이트리스트를 생성한다. Table 3.는 프로세스 화이트리스트의 JSON 저장 형식을, Table 4.은 네트워크 화이트리스트의 JSON 저장 형식을 나타낸다.

Table 3. eBPF-Snapshot Process Whitelist

Table 4. eBPF-Snapshot Network Whitelist

4.2 에이전트 시스템 실험

에이전트 시스템 실험에서는 운영 환경에서 제안한 에이전트 시스템이 화이트리스트 정책을 정상적으로 로드하고, 운영 중 발생하는 비인가 행위를 실시간으로 차단할 수 있는지를 검증하였다.

Fig. 8은 허용된 프로그램인 calculator를 실행시켰을 때 프로그램이 정상 동작함을 나타낸다.

Fig. 8. Allow Operation of the Calculator

반면 Fig. 9는 허용 목록에 포함되지 않은 프로그램이 실행될 경우, 해당 실행이 정상적으로 차단됨을 확인할 수 있다.

Fig. 9. Blocking Malicious Action

또한 Fig. 10은 허용된 프로그램을 실행하더라도 허가된 IP와 Port가 아닌 다른 주소로 연결을 시도했을 때 차단이 되는 것을 확인할 수 있다.

Fig. 10. Blocking Unauthorized IP/Port Access

4.3 에이전트 공격 시나리오 실험

공격 시나리오는 다음과 같이 IoT 환경 대상 사이버 공격으로 구성하였다. 공격자는 IoT 장치가 운영 중인 상태에서 원격 취약점을 악용하여 제한된 명령 실행 권한을 획득한 것으로 가정한다. 공격 표면으로는 단순한 원격 코드 실행(RCE) 취약점을 통해 쉘 접근이 가능하다는 환경을 설정하였다.

1) 악성 실행 파일 다운로드 시도[14]

공격자는 지속적 제어를 위해 원격 C2 서버로부터 악성 바이너리를 wget 또는 curl 명령을 통해 다운로드하려 시도한다. 이는 화이트리스트에 존재하지 않는 외부 프로세스 실행 및 네트워크 연결을 포함하므로, 에이전트 시스템은 커널 내부에서 execve 및 socket_connect 훅을 통해 이를 차단하여 다운로드가 이루어지지 않도록 한다. Fig. 11은 악성 파일의 다운로드 시도가 차단된 로그와 메시지를 보여준다.

Fig. 11. Blocking Malicious File Download

2) 민감 파일 접근을 통한 정보 탈취 시도[14]

공격자는 시스템 계정 정보를 탈취하기 위해 /etc / shadow, /etc / passwd 등 민감 정보가 포함된 파일을 읽으려 시도한다. 이는 화이트리스트에 등록되지 않은 프로세스의 비인가 파일 접근 시도로 분류되며, 권한 상승이 발생하더라도 해당 프로세스 화이트리스트에 등록되지 않은 행위는 차단한다. Fig. 12는 민감 파일 접근이 거부된 결과를 나타낸다.

Fig. 12. Blocking Sensitive File Access

3) 비인가 외부 네트워크로의 접속 시도[15]

공격자는 C2 서버와 통신을 위해 화이트리스트에 존재하지 않는 IP 및 Port로 원격 연결을 생성하려 한다. 제안 기법은 execve 및 socket_connect 훅에서 이를 탐지하며, 정책에 부합하지 않는 연결 요청을 차단한다. Fig. 13은 비인가 원격 연결이 거부되는 결과를 보인다.

Fig. 13. Blocking Unauthorized Network Access

4.4 에이전트 성능 실험

본 연구에서 비교 대상으로 선정한 WhiteEgret과 OpenSnitch는 각각 요구하는 커널 버전과 실행 환경이 다르기 때문에 완전히 동일한 실험 환경을 구성하는 것이 어렵다. 특히 WhiteEgret은 2018년 이후 업데이트가 되지 않아 최신 버전 커널에서는 운영이 제한된다. 따라서 본 실험은 각 기법의 보안 기법 적용 전·후 오버헤드 변화 비율을 비교하였다.

제안 기법과 OpenSnitch는 Table 2.의 실험 환경을 따르고, WhiteEgret은 Table 5.를 기반으로 실험을 진행하였다.

Table 5. WhiteEgret Environment Specifications

본 성능 평가에서는 각 기법 적용 전과 적용 후 평균 실행 시간을 기준으로 산출한 평균 오버헤드 증가율을 중심으로 상대적인 성능 차이를 분석하였다. 실험은 다음 두 가지 시나리오에 대해 100회 반복 측정한 평균 소요 시간을 비교하였다.

① 프로세스 허용 시나리오(Process-Allow Scenario): 허용된 실행 파일에 대해 execve()를 100회 반복 호출하여 평균 실행 지연을 측정하고, 보안 기법 적용 전·후의 실행 시간 차이를 기반으로 프로세스 실행 오버헤드를 산출하였다.

② 네트워크 허용 시나리오(Network-Allow Scenario): 로컬 루프백(127.0.0.1) 기반 HTTP 서버에 대해 100회 연결 요청을 수행하고, curl의 time_connect 값을 이용하여 TCP 연결 지연을 측정하였다. 이후 보안 기법 적용 전·후의 평균 연결 시간 변화를 비교하여 네트워크 허용 시 발생하는 오버헤드를 평가하였다.

Table 6에서 WhiteEgret은 허용된 프로세스 실행 시 31.72%의 지연 증가를 보였고, eBPF 기반 화이트리스트는 27.37% 증가로 더 낮은 오버헤드를 나타냈다. Table 7에서는 OpenSnitch가 3,831%의 연결 지연을 보인 반면, eBPF 기반 화이트리스트는 1,475% 증가로 상대적으로 적은 네트워크 오버헤드를 기록하였다.

Table 6. Execution Overhead When Running Allowed Processes

Table 7. Network Connection Overhead Under Allowed Connections

실험 결과, eBPF 기반 화이트리스트는 프로세스 실행과 네트워크 연결 모두에서 기존 화이트리스트 보안 기법보다 낮은 오버헤드를 나타냈다.

V. 결론

본 논문은 IoT 기기에서 기존 시그니처 기반 탐지나 사용자 개입에 의존하는 화이트리스트 방식이 갖는 한계를 보완하기 위해, IoT 환경의 특성을 고려하여 보안성을 갖춘 eBPF 기반 자동화 화이트리스트 기법을 제안하였다. 제안하는 시스템은 개발 단계에서 스냅샷을 통해 자동으로 정상 동작을 수집하고 정책을 생성한다. 특히 스냅샷 프로그램을 eBPF 도구를 활용해 스켈레톤 헤더 파일로 변환한 후 로더 프로그램에 포함해 실행 파일로 빌드 및 배포되므로, 개발 단계에서는 단순 스냅샷 프로그램 실행만으로 정책 생성이 가능하여 인적 자원 소모를 최소화할 수 있다. 운영 단계에서는 에이전트를 통해 해당 정책을 eBPF 맵에 적재함으로써 정책 변조를 방지하며, 사용자 개입 없이도 비인가 실행 및 네트워크 행위를 실시간으로 차단할 수 있음을 보였다. 또한 본 시스템은 실험을 통해 프로세스 실행 및 네트워크 통신에 대한 화이트리스트를 생성하고 적용하여 제안 기법이 IoT 환경에서 자동화 보안 체계로 활용할 수 있음을 보였다.

그러나 본 연구는 몇 가지 한계점을fs 가진다. 첫째, 실험 범위가 프로세스 실행과 네트워크 통신에 국한되어 있으며, 파일 접근이나 외부 디바이스 연결 등 다른 보안 이벤트에 대한 검증에 관한 연구가 추가로 필요하다. 둘째, 파일 무결성 보장 기법이 포함되지 않았기 때문에, 공격자가 정책에 등록된 파일의 정보로 악성 실행 파일을 변조하는 경우 이를 효과적으로 차단하기 어렵다.

향후 연구에서는 파일 접근, 메모리 조작, 외부 장치 제어 등 다양한 커널 이벤트를 포괄하는 확장된 정책 수집 및 제어 기능을 보완하고, 무결성 검증 기법을 추가하여 정책과 실행 파일에 대한 신뢰성을 높일 계획이다. 또한 성능 오버헤드를 더욱 줄이고, 다계층 방어 체계와의 통합을 통해 실질적인 IoT 환경에서 적용할 수 있는 고도화된 보안 프레임워크로 발전하는 것을 목표로 한다.