• Shuffle
    Toggle On
    Toggle Off
  • Alphabetize
    Toggle On
    Toggle Off
  • Front First
    Toggle On
    Toggle Off
  • Both Sides
    Toggle On
    Toggle Off
  • Read
    Toggle On
    Toggle Off
Reading...
Front

Card Range To Study

through

image

Play button

image

Play button

image

Progress

1/16

Click to flip

Use LEFT and RIGHT arrow keys to navigate between flashcards;

Use UP and DOWN arrow keys to flip the card;

H to show hint;

A reads text to speech;

16 Cards in this Set

  • Front
  • Back

התקני רשת נפוצים שעוזרים בהעברת מידע בין מחשבים


Hub

רכיב רשת אליו מתחברים כל המחשבים ברשת המקומית. כשמחשב רוצה לשלוח הודעה למחשב אחר, הוא שולח את ההודעה ל-hub, וה-hub שולח את ההודעה לכל המחשבים ברשת. המחשב אליו יועדה ההודעה ישתמש בה, ואילו כל המחשבים יקבלו את ההודעה, יראו שהיא לא מיועדת אליהם ויתעלמו ממנה.

התקני רשת נפוצים שעוזרים בהעברת מידע בין מחשבים


Switch

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

התקני רשת נפוצים שעוזרים בהעברת מידע בין מחשבים


Router

רכיב שמעביר מידע בין רשתות (על מנת שמחשבים מרשתות שונות יוכלו לתקשר)

התקפות של התקני רשת


Degradation attack

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

Poisoning attack

הרעלה - ניתוב המידע ליעד אחר (למשל אלינו) ממה שתוכנן, ע"י זיוף הודעות שיגרום לשינוי הנתונים בטבלה.

כתובת MAC

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

כתובת IP

כתובת המורכבת מ-32 ביטים (IPv4) או מ-128 ביטים (IPv6). כתובת לוגית המשתמשת כמזהה של המחשב ברשת ומאפשרת העברת מידע בין רשתות

פרוטוקול ARP

על מנת שמחשב A ידע לשלוח הודעה למחשב B (שניהם באותה הרשת) הוא צריך לדעת את כתובת ה-MAC שלו. לשם כך הוא נעזר ב-ARP - פרוטוקל שממפה בין כתובות IP לכתובות MAC.
אופן פעולת הפרוטוקול:
מחשב A מחפש בטבלת ה-ARP את ה-MAC של B. אם הוא לא מוצא אותה, הוא שולח לכל המחשבים ברשת הודעה בפורמט הבא:


"who has [IP1] tell [IP2]"


(כאשר IP1 שייך ל-B ו-IP2 שייך ל-A).
כל המחשבים פרט ל-B מתעלמים מההודעה, ואילו B שולח בתגובה את כתובת ה-MAC שלו.

איך ננצל את פרוטוקול ARP לצורך התקפה?

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

איך נתמודד עם תקיפת ARP?

- במקום עדכון אוטומטי ע"פ ההודעות המתקבלות, הרשומות בטבלה יהיו סטטיות ויעדכן אותן רק מנהל רשת אחראי. (קשה לניהול)


- זיהוי פעילות חריגה וחשודה ברשת, למשל מאק שממופה לכמה כתובות איי.פי (לא תמיד יעיל).


- שימוש בתוכנות שינסו לאתר ולמנוע זיוף הודעות ARP.

מה זה DHCP?

מנגנון שמאפשר לנו לקבל את כל המידע בנוגע לרשת אליה הגענו לראשונה, למשל כתובת איי.פי, כתובת איי.פי של שרת DNS וכו'.
לכל לקוח יש DHCP client ולכל רשת יש לפחות DHCP server אחד. כשלקוח מגיע לרשת ורוצה להיכנס אליה ולקבל מידע, הוא שולח "DHCP discovery" על מנת לגלות מי הוא שרת ה-DHCP. אחד משרתי ה-DHCP מקבל את ההודעה ושולח בתגובה DHCP offer, כלומר הוא מציע ללקוח להתחבר אליו (מספק לו IP ופרטים נוספים) ובאופן אוטומטי מסמן אצלו שכתובת ה-IP הזו ממתינה לאישורו של הלקוח (עד לפרק זמן מסוים). הלקוח מחליט לקבל את ההצעה ושולח DHCP request עם פרטי הבקשה. השרת שולח בתגובה DHCP ack ומשלב זה ה-IP משויך ללקוח.

