Bloklashning o’zi nega yukka aylanadi

Ilova qatlamida bloklangan so’rov quyidagi yo’lni bosib o’tadi: TCP ulanish qabul qilinadi, TLS qo’l berishuvi bajariladi, HTTP sarlavhalari o’qiladi, qoida ishlaydi va 403 javobi yoziladi.

Ya’ni siz «bloklandi» deb ko’rgan har bir so’rov uchun server ulanish, shifrlash va javob resursini sarfladi. Bitta so’rov uchun bu arzimas narsa. Sekundiga yuz mingta so’rov uchun esa aynan shu yiqilish sababi bo’ladi.

Eng qimmat qismi — TLS. RSA-2048 kalitli qo’l berishuvda serverning imzo amali mijoznikidan bir necha barobar qimmat: bu asimmetriya ataylab emas, protokolning tabiati. ECDSA P-256 ancha arzon, lekin baribir oddiy paket qabul qilishdan bir necha tartib qimmatroq.

Hujumchi buni biladi. Shuning uchun eng samarali L7 hujumlarining bir qismi umuman so’rov yubormaydi: ulanish ochiladi, TLS boshlanadi va shu yerda to’xtaydi. Sizning tomondan bu «bloklangan so’rov» ham emas — u statistikaga tushmaydi, lekin xotira va fayl deskriptorini egallaydi.

Hujum paytida panelda «bloklangan so’rovlar: 2,4 mln» degan raqamni ko’rasiz va himoya ishlayotgandek tuyuladi. Sayt esa ochilmaydi.

Sabab oddiy: bloklash statistikasi hisoblanyapti, chunki har bir bloklash haqiqiy ish bajarilganini anglatadi. Raqam qancha katta bo’lsa, server shuncha ko’p ishlagan. Grafikning o’sishi himoyaning emas, sarfning o’sishi.

To’g’ri panel bitta grafikda ikkita chiziqni ko’rsatadi: bloklangan so’rovlar va o’sha paytdagi protsessor yuki. Uchinchi chiziq ham foydali — ochiq ulanishlar soni, chunki ko’p holatda birinchi tugaydigan resurs protsessor emas, o’sha.

Buni o’lchash uchun ekzotik vosita kerak emas. `ss -s` ochiq soketlarni bir qatorda ko’rsatadi, `netstat -s` esa qayta yuborishlar va tashlangan paketlar hisobini beradi. Agar hujum paytida `TCPBacklogDrop` yoki `ListenOverflows` o’sib borsa, siz allaqachon navbat chegarasidasiz va bloklash qoidasi bunga hech qanday ta’sir qilmaydi.

Manba aniqlangandan keyin qaror yuqoriga ko’tarilmasligi kerak. Paket tarmoq stekining eng quyi bosqichida tashlanadi — ilova qatlamiga umuman yetib bormaydi, TLS ochilmaydi, hech qanday javob yozilmaydi.

Amalda bu bir necha darajada bo’ladi. Eng pastda — tarmoq kartasining o’zi yoki XDP: paket drayver darajasida, soket ham, `sk_buff` ham yaratilmasdan tashlanadi. Undan yuqorida — nftables yoki iptables, ya’ni `conntrack` va marshrutlashdan keyin. Eng yuqorida — ilova ichidagi qoida.

Farq nazariy emas. Har bosqich paket uchun qo’shimcha struktura ajratishni, qulflarni va kontekst almashinuvini talab qiladi; XDP’da tashlangan paket uchun bularning hech biri bajarilmaydi. Amalda bu bir xil temirda tartib darajasida ko’proq paketni hazm qilish demakdir.

Ikkinchi foyda ko’rinmaydi, lekin muhimroq: tashlangan paket ulanish jadvalida joy egallamaydi. `nf_conntrack` jadvali to’lganda yangi ulanishlar rad etila boshlaydi va bu butun serverga tegishli bo’ladi — hujum qilinayotgan saytga ham, qo’shni saytga ham. Yiqilish ko’pincha aynan shu yerdan boshlanadi.

Kernel paketni ko’radi, sessiyani emas. U «bu foydalanuvchi savatga o’n sakkiz marta bir xil mahsulot qo’shdi» degan xulosaga kela olmaydi — bu xulosa uchun kontekst kerak, kontekst esa yuqorida yashaydi.

XDP dasturi umuman cheklangan muhitda ishlaydi: eBPF tekshiruvchisi tsikllarni, dinamik xotirani va uzoq ijroni ruxsat bermaydi. Bu kamchilik emas, shart — aynan shu cheklovlar tufayli u paket tezligida ishlay oladi.

Shuning uchun to’g’ri arxitektura ikki qatlamli bo’ladi. Qaror yuqorida, xatti-harakat kontekstida qabul qilinadi; ijro esa pastda, arzon joyda bajariladi. Aniqlash aqlli, to’sish esa qo’pol va tez bo’lishi kerak.

Ikkisini bog’laydigan narsa — ro’yxat. Yuqoridagi mantiq manbani aniqlaydi va uni muddat bilan quyi qatlamga uzatadi; texnik jihatdan bu odatda eBPF map yoki `ipset` bo’ladi, chunki ularga yozish qoidalar to’plamini qayta yuklashni talab qilmaydi. Muddat majburiy — abadiy blok ro’yxati bir yildan keyin haqiqiy foydalanuvchilarni ham o’z ichiga oladi.

