د Cloudflare بندیدو توضیحات د جولای په 2، 2019

نږدې 9 کاله دمخه Cloudflare یو کوچنی شرکت و، او ما د دې لپاره کار نه کاوه، زه یوازې یو پیرودونکی وم. د Cloudflare په لاره اچولو یوه میاشت وروسته، ما یو خبرتیا ترلاسه کړه چې زما ویب پاڼه jgc.orgDNS داسې نه ښکاري چې کار کوي. Cloudflare کې بدلون راغلی د پروتوکول بفرونه، او یو مات شوی DNS شتون درلود.

ما سمدلاسه میتیو پرنس ته د سرلیک سره لیکلي "زما DNS چیرته دی؟" او هغه د تخنیکي توضیحاتو څخه ډک اوږد ځواب بیرته واستاوه (ټوله لیکنه دلته ولولئ)، چې ما ځواب ورکړ:

له خوا: جان ګراهام-کمینګ
نېټه: 7 اکتوبر 2010، 9:14
موضوع: بیا: زما DNS چیرته دی؟
ته: میتیو پرنس

ښه راپور، مننه. زه به خامخا زنګ ووهم که کومه ستونزه وي. دا شاید د دې په اړه پوسټ لیکلو ارزښت ولري کله چې تاسو ټول تخنیکي معلومات راټول کړل. زه فکر کوم چې خلک به د خلاصې او صادقانه کیسې څخه خوند واخلي. په ځانګړي توګه که تاسو دې ته ګرافونه ضمیمه کړئ ترڅو وښیې چې د پیل راهیسې ترافیک څنګه وده کړې.

زه په خپل سایټ کې ښه څارنه لرم، او زه د هرې ناکامۍ په اړه یو SMS ترلاسه کوم. څارنه ښیي چې ناکامي د 13:03:07 څخه تر 14:04:12 پورې واقع شوې. ازموینې په هرو پنځو دقیقو کې ترسره کیږي.

زه ډاډه یم چې تاسو به دا معلومه کړئ. ایا تاسو ډاډه یاست چې تاسو په اروپا کې خپل شخص ته اړتیا نلرئ؟ 🙂

او ځواب یې ورکړ:

له خوا: میتیو پرنس
نېټه: 7 اکتوبر 2010، 9:57
موضوع: بیا: زما DNS چیرته دی؟
ته: جان ګراهام-کمینګ

له تاسو مننه. موږ هر هغه چا ته ځواب ورکوو چې لیکلي یې دي. زه اوس دفتر ته په لاره یم او موږ به په بلاګ کې یو څه ولیکو یا به زموږ په بلیټین بورډ کې رسمي پوسټ پین کړو. زه په بشپړ ډول موافق یم، صداقت هرڅه دي.

اوس Cloudflare واقعیا یو لوی شرکت دی، زه د هغې لپاره کار کوم، او اوس زه باید زموږ د غلطیو، د هغې پایلو او زموږ د کړنو په اړه په ښکاره ډول ولیکم.

د جولای د 2 پیښې

د جولای په 2 مه موږ د WAFs لپاره په اداره شوي قواعدو کې یو نوی قانون رامینځته کړ چې له امله یې د CPU سرچینې ختمې شوې په ټوله نړۍ کې د Cloudflare شبکه کې د هر پروسیسر اصلي پروسس HTTP/HTTPS ترافیک. موږ په دوامداره توګه د نوي زیانونو او ګواښونو په ځواب کې د WAFs لپاره اداره شوي مقررات ښه کوو. د می په میاشت کې، د بیلګې په توګه، موږ چټک شو قاعده اضافه کړئپه SharePoint کې د جدي زیان په وړاندې د ساتنې لپاره. زموږ د WAF ټوله ټکی د ګړندي او نړۍ په کچه د مقرراتو پلي کولو وړتیا ده.

