ჩვენ ვწერთ დაცვას DDoS შეტევებისგან XDP-ზე. ბირთვული ნაწილი

eXpress მონაცემთა ბილიკის (XDP) ტექნოლოგია საშუალებას იძლევა ტრაფიკის თვითნებური დამუშავება Linux ინტერფეისებზე, სანამ პაკეტები შევა ბირთვის ქსელის დასტაში. XDP-ის გამოყენება - დაცვა DDoS შეტევებისგან (CloudFlare), რთული ფილტრები, სტატისტიკის შეგროვება (Netflix). XDP პროგრამები შესრულებულია eBPF ვირტუალური მანქანის მიერ და, შესაბამისად, აქვს შეზღუდვები როგორც მათ კოდზე, ასევე ბირთვის ხელმისაწვდომ ფუნქციებზე, ფილტრის ტიპის მიხედვით.

სტატია მიზნად ისახავს XDP-ზე არსებული მრავალი მასალის ნაკლოვანების ანაზღაურებას. პირველ რიგში, ისინი უზრუნველყოფენ მზა კოდს, რომელიც დაუყოვნებლივ გვერდს უვლის XDP-ის მახასიათებლებს: მომზადებულია გადამოწმებისთვის ან ძალიან მარტივია პრობლემების წარმოშობისთვის. როდესაც მოგვიანებით ცდილობთ დაწეროთ თქვენი საკუთარი კოდი ნულიდან, არ გესმით, რა უნდა გააკეთოთ ტიპიურ შეცდომებთან. მეორეც, ის არ მოიცავს XDP ადგილობრივად ტესტირების გზებს VM-ისა და აპარატურის გარეშე, მიუხედავად იმისა, რომ მათ აქვთ საკუთარი ხარვეზები. ტექსტი განკუთვნილია პროგრამისტებისთვის, რომლებიც კარგად იცნობენ ქსელებსა და Linux-ს, რომლებიც დაინტერესებულნი არიან XDP-ით და eBPF-ით.

ამ ნაწილში ჩვენ დეტალურად გავიგებთ, თუ როგორ არის აწყობილი XDP ფილტრი და როგორ შევამოწმოთ იგი, შემდეგ დავწერთ ცნობილი SYN ქუქიების მექანიზმის მარტივ ვერსიას პაკეტის დამუშავების დონეზე. სანამ არ შევქმნით "თეთრ სიას"
დამოწმებული კლიენტები, შეინახეთ მრიცხველები და მართეთ ფილტრი - საკმარისი ჟურნალი.

ჩვენ დავწერთ C - ეს არ არის მოდური, მაგრამ პრაქტიკული. ყველა კოდი ხელმისაწვდომია GitHub-ზე ბოლო ბმულზე და დაყოფილია ვალდებულებებად სტატიაში აღწერილი ნაბიჯების მიხედვით.

პასუხისმგებლობის უარყოფა. სტატიის მსვლელობისას შემუშავდება მინი გადაწყვეტა DDoS შეტევების მოსაგერიებლად, რადგან ეს არის რეალისტური ამოცანა XDP-სთვის და ჩემი ტერიტორიისთვის. თუმცა, მთავარი მიზანი ტექნოლოგიის გაგებაა, ეს არ არის მზა დაცვის შექმნის სახელმძღვანელო. სამეურვეო კოდი არ არის ოპტიმიზებული და გამოტოვებს ზოგიერთ ნიუანსს.

XDP-ის მოკლე მიმოხილვა

დავასახელებ მხოლოდ ძირითად პუნქტებს, რათა არ მოხდეს დოკუმენტაციის და არსებული სტატიების დუბლირება.

