어린 아이들을 위한 BPF, 파트 XNUMX: 클래식 BPF

BPF(Berkeley Packet Filters)는 몇 년 동안 영어 기술 간행물의 첫 페이지에 등장한 Linux 커널 기술입니다. 컨퍼런스는 BPF의 사용 및 개발에 대한 보고서로 가득 차 있습니다. Linux 네트워크 하위 시스템 관리자인 David Miller가 Linux Plumbers 2018에서 연설합니다. “이 이야기는 XDP에 관한 것이 아닙니다.” (XDP는 BPF의 한 가지 사용 사례입니다.) 브렌던 그레그(Brendan Gregg)가 다음과 같은 제목으로 강연을 합니다. Linux BPF 초능력. 토케 호일란드-요르겐센 웃음커널은 이제 마이크로커널입니다. Thomas Graf는 다음과 같은 아이디어를 장려합니다. BPF는 커널용 자바스크립트입니다..

Habré에는 BPF에 대한 체계적인 설명이 아직 없으므로 일련의 기사에서 기술의 역사에 대해 이야기하고 아키텍처 및 개발 도구를 설명하며 BPF 사용의 적용 및 실행 영역을 간략하게 설명하려고 합니다. 시리즈의 제로 기사에서는 클래식 BPF의 역사와 아키텍처를 설명하고 작동 원리의 비밀도 공개합니다. tcpdump, seccomp, strace, 그리고 훨씬 더.

BPF의 개발은 Linux 네트워킹 커뮤니티에 의해 제어되며, BPF의 주요 기존 애플리케이션은 네트워크와 관련되어 있으므로 허가를 받습니다. @eucariot, 나는 위대한 시리즈를 기리기 위해 이 시리즈를 "어린이를 위한 BPF"라고 불렀습니다. "어린아이들을 위한 네트워크".

BPF 역사에 대한 단기 강좌(c)

최신 BPF 기술은 동일한 이름을 가진 기존 기술을 개선하고 확장한 버전으로, 현재는 혼동을 피하기 위해 클래식 BPF라고 합니다. 잘 알려진 유틸리티는 클래식 BPF를 기반으로 만들어졌습니다. tcpdump, 메커니즘 seccomp, 덜 알려진 모듈 xt_bpf 에 iptables 및 분류기 cls_bpf. 최신 Linux에서는 클래식 BPF 프로그램이 자동으로 새로운 형식으로 변환되지만 사용자 관점에서 볼 때 API는 그대로 유지되었으며 이 기사에서 볼 수 있듯이 클래식 BPF의 새로운 용도가 여전히 발견되고 있습니다. 이러한 이유로, 그리고 Linux에서 클래식 BPF 개발의 역사를 따라가면 그것이 어떻게 그리고 왜 현대적인 형태로 진화했는지가 더 명확해질 것이기 때문에 나는 클래식 BPF에 대한 기사부터 시작하기로 결정했습니다.

지난 세기 XNUMX년대 말, 유명한 로렌스 버클리 연구소(Lawrence Berkeley Laboratory)의 엔지니어들은 지난 세기 XNUMX년대 후반에 현대화된 하드웨어에서 네트워크 패킷을 적절하게 필터링하는 방법에 대한 질문에 관심을 갖게 되었습니다. 원래 CSPF(CMU/Stanford Packet Filter) 기술로 구현된 필터링의 기본 아이디어는 불필요한 패킷을 최대한 빨리 필터링하는 것이었습니다. 이는 커널 공간에서 불필요한 데이터가 사용자 공간에 복사되는 것을 방지하기 때문입니다. 커널 공간에서 사용자 코드를 실행하기 위한 런타임 보안을 제공하기 위해 샌드박스 가상 머신이 사용되었습니다.

그러나 기존 필터의 가상 머신은 스택 기반 머신에서 실행되도록 설계되었으며 최신 RISC 머신에서는 효율적으로 실행되지 않았습니다. 결과적으로 Berkeley Labs의 엔지니어들의 노력을 통해 새로운 BPF(Berkeley Packet Filters) 기술이 개발되었으며, 그 가상 머신 아키텍처는 다음과 같은 잘 알려진 제품의 주력 제품인 Motorola 6502 프로세서를 기반으로 설계되었습니다. 애플 II 또는 NES. 새로운 가상 머신은 기존 솔루션에 비해 필터 성능을 수십 배 향상시켰습니다.

BPF 머신 아키텍처

사례를 분석하면서 실제적인 방식으로 아키텍처에 대해 알아 보겠습니다. 그러나 우선 머신에 사용자가 액세스할 수 있는 두 개의 32비트 레지스터, 즉 누산기가 있다고 가정해 보겠습니다. A 및 인덱스 레지스터 X, 쓰기 및 후속 읽기에 사용할 수 있는 64바이트 메모리(16워드) 및 이러한 개체 작업을 위한 작은 명령 시스템입니다. 조건식을 구현하기 위한 점프 명령도 프로그램에서 사용할 수 있었지만 프로그램의 적시 완료를 보장하기 위해 앞으로만 점프할 수 있었습니다. 즉, 특히 루프를 만드는 것이 금지되었습니다.

기계를 시작하는 일반적인 계획은 다음과 같습니다. 사용자는 BPF 아키텍처용 프로그램을 생성하고 다음을 사용합니다. 약간 커널 메커니즘(예: 시스템 호출)은 프로그램을 로드하고 연결합니다. 어떤 사람들에게는 커널의 이벤트 생성기(예: 이벤트는 네트워크 카드에 다음 패킷이 도착하는 것)입니다. 이벤트가 발생하면 커널은 프로그램을 실행하고(예: 인터프리터에서) 머신 메모리는 다음과 같습니다. 어떤 사람들에게는 커널 메모리 영역(예: 수신 패킷의 데이터)

위의 내용으로 예제를 살펴보기에 충분합니다. 필요에 따라 시스템 및 명령 형식에 대해 알아 보겠습니다. 가상 머신의 명령 시스템을 즉시 연구하고 모든 기능에 대해 배우고 싶다면 원본 기사를 읽으십시오. BSD 패킷 필터 및/또는 파일의 전반부 문서/네트워킹/filter.txt 커널 문서에서. 또한 프레젠테이션을 공부할 수도 있습니다. libpcap: 패킷 캡처를 위한 아키텍처 및 최적화 방법론, BPF의 저자 중 한 명인 McCanne이 창조의 역사에 대해 이야기합니다. libpcap.