له بده مرغه، د تیرې پنجشنبې تازه معلومات یو منظم بیان درلود چې د HTTP/HTTPS CPU ډیری سرچینې یې په بیکټریک کولو کې ضایع کړې. زموږ اصلي پراکسي، CDN، او WAF فعالیتونه د پایلې په توګه زیانمن شوي. ګراف ښیې چې د HTTP/HTTPS ترافیک خدمت کولو لپاره د پروسیسر سرچینې زموږ په شبکه کې په سرورونو کې نږدې 100٪ ته رسي.

د پیښې په جریان کې د شتون په یو ځای کې د CPU کارول

د پایلې په توګه، زموږ مراجعین (او زموږ د پیرودونکو مراجعینو) د Cloudflare ډومینونو کې د 502 غلطی پاڼې سره پای ته ورسید. 502 تېروتنې د Cloudflare مخکښې پای ویب سرورونو لخوا رامینځته شوي چې لاهم وړیا کورونه لري مګر د HTTP/HTTPS ترافیک اداره کولو پروسو سره د خبرو کولو توان نلري.

موږ پوهیږو چې دا زموږ پیرودونکي څومره تکلیف لري. موږ ډیر شرمیږو. او دې ناکامۍ موږ د پیښې سره په اغیزمنه توګه معامله کولو مخه ونیوله.

