Cloudflare מוסיפה כלל חירום ל-WAF: לבדוק את הכיסוי ואת החריגים

Cloudflare הוסיפה ב-14 באוקטובר כלל חסימת חירום למערך Cloudflare Managed Ruleset. לפי החברה, המהלך הוא תגובה לניצול פעיל של חולשת הרצת קוד מרחוק (RCE) בפריימוורקים לפיתוח ווב. הצעד המעשי הבא לבעלי אתרים הוא לבדוק אילו כללים והגדרות מגינים בפועל על האתר.

הודעת העדכון אינה נוקבת בשמות הפריימוורקים שנפגעו, אינה מפרטת גרסאות פגיעות ואינה מפנה לתיקון (patch) מטעם הספק. לכן אי אפשר להסיק ממנה אם אתר מסוים פגיע. הקביעה של Cloudflare על ניצול פעיל היא גרסת החברה, ולא ראיה לכך שהאתר של קורא כלשהו הותקף.

לוודא איזו הגנה פועלת באתר

לפי ההודעה, מנגנון הזיהוי החדש נוסף ל-Cloudflare Managed Ruleset עם פעולת חסימה. התיעוד של Cloudflare לכללים מנוהלים מבחין בין מערך הכללים הזה לבין Free Managed Ruleset: מערך Cloudflare Managed Ruleset הרחב יותר זמין בתוכניות Pro, Business ו-Enterprise.

אין להסיק שהאתר מוגן רק מכך שהדומיין משתמש בשרתי השמות של Cloudflare. צריך לבקש ממי שמנהלים את החשבון לוודא שהתנועה הרלוונטית עוברת דרך ההגנה, שמערך הכללים המתאים מופעל ושהפעולה שהוא מבצע בפועל לא שונתה.

מתעדים את שם המארח (hostname), את מערך הכללים ואת התצורה שנבדקו. כך הרגעה כללית הופכת למשהו שגם מנהלי מערכת אחרים יכולים לאמת. אם האתר נמצא באחסון מנוהל, כדאי לשאול את ספק האחסון אילו חלקים ביישום ובנתיב התנועה נמצאים בשליטתו.

התיעוד של Cloudflare מסביר גם שחריגים ודריסות (overrides) יכולים לשנות אילו כללים רצים ומה הם עושים. חריג ישן שנוצר כדי לתקן טופס שבור ראוי לבדיקה חוזרת, אם הוא מדלג באופן גורף על בדיקות האבטחה של היישום.

לבדוק גם את היישום, לא רק את חומת האש

מסנן שיושב לפני האתר ותיקון ביישום עצמו הם שני אמצעי בקרה נפרדים. ההכרזה הזאת אינה מציינת גרסה מתוקנת להתקנה, ולכן צריך להיעזר בהודעות האבטחה הרשמיות של התוכנה שרצה בפועל באתר. אין לבחור תיקון לפי ניחוש לאיזה פריימוורק, שלא צוין בשמו, Cloudflare מתכוונת.

כדאי להחזיק רשימת מלאי של מערכת ניהול התוכן (CMS), הפריימוורקים, התוספים והיישומים הייעודיים שמתוחזקים באתר. כך אפשר לפעול על פי הודעות אבטחה עתידיות: מישהו יוכל להתאים מוצר וגרסה שצוינו בהודעה לרכיב שמותקן באתר, במקום להתחיל מהזיכרון.

אם לוגי האבטחה מציגים בקשות שנחסמו, מתעדים אותן לצורך בירור. בקשה חסומה כשלעצמה אינה מעידה על פריצה מוצלחת. באותה מידה, דוח שקט אינו הערכה מלאה של מצב היישום. ראיות לשינויים או לגישה לא מורשים יש להעביר למי שאחראים לטיפול באירועי אבטחה.

לוודא שפעולות הפרסום הרגילות עדיין עובדות

לאחר בדיקת הכלל, מנסים את הפעולות הרגילות שעליהן מסתמכים הקוראים וצוות העריכה: טעינת מאמר, כניסה לחשבון, שמירת טיוטה ושליחת טופס בדיקה מורשה. אם פעולה לגיטימית נחסמת, אוספים את פרטי האירוע הרלוונטיים ומצמצמים את הבירור לפני שנוגעים בהגנה.

כיבוי גורף של ההגנה לא צריך להיות הצעד הראשון בפתרון התקלה. מזהים את הבקשה שנפגעה ובוחנים עם מנהלי המערכת את התיקון המצומצם ביותר שמתאים למקרה.

מוסיפים את בדיקות התצורה והיישום לשגרת התחזוקה של האתר. אם איש אינו יודע להסביר מי אחראי עליהן, צריך להבהיר את האחריות לפני החידוש או המעבר הבא של האחסון.