🥇XDP에 대한 DDoS 공격에 대한 보호 기능을 작성하고 있습니다. 원자력 부품

eXpress Data Path(XDP) 기술을 사용하면 패킷이 커널 네트워크 스택에 들어가기 전에 Linux 인터페이스에서 임의 트래픽 처리가 수행될 수 있습니다. XDP 적용 - DDoS 공격(CloudFlare), 복잡한 필터, 통계 수집(Netflix)으로부터 보호합니다. XDP 프로그램은 eBPF 가상 머신에 의해 실행되므로 필터 유형에 따라 코드와 사용 가능한 커널 기능 모두에 제한이 있습니다.

이 기사는 XDP의 수많은 자료의 단점을 보완하기 위해 작성되었습니다. 첫째, XDP의 기능을 즉시 우회하는 기성 코드를 제공합니다. 검증을 위해 준비되었거나 문제를 일으키기에는 너무 간단합니다. 그런 다음 처음부터 코드를 작성하려고 하면 일반적인 오류를 어떻게 해야 할지 전혀 알 수 없습니다. 둘째, 자체적인 함정이 있음에도 불구하고 VM 및 하드웨어 없이 로컬에서 XDP를 테스트하는 방법은 다루지 않습니다. 이 텍스트는 네트워킹 및 Linux에 익숙하고 XDP 및 eBPF에 관심이 있는 프로그래머를 대상으로 합니다.

이 부분에서는 XDP 필터가 어떻게 구성되고 테스트하는 방법을 자세히 이해한 다음 패킷 처리 수준에서 잘 알려진 SYN 쿠키 메커니즘의 간단한 버전을 작성하겠습니다. 아직 "화이트리스트"를 만들지 않습니다
검증된 클라이언트, 카운터 유지 및 필터 관리 - 충분한 로그.

우리는 C로 작성할 것입니다. 유행은 아니지만 실용적입니다. 모든 코드는 마지막 링크를 통해 GitHub에서 사용할 수 있으며 기사에 설명된 단계에 따라 커밋으로 나뉩니다.

부인 성명. 이 기사를 진행하면서 DDoS 공격을 방지하기 위한 미니 솔루션을 개발할 것입니다. 이는 XDP와 제 전문 분야에 대한 현실적인 작업이기 때문입니다. 그러나 주요 목표는 기술을 이해하는 것이며 이는 기성 보호 장치를 만드는 데 대한 지침이 아닙니다. 튜토리얼 코드는 최적화되지 않았으며 약간의 뉘앙스가 생략되었습니다.

XDP 개요

문서와 기존 기사가 중복되지 않도록 핵심 사항만 간략하게 설명하겠습니다.

따라서 필터 코드가 커널에 로드됩니다. 들어오는 패킷은 필터로 전달됩니다. 결과적으로 필터는 다음과 같은 결정을 내려야 합니다. 패킷을 커널로 전달합니다(XDP_PASS), 패킷 삭제(XDP_DROP) 또는 다시 보내십시오(XDP_TX). 필터는 패키지를 변경할 수 있으며 특히 다음과 같은 경우에 해당됩니다. XDP_TX. 프로그램을 중단할 수도 있습니다(XDP_ABORTED) 패키지를 재설정하지만 이는 유사합니다. assert(0) - 디버깅을 위해.

eBPF(extended Berkley Packet Filter) 가상 머신은 코드가 반복되지 않고 다른 사람의 메모리를 손상시키지 않는지 커널이 확인할 수 있도록 의도적으로 단순하게 만들어졌습니다. 누적 제한 및 검사:

루프(역방향)는 금지됩니다.
데이터용 스택은 있지만 함수는 없습니다(모든 C 함수는 인라인되어야 함).
스택 및 패킷 버퍼 외부의 메모리 액세스는 금지됩니다.
코드 크기는 제한되어 있지만 실제로는 그다지 중요하지 않습니다.
특수 커널 함수(eBPF 도우미)에 대한 호출만 허용됩니다.

필터를 설계하고 설치하는 방법은 다음과 같습니다.

소스 코드(예: kernel.c)는 객체(kernel.o) eBPF 가상 머신 아키텍처의 경우. 2019년 10.1월 현재 eBPF 컴파일은 Clang에서 지원되며 GCC XNUMX에서 약속됩니다.
이 개체 코드에 커널 구조(예: 테이블 및 카운터)에 대한 호출이 포함된 경우 해당 ID는 XNUMX으로 대체됩니다. 이는 해당 코드를 실행할 수 없음을 의미합니다. 커널에 로드하기 전에 이러한 XNUMX을 커널 호출(코드 링크)을 통해 생성된 특정 개체의 ID로 바꿔야 합니다. 외부 유틸리티를 사용하여 이를 수행할 수도 있고 특정 필터를 연결하고 로드하는 프로그램을 작성할 수도 있습니다.
커널은 로드된 프로그램을 확인합니다. 주기가 없고 패킷 및 스택 경계를 초과하지 못하는지 확인합니다. 검증자가 코드가 정확하다는 것을 증명할 수 없으면 프로그램이 거부됩니다. 검증자를 기쁘게 할 수 있어야 합니다.
성공적으로 검증된 후 커널은 eBPF 아키텍처 개체 코드를 시스템 아키텍처용 기계어 코드(적시)로 컴파일합니다.
프로그램이 인터페이스에 연결되고 패킷 처리를 시작합니다.