ასე რომ, ფილტრის კოდი იტვირთება ბირთვში. ფილტრს გადაეცემა შემომავალი პაკეტები. შედეგად, ფილტრმა უნდა მიიღოს გადაწყვეტილება: გადასცეს პაკეტი ბირთვს (XDP_PASS), ჩამოაგდე პაკეტი (XDP_DROP) ან გაუგზავნე უკან (XDP_TX). ფილტრს შეუძლია შეცვალოს პაკეტი, ეს განსაკუთრებით ეხება XDP_TX. თქვენ ასევე შეგიძლიათ დაშალოთ პროგრამა (XDP_ABORTED) და ჩამოაგდეთ პაკეტი, მაგრამ ეს ანალოგიურია assert(0) - გამართვისთვის.

eBPF (გაფართოებული ბერკლის პაკეტის ფილტრი) ვირტუალური მანქანა განზრახ გამარტივებულია ისე, რომ ბირთვმა შეძლოს შეამოწმოს, რომ კოდი არ ხვდება და არ აზიანებს სხვა ადამიანების მეხსიერებას. კუმულაციური შეზღუდვები და შემოწმებები:

• მარყუჟები (უკან გადახტომა) აკრძალულია.
• არსებობს მონაცემების დასტა, მაგრამ ფუნქციები არ არის (ყველა C ფუნქცია უნდა იყოს ჩასმული).
• აკრძალულია წვდომა მეხსიერებაზე სტეკისა და პაკეტების ბუფერის გარეთ.
• კოდის ზომა შეზღუდულია, მაგრამ პრაქტიკაში ეს არ არის ძალიან მნიშვნელოვანი.
• დასაშვებია მხოლოდ ბირთვის სპეციალური ფუნქციები (eBPF დამხმარეები).

ფილტრის შემუშავება და დაყენება ასე გამოიყურება:

1. წყაროს კოდი (მაგ. kernel.c) აწყობს ობიექტს (kernel.o) eBPF ვირტუალური მანქანის არქიტექტურისთვის. 2019 წლის ოქტომბრის მდგომარეობით, eBPF-ში შედგენას მხარს უჭერს Clang და დაპირებულია GCC 10.1-ში.
2. თუ ამ ობიექტის კოდში არის ზარები ბირთვის სტრუქტურებზე (მაგალითად, ცხრილებსა და მრიცხველებზე), მათი ID-ების ნაცვლად არის ნულები, ანუ ასეთი კოდი არ შეიძლება შესრულდეს. ბირთვში ჩატვირთვამდე, ეს ნულები უნდა შეიცვალოს ბირთვის გამოძახებით შექმნილი კონკრეტული ობიექტების ID-ებით (დააკავშირეთ კოდი). ამის გაკეთება შეგიძლიათ გარე კომუნალური საშუალებებით, ან შეგიძლიათ დაწეროთ პროგრამა, რომელიც დააკავშირებს და ჩატვირთავს კონკრეტულ ფილტრს.
3. ბირთვი ამოწმებს პროგრამის ჩატვირთვას. ის ამოწმებს ციკლების არარსებობას და პაკეტისა და სტეკის საზღვრებიდან არ გასვლას. თუ შემმოწმებელს არ შეუძლია დაამტკიცოს, რომ კოდი სწორია, პროგრამა უარყოფილია - მას უნდა მოეწონოს.
4. წარმატებული გადამოწმების შემდეგ, ბირთვი აგროვებს eBPF არქიტექტურის ობიექტის კოდს სისტემის არქიტექტურის მანქანის კოდში (უბრალოდ დროულად).
5. პროგრამა ერთვის ინტერფეისს და იწყებს პაკეტების დამუშავებას.

ვინაიდან XDP მუშაობს ბირთვში, გამართვა ეფუძნება კვალის ჟურნალებს და, ფაქტობრივად, პაკეტებს, რომლებსაც პროგრამა ფილტრავს ან ქმნის. თუმცა, eBPF ინახავს ჩამოტვირთულ კოდს სისტემისთვის, ასე რომ თქვენ შეგიძლიათ ექსპერიმენტი XDP-ით პირდაპირ თქვენს ადგილობრივ Linux-ზე.

