מומחה אבטחת מידע רשום, סתיו Reiwa 5, שאלת אחר-הצהריים 2 — קבצים שיוצאים מ-Wi-Fi לאורחים

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

ועדיין אפשר להוציא קבצים עסקיים.

שאלת אחר-הצהריים 2 בסתיו שנת Reiwa 5 (2023) של בחינת מומחה אבטחת מידע רשום (情報処理安全確保支援士) בוחנת את החורים שעדיין נשארו בחברת הביגוד M, אחרי כל הטיפולים האלה.¹ המאמר הזה הוא השני בסדרה אחרי הפירוש לשאלה 1 (XSS מאוחסן), וההיקף עובר מיישום ווב אל הרשת הפנימית ואימות קצה.

בעוד ששאלה 1 שאלה «איפה עקפו את הטיפולים שסודרו ביישום הווב», שאלה 2 שואלת «איזה היקף התכוון התכנון של הטיפולים להגן עליו». אף אחד מטיפולי M אינו שגוי. אבל כשבודקים אחד-אחד את ציון ההיקף שאותו הם שומרים, מיד מחוץ לו נשאר פתוח.

מה מקבלים במאמר הם דוגמאות תשובה לכל סעיף ואת הבסיס שלהן, ועוד נקודות בדיקה שאפשר לקחת לשטח בשלושה תחומים: רשת אלחוטית, אישור שרת, והגבלת כתובת IP מקור. מי שקורא לקראת הבחינה יכול להתחיל בסעיפים לפי שאלה; מי שצריך רק את המבט המעשי יכול להתחיל מפרקים 11 ו-12 והרצף יישאר מובן.

1. השורה התחתונה קודם

• הפרצה הייתה חדר הישיבות. M אסרה הכנסת מחשבים אישיים, אבל האיסור היה על חדר העבודה בלבד, וחדר הישיבות היה מחוץ להיקף. בחדר הישיבות טסות גם הרשת האלחוטית לעובדים וגם זו לאורחים
• לעובד יש שני נתיבי הוצאה. שיטה שמזייפת כתובת MAC ומתחברת לרשת האלחוטית לעובדים, ושיטה שפשוט מתחברים לרשת האלחוטית לאורחים. השנייה קלה בהרבה; כל מה שצריך הוא המפתח המשותף מראש שמחלקים לאורחים
• שירות האחסון בענן (שירות B) הוגבל ל«כניסה רק מכתובת ה-IP הגלובלית של M». אבל גם תעבורת הרשת האלחוטית לאורחים מתורגמת באותו NAT לאותה כתובת גלובלית, ולכן ההגבלה עוברת. הגבלת כתובת IP מקור מתירה לא את המחשב אלא את כל מי שחולק את היציאה
• AP מזויף + אתר מזויף מצד תוקף חיצוני נעצרים באימות אישור שרת. מה שפועל הם «האם רשות אישורים מהימנה הנפיקה» ו«האם שם השרת באישור תואם את היעד». לפי הערות הציון של IPA, שיעור התשובות הנכונות לשאלה שביקשה את שתי הנקודות האלה היה נמוך
• גם אם מקלידים בטעות http://, HSTS מחליף ל-HTTPS ואז מתחבר, ולכן שוב מתקבלת שגיאת אישור. ובמארח עם HSTS אסור להציג למשתמש אפשרות להתעלם מהאזהרה ולהמשיך
• גם פונקציית שיתוף הקבצים הלגיטימית הופכת לנתיב הוצאה. מספיק לציין את כתובת הדואר הפרטית ככתובת המשתף החיצוני. הייתה אישור ממונה, אבל היו ממונים שלא בדקו את היעד
• שלושת עמודי הטיפול: להעביר את הרשת האלחוטית לעובדים ל-EAP-TLS ולאמת באישור לקוח לכל מחשב, ולשים את המפתח הפרטי ב-TPM כך שאי אפשר להוציא אותו ממחשב העבודה. לנתק את הרשת האלחוטית לאורחים מרשת M (או להפריד את כתובת ה-IP הגלובלית ביציאה). ולמחוק VLAN, כללי סינון ו-SSID שאינם בשימוש

מפת הידע של המאמר

המאמר הזה הוא פירוש שמסדר סקירת תכנון סביב רשת אלחוטית ואישור שרת, על בסיס שאלת אחר-הצהריים 2 בסתיו שנת Reiwa 5 של בחינת מומחה אבטחת מידע רשום. ל-WPA2-PSK, שבו כולם חולקים אותו מפתח, יש חולשה שכל מי שיודע את המפתח יכול להקים AP מזויף (evil twin) שאי אפשר להבדיל מהאמיתי, אבל עם אימות אישור שרת ו-HSTS כניסה לאתר מזויף אינה מתקיימת. בהוצאה בידי עובד, מול זיוף כתובת MAC הטיפול הוא EAP-TLS שמשתמש באישור לקוח וב-RADIUS, ומול בעיית הגבלת כתובת IP מקור שעוברת ביציאת NAT שמשותפת לכמה רשתות הטיפול הוא הפרדת רשת האורחים. אחסון המפתח הפרטי ב-TPM כך שאי אפשר להוציא אותו הוא המפתח לכך שאימות באישור יפעל בפועל.

