🥇 हामी XDP मा DDoS आक्रमणहरू विरुद्ध सुरक्षा लेखिरहेका छौं। आणविक भाग

एक्सप्रेस डाटा पथ (XDP) प्रविधिले प्याकेटहरूले कर्नेल नेटवर्क स्ट्याकमा प्रवेश गर्नु अघि लिनक्स इन्टरफेसमा अनियमित ट्राफिक प्रशोधन गर्न अनुमति दिन्छ। XDP को आवेदन - DDoS आक्रमणहरू (CloudFlare), जटिल फिल्टरहरू, तथ्याङ्क सङ्कलन (Netflix) विरुद्ध सुरक्षा। XDP कार्यक्रमहरू eBPF भर्चुअल मेसिनद्वारा कार्यान्वयन गरिन्छ, त्यसैले तिनीहरूसँग तिनीहरूको कोड र उपलब्ध कर्नेल प्रकार्यहरूमा फिल्टर प्रकारको आधारमा प्रतिबन्धहरू छन्।

लेख XDP मा धेरै सामाग्री को कमजोरीहरु भर्न को उद्देश्य हो। सबैभन्दा पहिले, तिनीहरूले XDP का सुविधाहरू तुरुन्तै बाइपास गर्ने रेडिमेड कोड प्रदान गर्छन्: यो प्रमाणीकरणको लागि तयार छ वा समस्याहरू उत्पन्न गर्न धेरै सरल छ। जब तपाइँ स्क्र्याचबाट तपाइँको कोड लेख्ने प्रयास गर्नुहुन्छ, तपाइँलाई सामान्य त्रुटिहरु संग के गर्ने कुनै थाहा छैन। दोस्रो, स्थानीय रूपमा VM र हार्डवेयर बिना XDP परीक्षण गर्ने तरिकाहरू कभर गरिएको छैन, तिनीहरूको आफ्नै कमजोरीहरू भए पनि। यो पाठ XDP र eBPF मा रुचि राख्ने नेटवर्किङ र Linux सँग परिचित प्रोग्रामरहरूको लागि हो।

यस भागमा, हामी XDP फिल्टर कसरी जम्मा हुन्छ र यसलाई कसरी परीक्षण गर्ने भनेर विस्तृत रूपमा बुझ्नेछौं, त्यसपछि हामी प्याकेट प्रशोधन स्तरमा ज्ञात SYN कुकीज संयन्त्रको सरल संस्करण लेख्नेछौं। हामी अझै "सेतो सूची" सिर्जना गर्दैनौं
प्रमाणित ग्राहकहरू, काउन्टरहरू राख्नुहोस् र फिल्टर प्रबन्ध गर्नुहोस् - पर्याप्त लगहरू।

हामी C मा लेख्नेछौं - यो फैशनेबल छैन, तर यो व्यावहारिक छ। सबै कोड GitHub मा लिङ्क मार्फत अन्तमा उपलब्ध छ र लेखमा वर्णन गरिएका चरणहरू अनुसार कमिटहरूमा विभाजित गरिएको छ।

अस्वीकरण यस लेखको क्रममा, म DDoS आक्रमणहरू रोक्नको लागि एक मिनी-समाधान विकास गर्नेछु, किनभने यो XDP र मेरो विशेषज्ञताको क्षेत्रको लागि एक यथार्थपरक कार्य हो। जे होस्, मुख्य लक्ष्य टेक्नोलोजी बुझ्नु हो; यो तयार संरक्षण सिर्जना गर्न गाइड होइन। ट्यूटोरियल कोड अप्टिमाइज गरिएको छैन र केही सूक्ष्मताहरू हटाउँछ।

XDP संक्षिप्त अवलोकन

म केवल मुख्य बुँदाहरूलाई रूपरेखा दिनेछु ताकि कागजातहरू र अवस्थित लेखहरू नक्कल नगर्नुहोस्।

