איך להגביל גישה בין שני משרדים המחוברים ב-VPN
מנהרת אתר לאתר אינה אמון הדדי. בנו מטריצה של מקור, יעד ושירות, אכפו אותה על תעבורה מפוענחת, והוכיחו גם סירוב.
מנהרת אתר לאתר עונה על שאלה אחת, אם שני המשרדים יכולים להחליף מנות, ומשאירה את החשובה פתוחה: איזה התקן סניף רשאי להגיע לאיזה שירות מרכזי. התייחסות למנהרה כאמון הדדי היא הדרך שבה מחשב נייד של אורח מגיע לאותו נתיב כמו שרת הכספים. הפתרון אינו מנהרה טובה יותר, אלא רשימת הרשאות מפורשת שנאכפת לאחר הפענוח. מדריך זה מוביל את הרשימה מהגדרה ועד סירוב מוכח.
עבדו בסדר הזה, ואל תרחיבו את נתיב המנהרה עד ששלבי המדיניות שלמטה יעברו.
כתבו את המטריצה לפני שנוגעים בשער
שורה שימושית מציינת שלושה דברים: קבוצת מקור, מארח או רשת שירות של יעד, והפרוטוקול והפורט שהאפליקציה באמת משתמשת בהם. הסניף ומרכז הנתונים אינם רשומות. DNS פרטי ושירותי אימות זוכים לשורות משלהם רק כאשר האפליקציה אינה יכולה לעבוד בלעדיהם.
קבצו מקורות לפי תפקיד ולא לפי נוחות של תת-רשת: צוות, אורחים, ניהול. כאשר כל השלושה חולקים LAN שטוח אחד, השער אינו יכול להבדיל ביניהם בשכבת הרשת, ולכן בקרות זהות או פילוח חייבות לבוא קודם. לאחר מכן הניחו את המטריצה בכתב עם בעלים ותאריך סקירה בכל שורה.
| מקור | יעד | שירות | החלטה |
|---|---|---|---|
| צוות הסניף | אפליקציית הזמנות 10.10.5.10 | TCP 443 | לאשר בשער המפענח |
| צוות הסניף | VLAN לניהול שרתים | כל דבר | סירוב משתמע |
| Wi-Fi לאורחים | כל טווח מרכזי | כל דבר | לסרב לפני המנהרה |
| מארח קפיצה ניהולי | VLAN של שרתים | TCP 22 ו-3389 | לאשר עם MFA, חומת האש של המארח מצמצמת עוד |
אכפו במקום שבו המנות מפוענחות
הכללים שמתירים IKE ו-ESP בונים רק את המנהרה החיצונית. התעבורה הפנימית מגיעה בגלוי לממשק המנהרה, ושם מקומה של רשימת ההרשאות: שרשרת העברה בהתקן המפענח, השלכה כברירת מחדל, כלל אחד לכל שורת מטריצה. בשערי Linux זה אומר העברה מופעלת וכללי סינון בהתקן המנהרה, לא בקישור הפיזי, כפי שמסביר מדריך ההעברה של strongSwan.
בוררי תעבורה הם החלטת ניתוב, לא החלטת הרשאה. בורר רחב שמכסה את שתי תת-הרשתות יכול להיות נכון לניתוב בעוד חומת האש עדיין מתירה רק TCP 443 למארח אחד. הבורר מנוהל משא ומתן עבור המנהרה ומתאר מה רשאי להיכנס אליה, לא מה רשאי התקן נתון להשתמש בו. לעולם אל תרחיבו כלל של חומת אש מפני שהבורר רחב.
iptables -A FORWARD -i tun0 -s 10.20.0.0/24 -d 10.10.5.10 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i tun0 -j DROPNAT ותת-רשתות חופפות משנים את הכללים
כאשר שער הסניף מתרגם כל מארח לכתובת אחת לפני המנהרה, כל שורה מבוססת מקור קורסת לכתובת האחת הזו. או שתפסיקו לתרגם תעבורת מנהרה, או שתקבלו שהכללים חייבים להישען על משהו אחר, כמו כתובת המקור המקורית שנרשמה לפני התרגום. לקצה המרוחק אותה בעיה, כי מארח היעד רואה את הכתובת שאחרי NAT ולא את המקורית.
טווחים חופפים הם המלכודת האחרת. שני משרדים ששניהם משתמשים ב-192.168.1.0/24 לא ניתן לתאר בטבלת מדיניות אחת בלי למפות צד אחד, ומיפוי אינו תחליף לכתובוּת שאינה מתנגשת. תקנו את התוכנית לפני שתכתבו כללים שתצטרכו לפרק אחר כך.
הוכיחו סירוב, לא רק הצלחה
בדיקת האפליקציה המורשית בלבד מוכיחה מעט מאוד, כי כלל מתירני במקום כלשהו במעלה הזרם נותן את אותה תוצאה.
מהתקן סניף רגיל הגיעו לשירות המיועד וודאו שכל ההפעלה עובדת. אחר כך נסו יעד שחייב להישאר סגור, כמו פורט ניהולי בשרת שלסניף אין עסק איתו, וקראו את המונה או רשומת היומן שזרקה אותו. השבתת מערכת הכללים כדי לבדוק אם היא עובדת מבטלת את הבדיקה ומשאירה את השער פתוח בזמן שאתם מסתכלים.
שמרו על הרשימה בחיים
אפליקציות זזות, וכלל ששורד את האפליקציה שלו הופך לחור שאין לו בעלים. חברו את תאריך הסקירה לשורה, ושנו את היקף הבורר ואת כלל חומת האש באותו שלב תחזוקה כאשר שירות מחליף כתובת.
הגבלות ברמת המארח עדיין חשובות מאחורי המנהרה: חומת האש של השרת עצמו צריכה לקבל את טווח הסניף רק לשירות שהוא מפרסם. שתי שכבות שמסכימות קלות יותר לביקורת מאשר שכבה אחת שבוטחים בה לחלוטין.