flowchart LR
    accTitle: מפת הידע של מומחה אבטחת מידע רשום, סתיו Reiwa 5, שאלת אחר-הצהריים 2 (רשת אלחוטית ואישור שרת)
    accDescr: תרשים שמראה איך חולשת המפתח המשותף של WPA2-PSK מזמינה זיוף כתובת MAC והתקפת evil twin, איך אימות אישור שרת ו-HSTS מונעים כניסה לאתר מזויף, איך EAP-TLS עם RADIUS ומפתח פרטי ב-TPM מממשים אימות לפי מחשב, ואת מגבלת הגבלת IP מקור שחולקים ב-NAT ואת תיקונה.
    wpa2_psk["WPA2-PSK"]
    eap_tls["EAP-TLS"]
    evil_twin["התקפת evil twin (תאום השטן)"]
    phishing["פישינג"]
    mac_address_filtering["סינון כתובות MAC"]
    mac_address_spoofing["זיוף כתובת MAC"]
    server_certificate_validation["אימות אישור שרת"]
    certificate_chain["שרשרת אישורים"]
    root_ca["אישור CA שורש"]
    certificate_revocation_check["בדיקת ביטול של אישור"]
    trust_anchor_risk["סיכון לניצול לרעה של נקודת האמון"]
    hsts["HSTS (HTTP Strict Transport Security)"]
    hsts_preload_list["רשימת ה-preload של HSTS"]
    client_certificate["אישור לקוח"]
    radius["RADIUS"]
    ieee_802_1x["IEEE 802.1X (EAP over LAN)"]
    network_policy_server["Network Policy Server (NPS)"]
    private_key["מפתח פרטי"]
    tpm["TPM"]
    key_exfiltration_risk["סיכון להוצאת מפתח פרטי"]
    shared_egress_ip_bypass["עקיפת הגבלת IP מקור דרך IP יציאה משותף"]
    nat["NAT (תרגום כתובות רשת)"]
    guest_network_isolation["הפרדת רשת האורחים"]
    unused_config_cleanup["מחיקת הגדרות שאינן בשימוש"]
    source_ip_restriction["הגבלת כתובת IP מקור"]
    wpa2_psk -->|"עלול לגרום ל"| evil_twin
    evil_twin -.->|"עלול לגרום ל"| phishing
    mac_address_filtering -->|"שימוש לא מומלץ ל"| mac_address_spoofing
    eap_tls -->|"מענה מומלץ ל"| mac_address_spoofing
    server_certificate_validation -.->|"מונע"| phishing
    server_certificate_validation -->|"משתמש ב"| certificate_chain
    server_certificate_validation -->|"משתמש ב"| root_ca
    server_certificate_validation -.->|"משתמש ב"| certificate_revocation_check
    root_ca -.->|"עלול לגרום ל"| trust_anchor_risk
    hsts -.->|"מונע"| phishing
    hsts -->|"מחייב"| server_certificate_validation
    hsts_preload_list -.->|"מצמצם"| evil_twin
    eap_tls -->|"משתמש ב"| client_certificate
    eap_tls -.->|"משתמש ב"| radius
    eap_tls -.->|"משתמש ב"| ieee_802_1x
    network_policy_server -->|"מממש את"| radius
    client_certificate -->|"מחייב"| private_key
    private_key -.->|"נשמר ב"| tpm
    tpm -.->|"מונע"| key_exfiltration_risk
    shared_egress_ip_bypass -.->|"מחייב"| wpa2_psk
    nat -->|"עלול לגרום ל"| shared_egress_ip_bypass
    guest_network_isolation -->|"מונע"| shared_egress_ip_bypass
    guest_network_isolation -->|"צריך לקדום ל"| unused_config_cleanup
    source_ip_restriction -.->|"אינו מתיישב עם"| nat

בתרשים, קו מלא מציין קשר שמתקיים תמיד וקו מקווקו מציין קשר מותנה (תנאי ההתקיימות מפורטים בהסבר של כל קשר בעמוד המפורט). רשימת כל הקשרים (סך הכול 24, עם אסמכתה ורמת ודאות) והגדרות המושגים המרכזיים מרוכזות בעמוד המפורט של מפת הידע (ביפנית). נתונים: JSON-LD / Turtle

2. על החומר — המקור, ואיך המאמר מטפל בו

השאלה היא זו:

מקור: בחינת מומחה אבטחת מידע רשום, סתיו שנת Reiwa 5, אחר-הצהריים, שאלה 2

IPA קובעת שלגבי שאלות בחינה שפורסמו אין צורך באישור או בתשלום, אלא אם החוק קובע אחרת. אבל זכויות היוצרים לא ויתרו עליהן, ויש לציין את המקור בפורמט «שנה, מועד, סוג בחינה, חלוקת זמן, מספר שאלה וכו’», ואם שינו חלק מהשאלה — לציין גם זאת.²

במאמר אין העתקה כמות שהיא של האיורים מהחוברת. במקום זאת יש איורים מקוצרים וסיכומים שכתבנו בהיקף הדרוש להסבר המנגנון. גם נוסח הסעיפים ודוגמאות התשובה מטופלים כסיכום. את חוברת השאלות, דוגמאות התשובה והערות הציון אפשר להוריד בחינם מאתר IPA, ומומלץ לקרוא עם המקור פתוח ליד.^{1 3 4}

התאמה בין הסעיפים למאמר

אפשר להתחיל מהסעיף שרוצים לפתור.

תיאור החוברת, ואיך המאמר מטפל בו

כדי שאפשר יהיה להצליב מול המקור, זה מה שנעשה בכל חלק.

3. זירת השאלה — מה M «כבר עשתה»

M היא חברת בת של L, חברת ביגוד עם 100 עובדים. בניין המשרד פונה לשדרה סואנת בטוקיו. המשפט הזה יחזור בהמשך.

בשנה הקודמת עובד של M שמר קובץ עיצוב מוצר סודי משרת הקבצים הפנימי על USB והביא אותו למתחרה. בעקבות הנחיית חברת האם L מתקדם עדכון אבטחה. שלושת השינויים שכבר בוצעו:

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

האירוע הקודם היה הנתיב «שרת קבצים פנימי» → «USB», ולכן סגרו את שני הקצוות. ההיגיון מחזיק.

תצורת הרשת

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

בהיקף הדרוש להסבר, הצורה היא זו:

flowchart LR
    accTitle: תצורת הרשת של חברת M
    accDescr: הרשת האלחוטית לאורחים, הרשת האלחוטית לעובדים ורשת השרתים מומרות ב-NAT של אותו FW לכתובת IP גלובלית אחת ויוצאות לשירות B
    subgraph M["הרשת הפנימית של חברת M"]
        direction TB
        G["רשת אלחוטית לאורחים<br/>192.168.10.0/24<br/>(רק ה-AP בחדר הישיבות)"]
        E["רשת אלחוטית לעובדים<br/>192.168.20.0/24<br/>(חדר עבודה וחדר ישיבות)"]
        S["רשת שרתים<br/>192.168.30.0/24<br/>DHCP, DNS, ספרייה"]
        FW["FW<br/>NAT ממיר את המקור<br/>לכתובת IP גלובלית<br/>אחת"]
        G --> FW
        E --> FW
        S --> FW
    end
    FW --> B["שירות B<br/>(אחסון ענן)"]
    FW --> I["אינטרנט"]

איור 1: הרשת האלחוטית לאורחים, הרשת האלחוטית לעובדים ורשת השרתים יוצאות לאינטרנט ב-NAT של אותו FW ככתובת IP גלובלית אחת.

המפרט שחשוב לסעיפים:

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

שמתם לב שהכלל השני כותב «לחדר העבודה»? חדר הישיבות אינו כתוב.

איך השאלה מתקדמת

גב’ Y ממחלקת מערכות המידע, בסיוע מר S — מומחה אבטחת מידע רשום בחברת האם L — בודקת אם הטיפול בהוצאת קבצים משירות B מספיק. השניים מפרידים בין הוצאה בידי תוקף חיצוני לבין הוצאה בידי עובד. סעיף 1 הוא הראשון, סעיף 2 השני, סעיף 3 הוא הצעת הטיפול.

4. Wi-Fi מזויף ואתר מזויף — סעיפים 1(1)(2)

גב’ Y מעלה תחילה תרחיש שבו אורח שהשתמש ברשת האלחוטית לאורחים מתחבר אליה כתוקף מקרבת M וניגש לשירות B.