გარემოს მომზადება

ასამბლეა

Clang-ს არ შეუძლია პირდაპირ გასცეს ობიექტის კოდი eBPF არქიტექტურისთვის, ამიტომ პროცესი შედგება ორი ეტაპისგან:

1. C კოდის შედგენა LLVM ბაიტიკოდში (clang -emit-llvm).
2. გადაიყვანეთ ბაიტიკოდი 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

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. სად შეიძლება ახლა ტესტირება?

სატესტო სტენდი

სტენდი უნდა შეიცავდეს ორ ინტერფეისს: რომელზედაც იქნება ფილტრი და საიდანაც გაიგზავნება პაკეტები. ეს უნდა იყოს სრული Linux მოწყობილობები საკუთარი IP-ებით, რათა შეამოწმოთ როგორ მუშაობს რეგულარული აპლიკაციები ჩვენს ფილტრთან.

ჩვენთვის შესაფერისია ისეთი მოწყობილობები, როგორიცაა veth (ვირტუალური ეთერნეტი): ეს არის წყვილი ვირტუალური ქსელის ინტერფეისი, რომელიც პირდაპირ "დაკავშირებულია" ერთმანეთთან. თქვენ შეგიძლიათ შექმნათ ისინი ასე (ამ განყოფილებაში ყველა ბრძანება ip შესრულებული საწყისი root):

ip link add xdp-remote type veth peer name xdp-local

აქ xdp-remote и xdp-local - მოწყობილობების სახელები. ჩართულია xdp-local (192.0.2.1/24) დამაგრდება ფილტრი, თან xdp-remote (192.0.2.2/24) შემომავალი ტრაფიკი გაიგზავნება. თუმცა, არის პრობლემა: ინტერფეისები ერთსა და იმავე მანქანაზეა და Linux არ გაუგზავნის ტრაფიკს ერთ მათგანს მეორის მეშვეობით. თქვენ შეგიძლიათ გადაჭრათ რთული წესებით iptables, მაგრამ მათ მოუწევთ პაკეტების შეცვლა, რაც მოუხერხებელია გამართვისას. უმჯობესია გამოიყენოთ ქსელის სახელთა სივრცეები (ქსელის სახელთა სივრცეები, შემდგომი ქსელები).

ქსელის სახელთა სივრცე შეიცავს ინტერფეისების კომპლექტს, მარშრუტიზაციის ცხრილებს და NetFilter-ის წესებს, რომლებიც იზოლირებულია სხვა ქსელების მსგავსი ობიექტებისგან. თითოეული პროცესი გადის გარკვეულ სახელთა სივრცეში და მისთვის ხელმისაწვდომია მხოლოდ ამ ქსელის ობიექტები. ნაგულისხმევად, სისტემას აქვს ერთიანი ქსელის სახელების სივრცე ყველა ობიექტისთვის, ასე რომ თქვენ შეგიძლიათ იმუშაოთ Linux-ზე და არ იცოდეთ ქსელების შესახებ.

მოდით შევქმნათ ახალი სახელთა სივრცე 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-ზე, რომელიც ხელმისაწვდომია ამ პროცესისთვის. ეს ასევე მუშაობს საპირისპიროდ.

ქსელებს შორის გადაადგილებისას, ინტერფეისი იშლება და კარგავს მისამართს. ქსელებში ინტერფეისის დასაყენებლად, თქვენ უნდა გაუშვათ 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 საჭიროა ახალი პროგრამის დასაკავშირებლად, თუ სხვა უკვე დაკავშირებულია. "No news is good news" არ არის ამ ბრძანების შესახებ, გამომავალი მაინც მოცულობითია. მიუთითეთ 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 on xdp-remote. მან უნდა აჩვენოს იდენტური გამავალი და შემომავალი ICMP Echo მოთხოვნა და შეწყვიტოს 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])
                                     <...>

