XDP-യിൽ DDoS ആക്രമണങ്ങൾക്കെതിരെ ഞങ്ങൾ പരിരക്ഷ എഴുതുന്നു. ന്യൂക്ലിയർ ഭാഗം

ഇന്റർഫേസുകളിൽ അനിയന്ത്രിതമായ ട്രാഫിക് പ്രോസസ്സിംഗ് പ്രാപ്തമാക്കുന്ന eXpress ഡാറ്റ പാത്ത് (XDP) സാങ്കേതികവിദ്യ. Linux പാക്കറ്റുകൾ കേർണൽ നെറ്റ്‌വർക്ക് സ്റ്റാക്കിൽ പ്രവേശിക്കുന്നതിന് മുമ്പ്. XDP ആപ്ലിക്കേഷനുകളിൽ DDoS സംരക്ഷണം (CloudFlare), സങ്കീർണ്ണമായ ഫിൽട്ടറുകൾ, സ്റ്റാറ്റിസ്റ്റിക്സ് ശേഖരണം (Netflix) എന്നിവ ഉൾപ്പെടുന്നു. XDP പ്രോഗ്രാമുകൾ eBPF വെർച്വൽ മെഷീനാണ് നടപ്പിലാക്കുന്നത്, അതിനാൽ ഫിൽട്ടർ തരം അനുസരിച്ച് അവയുടെ കോഡിലും ലഭ്യമായ കേർണൽ ഫംഗ്ഷനുകളിലും പരിമിതികളുണ്ട്.

XDP-യിലെ നിരവധി മെറ്റീരിയലുകളുടെ പോരായ്മകൾ പരിഹരിക്കുക എന്നതാണ് ഈ ലേഖനത്തിന്റെ ലക്ഷ്യം. ഒന്നാമതായി, XDP-യുടെ സവിശേഷതകളെ ഉടനടി മറികടക്കുന്ന റെഡിമെയ്ഡ് കോഡ് അവർ നൽകുന്നു: ഇത് സ്ഥിരീകരണത്തിനായി തയ്യാറാക്കിയതോ അല്ലെങ്കിൽ പ്രശ്നങ്ങൾ സൃഷ്ടിക്കാൻ വളരെ ലളിതമോ ആണ്. ആദ്യം മുതൽ നിങ്ങളുടെ സ്വന്തം കോഡ് എഴുതാൻ ശ്രമിക്കുമ്പോൾ, സാധാരണ പിശകുകൾ എങ്ങനെ കൈകാര്യം ചെയ്യണമെന്ന് മനസ്സിലാക്കാൻ പ്രയാസമാണ്. രണ്ടാമതായി, VM അല്ലെങ്കിൽ ഹാർഡ്‌വെയർ ഇല്ലാതെ XDP പ്രാദേശികമായി പരിശോധിക്കുന്നതിനുള്ള രീതികൾ ഇത് ഉൾക്കൊള്ളുന്നില്ല, ഈ രീതികൾക്ക് അവരുടേതായ പോരായ്മകൾ ഉണ്ടെങ്കിലും. നെറ്റ്‌വർക്കുകളുമായി പരിചയമുള്ള പ്രോഗ്രാമർമാർക്കും Linux, XDP, eBPF എന്നിവയിൽ താൽപ്പര്യമുള്ളവർ.

ഈ ഭാഗത്ത്, XDP ഫിൽട്ടർ എങ്ങനെ കൂട്ടിച്ചേർക്കപ്പെടുന്നുവെന്നും അത് എങ്ങനെ പരിശോധിക്കാമെന്നും ഞങ്ങൾ വിശദമായി മനസ്സിലാക്കും, തുടർന്ന് പാക്കറ്റ് പ്രോസസ്സിംഗ് തലത്തിൽ അറിയപ്പെടുന്ന SYN കുക്കീസ് ​​മെക്കാനിസത്തിൻ്റെ ഒരു ലളിതമായ പതിപ്പ് ഞങ്ങൾ എഴുതും. ഞങ്ങൾ ഇതുവരെ ഒരു "വൈറ്റ് ലിസ്റ്റ്" സൃഷ്ടിക്കില്ല
പരിശോധിച്ച ക്ലയൻ്റുകൾ, കൗണ്ടറുകൾ സൂക്ഷിക്കുക, ഫിൽട്ടർ നിയന്ത്രിക്കുക - മതിയായ ലോഗുകൾ.

