ພວກເຮົາຂຽນການປ້ອງກັນການໂຈມຕີ DDoS ໃນ XDP. ສ່ວນ​ນິວ​ເຄຼຍ

ເທກໂນໂລຍີ eXpress Data Path (XDP) ຊ່ວຍໃຫ້ການປະມວນຜົນການຈາລະຈອນແບບສຸ່ມຖືກປະຕິບັດໃນການໂຕ້ຕອບ Linux ກ່ອນທີ່ແພັກເກັດຈະເຂົ້າໄປໃນ stack ເຄືອຂ່າຍ kernel. ຄໍາຮ້ອງສະຫມັກຂອງ XDP - ການປ້ອງກັນການໂຈມຕີ DDoS (CloudFlare), ການກັ່ນຕອງສະລັບສັບຊ້ອນ, ການເກັບກໍາສະຖິຕິ (Netflix). ໂປລແກລມ XDP ຖືກປະຕິບັດໂດຍເຄື່ອງ virtual eBPF, ດັ່ງນັ້ນພວກມັນມີຂໍ້ຈໍາກັດທັງລະຫັດຂອງພວກເຂົາແລະຫນ້າທີ່ kernel ທີ່ມີຢູ່ຂຶ້ນຢູ່ກັບປະເພດການກັ່ນຕອງ.

ບົດຄວາມມີຈຸດປະສົງເພື່ອຕື່ມຂໍ້ບົກຜ່ອງຂອງວັດສະດຸຈໍານວນຫລາຍໃນ XDP. ກ່ອນອື່ນ ໝົດ, ພວກເຂົາໃຫ້ລະຫັດທີ່ພ້ອມທີ່ຈະເຮັດໂດຍທັນທີທີ່ຂ້າມລັກສະນະຂອງ XDP: ມັນຖືກກະກຽມສໍາລັບການຢັ້ງຢືນຫຼືງ່າຍດາຍເກີນໄປທີ່ຈະເຮັດໃຫ້ເກີດບັນຫາ. ໃນເວລາທີ່ທ່ານຫຼັງຈາກນັ້ນພະຍາຍາມຂຽນລະຫັດຂອງທ່ານຈາກ scratch, ທ່ານບໍ່ມີຄວາມຄິດທີ່ຈະເຮັດແນວໃດກັບຄວາມຜິດພາດປົກກະຕິ. ອັນທີສອງ, ວິທີການທົດສອບ XDP ໃນທ້ອງຖິ່ນໂດຍບໍ່ມີ VM ແລະຮາດແວບໍ່ໄດ້ຖືກຄຸ້ມຄອງ, ເຖິງວ່າຈະມີຄວາມຈິງທີ່ວ່າພວກເຂົາມີຂຸມຂອງຕົນເອງ. ຂໍ້ຄວາມແມ່ນມີຈຸດປະສົງສໍາລັບນັກຂຽນໂປລແກລມທີ່ຄຸ້ນເຄີຍກັບເຄືອຂ່າຍແລະ Linux ທີ່ມີຄວາມສົນໃຈໃນ XDP ແລະ eBPF.

ໃນສ່ວນນີ້, ພວກເຮົາຈະເຂົ້າໃຈຢ່າງລະອຽດວ່າການກັ່ນຕອງ XDP ຖືກປະກອບແລະວິທີການທົດສອບມັນ, ຫຼັງຈາກນັ້ນພວກເຮົາຈະຂຽນແບບງ່າຍໆຂອງກົນໄກການຄຸກກີ SYN ທີ່ມີຊື່ສຽງໃນລະດັບການປຸງແຕ່ງແພັກເກັດ. ພວກເຮົາຈະບໍ່ສ້າງ "ບັນຊີລາຍຊື່ສີຂາວ" ເທື່ອ
ລູກຄ້າທີ່ຖືກຢືນຢັນ, ຮັກສາເຄື່ອງນັບແລະຈັດການການກັ່ນຕອງ - ບັນທຶກພຽງພໍ.

ພວກເຮົາຈະຂຽນໃນ C - ມັນບໍ່ແມ່ນຄົນອັບເດດ:, ແຕ່ມັນປະຕິບັດໄດ້. ລະຫັດທັງຫມົດແມ່ນມີຢູ່ໃນ GitHub ຜ່ານການເຊື່ອມຕໍ່ໃນຕອນທ້າຍແລະແບ່ງອອກເປັນຄໍາຫມັ້ນສັນຍາຕາມຂັ້ນຕອນທີ່ໄດ້ອະທິບາຍໄວ້ໃນບົດຄວາມ.