რა არის კოდი 6?

$ 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

თუ მის ნაცვლად ნაჩვენებია მხოლოდ ARP, თქვენ უნდა ამოიღოთ ფილტრები (ეს ხდის sudo ./stand detach), მოდით ping, შემდეგ დააინსტალირეთ ფილტრები და სცადეთ ხელახლა. პრობლემა ის არის, რომ ფილტრი XDP_TX გავლენას ახდენს ARP-ზეც და თუ სტეკი
სახელთა სივრცეები xdp-test მოახერხა MAC მისამართის "დავიწყება" 192.0.2.1, ის ვერ შეძლებს ამ IP-ს გადაჭრას.

პრობლემის შესახებ განცხადება

მოდით გადავიდეთ მითითებულ ამოცანაზე: ჩაწერეთ SYN ქუქი-ჩანაწერის მექანიზმი XDP-ზე.

ამ დრომდე, SYN flood რჩება პოპულარულ DDoS შეტევად, რომლის არსი შემდეგია. როდესაც კავშირი დამყარდება (TCP ხელის ჩამორთმევა), სერვერი იღებს SYN-ს, გამოყოფს რესურსებს მომავალი კავშირისთვის, პასუხობს SYNACK პაკეტით და ელოდება ACK-ს. თავდამსხმელი უბრალოდ აგზავნის SYN პაკეტებს ყალბი მისამართებიდან წამში ათასობით ოდენობით თითოეული ჰოსტიდან მრავალათასიან ბოტნეტში. სერვერი იძულებულია გამოყოს რესურსები პაკეტის ჩამოსვლისთანავე, მაგრამ ათავისუფლებს მას დიდი ხნის განმავლობაში, რის შედეგადაც მეხსიერება ან ლიმიტები ამოიწურება, ახალი კავშირები არ მიიღება, სერვისი მიუწვდომელია.

თუ თქვენ არ ანაწილებთ რესურსებს SYN პაკეტზე, მაგრამ პასუხობთ მხოლოდ SYNACK პაკეტით, მაშინ როგორ შეიძლება სერვერმა გაიგოს, რომ მოგვიანებით მოსულ ACK პაკეტი ეკუთვნის SYN პაკეტს, რომელიც არ იყო შენახული? ყოველივე ამის შემდეგ, თავდამსხმელს ასევე შეუძლია შექმნას ყალბი ACK-ები. SYN ქუქი-ფაილის არსი არის დაშიფვრა seqnum კავშირის პარამეტრები, როგორც მისამართების ჰეში, პორტები და ცვალებადი მარილი. თუ ACK-მა მოახერხა მარილის შეცვლამდე ჩამოსვლა, შეგიძლიათ კვლავ გამოთვალოთ ჰეში და შეადაროთ acknum. ყალბი acknum თავდამსხმელს არ შეუძლია, რადგან მარილი შეიცავს საიდუმლოს და არ ექნება დრო მისი დალაგების შეზღუდული არხის გამო.

SYN ქუქი-ფაილები დიდი ხანია დანერგილია Linux-ის ბირთვში და მათი ავტომატურად ჩართვაც კი შესაძლებელია, თუ SYN-ები ძალიან სწრაფად და მასობრივად ჩამოვა.

საგანმანათლებლო პროგრამა 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-ით (გატეხეთ კავშირი);
• ჩამოაგდეს სხვა პაკეტები.

ალგორითმის ფსევდოკოდი პაკეტის ანალიზთან ერთად:

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

ერთი (*) მონიშნულია წერტილები, სადაც საჭიროა სისტემის მდგომარეობის მართვა - პირველ ეტაპზე, თქვენ შეგიძლიათ გააკეთოთ მათ გარეშე უბრალოდ TCP ხელის ჩამორთმევის დანერგვით SYN ქუქი-ფაილის, როგორც seqnum-ის გენერირებით.

