Deyarli 9 yil oldin Cloudflare kichik kompaniya edi va men u uchun ishlamadim, men shunchaki mijoz edim. Cloudflare-ni ishga tushirgandan bir oy o'tgach, men veb-saytim haqida xabar oldim DNS ishlamayapti. Cloudflare o'zgarishlar kiritdi , va buzilgan DNS bor edi.
Men darhol Metyu Prinsga “Mening DNSim qayerda?” sarlavhasi bilan yozdim va u texnik tafsilotlarga to'la uzoq javob yubordi (), men javob berdim:
Muallif: Jon Graham-Cumming
Sana: 7 yil 2010 oktyabr, 9:14
Mavzu: Re: Mening DNSim qayerda?
Kimga: Metyu PrinsAjoyib hisobot, rahmat. Muammolar bo'lsa, albatta qo'ng'iroq qilaman. Ehtimol, barcha texnik ma'lumotlarni to'plaganingizdan so'ng, bu haqda post yozishga arziydi. O'ylaymanki, odamlar ochiq va halol hikoyadan zavqlanishadi. Ayniqsa, ishga tushirilgandan beri trafik qanday oshganini ko'rsatish uchun unga grafiklar biriktirsangiz.
Mening saytimda yaxshi monitoring bor va har bir muvaffaqiyatsizlik haqida SMS olaman. Monitoring shuni ko'rsatadiki, nosozlik 13:03:07 dan 14:04:12 gacha sodir bo'lgan. Sinovlar har besh daqiqada amalga oshiriladi.
Ishonchim komilki, siz buni tushunasiz. Evropada o'z odamingizga kerak emasligiga ishonchingiz komilmi? 🙂
Va u javob berdi:
Muallif: Metyu Prins
Sana: 7 yil 2010 oktyabr, 9:57
Mavzu: Re: Mening DNSim qayerda?
Kimga: Jon Graham-CummingRahmat. Biz yozganlarning barchasiga javob berdik. Men hozir ofisga ketyapman va biz blogga biror narsa yozamiz yoki e'lonlar taxtamizga rasmiy post qo'yamiz. To'liq qo'shilaman, halollik hamma narsa.
Endi Cloudflare haqiqatan ham katta kompaniya, men u uchun ishlayman va endi men xatomiz, uning oqibatlari va harakatlarimiz haqida ochiq yozishim kerak.
2 iyul voqealari
2-iyul kuni biz WAF uchun boshqariladigan qoidalarda yangi qoidani chiqardik, shu sababli butun dunyo bo'ylab Cloudflare tarmog'ida HTTP/HTTPS trafigini qayta ishlaydigan har bir protsessor yadrosida. Biz yangi zaifliklar va tahdidlarga javoban WAF uchun boshqariladigan qoidalarni doimiy ravishda takomillashtirib boramiz. May oyida, masalan, biz shoshildik SharePoint-dagi jiddiy zaiflikdan himoya qilish uchun. Bizning WAF-ning asosiy maqsadi qoidalarni tez va global miqyosda joylashtirish qobiliyatidir.
Afsuski, o'tgan payshanba kungi yangilanish orqaga qaytish uchun juda ko'p HTTP/HTTPS CPU resurslarini behuda sarflaydigan muntazam ifodani o'z ichiga olgan. Natijada bizning asosiy proksi-serverimiz, CDN va WAF funksiyalarimiz zarar ko'rdi. Grafik HTTP/HTTPS trafigiga xizmat ko'rsatish uchun protsessor resurslari bizning tarmog'imiz serverlarida deyarli 100% ga yetganini ko'rsatadi.
Hodisa paytida mavjud bo'lgan bir nuqtada protsessordan foydalanish
Natijada, bizning mijozlarimiz (va mijozlarimizning mijozlari) Cloudflare domenlarida 502 xato sahifasi bilan yakunlandi. 502 ta xato Cloudflare front-end veb-serverlari tomonidan yaratilgan bo'lib, ular hali ham bepul yadrolarga ega bo'lgan, ammo HTTP/HTTPS trafigini boshqarish jarayonlari bilan bog'lana olmagan.
Bu mijozlarimizga qanchalik noqulayliklar keltirganini bilamiz. Biz juda uyaldik. Va bu muvaffaqiyatsizlik bizni voqea bilan samarali kurashishimizga to'sqinlik qildi.
Agar siz ushbu mijozlardan biri bo'lsangiz, ehtimol siz qo'rqib, g'azablangan va xafa bo'lgansiz. Bundan tashqari, bizda yo'q . Yuqori protsessor iste'moli noto'g'ri yozilgan muntazam ifoda bilan bitta WAF qoidasiga bog'liq bo'lib, bu haddan tashqari orqaga qaytishga olib keldi. Mana aybdor ifoda: (?:(?:"|'|]|}||d|(?:nan|infinity|true|false|null|undefined|symbol|math)|`|-|+)+[)]*;?((?:s|-|~|!|{}||||+)*.*(?:.*=.*)))
Bu o'z-o'zidan qiziqarli bo'lsa-da (va men bu haqda quyida batafsilroq gaplashaman), Cloudflare xizmati nafaqat yomon muntazam ifoda tufayli 27 daqiqa davomida ishlamay qoldi. Muvaffaqiyatsizlikka olib kelgan voqealar ketma-ketligini tasvirlash uchun bizga biroz vaqt kerak bo'ldi, shuning uchun biz javob berishga sekin edik. Xabar oxirida men orqaga qaytishni oddiy iborada tasvirlab beraman va u bilan nima qilish kerakligini aytaman.
Nima bo'ldi
Keling, tartibda boshlaylik. Bu yerda barcha vaqtlar UTC da.
Soat 13:42 da xavfsizlik devori jamoasining muhandisi aniqlash qoidalariga kichik o'zgartirish kiritdi. avtomatik jarayon yordamida. Shunga ko'ra, o'zgartirish so'rovi chiptasi yaratildi. Biz bunday chiptalarni Jira orqali boshqaramiz (quyida skrinshot).
3 daqiqadan so'ng, WAF bilan bog'liq muammo haqida xabar beruvchi PagerDuty-ning birinchi sahifasi paydo bo'ldi. Bu normal ishlashini kuzatish uchun Cloudflare-dan tashqarida WAF-larning (bizda ularning yuzlablari bor) funksionalligini sinovdan o'tkazuvchi sintetik sinov edi. Shundan so'ng darhol Cloudflare-ning boshqa uchdan-end xizmat sinovlari muvaffaqiyatsizlikka uchraganligi, global trafik muammolari, keng tarqalgan 502 xatolik va dunyo bo'ylab shaharlardagi mavjudlik nuqtalarimizdan (PoP) bir tonna hisobotlar etishmasligi haqida ogohlantirishlar sahifalari paydo bo'ldi. CPU resurslari.
Men bunday ogohlantirishlarning bir nechtasini oldim, yig'ilishdan chiqib ketdim va stolga ketayotganimda, yechimlarni ishlab chiqish bo'limi boshlig'i biz trafikning 80 foizini yo'qotganimizni aytdi. Men muammo ustida ishlayotgan SRE muhandislarimiz oldiga yugurdim. Avvaliga biz buni qandaydir noma'lum hujum deb o'yladik.
Cloudflare SRE muhandislari butun dunyo bo'ylab tarqalib ketishgan va vaziyatni kechayu kunduz kuzatib borishadi. Odatda, bu ogohlantirishlar cheklangan doiradagi muayyan mahalliy muammolar haqida sizni xabardor qiladi, ichki asboblar panelida kuzatiladi va kuniga bir necha marta hal qilinadi. Ammo bu sahifalar va bildirishnomalar haqiqatan ham jiddiy narsani ko'rsatdi va SRE muhandislari darhol P0 jiddiylik darajasini e'lon qildilar va boshqaruv va tizim muhandislari bilan bog'lanishdi.
O'sha paytda bizning londonlik muhandislarimiz katta zalda ma'ruza tinglashayotgan edi. Ma'ruzani to'xtatishga to'g'ri keldi, hamma katta konferentsiya zalida yig'ildi va ko'proq mutaxassislar chaqirildi. Bu SRElar o'zlari hal qila oladigan odatiy muammo emas edi. Kerakli mutaxassislarni jalb qilish kerak edi.
Soat 14:00 da muammo WAFda ekanligini va hech qanday hujum yo'qligini aniqladik. Ishlash guruhi CPU ma'lumotlarini tortib oldi va WAF aybdor ekanligi ayon bo'ldi. Boshqa bir xodim bu nazariyani strace yordamida tasdiqladi. Yana kimdir jurnallarda WAF bilan bog'liq muammo borligini ko'rdi. Soat 14:02 da butun jamoa mening oldimga butun dunyo bo'ylab bitta komponentni o'chirib qo'yadigan Cloudflare-ga o'rnatilgan global o'ldirishdan foydalanishni taklif qilishdi.
WAF uchun global o'ldirishni qanday qilganimiz boshqa voqea. Bu unchalik oddiy emas. Biz o'z mahsulotlarimizdan foydalanamiz va bizning xizmatimizdan beri ishlamadi, biz autentifikatsiya qila olmadik va ichki boshqaruv paneliga kira olmadik (hamma narsa tuzatilganda, biz ba'zi jamoa a'zolari ichki boshqaruv panelidan foydalanilmasa, hisobga olish ma'lumotlarini o'chirib qo'yadigan xavfsizlik xususiyati tufayli kirishni yo'qotganligini bilib oldik. uzoq vaqt).
Va biz Jira yoki qurilish tizimi kabi ichki xizmatlarimizga kira olmadik. Bizga kamdan-kam ishlatadigan vaqtinchalik hal qilish mexanizmi kerak edi (buni ham ishlab chiqish kerak). Nihoyat, bitta muhandis soat 14:07 da WAFni o'chirib qo'yishga muvaffaq bo'ldi va 14:09 da trafik va CPU darajasi hamma joyda normal holatga qaytdi. Cloudflare-ning qolgan himoya mexanizmlari odatdagidek ishladi.
Keyin biz WAFni tiklashga kirishdik. Vaziyat g'ayrioddiy edi, shuning uchun biz bitta shaharda alohida trafikdan foydalangan holda salbiy testlar (o'zimizdan o'zimizdan bu o'zgarish haqiqatan ham muammomi yoki yo'qmi deb so'radik) va ijobiy testlarni (orqaga qaytish ishlaganiga ishonch hosil qilish) o'tkazdik va pullik mijozlarni u yerdan o'tkazdik.
14:52 da biz sababni tushunganimizga amin bo'ldik va tuzatish kiritdik va WAFni yana yoqdik.
Cloudflare qanday ishlaydi
Cloudflare-da WAF qoidalarini boshqarishga bag'ishlangan muhandislar jamoasi mavjud. Ular aniqlash sur'atlarini yaxshilashga, noto'g'ri pozitivlarni kamaytirishga va paydo bo'lgan yangi tahdidlarga tezda javob berishga intiladi. Oxirgi 60 kun ichida WAF uchun boshqariladigan qoidalar uchun 476 ta oʻzgartirish soʻrovi koʻrib chiqildi (oʻrtacha har 3 soatda bittadan).
Ushbu maxsus o'zgarish simulyatsiya rejimida qo'llanilishi kerak edi, bu erda haqiqiy mijoz trafigi qoida orqali o'tadi, lekin hech narsa bloklanmagan. Biz ushbu rejimdan qoidalarning samaradorligini sinab ko'rish va noto'g'ri ijobiy va noto'g'ri salbiy stavkalarni o'lchash uchun foydalanamiz. Ammo simulyatsiya rejimida ham qoidalar haqiqatda bajarilishi kerak va bu holda qoidada juda ko'p protsessor resurslarini iste'mol qiladigan muntazam ifoda mavjud edi.
Yuqoridagi o'zgartirish so'rovidan ko'rinib turibdiki, bizda joylashtirish rejasi, orqaga qaytarish rejasi va ushbu turdagi joylashtirish uchun ichki standart operatsion protseduraga (SOP) havola mavjud. Qoidani o'zgartirish uchun SOP uni global miqyosda nashr etishga imkon beradi. Aslida, Cloudflare-da ishlar butunlay boshqacha tarzda amalga oshiriladi va SOP biz dasturiy ta'minotni sinovdan o'tkazish va ichki foydalanish uchun avvalo ichki mavjudlik nuqtasiga (PoP) (bizning xodimlarimiz foydalanadigan), keyin esa kichik miqdordagi mijozlarga jo'natishimizni buyuradi. izolyatsiya qilingan joy, keyin ko'p sonli mijozlarga va shundan keyingina butun dunyoga.
Bu shunday ko'rinadi. Biz git-dan BitBucket orqali ichki foydalanamiz. O'zgartirishlar ustida ishlayotgan muhandislar TeamCity-ga tuzilgan kodni taqdim etadilar va qurilish o'tgandan keyin sharhlovchilar tayinlanadi. Pull so'rovi tasdiqlangandan so'ng, kod yig'iladi va bir qator testlar o'tkaziladi (yana).
Qurilish va sinovlar muvaffaqiyatli yakunlansa, Jira'da o'zgartirish so'rovi yaratiladi va tegishli menejer yoki rahbar o'zgartirishni tasdiqlashi kerak. Tasdiqlangandan so'ng, "PoP menagerie" deb ataladigan joyga joylashtirish amalga oshiriladi: DOG, PIG va (it, cho'chqa va kanareyka).
DOG PoP - bu Cloudflare PoP (har bir boshqa shaharlarimiz kabi) undan faqat Cloudflare xodimlari foydalanadi. Ichki foydalanish uchun PoP sizga mijozlar trafigi yechimga oqib chiqmasdan oldin muammolarni hal qilish imkonini beradi. Foydali narsa.
Agar DOG testi muvaffaqiyatli bo'lsa, kod PIG (gvineya cho'chqasi) bosqichiga o'tadi. Bu Cloudflare PoP bo'lib, u erda yangi kod orqali kichik miqdordagi bepul mijozlar oqimi o'tadi.
Agar hamma narsa yaxshi bo'lsa, kod Kanareykaga kiradi. Bizda dunyoning turli burchaklarida uchta Canary PoP mavjud. Ularda pullik va bepul mijozlarning trafigi yangi kod orqali o'tadi va bu xatolar uchun oxirgi tekshirish.
Cloudflare-da dasturiy ta'minotni chiqarish jarayoni
Agar kod Kanareykada yaxshi bo'lsa, biz uni chiqaramiz. Barcha bosqichlardan o'tish - DOG, PIG, Canary, butun dunyo - kod o'zgarishiga qarab bir necha soat yoki kun davom etadi. Cloudflare tarmog‘i va mijozlari xilma-xilligi tufayli biz kodni barcha mijozlarga global miqyosda chiqarishdan oldin uni sinchiklab tekshiramiz. Ammo WAF bu jarayonga aniq amal qilmaydi, chunki tahdidlarga tezda javob berish kerak.
WAF tahdidlari
So'nggi bir necha yil ichida umumiy ilovalarda tahdidlarning sezilarli o'sishi kuzatildi. Bu dasturiy ta'minotni sinovdan o'tkazish vositalarining ko'proq mavjudligi bilan bog'liq. Masalan, biz yaqinda yozgan edik ).
Manba:
Ko'pincha kontseptsiyaning isboti yaratiladi va darhol Github-da nashr etiladi, shunda dasturni qo'llab-quvvatlovchi jamoalar uni tezda sinab ko'rishlari va uning etarli darajada himoyalanganligiga ishonch hosil qilishlari mumkin. Shu sababli, Cloudflare yangi hujumlarga imkon qadar tezroq javob berish qobiliyatiga muhtoj, shunda mijozlar o'z dasturlarini tuzatish imkoniyatiga ega bo'ladilar.
Cloudflare tezkor javobining ajoyib namunasi - may oyida SharePoint zaiflikdan himoyalanish vositalarini o'rnatish (). E'lon qilinganidan so'ng deyarli darhol mijozlarimizning SharePoint o'rnatishlarida zaiflikdan foydalanishga urinishlarning ko'pligini payqadik. Bizning yigitlarimiz doimiy ravishda yangi tahdidlarni kuzatib boradilar va mijozlarimizni himoya qilish uchun qoidalarni yozishadi.
Payshanba kuni muammoga sabab bo'lgan qoida saytlararo skriptlardan (XSS) himoya qilishi kerak edi. So'nggi yillarda bunday hujumlar ham tez-tez sodir bo'ldi.
Manba:
WAF uchun boshqariladigan qoidani o'zgartirishning standart protsedurasi global joylashtirishdan oldin uzluksiz integratsiya (CI) testini o'tkazishdir. O'tgan payshanba kuni biz buni qildik va qoidalarni ishlab chiqdik. Soat 13:31 da muhandis o'zgartirish bilan tasdiqlangan tortib olish so'rovini yubordi.
13:37 da TeamCity qoidalarni to'pladi, testlarni o'tkazdi va ruxsat berdi. WAF test to'plami WAF ning asosiy funksionalligini sinovdan o'tkazadi va individual funktsiyalar uchun ko'p sonli birlik testlaridan iborat. Birlik sinovlaridan so'ng biz juda ko'p HTTP so'rovlaridan foydalangan holda WAF qoidalarini sinab ko'rdik. HTTP so'rovlari WAF tomonidan qaysi so'rovlar bloklanishi kerakligini (hujumni to'xtatish uchun) va qaysilari orqali ruxsat berilishi mumkinligini tekshiradi (hamma narsani bloklamaslik va noto'g'ri pozitivlardan qochish uchun). Ammo biz protsessorning haddan tashqari ishlatilishini sinab ko'rmadik va oldingi WAF tuzilmalarining jurnallarini o'rganish shuni ko'rsatadiki, qoida testini bajarish vaqti oshmagan va resurslar etarli emasligiga shubha qilish qiyin edi.
Sinovlar o'tdi va TeamCity avtomatik ravishda 13:42 da o'zgarishlarni joriy qila boshladi.
Quicksilver
WAF qoidalari tahdidlarni zudlik bilan bartaraf etishga qaratilgan, shuning uchun biz ularni oʻzgarishlarni bir necha soniya ichida global miqyosda targʻib qiluvchi Quicksilver’ning taqsimlangan kalit-qiymatlar doʻkonidan foydalanib joylashtiramiz. Bizning barcha mijozlarimiz asboblar panelida yoki API orqali konfiguratsiyani o'zgartirganda ushbu texnologiyadan foydalanadilar va shu tufayli biz o'zgarishlarga chaqmoq tezligida javob beramiz.
Biz Quicksilver haqida ko'p gaplashmadik. Ilgari biz foydalanardik global miqyosda taqsimlangan kalit-qiymat do'koni sifatida, lekin u bilan ishlashda muammolar bor edi va biz 180 dan ortiq shaharlarda takrorlangan o'z do'konimizni yozdik. Endi biz Quicksilver-dan mijozlarga konfiguratsiya o'zgarishlarini kiritish, WAF qoidalarini yangilash va mijozlar tomonidan yozilgan JavaScript kodini Cloudflare Workers-ga tarqatish uchun foydalanamiz.
Butun dunyo bo'ylab konfiguratsiyani o'zgartirish uchun asboblar panelidagi tugmani bosish yoki API-ga qo'ng'iroq qilish bir necha soniya vaqt oladi. Mijozlarga ushbu sozlash tezligi yoqdi. Va ishchilar ularga deyarli bir zumda global dasturiy ta'minotni joylashtirish imkonini beradi. O'rtacha, Quicksilver soniyada taxminan 350 o'zgarishlarni tarqatadi.
Va Quicksilver juda tez. O'rtacha, biz butun dunyo bo'ylab har bir kompyuterda o'zgarishlarni targ'ib qilish uchun 99 soniyaning 2,29 foiziga erishdik. Tezlik odatda yaxshi narsa. Axir, siz funktsiyani yoqsangiz yoki keshni tozalaganingizda, bu deyarli bir zumda va hamma joyda sodir bo'ladi. Cloudflare Workers orqali kod yuborish bir xil tezlikda sodir bo'ladi. Cloudflare o'z mijozlariga kerakli vaqtda tezkor yangilanishlarni va'da qiladi.
Ammo bu holatda tezlik bizni shafqatsiz hazil qildi va qoidalar hamma joyda bir necha soniya ichida o'zgardi. Siz WAF kodi Lua dan foydalanishini payqagandirsiz. Cloudflare ishlab chiqarish va tafsilotlarda Lua-dan keng foydalanadi bizmiz . Lua WAF foydalanadi ichki va moslashtirish uchun orqaga qaytishni qo'llaydi. Unda nazoratdan chiqib ketadigan ifodalardan himoya qilish mexanizmlari yo'q. Quyida men bu haqda va bu borada nima qilayotganimiz haqida ko'proq gaplashaman.
Qoidalar o'rnatilishidan oldin hamma narsa muammosiz o'tdi: tortish so'rovi yaratildi va tasdiqlandi, CI/CD quvur liniyasi kodni yig'di va sinovdan o'tkazdi, o'zgartirish so'rovi joylashtirish va orqaga qaytarishni boshqaradigan SOPga muvofiq topshirildi va joylashtirish tugallandi.
Cloudflare WAF-ni joylashtirish jarayoni
Nima bo‘ldi
Aytganimdek, biz har hafta o'nlab yangi WAF qoidalarini o'rnatamiz va bizda bunday joylashtirishning salbiy oqibatlaridan himoya qilish uchun ko'plab tizimlar mavjud. Va agar biror narsa noto'g'ri bo'lsa, bu odatda bir vaqtning o'zida bir nechta holatlarning kombinatsiyasi. Agar siz bitta sababni topsangiz, bu, albatta, taskin beradi, lekin bu har doim ham to'g'ri emas. Bular birgalikda HTTP/HTTPS xizmatimizning ishlamay qolishiga olib kelgan sabablardir.
- Muhandis haddan tashqari ko'p bo'lishi mumkin bo'lgan muntazam ifoda yozgan .
- Muntazam iboraning juda ko'p protsessorni isrof qilishiga to'sqinlik qilishi mumkin bo'lgan xususiyat bir necha hafta oldin WAF-ni qayta tiklashda noto'g'ri olib tashlangan - WAF kamroq resurslarni iste'mol qilish uchun qayta ishlash kerak edi.
- Muntazam ifoda mexanizmi murakkablik kafolatiga ega emas edi.
- Sinov to'plami ortiqcha protsessor sarfini aniqlay olmadi.
- SOP shoshilinch bo'lmagan qoidalar o'zgarishlarini ko'p bosqichli jarayonsiz global miqyosda amalga oshirish imkonini beradi.
- Qayta tiklash rejasi to'liq WAF qurishni ikki marta ishga tushirishni talab qildi, bu uzoq vaqt talab qildi.
- Global transport muammolari haqidagi birinchi ogohlantirish juda kech ishga tushirildi.
- Holat sahifasini yangilash uchun biroz vaqt ketdi.
- Nosozlik tufayli tizimlarga kirishda muammolarga duch keldik va aylanib o‘tish jarayoni yaxshi o‘rnatilmagan.
- SRE muhandislari baʼzi tizimlarga kirish huquqini yoʻqotdilar, chunki ularning hisob maʼlumotlari xavfsizlik sababli muddati tugagan.
- Bizning mijozlarimiz Cloudflare boshqaruv paneli yoki API-ga kirish imkoniga ega emas edilar, chunki ular Cloudflare mintaqasidan o'tadi.
O'tgan payshanbadan beri nima o'zgardi
Birinchidan, biz WAF uchun relizlar bo'yicha barcha ishlarni butunlay to'xtatdik va quyidagilarni amalga oshirmoqdamiz:
- Biz olib tashlagan protsessorni haddan tashqari ishlatishdan himoya qilishni qaytadan kiritmoqdamiz. (Tayyor)
- Boshqariladigan qoidalardagi barcha 3868 ta qoidani qoʻlda tekshirish WAF uchun boshqa mumkin boʻlgan haddan tashqari orqaga qaytish holatlarini topish va tuzatish. (Tasdiqlash tugallandi)
- Biz test to'plamidagi barcha qoidalar uchun ishlash profilini o'z ichiga olamiz. (Kutilayotgan: 19 iyul)
- Oddiy ifoda mexanizmiga o'tish yoki - ikkalasi ham ish vaqti kafolatlarini beradi. (Kutilayotgan: 31 iyul)
- Biz Cloudflare-dagi boshqa dasturlar singari qoidalarni bosqichma-bosqich o'rnatish uchun SOPni qayta yozmoqdamiz, lekin ayni paytda hujumlar allaqachon boshlangan bo'lsa, favqulodda global joylashtirish imkoniyatiga egamiz.
- Biz Cloudflare boshqaruv paneli va APIni Cloudflare hududidan zudlik bilan olib tashlash qobiliyatini rivojlantirmoqdamiz.
- Sahifani yangilashni avtomatlashtirish .
Uzoq muddatda biz bir necha yil oldin yozgan Lua WAF-dan uzoqlashyapmiz. WAF ga koʻchirilmoqda . Shunday qilib, WAF tezroq ishlaydi va qo'shimcha himoya darajasini oladi.
xulosa
Ushbu nosozlik biz va mijozlarimiz uchun muammo tug'dirdi. Biz vaziyatni toʻgʻirlash uchun tezkor harakat qildik va hozir halokatga sabab boʻlgan jarayonlardagi kamchiliklar ustida ishlayapmiz, shuningdek, kelajakda yangi texnologiyaga oʻtishda muntazam iboralar bilan yuzaga kelishi mumkin boʻlgan muammolardan ehtiyot boʻlish uchun yanada chuqurroq qazmoqdamiz.
Biz bu uzilishdan juda xijolatdamiz va mijozlarimizdan uzr so'raymiz. Umid qilamizki, bu o'zgarishlar bunday holat boshqa takrorlanmasligini ta'minlaydi.
Ilova. Muntazam iboralarni orqaga qaytarish
Qanday ifoda ekanligini tushunish uchun:
(?:(?:"|'|]|}||d
(?:nan|infinity|true|false|null|undefined|symbol|math)|`|-
|+)+[)]*;?((?:s|-|~|!|{}||||+)*.*(?:.*=.*)))barcha protsessor resurslarini yeb qo'ygan bo'lsangiz, standart oddiy ifoda mexanizmi qanday ishlashi haqida ozgina bilishingiz kerak. Bu erda muammo naqshdir .*(?:.*=.*). (?: va mos keladi ) tutib boʻlmaydigan guruhdir (yaʼni qavs ichidagi ifoda bitta ifoda sifatida guruhlangan).
Haddan tashqari CPU iste'moli kontekstida bu naqshni quyidagicha ta'riflash mumkin .*.*=.*. Ushbu shaklda naqsh keraksiz darajada murakkab ko'rinadi. Ammo bundan ham muhimi, real dunyoda dvigateldan fragmentga mos kelishini so'ragan iboralar (WAF qoidalaridagi murakkab iboralar kabi) va keyin boshqa fragment halokatli orqaga qaytishga olib kelishi mumkin. Va shuning uchun ham.
Muntazam ifodada . siz bitta belgiga mos kelishingiz kerakligini anglatadi, .* - nol yoki undan ko'p belgilarni "ochko'zlik bilan" moslashtiring, ya'ni maksimal belgilarni yozib oling, shunda .*.*=.* nol yoki undan ko'p belgilarga mos kelishini anglatadi, keyin nol yoki undan ko'p belgilarga mos keladi, literal = belgisini toping, nol yoki undan ko'p belgilarga mos keladi.
Keling, test chizig'ini olaylik x=x. Bu ifodaga mos keladi .*.*=.*. .*.* teng belgisi birinchisiga mos kelishidan oldin x (guruhlardan biri .* mos keladi x, va ikkinchisi - nol belgilar). .* keyin = oxirgi mos keladi x.
Ushbu taqqoslash 23 bosqichni talab qiladi. Birinchi guruh .* в .*.*=.* ochko'zlik bilan harakat qiladi va butun ipga mos keladi x=x. Dvigatel keyingi guruhga o'tadi .*. Bizda mos keladigan boshqa belgilar yo'q, shuning uchun ikkinchi guruh .* nol belgilarga mos keladi (bu ruxsat etiladi). Keyin vosita belgiga o'tadi =. Boshqa belgilar yo'q (birinchi guruh .* butun ifodani ishlatgan x=x), taqqoslash sodir bo'lmaydi.
Va keyin muntazam ifoda mexanizmi boshiga qaytadi. U birinchi guruhga o'tadi .* va taqqoslaydi с x= (o'rniga x=x), keyin esa ikkinchi guruhni oladi .*. Ikkinchi guruh .* ikkinchisi bilan solishtiriladi x, va bizda yana hech qanday belgilar qolmadi. Va dvigatel yana kelganida = в .*.*=.*, hech narsa ishlamaydi. Va u yana orqaga qaytdi.
Bu safar guruh .* hali ham mos keladi x=, lekin ikkinchi guruh .* boshqa emas; boshqa ... bo'lmaydi; Endi yo'q x, va nol belgilar. Dvigatel tom ma'noda belgi topishga harakat qilmoqda = naqshda .*.*=.*, lekin chiqmaydi (oxir-oqibat, birinchi guruh uni allaqachon egallab olgan .*). Va u yana orqaga qaytdi.
Bu safar birinchi guruh .* faqat birinchi x ni oladi. Ammo ikkinchi guruh .* "ochko'zlik bilan" qo'lga oladi =x. Nima bo'lishini allaqachon taxmin qildingizmi? Dvigatel literalga mos kelishga harakat qiladi =, muvaffaqiyatsiz tugadi va yana bir orqaga qaytishni amalga oshiradi.
Birinchi guruh .* hali ham birinchisiga mos keladi x... Ikkinchisi .* faqat oladi =. Albatta, vosita literalga mos kela olmaydi =, chunki ikkinchi guruh allaqachon buni qilgan .*. Va yana orqaga qaytish. Va biz uchta belgidan iborat qatorni moslashtirishga harakat qilmoqdamiz!
Natijada, birinchi guruh .* faqat birinchisiga mos keladi x, ikkinchi .* - nol belgilar bilan va vosita nihoyat harfga mos keladi = ifodada с = mos ravishda. Keyingi - oxirgi guruh .* oxirgisi bilan solishtiriladi x.
23 qadam faqat uchun x=x. Perl-dan foydalanish haqida qisqa videoni tomosha qiling , bu qadamlar va orqaga qaytish qanday sodir bo'lishini ko'rsatadi.
Bu allaqachon juda ko'p ish, lekin uning o'rniga nima bo'lsa x=x bizda bo'ladi x=xx? Bu 33 qadam. Agar x=xxx? 45. Munosabat chiziqli emas. Grafikda taqqoslash ko'rsatilgan x=x uchun x=xxxxxxxxxxxxxxxxxxxx (20 x после =). Agar bizda 20 x keyin bo'lsa =, vosita moslikni 555 qadamda yakunlaydi! (Bundan tashqari, agar biz yutqazgan bo'lsak x= va satr oddiygina 20 dan iborat x, dvigatel hech qanday mos kelmasligini tushunish uchun 4067 qadamni oladi).
Ushbu video taqqoslash uchun barcha orqaga qaytishlarni ko'rsatadi x=xxxxxxxxxxxxxxxxxxxx:
Muammo shundaki, string hajmi kattalashgani sayin, mos keladigan vaqt o'ta chiziqli ravishda o'sadi. Ammo oddiy ifoda biroz o'zgartirilsa, vaziyat yanada yomonlashishi mumkin. Aytaylik, bizda bor edi .*.*=.*; (ya'ni naqsh oxirida to'g'ridan-to'g'ri nuqta-vergul bor edi). Masalan, kabi ifodaga mos kelish uchun foo=bar;.
Va bu erda orqaga qaytish haqiqiy falokat bo'ladi. Taqqoslash uchun x=x u 90 emas, 23 qadamni oladi. Va bu raqam tez o'sib bormoqda. Taqqoslash uchun x= va 20 x, 5353 qadam kerak. Mana diagramma. Eksa qiymatlariga qarang Y oldingi grafik bilan solishtirganda.
Agar qiziqsangiz, 5353 ta mos kelmaydigan barcha qadamlarni tekshiring x=xxxxxxxxxxxxxxxxxxxx и .*.*=.*;
Ochko'zlikdan ko'ra dangasalikni qo'llash orqali orqaga qaytish darajasini nazorat qilish mumkin. Agar asl ifodani o'zgartirsak .*?.*?=.*?, taqqoslash uchun x=x u 11 qadamni oladi (23 emas). kelsak x=xxxxxxxxxxxxxxxxxxxx... Hammasi, chunki ? после .* harakat qilishdan oldin dvigatelga minimal belgilar soniga mos kelishini aytadi.
Ammo dangasa xaritalar orqaga qaytish muammosini to'liq hal qilmaydi. Agar biz halokatli misolni almashtirsak .*.*=.*; haqida .*?.*?=.*?;, bajarilish vaqti bir xil bo'lib qoladi. x=x hali ham 555 qadamni talab qiladi va x= va 20 x - 5353.
Qilish mumkin bo'lgan yagona narsa (to'liq aniqlik uchun naqshni to'liq qayta yozishdan tashqari) muntazam ifoda mexanizmidan orqaga qaytish mexanizmi bilan voz kechishdir. Bu biz keyingi bir necha hafta ichida qiladigan narsadir.
Bu muammoning yechimi 1968 yilda Kent Tompson maqola yozganidan beri ma'lum (“Dasturlash usullari: oddiy ifodalarni qidirish algoritmi”). Maqolada muntazam ifodani deterministik bo'lmagan chekli holat mashinalariga aylantirish imkonini beruvchi mexanizm tasvirlangan va deterministik bo'lmagan chekli holat mashinalarida holat o'zgargandan so'ng, bajarilish vaqti mos keladigan satrga chiziqli bog'liq bo'lgan algoritmdan foydalaning.
Dasturlash usullari
Oddiy ifodalarni qidirish algoritmi
Ken Tompson
Bell Telefon Laboratories, Inc., Murray Hill, Nyu-JersiU matndagi belgilarning ma'lum bir qatorini qidirish usulini tavsiflaydi va bu usulni kompilyator shaklida amalga oshirishni muhokama qiladi. Kompilyator muntazam ifodani manba kodi sifatida qabul qiladi va IBM 7094 dasturini ob'ekt kodi sifatida ishlab chiqaradi. Ob'ekt dasturi qidiruv matni ko'rinishida kiritishni qabul qiladi va har safar matn satri berilgan muntazam ifodaga mos kelganda signal chiqaradi. Maqolada misollar, muammolar va echimlar keltirilgan.
Algoritm
Agar qisman muvaffaqiyatli qidiruv natija bermasa, oldingi qidiruv algoritmlari orqaga qaytishga olib kelgan.Kompilyatsiya rejimida algoritm belgilar bilan ishlamaydi. U kompilyatsiya qilingan kodga ko'rsatmalarni uzatadi. Bajarish juda tez - ma'lumotlarni joriy ro'yxatning yuqori qismiga o'tkazgandan so'ng, u avtomatik ravishda muntazam ifodadagi barcha mumkin bo'lgan ketma-ket belgilarni qidiradi.
Kompilyatsiya va qidirish algoritmi vaqt almashish matn muharririga kontekstli qidiruv sifatida kiritilgan. Albatta, bu bunday qidiruv protsedurasining yagona qo'llanilishidan uzoqdir. Masalan, ushbu algoritmning varianti assemblerda jadvalda belgilar qidirish sifatida ishlatiladi.
O'quvchi muntazam iboralar va IBM 7094 kompyuter dasturlash tilini yaxshi biladi deb taxmin qilinadi.Kompilyator
Kompilyator parallel ravishda ishlaydigan uch bosqichdan iborat. Birinchi bosqich sintaktik filtrlash bo'lib, u faqat sintaktik jihatdan to'g'ri keladigan muntazam iboralarni o'tkazish imkonini beradi. Bu qadam oddiy iboralarni moslashtirish uchun "·" operatorini ham kiritadi. Ikkinchi bosqichda muntazam ifoda postfiks shakliga aylantiriladi. Uchinchi bosqichda obyekt kodi yaratiladi. Dastlabki 2 bosqich aniq va biz ular haqida to'xtalmaymiz.
Tompsonning maqolasi deterministik bo'lmagan chekli holat mashinalari haqida gapirmaydi, lekin u chiziqli vaqt algoritmini yaxshi tushuntiradi va IBM 60 uchun assembly til kodini yaratuvchi ALGOL-7094 dasturini taqdim etadi. Amalga oshirish qiyin, lekin g'oya juda oddiy.
joriy qidiruv yo'li. U bitta kirish va ikkita chiqishga ega ⊕ belgisi bilan ifodalanadi.
1-rasmda muntazam ifoda misolini o'zgartirishda uchinchi kompilyatsiya bosqichining funktsiyalari ko'rsatilgan. Misoldagi dastlabki uchta belgi a, b, c bo'lib, har biri S[i] stek yozuvini va NNODE maydonini yaratadi.Natijadagi muntazam ifodani bitta stek yozuvida yaratish uchun mavjud kodga NNODE (5-rasmga qarang)
Muntazam ifoda shunday ko'rinishga ega bo'ladi .*.*=.*, agar siz buni Tompsonning maqolasidagi rasmlardagi kabi tasavvur qilsangiz.
Shaklda. 0 da 0 dan boshlanadigan beshta holat va 3, 1 va 2 holatlardan boshlanadigan 3 ta davr mavjud. Bu uchta sikl uchtaga mos keladi. .* muntazam ifodada. Nuqtali 3 oval bitta belgiga mos keladi. Belgili oval = tom ma'nodagi belgiga mos keladi =. 4-shtat yakuniy hisoblanadi. Agar biz unga erishsak, unda muntazam ifoda mos keladi.
Bunday holat diagrammasi muntazam ifodalarni moslashtirish uchun qanday ishlatilishini ko'rish uchun .*.*=.*, biz satrlarni moslashtirishni ko'rib chiqamiz x=x. Dastur rasmda ko'rsatilganidek, 0 holatidan boshlanadi. 1.
Ushbu algoritm ishlashi uchun davlat mashinasi bir vaqtning o'zida bir nechta holatda bo'lishi kerak. Deterministik bo'lmagan chekli mashina bir vaqtning o'zida barcha mumkin bo'lgan o'tishlarni amalga oshiradi.
Kirish ma'lumotlarini o'qishga ulgurmasdan oldin, u rasmda ko'rsatilganidek, ikkala birinchi holatga (1 va 2) o'tadi. 2.
Shaklda. 2 birinchisiga qaraganida nima sodir bo'lishini ko'rsatadi x в x=x. x 1-holatdan 1-holatga qaytib, yuqori nuqtaga xaritalashi mumkin. Yoki x 2-holatdan 2-holatga oʻtib, quyidagi nuqtani xaritalashi mumkin.
Birinchisiga mos kelgandan keyin x в x=x biz hali ham 1 va 2-holatlardamiz. Biz 3 yoki 4-holatga erisha olmaymiz, chunki bizga harfiy belgi kerak =.
Keyin algoritm ko'rib chiqadi = в x=x. Undan oldingi x kabi, u 1-holatdan 1-holatgacha yoki 2-holatdan 2-holatgacha boʻlgan ikkita yuqori tsikldan biriga mos kelishi mumkin, lekin algoritm literalga mos kelishi mumkin. = va 2-holatdan 3-holatga (va darhol 4) o'ting. Bu rasmda ko'rsatilgan. 3.
Keyin algoritm oxirgisiga o'tadi x в x=x. 1 va 2 holatlardan 1 va 2 holatlarga bir xil o'tishlar mumkin. 3-holatdan x o'ngdagi nuqtaga mos kelishi va 3-holatga qaytishi mumkin.
Ushbu bosqichda har bir belgi x=x ko'rib chiqildi va biz 4-holatga erishganimiz sababli, muntazam ifoda ushbu qatorga mos keladi. Har bir belgi bir marta qayta ishlanadi, shuning uchun bu algoritm kirish satrining uzunligi bo'yicha chiziqli bo'ladi. Va orqaga qaytish yo'q.
Shubhasiz, 4-holatga erishgandan so'ng (algoritm mos kelganda x=) butun muntazam ifoda mos keladi va algoritm uni umuman hisobga olmasdan tugatilishi mumkin x.
Ushbu algoritm chiziqli ravishda kirish satrining o'lchamiga bog'liq.
Manba: www.habr.com