(שלום רב קוראים יקרים – אם אתם מכירים מישהו שעובד עבור יצרנית של SSL VPN – בפיתוח תוכנה, ניהול מוצר וכדומה, אנא שלחו לו או לה קישור לפוסט הזה, בתקווה שהרעיון יצבור תשומת לב, יתקבל ולבסוף יקום לתחיה, ובכך ישפר את אבטחת המידע עבור כולנו)
הגרסה באנגלית של פוסט זה נמצאת כאן.
אמ;לק / תקציר
זהו רעיון שאני מעלה כעת, במטרה לשפר את האבטחה של SSL VPN, על ידי צמצום משטח התקיפה של שרת ה-SSL VPN.
הרעיון הוא להוסיף פונקציונליות של תוכנת לקוח Dynamic DNS (DDNS) לנקודת הקצה של תוכנת לקוח ה-SSL VPN, ובהתאם להגדיר את צד השרת של ה-SSL VPN לאפשר גישה רק למקורות שמאושרים מראש ברמת הרשת לתקשר עם רכיב השרת של ה-SSL VPN של ה-Gateway, על בסיס ערכי FQDN של לקוחות ה-DDNS.
פעולה זו תחסום מראש את רוב האינטרנט מלתקשר עם שרת ה-SSL VPN, ובכך תפחית משמעותית את משטח התקיפה שלו.
כשחושבים על זה הלאה – העיקרון הנ"ל טוב לכל רכיב שרת שצריך לקבל תעבורה נכנסת מכתובות IP לא קבועות – בין אם זה שרת Web, שרת SSH וכדומה.
ניסיתי למצוא פתרונות שמשתמשים בתפיסה זו, אך לא מצאתי כאלה.
ממה שכן מצאתי – כל השימושים בלקוח DDNS הם לטובת מערכות אשר פועלות בתפיסת שרת, כלומר הן מאזינות לתעבורה נכנסת יזומה, בכדי לתת שירות ללקוחות, בכדי שהלקוחות יוכלו למצוא אותן ולהגיע אליהן, גם אם כתובת ה-IP של מערכות אלו משתנה.
קיימים מוצרי אבטחה מסוג Gateway שתומכים בשימוש ב-FQDN כאובייקט בחוקי ה-Firewall שלהם, מה שאומר שניתן לממש את הרעיון הזה מבחינה טכנית כבר עכשיו, אבל אני חושב שיהיה קשה לנהל את זה בצורה כזו, וזה לא יהיה ניתן לניהול בכמויות גדולות (Not scalable). אני חושב שנדרש לכך פתרון שיטתי יותר, שיטפל גם בצד הלקוח וגם בצד שרת ה-DDNS – באופן מרכזי, ולכן אני חושב שיצרנים צריכים לשלב את הרעיון כחלק מהמוצרים והשירותים הרלוונטיים שלהם, כדי שניתן יהיה לנהל אותו כראוי על ידי הלקוחות שלהם.
רקע
שמתי לב שלאחרונה ישנם אירועים רבים בהם רכיבי SSL VPN של Security Gateways נפרצים בהצלחה, עקב סיבות שונות, בעיקר עקב חולשות תוכנה של תוכנת ה-Gateway.
חולשות הן בלתי נמנעות, הן תמיד יקרו, שכן איננו יכולים להבטיח תוכנה חסינת תקלות ובטוחה ב-100 אחוז.
כמו כן, SSL VPN, כתפיסה, משמש בעיקר כדי להעניק גישה מאובטחת מהאינטרנט לרשתות מקומיות, פרטיות ופנימיות, ולכן הוא חייב להיות פתוח לכל (או לרוב) האינטרנט, שכן הארגון אינו יכול לדעת מראש מאיזו כתובת IP הלקוחות יתחילו את התקשורת ל-Gateway, וכן מכיוון שחלק מנקודות הקצה של הלקוחות משנות את כתובת ה-IP שלהן מדי פעם, מסיבות שונות (ספק האינטרנט שלהם שינה את ה-IP שהוקצה להם, הם נוסעים ברכבת ומשנים רשתות סלולריות כשהם חוצים למדינה אחרת, וכדומה).
לכן, חשבתי, יש לנו כאן משטח תקיפה עצום בצד ה-Gateway, שפתוח באופן קבוע לכל האינטרנט, אז אין פלא שהוא נפרץ בהצלחה כל כך הרבה.
חשבתי לעצמי: חייבת להיות דרך טובה יותר ומאובטחת יותר לעשות זאת.
להלן מספר כתבות חדשותיות על חולשות ופריצות עדכניות יחסית ב-SSL VPN (ממוינות מהחדש לישן):
2025, August
Fortinet SSL VPNs Hit by Global Brute-Force Wave Before Attackers Shift to FortiManager
https://thehackernews.com/2025/08/fortinet-ssl-vpns-hit-by-global-brute.html
2025, August
SonicWall Investigating Potential SSL VPN Zero-Day After 20+ Targeted Attacks Reported
https://thehackernews.com/2025/08/sonicwall-investigating-potential-ssl.html
2025, April
Ivanti has recently patched a critical severity vulnerability found in its Connect Secure (ICS) VPN appliances which was allegedly being abused in the wild by Chinese state-sponsored actors
https://www.techradar.com/pro/security/ivanti-patches-serious-connect-secure-flaw
2025, March
VPN Vulnerabilities Become a Primary Weapon for Threat Actors Targeting Organizations
https://gbhackers.com/vpn-vulnerabilities-become-a-primary-weapon/
2025, January
Ivanti Connect Secure VPN Targeted in New Zero-Day Exploitation
https://cloud.google.com/blog/topics/threat-intelligence/ivanti-connect-secure-vpn-zero-day
2024, February
Exploitation Observed: Ivanti Connect Secure — CVE-2023-46805 and CVE-2024-21887
https://www.akamai.com/blog/security-research/ivanti-january-rce-cve-zero-day-exploitation-observed
2023, July
Researchers Develop Exploit Code for Critical Fortinet VPN Bug
Some 340,000 FortiGate SSL VPN appliances remain exposed to the threat more than three weeks after Fortinet released firmware updates to address the issue
https://www.darkreading.com/vulnerabilities-threats/researchers-develop-exploit-code-for-critical-fortinet-bug
2022, December
Fortinet Warns of Active Exploitation of New SSL-VPN Pre-auth RCE Vulnerability
https://thehackernews.com/2022/12/fortinet-warns-of-active-exploitation.html
הפתרון המוצע (בקווים כלליים, High level design)
הרעיון המרכזי לשימוש ב-DDNS הוא שאם אנו רוצים להעניק גישה מאובטחת ללקוחות שאיננו יכולים לדעת מראש מהי כתובת ה-IP שלהם, וגם אם אנו יודעים זאת בשלב מסוים – הכתובת יכולה להשתנות בכל עת, מכיוון שזה אינו חיבור VPN קבוע, עם IP קבוע של הלקוח. לכן, אנו משתמשים במערכת ה-DDNS כדי שתהווה שכבת קיבוע מהימנה (המורכבת מהדומיין של ה-FQDN ומשרת ה-DDNS), שאנו סומכים עליה לאמת את מכשיר הלקוח – ולכן אנו מוכנים לאפשר גישה ברמה הראשונה של הרשת לכתובות IP של לקוחות שאינן ידועות מראש, אך הן כאלה שיש להן תוכנה נדרשת מוקדמת (לקוח ה-DDNS) והן עברו בהצלחה אימות זהות (אפילו אם מדובר רק בזהות של מכשיר ולא של אדם) במערכת שאנו סומכים עליה (מערכת שרת ה-DDNS).
הרעיון הוא להגביל את מי שיש לו גישה לצד שרת ה-SSL VPN, על בסיס הרעיון הכללי הבא:
צד לקוח ה-SSL VPN
- הלקוחות שרוצים לגשת ולהשתמש בשרת ה-SSL VPN – יותקן אצלם, כחלק מתוכנת לקוח ה-SSL VPN שלהם (ואולי גם כחלק מתוכנת לקוח ה-EDR שלהם), רכיב של לקוח Dynamic DNS (DDNS)
- לקוח ה-DDNS יתקשר בצורה מאובטחת עם שרת ה-DDNS שלו (אני מניח שבאמצעות HTTPS), יבצע הזדהות מולו, וישלח לשרת ה-DDNS את זהות הלקוח שלו ואת כתובת ה-IP הציבורית שלו (ששרת ה-DDNS יכול גם לאחזר בעצמו, מעצם התקשורת מול הלקוח). פעולה זו צריכה להתבצע בכל פעם שכתובת ה-IP הציבורית של הלקוח משתנה, כדי לוודא ששרת ה-DDNS וה-Gateway תמיד יקבלו את ה-IP הנוכחי של הלקוח
-
- תוכנת לקוח ה-DDNS חייבת כמובן להיות מאובטחת – יש להצפין את פרטי ההזדהות של הלקוח לשרת ה-DDNS מקומית; התקשורת לשרת ה-DDNS צריכה להיות מוצפנת ומאומתת, שאילתות DNS עדיף שיהיו מוצפנות באמצעות DoH (DNS over HTTPS); צריכה להיות מוגנת מפני שינויים וכדומה
-
צד שרת ה-SSL VPN (ה-Gateway הארגוני)
- ה-Gateway יבצע, באופן שוטף או לפי דרישה, שאילתות DNS (מסוג Reverse, מבוסס רשומות PTR) מול אותו שרת/מערכת DDNS שבה משתמש לקוח ה-SSL VPN, כדי לאחזר את כתובות ה-IP הנוכחיות של לקוחות SSL VPN רלוונטיים
- ל-Gateway יהיה חוק Firewall, הקשור לפעילות ה-SSL VPN, שיאפשר גישה אליו מהאינטרנט, לא על בסיס כתובות IP מספריות, אלא על בסיס שמות FQDN ששרת ה-DDNS שולט ומנהל, אלה שמוצמדים ללקוחותיו (רצוי עם תמיכה ב-wildcards, לצורך גמישות טובה יותר בהגדרת האובייקט)
- לדוגמה, אובייקט המקור המותר של חוק ה-Firewall יהיה *.vpn-allowed.firm.com, וכל IP שמתורגם ל-FQDN תואם, יאושר (לדוגמה, johndoe.vpn.firm.com או serioussam.vpn.firm.com)
התקשורת (Session)
- הלקוח יתחיל תקשורת SSL VPN מבוססת https ל-Gateway
- ה-Gateway יקבל את החבילה הראשונה של התקשורת (עם דגל ה-SYN) ויבדוק את הערך של כתובת ה-IP המקורית הנכנסת, על בסיס חוק ה-Firewall לגישה לשרת ה-SSL VPN
- כתובת ה-IP המקורית הזו תיבדק (עדיף באמצעות שאילתת תרגום DNS PTR (כלומר IP ל-FQDN) מול שרת ה-DDNS או, פחות רצוי, מכיוון שהנתונים שלו עשויים להיות לא עדכניים, מקומית מול מטמון (cache) שנשמר מקומית מראש)
- רצוי מאוד לקיים תהליכים של Timeout ופסילת לקוחות DDNS לא פעילים, בכדי למנוע מתן גישה ללקוחות לא מורשים שקיבלו את ה-IP המקורי אם הלקוח האמיתי כבר לא משתמש ב-IP הזה, מכל סיבה שהיא
- אם יש התאמה – הלקוח יקבל אישור להמשיך בתקשורת – להשלים את התקשורת TCP, להגדיר את תקשורת ה-TLS, לאמת ולאחר מכן ליצור את חיבור ה-SSL VPN
- אם אין התאמה – תהליך הערכת חוק ה-Firewall ימשיך לשאר חוקי ה-Firewall, ובאופן אידיאלי יגיע בסופו של דבר לחוק האחרון, חוק ה-cleanup / deny-all, שיחסום את התקשורת, ובכך יחסום כל תקשורת נוספת מצד הלקוח לשרת ה-SSL VPN, מה שלמעשה אומר חסימת כל כתובת IP שלא מחזיקה כרגע בזהות לקוח DDNS מותר ופעיל, וזה כנראה רוב האינטרנט, מה שאומר רוב, אם לא כל, התוקפים המזדמנים.
נקודות אפשריות נוספות:
מערכת שרת ה-DDNS
- אני חושב שרצוי לא להשתמש במערכת שרת DDNS שהיא חלק מה-Gateway, התקן שרת ה-SSL VPN – מכיוון שהיא חושפת את המכשיר לכל האינטרנט באמצעות ממשק שרת אינטרנט/DNS נוסף, וזה נוגד את מה שבעצם אנחנו מנסים להשיג כאן מלכתחילה
- כמו כן, אני חושב שפחות רצוי להשתמש במערכת/שירות DDNS של צד שלישי, אלא אם כן מדובר בשירות מאובטח מאוד
- באופן אידיאלי, מערכת ה-DDNS תהיה שירות ענן של אותו יצרן התקן ה-Security Gateway, כדי להשיג, כך יש לקוות, יותר תאימות, יכולת פעולה הדדית (interoperability) ואבטחה.
- כמובן, תפיסה זו מוסיפה למצב הדברים הקיים – יותר מורכבות, ניהול וצורך בהקשחה, אבל אני חושב שהאבטחה הנוספת שווה את זה
תכונות "אפס אמון" (Zero Trust) שניתן להוסיף:
- IP reputation – כדי לחסום גישה מראש למקורות שידועים כעוינים או חשודים, או במקום לחסום – להוסיף בדיקות אבטחה נוספות או הגבלות על השימוש מצד הלקוח
- חסימת התקשורת אם ה-IP הציבורי של הלקוח השתנה במהלך תקשורת פעילה, מה שיחייב את הלקוח להתחיל תקשורת חדשה מההתחלה
- חסימת לקוחות אם ה-IP הציבורי שלהם משתנה מהר מדי/בתדירות גבוהה מדי או שכתובת ה-IP הציבורית שלהם לא מדווחת בזמן (אם יש דרישה טכנית מהלוגיקה של ה-DDNS לעדכונים מתוזמנים חוזרים ונשנים מלקוח ה-DDNS לשרת שלו)
- בדיקת הגדרות מקומיות כמו אם הלקוח מוגדר כנתב (IP Forwarding), אם יש שימוש בשרת פרוקסי, אם יש שימוש ב-VPN אחר במקביל, וכדומה (אם כי זה גולש יותר לכיוון פונקציונליות של EDR)
זה הכל, חברים. אני מקווה שאהבתם, ואם כן – אנא הפיצו את הקישור לפוסט הזה, לאנשים רלוונטיים שיכולים להביא את הקונספט הזה לחיים.