Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out

89-860 Secure Messaging and Commerce

VIEWS: 24 PAGES: 5

									                        ‫אוניברסיטת בר-אילן – המחלקה למדעי המחשב‬
                      ‫053-98 מבוא לרשתות תקשורת - סמסטר א תשס"ו‬
                                  ‫מרצה: פרופ' אמיר הרצברג‬
                                     ‫מתרגל: עידן ספקטור‬
                         ‫בחינה סופית – מועד א – 6002.2.42 - פתרון‬
                                                                                              ‫הנחיות:‬
                                                    ‫1. משך הבחינה: שעתיים (021 דקות).‬
‫2. אין להשתמש בכל חומר עזר וגם לא במחשבון . בסוף גליון הבחינה מצורפים מספר דפי תזכורת‬
                                                                     ‫בנושאי השאלות.‬
‫3. אנא ענה בקיצור ובבהירות, עם תרשימים, נוסחאות והנמקות מתומצתות . ציון עובדות נכונות‬
 ‫שאינן רלוונטיות לתשובה יגרום להורדת נקודות (ובוודאי ציון עובדות שגויות , רלוונטיות או‬
                            ‫לא). אם חסרים נתונים, הנח הנחות סבירות ו ציין אותן בבירור .‬
            ‫4. השתמש בנימוקים, הנחות ודוגמאות מציאותיים, סבירים ונפוצים ככל האפשר.‬
                                                                     ‫בהצלחה!! אמיר הרצברג‬

                 ‫1. (03 נק') בהרצאה למדנו על פעולת מנגנון ‪( NAPT‬ראו תזכורת) , וציינו כי כאשר ה-‬
                ‫‪ NAPT‬מקבל חבילה ‪ p‬ומקצה לה ‪ port‬זמני מסוים ‪ x‬וכתובת ‪ IP‬יוצא ‪ ,y‬אז הוא‬
                  ‫שומר את הכתובות המקוריות : ‪. srcIP[x,y]=p.srcIP, srcPort[x,y]=p.srcPort‬‬
                    ‫בכתובות אלו הוא ישתמש עם קבלת חבילת תשובה ‪ , q‬בה יהיה ,‪x=q.dstPort‬‬
                                                                                 ‫‪.y=q.dstIP‬‬
                   ‫‪ 5( .a‬נק') הסבר מדוע אי אפשר לשחרר את הזוג ‪ x,y‬מייד עם קבלת חבילת‬
                                       ‫התשובה ‪ ,q‬אם הבקשה נשלחה בפרוטוקול ‪.TCP‬‬
                   ‫‪ 5( .b‬נק') הסבר מדוע אי אפשר לשחרר את הזוג ‪ x,y‬מייד עם קבלת חבילת‬
                                      ‫התשובה ‪ ,q‬אם הבקשה נשלחה בפרוטוקול ‪.UDP‬‬
                ‫‪ 15( .c‬נק') הנח שברשות ה-‪ NAPT‬יש עשר כתובות ‪ IP‬להקצאות זמניות. הצע‬
                   ‫אלגוריתם סביר להקצאת ושחרור מספרי ‪ port‬וכתובות ‪ IP‬זמניים עבור‬
                   ‫חבילות ‪ .UDP‬יש להציג את הפתרון ע"י פסוואדו-קוד (אפשר גם, אך לא‬
                             ‫מומלץ, ע"י תרשים זרימה; אין להציג ע"י דיאגרמת מצבים).‬
             ‫‪ 5( .d‬נק') אילו שינויים , אם בכלל, כדאי לעשות לטיפול בחבילות ‪( ?TCP‬אין צורך‬
                                                              ‫לכתוב את האלגוריתם).‬
   ‫(54 נק') ארגון ביקש ממך לבדוק ולשפר את ההתמודדות עם דואר זבל של שרת ה דואר‬       ‫2.‬
                                 ‫הנכנס (מהאינטרנט) של הארגון, ‪.in.smtp.irgun.org‬‬
     ‫3. ארגון ביקש ממך לבדוק ולשפר את ההתמודדות עם דואר זבל של שרת הדואר הנכנס‬
                                        ‫(מהאינטרנט) של הארגון, ‪.in.smtp.irgun.org‬‬
 ‫‪ 3( .a‬נק') הארגון מעונין להבטיח , שכתובות הנמענים יהיו תמיד בתוך הארגון . מדוע‬
                                                       ‫זה קשור לדואר זבל?‬
‫אם כתובות הנמענים הם לא בתוך הארגון , ונסכים לקבל אחריות על הדוא"ל (ע"י‬
 ‫תשובת ‪ )2xx‬ולשלוח אותו הלאה מחוץ לארגון , אזי הסכמנו להיות ‪open relay‬‬
 ‫ועלולים לשלוח דרכנו דואר זבל לארגונים אחרים . כתוצאה מכך ארגונים אחרים‬
                                         ‫עלולים לסרב לקבל מאתנו דואר .‬
   ‫‪3( .b‬נק') לשם בדיקה זו, יש לבדוק את הכתובות באיזה שדה או שדות ? ,‪(From‬‬
                            ‫)…,‪MAIL FROM, To, RCPT TO, CC, BCC‬‬
       ‫כדאי להסתכל ב ‪( RCPT TO‬שאר השדות רלוונטיים רק ברמת ה ‪)MUA‬‬
        ‫‪3( .c‬נק') הארגון מעוניין לבדוק את הדואר המתקבל ולחפש בו מילות מפתח‬
   ‫מסוימות, שמאפיינות דואר זבל , ובמקרה כזה לא להעביר אותו לנמען . אפשרות‬
‫אחת היא לבצע בדיקה זו (או חלקה) תוך כדי קבלת הדואר , לפני שליחת התשובה .‬
                    ‫במקרה זה, אם מתגלה הודעה חשודה כזבל , איך יש לנהוג ?‬
  ‫יש לשלוח שגיאת ‪ 5xx‬עם קוד מתאים. הערה: אמנם, יש חסרון מסוים מבחינת‬
‫אבטחה, בכך שאנו חושפים לשולח את העוב דה שהדואר הזה לא עבר את הפילטר‬
‫(אם השולח אכן ‪ .)spammer‬אולם פרוטוקול ‪ smtp‬דורש אמינות מהמקבל ובפרט‬
‫אם אנו יודעים כי לא נקבל את הדואל הרי הסטנדרט דורש שנודיע לשולח (לשולח‬
‫בקישור ‪ smtp‬ע"י קוד ‪ 5xx‬אם הבעיה מתגלה במהלך השליחה או לשולח המקורי‬
    ‫ע"י שליחת הודעת שגיאה ‪ delivery status notification‬אם מגלים אחר כך).‬
     ‫ובאמת אחרת עלול להגרם נזק משמעותי יותר מאבדן הודעה ללא כל סימון .‬
   ‫‪3( .d‬נק') אפשרות שניה היא לבצע את הבדיקה למילות מפתח שמזהות דואר זבל‬
   ‫לאחר סיום קבלת ההודעה (ושליחת ‪ .)250 OK‬במקרה זה, אם מתגלה הודעה‬
                                               ‫חשודה כזבל, איך יש לנהוג?‬
     ‫אין אפשרות אמיתית לדעת בוודאות אם זה זבל או לא, וכבר הסכמנו לקבל‬
    ‫אחריות על הדוא"ל (שלחנו 052). אז פשוט נסמן את ההודעה כחשודה, לצורך‬
    ‫פילטרציה אפליקטיבית של משתמש הקצה . לחילופין ניתן ל "זרוק" מייד את‬
    ‫החבילה, במקרה זה יש לשלוח הודעת שגיאה ‪delivery status notification‬‬
                           ‫לכתובת השגיאות שצוינה בדואל בשדה ‪.mail from‬‬
                     ‫‪3( .e‬נק') איזה אפשרות מבין השתיים עדיפה ומה היתרונות ?‬
‫בדרך כלל עדיפה הראשונה שחוסכת משאבים ודואגת ליידע את השולח . עם זאת,‬
‫יש שיעדיפו את אפשרות הסימון והעברה ליעד , אם הנמען משתמש בתוכנה יע ילה‬
                  ‫לניהול הדואר ויוכל לזהות יותר טוב דואר זבל ולהגיב אליו .‬
   ‫‪ 5( .f‬נק') הארגון מעוניין לא לקבל דואר משרתי דואר שידועים כשולחי דואר זבל ,‬
   ‫בעזרת רשימה שחורה שמוחזקת ע"י ‪ .DNSbl.org‬הנח שמתקבל חיבור משרת‬
    ‫מכתובת ‪ 144.55.66.77 : IP‬שמזדהה ע"י הודעת ‪ .HELO a.com‬הצע שיטה‬
‫פשוטה ויעילה לבדוק אם השרת השולח הוא ברשימה , והסבר איך תבוצע הבדיקה‬
                                              ‫עבור השרת השולח שצוין .‬
   ‫בד"כ ‪ BL‬מוחזק לפי ‪ IP‬ולא לפי ‪( DNS‬שהרי שם דומיין בהודעת ‪ HELO‬עלול‬
       ‫להיות מזויף). מבצעים שאילתת ‪ DNS‬רגילה (מסוג '‪ )'A‬לפענוח הכתובת‬
       ‫‪ .77.66.55.144.DNSbl.org‬מערכת ה-‪ DNS‬תחזיר תשובה לפי הרשומות‬
   ‫שנשלטות ע"י ‪ DNSbl.org‬ובפרט אם יש רישום שחושד בכתובת 77.66.55.441‬
   ‫ככתובת שעלולה להיות שולחת ‪( spam‬או חלק מבלוק כתובות חשוד ) אז נקבל‬
                                                             ‫סימון מתאים.‬
 ‫‪ 5( .g‬נק') הצע מוסכמה בין ה- ‪ domains‬כך ש-‪ domain‬למשל ‪ a.com‬יוכל לסמן את‬
 ‫הכתובות של שרתי הדואר היוצא שלו , כלומר את כתובות ה- ‪ IP‬מהן מותר לשלוח‬
   ‫דואל עם ‪ ,HELO a.com‬ושרת הדואל הנכנס של הארגון יוכל לוודא עם תחילת‬
  ‫הקישור מ- 77.66.55.441 שהוא אכן מורשה לשלוח דואר מטעם ‪( a.com‬כלומר‬
                                                        ‫עם ‪.)HELO a.com‬‬
‫מוסכמה פשוטה ויעילה – לכל שרת דואר יוצא למשל מכתובת ‪, 144.55.66.77 : IP‬‬
‫נחזיק רשומת ‪ DNS‬לכתובת ‪ . 77.66.55.144.OutMTA.a.com‬כלומר ה"דומיין"‬
     ‫‪ OutMTA.a.com‬יזהה לנו את הכתובות המותרות לשרתי הדואר היוצא של‬
                      ‫הדומיין. את שם הדומיין השולח ניקח מהודעת ‪.HELO‬‬
   ‫‪ 4( .h‬נק') הצע כיצד לבדוק אם האתר ברשימה ש ל אתרים "טובים" שמוחזקת ע"י‬
                           ‫‪ .DNSwl.org‬האם עדיף לפי שם או לפי כתובת ‪?IP‬‬
 ‫כדאי לפי שם (בהנחה שביצענו בדיקה לפי הסעיף הקודם כך שאנו יודעים שהשרת‬
    ‫השולח מורשה ע"י הדומיין ). כך למשל נוכל ישר להסתכל , עבור ‪xyz.aol.com‬‬
                 ‫‪ HELO‬האם ‪ xyz.aol.com‬הינו ‪ .white-listed‬כיצד בודקים:‬
         ‫שוב נראה הכי פשוט כי ‪ DNSwl.org‬פשוט יחזיק כניסת ‪ A record‬עבור‬
‫‪ ,xyz.aol.com.DNSwl.org‬והמדיניות תהיה שאם ‪ A record‬קיים – אזי ‪domain‬‬
                                                         ‫הינו ‪.white-listed‬‬


    ‫(61 נק') הנח כי כל המנגנונים דלעיל מומשו . צייר תרשים הודעות עם השהיות‬    ‫‪.i‬‬
   ‫וחשב זמן סיום, בהנחה שההשהיה של כל הודעה דרך האינטרנט (בין ‪domains‬‬
        ‫שונים) היא ‪ 0.1sec‬וההשהיה של כל הודעה בתוך ‪ domain‬היא ‪,10msec‬‬
                                                         ‫לתהליכים הבאים:‬
  ‫‪ 10( .i‬נק') קבלת קשר (והודעה ) משרת מכתובת ‪ 144.55.66.77 : IP‬שהוא‬
‫שרת דואר מורשה של ‪ ,aspammer.com‬בפעם הראשונה. הנח שה ‪domain‬‬
   ‫הזה (‪ ) aspammer.com‬הוא חדש (ואין שום מידע עליו בשרת ה- ‪DNS‬‬
                      ‫המקומי). השרת אינו באף אחת משתי הרשימות .‬
                                                ‫ראה תרשים מצורף.‬
      ‫הערות: השמטתי את הזמנים (טריוויאלי). הנחתי שהשולח יודע את‬
  ‫כתובת ‪ IP‬של השרת הנכנס ‪ .in.smpt.irgun.org‬הנחתי ששרת ה ‪DNS‬‬
   ‫המקומי יודע את כתובת של ‪( OutMTA.A.Com‬אם לא: צריך להוסיף‬
     ‫פניה ל-‪ TLD‬כדי לקבל את שרת ה-‪ DNS‬של ‪ a.com‬ואז פניה אליו).‬
      ‫‪ 6( .ii‬נק') קבלת הודעה נוספת מאותו שרת , זמן קצר מאוד לאחר מכן .‬
      ‫כאן רק צריך להשמיט קריאות ‪ DNS‬להן התוצאות ידועות מראש .‬
  ‫4. (52 נק') נתבקשת לתכנן פרוטוקול תקשורת למערכת תקשורת בין מטאטאים, שמיועדת‬
     ‫לתעד משחקי כדור בהם השחקנים טסים על המטאטאים. קוטר המגרש הוא 4 ק"מ,‬
     ‫והגובה המירבי של המגרש הוא 3 ק"מ. לכרטיס התקשורת קצב של 01 ‪ mbps‬ויכולת‬
                                                             ‫לזהות התנגשויות ושידור‬
  ‫(‪ )carrier sense and collision detection‬בתנאי שהשידור נמשך לפחות 02 מיקרו שניה,‬
      ‫ומהירות התפשטות סיגנל היא 000,002 ק"מ לשניה. הנח שכל המטאטאים קולטים‬
 ‫תשדורות זה מזה ללא מכשולים. ההודעות שיש לשלוח הן בין אורך 3 בתים לבין 02 קילו-‬
                                                                          ‫בתים.‬
                                   ‫‪ 13( .a‬נק') קבע גודל ‪ frame‬מינימאלי (ונמק...).‬
‫מרחק מירבי 5ק"מ (יתר במשולש), זמן התפשטות מירבי 52 מיקרו שניה; לכן צריך‬
     ‫שהשידור ימשך לפחות ‪ ,2*25+20=70microsec‬כלומר 007 ביטים שזה כ09‬
                                                                       ‫בתים.‬
                ‫‪ 3( .b‬נק') מה השיקול לקבוע גם אורך מרבי ? (אין צורך לחשב אותו )‬
 ‫אם נרשה חבילות מאוד ארוכות , תהיה סבירות גדולה של אבדן בגלל רעש . בנוסף,‬
    ‫אם תהיה התנגשות לא מזוהה (והרי זה אפשרי) אז הנזק גדול יותר . ולסיום זה‬
                                                                ‫יפגע בהוגנות.‬
 ‫‪ 3( .c‬נק') ההנחה שיש זיהוי התנגשויות וודאי אינה כל כך סבירה למערכת זו . הסבר‬
                                                                     ‫מדוע.‬
‫עוצמת הסיגנל הנקלט יורדת באופן חזק עם גדילת המרחק ולכן קשה לזהות קבלת‬
                                                   ‫סיגנל נוסף בשעת שידור .‬
   ‫‪ 6( .d‬נק') הנח כעת כי הסיכוי שמחשב שמשד ר יזהה התנגשות איתו הוא 2/1. איזו‬
                                   ‫שינויים, אם בכלל, כדאי לעשות בפרוטוקול ?‬
                  ‫ת: לשלוח ‪ ack‬על הודעות, ולשלוח מחדש אם לא מגיע …‪ack‬‬

								
To top