הרשם, ספק האחסון, CDN: מי יכול באמת לפעול?

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

מהו רשם?

הרשם הוא הארגון שממנו נרכש שם דומיין כמו secure-login.example. הוא זה שרשם את השם הזה במרשם הדומיינים (.com, .net וכו') ויכול, בעקבות דיווח, להשעות אותו: השם מפסיק לפעול, לא משנה לאן הוא מפנה. כל הקישורים שכבר נשלחו בקמפיין פישינג הופכים ללא שמישים באופן מיידי, גם אם השרת מאחוריהם עדיין פועל.

מהו ספק אחסון?

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

מהו CDN?

CDN (רשת אספקת תוכן) היא רשת של שרתי ביניים, כמו Cloudflare, Akamai או Fastly, המוצבים לפני השרת האמיתי. היא מאיצה את התצוגה, מסננת חלק מהתעבורה הבלתי רצויה, והכי חשוב: היא מסתירה את כתובת ה-IP האמיתית של השרת המקורי מעיני מבקרים רגילים. CDN יכול להציג אזהרה למבקרים או לחסום גישה לדף, אך אינו יכול למחוק את האתר: הוא רק מעביר אותו בשם הבעלים האמיתי.

מי שולט במה?

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

דוגמה קונקרטית: אתר פישינג מאחורי Cloudflare

אתר מחקה דף התחברות של בנק בכתובת https://secure-login.example. חיפוש WHOIS לכתובת ה-IP שלו מחזיר... Cloudflare. במבט ראשון, אפשר לחשוב ש-Cloudflare מארח את האתר הזה. זה כמעט אף פעם לא נכון: Cloudflare (או CDN דומה) פועל רק כמתווך. השרת האמיתי, שבאמת מכיל את הדף המזויף, נמצא במקום אחר, אצל ספק אחסון שלא מופיע כלל בחיפוש ה-WHOIS הראשוני הזה.

מדוע דיווח רק ל-CDN עשוי לא להספיק

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

כיצד לזהות את ספק האחסון האמיתי

מספר רמזים מאפשרים לרוב למצוא את השרת המקורי מאחורי ה-CDN, ללא כלי ייעודי:

• היסטוריית DNS: חלק משירותי היסטוריית DNS שומרים לעיתים את כתובת ה-IP שהדומיין השתמש בה לפני המעבר מאחורי CDN. אם האתר ותיק, או שינה את ההגדרות שלו לאחרונה, ה-IP הישן עשוי עדיין להופיע שם.
• תת-דומיין נשכח: ארגונים גדולים מפעילים CDN באתר הראשי, אך לעיתים שוכחים תת-דומיין נלווה (mail., ftp., dev., webmail.) שעדיין מצביע ישירות על השרת האמיתי.
• כותרות ותעודות: חלק מהשרתים שהוגדרו בצורה שגויה מגיבים באופן שונה כאשר ניגשים אליהם ישירות לעומת דרך CDN, או חושפים תעודה המשויכת לשם אחר.
• כותרות דוא"ל: אם הפישינג הגיע בדוא"ל, כתובת ה-IP של השרת השולח (ראו כיצד לקרוא את הכותרות המלאות) שייכת לעיתים לאותו ספק אחסון כמו האתר, גם אם האתר מוגן על ידי CDN.

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

ניסוח הדיווח שלכם

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

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

למידע נוסף: ניתוח פישינג מההודעה ועד התשתית, מציאת כתובת ה-abuse@ של ספק האחסון, או הבנת תפקיד ה-DNS.