XDP는 커널에서 실행되므로 추적 로그와 실제로 프로그램이 필터링하거나 생성하는 패킷을 사용하여 디버깅이 수행됩니다. 그러나 eBPF는 다운로드한 코드가 시스템에 대해 안전한지 확인하므로 로컬 Linux에서 직접 XDP를 실험할 수 있습니다.

환경 준비

조립

Clang은 eBPF 아키텍처에 대한 객체 코드를 직접 생성할 수 없으므로 프로세스는 다음 두 단계로 구성됩니다.

C 코드를 LLVM 바이트코드로 컴파일합니다(clang -emit-llvm).
바이트코드를 eBPF 객체 코드로 변환(llc -march=bpf -filetype=obj).

필터를 작성할 때 보조 기능과 매크로가 포함된 몇 개의 파일이 유용할 것입니다. 커널 테스트에서. 커널 버전(KVER). 다음 위치에 다운로드하세요. helpers/:

export KVER=v5.3.7
export BASE=https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/plain/tools/testing/selftests/bpf
wget -P helpers --content-disposition "${BASE}/bpf_helpers.h?h=${KVER}" "${BASE}/bpf_endian.h?h=${KVER}"
unset KVER BASE

Arch Linux용 Makefile(커널 5.3.7):

CLANG ?= clang
LLC ?= llc

KDIR ?= /lib/modules/$(shell uname -r)/build
ARCH ?= $(subst x86_64,x86,$(shell uname -m))

CFLAGS = 
    -Ihelpers 
    
    -I$(KDIR)/include 
    -I$(KDIR)/include/uapi 
    -I$(KDIR)/include/generated/uapi 
    -I$(KDIR)/arch/$(ARCH)/include 
    -I$(KDIR)/arch/$(ARCH)/include/generated 
    -I$(KDIR)/arch/$(ARCH)/include/uapi 
    -I$(KDIR)/arch/$(ARCH)/include/generated/uapi 
    -D__KERNEL__ 
    
    -fno-stack-protector -O2 -g

xdp_%.o: xdp_%.c Makefile
    $(CLANG) -c -emit-llvm $(CFLAGS) $< -o - | 
    $(LLC) -march=bpf -filetype=obj -o $@

.PHONY: all clean

all: xdp_filter.o

