🥇हम XDP पर DDoS हमलों के विरुद्ध सुरक्षा लिखते हैं। परमाणु भाग

ईएक्सप्रेस डेटा पाथ (एक्सडीपी) तकनीक पैकेट के कर्नेल नेटवर्क स्टैक में प्रवेश करने से पहले लिनक्स इंटरफेस पर ट्रैफ़िक के मनमाने ढंग से प्रसंस्करण की अनुमति देती है। XDP का अनुप्रयोग - DDoS हमलों (क्लाउडफ्लेयर), जटिल फिल्टर, सांख्यिकी संग्रह (नेटफ्लिक्स) से सुरक्षा। XDP प्रोग्राम eBPF वर्चुअल मशीन द्वारा निष्पादित होते हैं, और इसलिए फ़िल्टर के प्रकार के आधार पर उनके कोड और उपलब्ध कर्नेल फ़ंक्शंस दोनों पर प्रतिबंध होते हैं।

लेख का उद्देश्य XDP पर अनेक सामग्रियों की कमियों को दूर करना है। सबसे पहले, वे तैयार कोड प्रदान करते हैं जो XDP की सुविधाओं को तुरंत दरकिनार कर देता है: सत्यापन के लिए तैयार या समस्या पैदा करने के लिए बहुत सरल। जब आप बाद में स्क्रैच से अपना स्वयं का कोड लिखने का प्रयास करते हैं, तो यह समझ में नहीं आता है कि सामान्य त्रुटियों के साथ क्या किया जाए। दूसरे, इसमें वीएम और हार्डवेयर के बिना स्थानीय स्तर पर एक्सडीपी का परीक्षण करने के तरीकों को शामिल नहीं किया गया है, इस तथ्य के बावजूद कि उनके अपने नुकसान हैं। यह पाठ नेटवर्क और लिनक्स से परिचित प्रोग्रामरों के लिए है जो XDP और eBPF में रुचि रखते हैं।

इस भाग में, हम विस्तार से समझेंगे कि XDP फ़िल्टर को कैसे इकट्ठा किया जाता है और इसका परीक्षण कैसे किया जाता है, फिर हम पैकेट प्रोसेसिंग स्तर पर प्रसिद्ध SYN कुकीज़ तंत्र का एक सरल संस्करण लिखेंगे। जब तक हम एक "श्वेत सूची" नहीं बना लेते
सत्यापित ग्राहक, काउंटर रखें और फ़िल्टर प्रबंधित करें - पर्याप्त लॉग।

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

अस्वीकरण। लेख के दौरान, DDoS हमलों को निरस्त करने के लिए एक लघु-समाधान विकसित किया जाएगा, क्योंकि यह XDP और मेरे क्षेत्र के लिए एक यथार्थवादी कार्य है। हालाँकि, मुख्य लक्ष्य प्रौद्योगिकी को समझना है, यह तैयार सुरक्षा बनाने के लिए एक मार्गदर्शिका नहीं है। ट्यूटोरियल कोड अनुकूलित नहीं है और कुछ बारीकियों को छोड़ देता है।

एक्सडीपी का संक्षिप्त अवलोकन

मैं केवल मुख्य बिंदु बताऊंगा ताकि दस्तावेज़ीकरण और मौजूदा लेखों की नकल न हो।

तो, फ़िल्टर कोड को कर्नेल में लोड किया जाता है। फ़िल्टर आने वाले पैकेटों को पास कर देता है। परिणामस्वरूप, फ़िल्टर को निर्णय लेना होगा: पैकेट को कर्नेल में पास करने के लिए (XDP_PASS), ड्रॉप पैकेट (XDP_DROP) या इसे वापस भेजें (XDP_TX). फ़िल्टर पैकेज को बदल सकता है, यह विशेष रूप से सच है XDP_TX. आप प्रोग्राम को क्रैश भी कर सकते हैं (XDP_ABORTED) और पैकेज छोड़ दें, लेकिन यह समान है assert(0) - डिबगिंग के लिए.

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

