कंपनी में, DDoS हमलों का मुकाबला करने के लिए हमारी टीम को "पैकेट ड्रॉपर" कहा जाता है। जबकि अन्य सभी टीमें हमारे नेटवर्क से गुजरने वाले ट्रैफिक के साथ शांत चीजें कर रही हैं, हमें इससे छुटकारा पाने के लिए नए तरीके खोजने में मज़ा आता है।


फोटो: ब्रायन इवांस , सीसी बाय-एसए 2.0

डीडीओएस हमलों का विरोध करने के लिए पैकेट को जल्दी से छोड़ने की क्षमता बहुत महत्वपूर्ण है।

हमारे सर्वर तक पहुंचने वाले पैकेट को कई स्तरों पर प्रदर्शित किया जा सकता है। प्रत्येक विधि के पेशेवरों और विपक्ष हैं। कटौती के तहत, हम हमारे द्वारा परीक्षण की गई हर चीज को देखते हैं।

अनुवादक का नोट: प्रस्तुत कुछ आदेशों के आउटपुट में, पठनीयता बनाए रखने के लिए अतिरिक्त स्थान हटा दिए गए थे।

परीक्षण स्थल

तरीकों की तुलना करने की सुविधा के लिए, हम आपको कुछ संख्याएं प्रदान करेंगे, हालांकि, परीक्षणों की कृत्रिमता के कारण, उन्हें बहुत शाब्दिक रूप से नहीं लेते हैं। हम अपने इंटेल 10Gb / s नेटवर्क कार्ड में से एक का उपयोग करेंगे। शेष सर्वर विशेषताएँ इतनी महत्वपूर्ण नहीं हैं, क्योंकि हम ऑपरेटिंग सिस्टम की सीमाओं पर ध्यान केंद्रित करना चाहते हैं, हार्डवेयर नहीं।

हमारे परीक्षण निम्नानुसार होंगे:

• हम बड़ी संख्या में छोटे यूडीपी पैकेटों का भार बनाते हैं, जो 14 मिलियन पैकेट प्रति सेकंड के मूल्य तक पहुंचते हैं;
• यह सभी ट्रैफ़िक चयनित सर्वर के एक प्रोसेसर कोर को निर्देशित किया जाता है;
• हम एकल प्रोसेसर कोर पर कर्नेल द्वारा संसाधित पैकेट की संख्या को मापते हैं।

अधिकतम लोड बनाने के लिए कृत्रिम ट्रैफ़िक इस तरह से उत्पन्न होता है: यादृच्छिक आईपी पते और प्रेषक पोर्ट का उपयोग किया जाता है। यह वही है जो tcpdump में दिखता है:

$ tcpdump -ni vlan100 -c 10 -t udp and dst port 1234 IP 198.18.40.55.32059 > 198.18.0.12.1234: UDP, length 16 IP 198.18.51.16.30852 > 198.18.0.12.1234: UDP, length 16 IP 198.18.35.51.61823 > 198.18.0.12.1234: UDP, length 16 IP 198.18.44.42.30344 > 198.18.0.12.1234: UDP, length 16 IP 198.18.106.227.38592 > 198.18.0.12.1234: UDP, length 16 IP 198.18.48.67.19533 > 198.18.0.12.1234: UDP, length 16 IP 198.18.49.38.40566 > 198.18.0.12.1234: UDP, length 16 IP 198.18.50.73.22989 > 198.18.0.12.1234: UDP, length 16 IP 198.18.43.204.37895 > 198.18.0.12.1234: UDP, length 16 IP 198.18.104.128.1543 > 198.18.0.12.1234: UDP, length 16 

चयनित सर्वर पर, सभी पैकेट एक आरएक्स कतार में बन जाएंगे और इसलिए, एक कोर द्वारा संसाधित किया जाएगा। हम इसे हार्डवेयर प्रवाह नियंत्रण के साथ प्राप्त करते हैं:

 ethtool -N ext0 flow-type udp4 dst-ip 198.18.0.12 dst-port 1234 action 2 

प्रदर्शन परीक्षण एक जटिल प्रक्रिया है। जब हमने परीक्षण तैयार किए, तो हमने देखा कि सक्रिय कच्चे सॉकेटों की उपस्थिति प्रदर्शन को नकारात्मक रूप से प्रभावित करती है, इसलिए परीक्षणों को चलाने से पहले, आपको यह सुनिश्चित करने की आवश्यकता है कि कोई भी tcpdump नहीं चल रहा है। खराब प्रक्रियाओं की जांच करने का एक आसान तरीका है:

 $ ss -A raw,packet_raw -l -p|cat Netid State Recv-Q Send-Q Local Address:Port p_raw UNCONN 525157 0 *:vlan100 users:(("tcpdump",pid=23683,fd=3)) 