clean:
    rm -f ./*.o

KDIR 커널 헤더에 대한 경로를 포함합니다. ARCH - 시스템 구조. 경로와 도구는 배포판마다 약간 다를 수 있습니다.

Debian 10(커널 4.19.67)의 차이점 예

# другая команда
CLANG ?= clang
LLC ?= llc-7

# другой каталог
KDIR ?= /usr/src/linux-headers-$(shell uname -r)
ARCH ?= $(subst x86_64,x86,$(shell uname -m))

# два дополнительных каталога -I
CFLAGS = 
    -Ihelpers 
    
    -I/usr/src/linux-headers-4.19.0-6-common/include 
    -I/usr/src/linux-headers-4.19.0-6-common/arch/$(ARCH)/include 
    # далее без изменений

CFLAGS 보조 헤더가 있는 디렉터리와 커널 헤더가 있는 여러 디렉터리를 연결합니다. 상징 __KERNEL__ 필터가 커널에서 실행되므로 UAPI(사용자 공간 API) 헤더가 커널 코드에 정의되어 있음을 의미합니다.

스택 보호를 비활성화할 수 있습니다(-fno-stack-protector), eBPF 코드 검증기는 여전히 스택 범위 위반 위반을 확인하기 때문입니다. eBPF 바이트코드의 크기가 제한되어 있으므로 즉시 최적화를 활성화하는 것이 좋습니다.

모든 패킷을 통과하고 아무 작업도 수행하지 않는 필터부터 시작해 보겠습니다.

#include <uapi/linux/bpf.h>

#include <bpf_helpers.h>

SEC("prog")
int xdp_main(struct xdp_md* ctx) {
    return XDP_PASS;
}

char _license[] SEC("license") = "GPL";

팀 make 수집하다 xdp_filter.o. 지금 어디에서 시험해 볼 수 있나요?

테스트 벤치

스탠드에는 필터가 있는 인터페이스와 패킷이 전송되는 인터페이스 두 개가 포함되어야 합니다. 일반 애플리케이션이 필터와 어떻게 작동하는지 확인하려면 자체 IP를 갖춘 완전한 Linux 장치여야 합니다.

veth(가상 이더넷) 유형의 장치는 우리에게 적합합니다. 이는 서로 직접 "연결된" 가상 네트워크 인터페이스 쌍입니다. 다음과 같이 만들 수 있습니다(이 섹션에서는 모든 명령을 ip 에서 수행됩니다 root):

ip link add xdp-remote type veth peer name xdp-local

여기에 xdp-remote и xdp-local — 장치 이름. ~에 xdp-local (192.0.2.1/24) 필터가 부착됩니다. xdp-remote (192.0.2.2/24) 들어오는 트래픽이 전송됩니다. 그러나 문제가 있습니다. 인터페이스가 동일한 시스템에 있고 Linux는 다른 인터페이스를 통해 둘 중 하나로 트래픽을 보내지 않습니다. 까다로운 규칙으로 이 문제를 해결할 수 있습니다. iptables, 그러나 패키지를 변경해야 하므로 디버깅이 불편합니다. 네트워크 네임스페이스(이하 netns)를 사용하는 것이 더 좋습니다.

네트워크 네임스페이스에는 다른 netns의 유사한 개체와 격리된 일련의 인터페이스, 라우팅 테이블 및 NetFilter 규칙이 포함되어 있습니다. 각 프로세스는 네임스페이스에서 실행되며 해당 netns의 개체에만 액세스할 수 있습니다. 기본적으로 시스템에는 모든 개체에 대한 단일 네트워크 네임스페이스가 있으므로 Linux에서 작업할 수 있으며 netns에 대해서는 알 수 없습니다.

새 네임스페이스를 만들어 보겠습니다. xdp-test 그리고 거기로 옮겨 xdp-remote.

ip netns add xdp-test
ip link set dev xdp-remote netns xdp-test

그런 다음 실행중인 프로세스 xdp-test, "보지" 않을 것입니다 xdp-local (기본적으로 netns에 남아 있습니다.) 192.0.2.1로 패킷을 보낼 때 이를 통과합니다. xdp-remote이는 이 프로세스에 액세스할 수 있는 192.0.2.0/24의 유일한 인터페이스이기 때문입니다. 이것은 반대 방향으로도 작동합니다.

netns 사이를 이동할 때 인터페이스가 다운되고 주소가 손실됩니다. netns에서 인터페이스를 구성하려면 다음을 실행해야 합니다. ip ... 이 명령 네임스페이스에서 ip netns exec:

ip netns exec xdp-test 
    ip address add 192.0.2.2/24 dev xdp-remote
ip netns exec xdp-test 
    ip link set xdp-remote up

보시다시피 설정과 다르지 않습니다. xdp-local 기본 네임스페이스에서:

    ip address add 192.0.2.1/24 dev xdp-local
    ip link set xdp-local up

당신이 실행하는 경우 tcpdump -tnevi xdp-local, 다음에서 보낸 패킷을 볼 수 있습니다. xdp-test, 이 인터페이스로 전달됩니다.

ip netns exec xdp-test   ping 192.0.2.1

쉘을 실행하는 것이 편리합니다. xdp-test. 저장소에는 스탠드 작업을 자동화하는 스크립트가 있습니다. 예를 들어 다음 명령을 사용하여 스탠드를 구성할 수 있습니다. sudo ./stand up 그리고 삭제해 sudo ./stand down.

트레이싱

필터는 다음과 같이 장치와 연결됩니다.

ip -force link set dev xdp-local xdp object xdp_filter.o verbose

열쇠 -force 다른 프로그램이 이미 연결되어 있는 경우 새 프로그램을 연결해야 합니다. “무소식은 좋은 소식이다”는 이 명령에 관한 것이 아니며, 어쨌든 결론은 방대합니다. 나타내다 verbose 선택 사항이지만 이를 사용하면 어셈블리 목록과 함께 코드 검증기 작업에 대한 보고서가 나타납니다.

Verifier analysis:

0: (b7) r0 = 2
1: (95) exit

인터페이스에서 프로그램 연결을 해제합니다.

ip link set dev xdp-local xdp off

스크립트에서 다음은 명령입니다. sudo ./stand attach и sudo ./stand detach.

필터를 부착하면 확인할 수 있습니다. ping 계속 실행되지만 프로그램이 작동합니까? 로그를 추가해 보겠습니다. 기능 bpf_trace_printk() 비슷하다 printf()이지만 패턴 외에 최대 XNUMX개의 인수와 제한된 지정자 목록만 지원합니다. 매크로 bpf_printk() 통화를 단순화합니다.

   SEC("prog")
   int xdp_main(struct xdp_md* ctx) {
+      bpf_printk("got packet: %pn", ctx);
       return XDP_PASS;
   }

출력은 활성화되어야 하는 커널 추적 채널로 이동합니다.

echo -n 1 | sudo tee /sys/kernel/debug/tracing/options/trace_printk

메시지 스레드 보기:

cat /sys/kernel/debug/tracing/trace_pipe

이 두 명령 모두 호출을 수행합니다. sudo ./stand log.

이제 Ping은 다음과 같은 메시지를 트리거해야 합니다.

<...>-110930 [004] ..s1 78803.244967: 0: got packet: 00000000ac510377

검증기의 출력을 자세히 살펴보면 이상한 계산을 발견할 수 있습니다.

0: (bf) r3 = r1
1: (18) r1 = 0xa7025203a7465
3: (7b) *(u64 *)(r10 -8) = r1
4: (18) r1 = 0x6b63617020746f67
6: (7b) *(u64 *)(r10 -16) = r1
7: (bf) r1 = r10
8: (07) r1 += -16
9: (b7) r2 = 16
10: (85) call bpf_trace_printk#6
<...>

사실 eBPF 프로그램에는 데이터 섹션이 없으므로 형식 문자열을 인코딩하는 유일한 방법은 VM 명령의 즉각적인 인수입니다.

$ python -c "import binascii; print(bytes(reversed(binascii.unhexlify('0a7025203a74656b63617020746f67'))))"
b'got packet: %pn'

이러한 이유로 디버그 출력은 결과 코드를 크게 부풀립니다.

XDP 패킷 보내기

필터를 변경해 보겠습니다. 들어오는 모든 패킷을 다시 보내도록 하세요. 헤더의 주소를 변경해야 하기 때문에 네트워크 관점에서는 올바르지 않지만 이제 원칙적으로 작업이 중요합니다.

       bpf_printk("got packet: %pn", ctx);
-      return XDP_PASS;
+      return XDP_TX;
   }

시작하다 tcpdump 에 xdp-remote. 동일한 발신 및 수신 ICMP 에코 요청을 표시하고 ICMP 에코 응답 표시를 중지해야 합니다. 그러나 그것은 표시되지 않습니다. 그것은 일을 위해 밝혀졌습니다 XDP_TX 에 있는 프로그램에서 xdp-local 해야쌍 인터페이스로 xdp-remote 비어 있어도 프로그램도 할당되어 자랐습니다.

내가 이걸 어떻게 알았지?

커널에서 패키지 경로 추적 그런데 성능 이벤트 메커니즘을 사용하면 동일한 가상 머신을 사용할 수 있습니다. 즉, eBPF를 사용한 디스어셈블리에 eBPF가 사용됩니다.

악에서 선을 찾아야 합니다. 왜냐하면 악에서 선을 이끌어낼 다른 것이 없기 때문입니다.

$ sudo perf trace --call-graph dwarf -e 'xdp:*'
   0.000 ping/123455 xdp:xdp_bulk_tx:ifindex=19 action=TX sent=0 drops=1 err=-6
                                     veth_xdp_flush_bq ([veth])
                                     veth_xdp_flush_bq ([veth])
                                     veth_poll ([veth])
                                     <...>

코드 6이란 무엇입니까?

$ errno 6
ENXIO 6 No such device or address

기능 veth_xdp_flush_bq() 에서 오류 코드를 받습니다. veth_xdp_xmit(), 여기서 검색 ENXIO 그리고 댓글을 찾아보세요.

최소 필터를 복원해 보겠습니다(XDP_PASS) 파일에 있음 xdp_dummy.c, Makefile에 추가하고 바인딩하십시오. xdp-remote:

ip netns exec remote 
    ip link set dev int xdp object dummy.o

지금 tcpdump 예상되는 내용을 보여줍니다.

62:57:8e:70:44:64 > 26:0e:25:37:8f:96, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 13762, offset 0, flags [DF], proto ICMP (1), length 84)
    192.0.2.2 > 192.0.2.1: ICMP echo request, id 46966, seq 1, length 64
62:57:8e:70:44:64 > 26:0e:25:37:8f:96, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 13762, offset 0, flags [DF], proto ICMP (1), length 84)
    192.0.2.2 > 192.0.2.1: ICMP echo request, id 46966, seq 1, length 64

대신 ARP만 표시되는 경우 필터를 제거해야 합니다. sudo ./stand detach), 가자 ping을 탭한 다음 필터를 설정하고 다시 시도하세요. 문제는 필터가 XDP_TX ARP와 스택 모두 유효합니다.
네임스페이스 xdp-test MAC 주소 192.0.2.1을 "잊어 버리면" 이 IP를 확인할 수 없습니다.

문제 성명

명시된 작업으로 넘어가겠습니다. XDP에 SYN 쿠키 메커니즘을 작성합니다.

SYN Flood는 여전히 널리 사용되는 DDoS 공격으로, 그 본질은 다음과 같습니다. 연결이 설정되면(TCP 핸드셰이크) 서버는 SYN을 수신하고 향후 연결을 위해 리소스를 할당하고 SYNACK 패킷으로 응답하고 ACK를 기다립니다. 공격자는 수천 개의 강력한 봇넷에 있는 각 호스트의 스푸핑된 주소에서 초당 수천 개의 SYN 패킷을 보냅니다. 서버는 패킷이 도착하자마자 강제로 자원을 할당하지만, 시간이 많이 초과된 후에 자원을 해제하므로 메모리나 제한이 모두 소모되고 새로운 연결이 허용되지 않으며 서비스를 사용할 수 없게 됩니다.

SYN 패킷을 기반으로 자원을 할당하지 않고 SYNACK 패킷으로만 응답한다면 나중에 도착한 ACK 패킷이 저장되지 않은 SYN 패킷임을 서버는 어떻게 이해할 수 있겠는가? 결국 공격자는 가짜 ACK를 생성할 수도 있습니다. SYN 쿠키의 요점은 이를 인코딩하는 것입니다. seqnum 주소, 포트 및 솔트 변경의 해시인 연결 매개변수입니다. 솔트가 변경되기 전에 ACK가 도착했다면 해시를 다시 계산하여 다음과 비교할 수 있습니다. acknum. 노 acknum 솔트에는 비밀이 포함되어 있고 제한된 채널로 인해 이를 분류할 시간이 없기 때문에 공격자는 그렇게 할 수 없습니다.

SYN 쿠키는 오랫동안 Linux 커널에서 구현되어 왔으며 SYN이 너무 빨리 대량으로 도착하는 경우 자동으로 활성화될 수도 있습니다.

TCP 핸드셰이크 교육 프로그램

TCP는 데이터 전송을 바이트 스트림으로 제공합니다. 예를 들어 HTTP 요청은 TCP를 통해 전송됩니다. 스트림은 패킷의 조각으로 전송됩니다. 모든 TCP 패킷에는 논리적 플래그와 32비트 시퀀스 번호가 있습니다.

플래그의 조합에 따라 특정 패키지의 역할이 결정됩니다. SYN 플래그는 이것이 연결에서 보낸 사람의 첫 번째 패킷임을 나타냅니다. ACK 플래그는 보낸 사람이 해당 바이트까지의 모든 연결 데이터를 수신했음을 의미합니다. acknum. 패킷에는 여러 개의 플래그가 있을 수 있으며 SYNACK 패킷과 같이 해당 플래그의 조합으로 호출됩니다.
시퀀스 번호(seqnum)는 이 패킷에서 전송되는 첫 번째 바이트에 대한 데이터 스트림의 오프셋을 지정합니다. 예를 들어 X바이트의 데이터가 포함된 첫 번째 패킷에서 이 숫자가 N인 경우 새 데이터가 포함된 다음 패킷에서는 N+X가 됩니다. 연결이 시작될 때 각 측은 이 번호를 무작위로 선택합니다.
승인 번호(acknum) - seqnum과 동일한 오프셋이지만 전송되는 바이트 수를 결정하는 것이 아니라 발신자가 보지 못한 수신자의 첫 번째 바이트 수를 결정합니다.

연결이 시작될 때 당사자들은 동의해야 합니다. seqnum и acknum. 클라이언트는 자신의 메시지와 함께 SYN 패킷을 보냅니다. seqnum = X. 서버는 SYNACK 패킷으로 응답하며, 여기에 해당 내용을 기록합니다. seqnum = Y 그리고 노출한다 acknum = X + 1. 클라이언트는 ACK 패킷으로 SYNACK에 응답합니다. seqnum = X + 1, acknum = Y + 1. 그 후 실제 데이터 전송이 시작됩니다.

피어가 패킷 수신을 확인하지 않으면 TCP는 시간 초과 후 패킷을 다시 보냅니다.

SYN 쿠키가 항상 사용되지 않는 이유는 무엇입니까?

첫째, SYNACK 또는 ACK가 손실되면 다시 전송될 때까지 기다려야 합니다. 연결 설정 속도가 느려집니다. 둘째, SYN 패키지에만 있습니다! — 연결의 추가 작업에 영향을 미치는 여러 옵션이 전송됩니다. 들어오는 SYN 패킷을 기억하지 않으면 서버는 이러한 옵션을 무시하고 클라이언트는 다음 패킷에서 해당 옵션을 보내지 않습니다. 이 경우 TCP가 작동할 수 있지만 적어도 초기 단계에서는 연결 품질이 저하됩니다.

패키지 관점에서 XDP 프로그램은 다음을 수행해야 합니다.

쿠키를 사용하여 SYNACK으로 SYN에 응답합니다.
RST(연결 해제)로 ACK에 응답합니다.
나머지 패킷을 폐기합니다.

패키지 구문 분석과 함께 알고리즘의 의사 코드:

Если это не Ethernet,
    пропустить пакет.
Если это не IPv4,
    пропустить пакет.
Если адрес в таблице проверенных,               (*)
        уменьшить счетчик оставшихся проверок,
        пропустить пакет.
Если это не TCP,
    сбросить пакет.     (**)
Если это SYN,
    ответить SYN-ACK с cookie.
Если это ACK,
    если в acknum лежит не cookie,
        сбросить пакет.
    Занести в таблицу адрес с N оставшихся проверок.    (*)
    Ответить RST.   (**)
В остальных случаях сбросить пакет.

하나 (*) 시스템 상태를 관리해야 하는 지점이 표시되어 있습니다. 첫 번째 단계에서는 SYN 쿠키를 seqnum으로 생성하여 TCP 핸드셰이크를 구현하기만 하면 이러한 지점 없이도 수행할 수 있습니다.

현장에서 (**), 테이블이 없으면 패킷을 건너뜁니다.

TCP 핸드셰이크 구현

패키지 구문 분석 및 코드 확인

네트워크 헤더 구조가 필요합니다: 이더넷(uapi/linux/if_ether.h), IPv4(uapi/linux/ip.h) 및 TCP(uapi/linux/tcp.h). 다음과 관련된 오류로 인해 후자를 연결할 수 없습니다. atomic64_t, 필요한 정의를 코드에 복사해야 했습니다.

가독성을 위해 C로 강조 표시된 모든 함수는 호출 시점에 인라인되어야 합니다. 커널의 eBPF 검증자가 역추적, 즉 실제로 루프 및 함수 호출을 금지하기 때문입니다.

#define INTERNAL static __attribute__((always_inline))

매크로 LOG() 릴리스 빌드에서 인쇄를 비활성화합니다.

프로그램은 기능의 컨베이어입니다. 각각은 해당 레벨 헤더가 강조 표시된 패킷을 수신합니다. 예를 들어, process_ether() 채워질 것으로 예상 ether. 필드 분석 결과를 바탕으로 이 기능은 패킷을 더 높은 수준으로 전달할 수 있습니다. 함수의 결과는 XDP 작업입니다. 현재로서는 SYN 및 ACK 처리기가 모든 패킷을 전달합니다.

struct Packet {
    struct xdp_md* ctx;

    struct ethhdr* ether;
    struct iphdr* ip;
    struct tcphdr* tcp;
};

INTERNAL int process_tcp_syn(struct Packet* packet) { return XDP_PASS; }
INTERNAL int process_tcp_ack(struct Packet* packet) { return XDP_PASS; }
INTERNAL int process_tcp(struct Packet* packet) { ... }
INTERNAL int process_ip(struct Packet* packet) { ... }

INTERNAL int
process_ether(struct Packet* packet) {
    struct ethhdr* ether = packet->ether;

    LOG("Ether(proto=0x%x)", bpf_ntohs(ether->h_proto));

    if (ether->h_proto != bpf_ntohs(ETH_P_IP)) {
        return XDP_PASS;
    }

    // B
    struct iphdr* ip = (struct iphdr*)(ether + 1);
    if ((void*)(ip + 1) > (void*)packet->ctx->data_end) {
        return XDP_DROP; /* malformed packet */
    }

    packet->ip = ip;
    return process_ip(packet);
}