התרחיש מתקיים כי שיטת האימות היא WPA2-PSK. PSK ‏(Pre-Shared Key, מפתח משותף מראש) הוא, כשמו, אופן שבו כולם חולקים אותו מפתח. המפתח המשותף מראש של הרשת לאורחים נועד להיאמר לאורחים. ברגע שאמרו אותו, אין דרך לבטל את זה שהאדם יידע אותו גם להבא (מלבד לשנות לכולם). ובניין המשרד פונה לשדרה סואנת, ולכן הגל מגיע גם מחוץ למבנה.

תשובת מר S ברורה. כדי להיכנס לשירות B נדרשים [a] מזהה משתמש ו-[b] סיסמה. זו דוגמת התשובה לסעיף 1(1) (סדר חופשי). חיבור לרשת האלחוטית עצמו אינו כניסה לשירות B.

AP מזויף ואתר מזויף

אז גב’ Y מעמיקה. מה לגבי שיטה שמכינים AP מזויף באותן הגדרות כמו ה-AP של הרשת לאורחים, ואתר מזויף באותו URL כמו שירות B, מזייפים DNS, וגונבים מזהה וסיסמה. אם שמים את ה-AP המזויף ליד M, עובד של M עלול לחבר בטעות את מחשב העבודה ל-AP המזויף, לנסות לגשת לשירות B, להגיע לאתר המזויף, ולהיכנס.

זה evil twin («תאום השטן»). אם מקימים AP באותו SSID ובאותו מפתח משותף מראש כמו הרשת לאורחים, מהמחשב אי אפשר להבדיל בינו לבין ה-AP הלגיטימי. ב-WPA2-PSK כל מה שהמחשב יכול לאשר על ה-AP הוא ש«הוא יודע את אותו מפתח משותף מראש». AP שלא יודע את המפתח לא יכול לסיים את הליך החיבור, ולהפך — כל מי שיודע את המפתח יכול להיות «ה-AP האמיתי». מפתח שמחלקים לאורחים צריך לראות כמפתח שמחולק גם לתוקף.

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

• אישור השרת הזה אינו אישור שרת שהונפק על ידי רשות אישורים מהימנה (משבצת c)
• שם השרת הרשום באישור השרת הזה שונה משם השרת שאליו מתחברים (משבצת d)
• אישור השרת הזה בוטל
• פג תוקף אישור השרת הזה

שני התחתונים היו כתובים בחוברת מההתחלה, ואת שני העליונים (משבצות c ו-d, עד 40 תווים, סדר חופשי) עונים בסעיף 1(2).

sequenceDiagram
    accTitle: AP מזויף ואתר מזויף נעצרים באימות אישור
    accDescr: חיבור HTTPS של עובד דרך AP מזויף נכשל כי האישור לא הונפק על ידי רשות אישורים מהימנה או ששם השרת אינו תואם, ומסך הכניסה אינו מוצג
    autonumber
    participant U as מחשב העבודה של העובד
    participant F as AP מזויף ואתר מזויף<br/>(תוקף)
    participant B as שירות B (לגיטימי)

    Note over F: מקימים AP באותו SSID ובאותו<br/>מפתח משותף מראש כמו הרשת לאורחים
    U->>F: חיבור בטעות ל-AP המזויף
    Note over F: מזייפים DNS ומפנים את שם<br/>הדומיין של שירות B לאתר המזויף
    U->>F: חיבור ב-HTTPS ל-URL של שירות B
    F-->>U: אישור השרת של האתר המזויף
    Note over U: האימות נכשל<br/>· לא הונפק על ידי רשות אישורים מהימנה<br/>· שם השרת באישור שונה מהיעד
    Note over U: מציגים שגיאה שהחיבור אינו בטוח<br/>מסך הכניסה אינו מוצג
    Note over U,B: מלכתחילה אין תקשורת<br/>עם שירות B הלגיטימי

איור 2: גישת HTTPS דרך AP מזויף נכשלת באימות אישור השרת; מסך הכניסה אינו מוצג.

מה אימות האישור בודק

הערות הציון כותבות על הסעיף הזה כך:

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

גם מי שיודע ש«מופיעה שגיאת אישור» התקשה לפרק מה נבדק ולמה זה נכשל לארבעה סעיפים. אם מסדרים את ארבעת הסעיפים באיור 2 לפי «לשם מה הבדיקה»:

מבחינת התוקף, שני העליונים הם חומה שאי אפשר לעבור. אישור בחתימה עצמית נופל בראשון; גם אישור חינמי לגיטימי לדומיין שלו (למשל b-service.example.net) נופל בשני, כי היעד הוא דומיין שירות B. אישור לשם הדומיין של שירות B אפשר להשיג רק אם מנהלים את הדומיין של שירות B. הצירוף של שתי הנקודות האלה הוא ליבת מנגנון האישורים.

הליך אימות נתיב האישור מוגדר ב-RFC 5280,⁵ והליך התאמת השם באישור לשם היעד ב-RFC 6125.⁶

ארבעת הסעיפים אינם פועלים באותו חוזק

כאן מפרידים בין תשובת הבחינה להתנהגות דפדפן אמיתית. ארבעת הסעיפים הם מה שאיור 2 בשאלה מונה כ«פירוט שגיאה שעשוי להיות מוצג»; אסור לקרוא שכל דפדפן בודק את הארבעה באותה ודאות.

מנפיק, שם שרת ותוקף נקבעים מהמידע שביד ברגע קבלת האישור, ולכן תמיד מאומתים. גם מה שעוצר את התקיפה בשאלה הם השלושה האלה.

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

• Chrome בדרך כלל אינו מבצע בדיקת OCSP או CRL מקוונת. במקום זה הוא מפיץ CRLSet — רשימה מוגבלת שמטרתה העיקרית לחסום אישורים במהירות בחירום — ורק חלק מרשימות הביטול של רשויות האישורים נכנס לכל מהדורה⁷
• גם במימושים ששואלים OCSP נפוצה תצורה שעוברת את החיבור כשאין תשובה (soft-fail)

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

מלכודת בשטח — מי מחליט מי היא «רשות אישורים מהימנה»

מכאן והלאה זה מחוץ לנוסח השאלה. הסעיף הראשון בטבלה תלוי בבמה אותו מחשב סומך. רשימת האמון נמצאת בדפדפן או במערכת ההפעלה; ב-Windows זה «רשויות אישורי שורש מהימנות» במאגר האישורים.

כלומר במצבים האלה הבדיקה הראשונה תעבור:

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

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