Საიტზე (**), სანამ მაგიდა არ გვაქვს, ჩვენ გამოვტოვებთ პაკეტს.

TCP ხელის ჩამორთმევის განხორციელება

პაკეტის ანალიზი და კოდის გადამოწმება

ჩვენ გვჭირდება ქსელის სათაურის სტრუქტურები: Ethernet (uapi/linux/if_ether.h), IPv4 (uapi/linux/ip.h) და TCP (uapi/linux/tcp.h). ბოლო მე ვერ დავაკავშირე შეცდომების გამო atomic64_tმე მომიწია საჭირო განმარტებების კოპირება კოდში.

ყველა ფუნქცია, რომელიც გამოირჩევა C-ში წაკითხვისთვის, უნდა იყოს ჩასმული ზარის ადგილზე, რადგან ბირთვში eBPF ვერიფიკატორი კრძალავს უკანა ნახტომებს, ანუ ფაქტობრივად მარყუჟებს და ფუნქციების გამოძახებას.

#define INTERNAL static __attribute__((always_inline))

მაკრო LOG() გამორთავს ბეჭდვას გამოშვების ვერსიაში.

პროგრამა არის ფუნქციების მილსადენი. თითოეული იღებს პაკეტს, რომელშიც მონიშნულია შესაბამისი დონის სათაური, მაგალითად, process_ether() ელოდება შევსებას ether. საველე ანალიზის შედეგებზე დაყრდნობით, ფუნქციას შეუძლია პაკეტის გადატანა უფრო მაღალ დონეზე. ფუნქციის შედეგი არის XDP მოქმედება. სანამ SYN და ACK დამმუშავებლები უშვებენ ყველა პაკეტს.

struct Packet {
    struct xdp_md* ctx;

    struct ethhdr* ether;
    struct iphdr* ip;
    struct tcphdr* tcp;
};

INTERNAL int process_tcp_syn(struct Packet* packet) { return XDP_PASS; }
INTERNAL int process_tcp_ack(struct Packet* packet) { return XDP_PASS; }
INTERNAL int process_tcp(struct Packet* packet) { ... }
INTERNAL int process_ip(struct Packet* packet) { ... }

INTERNAL int
process_ether(struct Packet* packet) {
    struct ethhdr* ether = packet->ether;

    LOG("Ether(proto=0x%x)", bpf_ntohs(ether->h_proto));

    if (ether->h_proto != bpf_ntohs(ETH_P_IP)) {
        return XDP_PASS;
    }

    // B
    struct iphdr* ip = (struct iphdr*)(ether + 1);
    if ((void*)(ip + 1) > (void*)packet->ctx->data_end) {
        return XDP_DROP; /* malformed packet */
    }

    packet->ip = ip;
    return process_ip(packet);
}

SEC("prog")
int xdp_main(struct xdp_md* ctx) {
    struct Packet packet;
    packet.ctx = ctx;

    // A
    struct ethhdr* ether = (struct ethhdr*)(void*)ctx->data;
    if ((void*)(ether + 1) > (void*)ctx->data_end) {
        return XDP_PASS;
    }

    packet.ether = ether;
    return process_ether(&packet);
}

ყურადღებას ვაქცევ A და B მონიშნულ ჩეკებს. თუ კომენტარს გააკეთებთ A, პროგრამა აშენდება, მაგრამ ჩატვირთვისას იქნება გადამოწმების შეცდომა:

Verifier analysis:

<...>
11: (7b) *(u64 *)(r10 -48) = r1
12: (71) r3 = *(u8 *)(r7 +13)
invalid access to packet, off=13 size=1, R7(id=0,off=0,r=0)
R7 offset is outside of the packet
processed 11 insns (limit 1000000) max_states_per_insn 0 total_states 0 peak_states 0 mark_read 0

Error fetching program/map!

