כיצד להשתמש ב-Shodan כדי למפות ולנטרל את חולשות התשתית של הלקוחות שלכם

בעולם אידיאלי, לכל ארגון יש רשימת מצלאי (Inventory) מדויקת ומעודכנת בזמן אמת של כל כתובת IP, שרת, נתב ושירות שחשופים לאינטרנט. המציאות? המציאות היא כאוס. מחלקות שיווק מרימות שרתי וורדפרס זמניים שוכחות מהם, מפתחים פותחים פורטים ב-AWS כדי לעבוד מהבית בסופ"ש, ומיזוגים ורכישות מייצרים "חורים שחורים" של תשתיות לגאסי (Legacy) שאף אחד לא מתחזק.

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

במאמר זה נפרק את המתודולוגיה המקצועית של ניהול שטח תקיפה חיצוני (EASM, External Attack Surface Management) באמצעות Shodan. לא מדובר ב"האקינג", אלא במודיעין תשתיות גלוי ואקטיבי שמטרתו למצוא את הפגמים לפני שכלי הכופר (Ransomware) האוטומטיים יעשו זאת.

---

כלל ברזל לפני שמתחילים: חוקיות, אתיקה והרשאות

אני אגיד את זה בצורה הברורה והנוקשה ביותר: אל תחפשו לקוחות ב-Shodan ללא אישור מפורש וכתוב. למרות ש-Shodan אוסף מידע פומבי (Passive Reconnaissance מצידכם, שכן Shodan הוא זה שביצע את הסריקה האקטיבית), השימוש במידע הזה כדי להציג ללקוח פגיעויות צריך להיות מגובה בחוזה (Rules of Engagement). חיפוש פגיעויות אצל לקוח פוטנציאלי במטרה "להפחיד" אותו כדי שיסגור עסקה הוא פרקטיקה חובבנית, לא אתית, ולעיתים גובלת בתחום האפור המשפטי.

העבודה שלכם צריכה להיות חלק משירות מוגדר של Penetration Testing, שירותי CISO as a Service, או ניטור תשתית שוטף. ברגע שיש לכם את המנדט, עליכם להשתמש ב-Shodan ללא רחמים כדי להאיר כל פינה חשוכה.

---

מה Shodan באמת עושה? (זה לא "גוגל להאקרים")

הכינוי "גוגל של ההאקרים" עושה ל-Shodan עוול תדמיתי ומקצועי. גוגל זוחל (Crawls) על גבי פרוטוקולים כמו HTTP/HTTPS ומאנדקס תוכן מבוסס טקסט. Shodan, לעומת זאת, סורק את כל מרחב כתובות ה-IP הגלובלי (IPv4 וחלקי IPv6) על פני מאות פורטים שונים.

הוא לא מחפש את התוכן של אתר האינטרנט, אלא את הבאנרים (Banners). הבאנר הוא תעודת הזהות שהשירות מחזיר כאשר מישהו מתחבר אליו. זה יכול להיות שרת SSH שמכריז על הגרסה שלו, שרת RDP שחושף את תעודת ה-SSL והדומיין הפנימי שלו, או בקר תעשייתי (SCADA) שפולט נתוני מערכת גולמיים ללא שום הזדהות. Shodan אוסף את המטא-דאטה הזה, מקטלג אותו, ומאפשר לכם לשאול עליו שאלות מורכבות.

---

מתודולוגיית העבודה: מחיפוש רחב לזיהוי חולשות נקודתי

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

שלב 1: הגדרת ההיקף ומיפוי נכסים (Asset Discovery)

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

חיפוש לפי ארגון (Organization): ניתן לחפש את השם הרשמי של הארגון כפי שהוא מופיע ברישומי ה-IP. זה עובד היטב לארגונים גדולים.

org:"Client Company Name"

חיפוש לפי ASN (Autonomous System Number): אם ללקוח שלכם יש BGP routing משלו והוא ספק שירות או ארגון אנטרפרייז ענק, ה-ASN הוא מזהה מוחלט.

asn:AS12345

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

net:192.168.1.0/24

(כמובן, עם כתובות ציבוריות ולא פרטיות.)

חיפוש לפי תעודות SSL: זהו טריק קריטי. לעיתים לקוחות מארחים שירותים בענן (AWS, Azure) ואין להם כתובת IP קבועה שרשומה על שמם. אבל, הם כן משתמשים בתעודת ה-SSL הרשמית של החברה. Shodan מאפשר חיפוש בתוך פרטי התעודה:

ssl.cert.subject.CN:"*.clientdomain.com"

שלב 2: זיהוי תצורות שגויות ושירותים מסוכנים (Misconfigurations & Shadow IT)

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

