យើងសរសេរការការពារប្រឆាំងនឹងការវាយប្រហារ DDoS លើ XDP ។ ផ្នែកនុយក្លេអ៊ែរ

បច្ចេកវិទ្យា eXpress Data Path (XDP) អនុញ្ញាតឱ្យដំណើរការចរាចរចៃដន្យត្រូវបានអនុវត្តនៅលើចំណុចប្រទាក់លីនុច មុនពេលកញ្ចប់ព័ត៌មានចូលទៅក្នុងជង់បណ្តាញខឺណែល។ កម្មវិធី XDP - ការការពារប្រឆាំងនឹងការវាយប្រហារ DDoS (CloudFlare) តម្រងស្មុគស្មាញ ការប្រមូលស្ថិតិ (Netflix) ។ កម្មវិធី XDP ត្រូវបានប្រតិបត្តិដោយម៉ាស៊ីននិម្មិត eBPF ដូច្នេះពួកគេមានការរឹតបន្តឹងទាំងកូដរបស់ពួកគេ និងមុខងារខឺណែលដែលមានអាស្រ័យលើប្រភេទតម្រង។

អត្ថបទនេះមានគោលបំណងបំពេញចំណុចខ្វះខាតនៃសម្ភារៈជាច្រើននៅលើ XDP ។ ទីមួយ ពួកគេផ្តល់លេខកូដដែលត្រៀមរួចជាស្រេចដែលរំលងលក្ខណៈពិសេសរបស់ XDP ភ្លាមៗ៖ វាត្រូវបានរៀបចំសម្រាប់ការផ្ទៀងផ្ទាត់ ឬសាមញ្ញពេកក្នុងការបង្កបញ្ហា។ នៅពេលអ្នកព្យាយាមសរសេរកូដរបស់អ្នកពីដំបូង អ្នកមិនដឹងថាត្រូវធ្វើអ្វីជាមួយកំហុសធម្មតាទេ។ ទីពីរ វិធីដើម្បីសាកល្បង XDP ក្នុងស្រុកដោយគ្មាន VM និងផ្នែករឹងមិនត្រូវបានគ្របដណ្តប់ទេ បើទោះបីជាពួកគេមានកំហុសផ្ទាល់ខ្លួនក៏ដោយ។ អត្ថបទនេះត្រូវបានបម្រុងទុកសម្រាប់អ្នកសរសេរកម្មវិធីដែលស្គាល់បណ្តាញ និងលីនុចដែលចាប់អារម្មណ៍លើ XDP និង eBPF ។

នៅក្នុងផ្នែកនេះ យើងនឹងយល់យ៉ាងលម្អិតអំពីរបៀបដែលតម្រង XDP ត្រូវបានប្រមូលផ្តុំ និងរបៀបសាកល្បងវា បន្ទាប់មកយើងនឹងសរសេរកំណែសាមញ្ញនៃយន្តការខូគី SYN ដ៏ល្បីល្បាញនៅកម្រិតដំណើរការកញ្ចប់ព័ត៌មាន។ យើងនឹងមិនបង្កើត "បញ្ជីស" នៅឡើយទេ
អតិថិជនដែលបានផ្ទៀងផ្ទាត់ រក្សាបញ្ជរ និងគ្រប់គ្រងតម្រង - កំណត់ហេតុគ្រប់គ្រាន់។

យើង​នឹង​សរសេរ​ជា C - វា​មិន​ទាន់សម័យ​ទេ ប៉ុន្តែ​វា​ជា​ការ​អនុវត្ត​ជាក់ស្តែង។ កូដទាំងអស់មាននៅលើ GitHub តាមរយៈតំណភ្ជាប់នៅចុងបញ្ចប់ ហើយត្រូវបានបែងចែកទៅជាការប្រព្រឹត្តតាមដំណាក់កាលដែលបានពិពណ៌នានៅក្នុងអត្ថបទ។

ការបដិសេធ។ ក្នុងអំឡុងពេលនៃអត្ថបទនេះ ខ្ញុំនឹងបង្កើតដំណោះស្រាយខ្នាតតូច ដើម្បីទប់ស្កាត់ការវាយប្រហារដោយ DDoS ពីព្រោះនេះគឺជាកិច្ចការជាក់ស្តែងសម្រាប់ XDP និងផ្នែកជំនាញរបស់ខ្ញុំ។ ទោះជាយ៉ាងណាក៏ដោយ គោលដៅសំខាន់គឺត្រូវយល់ពីបច្ចេកវិទ្យានេះ មិនមែនជាការណែនាំដើម្បីបង្កើតការការពារដែលត្រៀមរួចជាស្រេចនោះទេ។ កូដបង្រៀនមិនត្រូវបានធ្វើឱ្យប្រសើរទេ ហើយលុបចោលនូវចំណុចមួយចំនួន។