לבדיקה השנייה (התאמת שם השרת) יש נקודת זהירות נפרדת בשטח. מול תקיפה שבה המשתמש מבלבל שם דומיין, האישור חסר אונים. אם התוקף רוכש דומיין מבלבל כמו b-serv1ce.example.com ומשיג לו אישור לגיטימי, הדפדפן לא יציג שגיאה. מה שהאישור מבטיח הוא «שם השרת ביעד תואם את שם השרת באישור», לא «שם השרת הזה הוא היעד שהמשתמש התכוון אליו». את הצעד האחרון בלי להסתמך על עין המשתמש ממלאים שיטות כמו מפתחות גישה (WebAuthn) שבהן המאמת בודק את המקור בעצמו. פירוט בלמה מפתחות גישה בטוחים.

5. למה זה נעצר גם כשמקלידים http:// — סעיף 1(3)

גב’ Y לא מוותרת. במצב מחובר ל-AP מזויף, אם העובד מקליד בטעות http:// בכתובת שירות B בדפדפן, אולי הודעת השגיאה לא תופיע?

שאלה סבירה. בחיבור HTTP אישור שרת כלל לא נכנס לתמונה. נראה שהאתר המזויף יוכל להציג מסך כניסה בלי שום שגיאה.

תשובת מר S: «זה בסדר. HSTS מופעל, ולכן גם אז תופיע אותה הודעת שגיאה כמו קודם». סעיף 1(3) שואל את תנועת הדפדפן עד רגע לפני הצגת הודעת השגיאה, עד 60 תווים.

דוגמת התשובה: «מחליפים את הגישה ב-HTTP בגישה ב-HTTPS וניגשים. אחר כך מקבלים אישור שרת מהאתר המזויף».

מה קורה בתוך הדפדפן

HSTS ‏(HTTP Strict Transport Security) הוא מנגנון שבו האתר מכריז בכותרת Strict-Transport-Security «מכאן והלאה בואו לכאן רק ב-HTTPS», והדפדפן זוכר זאת. זה מוגדר ב-RFC 6797.⁸

כשמנסים לגשת ב-http:// למארח שכבר זכור, הדפדפן פועל כך:

1. מחליף את סכימת ה-URL מ-http ל-https. אם צוין פורט 80, ממיר ל-443 (RFC 6797 סעיף 8.3)
2. מתחבר ב-HTTPS כתוצאה מכך. בנקודה זו DNS מזויף, ולכן היעד הוא האתר המזויף
3. מקבל אישור שרת מהאתר המזויף
4. האימות נכשל, ומתקבלת אותה שגיאה כמו בפרק 4

החשוב הוא שההחלפה ב-1 מסתיימת לפני היציאה לרשת. בקשת HTTP גלויה כלל אינה נשלחת. לכן לא נוצר המצב «התחברנו ב-HTTP ולכן אין אישור».

אי אפשר ללחוץ על «התעלם והמשך»

ל-HSTS יש עוד תכונה גדולה מאוד בשטח. סעיף 8.4 ב-RFC 6797 דורש שבשגיאה במהלך הקמת ערוץ בטוח למארח עם HSTS, בין אזהרה ובין קטלנית, יש לנתק. וסעיף 12.1 מכנה את ההתנהגות “No User Recourse” (אין למשתמש דרך לעקוף) וקובע שאסור להציג אפשרויות כמו «החיבור אינו בטוח, להמשיך?».

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

הנחת HSTS — את הפעם הראשונה הוא לא מגן

אבל ל-HSTS יש הנחה. לפי סעיף 8.1 ב-RFC 6797, מארח הופך ל«מארח HSTS ידוע» כשסוכן המשתמש מקבל כותרת Strict-Transport-Security מעל ערוץ בטוח. כלומר אותו דפדפן כבר היה צריך להגיע פעם אחת לאתר הלגיטימי ב-HTTPS.

לכן במקרים האלה אין הגנה:

• במחשב עבודה שזה עתה חולק, הגישה הראשונה מתבצעת מיד תחת AP מזויף
• יצרו מחדש פרופיל דפדפן, או מחקו נתוני גלישה וגם את רשומת HSTS
• פג תוקף הרשומה (max-age)

את בעיית הפעם הראשונה ממלאת רשימת ה-preload של HSTS. אם הדומיין ברשימה המובנית בדפדפן, כופים HTTPS גם בלי שביקרו מעולם.

אבל אם שוקלים רישום של אתר הארגון, בדקו קודם את התנאים. דרישות הרישום:⁹

• לספק אישור תקף
• אם מאזינים בפורט 80, להפנות מ-HTTP ל-HTTPS באותו מארח
• לספק את כל תת-הדומיינים ב-HTTPS (כולל www אם יש רשומת DNS)
• במארח הבסיס להחזיר כותרת Strict-Transport-Security עם max-age של 31536000 שניות (שנה) לפחות, ועם includeSubDomains ו-preload

מה שמשפיע הוא הצירוף של השלישית עם includeSubDomains. אם תת-דומיין פנימי ישן הוא HTTP בלבד, או שאין לו אישור, ברגע הרישום אי אפשר להגיע אליו. לפני רישום סופרים את כל תת-הדומיינים.

וביטול אינו קל. בקשות מחיקה מתקבלות בדרך כלל, אבל עד שהשינוי מגיע לדפדפני המשתמשים עוברים חודשים, ולגבי דפדפנים שאינם Chrome אין הבטחה.⁹ בטוח לגשת ל-preload כאל הגדרה ש«אם טעינו, נחזיר» — לא.

ולהפך, כמשתמשים, האם שירותי הענן שבשימוש עסקי תומכים ב-HSTS הוא שיקול ראוי בבחירה.

6. ברגע שהאישור מתרוקן, פונקציית השיתוף הופכת לנתיב הוצאה — סעיף 2(1)

מכאן עוברים לבחינת הוצאה בידי עובד.

מר S בודק תחילה את תפעול פונקציית שיתוף הקבצים. האם הממונה באמת בודק את כתובת היעד ואת הקובץ לפני שהוא מאשר. תשובת גב’ Y: «נראה שיש ממונים שלא מצליחים לבדוק».

אז מר S מצביע על סעיף 2(1). עונים במפורש, עד 40 תווים, על שיטת ניצול פונקציית שיתוף הקבצים כדי לאפשר הורדה מחוץ ל-M.

דוגמת התשובה: «מציינים את כתובת הדואר הפרטית של עצמם ככתובת המשתף החיצוני».

התכנון נכון, התפעול חסר

פונקציית שיתוף הקבצים של שירות B בנויה במחשבה.

• לשיתוף נדרש אישור ממונה
• קישור השיתוף החיצוני אינו מודע לעובד עצמו ולא לממונה. העובד עצמו לא יכול להעביר את הקישור ולהוציא
• הקישור כולל מחרוזת אקראית קשה לניחוש, ותוקף ליום אחד

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

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

תנאי התרוקנות האישור קבועים

כשאישור מתרוקן בשטח, הסיבה היא בדרך כלל אחת מאלה.

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

