פרוטוקולי רשת - שירותיהם וסכנותיהם.

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

Simple Network Management Protocol - SNMP

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

שני רכיבים עיקריים ל-SNMP; "סוכן" (Agent) ו-"מנהל" (Manager). רכיב ה-Manager הינו החלק "השרתי" של הפרוטוקול – הוא מלקט מידע אודות מצב ההתקנים ברשת, ובנוסף, מקבל הודעות מרכיב ה-Agent ומהווה בעצם אזור ריכוזי המאחסן מידע אודות הרשת. רכיב ה-Agent הינו תוכנה קטנה – אשר מצויה בהתקני הרשת, ובד"כ מוטמעת במערכת ההפעלה. ל-Agent רשימה מסודרת אודות האובייקטים עמם הוא עובד. רשימה זו מיושמת במבנה הדומה לבסיס נתונים הנקרא Management Information Base או בקצרה – MIB. ה-MIB מחלק (בצורה לוגית) את האובייקטים לקבוצות. האובייקטים מכילים נתונים נחוצים המשמשים לניהול הרשת ובדיקת מצב ההתקנים בה. הווה אומר, כאשר רכיב ה-Manager מזהה התקן (או Agent, לצורך העניין), אותו התקן "מושך" נתונים מה-MIB ומעביר אותו ל-Manager. בד"כ רכיב ה-Manager יהיה מצוי במחשב מרכזי המבקר את פעילות הרשת וההתקנים המחוברים אליה.

אם על אבטחת מידע עסקינן, יהיה נחוץ להגביל אילו Managers מורשים לבקש מידע מה-Agents – לכן, פותח מנגנון אבטחה הנקרא Communities המעניק קישור מהימן בין Agent-ים ספציפיים ל-Manager. מנגנון זה מאופיין בבקרת גישה הנקראת Community String – מעין סיסמה המשמשת את ה-Manager בעת בקשות ל-Agent, ולה שתי רמות גישה: קריאה-בלבד ו-קריאה-כתיבה. Community string מסוג קריאה-בלבד מאפשרת ל-Manager לקרוא מידע ב-MIB של ההתקן, ו-Community string מסוג קריאה-כתיבה מאפשר ל-Manager לקרוא ולשנות מידע ב-MIB של ההתקן.

אם התוקף מצליח לגלות ה-Community string מסוג קריאה-כתיבה, הוא יכול בקלות לשנות ערכים ב-MIB ולכן גם לשנות הגדרות של אותו התקן. אבל כאמור, רוב אנשי המקצוע אינם מודעים לאופן פעילות הפרוטוקול ולכן משאירים את אותן סיסמאות בברירת המחדל שלהם – אותן אפשר למצוא בקלות באינטרנט ע"פ היצרן. בנוסף, רבים מאפשרים (או יותר נכון - לא מונעים) גישה לפרוטוקול (פורטים 161 ו-162) מרחוק – באמצעות האינטרנט. אם כך, התוקף מתחבר דרך פורט 161 ומוצא נתונים מעניינים ב-MIB של האובייקטים כגון:

• שמות המשתמשים
• .server.svUserTable.svUserEntry.svUserName.
• שמות ההתקנים המשותפים
• server.svShareTable.svShareEntry.svShareName.
• הערות אודות ההתקנים המשותפים
• server.svShareTable.svShareEntry.svShareComment.
• מיקום (לוגי) ההתקנים
• server.svShareTable.svShareEntry.svSharePath.
• שירותי רשת פועלים
• server.svSvcTable.svSvcEntry.svSvcName.

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

ע"מ להגן רשתות מסוג זה של התקפות (מיפוי הרשת ושינוי הגדרות התקנים דרך פרוטוקול ה-SNMP), יש תחילה לשנות את ה-Community string מברירת המחדל שלו, ולהגדיר סיסמא חזקה (אינה מכילה מילה שלמה, לפחות 8 תווים ולא מכילה שם משתמש או את שם החברה\ארגון...). בנוסף, יש להגביל גישה של רשתות לא מהימנות (כגון האינטרנט) לפורטים 161 ו-162 (פורטים ידועים של ה-SNMP). אם אין אפשרות להגביל גישה של רשתות לא מהימנות – הגדירו את הנתב (או את חומת האש) לאפשר תעבורה רק דרך פרוטוקול UDP.