ទិដ្ឋភាពទូទៅសង្ខេប XDP

ខ្ញុំនឹងគូសបញ្ជាក់តែចំណុចសំខាន់ៗប៉ុណ្ណោះ ដើម្បីកុំឱ្យចម្លងឯកសារ និងអត្ថបទដែលមានស្រាប់។

ដូច្នេះ កូដតម្រងត្រូវបានផ្ទុកទៅក្នុងខឺណែល។ កញ្ចប់ព័ត៌មានចូលត្រូវបានបញ្ជូនទៅតម្រង។ ជាលទ្ធផល តម្រងត្រូវតែធ្វើការសម្រេចចិត្ត៖ បញ្ជូនកញ្ចប់ព័ត៌មានទៅក្នុងខឺណែល (XDP_PASS) ទម្លាក់កញ្ចប់ (XDP_DROP) ឬផ្ញើវាមកវិញ (XDP_TX) តម្រងអាចផ្លាស់ប្តូរកញ្ចប់ នេះជាការពិតជាពិសេសសម្រាប់ XDP_TX. អ្នកក៏អាចបោះបង់កម្មវិធី (XDP_ABORTED) ហើយកំណត់កញ្ចប់ឡើងវិញ ប៉ុន្តែនេះគឺស្រដៀងគ្នា assert(0) - សម្រាប់ការកែកំហុស។

ម៉ាស៊ីននិម្មិត eBPF (extended Berkley Packet Filter) ត្រូវបានបង្កើតឡើងដោយចេតនាសាមញ្ញ ដើម្បីឱ្យខឺណែលអាចពិនិត្យមើលថាកូដមិនរង្វិលជុំ និងមិនធ្វើឱ្យខូចការចងចាំរបស់អ្នកដទៃ។ ការរឹតបន្តឹង និងការត្រួតពិនិត្យបន្ថែម៖

• រង្វិលជុំ (ថយក្រោយ) ត្រូវបានហាមឃាត់។
• មានជង់សម្រាប់ទិន្នន័យ ប៉ុន្តែមិនមានមុខងារទេ (មុខងារ C ទាំងអស់ត្រូវតែដាក់ក្នុងជួរ)។
• ការចូលប្រើអង្គចងចាំនៅខាងក្រៅជង់ និងសតិបណ្ដោះអាសន្នកញ្ចប់ព័ត៌មានត្រូវបានហាមឃាត់។
• ទំហំ​កូដ​មាន​កម្រិត ប៉ុន្តែ​ក្នុង​ការ​អនុវត្ត​នេះ​មិន​សូវ​សំខាន់​ទេ។
• មានតែការហៅទៅកាន់មុខងារខឺណែលពិសេស (អ្នកជំនួយ eBPF) ប៉ុណ្ណោះដែលត្រូវបានអនុញ្ញាត។

ការរចនា និងដំឡើងតម្រងមើលទៅដូចនេះ៖

