כללי חומת אש שמטפלים רק ב-NEW לא סוגרים כל נתיב WAN

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

מצב הוא תנאי התאמה, לא פסק דין

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

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

קראו את הכלל בהקשר שלו

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

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

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

הביעו את האיסור ללא תלות במצב

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

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

מדיניות שמתירה במכוון תשובות לגישה שמתחילה מרחוק דרך WAN היא ניתנת להגנה. רק צריך לתאר אותה כך במקום להציג אותה כבידוד מוחלט דרך המנהרה בלבד.

בדקו מי באמת נמצא בתוך הקבוצה

הדוגמה מכסה תעבורת IPv4 מועברת מקידומת אחת דרך ממשק אחד. היא לא אומרת דבר על IPv6, על קישור עליון שני או על תעבורה שהנתב עצמו יוצר. נתב שמשמש כמפתה DNS שולח את שאילתותיו כלפי מעלה, ואלה כלל לא עוברות דרך שרשרת forward.

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

iptables -S FORWARD
iptables -L FORWARD -v -n
cat /proc/net/nf_conntrack | grep -c ESTABLISHED

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