Dynamic Host Configuration Protocol - DHCP

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

DHCP הוא פרוטוקול מבוסס UDP, המאפשר לשרתים להקצות כתובות רשת והגדרות מתאימות למחשבי הרשת. איך הוא עובד?

תחילה, המחשב (Client) שולח הודעת DHCPDISCOVER למחשבי הרשת ע"מ לזהות את שרת ה-DHCP. כאשר שרת ה-DHCP מקבל הודעה זו – הוא עונה בהודעת DHCPOFFER – בו הוא "מציע" למחשב המיועד כתובת IP. כאשר המחשב המיועד מקבל את ההודעה – הוא עונה לשרת באמצעות הודעת DHCPREQUEST, המאשר לשרת את קבלת ההגדרות. השרת כעת מחזיר הודעת "אישור" DHCPACK המכילה את תוקף זמן ההקצאה.

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

תהליך בקשת וקבלת כתובות והגדרות IP משרת ה-DHCP

Address Resolution Protocol - ARP

ברשתות TCP/IP, כל מחשב והתקן רשת חייב להכיל כתובת רשת פיזית וכתובת IP  – שונות. כל כרטיס רשת (Network Interface Card – NIC) חייב להכיל כתובת פיזית ייחודית לו – המוטמעת בצ'יפ ה-ROM שלו. כתובת פיזית זו מכונה לעתים גם כתובת MAC – Media Access Control והיא שונה מהתקן להתקן (הכתובת מורכבת מ-48 סיביות כאשר 24 הסיביות הראשונות מזהות את היצרן ו-24 הסיביות האחרות מהוות כמעין מספר סידורי הניתן להתקן ע"י היצרן.). בעוד שכבת הרשת מבינה כתובות IP ושכבת קישור הנתונים מבינה כתובות פיזיות – איך שני סוגי כתובות אלה עובדות יחדיו?

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

ARP table cache poisoning – לעתים קרובות, תוקפים משנים את נתוני הטבלה כדי לקבל מנות (Packets) שמיועד למחשב אחר. התקפה מסוג זה נקראת לעיתים גם ARP Poisoning או ARP spoofing.
ובכן, ARP הינו פרוטוקול קריטי לתקשורת בין מערכות, אבל הוא חשוף להתקפות התחזות המשנות את טבלת המיפוי שלו. הפרוטוקול אינו מכיל אמצעי הגנה ולכן, יש לוודא כי קיים IDS שיוכל להתריע בעת התקפות מסוג זה.

טופולגית התקפה טיפוסית מסוג ARP Poisoning. האיור באדיבות windowsecurity.com

Internet Control Message Protocol - ICMP

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

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

התקפה נוספת ופופולרית לא פחות, היא התקפת ה- Ping of Death. זוהי התקפה המתבססת על שימוש במנות ICMP גדולות מהרגיל; מנות ICMP בד"כ מגיעות בגדלים של 65,536 בתים. מערכות רבות אינן יודעות איך להתנהג עם מנות גדולות מאלה – מה שגורם לקריסתם (או הקפאתם). כן, ניחשתם נכון – זו התקפת מניעת שירות (DDoS) קלאסית.

התקפה נוספת העושה שימוש בעקרונות ה-ICMP היא Smurf Attack. בהתקפה מסוג זה, התוקף בד"כ מגדיר כיעד מחשב בודד השייך כחלק מרשת גדולה. הוא שולח מנות מסוג ICMP ECHO REQUEST כאשר כתובת מקור המנות – מזויפת, ומכילה במקום את כתובת הקורבן, וכתובת היעד ככתובת ה-Broadcast של רשת הקורבן. כל מחשבי הרשת (באותו Subnet, חשוב לי לציין) מקבלים בקשות אלו ומגיבים בשליחת מנות מסוג ICMP ECHO REPLY אל כתובת המקור המזויפות – כלומר, אל הקורבן. ביצוע הפעולות הנ"ל באופן שחוזר על עצמו – סביר להניח שיגרום לקריסת המערכת או הקפאתו. גם זו התקפת מניעת שירות (DDoS) קלאסית.

