અમે XDP પર DDoS હુમલાઓ સામે રક્ષણ લખીએ છીએ. પરમાણુ ભાગ

eXpress ડેટા પાથ (XDP) ટેક્નોલોજી પેકેટો કર્નલ નેટવર્ક સ્ટેકમાં દાખલ થાય તે પહેલાં Linux ઇન્ટરફેસ પર ટ્રાફિકની મનસ્વી પ્રક્રિયાને મંજૂરી આપે છે. XDP ની એપ્લિકેશન - DDoS હુમલાઓ (CloudFlare), જટિલ ફિલ્ટર્સ, આંકડા સંગ્રહ (Netflix) સામે રક્ષણ. XDP પ્રોગ્રામ્સ eBPF વર્ચ્યુઅલ મશીન દ્વારા એક્ઝિક્યુટ કરવામાં આવે છે, અને તેથી ફિલ્ટરના પ્રકારને આધારે તેમના કોડ અને ઉપલબ્ધ કર્નલ ફંક્શન બંને પર નિયંત્રણો હોય છે.

લેખ XDP પરની અસંખ્ય સામગ્રીની ખામીઓને દૂર કરવાનો છે. પ્રથમ, તેઓ તૈયાર કોડ પ્રદાન કરે છે જે તરત જ XDP ની સુવિધાઓને બાયપાસ કરે છે: ચકાસણી માટે તૈયાર અથવા સમસ્યાઓ ઊભી કરવા માટે ખૂબ સરળ. જ્યારે તમે પછીથી શરૂઆતથી તમારો પોતાનો કોડ લખવાનો પ્રયાસ કરો છો, ત્યારે લાક્ષણિક ભૂલો સાથે શું કરવું તેની કોઈ સમજણ નથી. બીજું, તે VM અને હાર્ડવેર વિના XDP ને સ્થાનિક રીતે ચકાસવાની રીતોને આવરી લેતું નથી, તે હકીકત હોવા છતાં કે તેમની પોતાની મુશ્કેલીઓ છે. ટેક્સ્ટનો હેતુ નેટવર્ક્સ અને લિનક્સથી પરિચિત એવા પ્રોગ્રામરો માટે છે જેઓ 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 માં કમ્પાઇલ કરવાનું ક્લેંગ દ્વારા સમર્થિત છે અને GCC 10.1 માં વચન આપવામાં આવ્યું છે.
2. જો આ ઑબ્જેક્ટ કોડમાં કર્નલ સ્ટ્રક્ચર્સ (ઉદાહરણ તરીકે, કોષ્ટકો અને કાઉન્ટર્સ પર) કૉલ્સ છે, તો તેમના ID ને બદલે શૂન્ય છે, એટલે કે, આવા કોડને એક્ઝિક્યુટ કરી શકાતો નથી. કર્નલમાં લોડ કરતા પહેલા, આ શૂન્યને કર્નલ કૉલ્સ (કોડને લિંક કરો) દ્વારા બનાવેલ ચોક્કસ ઑબ્જેક્ટના IDs સાથે બદલવું આવશ્યક છે. તમે બાહ્ય ઉપયોગિતાઓ સાથે આ કરી શકો છો, અથવા તમે એક પ્રોગ્રામ લખી શકો છો જે ચોક્કસ ફિલ્ટરને લિંક કરશે અને લોડ કરશે.
3. કર્નલ પ્રોગ્રામ લોડ થઈ રહ્યો છે તેની ચકાસણી કરે છે. તે ચક્રની ગેરહાજરી અને પેકેજ અને સ્ટેક બાઉન્ડ્રીમાંથી બહાર ન નીકળવા માટે તપાસ કરે છે. જો ચકાસણીકર્તા સાબિત કરી શકતો નથી કે કોડ સાચો છે, તો પ્રોગ્રામ નકારવામાં આવે છે - વ્યક્તિએ તેને ખુશ કરવા સક્ષમ હોવા જોઈએ.
4. સફળ ચકાસણી પછી, કર્નલ eBPF આર્કિટેક્ચર ઑબ્જેક્ટ કોડને સિસ્ટમ આર્કિટેક્ચર મશીન કોડમાં કમ્પાઇલ કરે છે (હમણાં-સમયમાં).
5. પ્રોગ્રામ ઇન્ટરફેસ સાથે જોડાયેલ છે અને પેકેટો પર પ્રક્રિયા કરવાનું શરૂ કરે છે.