त्यसोभए, फिल्टर कोड कर्नेलमा लोड हुन्छ। आगमन प्याकेटहरू फिल्टरमा पठाइन्छ। नतिजाको रूपमा, फिल्टरले निर्णय गर्नुपर्छ: कर्नेलमा प्याकेट पास गर्नुहोस् (XDP_PASS), ड्रप प्याकेट (XDP_DROP) वा फिर्ता पठाउनुहोस् (XDP_TX)। फिल्टरले प्याकेज परिवर्तन गर्न सक्छ, यो विशेष गरी सत्य हो XDP_TX। तपाइँ कार्यक्रम पनि रद्द गर्न सक्नुहुन्छ (XDP_ABORTED) र प्याकेज रिसेट गर्नुहोस्, तर यो समान छ assert(0) - डिबगिङको लागि।

eBPF (विस्तारित बर्कले प्याकेट फिल्टर) भर्चुअल मेसिन जानाजानी सरल बनाइएको छ ताकि कर्नेलले जाँच गर्न सक्छ कि कोड लुप छैन र अन्य व्यक्तिको मेमोरीलाई हानि गर्दैन। संचयी प्रतिबन्ध र जाँचहरू:

लूपहरू (पछाडि) निषेधित छन्।
त्यहाँ डेटाको लागि स्ट्याक छ, तर कुनै प्रकार्यहरू छैनन् (सबै सी प्रकार्यहरू इनलाइन हुनुपर्छ)।
स्ट्याक र प्याकेट बफर बाहिर मेमोरी पहुँच निषेधित छ।
कोड साइज सीमित छ, तर व्यवहारमा यो धेरै महत्त्वपूर्ण छैन।
विशेष कर्नेल प्रकार्यहरू (eBPF सहयोगीहरू) लाई मात्र कल गर्न अनुमति छ।

फिल्टर डिजाइन र स्थापना यो जस्तो देखिन्छ:

स्रोत कोड (जस्तै kernel.c) वस्तुमा कम्पाइल गरिएको छ (kernel.o) eBPF भर्चुअल मेसिन आर्किटेक्चरको लागि। अक्टोबर 2019 सम्म, eBPF को संकलन Clang द्वारा समर्थित छ र GCC 10.1 मा प्रतिज्ञा गरिएको छ।
यदि यो वस्तु कोडले कर्नेल संरचनाहरूमा कलहरू समावेश गर्दछ (उदाहरणका लागि, तालिकाहरू र काउन्टरहरू), तिनीहरूको ID लाई शून्यले प्रतिस्थापन गरिन्छ, जसको मतलब यस्तो कोड कार्यान्वयन गर्न सकिँदैन। कर्नेलमा लोड गर्नु अघि, तपाइँले यी शून्यहरूलाई कर्नेल कलहरू मार्फत सिर्जना गरिएका विशेष वस्तुहरूको आईडीहरूसँग बदल्न आवश्यक छ (कोड लिङ्क गर्नुहोस्)। तपाइँ यो बाह्य उपयोगिताहरु संग गर्न सक्नुहुन्छ, वा तपाइँ एक कार्यक्रम लेख्न सक्नुहुन्छ जुन लिङ्क र एक विशेष फिल्टर लोड हुनेछ।
कर्नेलले लोड गरिएको कार्यक्रम प्रमाणित गर्दछ। चक्रको अनुपस्थिति र प्याकेट र स्ट्याक सीमाहरू पार गर्न असफलता जाँच गरिन्छ। यदि प्रमाणिकरणकर्ताले कोड सही छ भनेर प्रमाणित गर्न सक्दैन भने, कार्यक्रम अस्वीकार गरिएको छ - तपाईंले उसलाई खुशी पार्न सक्षम हुन आवश्यक छ।
सफल प्रमाणीकरण पछि, कर्नेलले प्रणाली आर्किटेक्चरको लागि मेसिन कोडमा eBPF आर्किटेक्चर वस्तु कोड कम्पाइल गर्दछ (भर्खर-समय)।
कार्यक्रम इन्टरफेसमा संलग्न हुन्छ र प्याकेट प्रशोधन सुरु हुन्छ।

XDP कर्नेलमा चल्ने हुनाले, डिबगिङ ट्रेस लगहरू र वास्तवमा, कार्यक्रमले फिल्टर वा उत्पन्न गर्ने प्याकेटहरू प्रयोग गरेर गरिन्छ। जे होस्, eBPF ले सुनिश्चित गर्दछ कि डाउनलोड गरिएको कोड प्रणालीको लागि सुरक्षित छ, त्यसैले तपाईले XDP सँग सीधा आफ्नो स्थानीय लिनक्समा प्रयोग गर्न सक्नुहुन्छ।

