חדשות DNS ואבטחה · המקורות נבדקו ב־7 בנובמבר 2026
למנהלי Cloudflare One נוסף אות סיכון שקשור ל־DNS. לפני הפעלתו, כדאי לבדוק אם מדיניות הגישה הקיימת כבר מסתמכת על ציוני הסיכון של המשתמשים. זיהוי חדש עשוי להצדיק בדיקה, וגם להשפיע על הגישה ליישום באמצעות אותה מדיניות.
מה Cloudflare הכריזה
בעדכון מ־6 בנובמבר הוסיפה Cloudflare זיהוי Fast Flux כהתנהגות סיכון מוגדרת מראש במערכת לניתוח התנהגות משתמשים וישויות, UEBA. התכונה זמינה בתוכניות Enterprise. מנהלי המערכת מפעילים אותה תחת Risk score > Risk behaviors בלוח Zero Trust, ולאחר ההפעלה הזיהויים תורמים לציון הסיכון של המשתמש.
זהו מדריך בדיקה מעשי המבוסס על ההכרזה והתיעוד, ולא דיווח על הטמעה שביצענו בפועל.
למה שינוי בתשובות DNS עשוי להצדיק בדיקה
Fast Flux הוא שינוי מהיר של כתובות ה־IP המשויכות לשם מתחם. תוקפים יכולים להשתמש בו כדי לשמור על זמינות התשתית הזדונית ולהקשות על מעקב וחסימה של שרתים בודדים. ההסבר של Cloudflare על DNS מתאר את השיטה ואת השימוש בה בתשתיות זדוניות.
החלפת כתובות לבדה אינה מוכיחה שמכשיר או חשבון נפרצו. ההנחיה המשותפת של רשויות סייבר לאומיות בנושא Fast Flux מזהירה במפורש שגם שירותים לגיטימיים, ובהם רשתות להפצת תוכן ומאזני עומסים, עשויים להציג התנהגות דומה. בדיקה מועילה משלבת את תצפית ה־DNS עם ההקשר של היעד ושל הפעילות שיזמה את הבקשה.
בדקו את ההשלכות לפני ההפעלה
לפי תיעוד ציוני הסיכון של Cloudflare, התנהגויות מוגדרות מראש כבויות כברירת מחדל, ולאחר הפעלתן הן נבדקות בקרב משתמשי הארגון. התיעוד מתאר גם מדיניות Access שמשתמשת בציוני סיכון. ההכרזה החדשה אינה אומרת שהפעלת זיהוי Fast Flux יוצרת אוטומטית מדיניות חסימה.
התחילו ברשימה קצרה של היישומים שכבר משתמשים בציוני סיכון בהחלטות גישה. לכל יישום תעדו אחראי למדיניות, רמות סיכון שהכללים מתאימים להן והתוצאה הצפויה. בררו מול צוות התמיכה מי רשאי לבדוק זיהוי שנוי במחלוקת ולהחזיר גישה לפי הנוהל המאושר. אל תניחו שאפשר להגביל את המתג למשתמש ניסוי אחד; ודאו מול הספק שכל היקף מצומצם יותר אכן נתמך.
לדוגמה, נניח שליישום כבר קיימת מדיניות שמחריגה משתמשים בסיכון גבוה. אם זיהוי חדש מותיר משתמש בקטגוריה הזאת, המדיניות עשויה להשפיע על גישתו. לכן צריך לבדוק את המדיניות. אין בכך טענה שכל זיהוי Fast Flux מקבל את הסיווג High: ההכרזה אינה מפרטת את חומרת ברירת המחדל של התכונה.
תנו לאנליסט צעד המשך ברור
הכינו רישום בדיקה קצר, במקום להתייחס לשם ההתראה כאל מסקנה. הרשימה הבאה היא המלצה תפעולית, ולא תיאור של שדות שמובטח שיופיעו בכל אירוע של Cloudflare:
- שמרו את הקשר האירוע. תעדו זמן, משתמש או מכשיר, יעד ולוגים תומכים שזמינים לכם. שמרו את הראיות במערכות הפנימיות המאושרות.
- זהו מה יזם את הפעילות. האם המשתמש פתח דף, יישום שלח בקשת רקע, או שהפעילות עדיין אינה מוסברת? הצליבו מידע מתחנת הקצה ומהרשת כאשר הוא זמין.
- בדקו מה תפקידו של היעד. השוו אותו לשירותים צפויים ולמודיעין איומים עדכני. אל תפתחו אתר חשוד ממחשב עבודה רגיל רק כדי לראות מה יקרה.
- הפרידו בין התצפית למסקנה. כתבו מה ידוע, מה עדיין אינו ברור ואילו ראיות נוספות יצדיקו פעולת בלימה. דפוס DNS אינו מוכיח מה הייתה כוונת המשתמש.
- תעדו את ההשפעה על הגישה. אם מדיניות מנעה גישה, שמרו את הכלל שהתאים ואת פרטי האחראי לו. טפלו בזיהוי שגוי מאומת באמצעות בדיקה ממוקדת, בלי להחליש מדיניות רחבה רק כדי להעלים את ההתראה.
אל תמלאו את הפערים בתיעוד בהשערות
ההכרזה אינה מפרסמת ספי זיהוי, זמני הערכה או מדידות דיוק. דף ציוני הסיכון הכללי שנבדק לצורך המאמר עדיין אינו כולל שורה ייעודית ל־Fast Flux. ודאו מהי נראות התעבורה הנדרשת ואילו פרטי אירוע צפויים בהטמעה שלכם, במקום להעתיק הגדרות של התנהגות סיכון אחרת.
התיעוד הכללי של Cloudflare מציין גם שכיבוי התנהגות מפסיק ניטור עתידי, אך משאיר זיהויים קודמים משויכים למשתמש. תוכנית חזרה לאחור צריכה לכן להתייחס גם להגדרה וגם לבירור הממצאים שכבר נוצרו. קבעו אחראי, הגדירו כיצד בודקים זיהויים שגויים ובחנו את ההשלכות על מדיניות הגישה לפני ההפעלה.