אנו כותבים הגנה מפני התקפות DDoS על XDP. חלק גרעיני

טכנולוגיית eXpress Data Path (XDP) מאפשרת עיבוד שרירותי של תעבורה בממשקי לינוקס לפני שהמנות נכנסות למחסנית רשת הקרנל. יישום XDP - הגנה מפני התקפות DDoS (CloudFlare), מסננים מורכבים, איסוף סטטיסטיקות (Netflix). תוכניות XDP מבוצעות על ידי המכונה הווירטואלית eBPF, ולכן יש הגבלות הן על הקוד והן על פונקציות הליבה הזמינות, בהתאם לסוג המסנן.

המאמר נועד לפצות על החסרונות של חומרים רבים ב-XDP. ראשית, הם מספקים קוד מוכן שעוקף מיד את התכונות של XDP: מוכן לאימות או פשוט מכדי לגרום לבעיות. כאשר אתה מנסה לכתוב קוד משלך מאפס מאוחר יותר, אין הבנה מה לעשות עם שגיאות טיפוסיות. שנית, זה לא מכסה דרכים לבדיקה מקומית של XDP ללא VM וחומרה, למרות העובדה שיש להם את המלכודות שלהם. הטקסט מיועד למתכנתים המכירים רשתות ולינוקס המתעניינים ב-XDP וב-eBPF.

בחלק זה נבין בפירוט כיצד מורכב מסנן XDP וכיצד לבדוק אותו, לאחר מכן נכתוב גרסה פשוטה של ​​מנגנון העוגיות SYN הידוע ברמת עיבוד המנות. עד שניצור "רשימה לבנה"
לקוחות מאומתים, שמור מונים ונהל את המסנן - מספיק יומנים.

נכתוב ב-C - זה לא אופנתי, אלא פרקטי. כל הקוד זמין ב-GitHub בקישור בסוף ומחולק ל-commits לפי השלבים המתוארים במאמר.

כתב ויתור. במהלך המאמר יפותח מיני פתרון להרחקת התקפות DDoS, כי זו משימה ריאלית עבור XDP והאזור שלי. עם זאת, המטרה העיקרית היא להבין את הטכנולוגיה, זה לא מדריך ליצירת הגנה מוכנה. קוד ההדרכה אינו מותאם ומשמיט כמה ניואנסים.

סקירה קצרה של XDP

אציין רק את נקודות המפתח כדי לא לשכפל את התיעוד והמאמרים הקיימים.

אז, קוד הסינון נטען לתוך הקרנל. המסנן מועבר מנות נכנסות. כתוצאה מכך, על המסנן לקבל החלטה: להעביר את החבילה לקרנל (XDP_PASS), זרוק חבילה (XDP_DROP) או שלח אותו בחזרה (XDP_TX). המסנן יכול לשנות את החבילה, זה נכון במיוחד עבור XDP_TX. אתה יכול גם לקרוס את התוכנית (XDP_ABORTED) ושחרר את החבילה, אבל זה דומה assert(0) - עבור איתור באגים.

המכונה הווירטואלית eBPF (Extended Berkley Packet Filter) נעשית פשוטה בכוונה כך שהקרנל יוכל לבדוק שהקוד אינו עובר לולאה ואינו פוגע בזיכרון של אנשים אחרים. הגבלות ובדיקות מצטברות:

• לולאות (קפיצות אחורה) אסורות.
• יש מחסנית לנתונים, אבל אין פונקציות (כל פונקציות C חייבות להיות מוטבעות).
• גישה לזיכרון מחוץ למאגר המחסנית ומאגר החבילות אסורה.
• גודל הקוד מוגבל, אבל בפועל זה לא מאוד משמעותי.
• רק פונקציות ליבה מיוחדות (עוזרים eBPF) מותרות.

פיתוח והתקנה של מסנן נראה כך:

1. קוד מקור (למשל. kernel.c) מהדר לאובייקט (kernel.o) עבור ארכיטקטורת המחשב הווירטואלי eBPF. החל מאוקטובר 2019, קומפילציה ל-eBPF נתמכת על ידי Clang ומובטחת ב-GCC 10.1.
2. אם בקוד האובייקט הזה יש קריאות למבני ליבה (לדוגמה, לטבלאות ולמונים), במקום המזהים שלהם יש אפסים, כלומר, לא ניתן להפעיל קוד כזה. לפני הטעינה לתוך הליבה, יש להחליף את האפסים הללו במזהים של אובייקטים ספציפיים שנוצרו באמצעות קריאות ליבה (קשר את הקוד). אתה יכול לעשות זאת עם כלי עזר חיצוניים, או שאתה יכול לכתוב תוכנית שתקשר ותטען מסנן ספציפי.
3. הקרנל מאמת את התוכנית הנטענת. הוא בודק את היעדר מחזורים ואי יציאה של גבולות החבילה והערימה. אם המאמת לא יכול להוכיח שהקוד תקין, התוכנית נדחית - צריך להיות מסוגל לרצות אותו.
4. לאחר אימות מוצלח, הליבה מרכיבה את קוד האובייקט של ארכיטקטורת eBPF לקוד מכונה של ארכיטקטורת המערכת (בדיוק בזמן).
5. התוכנית מחוברת לממשק ומתחילה לעבד מנות.

מכיוון ש-XDP פועל בקרנל, איתור באגים מבוסס על יומני מעקב ולמעשה, על מנות שהתוכנית מסננת או מייצרת. עם זאת, eBPF שומר על הקוד שהורדת בטוח עבור המערכת, כך שתוכל להתנסות עם XDP ישירות בלינוקס המקומי שלך.

הכנת הסביבה

העצרת

Clang לא יכול להנפיק ישירות קוד אובייקט עבור ארכיטקטורת eBPF, ולכן התהליך מורכב משני שלבים:

1. הידור קוד C לקוד בייט LLVM (clang -emit-llvm).
2. המרת bytecode לקוד אובייקט 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 bytecode מוגבל.

נתחיל עם מסנן שמעביר את כל החבילות ולא עושה כלום:

#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 משלהם כדי לבדוק איך יישומים רגילים עובדים עם המסנן שלנו.

מכשירים כמו 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) תישלח תנועה נכנסת. עם זאת, יש בעיה: הממשקים נמצאים על אותו מכונה, ולינוקס לא ישלח תעבורה לאחד מהם דרך השני. אתה יכול לפתור את זה עם כללים מסובכים iptables, אבל הם יצטרכו לשנות חבילות, וזה לא נוח בעת ניפוי באגים. עדיף להשתמש במרחבי שמות ברשת (מרחבי שמות ברשת, רשתות נוספות).

מרחב השמות של הרשת מכיל קבוצה של ממשקים, טבלאות ניתוב וכללי NetFilter המבודדים מאובייקטים דומים ברשתות אחרות. כל תהליך פועל במרחב שמות כלשהו, ​​ורק האובייקטים של ה-netns הזה זמינים לו. כברירת מחדל, למערכת יש מרחב שמות רשת אחד לכל האובייקטים, כך שתוכל לעבוד על לינוקס ולא לדעת על netns.

בואו ניצור מרחב שמות חדש 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, אתה צריך להפעיל 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 Echo Request יוצאות ונכנסות זהות ולהפסיק להציג ICMP Echo Reply. אבל זה לא מופיע. מסתבר שעובד XDP_TX בתוכנית עבור xdp-local חייבלהתאמה של ממשק xdp-remote הוקצתה גם תוכנית, גם אם הייתה ריקה, והיא הועלתה.

איך ידעתי?

מעקב אחר הנתיב של חבילה בקרנל מנגנון perf events מאפשר, אגב, שימוש באותה מכונה וירטואלית, כלומר, 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 cookie ב-XDP.