ການປະຕິເສດ. ໃນໄລຍະຂອງບົດຄວາມນີ້, ຂ້າພະເຈົ້າຈະພັດທະນາການແກ້ໄຂ mini ເພື່ອປ້ອງກັນການໂຈມຕີ DDoS, ເນື່ອງຈາກວ່ານີ້ແມ່ນວຽກງານທີ່ແທ້ຈິງສໍາລັບ XDP ແລະພື້ນທີ່ຄວາມຊ່ຽວຊານຂອງຂ້າພະເຈົ້າ. ຢ່າງໃດກໍ່ຕາມ, ເປົ້າຫມາຍຕົ້ນຕໍແມ່ນເພື່ອເຂົ້າໃຈເຕັກໂນໂລຢີ; ລະຫັດການສອນບໍ່ໄດ້ຖືກປັບໃຫ້ເໝາະສົມ ແລະບໍ່ມີບາງອັນ.

ພາບລວມຂອງ XDP

ຂ້າພະເຈົ້າຈະອະທິບາຍພຽງແຕ່ຈຸດສໍາຄັນເພື່ອບໍ່ໃຫ້ຊ້ໍາກັນເອກະສານແລະບົດຄວາມທີ່ມີຢູ່ແລ້ວ.

ດັ່ງນັ້ນ, ລະຫັດການກັ່ນຕອງຖືກໂຫລດເຂົ້າໄປໃນແກ່ນ. ແພັກເກັດທີ່ເຂົ້າມາແມ່ນຖືກສົ່ງໄປຫາຕົວກອງ. ດັ່ງນັ້ນ, ການກັ່ນຕອງຕ້ອງໄດ້ຕັດສິນໃຈ: ຜ່ານແພັກເກັດເຂົ້າໄປໃນແກ່ນ (.XDP_PASS) ວາງ​ຊອງ (XDP_DROP) ຫຼື​ສົ່ງ​ຄືນ (XDP_TX). ການກັ່ນຕອງສາມາດປ່ຽນຊຸດ, ນີ້ແມ່ນຄວາມຈິງໂດຍສະເພາະສໍາລັບ XDP_TX. ນອກນັ້ນທ່ານຍັງສາມາດຍົກເລີກໂຄງການ (XDP_ABORTED) ແລະຕັ້ງຄ່າຊຸດໃຫມ່, ແຕ່ນີ້ແມ່ນຄ້າຍຄືກັນ assert(0) - ສໍາລັບການ debugging.

ເຄື່ອງ virtual eBPF (extended Berkley Packet Filter) ແມ່ນຖືກສ້າງແບບງ່າຍດາຍໂດຍເຈດຕະນາເພື່ອໃຫ້ kernel ສາມາດກວດເບິ່ງວ່າລະຫັດບໍ່ loop ແລະບໍ່ທໍາລາຍຄວາມຊົງຈໍາຂອງຄົນອື່ນ. ຂໍ້​ຈໍາ​ກັດ​ສະ​ສົມ​ແລະ​ການ​ກວດ​ສອບ​:

• Loops (ກັບ​ຄືນ​ໄປ​ບ່ອນ​) ແມ່ນ​ຫ້າມ​.
• ມີ stack ສໍາລັບຂໍ້ມູນ, ແຕ່ບໍ່ມີຟັງຊັນ (ຟັງຊັນ C ທັງຫມົດຕ້ອງຢູ່ໃນແຖວ).
• ການເຂົ້າເຖິງຄວາມຊົງຈໍາຢູ່ນອກ stack ແລະ packet buffer ແມ່ນຖືກຫ້າມ.
• ຂະຫນາດລະຫັດແມ່ນຈໍາກັດ, ແຕ່ໃນທາງປະຕິບັດ, ນີ້ບໍ່ແມ່ນຄວາມສໍາຄັນຫຼາຍ.
• ອະນຸຍາດໃຫ້ໂທຫາຟັງຊັນ kernel ພິເສດ (ຕົວຊ່ວຍ eBPF) ເທົ່ານັ້ນ.

ການອອກແບບແລະຕິດຕັ້ງຕົວກອງເບິ່ງຄືວ່ານີ້:

1. ລະຫັດແຫຼ່ງ (ຕົວຢ່າງ kernel.c) ຖືກລວບລວມເປັນວັດຖຸ (kernel.o) ສໍາລັບສະຖາປັດຕະຍະກໍາເຄື່ອງ virtual eBPF. ໃນເດືອນຕຸລາ 2019, ການລວບລວມຂໍ້ມູນໃສ່ eBPF ໄດ້ຮັບການສະຫນັບສະຫນູນໂດຍ Clang ແລະສັນຍາໄວ້ໃນ GCC 10.1.
2. ຖ້າລະຫັດວັດຖຸນີ້ມີການໂທຫາໂຄງສ້າງຂອງແກ່ນ (ຕົວຢ່າງ, ຕາຕະລາງແລະຕົວນັບ), ID ຂອງພວກມັນຖືກແທນທີ່ດ້ວຍສູນ, ຊຶ່ງຫມາຍຄວາມວ່າລະຫັດດັ່ງກ່າວບໍ່ສາມາດປະຕິບັດໄດ້. ກ່ອນທີ່ຈະໂຫລດເຂົ້າໄປໃນ kernel, ທ່ານຈໍາເປັນຕ້ອງໄດ້ທົດແທນສູນເຫຼົ່ານີ້ດ້ວຍ IDs ຂອງວັດຖຸສະເພາະທີ່ສ້າງຂຶ້ນໂດຍຜ່ານການໂທ kernel (ເຊື່ອມຕໍ່ລະຫັດ). ທ່ານສາມາດເຮັດສິ່ງນີ້ກັບອຸປະກອນພາຍນອກ, ຫຼືທ່ານສາມາດຂຽນໂປຼແກຼມທີ່ຈະເຊື່ອມຕໍ່ແລະໂຫລດຕົວກອງສະເພາະ.
3. kernel ກວດສອບໂຄງການທີ່ໂຫລດ. ການຂາດຮອບວຽນແລະຄວາມລົ້ມເຫຼວທີ່ຈະເກີນ packet ແລະ stack boundaries ແມ່ນການກວດສອບ. ຖ້າຜູ້ກວດສອບບໍ່ສາມາດພິສູດໄດ້ວ່າລະຫັດຖືກຕ້ອງ, ໂຄງການຖືກປະຕິເສດ - ທ່ານຈໍາເປັນຕ້ອງສາມາດເຮັດໃຫ້ລາວພໍໃຈ.
4. ຫຼັງຈາກການກວດສອບສົບຜົນສໍາເລັດ, kernel ລວບລວມລະຫັດວັດຖຸສະຖາປັດຕະຍະກໍາ eBPF ເຂົ້າໄປໃນລະຫັດເຄື່ອງຈັກສໍາລັບສະຖາປັດຕະຍະກໍາລະບົບ (ພຽງແຕ່ໃນທີ່ໃຊ້ເວລາ).
5. ໂຄງ​ການ​ຕິດ​ກັບ​ການ​ໂຕ້​ຕອບ​ແລະ​ເລີ່ມ​ຕົ້ນ​ການ​ປຸງ​ແຕ່ງ​ຊອງ​.

ນັບຕັ້ງແຕ່ XDP ແລ່ນຢູ່ໃນແກ່ນ, ການດີບັກແມ່ນດໍາເນີນການໂດຍໃຊ້ບັນທຶກການຕິດຕາມແລະ, ໃນຄວາມເປັນຈິງ, ຊຸດທີ່ໂຄງການການກັ່ນຕອງຫຼືສ້າງ. ຢ່າງໃດກໍ່ຕາມ, eBPF ຮັບປະກັນວ່າລະຫັດທີ່ດາວໂຫລດແມ່ນປອດໄພສໍາລັບລະບົບ, ດັ່ງນັ້ນທ່ານສາມາດທົດລອງກັບ XDP ໂດຍກົງໃນ Linux ທ້ອງຖິ່ນຂອງທ່ານ.

ການກະກຽມສະພາບແວດລ້ອມ

Assembly

Clang ບໍ່ສາມາດຜະລິດລະຫັດວັດຖຸໂດຍກົງສໍາລັບສະຖາປັດຕະຍະກໍາ eBPF, ດັ່ງນັ້ນຂະບວນການປະກອບດ້ວຍສອງຂັ້ນຕອນ:

1. ລວບລວມລະຫັດ C ເປັນ LLVM bytecode (clang -emit-llvm).
2. ປ່ຽນ bytecode ເປັນລະຫັດວັດຖຸ eBPF (llc -march=bpf -filetype=obj).

