मशीन पर हमले: हम क्या करते हैं और आप क्या कर सकते हैं

“अटैक” शब्द दो बिल्कुल अलग स्थितियों में एक जैसा सुनाई देता है: जब आपका चैनल बेकार ट्रैफ़िक से भर जाए और जब प्रति सेकंड कुछ सौ रिक्वेस्ट आपकी एप्लिकेशन को गिरा दें। इन दोनों को अलग-अलग तरीके से संभाला जाता है, और सबसे पहले यह पता लगाना ज़रूरी है कि आप किस स्थिति का सामना कर रहे हैं।

दोनों में फ़र्क़ पहचानना

पिछले 24 घंटों के लिए /hosting/vds/m/<id> पर “Overview” में प्रोसेसर, मेमोरी और ट्रैफ़िक ग्राफ़ देखें। अगर ट्रैफ़िक सामान्य है पर प्रोसेसर सीमा तक जकड़ा हुआ है, तो यह एप्लिकेशन लोड है, और इसे आपको अपनी तरफ़ से संभालना होगा।

आप क्या कर सकते हैं

nginx में रिक्वेस्ट की दर सीमित करना:

limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=conn:10m;

server {
    limit_req zone=perip burst=20 nodelay;
    limit_conn conn 20;
    client_body_timeout 10s;
    client_header_timeout 10s;
}

फ़ायरवॉल में कनेक्शन सीमित करना:

ufw limit 22/tcp

ज़्यादा लचीले नियम nftables लेख में हैं: वहाँ आप नए कनेक्शन की दर भी सीमित कर सकते हैं और ब्लॉक किए गए पतों की सूची समय-सीमा के साथ रख सकते हैं।

लॉग में स्रोत खोजें:

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
ss -tn state established | awk '{print $4}' | cut -d: -f1 | sort | uniq -c | sort -rn | head

किसी पते या नेटवर्क को एक बार ब्लॉक करना:

ufw deny from 203.0.113.0/24

fail2ban लॉग के आधार पर ब्लॉकिंग को अपने आप कर सकता है।

हम क्या करते हैं

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

नोड-लेवल सुरक्षा जो नहीं करती: वह आपकी एप्लिकेशन के लॉजिक का विश्लेषण नहीं करती। बाहर से सामान्य दिखने वाली रिक्वेस्ट आपकी मशीन तक पहुँच जाती हैं, और उनसे सिर्फ़ आपका अपना कॉन्फ़िगरेशन ही बचाता है।

अगर आपकी मशीन ख़ुद अटैक का स्रोत बन जाए — जैसे कि उसे हैक कर लिया गया हो और वह किसी और के स्पैम अभियान में हिस्सा ले रही हो — तो स्वीकार्य उपयोग नीति के तहत पहुँच सीमित कर दी जाएगी। अपनी मशीन को समझौते के संकेतों के आधार पर जाँचें।

कैशिंग और स्टैटिक फ़ाइलें

रिक्वेस्ट की बाढ़ के ख़िलाफ़ सबसे असरदार तरीका है एक ही चीज़ को दो बार न गिनना:

location /static/ {
    expires 30d;
    add_header Cache-Control "public";
}

भारी पेजों को एप्लिकेशन की तरफ़ कैश करें। कैश से दी गई रिक्वेस्ट सैकड़ों गुना कम महँगी पड़ती है।

आम गलतियाँ

• burst के बिना limit_req सेट करना — सामान्य यूज़र, जिनका पेज दो दर्जन फ़ाइलें खींचता है, कट जाते हैं।
• डिस्ट्रीब्यूटेड अटैक के दौरान एक-एक करके हाथ से पते ब्लॉक करना: वे हज़ारों में होते हैं, और आप सबको संभाल नहीं पाएँगे।
• ICMP को पूरी तरह ब्लॉक करना — इससे पैकेट साइज़ की बातचीत टूट जाती है, देखें MTU।
• अपनी ही बग को अटैक समझ लेना: कोड में लूप, कोई सर्च बॉट किसी ऐसी डायरेक्टरी को क्रॉल कर रहा हो जिसे आप बाहर करना भूल गए, क्लाइंट के बेसिर-पैर के बार-बार रिट्राई।

अपनी सीमाएँ पहले से, शांत मशीन पर सेट करें। रिक्वेस्ट की बाढ़ के दौरान आप rate और burst के मान ठीक नहीं कर पाएँगे: आप अंधेरे में और टुकड़ों-टुकड़ों में कॉन्फ़िग एडिट करते रह जाएँगे।