איך אפשר לנצל את מנגון DHCP להתקפה?

ניתן להתקין שרת DHCP מזויף, שיענה ל-DHCP discovery של הלקוח (בהנחה שהמענה יהיה מהיר יותר מהאחרים והלקוח יבחר בשרת הזה) ובעצם ישלוט על כל המידע שהלקוח יקבל. למשל, אם נאמר לו שהכתובת של ה-default gateway או של שרת ה-DNS היא הכתובת שלנו, נגרום לכך שכל התעבורה תעבור דרכנו ונוכל לשלוט בכתובת ה-IP אליה/ממנה הלקוח יקבל/ישלח מידע לכל אתר שהוא יחפש.

מה זה DNS?


שרתי ה-DNS ממפים בין domain names לבין כתובות אייפי. domain names הם היררכיים ובעלי משמעות (מובן כי il מציין ישראל, למשל). שרת ה-Loacl DNS מחזיק טבלה בשם resource records המשמשת כ-cache של השאילתות שענה עליהן בעבר כדי שיוכל לשלוף משם תשובות לשאילתות הבאות במהירות. בנוסף, בתגובה המתקבלת אצל שרת ה-Local DNS מה-Root מתווספת רשומה המחזיקה את כתובות ה-IP של ה name servers אליהם יש הפנייה. דבר זה נקרא glue.

איך אפשר לנצל את מנגון ה-DNS לצורך התקפה?

בתשובה שה-Root מעביר, הוא יכול להוסיף ל resource records רשומה נוספת ובה כתובת IP של אתר נוסף מעבר לזה שבוקש בשאילתה (כביכול ע"פ מידע שהוא אסף התברר שרוב האנשים שביקשו את האתר הראשון ביקשו לאחר מכן גם את האתר השני, ולכן הוא חוסך לנו בזמן וביעילות ומכניס את האתר השני ל-cache). אולם, ע"י זיוף ה-IP של האתר השני, נוכל לגרום לכך שכל הלקוחות שישלחו שאילתות ל-DNS בבקשה להיכנס לאתר השני, יופנו בעצם אלינו. כך, במצב שבו כל הרשומות יתווספו באופן אוטומטי ל-cache, הן יורעלו.

איך נתמודד עם התקפת ה-DNS?

על מנת למנוע הרעלה, נוסיף רשומות ל-cache, רק אם הן in-Bailiwick, כלומר רק אם התשובה שהתקבלה היא מאותו הדומיין של האתר המבוקש בשאילתה (למשל ns.bob.com עבור bob.com). במקרה שהרשומות הן Out-in-Bailiwick, כלומר הדומיינים שונים (ns.bob.net עבור bob.com), לא נוסיף אותן.

Kaminsky’s Attack

נוכל להתחזות לאחד מהשרתים שכן יעבור את "מבחן ה-bailiwick" ובכך לקבל שליטה.
הבעיה היא שלשם ההתחזות עלינו לנחש את ה- transaction id בפרק זמן מאוד קצר, ולחכות בכל פעם עד שה-TTL יעבור (פרק הזמן בו נשמר ה transaction id הנכון ב-cache) כדי שנוכל לנסות לנחש פעם נוספת, מה שהופך את העניין ללא יעיל ולא פרקטי.
קמינסקי שינה את זה ועזר לנו להתגבר על בעיית ה TTL:
במקום לשלוח שאילתת DNS אחת, נשלח הרבה שאילתות DNS, לדומיינים שונים, רנדומליים ושלא באמת קיימים, ולכן לא ימצאו ב-cache, מה שיגרום לשרת ה-Local DNS להעביר את השאילתה הלאה. עבור כל שאילתה יווצר transaction ID שונה, וכעת, כשיש הרבה transaction id , הסיכוי שלנו לנחש אחד מהם הוא הרבה יותר גבוה.