SEC("prog")
int xdp_main(struct xdp_md* ctx) {
    struct Packet packet;
    packet.ctx = ctx;

    // A
    struct ethhdr* ether = (struct ethhdr*)(void*)ctx->data;
    if ((void*)(ether + 1) > (void*)ctx->data_end) {
        return XDP_PASS;
    }

    packet.ether = ether;
    return process_ether(&packet);
}

A와 B로 표시된 확인 사항에 주목하세요. A를 주석 처리하면 프로그램이 빌드되지만 로드 시 확인 오류가 발생합니다.

Verifier analysis:

<...>
11: (7b) *(u64 *)(r10 -48) = r1
12: (71) r3 = *(u8 *)(r7 +13)
invalid access to packet, off=13 size=1, R7(id=0,off=0,r=0)
R7 offset is outside of the packet
processed 11 insns (limit 1000000) max_states_per_insn 0 total_states 0 peak_states 0 mark_read 0

Error fetching program/map!

키 문자열 invalid access to packet, off=13 size=1, R7(id=0,off=0,r=0): 버퍼 시작부터 12번째 바이트가 패킷 외부일 때 실행 경로가 있습니다. 목록에서 우리가 말하는 줄을 이해하기는 어렵지만 명령 번호(XNUMX)와 소스 코드 줄을 보여주는 디스어셈블러가 있습니다.

