🥇आम्ही XDP वर DDoS हल्ल्यांपासून संरक्षण लिहित आहोत. अणुभाग

एक्स्प्रेस डेटा पथ (XDP) तंत्रज्ञान पॅकेट्स कर्नल नेटवर्क स्टॅकमध्ये प्रवेश करण्यापूर्वी लिनक्स इंटरफेसवर यादृच्छिक रहदारी प्रक्रिया करण्यास अनुमती देते. XDP चे ऍप्लिकेशन - DDoS हल्ल्यांपासून संरक्षण (क्लाउडफ्लेअर), जटिल फिल्टर, आकडेवारी संग्रह (नेटफ्लिक्स). XDP प्रोग्राम्स eBPF व्हर्च्युअल मशीनद्वारे कार्यान्वित केले जातात, त्यामुळे फिल्टर प्रकारावर अवलंबून त्यांच्या कोड आणि उपलब्ध कर्नल फंक्शन्सवर निर्बंध असतात.

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

या भागात, XDP फिल्टर कसे एकत्र केले जाते आणि त्याची चाचणी कशी करायची हे आम्ही तपशीलवार समजून घेऊ, त्यानंतर आम्ही पॅकेट प्रक्रिया स्तरावर सुप्रसिद्ध SYN कुकीज यंत्रणेची एक सोपी आवृत्ती लिहू. आम्ही अद्याप "श्वेत यादी" तयार करणार नाही
सत्यापित क्लायंट, काउंटर ठेवा आणि फिल्टर व्यवस्थापित करा - पुरेसे लॉग.

आम्ही सी मध्ये लिहू - ते फॅशनेबल नाही, परंतु ते व्यावहारिक आहे. सर्व कोड GitHub वर शेवटी लिंकद्वारे उपलब्ध आहेत आणि लेखात वर्णन केलेल्या चरणांनुसार कमिटमध्ये विभागले गेले आहेत.

अस्वीकरण. या लेखाच्या दरम्यान, मी DDoS हल्ले रोखण्यासाठी एक मिनी-सोल्यूशन विकसित करेन, कारण हे XDP आणि माझ्या कौशल्याच्या क्षेत्रासाठी एक वास्तववादी कार्य आहे. तथापि, तंत्रज्ञान समजून घेणे हे मुख्य ध्येय आहे, हे तयार संरक्षण तयार करण्यासाठी मार्गदर्शक नाही. ट्यूटोरियल कोड ऑप्टिमाइझ केलेला नाही आणि काही बारकावे वगळले आहेत.

XDP संक्षिप्त विहंगावलोकन

दस्तऐवज आणि विद्यमान लेखांची नक्कल होऊ नये म्हणून मी फक्त मुख्य मुद्द्यांची रूपरेषा देईन.

तर, फिल्टर कोड कर्नलमध्ये लोड केला जातो. येणारे पॅकेट फिल्टरला दिले जातात. परिणामी, फिल्टरने निर्णय घेणे आवश्यक आहे: पॅकेट कर्नलमध्ये पास करा (XDP_PASS), ड्रॉप पॅकेट (XDP_DROP) किंवा परत पाठवा (XDP_TX). फिल्टर पॅकेज बदलू शकतो, हे विशेषतः सत्य आहे XDP_TX. आपण कार्यक्रम रद्द देखील करू शकता (XDP_ABORTED) आणि पॅकेज रीसेट करा, परंतु हे समान आहे assert(0) - डीबगिंगसाठी.

eBPF (विस्तारित बर्कले पॅकेट फिल्टर) व्हर्च्युअल मशीन जाणूनबुजून सोपे केले आहे जेणेकरुन कर्नल तपासू शकेल की कोड लूप होत नाही आणि इतर लोकांच्या मेमरी खराब होत नाही. संचयी निर्बंध आणि तपासणी:

लूप (मागे) प्रतिबंधित आहेत.
डेटासाठी स्टॅक आहे, परंतु कोणतेही कार्य नाहीत (सर्व C फंक्शन्स इनलाइन केलेले असणे आवश्यक आहे).
स्टॅक आणि पॅकेट बफरच्या बाहेर मेमरी प्रवेश प्रतिबंधित आहेत.
कोड आकार मर्यादित आहे, परंतु सराव मध्ये हे फार महत्वाचे नाही.
केवळ विशेष कर्नल फंक्शन्स (eBPF मदतनीस) वर कॉल करण्याची परवानगी आहे.

फिल्टर डिझाइन करणे आणि स्थापित करणे असे दिसते:

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

XDP कर्नलमध्ये चालत असल्याने, डीबगिंग ट्रेस लॉग वापरून केले जाते आणि खरेतर, प्रोग्राम फिल्टर करते किंवा निर्माण करते. तथापि, eBPF हे सुनिश्चित करते की डाउनलोड केलेला कोड सिस्टमसाठी सुरक्षित आहे, त्यामुळे तुम्ही थेट तुमच्या स्थानिक Linux वर XDP चा प्रयोग करू शकता.

वातावरण तयार करणे

असेंब्ली

क्लँग थेट ईबीपीएफ आर्किटेक्चरसाठी ऑब्जेक्ट कोड तयार करू शकत नाही, म्हणून प्रक्रियेमध्ये दोन चरण असतात:

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 बायटेकोडचा आकार मर्यादित आहे.

चला अशा फिल्टरसह प्रारंभ करूया जो सर्व पॅकेट पास करतो आणि काहीही करत नाही:

#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 डिव्हाइस असणे आवश्यक आहे.

व्हेथ (व्हर्च्युअल इथरनेट) प्रकारातील उपकरणे आमच्यासाठी योग्य आहेत: ही व्हर्च्युअल नेटवर्क इंटरफेसची जोडी आहेत जी एकमेकांशी थेट “कनेक्ट” आहेत. तुम्ही त्यांना याप्रमाणे तयार करू शकता (या विभागात सर्व कमांड 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 बद्दल माहिती नाही.

चला नवीन नेमस्पेस तयार करूया 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 एक कार्यक्रम देखील नियुक्त केला गेला, जरी तो रिकामा असला तरीही, आणि त्याला उठवले गेले.

मला हे कसे कळले?

कर्नलमधील पॅकेजचा मार्ग ट्रेस करा परफ इव्हेंट मेकॅनिझम, तसे, समान व्हर्च्युअल मशीन वापरून परवानगी देते, म्हणजे, 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 बाइट्सचा प्रवाह म्हणून डेटा ट्रान्समिशन प्रदान करते, उदाहरणार्थ, HTTP विनंत्या TCP वर प्रसारित केल्या जातात. प्रवाह पॅकेटमध्ये तुकड्यांमध्ये प्रसारित केला जातो. सर्व TCP पॅकेटमध्ये तार्किक ध्वज आणि 32-बिट अनुक्रम क्रमांक आहेत:

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

कनेक्शनच्या सुरूवातीस, पक्षांनी सहमत असणे आवश्यक आहे seqnum и acknum. क्लायंट त्याच्यासह एक SYN पॅकेट पाठवतो seqnum = X. सर्व्हर SYNACK पॅकेटसह प्रतिसाद देतो, जेथे तो त्याची नोंद करतो seqnum = Y आणि उघड करते acknum = X + 1. क्लायंट SYNACK ला ACK पॅकेटसह प्रतिसाद देतो, कुठे 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 कुकीच्या निर्मितीसह 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 बाइट्स पर्यंत. आपण पुनरावृत्तीच्या निश्चित संख्येसह लूप बनवू शकता, जे लवकर समाप्त होऊ शकते.

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

दुसऱ्या भागात, जर विषय मनोरंजक असेल, तर आम्ही सत्यापित क्लायंट आणि डिस्कनेक्शन्सचे सारणी पूर्ण करू, काउंटर लागू करू आणि फिल्टर व्यवस्थापित करण्यासाठी वापरकर्ता स्थान उपयुक्तता लिहू.

दुवे:

स्त्रोत: www.habr.com

आम्ही XDP वर DDoS हल्ल्यांपासून संरक्षण लिहितो. आण्विक भाग