עד כה, מבול ה-SYN נותר התקפת DDoS פופולרית, שמהותה היא כדלקמן. כאשר נוצר חיבור (לחיצת יד TCP), השרת מקבל SYN, מקצה משאבים לחיבור עתידי, מגיב עם חבילת SYNACK ומחכה ל-ACK. התוקף פשוט שולח מנות SYN מכתובות מזויפות בכמות של אלפים בשנייה מכל מארח ברשת בוטנט רב-אלפים. השרת נאלץ להקצות משאבים מיד עם הגעת החבילה, אך משחרר אותה לאחר זמן קצוב ארוך, כתוצאה מכך, הזיכרון או המגבלות מוצו, חיבורים חדשים אינם מתקבלים, השירות אינו זמין.

אם אתה לא מקצה משאבים על חבילת SYN, אלא רק מגיב עם חבילת SYNACK, אז איך השרת יכול להבין שחבילת ACK שהגיעה מאוחר יותר שייכת לחבילת SYN שלא נשמרה? אחרי הכל, תוקף יכול גם ליצור ACKs מזויפים. המהות של עוגיית SYN היא להצפין פנימה seqnum פרמטרי חיבור כ-hash של כתובות, יציאות ומלח משתנה. אם ה-ACK הצליח להגיע לפני החלפת המלח, אתה יכול לחשב שוב את ה-hash ולהשוות עם acknum. מְזוּיָף acknum התוקף לא יכול, מכיוון שהמלח כולל את הסוד, ולא יהיה לו זמן למיין אותו בגלל הערוץ המוגבל.

קובצי SYN מיושמים בליבת לינוקס במשך זמן רב וניתן אפילו להפעיל אותם באופן אוטומטי אם 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 עם קובץ Cookie;
• לענות ACK עם RST (לשבור את החיבור);
• זרוק מנות אחרות.

פסאודוקוד של האלגוריתם יחד עם ניתוח מנות:

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

אחד (*) הנקודות בהן אתה צריך לנהל את מצב המערכת מסומנות - בשלב הראשון, אתה יכול להסתדר בלעדיהם פשוט על ידי יישום לחיצת יד של TCP עם יצירת קובץ Cookie של SYN כקובץ המשך.

במקום (**), בעוד שאין לנו שולחן, נדלג על החבילה.

יישום לחיצת יד של TCP

ניתוח חבילה ואימות קוד

אנחנו צריכים מבני כותרות רשת: Ethernet (uapi/linux/if_ether.h), IPv4 (uapi/linux/ip.h) ו-TCP (uapi/linux/tcp.h). האחרון לא יכולתי להתחבר עקב שגיאות הקשורות אליו atomic64_t, הייתי צריך להעתיק את ההגדרות הדרושות לקוד.

כל הפונקציות הנבדלות ב-C לקריאות חייבות להיות מוטבעות באתר השיחה, שכן ה-eBPF Verifier בקרנל אוסר על קפיצות אחורה, כלומר למעשה, לולאות וקריאות פונקציות.

#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 לא הייתה בעיה זו. אולי המהדר ניגש למשתנה מקומי בצורה שונה משדה. מוסרי - על קינון גדול, פישוט הקוד יכול לעזור.

בדיקות שגרתיות נוספות של אורכים לתפארת המאמת; O 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 intrinsik.

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 הסופי, אליו הגיבה לינוקס בחבילת RST, מאחר שמחסנית הרשת לא קיבלה SYN - היא הומרה ל-SYNACK ונשלחה חזרה - ומנקודת מבט של מערכת ההפעלה, הגיעה חבילה שלא הייתה קשור לחיבורים פתוחים.

$ 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, הצ'ק עצמו הוא טריוויאלי. אלגוריתם החישוב הוא פרימיטיבי וכנראה פגיע לתוקף מתוחכם. ליבת לינוקס, למשל, משתמשת ב- SipHash ההצפנה, אבל היישום שלה עבור XDP הוא בבירור מעבר לתחום של מאמר זה.

הופיע עבור מטלות חדשות הקשורות לאינטראקציה חיצונית:

• תוכנית 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

כל עוד אין רשימה של כתובות 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 Cheat Sheet
• מדריך BPF ו-XDP
• מדריך XDP
• PoC: קומפילציה ל-eBPF מ-Rust

מקור: www.habr.com