Linux에서 클래식 BPF를 사용하는 모든 중요한 예를 살펴보겠습니다. tcpdump (libpcap), 초컴, xt_bpf, cls_bpf.

TCP 덤프

BPF 개발은 잘 알려진 유틸리티인 패킷 필터링을 위한 프런트엔드 개발과 병행하여 수행되었습니다. tcpdump. 그리고 이것은 많은 운영 체제에서 사용할 수 있는 클래식 BPF를 사용하는 가장 오래되고 유명한 예이므로 이 기술에 대한 연구를 시작하겠습니다.

(저는 이 글의 모든 예제를 Linux에서 실행했습니다. 5.6.0-rc6. 더 나은 가독성을 위해 일부 명령의 출력이 편집되었습니다.)

예: IPv6 패킷 관찰

인터페이스의 모든 IPv6 패킷을 보고 싶다고 가정해 보겠습니다. eth0. 이를 위해 우리는 프로그램을 실행할 수 있습니다 tcpdump 간단한 필터로 ip6:

$ sudo tcpdump -i eth0 ip6

이 경우, tcpdump 필터를 컴파일합니다 ip6 BPF 아키텍처 바이트코드로 변환하여 커널로 보냅니다(자세한 내용은 섹션 참조). Tcpdump: 로드 중). 인터페이스를 통과하는 모든 패킷에 대해 로드된 필터가 실행됩니다. eth0. 필터가 XNUMX이 아닌 값을 반환하는 경우 n, 그 다음에는 최대 n 패킷의 바이트가 사용자 공간에 복사되고 출력에서 ​​볼 수 있습니다. tcpdump.

어떤 바이트코드가 커널로 전송되었는지 쉽게 알아낼 수 있다는 것이 밝혀졌습니다. tcpdump 의 도움으로 tcpdump, 옵션을 사용하여 실행하면 -d:

$ sudo tcpdump -i eth0 -d ip6
(000) ldh      [12]
(001) jeq      #0x86dd          jt 2    jf 3
(002) ret      #262144
(003) ret      #0

XNUMX번째 줄에서 다음 명령을 실행합니다. ldh [12], 이는 "레지스터에 로드"를 의미합니다. A 주소 16”에 반 단어(12비트)가 있고 유일한 질문은 우리가 어떤 종류의 메모리를 처리하고 있습니까? 대답은 에 있습니다. x 시작하다 (x+1)분석된 네트워크 패킷의 번째 바이트입니다. 이더넷 인터페이스에서 패킷을 읽습니다. eth0그리고이 방법패킷은 다음과 같습니다(단순화를 위해 패킷에 VLAN 태그가 없다고 가정합니다).

       6              6          2
|Destination MAC|Source MAC|Ether Type|...|

그래서 명령을 실행한 후 ldh [12] 기록부에 A 들판이 있을 거야 Ether Type — 이 이더넷 프레임에서 전송된 패킷 유형. 1번째 줄에서는 레지스터의 내용을 비교합니다. A (패키지형) 다 0x86dd그리고이 거기에는 우리가 관심 있는 유형은 IPv6입니다. 1행에는 비교 명령 외에도 두 개의 열이 더 있습니다. jt 2 и jf 3 — 비교가 성공한 경우 이동해야 할 표시(A == 0x86dd) 실패했습니다. 따라서 성공적인 경우(IPv6)에서는 2행으로 이동하고, 실패한 경우에는 3행으로 이동합니다. 3행에서 프로그램은 코드 0(패킷 복사 안 함)으로 종료되고, 2행에서 프로그램은 코드로 종료됩니다. 262144(최대 256KB 패키지를 복사하세요).

더 복잡한 예: 대상 포트별로 TCP 패킷을 살펴봅니다.

대상 포트 666을 사용하여 모든 TCP 패킷을 복사하는 필터의 모양을 살펴보겠습니다. IPv4 사례가 더 간단하므로 IPv6 사례를 고려해 보겠습니다. 이 예제를 연구한 후 연습으로 IPv6 필터를 직접 탐색할 수 있습니다(ip6 and tcp dst port 666) 및 일반적인 경우에 대한 필터(tcp dst port 666). 따라서 우리가 관심 있는 필터는 다음과 같습니다.

$ sudo tcpdump -i eth0 -d ip and tcp dst port 666
(000) ldh      [12]
(001) jeq      #0x800           jt 2    jf 10
(002) ldb      [23]
(003) jeq      #0x6             jt 4    jf 10
(004) ldh      [20]
(005) jset     #0x1fff          jt 10   jf 6
(006) ldxb     4*([14]&0xf)
(007) ldh      [x + 16]
(008) jeq      #0x29a           jt 9    jf 10
(009) ret      #262144
(010) ret      #0

우리는 0행과 1행이 무엇을 하는지 이미 알고 있습니다. 2번째 줄에서 우리는 이것이 IPv4 패킷인지를 이미 확인했습니다(Ether Type = 0x800) 레지스터에 로드합니다. A 패킷의 24번째 바이트입니다. 우리 패키지는 다음과 같습니다

       14            8      1     1
|ethernet header|ip fields|ttl|protocol|...|

이는 우리가 레지스터에 로드한다는 의미입니다. A IP 헤더의 프로토콜 필드는 논리적입니다. TCP 패킷만 복사하려고 하기 때문입니다. 우리는 프로토콜을 다음과 비교합니다. 0x6 (IPPROTO_TCP) 3행에 있습니다.

라인 4와 5에서는 주소 20에 있는 하프워드를 로드하고 다음 명령을 사용합니다. jset 세 가지 중 하나가 설정되어 있는지 확인하십시오. 깃발 - 지급된 마스크를 착용 jset 가장 중요한 세 비트가 지워집니다. XNUMX개의 비트 중 XNUMX개는 패킷이 조각화된 IP 패킷의 일부인지 여부를 알려주고, 그렇다면 마지막 조각인지 여부를 알려줍니다. 세 번째 비트는 예약되어 있으며 XNUMX이어야 합니다. 불완전하거나 손상된 패킷을 확인하고 싶지 않으므로 세 비트를 모두 확인합니다.

