ALB פנימי עם שם DNS ציבורי: האם הוא באמת חשוף?

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

שלב ראשון: קראו את הסכימה, לא את ה-IP

שדה הסכימה הוא ההצהרה של מאזן העומס עצמו על הגבול שלו. aws elbv2 describe-load-balancers --names app-internal מחזיר Scheme עם הערך internal או internet-facing, בתוספת סוג כתובת ל-IPv4 או מחסנית כפולה. מאזן עומס הפונה לאינטרנט עדיין יכול להעביר ליעדים פרטיים, כך שראיית כתובות backend פרטיות לא מוכיחה דבר על החזית.

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

שלב שני: ראו למה השם מתפענח

שאלו מחוץ ל-VPC עם dig +short app-internal-1234567890.eu-west-1.elb.amazonaws.com ורשמו אם התשובות בטווח 10.0.0.0/8, 172.16.0.0/12 או 192.168.0.0/16. תשובה פרטית ממאשר ציבורי היא ההתנהגות הצפויה עבור שם של מאזן עומס פנימי; היא אינה הוכחה שהכתובת ניתנת לניתוב מהאינטרנט.

פתרו את אותו שם מתוך ה-VPC והשוו. אם שתי התשובות שונות, אתם רואים מתן שמות split-horizon, וההבדל הזה הוא פרט תכנון, לא דליפה.

שלב שלישי: מנו את הנתיבים שיכולים להגיע אליו

כתובת פרטית נגישה מכל מקום שבו קיימים נתיב וכלל אבטחה. מנו אותם במכוון: VPN מאתר לאתר, VPN לקוח, VPC peering, חיבורי transit gateway, Direct Connect וכל פרוקסי או bastion בתוך ה-VPC. אחד מהם הוא הנתיב המיועד, והשאר הם אלה שתוקף יחפש.

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

שלב רביעי: בדקו את המאזין והיישום בנפרד

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

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

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

שלב חמישי: החליטו אם השם עצמו חשוב

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

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

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