בוטים מהווים היום יותר מחצי מכלל התעבורה באינטרנט. חלק מהתעבורה הזו מועילה, כמו זחלנים של מנועי חיפוש שמאנדקסים את הדפים שלכם. חלק גדול ממנה לא. סקרייפרים גונבים לכם תוכן, בוטים שמנסים סיסמאות גנובות (credential stuffing) תוקפים את דף ההתחברות שלכם, ובוטים שצדים מלאי חוטפים מוצרים בקופה לפני שללקוחות אמיתיים בכלל יש סיכוי. הקושי האמיתי הוא לא רק לזהות בוטים רעים, אלא להבדיל אותם מבני אדם אמיתיים בלי לחסום בטעות לקוחות משלמים.
זה בדיוק האיזון העדין שחומת אש לאפליקציות ווב נבנתה כדי לספק. בואו נראה איך היא באמת עושה את זה.
למה תעבורת בוטים קשה יותר לסינון ממה שזה נשמע
לחסום בוט נשמע פשוט עד שמנסים בפועל. בוט יכול להשתמש באותם headers של דפדפן כמו בן אדם. הוא יכול להחליף בין אלפי כתובות IP. הוא אפילו יכול לפתור CAPTCHA בסיסי בעזרת שירותים אוטומטיים. במקביל, המבקרים האמיתיים שלכם אולי משתמשים ב-VPN, פרוקסי ארגוני, או תוספי דפדפן חריגים שגורמים גם להם להיראות קצת חשודים.
חומת אש לאפליקציות ווב צריכה למיין את כל הרעש הזה בזמן אמת, על כל בקשה בודדת, בלי להוסיף עיכוב מורגש. זו בעיה הרבה יותר מורכבת מאשר סתם בדיקת IP מול רשימה חסומה.
איך חומת אש לאפליקציות ווב באמת מבחינה בין בוטים לבני אדם
דפוסי התנהגות, לא רק חתימות
חומות אש מסורתיות מסתמכות בעיקר על חתימות ידועות, כמו מחרוזת user agent ספציפית או טווח IP מסומן. כללי חומת אש לאפליקציות ווב מודרנית הולכים צעד קדימה ומתבוננים בהתנהגות. בני אדם אמיתיים לוחצים על דברים, עוצרים לקרוא, מזיזים את העכבר, ולוקח להם כמה שניות בין טעינת דף לדף. בוטים נוטים לנוע בקווים ישרים. הם פוגעים בדפים במהירות לא אנושית, מדלגים על משאבים שדפדפן רגיל היה טוען כמו תמונות או CSS, וחוזרים על אותם דפוסי בקשה שוב ושוב.
כשה-WAF רואה לקוח שמבקש חמישים דפי מוצר בשנייה בלי שום זמן גלילה או קריאה, זה סימן התנהגותי חזק, גם אם כל header נראה לגיטימי.
הגבלת קצב עם הקשר
הגבלת קצב פשוטה לבדה הייתה פוגעת במשתמשים אמיתיים בזמן מבצע עמוס או גל תעבורה ויראלי. גישה חכמה יותר מיישמת הגבלות לפי נקודת קצה ולפי הקשר. דף התחברות אולי יאפשר חמישה ניסיונות בדקה לכל IP, בעוד דף רשימת מוצרים יאפשר הרבה יותר, כי התנהגות גלישה נראית שונה מהתנהגות של בדיקת סיסמאות. סוג כזה של הגבלת קצב תלוית הקשר הוא חלק מרכזי מהאופן שבו חומת אש לאפליקציות ווב שומרת על גורמים זדוניים בחוץ תוך מתן מעבר לגלי תעבורה לגיטימיים. הרחבנו על המנגנון הזה באיך הגבלת קצב וניקוי תעבורה עובדים יחד באירוח עם הגנת DDoS.
זיהוי מעבר לכתובת ה-IP
כתובות IP בלבד הן היום סימן חלש. רשתות פרוקסי ביתיות מאפשרות למפעילי בוטים לנתב תעבורה דרך אלפי כתובות IP ביתיות אמיתיות, מה שגורם לתעבורה להיראות מפוזרת גיאוגרפית ולגיטימית. WAF מיומן מסתכל לעומק: טביעות אצבע של TLS, בדיקות הרצת JavaScript, סדר ה-headers, ועקביות בין הדפדפן המוצהר להתנהגות בפועל. אם בקשה טוענת שהיא Chrome בטלפון אבל ה-handshake של TLS תואם לספריית סקרייפינג ידועה, אי ההתאמה הזו מסומנת.
אתגר-תגובה בלי חיכוך
כשה-WAF לא בטוח לגמרי, הוא לא חייב לבחור בין חסימה מוחלטת לבין העברת הבקשה בעיניים עצומות. הוא יכול להציב אתגר קליל, כמו חישוב JavaScript שדפדפן אמיתי פותר מיידית אבל סקריפט בוט בסיסי לא מצליח לפתור. זה קורה בצורה בלתי נראית למבקר ברוב המקרים. רק כשהתעבורה באמת מעורפלת, המשתמש רואה משהו כמו שלב אימות קצר, וגם אז זה אמור לקחת כמה שניות, לא דקות.
בוטים טובים עדיין צריכים דרך כניסה
לא כל מבקר אוטומטי הוא איום. זחלני מנועי חיפוש, מוניטורים לזמינות, ו-webhooks של שערי תשלום הם גם כן בוטים, וחסימתם פוגעת ב-SEO שלכם או בתהליך הקופה. חומת אש לאפליקציות ווב מכוונת כראוי שומרת רשימות אישור לבוטים טובים ידועים שמאומתים באמצעות בדיקת reverse DNS, לא רק מחרוזת user agent שכל אחד יכול לזייף. זו אחת הסיבות שקונפיגורציית WAF בניהול עצמי מסוכנת יותר משנראה. פספוס של זחלן לגיטימי אחד וגם דירוג החיפוש שלכם נפגע בשקט במשך שבועות לפני שמישהו שם לב. הרחבנו על הפשרה הזו בחומת אש לאפליקציות ווב מנוהלת מול מוגדרת עצמית.
מאיפה מגיעים חיוביים כוזבים (וכיצד להימנע מהם)
אפילו כללים מכוונים היטב לפעמים מסמנים אנשים אמיתיים. הגורמים הנפוצים כוללים:
- רשתות ארגוניות שבהן מאות עובדים חולקים כתובת IP יוצאת אחת, מה שמפעיל הגבלות קצב שנועדו לבוטים בודדים
- תוספי דפדפן או כלי פרטיות שמסירים headers שה-WAF מצפה לראות
- חוסמי פרסומות אגרסיביים שמשנים דפוסי בקשה בצורה שדומה לסקרייפינג
- דפדפני מובייל ישנים עם ספריות TLS מיושנות שנראות דומות למסגרות עבודה של בוטים
ניהול טוב של WAF פירושו בדיקה שוטפת של יומני חסימה והתאמת כללים במקום להגדיר אותם פעם אחת ולשכוח מהם. עברנו על התהליך הזה בפירוט בחיוביים כוזבים בחומת אש לאפליקציות ווב וכיצד לכוון אותם בלי לשבור את האתר.
מה זה אומר עבור הגדרת השרת שלכם
אם אתם מריצים כללי WAF משלכם על שרת בניהול עצמי, סוג כזה של כוונון דורש תשומת לב מתמשכת. אתם צריכים ראות לגבי אילו בקשות מקבלות אתגר או נחסמות, ויכולת להתאים במהירות כשמשהו נשבר עבור משתמשים אמיתיים. בהגדרה מנוהלת, זה מטופל עבורכם, ואזור האבטחה של השרת בדרך כלל נותן לכם ראות לרשימות IP של בוטים וכללי חומת אש מבלי לגעת ישירות בקובץ הגדרות. השילוב הזה של סינון אוטומטי ופיקוח נגיש הוא מה ששומר על תעבורת בוטים בחוץ בלי להפוך את דף הקופה שלכם למסלול מכשולים ללקוחות אמיתיים.
למבט רחב יותר על איך זה משתלב בשאר ההגנות שלכם, ראו את סקירת ה-WAF שלנו ואת פרטי הגנת ה-DDoS.
לסיכום
טיפול טוב בתעבורת בוטים הוא לא עניין של לחסום כמה שיותר. זה עניין של להבדיל בין איום ללקוח, תוך מילישניות, בלי שאף אחד מהם ירגיש בתהליך. ניתוח התנהגותי, הגבלות קצב תלויות הקשר, זיהוי מעמיק יותר, ואתגרים קלילים, כל אלה עובדים יחד כדי לאפשר את זה. אם ההגדרה הנוכחית שלכם בודקת רק IP ו-user agent, כנראה שהיא מאפשרת לבוטים מתוחכמים לעבור תוך שהיא חוסמת מדי פעם מבקרים לגיטימיים, וכדאי לתקן את זה מוקדם ולא מאוחר.