और अंत में, हम अपने सर्वर पर इंटेल टर्बो बूस्ट को बंद कर देते हैं:

 echo 1 | sudo tee /sys/devices/system/cpu/intel_pstate/no_turbo 

इस तथ्य के बावजूद कि टर्बो बूस्ट एक महान चीज है और कम से कम 20% से थ्रूपुट बढ़ता है, यह हमारे परीक्षणों में मानक विचलन को काफी खराब करता है। टर्बो के साथ, विचलन bo 1.5% तक पहुंच जाता है, जबकि इसके बिना केवल 0.25% होता है।

चरण 1. आवेदन में पैकेट छोड़ें

आइए आवेदन से सभी पैकेजों को वितरित करने और उन्हें अनदेखा करने के विचार से शुरू करें। प्रयोग की ईमानदारी के लिए, सुनिश्चित करें कि iptables किसी भी तरह से प्रदर्शन को प्रभावित नहीं करते हैं:

 iptables -I PREROUTING -t mangle -d 198.18.0.12 -p udp --dport 1234 -j ACCEPT iptables -I PREROUTING -t raw -d 198.18.0.12 -p udp --dport 1234 -j ACCEPT iptables -I INPUT -t filter -d 198.18.0.12 -p udp --dport 1234 -j ACCEPT 

आवेदन एक सरल चक्र है जिसमें प्राप्त डेटा तुरंत खारिज कर दिया जाता है:

 s = socket.socket(AF_INET, SOCK_DGRAM) s.bind(("0.0.0.0", 1234)) while True: s.recvmmsg([...]) 

हमने पहले ही कोड तैयार कर लिया है, भागो:

 $ ./dropping-packets/recvmmsg-loop packets=171261 bytes=1940176 

यह समाधान कर्नेल को हार्डवेयर कतार से केवल 175 हजार पैकेट लेने की अनुमति देता है, जैसा कि mmwatch और हमारी mmwatch द्वारा मापा गया था:

 $ mmwatch 'ethtool -S ext0|grep rx_2' rx2_packets: 174.0k/s 

तकनीकी रूप से, प्रति सेकंड 14 मिलियन पैकेट सर्वर पर आते हैं, हालांकि, एक प्रोसेसर कोर इस तरह की मात्रा का सामना नहीं कर सकता है। mpstat इसकी पुष्टि करता है:

 $ watch 'mpstat -u -I SUM -P ALL 1 1|egrep -v Aver' 01:32:05 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle 01:32:06 PM 0 0.00 0.00 0.00 2.94 0.00 3.92 0.00 0.00 0.00 93.14 01:32:06 PM 1 2.17 0.00 27.17 0.00 0.00 0.00 0.00 0.00 0.00 70.65 01:32:06 PM 2 0.00 0.00 0.00 0.00 0.00 100.00 0.00 0.00 0.00 0.00 01:32:06 PM 3 0.95 0.00 1.90 0.95 0.00 3.81 0.00 0.00 0.00 92.38 

जैसा कि हम देख सकते हैं, एप्लिकेशन एक अड़चन नहीं है: CPU # 1 का उपयोग 27.17% + 2.17% पर किया जाता है, जबकि इंटरप्ट हैंडलिंग CPU # 2 पर 100% तक होती है।

