👵 ▶️ 🧑🏾 Rincian kerusakan Cloudflare 2 Juli 2019 🛃 👸🏼 🤳🏽

Hampir 9 tahun yang lalu, Cloudflare adalah perusahaan kecil, tetapi saya tidak bekerja di dalamnya, saya hanya seorang klien. Sebulan setelah meluncurkan Cloudflare, saya menerima pemberitahuan bahwa DNS tampaknya tidak berfungsi di situs web jgc.org saya. Cloudflare membuat perubahan ke Protokol Buffer , dan ada DNS yang rusak.

Saya segera menulis kepada Matthew Prince, mengepalai surat "Di mana DNS saya?", Dan dia mengirim jawaban panjang, penuh dengan rincian teknis ( baca semua korespondensi di sini ), dan saya menjawab:

Dari: John Graham Cumming
Tanggal: 7 Oktober 2010 9:14
Subjek: Re: Di mana DNS saya?
Kepada: Matthew Prince

Laporan keren, terima kasih. Saya pasti akan menelepon jika ada masalah. Mungkin layak menulis posting tentang ini ketika Anda mengumpulkan semua info teknis. Saya pikir orang akan menyukai cerita yang terbuka dan jujur. Terutama jika Anda melampirkan grafik untuk menunjukkan bagaimana lalu lintas tumbuh setelah diluncurkan.

Saya memiliki pemantauan yang baik di situs, dan saya menerima SMS tentang setiap kegagalan. Pemantauan menunjukkan bahwa kegagalan adalah dari 13:03:07 hingga 14:04:12. Tes dilakukan setiap lima menit.

Saya yakin Anda akan mengetahuinya. Anda pasti tidak membutuhkan orang Anda sendiri di Eropa? :-)

Dan dia menjawab:

Dari: Matthew Prince
Tanggal: 7 Oktober 2010, 9:57
Subjek: Re: Di mana DNS saya?
Kepada: John Graham Cumming

Terima kasih Kami menjawab semua orang yang menulis. Saya akan ke kantor sekarang, dan kami akan menulis sesuatu di blog atau mengirim posting resmi di papan buletin kami. Saya sepenuhnya setuju, kejujuran adalah segalanya bagi kami.

Sekarang Cloudflare adalah perusahaan yang sangat besar, saya bekerja di dalamnya, dan sekarang saya harus menulis secara terbuka tentang kesalahan kita, konsekuensinya dan tindakan kita.

2 Juli acara

Pada tanggal 2 Juli, kami menerapkan aturan baru dalam aturan yang dikelola untuk WAF, karena sumber daya prosesor habis pada setiap inti prosesor yang memproses lalu lintas HTTP / HTTPS di jaringan Cloudflare di seluruh dunia. Kami terus meningkatkan aturan yang dikelola untuk WAF dalam menanggapi kerentanan dan ancaman baru. Pada Mei, misalnya, kami bergegas menambahkan aturan untuk melindungi diri dari kerentanan serius di SharePoint. Inti dari WAF kami adalah kemampuan untuk menyebarkan aturan secara cepat dan global.

Sayangnya, pembaruan Kamis lalu berisi ekspresi reguler yang menghabiskan terlalu banyak sumber daya prosesor yang didedikasikan untuk HTTP / HTTPS untuk melakukan backtracking. Ini memengaruhi fitur inti proxy, CDN, dan WAF kami. Grafik menunjukkan bahwa sumber daya prosesor untuk melayani lalu lintas HTTP / HTTPS mencapai hampir 100% pada server di jaringan kami.

Menggunakan sumber daya prosesor di salah satu titik kehadiran selama insiden

Akibatnya, klien kami (dan klien klien kami) berlari ke halaman dengan kesalahan 502 di domain Cloudflare. 502 kesalahan dihasilkan oleh server web Cloudflare front-end, yang masih memiliki kernel gratis, tetapi mereka tidak dapat menghubungi proses yang memproses lalu lintas HTTP / HTTPS.

Kami tahu berapa banyak ketidaknyamanan yang menyebabkan pelanggan kami. Kami sangat malu. Dan kegagalan ini mencegah kami dari berurusan secara efektif dengan kejadian itu.