את התמונה הכללית מאיפה עסק קטן מתחיל מטפל מדריך ההליכה ב«מדריך אבטחת המידע לעסקים קטנים ובינוניים» של IPA, מהדורה 4.0.

7. הפרצה שנקראת חדר ישיבות — סעיף 2(2)

השאלה הבאה של מר S: «אפשר להכניס מחשב אישי לחדר הישיבות?». תשובת גב’ Y: «הכנסה לחדר הישיבות אינה אסורה, אז אפשר».

כאן עולות שיטה 1 ושיטה 2. בשתיהן העלילה היא להוריד קבצים משירות B במחשב אישי, ולקחת את המחשב האישי כולו. הגדרות תוכנת מניעת הדליפה במחשב העבודה לא חלות כלל על המחשב האישי.

שיטה 1 — זיוף כתובת MAC

שיטה 1 היא לשנות את [e] כתובת ה-MAC של ממשק הרשת האלחוטית במחשב האישי לכתובת ה-MAC של ממשק הרשת האלחוטית במחשב עבודה, ואז לחבר את המחשב האישי לרשת האלחוטית לעובדים. לענות על משבצת e זה סעיף 2(2).

את הכניסה לרשת האלחוטית לעובדים שמרו שני דברים: המפתח המשותף מראש של WPA2-PSK, וסינון כתובות MAC. את שניהם עובד יכול לעבור.

• המפתח המשותף מראש מוגדר במחשב העבודה, והעובד הוא המשתמש במחשב העבודה. בשיטה שבה כולם חולקים מפתח אחד, ההנחה היא ש«המשתמש יכול לדעת»
• כתובת MAC ניתנת לשינוי בצד המחשב. בדרך כלל משנים אותה בהגדרות מערכת ההפעלה או במאפייני מנהל ההתקן, בלי כלי מיוחד. בנוסף, כתובת ה-MAC שעל מסגרות הרשת האלחוטית אינה מוצפנת, ולכן קבלה בקרבת מקום חושפת גם כתובות MAC של מחשבי עבודה רשומים

סינון כתובות MAC והסתרת SSID יש להם ערך כסידור שמפחית חיבור בטעות. אבל הם אינם מנגנון אימות שעוצר מי שמנסה להיכנס במכוון. בדקו גם בתצורה שלכם אם הכנסתם את השניים האלה למניין «הטיפולים».

שיטה 2 — פשוט להתחבר לרשת האלחוטית לאורחים

שיטה 2 פשוטה עוד יותר. מחברים מחשב אישי לרשת האלחוטית לאורחים, מורידים קבצים משירות B, ולוקחים את המחשב האישי. זה הכול.

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

כאן עולה באופן טבעי השאלה הבאה. שירות B הוגבל ל«במזהה שניתן לעובד של M אפשר להיכנס רק מכתובת ה-IP הגלובלית של M» — לא?

מה באמת מתירה הגבלת כתובת IP מקור

קריאת הגדרות חומת האש בשאלה נותנת את התשובה. גם תעבורה מהרשת האלחוטית לאורחים לאינטרנט וגם תעבורה מהרשת האלחוטית לעובדים מתורגמות באותו NAT לאותה כתובת IP גלובלית אחת.

מבחינת שירות B אי אפשר להבדיל בין השלושה. ההגבלה לפי כתובת IP עוברת.

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

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

8. לנעול את המחשב באישור — סעיפים 3(1)–(4)

כטיפול לשיטה 1, M בוחרת EAP-TLS כשיטת האימות ברשת האלחוטית לעובדים, ומכינה שרת אימות.

סעיף 3(1) — RADIUS

סעיף 3(1) שואל את הפרוטוקול מעל UDP שהשרת המאמת משתמש בו ב-EAP. דוגמת התשובה: RADIUS.

אם מסדרים את המבנה, יש שלושה שחקנים.

בין מחשב העבודה ל-AP זה IEEE 802.1X ‏(EAP over LAN), ובין ה-AP לשרת האימות זה RADIUS. RADIUS רץ מעל UDP.¹⁰ את הליך EAP-TLS עצמו מגדיר RFC 5216.¹¹ ב-Windows Server את תפקיד שרת האימות ממלא Network Policy Server ‏(NPS).¹²

כדאי לתפוס מה משתנה במעבר מ-WPA2-PSK ל-EAP-TLS.

השורה האחרונה דורשת השלמה. ב-EAP-TLS הצד שהלקוח מאמת את האישור שלו הוא שרת האימות, לא ה-AP. ה-AP הוא רק authenticator שמעביר את חילופי EAP, והלקוח אינו מאשר את זהות ה-AP עצמו.

ועדיין זה מכין מול evil twin מפרק 4, כי חומר המפתח שנוצר רק אחרי הצלחת האימות מגיע רק ל-AP לגיטימי שמחזיק בסוד המשותף של RADIUS. AP שתוקף הקים לבד, כל עוד אין מאחוריו שרת אימות לגיטימי, לא יכול להשלים את ההליך. מה שהלקוח מאמת ישירות הוא שרת האימות, ולגיטימיות ה-AP נגזרת משם בעקיפין.

אבל זה מותנה. אם בצד הלקוח לא מגדירים «איזה אישור שרת, מאיזו רשות אישורים, באיזה שם, ראוי לאמון», אי אפשר להבדיל כשהתוקף מביא שרת אימות משלו. תצורה שבה הכניסו EAP-TLS ובפרופיל הלקוח כיבו את אימות אישור השרת קיימת בפועל. אחרי הטמעה בודקים גם עד לשם.

סעיף 3(2) — התשובות השגויות שהערות הציון ציינו

הסבר גב’ Y ממשיך. אישור הלקוח מונפק בשרת CA חדש, והעובד אינו מתקין אותו בעצמו במחשב העבודה אלא מאחסנים אותו במחשב העבודה בפונקציית שרת הספרייה. ואת [f] שמתאים לאישור הלקוח מאחסנים ב-TPM של מחשב העבודה ומגנים עליו כדי [g].

סעיף 3(2) שואל את משבצת f. דוגמת התשובה: מפתח פרטי.

הערות הציון כותבות כך:

בסעיף 3(2) שיעור התשובות הנכונות היה גבוה יחסית, אבל נראו גם תשובות כמו “מפתח ציבורי” ו”אישור שרת”. PKI הוא טכנולוגיה בסיסית למגוון טכנולוגיות אבטחה, ולכן רוצים שיבינו באילו מצבים ואיך משתמשים בה.

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

מה משתנה כשמכניסים ל-TPM — סעיף 3(3)

סעיף 3(3) שואל את משבצת g עד 20 תווים. דוגמת התשובה: «כדי שאי אפשר יהיה להוציא ממחשב העבודה».

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

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

