בדקו שהפרוקסי שלכם אינו פתוח לכולם
לפני חשיפת פרוקסי קדמי בדקו מאזין, סדר כללים, פרטי גישה והעברה בפועל ממקורות מורשים ודחויים.
בדקו את גבול הגישה לפני שפרוקסי קדמי חדש נגיש מרשתות אחרות. בקשה מוצלחת מהשרת עצמו מוכיחה מעט על יכולת לקוח לא קשור. השתמשו ביעד שבשליטתכם כדי לזהות אם בקשה שנדחתה הועברה בפועל.
בדקו את המאזין והמדיניות הפעילים
בדקו את התהליך והכתובות המאזינים, כולל IPv6 אם פעיל. הסירו מאזינים נוספים לא מכוונים או מופעי שירות ישנים. הגבילו את חומת האש הרשתית למקורות שאמורים להגיע לשירות.
בדקו אחר כך את התצורה שהתהליך באמת טען, כולל קבצים נכללים. ב־Squid 6, היתר מוקדם עלול לבטל הגבלה מאוחרת. ב־Tinyproxy 1.11.2, מחיקת כל שורות Allow ו־Deny מתירה את כל הלקוחות. ל־Dante יש כללי לקוח ו־SOCKS נפרדים, לכן אישור חיבור TCP אינו כל המדיניות.
השתמשו בתיעוד הגרסה המותקנת. שינויי ההנחיות ב־Squid 8 הם סיבה לבדוק גרסה, לא להניח שתצורה מוכרת התקבלה באותה משמעות.
בדקו מקרים מורשים ודחויים גם יחד
אם הפרוקסי אמור לדרוש גם מקור מאושר וגם התחברות, הריצו מטריצה זו באמצעות מערכות בשליטתכם:
| מקור | פרטי גישה | תוצאה נדרשת |
|---|---|---|
| מורשה | תקינים | היעד המיועד מקבל את הבקשה. |
| מורשה | חסרים או שגויים | לא מגיעים ליעד. |
| לא מורשה | תקינים או חסרים | לא מגיעים ליעד. |
שני מכשירים מאחורי NAT אחד עשויים להיראות כאותו מקור. בחרו מקומות בדיקה עם כתובות מקור שונות בפרוקסי ואמתו אותן ביומניו. אל תשתמשו במכשירי צד שלישי לא קשור ואל תסרקו שירותים של אחרים.
דחיית חומת אש עשויה לא להחזיר תגובת HTTP; דחיית יישום עשויה להחזיר שגיאה. בשני המקרים ודאו שהיעד שבשליטתכם לא קיבל את הבקשה האסורה; דף שגיאה לבדו עלול להתפרש כתגובת יעד.
בדקו את מצבי ההעברה שבכוונתכם להתיר
בפרוקסי אינטרנט בדקו בנפרד HTTP רגיל ואת נתיב HTTPS CONNECT המורשה. אם המדיניות מגבילה יעדים, בדקו יעד מורשה ויעד שבשליטתכם שצריך להידחות. אל תסירו בקרות רק כדי שכל בדיקה תצליח.
בדקו שוב לאחר שינוי טווחי מקור, פרטי גישה, כתובות מאזינים, קבצים נכללים או גרסאות שירות. שמרו יחד את זמן הבדיקה, גרסת התצורה והתוצאות כדי לבדוק שינוי מאוחר מול אותו גבול.
זהו תהליך קבלה, לא טענה שמנתח תצורה או בקשה אחת יכולים להוכיח שכל נתיב רשת סגור.