כולם כאן ודאי מכירים את הסוגיה הכאובה (בייחוד מבחינת א"מ) של תקשורת בין שרתי Front לשרת Backend של Exchange (כבר כתבתי על כך בעבר...)

לאחרונה התברר לי, שלא רק זאת ששרת Front חייב פתיחה של כמות נכבדת של פורטים בינו לבין שרת ה Back שעליו נמצאות התיבות / Public שאליהם צריך לגשת, אלא שגם נראה ששרת ה Back אינו יודע לתפקד כמעין Proxy עבור שרת ה Front למידע שנמצא על שרתי Back אחרים במקומות אחרים בארגון (לצורך זה - למשל Calendar של תיבות ב Site-ים אחרים) - מה שבעצם מצריך לפתוח תקשורת בין כל שרת Front לכל שרתי ה Back מכל ה DMZ-ים לכל הרשתות הפנימיות, וכמובן גם לעשות את כל הבלאגן הזה תחת VPN. די מסוכן, ודי מיותר, מבחינה הגיונית.

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

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

רעיון בלי להיכנס לעובי הקורה:
מה בדבר vlan-ים ולבצע את החסימות ברמת החומרה?

VLAN פועל ברמת Ethernet - אני לא כל כך מבין איך זה קשור לתקשורת בין אתרים (שבוודאי יוצאת מעבר לשכבה 2)... ואני גם לא כל כך מבין מה הוא היה עוזר לי אפילו היו כל השרתים באותה רשת מקומית (איך זה פותר את הבעייה שה Front צריך להתחבר לכל ה Back-ים ובכך להקריב א"מ באופן כל כך דראסטי)

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

המטרה בגדול הייתה לשים על כל השרתים כרטיס רשת נוסף ב vlan "אקסקלוסיבי" משלהם שבו הFW לא יחסום פורטים (עם כתובות מוגבלות, חסימה ברמת mac address ושאר הדרכים להגברת האבטחה למניעת התחזות כמובן)
אבל בגלל שמדובר בשרתים מרוחקים וvpn לא מוצא חן בעיניך, צריך למצוא פתרון אחר.

לא אמרת לפי איזה מסמך פעלת... אבל פי מסמך שמראה את הטופולוגיה שלך, כן צריך לפתוח את הפורטים בין כל שרתי ה front לכול שרתי ה back
http://www.microsoft.com/technet/pr...n/e2kfront.mspx

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

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

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

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

ישנו Best Practice של MS להגדרה IPSEC בין שרת ה FRONT ל BACK.
לדעתי האישית לא לעבוד במוד FRONT\BACK, וגם לא לחשוף את שרת ה EXCHANGE
לאינטרנט ישירות זאת הדרך הכי בטוחה.

http://www.ms-mvps.com/articles/Exchangefront&back.htm

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

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

לעניין IPsec בין שרת Front ל Back - לא הבנתי במה זה בדיוק מסייע - שתהיה לי הצפנה שאני לא אוכל לנטר מה הולך שם? בשביל מה אני בכלל צריך הצפנה בין שני שרתים שהתעבורה שלהם כלל לא עוברת באינטרנט / עוברת באינטרנט מוצפנת כבר באמצעי אחר כגון VPN ?

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

דרך ה IPSEC למעשה אתה יכול להעביר את התקשורת בין שרת ה FRONT ל BACK/DC.
כך אתה חוסך הגדרת כמות פורטים נכבדת, קיבוע הגדרות ברגיסטרי וכולי.
בקשר לבקרה, מכיוון שאתה עובד עם IPSEC למעשה קשה לעקוב אחר התעבורה, אבל מצד
שני זה יעיל יותר מאשר להגדיר את כל הפורטים.
הבעיה הינה שקשר בין ה DMZ ל LAN לא תמיד נחשב מאובטח, ביחוד כאשר עובדים עם RPC.

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

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

ולא הבנתי איך הקשר בין ה DMZ ל LAN יכול להיות לא מאובטח ומה הקשר ל RPC?

(הטופולוגיה היא הרי DMZ <-> FW <-> LAN - אין שום דבר אחר בדרך ביניהם, מה כאן יכול להיות לא בטוח?)

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