이 목록에서 가장 흥미로운 것은 6번째 줄입니다. 표현 ldxb 4*([14]&0xf) 레지스터에 로드한다는 의미입니다. X 패킷의 4번째 바이트의 최하위 XNUMX비트에 XNUMX를 곱한 것입니다. XNUMX번째 바이트의 최하위 XNUMX비트는 필드입니다. 인터넷 헤더 길이 헤더의 길이를 단어로 저장하는 IPv4 헤더이므로 4를 곱해야 합니다. 흥미롭게도 표현식은 4*([14]&0xf) 이 형식과 레지스터에만 사용할 수 있는 특수 주소 지정 체계에 대한 지정입니다. X, 즉. 우리도 말할 수 없어 ldb 4*([14]&0xf) 도 ldxb 5*([14]&0xf) (다른 오프셋만 지정할 수 있습니다. 예를 들어, ldxb 4*([16]&0xf)). 이 주소 지정 방식이 BPF에 정확하게 추가된 것은 분명합니다. X (인덱스 레지스터) IPv4 헤더 길이입니다.

그래서 7번째 줄에서 우리는 단어의 절반을 로드하려고 합니다. (X+16). 이더넷 헤더가 14바이트를 차지한다는 점을 기억하고, X IPv4 헤더의 길이가 포함되어 있으므로 A TCP 대상 포트가 로드되었습니다.

       14           X           2             2
|ethernet header|ip header|source port|destination port|

마지막으로 8행에서는 대상 포트를 원하는 값과 비교하고 9행 또는 10행에서는 패킷을 복사할지 여부에 대한 결과를 반환합니다.

Tcpdump: 로드 중

이전 예제에서는 패킷 필터링을 위해 BPF 바이트코드를 커널에 정확히 로드하는 방법에 대해 자세히 설명하지 않았습니다. 일반적으로 말하면, tcpdump 많은 시스템으로 포팅되었으며 필터 작업을 위해 tcpdump 도서관을 이용한다 libpcap. 간단히 말해서 다음을 사용하여 인터페이스에 필터를 배치하려면 libpcap, 다음을 수행해야 합니다.

• 유형 설명자 만들기 pcap_t 인터페이스 이름에서: pcap_create,
• 인터페이스 활성화: pcap_activate,
• 컴파일 필터: pcap_compile,
• 연결 필터: pcap_setfilter.

기능이 어떻게 되는지 보려면 pcap_setfilter Linux에서 구현된 경우 strace (일부 줄이 제거되었습니다):

$ sudo strace -f -e trace=%network tcpdump -p -i eth0 ip
socket(AF_PACKET, SOCK_RAW, 768)        = 3
bind(3, {sa_family=AF_PACKET, sll_protocol=htons(ETH_P_ALL), sll_ifindex=if_nametoindex("eth0"), sll_hatype=ARPHRD_NETROM, sll_pkttype=PACKET_HOST, sll_halen=0}, 20) = 0
setsockopt(3, SOL_SOCKET, SO_ATTACH_FILTER, {len=4, filter=0xb00bb00bb00b}, 16) = 0
...

출력의 처음 두 줄에서 우리는 원시 소켓 모든 이더넷 프레임을 읽고 이를 인터페이스에 바인딩합니다. eth0. 부터 우리의 첫 번째 예 우리는 필터가 ip XNUMX개의 BPF 명령어로 구성되며 세 번째 줄에서는 옵션을 사용하는 방법을 보여줍니다. SO_ATTACH_FILTER 시스템 호출 setsockopt 길이가 4인 필터를 로드하고 연결합니다. 이것이 필터입니다.

클래식 BPF에서는 필터 로드 및 연결이 항상 원자성 작업으로 발생하지만 새 버전의 BPF에서는 프로그램 로드 및 이벤트 생성기에 바인딩하는 작업이 시간적으로 분리된다는 점은 주목할 가치가 있습니다.

숨겨진 진실

약간 더 완전한 버전의 출력은 다음과 같습니다.

$ sudo strace -f -e trace=%network tcpdump -p -i eth0 ip
socket(AF_PACKET, SOCK_RAW, 768)        = 3
bind(3, {sa_family=AF_PACKET, sll_protocol=htons(ETH_P_ALL), sll_ifindex=if_nametoindex("eth0"), sll_hatype=ARPHRD_NETROM, sll_pkttype=PACKET_HOST, sll_halen=0}, 20) = 0
setsockopt(3, SOL_SOCKET, SO_ATTACH_FILTER, {len=1, filter=0xbeefbeefbeef}, 16) = 0
recvfrom(3, 0x7ffcad394257, 1, MSG_TRUNC, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable)
setsockopt(3, SOL_SOCKET, SO_ATTACH_FILTER, {len=4, filter=0xb00bb00bb00b}, 16) = 0
...

위에서 언급했듯이 필터를 로드하고 5번 라인의 소켓에 연결합니다. 하지만 3번 라인과 4번 라인에서는 어떤 일이 발생합니까? 이것이 밝혀졌습니다 libpcap 우리를 돌봅니다. 필터의 출력에 필터를 만족하지 않는 패킷이 포함되지 않도록 라이브러리 연결하다 더미 필터 ret #0 (모든 패킷 삭제) 소켓을 비차단 모드로 전환하고 이전 필터에서 남아 있을 수 있는 모든 패킷을 빼려고 시도합니다.

전체적으로 클래식 BPF를 사용하여 Linux에서 패키지를 필터링하려면 다음과 같은 구조 형태의 필터가 필요합니다. struct sock_fprog 개방형 소켓, 그 후 시스템 호출을 사용하여 필터를 소켓에 연결할 수 있습니다. setsockopt.

흥미롭게도 필터는 원시 소켓뿐만 아니라 모든 소켓에 부착될 수 있습니다. 여기 예 들어오는 모든 UDP 데이터그램에서 처음 XNUMX바이트를 제외하고 모두 차단하는 프로그램입니다. (글이 복잡해지지 않도록 코드에 주석을 추가했습니다.)

사용에 대한 자세한 내용 setsockopt 필터 연결에 대해서는 참조 소켓(7), 하지만 다음과 같은 자신만의 필터를 작성하는 방법에 대해서는 struct sock_fprog 도움없이 tcpdump 우리는 섹션에서 이야기 할 것입니다 우리 손으로 BPF 프로그래밍하기.

클래식 BPF와 XNUMX세기

BPF는 1997년 Linux에 포함되었으며 오랫동안 주력으로 남아 있습니다. libpcap 특별한 변경 없이(Linux 관련 변경은 물론, 했다, 그러나 그들은 글로벌 그림을 바꾸지 않았습니다). BPF가 진화할 것이라는 첫 번째 심각한 징후는 Eric Dumazet이 제안한 2011년에 나타났습니다. 패치, 커널에 Just In Time Compiler를 추가합니다. BPF 바이트코드를 네이티브 코드로 변환하는 변환기입니다. x86_64 암호.