llvm-objdump -S xdp_filter.o | less

이 경우에는 선을 가리킵니다.

LOG("Ether(proto=0x%x)", bpf_ntohs(ether->h_proto));

문제가 있다는 것을 분명히 해줍니다. ether. 항상 이런 식일 것입니다.

답장하다 SYN

이 단계의 목표는 고정된 SYNACK 패킷을 생성하는 것입니다. seqnum, 이는 향후 SYN 쿠키로 대체될 예정입니다. 모든 변경 사항은 다음에서 발생합니다. process_tcp_syn() 그리고 주변 지역.

패키지 확인

이상하게도 가장 주목할만한 대사는 다음과 같습니다.

/* Required to verify checksum calculation */
const void* data_end = (const void*)ctx->data_end;

첫 번째 버전의 코드를 작성할 때 5.1 커널이 사용되었으며 검증자에게는 다음과 같은 차이가 있었습니다. data_end и (const void*)ctx->data_end. 이 글을 쓰는 시점에는 커널 5.3.1에는 이 문제가 없었습니다. 컴파일러가 필드와 다르게 지역 변수에 액세스했을 가능성이 있습니다. 교훈: 중첩 규모가 클 경우 코드를 단순화하는 것이 도움이 될 수 있습니다.

다음은 검증자의 영광을 위한 일상적인 길이 확인입니다. 영형 MAX_CSUM_BYTES 아래에.