ເມື່ອຂຽນຕົວກອງ, ສອງໄຟລ໌ທີ່ມີຫນ້າທີ່ຊ່ວຍແລະ macros ຈະເປັນປະໂຫຍດ ຈາກ​ການ​ທົດ​ສອບ kernel​. ມັນເປັນສິ່ງ ສຳ ຄັນທີ່ພວກມັນກົງກັບລຸ້ນ kernel (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 (kernel 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 ປະກອບມີເສັ້ນທາງໄປຫາຫົວ kernel, ARCH - ຖາປັດຕະຍະລະບົບ. ເສັ້ນທາງແລະເຄື່ອງມືອາດຈະແຕກຕ່າງກັນເລັກນ້ອຍລະຫວ່າງການແຈກຢາຍ.

ຕົວຢ່າງຄວາມແຕກຕ່າງຂອງ Debian 10 (kernel 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) headers ຖືກກໍານົດສໍາລັບລະຫັດ kernel, ນັບຕັ້ງແຕ່ການກັ່ນຕອງໄດ້ຖືກປະຕິບັດໃນ kernel.

ການປ້ອງກັນ stack ສາມາດຖືກປິດໃຊ້ງານ (-fno-stack-protector), ເນື່ອງຈາກວ່າຕົວກວດສອບລະຫັດ eBPF ຍັງກວດສອບການລ່ວງລະເມີດ stack out-of-bounds. ມັນຄຸ້ມຄ່າທີ່ຈະເປີດການເພີ່ມປະສິດທິພາບທັນທີ, ເພາະວ່າຂະຫນາດຂອງ bytecode 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 (virtual Ethernet) ແມ່ນເຫມາະສົມສໍາລັບພວກເຮົາ: ເຫຼົ່ານີ້ແມ່ນຄູ່ຂອງການໂຕ້ຕອບເຄືອຂ່າຍ virtual "ເຊື່ອມຕໍ່" ໂດຍກົງກັບກັນແລະກັນ. ທ່ານສາມາດສ້າງພວກມັນໄດ້ແບບນີ້ (ໃນພາກນີ້ຄໍາສັ່ງທັງຫມົດ 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 ຈະບໍ່ສົ່ງການຈະລາຈອນໄປຫາຫນຶ່ງໃນນັ້ນໂດຍຜ່ານເຄື່ອງອື່ນ. ທ່ານສາມາດແກ້ໄຂນີ້ດ້ວຍກົດລະບຽບ tricky iptables, ແຕ່ພວກເຂົາເຈົ້າຈະຕ້ອງມີການປ່ຽນແປງການຫຸ້ມຫໍ່, ຊຶ່ງບໍ່ສະດວກສໍາລັບການ debugging. ມັນດີກວ່າທີ່ຈະໃຊ້ namespaces ເຄືອຂ່າຍ (ຕໍ່ໄປນີ້ແມ່ນ netns).

namespace ເຄືອຂ່າຍປະກອບດ້ວຍຊຸດຂອງສ່ວນຕິດຕໍ່, ຕາຕະລາງການກໍານົດເສັ້ນທາງ, ແລະກົດລະບຽບ NetFilter ທີ່ໂດດດ່ຽວຈາກວັດຖຸທີ່ຄ້າຍຄືກັນໃນ netns ອື່ນໆ. ແຕ່ລະຂະບວນການດໍາເນີນການຢູ່ໃນ namespace ແລະມີພຽງແຕ່ເຂົ້າເຖິງວັດຖຸຂອງ netns ນັ້ນ. ໂດຍຄ່າເລີ່ມຕົ້ນ, ລະບົບມີ namespace ເຄືອຂ່າຍດຽວສໍາລັບວັດຖຸທັງຫມົດ, ດັ່ງນັ້ນທ່ານສາມາດເຮັດວຽກຢູ່ໃນ Linux ແລະບໍ່ຮູ້ກ່ຽວກັບ 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. repository ມີ script ທີ່ automates ເຮັດວຽກກັບ stand ໄດ້, ສໍາລັບການຍົກຕົວຢ່າງ, ທ່ານສາມາດ configure stand ດ້ວຍຄໍາສັ່ງ sudo ./stand up ແລະລຶບມັນ sudo ./stand down.

ການຕິດຕາມ

ການກັ່ນຕອງແມ່ນກ່ຽວຂ້ອງກັບອຸປະກອນເຊັ່ນນີ້:

ip -force link set dev xdp-local xdp object xdp_filter.o verbose

Key -force ຕ້ອງການເພື່ອເຊື່ອມຕໍ່ໂຄງການໃຫມ່ຖ້າອັນອື່ນຖືກເຊື່ອມຕໍ່ແລ້ວ. "ບໍ່ມີຂ່າວເປັນຂ່າວດີ" ບໍ່ແມ່ນກ່ຽວກັບຄໍາສັ່ງນີ້, ການສະຫລຸບແມ່ນ voluminous ໃນກໍລະນີໃດກໍ່ຕາມ. ຊີ້ບອກ 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(), ແຕ່ພຽງແຕ່ສະຫນັບສະຫນູນເຖິງສາມ arguments ນອກເຫນືອຈາກຮູບແບບ, ແລະບັນຊີລາຍຊື່ຈໍາກັດຂອງ specifiers. ມະຫາພາກ bpf_printk() ເຮັດໃຫ້ການໂທງ່າຍຂຶ້ນ.

   SEC("prog")
   int xdp_main(struct xdp_md* ctx) {
+      bpf_printk("got packet: %pn", ctx);
       return XDP_PASS;
   }

ຜົນ​ໄດ້​ຮັບ​ໄປ​ຫາ​ຊ່ອງ​ທາງ​ການ​ຕິດ​ຕາມ kernel​, ເຊິ່ງ​ຈໍາ​ເປັນ​ຕ້ອງ​ໄດ້​ຮັບ​ການ​ເປີດ​ໃຊ້​ງານ​:

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'

ສໍາລັບເຫດຜົນນີ້, debug output ຢ່າງຫຼວງຫຼາຍ bloats ລະຫັດຜົນໄດ້ຮັບ.

ກຳລັງສົ່ງແພັກເກັດ XDP

ມາປ່ຽນຕົວກອງກັນ: ໃຫ້ມັນສົ່ງແພັກເກັດທີ່ເຂົ້າມາທັງໝົດຄືນ. ນີ້ແມ່ນບໍ່ຖືກຕ້ອງຈາກທັດສະນະຂອງເຄືອຂ່າຍ, ເນື່ອງຈາກວ່າມັນເປັນສິ່ງຈໍາເປັນທີ່ຈະປ່ຽນທີ່ຢູ່ໃນສ່ວນຫົວ, ແຕ່ໃນປັດຈຸບັນການເຮັດວຽກໃນຫຼັກການແມ່ນສໍາຄັນ.

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

ເປີດຕົວ tcpdump ສຸດ xdp-remote. ມັນຄວນຈະສະແດງໃຫ້ເຫັນການຮ້ອງຂໍ ICMP Echo ຂາອອກແລະຂາເຂົ້າດຽວກັນແລະຢຸດການສະແດງ ICMP Echo Reply. ແຕ່ມັນບໍ່ໄດ້ສະແດງໃຫ້ເຫັນ. ມັນ turns ໃຫ້​ເຫັນ​ວ່າ​ສໍາ​ລັບ​ການ​ເຮັດ​ວຽກ​ XDP_TX ໃນ​ໂຄງ​ການ​ກ່ຽວ​ກັບ​ການ​ xdp-local ແມ່ນມີຄວາມຈໍາເປັນກັບການໂຕ້ຕອບຄູ່ xdp-remote ໂຄງການໄດ້ຖືກມອບຫມາຍ, ເຖິງແມ່ນວ່າມັນຫວ່າງເປົ່າ, ແລະລາວໄດ້ຖືກຍົກຂຶ້ນມາ.

ຂ້ອຍຮູ້ເລື່ອງນີ້ໄດ້ແນວໃດ?

ຕິດຕາມເສັ້ນທາງຂອງຊຸດໃນແກ່ນ ກົນໄກເຫດການ perf ອະນຸຍາດໃຫ້, ໂດຍວິທີທາງການ, ການນໍາໃຊ້ເຄື່ອງ virtual ດຽວກັນ, ນັ້ນແມ່ນ, 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, ເພີ່ມມັນໃສ່ 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 ແລະຖ້າ stack
namespaces 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 ໄດ້ຖືກປະຕິບັດມາດົນແລ້ວໃນ Linux kernel ແລະເຖິງແມ່ນວ່າສາມາດຖືກເປີດໃຊ້ໂດຍອັດຕະໂນມັດຖ້າ SYNs ມາຮອດໄວເກີນໄປແລະມີຈໍານວນຫຼວງຫຼາຍ.

ໂຄງການການສຶກສາກ່ຽວກັບການຈັບມື TCP

TCP ສະຫນອງການສົ່ງຂໍ້ມູນເປັນກະແສຂອງ bytes, ຕົວຢ່າງ, ການຮ້ອງຂໍ HTTP ຖືກສົ່ງຜ່ານ TCP. ກະແສຖືກຖ່າຍທອດເປັນຕ່ອນໆໃນແພັກເກັດ. ແພັກເກັດ TCP ທັງໝົດມີທຸງຕາມເຫດຜົນ ແລະຕົວເລກລຳດັບ 32-ບິດ:

• ການປະສົມປະສານຂອງທຸງກໍານົດບົດບາດຂອງຊຸດສະເພາະ. ທຸງ SYN ຊີ້ໃຫ້ເຫັນວ່ານີ້ແມ່ນແພັກເກັດທໍາອິດຂອງຜູ້ສົ່ງໃນການເຊື່ອມຕໍ່. ທຸງ ACK ຫມາຍຄວາມວ່າຜູ້ສົ່ງໄດ້ຮັບຂໍ້ມູນການເຊື່ອມຕໍ່ທັງຫມົດເຖິງໄບຕ໌ acknum. ແພັກເກັດສາມາດມີຫຼາຍທຸງ ແລະຖືກເອີ້ນໂດຍການລວມກັນຂອງພວກມັນ, ຕົວຢ່າງ, ຊຸດ SYNACK.

• ໝາຍເລກລຳດັບ (seqnum) ລະບຸຄ່າຊົດເຊີຍໃນກະແສຂໍ້ມູນສຳລັບໄບຕ໌ທຳອິດທີ່ຖືກສົ່ງໃນແພັກເກັດນີ້. ຕົວຢ່າງ, ຖ້າຢູ່ໃນແພັກເກັດທໍາອິດທີ່ມີ X bytes ຂອງຂໍ້ມູນຕົວເລກນີ້ແມ່ນ N, ໃນຊຸດຕໍ່ໄປທີ່ມີຂໍ້ມູນໃຫມ່ມັນຈະເປັນ N + X. ໃນຕອນເລີ່ມຕົ້ນຂອງການເຊື່ອມຕໍ່, ແຕ່ລະຝ່າຍເລືອກຕົວເລກນີ້ແບບສຸ່ມ.

• ຈໍານວນການຮັບຮູ້ (acknum) - ຊົດເຊີຍດຽວກັນກັບ seqnum, ແຕ່ມັນບໍ່ໄດ້ກໍານົດຈໍານວນ byte ທີ່ຖືກສົ່ງ, ແຕ່ຈໍານວນ byte ທໍາອິດຈາກຜູ້ຮັບ, ທີ່ຜູ້ສົ່ງບໍ່ເຫັນ.

ໃນຕອນເລີ່ມຕົ້ນຂອງການເຊື່ອມຕໍ່, ຝ່າຍຕ່າງໆຕ້ອງຕົກລົງ 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

ການແຍກແພັກເກັດ ແລະກວດສອບລະຫັດ

ພວກເຮົາຈະຕ້ອງການໂຄງສ້າງຫົວເຄືອຂ່າຍ: Ethernet (uapi/linux/if_ether.h), IPv4 (uapi/linux/ip.h) ແລະ TCP (uapi/linux/tcp.h). ຂ້ອຍບໍ່ສາມາດເຊື່ອມຕໍ່ອັນສຸດທ້າຍໄດ້ເນື່ອງຈາກຄວາມຜິດພາດທີ່ກ່ຽວຂ້ອງກັບ atomic64_t, ຂ້ອຍຕ້ອງຄັດລອກຄໍານິຍາມທີ່ຈໍາເປັນເຂົ້າໄປໃນລະຫັດ.

ຟັງຊັນທັງຫມົດທີ່ເນັ້ນໃສ່ໃນ C ສໍາລັບການອ່ານຕ້ອງຖືກ inlined ຢູ່ຈຸດຂອງການໂທ, ເນື່ອງຈາກວ່າ eBPF verifier ໃນ kernel ຫ້າມ backtracking, ນັ້ນແມ່ນ, ໃນຄວາມເປັນຈິງ, loops ແລະ function calls.

#define INTERNAL static __attribute__((always_inline))

Macro LOG() ປິດໃຊ້ງານການພິມໃນການປ່ອຍຕົວ.

ໂຄງການແມ່ນ conveyor ຂອງຫນ້າທີ່. ແຕ່ລະຄົນໄດ້ຮັບຊຸດທີ່ສ່ວນຫົວລະດັບທີ່ສອດຄ້ອງກັນຖືກເນັ້ນໃສ່, ຕົວຢ່າງ, 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): ມີເສັ້ນທາງປະຕິບັດໃນເວລາທີ່ສິບສາມ byte ຈາກຈຸດເລີ່ມຕົ້ນຂອງ buffer ຢູ່ນອກແພັກເກັດ. ມັນເປັນການຍາກທີ່ຈະເຂົ້າໃຈຈາກລາຍການທີ່ພວກເຮົາກໍາລັງເວົ້າເຖິງ, ແຕ່ມີຄໍາແນະນໍາ (12) ແລະ disassembler ສະແດງເສັ້ນຂອງລະຫັດແຫຼ່ງ:

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() ແລະເຂດອ້ອມຂ້າງ.

ການຢັ້ງຢືນຊຸດ

Oddly ພຽງພໍ, ນີ້ແມ່ນເສັ້ນທີ່ໂດດເດັ່ນທີ່ສຸດ, ຫຼືແທນທີ່ຈະ, ຄໍາເຫັນກ່ຽວກັບມັນ:

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

ໃນເວລາທີ່ຂຽນລະຫັດສະບັບທໍາອິດຂອງ, kernel 5.1 ໄດ້ຖືກນໍາໃຊ້, ສໍາລັບການກວດສອບວ່າມີຄວາມແຕກຕ່າງກັນລະຫວ່າງ. data_end и (const void*)ctx->data_end. ໃນເວລາຂຽນ, kernel 5.3.1 ບໍ່ມີບັນຫານີ້. ມັນເປັນໄປໄດ້ວ່າ compiler ໄດ້ເຂົ້າເຖິງຕົວແປທ້ອງຖິ່ນທີ່ແຕກຕ່າງຈາກພາກສະຫນາມ. ຈັນຍາບັນຂອງເລື່ອງ: ຄວາມງ່າຍດາຍຂອງລະຫັດສາມາດຊ່ວຍໄດ້ໃນເວລາທີ່ມີຮັງຫຼາຍ.

ຕໍ່ໄປແມ່ນການກວດສອບຄວາມຍາວປົກກະຕິສໍາລັບລັດສະຫມີພາບຂອງຕົວກວດສອບ; ອ 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);

ການຄິດໄລ່ຄືນຂອງ checksums

IPv4 ແລະ TCP checksums ຮຽກຮ້ອງໃຫ້ມີການເພີ່ມຄໍາສັບ 16-bit ທັງຫມົດໃນ headers, ແລະຂະຫນາດຂອງ headers ໄດ້ຖືກຂຽນເຂົ້າໄປໃນພວກມັນ, ນັ້ນແມ່ນ, ບໍ່ຮູ້ໃນເວລາລວບລວມ. ນີ້ແມ່ນບັນຫາເພາະວ່າຕົວກວດສອບຈະບໍ່ຂ້າມ loop ປົກກະຕິໄປຫາຕົວແປຂອບເຂດ. ແຕ່ຂະຫນາດຂອງຫົວແມ່ນຈໍາກັດ: ສູງເຖິງ 64 bytes ແຕ່ລະຄົນ. ທ່ານສາມາດເຮັດ loop ທີ່ມີຈໍານວນຄົງທີ່ຂອງ iterations, ເຊິ່ງສາມາດສິ້ນສຸດໄວ.

ຂ້າພະເຈົ້າສັງເກດວ່າມີ RFC 1624 ກ່ຽວກັບວິທີການຄິດໄລ່ບາງສ່ວນຂອງ checksum ຖ້າພຽງແຕ່ຄໍາຄົງທີ່ຂອງແພັກເກັດຖືກປ່ຽນແປງ. ຢ່າງໃດກໍຕາມ, ວິທີການບໍ່ແມ່ນທົ່ວໄປ, ແລະການປະຕິບັດຈະມີຄວາມຫຍຸ້ງຍາກຫຼາຍທີ່ຈະຮັກສາ.

ຟັງຊັນການຄິດໄລ່ 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 ການກວດສອບໂດຍລະຫັດການໂທ, ເງື່ອນໄຂການອອກທີສອງແມ່ນມີຄວາມຈໍາເປັນເພື່ອໃຫ້ຜູ້ກວດສອບສາມາດພິສູດການສໍາເລັດຂອງ loop ໄດ້.

ສໍາລັບຄໍາສັບ 32-bit, ສະບັບທີ່ງ່າຍດາຍແມ່ນປະຕິບັດ:

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

ຕົວຈິງແລ້ວການຄິດໄລ່ checksums ແລະການສົ່ງຊອງຄືນ:

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() ເຮັດໃຫ້ checksum ຈາກຜົນລວມ 32-bit ຂອງຄໍາສັບ 16-bit, ອີງຕາມ RFC 791.

ການຢັ້ງຢືນການຈັບມື TCP

ການກັ່ນຕອງຢ່າງຖືກຕ້ອງສ້າງຕັ້ງການເຊື່ອມຕໍ່ກັບ netcat, ຂາດ ACK ສຸດທ້າຍ, ທີ່ Linux ຕອບສະຫນອງກັບແພັກເກັດ RST, ນັບຕັ້ງແຕ່ stack ເຄືອຂ່າຍບໍ່ໄດ້ຮັບ SYN - ມັນຖືກປ່ຽນເປັນ SYNACK ແລະສົ່ງຄືນ - ແລະຈາກຈຸດຂອງ OS, packet ມາຮອດທີ່ບໍ່ກ່ຽວຂ້ອງກັບການເປີດ. ການເຊື່ອມຕໍ່.

$ 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 ບໍ່ຕອບສະຫນອງກັບ checksums ທີ່ບໍ່ຖືກຕ້ອງ.

SYN cookie

ຈາກທັດສະນະຂອງ XDP, ການກວດສອບຕົວມັນເອງແມ່ນເປັນເລື່ອງເລັກໆນ້ອຍໆ. ສູດການຄິດໄລ່ແມ່ນເບື້ອງຕົ້ນ ແລະອາດຈະມີຄວາມສ່ຽງຕໍ່ກັບຜູ້ໂຈມຕີທີ່ຊັບຊ້ອນ. ຕົວຢ່າງເຊັ່ນ Linux kernel ໃຊ້ SipHash cryptographic, ແຕ່ການປະຕິບັດຂອງມັນສໍາລັບ 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 ແມ່ນເຄື່ອງມືສໍາລັບການແຊກແຊງການປຸງແຕ່ງຂອງແພັກເກັດໂດຍແກ່ນ, ແລະບໍ່ແມ່ນທາງເລືອກສໍາລັບ stack kernel, ເຊັ່ນ DPDK ແລະທາງເລືອກ bypass kernel ອື່ນໆ. ໃນທາງກົງກັນຂ້າມ, XDP ຊ່ວຍໃຫ້ທ່ານສາມາດປະຕິບັດເຫດຜົນທີ່ຂ້ອນຂ້າງສັບສົນ, ເຊິ່ງ, ນອກຈາກນັ້ນ, ງ່າຍຕໍ່ການປັບປຸງໂດຍບໍ່ມີການຂັດຂວາງການປຸງແຕ່ງການຈະລາຈອນ. ຕົວກວດສອບບໍ່ໄດ້ສ້າງບັນຫາໃຫຍ່ໂດຍສ່ວນຕົວ, ຂ້ອຍຈະບໍ່ປະຕິເສດນີ້ສໍາລັບສ່ວນຂອງລະຫັດ userspace.

ໃນສ່ວນທີສອງ, ຖ້າຫົວຂໍ້ແມ່ນຫນ້າສົນໃຈ, ພວກເຮົາຈະເຮັດສໍາເລັດຕາຕະລາງຂອງລູກຄ້າທີ່ຖືກຢືນຢັນແລະການຂັດຂວາງ, ປະຕິບັດຕົວນັບແລະຂຽນ userspace utility ເພື່ອຈັດການການກັ່ນຕອງ.

ເອກະສານອ້າງອີງ:

• ລະຫັດເຕັມໃນ GitHub
• bpftrace Cheat Sheet
• ຄູ່ມືອ້າງອີງ BPF ແລະ XDP
• ການສອນ XDP
• PoC: ການລວບລວມກັບ eBPF ຈາກ Rust

ແຫຼ່ງຂໍ້ມູນ: www.habr.com