ממשקי ניהול מרחוק (Remote Management):

שום שרת בארגון לא צריך לאפשר גישת RDP או SSH ישירה מהאינטרנט. נקודה. הכל צריך להיות מאחורי VPN, ZTNA (Zero Trust Network Access), או Bastion Host.

חיפוש לדוגמה בתוך טווח הלקוח:

net:203.0.113.0/24 port:3389

(מחפש RDP)

net:203.0.113.0/24 port:22

(מחפש SSH)

מסדי נתונים חשופים (Exposed Databases):

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

• Elasticsearch (בדרך כלל פורט 9200): שרתים אלו לרוב מכילים לוגים רגישים של מערכות. חיפוש תגובת 200 OK מאשר שהשרת לא דורש סיסמה.
• MongoDB (פורט 27017): Shodan יכול להראות לכם אילו בסיסי נתונים קיימים שם ומה הגודל שלהם.

דוגמה לשאילתה:

net:203.0.113.0/24 product:"Elasticsearch"

פאנלי ניהול של מערכות ליבה:

ראוטרים, חומות אש (Firewalls), ומערכות גיבוי. האם ממשק הניהול של ה-FortiGate של הלקוח שלכם פתוח לעולם מחוץ לפורט ה-VPN?

org:"Client Name" "Fortinet"

או מילות מפתח מתוך עמוד ההתחברות.

שלב 3: ציד חולשות ספציפיות (Vulnerability Hunting)

Shodan אינו סורק חולשות (Vulnerability Scanner) קלאסי כמו Nessus או Qualys, כיוון שהוא לא מבצע אימות אקטיבי של החולשה מול השרת (מה שעלול לגרום לנפילות). עם זאת, הוא כן מנתח את הבאנרים. אם שרת מודיע בגלוי "אני מריץ Apache גרסה 2.4.49", גרסה שידועה כפגיעה ל-Path Traversal חמור (CVE-2021-41773), Shodan (למנויי אנטרפרייז) יצליב את המידע עם מאגר ה-CVE ויציג זאת.

אתם יכולים ליזום חיפושים אקטיביים על סמך טכנולוגיות ישנות:

net:203.0.113.0/24 "Server: Microsoft-IIS/7.5"

שרת המריץ IIS 7.5 מעיד על מערכת הפעלה Windows Server 2008 R2, מערכת עתיקה שלא מקבלת עדכוני אבטחה, ומייצגת סיכון קריטי ואבן דרך קלה לתוקפים ברשת של הלקוח.

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

net:203.0.113.0/24 vuln:CVE-2023-46805

(שימו לב: פילטר vuln דורש הרשאת API מתאימה של Shodan.)

---

הפיכת נתונים גולמיים לאסטרטגיית הגנה (Remediation)

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

איך עושים את המעבר מ"מצאנו בעיה" ל"פתרנו אותה"?

אימות ללא ניצול (Validation without Exploitation):

Shodan מציג תמונת מצב מנקודת זמן מסוימת (Point in Time). ייתכן שהלקוח כבר סגר את הפורט אתמול, אך הנתונים ב-Shodan טרם התעדכנו (Caching). לפני שאתם מפעילים אזעקות, בצעו בדיקה נקודתית קלה, למשל סריקת Nmap זהירה וממוקדת ל-IP הספציפי, רק כדי לוודא שהשירות עדיין חשוף. בשום שלב אל תנסו לנצל (Exploit) את החולשה.

הבנת ההקשר (Contextualization):

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

תעדוף (Prioritization):

אל תציפו את הלקוח ברשימה של 50 ממצאים. חלקו אותם לפי רמת חומרה:

• קריטי: מסדי נתונים ללא סיסמה, RDP פתוח, ממשקי ניהול של חומות אש., לטיפול מיידי (SLA של שעות).
• גבוה: שרתים שמריצים תוכנות ישנות (EOL) עם פגיעויות ידועות מנצלות (CISA KEV)., לטיפול במסגרת מחזור העדכונים הקרוב ולבחינת הגדרות IPS בטווח המיידי.

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

אוטומציה וניטור רציף (Continuous Monitoring):

זה ההבדל המרכזי בין "סריקה שנתית" לשירות EASM אמיתי. תשתית ענן היא אלסטית. כתובות IP משתחררות ונרכשות מדי יום. עליכם להגדיר התראות שוטפות (באמצעות Shodan Monitor או חיבור API למערכת ה-SIEM/SOAR שלכם). ברגע שפורט חדש ובלתי צפוי נפתח בטווח של הלקוח, אתם צריכים לקבל על כך התראה בזמן אמת, ולא לחכות לבדיקה הידנית של החודש הבא.

---

סיכום

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

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