वातावरण तयार गर्दै

विधानसभा

क्ल्याङले eBPF आर्किटेक्चरको लागि वस्तुको कोड सीधा उत्पादन गर्न सक्दैन, त्यसैले प्रक्रियामा दुई चरणहरू हुन्छन्:

LLVM बाइटकोडमा C कोड कम्पाइल गर्नुहोस् (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

आर्क लिनक्सको लागि मेकफाइल (कर्नेल 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 - प्रणाली वास्तुकला। वितरणहरू बीच बाटो र उपकरणहरू थोरै फरक हुन सक्छ।

डेबियन 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 (userspace API) हेडरहरू कर्नेल कोडका लागि परिभाषित गरिएको छ, किनभने फिल्टर कर्नेलमा कार्यान्वयन हुन्छ।

स्ट्याक सुरक्षा असक्षम गर्न सकिन्छ (-fno-stack-protector), किनभने eBPF कोड प्रमाणिकरणकर्ताले अझै पनि स्ट्याक-बाउन्ड उल्लङ्घनहरूको लागि जाँच गर्दछ। यो तुरुन्तै अप्टिमाइजेसनहरू खोल्न लायक छ, किनकि eBPF bytecode को आकार सीमित छ।

सबै प्याकेटहरू पास गर्ने र केही नगर्ने फिल्टरको साथ सुरू गरौं:

#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। अब कहाँ प्रयास गर्ने?

परीक्षण स्ट्यान्ड

स्ट्यान्डमा दुई इन्टरफेसहरू समावेश हुनुपर्छ: जसमा त्यहाँ फिल्टर हुनेछ र जसबाट प्याकेटहरू पठाइनेछ। नियमित अनुप्रयोगहरूले हाम्रो फिल्टरसँग कसरी काम गर्छ भनी जाँच्नको लागि तिनीहरूको आफ्नै आईपीहरू भएका लिनक्स यन्त्रहरू पूर्ण रूपमा हुनुपर्छ।

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) आगमन ट्राफिक पठाइनेछ। यद्यपि, त्यहाँ एउटा समस्या छ: इन्टरफेसहरू एउटै मेसिनमा छन्, र लिनक्सले ती मध्ये एउटामा अर्को मार्फत ट्राफिक पठाउँदैन। तपाइँ यसलाई कठिन नियमहरु संग समाधान गर्न सक्नुहुन्छ iptables, तर तिनीहरूले प्याकेजहरू परिवर्तन गर्नुपर्नेछ, जुन डिबगिङका लागि असुविधाजनक छ। नेटवर्क नेमस्पेसहरू (यसपछि netns) प्रयोग गर्नु राम्रो हुन्छ।

सञ्जाल नेमस्पेसले इन्टरफेसहरू, राउटिंग तालिकाहरू, र नेटफिल्टर नियमहरूको सेट समावेश गर्दछ जुन अन्य netns मा समान वस्तुहरूबाट अलग छन्। प्रत्येक प्रक्रिया नेमस्पेसमा चल्छ र त्यो netns को वस्तुहरूमा मात्र पहुँच हुन्छ। पूर्वनिर्धारित रूपमा, प्रणालीमा सबै वस्तुहरूको लागि एकल नेटवर्क नेमस्पेस छ, त्यसैले तपाइँ लिनक्समा काम गर्न सक्नुहुन्छ र 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(), तर ढाँचा बाहेक अन्य तीन तर्क सम्म मात्र समर्थन गर्दछ, र निर्दिष्टकर्ताहरूको सीमित सूची। म्याक्रो 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.

पिङले अब यस्तो सन्देशहरू ट्रिगर गर्नुपर्छ:

<...>-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 एउटा कार्यक्रम पनि तोकियो, त्यो खाली भए पनि, र उसलाई उठाइयो।

मलाई यो कसरी थाहा भयो?

कर्नेलमा प्याकेजको मार्ग ट्रेस गर्नुहोस् perf घटना संयन्त्रले अनुमति दिन्छ, वैसे, उही भर्चुअल मेसिन प्रयोग गरेर, त्यो हो, eBPF को साथ disassemblies को लागी 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, यसलाई मेकफाइलमा थप्नुहोस्, यसलाई बाँध्नुहोस् 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

यदि यसको सट्टा एआरपीहरू मात्र देखाइन्छ भने, तपाईंले फिल्टरहरू हटाउनु पर्छ (यसले गर्छ sudo ./stand detach), छोड्नुहोस् ping, त्यसपछि फिल्टरहरू सेट गर्नुहोस् र पुन: प्रयास गर्नुहोस्। समस्या फिल्टरको हो XDP_TX एआरपी र स्ट्याक दुवैमा मान्य
नेमस्पेसहरू xdp-test MAC ठेगाना 192.0.2.1 लाई "बिर्सन" गर्न व्यवस्थित, यो आईपी समाधान गर्न सक्षम हुनेछैन।

समस्याको गठन

भनिएको कार्यमा जाऔं: XDP मा SYN कुकीज मेकानिज्म लेख्नुहोस्।

SYN बाढी एक लोकप्रिय DDoS आक्रमण बनेको छ, जसको सार निम्नानुसार छ। जब जडान स्थापित हुन्छ (TCP ह्यान्डशेक), सर्भरले SYN प्राप्त गर्दछ, भविष्यको जडानको लागि स्रोतहरू आवंटित गर्दछ, SYNACK प्याकेटसँग प्रतिक्रिया दिन्छ र ACK को लागि पर्खन्छ। आक्रमणकारीले बहु-हजार-बलियो बोटनेटमा प्रत्येक होस्टबाट नक्कली ठेगानाहरूबाट प्रति सेकेन्ड हजारौं SYN प्याकेटहरू पठाउँदछ। सर्भरलाई प्याकेटको आगमनमा तुरुन्तै स्रोतहरू आवंटित गर्न बाध्य पारिएको छ, तर तिनीहरूलाई ठूलो टाइमआउट पछि रिलीज गर्दछ; परिणामको रूपमा, मेमोरी वा सीमाहरू समाप्त हुन्छन्, नयाँ जडानहरू स्वीकार गरिँदैन, र सेवा अनुपलब्ध छ।

यदि तपाइँ SYN प्याकेटमा आधारित स्रोतहरू आवंटित गर्नुहुन्न, तर केवल SYNACK प्याकेटको साथ प्रतिक्रिया दिनुहुन्छ भने, त्यसपछि कसरी सर्भरले बुझ्न सक्छ कि पछि आएको ACK प्याकेटले SYN प्याकेटलाई बुझाउँछ जुन बचत गरिएको थिएन? आखिर, एक आक्रमणकारीले नक्कली ACKs पनि उत्पन्न गर्न सक्छ। SYN कुकीको बिन्दु यसलाई इनकोड गर्नु हो seqnum ठेगानाहरू, पोर्टहरू र नुन परिवर्तन गर्ने ह्यासको रूपमा जडान प्यारामिटरहरू। यदि ACK नुन परिवर्तन हुनु अघि आइपुग्यो भने, तपाइँ फेरि ह्यास गणना गर्न सक्नुहुन्छ र यसलाई तुलना गर्न सक्नुहुन्छ। acknum। फोर्ज acknum आक्रमणकारीले सक्दैन, किनकि नुनले गोप्य समावेश गर्दछ, र सीमित च्यानलको कारणले यसलाई क्रमबद्ध गर्न समय हुँदैन।

SYN कुकी लामो समयदेखि लिनक्स कर्नेलमा लागू गरिएको छ र यदि SYN हरू धेरै छिटो र सामूहिक रूपमा आइपुग्छन् भने स्वचालित रूपमा सक्षम गर्न सकिन्छ।

TCP ह्यान्डशेकमा शैक्षिक कार्यक्रम

TCP ले बाइटहरूको स्ट्रिमको रूपमा डेटा प्रसारण प्रदान गर्दछ, उदाहरणका लागि, HTTP अनुरोधहरू TCP मार्फत प्रसारित हुन्छन्। स्ट्रिम प्याकेटहरूमा टुक्राहरूमा प्रसारित हुन्छ। सबै TCP प्याकेटहरूमा तार्किक झण्डा र 32-बिट अनुक्रम संख्याहरू छन्:

झण्डाहरूको संयोजनले विशेष प्याकेजको भूमिका निर्धारण गर्दछ। SYN झण्डाले संकेत गर्दछ कि यो जडानमा प्रेषकको पहिलो प्याकेट हो। ACK झण्डा भनेको प्रेषकले बाइट सम्मको सबै जडान डेटा प्राप्त गरेको हो acknum। एउटा प्याकेटमा धेरै झण्डाहरू हुन सक्छन् र तिनीहरूको संयोजनद्वारा बोलाइन्छ, उदाहरणका लागि, SYNACK प्याकेट।
अनुक्रम नम्बर (sequnum) ले यो प्याकेटमा प्रसारण भएको पहिलो बाइटको लागि डाटा स्ट्रिममा अफसेट निर्दिष्ट गर्दछ। उदाहरणका लागि, यदि डेटाको 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 लाई जवाफ दिनुहोस्;
ACK लाई RST सँग जवाफ दिनुहोस् (विच्छेद गर्नुहोस्);
बाँकी प्याकेटहरू खारेज गर्नुहोस्।

प्याकेज पार्सिङको साथ एल्गोरिदमको स्यूडोकोड:

Если это не 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) र स्रोत कोडको लाइनहरू देखाउने एक डिसेम्बलर छ:

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() - एउटा म्याक्रो जसले क्ल्याङ्ग भित्री कुराहरू लुकाउँछ।

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, अन्तिम ACK हराइरहेको छ, जसमा लिनक्सले RST प्याकेटको साथ प्रतिक्रिया दियो, किनकि नेटवर्क स्ट्याकले 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 दृष्टिकोणबाट, प्रमाणिकरण आफैमा तुच्छ छ। गणना एल्गोरिथ्म आदिम छ र एक परिष्कृत आक्रमणकारीको लागि सम्भवतः कमजोर छ। लिनक्स कर्नेल, उदाहरणका लागि, क्रिप्टोग्राफिक SipHash प्रयोग गर्दछ, तर XDP को लागी यसको कार्यान्वयन स्पष्ट रूपमा यस लेखको दायरा बाहिर छ।