XDP કર્નલમાં ચાલતું હોવાથી, ડિબગીંગ ટ્રેસ લોગ પર આધારિત છે અને હકીકતમાં, પ્રોગ્રામ ફિલ્ટર કરે છે અથવા જનરેટ કરે છે તે પેકેટો પર. જો કે, eBPF ડાઉનલોડ કરેલ કોડને સિસ્ટમ માટે સુરક્ષિત રાખે છે, જેથી તમે તમારા સ્થાનિક Linux પર જ XDP સાથે પ્રયોગ કરી શકો.

પર્યાવરણની તૈયારી

વિધાનસભા

રણકાર eBPF આર્કિટેક્ચર માટે ઑબ્જેક્ટ કોડ સીધો જારી કરી શકતો નથી, તેથી પ્રક્રિયામાં બે પગલાં શામેલ છે:

1. સી કોડને 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

આર્ક લિનક્સ માટે મેકફાઇલ (કર્નલ 5.3.7):

CLANG ?= clang
LLC ?= llc

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

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

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

.PHONY: all clean

all: xdp_filter.o

clean:
    rm -f ./*.o

KDIR કર્નલ હેડરોનો માર્ગ સમાવે છે, ARCH - સિસ્ટમ આર્કિટેક્ચર. વિતરણો વચ્ચે પાથ અને સાધનો થોડો બદલાઈ શકે છે.

ડેબિયન 10 (કર્નલ 4.19.67) માટે તફાવતનું ઉદાહરણ

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

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

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

CFLAGS સહાયક હેડરો સાથે ડિરેક્ટરી અને કર્નલ હેડરો સાથે ઘણી ડિરેક્ટરીઓ શામેલ કરો. પ્રતીક __KERNEL__ મતલબ કે UAPI (userspace API) હેડરો કર્નલ કોડ માટે વ્યાખ્યાયિત થયેલ છે, કારણ કે ફિલ્ટર કર્નલમાં ચલાવવામાં આવે છે.

સ્ટેક સંરક્ષણ અક્ષમ કરી શકાય છે (-fno-stack-protector) કારણ કે eBPF કોડ વેરિફાયર કોઈપણ રીતે સ્ટેક બાઉન્ડ્રીની બહાર ન હોવા માટે તપાસ કરે છે. તમારે તરત જ ઑપ્ટિમાઇઝેશનને સક્ષમ કરવું જોઈએ, કારણ કે eBPF બાઇટકોડનું કદ મર્યાદિત છે.

ચાલો એક ફિલ્ટર સાથે પ્રારંભ કરીએ જે બધા પેકેટો પસાર કરે છે અને કંઈ કરતું નથી:

#include <uapi/linux/bpf.h>

#include <bpf_helpers.h>

SEC("prog")
int xdp_main(struct xdp_md* ctx) {
    return XDP_PASS;
}

char _license[] SEC("license") = "GPL";

ટીમ make એકત્રિત કરે છે xdp_filter.o. હવે તમે તેને ક્યાં ચકાસી શકો છો?

ટેસ્ટ બેન્ચ

સ્ટેન્ડમાં બે ઇન્ટરફેસ શામેલ હોવા જોઈએ: જેના પર ફિલ્ટર હશે અને જેમાંથી પેકેટો મોકલવામાં આવશે. અમારા ફિલ્ટર સાથે નિયમિત એપ્લિકેશનો કેવી રીતે કાર્ય કરે છે તે તપાસવા માટે આ તેમના પોતાના IP સાથે સંપૂર્ણ Linux ઉપકરણો હોવા જોઈએ.

વેથ (વર્ચ્યુઅલ ઈથરનેટ) જેવા ઉપકરણો આપણા માટે યોગ્ય છે: તે વર્ચ્યુઅલ નેટવર્ક ઈન્ટરફેસની જોડી છે જે એકબીજા સાથે સીધા જ "જોડાયેલ" છે. તમે તેમને આ રીતે બનાવી શકો છો (આ વિભાગમાં, બધા આદેશો ip થી કરવામાં આવે છે root):

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

તે xdp-remote и xdp-local - ઉપકરણ નામો. ચાલુ xdp-local (192.0.2.1/24) સાથે ફિલ્ટર જોડવામાં આવશે xdp-remote (192.0.2.2/24) ઇનકમિંગ ટ્રાફિક મોકલવામાં આવશે. જો કે, ત્યાં એક સમસ્યા છે: ઇન્ટરફેસો એક જ મશીન પર છે, અને Linux તેમાંથી એકને બીજા દ્વારા ટ્રાફિક મોકલશે નહીં. તમે તેને મુશ્કેલ નિયમો દ્વારા હલ કરી શકો છો iptables, પરંતુ તેઓએ પેકેજો બદલવા પડશે, જે ડિબગીંગ કરતી વખતે અસુવિધાજનક છે. નેટવર્ક નેમસ્પેસ (નેટવર્ક નેમસ્પેસ, આગળ નેટન્સ) નો ઉપયોગ કરવો વધુ સારું છે.

નેટવર્ક નેમસ્પેસમાં ઈન્ટરફેસ, રૂટીંગ કોષ્ટકો અને નેટફિલ્ટર નિયમોનો સમૂહ હોય છે જે અન્ય નેટન્સમાં સમાન ઓબ્જેક્ટથી અલગ હોય છે. દરેક પ્રક્રિયા અમુક નેમસ્પેસમાં ચાલે છે, અને માત્ર આ નેટન્સના ઑબ્જેક્ટ્સ જ તેને ઉપલબ્ધ છે. ડિફૉલ્ટ રૂપે, સિસ્ટમમાં તમામ ઑબ્જેક્ટ્સ માટે એક જ નેટવર્ક નેમસ્પેસ છે, જેથી તમે Linux પર કામ કરી શકો અને netns વિશે જાણતા નથી.

ચાલો એક નવું નેમસ્પેસ બનાવીએ 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 પર એકમાત્ર ઇન્ટરફેસ છે. આ વિપરીત રીતે પણ કામ કરે છે.

જ્યારે નેટન્સ વચ્ચે ફરે છે, ત્યારે ઈન્ટરફેસ નીચે જાય છે અને સરનામું ગુમાવે છે. netns માં ઇન્ટરફેસ સેટ કરવા માટે, તમારે ચલાવવાની જરૂર છે ip ... આ આદેશ નેમસ્પેસમાં ip netns exec:

ip netns exec xdp-test 
    ip address add 192.0.2.2/24 dev xdp-remote
ip netns exec xdp-test 
    ip link set xdp-remote up

જેમ તમે જોઈ શકો છો, આ સેટિંગથી અલગ નથી xdp-local ડિફૉલ્ટ નેમસ્પેસમાં:

    ip address add 192.0.2.1/24 dev xdp-local
    ip link set xdp-local up

જો ચલાવો tcpdump -tnevi xdp-local, તમે જોઈ શકો છો કે જે પેકેટો મોકલવામાં આવ્યા છે xdp-test, આ ઇન્ટરફેસ પર વિતરિત કરવામાં આવે છે:

ip netns exec xdp-test   ping 192.0.2.1

અંદર શેલ ચલાવવા માટે તે અનુકૂળ છે xdp-test. રિપોઝીટરીમાં એક સ્ક્રિપ્ટ છે જે સ્ટેન્ડ સાથે કામને સ્વચાલિત કરે છે, ઉદાહરણ તરીકે, તમે આદેશ સાથે સ્ટેન્ડ સેટ કરી શકો છો sudo ./stand up અને તેને દૂર કરો sudo ./stand down.

ટ્રેસીંગ

ફિલ્ટર આ રીતે ઉપકરણ સાથે જોડાયેલ છે:

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

કી -force નવા પ્રોગ્રામને લિંક કરવા માટે જરૂરી છે જો અન્ય એક પહેલાથી જ લિંક થયેલ હોય. "કોઈ સમાચાર સારા સમાચાર નથી" આ આદેશ વિશે નથી, આઉટપુટ કોઈપણ રીતે વિશાળ છે. સૂચવે છે verbose વૈકલ્પિક, પરંતુ તેની સાથે એસેમ્બલર સૂચિ સાથે કોડ વેરિફાયરના કાર્ય વિશેનો અહેવાલ દેખાય છે:

Verifier analysis:

0: (b7) r0 = 2
1: (95) exit

પ્રોગ્રામને ઇન્ટરફેસમાંથી અલગ કરો:

ip link set dev xdp-local xdp off

સ્ક્રિપ્ટમાં, આ આદેશો છે sudo ./stand attach и sudo ./stand detach.

ફિલ્ટરને બાંધીને, તમે તેની ખાતરી કરી શકો છો ping કામ કરવાનું ચાલુ રાખે છે, પરંતુ શું પ્રોગ્રામ કામ કરે છે? ચાલો લોગો ઉમેરીએ. કાર્ય bpf_trace_printk() તેના જેવું printf(), પરંતુ માત્ર પેટર્ન સિવાયની ત્રણ દલીલો અને સ્પષ્ટીકરણોની મર્યાદિત સૂચિને સમર્થન આપે છે. મેક્રો bpf_printk() કૉલને સરળ બનાવે છે.

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

આઉટપુટ કર્નલ ટ્રેસ ચેનલ પર જાય છે, જેને સક્ષમ કરવાની જરૂર છે:

echo -n 1 | sudo tee /sys/kernel/debug/tracing/options/trace_printk

સંદેશનો પ્રવાહ જુઓ:

cat /sys/kernel/debug/tracing/trace_pipe

આ બંને ટીમો કોલ કરે છે sudo ./stand log.

પિંગે હવે તેમાં આના જેવા સંદેશાઓ ઉત્પન્ન કરવા જોઈએ:

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

જો તમે વેરિફાયરના આઉટપુટને નજીકથી જોશો, તો તમે વિચિત્ર ગણતરીઓ જોઈ શકો છો:

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

હકીકત એ છે કે eBPF પ્રોગ્રામ્સ પાસે ડેટા વિભાગ નથી, તેથી ફોર્મેટ સ્ટ્રિંગને એન્કોડ કરવાનો એકમાત્ર રસ્તો VM આદેશોની તાત્કાલિક દલીલો છે:

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

આ કારણોસર, ડીબગ આઉટપુટ પરિણામી કોડને મોટા પ્રમાણમાં ફૂલે છે.

XDP પેકેટ મોકલી રહ્યું છે

ચાલો ફિલ્ટર બદલીએ: તેને બધા આવનારા પેકેટો પાછા મોકલવા દો. નેટવર્કના દૃષ્ટિકોણથી આ ખોટું છે, કારણ કે હેડરમાં સરનામાં બદલવાની જરૂર પડશે, પરંતુ હવે સિદ્ધાંતમાં કાર્ય મહત્વપૂર્ણ છે.

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

લોંચ કરો tcpdump પર xdp-remote. તેણે સરખા આઉટગોઇંગ અને ઇનકમિંગ ICMP ઇકો રિક્વેસ્ટ બતાવવી જોઈએ અને ICMP ઇકો રિપ્લાય બતાવવાનું બંધ કરવું જોઈએ. પરંતુ તે દેખાતું નથી. કામ માટે બહાર વળે છે XDP_TX માટે કાર્યક્રમમાં xdp-local જરૂરી છેઈન્ટરફેસ જોડવા માટે xdp-remote એક પ્રોગ્રામ પણ સોંપવામાં આવ્યો હતો, પછી ભલે તે ખાલી હોય, અને તેને ઉછેરવામાં આવ્યો.

મને કેવી રીતે ખબર પડી?

કર્નલમાં પેકેજનો માર્ગ શોધી રહ્યા છે પર્ફ ઇવેન્ટ મિકેનિઝમ એ જ વર્ચ્યુઅલ મશીનનો ઉપયોગ કરીને પરવાનગી આપે છે, એટલે કે, eBPF નો ઉપયોગ eBPF સાથે ડિસએસેમ્બલી માટે થાય છે.

તમારે અનિષ્ટમાંથી સારું બનાવવું જોઈએ, કારણ કે તેને બનાવવા માટે બીજું કંઈ નથી.

$ sudo perf trace --call-graph dwarf -e 'xdp:*'
   0.000 ping/123455 xdp:xdp_bulk_tx:ifindex=19 action=TX sent=0 drops=1 err=-6
                                     veth_xdp_flush_bq ([veth])
                                     veth_xdp_flush_bq ([veth])
                                     veth_poll ([veth])
                                     <...>

કોડ 6 શું છે?

$ errno 6
ENXIO 6 No such device or address

કાર્ય veth_xdp_flush_bq() થી એરર કોડ મેળવે છે veth_xdp_xmit(), જ્યાં દ્વારા શોધો ENXIO અને ટિપ્પણી શોધો.

ન્યૂનતમ ફિલ્ટર પુનઃસ્થાપિત કરો (XDP_PASS) ફાઇલમાં xdp_dummy.c, તેને મેકફાઈલમાં ઉમેરો, સાથે જોડો xdp-remote:

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

હવે tcpdump શું અપેક્ષિત છે તે દર્શાવે છે:

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

જો તેના બદલે માત્ર 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 પેકેટનું છે જે સાચવવામાં આવ્યું ન હતું? છેવટે, હુમલાખોર નકલી ACKs પણ જનરેટ કરી શકે છે. SYN કૂકીનો સાર એ એન્કોડ કરવાનો છે seqnum સરનામાં, બંદરો અને બદલાતા મીઠાના હેશ તરીકે જોડાણ પરિમાણો. જો ACK મીઠું બદલાતા પહેલા પહોંચવામાં વ્યવસ્થાપિત હોય, તો તમે ફરીથી હેશની ગણતરી કરી શકો છો અને તેની સાથે સરખામણી કરી શકો છો acknum. નકલી acknum હુમલાખોર કરી શકતો નથી, કારણ કે મીઠામાં રહસ્યનો સમાવેશ થાય છે, અને મર્યાદિત ચેનલને કારણે તેની પાસે સૉર્ટ કરવાનો સમય નથી.

SYN કૂકીઝને Linux કર્નલમાં લાંબા સમયથી લાગુ કરવામાં આવી છે અને જો SYN ખૂબ ઝડપથી અને બલ્કમાં આવે તો પણ તે આપમેળે સક્ષમ થઈ શકે છે.

TCP હેન્ડશેક પર શૈક્ષણિક કાર્યક્રમ

TCP બાઇટ્સના સ્ટ્રીમ તરીકે ડેટાનું ટ્રાન્સફર પૂરું પાડે છે, ઉદાહરણ તરીકે, HTTP વિનંતીઓ TCP પર ટ્રાન્સમિટ થાય છે. સ્ટ્રીમ ટુકડે ટુકડે પેકેટોમાં પ્રસારિત થાય છે. બધા TCP પેકેટોમાં લોજિકલ ફ્લેગ્સ અને 32-બીટ સિક્વન્સ નંબરો છે:

• ફ્લેગ્સનું સંયોજન ચોક્કસ પેકેજની ભૂમિકાને વ્યાખ્યાયિત કરે છે. SYN ફ્લેગનો અર્થ છે કે આ કનેક્શન પર મોકલનારનું પ્રથમ પેકેટ છે. ACK ફ્લેગનો અર્થ છે કે પ્રેષકને બાઈટ સુધીનો તમામ કનેક્શન ડેટા પ્રાપ્ત થયો છે. acknum. એક પેકેટમાં ઘણા ધ્વજ હોઈ શકે છે અને તેનું નામ તેમના સંયોજન પર રાખવામાં આવ્યું છે, ઉદાહરણ તરીકે, SYNACK પેકેટ.

• સિક્વન્સ નંબર (સેક્નમ) આ પેકેટમાં મોકલવામાં આવેલ પ્રથમ બાઈટ માટે ડેટા સ્ટ્રીમમાં ઓફસેટનો ઉલ્લેખ કરે છે. ઉદાહરણ તરીકે, જો ડેટાના X બાઇટ્સ સાથેના પ્રથમ પેકેટમાં આ નંબર N હતો, તો નવા ડેટા સાથેના આગામી પેકેટમાં તે N+X હશે. કનેક્શનની શરૂઆતમાં, દરેક પક્ષ આ નંબર રેન્ડમલી પસંદ કરે છે.

• સ્વીકૃતિ નંબર (એકનમ) - સેકનમ જેવો જ ઓફસેટ છે, પરંતુ તે ટ્રાન્સમિટેડ બાઈટની સંખ્યા નક્કી કરતું નથી, પરંતુ પ્રાપ્તકર્તા તરફથી પ્રથમ બાઈટની સંખ્યા, જે પ્રેષકે જોઈ ન હતી.

જોડાણની શરૂઆતમાં, પક્ષકારોએ સંમત થવું આવશ્યક છે seqnum и acknum. ક્લાયંટ તેની સાથે SYN પેકેટ મોકલે છે seqnum = X. સર્વર SYNACK પેકેટ સાથે પ્રતિસાદ આપે છે, જ્યાં તે પોતાનું લખે છે seqnum = Y અને છતી કરે છે acknum = X + 1. ક્લાયંટ SYNACK ને ACK પેકેટ સાથે જવાબ આપે છે, જ્યાં seqnum = X + 1, acknum = Y + 1. તે પછી, વાસ્તવિક ડેટા ટ્રાન્સફર શરૂ થાય છે.

જો ઇન્ટરલોક્યુટર પેકેટની રસીદ સ્વીકારતો નથી, તો TCP તેને સમયસમાપ્તિ દ્વારા ફરીથી મોકલે છે.

SYN કૂકીઝ શા માટે હંમેશા ઉપયોગમાં લેવાતી નથી?

પ્રથમ, જો SYNACK અથવા ACK ખોવાઈ જાય, તો તમારે ફરીથી મોકલવાની રાહ જોવી પડશે - કનેક્શનની સ્થાપના ધીમી પડી જાય છે. બીજું, SYN પેકેટમાં - અને ફક્ત તેમાં! - સંખ્યાબંધ વિકલ્પો પ્રસારિત થાય છે જે કનેક્શનની આગળની કામગીરીને અસર કરે છે. આવનારા SYN પેકેટોને યાદ ન રાખતા, સર્વર આમ આ વિકલ્પોને અવગણે છે, નીચેના પેકેટોમાં ક્લાયન્ટ હવે તેમને મોકલશે નહીં. TCP આ કિસ્સામાં કામ કરી શકે છે, પરંતુ ઓછામાં ઓછા પ્રારંભિક તબક્કે, કનેક્શનની ગુણવત્તામાં ઘટાડો થશે.

પેકેજોના સંદર્ભમાં, XDP પ્રોગ્રામે નીચે મુજબ કરવું જોઈએ:

• કૂકી સાથે SYNACK સાથે SYN ને પ્રતિસાદ આપો;
• ACK ને RST સાથે જવાબ આપો (કનેક્શન તોડો);
• અન્ય પેકેટો છોડો.

પેકેટ પાર્સિંગ સાથે અલ્ગોરિધમનો સ્યુડોકોડ:

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

એક (*) તમારે સિસ્ટમની સ્થિતિને મેનેજ કરવાની જરૂર હોય તે બિંદુઓ ચિહ્નિત થયેલ છે - પ્રથમ તબક્કે, તમે સીકનમ તરીકે SYN કૂકી જનરેટ કરીને TCP હેન્ડશેકનો અમલ કરીને તેમના વિના કરી શકો છો.

જગ્યા પર (**), જ્યારે અમારી પાસે ટેબલ નથી, અમે પેકેટ છોડી દઈશું.

TCP હેન્ડશેક અમલીકરણ

પેકેજ પાર્સિંગ અને કોડ વેરિફિકેશન

અમને નેટવર્ક હેડર સ્ટ્રક્ચર્સની જરૂર છે: ઇથરનેટ (uapi/linux/if_ether.h), IPv4 (uapi/linux/ip.h) અને TCP (uapi/linux/tcp.h). છેલ્લું જે હું સંબંધિત ભૂલોને કારણે કનેક્ટ કરી શક્યો નથી atomic64_t, મારે કોડમાં જરૂરી વ્યાખ્યાઓની નકલ કરવી પડી.

વાંચનક્ષમતા માટે C માં અલગ પાડવામાં આવેલ તમામ ફંક્શન્સ કૉલ સાઇટ પર ઇનલાઇન હોવા જોઈએ, કારણ કે કર્નલમાં eBPF વેરિફાયર બેક જમ્પ્સ, એટલે કે, હકીકતમાં, લૂપ્સ અને ફંક્શન કૉલ્સને પ્રતિબંધિત કરે છે.

#define INTERNAL static __attribute__((always_inline))

મેક્રો LOG() રીલીઝ બિલ્ડમાં પ્રિન્ટીંગને અક્ષમ કરે છે.

પ્રોગ્રામ એ કાર્યોની પાઇપલાઇન છે. દરેકને એક પેકેટ મળે છે જેમાં અનુરૂપ સ્તરનું હેડર પ્રકાશિત થાય છે, ઉદાહરણ તરીકે, process_ether() ભરવાની રાહ જોવી ether. ક્ષેત્ર વિશ્લેષણના પરિણામોના આધારે, કાર્ય પેકેટને ઉચ્ચ સ્તર પર સ્થાનાંતરિત કરી શકે છે. કાર્યનું પરિણામ એ XDP ક્રિયા છે. જ્યારે SYN અને ACK હેન્ડલર્સ બધા પેકેટને પસાર થવા દે છે.

struct Packet {
    struct xdp_md* ctx;

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

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

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

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

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

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

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

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

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

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

હું A અને B ચિહ્નિત ચેક પર ધ્યાન આપું છું. જો તમે A ની ટિપ્પણી કરો છો, તો પ્રોગ્રામ બિલ્ડ થશે, પરંતુ લોડ કરતી વખતે ચકાસણી ભૂલ હશે:

Verifier analysis:

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

Error fetching program/map!

કી સ્ટ્રિંગ invalid access to packet, off=13 size=1, R7(id=0,off=0,r=0): જ્યારે બફરની શરૂઆતથી તેરમો બાઈટ પેકેટની બહાર હોય ત્યારે એક્ઝેક્યુશન પાથ હોય છે. સૂચિમાંથી તે કહેવું મુશ્કેલ છે કે અમે કઈ લાઇન વિશે વાત કરી રહ્યા છીએ, પરંતુ ત્યાં એક સૂચના નંબર (12) અને ડિસએસેમ્બલર છે જે સ્રોત કોડની રેખાઓ દર્શાવે છે:

llvm-objdump -S xdp_filter.o | less

આ કિસ્સામાં, તે રેખા તરફ નિર્દેશ કરે છે

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

જે સ્પષ્ટ કરે છે કે સમસ્યા છે ether. તે હંમેશા એવું જ હશે.

SYN ને જવાબ આપો

આ તબક્કે ધ્યેય નિશ્ચિત સાથે યોગ્ય SYNACK પેકેટ બનાવવાનું છે seqnum, જે ભવિષ્યમાં SYN કૂકી દ્વારા બદલવામાં આવશે. બધા ફેરફારો માં થાય છે process_tcp_syn() અને આસપાસના.

પેકેજ તપાસી રહ્યું છે

વિચિત્ર રીતે, અહીં સૌથી નોંધપાત્ર લાઇન છે, અથવા તેના બદલે, તેના પર એક ટિપ્પણી છે:

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

કોડનું પ્રથમ સંસ્કરણ લખતી વખતે, 5.1 કર્નલનો ઉપયોગ કરવામાં આવ્યો હતો, જેની ચકાસણીકર્તા માટે વચ્ચે તફાવત હતો data_end и (const void*)ctx->data_end. લખવાના સમયે, 5.3.1 કર્નલ પાસે આ સમસ્યા નથી. કદાચ કમ્પાઈલર ક્ષેત્ર કરતા અલગ રીતે સ્થાનિક ચલને એક્સેસ કરી રહ્યો હતો. નૈતિક - મોટા માળખા પર, કોડને સરળ બનાવવાથી મદદ મળી શકે છે.

વેરિફાયરના ગૌરવ માટે લંબાઈની વધુ નિયમિત તપાસ; ઓ MAX_CSUM_BYTES નીચે.

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

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

પેકેજ સ્પ્રેડ

અમે ભરીએ છીએ seqnum и acknum, ACK સેટ કરો (SYN પહેલેથી સેટ છે):

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

TCP પોર્ટ, IP અને MAC એડ્રેસ સ્વેપ કરો. XDP પ્રોગ્રામમાંથી પ્રમાણભૂત પુસ્તકાલય ઉપલબ્ધ નથી, તેથી memcpy() — એક મેક્રો કે જે રણકાર આંતરિક છુપાવે છે.

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

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

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

ચેકસમ પુનઃ ગણતરી

IPv4 અને TCP ચેકસમને હેડરમાં બધા 16-બીટ શબ્દો ઉમેરવાની જરૂર છે, અને હેડરોનું કદ તેમાં લખાયેલું છે, એટલે કે, સંકલન સમયે અજ્ઞાત છે. આ એક સમસ્યા છે કારણ કે બાઉન્ડ્રી વેરીએબલ સુધી વેરિફાયર સામાન્ય લૂપને છોડશે નહીં. પરંતુ હેડરોનું કદ મર્યાદિત છે: દરેક 64 બાઇટ્સ સુધી. તમે નિશ્ચિત સંખ્યામાં પુનરાવર્તનો સાથે લૂપ બનાવી શકો છો, જે વહેલા સમાપ્ત થઈ શકે છે.

હું નોંધું છું કે ત્યાં છે આરએફસી 1624 જો માત્ર પેકેટોના નિશ્ચિત શબ્દો બદલવામાં આવે તો ચેકસમની આંશિક રીતે પુનઃગણતરી કેવી રીતે કરવી તે વિશે. જો કે, પદ્ધતિ સાર્વત્રિક નથી, અને અમલીકરણ જાળવવું વધુ મુશ્કેલ હશે.

ચેકસમ ગણતરી કાર્ય:

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

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

જોકે size કૉલિંગ કોડ દ્વારા તપાસવામાં આવે છે, બીજી એક્ઝિટ શરત જરૂરી છે જેથી વેરિફાયર લૂપનો અંત સાબિત કરી શકે.

32-બીટ શબ્દો માટે, એક સરળ સંસ્કરણ લાગુ કરવામાં આવ્યું છે:

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

ખરેખર ચેકસમની પુનઃગણતરી કરવી અને પેકેટ પાછું મોકલવું:

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

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

return XDP_TX;

કાર્ય carry() RFC 32 મુજબ, 16-બીટ શબ્દોના 791-બીટ રકમમાંથી ચેકસમ બનાવે છે.

TCP હેન્ડશેક ચેક

ફિલ્ટર યોગ્ય રીતે સાથે જોડાણ સ્થાપિત કરે છે netcat, અંતિમ ACK ને છોડીને, જેના માટે Linux એ RST પેકેટ સાથે પ્રતિસાદ આપ્યો, કારણ કે નેટવર્ક સ્ટેકને SYN પ્રાપ્ત થયું ન હતું - તેને SYNACK માં રૂપાંતરિત કરવામાં આવ્યું હતું અને પાછું મોકલવામાં આવ્યું હતું - અને OS ના દૃષ્ટિકોણથી, એક પેકેટ આવ્યું જે ન હતું. ખુલ્લા જોડાણોથી સંબંધિત.

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

સંપૂર્ણ એપ્લિકેશન સાથે તપાસ કરવી અને અવલોકન કરવું મહત્વપૂર્ણ છે tcpdump પર xdp-remote કારણ કે, ઉદાહરણ તરીકે, hping3 ખોટા ચેકસમનો જવાબ આપતો નથી.

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 તમને જટિલ તર્કને અમલમાં મૂકવાની મંજૂરી આપે છે, જે વધુમાં, ટ્રાફિક પ્રક્રિયામાં વિરામ વિના અપડેટ કરવાનું સરળ છે. વેરિફાયર મોટી સમસ્યાઓ ઉભી કરતું નથી, વ્યક્તિગત રીતે હું યુઝરસ્પેસ કોડના ભાગો માટે આનો ઇનકાર કરીશ નહીં.

બીજા ભાગમાં, જો વિષય રસપ્રદ છે, તો અમે ચકાસાયેલ ક્લાયન્ટ્સનું કોષ્ટક પૂર્ણ કરીશું અને જોડાણો તોડીશું, કાઉન્ટર્સ લાગુ કરીશું અને ફિલ્ટરને સંચાલિત કરવા માટે યુઝરસ્પેસ ઉપયોગિતા લખીશું.

સંદર્ભો:

• GitHub પર સંપૂર્ણ કોડ
• bpftrace ચીટ શીટ
• BPF અને XDP સંદર્ભ માર્ગદર્શિકા
• XDP ટ્યુટોરીયલ
• PoC: રસ્ટથી eBPF માં કમ્પાઇલ કરવું

સોર્સ: www.habr.com