JIT 컴파일러는 2012년에 일련의 변화 중 첫 번째였습니다. 출연 한 필터를 작성하는 기능 초컴, BPF를 사용하여 2013년 XNUMX월에 추가 모듈 xt_bpf, 이를 통해 다음에 대한 규칙을 작성할 수 있습니다. iptables BPF의 도움으로 2013년 XNUMX월에 추가 또한 모듈 cls_bpf, BPF를 사용하여 트래픽 분류자를 작성할 수 있습니다.

이 모든 예제를 곧 더 자세히 살펴보겠지만 먼저 BPF용 임의 프로그램을 작성하고 컴파일하는 방법을 배우는 것이 유용할 것입니다. libpcap 제한적(간단한 예: 필터 생성됨) libpcap 0 또는 0x40000의 두 가지 값만 반환할 수 있음) 또는 일반적으로 seccomp의 경우와 같이 적용할 수 없습니다.

우리 손으로 BPF 프로그래밍하기

BPF 명령어의 바이너리 형식에 대해 알아봅시다. 매우 간단합니다.

   16    8    8     32
| code | jt | jf |  k  |

각 명령어는 64비트를 차지하며 처음 16비트는 명령어 코드이고 그 다음에는 XNUMX비트 들여쓰기가 XNUMX개 있습니다. jt и jf및 인수의 경우 32비트 K, 그 목적은 명령마다 다릅니다. 예를 들어 다음 명령은 ret, 프로그램을 종료하는 코드에는 6, 반환 값은 상수에서 가져옵니다. K. C에서는 단일 BPF 명령어가 구조로 표현됩니다.

struct sock_filter {
        __u16   code;
        __u8    jt;
        __u8    jf;
        __u32   k;
}

전체 프로그램은 구조 형태입니다.

struct sock_fprog {
        unsigned short len;
        struct sock_filter *filter;
}

따라서 우리는 이미 프로그램을 작성할 수 있습니다(예를 들어, 명령어 코드를 알고 있습니다). [1]). 필터는 이렇게 생겼어요 ip6 으로 우리의 첫 번째 예:

struct sock_filter code[] = {
        { 0x28, 0, 0, 0x0000000c },
        { 0x15, 0, 1, 0x000086dd },
        { 0x06, 0, 0, 0x00040000 },
        { 0x06, 0, 0, 0x00000000 },
};
struct sock_fprog prog = {
        .len = ARRAY_SIZE(code),
        .filter = code,
};

프로그램 prog 우리는 통화에서 합법적으로 사용할 수 있습니다

setsockopt(sk, SOL_SOCKET, SO_ATTACH_FILTER, &prog, sizeof(prog))

기계어 형태로 프로그램을 작성하는 것은 그리 편리하지는 않지만 때로는 필요할 때도 있습니다(예: 디버깅, 단위 테스트 생성, Habré에 대한 기사 작성 등). 편의상 파일에 <linux/filter.h> 도우미 매크로가 정의되었습니다. 위와 동일한 예를 다음과 같이 다시 작성할 수 있습니다.

struct sock_filter code[] = {
        BPF_STMT(BPF_LD|BPF_H|BPF_ABS, 12),
        BPF_JUMP(BPF_JMP|BPF_JEQ|BPF_K, ETH_P_IPV6, 0, 1),
        BPF_STMT(BPF_RET|BPF_K, 0x00040000),
        BPF_STMT(BPF_RET|BPF_K, 0),
}

그러나 이 옵션은 그다지 편리하지 않습니다. 이것이 Linux 커널 프로그래머가 추론한 것이므로 디렉토리에 있습니다. tools/bpf 커널에서는 클래식 BPF 작업을 위한 어셈블러와 디버거를 찾을 수 있습니다.

어셈블리 언어는 디버그 출력과 매우 유사합니다. tcpdump, 그러나 추가로 기호 레이블을 지정할 수도 있습니다. 예를 들어, 다음은 TCP/IPv4를 제외한 모든 패킷을 삭제하는 프로그램입니다.

$ cat /tmp/tcp-over-ipv4.bpf
ldh [12]
jne #0x800, drop
ldb [23]
jneq #6, drop
ret #-1
drop: ret #0

기본적으로 어셈블러는 다음 형식으로 코드를 생성합니다. <количество инструкций>,<code1> <jt1> <jf1> <k1>,..., TCP를 사용한 예에서는 다음과 같습니다.

$ tools/bpf/bpf_asm /tmp/tcp-over-ipv4.bpf
6,40 0 0 12,21 0 3 2048,48 0 0 23,21 0 1 6,6 0 0 4294967295,6 0 0 0,

C 프로그래머의 편의를 위해 다른 출력 형식을 사용할 수 있습니다.

$ tools/bpf/bpf_asm -c /tmp/tcp-over-ipv4.bpf
{ 0x28,  0,  0, 0x0000000c },
{ 0x15,  0,  3, 0x00000800 },
{ 0x30,  0,  0, 0x00000017 },
{ 0x15,  0,  1, 0x00000006 },
{ 0x06,  0,  0, 0xffffffff },
{ 0x06,  0,  0, 0000000000 },

이 텍스트는 유형 구조 정의에 복사될 수 있습니다. struct sock_filter, 이 섹션의 시작 부분에서 그랬던 것처럼.

Linux 및 netsniff-ng 확장

표준 BPF 외에도 Linux 및 tools/bpf/bpf_asm 지원과 비표준 세트. 기본적으로 명령어는 구조체의 필드에 액세스하는 데 사용됩니다. struct sk_buff, 커널의 네트워크 패킷을 설명합니다. 그러나 다른 유형의 도우미 명령도 있습니다. 예를 들면 다음과 같습니다. ldw cpu 레지스터에 로드됩니다 A 커널 함수 실행 결과 raw_smp_processor_id(). (BPF의 새 버전에서는 이러한 비표준 확장이 확장되어 메모리, 구조에 액세스하고 이벤트를 생성하기 위한 커널 도우미 세트를 프로그램에 제공합니다.) 다음은 필터의 흥미로운 예입니다. 확장을 사용하여 패킷 헤더를 사용자 공간으로 poff, 페이로드 오프셋:

ld poff
ret a