लूप्स (वापस कूदना) निषिद्ध है।
डेटा के लिए एक स्टैक है, लेकिन कोई फ़ंक्शन नहीं है (सभी सी फ़ंक्शन इनलाइन होने चाहिए)।
स्टैक और पैकेट बफ़र के बाहर मेमोरी तक पहुंच निषिद्ध है।
कोड का आकार सीमित है, लेकिन व्यवहार में यह बहुत महत्वपूर्ण नहीं है।
केवल विशेष कर्नेल फ़ंक्शंस (eBPF हेल्पर्स) की अनुमति है।

फ़िल्टर को विकसित करना और स्थापित करना इस तरह दिखता है:

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

चूँकि XDP कर्नेल में चलता है, डिबगिंग ट्रेस लॉग पर और वास्तव में, उन पैकेटों पर आधारित होती है जिन्हें प्रोग्राम फ़िल्टर करता है या उत्पन्न करता है। हालाँकि, eBPF डाउनलोड किए गए कोड को सिस्टम के लिए सुरक्षित रखता है, इसलिए आप सीधे अपने स्थानीय लिनक्स पर XDP के साथ प्रयोग कर सकते हैं।

पर्यावरण की तैयारी

सभा

क्लैंग eBPF आर्किटेक्चर के लिए सीधे ऑब्जेक्ट कोड जारी नहीं कर सकता है, इसलिए प्रक्रिया में दो चरण होते हैं:

सी कोड को एलएलवीएम बाइटकोड में संकलित करें (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__ इसका मतलब है कि यूएपीआई (यूजरस्पेस एपीआई) हेडर को कर्नेल कोड के लिए परिभाषित किया गया है, क्योंकि फ़िल्टर कर्नेल में निष्पादित होता है।

स्टैक सुरक्षा अक्षम की जा सकती है (-fno-stack-protector) क्योंकि ईबीपीएफ कोड सत्यापनकर्ता वैसे भी स्टैक सीमाओं से बाहर होने की जांच करता है। आपको तुरंत अनुकूलन सक्षम करना चाहिए, क्योंकि 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 से प्रदर्शन किया गया 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, लेकिन उन्हें पैकेज बदलना होगा, जो डिबगिंग के समय असुविधाजनक है। नेटवर्क नेमस्पेस (नेटवर्क नेमस्पेस, आगे नेटएनएस) का उपयोग करना बेहतर है।

नेटवर्क नेमस्पेस में इंटरफेस, राउटिंग टेबल और नेटफिल्टर नियमों का एक सेट होता है जो अन्य नेटन में समान ऑब्जेक्ट से अलग होते हैं। प्रत्येक प्रक्रिया कुछ नेमस्पेस में चलती है, और केवल इस नेटन की वस्तुएं ही इसके लिए उपलब्ध होती हैं। डिफ़ॉल्ट रूप से, सिस्टम में सभी ऑब्जेक्ट के लिए एक एकल नेटवर्क नेमस्पेस होता है, इसलिए आप लिनक्स पर काम कर सकते हैं और नेटन के बारे में नहीं जान सकते।

आइए एक नया नेमस्पेस बनाएं xdp-test और वहां चले जाओ xdp-remote.

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

फिर प्रक्रिया चल रही है xdp-test, "नहीं देखूंगा" xdp-local (यह डिफ़ॉल्ट रूप से नेटन में रहेगा) और 192.0.2.1 पर एक पैकेट भेजते समय इसे पास कर दिया जाएगा xdp-remote, क्योंकि इस प्रक्रिया के लिए 192.0.2.0/24 पर यही एकमात्र इंटरफ़ेस उपलब्ध है। यह उल्टा भी काम करता है.

नेटएन के बीच चलते समय, इंटरफ़ेस नीचे चला जाता है और पता खो देता है। नेटन्स में एक इंटरफ़ेस सेट करने के लिए, आपको चलाने की आवश्यकता है 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
<...>

तथ्य यह है कि ईबीपीएफ प्रोग्राम में डेटा अनुभाग नहीं होता है, इसलिए प्रारूप स्ट्रिंग को एन्कोड करने का एकमात्र तरीका वीएम कमांड के तत्काल तर्क हैं:

$ 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, इसे मेकफ़ाइल में जोड़ें, बाइंड करें 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 एआरपी को भी प्रभावित करता है, और यदि स्टैक
नामस्थान xdp-test मैक एड्रेस 192.0.2.1 को "भूलने" में कामयाब रहा, वह इस आईपी को हल करने में सक्षम नहीं होगा।

समस्या का निरूपण

आइए बताए गए कार्य पर आगे बढ़ें: XDP पर एक SYN कुकी तंत्र लिखना।

अब तक, SYN बाढ़ एक लोकप्रिय DDoS हमला बना हुआ है, जिसका सार इस प्रकार है। जब कोई कनेक्शन स्थापित होता है (टीसीपी हैंडशेक), तो सर्वर एक SYN प्राप्त करता है, भविष्य के कनेक्शन के लिए संसाधन आवंटित करता है, एक SYNACK पैकेट के साथ प्रतिक्रिया करता है, और एक ACK की प्रतीक्षा करता है। हमलावर बहु-हज़ार बॉटनेट में प्रत्येक होस्ट से प्रति सेकंड हजारों की मात्रा में नकली पते से SYN पैकेट भेजता है। सर्वर को पैकेट के आने पर तुरंत संसाधन आवंटित करने के लिए मजबूर किया जाता है, लेकिन लंबे समय के बाद इसे जारी करता है, परिणामस्वरूप, मेमोरी या सीमाएं समाप्त हो जाती हैं, नए कनेक्शन स्वीकार नहीं किए जाते हैं, सेवा अनुपलब्ध है।

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

SYN कुकीज़ को लिनक्स कर्नेल में लंबे समय से लागू किया गया है और यदि SYN बहुत जल्दी और थोक में आते हैं तो इन्हें स्वचालित रूप से सक्षम भी किया जा सकता है।

टीसीपी हैंडशेक पर शैक्षिक कार्यक्रम

टीसीपी बाइट्स की एक धारा के रूप में डेटा का स्थानांतरण प्रदान करता है, उदाहरण के लिए, HTTP अनुरोध टीसीपी पर प्रसारित होते हैं। धारा को टुकड़े-टुकड़े करके पैकेटों में प्रसारित किया जाता है। सभी टीसीपी पैकेटों में तार्किक झंडे और 32-बिट अनुक्रम संख्याएं होती हैं:

झंडों का संयोजन किसी विशेष पैकेज की भूमिका को परिभाषित करता है। SYN ध्वज का अर्थ है कि यह कनेक्शन पर प्रेषक का पहला पैकेट है। ACK ध्वज का अर्थ है कि प्रेषक को एक बाइट तक का सभी कनेक्शन डेटा प्राप्त हो गया है। acknum. एक पैकेट में कई झंडे हो सकते हैं और उनके संयोजन के आधार पर इसका नाम रखा जाता है, उदाहरण के लिए, एक SYNACK पैकेट।
अनुक्रम संख्या (सेकनम) इस पैकेट में भेजे गए पहले बाइट के लिए डेटा स्ट्रीम में ऑफसेट निर्दिष्ट करती है। उदाहरण के लिए, यदि X बाइट्स डेटा वाले पहले पैकेट में यह संख्या N थी, तो नए डेटा वाले अगले पैकेट में यह N+X होगी। कॉल की शुरुआत में, प्रत्येक पक्ष इस नंबर को यादृच्छिक रूप से चुनता है।
पावती संख्या (एकनम) - सेक्नम के समान ऑफसेट, लेकिन यह प्रेषित बाइट की संख्या निर्धारित नहीं करता है, बल्कि प्राप्तकर्ता से पहली बाइट की संख्या निर्धारित करता है, जिसे प्रेषक ने नहीं देखा है।

कनेक्शन की शुरुआत में, पार्टियों को सहमत होना होगा seqnum и acknum. क्लाइंट इसके साथ एक SYN पैकेट भेजता है seqnum = X. सर्वर एक SYNACK पैकेट के साथ प्रतिक्रिया करता है, जहां वह अपना खुद का पैकेट लिखता है seqnum = Y और उजागर करता है acknum = X + 1. क्लाइंट SYNACK को ACK पैकेट के साथ प्रतिक्रिया देता है, जहाँ seqnum = X + 1, acknum = Y + 1. उसके बाद, वास्तविक डेटा स्थानांतरण शुरू होता है।

यदि वार्ताकार पैकेट की प्राप्ति की पुष्टि नहीं करता है, तो टीसीपी इसे टाइमआउट तक पुनः भेज देता है।

SYN कुकीज़ का हमेशा उपयोग क्यों नहीं किया जाता?

सबसे पहले, यदि कोई SYNACK या ACK खो जाता है, तो आपको दोबारा भेजने के लिए इंतजार करना होगा - कनेक्शन स्थापना धीमी हो जाती है। दूसरे, SYN पैकेट में - और केवल उसमें! - कई विकल्प प्रसारित होते हैं जो कनेक्शन के आगे के संचालन को प्रभावित करते हैं। आने वाले SYN पैकेटों को याद न रखते हुए, सर्वर इस प्रकार इन विकल्पों को अनदेखा कर देता है, निम्नलिखित पैकेटों में क्लाइंट अब उन्हें नहीं भेजेगा। टीसीपी इस मामले में काम कर सकता है, लेकिन कम से कम प्रारंभिक चरण में, कनेक्शन की गुणवत्ता कम हो जाएगी।

पैकेज के संदर्भ में, एक XDP प्रोग्राम को निम्नलिखित कार्य करना चाहिए:

कुकी के साथ SYNACK के साथ SYN का जवाब दें;
ACK को RST के साथ उत्तर दें (कनेक्शन तोड़ें);
अन्य पैकेट गिराओ.

पैकेट पार्सिंग के साथ एल्गोरिथ्म का छद्म कोड:

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

एक (*) उन बिंदुओं को चिह्नित किया गया है जहां आपको सिस्टम की स्थिति को प्रबंधित करने की आवश्यकता है - पहले चरण में, आप उनके बिना केवल एक SYN कुकी को एक सेक्नम के रूप में उत्पन्न करने के साथ एक टीसीपी हैंडशेक लागू करके कर सकते हैं।

साइट पर (**), जबकि हमारे पास टेबल नहीं है, हम पैकेट छोड़ देंगे।

टीसीपी हैंडशेक कार्यान्वयन

पैकेज पार्सिंग और कोड सत्यापन

हमें नेटवर्क हेडर संरचनाओं की आवश्यकता है: ईथरनेट (uapi/linux/if_ether.h), आईपीवी4 (uapi/linux/ip.h) और टीसीपी (uapi/linux/tcp.h). आखिरी वाला मैं संबंधित त्रुटियों के कारण कनेक्ट नहीं कर सका atomic64_t, मुझे आवश्यक परिभाषाओं को कोड में कॉपी करना पड़ा।

पठनीयता के लिए सी में पहचाने जाने वाले सभी कार्यों को कॉल साइट पर इनलाइन किया जाना चाहिए, क्योंकि कर्नेल में ईबीपीएफ सत्यापनकर्ता बैक जंप को रोकता है, यानी वास्तव में, लूप और फ़ंक्शन कॉल।

#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);
}