Bloklangan manba muddati ikki xil xatoni belgilaydi. Muddat juda qisqa bo’lsa, hujumchi qayta-qayta qaytadi va aniqlash mantig’i doim ishlab turadi. Juda uzun bo’lsa, mobil operatorning NAT manzili ortidagi mingta foydalanuvchi soatlab ichkariga kira olmaydi.

Amaliy yechim — o’sib boruvchi muddat: birinchi marta qisqa, takrorlanganda uzunroq. Shunda tasodifiy tushib qolgan foydalanuvchi tez chiqadi, qaytib keladigan manba esa asta-sekin uzoqroqqa uzoqlashadi.

IPv6 da qoida boshqacha. Bitta xostga odatda /64 ajratiladi, ya’ni bitta manzilni bloklash hech narsa bermaydi — hujumchi qo’shnisiga o’tadi. Shuning uchun IPv6 da blok /64 bo’yicha, ba’zan esa /48 bo’yicha qo’llanadi, va bu qaror alohida yozilishi kerak.

Va har bir qora ro’yxat yozuvi sababini saqlashi kerak: qaysi qoida, qaysi vaqtda, qaysi belgiga ko’ra. Sababsiz ro’yxat bir oydan keyin hech kim tegishga jur’at etmaydigan qora quti bo’lib qoladi — «bu IP nega bu yerda?» degan savolga javob yo’q, va uni o’chirish qo’rqinchli.

Hajmli hujum kanalni to’ldiradi va u tarmoq operatori darajasida so’riladi. Bu yerda gap protsessorda emas, tarmoq kengligida — shuning uchun bunday hujumni server yonida to’xtatib bo’lmaydi: kanal allaqachon to’lgan, sizning qoidangiz esa kanalning narigi uchida.

Klassik misollar — DNS yoki NTP amplifikatsiyasi va TCP SYN toshqini. Ular uchun javob ham boshqacha: upstream’da tozalash markazi, BGP orqali trafikni burish, yoki `SYN cookies` (Linux’da `net.ipv4.tcp_syncookies`), bu esa navbat to’lganda holat saqlamasdan javob berish imkonini beradi.

Ilova qatlamidagi hujum esa boshqacha ko’rinadi: trafik hajmi kichik, so’rovlar to’g’ri, TLS haqiqiy, User-Agent ishonarli. Lekin ularning har biri qimmat sahifani so’raydi — qidiruv, hisobot, filtrli katalog. Bu yerda kanal emas, ma’lumotlar bazasi yiqiladi, va tarmoq grafigi mutlaqo tinch ko’rinadi.

Ikkalasi uchun bitta chora yo’q. «Bizda DDoS himoyasi bor» degan gap qaysi biri haqida ekanini aytmaguncha ma’nosiz — va ko’p taklifda faqat birinchisi nazarda tutiladi.

Har bir shubhali so’rovni bloklash shart emas. Ba’zan uni sekinlashtirish yoki hisob-kitob talab qiladigan tekshiruv qo’yish arzonroq bo’ladi: haqiqiy brauzer buni sezmaydi, minglab so’rov yuboradigan skript esa tezligini yo’qotadi.

Bu, ayniqsa, aniq bo’lmagan holatlarda foydali. Bloklash xato bo’lsa, foydalanuvchi butunlay yo’qoladi; sekinlashtirish xato bo’lsa, u atigi bir necha yuz millisekund kutadi. Xatoning narxi tushadi, ya’ni chegarani qattiqroq qo’yish mumkin bo’ladi.

HTTP darajasida bu 429 va `Retry-After` sarlavhasi orqali qilinadi — bu standart mexanizm, va yaxshi yozilgan mijozlar unga bo’ysunadi. Yomon yozilganlari esa bo’ysunmaydi, va aynan shu farq foydali signalga aylanadi: `Retry-After` ni e’tiborsiz qoldiradigan mijoz brauzer emas.

Muhim shart — sekinlashtirish ham arzon joyda bajarilishi kerak. Ulanishni ochiq ushlab, javobni kechiktirish sizning fayl deskriptorlaringizni band qiladi. Kutish holatsiz bo’lishi kerak: javobni darhol berib, keyingi so’rovni rad etish — ochiq ulanishni ushlab turishdan arzonroq.

Sotuvchidan bitta narsani so’rang: bloklangan manba uchun server protsessori o’zgaradimi? Agar «bloklangan so’rovlar soni» o’sganda protsessor ham o’ssa — bloklash ilova qatlamida bajarilyapti.

Ikkinchi savol: bloklangan manzildan kelgan so’rov uchun TLS qo’l berishuvi bajariladimi? Buni tekshirish oson — `openssl s_client -connect host:443` ni bloklangan manzildan ishga tushiring. Agar sertifikat qaytsa, siz eng qimmat qismini baribir to’lab turibsiz, bloklash esa faqat javob matnini o’zgartiryapti.

Uchinchi savol muddat haqida: qora ro’yxat yozuvi qancha yashaydi va uni nima uzaytiradi? Javob bo’lmasa, demak ro’yxat qo’lda tozalanadi — ya’ni tozalanmaydi.

To’rtinchisi eng ko’p narsani ochadi: yuk testini o’tkazganda tashlangan paketlar qayerda hisoblanadi? Agar sotuvchi bu raqamni umuman ko’rsata olmasa, demak tashlash ilova qatlamidan pastda umuman bajarilmayapti.