Cloudflare-ის გათიშვის დეტალები 2 წლის 2019 ივლისს

თითქმის 9 წლის წინ Cloudflare იყო პატარა კომპანია და მე მასში არ ვმუშაობდი, მე მხოლოდ მომხმარებელი ვიყავი. Cloudflare-ის გაშვებიდან ერთი თვის შემდეგ მივიღე შეტყობინება, რომ ჩემი ვებსაიტი jgc.orgროგორც ჩანს, DNS არ მუშაობს. Cloudflare-მა შეიტანა ცვლილება პროტოკოლის ბუფერებიდა იყო გატეხილი DNS.

მე მაშინვე მივწერე მეთიუ პრინცს სათაურით "სად არის ჩემი DNS?" და მან გამომიგზავნა ტექნიკური დეტალებით სავსე გრძელი პასუხი (წაიკითხეთ მთელი კორესპონდენცია აქ), რაზეც მე ვუპასუხე:

ავტორი: ჯონ გრემ-კამინგი
თარიღი: 7 წლის 2010 ოქტომბერი, 9:14
თემა: Re: სად არის ჩემი DNS?
მიმართ: მეთიუ პრინცი

მაგარი ანგარიშია, მადლობა. თუ რამე პრობლემაა აუცილებლად დავრეკავ. ალბათ ღირს ამის შესახებ პოსტის დაწერა მას შემდეგ რაც შეაგროვებთ ყველა ტექნიკურ ინფორმაციას. ვფიქრობ, ხალხს ღია და გულწრფელი ამბავი მოეწონება. მით უმეტეს, თუ მას ანიჭებთ გრაფიკებს იმის საჩვენებლად, თუ როგორ გაიზარდა ტრაფიკი გაშვების შემდეგ.

ჩემს საიტზე კარგი მონიტორინგი მაქვს და ყოველი წარუმატებლობის შესახებ SMS-ს ვიღებ. მონიტორინგი აჩვენებს, რომ გაუმართაობა მოხდა 13:03:07 საათიდან 14:04:12 საათამდე. ტესტები ტარდება ყოველ ხუთ წუთში.

დარწმუნებული ვარ გაერკვევით. დარწმუნებული ხარ, რომ არ გჭირდება შენი საკუთარი პიროვნება ევროპაში? 🙂

და მან უპასუხა:

ავტორი: მეთიუ პრინცი
თარიღი: 7 წლის 2010 ოქტომბერი, 9:57
თემა: Re: სად არის ჩემი DNS?
მიმართ: ჯონ გრეჰემ-კამინგს

Გმადლობთ. ჩვენ ვუპასუხეთ ყველას, ვინც დაწერა. ახლა მივდივარ ოფისში და დავწერთ რაღაცას ბლოგზე ან დავამაგრებთ ოფიციალურ პოსტს ჩვენს ბიულეტენზე. გეთანხმები, პატიოსნება ყველაფერია.

ახლა Cloudflare მართლაც დიდი კომპანიაა, მე მასზე ვმუშაობ და ახლა ღიად უნდა დავწერო ჩვენი შეცდომის, მისი შედეგებისა და ჩვენი ქმედებების შესახებ.

2 ივლისის მოვლენები

2 ივლისს ჩვენ გამოვაქვეყნეთ ახალი წესი WAF-ების მართულ წესებში, რის გამოც CPU რესურსები იწურებოდა ყველა პროცესორის ბირთვზე, რომელიც ამუშავებს HTTP/HTTPS ტრაფიკს Cloudflare ქსელში მთელ მსოფლიოში. ჩვენ მუდმივად ვაუმჯობესებთ WAF-ების მართულ წესებს ახალი დაუცველობისა და საფრთხეების საპასუხოდ. მაისში, მაგალითად, ვიჩქარეთ წესის დამატებაSharePoint-ში სერიოზული დაუცველობისგან დასაცავად. ჩვენი WAF-ის მთელი აზრი არის წესების სწრაფად და გლობალურად განლაგების შესაძლებლობა.

სამწუხაროდ, გასული ხუთშაბათის განახლება შეიცავდა რეგულარულ გამონათქვამს, რომელიც ძალიან ბევრ HTTP/HTTPS CPU რესურსს ხარჯავდა უკან დაბრუნებაზე. შედეგად დაზარალდა ჩვენი ძირითადი პროქსი, CDN და WAF ფუნქციები. გრაფიკი გვიჩვენებს, რომ პროცესორის რესურსები HTTP/HTTPS ტრაფიკის მომსახურებისთვის ჩვენს ქსელში სერვერებზე თითქმის 100%-ს აღწევს.

პროცესორის გამოყენება ინციდენტის დროს ყოფნის ერთ წერტილში

შედეგად, ჩვენს კლიენტებს (და ჩვენი კლიენტების კლიენტებს) მიიღეს 502 შეცდომის გვერდი Cloudflare დომენებზე. 502 შეცდომა შეიქმნა Cloudflare-ის წინა ვებ სერვერების მიერ, რომლებსაც ჯერ კიდევ ჰქონდათ თავისუფალი ბირთვები, მაგრამ ვერ ახერხებდნენ კომუნიკაციას HTTP/HTTPS ტრაფიკის პროცესებთან.

ჩვენ ვიცით, რამხელა უხერხულობა გამოიწვია ამან ჩვენს მომხმარებლებს. საშინლად მრცხვენია. და ამ წარუმატებლობამ ხელი შეგვიშალა ინციდენტის ეფექტურად გამკლავებაში.