BPF 확장은 다음에서 사용할 수 없습니다. tcpdump, 그러나 이것이 유틸리티 패키지에 대해 알아가는 좋은 이유입니다. netsniff-ng, 무엇보다도 고급 프로그램이 포함되어 있습니다. netsniff-ng, BPF를 사용한 필터링 외에도 효과적인 트래픽 생성기가 포함되어 있으며 tools/bpf/bpf_asm, BPF 어셈블러는 다음과 같습니다. bpfc. 패키지에는 매우 자세한 문서가 포함되어 있습니다. 기사 마지막에 있는 링크도 참조하세요.

초컴

따라서 우리는 임의의 복잡성을 지닌 BPF 프로그램을 작성하는 방법을 이미 알고 있으며 새로운 예제를 볼 준비가 되었습니다. 그 중 첫 번째는 BPF 필터를 사용하여 사용 가능한 시스템 호출 인수 세트 및 세트를 관리할 수 있는 seccomp 기술입니다. 주어진 프로세스와 그 자손.

seccomp의 첫 번째 버전은 2005년에 커널에 추가되었지만 그다지 인기가 없었습니다. 프로세스에서 사용할 수 있는 시스템 호출 집합을 다음으로 제한하는 단일 옵션만 제공했기 때문입니다. read, write, exit и sigreturn, 규칙을 위반한 프로세스는 다음을 사용하여 종료되었습니다. SIGKILL. 그러나 2012년에 seccomp에는 BPF 필터를 사용하는 기능이 추가되어 허용되는 시스템 호출 집합을 정의하고 해당 인수에 대한 검사도 수행할 수 있습니다. (흥미롭게도 Chrome은 이 기능의 최초 사용자 중 하나였으며 Chrome 직원은 현재 BPF의 새 버전을 기반으로 KRSI 메커니즘을 개발하고 Linux 보안 모듈의 사용자 정의를 허용하고 있습니다.) 추가 문서에 대한 링크는 끝에서 찾을 수 있습니다. 기사의.

seccomp 사용에 대한 기사가 이미 허브에 있으므로 다음 하위 섹션을 읽기 전에(또는 대신) 읽어보고 싶어할 수도 있습니다. 기사에서 컨테이너 및 보안: seccomp 2007 버전과 BPF를 사용하는 버전(libseccomp를 사용하여 필터가 생성됨)의 seccomp 사용 예제를 제공하고 seccomp와 Docker의 연결에 대해 설명하며 많은 유용한 링크도 제공합니다. 기사에서 systemd를 사용하여 데몬을 격리하거나 “이 작업에는 Docker가 필요하지 않습니다!” 특히 systemd를 실행하는 데몬에 대한 시스템 호출의 블랙리스트 또는 화이트리스트를 추가하는 방법을 다룹니다.

다음으로 필터를 작성하고 로드하는 방법을 살펴보겠습니다. seccomp 베어 C에서 라이브러리 사용 libseccomp 각 옵션의 장단점은 무엇이며, 마지막으로 프로그램에서 seccomp가 어떻게 사용되는지 살펴보겠습니다. strace.

seccomp용 필터 작성 및 로드

우리는 이미 BPF 프로그램을 작성하는 방법을 알고 있으므로 먼저 seccomp 프로그래밍 인터페이스를 살펴보겠습니다. 프로세스 수준에서 필터를 설정할 수 있으며 모든 하위 프로세스는 제한 사항을 상속합니다. 이는 시스템 호출을 사용하여 수행됩니다. seccomp(2):

seccomp(SECCOMP_SET_MODE_FILTER, flags, &filter)

어디에서 &filter - 이것은 우리에게 이미 친숙한 구조에 대한 포인터입니다. struct sock_fprog, 즉. BPF 프로그램.

seccomp 프로그램은 소켓 프로그램과 어떻게 다릅니까? 전송된 컨텍스트. 소켓의 경우 패킷을 포함하는 메모리 영역이 주어졌고 seccomp의 경우 다음과 같은 구조가 주어졌습니다.

struct seccomp_data {
    int   nr;
    __u32 arch;
    __u64 instruction_pointer;
    __u64 args[6];
};

여기에 nr 시작할 시스템 호출의 번호입니다. arch - 현재 아키텍처(자세한 내용은 아래 참조) args - 최대 XNUMX개의 시스템 호출 인수 instruction_pointer 시스템 호출을 수행한 사용자 공간 명령에 대한 포인터입니다. 따라서 예를 들어 시스템 호출 번호를 레지스터에 로드하려면 A 우리는 말해야

ldw [0]

seccomp 프로그램에는 다른 기능이 있습니다. 예를 들어 컨텍스트는 32비트 정렬로만 액세스할 수 있으며 필터를 로드하려고 할 때 반 단어 또는 바이트를 로드할 수 없습니다. ldh [0] 시스템 호출 seccomp 돌아올 것이다 EINVAL. 이 함수는 로드된 필터를 확인합니다. seccomp_check_filter() 커널. (재미있는 점은 seccomp 기능을 추가한 원래 커밋에서 이 기능에 명령을 사용할 수 있는 권한을 추가하는 것을 잊어버렸다는 것입니다. mod (나누기 나머지) 추가 이후 seccomp BPF 프로그램에는 사용할 수 없습니다. 부서질 것이다 ABI.)

기본적으로 우리는 seccomp 프로그램을 작성하고 읽는 데 필요한 모든 것을 이미 알고 있습니다. 일반적으로 프로그램 로직은 시스템 호출의 화이트 또는 블랙 리스트로 배열됩니다.

ld [0]
jeq #304, bad
jeq #176, bad
jeq #239, bad
jeq #279, bad
good: ret #0x7fff0000 /* SECCOMP_RET_ALLOW */
bad: ret #0

304, 176, 239, 279번으로 번호가 매겨진 XNUMX개의 시스템 호출의 블랙리스트를 확인합니다. 이 시스템 호출은 무엇입니까? 프로그램이 어떤 아키텍처를 위해 작성되었는지 모르기 때문에 확실히 말할 수 없습니다. 따라서 seccomp의 저자는 제공 아키텍처 검사로 모든 ​​프로그램을 시작합니다(현재 아키텍처는 컨텍스트에 필드로 표시됩니다). arch 구조 struct seccomp_data). 아키텍처를 확인한 경우 예제의 시작 부분은 다음과 같습니다.

ld [4]
jne #0xc000003e, bad_arch ; SCMP_ARCH_X86_64

그러면 시스템 호출 번호가 특정 값을 얻게 됩니다.

다음을 사용하여 seccomp에 대한 필터를 작성하고 로드합니다. libseccomp