const u32 ip_len = ip->ihl * 4;
if ((void*)ip + ip_len > data_end) {
    return XDP_DROP; /* malformed packet */
}
if (ip_len > MAX_CSUM_BYTES) {
    return XDP_ABORTED; /* implementation limitation */
}

const u32 tcp_len = tcp->doff * 4;
if ((void*)tcp + tcp_len > (void*)ctx->data_end) {
    return XDP_DROP; /* malformed packet */
}
if (tcp_len > MAX_CSUM_BYTES) {
    return XDP_ABORTED; /* implementation limitation */
}

패키지 펼치기

작성 seqnum и acknum, ACK를 설정합니다(SYN이 이미 설정되어 있음).

const u32 cookie = 42;
tcp->ack_seq = bpf_htonl(bpf_ntohl(tcp->seq) + 1);
tcp->seq = bpf_htonl(cookie);
tcp->ack = 1;

TCP 포트, IP 주소, MAC 주소를 교환합니다. 표준 라이브러리는 XDP 프로그램에서 접근이 불가능하므로 memcpy() — Clang 내장 기능을 숨기는 매크로입니다.

const u16 temp_port = tcp->source;
tcp->source = tcp->dest;
tcp->dest = temp_port;

const u32 temp_ip = ip->saddr;
ip->saddr = ip->daddr;
ip->daddr = temp_ip;