ഞങ്ങൾ സിയിൽ എഴുതും - ഇത് ഫാഷനല്ല, പക്ഷേ ഇത് പ്രായോഗികമാണ്. എല്ലാ കോഡുകളും അവസാനത്തെ ലിങ്ക് വഴി GitHub-ൽ ലഭ്യമാണ്, ലേഖനത്തിൽ വിവരിച്ചിരിക്കുന്ന ഘട്ടങ്ങൾക്കനുസരിച്ച് കമ്മിറ്റുകളായി തിരിച്ചിരിക്കുന്നു.

നിരാകരണം. ഈ ലേഖനത്തിനിടയിൽ, DDoS ആക്രമണങ്ങളിൽ നിന്ന് രക്ഷനേടാൻ ഞാൻ ഒരു മിനി-സൊല്യൂഷൻ വികസിപ്പിക്കും, കാരണം ഇത് XDP-യ്ക്കും എൻ്റെ വൈദഗ്ധ്യത്തിൻ്റെ മേഖലയ്ക്കും ഒരു യഥാർത്ഥ ചുമതലയാണ്. എന്നിരുന്നാലും, സാങ്കേതികവിദ്യ മനസ്സിലാക്കുക എന്നതാണ് പ്രധാന ലക്ഷ്യം, ഇത് റെഡിമെയ്ഡ് സംരക്ഷണം സൃഷ്ടിക്കുന്നതിനുള്ള ഒരു വഴികാട്ടിയല്ല. ട്യൂട്ടോറിയൽ കോഡ് ഒപ്റ്റിമൈസ് ചെയ്തിട്ടില്ല കൂടാതെ ചില സൂക്ഷ്മതകൾ ഒഴിവാക്കുകയും ചെയ്യുന്നു.

XDP സംക്ഷിപ്ത അവലോകനം

ഡോക്യുമെൻ്റേഷനും നിലവിലുള്ള ലേഖനങ്ങളും തനിപ്പകർപ്പാക്കാതിരിക്കാൻ ഞാൻ പ്രധാന പോയിൻ്റുകൾ മാത്രം രൂപപ്പെടുത്തും.

അതിനാൽ, ഫിൽട്ടർ കോഡ് കേർണലിലേക്ക് ലോഡ് ചെയ്തു. ഇൻകമിംഗ് പാക്കറ്റുകൾ ഫിൽട്ടറിലേക്ക് കൈമാറുന്നു. തൽഫലമായി, ഫിൽട്ടർ ഒരു തീരുമാനം എടുക്കണം: പാക്കറ്റ് കേർണലിലേക്ക് കടത്തിവിടുക (XDP_PASS), ഡ്രോപ്പ് പാക്കറ്റ് (XDP_DROP) അല്ലെങ്കിൽ തിരികെ അയയ്ക്കുക (XDP_TX). ഫിൽട്ടറിന് പാക്കേജ് മാറ്റാൻ കഴിയും, ഇത് പ്രത്യേകിച്ചും സത്യമാണ് XDP_TX. നിങ്ങൾക്ക് പ്രോഗ്രാം നിർത്തലാക്കാനും കഴിയും (XDP_ABORTED) കൂടാതെ പാക്കേജ് പുനഃസജ്ജമാക്കുക, എന്നാൽ ഇത് സമാനമാണ് assert(0) - ഡീബഗ്ഗിംഗിന്.

eBPF (എക്‌സ്റ്റെൻഡഡ് ബെർക്ക്‌ലി പാക്കറ്റ് ഫിൽട്ടർ) വെർച്വൽ മെഷീൻ ബോധപൂർവം ലളിതമാക്കിയതിനാൽ കോഡ് ലൂപ്പ് ചെയ്യുന്നില്ലെന്നും മറ്റുള്ളവരുടെ മെമ്മറി കേടുവരുത്തുന്നില്ലെന്നും കേർണലിന് പരിശോധിക്കാൻ കഴിയും. ക്യുമുലേറ്റീവ് നിയന്ത്രണങ്ങളും പരിശോധനകളും:

• ലൂപ്പുകൾ (പിന്നിലേക്ക്) നിരോധിച്ചിരിക്കുന്നു.
• ഡാറ്റയ്ക്കായി ഒരു സ്റ്റാക്ക് ഉണ്ട്, എന്നാൽ ഫംഗ്ഷനുകളൊന്നുമില്ല (എല്ലാ സി ഫംഗ്ഷനുകളും ഇൻലൈൻ ചെയ്തിരിക്കണം).
• സ്റ്റാക്കിനും പാക്കറ്റ് ബഫറിനും പുറത്തുള്ള മെമ്മറി ആക്‌സസ്സ് നിരോധിച്ചിരിക്കുന്നു.
• കോഡ് വലുപ്പം പരിമിതമാണ്, എന്നാൽ പ്രായോഗികമായി ഇത് വളരെ പ്രധാനമല്ല.
• പ്രത്യേക കേർണൽ ഫംഗ്‌ഷനുകളിലേക്കുള്ള (eBPF സഹായികൾ) കോളുകൾ മാത്രമേ അനുവദിക്കൂ.

ഒരു ഫിൽട്ടർ രൂപകൽപ്പന ചെയ്യുന്നതും ഇൻസ്റ്റാൾ ചെയ്യുന്നതും ഇതുപോലെ കാണപ്പെടുന്നു:

1. ഉറവിട കോഡ് (ഉദാ kernel.c) ഒബ്ജക്റ്റിലേക്ക് സമാഹരിച്ചിരിക്കുന്നു (kernel.o) eBPF വെർച്വൽ മെഷീൻ ആർക്കിടെക്ചറിനായി. 2019 ഒക്‌ടോബർ മുതൽ, eBPF-ലേക്കുള്ള സമാഹാരം Clang പിന്തുണയ്‌ക്കുകയും GCC 10.1-ൽ വാഗ്ദാനം ചെയ്യുകയും ചെയ്യുന്നു.
2. ഈ ഒബ്‌ജക്റ്റ് കോഡിൽ കേർണൽ ഘടനകളിലേക്കുള്ള കോളുകൾ അടങ്ങിയിട്ടുണ്ടെങ്കിൽ (ഉദാഹരണത്തിന്, പട്ടികകളും കൗണ്ടറുകളും), അവയുടെ ഐഡികൾ പൂജ്യങ്ങളാൽ മാറ്റിസ്ഥാപിക്കപ്പെടുന്നു, അതായത് അത്തരം കോഡ് എക്‌സിക്യൂട്ട് ചെയ്യാൻ കഴിയില്ല. കേർണലിലേക്ക് ലോഡുചെയ്യുന്നതിന് മുമ്പ്, കേർണൽ കോളുകൾ വഴി സൃഷ്ടിച്ച നിർദ്ദിഷ്ട ഒബ്‌ജക്റ്റുകളുടെ ഐഡികൾ ഉപയോഗിച്ച് ഈ പൂജ്യങ്ങൾ മാറ്റിസ്ഥാപിക്കേണ്ടതുണ്ട് (കോഡ് ലിങ്ക് ചെയ്യുക). ബാഹ്യ യൂട്ടിലിറ്റികൾ ഉപയോഗിച്ച് നിങ്ങൾക്ക് ഇത് ചെയ്യാൻ കഴിയും, അല്ലെങ്കിൽ ഒരു നിർദ്ദിഷ്ട ഫിൽട്ടർ ലിങ്ക് ചെയ്ത് ലോഡ് ചെയ്യുന്ന ഒരു പ്രോഗ്രാം നിങ്ങൾക്ക് എഴുതാം.
3. കേർണൽ ലോഡ് ചെയ്ത പ്രോഗ്രാം പരിശോധിക്കുന്നു. സൈക്കിളുകളുടെ അഭാവവും പാക്കറ്റ്, സ്റ്റാക്ക് ബൗണ്ടറികൾ കവിയാനുള്ള പരാജയവും പരിശോധിക്കുന്നു. കോഡ് ശരിയാണെന്ന് വെരിഫയർ തെളിയിക്കുന്നില്ലെങ്കിൽ, പ്രോഗ്രാം നിരസിക്കപ്പെട്ടു - നിങ്ങൾക്ക് അവനെ പ്രസാദിപ്പിക്കാൻ കഴിയണം.
4. വിജയകരമായ സ്ഥിരീകരണത്തിന് ശേഷം, കേർണൽ eBPF ആർക്കിടെക്ചർ ഒബ്‌ജക്റ്റ് കോഡ് സിസ്റ്റം ആർക്കിടെക്ചറിനായുള്ള മെഷീൻ കോഡിലേക്ക് സമാഹരിക്കുന്നു (ഇത് സമയത്തുതന്നെ).
5. പ്രോഗ്രാം ഇൻ്റർഫേസുമായി ബന്ധിപ്പിച്ച് പാക്കറ്റുകൾ പ്രോസസ്സ് ചെയ്യാൻ തുടങ്ങുന്നു.