თუ თქვენ ერთ-ერთი ასეთი კლიენტი იყავით, ალბათ შეშინებული, გაბრაზებული და გაბრაზებული იყავით. უფრო მეტიც, ჩვენ არ გვქონია გლობალური შეფერხებები. CPU-ს მაღალი მოხმარება განპირობებული იყო WAF-ის ერთი წესით ცუდად ფორმულირებული რეგულარული გამოთქმით, რამაც გამოიწვია გადაჭარბებული უკან დაბრუნება. აი დამნაშავე გამოთქმა: (?:(?:"|'|]|}||d|(?:nan|infinity|true|false|null|undefined|symbol|math)|`|-|+)+[)]*;?((?:s|-|~|!|{}||||+)*.*(?:.*=.*)))

მიუხედავად იმისა, რომ ეს თავისთავად საინტერესოა (და ამაზე უფრო დეტალურად ქვემოთ ვისაუბრებ), Cloudflare სერვისი 27 წუთის განმავლობაში გათიშული იყო არა მხოლოდ ცუდი რეგულარული გამოხატვის გამო. დრო დაგვჭირდა იმ მოვლენების თანმიმდევრობის აღსაწერად, რამაც წარუმატებლობა გამოიწვია, ასე რომ, ჩვენ ვანელებდით პასუხს. პოსტის ბოლოს მე აღვწერ უკან დახევას ჩვეულებრივი გამოთქმით და გეტყვით რა უნდა გააკეთოთ მასთან.

რა მოხდა

დავიწყოთ თანმიმდევრობით. აქ ყველა დრო UTC-შია.

13:42 საათზე, Firewall-ის ჯგუფმა ინჟინერმა მცირე ცვლილება შეიტანა გამოვლენის წესებში. XSS ავტომატური პროცესის გამოყენებით. შესაბამისად, შეიქმნა ცვლილების მოთხოვნის ბილეთი. ჩვენ ვმართავთ ასეთ ბილეთებს Jira-ს მეშვეობით (სკრინშოტი ქვემოთ).

3 წუთის შემდეგ გამოჩნდა PagerDuty-ის პირველი გვერდი, სადაც მოხსენებულია WAF-ის პრობლემა. ეს იყო სინთეზური ტესტი, რომელიც ამოწმებს WAF-ების ფუნქციონირებას (ჩვენ გვაქვს ასობით მათგანი) Cloudflare-ის გარეთ ნორმალური მუშაობის მონიტორინგისთვის. ამას მაშინვე მოჰყვა შეტყობინებების გვერდები Cloudflare-ის სხვა ბოლოდან ბოლომდე სერვისის ტესტების წარუმატებლობის, გლობალური ტრაფიკის პრობლემების, ფართოდ გავრცელებული 502 შეცდომის შესახებ და უამრავი მოხსენება ჩვენი ყოფნის წერტილებიდან (PoP) მსოფლიოს ქალაქებში, რომლებიც მიუთითებდნენ ნაკლებობაზე. CPU რესურსები.

მე მივიღე რამდენიმე ასეთი გაფრთხილება, გამოვედი შეხვედრიდან და მივედი მაგიდისკენ, როდესაც ჩვენი გადაწყვეტილებების განვითარების განყოფილების ხელმძღვანელმა თქვა, რომ ჩვენ დავკარგეთ ჩვენი ტრაფიკის 80%. გავიქეცი ჩვენს SRE ინჟინრებთან, რომლებიც უკვე მუშაობდნენ პრობლემაზე. თავიდან გვეგონა, რომ ეს რაღაც უცნობი თავდასხმა იყო.

Cloudflare SRE ინჟინრები მიმოფანტულნი არიან მთელ მსოფლიოში და აკონტროლებენ სიტუაციას მთელი საათის განმავლობაში. როგორც წესი, ეს გაფრთხილებები შეგატყობინებთ შეზღუდული მოცულობის ადგილობრივ პრობლემებს, თვალყურს ადევნებთ შიდა დაფებზე და წყდება დღეში რამდენჯერმე. მაგრამ ეს გვერდები და შეტყობინებები მიუთითებდნენ რაღაც მართლაც სერიოზულზე და SRE ინჟინრებმა მაშინვე გამოაცხადეს სიმძიმის დონე P0 და დაუკავშირდნენ მენეჯმენტსა და სისტემის ინჟინრებს.

ჩვენი ლონდონელი ინჟინრები ამ დროს მთავარ დარბაზში უსმენდნენ ლექციას. ლექცია უნდა შეწყდეს, ყველა შეიკრიბა დიდ საკონფერენციო დარბაზში და გამოიძახეს მეტი სპეციალისტი. ეს არ იყო ტიპიური პრობლემა, რომელსაც SRE-ები თავად შეეძლოთ გაუმკლავდნენ. გადაუდებელი იყო შესაბამისი სპეციალისტების ჩართვა.

14:00 საათზე დავადგინეთ, რომ პრობლემა WAF-ში იყო და შეტევა არ ყოფილა. შესრულების გუნდმა ამოიღო CPU მონაცემები და გაირკვა, რომ WAF იყო დამნაშავე. კიდევ ერთმა თანამშრომელმა დაადასტურა ეს თეორია სტრაისის გამოყენებით. სხვამ დაინახა ჟურნალებში, რომ WAF-ის პრობლემა იყო. 14:02 საათზე მთელი გუნდი მოვიდა ჩემთან, როდესაც შემოგვთავაზეს გლობალური მკვლელობის გამოყენება, Cloudflare-ში ჩაშენებული მექანიზმი, რომელიც თიშავს ერთ კომპონენტს მთელ მსოფლიოში.

როგორ მოვახერხეთ გლობალური მკვლელობა WAF-ისთვის, სხვა ამბავია. ეს არც ისე მარტივია. ჩვენ ვიყენებთ საკუთარ პროდუქტებს და ჩვენი მომსახურებით ხელმისაწვდომობა არ მუშაობდა, ჩვენ ვერ მოვახერხეთ ავთენტიფიკაცია და შესვლა შიდა მართვის პანელში (როდესაც ყველაფერი გამოსწორდა, გავიგეთ, რომ გუნდის ზოგიერთმა წევრმა დაკარგა წვდომა უსაფრთხოების ფუნქციის გამო, რომელიც გათიშავს რწმუნებათა სიგელებს, თუ შიდა მართვის პანელი არ გამოიყენება დიდი დრო).

და ჩვენ ვერ მივაღწიეთ ჩვენს შიდა სერვისებს, როგორიცაა Jira ან build სისტემა. დაგვჭირდა გამოსავლის მექანიზმი, რომელსაც იშვიათად ვიყენებდით (ამას დამუშავებაც დასჭირდება). საბოლოოდ, ერთმა ინჟინერმა მოახერხა WAF-ის გამორთვა 14:07 საათზე და 14:09 საათზე ტრაფიკი და CPU დონე ყველგან ნორმალურად დაბრუნდა. Cloudflare-ის დანარჩენი დაცვის მექანიზმები ნორმალურად მუშაობდა.

შემდეგ ჩვენ შევუდექით WAF-ის აღდგენას. სიტუაცია არაჩვეულებრივი იყო, ამიტომ ჩვენ ჩავატარეთ უარყოფითი ტესტები (ვკითხეთ საკუთარ თავს, იყო თუ არა ცვლილება ნამდვილად პრობლემა) და დადებითი ტესტები (დარწმუნებული ვიყავით, რომ უკან დაბრუნება მუშაობდა) ერთ ქალაქში ცალკე ტრაფიკის გამოყენებით, იქიდან გადავიტანეთ გადამხდელი მომხმარებლები.

14:52-ზე დავრწმუნდით, რომ გავიგეთ მიზეზი და შევიტანეთ შესწორება და კვლავ გავააქტიურეთ WAF.

როგორ მუშაობს Cloudflare

Cloudflare-ს ჰყავს ინჟინრების გუნდი, რომელიც ეძღვნება WAF-ების წესების მართვას. ისინი ცდილობენ გააუმჯობესონ გამოვლენის მაჩვენებლები, შეამცირონ ცრუ დადებითი და სწრაფად უპასუხონ ახალ საფრთხეებს, როდესაც ისინი წარმოიქმნება. ბოლო 60 დღის განმავლობაში დამუშავდა 476 ცვლილება WAF-ის მართულ წესებზე (საშუალოდ ერთი ყოველ 3 საათში).

ამ კონკრეტულ ცვლილებას სჭირდებოდა განლაგება სიმულაციური რეჟიმში, სადაც კლიენტის რეალური ტრაფიკი გადის წესს, მაგრამ არაფერი იბლოკება. ჩვენ ვიყენებთ ამ რეჟიმს წესების ეფექტურობის შესამოწმებლად და ცრუ დადებითი და ცრუ უარყოფითი მაჩვენებლების გასაზომად. მაგრამ სიმულაციური რეჟიმშიც კი, წესები რეალურად უნდა შესრულდეს და ამ შემთხვევაში წესი შეიცავდა რეგულარულ გამოხატულებას, რომელიც მოიხმარდა პროცესორის ძალიან დიდ რესურსს.

როგორც ზემოთ მოყვანილი ცვლილების მოთხოვნიდან ხედავთ, ჩვენ გვაქვს განლაგების გეგმა, დაბრუნების გეგმა და ბმული შიდა სტანდარტის საოპერაციო პროცედურასთან (SOP) ამ ტიპის განლაგებისთვის. წესის შეცვლის SOP საშუალებას აძლევს მას გამოქვეყნდეს გლობალურად. სინამდვილეში, Cloudflare-ში ყველაფერი კეთდება სრულიად განსხვავებულად და SOP გვკარნახობს, რომ ჩვენ ჯერ პროგრამული უზრუნველყოფა გამოვგზავნოთ ტესტირებისა და შიდა გამოყენებისთვის შიდა ყოფნის წერტილში (PoP) (რომელსაც ჩვენი თანამშრომლები იყენებენ), შემდეგ კლიენტების მცირე რაოდენობას. იზოლირებულ ადგილას, შემდეგ კლიენტთა დიდი რაოდენობით და მხოლოდ ამის შემდეგ მთელ მსოფლიოში.

ასე გამოიყურება. ჩვენ ვიყენებთ git-ს შიდა BitBucket-ის საშუალებით. ინჟინრები, რომლებიც მუშაობენ ცვლილებებზე, წარადგენენ კოდს, რომელიც აგებულია TeamCity-ში და როდესაც build გაივლის, მიმომხილველებს ენიჭებათ. როდესაც pull მოთხოვნა დამტკიცდება, კოდი იკრიბება და ტესტების სერია ტარდება (ხელახლა).

თუ აწყობა და ტესტები წარმატებით დასრულდება, ცვლილების მოთხოვნა იქმნება Jira-ში და შესაბამისმა მენეჯერმა ან ლიდერმა უნდა დაამტკიცოს ცვლილება. დამტკიცების შემდეგ, განლაგება ხდება ეგრეთ წოდებულ „PoP მენაჟეაში“: DOG, PIG და კანარის (ძაღლი, ღორი და კანარი).

DOG PoP არის Cloudflare PoP (როგორც ჩვენი ყველა სხვა ქალაქი), რომელსაც იყენებენ მხოლოდ Cloudflare-ის თანამშრომლები. შიდა გამოყენებისთვის PoP საშუალებას გაძლევთ დაიჭიროთ პრობლემები მანამ, სანამ მომხმარებელთა ტრაფიკი გადაწყვეტაში დაიწყებს შემოდინებას. სასარგებლო რამ.

თუ DOG ტესტი წარმატებულია, კოდი გადადის PIG (გვინეა გოჭი) ეტაპზე. ეს არის Cloudflare PoP, სადაც მომხმარებელთა უფასო ტრაფიკის მცირე რაოდენობა მიედინება ახალი კოდის მეშვეობით.
თუ ყველაფერი კარგადაა, კოდი გადადის კანარში. ჩვენ გვაქვს სამი კანარის პოპ მსოფლიოს სხვადასხვა კუთხეში. მათში ფასიანი და უფასო კლიენტების ტრაფიკი გადის ახალ კოდს და ეს არის შეცდომების ბოლო შემოწმება.

პროგრამული უზრუნველყოფის გამოშვების პროცესი Cloudflare-ზე

თუ კოდი კანარში ნორმალურია, ჩვენ მას ვათავისუფლებთ. ყველა ეტაპის გავლას - DOG, PIG, Canary, მთელი მსოფლიო - რამდენიმე საათი ან დღე სჭირდება, კოდის შეცვლაზეა დამოკიდებული. Cloudflare-ის ქსელისა და კლიენტების მრავალფეროვნების გამო, ჩვენ საფუძვლიანად ვამოწმებთ კოდს, სანამ მას გლობალურად გამოვუშვებთ ყველა კლიენტისთვის. მაგრამ WAF კონკრეტულად არ მიჰყვება ამ პროცესს, რადგან საფრთხეებს სწრაფი რეაგირება სჭირდება.

WAF მუქარა
ბოლო რამდენიმე წლის განმავლობაში, საერთო აპლიკაციებში საფრთხეების მნიშვნელოვანი ზრდა იყო. ეს გამოწვეულია პროგრამული უზრუნველყოფის ტესტირების ხელსაწყოების უფრო დიდი ხელმისაწვდომობით. მაგალითად, ჩვენ ცოტა ხნის წინ დავწერეთ ამის შესახებ ბუნდოვანი).

წყარო: https://cvedetails.com/

ძალიან ხშირად, კონცეფციის მტკიცებულება იქმნება და დაუყოვნებლივ ქვეყნდება Github-ზე, რათა აპლიკაციის შემნახველმა გუნდებმა სწრაფად შეამოწმონ იგი და უზრუნველყონ მისი ადეკვატურად დაცვა. ამიტომ, Cloudflare-ს ესაჭიროება შესაძლებლობა უპასუხოს ახალ შეტევებს რაც შეიძლება სწრაფად, რათა მომხმარებლებს ჰქონდეთ შესაძლებლობა შეასწორონ თავიანთი პროგრამული უზრუნველყოფა.

Cloudflare-ის სწრაფი რეაგირების შესანიშნავი მაგალითია SharePoint დაუცველობის დაცვის დანერგვა მაისში (დაწვრილებით აქ). განცხადებების გაკეთებისთანავე, ჩვენ შევამჩნიეთ უამრავი მცდელობა, გამოეყენებინათ დაუცველობა ჩვენი მომხმარებლების SharePoint ინსტალაციაში. ჩვენი ბიჭები მუდმივად აკვირდებიან ახალ საფრთხეებს და წერენ წესებს ჩვენი მომხმარებლების დასაცავად.

წესი, რამაც პრობლემა გამოიწვია ხუთშაბათს, უნდა დაიცვას ჯვარედინი სკრიპტებისაგან (XSS). ასეთი თავდასხმები ასევე გახშირდა ბოლო წლებში.

წყარო: https://cvedetails.com/

WAF-ისთვის მართული წესის შეცვლის სტანდარტული პროცედურა არის უწყვეტი ინტეგრაციის (CI) ტესტირების ჩატარება გლობალურ განლაგებამდე. გასულ ხუთშაბათს ჩვენ გავაკეთეთ ეს და გავაფორმეთ წესები. 13:31 საათზე, ინჟინერმა წარადგინა დამტკიცებული მოთხოვნა შეცვლით.

13:37 საათზე TeamCity-მ შეაგროვა წესები, ჩაატარა ტესტები და დაუშვა. WAF ტესტის კომპლექტი ამოწმებს WAF-ის ძირითად ფუნქციონირებას და შედგება ცალკეული ფუნქციების ერთეული ტესტების დიდი რაოდენობით. ერთეულის ტესტების შემდეგ, ჩვენ გამოვცადეთ WAF-ის წესები HTTP მოთხოვნის დიდი რაოდენობით გამოყენებით. HTTP მოთხოვნები ამოწმებს, რომელი მოთხოვნები უნდა დაიბლოკოს WAF-მა (შეტევის ჩასაჭრელად) და რომელი შეიძლება დაუშვას (რათა არ დაბლოკოს ყველაფერი და თავიდან აიცილოს ცრუ პოზიტივი). მაგრამ ჩვენ არ ვამოწმებდით CPU-ს გადაჭარბებულ გამოყენებას და WAF-ის წინა ნაგებობების ჟურნალების შესწავლა აჩვენებს, რომ წესების ტესტის შესრულების დრო არ გაიზარდა და ძნელი იყო ეჭვი, რომ არ იქნებოდა საკმარისი რესურსები.

ტესტებმა გაიარა და TeamCity-მ ავტომატურად დაიწყო ცვლილების განლაგება 13:42 საათზე.

Quicksilver

WAF-ის წესები ფოკუსირებულია საფრთხის დაუყოვნებლივ აღმოფხვრაზე, ამიტომ ჩვენ მათ ვაყენებთ Quicksilver-ის განაწილებული გასაღების მნიშვნელობების მაღაზიის გამოყენებით, რომელიც გლობალურად ცვლილებებს ავრცელებს წამებში. ყველა ჩვენი კლიენტი იყენებს ამ ტექნოლოგიას, როდესაც ისინი ცვლის კონფიგურაციას დაფაზე ან API-ს მეშვეობით და სწორედ მისი წყალობით ვპასუხობთ ცვლილებებს ელვის სისწრაფით.

ჩვენ ბევრი არ გვისაუბრია Quicksilver-ზე. ადრე ვიყენებდით კიოტოს მაგნატი როგორც გლობალურად განაწილებული გასაღების ღირებულების მაღაზია, მაგრამ მასში იყო ოპერაციული პრობლემები და ჩვენ დავწერეთ ჩვენი საკუთარი მაღაზია, რომელიც გავრცელდა 180-ზე მეტ ქალაქში. ჩვენ ახლა ვიყენებთ Quicksilver-ს, რათა გადავიტანოთ კონფიგურაციის ცვლილებები კლიენტებზე, განაახლოთ WAF წესები და გავავრცელოთ კლიენტების მიერ დაწერილი JavaScript კოდი Cloudflare Workers-ში.

მხოლოდ რამდენიმე წამი სჭირდება დაფაზე ღილაკზე დაწკაპუნებას ან API-ს გამოძახებას კონფიგურაციის ცვლილებამდე მთელ მსოფლიოში. მომხმარებელს მოეწონა დაყენების ეს სიჩქარე. და Workers აძლევს მათ პროგრამული უზრუნველყოფის თითქმის მყისიერ გლობალურ გამოყენებას. საშუალოდ, Quicksilver ავრცელებს დაახლოებით 350 ცვლილებას წამში.

და Quicksilver არის ძალიან სწრაფი. საშუალოდ, ჩვენ მივაღწიეთ 99 წამის 2,29-ე პროცენტულს, რათა გამევრცელებინა ცვლილებები მსოფლიოს ყველა კომპიუტერზე. სიჩქარე, როგორც წესი, კარგია. ყოველივე ამის შემდეგ, როდესაც ჩართავთ ფუნქციას ან ასუფთავებთ ქეშს, ეს ხდება თითქმის მყისიერად და ყველგან. კოდის გაგზავნა Cloudflare Workers-ის მეშვეობით ხდება იმავე სიჩქარით. Cloudflare ჰპირდება თავის მომხმარებლებს სწრაფ განახლებებს საჭირო დროს.

მაგრამ ამ შემთხვევაში სიჩქარემ სასტიკი ხუმრობა დაგვათამაშა და წესები ყველგან რამდენიმე წამში შეიცვალა. თქვენ შეიძლება შეამჩნიეთ, რომ WAF კოდი იყენებს ლუას. Cloudflare იყენებს ლუას წარმოებასა და დეტალებში ლუა WAF-ში ჩვენ უკვე განიხილეს. Lua WAF იყენებს PCRE შიგადაშიგ და მიმართავს უკან დახევას შესატყვისად. მას არ გააჩნია კონტროლიდან გამოსული გამონათქვამებისგან დაცვის მექანიზმები. ქვემოთ უფრო მეტს ვისაუბრებ ამაზე და რას ვაკეთებთ ამის შესახებ.

წესების დანერგვამდე ყველაფერი შეუფერხებლად მიმდინარეობდა: pull-ის მოთხოვნა შეიქმნა და დამტკიცდა, CI/CD მილსადენმა შეაგროვა და შეამოწმა კოდი, ცვლილების მოთხოვნა წარადგინეს SOP-ის მიხედვით, რომელიც არეგულირებს განლაგებას და დაბრუნებას, და განლაგება დასრულდა.

Cloudflare WAF განლაგების პროცესი

რა მოხდა არასწორედ
როგორც ვთქვი, ჩვენ ყოველ კვირას ვაყენებთ ათობით ახალ WAF წესს და გვაქვს მრავალი სისტემა, რომ დავიცვათ ასეთი განლაგების უარყოფითი შედეგებისგან. და როდესაც რაღაც არასწორედ მიდის, ეს ჩვეულებრივ რამდენიმე გარემოების ერთობლიობაა ერთდროულად. თუ მხოლოდ ერთ მიზეზს იპოვით, ეს, რა თქმა უნდა, დამამშვიდებელია, მაგრამ ყოველთვის ასე არ არის. ეს არის მიზეზები, რამაც ერთად გამოიწვია ჩვენი HTTP/HTTPS სერვისის წარუმატებლობა.

1. ინჟინერმა დაწერა რეგულარული გამოთქმა, რამაც შეიძლება გამოიწვიოს ზედმეტი უკან დახევა.
2. ფუნქცია, რომელიც ხელს უშლიდა რეგულარულ გამოხატულებას CPU-ს ჭარბი ხარჯვისგან, შეცდომით ამოიღეს WAF-ის რეფაქტორირებისას რამდენიმე კვირით ადრე - რეფაქტორირება იყო საჭირო იმისათვის, რომ WAF-მა ნაკლები რესურსი მოიხმაროს.
3. რეგულარული გამოხატვის ძრავას არ ჰქონდა სირთულის გარანტიები.
4. სატესტო კომპლექტს ვერ აღმოაჩინა გადაჭარბებული CPU მოხმარება.
5. SOP საშუალებას იძლევა არაგადაუდებელი წესების ცვლილებები გლობალურად განხორციელდეს მრავალსაფეხურიანი პროცესის გარეშე.
6. დაბრუნების გეგმა მოითხოვდა სრული WAF-ის ორჯერ გაშვებას, რასაც დიდი დრო დასჭირდა.
7. პირველი გაფრთხილება გლობალური სატრანსპორტო პრობლემების შესახებ ძალიან გვიან გააქტიურდა.
8. გარკვეული დრო დაგვჭირდა სტატუსის გვერდის განახლებას.
9. სისტემებთან წვდომის პრობლემა გვქონდა შეფერხების გამო და შემოვლითი პროცედურა კარგად არ იყო დადგენილი.
10. SRE ინჟინერებმა დაკარგეს წვდომა ზოგიერთ სისტემაზე, რადგან მათ რწმუნებათა სიგელებს ვადა გაუვიდა უსაფრთხოების მიზეზების გამო.
11. ჩვენს მომხმარებლებს არ ჰქონდათ წვდომა Cloudflare-ის დაფაზე ან API-ზე, რადგან ისინი გადიან Cloudflare რეგიონში.

რა შეიცვალა გასული ხუთშაბათის შემდეგ

პირველ რიგში, ჩვენ მთლიანად შევაჩერეთ ყველა მუშაობა WAF-ის გამოშვებებზე და ვაკეთებთ შემდეგს:

1. ჩვენ ხელახლა შემოგთავაზებთ CPU-ს გადაჭარბებული გამოყენების დაცვას, რომელიც ჩვენ წავშალეთ. (მზად)
2. WAF-ისთვის მართულ წესებში არსებული 3868 წესის ხელით შემოწმება, რათა აღმოაჩინოს და გამოასწოროს გადაჭარბებული უკან დახევის სხვა პოტენციური შემთხვევები. (დადასტურება დასრულებულია)
3. ჩვენ ვიცავთ შესრულების პროფილირებას ყველა წესისთვის ტესტის კომპლექტში. (მოსალოდნელია: 19 ივლისი)
4. რეგულარული გამოხატვის ძრავზე გადასვლა რეგლამენტი ან Rust - ორივე უზრუნველყოფს გაშვების გარანტიას. (მოსალოდნელია: 31 ივლისი)
5. ჩვენ ხელახლა ვწერთ SOP-ს, რათა განვათავსოთ წესები ეტაპობრივად, ისევე როგორც სხვა პროგრამული უზრუნველყოფა Cloudflare-ში, მაგრამ ამავე დროს გვაქვს შესაძლებლობა გადაუდებელი გლობალური განლაგება, თუ შეტევები უკვე დაწყებულია.
6. ჩვენ ვავითარებთ Cloudflare-ის დაფის და API-ს სასწრაფოდ ამოღების შესაძლებლობას Cloudflare რეგიონიდან.
7. გვერდის განახლების ავტომატიზაცია Cloudflare სტატუსი.

გრძელვადიან პერსპექტივაში ჩვენ ვშორდებით Lua WAF-ს, რომელიც დავწერე რამდენიმე წლის წინ. WAF-ის გადატანა ახალი firewall სისტემა. ამ გზით WAF იქნება უფრო სწრაფი და მიიღებს დაცვის დამატებით დონეს.

დასკვნა

ამ წარუმატებლობამ ჩვენ და ჩვენს მომხმარებლებს პრობლემები შეუქმნა. ჩვენ სწრაფად ვიმოქმედეთ სიტუაციის გამოსასწორებლად და ახლა ვმუშაობთ პროცესების ხარვეზებზე, რამაც გამოიწვია ავარია, ასევე, უფრო ღრმად ვიჭრებით, რათა დავიცვათ პოტენციური პრობლემები მომავალში რეგულარულ გამონათქვამებთან, ახალ ტექნოლოგიებზე გადასვლისას.

ჩვენ ძალიან გვრცხვენია ამ შეფერხების გამო და ბოდიშს ვუხდით ჩვენს მომხმარებლებს. ვიმედოვნებთ, რომ ეს ცვლილებები უზრუნველყოფს, რომ მსგავსი რამ აღარ განმეორდეს.

განაცხადი. რეგულარული გამონათქვამების უკან დაბრუნება

იმის გასაგებად, თუ როგორ არის გამოხატული:

(?:(?:"|'|]|}||d
(?:nan|infinity|true|false|null|undefined|symbol|math)|`|-
|+)+[)]*;?((?:s|-|~|!|{}||||+)*.*(?:.*=.*)))

შეჭამა CPU-ს ყველა რესურსი, თქვენ უნდა იცოდეთ ცოტა იმაზე, თუ როგორ მუშაობს სტანდარტული რეგულარული გამოხატვის ძრავა. პრობლემა აქ არის ნიმუში .*(?:.*=.*). (?: და შესაბამისი ) არის არადამჭერი ჯგუფი (ანუ ფრჩხილებში გამოსახული გამოთქმა დაჯგუფებულია ერთ გამოსახულებად).

გადაჭარბებული CPU მოხმარების კონტექსტში, ეს ნიმუში შეიძლება აღწერილი იყოს როგორც .*.*=.*. ამ ფორმით, ნიმუში გამოიყურება ზედმეტად რთული. მაგრამ რაც მთავარია, რეალურ სამყაროში გამონათქვამებმა (როგორც რთული გამონათქვამები WAF წესებში), რომლებიც ძრავს სთხოვენ შეესაბამებოდეს ფრაგმენტს, რასაც მოჰყვება სხვა ფრაგმენტი, შეიძლება გამოიწვიოს კატასტროფული უკან დაბრუნება. და ამიტომ.

რეგულარულ გამოხატულებაში . ნიშნავს, რომ უნდა შეესაბამებოდეს ერთ პერსონაჟს, .* - ნულოვანი ან მეტი სიმბოლოს "ხარბად" შეხამება, ანუ მაქსიმუმ სიმბოლოების დაჭერა, ისე რომ .*.*=.* ნიშნავს ნულს ან მეტ სიმბოლოს, შემდეგ ნულს ან მეტ სიმბოლოს, იპოვნეთ ლიტერატურული = სიმბოლო, ემთხვევა ნულს ან მეტ სიმბოლოს.

ავიღოთ ტესტის ხაზი x=x. იგი შეესაბამება გამოხატულებას .*.*=.*. .*.* სანამ თანაბარი ნიშანი პირველს ემთხვევა x (ერთ-ერთი ჯგუფი .* შეესაბამება x, ხოლო მეორე - ნულოვანი სიმბოლო). .* შემდეგ = მატჩები ბოლო x.

ეს შედარება მოითხოვს 23 ნაბიჯს. პირველი ჯგუფი .* в .*.*=.* მოქმედებს ხარბად და ემთხვევა მთელ სტრიქონს x=x. ძრავა გადადის შემდეგ ჯგუფში .*. ჩვენ აღარ გვყავს შესატყვისი პერსონაჟები, ამიტომ მეორე ჯგუფი .* ემთხვევა ნულოვანი სიმბოლოს (ეს დასაშვებია). შემდეგ ძრავა გადადის ნიშანზე =. აღარ არის სიმბოლოები (პირველი ჯგუფი .* გამოიყენა მთელი გამოთქმა x=x), შედარება არ ხდება.

და შემდეგ რეგულარული გამოხატვის ძრავა უბრუნდება საწყისს. ის გადადის პირველ ჯგუფში .* და ადარებს მას с x= (ნაცვლად x=x), შემდეგ კი იღებს მეორე ჯგუფს .*. მეორე ჯგუფი .* შედარებულია მეორესთან x, და ჩვენ ისევ არ დაგვრჩენია პერსონაჟები. და როცა ძრავა ისევ მიაღწევს = в .*.*=.*, არაფერი მუშაობს. და ის ისევ უკან იხევს.

ამჯერად ჯგუფი .* ჯერ კიდევ ემთხვევა x=, მაგრამ მეორე ჯგუფი .* მეტი აღარ xდა ნულოვანი სიმბოლოები. ძრავა ცდილობს იპოვნოს პირდაპირი სიმბოლო = ნიმუშში .*.*=.*, მაგრამ არ გამოდის (ბოლოს და ბოლოს, პირველმა ჯგუფმა უკვე დაიკავა იგი .*). და ის ისევ უკან იხევს.

ამჯერად პირველი ჯგუფი .* იღებს მხოლოდ პირველ x-ს. მაგრამ მეორე ჯგუფი .* "ხარბად" იპყრობს =x. უკვე გამოიცანით რა მოხდება? ძრავა ცდილობს შეესაბამებოდეს სიტყვასიტყვით =, მარცხდება და აკეთებს მორიგ უკან დახევას.

პირველი ჯგუფი .* მაინც ემთხვევა პირველს x. მეორე .* მხოლოდ იღებს =. რა თქმა უნდა, ძრავა ვერ ემთხვევა სიტყვასიტყვით =, რადგან მეორე ჯგუფმა ეს უკვე გააკეთა .*. და ისევ უკან დახევა. და ჩვენ ვცდილობთ დავამთხვიოთ სამი სიმბოლოს სტრიქონი!

შედეგად, პირველი ჯგუფი .* ემთხვევა მხოლოდ პირველს x, მეორე .* - ნულოვანი სიმბოლოებით და ძრავა საბოლოოდ ემთხვევა სიტყვასიტყვით = გამოხატვისას с = ხაზში. შემდეგი არის ბოლო ჯგუფი .* შედარებულია ბოლოსთან x.

მხოლოდ 23 ნაბიჯი x=x. უყურეთ მოკლე ვიდეოს პერლის გამოყენების შესახებ Regexp::გამმართველი, რომელიც გვიჩვენებს, თუ როგორ ხდება ნაბიჯები და უკან დახევა.

ეს უკვე ბევრი სამუშაოა, მაგრამ რა იქნებოდა ამის ნაცვლად x=x გვექნება x=xx? ეს არის 33 ნაბიჯი. Და თუ x=xxx? 45. ურთიერთობა არ არის წრფივი. გრაფიკი აჩვენებს შედარებას x=x დან x=xxxxxxxxxxxxxxxxxxxx (20 x შემდეგ =). თუ გვაქვს 20 x შემდეგ =, ძრავა ასრულებს შესაბამისობას 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. ყველა იმიტომ ? შემდეგ .* ეუბნება ძრავას, რომ შეესაბამებოდეს სიმბოლოების მინიმალურ რაოდენობას გადაადგილებამდე.

მაგრამ ზარმაცი რუკებით სრულებით არ წყვეტს უკან დახევის პრობლემა. თუ კატასტროფულ მაგალითს შევცვლით .*.*=.*; on .*?.*?=.*?;, შესრულების დრო იგივე დარჩება. x=x ჯერ კიდევ სჭირდება 555 ნაბიჯი და x= და 20 x - 5353.

ერთადერთი, რისი გაკეთებაც შეიძლება (გარდა ნიმუშის სრული გადაწერისა უფრო მეტი სპეციფიკისთვის) არის რეგულარული გამოხატვის ძრავის მიტოვება მისი უკან დახევის მექანიზმით. ეს არის ის, რასაც ჩვენ გავაკეთებთ მომდევნო რამდენიმე კვირის განმავლობაში.

ამ პრობლემის გადაწყვეტა ცნობილია 1968 წლიდან, როდესაც კენტ ტომპსონმა დაწერა სტატია პროგრამირების ტექნიკა: რეგულარული გამოხატვის ძიების ალგორითმი („პროგრამირების მეთოდები: რეგულარული გამოხატვის ძიების ალგორითმი“). სტატიაში აღწერილია მექანიზმი, რომელიც საშუალებას გაძლევთ გადაიყვანოთ რეგულარული გამოხატულება არადეტერმინისტულ სასრულ მდგომარეობებში და არადეტერმინისტული სასრული მდგომარეობის მანქანებში მდგომარეობის ცვლილების შემდეგ, გამოიყენოთ ალგორითმი, რომლის შესრულების დრო ხაზობრივად დამოკიდებულია შესაბამის სტრიქონზე.

პროგრამირების მეთოდები
რეგულარული გამოხატვის ძიების ალგორითმი
კენ ტომპსონი
Bell Telephone Laboratories, Inc., მიურეი ჰილი, ნიუ ჯერსი

იგი აღწერს ტექსტში სიმბოლოების კონკრეტული სტრიქონის ძიების მეთოდს და განიხილავს ამ მეთოდის დანერგვას კომპილერის სახით. შემდგენელი იღებს რეგულარულ გამონათქვამს, როგორც წყაროს კოდს და აწარმოებს IBM 7094 პროგრამას, როგორც ობიექტის კოდს. ობიექტის პროგრამა იღებს შეყვანას საძიებო ტექსტის სახით და ასხივებს სიგნალს ყოველ ჯერზე, როცა ტექსტის სტრიქონი ემთხვევა მოცემულ რეგულარულ გამონათქვამს. სტატიაში მოცემულია მაგალითები, პრობლემები და გადაწყვეტილებები.

ალგორითმი
წინა ძიების ალგორითმები იწვევდა უკან დაბრუნებას, თუ ნაწილობრივ წარმატებულმა ძიებამ შედეგი ვერ გამოიღო.

კომპილაციის რეჟიმში ალგორითმი არ მუშაობს სიმბოლოებთან. ის გადასცემს ინსტრუქციებს კომპილირებული კოდისთვის. შესრულება ძალიან სწრაფია - მონაცემების მიმდინარე სიის ზედა ნაწილში გადაცემის შემდეგ, ის ავტომატურად ეძებს ყველა შესაძლო თანმიმდევრულ სიმბოლოს ჩვეულებრივ გამოსახულებაში.
კომპილაციისა და ძიების ალგორითმი შედის დროის გაზიარების ტექსტის რედაქტორში, როგორც კონტექსტური ძიება. რა თქმა უნდა, ეს შორს არის ასეთი ძიების პროცედურის ერთადერთი გამოყენებისგან. მაგალითად, ამ ალგორითმის ვარიანტი გამოიყენება ასამბლერის ცხრილში სიმბოლოების საძიებლად.
ვარაუდობენ, რომ მკითხველი იცნობს რეგულარულ გამონათქვამებს და IBM 7094 კომპიუტერული პროგრამირების ენას.

შემდგენელი
შემდგენელი შედგება სამი ეტაპისგან, რომელიც მიმდინარეობს პარალელურად. პირველი ეტაპი არის სინტაქსის ფილტრაცია, რომელიც მხოლოდ სინტაქსურად სწორი რეგულარული გამონათქვამების გავლის საშუალებას იძლევა. ეს ნაბიჯი ასევე ჩასვამს "·" ოპერატორს რეგულარული გამონათქვამების შესატყვისად. მეორე საფეხურზე რეგულარული გამოხატულება გარდაიქმნება პოსტფიქს ფორმაში. მესამე ეტაპზე იქმნება ობიექტის კოდი. პირველი 2 ეტაპი აშკარაა და ჩვენ არ შევჩერდებით მათზე.

ტომპსონის სტატია არ საუბრობს არადეტერმინისტულ სასრულ მდგომარეობებზე, მაგრამ ის კარგად ხსნის დროის ხაზოვან ალგორითმს და წარმოადგენს ALGOL-60 პროგრამას, რომელიც აგენერირებს ასამბლეის ენის კოდს IBM 7094-ისთვის. განხორციელება რთულია, მაგრამ იდეა ძალიან მარტივია.

მიმდინარე საძიებო გზა. იგი წარმოდგენილია ⊕ ხატით ერთი შეყვანით და ორი გამომავალით.
სურათი 1 გვიჩვენებს კომპილაციის მესამე საფეხურის ფუნქციებს რეგულარული გამოხატვის მაგალითის გარდაქმნისას. მაგალითის პირველი სამი სიმბოლოა a, b, c და თითოეული ქმნის სტეკის ჩანაწერს S[i] და NNODE ველს.

NNODE არსებულ კოდზე, რათა წარმოქმნას მიღებული რეგულარული გამოხატულება ერთ სტეკის ჩანაწერში (იხ. სურათი 5)

ასე გამოიყურება რეგულარული გამოთქმა .*.*=.*, თუ წარმოგიდგენიათ, როგორც ტომპსონის სტატიის სურათებში.

ნახ. 0 არის ხუთი მდგომარეობა, დაწყებული 0-დან და 3 ციკლი, რომელიც იწყება 1, 2 და 3 მდგომარეობიდან. ეს სამი ციკლი შეესაბამება სამს. .* რეგულარულ გამოხატულებაში. 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