recvmessagge(2) का उपयोग करना एक महत्वपूर्ण भूमिका निभाता है। स्पेक्टर भेद्यता का पता चलने के बाद , कर्नेल में प्रयुक्त केपीटीआई और रेटपॉलिन के कारण सिस्टम कॉल और भी अधिक महंगे हो गए

 $ tail -n +1 /sys/devices/system/cpu/vulnerabilities/* ==> /sys/devices/system/cpu/vulnerabilities/meltdown <== Mitigation: PTI ==> /sys/devices/system/cpu/vulnerabilities/spectre_v1 <== Mitigation: __user pointer sanitization ==> /sys/devices/system/cpu/vulnerabilities/spectre_v2 <== Mitigation: Full generic retpoline, IBPB, IBRS_FW 

चरण 2. हत्या करने वाला

हमने विशेष रूप से जितना संभव हो उतना कंवर्ट लोड करने के लिए अलग-अलग आईपी और प्रेषक पोर्ट के साथ ऐसा लोड किया। टेस्ट के दौरान कॉनट्रैक में प्रविष्टियों की संख्या अधिकतम संभव हो जाती है और हम इसे सत्यापित कर सकते हैं:

 $ conntrack -C 2095202 $ sysctl net.netfilter.nf_conntrack_max net.netfilter.nf_conntrack_max = 2097152 

इसके अलावा, dmesg आप कंकरर चीख भी देख सकते हैं:

 [4029612.456673] nf_conntrack: nf_conntrack: table full, dropping packet [4029612.465787] nf_conntrack: nf_conntrack: table full, dropping packet [4029617.175957] net_ratelimit: 5731 callbacks suppressed 

तो चलिए इसे बंद करते हैं:

 iptables -t raw -I PREROUTING -d 198.18.0.12 -p udp -m udp --dport 1234 -j NOTRACK 

और परीक्षण पुनः आरंभ करें:

 $ ./dropping-packets/recvmmsg-loop packets=331008 bytes=5296128 

इसने हमें 333 हजार पैकेट प्रति सेकंड के निशान तक पहुंचने की अनुमति दी। हुर्रे!
PS SO_BUSY_POLL का उपयोग करके हम प्रति सेकंड 470 हज़ार प्राप्त कर सकते हैं, हालाँकि, यह एक अलग पोस्ट के लिए एक विषय है।

चरण 3. बर्कले बैच फ़िल्टर

चलो आगे बढ़ते हैं। हमें एप्लिकेशन को पैकेज देने की आवश्यकता क्यों है? हालांकि यह एक सामान्य समाधान नहीं है, लेकिन हम setsockopt(SO_ATTACH_FILTER) कॉल करके क्लासिक बर्कले पैकेट फ़िल्टर को सॉकेट से बाँध सकते हैं और फ़िल्टर को पैकेट को कर्नेल में वापस ड्रॉप करने के लिए कॉन्फ़िगर कर सकते हैं।
कोड तैयार करें, चलाएं:

 $ ./bpf-drop packets=0 bytes=0 

एक पैकेट फिल्टर (क्लासिक और उन्नत बर्कले फिल्टर का उपयोग लगभग समान प्रदर्शन देता है), हम प्रति सेकंड लगभग 512 हजार पैकेट प्राप्त करते हैं। इसके अलावा, एक बाधा के दौरान एक पैकेट छोड़ने से प्रोसेसर को एप्लिकेशन को जगाने से मुक्त किया जाता है।

चरण 4. रूटिंग के बाद DROP को iptables

अब हम INPUT श्रृंखला में iptables में निम्नलिखित नियम जोड़कर पैकेट छोड़ सकते हैं:

 iptables -I INPUT -d 198.18.0.12 -p udp --dport 1234 -j DROP 

मुझे याद दिलाना है कि हम पहले से ही -j NOTRACK नियम के साथ -j NOTRACK गए हैं। ये दो नियम हमें प्रति सेकंड 608 हजार पैकेट देते हैं।

आइए iptables में संख्याओं को देखें:

 $ mmwatch 'iptables -L -v -n -x | head' Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 605.9k/s 26.7m/s DROP udp -- * * 0.0.0.0/0 198.18.0.12 udp dpt:1234 

ठीक है, बुरा नहीं है, लेकिन हम बेहतर कर सकते हैं।

चरण 5. PREROUTING में iptabes DROP

इस नियम का उपयोग करने से पहले पैकेट को छोड़ने के लिए एक तेज़ तकनीक है:

 iptables -I PREROUTING -t raw -d 198.18.0.12 -p udp --dport 1234 -j DROP 

यह हमें प्रति सेकंड 1.688 मिलियन पैकेट छोड़ने की अनुमति देता है।

वास्तव में, यह प्रदर्शन में थोड़ा आश्चर्यजनक छलांग है। मुझे अभी भी कारणों की समझ नहीं है, शायद हमारी रूटिंग जटिल है, या शायद सर्वर कॉन्फ़िगरेशन में सिर्फ एक बग है।

किसी भी मामले में, कच्चे iptables बहुत तेज हैं।

चरण 6. डीएटीपी को एनएफटीबल्स

Iptables की उपयोगिता अब थोड़ी पुरानी हो गई है। वह nftables द्वारा प्रतिस्थापित किया गया था। क्यों nftables शीर्ष है की इस वीडियो स्पष्टीकरण की जाँच करें। Nftables कई कारणों से iptables को ग्रे करने की तुलना में तेज़ होने का वादा करता है, जिसमें अफवाहें भी शामिल हैं कि रिटपोलिन iptables को बहुत धीमा कर देते हैं।

लेकिन हमारा लेख अभी भी iptables और nftables की तुलना करने के बारे में नहीं है, तो चलो बस सबसे तेज़ कोशिश करें जो मैं कर सकता था:

 nft add table netdev filter nft -- add chain netdev filter input { type filter hook ingress device vlan100 priority -500 \; policy accept \; } nft add rule netdev filter input ip daddr 198.18.0.0/24 udp dport 1234 counter drop nft add rule netdev filter input ip6 daddr fd00::/64 udp dport 1234 counter drop 

काउंटरों को इस तरह देखा जा सकता है:

 $ mmwatch 'nft --handle list chain netdev filter input' table netdev filter { chain input { type filter hook ingress device vlan100 priority -500; policy accept; ip daddr 198.18.0.0/24 udp dport 1234 counter packets 1.6m/s bytes 69.6m/s drop # handle 2 ip6 daddr fd00::/64 udp dport 1234 counter packets 0 bytes 0 drop # handle 3 } } 

Nftables इनपुट हुक ने लगभग 1.53 मिलियन पैकेट के मान दिखाए। यह iptables में PREROUTING चेन से थोड़ा कम है। लेकिन इसमें एक रहस्य है: सैद्धांतिक रूप से, nftables हुक PREROUTING iptables की तुलना में पहले चला जाता है और इसलिए, इसे तेजी से संसाधित किया जाना चाहिए।

हमारे परीक्षण में, nftables iptables की तुलना में थोड़ा धीमा है, लेकिन nftables वैसे भी कूलर हैं। : पी

चरण 7. टीसी DROP

कुछ अप्रत्याशित रूप से, tc (ट्रैफिक कंट्रोल) हुक iptables PREROUTING की तुलना में पहले होता है। टीसी हमें सरल मानदंडों के अनुसार पैकेटों का चयन करने की अनुमति देता है और निश्चित रूप से उन्हें छोड़ देता है। वाक्यविन्यास थोड़ा असामान्य है, इसलिए हम कॉन्फ़िगरेशन के लिए इस स्क्रिप्ट का उपयोग करने का सुझाव देते हैं। और हमें एक जटिल नियम की आवश्यकता है जो इस तरह दिखता है:

 tc qdisc add dev vlan100 ingress tc filter add dev vlan100 parent ffff: prio 4 protocol ip u32 match ip protocol 17 0xff match ip dport 1234 0xffff match ip dst 198.18.0.0/24 flowid 1:1 action drop tc filter add dev vlan100 parent ffff: protocol ipv6 u32 match ip6 dport 1234 0xffff match ip6 dst fd00::/64 flowid 1:1 action drop 

और हम इसे कार्रवाई में देख सकते हैं:

 $ mmwatch 'tc -s filter show dev vlan100 ingress' filter parent ffff: protocol ip pref 4 u32 filter parent ffff: protocol ip pref 4 u32 fh 800: ht divisor 1 filter parent ffff: protocol ip pref 4 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:1 (rule hit 1.8m/s success 1.8m/s) match 00110000/00ff0000 at 8 (success 1.8m/s ) match 000004d2/0000ffff at 20 (success 1.8m/s ) match c612000c/ffffffff at 16 (success 1.8m/s ) action order 1: gact action drop random type none pass val 0 index 1 ref 1 bind 1 installed 1.0/s sec Action statistics: Sent 79.7m/s bytes 1.8m/s pkt (dropped 1.8m/s, overlimits 0 requeues 0) 

टीसी हुक ने हमें एक कोर पर 1.8 मिलियन पैकेट प्रति सेकंड छोड़ने की अनुमति दी। यह महान है!
लेकिन हम इसे और भी तेजी से कर सकते हैं ...

चरण 8. XDP_DROP

और अंत में, हमारा सबसे मजबूत हथियार: XDP - eXpress डेटा पथ । XDP का उपयोग करते हुए, हम नेटवर्क ड्राइवर के संदर्भ में विस्तारित बर्कले पैकेट फ़िल्टर (eBPF) कोड को सीधे चला सकते हैं और सबसे महत्वपूर्ण बात, skbuff लिए मेमोरी आवंटित करने से पहले भी, जो हमें गति में वृद्धि का वादा करता है।

आमतौर पर, XDP प्रोजेक्ट में दो भाग होते हैं:

• डाउनलोड करने योग्य eBPF कोड
• बूटलोडर जो सही नेटवर्क इंटरफेस में कोड डालता है

अपने बूटलोडर को लिखना एक मुश्किल काम है, इसलिए बस नए iproute2 चिप का उपयोग करें और एक साधारण कमांड के साथ कोड लोड करें:

 ip link set dev ext0 xdp obj xdp-drop-ebpf.o 

ता डैम!

डाउनलोड करने योग्य eBPF प्रोग्राम का सोर्स कोड यहां उपलब्ध है । कार्यक्रम यूपीडी प्रोटोकॉल, प्रेषक सबनेट, और गंतव्य पोर्ट के रूप में आईपी पैकेट की ऐसी विशेषताओं को देखता है:

 if (h_proto == htons(ETH_P_IP)) { if (iph->protocol == IPPROTO_UDP && (htonl(iph->daddr) & 0xFFFFFF00) == 0xC6120000 // 198.18.0.0/24 && udph->dest == htons(1234)) { return XDP_DROP; } } 

XDP प्रोग्राम को आधुनिक क्लैंग का उपयोग करके बनाया जाना चाहिए, जो BPF बायटेकोड उत्पन्न कर सकता है। उसके बाद, हम BFP प्रोग्राम की कार्यक्षमता को डाउनलोड और परीक्षण कर सकते हैं:

 $ ip link show dev ext0 4: ext0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 xdp qdisc fq state UP mode DEFAULT group default qlen 1000 link/ether 24:8a:07:8a:59:8e brd ff:ff:ff:ff:ff:ff prog/xdp id 5 tag aedc195cc0471f51 jited 

और फिर ethtool में आंकड़े देखें:

 $ mmwatch 'ethtool -S ext0|egrep "rx"|egrep -v ": 0"|egrep -v "cache|csum"' rx_out_of_buffer: 4.4m/s rx_xdp_drop: 10.1m/s rx2_xdp_drop: 10.1m/s 

यू हू! XDP के साथ, हम प्रति सेकंड 10 मिलियन पैकेट तक छोड़ सकते हैं!


फोटो: एंड्रयू फिलर , सीसी बाय-एसए 2.0

निष्कर्ष

हमने IPv4 और IPv6 के प्रयोग को दोहराया और इस आरेख को तैयार किया:


सामान्य तौर पर, यह तर्क दिया जा सकता है कि आईपीवी 6 के लिए हमारा सेटअप थोड़ा धीमा है। लेकिन चूंकि आईपीवी 6 पैकेट कुछ बड़े हैं, इसलिए गति में अंतर अपेक्षित है।

लिनक्स के पास पैकेज को फ़िल्टर करने के कई तरीके हैं, प्रत्येक की अपनी गति और जटिलता है।

DDoS से सुरक्षा के लिए, आवेदन को पैकेट देना और उन्हें वहां संसाधित करना काफी उचित है। एक अच्छी तरह से तैयार किया गया आवेदन अच्छे परिणाम दिखा सकता है।

DDoS हमलों के लिए यादृच्छिक या स्पूफ किए गए आईपी के साथ गति में एक छोटी वृद्धि प्राप्त करने के लिए कंवर्ट को अक्षम करना उपयोगी हो सकता है, लेकिन सावधान रहें: ऐसे हमले होते हैं जिनके खिलाफ कॉनट्रैक बहुत उपयोगी है।

अन्य मामलों में, DDoS हमले को कम करने के तरीकों में से एक के रूप में लिनक्स फ़ायरवॉल को जोड़ना समझ में आता है। कुछ मामलों में, "-t रॉ PREROUTING" तालिका का उपयोग करना बेहतर है, क्योंकि यह फ़िल्टर तालिका की तुलना में बहुत तेज़ है।

सबसे उन्नत मामलों के लिए, हम हमेशा XDP का उपयोग करते हैं। और हां, यह बहुत शक्तिशाली चीज है। यहाँ ऊपर दिया गया एक ग्राफ है, केवल XDP के साथ:


यदि आप प्रयोग दोहराना चाहते हैं, तो यहां README है, जिसमें हमने सब कुछ प्रलेखित किया है ।

हम CloudFlare का उपयोग करते हैं ... इन तकनीकों के लगभग सभी। उपयोगकर्ता स्थान में कुछ ट्रिक्स हमारे अनुप्रयोगों में एकीकृत हैं। हमारे गेटबोट में iptables तकनीक पाई जाती है । अंत में, हम अपने स्वयं के कोर समाधान को XDP के साथ बदलते हैं।

उनकी मदद के लिए जेसपर डेंगार्ड ब्रूअर को बहुत धन्यवाद।