बाह्य सञ्चारसँग सम्बन्धित नयाँ TODOs को लागि परिचय:

XDP कार्यक्रम भण्डारण गर्न सक्दैन cookie_seed (नुनको गोप्य भाग) एक वैश्विक चरमा, तपाईंलाई कर्नेलमा भण्डारण चाहिन्छ, जसको मूल्य आवधिक रूपमा भरपर्दो जनरेटरबाट अद्यावधिक हुनेछ।
यदि SYN कुकी ACK प्याकेटमा मेल खान्छ भने, तपाईंले सन्देश प्रिन्ट गर्न आवश्यक पर्दैन, तर त्यसबाट प्याकेटहरू पास गर्न जारी राख्नको लागि प्रमाणित ग्राहकको आईपी सम्झनुहोस्।

वैध ग्राहक प्रमाणिकरण:

$ 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

जब त्यहाँ प्रमाणित आईपीहरूको कुनै सूची छैन, त्यहाँ 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 ले तपाईंलाई धेरै जटिल तर्क लागू गर्न अनुमति दिन्छ, जुन ट्राफिक प्रशोधनमा अवरोध बिना अद्यावधिक गर्न सजिलो छ। प्रमाणिकरणले ठूला समस्याहरू सिर्जना गर्दैन; व्यक्तिगत रूपमा, म प्रयोगकर्तास्पेस कोडका भागहरूको लागि यसलाई अस्वीकार गर्दिन।

दोस्रो भागमा, यदि विषय चाखलाग्दो छ भने, हामी प्रमाणित ग्राहकहरू र विच्छेदहरूको तालिका पूरा गर्नेछौं, काउन्टरहरू लागू गर्नेछौं र फिल्टर व्यवस्थापन गर्न प्रयोगकर्तास्पेस उपयोगिता लेख्नेछौं।

सन्दर्भहरू:

स्रोत: www.habr.com

हामी XDP मा DDoS आक्रमणहरू विरुद्ध सुरक्षा लेख्छौं। परमाणु भाग