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

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

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

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

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

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

एक नज़र में XDP

मैं केवल मुख्य बिंदुओं को रेखांकित करूंगा ताकि डॉक्यूमेंटेशन और मौजूदा लेखों की नकल न की जा सके।

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

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

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

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

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

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

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

सभा

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

1. LLVM bytecode ( clang -emit-llvm ) में C कोड संकलित करें।
2. बाइटकोड को eBPF ऑब्जेक्ट कोड ( llc -march=bpf -filetype=obj ) में llc -march=bpf -filetype=obj ।

फ़िल्टर लिखते समय, कर्नेल परीक्षणों से सहायक कार्यों और मैक्रो के साथ कुछ फाइलें काम में आती हैं। यह महत्वपूर्ण है कि वे कर्नेल संस्करण ( KVER ) से मेल खाते हों। उन्हें helpers/ में डाउनलोड करें 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 में कर्नेल हेडर, KDIR - सिस्टम की वास्तुकला शामिल है। वितरण के बीच पथ और उपकरण थोड़ा भिन्न हो सकते हैं।

 #   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 के साथ पूर्ण लिनक्स डिवाइस होना चाहिए।

वेथ (वर्चुअल ईथरनेट) जैसे डिवाइस हमारे लिए उपयुक्त हैं: वे एक जोड़ी वर्चुअल नेटवर्क इंटरफेस हैं जो सीधे एक दूसरे से "कनेक्ट" होते हैं। आप उन्हें इस तरह से बना सकते हैं (इस अनुभाग में, सभी ip कमांड को root रूप में निष्पादित किया जाता 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 ले xdp-remote ।

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

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

नेटन्स के बीच जाने पर, इंटरफ़ेस ड्रॉप हो जाता है और पता खो देता है। Netns में इंटरफ़ेस को कॉन्फ़िगर करने के लिए, आपको ip ... चलाने की आवश्यकता है ip ... इस ip netns exec कमांड नेमस्पेस 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 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() फ़ंक्शन bpf_trace_printk() समान है, लेकिन केवल तीन तर्कों का समर्थन करता है, टेम्पलेट को छोड़कर, और क्वालीफायर की एक सीमित सूची। bpf_printk() मैक्रो कॉल को सरल करता है।

  SEC("prog") int xdp_main(struct xdp_md* ctx) { + bpf_printk("got packet: %p\n", 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: %p\n' 

इस कारण से, डिबग आउटपुट परिणामी कोड को बहुत बढ़ाता है।

XDP पैकेज भेजना

चलो फ़िल्टर को बदलते हैं: इसे सभी आने वाले पैकेट वापस भेजने दें। यह नेटवर्क के दृष्टिकोण से गलत है, क्योंकि हेडर में पतों को बदलना आवश्यक होगा, लेकिन अब सिद्धांत रूप में काम महत्वपूर्ण है।

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

xdp-remote पर tcpdump चलाएँ। यह समान आउटगोइंग और इनकमिंग ICMP इको रिक्वेस्ट दिखाना चाहिए और ICMP इको रिप्लाई दिखाना बंद कर देना चाहिए। लेकिन दिखा नहीं। यह पता चला है कि XDP_TX लिए xdp-local पर एक प्रोग्राम में काम करने के लिए xdp-local यह आवश्यक है कि xdp-remote इंटरफ़ेस xdp-remote इंटरफ़ेस xdp-remote , भले ही वह खाली हो, और उसे उठाया जाना चाहिए।

 $ 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]) <...> 

 $ errno 6 ENXIO 6 No such device or address 

xdp_dummy.c फ़ाइल में न्यूनतम फ़िल्टर ( XDP_PASS ) को पुनर्स्थापित करें, इसे 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 नेमस्पेस मैक एड्रेस 192.0.2.1 को "भूल" करने में कामयाब रहा, यह इस आईपी को हल करने में सक्षम नहीं होगा।

समस्या का बयान

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

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

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

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

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

• SYN पर प्रतिक्रिया देने के लिए कुकी के साथ SYNACK;
• ACK RST (डिस्कनेक्ट) का जवाब;
• अन्य पैकेट त्यागें।

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

    Ethernet,  .    IPv4,  .     , (*)    ,  .    TCP,  . (**)   SYN,  SYN-ACK  cookie.   ACK,   acknum   cookie,  .      N  . (*)  RST. (**)     . 

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

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

टीसीपी हाथ मिलाना कार्यान्वयन

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

हमें नेटवर्क हेडर संरचनाओं की आवश्यकता है: ईथरनेट ( uapi/linux/if_ether.h ), IPv4 ( uapi/linux/ip.h ) और TCP ( 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 को उत्तर दें

इस स्तर पर लक्ष्य एक निश्चित seqnum साथ एक सही 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 कर्नेल को ऐसी समस्या नहीं थी। शायद संकलक ने स्थानीय चर को क्षेत्र की तुलना में अलग तरीके से एक्सेस किया। Moral - सरलीकृत कोड बहुत सारे घोंसले के शिकार में मदद कर सकता है।

सत्यापनकर्ता के सम्मान में लंबाई की आगे की नियमित जाँच; नीचे के बारे में 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() 32- 16- , RFC 791.

TCP

netcat , ACK, Linux RST-, SYN — SYNACK - , .

 $ 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 .

SYN cookie

XDP . , , . Linux, , SipHash, XDP .

TODO, :

• XDP- cookie_seed ( ) , , .

  
  

• SYN cookie 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 flood , ACK flood, :

 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 kernel bypass. , XDP , , , . , userspace-.

, , , userspace- .

संदर्भ:

• GitHub
• bpftrace Cheat Sheet
• BPF and XDP Reference Guide
• XDP Tutorial
• PoC: compiling to eBPF from Rust