שלום רב,
1.כיצד ניתן למנוע התקפת MITM על משתמש שמתחבר לארגון באמצעות רשת ציבורית כלשהי?
המשתמש מתחבר באמצעות SSL VPN וכולל הזדהות חזקה.
מה מבטיח לי (בניגוד למנגנון אבטחה ב-SSH כפי שדובר כאן
http://www.fresh.co.il/vBulletin/sh...ad.php?t=555288 )
שהתוקף לא יוכל לחטוף את ה-Sesion למשתמש ומשם להתחבר לארגון לאחר שהמשתמש ביצע login למערכת?

2.עד כמה מסוכנת האזהרה כאן לגבי משתמש vpn שהם clientless?
http://www.kb.cert.org/vuls/id/261869
מה הסיכון לפריצה ברגע שאני עובד עם ACL מסודר ברמת אפליקציות+כתובות IP פר משתמשים?

כל הרעיון של SSL בשימושו באינטרנט, מבוסס על מנגנון של PKI - Public Key Infrastructure...

כחלק מה negotiation של SSL, השרת מציג בפנייך תעודה שנחתמה בצורה דיגיטלית על ידי גוף ידוע, שחתימתו כלולה במערכת ההפעלה שלך או באפליקציה שלך, והתעודה הזו עוברת אימות. אם תהיה התקפת MITM, התעודה שתוצג על ידי התוקף, תהיה או לא חתומה על ידי מקור ידוע (למשל - חתומה-עצמית), או, אם בצורה כלשהי התוקף הצליח לשטות באחד מהגופים הידועים כדי שיחתום לו על תעודה שתואמת לשם ה host שאליו אתה מתחבר, אזי התעודה תהיה חתומה בצורה תקינה (עד שהנתקף יגלה וידרוש להוסיף את המספר הסידורי של תעודה זו ל CRL של החותם), אבל אז זהות החותם תהיה שונה, ושוב, תוכל לדעת.

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

פה אנחנו מדברים על איך נפתח ה session, לפני שמתחיל המעבר של המידע.

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

אשר למה שהוספת בעריכה: ברפרוף מהיר, נראה שהתוקף במקרה המסויים הזה צריך שהמשתמש יגלוש לאתר שיוגש על ידי ה "SSLVPN" (זה קצת אדיוטי לקרוא ל reverse proxy בשם VPN, ר"ת שמכילים במהותם את המילה Network, אבל נזרום עם כל ה Vendor-ים שלא הצליחו לממש מה ש OpenVPN עושה כבר שנים רבות...) - כלומר, בסבירות גבוהה, לשלוט על אתר אינטרנט פנימי בארגון, שמפורסם על ידי VPN.

באופן כללי, דעתי האישית היא, ש clientless VPN הוא דבר נורא ואיום מבחינת אבטחה, בין אם זה באמת VPN (ואז זה בעצם ממילא מתקין לך תוכנה דרך הדפדפן, בצורה מפוקפקת למדי, כך שלא ברור מה כאן בדיוק clientless), ובין אם זה בגישה למשאבי אינטראנט מתוך הדפדפן, שאליו אנשים נכנסים מאיזה מחשב שבא להם ("כי זה VPN של ג'וניפר/סיסקו/צ'קפויינט, אז זה מאובטח!!!"), וד"ש ל key-logger-ים ולסוסים הטרוייאנים באשר הם...

נמאס לכם לזכור סיסמאות? לחצו כאן!

צהריים טובים שימי ומועדים לשמחה!
ראשית,תודה על התגובה המהירה והמפורטת.

1.בסנריו הראשון (שלב זיהוי תעודת ה-SSL)אתה טוען כי על התוקף להניח ידו על שרת ה-CA של אחד מהגורמים המאשרים המוכרים לצורך הנפקת valid certificate וגם אז ה-Serial Number של התעודה יהיה שונה.

א.האם תוקף מנוסה שמתמצא במערכת RSA Kenon או Microsoft CA יכול לערוך את שדה התעודה באופן ידני (ממה שאני מכיר-ניתן לערוך את השדות ) וגם את ה-Serial Number של התעודה לזייף?
או שזה מונפק באופן רנדומלי?
(אני בכוונה הולך רחוק במיוחד לנוכח כל מה שקורה עם התקפות ה-APT's כיום).

ב.כיצד (אם בכלל) ניתן לוודא שהמשתמש יבצע אימות SSL מול סריאל של תעודת SSL ספציפית באתר ספציפי?

ג.מבחינה תאורתית-האם תוקף שעובד עם כלים כדוגמת SSLTIP יכול להנפיק תעודה שהדפדפן יזהה אותה כ-Valid?
אני מדבר על הדבר הזה:
http://www.itnews-blog.com/it/81125.html
זה מאוד מזכיר לי SSL PROXY (למשל Websense בארגונים) שלמעשה שובר לך את ה-Session
ואז את כל נושא החלפת המפתחות מי שמבצע את זה זה למעשה הפרוקסי השקוף .
אתה כמשתמש (לעולם לא בדקתי אבל זה מאוד מענין) תראה תעודה שהיא VALID למרות שהפרוקסי מבצע את ההצפנה מול השרת ולא תראה הודעת אזהרה בדפדפן (תקן אותי בבקשה אם אני טועה).


2.כתבת:
"אשר למה שהוספת בעריכה: ברפרוף מהיר, נראה שהתוקף במקרה המסויים הזה צריך שהמשתמש יגלוש לאתר שיוגש על ידי ה "SSLVPN" (זה קצת אדיוטי לקרוא ל reverse proxy בשם VPN, ר"ת שמכילים במהותם את המילה Network, אבל נזרום עם כל ה Vendor-ים שלא הצליחו לממש מה ש OpenVPN עושה כבר שנים רבות...) - כלומר, בסבירות גבוהה, לשלוט על אתר אינטרנט פנימי בארגון, שמפורסם על ידי VPN."

אתה מתכוון פה שהסיכון הוא משחקים ב-URL ? ה-ACL דווקא עושה את העבודה.
הוא גם ברמת IP גם ברמת אפליקציה וגם ברמת PORT ספציפי.
מה הסיכון פה?

3.מה קורה(סנריו מספר 2) במקרה שבו מישהו מצטרף באמצע שכבר יש session פעיל, שאפקטיבית, מבחינת התוקף, עובר בו זבל אקראי למדי, ומצליח איכשהוא לפענח את התקשורת של שני הצדדים, ולזייף ?
ב-SSH אני יודע שזה שה-Session היה נסגר נשבר מיידית לפי מה שהסברת לי בנושא.
עד כמה אפשרי לתקוף משתמש שעבר אותנתיקציה והכל יש SESSION פעיל והוא מתחבר מרשת של בית קפה ו"לרכב" לו על ה-session ולחדור לארגון?

הפתרון שאני חשבתי כנגד כל הסוגיה הזאת הוא התחברות ממודמים ספציפים של ספקית סלולר ל-Cloud של הספק (בדומה ל-IPVPN) ומשם לארגון כאשר אני אגביל את הכניסה רק לאותם מודמים ספציפים עם כתובות IP סטטיות (ACL FIREWALL).
בנוסף למנוע Split Tunnel (האם זה אפקטיבי בהגנה מבחינת MITM ?) וכמובן ליישם הזדהות חזקה עם Certificate/OTP (כנגד Kelogers) ובמקביל לנצל את כל יכולות ה-SSL VPN APPLIANCE כדוגמת Endpoint Control (זה יצמצם לי משמעותית את הסיכונים).

אשמח לקבל את דעתך המקצועית .

1.
א. PKI נסמך לחלוטין על הסודיות של המפתחות הפרטיים. אם תוקף השיג את המפתח הפרטי של ה-CA, אני לא רואה סיבה שהתוקף לא יוכל לייצר תעודה עם איזה מספר סידורי שרק ירצה ולחתום עליה.
כמובן שהוא יכול לעשות זאת עם כל כלי שהוא רוצה, לאו דווקא שרתי CA מסחריים ומוכרים.
ב. כאמור, לא רואה סיבה להסתמך על מספר סידורי באם המפתח הפרטי של ה-CA זלג (כנ"ל לגבי CRL-ים).
ג. הוא לא שובר SESSION קיים, הוא מייצר SESSION חדש ומחבר ביניהם. פתרון אפשרי (ברמת ארגון) הוא שימוש ב-Client side certificates בנוסף.

2. הסיכון הקבוע: אם ממערכת א' אפשר להגיע למערכת ב' וכן הלאה...

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

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

אם זה מספיק טוב בשבילך - אתה אמור לדעת.

תעזרו קצת לעולם:

שלום,
תודה על התגובה המפורט-הדברים ברורים יותר.
רציתי לשאול בבקשה:

1.במידה ותוקף מבצע ARP Cache Poisoning וגורם לניתב של כל התעבורה של ה"קורבן" דרכו-האם במקרה זה הוא יוכל ליצור תעודה מסוג Self-Sign והיא תהיה Valid מבחינת ה"קורבן"?
הבנתי שבמתקפה שכזאת הדבר ניתן מאחר והתוקף ממיר את בקשות ה-HTTPS של ה"קורבן" ל-HTTP .

2.האם בעת שימוש ב-SSL Proxy (לדוגמה בארגון-Websense) לא תוצג למשתמש הודעת אזהרה?
עד כמה שאני זוכר נכון הלקוח לא יודע בכלל שהוא עובר דרך פרוקסי.

3. עד כמה יעיל שימוש ב-Client side certificates כאשר ה"קורבן" פתח Tunnel והתוקף מתחיל לבצע MITM ? האם בכל פתיחה של Session חדש הוא יצטרך Certificate ?
איך למעשה בפועל זה מגן עליי?

4.מבחינת ACL אני משייך משתמשים לקבוצות ומעניק להם את הגישה הרצויה לאוביקט ספציפי בפורט ספציפי.
האם יש שיטה מומלצת או מקובלת יותר?

1. חשוב מאוד לשאול - למה שהתעודה תהיה VALID-ית?

האם התעודה נחתמה ע"י ה-CA הארגוני כמו באופציה שהוזכרה לעיל?

האם התעודה נחתמה ע"י CA כלשהו שנמצא ברשימת ה-TRUSTED CA ה-DEFAULT-ית ב-STORE של ה-PC/דפדפן? האם יש בקרה מספקת של/על ה-CA האלו?
(אין, וזו הבעיה החמורה ביותר בעולם הPKI כפי שהוא בא לידי ביטוי באינטרנט)

האם התעודה כלל לא VALID-ית אבל המשתמש פשוט רגיל לאשר חריגות כי "ככה זה"? (גם בעיה חמורה)

2. במקרה כזה התעודה אמורה להיות VALID-ית ולא תהיה אזהרה.

3. עוזר בהתקפה שהוזכרה בסעיף 1.
ה-SESSION נפתח בעצם ע"י התוקף, שלא אמורה להיות לו תעודה VALID-ית, ולכן לא יאושר.

4. לא, רק צריך להכיר את המשמעויות והסיכונים.

תעזרו קצת לעולם:

שלום רב,
SSL VPN מסורתי לא מספק קשת הגנה מספקת לארגונים עם מידע רגיש, ולכן ישנם פתרונות הכוללים IPSEC Over SSL VPN. אני מציע שתעיין בתיעוד ל Juniper SSL VPN לשם התרשמות מיכולות פיתרון דומה.

http://www.juniper.net/techpubs/software/ive/

בהצלחה

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