במימוש ב-Windows מציינים Microsoft Platform Crypto Provider כספק אחסון המפתחות (KSP) בתבנית האישור. הספק הזה מגן על מפתחות באמצעות TPM, ואי אפשר לבחור אותו אם בתבנית האישור מסומן «התר ייצוא מפתח פרטי».¹³ אם אפשר לייצא, אין טעם בהגנה — מגבלה מובנת מאליה.

את תפקיד הרכיב TPM עצמו מטפל המדריך המעשי ל-BitLocker בהקשר של הצפנת כונן. הרעיון «לא להוציא מפתח פרטי מחוץ למכשיר» הוא אותו רעיון כמו תכנון המאמת שמוסבר בלמה מפתחות גישה בטוחים.

למה אפשר לומר ש«אין בעיה» — סעיף 3(4)

אחרי הסבר גב’ Y, מר S עונה «בשיטת האחסון הזו אני חושב שאין בעיה». סעיף 3(4) שואל את הסיבה עד 40 תווים.

דוגמת התשובה: «כי את אישורי האימות הנדרשים ל-EAP-TLS אפשר לאחסן רק במחשב העבודה».

הזרימה היא זו:

1. אישור הלקוח אינו מותקן בידי העובד עצמו, אלא מחולק למחשב העבודה בפונקציית שרת הספרייה. הוא לא עובר בידי העובד
2. המפתח הפרטי נמצא בתוך ה-TPM, ואי אפשר להוציא אותו ממחשב העבודה
3. לכן רק מחשב עבודה שהחברה חילקה יכול להתחבר לרשת האלחוטית לעובדים ב-EAP-TLS
4. מחשב אישי, גם אם מזייף כתובת MAC, לא יעבור אימות. שיטה 1 נחסמת

שימו לב לניסוח המותנה «בשיטת האחסון הזו». אם המפתח הפרטי היה יושב כקובץ במחשב העבודה, מר S לא היה אומר שאין בעיה. גם באותו «אימות באישור לקוח», היקף ההגנה משתנה לפי מקום המפתח הפרטי.

מה TPM לא מגן עליו

מצד שני, זה לא אומר שאחרי הכנסה ל-TPM אפשר להירגע. TPM מבטיח רק ש«המפתח לא יועתק למחשב אחר». הוא אינו מגן על אלה:

• כשמוציאים את המחשב עצמו. הוצאת מחשב העבודה היא הוצאת ה-TPM יחד איתו. בכללי M הוצאת מחשב עבודה מחוץ לחברה אסורה, אבל כלל וכפייה טכנית הם דבר שונה. נדרשים בנפרד הצפנת כונן (כולל אימות לפני הפעלה) ותפעול ביטול אישור באובדן
• התחזות למשתמש. TPM מזהה מחשב, אבל אינו מבטיח מי מפעיל אותו. אימות המשתמש נדרש בנפרד
• תוכנה זדונית שרצה במחשב. אי אפשר לקרוא את המפתח הפרטי, אבל קוד שרץ במחשב יכול «לבקש מה-TPM לחתום». מונעים שכפול מפתח, אבל לא שימוש לרעה כל עוד המחשב נתון בשליטה

9. להפריד את כתובת ה-IP ביציאה — סעיף 3(5)

כטיפול לשיטה 2 (פשוט להתחבר לרשת האלחוטית לאורחים) M בוחנת שני רעיונות. לשנות את הגדרת ה-NAT ב-FW, ולהשתמש בשירות רשת אלחוטית (שירות D).

סעיף 3(5) שואל את תוכן השינוי בראשון עד 70 תווים. דוגמת התשובה היא ברוח «כשניגשים לאינטרנט מהרשת האלחוטית לאורחים, לשים את כתובת ה-IP של המקור לכתובת IP אחרת מכתובת ה-IP הגלובלית שבשימוש כעת» (בשאלה כתובת ה-IP הגלובלית הזו מצוינת כ-a1.b1.c1.d1).

כפי שראינו בפרק 7, שיטה 2 מתקיימת כי תעבורת הרשת האלחוטית לאורחים יוצאת באותה כתובת גלובלית כמו העובדים. אז מספיק לתרגם רק את הרשת האלחוטית לאורחים לכתובת גלובלית אחרת. הגבלת ה-IP בצד שירות B לא משתנה, ורק הגישה מהרשת האלחוטית לאורחים יוצאת ממנה.

זה מתקיים כי בצד ה-WAN של M מוקצות כמה כתובות IP גלובליות. בקריאת הגדרות הממשק של ה-FW בשאלה, מסכת תת-הרשת בצד WAN היא 255.255.255.248, כלומר /29, ואפשר לראות שיש יותר מכתובת אחת. זו הקדמה שקטה אבל בטוחה, שדורשת לקרוא את הטבלה בשאלה לפרטים.

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

10. הטיפול נגמר רק כשמוחקים הגדרות שאינן בשימוש — סעיפים 3(6)(7)

בסוף הבחינה M בוחרת להשתמש בשירות D.

• בחדר הישיבות מציבים נתב אלחוטי (נתב D) ששירות D משאיל
• בנתב D מפעילים פונקציית שרת DHCP ופונקציית שרת מטמון DNS
• מחשבי אורחים מתחברים לאינטרנט בלי לעבור ברשת של M, באמצעות ה-SIM המובנה בנתב D
• את המקרן מחברים בכבל HDMI, בלי להשתמש ברשת האלחוטית לאורחים

flowchart LR
    accTitle: אחרי הטיפול מנתקים את רשת האורחים
    accDescr: רשת העובדים משתמשת ב-EAP-TLS וב-TPM, ומחשב שאורח מביא יוצא לאינטרנט ב-SIM של נתב D בלי לעבור ברשת של M
    subgraph M["הרשת הפנימית של חברת M (אחרי הטיפול)"]
        direction TB
        E["רשת אלחוטית לעובדים<br/>EAP-TLS + RADIUS<br/>המפתח הפרטי בתוך TPM"]
        S["רשת שרתים"]
        FW["FW"]
        E --> FW
        S --> FW
    end
    subgraph K["חדר ישיבות"]
        T["מחשב שאורח מביא"]
        D["נתב D<br/>ישר לאינטרנט דרך SIM"]
        T --> D
    end
    FW --> B["שירות B"]
    D --> I["אינטרנט"]

איור 3: רשת האורחים נותקה מרשת חברת M פיזית וגם לוגית; היא גם אינה יוצאת עוד באותה כתובת IP גלובלית.

רשת האורחים נותקה מרשת M פיזית וגם לוגית. היא גם אינה יוצאת באותה כתובת גלובלית.

סעיף 3(6) — תעבורה שתהיה מיותרת

כשמחשבי אורחים מפסיקים להשתמש ברשת של M, התעבורה שהייתה נחוצה עד כה לשרת DHCP ולשרת [h] הופכת למיותרת. דוגמת התשובה למשבצת h: DNS.