네이티브 코드 또는 BPF 어셈블리에 필터를 작성하면 결과를 완전히 제어할 수 있지만 동시에 이식 가능하고/또는 읽을 수 있는 코드를 사용하는 것이 더 나은 경우도 있습니다. 도서관이 우리를 도와줄 거예요 libseccomp, 흑백 필터 작성을 위한 표준 인터페이스를 제공합니다.

예를 들어, 이전에 시스템 호출 블랙리스트를 설치한 후 사용자가 선택한 바이너리 파일을 실행하는 프로그램을 작성해 보겠습니다. 위의 기사 (가독성을 높이기 위해 프로그램이 단순화되었습니다. 전체 버전을 찾을 수 있습니다. 여기에):

#include <seccomp.h>
#include <unistd.h>
#include <err.h>

static int sys_numbers[] = {
        __NR_mount,
        __NR_umount2,
       // ... еще 40 системных вызовов ...
        __NR_vmsplice,
        __NR_perf_event_open,
};

int main(int argc, char **argv)
{
        scmp_filter_ctx ctx = seccomp_init(SCMP_ACT_ALLOW);

        for (size_t i = 0; i < sizeof(sys_numbers)/sizeof(sys_numbers[0]); i++)
                seccomp_rule_add(ctx, SCMP_ACT_TRAP, sys_numbers[i], 0);

        seccomp_load(ctx);

        execvp(argv[1], &argv[1]);
        err(1, "execlp: %s", argv[1]);
}

먼저 배열을 정의합니다. sys_numbers 차단할 시스템 호출 번호가 40개 이상입니다. 그런 다음 컨텍스트를 초기화합니다. ctx 그리고 우리가 무엇을 허용하고 싶은지 라이브러리에 알려주세요(SCMP_ACT_ALLOW) 기본적으로 모든 시스템 호출(블랙리스트를 작성하는 것이 더 쉽습니다). 그런 다음 블랙리스트의 모든 시스템 호출을 하나씩 추가합니다. 목록의 시스템 호출에 대한 응답으로 우리는 다음을 요청합니다. SCMP_ACT_TRAP, 이 경우 seccomp는 프로세스에 신호를 보냅니다. SIGSYS 어떤 시스템 호출이 규칙을 위반했는지에 대한 설명과 함께. 마지막으로 다음을 사용하여 프로그램을 커널에 로드합니다. seccomp_load, 프로그램을 컴파일하고 시스템 호출을 사용하여 프로세스에 연결합니다. seccomp(2).

성공적인 컴파일을 위해서는 프로그램이 라이브러리와 연결되어야 합니다. libseccomp예 :

cc -std=c17 -Wall -Wextra -c -o seccomp_lib.o seccomp_lib.c
cc -o seccomp_lib seccomp_lib.o -lseccomp

성공적인 출시의 예:

$ ./seccomp_lib echo ok
ok

차단된 시스템 호출의 예:

$ sudo ./seccomp_lib mount -t bpf bpf /tmp
Bad system call

우리는 사용 strace자세한 내용은 다음을 참조하세요.

$ sudo strace -e seccomp ./seccomp_lib mount -t bpf bpf /tmp
seccomp(SECCOMP_SET_MODE_FILTER, 0, {len=50, filter=0x55d8e78428e0}) = 0
--- SIGSYS {si_signo=SIGSYS, si_code=SYS_SECCOMP, si_call_addr=0xboobdeadbeef, si_syscall=__NR_mount, si_arch=AUDIT_ARCH_X86_64} ---
+++ killed by SIGSYS (core dumped) +++
Bad system call

불법적인 시스템 호출로 인해 프로그램이 종료되었는지 어떻게 알 수 있나요? mount(2).

그래서 우리는 라이브러리를 사용하여 필터를 작성했습니다. libseccomp, 사소하지 않은 코드를 네 줄에 맞추는 것입니다. 위의 예에서 시스템 호출이 많은 경우에는 비교 목록에 불과하므로 실행 시간이 눈에 띄게 줄어들 수 있습니다. 최적화를 위해 libseccomp는 최근 패치 포함, 필터 속성에 대한 지원을 추가합니다. SCMP_FLTATR_CTL_OPTIMIZE. 이 속성을 2로 설정하면 필터가 이진 검색 프로그램으로 변환됩니다.

이진 검색 필터가 어떻게 작동하는지 보려면 다음을 살펴보세요. 간단한 스크립트, 시스템 호출 번호를 다이얼링하여 BPF 어셈블러에서 이러한 프로그램을 생성합니다. 예:

$ echo 1 3 6 8 13 | ./generate_bin_search_bpf.py
ld [0]
jeq #6, bad
jgt #6, check8
jeq #1, bad
jeq #3, bad
ret #0x7fff0000
check8:
jeq #8, bad
jeq #13, bad
ret #0x7fff0000
bad: ret #0

BPF 프로그램은 들여쓰기 점프를 수행할 수 없기 때문에 훨씬 더 빠르게 작성할 수는 없습니다(예를 들어 다음과 같이 할 수 없습니다). jmp A 또는 jmp [label+X]) 따라서 모든 전환은 정적입니다.

seccomp 및 strace

모두가 유틸리티를 알고 있습니다. strace Linux에서 프로세스의 동작을 연구하는 데 없어서는 안될 도구입니다. 그러나 많은 사람들이 성능 문제 이 유틸리티를 사용할 때. 사실은 strace 사용하여 구현 ptrace(2), 이 메커니즘에서는 프로세스를 중지하는 데 필요한 시스템 호출 세트(예: 명령)를 지정할 수 없습니다.

$ time strace du /usr/share/ >/dev/null 2>&1

real    0m3.081s
user    0m0.531s
sys     0m2.073s

и

$ time strace -e open du /usr/share/ >/dev/null 2>&1

real    0m2.404s
user    0m0.193s
sys     0m1.800s

두 번째 경우에는 단 하나의 시스템 호출만 추적하려고 하지만 거의 동시에 처리됩니다.

새로운 옵션 --seccomp-bpf에 추가 strace 버전 5.3을 사용하면 프로세스 속도를 여러 번 높일 수 있으며 하나의 시스템 호출 추적에 따른 시작 시간은 이미 일반 시작 시간과 비슷합니다.

$ time strace --seccomp-bpf -e open du /usr/share/ >/dev/null 2>&1

real    0m0.148s
user    0m0.017s
sys     0m0.131s

$ time du /usr/share/ >/dev/null 2>&1