که تاسو د دې پیرودونکو څخه یو یاست، تاسو شاید ویره، غوسه او خپه یاست. سربیره پردې، موږ نه لرو نړیوال خنډونه. د لوړ CPU مصرف د WAF د یوې قاعدې له امله و چې د ضعیف کلمو منظم بیان سره چې د ډیر شاته کیدو لامل شو. دلته د مجرم بیان دی: (?:(?:"|'|]|}||d|(?:nan|infinity|true|false|null|undefined|symbol|math)|`|-|+)+[)]*;?((?:s|-|~|!|{}||||+)*.*(?:.*=.*)))

پداسې حال کې چې دا په خپل حق کې په زړه پوري دی (او زه به یې په اړه لاندې نور توضیحاتو سره وغږیږم) ، د Cloudflare خدمت د 27 دقیقو لپاره نه یوازې د خراب منظم بیان له امله ښکته و. دا موږ یو څه وخت نیولی ترڅو د پیښو ترتیب بیان کړو چې د ناکامۍ لامل شوی، نو موږ د ځواب ورکولو لپاره ورو وو. د پوسټ په پای کې، زه به په منظم بیان کې بیرته راستنیدل تشریح کړم او تاسو ته به ووایم چې د دې سره څه وکړي.

случилось случилось

راځئ چې په ترتیب سره پیل وکړو. دلته ټول وختونه په UTC کې دي.

د ماسپښین په 13:42 کې، د اور وژنې ټیم انجنیر د کشف قواعدو کې یو کوچنی بدلون وکړ XSS د اتوماتیک پروسې کارول. په دې اساس، د بدلون غوښتنې ټکټ جوړ شو. موږ دا ډول ټکټونه د جیرا له لارې اداره کوو (لاندې سکرین شاټ).

د 3 دقیقو وروسته، د PagerDuty لومړۍ پاڼه ښکاره شوه، د WAF سره د ستونزې راپور ورکوي. دا یو مصنوعي ازموینه وه چې د نورمال عملیاتو نظارت کولو لپاره د کلاوډ فلیر څخه بهر د WAFs فعالیت ازموي (موږ یې په سلګونو لرو). دا سمدلاسه د نورو Cloudflare پای څخه تر پای پورې خدماتو ازموینې ناکامیدو ، د نړیوال ترافیک مسلو ، پراخه 502 غلطیو ، او د نړۍ په ښارونو کې زموږ د شتون ځایونو (PoP) څخه یو ټن راپورونه په اړه د خبرتیاو پا pagesو لخوا تعقیب شو چې نشتوالی یې په ګوته کړ. د CPU سرچینې.

ما د دې خبرتیاو څخه ډیری ترلاسه کړل، له یوې غونډې څخه راووتم، او د میز په لور روان وم کله چې زموږ د حل پراختیا څانګې مشر وویل چې موږ زموږ 80٪ ترافیک له لاسه ورکړی. زه زموږ د SRE انجنیرانو ته ورغلم، کوم چې دمخه په ستونزه کار کاوه. په لومړي سر کې موږ فکر کاوه چې دا یو ډول نامعلوم برید و.

د Cloudflare SRE انجنیران په ټوله نړۍ کې ویشل شوي او د ساعت په شاوخوا کې وضعیت څارنه کوي. عموما، دا خبرتیاوې تاسو ته د محدودو محلي مسلو په اړه خبر ورکوي، په داخلي ډشبورډونو کې تعقیب کیږي، او په ورځ کې څو ځله حل کیږي. مګر دا پاڼې او خبرتیاوې یو څه جدي اشاره کوي، او د SRE انجنیرانو سمدستي د شدت کچه ​​​​P0 اعلان کړه او د مدیریت او سیسټم انجنیرانو سره یې اړیکه ونیوله.

زموږ د لندن انجینرانو په هغه وخت کې په مرکزي تالار کې لیکچر ته غوږ نیولی و. لیکچر باید ودرول شي، هرڅوک په یوه لوی کنفرانس خونه کې راټول شوي، او نور متخصصین بلل شوي. دا یوه عادي ستونزه نه وه چې SREs کولی شي پخپله معامله وکړي. دا عاجل و چې سم متخصصین پکې شامل شي.

په 14:00 موږ معلومه کړه چې ستونزه د WAF سره وه او هیڅ برید نه و. د فعالیت ټیم د CPU ډیټا را ایستل او دا څرګنده شوه چې WAF ملامت و. یو بل کارمند دا تیوري د سټریس په کارولو سره تایید کړه. بل چا په لاګونو کې ولیدل چې د WAF سره ستونزه وه. د ماسپښین په 14:02 کې، ټول ټیم ​​ما ته راغی کله چې د نړیوال وژنې کارولو وړاندیز شوی و، یو میکانیزم چې په کلاوډ فلیر کې جوړ شوی چې په ټوله نړۍ کې یوه برخه بندوي.

موږ څنګه د WAF لپاره نړیواله وژنه وکړه یوه بله کیسه ده. دا دومره ساده نه ده. موږ خپل محصولات کاروو، او زموږ د خدمت راهیسې ته لاسرسی کار ونکړ، موږ نشو کولی د داخلي کنټرول پینل تصدیق او ننوتلو (کله چې هرڅه سم شوي، موږ پوهیږو چې د ټیم ځینې غړو د امنیتي ځانګړتیاو له امله لاسرسی له لاسه ورکړی و چې اعتبار یې غیر فعالوي که چیرې د داخلي کنټرول پینل نه کارول کیږي. اوږده موده).

او موږ نشو کولی خپلو داخلي خدماتو ته ورسیږو، لکه جیرا یا د جوړونې سیسټم. موږ د کار کولو میکانیزم ته اړتیا درلوده، کوم چې موږ په مکرر ډول کاروو (دا به هم کار کولو ته اړتیا ولري). په نهایت کې، یو انجینر په 14:07 کې د WAF غیر فعال کولو توان درلود، او په 14:09 کې، د ټرافیک او CPU کچه هرچیرې بیرته عادي حالت ته شوه. د Cloudflare پاتې محافظت میکانیزمونه د نورمال په توګه کار کوي.

بیا موږ د WAF بیا رغولو په اړه پیل وکړ. وضعیت له عادي څخه بهر و، نو موږ منفي ازموینې ترسره کړې (له ځانه وپوښتل چې ایا بدلون واقعیا ستونزه وه) او مثبت ازموینې (ډاډ ترلاسه کول چې رول بیک کار کړی) په یو ښار کې د جلا ترافیک په کارولو سره ، له هغه ځایه تادیه کونکي پیرودونکي لیږدول.

په 14:52 کې موږ ډاډه شو چې موږ په دلیل پوهیږو او اصلاح مو وکړه، او WAF بیا فعال کړ.

Cloudflare څنګه کار کوي

Cloudflare د انجنیرانو یوه ډله لري چې د WAFs لپاره د قواعدو اداره کولو لپاره وقف شوي. دوی هڅه کوي چې د کشف کچه ښه کړي، غلط مثبت کم کړي، او په چټکۍ سره نوي ګواښونو ته ځواب ووايي کله چې دوی راڅرګند شي. په تیرو 60 ورځو کې، د WAF لپاره د منظم مقرراتو لپاره 476 د بدلون غوښتنې پروسس شوي دي (په اوسط ډول په هر 3 ساعتونو کې یوه).

دا ځانګړي بدلون ته اړتیا ده چې د سمولیشن حالت کې ځای په ځای شي، چیرې چې د اصلي مراجعینو ټرافيک د قواعدو څخه تیریږي، مګر هیڅ شی بند شوی نه دی. موږ د دې طریقې څخه کار اخلو ترڅو د مقرراتو اغیزمنتیا ازموینه وکړو او د غلط مثبت او غلط منفي نرخونه اندازه کړو. مګر حتی د سمولیشن حالت کې ، مقررات باید واقعیا اجرا شي ، او پدې حالت کې قاعده یو منظم بیان لري چې د پروسیسر ډیرې سرچینې مصرفوي.

لکه څنګه چې تاسو د پورته بدلون غوښتنې څخه لیدلی شئ، موږ د دې ډول ګمارنې لپاره د ګمارنې پالن، د رول بیک پلان، او د داخلي معیاري عملیاتي کړنالرې (SOP) سره اړیکه لرو. د قانون بدلولو لپاره SOP اجازه ورکوي چې په نړیواله کچه خپاره شي. په حقیقت کې ، په کلاوډ فلیر کې ، شیان په بشپړ ډول مختلف ترسره کیږي ، او SOP امر کوي چې موږ لومړی د ازموینې او داخلي کارونې لپاره سافټویر د داخلي شتون (PoP) (کوم چې زموږ کارمندان یې کاروي) ته واستوو ، بیا په کې لږ شمیر پیرودونکو ته. یو جلا ځای، بیا د پیرودونکو لوی شمیر ته، او یوازې بیا ټولې نړۍ ته.

دا هغه څه دي چې داسې ښکاري. موږ git په داخلي توګه د BitBucket له لارې کاروو. انجنیران چې په بدلونونو کار کوي کوډ وړاندې کوي، کوم چې د ټیم سیټي ته جوړ شوی، او کله چې جوړیږي، بیاکتونکي ګمارل کیږي. یوځل چې د پلټ غوښتنه تصویب شي ، کوډ راټول شوی او د ازموینو لړۍ پیل کیږي (بیا).

که چیرې جوړونه او ازموینې په بریالیتوب سره بشپړې شي، په جیرا کې د بدلون غوښتنه رامینځته کیږي او مناسب مدیر یا مشر باید بدلون تصویب کړي. د تصویب وروسته، ګمارل په تش په نامه "PoP مینیجر" کې واقع کیږي: DOG، PIG او کانري (سپی، سور او کانری).

د DOG PoP یو کلاوډ فلیر PoP دی (زموږ د نورو ښارونو په څیر) چې یوازې د کلاوډ فلیر کارمندانو لخوا کارول کیږي. د داخلي کارونې لپاره PoP تاسو ته اجازه درکوي ستونزې ونیسئ مخکې لدې چې د پیرودونکي ترافیک حل ته جریان پیل کړي. ګټور شی.

که د DOG ازموینه بریالۍ وي، کوډ د PIG (ګیني سور) مرحلې ته ځي. دا د Cloudflare PoP دی، چیرې چې د وړیا پیرودونکو ټرافيک لږ مقدار د نوي کوډ له لارې تیریږي.
که هرڅه سم وي، کوډ کانري ته ځي. موږ د نړۍ په بیلابیلو برخو کې درې کانري PoPs لرو. په دوی کې ، د تادیه شوي او وړیا پیرودونکو ترافیک د نوي کوډ له لارې تیریږي ، او دا د غلطیو لپاره وروستی چک دی.

په Cloudflare کې د سافټویر خوشې کولو پروسه

که کوډ په کانري کې سم وي، موږ یې خوشې کوو. د ټولو مرحلو څخه تیریدل - DOG، PIG، Canary، ټوله نړۍ - د کوډ بدلون پورې اړه لري څو ساعته یا ورځې نیسي. د Cloudflare شبکې او پیرودونکو تنوع له امله، موږ په ټوله نړۍ کې ټولو پیرودونکو ته د خپرولو دمخه کوډ په بشپړه توګه ازموینه کوو. مګر WAF په ځانګړې توګه دا پروسه نه تعقیبوي ځکه چې ګواښونو ته په چټکۍ سره ځواب ویلو ته اړتیا لري.

د WAF ګواښونه
په تیرو څو کلونو کې، په عام غوښتنلیکونو کې په ګواښونو کې د پام وړ زیاتوالی راغلی. دا د سافټویر ازموینې وسیلو لوی شتون له امله دی. د بیلګې په توګه، موږ پدې وروستیو کې لیکلي ګډوډ).

سرچینه: https://cvedetails.com/

ډیری وختونه ، د مفکورې ثبوت رامینځته کیږي او سمدلاسه په ګیتوب کې خپریږي ترڅو د غوښتنلیک ساتونکي ټیمونه ژر تر ژره ازموینه وکړي او ډاډ ترلاسه کړي چې دا په کافي اندازه خوندي دی. له همدې امله، Cloudflare د دې وړتیا ته اړتیا لري چې ژر تر ژره نوي بریدونو ته ځواب ووایي ترڅو پیرودونکي د دوی سافټویر حل کولو فرصت ولري.

د Cloudflare د چټک غبرګون یوه ښه بیلګه د می په میاشت کې د SharePoint د زیان مننې محافظتونو ګمارل دي (دلته ولولئ). نږدې سمدلاسه وروسته له دې چې اعلانونه وشول، موږ د خپلو پیرودونکو د SharePoint تاسیساتو کې د زیانونو څخه د ګټې اخیستنې لپاره ډیری هڅې ولیدلې. زموږ هلکان په دوامداره توګه د خپلو پیرودونکو ساتلو لپاره نوي ګواښونه او د لیکلو مقرراتو څارنه کوي.

هغه قاعده چې د پنجشنبې په ورځ د ستونزې لامل شوې باید د کراس سایټ سکریپټینګ (XSS) پروړاندې محافظت وکړي. دا ډول بریدونه هم په وروستیو کلونو کې ډېر شوي دي.

سرچینه: https://cvedetails.com/

د WAF لپاره د مدیریت شوي قاعدې بدلولو معیاري کړنلاره د نړیوال پلي کولو دمخه د دوامداره ادغام (CI) ازموینې ترسره کول دي. تیره پنجشنبه موږ دا وکړل او مقررات مو پلي کړل. د ماسپښین په 13:31 بجو، یو انجینر د بدلون سره د پلي کولو غوښتنه تصویب کړه.

په 13:37 ټیم سیټي مقررات راټول کړل، ازموینې یې واخیستې او مخکې لاړ. د WAF ټیسټ سویټ د WAF اصلي فعالیت ازموینه کوي او د انفرادي دندو لپاره د یونټ ازموینې لوی شمیر لري. د واحد ازموینو وروسته، موږ د WAF لپاره د ډیرو HTTP غوښتنو په کارولو سره مقررات ازموینه وکړه. د HTTP غوښتنې چیک کوي چې کومې غوښتنې باید د WAF لخوا بندې شي (د برید مخه ونیسي) او کوم ته اجازه ورکول کیدی شي (د دې لپاره چې هرڅه بند نشي او د غلط مثبتو څخه مخنیوی وشي). مګر موږ د ډیر CPU کارولو لپاره ازموینه نه ده کړې، او د پخوانیو WAF ودانیو لاګونو معاینه کول ښیې چې د مقرراتو ازموینې اجرا کولو وخت نه دی زیات شوی، او دا ستونزمنه وه چې شکمن وي چې کافي سرچینې به نه وي.

ازموینې تیرې شوې او ټیم سیټي په اوتومات ډول د ماسپښین په 13:42 کې د بدلون پلي کول پیل کړل.

Quicksilver

د WAF مقررات د سمدستي ګواښ په درملنه تمرکز کوي، نو موږ یې د Quicksilver د توزیع شوي کلیدي ارزښت پلورنځي په کارولو سره ځای په ځای کوو، کوم چې په نړۍ کې په ثانیو کې بدلونونه خپروي. زموږ ټول پیرودونکي دا ټیکنالوژي کاروي کله چې دوی په ډشبورډ کې یا د API له لارې تشکیلات بدلوي، او دا د دې څخه مننه ده چې موږ د بریښنا سرعت سره بدلونونو ته ځواب ورکوو.

موږ د Quicksilver په اړه ډیرې خبرې نه دي کړي. مخکې موږ کارول کیوټو ټیکون د نړۍ په کچه د توزیع شوي کلیدي ارزښت پلورنځي په توګه ، مګر پدې کې عملیاتي ستونزې شتون درلود ، او موږ خپل پلورنځی لیکلی ، له 180 څخه زیاتو ښارونو کې نقل شوی. موږ اوس Quicksilver کاروو ترڅو پیرودونکو ته د تشکیلاتو بدلونونو فشار ورکړئ ، د WAF قواعد تازه کړئ ، او د Cloudflare کارمندانو ته د پیرودونکو لخوا لیکل شوي جاواسکریپټ کوډ توزیع کړئ.

دا په ډشبورډ کې د تڼۍ کلیک کولو یا په ټوله نړۍ کې د تنظیم کولو بدلون رامینځته کولو لپاره API ته زنګ وهلو څخه یوازې څو ثانیې وخت نیسي. پیرودونکو د تنظیم کولو دا سرعت خوښ کړ. او کارګران دوی ته نږدې سمدستي نړیوال سافټویر ځای په ځای کوي. په اوسط ډول، Quicksilver په هره ثانیه کې شاوخوا 350 بدلونونه خپروي.

او Quicksilver خورا ګړندی دی. په اوسط ډول، موږ د نړۍ په هر کمپیوټر کې د بدلونونو تبلیغ کولو لپاره د 99 ثانیو 2,29 فیصده ترلاسه کړه. سرعت معمولا یو ښه شی دی. په هرصورت ، کله چې تاسو یو فنکشن فعال کړئ یا کیچ پاک کړئ ، دا نږدې سمدستي او هرچیرې پیښیږي. د Cloudflare کارمندانو له لارې د کوډ لیږل په ورته سرعت کې پیښیږي. Cloudflare خپلو پیرودونکو ته په سم وخت کې د ګړندي تازه معلوماتو ژمنه کوي.

مګر پدې حالت کې ، سرعت زموږ په اړه ظالمانه ټوکه وکړه ، او مقررات په ثانیو کې هرچیرې بدل شول. تاسو شاید لیدلي وي چې د WAF کوډ Lua کاروي. Cloudflare لوا په پراخه کچه په تولید او توضیحاتو کې کاروي Lua په WAF کې موږ یو دمخه بحث شوی. Lua WAF کاروي د کمپیوټر په داخلي توګه او د میچ کولو لپاره بیکټریک کول پلي کوي. دا هیڅ میکانیزم نلري چې د بیانونو پروړاندې محافظت وکړي چې له کنټرول څخه بهر کیږي. لاندې به زه د دې په اړه نور څه وغږیږم او موږ د دې په اړه څه کوو.

مخکې لدې چې مقررات پلي شي ، هرڅه په اسانۍ سره پرمخ تللي: د پل غوښتنه رامینځته شوې او تصویب شوې ، د 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. موږ د ازموینې سیټ کې د ټولو مقرراتو لپاره د فعالیت پروفایل شامل کوو. (توقع: د جولای ۱۹)
4. د منظم بیان انجن ته بدلول ریکاینکس او یا سوله - دواړه د چلولو تضمین چمتو کوي. (توقع: د جولای ۳۱)
5. موږ په کلاوډ فلیر کې د نورو سافټویر په څیر په مرحلو کې د مقرراتو پلي کولو لپاره SOP بیا لیکو ، مګر په ورته وخت کې د بیړني نړیوال ګمارلو وړتیا لرو که بریدونه دمخه پیل شوي وي.
6. موږ د دې وړتیا ته وده ورکوو چې په عاجل ډول د Cloudflare ډشبورډ او API د Cloudflare سیمې څخه لرې کړو.
7. د مخ تازه کولو اتومات کول د Cloudflare حالت.

د اوږدې مودې لپاره موږ د Lua WAF څخه لیرې یو چې ما څو کاله دمخه لیکلي و. WAF ته لیږدول د اور وژنې نوی سیسټم. پدې توګه به 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::Debugger، کوم چې ښیي چې څنګه ګامونه او شا تګ واقع کیږي.

دا لا دمخه ډیر کار دی، مګر که څه هم پرځای 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 x5353 مرحلو ته اړتیا ده. دلته چارټ دی. د محور ارزښتونو ته وګورئ Y د تیر چارټ په پرتله.

که تاسو لیوالتیا لرئ، ټول 5353 ناکام شوي مطابقت مرحلې وګورئ x=xxxxxxxxxxxxxxxxxxxx и .*.*=.*;

د لالچ میچ کولو پر ځای د سست کارولو سره، د شاتګ کچه کنټرول کیدی شي. که موږ اصلي وینا ته بدل کړو .*?.*?=.*?د پرتله کولو لپاره x=x دا به 11 ګامونه واخلي (نه 23). لکه څنګه چې x=xxxxxxxxxxxxxxxxxxxx. ټول ځکه ? после .* انجن ته وايي چې د حرکت کولو دمخه د لږ تر لږه حروفونو سره سمون خوري.

مګر سست نقشه په بشپړه توګه د بیرته راستنیدو ستونزه نه حل کوي. که موږ د ناورین مثال بدل کړو .*.*=.*; په .*?.*?=.*?;، د اعدام وخت به ورته پاتې شي. x=x لاهم 555 ګامونو ته اړتیا لري، او x= او 20 x - 5353.

یوازینی شی چې ترسره کیدی شي (د لوی ځانګړتیا لپاره د نمونې په بشپړ ډول بیا لیکلو سربیره) د دې د شاته کولو میکانیزم سره د منظم بیان انجن پریښودل دي. دا هغه څه دي چې موږ به یې په راتلونکو څو اونیو کې وکړو.

د دې ستونزې حل د 1968 راهیسې پیژندل شوی، کله چې کینټ تامپسن یوه مقاله لیکلې وه د پروګرام کولو تخنیکونه: منظم بیان لټون الګوریتم ("د پروګرام کولو میتودونه: منظم بیان لټون الګوریتم"). مقاله یو میکانیزم تشریح کوي چې تاسو ته اجازه درکوي منظم بیان په غیر متمرکز محدود حالت ماشینونو کې بدل کړئ، او د غیر متمرکز محدود حالت ماشینونو کې د دولت بدلونونو وروسته، یو الګوریتم وکاروئ چې د اجرا کولو وخت په ترتیب شوي تار پورې تړاو لري.

د پروګرام کولو میتودونه
د منظم بیان لټون الګوریتم
کین تامپسن
د بیل ټیلیفون لابراتوارونه، انکارپوریشن، موری هیل، نیو جرسی

دا په متن کې د حروفونو د ځانګړي تار لټون کولو میتود تشریح کوي او د کمپیلر په شکل کې د دې میتود پلي کولو په اړه بحث کوي. کمپیلر منظم بیان د سرچینې کوډ په توګه اخلي او د 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