გასაღების სტრიქონი invalid access to packet, off=13 size=1, R7(id=0,off=0,r=0): არის შესრულების ბილიკები, როდესაც ბუფერის დაწყებიდან მეცამეტე ბაიტი არის პაკეტის გარეთ. სიიდან ძნელია იმის თქმა, რომელ ხაზზე ვსაუბრობთ, მაგრამ არის ინსტრუქციის ნომერი (12) და დემონტაჟი, რომელიც აჩვენებს წყაროს კოდის ხაზებს:

llvm-objdump -S xdp_filter.o | less

ამ შემთხვევაში, ის მიუთითებს ხაზზე

LOG("Ether(proto=0x%x)", bpf_ntohs(ether->h_proto));

რაც ცხადყოფს, რომ პრობლემა არის ether. ყოველთვის ასე იქნებოდა.

პასუხი SYN-ზე

მიზანი ამ ეტაპზე არის სწორი SYNACK პაკეტის გენერირება ფიქსირებული seqnum, რომელიც მომავალში შეიცვლება SYN ქუქიით. ყველა ცვლილება ხდება process_tcp_syn() და შემოგარენი.

პაკეტის შემოწმება

უცნაურად საკმარისია, აქ არის ყველაზე ღირსშესანიშნავი ხაზი, უფრო სწორად, კომენტარი მასზე:

/* Required to verify checksum calculation */
const void* data_end = (const void*)ctx->data_end;

კოდის პირველი ვერსიის დაწერისას გამოყენებული იქნა 5.1 ბირთვი, რომლის გადამოწმებისთვისაც იყო განსხვავება data_end и (const void*)ctx->data_end. წერის დროს 5.3.1 ბირთვს ეს პრობლემა არ ქონდა. შესაძლოა, შემდგენელი ლოკალურ ცვლადზე წვდომას სხვაგვარად წვდებოდა, ვიდრე ველზე. მორალი - დიდ ბუდეზე, კოდის გამარტივება დაგეხმარებათ.

სიგრძის შემდგომი რუტინული შემოწმება ვერიფიკატორის დიდებისთვის; ო MAX_CSUM_BYTES Ниже.

const u32 ip_len = ip->ihl * 4;
if ((void*)ip + ip_len > data_end) {
    return XDP_DROP; /* malformed packet */
}
if (ip_len > MAX_CSUM_BYTES) {
    return XDP_ABORTED; /* implementation limitation */
}

const u32 tcp_len = tcp->doff * 4;
if ((void*)tcp + tcp_len > (void*)ctx->data_end) {
    return XDP_DROP; /* malformed packet */
}
if (tcp_len > MAX_CSUM_BYTES) {
    return XDP_ABORTED; /* implementation limitation */
}

პაკეტის გავრცელება

ჩვენ ვავსებთ seqnum и acknum, დააყენეთ ACK (SYN უკვე დაყენებულია):

const u32 cookie = 42;
tcp->ack_seq = bpf_htonl(bpf_ntohl(tcp->seq) + 1);
tcp->seq = bpf_htonl(cookie);
tcp->ack = 1;

შეცვალეთ TCP პორტები, IP და MAC მისამართები. სტანდარტული ბიბლიოთეკა არ არის ხელმისაწვდომი XDP პროგრამიდან, ამიტომ memcpy() - მაკრო, რომელიც მალავს კლანგის შიგთავსს.

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

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

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

საკონტროლო ჯამის ხელახალი გაანგარიშება

IPv4 და TCP საკონტროლო ჯამები მოითხოვს სათაურებში ყველა 16-ბიტიანი სიტყვის დამატებას და მათში იწერება სათაურების ზომა, ანუ შედგენის დროს უცნობია. ეს პრობლემაა, რადგან ვერიფიკატორი არ გამოტოვებს ნორმალურ ციკლს სასაზღვრო ცვლადამდე. მაგრამ სათაურების ზომა შეზღუდულია: თითოეული 64 ბაიტამდე. შეგიძლიათ გააკეთოთ მარყუჟი ფიქსირებული რაოდენობის გამეორებით, რომელიც შეიძლება ადრე დასრულდეს.