struct ethhdr temp_ether = *ether;
memcpy(ether->h_dest, temp_ether.h_source, ETH_ALEN);
memcpy(ether->h_source, temp_ether.h_dest, ETH_ALEN);

체크섬 재계산

IPv4 및 TCP 체크섬을 사용하려면 헤더에 모든 16비트 단어를 추가해야 하며 헤더의 크기가 여기에 기록됩니다. 즉, 컴파일 시간에는 알 수 없습니다. 이는 검증자가 경계 변수에 대한 일반 루프를 건너뛰지 않기 때문에 문제가 됩니다. 그러나 헤더의 크기는 각각 최대 64바이트로 제한됩니다. 고정된 반복 횟수로 루프를 만들 수 있으며, 이는 일찍 종료될 수 있습니다.

있음을 참고합니다 RFC 1624 패키지의 고정 단어만 변경된 경우 체크섬을 부분적으로 다시 계산하는 방법에 대해 설명합니다. 그러나 이 방법은 보편적이지 않으며 구현을 유지 관리하기가 더 어렵습니다.

체크섬 계산 기능:

#define MAX_CSUM_WORDS 32
#define MAX_CSUM_BYTES (MAX_CSUM_WORDS * 2)

INTERNAL u32
sum16(const void* data, u32 size, const void* data_end) {
    u32 s = 0;
#pragma unroll
    for (u32 i = 0; i < MAX_CSUM_WORDS; i++) {
        if (2*i >= size) {
            return s; /* normal exit */
        }
        if (data + 2*i + 1 + 1 > data_end) {
            return 0; /* should be unreachable */
        }
        s += ((const u16*)data)[i];
    }
    return s;
}

하지만 size 호출 코드에 의해 검증되면 검증자가 루프 완료를 증명할 수 있도록 두 번째 종료 조건이 필요합니다.