לנתב D עצמו יש פונקציית שרת DHCP ופונקציית שרת מטמון DNS, ולכן מחשבי אורחים אינם צריכים את שרת ה-DHCP ושרת ה-DNS ברשת השרתים של M. אם קוראים שוב את תיאור השאלה, זה כתוב כמו שהוא.

סעיף 3(7) — למנות את כל ההגדרות למחיקה

סעיף 3(7) מבקש לענות על כל מספרי הפריטים שיש למחוק מהגדרות ממשק ה-VLAN ומהגדרות הסינון של ה-FW, בעקבות השינוי.

התשובה: מהגדרות ממשק VLAN את VLAN של הרשת האלחוטית לאורחים (פריט 1); מהגדרות הסינון את הכלל שמתיר HTTP/HTTPS מהרשת האלחוטית לאורחים לאינטרנט (פריט 1) ואת הכלל שמתיר גישה מ-DNS ברשת השרתים מהרשת האלחוטית לאורחים (פריט 4) — שניים. בנוסף מוחקים מהגדרות ה-AP את הגדרת SSID האורחים.

הערות הציון כותבות כך:

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

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

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

אבל אל תכלילו את שיטת ההערכה הזו לכל חומת אש. המוצר קובע אחרת.

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

את הצד של חומת האש במחשב — איך מנהלים כללי כניסה שנחוצים ליישום עסקי — מטפל חומת האש של Windows ויישומים עסקיים.

11. טיפולים שלא פעלו, וטיפולים שפעלו

אם מרכזים את השאלה לטבלה אחת, מתקבלת ההתאמה בין הטיפולים שהיו ל-M לבין איפה עברו אותם.

רק השורה האחרונה «פעלה». ואת מה שהוצע כטיפול מסדרים כך:

בהשוואה האופי מתבהר. הטיפולים שעברו הם ברובם איסור «אמצעי», והטיפולים שפעלו והטיפולים שהוצעו משנים «נתיב» או «אופי האישור». גם אם חוסמים USB, כל עוד נשאר נתיב לקובץ ההוצאה מתקיימת; גם אם מאריכים מפתח משותף מראש, הוא נשאר סוד משותף.

12. נקודות בדיקה לשטח

פריטי אישור כשמחילים את השאלה על התצורה שלכם.

1. האם אפשר לכתוב את מניעת ההוצאה בנתיבים ולא באמצעים. לא רשימת אמצעים כמו USB, צירוף למייל ודואר אינטרנט, אלא «רשימת המחשבים והרשתות שיכולים להגיע לקובץ העסקי». אם יש ולו נתיב אחד שמחשב לא מנוהל מגיע בו, איסור האמצעי יעקוף
2. האם כללי הכנסה והוצאה אינם מצמצמים מקום. «איסור הכנסה לחדר העבודה» מתיר חדר ישיבות, קבלה ומרחב משותף. בודקים אם החלוקה הפיזית והחלוקה הרשתית חופפות
3. האם אפשר לומר מה באמת מתירה הגבלת כתובת IP מקור. סופרים הכול שיוצא בכתובת הגלובלית הזו. Wi-Fi לאורחים, רשת אורחים, VPN בין אתרים, שער מרוכז לעבודה מרחוק, סביבת בדיקה
4. האם אישור הרשת האלחוטית הוא לפי מחשב. מפתח משותף מראש הוא סוד משותף אצל כולם; דליפה אצל אחד היא דליפה לכולם, ואי אפשר לעצור מחשב אחד מסוים
5. האם לא הכנסתם סינון כתובות MAC והסתרת SSID למניין הטיפולים. שניהם סידור שמפחית חיבור בטעות, לא אימות
6. האם המפתח הפרטי של אישור הלקוח במצב שאי אפשר להוציא מהמחשב. מפתח פרטי כקובץ ניתן לשכפול. מציינים ספק אחסון מפתחות שמשתמש ב-TPM, ולא מתירים ייצוא
7. האם הלקוח שאליו הכניסו EAP-TLS מאמת את אישור שרת האימות. אם מכבים את זה, נעלמת העמידות מול שרת אימות מזויף
8. האם שגיאת אישור שרת אינה במצב שהמשתמש יכול לעבור ב«המשך». מגדירים HSTS לאתר הארגון. לא משאירים שגיאות אישור במערכות פנימיות, ולא מלמדים את המשתמש ש«שגיאה לוחצים וממשיכים»
9. האם סופרים את תוכן מאגר רשויות אישורי השורש המהימנות. מה שנמצא שם הוא בדיוק הצד שהמחשב מכריז «אישור שהרשות הזו הנפיקה ייחשב אמיתי»
10. האם למאשר בזרימת האישור מגיע חומר שיפוט, והאם רואים אחר כך את תוצאת האישור. בודקים באופן קבוע ברשימה שיתופים לדומיינים חיצוניים ולדואר חינמי
11. האם מוחקים הגדרות של נתיב שבוטל. ממשק VLAN, כללי סינון, SSID, רשומות ברשימת היתר. נותנים מועד גם לעבודת המחיקה, באותו יחס כמו «להכניס חדש»

לסיום — טיפול שלא כותב «היקף» אינו מגן

אם שאלה 1 שאלה «את איזה שלב, של איזו תקיפה, הטיפול הזה עוצר», מה ששאלה 2 שואלת הוא «איזה היקף הטיפול הזה שומר».

לכל אחד מטיפולי M היה היקף מובלע. היקף תוכנת מניעת הדליפה הוא עד מחשב העבודה. היקף איסור ההכנסה הוא עד חדר העבודה. היקף סינון כתובות MAC הוא עד «מי שאינו מזייף». היקף הגבלת כתובת IP מקור הוא עד «כל מי שיוצא בכתובת הגלובלית הזו». כל היקף פעל נכון; רק החיבור לשכן היה פתוח.

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

כדי למצוא רווח אין ברירה אלא לכתוב רשימת נתיבים, לא רשימת טיפולים. זה בדיוק מה שגב’ Y ומר S עשו בשאלה. מפרידים ל«תוקף חיצוני» ו«עובד», וסוגרים לכל אחד נתיב הגעה אחד-אחד. «היכולת לשער איומים מזוויות שונות בסביבה שמשתמשת ברשת אלחוטית», ש-IPA כתבה בכוונת השאלה, היא העבודה הזו.

תחומי ייעוץ קשורים

KomuraSoft LLC מטפלת בסקירת תכנון על בסיס רשת ותצורת קצה קיימות, ובמימוש הפצת אישורים והגנה על מפתחות בסביבת Windows.

• ייעוץ טכני וסקירת תכנון
• פיתוח יישומי Windows
• חקירת תקלות ואיתור גורמים
• יצירת קשר

מקורות

מאמרים קשורים

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

נושאים קשורים

העמודים האלה ממקמים את הנושא בהקשר רחב יותר של שירותים והחלטות.

