Бараг 9 жилийн өмнө Cloudflare жижигхэн компани байсан бөгөөд би үүнд ажиллаагүй, би зүгээр л үйлчлүүлэгч байсан. Cloudflare-г ажиллуулснаас хойш нэг сарын дараа би вэбсайтаа хийсэн тухай мэдэгдэл хүлээн авсан DNS ажиллахгүй байх шиг байна. Cloudflare-д өөрчлөлт оруулсан , мөн эвдэрсэн DNS байсан.
Би тэр даруй Мэттью Принс руу "Миний DNS хаана байна?" гэсэн гарчигтай захидал бичсэн бөгөөд тэр техникийн дэлгэрэнгүй мэдээлэл бүхий урт хариултыг буцааж илгээсэн (), үүнд би хариулсан:
Эх сурвалж: Жон Грэм-Каминг
Огноо: 7 оны 2010-р сарын 9, 14:XNUMX
Сэдэв: Re: Миний DNS хаана байна?
Хэнд: Мэттью ПринсСайхан тайлан, баярлалаа. Асуудал гарвал би заавал залгана. Техникийн бүх мэдээллийг цуглуулсны дараа энэ тухай нийтлэл бичих нь зүйтэй болов уу. Нээлттэй, шударга түүх хүмүүст таалагдах байх гэж бодож байна. Ялангуяа та үүн дээр график хавсаргаж эхэлснээс хойш замын хөдөлгөөн хэрхэн өссөнийг харуулах юм бол.
Би сайт дээрээ сайн хяналт тавьдаг бөгөөд бүтэлгүйтлийн тухай SMS ирдэг. Хяналт шалгалтаар 13:03:07-14:04:12 цагийн хооронд гэмтэл гарсан байна. Туршилтыг таван минут тутамд хийдэг.
Та үүнийг ойлгоно гэдэгт итгэлтэй байна. Та Европт өөрийн хүн хэрэггүй гэдэгт итгэлтэй байна уу? 🙂
Тэгээд тэр хариулав:
Эх сурвалж: Мэттью Принс
Огноо: 7 оны 2010-р сарын 9, 57:XNUMX
Сэдэв: Re: Миний DNS хаана байна?
Хэнд: Жон Грэм-КамингБаярлалаа. Бид бичсэн бүх хүнд хариу өгсөн. Би одоо оффис руугаа явж байна, бид блог дээр ямар нэг зүйл бичих эсвэл мэдээллийн самбартаа албан ёсны бичлэг хийх болно. Би бүрэн санал нийлж байна, шударга байдал бол бүх зүйл юм.
Одоо Cloudflare бол үнэхээр том компани, би түүний төлөө ажилладаг, одоо би алдаа, түүний үр дагавар, бидний үйлдлийн талаар илэн далангүй бичих ёстой.
2-р сарын XNUMX-ны үйл явдал
2-р сарын XNUMX-нд бид WAF-ийн удирддаг дүрэмд шинэ дүрмийг гаргасан Дэлхий даяарх Cloudflare сүлжээнд HTTP/HTTPS траффик боловсруулдаг процессор бүр дээр. Бид шинэ эмзэг байдал, аюул заналхийллийн хариуд WAF-ийн удирддаг дүрмийг байнга сайжруулж байна. Жишээлбэл, тавдугаар сард бид яаравчлав SharePoint дахь ноцтой эмзэг байдлаас хамгаалах. Манай WAF-ийн гол санаа бол дүрмийг хурдан бөгөөд дэлхий даяар нэвтрүүлэх чадвар юм.
Харамсалтай нь өнгөрсөн пүрэв гаригийн шинэчлэлт нь буцаахдаа хэт их HTTP/HTTPS CPU-ийн нөөцийг дэмий үрсэн тогтмол илэрхийлэл агуулж байна. Үүний үр дүнд манай үндсэн прокси, CDN болон WAF функцууд эвдэрсэн. Графикаас харахад HTTP/HTTPS урсгалд үйлчлэх процессорын нөөц манай сүлжээн дэх серверүүд дээр бараг 100% хүрдэг.
Ослын үед нэг цэг дээр CPU-ийн хэрэглээ
Үүний үр дүнд манай үйлчлүүлэгчид (мөн манай үйлчлүүлэгчдийн үйлчлүүлэгчид) Cloudflare домэйн дээр 502 алдаатай хуудастай болсон. Үнэгүй цөмтэй байсан ч HTTP/HTTPS урсгалыг зохицуулдаг процессуудтай холбогдох боломжгүй байсан Cloudflare урд талын вэб серверүүд 502 алдаа гаргасан.
Энэ нь үйлчлүүлэгчдэдээ ямар их төвөг учруулсныг бид мэднэ. Бид маш их ичиж байна. Энэхүү бүтэлгүйтэл нь биднийг үйл явдлыг үр дүнтэй шийдвэрлэхэд саад болсон.
Хэрэв та эдгээр үйлчлүүлэгчдийн нэг байсан бол айж, уурлаж, бухимдаж байсан байх. Түүгээр ч барахгүй бидэнд ийм зүйл байгаагүй . CPU-ийн өндөр зарцуулалт нь буруу үг хэллэгтэй тогтмол илэрхийлэл бүхий нэг WAF дүрмээс шалтгаалж, хэт их ухрахад хүргэсэн. Энд гэм буруугийн илэрхийлэл байна: (?:(?:"|'|]|}||d|(?:nan|infinity|true|false|null|undefined|symbol|math)|`|-|+)+[)]*;?((?:s|-|~|!|{}||||+)*.*(?:.*=.*)))
Хэдийгээр энэ нь өөрөө сонирхолтой боловч (мөн би энэ талаар доор дэлгэрэнгүй ярих болно) Cloudflare үйлчилгээ зөвхөн ердийн илэрхийлэл муутайгаас болж 27 минутын турш зогссон. Бүтэлгүйтэлд хүргэсэн үйл явдлын дарааллыг тайлбарлахад багагүй хугацаа шаардагдах тул бид хариу өгөхдөө удаан байсан. Бичлэгийн төгсгөлд би ухрах явдлыг ердийн хэллэгээр тайлбарлаж, үүнийг юу хийхийг танд хэлэх болно.
Юу болов
Дарааллаар нь эхэлцгээе. Энд байгаа бүх цаг UTC байна.
13:42 цагт галт ханын багийн инженер илрүүлэх дүрэмд бага зэрэг өөрчлөлт оруулсан. автомат процесс ашиглан. Үүний дагуу өөрчлөлтийн хүсэлтийн тасалбар үүсгэгдсэн. Бид ийм тасалбарыг Жирагаар удирддаг (доорх дэлгэцийн зураг).
3 минутын дараа WAF-тай холбоотой асуудлыг мэдээлсэн PagerDuty-ийн эхний хуудас гарч ирэв. Энэ нь Cloudflare-ээс гадуур WAF-ийн (бидэнд олон зуун байдаг) хэвийн ажиллагааг хянахын тулд нийлэг туршилт байсан. Үүний дараа Cloudflare-ийн бусад үйлчилгээний туршилтууд амжилтгүй болсон, дэлхийн замын хөдөлгөөний асуудал, өргөн тархсан 502 алдаа, дэлхийн хотууд дахь манай Байлцах цэгүүдээс (PoP) олон тооны тайлангууд дутмаг байгааг илтгэсэн хуудаснууд гарч ирэв. CPU-ийн нөөц.
Би эдгээр сэрэмжлүүлгийн хэд хэдэн удаа хүлээн авч, уулзалтаас гараад ширээ рүүгээ явж байтал манай шийдэл боловсруулах хэлтсийн дарга бид замын хөдөлгөөний 80%-ийг алдсан гэж хэлсэн. Би асуудал дээр ажиллаж байсан манай SRE инженерүүд рүү гүйв. Бид эхлээд ямар нэгэн үл мэдэгдэх халдлага гэж бодсон.
Cloudflare SRE инженерүүд дэлхийн өнцөг булан бүрт тархаж, нөхцөл байдлыг цаг наргүй хянаж байдаг. Ерөнхийдөө эдгээр сэрэмжлүүлэг нь хязгаарлагдмал хамрах хүрээтэй орон нутгийн тодорхой асуудлын талаар танд мэдэгддэг бөгөөд дотоод хяналтын самбар дээр хянагддаг бөгөөд өдөрт хэд хэдэн удаа шийдэгддэг. Гэвч эдгээр хуудас болон мэдэгдлүүд нь үнэхээр ноцтой зүйлийг илтгэж байсан тул SRE инженерүүд P0 зэрэглэлийг даруй зарлаж, удирдлага болон системийн инженерүүдтэй холбоо барив.
Энэ үед манай Лондонгийн инженерүүд төв танхимд лекц сонсож байв. Лекцийг таслах шаардлагатай болж, бүгд том хурлын танхимд цугларч, нэмэлт мэргэжилтнүүдийг дуудсан. Энэ нь SRE-ийн өөрсдөө шийдэж чадах ердийн асуудал биш байв. Яаралтай зөв мэргэжилтнүүдийг татан оролцуулах хэрэгтэй байв.
14:00 цагт бид асуудал WAF-тай холбоотой болохыг тогтоосон бөгөөд ямар ч халдлага байхгүй. Гүйцэтгэлийн баг CPU-ийн өгөгдлийг гаргаж авсан бөгөөд WAF буруутай болох нь тодорхой болов. Өөр нэг ажилтан энэ онолыг strace ашиглан баталжээ. WAF-тай холбоотой асуудал байгааг өөр хэн нэгэн бүртгэлээс харсан. 14:02 цагт Cloudflare-д суурилуулсан, дэлхий даяар нэг бүрэлдэхүүн хэсгийг хаадаг global kill-ийг ашиглахыг санал болгоход бүх баг над дээр ирсэн.
Бид WAF-ийн төлөө дэлхийн хэмжээнд хэрхэн хөнөөсөн нь өөр түүх юм. Энэ нь тийм ч энгийн зүйл биш юм. Бид өөрсдийн бүтээгдэхүүнээ ашигладаг бөгөөд бидний үйлчилгээнээс хойш ажиллахгүй, бид дотоод хяналтын самбар руу нэвтрэн орж баталгаажуулж чадсангүй (бүх зүйл засагдсан үед дотоод хяналтын самбарыг ашиглахгүй бол итгэмжлэлийг идэвхгүй болгодог хамгаалалтын функцийн улмаас багийн зарим гишүүд нэвтрэх боломжгүй болсныг бид мэдсэн. удаан хугацаагаар).
Мөн бид Jira эсвэл бүтээх систем гэх мэт дотоод үйлчилгээндээ хүрч чадаагүй. Бидэнд ховор ашигладаг тойрон гарах механизм хэрэгтэй байсан (үүнийг бас боловсруулах шаардлагатай болно). Эцэст нь нэг инженер 14:07 цагт WAF-ыг идэвхгүй болгож чадсан бөгөөд 14:09 цагт замын хөдөлгөөн болон CPU-ийн түвшин хаа сайгүй хэвийн байдалдаа орсон. Cloudflare-ийн бусад хамгаалалтын механизмууд хэвийн ажиллаж байсан.
Дараа нь бид WAF-ийг сэргээх ажлыг эхлүүлэв. Нөхцөл байдал ер бусын байсан тул бид нэг хотод сөрөг туршилт (өөрчлөлт үнэхээр асуудал байгаа эсэхийг өөрөөсөө асууж) болон эерэг сорилтуудыг (буцах ажиллагаа амжилттай болсон эсэхийг шалгах) тус тусад нь замын хөдөлгөөнийг ашиглан, тэндээс төлбөр төлдөг үйлчлүүлэгчдийг шилжүүлсэн.
14:52 цагт бид учрыг нь ойлгож залруулга хийсэн гэдэгтээ итгэлтэй болж, WAF-г дахин идэвхжүүлсэн.
Cloudflare хэрхэн ажилладаг
Cloudflare нь WAF-ийн дүрмийг удирдахад зориулагдсан инженерүүдийн багтай. Тэд илрүүлэлтийн түвшинг дээшлүүлж, хуурамч эерэг үр дүнг бууруулж, шинэ аюул заналхийлэхэд хурдан хариу арга хэмжээ авахыг эрмэлздэг. Сүүлийн 60 хоногт WAF-н удирддаг дүрмийн өөрчлөлтийн 476 хүсэлтийг (дунджаар 3 цаг тутамд нэг) боловсруулсан байна.
Энэхүү тодорхой өөрчлөлтийг симуляцийн горимд байрлуулах шаардлагатай байсан бөгөөд үүнд үйлчлүүлэгчийн бодит урсгал дүрмээр дамждаг боловч юу ч хаагдсангүй. Бид энэ горимыг дүрмийн үр нөлөөг шалгах, хуурамч эерэг ба хуурамч сөрөг хувь хэмжээг хэмжихэд ашигладаг. Гэхдээ симуляцийн горимд ч гэсэн дүрмүүд нь бодитоор хэрэгжих ёстой бөгөөд энэ тохиолдолд дүрэм нь процессорын хэт их нөөцийг зарцуулсан тогтмол илэрхийлэл агуулж байсан.
Дээрх өөрчлөлтийн хүсэлтээс харж байгаагаар, бидэнд байршуулах төлөвлөгөө, буцаах төлөвлөгөө болон энэ төрлийн байршуулалтын дотоод стандарт үйлдлийн журам (SOP)-ын холбоос байгаа. Дүрмийг өөрчлөх SOP нь үүнийг дэлхий даяар нийтлэх боломжийг олгодог. Үнэн хэрэгтээ Cloudflare-д бүх зүйл огт өөрөөр хийгддэг бөгөөд SOP нь эхлээд бид программ хангамжийг турших, дотоод хэрэгцээнд зориулан дотоод орших цэг (PoP) (манай ажилчдын ашигладаг), дараа нь цөөн тооны үйлчлүүлэгчдэд хүргэхийг шаарддаг. тусгаарлагдсан байршил, дараа нь олон тооны үйлчлүүлэгчид, зөвхөн дараа нь дэлхий даяар.
Энэ нь иймэрхүү харагдаж байна. Бид BitBucket-ээр дамжуулан git-г дотооддоо ашигладаг. Өөрчлөлт дээр ажиллаж буй инженерүүд TeamCity-д бүтээгдсэн кодыг илгээдэг бөгөөд уг бүтээц дуусахад хянагчдыг томилдог. Татаж авах хүсэлтийг зөвшөөрсний дараа кодыг угсарч, хэд хэдэн туршилтыг явуулдаг (дахин).
Хэрэв угсралт болон туршилтууд амжилттай дуусвал Jira-д өөрчлөлтийн хүсэлтийг үүсгэх бөгөөд зохих менежер эсвэл удирдагч өөрчлөлтийг зөвшөөрөх ёстой. Зөвшөөрөл авсны дараа "PoP menagerie" гэж нэрлэгддэг НОХОЙ, ГАХАЙ болон (нохой, гахай, канар).
DOG PoP нь Cloudflare PoP (манай бусад хотуудын нэгэн адил) бөгөөд зөвхөн Cloudflare-ийн ажилчид ашигладаг. Дотоод хэрэглээнд зориулсан PoP нь үйлчлүүлэгчийн урсгал шийдэл рүү урсаж эхлэхээс өмнө асуудлыг шийдвэрлэх боломжийг танд олгоно. Хэрэгтэй зүйл.
Хэрэв DOG тест амжилттай бол код нь PIG (Гвиней гахай) шат руу шилждэг. Энэ бол Cloudflare PoP бөгөөд бага хэмжээний үнэгүй хэрэглэгчийн урсгал шинэ кодоор дамждаг.
Хэрэв бүх зүйл сайн байвал код Канар руу орно. Бид дэлхийн янз бүрийн хэсэгт гурван Канар ПоП-той. Тэдгээрийн дотор төлбөртэй болон үнэ төлбөргүй үйлчлүүлэгчдийн урсгал шинэ кодоор дамждаг бөгөөд энэ нь алдааны сүүлчийн шалгалт юм.
Cloudflare дээр програм хангамжийг гаргах үйл явц
Хэрэв Канарын код нь зүгээр бол бид үүнийг гаргадаг. НОХОЙ, ГАХАЙ, Канар, дэлхийн бүх үе шатыг давах нь кодын өөрчлөлтөөс хамааран хэдэн цаг эсвэл өдөр шаардагдана. Cloudflare-ийн сүлжээ болон үйлчлүүлэгчид олон янз байдаг тул бид кодыг бүх үйлчлүүлэгчдэдээ дэлхий даяар гаргахаасаа өмнө сайтар шалгадаг. Гэхдээ аюул заналхийлэлд хурдан хариу өгөх шаардлагатай тул WAF энэ үйл явцыг тусгайлан дагаж мөрддөггүй.
WAF-ийн аюул занал
Сүүлийн хэдэн жилийн хугацаанд нийтлэг хэрэглээнд аюул заналхийлэх нь мэдэгдэхүйц нэмэгдсэн. Энэ нь програм хангамжийн туршилтын хэрэгслүүдийн хүртээмж өндөртэй холбоотой юм. Жишээлбэл, бид саяхан бичсэн ).
Эх сурвалж:
Ихэнх тохиолдолд концепцийн нотолгоог Github дээр нэн даруй гаргаж, нийтэлдэг бөгөөд ингэснээр програмыг ажиллуулж буй багууд үүнийг хурдан шалгаж, зохих ёсоор хамгаалагдсан эсэхийг баталгаажуулах болно. Тиймээс Cloudflare нь шинэ халдлагад аль болох хурдан хариу өгөх чадвартай байх шаардлагатай бөгөөд ингэснээр хэрэглэгчид программ хангамжаа засах боломжтой болно.
Cloudflare-ийн шуурхай хариу арга хэмжээний гайхалтай жишээ бол XNUMX-р сард SharePoint-ийн эмзэг байдлын хамгаалалтыг нэвтрүүлсэн явдал юм (). Мэдэгдэл гарсны дараа бараг тэр даруй бид үйлчлүүлэгчдийнхээ SharePoint суулгацын эмзэг байдлыг ашиглах оролдлогыг анзаарсан. Манай залуус үйлчлүүлэгчдээ хамгаалахын тулд шинэ аюул заналхийллийг байнга хянаж, дүрэм бичдэг.
Пүрэв гарагт асуудал үүсгэсэн дүрэм нь сайт хоорондын скриптээс (XSS) хамгаалах ёстой байв. Сүүлийн жилүүдэд ийм халдлага ч их гарах болсон.
Эх сурвалж:
WAF-ийн удирддаг дүрмийг өөрчлөх стандарт журам нь дэлхий даяар байршуулахаас өмнө тасралтгүй интеграцийн (CI) туршилт хийх явдал юм. Өнгөрсөн пүрэв гарагт бид үүнийг хийж, дүрмийг гаргасан. 13:31 цагт инженер нь өөрчлөлт оруулах зөвшөөрөлтэй татах хүсэлтийг ирүүлсэн.
13:37 цагт TeamCity дүрмээ цуглуулж, туршилт хийж, зөвшөөрлөө. WAF тестийн иж бүрдэл нь WAF-ийн үндсэн функцийг шалгадаг бөгөөд бие даасан функцүүдэд зориулсан олон тооны нэгж тестүүдээс бүрддэг. Нэгжийн туршилтын дараа бид маш олон тооны HTTP хүсэлтийг ашиглан WAF-ийн дүрмийг туршиж үзсэн. HTTP хүсэлтүүд нь WAF ямар хүсэлтийг хаах (халдлагыг таслан зогсоохын тулд) болон аль нь дамжуулж болохыг (бүх зүйлийг хааж, худал эерэгээс зайлсхийхийн тулд) шалгадаг. Гэхдээ бид CPU-ийн хэт их хэрэглээг туршиж үзээгүй бөгөөд өмнөх WAF-ийн бүтээцийн бүртгэлийг судалж үзэхэд дүрмийн туршилтын гүйцэтгэлийн хугацаа нэмэгдээгүй бөгөөд хангалттай нөөц байхгүй гэж сэжиглэхэд хэцүү байсан.
Туршилтууд амжилттай болж, TeamCity 13:42 цагт өөрчлөлтийг автоматаар байрлуулж эхлэв.
Quicksilver
WAF дүрмүүд нь аюул заналхийллийг яаралтай арилгахад чиглэдэг тул бид өөрчлөлтийг секундын дотор дэлхий даяар түгээдэг Quicksilver-ийн түгээсэн түлхүүр утгын дэлгүүрийг ашиглан тэдгээрийг байршуулдаг. Манай бүх үйлчлүүлэгчид хяналтын самбар эсвэл API-ээр дамжуулан тохиргоог өөрчлөхдөө энэ технологийг ашигладаг бөгөөд үүний ачаар бид өөрчлөлтөд аянгын хурдтайгаар хариу үйлдэл үзүүлдэг.
Бид Quicksilver-ийн талаар нэг их яриагүй. Өмнө нь бид ашигладаг байсан Дэлхий даяар тархсан гол үнэ цэнийн дэлгүүр байсан ч үйл ажиллагааны асуудалтай тулгарсан тул бид өөрсдийн дэлгүүрээ бичиж, 180 гаруй хотод хуулбарласан. Одоо бид Quicksilver программыг тохиргооны өөрчлөлтийг үйлчлүүлэгчдэд хүргэх, WAF дүрмийг шинэчлэх, үйлчлүүлэгчдийн бичсэн JavaScript кодыг Cloudflare Workers-д түгээх зорилгоор ашигладаг.
Хяналтын самбар дээрх товчлуур дээр дарах эсвэл API руу залгахад дэлхий даяар тохиргооны өөрчлөлт хийхэд хэдхэн секунд зарцуулагдана. Үйлчлүүлэгчид энэ хурдыг тохируулах дуртай байсан. Мөн Ажилчид нь дэлхийн программ хангамжийг бараг агшин зуурт байршуулах боломжийг олгодог. Дунджаар Quicksilver нь секундэд 350 орчим өөрчлөлтийг тараадаг.
Мөн Quicksilver маш хурдан. Дэлхий даяарх бүх компьютерт өөрчлөлтийг түгээхийн тулд бид дунджаар 99 секундын 2,29 дэх хувийг гүйцэтгэсэн. Хурд бол ихэвчлэн сайн зүйл юм. Эцсийн эцэст, та функцийг идэвхжүүлэх эсвэл кэшийг цэвэрлэх үед энэ нь бараг тэр даруй, хаа сайгүй тохиолддог. Cloudflare Workers-ээр дамжуулан код илгээх нь ижил хурдтай явагддаг. Cloudflare нь хэрэглэгчиддээ зөв цагт хурдан шинэчлэлтүүдийг амлаж байна.
Гэхдээ энэ тохиолдолд хурд нь биднийг харгис хэрцгий хошигнол болгож, дүрэм журам нь хэдхэн секундын дотор хаа сайгүй өөрчлөгдсөн. WAF код нь Lua-г ашигладаг болохыг та анзаарсан байх. Cloudflare нь Lua-г үйлдвэрлэл, дэлгэрэнгүй мэдээлэлд өргөн ашигладаг бид байна . Луа WAF ашигладаг дотооддоо болон тааруулахын тулд буцаах арга хэрэглэдэг. Энэ нь хяналтаас гарах илэрхийллээс хамгаалах механизмгүй. Доор би энэ талаар болон бид юу хийж байгаа талаар дэлгэрэнгүй ярих болно.
Дүрмүүдийг хэрэгжүүлэхээс өмнө бүх зүйл жигд явагдсан: татах хүсэлтийг үүсгэж, зөвшөөрсөн, CI/CD дамжуулах хоолой нь кодыг цуглуулж, туршсан, өөрчлөлтийн хүсэлтийг байршуулалт, буцаалтыг зохицуулдаг SOP-ийн дагуу илгээж, байршуулалт дууссан.
Cloudflare WAF байршуулах үйл явц
Ямар нэгэн зүйл буруугаар эргэсэн
Миний хэлсэнчлэн бид долоо хоног бүр олон арван шинэ WAF дүрмийг нэвтрүүлдэг бөгөөд ийм байршуулалтын сөрөг үр дагавраас хамгаалах олон систем бий. Ямар нэг зүйл буруу болвол энэ нь ихэвчлэн хэд хэдэн нөхцөл байдлын нэг дор нийлдэг. Хэрэв та ганцхан шалтгааныг олж харвал энэ нь мэдээжийн хэрэг тайвшруулах болно, гэхдээ энэ нь үргэлж үнэн байдаггүй. Эдгээр нь нийлээд манай HTTP/HTTPS үйлчилгээний доголдолд хүргэсэн шалтгаанууд юм.
- Инженер хэт их үр дүнд хүргэж болзошгүй тогтмол илэрхийлэл бичсэн .
- Тогтмол илэрхийлэл нь CPU-ийг хэт их үрэхээс сэргийлж чадах функцийг хэдэн долоо хоногийн өмнө WAF-ийн рефакторинг хийхдээ андуурч устгасан—WAF-г бага нөөц зарцуулахын тулд дахин засварлах шаардлагатай байсан.
- Тогтмол илэрхийллийн хөдөлгүүр нь нарийн төвөгтэй байдлын баталгаагүй байв.
- Туршилтын багц нь CPU-ийн хэт их хэрэглээг илрүүлж чадсангүй.
- SOP нь яаралтай бус дүрмийн өөрчлөлтийг олон шатлалт үйл явцгүйгээр дэлхий даяар нэвтрүүлэх боломжийг олгодог.
- Буцах төлөвлөгөөнд WAF-ийн бүрэн бүтээцийг хоёр удаа ажиллуулах шаардлагатай байсан бөгөөд үүнд удаан хугацаа зарцуулагдсан.
- Дэлхийн замын хөдөлгөөний асуудлын талаарх анхны сэрэмжлүүлэг хэтэрхий оройтсон.
- Бид статусын хуудсыг шинэчлэхэд багагүй хугацаа зарцуулсан.
- Бид алдааны улмаас системд хандахад асуудалтай байсан бөгөөд тойрч гарах журам сайн тогтоогдоогүй байна.
- SRE инженерүүд аюулгүй байдлын шалтгааны улмаас итгэмжлэлийн хугацаа дууссан тул зарим системд хандах эрхээ алдсан.
- Манай үйлчлүүлэгчид Cloudflare бүсээр дамждаг тул Cloudflare хяналтын самбар эсвэл API-д хандах боломжгүй байсан.
Өнгөрсөн пүрэв гарагаас хойш юу өөрчлөгдсөн бэ
Нэгдүгээрт, бид WAF-д зориулсан хувилбаруудын бүх ажлыг бүрэн зогсоож, дараахь зүйлийг хийж байна.
- Бид устгасан CPU-ийн хэт ашиглалтын хамгаалалтыг дахин нэвтрүүлж байна. (Бэлэн)
- WAF-ийн удирдаж буй дүрмийн бүх 3868 дүрмийг гараар шалгаж, хэт их ухарсан бусад тохиолдлуудыг олж, засч залруулах болно. (Баталгаажуулалт дууссан)
- Бид туршилтын багц дахь бүх дүрмийн гүйцэтгэлийн профайлыг оруулсан болно. (Хүлээгдэж буй: 19-р сарын XNUMX)
- Тогтмол илэрхийлэлийн хөдөлгүүр рүү шилжих буюу - хоёулаа ажиллах хугацааны баталгаа өгдөг. (Хүлээгдэж буй: 31-р сарын XNUMX)
- Бид Cloudflare-ийн бусад программ хангамжийн нэгэн адил дүрмийг үе шаттайгаар нэвтрүүлэхийн тулд SOP-ийг дахин бичиж байгаа боловч нэгэн зэрэг халдлага эхэлсэн бол яаралтай дэлхийн хэмжээнд байршуулах боломжтой.
- Бид Cloudflare-ийн хяналтын самбар болон API-г Cloudflare бүсээс яаралтай устгах чадварыг хөгжүүлж байна.
- Хуудасны шинэчлэлтийг автоматжуулах .
Удаан хугацааны туршид бид хэдэн жилийн өмнө бичсэн Луа WAF-аас холдож байна. WAF руу зөөж байна . Ингэснээр WAF илүү хурдан болж, нэмэлт хамгаалалт авах болно.
дүгнэлт
Энэхүү бүтэлгүйтэл нь бидэнд болон манай үйлчлүүлэгчдэд хүндрэл учруулсан. Бид нөхцөл байдлыг засч залруулахын тулд шуурхай ажиллаж, ослыг үүсгэсэн үйл явцын алдаанууд дээр ажиллаж, ирээдүйд шинэ технологид шилжих үед байнгын илэрхийлэлд гарч болзошгүй асуудлаас урьдчилан сэргийлэхийн тулд бүр гүнзгийрүүлэн ухаж байна.
Бид энэ тасалдалд маш их ичиж байгаа бөгөөд үйлчлүүлэгчдээсээ хүлцэл өчье. Эдгээр өөрчлөлтүүд нь ийм зүйл дахин давтагдахгүй байх баталгаа болно гэж найдаж байна.
Өргөдөл. Тогтмол хэллэгийг буцаах
Хэрхэн илэрхийлэгдэхийг ойлгохын тулд:
(?:(?:"|'|]|}||d
(?:nan|infinity|true|false|null|undefined|symbol|math)|`|-
|+)+[)]*;?((?:s|-|~|!|{}||||+)*.*(?:.*=.*)))CPU-ийн бүх нөөцийг идэж дууссаны дараа та ердийн илэрхийллийн хөдөлгүүр хэрхэн ажилладаг талаар бага зэрэг мэдэх хэрэгтэй. Энд байгаа асуудал бол загвар юм .*(?:.*=.*). (?: болон харгалзах ) нь барьж авдаггүй бүлэг юм (өөрөөр хэлбэл, хаалтанд байгаа илэрхийлэлийг нэг илэрхийлэл болгон бүлэглэсэн).
CPU-ийн хэт их хэрэглээний нөхцөлд энэ хэв маягийг дараах байдлаар тодорхойлж болно .*.*=.*. Энэ хэлбэрээр загвар нь шаардлагагүй төвөгтэй харагдаж байна. Гэхдээ илүү чухал зүйл бол бодит ертөнцөд хөдөлгүүрээс фрагмент болон өөр фрагментийг тааруулахыг шаарддаг илэрхийллүүд (WAF дүрмүүдийн нарийн төвөгтэй илэрхийллүүд гэх мэт) нь сүйрлийн ухралтанд хүргэдэг. Тийм учраас л.
Тогтмол хэллэгээр . Та нэг дүртэй таарах хэрэгтэй гэсэн үг, .* - тэг буюу түүнээс дээш тэмдэгтийг "шунаж" тааруулах, өөрөөр хэлбэл хамгийн их тэмдэгтийг авах, ингэснээр .*.*=.* тэг буюу түүнээс дээш тэмдэгттэй таарч, тэг ба түүнээс дээш тэмдэгттэй таарч, literal = тэмдэгтийг ол, тэг ба түүнээс дээш тэмдэгттэй тохирно гэсэн үг.
Туршилтын шугамыг авч үзье x=x. Энэ нь илэрхийлэлтэй тохирч байна .*.*=.*. .*.* тэнцүү тэмдэг эхнийхтэй таарахаас өмнө x (бүлэгүүдийн нэг .* харгалзана x, хоёр дахь нь - тэг тэмдэгт). .* дараа = хамгийн сүүлд таарч байна x.
Энэ харьцуулалтад 23 алхам шаардлагатай. Эхний бүлэг .* в .*.*=.* шуналтай үйлдэл хийж, бүхэл утсанд таарч байна x=x. Хөдөлгүүр нь дараагийн бүлэгт шилждэг .*. Бидэнд тохирох дүр байхгүй тул хоёрдугаар бүлэг .* тэг тэмдэгттэй таарч байна (үүнийг зөвшөөрнө). Дараа нь хөдөлгүүр нь тэмдэг рүү шилждэг =. Өөр ямар ч тэмдэг байхгүй (эхний бүлэг .* илэрхийллийг бүхэлд нь ашигласан x=x), харьцуулалт байхгүй.
Дараа нь ердийн илэрхийллийн хөдөлгүүр эхэндээ буцаж ирдэг. Тэр эхний бүлэгт шилждэг .* мөн харьцуулдаг с x= (оронд нь x=x), дараа нь хоёрдугаар бүлгийг авна .*. Хоёрдугаар бүлэг .* хоёр дахьтой харьцуулж үздэг x, мөн бидэнд дахин нэг ч дүр үлдсэнгүй. Мөн хөдөлгүүр дахин ирэхэд = в .*.*=.*, юу ч ажиллахгүй. Тэгээд тэр дахин ухарсан.
Энэ удаад бүлэг .* таарсан хэвээр байна x=, гэхдээ хоёр дахь бүлэг .* дахиж байхгүй x, мөн тэг тэмдэгт. Хөдөлгүүр нь үгийн дүрийг олохыг оролдож байна = загварт .*.*=.*, гэхдээ гарч ирэхгүй байна (эцсийн эцэст эхний бүлэг үүнийг аль хэдийн эзэлжээ .*). Тэгээд тэр дахин ухарсан.
Энэ удаад эхний бүлэг .* зөвхөн эхний х-г авна. Гэхдээ хоёр дахь бүлэг .* "шуналтайгаар" барьж авдаг =x. Юу болохыг та аль хэдийн таамаглаж байсан уу? Хөдөлгүүр нь үгийн утганд яг тохирч байхыг хичээдэг =, бүтэлгүйтэж, өөр ухралт хийдэг.
Нэгдүгээр бүлэг .* эхнийхтэй нь таарсан хэвээр байна x... Хоёрдугаарт .* зөвхөн авдаг =. Мэдээжийн хэрэг, хөдөлгүүр нь шууд утгаараа таарахгүй =, учир нь хоёрдугаар бүлэг үүнийг аль хэдийн хийсэн .*. Бас дахин ухарсан. Мөн бид гурван тэмдэгтийн мөрийг тохируулахыг хичээж байна!
Үүний үр дүнд эхний бүлэг .* зөвхөн эхнийхтэй таарч байна x, хоёрдугаарт .* - тэг тэмдэгттэй, хөдөлгүүр нь эцэст нь үгийн утгатай тохирч байна = илэрхийлэлд с = шугаманд. Дараагийн бүлэг бол сүүлчийн бүлэг юм .* сүүлчийнхтэй харьцуулж үздэг x.
Зөвхөн 23 алхам x=x. Perl ашиглах тухай богино хэмжээний видеог үзээрэй , энэ нь алхмууд болон ухралт хэрхэн явагддагийг харуулдаг.
Энэ бол аль хэдийн маш их ажил, гэхдээ оронд нь яах вэ x=x бидэнд байх болно x=xx? Энэ нь 33 алхам юм. Тэгээд хэрэв x=xxx? 45. Харилцаа нь шугаман биш юм. График нь харьцуулалтыг харуулж байна x=x нь x=xxxxxxxxxxxxxxxxxxxx (20 x после =). Хэрэв бид дараа нь 20 удаа байвал =, хөдөлгүүр нь 555 алхмаар тааруулж дуусгадаг! (Үүнээс гадна хэрэв бид ялагдсан бол x= ба мөр нь ердөө 20-оос бүрдэнэ x, хөдөлгүүр нь тохирох зүйл байхгүй гэдгийг ойлгохын тулд 4067 алхам хийх болно).
Энэ видео нь харьцуулах зорилгоор бүх ухралтуудыг харуулж байна x=xxxxxxxxxxxxxxxxxxxx:
Асуудал нь мөрний хэмжээ ихсэх тусам тохирох хугацаа хэт шугаман ургадаг. Гэхдээ ердийн хэллэгийг бага зэрэг өөрчилсөн тохиолдолд байдал улам дордох болно. Бидэнд байсан гэж бодъё .*.*=.*; (өөрөөр хэлбэл загварын төгсгөлд цэг таслал байсан). Жишээ нь: гэх мэт илэрхийлэлтэй тааруулах foo=bar;.
Эндээс буцах нь жинхэнэ гамшиг болно. Харьцуулбал x=x Энэ нь 90 биш 23 алхам хийх болно. Мөн энэ тоо хурдан өсч байна. Харьцуулах x= болон 20 x, 5353 алхам шаардлагатай. Энд график байна. Тэнхлэгийн утгыг харна уу Y өмнөх графиктай харьцуулахад.
Хэрэв та сонирхож байгаа бол 5353 бүтэлгүйтсэн тохирох бүх алхмуудыг шалгана уу x=xxxxxxxxxxxxxxxxxxxx и .*.*=.*;
Шуналтай нийцүүлэхийн оронд залхууг ашигласнаар ухрах байдлыг хянах боломжтой. Хэрэв бид анхны илэрхийлэлийг өөрчилбөл .*?.*?=.*?, харьцуулахын тулд x=x Энэ нь 11 алхам хийх болно (23 биш). Хувьд x=xxxxxxxxxxxxxxxxxxxx. Бүгд учир нь ? после .* хөдөлгөхөөсөө өмнө хөдөлгүүрт хамгийн бага тэмдэгттэй таарахыг хэлдэг.
Гэхдээ залхуу зураглал нь ухрах асуудлыг бүрэн шийдэж чадахгүй. Хэрэв бид сүйрлийн жишээг орлуулах юм бол .*.*=.*; тухай .*?.*?=.*?;, гүйцэтгэлийн хугацаа хэвээр байх болно. x=x 555 алхам шаардлагатай хэвээр байна x= болон 20 x - 5353.
Хийж болох цорын ганц зүйл бол (илүү тодорхой болгохын тулд хэв маягийг бүрэн дахин бичихээс гадна) буцах механизмтай тогтмол илэрхийллийн хөдөлгүүрийг орхих явдал юм. Энэ бол бидний дараагийн хэдэн долоо хоногт хийх зүйл юм.
Энэ асуудлыг шийдэх гарцыг 1968 онд Кент Томпсон нийтлэл бичсэн цагаас хойш мэддэг болсон (“Програмчлалын аргууд: Тогтмол илэрхийллийн хайлтын алгоритм”). Уг нийтлэлд тогтмол илэрхийллийг тодорхой бус төгсгөлтэй төлөвт машин болгон хувиргах механизмыг тайлбарлах ба детерминистик бус төгсгөлтэй төлөвийн машинд төлөв өөрчлөгдсөний дараа гүйцэтгэх хугацаа нь тохирох мөрөөс шугаман хамааралтай алгоритмыг ашиглах болно.
Програмчлалын аргууд
Тогтмол илэрхийлэл хайлтын алгоритм
Кен Томпсон
Bell Telephone Laboratories, Inc., Murray Hill, New JerseyЭнэ нь текстээс тодорхой тэмдэгтүүдийг хайх аргыг тайлбарлаж, хөрвүүлэгч хэлбэрээр энэ аргыг хэрэгжүүлэх талаар авч үздэг. Хөрвүүлэгч нь ердийн илэрхийлэлийг эх код болгон авч IBM 7094 програмыг объект код болгон гаргадаг. Объект программ нь хайлтын текст хэлбэрээр оролт авч, текстийн мөрийг өгөгдсөн ердийн илэрхийлэлтэй тааруулах бүрт дохио өгдөг. Нийтлэлд жишээ, асуудал, шийдлүүдийг оруулсан болно.
Алгоритм
Хэсэгчилсэн амжилттай хайлт үр дүнд хүрч чадаагүй тохиолдолд өмнөх хайлтын алгоритмууд нь буцаахад хүргэдэг.Эмхэтгэлийн горимд алгоритм нь тэмдэгтүүдтэй ажиллахгүй. Энэ нь эмхэтгэсэн код руу зааврыг дамжуулдаг. Гүйцэтгэл нь маш хурдан байдаг - одоогийн жагсаалтын дээд хэсэгт өгөгдөл дамжуулсны дараа энэ нь ердийн илэрхийлэл дэх бүх боломжит дараалсан тэмдэгтүүдийг автоматаар хайдаг.
Эмхэтгэл ба хайлтын алгоритмыг цаг хуваалцах текст засварлагчийн контекст хайлт болгон оруулсан болно. Мэдээжийн хэрэг, энэ нь ийм хайлтын журмын цорын ганц хэрэглээнээс хол байна. Жишээлбэл, уг алгоритмын хувилбарыг ассемблер дээрх хүснэгтэд тэмдэгт хайлт болгон ашигладаг.
Уншигч энгийн хэллэгүүд болон IBM 7094 компьютерийн програмчлалын хэлийг мэддэг гэж үздэг.Хөрвүүлэгч
Хөрвүүлэгч нь зэрэгцээ ажилладаг гурван үе шатаас бүрдэнэ. Эхний үе шат бол синтакс шүүлтүүр бөгөөд зөвхөн синтаксийн хувьд зөв тогтмол хэллэгийг дамжин өнгөрөх боломжийг олгодог. Энэ алхам нь мөн тогтмол илэрхийлэлтэй тааруулахын тулд "·" операторыг оруулна. Хоёрдахь алхамд тогтмол илэрхийллийг postfix хэлбэрт шилжүүлнэ. Гурав дахь шатанд объектын кодыг үүсгэнэ. Эхний 2 үе шат нь тодорхой бөгөөд бид тэдгээрийн талаар ярихгүй.
Томпсоны өгүүлэлд тодорхой бус хязгаарлагдмал төлөвийн машинуудын тухай яриагүй ч шугаман цагийн алгоритмыг сайн тайлбарлаж, IBM 60-д зориулсан ассемблер хэлний кодыг үүсгэдэг ALGOL-7094 програмыг танилцуулж байна. Хэрэгжилт нь төвөгтэй боловч санаа нь маш энгийн.
одоогийн хайлтын зам. Энэ нь нэг оролт, хоёр гаралт бүхий ⊕ дүрсээр илэрхийлэгдэнэ.
Зураг 1-д ердийн илэрхийлэлийн жишээг хувиргах үед эмхэтгэлийн гурав дахь алхамын функцуудыг харуулав. Жишээн дээрх эхний гурван тэмдэгт нь a, b, c бөгөөд тус бүр нь стек оруулга S[i] болон NNODE талбарыг үүсгэдэг.Нэг стек оруулгад үүссэн тогтмол илэрхийллийг үүсгэхийн тулд одоо байгаа код руу NNODE (Зураг 5-ыг үзнэ үү)
Тогтмол илэрхийлэл иймэрхүү харагдах болно .*.*=.*, хэрэв та үүнийг Томпсоны нийтлэл дэх зургуудын адилаар төсөөлж байгаа бол.
Зураг дээр. 0 нь 0-ээс эхлэн таван төлөв, 3, 1, 2-р төлөвөөс эхэлдэг 3 мөчлөг байдаг. Эдгээр гурван мөчлөг нь XNUMX-тай тохирч байна. .* тогтмол хэллэгээр. Цэгтэй 3 зууван нь нэг тэмдэгттэй тохирч байна. Тэмдэгтэй зууван = үгийн тэмдэгттэй таарч байна =. 4-р муж эцсийнх. Хэрэв бид түүнд хүрвэл тогтмол илэрхийлэл таарч байна.
Ийм төлөвийн диаграммыг ердийн илэрхийлэлд нийцүүлэхэд хэрхэн ашиглаж болохыг харах .*.*=.*, бид мөрийн тохирлыг авч үзэх болно x=x. Зурагт үзүүлсэн шиг програм 0 төлөвөөс эхэлдэг. 1.
Энэ алгоритм ажиллахын тулд төрийн машин нэгэн зэрэг хэд хэдэн төлөвт байх ёстой. Тодорхой бус хязгаарлагдмал машин нь бүх боломжит шилжилтийг нэгэн зэрэг хийх болно.
Оролтын өгөгдлийг уншиж амжихаас өмнө зурагт үзүүлсэн шиг эхний хоёр төлөвт (1 ба 2) орно. 2.
Зураг дээр. 2-т тэр эхлээд харахад юу болдгийг харуулж байна x в x=x. x 1-р төлөвөөс 1-р төлөв рүү шилжих хамгийн дээд цэг рүү зураглаж болно. Эсвэл x 2-р төлөвөөс буцаад 2-р төлөв рүү шилжих доорх цэг рүү зураглаж болно.
Эхнийхтэй таарсаны дараа x в x=x Бид 1 ба 2-р төлөвт байсаар байна. Бид 3 эсвэл 4-р төлөвт хүрч чадахгүй, учир нь бидэнд шууд утга хэрэгтэй =.
Дараа нь алгоритм авч үзнэ = в x=x. Өмнөх x-ийн нэгэн адил үүнийг 1-ээс төлөв 1 хүртэл эсвэл 2-оос төлөв 2 хүртэл дээд хоёр гогцооны аль нэгтэй нь тааруулж болох боловч алгоритм нь шууд утгатай таарч болно. = ба 2-р төлөвөөс 3-т шилжих (мөн даруй 4). Үүнийг Зураг дээр үзүүлэв. 3.
Дараа нь алгоритм сүүлчийнх рүү шилжинэ x в x=x. 1 ба 2-р мужаас 1 ба 2-р муж руу ижил шилжилт хийх боломжтой. 3-р төлөвөөс x баруун талын цэгтэй таарч 3-р төлөв рүү буцаж болно.
Энэ үе шатанд дүр бүр x=x гэж үзсэн бөгөөд бид 4-р төлөвт хүрсэн тул тогтмол илэрхийлэл нь тэр мөрөнд таарч байна. Тэмдэгт бүрийг нэг удаа боловсруулдаг тул энэ алгоритм нь оролтын мөрийн уртад шугаман байна. Мөн ухрах зүйл байхгүй.
Мэдээжийн хэрэг, 4-р төлөвт хүрсний дараа (алгоритм тохирох үед x=) ердийн илэрхийлэл бүхэлдээ таарч, алгоритм нь үүнийг огт авч үзэхгүйгээр дуусгавар болж болно x.
Энэ алгоритм нь оролтын мөрийн хэмжээнээс шугаман хамааралтай.
Эх сурвалж: www.habr.com