32비트 단어의 경우 더 간단한 버전이 구현됩니다.

INTERNAL u32
sum16_32(u32 v) {
    return (v >> 16) + (v & 0xffff);
}

실제로 체크섬을 다시 계산하고 패킷을 다시 보냅니다.

ip->check = 0;
ip->check = carry(sum16(ip, ip_len, data_end));

u32 tcp_csum = 0;
tcp_csum += sum16_32(ip->saddr);
tcp_csum += sum16_32(ip->daddr);
tcp_csum += 0x0600;
tcp_csum += tcp_len << 8;
tcp->check = 0;
tcp_csum += sum16(tcp, tcp_len, data_end);
tcp->check = carry(tcp_csum);

return XDP_TX;

기능 carry() RFC 32에 따라 16비트 단어의 791비트 합계에서 체크섬을 만듭니다.

TCP 핸드셰이크 확인

필터는 다음과의 연결을 올바르게 설정합니다. netcat, Linux가 RST 패킷으로 응답한 최종 ACK가 누락되었습니다. 네트워크 스택이 SYN을 수신하지 않았기 때문에(SYNACK로 변환되어 다시 전송되었으며) OS 관점에서 보면 열기와 관련 없는 패킷이 도착했습니다. 사이.

$ sudo ip netns exec xdp-test   nc -nv 192.0.2.1 6666
192.0.2.1 6666: Connection reset by peer

본격적인 응용 프로그램으로 확인하고 관찰하는 것이 중요합니다 tcpdump 에 xdp-remote 왜냐하면 예를 들면, hping3 잘못된 체크섬에는 응답하지 않습니다.

XDP 관점에서 볼 때 검증 자체는 사소한 것입니다. 계산 알고리즘은 원시적이며 정교한 공격자에게 취약할 가능성이 높습니다. 예를 들어 Linux 커널은 암호화 SipHash를 사용하지만 XDP에 대한 구현은 분명히 이 기사의 범위를 벗어납니다.

외부 통신과 관련된 새로운 TODO를 위해 도입되었습니다.

XDP 프로그램이 저장할 수 없습니다. cookie_seed (솔트의 비밀 부분) 전역 변수에는 커널에 저장이 필요하며 그 값은 신뢰할 수 있는 생성기에서 주기적으로 업데이트됩니다.
SYN 쿠키가 ACK 패킷과 일치하면 메시지를 인쇄할 필요가 없지만, 패킷을 계속 전달하기 위해 확인된 클라이언트의 IP를 기억합니다.

합법적인 클라이언트 확인:

$ sudoip netns exec xdp-test   nc -nv 192.0.2.1 6666
192.0.2.1 6666: Connection reset by peer

로그에는 검사가 통과되었음을 표시합니다(flags=0x2 - 이것은 SYN입니다. flags=0x10 ACK입니다):

Ether(proto=0x800)
  IP(src=0x20e6e11a dst=0x20e6e11e proto=6)
    TCP(sport=50836 dport=6666 flags=0x2)
Ether(proto=0x800)
  IP(src=0xfe2cb11a dst=0xfe2cb11e proto=6)
    TCP(sport=50836 dport=6666 flags=0x10)
      cookie matches for client 20200c0

확인된 IP 목록은 없지만 SYN 플러드 자체로부터 보호할 수는 없지만 다음 명령으로 시작된 ACK 플러드에 대한 반응은 다음과 같습니다.

sudo ip netns exec xdp-test   hping3 --flood -A -s 1111 -p 2222 192.0.2.1

로그 항목:

Ether(proto=0x800)
  IP(src=0x15bd11a dst=0x15bd11e proto=6)
    TCP(sport=3236 dport=2222 flags=0x10)
      cookie mismatch

결론

때로는 일반적으로 eBPF, 특히 XDP가 개발 플랫폼이라기보다는 고급 관리자 도구로 더 많이 제시되기도 합니다. 실제로 XDP는 커널의 패킷 처리를 방해하기 위한 도구이지 DPDK 및 기타 커널 우회 옵션과 같은 커널 스택의 대안이 아닙니다. 반면에 XDP를 사용하면 매우 복잡한 로직을 구현할 수 있으며 트래픽 처리 중단 없이 쉽게 업데이트할 수 있습니다. 검증자는 큰 문제를 일으키지 않으며 개인적으로 사용자 공간 코드의 일부에 대해 이를 거부하지 않습니다.

두 번째 부분에서는 주제가 흥미로울 경우 확인된 클라이언트 및 연결 끊김 테이블을 완성하고 카운터를 구현하며 필터를 관리하기 위한 사용자 공간 유틸리티를 작성합니다.

링크 :

출처 : habr.com

우리는 XDP에 대한 DDoS 공격에 대한 보호 기능을 작성하고 있습니다. 핵 부분