मैं ए और बी चिह्नित चेक पर ध्यान देता हूं। यदि आप ए पर टिप्पणी करते हैं, तो प्रोग्राम बन जाएगा, लेकिन लोड करते समय एक सत्यापन त्रुटि होगी:

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;

टीसीपी पोर्ट, आईपी और मैक पते स्वैप करें। मानक लाइब्रेरी 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);

चेकसम पुनर्गणना

आईपीवी4 और टीसीपी चेकसम में हेडर में सभी 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-बिट योग से एक चेकसम बनाता है।

टीसीपी हैंडशेक जांच

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

बाह्य संपर्क से संबंधित नए TODO के लिए प्रस्तुत हुए:

XDP प्रोग्राम स्टोर नहीं कर सकता cookie_seed (नमक का गुप्त हिस्सा) एक वैश्विक चर में, आपको एक कर्नेल स्टोर की आवश्यकता होती है जिसका मूल्य समय-समय पर एक विश्वसनीय जनरेटर से अपडेट किया जाएगा।
यदि ACK पैकेट में SYN कुकी मेल खाती है, तो आपको एक संदेश प्रिंट करने की आवश्यकता नहीं है, लेकिन पैकेट को आगे छोड़ने के लिए सत्यापित क्लाइंट का 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 एसीके है):

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 हमलों के विरुद्ध सुरक्षा लिखते हैं। परमाणु भाग