1. កូដប្រភព (ឧ kernel.c) ត្រូវបានចងក្រងជាវត្ថុ (kernel.o) សម្រាប់ស្ថាបត្យកម្មម៉ាស៊ីននិម្មិត eBPF ។ គិតត្រឹមខែតុលា ឆ្នាំ 2019 ការចងក្រងទៅ eBPF ត្រូវបានគាំទ្រដោយ Clang និងបានសន្យានៅក្នុង GCC 10.1 ។
2. ប្រសិនបើកូដវត្ថុនេះមានការហៅទៅកាន់រចនាសម្ព័ន្ធខឺណែល (ឧទាហរណ៍ តារាង និងបញ្ជរ) លេខសម្គាល់របស់ពួកគេត្រូវបានជំនួសដោយលេខសូន្យ ដែលមានន័យថាកូដបែបនេះមិនអាចប្រតិបត្តិបានទេ។ មុនពេលផ្ទុកទៅក្នុងខឺណែល អ្នកត្រូវជំនួសលេខសូន្យទាំងនេះជាមួយនឹងលេខសម្គាល់នៃវត្ថុជាក់លាក់ដែលបានបង្កើតតាមរយៈការហៅទូរស័ព្ទខឺណែល (ភ្ជាប់កូដ)។ អ្នកអាចធ្វើដូចនេះជាមួយឧបករណ៍ប្រើប្រាស់ខាងក្រៅ ឬអ្នកអាចសរសេរកម្មវិធីដែលនឹងភ្ជាប់ និងផ្ទុកតម្រងជាក់លាក់មួយ។
3. ខឺណែលផ្ទៀងផ្ទាត់កម្មវិធីដែលបានផ្ទុក។ អវត្ដមាននៃវដ្ត និងការបរាជ័យក្នុងការលើសពីកញ្ចប់ព័ត៌មាន និងព្រំដែនជង់ត្រូវបានពិនិត្យ។ ប្រសិនបើអ្នកផ្ទៀងផ្ទាត់មិនអាចបង្ហាញថាលេខកូដត្រឹមត្រូវទេ កម្មវិធីត្រូវបានបដិសេធ - អ្នកត្រូវតែអាចផ្គាប់ចិត្តគាត់។
4. បន្ទាប់ពីការផ្ទៀងផ្ទាត់ដោយជោគជ័យ ខឺណែលចងក្រងកូដវត្ថុស្ថាបត្យកម្ម eBPF ទៅជាកូដម៉ាស៊ីនសម្រាប់ស្ថាបត្យកម្មប្រព័ន្ធ (គ្រាន់តែនៅក្នុងពេលវេលា)។
5. កម្មវិធីភ្ជាប់ទៅចំណុចប្រទាក់ ហើយចាប់ផ្តើមដំណើរការកញ្ចប់ព័ត៌មាន។

ចាប់តាំងពី XDP ដំណើរការនៅក្នុងខឺណែល ការបំបាត់កំហុសត្រូវបានអនុវត្តដោយប្រើកំណត់ហេតុតាមដាន ហើយជាការពិត កញ្ចប់ព័ត៌មានដែលកម្មវិធីចម្រោះ ឬបង្កើត។ ទោះយ៉ាងណាក៏ដោយ eBPF ធានាថាកូដដែលបានទាញយកគឺមានសុវត្ថិភាពសម្រាប់ប្រព័ន្ធ ដូច្នេះអ្នកអាចពិសោធន៍ជាមួយ XDP ដោយផ្ទាល់នៅលើលីនុចក្នុងស្រុករបស់អ្នក។

ការរៀបចំបរិស្ថាន

សន្និបាត

Clang មិនអាចបង្កើតកូដវត្ថុដោយផ្ទាល់សម្រាប់ស្ថាបត្យកម្ម eBPF បានទេ ដូច្នេះដំណើរការមានពីរជំហាន៖