Jika Anda salah satu dari klien ini, itu mungkin membuat Anda takut, marah dan kesal. Selain itu, kami belum mengalami kegagalan global selama 6 tahun. Konsumsi CPU yang tinggi adalah karena satu aturan WAF dengan ekspresi reguler yang diformulasikan dengan buruk, yang menyebabkan backtracking yang berlebihan. Inilah ekspresi bersalahnya: (?:(?:\"|'|\]|\}|\\|\d|(?:nan|infinity|true|false|null|undefined|symbol|math)|\`|\-|\+)+[)]*;?((?:\s|-|~|!|{}|\|\||\+)*.*(?:.*=.*)))

Meskipun itu menarik dalam dirinya sendiri (dan saya akan memberi tahu Anda lebih banyak tentangnya di bawah), layanan Cloudflare terputus selama 27 menit, tidak hanya karena ekspresi reguler yang tidak sesuai. Butuh beberapa saat untuk menggambarkan urutan kejadian yang menyebabkan kegagalan, jadi kami tidak merespons dengan cepat. Di akhir posting, saya akan menjelaskan penelusuran mundur dalam ekspresi reguler dan memberi tahu Anda apa yang harus dilakukan.

Apa yang terjadi

Mari kita mulai. Semua waktu ditunjukkan di sini dalam UTC.

Pada 13:42, seorang insinyur dari tim firewall membuat perubahan kecil pada aturan untuk mendeteksi XSS menggunakan proses otomatis. Karenanya, tiket permintaan perubahan telah dibuat. Kami mengelola tiket ini melalui Jira (tangkapan layar di bawah).

Setelah 3 menit, halaman PagerDuty pertama muncul, melaporkan masalah dengan WAF. Itu adalah tes sintetis yang memeriksa fungsionalitas WAF (kami memiliki ratusan di antaranya) di luar Cloudflare untuk memantau operasi normal. Lalu segera ada halaman-halaman dengan pemberitahuan kegagalan dari tes end-to-end lain dari layanan Cloudflare, masalah lalu lintas global, kesalahan 502 yang tersebar luas, dan banyak laporan dari titik kehadiran kami (PoP) di kota-kota di seluruh dunia yang menunjukkan kurangnya sumber daya prosesor.

Saya menerima beberapa pemberitahuan seperti itu, keluar dari rapat dan sudah berjalan ke meja ketika kepala departemen pengembangan solusi kami mengatakan bahwa kami kehilangan 80% dari lalu lintas. Saya berlari ke insinyur SRE kami yang sudah mengerjakan masalah. Awalnya kami pikir itu semacam serangan yang tidak diketahui.

Insinyur Cloudflare SRE tersebar di seluruh dunia dan memantau situasi sepanjang waktu. Biasanya, peringatan tersebut memberi tahu Anda tentang masalah lokal spesifik lingkup terbatas, dipantau pada dasbor internal, dan diselesaikan beberapa kali sehari. Tetapi halaman dan pemberitahuan tersebut menunjukkan sesuatu yang sangat serius, dan para insinyur SRE segera mengumumkan tingkat keparahan P0 dan beralih ke manajemen dan teknisi sistem.

Insinyur London kami pada saat itu sedang mendengarkan ceramah di aula utama. Ceramah harus diganggu, semua orang berkumpul di ruang konferensi besar, dan lebih banyak ahli diundang. Ini bukan masalah umum yang SRE bisa cari tahu sendiri. Sangat mendesak untuk menghubungkan spesialis yang tepat.

Pada pukul 14:00 kami memutuskan bahwa ada masalah dengan WAF dan tidak ada serangan. Departemen kinerja mengambil data prosesor, dan menjadi jelas bahwa WAF yang harus disalahkan. Kolaborator lain mengkonfirmasi teori ini dengan strace. Orang lain melihat di log bahwa masalah dengan WAF. Pada pukul 14:02, seluruh tim mendatangi saya ketika diusulkan untuk menggunakan global kill - sebuah mekanisme yang dibangun dalam Cloudflare yang menonaktifkan satu komponen di seluruh dunia.

Bagaimana kami melakukan global kill untuk WAF adalah cerita yang berbeda. Tidak sesederhana itu. Kami menggunakan produk kami sendiri, dan karena layanan Access kami tidak berfungsi, kami tidak dapat mengotentikasi dan masuk ke panel kontrol internal (ketika semuanya diperbaiki, kami mengetahui bahwa beberapa anggota tim kehilangan akses karena fitur keamanan yang menonaktifkan kredensial jika jangan gunakan panel kontrol internal untuk waktu yang lama).

Dan kami tidak bisa mendapatkan layanan internal kami, seperti Jira atau sistem build. Kami membutuhkan solusi, yang jarang kami gunakan (ini juga perlu diselesaikan). Akhirnya, seorang insinyur mampu memotong WAF pada 14:07, dan pada 14:09 tingkat lalu lintas dan prosesor di mana-mana kembali normal. Mekanisme pertahanan Cloudflare lainnya berfungsi seperti yang diharapkan.

Kemudian kami mulai mengembalikan WAF. Situasinya luar biasa, jadi kami melakukan tes negatif (bertanya pada diri sendiri apakah masalah sebenarnya adalah perubahan ini) dan positif (memastikan bahwa kemunduran berfungsi) di satu kota menggunakan lalu lintas terpisah, memindahkan pelanggan berbayar dari sana.

Pada pukul 2:52 malam, kami yakin bahwa kami memahami alasannya dan melakukan koreksi, dan menyalakan WAF lagi.

Bagaimana Cloudflare Bekerja

Cloudflare memiliki tim insinyur yang mengelola aturan yang dikelola untuk WAF. Mereka mencoba untuk meningkatkan tingkat deteksi, mengurangi jumlah positif palsu dan cepat menanggapi ancaman baru saat mereka muncul. Selama 60 hari terakhir, 476 permintaan perubahan untuk aturan yang dikelola WAF telah diproses (rata-rata, satu setiap 3 jam).

Perubahan khusus ini perlu digunakan dalam mode simulasi, di mana lalu lintas klien nyata melewati aturan, tetapi tidak ada yang diblokir. Kami menggunakan mode ini untuk memeriksa efektivitas aturan dan mengukur proporsi hasil positif palsu dan negatif palsu. Tetapi bahkan dalam mode simulasi, aturan harus benar-benar dieksekusi, dan dalam kasus ini, aturan berisi ekspresi reguler yang menghabiskan terlalu banyak sumber daya prosesor.

Seperti yang dapat Anda lihat dari permintaan perubahan di atas, kami memiliki paket penerapan, paket rollback, dan tautan ke prosedur operasi standar internal (SOP) untuk jenis penyebaran ini. SOP untuk mengubah aturan memungkinkan Anda untuk mempublikasikannya secara global. Bahkan, di Cloudflare, semuanya diatur dengan sangat berbeda, dan SOP pertama-tama mengharuskan untuk mengirim perangkat lunak untuk pengujian dan penggunaan internal ke titik kehadiran internal (PoP) (yang digunakan karyawan kami), kemudian ke sejumlah kecil klien di tempat yang terisolasi, kemudian ke sejumlah besar klien, dan hanya kemudian ke seluruh dunia.

Ini tampilannya. Kami menggunakan git di sistem internal melalui BitBucket. Insinyur perubahan mengirim kode yang mereka buat ke TeamCity, dan ketika build berlalu, pengulas ditugaskan. Ketika permintaan kumpulan disetujui, kode dikumpulkan dan serangkaian tes dilakukan (lagi).

Jika perakitan dan tes berhasil, permintaan perubahan dibuat di Jira, dan perubahan tersebut harus disetujui oleh penyelia atau spesialis utama yang sesuai. Setelah disetujui, itu digunakan untuk apa yang disebut "PoP menagerie": DOG, PIG dan Canary (anjing, gondong dan kenari).

DOG PoP adalah Cloudflare PoP (seperti kota-kota kami lainnya), yang hanya digunakan oleh karyawan Cloudflare. PoP untuk penggunaan internal memungkinkan Anda untuk menangkap masalah bahkan sebelum solusi mulai menerima lalu lintas pelanggan. Hal yang berguna.

Jika tes DOG berhasil, kode dilanjutkan ke tahap PIG (kelinci percobaan). Ini adalah Cloudflare PoP, di mana sejumlah kecil lalu lintas klien gratis mengalir melalui kode baru.
Jika semuanya baik-baik saja, kodenya masuk ke Canary. Kami memiliki tiga PoP Canary di berbagai belahan dunia. Lalu lintas klien berbayar dan gratis melewati kode baru di dalamnya, dan ini adalah pemeriksaan kesalahan terakhir.

Proses Peluncuran Perangkat Lunak Cloudflare

Jika kodenya oke di Canary, kami merilisnya. Melewati semua tahapan - DOG, PIG, Canary, seluruh dunia - membutuhkan beberapa jam atau hari, tergantung pada perubahan kode. Karena keragaman jaringan dan pelanggan Cloudflare, kami menguji kode secara menyeluruh sebelum rilis global untuk semua pelanggan. Tetapi WAF tidak secara khusus mengikuti proses ini karena ancaman perlu ditanggapi dengan cepat.

Ancaman WAF
Dalam beberapa tahun terakhir, ada lebih banyak ancaman signifikan dalam aplikasi konvensional. Hal ini disebabkan oleh ketersediaan perangkat pengujian perangkat lunak yang lebih besar. Sebagai contoh, kami baru saja menulis tentang fuzzing ).

Sumber: https://cvedetails.com/

Sangat sering, konfirmasi konsep dibuat dan segera diterbitkan di Github sehingga tim yang melayani aplikasi dapat dengan cepat mengujinya dan memastikan bahwa itu dilindungi secara memadai. Oleh karena itu, Cloudflare membutuhkan kemampuan untuk merespons serangan baru secepat mungkin sehingga pelanggan memiliki kesempatan untuk memperbaiki perangkat lunak mereka.

Sebuah contoh bagus dari tanggapan cepat Cloudflare adalah penerapan perlindungan kerentanan SharePoint pada bulan Mei ( baca di sini ). Hampir segera setelah publikasi iklan, kami melihat sejumlah besar upaya untuk mengeksploitasi kerentanan dalam instalasi SharePoint klien kami. Teman-teman kami terus-menerus memonitor ancaman baru dan menulis aturan untuk melindungi pelanggan kami.

Aturan yang menyebabkan masalah pada hari Kamis adalah untuk melindungi terhadap scripting lintas situs (XSS). Ada juga banyak serangan seperti itu dalam beberapa tahun terakhir.

Sumber: https://cvedetails.com/

Prosedur standar untuk memodifikasi aturan yang dikelola untuk WAF memerlukan pengujian integrasi berkelanjutan (CI) sebelum penyebaran global. Kamis lalu, kami melakukannya dan memperluas aturan. Pada pukul 13:31, seorang insinyur mengirim permintaan kolam yang disetujui dengan kembalian.

Pada 13:37, TeamCity mengumpulkan aturan, menjalankan tes dan memberikan lampu hijau. Test suite WAF menguji fungsionalitas inti WAF dan terdiri dari sejumlah besar unit test untuk fungsi individual. Setelah pengujian unit, kami memeriksa aturan WAF dengan sejumlah besar permintaan HTTP. Permintaan HTTP memeriksa permintaan mana yang harus diblokir oleh WAF (untuk mencegat serangan) dan yang dapat dilewati (agar tidak memblokir semuanya dan menghindari kesalahan positif). Tetapi kami tidak melakukan tes untuk penggunaan sumber daya prosesor yang berlebihan, dan mempelajari log dari rakitan WAF sebelumnya menunjukkan bahwa waktu pelaksanaan uji dengan aturan tidak meningkat, dan sulit untuk mencurigai bahwa tidak ada sumber daya yang cukup.

Tes telah berlalu, dan TeamCity mulai secara otomatis menyebarkan perubahan pada pukul 13:42.

Quicksilver

Aturan WAF dirancang untuk mengatasi ancaman dengan cepat, jadi kami menyebarkannya menggunakan repositori pasangan kunci-nilai terdistribusi Quicksilver, yang mendistribusikan perubahan secara global dalam hitungan detik. Semua pelanggan kami menggunakan teknologi ini ketika mereka mengubah konfigurasi di dasbor atau melalui API, dan karena itu kami merespons perubahan dengan kecepatan kilat.

Kami berbicara sedikit tentang Quicksilver. Kami dulu menggunakan Kyoto Tycoon sebagai repositori pasangan nilai kunci terdistribusi secara global, tetapi ada masalah operasional dengannya, dan kami menulis repositori kami yang direplikasi di lebih dari 180 kota. Sekarang, dengan Quicksilver, kami mengirim perubahan konfigurasi klien, memperbarui aturan WAF, dan mendistribusikan kode JavaScript yang ditulis oleh klien di Cloudflare Workers.

Hanya diperlukan beberapa detik untuk konfigurasi untuk keliling dunia dari menekan tombol pada dashboard atau memanggil API untuk membuat perubahan konfigurasi. Pelanggan menyukai pengaturan kecepatan ini. Dan Pekerja memberi mereka penyebaran perangkat lunak global yang hampir instan. Rata-rata, Quicksilver mendistribusikan sekitar 350 perubahan per detik.

Dan Quicksilver sangat cepat. Rata-rata, kami mencapai persentil ke-99 dari 2,29 untuk menyebarkan perubahan ke setiap komputer di seluruh dunia. Biasanya kecepatannya bagus. Lagi pula, ketika Anda menghidupkan fungsi atau menghapus cache, itu terjadi hampir secara instan dan di mana-mana. Mengirim kode melalui Pekerja Cloudflare dengan kecepatan yang sama. Cloudflare menjanjikan pelanggannya pembaruan cepat pada waktu yang tepat.

Tetapi dalam kasus ini, kecepatan memainkan trik pada kami, dan aturan berubah di mana-mana dalam hitungan detik. Anda mungkin memperhatikan bahwa kode WAF menggunakan Lua. Cloudflare menggunakan Lua secara ekstensif di lingkungan produksi dan kami telah membahas detail Lua di WAF . Lua WAF menggunakan PCRE secara internal dan menerapkan pelacakan balik untuk pencocokan. Ia tidak memiliki mekanisme pertahanan terhadap ekspresi yang di luar kendali. Di bawah ini saya akan berbicara lebih banyak tentang ini dan apa yang kita lakukan dengannya.

Sebelum penerapan aturan, semuanya berjalan dengan lancar: permintaan kumpulan dibuat dan disetujui, pipa CI / CD mengumpulkan dan menguji kode, permintaan perubahan dikirim sesuai dengan SOP, yang mengatur penyebaran dan rollback, dan penyebaran selesai.

Proses Penyebaran CloudFare WAF

Apa yang salah
Seperti yang saya katakan sebelumnya, kami menerapkan lusinan aturan WAF baru setiap minggu, dan kami memiliki banyak sistem perlindungan terhadap konsekuensi negatif dari penyebaran seperti itu. Dan ketika terjadi kesalahan, biasanya kombinasi dari beberapa keadaan. Jika Anda hanya menemukan satu alasan, ini tentu saja menenangkan, tetapi tidak selalu benar. Berikut adalah alasan yang bersama-sama menyebabkan kegagalan layanan HTTP / HTTPS kami.

Insinyur itu menulis ekspresi reguler yang bisa mengarah pada kemunduran yang berlebihan.
Sebuah alat yang dapat mencegah penggunaan berlebihan sumber daya prosesor yang digunakan oleh ekspresi reguler salah dihapus selama WAF refactoring beberapa minggu sebelumnya - refactoring diperlukan sehingga WAF mengkonsumsi lebih sedikit sumber daya.
Mesin regex tidak memiliki jaminan kompleksitas.
Test suite tidak dapat mengungkapkan konsumsi CPU yang berlebihan.
Prosedur SOP memungkinkan penyebaran global perubahan aturan yang tidak mendesak tanpa proses multi-langkah.
Rencana rollback membutuhkan perakitan WAF lengkap dua kali, yang memakan waktu lama.
Peringatan lalu lintas global pertama bekerja sangat terlambat.
Kami menunda memperbarui halaman status.
Kami memiliki masalah dalam mengakses sistem karena macet, dan solusinya tidak berhasil dengan baik.
Insinyur SRE telah kehilangan akses ke beberapa sistem karena kredensial mereka telah kedaluwarsa karena alasan keamanan.
Pelanggan kami tidak memiliki akses ke dasbor atau API Cloudflare karena mereka pergi melalui wilayah Cloudflare.

Apa yang telah berubah sejak Kamis lalu

Pertama, kami sepenuhnya menghentikan semua pekerjaan pada rilis untuk WAF dan melakukan hal berikut:

Memperkenalkan kembali perlindungan terhadap sumber daya prosesor berlebihan yang kami hapus. (Selesai)
Periksa secara manual semua 3868 aturan dalam aturan yang dikelola untuk WAF untuk menemukan dan memperbaiki kasus potensial lainnya dari pengulangan yang berlebihan. (Verifikasi selesai)
Kami menyertakan profil kinerja untuk semua aturan dalam rangkaian uji. (Diharapkan: 19 Juli)
Kami beralih ke mesin re2 atau Rust regex - keduanya memberikan jaminan saat runtime. (Diharapkan: 31 Juli)
Kami menulis ulang SOP untuk menerapkan aturan secara bertahap, seperti perangkat lunak lain di Cloudflare, tetapi pada saat yang sama memiliki kemampuan untuk penyebaran darurat global jika serangan sudah dimulai.
Kami sedang mengembangkan kemungkinan penarikan segera dashboard dan API Cloudflare dari wilayah Cloudflare.
Kami mengotomatiskan pembaruan halaman Status Cloudflare .

Dalam jangka panjang, kami meninggalkan Lua WAF, yang saya tulis beberapa tahun yang lalu. Kami memigrasikan WAF ke sistem firewall baru . Jadi WAF akan lebih cepat dan menerima tingkat perlindungan tambahan.

Kesimpulan

Kegagalan ini menyebabkan masalah bagi kami dan pelanggan kami. Kami dengan cepat bereaksi untuk memperbaiki situasi, dan sekarang kami sedang mengerjakan kesalahan dalam proses yang menyebabkan kegagalan, dan kami menggali lebih dalam lagi untuk melindungi diri dari masalah potensial dengan ekspresi reguler di masa depan dengan beralih ke teknologi baru.

Kami sangat malu dengan kegagalan ini, dan kami meminta maaf kepada pelanggan kami. Kami berharap perubahan ini memastikan bahwa ini tidak terjadi lagi.

Aplikasi. Pengulangan Ekspresi Reguler

Untuk memahami bagaimana ekspresi:

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

memakan semua sumber daya prosesor, Anda perlu tahu sedikit tentang cara kerja mesin regex standar. Masalahnya di sini adalah polanya .*(?:.*=.*) . (?: dan yang sesuai ) bukan grup yang menarik (yaitu, ekspresi dalam tanda kurung dikelompokkan sebagai satu ekspresi).

Dalam konteks konsumsi sumber daya prosesor yang berlebihan, pola ini dapat ditetapkan sebagai .*.*=.* . Dengan demikian, polanya terlihat tidak perlu rumit. Tapi yang lebih penting, di dunia nyata, ekspresi seperti itu (mirip dengan ekspresi kompleks dalam aturan WAF) yang meminta mesin untuk mencocokkan sebuah fragmen, diikuti oleh fragmen lain, dapat menyebabkan backtracking bencana. Dan inilah alasannya.

Dalam ekspresi reguler . berarti bahwa Anda harus mencocokkan satu karakter,. .* - mencocokkan nol atau lebih karakter "dengan rakus", yaitu, menangkap maksimum karakter, jadi .*.*=.* berarti mencocokkan dengan nol karakter atau lebih, kemudian mencocokkan dengan nol atau lebih banyak karakter, cari karakter literal =, cocok dengan nol atau lebih karakter.

Ambil garis uji x=x . Ini cocok dengan ungkapan .*.*=.*. .*.* .*.*=.*. .*.* hingga tanda sama dengan sesuai dengan x pertama (salah satu grup .* sesuai dengan x , dan yang kedua ke nol karakter). .* setelah = cocok dengan x terakhir.

Untuk perbandingan seperti itu, 23 langkah diperlukan. Grup pertama .* .*.*=.* Kisah "rakus" dan cocok dengan seluruh baris x=x . Mesin pindah ke grup berikutnya .* . Kami tidak lagi memiliki karakter yang cocok, jadi grup kedua .* Cocok dengan nol karakter (ini dibolehkan). Kemudian mesin menuju ke tanda = . Tidak ada lagi karakter (grup pertama .* Menggunakan seluruh ekspresi x=x ), tidak ada kecocokan yang terjadi.

Dan di sini mesin ekspresi reguler kembali ke awal. Dia pergi ke grup pertama .* Dan membandingkannya x= (bukan x=x ), dan kemudian mengambil grup kedua .* . Grup kedua .* Peta ke x kedua, dan sekali lagi kami tidak memiliki karakter tersisa. Dan ketika mesin mencapai = v .*.*=.* Sekali lagi, tidak ada yang terjadi. Dan dia mundur lagi.

Kali ini, grup .* Masih cocok dengan x= , tetapi grup kedua .* Bukan lagi x , tetapi nol karakter. Mesin mencoba menemukan simbol literal = dalam pola .*.*=.* , Tetapi tidak keluar (setelah semua, kelompok pertama telah menempatinya .* ). Dan dia mundur lagi.

Kali ini grup pertama .* mengambil x pertama. Tetapi kelompok kedua .* "Dengan rakus" menangkap =x . Sudah menebak apa yang akan terjadi? Mesin mencoba untuk mencocokkan literal = , gagal dan melakukan backtracking berikutnya.

.* x . .* = . , = , .* . . !

.* x , .* — , = = . .* x .

23 x=x . Perl Regexp::Debugger , , .