real    0m0.140s
user    0m0.024s
sys     0m0.116s

(물론 여기에는 이 명령의 기본 시스템 호출을 추적하지 않는다는 점에서 약간의 속임수가 있습니다. 예를 들어, newfsstat, 그런 다음 strace 없는 것만큼 세게 브레이크를 밟을 것이다 --seccomp-bpf.)

이 옵션은 어떻게 작동하나요? 그녀없이 strace 프로세스에 연결하고 다음을 사용하여 시작합니다. PTRACE_SYSCALL. 관리되는 프로세스가 (모든) 시스템 호출을 발행하면 제어가 다음 프로세스로 이전됩니다. strace, 시스템 호출의 인수를 살펴보고 다음과 같이 실행합니다. PTRACE_SYSCALL. 일정 시간이 지난 후 프로세스는 시스템 호출을 완료하고 종료하면 제어가 다시 전송됩니다. strace, 반환 값을 보고 다음을 사용하여 프로세스를 시작합니다. PTRACE_SYSCALL, 등등.

그러나 seccomp를 사용하면 이 프로세스를 우리가 원하는 대로 정확하게 최적화할 수 있습니다. 즉, 시스템 콜만 보고 싶다면 X, 그런 다음 BPF 필터를 작성할 수 있습니다. X 값을 반환 SECCOMP_RET_TRACE, 그리고 우리에게 관심이 없는 전화의 경우 - SECCOMP_RET_ALLOW:

ld [0]
jneq #X, ignore
trace: ret #0x7ff00000
ignore: ret #0x7fff0000

이 경우 strace 처음에는 다음과 같이 프로세스를 시작합니다. PTRACE_CONT, 시스템 호출이 그렇지 않은 경우 필터는 각 시스템 호출에 대해 처리됩니다. X, 프로세스는 계속 실행되지만, X, seccomp가 제어권을 이전합니다. strace인수를 보고 다음과 같은 프로세스를 시작합니다. PTRACE_SYSCALL (seccomp에는 시스템 호출 종료 시 프로그램을 실행할 수 있는 기능이 없기 때문입니다.) 시스템 호출이 반환되면 strace 다음을 사용하여 프로세스를 다시 시작합니다. PTRACE_CONT seccomp의 새 메시지를 기다립니다.

옵션 사용시 --seccomp-bpf 두 가지 제한 사항이 있습니다. 첫째, 이미 존재하는 프로세스에 참여할 수 없습니다(옵션 -p 프로그램 strace), 이는 seccomp에서 지원되지 않기 때문입니다. 둘째, 가능성이 없다 아니 하위 프로세스를 살펴보십시오. seccomp 필터는 이를 비활성화할 수 있는 기능 없이 모든 하위 프로세스에 의해 상속되기 때문입니다.

정확히 어떻게 되는지 좀 더 자세히 strace 와 일하다 seccomp 에서 찾을 수 있습니다 최근 보고서. 우리에게 가장 흥미로운 사실은 seccomp로 대표되는 클래식 BPF가 오늘날에도 여전히 사용되고 있다는 것입니다.

xt_bpf

이제 네트워크의 세계로 돌아가 보겠습니다.

배경: 오래전인 2007년에 핵심은 추가 모듈 xt_u32 넷필터용. 훨씬 더 오래된 트래픽 분류기와 유사하게 작성되었습니다. cls_u32 다음과 같은 간단한 작업을 사용하여 iptables에 대한 임의의 이진 규칙을 작성할 수 있습니다. 패키지에서 32비트를 로드하고 이에 대해 일련의 산술 작업을 수행합니다. 예를 들어,

sudo iptables -A INPUT -m u32 --u32 "6&0xFF=1" -j LOG --log-prefix "seen-by-xt_u32"

패딩 32부터 시작하여 IP 헤더의 6비트를 로드하고 여기에 마스크를 적용합니다. 0xFF (낮은 바이트를 취함) 이 필드 protocol IP 헤더를 1(ICMP)과 비교합니다. 여러 검사를 하나의 규칙으로 결합할 수 있으며 연산자를 실행할 수도 있습니다. @ — X바이트를 오른쪽으로 이동합니다. 예를 들어, 규칙

iptables -m u32 --u32 "6&0xFF=0x6 && 0>>22&0x3C@4=0x29"

TCP 시퀀스 번호가 같지 않은지 확인합니다. 0x29. 그러한 규칙을 직접 작성하는 것이 그다지 편리하지 않다는 것이 이미 분명하기 때문에 더 자세히 설명하지 않겠습니다. 기사에서 BPF - 잊혀진 바이트코드, 에 대한 사용 및 규칙 생성 예가 포함된 여러 링크가 있습니다. xt_u32. 이 글 마지막에 있는 링크도 참조하세요.

2013년부터 모듈 대신 모듈 xt_u32 BPF 기반 모듈을 사용할 수 있습니다 xt_bpf. 여기까지 읽은 사람이라면 누구나 BPF 바이트코드를 iptables 규칙으로 실행하는 작동 원리에 대해 이미 명확하게 알고 있을 것입니다. 예를 들어 다음과 같이 새 규칙을 만들 수 있습니다.

iptables -A INPUT -m bpf --bytecode <байткод> -j LOG

여기에 <байткод> - 이것은 어셈블러 출력 형식의 코드입니다. bpf_asm 예를 들어 기본적으로

$ cat /tmp/test.bpf
ldb [9]
jneq #17, ignore
ret #1
ignore: ret #0

$ bpf_asm /tmp/test.bpf
4,48 0 0 9,21 0 1 17,6 0 0 1,6 0 0 0,

# iptables -A INPUT -m bpf --bytecode "$(bpf_asm /tmp/test.bpf)" -j LOG

이 예에서는 모든 UDP 패킷을 필터링합니다. 모듈의 BPF 프로그램에 대한 컨텍스트 xt_bpf는 물론 iptables의 경우 IPv4 헤더의 시작 부분을 가리키는 패킷 데이터를 가리킵니다. BPF 프로그램의 반환 값 부울어디에서 false 패킷이 일치하지 않음을 의미합니다.

모듈이 분명합니다. xt_bpf 위의 예보다 더 복잡한 필터를 지원합니다. Cloudfare의 실제 사례를 살펴보겠습니다. 최근까지 그들은 모듈을 사용했습니다. xt_bpf DDoS 공격으로부터 보호합니다. 기사에서 BPF 도구 소개 BPF 필터를 생성하는 방법(및 이유)을 설명하고 이러한 필터를 생성하기 위한 유틸리티 세트에 대한 링크를 게시합니다. 예를 들어 유틸리티를 사용하면 bpfgen 이름에 대한 DNS 쿼리와 일치하는 BPF 프로그램을 만들 수 있습니다 habr.com:

$ ./bpfgen --assembly dns -- habr.com
ldx 4*([0]&0xf)
ld #20
add x
tax

lb_0:
    ld [x + 0]
    jneq #0x04686162, lb_1
    ld [x + 4]
    jneq #0x7203636f, lb_1
    ldh [x + 8]
    jneq #0x6d00, lb_1
    ret #65535

lb_1:
    ret #0

프로그램에서 먼저 레지스터에 로드합니다. X 줄 주소의 시작 x04habrx03comx00 UDP 데이터그램 내부에서 요청을 확인합니다. 0x04686162 <-> "x04hab" 기타

잠시 후 Cloudfare는 p0f -> BPF 컴파일러 코드를 게시했습니다. 기사에서 p0f BPF 컴파일러 소개 그들은 p0f가 무엇인지, p0f 서명을 BPF로 변환하는 방법에 대해 이야기합니다.

$ ./bpfgen p0f -- 4:64:0:0:*,0::ack+:0
39,0 0 0 0,48 0 0 8,37 35 0 64,37 0 34 29,48 0 0 0,
84 0 0 15,21 0 31 5,48 0 0 9,21 0 29 6,40 0 0 6,
...

현재 더 이상 Cloudfare를 사용하지 않습니다. xt_bpf, 새로운 버전의 BPF를 사용하기 위한 옵션 중 하나인 XDP로 이동했기 때문에 참조하세요. L4Drop: XDP DDoS 완화.

cls_bpf

커널에서 클래식 BPF를 사용하는 마지막 예는 분류자입니다. cls_bpf Linux의 트래픽 제어 하위 시스템용으로 2013년 말에 Linux에 추가되었으며 개념적으로 고대 하위 시스템을 대체합니다. cls_u32.

하지만 지금은 작품에 대해 설명하지 않겠습니다. cls_bpf, 클래식 BPF에 대한 지식의 관점에서 볼 때 이것은 우리에게 아무것도 제공하지 않기 때문에 우리는 이미 모든 기능에 익숙해졌습니다. 또한 확장 BPF에 대해 설명하는 후속 기사에서는 이 분류자를 두 번 이상 만날 것입니다.

클래식 BPF c 사용에 대해 이야기하지 않는 또 다른 이유 cls_bpf 문제는 확장 BPF와 비교할 때 이 경우 적용 범위가 근본적으로 좁아진다는 것입니다. 기존 프로그램은 패키지의 내용을 변경할 수 없으며 호출 간에 상태를 저장할 수 없습니다.

이제 클래식 BPF에 작별을 고하고 미래를 바라볼 때입니다.

클래식 BPF와 작별

우리는 32년대 초반에 개발된 BPF 기술이 어떻게 64년 동안 성공적으로 살아남았고 마지막까지 새로운 응용 분야를 찾았는지 살펴보았습니다. 그러나 스택 머신에서 RISC로의 전환이 클래식 BPF 개발의 원동력이 되었던 것처럼, XNUMX년대에는 XNUMX비트 머신에서 XNUMX비트 머신으로의 전환이 있었고 클래식 BPF는 쓸모없게 되기 시작했습니다. 또한 클래식 BPF의 기능은 매우 제한적이며 오래된 아키텍처 외에도 BPF 프로그램 호출 사이에 상태를 저장하는 기능이 없으며 직접적인 사용자 상호 작용 가능성이 없으며 상호 작용할 가능성이 없습니다. 제한된 수의 구조 필드를 읽는 것을 제외하고 커널과 함께 sk_buff 가장 간단한 도우미 기능을 실행하면 패킷의 내용을 변경하고 리디렉션할 수 없습니다.

실제로 현재 Linux에 남아 있는 클래식 BPF는 API 인터페이스뿐입니다. 커널 내부에서는 소켓 필터나 seccomp 필터 등 모든 클래식 프로그램이 자동으로 새로운 형식인 확장 BPF로 변환됩니다. (이것이 어떻게 발생하는지에 대해서는 다음 기사에서 자세히 설명하겠습니다.)

새로운 아키텍처로의 전환은 Alexey Starovoitov가 BPF 업데이트 체계를 제안한 2013년에 시작되었습니다. 2014년에 해당 패치 나타나기 시작했다 핵심에. 내가 아는 한, 원래 계획은 64비트 시스템에서 더 효율적으로 실행되도록 아키텍처와 JIT 컴파일러를 최적화하는 것뿐이었지만, 대신 이러한 최적화는 Linux 개발의 새로운 장의 시작을 의미했습니다.

이 시리즈의 추가 기사에서는 처음에는 내부 BPF, 확장 BPF, 지금은 단순히 BPF로 알려진 새로운 기술의 아키텍처와 애플리케이션을 다룰 것입니다.

참조

1. Steven McCanne 및 Van Jacobson, "BSD 패킷 필터: 사용자 수준 패킷 캡처를 위한 새로운 아키텍처", https://www.tcpdump.org/papers/bpf-usenix93.pdf
2. Steven McCanne, "libpcap: 패킷 캡처를 위한 아키텍처 및 최적화 방법론", https://sharkfestus.wireshark.org/sharkfest.11/presentations/McCanne-Sharkfest'11_Keynote_Address.pdf
3. tcpdump, libpcap: https://www.tcpdump.org/
4. IPtable U32 경기 튜토리얼.
5. BPF - 잊혀진 바이트코드: https://blog.cloudflare.com/bpf-the-forgotten-bytecode/
6. BPF 도구 소개: https://blog.cloudflare.com/introducing-the-bpf-tools/
7. bpf_cls: http://man7.org/linux/man-pages/man8/tc-bpf.8.html
8. seccomp 개요: https://lwn.net/Articles/656307/
9. https://github.com/torvalds/linux/blob/master/Documentation/userspace-api/seccomp_filter.rst
10. habr: 컨테이너 및 보안: seccomp
11. habr: systemd로 데몬을 격리하거나 "이 작업에는 Docker가 필요하지 않습니다!"
12. Paul Chaignon, "strace --seccomp-bpf: 내부 살펴보기", https://fosdem.org/2020/schedule/event/debugging_strace_bpf/
13. netsniff-ng: http://netsniff-ng.org/

출처 : habr.com