1. ចងក្រងកូដ C ទៅជា LLVM bytecode (clang -emit-llvm).
2. បំលែង bytecode ទៅ eBPF object code (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

Makefile សម្រាប់ Arch Linux (ខឺណែល 5.3.7)៖

CLANG ?= clang
LLC ?= llc

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

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

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

.PHONY: all clean

all: xdp_filter.o

clean:
    rm -f ./*.o

KDIR មានផ្លូវទៅកាន់បឋមកថាខឺណែល ARCH - ស្ថាបត្យកម្មប្រព័ន្ធ។ ផ្លូវ និងឧបករណ៍អាចប្រែប្រួលបន្តិចបន្តួចរវាងការចែកចាយ។

ឧទាហរណ៍នៃភាពខុសគ្នាសម្រាប់ Debian 10 (ខឺណែល 4.19.67)

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

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

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

CFLAGS ភ្ជាប់​ថត​ជាមួយ​បឋមកថា​ជំនួយ និង​ថត​មួយ​ចំនួន​ជាមួយ​បឋមកថា​ខឺណែល។ និមិត្តសញ្ញា __KERNEL__ មានន័យថា បឋមកថា UAPI (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. សាកល្បងនៅឯណាឥឡូវនេះ?

ឈរសាកល្បង

កន្លែងឈរត្រូវតែរួមបញ្ចូលចំណុចប្រទាក់ពីរ៖ ដែលនឹងមានតម្រង និងពីកញ្ចប់ព័ត៌មានណាមួយនឹងត្រូវបានផ្ញើ។ ទាំងនេះត្រូវតែជាឧបករណ៍លីនុចពេញលេញជាមួយនឹង IPs ផ្ទាល់របស់ពួកគេ ដើម្បីពិនិត្យមើលថាតើកម្មវិធីធម្មតាដំណើរការជាមួយតម្រងរបស់យើង។

ឧបករណ៍នៃប្រភេទ veth (virtual Ethernet) គឺសមរម្យសម្រាប់យើង៖ ទាំងនេះគឺជាគូនៃចំណុចប្រទាក់បណ្តាញនិម្មិត "បានភ្ជាប់" ដោយផ្ទាល់ទៅគ្នាទៅវិញទៅមក។ អ្នកអាចបង្កើតពួកវាដូចនេះ (នៅក្នុងផ្នែកនេះ ពាក្យបញ្ជាទាំងអស់។ 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) ។

ចន្លោះឈ្មោះបណ្តាញមានសំណុំនៃចំណុចប្រទាក់ តារាងនាំផ្លូវ និងច្បាប់ NetFilter ដែលដាច់ឆ្ងាយពីវត្ថុស្រដៀងគ្នានៅក្នុង netns ផ្សេងទៀត។ ដំណើរការនីមួយៗដំណើរការក្នុង namespace ហើយមានសិទ្ធិចូលប្រើតែវត្ថុនៃ netns នោះ។ តាមលំនាំដើម ប្រព័ន្ធមានលំហបណ្តាញតែមួយសម្រាប់វត្ថុទាំងអស់ ដូច្នេះអ្នកអាចធ្វើការនៅក្នុងលីនុច ហើយមិនដឹងអំពី netns ទេ។

តោះបង្កើត namespace ថ្មី។ 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 ... នៅក្នុង namespace ពាក្យបញ្ជានេះ។ 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 នៅក្នុង namespace លំនាំដើម៖

    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. ឃ្លាំងមានស្គ្រីបដែលដំណើរការដោយស្វ័យប្រវត្តជាមួយ stand; ឧទាហរណ៍ អ្នកអាចកំណត់រចនាសម្ព័ន្ធឈរដោយប្រើពាក្យបញ្ជា 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.

Ping គួរតែចាប់ផ្តើមសារដូចនេះ៖

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

ប្រសិនបើអ្នកក្រឡេកមើលលទ្ធផលរបស់អ្នកផ្ទៀងផ្ទាត់ឱ្យបានដិតដល់ អ្នកនឹងសម្គាល់ឃើញការគណនាចម្លែក៖

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

ការពិតគឺថាកម្មវិធី eBPF មិនមានផ្នែកទិន្នន័យទេ ដូច្នេះវិធីតែមួយគត់ដើម្បីអ៊ិនកូដខ្សែអក្សរទ្រង់ទ្រាយគឺជាអាគុយម៉ង់ភ្លាមៗនៃពាក្យបញ្ជា VM៖

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

សម្រាប់ហេតុផលនេះ លទ្ធផលបំបាត់កំហុសធ្វើឱ្យកូដលទ្ធផលដំណើរការយ៉ាងខ្លាំង។

កំពុងផ្ញើកញ្ចប់ XDP

តោះផ្លាស់ប្តូរតម្រង៖ អនុញ្ញាតឱ្យវាបញ្ជូនកញ្ចប់ព័ត៌មានចូលទាំងអស់។ នេះមិនត្រឹមត្រូវតាមទស្សនៈរបស់បណ្តាញ ព្រោះថាវាចាំបាច់ក្នុងការផ្លាស់ប្តូរអាសយដ្ឋាននៅក្នុងបឋមកថា ប៉ុន្តែឥឡូវនេះការងារជាគោលការណ៍មានសារៈសំខាន់។

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

បើកដំណើរការ tcpdump នៅលើ xdp-remote. វាគួរតែបង្ហាញ ICMP Echo Request ចេញ និងចូលដូចគ្នា ហើយឈប់បង្ហាញ ICMP Echo Reply ។ ប៉ុន្តែវាមិនបង្ហាញទេ។ វាប្រែថាសម្រាប់ការងារ XDP_TX នៅក្នុងកម្មវិធីនៅលើ xdp-local គឺចាំបាច់ទៅចំណុចប្រទាក់គូ xdp-remote កម្មវិធីមួយក៏ត្រូវបានចាត់តាំងផងដែរ ទោះបីជាវាទទេក៏ដោយ ហើយគាត់ត្រូវបានលើកឡើង។

តើខ្ញុំដឹងរឿងនេះដោយរបៀបណា?

តាមដានផ្លូវនៃកញ្ចប់មួយនៅក្នុងខឺណែល។ យន្តការព្រឹត្តិការណ៍ perf អនុញ្ញាតដោយវិធីនេះ ដោយប្រើម៉ាស៊ីននិម្មិតដូចគ្នា ពោលគឺ 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])
                                     <...>

តើលេខកូដ ៦ ជាអ្វី?

$ errno 6
ENXIO 6 No such device or address

មុខងារ veth_xdp_flush_bq() ទទួលបានលេខកូដកំហុសពី veth_xdp_xmit()ដែលជាកន្លែងដែលស្វែងរកដោយ ENXIO និងស្វែងរកមតិយោបល់។

តោះស្តារតម្រងអប្បបរមា (XDP_PASS) នៅក្នុងឯកសារ xdp_dummy.cបន្ថែមវាទៅ Makefile ចងវាទៅ xdp-remote:

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

ឥឡូវនេះ tcpdump បង្ហាញពីអ្វីដែលរំពឹងទុក៖

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

ប្រសិនបើមានតែ ARPs ត្រូវបានបង្ហាញជំនួសវិញ អ្នកត្រូវដកតម្រងចេញ (វាកើតឡើង sudo ./stand detach), តោះ​ទៅ pingបន្ទាប់មកកំណត់តម្រង ហើយព្យាយាមម្តងទៀត។ បញ្ហាគឺថាតម្រង XDP_TX មានសុពលភាពទាំងនៅលើ ARP និងប្រសិនបើជង់
ចន្លោះឈ្មោះ xdp-test គ្រប់គ្រងដើម្បី "បំភ្លេច" អាសយដ្ឋាន MAC 192.0.2.1 វានឹងមិនអាចដោះស្រាយ IP នេះបានទេ។

ការបង្កើតបញ្ហា

ចូរបន្តទៅកិច្ចការដែលបានបញ្ជាក់៖ សរសេរយន្តការខូគី SYN នៅលើ XDP ។

ទឹកជំនន់ SYN នៅតែជាការវាយប្រហារ DDoS ដ៏ពេញនិយម ដែលខ្លឹមសារមានដូចខាងក្រោម។ នៅពេលដែលការតភ្ជាប់ត្រូវបានបង្កើតឡើង (ការចាប់ដៃ TCP) ម៉ាស៊ីនមេទទួលបាន SYN បែងចែកធនធានសម្រាប់ការតភ្ជាប់នាពេលអនាគត ឆ្លើយតបជាមួយកញ្ចប់ SYNACK ហើយរង់ចាំ ACK ។ អ្នកវាយប្រហារគ្រាន់តែផ្ញើកញ្ចប់ SYN រាប់ពាន់ក្នុងមួយវិនាទីពីអាសយដ្ឋានក្លែងក្លាយពីម៉ាស៊ីននីមួយៗនៅក្នុង botnet ដែលមានកម្លាំងច្រើនពាន់។ ម៉ាស៊ីនមេត្រូវបានបង្ខំឱ្យបែងចែកធនធានភ្លាមៗនៅពេលការមកដល់នៃកញ្ចប់ព័ត៌មាន ប៉ុន្តែបញ្ចេញពួកវាបន្ទាប់ពីអស់ពេលច្រើនជាលទ្ធផល អង្គចងចាំ ឬដែនកំណត់ត្រូវបានអស់ ការតភ្ជាប់ថ្មីមិនត្រូវបានទទួលយក ហើយសេវាកម្មនេះមិនអាចប្រើបានទេ។

ប្រសិនបើអ្នកមិនបែងចែកធនធានដោយផ្អែកលើកញ្ចប់ព័ត៌មាន SYN ប៉ុន្តែគ្រាន់តែឆ្លើយតបជាមួយកញ្ចប់ព័ត៌មាន SYNACK នោះ តើម៉ាស៊ីនមេអាចយល់ដោយរបៀបណាថាកញ្ចប់ព័ត៌មាន ACK ដែលបានមកដល់នៅពេលក្រោយសំដៅលើកញ្ចប់ព័ត៌មាន SYN ដែលមិនត្រូវបានរក្សាទុក? យ៉ាងណាមិញ អ្នកវាយប្រហារក៏អាចបង្កើត ACKs ក្លែងក្លាយផងដែរ។ ចំនុចនៃខូគី SYN គឺការអ៊ិនកូដវាចូល seqnum ប៉ារ៉ាម៉ែត្រនៃការតភ្ជាប់ជា hash នៃអាសយដ្ឋាន ច្រក និងការផ្លាស់ប្តូរអំបិល។ ប្រសិនបើ ACK អាចមកដល់មុនពេលអំបិលត្រូវបានផ្លាស់ប្តូរ អ្នកអាចគណនា hash ម្តងទៀត ហើយប្រៀបធៀបវាជាមួយ acknum. ក្លែងបន្លំ acknum អ្នកវាយប្រហារមិនអាចទេ ព្រោះអំបិលរួមបញ្ចូលអាថ៌កំបាំង ហើយនឹងមិនមានពេលវេលាដើម្បីតម្រៀបវាទេ ដោយសារឆានែលមានកំណត់។

ខូគី SYN ត្រូវបានអនុវត្តជាយូរមកហើយនៅក្នុងខឺណែលលីនុច ហើយថែមទាំងអាចបើកដំណើរការដោយស្វ័យប្រវត្តិ ប្រសិនបើ SYNs មកដល់លឿនពេក និងមានទំហំធំ។

កម្មវិធីអប់រំអំពីការចាប់ដៃ TCP

TCP ផ្តល់នូវការបញ្ជូនទិន្នន័យជាស្ទ្រីមនៃបៃ ឧទាហរណ៍ សំណើ HTTP ត្រូវបានបញ្ជូនតាម TCP ។ ស្ទ្រីមត្រូវបានបញ្ជូនជាបំណែកនៅក្នុងកញ្ចប់។ កញ្ចប់ TCP ទាំងអស់មានទង់ឡូជីខល និងលេខលំដាប់ 32 ប៊ីត៖

• ការរួមបញ្ចូលគ្នានៃទង់កំណត់តួនាទីនៃកញ្ចប់ជាក់លាក់មួយ។ ទង់ SYN បង្ហាញថានេះគឺជាកញ្ចប់ព័ត៌មានដំបូងរបស់អ្នកផ្ញើនៅលើការតភ្ជាប់។ ទង់ ACK មានន័យថាអ្នកផ្ញើបានទទួលទិន្នន័យតភ្ជាប់ទាំងអស់រហូតដល់បៃ acknum. កញ្ចប់ព័ត៌មានអាចមានទង់ជាច្រើន ហើយត្រូវបានហៅដោយការរួមបញ្ចូលគ្នារបស់ពួកគេ ឧទាហរណ៍ កញ្ចប់ SYNACK ។

• លេខលំដាប់ (seqnum) បញ្ជាក់អុហ្វសិតក្នុងស្ទ្រីមទិន្នន័យសម្រាប់បៃដំបូងដែលត្រូវបានបញ្ជូនក្នុងកញ្ចប់ព័ត៌មាននេះ។ ឧទាហរណ៍ ប្រសិនបើនៅក្នុងកញ្ចប់ព័ត៌មានដំបូងដែលមាន X បៃនៃទិន្នន័យ លេខនេះគឺជា N នោះនៅក្នុងកញ្ចប់បន្ទាប់ដែលមានទិន្នន័យថ្មីវានឹងជា N + X ។ នៅដំណាក់កាលដំបូងនៃការតភ្ជាប់ ភាគីនីមួយៗជ្រើសរើសលេខនេះដោយចៃដន្យ។

• លេខការទទួលស្គាល់ (acknum) - អុហ្វសិតដូចគ្នានឹង seqnum ប៉ុន្តែវាមិនកំណត់ចំនួនបៃដែលត្រូវបានបញ្ជូនទេ ប៉ុន្តែចំនួនបៃដំបូងពីអ្នកទទួលដែលអ្នកផ្ញើមិនបានឃើញ។

នៅដើមដំបូងនៃការតភ្ជាប់ភាគីត្រូវតែយល់ព្រម seqnum и acknum. អតិថិជនផ្ញើកញ្ចប់ SYN ជាមួយវា។ seqnum = X. ម៉ាស៊ីនមេឆ្លើយតបជាមួយនឹងកញ្ចប់ SYNACK ដែលវាកត់ត្រារបស់វា។ seqnum = Y និងលាតត្រដាង acknum = X + 1. អតិថិជនឆ្លើយតបទៅនឹង SYNACK ជាមួយនឹងកញ្ចប់ព័ត៌មាន ACK ដែលជាកន្លែងដែល seqnum = X + 1, acknum = Y + 1. បន្ទាប់ពីនេះ ការផ្ទេរទិន្នន័យពិតប្រាកដចាប់ផ្តើម។

ប្រសិនបើមិត្តភ័ក្តិមិនទទួលស្គាល់ការទទួលកញ្ចប់ព័ត៌មានទេ TCP នឹងបញ្ជូនវាឡើងវិញបន្ទាប់ពីអស់ពេល។

ហេតុអ្វីបានជាខូគី SYN មិនតែងតែប្រើ?

ទីមួយ ប្រសិនបើ SYNACK ឬ ACK ត្រូវបានបាត់បង់ អ្នកនឹងត្រូវរង់ចាំវាត្រូវបានផ្ញើម្តងទៀត - ការដំឡើងការតភ្ជាប់នឹងថយចុះ។ ទីពីរនៅក្នុងកញ្ចប់ SYN - ហើយមានតែនៅក្នុងវាប៉ុណ្ណោះ! - ជម្រើសមួយចំនួនត្រូវបានបញ្ជូន ដែលប៉ះពាល់ដល់ប្រតិបត្តិការបន្ថែមទៀតនៃការតភ្ជាប់។ ដោយមិនចាំកញ្ចប់ SYN ចូលទេ ដូច្នេះម៉ាស៊ីនមេមិនអើពើជម្រើសទាំងនេះទេ អតិថិជននឹងមិនផ្ញើពួកវានៅក្នុងកញ្ចប់បន្ទាប់ទេ។ TCP អាចដំណើរការក្នុងករណីនេះ ប៉ុន្តែយ៉ាងហោចណាស់នៅដំណាក់កាលដំបូង គុណភាពនៃការតភ្ជាប់នឹងថយចុះ។

នៅក្នុងលក្ខខណ្ឌនៃកញ្ចប់កម្មវិធី XDP ត្រូវធ្វើដូចខាងក្រោម:

• ឆ្លើយតបទៅ SYN ជាមួយ SYNACK ជាមួយខូគី;
• ឆ្លើយតបទៅនឹង ACK ជាមួយ RST (ផ្តាច់);
• បោះចោលកញ្ចប់ដែលនៅសល់។

Pseudocode នៃ algorithm រួមជាមួយនឹងការញែកកញ្ចប់៖

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

មួយ។ (*) ចំណុចដែលអ្នកត្រូវការដើម្បីគ្រប់គ្រងស្ថានភាពនៃប្រព័ន្ធត្រូវបានសម្គាល់ - នៅដំណាក់កាលដំបូងអ្នកអាចធ្វើបានដោយគ្មានពួកវាដោយគ្រាន់តែអនុវត្តការចាប់ដៃ TCP ជាមួយនឹងការបង្កើតខូគី SYN ជា seqnum ។

នៅ​នឹង​កន្លែង (**)ខណៈពេលដែលយើងមិនមានតុ យើងនឹងរំលងកញ្ចប់ព័ត៌មាន។

ការអនុវត្តការចាប់ដៃ 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() - ម៉ាក្រូដែលលាក់ខាងក្នុង Clang ។

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

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

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

ការគណនាឡើងវិញនៃមូលប្បទានប័ត្រ

ការពិនិត្យ IPv4 និង TCP ទាមទារការបន្ថែមពាក្យ 16 ប៊ីតទាំងអស់នៅក្នុងបឋមកថា ហើយទំហំនៃបឋមកថាត្រូវបានសរសេរទៅក្នុងពួកវា ពោលគឺមិនស្គាល់នៅពេលចងក្រង។ នេះ​ជា​បញ្ហា​ព្រោះ​អ្នក​ផ្ទៀងផ្ទាត់​នឹង​មិន​រំលង​រង្វិលជុំ​ធម្មតា​ទៅ​អថេរ​ព្រំដែន។ ប៉ុន្តែទំហំនៃបឋមកថាត្រូវបានកំណត់: រហូតដល់ 64 បៃនីមួយៗ។ អ្នកអាចបង្កើតរង្វិលជុំជាមួយនឹងចំនួនថេរនៃការធ្វើដដែលៗ ដែលអាចបញ្ចប់មុន។

ខ្ញុំកត់សំគាល់ថាមាន RFC 1624 អំពីរបៀបគណនាមូលប្បទានប័ត្រដោយផ្នែក ប្រសិនបើមានតែពាក្យថេរនៃកញ្ចប់ត្រូវបានផ្លាស់ប្តូរ។ ទោះជាយ៉ាងណាក៏ដោយ វិធីសាស្ត្រនេះមិនមែនជាសកលទេ ហើយការអនុវត្តនឹងកាន់តែលំបាកក្នុងការថែរក្សា។

មុខងារគណនា Checksum៖

#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 ចុងក្រោយ ដែលលីនុចបានឆ្លើយតបជាមួយកញ្ចប់ព័ត៌មាន 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 មិនឆ្លើយតបទៅនឹងមូលប្បទានប័ត្រមិនត្រឹមត្រូវទេ។

SYN cookie

តាមទស្សនៈ XDP ការផ្ទៀងផ្ទាត់ខ្លួនវាគឺមិនសំខាន់។ ក្បួនដោះស្រាយការគណនាគឺមានលក្ខណៈបឋម ហើយទំនងជាងាយរងគ្រោះចំពោះអ្នកវាយប្រហារដ៏ទំនើប។ ជាឧទាហរណ៍ ខឺណែលលីនុច ប្រើកូដគ្រីប SipHash ប៉ុន្តែការអនុវត្តរបស់វាសម្រាប់ XDP គឺហួសពីវិសាលភាពនៃអត្ថបទនេះ។

ណែនាំសម្រាប់ TODOs ថ្មីទាក់ទងនឹងទំនាក់ទំនងខាងក្រៅ៖

• កម្មវិធី XDP មិនអាចរក្សាទុកបានទេ។ cookie_seed (ផ្នែកសម្ងាត់នៃអំបិល) នៅក្នុងអថេរសកល អ្នកត្រូវការការផ្ទុកនៅក្នុងខឺណែល តម្លៃដែលនឹងត្រូវបានធ្វើបច្ចុប្បន្នភាពជាទៀងទាត់ពីម៉ាស៊ីនភ្លើងដែលអាចទុកចិត្តបាន។

• ប្រសិនបើខូគី SYN ត្រូវគ្នានៅក្នុងកញ្ចប់ព័ត៌មាន ACK អ្នកមិនចាំបាច់បោះពុម្ពសារទេ ប៉ុន្តែត្រូវចងចាំ IP របស់អតិថិជនដែលបានផ្ទៀងផ្ទាត់ ដើម្បីបន្តឆ្លងកាត់កញ្ចប់ព័ត៌មានពីវា។

ការផ្ទៀងផ្ទាត់អតិថិជនស្របច្បាប់៖

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

កំណត់ហេតុបង្ហាញថាការត្រួតពិនិត្យបានឆ្លងកាត់ (flags=0x2 - នេះគឺជា SYN flags=0x10 គឺ ACK)៖

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

ខណៈពេលដែលមិនមានបញ្ជី IPs ដែលបានផ្ទៀងផ្ទាត់ វានឹងមិនមានការការពារពីទឹកជំនន់ 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 អនុញ្ញាតឱ្យអ្នកអនុវត្តតក្កវិជ្ជាដ៏ស្មុគស្មាញ ដែលលើសពីនេះទៅទៀត វាងាយស្រួលក្នុងការធ្វើបច្ចុប្បន្នភាពដោយមិនមានការរំខានក្នុងដំណើរការចរាចរណ៍។ កម្មវិធីផ្ទៀងផ្ទាត់មិនបង្កើតបញ្ហាធំដោយផ្ទាល់ទេ ខ្ញុំនឹងមិនបដិសេធចំពោះផ្នែកនៃកូដកន្លែងប្រើប្រាស់ទេ។

នៅក្នុងផ្នែកទីពីរ ប្រសិនបើប្រធានបទគួរឱ្យចាប់អារម្មណ៍ យើងនឹងបំពេញតារាងអតិថិជនដែលបានផ្ទៀងផ្ទាត់ និងការផ្តាច់ អនុវត្តការរាប់ និងសរសេរឧបករណ៍ប្រើប្រាស់កន្លែងប្រើប្រាស់ដើម្បីគ្រប់គ្រងតម្រង។

ឯកសារយោង:

• កូដពេញលេញនៅលើ GitHub
• bpfrace សន្លឹកបន្លំ
• មគ្គុទ្ទេសក៍យោង BPF និង XDP
• ការបង្រៀន XDP
• PoC: ចងក្រងទៅ eBPF ពី Rust

ប្រភព: www.habr.com