מפתח SaaS גילה שהפעלת Bot Fight Mode של Cloudflare עבור כל דומיין בחשבונו עיכבה את תעבורת ה-API במשך חודש שלם, מה שגרם ללקוחות משלמים שלא היו יכולים להשתמש בתכונות הליבה של המוצר שלו.

הבעיה צצה כאשר המפתח הבחין בשינוי פתאומי ושטוח במדדי השימוש. הרשמות חדשות המשיכו להגיע, אך מספר הסשנים (sessions) הפעילים הפסיק לגדול. לאחר שבועות של כתיבת קוד מחדש וניפוי שגיאות (debugging), התברר כי כפתור אבטחה בודד הוא האשם: Bot Fight Mode של Cloudflare סימן את ה-endpoint של ה-AWS Lambda של ה-SaaS עצמו כבוט זדוני וחסם אותו.

איך הגדרה אחת שברה שירות שלם

ה-stack של המפתח התבסס על קריאות server-to-server. פונקציית Lambda פנימית שלחה נתונים באופן קבוע חזרה לדומיין הציבורי של ה-SaaS, דפוס נפוץ בארכיטקטורות micro-service מודרניות. Bot Fight Mode מאתגר או חוסם בקשות שנראות כמו scrapers אוטומטיים, ובכך מגן על אתרים מבוססי תוכן מפני איסוף נתונים (data harvesting).

כאשר המצב הופעל בכל ה-zones, Cloudflare התייחסה לבקשה היוצאת של ה-Lambda כאל לקוח אוטומטי נוסף. הבקשה מעולם לא הגיעה לאפליקציה, ומכיוון שהחסימה התרחשה ב-edge, כלי הניטור של ה-SaaS לא זיהו שגיאה – התעבורה פשוט נעלמה. צריכת ה-CPU של המפתח ב-Cloudflare Workers זינקה, מה שהוביל אותו לחשוד ב-scraper חיצוני במקום ב-backend שלו עצמו.

רק לאחר חקירה מעמיקה בלוגים של Cloudflare הוא ראה ש-"Bot Fight Mode" חסם רשומות שתאמו לטווח ה-IP של ה-Lambda. הוא כיבה את התכונה עבור ה-zones המושפעים, ותעבורת ה-API חזרה למסלולה, מה שהחזיר את מדדי השימוש למצב רגיל.

למה הטעות הזו חשובה למפעילי SaaS

  • מוצרים מבוססי API זקוקים לערוצי server-to-server פתוחים. Bot Fight Mode מניח שתעבורת המקור היא בקשות של דפדפנים אנושיים לקבצי HTML, תמונות או נכסים סטטיים (static assets). פלטפורמות SaaS שחושפות APIs, webhooks או internal callbacks עלולות לסבול מהאטה (throttling) או מחסימה ללא קוד שגיאה נראה לעין שמגיע לשכבת האפליקציה.
  • הגדרות אבטחה גלובליות לעיתים רחוקות מתאימות לכל סוג עומס עבודה. החלת קונפיגורציה אחת של Cloudflare על כל הדומיינים מתייחסת לכל אתר כאילו הוא שותף לאותו מודל איומים. לאתרי תוכן, פורומים ו-SaaS back-ends יש דרישות אבטחה שונות מאוד.
  • כשלים שקטים שוחקים הכנסות. מערכת ההתראות של המפתח לא הופעלה מכיוון שהבקשות שנחסמו מעולם לא הגיעו לאפליקציה. רק ירידה במדדי מעורבות משתמשים (user-engagement) רמזה על הבעיה. ללא בדיקה פרואקטיבית של לוגים ברמת ה-edge, בעיות דומות עלולות להימשך מבלי שיבחינו בהן.

מה מפתחים יכולים לעשות כדי להימנע מאותו גורל

  1. בצעו ביקורת (Audit) לפרופיל התעבורה של כל zone. לפני הפעלת Bot Fight Mode, רשמו את סוגי הבקשות שהדומיין שלכם מצפה להן: דפדפנים אנושיים, קריאות API, webhook callbacks או קריאות שירות פנימיות. אם מי מהם חיוני לפונקציונליות הליבה, התייחסו ל-zone כ-"API-first" ושמרו על הגדרות מניעת בוטים מינימליות.
  2. בחנו שינויים בסביבת staging. Cloudflare מאפשרת לכם להחיל הגדרות על תת-דומיין בודד או על staging zone. ודאו שאוטומציה לגיטימית עדיין עובדת לפני שאתם משיגים את השינוי באופן גלובלי.
  3. נטרו לוגים ברמת ה-edge כחלק ממערך ה-observability שלכם. העבירו (Stream) את לוגי ה-firewall ומניעת הבוטים של Cloudflare ל-SIEM, Loki או כל שירות אגרגציה אחר. קשרו בין קפיצות במספר הבקשות שנחסמו לבין ירידות במדדי האפליקציה כדי לזהות כשלים שקטים בשלב מוקדם.
  4. הפכו את הגדרות האבטחה להפיכות. שמרו תוכנית rollback מתועדת. אם כלל חדש גורם להתנהגות בלתי צפויה, השבית אותו תחילה ואשר את השינוי לפני שתשקיעו זמן בפתרונות קוד עוקפים (workarounds).
  5. שאלו את השאלה הנכונה. במקום לשאול "איך אני יכול לעצור scrapers?", שאלו "האם הכלי הזה פותר את הבעיה הספציפית שאני רואה?". תכונת אבטחה שחוסמת scrapers עשויה שלא להיות התשובה המתאימה עבור SaaS הזקוק לגישה פתוחה ל-API.

הפרספקטיבה הרחבה יותר

Bot Fight Mode נותר בעל ערך עבור אתרים שצריכים להגן על תוכן סטטי מפני crawlers אגרסיביים. החיסרון שלו הוא חוסר היכולת להבחין בין scraper עוין לבין לקוח אוטומטי לגיטימי שפועל לפי אותם דפוסי HTTP.

שורה תחתונה

כשאתם מנהלים מספר דומיינים תחת חשבון Cloudflare אחד, התייחסו לכל אחד מהם כאל zone אבטחה נפרד. הפעילו את Bot Fight Mode רק במקומות שבהם התעבורה מונעת על ידי בני אדם בלבד; עבור עומסי עבודה של SaaS עתירי API, השאירו את ההגדרה כבויה או כוונו אותה בעדינות באמצעות חוקי firewall מותאמים אישית. לחיצה אחת יכולה להשתיק תעבורה לגיטימית באותה יעילות שבה היא יכולה לעצור scraper.