התקפה דומה ל-Smurf הינה Fraggle Attack. בעוד ש-Smurf Attack משתמש בפרוטוקול ICMP – ה-Fraggle Attack עושה שימוש בפרוטוקול UDP. התקפות מסוג זה משתמשות בזיוף מקור השליחה (Spoofing) ומיועדות לביצוע DDoS.

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

התקפת Smurf למניעת שירות

Domain Name Service - DNS

תארו לכם עולם כאשר השימוש באינטרנט נעשה ע"י (זכירת) כתובות IP בכל פעם שתרצו להיכנס לאתר אינטרנט מסוים. באסה, נכון?

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

בתחילת ימי "האינטרנט" (אנחנו מדברים על סוף שנות ה-60, תחילת שנות ה-70, עת היו קיימות מס' רשתות TCP/IP כגון ARPANET ש-לימים היוו אבן יסוד לאינטרנט שאנו מכירים היום), שהיה בזמנו מורכב מבערך 100 מחשבים (היום, לצורך השוואה, מעל מיליארד מחשבים) – לא היה צורך בשירות שכזה. הייתה קיימת רשימת טקסט (שבד"כ נשמרה ב-FTP כדי להנגישה לכולם) ובה ממופות כתובות הרשת למערכות השונות. לא עבר זמן רב עד שהבינו כי תחזוקה של רשימה כזו תהיה מסובכת ותגזול זמן יקר הן למפעילים והן למשתמשים. לכן, קהילת אנשי המחשב דאז חיפשו דרך לְאַטמֵט (מלשון אוטומציה) את כל הקשור לתחזוקה, הפעלה וניהול הרשימה. לכן, פותחו מערכות שעושות את העבודה הדרושה ושמן –Domain Name Systems  ותפקידן – "המרת" כתובות הכתובות ב"שפה אנושית" לכתובות שהמחשב מבין – כתובות IP. אם שמתם לב, רשמתי את תת-הכותרת בפוסט זה כ- Domain Name Service ולא כ-Domain Name System. שני המונחים חופפים, אך ברצוני לדון על הנושא ברמת השירות ולא ברמת המערכת.

כיום, חברות וארגונים רבים עושים שימוש בשרתי DNS משלהם, וזאת ע"מ למפות התקנים המחוברים לרשת הארגון\חברה. סביר כי חברות וארגונים אלה יעשו שימוש גם בשרתי DNS ציבוריים (אלה הניתנים להם ע"י ספקית האינטרנט או אלה המוענקים ע"י "גוגל", למשל.) כדי למפות את רשת האינטרנט כולה. בתוך ה-DNS, מרחב השמות (namespace) מחולק ל"אזורים" (Zones); אזור אחד יכול להכיל את שמות התקני הרשת (hostnames, ליתר דיוק) של מחלקות הארגון (מכירות, משאבי אנוש וכו'), ואזור שני יכיל hostnames לניהול, מחקר ותחזוקה של הרשת. שרתי ה-DNS המחזיקים בקבצי ה-zones מוגדרים כאוטוריטטיביים (Authoritative) לאותו zone.

חשוב ומומלץ שלכל Zone יהיו שני שרתי DNS "שיכסו" אחד על השני – אלה נקראים שרת DNS ראשי ושרת DNS משני (Primary and secondary DNS servers). שרת ה-DNS המשני מכיל עותק של רשומות (records) האזורים הקיים בשרת ה-DNS הראשי, כך שאם השרת הראשי נופל מסיבה כלשהי, משתמשים יוכלו לגשת לכתובות בעזרת השרת המשני.

כאשר נעשה שינוי בשרת ה-DNS הראשי, יש להעתיק את אותו שינוי גם לשרת המשני. תהליך סנכרון זה בין שני השרתים נקרא "העברת אזורים" או ליתר דיוק – Zone transfer; האקרים ותוקפים משתמשים במנגנון זה כבר שנים כדי לבצע "העברות אזורים" לא מורשות. טכניקת התקפה זו נחשבת למסוכנת מאוד – שכן אם התוקף מצליח לבצע העברה לא מורשית, הוא חשוף למידע שימושי אודות כל המערכות ברשת; מיהם שרתי ה-DNS, מיהם שרתי ה-DHCP וכו' – מה שמעניק לו יכולת מיפוי מלאה של כל רשת הארגון. 

לא כל שרתי ה-DNS יודעים את כל ההקצאות בין hostname לכתובת IP. אם נשלחה בקשה לשרת DNS א', הוא יחפש ברשומות אצלו אם קיימת התאמה – אם לא, הוא יעביר את הבקשה לשרת DNS ב' וזה יחפש התאמה ל-hostname וכך הלאה. כאשר נמצאת התאמה, היא נשלחת חזרה לשרת א' וזה שומר את אותה התאמה במעין זיכרון מטמון (Cache).

אציג תרחיש העושה שימוש במאפיין זה: נניח כי יוסי רוצה שבכל פעם שרינה – הלקוחה שלו, מנסה להיכנס לאתר המתחרה בו – היא תכוון אוטומטית לאתר שלו. לכן, יוסי עושה שימוש בכלי ש"מאזין" לכל הבקשות מ-שרת DNS א' לשרתי DNS אחרים עת שרת א' אינו מוצא רשומה מתאימה לבקשה. כאשר יוסי מבחין בבקשה שכזו, הוא מיד מחזיר תגובה לשרת א' עם רשומה שמתאימה את כתובת הבקשה – לכתובת האתר שלו. שרת DNS א' מקבל תשובה עם מיפוי שגוי לכתובת המבוקשת, מפנה את רינה לכתובת האתר של יוסי ושומר את אותו מיפוי בזיכרון המטמון שלו. צדקתם, עכשיו לא רק רינה מופנית לאתר של יוסי – אלא כל מי שינסה להיכנס לאתר המתחרה. התקפה כזו מוגדרת כהתקפה מסוג DNS Pharming או DNS Cache Poisoning.

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

DNSSEC מיושמת כבר ברוב התוכנות המפעילות שרתי DNS. היא משתמשת בתעודות דיגיטליות ומיישמת PKI - Public Key Infrastructure לאימות מקור הבקשות ומבטיחה לזהות מקורות מזויפים (Spoofed) שבד"כ זדוניים.

נשמע אולי מבטיח, אבל כדי ש-DNSSEC תפעל ביעילות – כל שרתי ה-DNS באינטרנט חייבים להשתתף ב-PKI, מה שכבר הוכח כ-מאוד קשה ואולי בלתי אפשר ליישום. חרף זאת, אני רואה  עוד ועוד ארגונים בעולם המיישמים בקרה זו ומעודדים שימושה.

ממשלת ארה"ב הורתה להשתמש ב-DNSSEC בכל דומיין הנחשב "Top-Level" - (דומיין המסתיים ב .mil, .gov) מדינות רבות הלכו בעקבותיה ויישמו בקרה זו גם לכל דומיין top-level שלה.

טופולוגית התקפה מסוג DNS cache poisoning

לעתים קרובות, תוקפים יעדיפו להשתמש בטכניקות פשוטות הרבה יותר ע"מ לנתב תעבורת משתמשים לכתובות מזויפות. הטכניקה הידועה ביותר היא ע"י "הסתרת ה-URL" או URL Masking – בה התוקף יוצר מסמכי HTML ומטמיע כתובת מזויפת בכפתורים או קישורים המבקשים ל-"לחץ כאן" – קישורים שאתם רואים הרבה בדוא"ל שלכם ובאתרי אינטרנט שונים. ההגנה היעילה ביותר כנגד התקפות מסוג זה היא – ערנות; לא למהר וללחוץ על קישורים – במיוחד אלו הנמצאים במכתבי דוא"ל ובאתרים לא מהימנים, ותמיד – לבדוק בשורת הכתובת של הדפדפן אם זהו האתר שבאמת התכוונתם להיכנס אליו.