XDP കേർണലിൽ പ്രവർത്തിക്കുന്നതിനാൽ, ട്രേസ് ലോഗുകളും പ്രോഗ്രാം ഫിൽട്ടർ ചെയ്യുന്നതോ സൃഷ്ടിക്കുന്നതോ ആയ പാക്കറ്റുകളും ഉപയോഗിച്ചാണ് ഡീബഗ്ഗിംഗ് നടത്തുന്നത്. എന്നിരുന്നാലും, സിസ്റ്റത്തിനായി ലോഡ് ചെയ്ത കോഡിന്റെ സുരക്ഷ eBPF ഉറപ്പാക്കുന്നു, അതിനാൽ നിങ്ങൾക്ക് നിങ്ങളുടെ ലോക്കൽ മെഷീനിൽ നേരിട്ട് XDP പരീക്ഷിക്കാൻ കഴിയും. Linux.

പരിസ്ഥിതി ഒരുക്കുന്നു

നിയമസഭ

eBPF ആർക്കിടെക്ചറിനായി Clang-ന് നേരിട്ട് ഒബ്‌ജക്റ്റ് കോഡ് നിർമ്മിക്കാൻ കഴിയില്ല, അതിനാൽ പ്രക്രിയ രണ്ട് ഘട്ടങ്ങൾ ഉൾക്കൊള്ളുന്നു:

1. LLVM ബൈറ്റ്കോഡിലേക്ക് C കോഡ് കംപൈൽ ചെയ്യുക (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

ആർച്ചിനുള്ള മേക്ക് ഫയൽ 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__ കേർണലിൽ ഫിൽട്ടർ എക്സിക്യൂട്ട് ചെയ്തിരിക്കുന്നതിനാൽ യുഎപിഐ (യൂസ്‌പേസ് എപിഐ) ഹെഡറുകൾ കേർണൽ കോഡിനായി നിർവചിച്ചിരിക്കുന്നു എന്നാണ് അർത്ഥമാക്കുന്നത്.

സ്റ്റാക്ക് സംരക്ഷണം പ്രവർത്തനരഹിതമാക്കാം (-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 മുതൽ നടത്തപ്പെടുന്നു 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, എന്നാൽ അവർ പാക്കേജുകൾ മാറ്റേണ്ടിവരും, ഇത് ഡീബഗ്ഗിംഗിന് അസൗകര്യമാണ്. നെറ്റ്‌വർക്ക് നെയിംസ്‌പെയ്‌സുകൾ ഉപയോഗിക്കുന്നതാണ് നല്ലത് (ഇനി മുതൽ നെറ്റ്‌നുകൾ).

ഒരു നെറ്റ്‌വർക്ക് നെയിംസ്‌പെയ്‌സിൽ മറ്റ് നെറ്റ്‌വർക്ക് നാമങ്ങളിലെ സമാന ഒബ്‌ജക്റ്റുകളിൽ നിന്ന് വേർതിരിച്ചെടുത്ത ഒരു കൂട്ടം ഇന്റർഫേസുകൾ, റൂട്ടിംഗ് ടേബിളുകൾ, നെറ്റ്ഫിൽട്ടർ നിയമങ്ങൾ എന്നിവ അടങ്ങിയിരിക്കുന്നു. ഓരോ പ്രക്രിയയും ഒരു പ്രത്യേക നെയിംസ്‌പെയ്‌സിൽ പ്രവർത്തിക്കുന്നു, കൂടാതെ ആ നെറ്റ്‌വർക്ക് നെയിംസ്‌പെയ്‌സിനുള്ളിലെ ഒബ്‌ജക്റ്റുകൾക്ക് മാത്രമേ ആക്‌സസ് ചെയ്യാൻ കഴിയൂ. സ്ഥിരസ്ഥിതിയായി, സിസ്റ്റത്തിന് എല്ലാ ഒബ്‌ജക്റ്റുകൾക്കുമായി ഒരൊറ്റ നെറ്റ്‌വർക്ക് നെയിംസ്‌പെയ്‌സ് ഉണ്ട്, അതിനാൽ നിങ്ങൾക്ക് പ്രവർത്തിക്കാൻ കഴിയും Linux നെറ്റ്സിനെക്കുറിച്ചും അറിയില്ല.

നമുക്ക് ഒരു പുതിയ നെയിംസ്പേസ് ഉണ്ടാക്കാം xdp-test അങ്ങോട്ടു മാറ്റുക xdp-remote.

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

തുടർന്ന് പ്രക്രിയ പ്രവർത്തിക്കുന്നു xdp-test, "കാണില്ല" xdp-local (അത് സ്ഥിരസ്ഥിതിയായി നെറ്റ്‌നുകളിൽ നിലനിൽക്കും) ഒരു പാക്കറ്റ് 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 മറ്റൊന്ന് ഇതിനകം ലിങ്ക് ചെയ്തിട്ടുണ്ടെങ്കിൽ ഒരു പുതിയ പ്രോഗ്രാം ലിങ്ക് ചെയ്യേണ്ടത് ആവശ്യമാണ്. “ഒരു വാർത്തയും നല്ല വാർത്തയല്ല” എന്നത് ഈ കമാൻഡിനെക്കുറിച്ചല്ല, ഏത് സാഹചര്യത്തിലും നിഗമനം വളരെ വലുതാണ്. സൂചിപ്പിക്കുക 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 ഉപയോഗിച്ച് ഡിസ്അസംബ്ലി ചെയ്യാൻ 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 പരിഹരിക്കാൻ കഴിയില്ല.

പ്രശ്ന പ്രസ്താവന

നമുക്ക് പ്രസ്താവിച്ച ടാസ്ക്കിലേക്ക് പോകാം: XDP-യിൽ ഒരു SYN കുക്കികൾ മെക്കാനിസം എഴുതുക.

SYN വെള്ളപ്പൊക്കം ഒരു ജനപ്രിയ 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. ഒരു പാക്കറ്റിന് നിരവധി ഫ്ലാഗുകൾ ഉണ്ടായിരിക്കാം, അവയുടെ സംയോജനത്താൽ വിളിക്കപ്പെടുന്നു, ഉദാഹരണത്തിന്, ഒരു സിനാക്ക് പാക്കറ്റ്.

• സീക്വൻസ് നമ്പർ (seqnum) ഈ പാക്കറ്റിൽ കൈമാറ്റം ചെയ്യപ്പെടുന്ന ആദ്യ ബൈറ്റിനുള്ള ഡാറ്റ സ്ട്രീമിലെ ഓഫ്സെറ്റ് വ്യക്തമാക്കുന്നു. ഉദാഹരണത്തിന്, X ബൈറ്റ് ഡാറ്റയുള്ള ആദ്യ പാക്കറ്റിൽ ഈ നമ്പർ N ആയിരുന്നുവെങ്കിൽ, പുതിയ ഡാറ്റയുള്ള അടുത്ത പാക്കറ്റിൽ ഇത് N+X ആയിരിക്കും. കണക്ഷൻ്റെ തുടക്കത്തിൽ, ഓരോ വശവും ഈ നമ്പർ ക്രമരഹിതമായി തിരഞ്ഞെടുക്കുന്നു.

• അംഗീകാര നമ്പർ (അക്‌നം) - seqnum-ൻ്റെ അതേ ഓഫ്‌സെറ്റ്, എന്നാൽ ഇത് കൈമാറ്റം ചെയ്യപ്പെടുന്ന ബൈറ്റിൻ്റെ എണ്ണം നിർണ്ണയിക്കുന്നില്ല, എന്നാൽ സ്വീകർത്താവിൽ നിന്നുള്ള ആദ്യ ബൈറ്റിൻ്റെ എണ്ണം, അത് അയച്ചയാൾ കണ്ടില്ല.

കണക്ഷൻ്റെ തുടക്കത്തിൽ, കക്ഷികൾ സമ്മതിക്കണം seqnum и acknum. ക്ലയൻ്റ് അതിൻ്റെ കൂടെ ഒരു SYN പാക്കറ്റ് അയയ്ക്കുന്നു seqnum = X. സെർവർ ഒരു SYNACK പാക്കറ്റ് ഉപയോഗിച്ച് പ്രതികരിക്കുന്നു, അവിടെ അത് രേഖപ്പെടുത്തുന്നു seqnum = Y തുറന്നുകാട്ടുകയും ചെയ്യുന്നു acknum = X + 1. ക്ലയൻ്റ് ഒരു ACK പാക്കറ്റ് ഉപയോഗിച്ച് SYNACK-നോട് പ്രതികരിക്കുന്നു seqnum = X + 1, acknum = Y + 1. ഇതിനുശേഷം, യഥാർത്ഥ ഡാറ്റ കൈമാറ്റം ആരംഭിക്കുന്നു.

പാക്കറ്റിൻ്റെ രസീത് പിയർ അംഗീകരിക്കുന്നില്ലെങ്കിൽ, ഒരു സമയപരിധിക്ക് ശേഷം TCP അത് വീണ്ടും അയയ്ക്കുന്നു.

എന്തുകൊണ്ടാണ് SYN കുക്കികൾ എപ്പോഴും ഉപയോഗിക്കാത്തത്?

ഒന്നാമതായി, SYNACK അല്ലെങ്കിൽ ACK നഷ്‌ടപ്പെടുകയാണെങ്കിൽ, അത് വീണ്ടും അയയ്‌ക്കുന്നതിന് നിങ്ങൾ കാത്തിരിക്കേണ്ടിവരും - കണക്ഷൻ സജ്ജീകരണം മന്ദഗതിയിലാകും. രണ്ടാമതായി, SYN പാക്കേജിൽ - അതിൽ മാത്രം! - കണക്ഷൻ്റെ തുടർന്നുള്ള പ്രവർത്തനത്തെ ബാധിക്കുന്ന നിരവധി ഓപ്ഷനുകൾ കൈമാറ്റം ചെയ്യപ്പെടുന്നു. ഇൻകമിംഗ് SYN പാക്കറ്റുകൾ ഓർമ്മിക്കാതെ, സെർവർ ഈ ഓപ്ഷനുകളെ അവഗണിക്കുന്നു; ഈ സാഹചര്യത്തിൽ TCP പ്രവർത്തിക്കാൻ കഴിയും, എന്നാൽ കുറഞ്ഞത് പ്രാരംഭ ഘട്ടത്തിൽ കണക്ഷൻ്റെ ഗുണനിലവാരം കുറയും.

ഒരു പാക്കേജ് വീക്ഷണകോണിൽ, ഒരു XDP പ്രോഗ്രാം ഇനിപ്പറയുന്നവ ചെയ്യണം:

• ഒരു കുക്കി ഉപയോഗിച്ച് SYNACK ഉപയോഗിച്ച് SYN-ലേക്ക് പ്രതികരിക്കുക;
• RST ഉപയോഗിച്ച് ACK യോട് പ്രതികരിക്കുക (വിച്ഛേദിക്കുക);
• ബാക്കിയുള്ള പാക്കറ്റുകൾ ഉപേക്ഷിക്കുക.

പാക്കേജ് പാഴ്‌സിംഗ് സഹിതം അൽഗോരിതത്തിൻ്റെ സ്യൂഡോകോഡ്:

Если это не 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, എനിക്ക് ആവശ്യമായ നിർവചനങ്ങൾ കോഡിലേക്ക് പകർത്തേണ്ടി വന്നു.

കേർണലിലെ eBPF വെരിഫയർ ബാക്ക്‌ട്രാക്കിംഗ് നിരോധിക്കുന്നതിനാൽ, യഥാർത്ഥത്തിൽ, ലൂപ്പുകളും ഫംഗ്‌ഷൻ കോളുകളും, റീഡബിലിറ്റിക്കായി C-യിൽ ഹൈലൈറ്റ് ചെയ്‌തിരിക്കുന്ന എല്ലാ ഫംഗ്‌ഷനുകളും കോൾ പോയിൻ്റിൽ ഇൻലൈൻ ചെയ്തിരിക്കണം.

#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-നുള്ള മറുപടി

ഈ ഘട്ടത്തിലെ ലക്ഷ്യം ഫിക്സഡ് ഉപയോഗിച്ച് ശരിയായ സിനാക്ക് പാക്കറ്റ് സൃഷ്ടിക്കുക എന്നതാണ് 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() RFC 32 അനുസരിച്ച്, 16-ബിറ്റ് വാക്കുകളുടെ 791-ബിറ്റ് തുകയിൽ നിന്ന് ഒരു ചെക്ക്സം ഉണ്ടാക്കുന്നു.

TCP ഹാൻഡ്‌ഷേക്ക് സ്ഥിരീകരണം

ഫിൽട്ടർ ശരിയായി ഒരു കണക്ഷൻ സ്ഥാപിക്കുന്നു netcat, അവസാന ACK ഒഴിവാക്കുന്നു, അതിലേക്ക് Linux നെറ്റ്‌വർക്ക് സ്റ്റാക്കിന് SYN ലഭിക്കാത്തതിനാൽ ഒരു RST പാക്കറ്റ് ഉപയോഗിച്ച് പ്രതികരിച്ചു - അത് ഒരു 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 കുക്കി

ഒരു XDP കാഴ്ചപ്പാടിൽ, സ്ഥിരീകരണം തന്നെ നിസ്സാരമാണ്. കണക്കുകൂട്ടൽ അൽഗോരിതം പ്രാകൃതമാണ്, കൂടാതെ സങ്കീർണ്ണമായ ഒരു ആക്രമണകാരിക്ക് എളുപ്പത്തിൽ എളുപ്പത്തിൽ ആക്രമിക്കാൻ സാധ്യതയുണ്ട്. കേർണൽ Linuxഉദാഹരണത്തിന്, ക്രിപ്‌റ്റോഗ്രാഫിക് സിപ്ഹാഷ് ഉപയോഗിക്കുന്നു, എന്നാൽ 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 നിങ്ങളെ അനുവദിക്കുന്നു, കൂടാതെ, ട്രാഫിക് പ്രോസസ്സിംഗിൽ തടസ്സമില്ലാതെ അപ്ഡേറ്റ് ചെയ്യാൻ എളുപ്പമാണ്. വെരിഫയർ വ്യക്തിപരമായി വലിയ പ്രശ്‌നങ്ങൾ സൃഷ്ടിക്കുന്നില്ല, യൂസർസ്‌പേസ് കോഡിൻ്റെ ഭാഗങ്ങൾക്കായി ഞാൻ ഇത് നിരസിക്കില്ല.

രണ്ടാം ഭാഗത്ത്, വിഷയം രസകരമാണെങ്കിൽ, ഞങ്ങൾ പരിശോധിച്ച ക്ലയൻ്റുകളുടെയും ഡിസ്കണക്ഷനുകളുടെയും പട്ടിക പൂർത്തിയാക്കുകയും കൗണ്ടറുകൾ നടപ്പിലാക്കുകയും ഫിൽട്ടർ നിയന്ത്രിക്കുന്നതിന് ഒരു യൂസർസ്പേസ് യൂട്ടിലിറ്റി എഴുതുകയും ചെയ്യും.

റെഫറൻസുകൾ:

• GitHub-ലെ പൂർണ്ണ കോഡ്
• bpftrace ചീറ്റ് ഷീറ്റ്
• BPF, XDP റഫറൻസ് ഗൈഡ്
• XDP ട്യൂട്ടോറിയൽ
• PoC: റസ്റ്റിൽ നിന്ന് eBPF-ലേക്ക് കംപൈൽ ചെയ്യുന്നു

അവലംബം: www.habr.com