שירותים הקשורים לנושא הזה

המאמר קשור ישירות לשירותים הבאים.

שאלות נפוצות

שאלות נפוצות בפניות בנושא המאמר.

אסרו חיבור USB ואסרו שמירה לדיסק מקומי — איך בכל זאת מוציאים קבצים?

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

שירות B הוגבל ל«כניסה רק מכתובת ה-IP הגלובלית של M». למה אפשר לעקוף מ-Wi-Fi לאורחים?

גם התעבורה של הרשת האלחוטית לאורחים עוברת באותו NAT של אותה חומת אש, ומתורגמת לאותה כתובת IP גלובלית לפני שהיא יוצאת לאינטרנט. מבחינת שירות B, גישה ממחשב עבודה פנימי וגישה ממחשב אישי שמחובר ל-Wi-Fi לאורחים בחדר הישיבות נראות כאותה כתובת מקור. אי אפשר להבדיל. הגבלת כתובת IP מקור אינה «רק מהמחשב הזה» אלא «כל מי שחולק את אותו יציאה». Wi-Fi לאורחים, VPN בין אתרים, ושער מרוכז לעבודה מרחוק — כל מה שיוצא באותה כתובת גלובלית נכנס להיתר.

על הרשת האלחוטית לעובדים היה סינון כתובות MAC. זה לא נחשב לטיפול?

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

גם אם מכינים נקודת גישה מזויפת ואתר מזויף, למה אפשר לומר שהעובדים לא יולכו שולל?

כי בחיבור HTTPS האתר המזויף לא יעבור את אימות אישור השרת. איור 2 בשאלה מונה ארבעה פירוטי שגיאה אפשריים: לא הונפק על ידי רשות אישורים מהימנה, שם השרת באישור שונה משם השרת שאליו מתחברים, האישור בוטל, פג תוקף. התוקף אינו יכול להשיג אישור לגיטימי לשם הדומיין של שירות B, ולכן אישור בחתימה עצמית נופל בראשון, ואישור לגיטימי לדומיין שלו נופל בשני. לפי הערות הציון של IPA, שיעור התשובות הנכונות לשאלה על תוכן האימות הזה היה נמוך. ארבעת הסעיפים גם אינם פועלים באותו חוזק. מה שעוצר את התקיפה הם השניים הראשונים (מנפיק ושם) ותוקף — הדפדפן תמיד בודק אותם. בדיקת ביטול תלויה במימוש ובהגדרה. Chrome למשל בדרך כלל אינו בודק OCSP או CRL מקוונים, ומשתמש ב-CRLSet — רשימה מוגבלת שמטרתה חסימה בחירום. אל תחשבו שביטול תמיד ידחה. ואם מפיצים למחשבי העבודה את אישור השורש של רשות אישורים פנימית, והמפתח הפרטי או הליך ההנפקה של אותה רשות נפלו בידי תוקף, גם הבדיקה הראשונה תעבור.

מה קורה אם מקלידים בטעות «http://»? מה HSTS עושה?

הדפדפן מחליף HTTP ב-HTTPS ואז מתחבר, ולכן התוצאה היא שוב שגיאת אישור שרת. HSTS הוא מנגנון שבו הדפדפן זוכר את תוכן הכותרת שקיבל בחיבור HTTPS קודם לאותו אתר. RFC 6797 דורש שאם ב-URL ליעד יש סכימת http, סוכן המשתמש מחליף אותה ב-https, ואם צוין פורט 80 הוא מומר ל-443. כלומר בקשת HTTP גלויה נעלמת לפני שהיא יוצאת לרשת. חשוב עוד יותר: בחיבור למארח עם HSTS, אם אימות האישור נכשל, בין אזהרה ובין שגיאה קטלנית — יש לנתק. מצוין במפורש שאסור להציג למשתמש «החיבור אינו בטוח, להמשיך?». אבל HSTS מניח שהדפדפן כבר הגיע פעם אחת לאתר הלגיטימי ב-HTTPS וקיבל את הכותרת. במחשב חדש לגמרי, אם הגישה הראשונה היא מיד לאתר מזויף, זה לא עוזר. את הפעם הראשונה ממלאת רשימת ה-preload המובנית בדפדפן.

מה משתנה כשמאחסנים את המפתח הפרטי של אישור הלקוח ב-TPM?

אי אפשר להוציא את המפתח הפרטי ממחשב העבודה. מפתח פרטי שיושב כקובץ במחשב אפשר להעתיק למחשב אישי, ואז אותו מחשב אישי יעבור אימות כמחשב עבודה. אם יוצרים את המפתח בתוך TPM במצב שאינו ניתן לייצוא, חישובים כמו חתימה רצים רק בתוך ה-TPM, והמפתח עצמו אינו מגיע ל-OS ולא לתוכנה זדונית. התוצאה: רק מחשב עבודה שהחברה חילקה יכול לעבור EAP-TLS. זו הסיבה שמר S יכול היה לומר «בשיטת האחסון הזו אין בעיה». ב-Windows מציינים Microsoft Platform Crypto Provider כספק אחסון המפתחות בתבנית האישור, ולא מתירים ייצוא מפתח פרטי. אבל TPM מגן רק על «המפתח לא יועתק למחשב אחר»; מי שמחזיק את המחשב עדיין יכול להשתמש בו. מול אובדן וגניבה צריך בנפרד הצפנת כונן וביטול אישור.

מה כדאי לקחת מהשאלה הזו לשטח?

ארבע נקודות. ראשית, לחשוב על מניעת הוצאה בנתיבים ולא באמצעים. גם אם חוסמים USB, צירוף למייל ודואר אינטרנט אחד-אחד, אם נשאר מחשב שמגיע לקובץ — אין בזה תועלת. שנית, לכתוב במפורש מה באמת מתירה הגבלת כתובת IP מקור. אם Wi-Fi לאורחים או VPN משתמשים באותה יציאה, גם הם בהיתר. שלישית, להפוך את אימות הרשת האלחוטית לאישורים לפי מחשב. מפתח משותף מראש הוא סוד משותף אצל כולם; דליפה אצל אחד היא דליפה לכולם. עם EAP-TLS ואישור לקוח, ועם מפתח פרטי שאינו יוצא מה-TPM, האישור ננעל למחשב. רביעית, למחוק הגדרות שאינן בשימוש. השאלה האחרונה ביקשה למנות את כל הגדרות ממשק ה-VLAN וכללי הסינון בחומת האש שנשארים אחרי ביטול הרשת האלחוטית לאורחים. לפי הערות הציון של IPA שיעור התשובות הנכונות היה גבוה, אבל מעט ארגונים מסיימים את זה בשטח.

פרופיל הכותב

עמוד היכרות עם כותב המאמר.

Go Komura

מנהל KomuraSoft LLC

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