Bron i 9 mlynedd yn ôl roedd Cloudflare yn gwmni bach, a doeddwn i ddim yn gweithio iddo, dim ond cwsmer oeddwn i. Fis ar ôl lansio Cloudflare, cefais hysbysiad bod fy ngwefan Nid yw'n ymddangos bod DNS yn gweithio. Mae Cloudflare wedi gwneud newid i , a bu DNS torri.
Ysgrifennais ar unwaith at Matthew Prince gyda'r teitl "Ble mae fy DNS?" ac anfonodd ateb hir yn llawn o fanylion technegol (), ac atebais i:
Oddi wrth: John Graham-Cumming
Dyddiad: Hydref 7, 2010, 9:14
Testun: Re: Ble mae fy DNS?
I: Matthew PrinceAdroddiad cŵl, diolch. Byddaf yn bendant yn galw os oes problemau. Mae’n debyg ei bod yn werth ysgrifennu post am hyn ar ôl i chi gasglu’r holl wybodaeth dechnegol. Rwy'n meddwl y bydd pobl yn mwynhau stori agored a gonest. Yn enwedig os ydych chi'n atodi graffiau iddo i ddangos sut mae traffig wedi cynyddu ers ei lansio.
Mae gen i fonitro da ar fy ngwefan, ac rwy'n derbyn SMS am bob methiant. Mae monitro yn dangos bod y methiant wedi digwydd o 13:03:07 i 14:04:12. Cynhelir profion bob pum munud.
Rwy'n siŵr y byddwch chi'n cyfrifo'r peth. Ydych chi'n siŵr nad oes angen eich person eich hun arnoch chi yn Ewrop? 🙂
Ac efe a atebodd:
Oddi wrth: Matthew Prince
Dyddiad: Hydref 7, 2010, 9:57
Testun: Re: Ble mae fy DNS?
I: John Graham-CummingDiolch. Fe wnaethon ni ymateb i bawb a ysgrifennodd. Rydw i ar fy ffordd i'r swyddfa nawr a byddwn yn ysgrifennu rhywbeth ar y blog neu'n gosod post swyddogol ar ein bwrdd bwletin. Cytunaf yn llwyr, gonestrwydd yw popeth.
Nawr mae Cloudflare yn gwmni mawr iawn, rwy'n gweithio iddo, a nawr mae'n rhaid i mi ysgrifennu'n agored am ein camgymeriad, ei ganlyniadau a'n gweithredoedd.
Digwyddiadau 2 Gorffennaf
Ar 2 Gorffennaf, fe wnaethom gyflwyno rheol newydd yn y Rheolau Rheoledig ar gyfer WAFs ac oherwydd hynny ar bob prosesydd craidd prosesu traffig HTTP/HTTPS ar rwydwaith Cloudflare ledled y byd. Rydym yn gyson yn gwella rheolau a reolir ar gyfer WAFs mewn ymateb i wendidau a bygythiadau newydd. Ym mis Mai, er enghraifft, fe wnaethom frysio i amddiffyn rhag bregusrwydd difrifol yn SharePoint. Holl bwynt ein WAF yw'r gallu i roi rheolau ar waith yn gyflym ac yn fyd-eang.
Yn anffodus, roedd diweddariad dydd Iau diwethaf yn cynnwys mynegiant rheolaidd a oedd yn gwastraffu gormod o adnoddau CPU HTTP/HTTPS ar ôl-dracio. Dioddefodd ein swyddogaethau dirprwy craidd, CDN, a WAF o ganlyniad. Mae'r graff yn dangos bod adnoddau prosesydd ar gyfer gwasanaethu traffig HTTP/HTTPS yn cyrraedd bron i 100% ar weinyddion yn ein rhwydwaith.
Defnydd CPU ar un pwynt presenoldeb yn ystod digwyddiad
O ganlyniad, daeth ein cleientiaid (a chleientiaid ein cleientiaid) i ben i fyny gyda thudalen gwall 502 ar barthau Cloudflare. Cynhyrchwyd gwallau 502 gan weinyddion gwe pen blaen Cloudflare a oedd â creiddiau am ddim o hyd ond nad oeddent yn gallu cyfathrebu â phrosesau sy'n trin traffig HTTP / HTTPS.
Gwyddom faint o anghyfleustra y mae hyn wedi'i achosi i'n cwsmeriaid. Mae gennym ni gywilydd ofnadwy. Ac fe wnaeth y methiant hwn ein hatal rhag delio'n effeithiol â'r digwyddiad.
Os oeddech chi'n un o'r cwsmeriaid hyn, mae'n debyg eich bod yn ofnus, yn ddig ac yn ofidus. Ar ben hynny, nid ydym wedi cael a . Roedd y defnydd uchel o CPUs oherwydd un rheol WAF gyda mynegiant rheolaidd wedi'i eirio'n wael a arweiniodd at olrhain gormodol. Dyma'r mynegiant euog: (?:(?:"|'|]|}||d|(?:nan|infinity|true|false|null|undefined|symbol|math)|`|-|+)+[)]*;?((?:s|-|~|!|{}||||+)*.*(?:.*=.*)))
Er bod hyn yn ddiddorol ynddo'i hun (a byddaf yn siarad amdano yn fanylach isod), roedd gwasanaeth Cloudflare i lawr am 27 munud nid yn unig oherwydd mynegiant rheolaidd gwael. Cymerodd dipyn o amser i ni ddisgrifio'r dilyniant o ddigwyddiadau a arweiniodd at y methiant, felly roedden ni'n araf i ymateb. Ar ddiwedd y post, byddaf yn disgrifio ôl-dracio mewn mynegiant rheolaidd ac yn dweud wrthych beth i'w wneud ag ef.
Beth sydd wedi digwydd
Gadewch i ni ddechrau mewn trefn. Mae pob amser yma yn UTC.
Am 13:42 p.m., gwnaeth peiriannydd ar y tîm wal dân newid bach i'r rheolau canfod defnyddio proses awtomatig. Yn unol â hynny, crëwyd tocyn cais am newid. Rydym yn rheoli tocynnau o'r fath trwy Jira (ciplun isod).
Ar ôl 3 munud, ymddangosodd tudalen gyntaf PagerDuty, yn adrodd am broblem gyda WAF. Prawf synthetig oedd hwn sy'n profi ymarferoldeb WAFs (mae gennym ni gannoedd ohonyn nhw) y tu allan i Cloudflare i fonitro gweithrediad arferol. Dilynwyd hyn yn syth gan dudalennau o rybuddion am brofion gwasanaeth diwedd-i-ddiwedd Cloudflare eraill yn methu, materion traffig byd-eang, gwallau 502 eang, a thunnell o adroddiadau gan ein Pwyntiau Presenoldeb (PoP) mewn dinasoedd ledled y byd a nododd ddiffyg o adnoddau CPU.
Derbyniais nifer o'r rhybuddion hyn, allan o gyfarfod, ac roeddwn ar fy ffordd at y bwrdd pan ddywedodd pennaeth ein hadran datblygu datrysiadau ein bod wedi colli 80% o'n traffig. Rhedais at ein peirianwyr ARhPh, a oedd eisoes yn gweithio ar y broblem. Ar y dechrau roeddem yn meddwl ei fod yn rhyw fath o ymosodiad anhysbys.
Mae peirianwyr Cloudflare SRE wedi'u gwasgaru o gwmpas y byd ac yn monitro'r sefyllfa o gwmpas y cloc. Yn nodweddiadol, mae'r rhybuddion hyn yn eich hysbysu am faterion lleol penodol â chwmpas cyfyngedig, yn cael eu holrhain ar ddangosfyrddau mewnol, ac yn cael eu datrys sawl gwaith y dydd. Ond roedd y tudalennau a'r hysbysiadau hyn yn nodi rhywbeth gwirioneddol ddifrifol, a datganodd peirianwyr SRE y lefel P0 difrifoldeb ar unwaith a chysylltwyd â pheirianwyr rheoli a systemau.
Roedd ein peirianwyr o Lundain yn gwrando ar ddarlith yn y brif neuadd y funud honno. Bu’n rhaid torri ar draws y ddarlith, ymgasglodd pawb mewn ystafell gynadledda fawr, a galwyd mwy o arbenigwyr. Nid oedd hon yn broblem nodweddiadol y gallai ARhPh ymdrin â hi eu hunain. Roedd yn fater brys cynnwys yr arbenigwyr cywir.
Am 14:00 fe wnaethom benderfynu mai gyda'r WAF oedd y broblem ac nad oedd ymosodiad. Tynnodd y tîm perfformiad ddata'r CPU a daeth yn amlwg mai'r WAF oedd ar fai. Cadarnhaodd gweithiwr arall y ddamcaniaeth hon gan ddefnyddio strace. Gwelodd rhywun arall yn y logiau fod yna broblem gyda WAF. Am 14:02 p.m., daeth y tîm cyfan ataf pan gynigiwyd defnyddio lladd byd-eang, mecanwaith sydd wedi'i ymgorffori yn Cloudflare sy'n cau un gydran ledled y byd.
Mae sut y gwnaethom ladd byd-eang i WAF yn stori wahanol. Nid yw mor syml â hynny. Rydym yn defnyddio ein cynnyrch ein hunain, ac ers ein gwasanaeth ddim yn gweithio, ni allem ddilysu a mewngofnodi i'r panel rheoli mewnol (pan oedd popeth wedi'i drwsio, fe wnaethom ddysgu bod rhai aelodau tîm wedi colli mynediad oherwydd nodwedd ddiogelwch sy'n analluogi tystlythyrau os na ddefnyddir y panel rheoli mewnol ar gyfer a amser hir).
Ac ni allem gyrraedd ein gwasanaethau mewnol, fel Jira neu'r system adeiladu. Roedd angen mecanwaith ateb i ni, a oedd yn cael ei ddefnyddio'n anaml (bydd angen gweithio allan hwn hefyd). Yn olaf, llwyddodd un peiriannydd i analluogi'r WAF am 14:07, ac am 14:09, roedd lefelau traffig a CPU yn ôl i normal ym mhobman. Roedd gweddill mecanweithiau amddiffyn Cloudflare yn gweithio fel arfer.
Yna aethom ati i adfer y WAF. Roedd y sefyllfa'n anarferol, felly fe wnaethom gynnal profion negyddol (gan ofyn i'n hunain ai'r newid oedd y broblem mewn gwirionedd) a phrofion cadarnhaol (gan sicrhau bod y dychweliad yn gweithio) mewn un ddinas gan ddefnyddio traffig ar wahân, gan drosglwyddo cwsmeriaid sy'n talu oddi yno.
Am 14:52 roeddem yn argyhoeddedig ein bod yn deall y rheswm ac wedi gwneud cywiriad, ac wedi galluogi WAF eto.
Sut mae Cloudflare yn gweithio
Mae gan Cloudflare dîm o beirianwyr sy'n ymroddedig i reoli rheolau ar gyfer WAFs. Maent yn ymdrechu i wella cyfraddau canfod, lleihau positifau ffug, ac ymateb yn gyflym i fygythiadau newydd wrth iddynt ddod i'r amlwg. Yn ystod y 60 diwrnod diwethaf, mae 476 o geisiadau newid wedi'u prosesu ar gyfer rheolau rheoledig ar gyfer WAF (cyfartaledd o un bob 3 awr).
Roedd angen defnyddio'r newid penodol hwn yn y modd efelychu, lle mae traffig cleientiaid go iawn yn mynd trwy'r rheol, ond nid oes dim wedi'i rwystro. Rydym yn defnyddio'r modd hwn i brofi effeithiolrwydd y rheolau a mesur y cyfraddau positif ffug a negyddol ffug. Ond hyd yn oed yn y modd efelychu, rhaid gweithredu'r rheolau mewn gwirionedd, ac yn yr achos hwn roedd y rheol yn cynnwys mynegiant rheolaidd a oedd yn defnyddio gormod o adnoddau prosesydd.
Fel y gallwch weld o'r cais newid uchod, mae gennym gynllun lleoli, cynllun dychwelyd, a dolen i weithdrefn weithredu safonol fewnol (SOP) ar gyfer y math hwn o ddefnydd. Mae'r SOP ar gyfer newid rheol yn caniatáu iddo gael ei gyhoeddi'n fyd-eang. Mewn gwirionedd, yn Cloudflare, mae pethau'n cael eu gwneud yn hollol wahanol, ac mae'r SOP yn mynnu ein bod ni'n llongio'r meddalwedd i'w brofi a'i ddefnyddio'n fewnol yn gyntaf i bwynt presenoldeb mewnol (PoP) (y mae ein gweithwyr yn ei ddefnyddio), yna i nifer fach o gleientiaid yn lleoliad ynysig, yna i nifer fawr o gleientiaid, a dim ond wedyn i'r byd i gyd.
Dyma sut mae'n edrych. Rydym yn defnyddio git yn fewnol trwy BitBucket. Mae peirianwyr sy'n gweithio ar newidiadau yn cyflwyno cod, sy'n cael ei adeiladu i TeamCity, a phan fydd yr adeiladu'n pasio, mae adolygwyr yn cael eu neilltuo. Unwaith y bydd cais tynnu yn cael ei gymeradwyo, mae'r cod yn cael ei ymgynnull a chyfres o brofion yn cael eu rhedeg (eto).
Os bydd y gwaith adeiladu a phrofion yn cael eu cwblhau'n llwyddiannus, caiff cais am newid ei greu yn Jira a rhaid i'r rheolwr neu'r arweinydd priodol gymeradwyo'r newid. Ar ôl cael ei gymeradwyo, mae'n cael ei ddefnyddio yn yr hyn a elwir yn “PoP menagerie”: Cŵn, PIG a (ci, mochyn a caneri).
Mae DOG PoP yn Cloudflare PoP (fel pob un arall o'n dinasoedd) a ddefnyddir gan weithwyr Cloudflare yn unig. Mae PoP ar gyfer defnydd mewnol yn caniatáu ichi ddal problemau cyn i draffig cwsmeriaid ddechrau llifo i'r ateb. Peth defnyddiol.
Os yw'r prawf Cŵn yn llwyddiannus, mae'r cod yn symud i'r cam PIG (mochyn cwta). Dyma Cloudflare PoP, lle mae ychydig bach o draffig cwsmeriaid am ddim yn llifo trwy god newydd.
Os yw popeth yn iawn, mae'r cod yn mynd i mewn i Canary. Mae gennym ni dri PoP Dedwydd mewn gwahanol rannau o'r byd. Ynddyn nhw, mae traffig cleientiaid taledig a rhad ac am ddim yn mynd trwy'r cod newydd, a dyma'r gwiriad olaf am wallau.
Proses Rhyddhau Meddalwedd yn Cloudflare
Os yw'r cod yn iawn yn Canary, rydyn ni'n ei ryddhau. Mae mynd trwy'r holl gamau - Cŵn, PIG, Dedwydd, y byd i gyd - yn cymryd sawl awr neu ddiwrnod, yn dibynnu ar y newid cod. Oherwydd amrywiaeth rhwydwaith a chleientiaid Cloudflare, rydym yn profi cod yn drylwyr cyn ei ryddhau'n fyd-eang i bob cleient. Ond nid yw WAF yn dilyn y broses hon yn benodol oherwydd bod angen ymateb yn gyflym i fygythiadau.
Bygythiadau WAF
Dros yr ychydig flynyddoedd diwethaf, bu cynnydd sylweddol mewn bygythiadau mewn cymwysiadau cyffredin. Mae hyn oherwydd bod mwy o offer profi meddalwedd ar gael. Er enghraifft, yn ddiweddar rydym wedi ysgrifennu am ).
Ffynhonnell:
Yn aml iawn, mae prawf cysyniad yn cael ei greu a'i gyhoeddi ar unwaith ar Github fel bod y timau sy'n cynnal y cais yn gallu ei brofi'n gyflym a sicrhau ei fod wedi'i ddiogelu'n ddigonol. Felly, mae angen y gallu ar Cloudflare i ymateb i ymosodiadau newydd cyn gynted â phosibl fel bod cwsmeriaid yn cael cyfle i drwsio eu meddalwedd.
Enghraifft wych o ymateb cyflym Cloudflare yw defnyddio amddiffyniadau bregusrwydd SharePoint ym mis Mai (). Bron yn syth ar ôl i'r cyhoeddiadau gael eu gwneud, fe wnaethom sylwi ar nifer enfawr o ymdrechion i fanteisio ar y bregusrwydd yng ngosodiadau SharePoint ein cwsmeriaid. Mae ein dynion yn monitro bygythiadau newydd yn gyson ac yn ysgrifennu rheolau i amddiffyn ein cwsmeriaid.
Roedd y rheol a achosodd y broblem ddydd Iau i fod i amddiffyn rhag sgriptio traws-safle (XSS). Mae ymosodiadau o'r fath hefyd wedi dod yn llawer amlach yn ystod y blynyddoedd diwethaf.
Ffynhonnell:
Y weithdrefn safonol ar gyfer newid rheol reoledig ar gyfer WAF yw cynnal profion integreiddio parhaus (CI) cyn ei ddefnyddio'n fyd-eang. Dydd Iau diwethaf fe wnaethom hyn a chyflwyno'r rheolau. Am 13:31 p.m., cyflwynodd peiriannydd gais tynnu cymeradwy gyda newid.
Am 13:37 casglodd TeamCity y rheolau, cynnal profion a rhoi sêl bendith. Mae cyfres brawf WAF yn profi ymarferoldeb craidd y WAF ac mae'n cynnwys nifer fawr o brofion uned ar gyfer swyddogaethau unigol. Ar ôl profion uned, gwnaethom brofi'r rheolau ar gyfer y WAF gan ddefnyddio nifer enfawr o geisiadau HTTP. Mae ceisiadau HTTP yn gwirio pa geisiadau ddylai gael eu rhwystro gan y WAF (i ryng-gipio'r ymosodiad) a pha rai y gellir eu caniatáu (er mwyn peidio â rhwystro popeth ac osgoi pethau cadarnhaol ffug). Ond ni wnaethom brofi am ddefnydd gormodol o CPU, ac mae archwilio logiau adeiladau WAF blaenorol yn dangos nad oedd yr amser gweithredu prawf rheol yn cynyddu, ac roedd yn anodd amau na fyddai digon o adnoddau.
Pasiodd y profion a dechreuodd TeamCity ddefnyddio'r newid yn awtomatig am 13:42 p.m.
Chwiban
Mae rheolau WAF yn canolbwyntio ar adferiad bygythiad uniongyrchol, felly rydym yn eu defnyddio gan ddefnyddio storfa gwerth allwedd ddosbarthedig Quicksilver, sy'n lluosogi newidiadau yn fyd-eang mewn eiliadau. Mae pob un o'n cleientiaid yn defnyddio'r dechnoleg hon pan fyddant yn newid y ffurfweddiad yn y dangosfwrdd neu drwy'r API, a diolch iddo rydym yn ymateb i newidiadau gyda chyflymder mellt.
Nid ydym wedi siarad llawer am Quicksilver. Yn flaenorol rydym yn defnyddio fel storfa gwerth allweddol a ddosbarthwyd yn fyd-eang, ond roedd problemau gweithredol ag ef, ac fe wnaethom ysgrifennu ein siop ein hunain, wedi'i hailadrodd mewn mwy na 180 o ddinasoedd. Rydym nawr yn defnyddio Quicksilver i wthio newidiadau cyfluniad i gleientiaid, diweddaru rheolau WAF, a dosbarthu cod JavaScript a ysgrifennwyd gan gleientiaid i Cloudflare Workers.
Dim ond ychydig eiliadau y mae'n ei gymryd o glicio botwm ar ddangosfwrdd neu alw API i wneud newid cyfluniad ledled y byd. Roedd cwsmeriaid wrth eu bodd â'r cyflymder gosod hwn. Ac mae Gweithwyr yn rhoi defnydd meddalwedd byd-eang bron ar unwaith iddynt. Ar gyfartaledd, mae Quicksilver yn lluosogi tua 350 o newidiadau yr eiliad.
Ac mae Quicksilver yn gyflym iawn. Ar gyfartaledd, fe wnaethom gyrraedd y 99fed canradd o 2,29 eiliad i ledaenu newidiadau i bob cyfrifiadur ledled y byd. Mae cyflymder fel arfer yn beth da. Wedi'r cyfan, pan fyddwch chi'n galluogi swyddogaeth neu'n clirio'r storfa, mae'n digwydd bron yn syth ac ym mhobman. Mae anfon cod trwy Cloudflare Workers yn digwydd ar yr un cyflymder. Mae Cloudflare yn addo diweddariadau cyflym i'w gwsmeriaid ar yr amser iawn.
Ond yn yr achos hwn, roedd cyflymder yn chwarae jôc greulon arnom, ac fe newidiodd y rheolau ym mhobman mewn ychydig eiliadau. Efallai eich bod wedi sylwi bod y cod WAF yn defnyddio Lua. Mae Cloudflare yn defnyddio Lua yn helaeth mewn cynhyrchu a manylion rydym . Lua WAF yn defnyddio yn fewnol ac yn defnyddio ôl-dracio ar gyfer paru. Nid oes ganddo unrhyw fecanweithiau i amddiffyn rhag ymadroddion sy'n mynd allan o reolaeth. Isod byddaf yn siarad mwy am hyn a'r hyn yr ydym yn ei wneud yn ei gylch.
Cyn i'r rheolau gael eu defnyddio, aeth popeth yn llyfn: crëwyd a chymeradwywyd y cais tynnu, casglodd y biblinell CI / CD y cod a'i brofi, cyflwynwyd y cais am newid yn unol â'r SOP sy'n llywodraethu'r defnydd a'r dychwelyd, a chwblhawyd y defnydd.
Proses Defnyddio WAF Cloudflare
Aeth rhywbeth o'i le
Fel y dywedais, rydym yn defnyddio dwsinau o reolau WAF newydd bob wythnos, ac mae gennym lawer o systemau ar waith i amddiffyn rhag canlyniadau negyddol defnydd o'r fath. A phan aiff rhywbeth o'i le, fel arfer mae'n gyfuniad o sawl amgylchiad ar unwaith. Os dewch chi o hyd i un rheswm yn unig, mae hyn, wrth gwrs, yn galonogol, ond nid yw bob amser yn wir. Dyma’r rhesymau sydd gyda’i gilydd wedi arwain at fethiant ein gwasanaeth HTTP/HTTPS.
- Ysgrifennodd peiriannydd fynegiad rheolaidd a allai arwain at ormodol .
- Cafodd nodwedd a allai fod wedi atal y mynegiant rheolaidd rhag gwastraffu gormod o CPU ei dileu ar gam wrth ailffactorio'r WAF sawl wythnos ynghynt - roedd angen yr ailffactorio i wneud i'r WAF ddefnyddio llai o adnoddau.
- Nid oedd gan yr injan mynegiant rheolaidd unrhyw warantau cymhlethdod.
- Ni allai'r gyfres brawf ganfod defnydd gormodol o CPU.
- Mae'r SOP yn caniatáu i newidiadau rheol nad ydynt yn rhai brys gael eu cyflwyno'n fyd-eang heb broses aml-gam.
- Roedd y cynllun dychwelyd yn gofyn am redeg WAF llawn ddwywaith, a gymerodd amser hir.
- Sbardunwyd y rhybudd cyntaf am broblemau traffig byd-eang yn rhy hwyr.
- Fe wnaethon ni gymryd amser i ddiweddaru'r dudalen statws.
- Cawsom broblemau wrth gael mynediad at systemau oherwydd nam, ac nid oedd gweithdrefn y ffordd osgoi wedi'i hen sefydlu.
- Collodd peirianwyr SRE fynediad i rai systemau oherwydd bod eu cymwysterau wedi dod i ben oherwydd rhesymau diogelwch.
- Nid oedd gan ein cwsmeriaid fynediad i ddangosfwrdd neu API Cloudflare oherwydd eu bod yn mynd trwy ranbarth Cloudflare.
Beth sydd wedi newid ers dydd Iau diwethaf
Yn gyntaf, fe wnaethom atal yn llwyr yr holl waith ar ddatganiadau ar gyfer WAF ac rydym yn gwneud y canlynol:
- Rydym yn ailgyflwyno'r amddiffyniad gorddefnyddio CPU y gwnaethom ei ddileu. (Barod)
- Gwirio pob un o'r 3868 o reolau yn y rheolau a reolir â llaw er mwyn i'r WAF ganfod a chywiro achosion posibl eraill o olrhain gormodol. (Dilysiad wedi'i gwblhau)
- Rydym yn cynnwys proffilio perfformiad ar gyfer yr holl reolau yn y set prawf. (Disgwylir: Gorffennaf 19)
- Newid i injan mynegiant rheolaidd neu - mae'r ddau yn darparu gwarantau amser rhedeg. (Disgwylir: Gorffennaf 31)
- Rydym yn ailysgrifennu'r SOP i ddefnyddio rheolau fesul cam, fel meddalwedd arall yn Cloudflare, ond ar yr un pryd mae gennym y gallu i leoli brys yn fyd-eang os yw ymosodiadau eisoes wedi dechrau.
- Rydym yn datblygu'r gallu i dynnu dangosfwrdd Cloudflare ac API o ranbarth Cloudflare ar frys.
- Awtomeiddio diweddariadau tudalennau .
Yn y tymor hir rydym yn symud i ffwrdd o'r Lua WAF ysgrifennais ychydig flynyddoedd yn ôl. Symud WAF i . Fel hyn bydd y WAF yn gyflymach ac yn derbyn lefel ychwanegol o amddiffyniad.
Casgliad
Achosodd y methiant hwn drafferth i ni a'n cwsmeriaid. Fe wnaethom weithredu'n gyflym i gywiro'r sefyllfa ac rydym bellach yn gweithio ar y diffygion yn y prosesau a achosodd y ddamwain, yn ogystal â chloddio hyd yn oed yn ddyfnach i warchod rhag problemau posibl gydag ymadroddion rheolaidd yn y dyfodol wrth fudo i dechnoleg newydd.
Rydym yn teimlo embaras mawr am y toriad hwn ac yn ymddiheuro i'n cwsmeriaid. Gobeithiwn y bydd y newidiadau hyn yn sicrhau na fydd rhywbeth fel hyn yn digwydd eto.
Cais. Olrhain ymadroddion rheolaidd
I ddeall sut mae'r mynegiant:
(?:(?:"|'|]|}||d
(?:nan|infinity|true|false|null|undefined|symbol|math)|`|-
|+)+[)]*;?((?:s|-|~|!|{}||||+)*.*(?:.*=.*)))Wedi bwyta'r holl adnoddau CPU, mae angen i chi wybod ychydig am sut mae'r injan mynegiant rheolaidd safonol yn gweithio. Y broblem yma yw'r patrwm .*(?:.*=.*). (?: ac yn cyfateb ) yn grŵp nad yw'n dal (hynny yw, mae'r mynegiant mewn cromfachau wedi'i grwpio fel un mynegiant).
Yng nghyd-destun gor-ddefnyddio CPU, gellir disgrifio'r patrwm hwn fel .*.*=.*. Yn y ffurflen hon, mae'r patrwm yn edrych yn ddiangen o gymhleth. Ond yn bwysicach fyth, yn y byd go iawn, gall ymadroddion (fel ymadroddion cymhleth yn rheolau WAF) sy'n gofyn i'r injan gydweddu â darn ac yna darn arall arwain at ôl-dracio trychinebus. A dyna pam.
Mewn mynegiant rheolaidd . yn golygu bod angen i chi gyfateb un cymeriad, .* - cyfateb sero neu fwy o gymeriadau "farus", hynny yw, cipio uchafswm o nodau, fel bod .*.*=.* yn golygu paru sero neu fwy o nodau, yna cyfateb sero neu fwy o nodau, canfod y llythrennol = nod, cyfateb sero neu fwy o nodau.
Gadewch i ni gymryd y llinell brawf x=x. Mae'n cyfateb i'r mynegiant .*.*=.*. .*.* cyn bod yr arwydd cyfartal yn cyfateb i'r cyntaf x (un o'r grwpiau .* соответствуетт x, a'r ail - sero nodau). .* ar ôl = matsis diwethaf x.
Mae angen 23 cam ar gyfer y gymhariaeth hon. Grwp cyntaf .* в .*.*=.* yn ymddwyn yn farus ac yn cyfateb i'r llinyn cyfan x=x. Mae'r injan yn symud i'r grŵp nesaf .*. Nid oes gennym fwy o gymeriadau i gyd-fynd, felly yr ail grŵp .* yn cyfateb i sero nod (caniateir hyn). Yna mae'r injan yn symud i'r arwydd =. Nid oes mwy o symbolau (grŵp cyntaf .* defnyddio'r mynegiant cyfan x=x), nid oes cymhariaeth yn digwydd.
Ac yna mae'r injan mynegiant rheolaidd yn dychwelyd i'r dechrau. Mae'n symud ymlaen i'r grŵp cyntaf .* ac yn ei gymharu с x= (yn lle x=x), ac yna'n cymryd yr ail grŵp .*. Ail grŵp .* yn cael ei gymharu â'r ail x, ac eto nid oes gennym unrhyw gymeriadau ar ôl. A phan fydd yr injan yn cyrraedd eto = в .*.*=.*, dim byd yn gweithio. Ac mae'n backtracks eto.
Y tro hwn y grŵp .* dal yn cyfateb x=, ond yr ail grŵp .* Dim mwy x, a sero nodau. Mae'r injan yn ceisio dod o hyd i gymeriad llythrennol = yn y patrwm .*.*=.*, ond nid yw'n dod allan (wedi'r cyfan, mae'r grŵp cyntaf eisoes wedi'i feddiannu .*). Ac mae'n backtracks eto.
Y tro hwn y grŵp cyntaf .* yn cymryd yr x cyntaf yn unig. Ond yr ail grŵp .* "farus" yn cipio =x. Ydych chi eisoes wedi dyfalu beth fydd yn digwydd? Mae'r injan yn ceisio cyfateb y llythrennol =, yn methu ac yn gwneud backtracking arall.
Grŵp cyntaf .* dal yn cyfateb i'r un cyntaf x... Yr ail .* dim ond yn cymryd =. Wrth gwrs, ni all yr injan gyd-fynd â'r llythrennol =, oherwydd bod yr ail grŵp eisoes wedi gwneud hyn .*. Ac eto backtracking. Ac rydym yn ceisio cyfateb llinyn o dri chymeriad!
O ganlyniad, y grŵp cyntaf .* yn cyfateb i'r un cyntaf yn unig x, ail .* - gyda sero cymeriadau, ac mae'r injan yn olaf yn cyfateb i'r llythrennol = mewn mynegiant с = mewn llinell. Nesaf yw'r grŵp olaf .* yn cael ei gymharu â'r olaf x.
23 cam yn unig ar gyfer x=x. Gwyliwch fideo byr am ddefnyddio Perl , sy'n dangos sut mae camau ac ôl-dracio yn digwydd.
Mae hyn eisoes yn llawer o waith, ond beth os yn lle hynny x=x bydd gennym x=xx? Dyna 33 cam. Ac os x=xxx? 45. Nid yw'r berthynas yn un llinellol. Mae'r graff yn dangos cymhariaeth o x=x i x=xxxxxxxxxxxxxxxxxxxx (20 x ar ôl =). Os oes gennym ni 20 x ar ôl =, mae'r injan yn cwblhau'r paru mewn 555 o gamau! (Ar ben hynny, os ydym wedi colli x= ac mae'r llinyn yn syml yn cynnwys 20 x, bydd yr injan yn cymryd 4067 o gamau i ddeall nad oes unrhyw gemau).
Mae'r fideo hwn yn dangos yr holl ôl-dracio er mwyn cymharu x=xxxxxxxxxxxxxxxxxxxx:
Y drafferth yw, wrth i faint y llinyn gynyddu, mae'r amser paru yn tyfu'n uwch-linellol. Ond gall pethau fynd yn waeth byth os caiff y mynegiant rheolaidd ei addasu ychydig. Gadewch i ni ddweud ein bod wedi .*.*=.*; (hynny yw, roedd hanner colon llythrennol ar ddiwedd y patrwm). Er enghraifft, i gyd-fynd â mynegiant fel foo=bar;.
Ac yma byddai backtracking yn drychineb go iawn. Er cymhariaeth x=x bydd yn cymryd 90 cam, nid 23. Ac mae'r nifer hwnnw'n tyfu'n gyflym. I gymharu x= a 20 x, mae angen 5353 o gamau. Dyma'r siart. Edrychwch ar y gwerthoedd echelin Y o'i gymharu â'r siart blaenorol.
Os oes gennych ddiddordeb, edrychwch ar bob un o'r 5353 o gamau paru a fethwyd x=xxxxxxxxxxxxxxxxxxxx и .*.*=.*;
Trwy ddefnyddio paru diog yn hytrach na barus, gellir rheoli maint yr ôl-dracio. Os byddwn yn newid y mynegiant gwreiddiol i .*?.*?=.*?, er cymhariaeth x=x bydd yn cymryd 11 cam (nid 23). Fel ar gyfer x=xxxxxxxxxxxxxxxxxxxx... Y cyfan oherwydd ? ar ôl .* yn dweud wrth yr injan i gyd-fynd ag isafswm nifer o nodau cyn symud ymlaen.
Ond nid yw mapiau diog yn datrys y broblem ôl-dracio yn llwyr. Os byddwn yn disodli'r enghraifft drychinebus .*.*=.*; ar .*?.*?=.*?;, bydd yr amser gweithredu yn aros yr un fath. x=x dal angen 555 o gamau, a x= a 20 x - 5353.
Yr unig beth y gellir ei wneud (ar wahân i ailysgrifennu'r patrwm yn gyfan gwbl ar gyfer mwy o benodolrwydd) yw rhoi'r gorau i'r injan mynegiant rheolaidd gyda'i fecanwaith tracio ôl. Dyma beth fyddwn yn ei wneud dros yr wythnosau nesaf.
Mae'r ateb i'r broblem hon wedi bod yn hysbys ers 1968, pan ysgrifennodd Kent Thompson erthygl (“Dulliau Rhaglennu: Algorithm Chwilio Mynegiant Rheolaidd”). Mae'r erthygl yn disgrifio mecanwaith sy'n eich galluogi i drosi mynegiant rheolaidd yn beiriannau cyflwr meidraidd anbenderfynol, ac ar ôl newidiadau cyflwr mewn peiriannau cyflwr meidraidd anbenderfynol, defnyddiwch algorithm y mae ei amser gweithredu yn dibynnu'n llinol ar y llinyn cyfatebol.
Dulliau Rhaglennu
Algorithm Chwilio Mynegiant Rheolaidd
Ken Thompson
Labordai Ffôn Bell, Inc., Murray Hill, New JerseyMae'n disgrifio dull o chwilio am gyfres benodol o nodau mewn testun ac yn trafod gweithredu'r dull hwn ar ffurf casglwr. Mae'r casglwr yn cymryd y mynegiant rheolaidd fel cod ffynhonnell ac yn cynhyrchu rhaglen IBM 7094 fel cod gwrthrych. Mae'r rhaglen gwrthrych yn cymryd mewnbwn ar ffurf testun chwilio ac yn allyrru signal bob tro mae llinyn o destun yn cael ei baru â mynegiant rheolaidd penodol. Mae'r erthygl yn rhoi enghreifftiau, problemau ac atebion.
Algorithm
Arweiniodd algorithmau chwilio blaenorol at ôl-dracio os methodd chwiliad rhannol lwyddiannus â chynhyrchu canlyniad.Yn y modd llunio, nid yw'r algorithm yn gweithio gyda symbolau. Mae'n pasio cyfarwyddiadau i god a luniwyd. Mae cyflawni yn gyflym iawn - ar ôl pasio data i frig y rhestr gyfredol, mae'n chwilio'n awtomatig am yr holl nodau olynol posibl yn y mynegiant rheolaidd.
Mae'r algorithm casglu a chwilio wedi'i gynnwys yn y golygydd testun rhannu amser fel chwiliad cyd-destunol. Wrth gwrs, mae hyn ymhell o fod yn unig gymhwyso gweithdrefn chwilio o'r fath. Er enghraifft, defnyddir amrywiad o'r algorithm hwn fel chwiliad symbolau mewn tabl mewn cyfosodwr.
Tybir bod y darllenydd yn gyfarwydd ag ymadroddion rheolaidd ac iaith rhaglennu cyfrifiadurol IBM 7094.Casglwr
Mae'r casglwr yn cynnwys tri cham yn rhedeg ochr yn ochr. Y cam cyntaf yw hidlo cystrawen, sy'n caniatáu i ymadroddion rheolaidd sy'n gywir syntactig basio drwodd yn unig. Mae'r cam hwn hefyd yn mewnosod y gweithredwr "·" i gyd-fynd â mynegiadau rheolaidd. Yn yr ail gam, mae'r mynegiant rheolaidd yn cael ei drawsnewid i ffurf postfix. Yn y trydydd cam, crëir cod gwrthrych. Mae'r 2 gam cyntaf yn amlwg, ac ni fyddwn yn aros arnynt.
Nid yw erthygl Thompson yn sôn am beiriannau cyflwr meidraidd anbenderfynol, ond mae'n esbonio'r algorithm amser llinol yn dda ac yn cyflwyno rhaglen ALGOL-60 sy'n cynhyrchu cod iaith cydosod ar gyfer yr IBM 7094. Mae'r gweithrediad yn anodd, ond mae'r syniad yn syml iawn.
llwybr chwilio cyfredol. Fe'i cynrychiolir gan eicon ⊕ gydag un mewnbwn a dau allbwn.
Mae Ffigur 1 yn dangos swyddogaethau'r trydydd cam llunio wrth drawsnewid enghraifft mynegiant rheolaidd. Y tri nod cyntaf yn yr enghraifft yw a, b, c, ac mae pob un yn creu cofnod pentwr S[i] a maes NNODE.NNODE i'r cod presennol i gynhyrchu'r mynegiant rheolaidd canlyniadol mewn cofnod un pentwr (gweler Ffigur 5)
Dyma sut olwg fyddai ar fynegiant rheolaidd .*.*=.*, os ydych chi'n ei ddychmygu fel yn y lluniau o erthygl Thompson.
Yn Ffig. 0 mae pum talaith yn dechrau o 0, a 3 chylch sy'n dechrau o daleithiau 1, 2 a 3. Mae'r tri chylch hyn yn cyfateb i dri .* mewn mynegiant rheolaidd. Mae 3 hirgrwn gyda dotiau yn cyfateb i un symbol. Hirgrwn ag arwydd = yn cyfateb i gymeriad llythrennol =. Mae cyflwr 4 yn derfynol. Os byddwn yn ei gyrraedd, yna mae'r mynegiant rheolaidd yn cyfateb.
Gweld sut y gellir defnyddio diagram cyflwr o'r fath ar gyfer paru mynegiant rheolaidd .*.*=.*, byddwn yn edrych ar gyfateb llinyn x=x. Mae'r rhaglen yn dechrau o gyflwr 0, fel y dangosir yn Ffig. 1 .
Er mwyn i'r algorithm hwn weithio, rhaid i'r peiriant cyflwr fod mewn sawl cyflwr ar yr un pryd. Bydd peiriant terfynedig anbenderfynol yn gwneud yr holl drawsnewidiadau posibl ar yr un pryd.
Cyn iddo gael amser i ddarllen y data mewnbwn, mae'n mynd i'r ddau gyflwr cyntaf (1 a 2), fel y dangosir yn Ffig. 2 .
Yn Ffig. 2 yn dangos beth sy'n digwydd pan fydd yn edrych ar y cyntaf x в x=x. x yn gallu mapio i'r pwynt uchaf, gan fynd o gyflwr 1 ac yn ôl i gyflwr 1. Neu x yn gallu mapio i'r pwynt isod, gan fynd o gyflwr 2 ac yn ôl i gyflwr 2.
Ar ôl cyfateb y cyntaf x в x=x rydym yn dal yn nhaleithiau 1 a 2. Ni allwn gyrraedd cyflwr 3 neu 4 oherwydd mae angen cymeriad llythrennol arnom =.
Yna mae'r algorithm yn ystyried = в x=x. Fel x o'i flaen, gellir ei baru i un o'r ddwy ddolen uchaf o gyflwr 1 i gyflwr 1 neu o gyflwr 2 i gyflwr 2, ond gall yr algorithm gyfateb i'r llythrennol = a symud o gyflwr 2 i gyflwr 3 (ac ar unwaith 4). Dangosir hyn yn Ffig. 3.
Yna mae'r algorithm yn symud ymlaen i'r un olaf x в x=x. O daleithiau 1 a 2 mae'r un trawsnewidiadau yn bosibl yn ôl i gyflyrau 1 a 2. O gyflwr 3 x yn gallu cyfateb y pwynt ar y dde a mynd yn ôl i gyflwr 3.
Ar y cam hwn, pob cymeriad x=x ystyried, ac ers i ni gyrraedd cyflwr 4, mae'r mynegiant rheolaidd yn cyfateb i'r llinyn hwnnw. Mae pob nod yn cael ei brosesu unwaith, felly mae'r algorithm hwn yn llinol yn hyd y llinyn mewnbwn. A dim backtracking.
Yn amlwg, ar ôl cyrraedd cyflwr 4 (pan fydd yr algorithm wedi cyfateb x=) mae'r mynegiant rheolaidd cyfan yn cyfateb, a gall yr algorithm ddod i ben heb ei ystyried o gwbl x.
Mae'r algorithm hwn yn dibynnu'n llinol ar faint y llinyn mewnbwn.
Ffynhonnell: hab.com