აღვნიშნავ, რომ არსებობს RFC 1624 იმის შესახებ, თუ როგორ უნდა გამოვთვალოთ საკონტროლო ჯამი ნაწილობრივ, თუ შეიცვლება მხოლოდ პაკეტების ფიქსირებული სიტყვები. თუმცა, მეთოდი არ არის უნივერსალური და განხორციელების შენარჩუნება უფრო რთული იქნება.

საკონტროლო ჯამის გამოთვლის ფუნქცია:

#define MAX_CSUM_WORDS 32
#define MAX_CSUM_BYTES (MAX_CSUM_WORDS * 2)

INTERNAL u32
sum16(const void* data, u32 size, const void* data_end) {
    u32 s = 0;
#pragma unroll
    for (u32 i = 0; i < MAX_CSUM_WORDS; i++) {
        if (2*i >= size) {
            return s; /* normal exit */
        }
        if (data + 2*i + 1 + 1 > data_end) {
            return 0; /* should be unreachable */
        }
        s += ((const u16*)data)[i];
    }
    return s;
}

მიუხედავად იმისა size შემოწმებულია გამოძახების კოდით, მეორე გასასვლელი პირობაა საჭირო, რათა შემმოწმებელმა დაამტკიცოს მარყუჟის დასასრული.

32-ბიტიანი სიტყვებისთვის დანერგილია უფრო მარტივი ვერსია:

INTERNAL u32
sum16_32(u32 v) {
    return (v >> 16) + (v & 0xffff);
}

რეალურად შემოწმებული ჯამების ხელახალი გამოთვლა და პაკეტის უკან გაგზავნა:

ip->check = 0;
ip->check = carry(sum16(ip, ip_len, data_end));

u32 tcp_csum = 0;
tcp_csum += sum16_32(ip->saddr);
tcp_csum += sum16_32(ip->daddr);
tcp_csum += 0x0600;
tcp_csum += tcp_len << 8;
tcp->check = 0;
tcp_csum += sum16(tcp, tcp_len, data_end);
tcp->check = carry(tcp_csum);

return XDP_TX;

ფუნქცია carry() აკეთებს საკონტროლო ჯამს 32-ბიტიანი სიტყვების 16-ბიტიანი ჯამიდან, RFC 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 on xdp-remote რადგან, მაგალითად, hping3 არ პასუხობს არასწორ შემოწმებას.

SYN ქუქი

XDP-ის თვალსაზრისით, თვით შემოწმება ტრივიალურია. გაანგარიშების ალგორითმი პრიმიტიულია და სავარაუდოდ დაუცველია დახვეწილი თავდამსხმელის მიმართ. მაგალითად, Linux-ის ბირთვი იყენებს კრიპტოგრაფიულ SipHash-ს, მაგრამ მისი განხორციელება 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 საშუალებას გაძლევთ განახორციელოთ საკმაოდ რთული ლოგიკა, რაც, უფრო მეტიც, მარტივია განახლება ტრაფიკის დამუშავების პაუზის გარეშე. ვერიფიკატორი დიდ პრობლემებს არ ქმნის, პირადად მე უარს არ ვიტყოდი მომხმარებლის სივრცის კოდის ნაწილებზე.

მეორე ნაწილში, თუ თემა საინტერესოა, შევავსებთ ვერიფიცირებული კლიენტების ცხრილს და ვარღვევთ კავშირებს, განვახორციელებთ მრიცხველებს და დავწერთ userspace უტილიტას ფილტრის სამართავად.

ბმულები:

• სრული კოდი GitHub-ზე
• bpftrace მოტყუების ფურცელი
• BPF და XDP საცნობარო გზამკვლევი
• XDP გაკვეთილი
• PoC: შედგენა eBPF-ში Rust-დან

წყარო: www.habr.com