Stateful

Rיקש

New member
Stateful

לאחרונה אני רואה את המושג הזה הרבה בכל מיני FWים חומרתיים וכמובן בIPTABLES... מה זה בדיוק אומר המושג הזה?
 

uzi2

Active member
וגם תראה את זה בפיירוולים אישיים

בד"כ לא תראה stateful לבד אלא את המונח stateful inspection, שפרושו מעקב אחרי sessions שלמים. פיירוול שאינו תומך ב- stateful inspection (כלומר stateless) בודק כל IP packet באופן נפרד ובלתי תלוי. פיירוול שמבצע stateful inspection עוקב אחרי sessions של תקשורת ויותר לקשר בין packets ששייכים לאותו session ואלו שלא. המדובר ביחוד ב- TCP (ששם מוגדרים sessions). ב- stateless inspection יש בדיקה עבור כל חבילה באופן בלתי תלוי. ב- stateful inspection, בהתאם לפיירוול ולהגדרותיו, יש הבדל בין תקשורת יזומה מבפנים ליזומה מבחוץ. בפיירוול אישי שתומך בזה, יש בדיקה של ההתאמה לחוקים רק לגבי הפאקט הראשון בכל session, ואח"כ בהתאם לאישור או לסרוב של התקשורת, והפיירוול כבר ידאג שאותה ההחלטה תיושם לגבי כל הפאקטס באותו session. זה חוסך לפיירוול בדיקה של החוקים מחדש עבור כל החבילות השונות בכל session, אבל דורש ממנו לזכור את ה- sessions ואת ה- ISN (מספרים שמגדירים בכל חבילה מה תהיה החבילה שאחריה ב- session, וזה מה שמאפשר לפיירוול לעקוב אחרי sessions), של כל התקשורות הקיימות.
 

Rיקש

New member
זה נשמע לי כמו

חסכון בCPU לFWים שמתעסקים בהרבה תנועה, לא? ואני מבין שזה לא רלוונטי לUDP? (הFW שאני מקים עכשיו חי על UDP
)
 

uzi2

Active member
הסבר קצת יותר מעמיק

ראשית לא התנסחתי מספיק בדייקנות בהסבר הקודם בנקודה אחת: כתבתי שב- stateful inspection שזה דורש ניהול רישום אחרי כל session שנפתח, וה- ISNs שלו. יש רישום ומעקב אחרי ה- sessions אבל לא בכל ה- stateful firewalls יש גם מעקב אחרי ה- ISNs (בחלקם יש ובחלקם המעקב מתבצע דרך מה שקרוי flags). בכל מקרה, יש אכן ככלל חסכון לעבודת פיירוול עקב העובדה שבכל session יש (ככלל) בדיקה של החוקים רק לגבי החבילה שיוזמת אותם ואח"כ כבר הפיירוול פועל על פי הטבלה, ובהתאם להחלטה שלו לגבי אותו session. אבל החשיבות העיקרית אינה בזה. החשיבות העיקרית, היא בכך שב- stateful inspection יש את האינפורמציה מי יזם את התקשורת, בעוד שב- stateless filtering אין מעקב כזה. כלומר בפיירוול מודרני שתומך ב- stateful inspection, יש אפשרות להגדיר שתקשורת מסויימת תאושר אם היא יזומה מבפנים בעוד שהיא תידחה עם היא יזומה מבחוץ. אם אין stateful inspection אז אפשר לדעת לגבי החבילות שאחראיות ליוזמת הקשר אם הן יזומות מבחוץ או לא, אבל מכיוון שאין מעקב אחרי sessions אז לגבי חבילות ההמשך הפיירוול לא יודע אם הן מתייחסות לתקשורת שיזומה מבחוץ או לתקשורת שיזומה מבפנים ולכן לא יכול לסנן על פי הקריטריון הזה, אלא רק לגבי הקריטריון האם התקשורת מגיעה מבחוץ (גם אם היוזמה ל- session הגיעה מבפנים) או מגיעה מבפנים (גם אם ה- session נפתח מבחוץ). פרוטוקול UDP הוא מה שקרוי stateless protocol כלומר אין שם את המונח session. פיירוול יכול לנהל מעקב מסויים גם על תקשורת כזאת האם היא יזומה מבפנים או מבחוץ ע"י מעקב ושמירה לתקופה קצובה של נתונים על יוזמות התקשורת, אבל מעקב זה מוגבל למדי ולכן פיירוולים הרבה מפספסים לגבי השאלה מי יזם את התקשורת במקור, ואין הסתמכות יתר על הנקודה הזאת (הפרטים תלויים בפיירוול הספציפי). ההמלצה שלי, נשארה בעינה. במקרה שלך מכיוון שהתקשורת שאתה מבקש לאשר ל- IP מסויימים, אינה תלוי בשאלה האם התקשורת יזומה מבחות או מבפנים או לשאלה מאיפה מגיעה התקשורת אלא רק על פי מספרי ה- IP, הרי שלא בטוח שניהול טבלה כזאת לגבי תקשורות אלו היא חיונית. אני בכלל לא בטוח שאם חבילה כזאת תבדק רק ע"י החוק הראשון ב- chain ותאושר. זה לא יהיה יותר מהיר מאשר אם היא תיגש לטבלת התקשורות הפעילות ותעדכן אותה כל הזמן. לכן המלצתי לנסח חוק ראשון בצורה הכללית ביותר מתוך תקווה שבמידה ואין צורך בניהול טבלת sessions אז גם הם לא ינוהלו. בכל מקרה, כיום כמעט כל הפיירוולים שיש עובדים עם stateful inspection.
 

Rיקש

New member
תודה רבה עוזי!

כל הכבוד על ההשקעה בהסבר, שוב, תודה. כנראה שאני עוד יציק לך בשאלות.
 
למעלה