פרוטוקולי זרימה ככלי לניטור אבטחת רשת פנימית

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

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

הייתי מדגיש שלושה מקורות נתונים מרכזיים לניטור תשתית ברמת הרשת:

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

לכידת תעבורה גולמית היא האפשרות הפופולרית ביותר בקרב מומחי אבטחה, מכיוון שהיא הופיעה היסטורית והייתה הראשונה. מערכות קונבנציונליות לזיהוי פריצות לרשת (המערכת המסחרית הראשונה לזיהוי פריצה הייתה NetRanger מקבוצת Wheel, שנרכשה ב-1998 על ידי סיסקו) עסקו בדיוק בלכידת מנות (ובמפגשים מאוחרים יותר) שבהן חיפשו חתימות מסוימות ("כללים מכריעים" ב- מינוח FSTEC), איתות התקפות. כמובן, אתה יכול לנתח תעבורה גולמית לא רק באמצעות IDS, אלא גם באמצעות כלים אחרים (לדוגמה, Wireshark, tcpdum או פונקציונליות NBAR2 ב-Cisco IOS), אך לרוב חסר להם בסיס הידע שמבדיל בין כלי אבטחת מידע לבין כלי רגיל כלי IT.

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

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

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

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

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

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

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

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

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

בואו נדמיין רשת הפועלת במהירות של 250 Mbit/sec. אם אתה רוצה לאחסן את כל הנפח הזה, אז תצטרך 31 מגה-בייט של אחסון עבור שנייה אחת של שידור תעבורה, 1,8 ג'יגה-בייט לדקה אחת, 108 ג'יגה-בייט לשעה אחת ו-2,6 טרה-בייט ליום אחד. כדי לאחסן נתונים יומיים מרשת ברוחב פס של 10 Gbit/s, תזדקק לאחסון של 108 TB. אבל חלק מהרגולטורים דורשים אחסון נתוני אבטחה במשך שנים... הקלטה לפי דרישה, שניתוח זרימה עוזר לך ליישם, עוזרת להפחית את הערכים האלה בסדרי גודל. אגב, אם אנחנו מדברים על היחס בין נפח נתוני הטלמטריה המוקלטים ברשת ולכידת נתונים מלאה, אז זה הוא בערך 1 עד 500. עבור אותם ערכים שניתנו לעיל, אחסון תמליל מלא של כל התעבורה היומית יהיה 5 ו-216 GB, בהתאמה (אתה יכול אפילו להקליט אותו בכונן הבזק רגיל).

אם עבור כלים לניתוח נתוני רשת גולמיים, שיטת לכידתם כמעט זהה מספק לספק, הרי שבמקרה של ניתוח תזרים המצב שונה. ישנן מספר אפשרויות לפרוטוקולי זרימה, על ההבדלים שבהם אתה צריך לדעת בהקשר של אבטחה. הפופולרי ביותר הוא פרוטוקול Netflow שפותח על ידי סיסקו. ישנן מספר גרסאות של פרוטוקול זה, שונות ביכולות שלהן ובכמות מידע התעבורה שנרשם. הגרסה הנוכחית היא התשיעית (Netflow v9), שעל בסיסה פותח התקן התעשייה Netflow v10, הידוע גם בשם IPFIX. כיום, רוב ספקי הרשת תומכים ב-Netflow או IPFIX בציוד שלהם. אבל יש עוד אפשרויות שונות לפרוטוקולי זרימה - sFlow, jFlow, cFlow, rFlow, NetStream וכו', ש-sFlow הוא הפופולרי ביותר. סוג זה נתמך לרוב על ידי יצרנים מקומיים של ציוד רשת בגלל קלות היישום שלו. מהם ההבדלים העיקריים בין Netflow, שהפכה לתקן דה פקטו, לבין sFlow? הייתי מדגיש כמה מרכזיים. ראשית, ל-Netflow יש שדות הניתנים להתאמה אישית של המשתמש, בניגוד לשדות הקבועים ב-sFlow. ושנית, וזה הדבר החשוב ביותר במקרה שלנו, sFlow אוסף מה שנקרא טלמטריה מדוגמת; בניגוד לזה שלא נדגם עבור Netflow ו-IPFIX. מה ההבדל ביניהם?

תאר לעצמך שאתה מחליט לקרוא את הספר"מרכז תפעול אבטחה: בנייה, הפעלה ותחזוקה של ה-SOC שלך” של הקולגות שלי - גארי מקינטייר, ג'וזף מוניץ ונאדם אלפרדן (ניתן להוריד חלק מהספר מהקישור). יש לך שלוש אפשרויות להשיג את המטרה שלך - קרא את הספר כולו, דפדוף בו, עצור בכל עמוד 10 או 20, או נסה למצוא תיאור מחדש של מושגי מפתח בבלוג או שירות כמו SmartReading. אז, טלמטריה ללא דגימה קוראת כל "עמוד" של תעבורת רשת, כלומר מנתחת מטא נתונים עבור כל מנה. טלמטריה מדוגמת היא מחקר סלקטיבי של תעבורה בתקווה שהדגימות שנבחרו יכילו את מה שאתה צריך. בהתאם למהירות הערוץ, טלמטריה מדוגמת תישלח לניתוח כל חבילה 64, 200, 500, 1000, 2000 או אפילו 10000.

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

כמובן, איזשהו מנתח Netflow בקוד פתוח לא יאפשר לכם לעשות זאת, שכן המשימה העיקרית שלו היא לאסוף טלמטריה ולערוך עליה ניתוח בסיסי מנקודת מבט של IT. כדי לזהות איומי אבטחת מידע על סמך זרימה, יש צורך לצייד את המנתח במנועים ואלגוריתמים שונים, שיזהו בעיות אבטחת סייבר על סמך שדות Netflow סטנדרטיים או מותאמים אישית, יעשירו נתונים סטנדרטיים בנתונים חיצוניים ממקורות שונים של Threat Intelligence וכו'.

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

בקיץ 2019, ניתחתי את היכולות שיש ליצרניות חומרת רשתות רוסיות וכולם, למעט NSG, Polygon ו-Craftway, הכריזו על תמיכה ב-sFlow (לפחות Zelax, Natex, Eltex, QTech, Rusteleteh).

השאלה הבאה שתתמודד איתה היא היכן ליישם תמיכה בזרימה למטרות אבטחה? למעשה, השאלה אינה מוגשת כהלכה. ציוד מודרני כמעט תמיד תומך בפרוטוקולי זרימה. לכן, הייתי מנסח מחדש את השאלה אחרת – היכן הכי יעיל לאסוף טלמטריה מנקודת מבט אבטחה? התשובה תהיה די ברורה - ברמת הגישה, שם תראה 100% מכל התעבורה, שם יהיה לך מידע מפורט על מארחים (MAC, VLAN, interface ID), שם תוכל אפילו לנטר תעבורת P2P בין מארחים, אשר הוא קריטי לזיהוי והפצה של קוד זדוני בסריקה. ברמת הליבה, אולי פשוט לא תראה חלק מהתנועה, אבל ברמת ההיקפית, תראה רבע מכל תעבורת הרשת שלך. אבל אם מסיבה כלשהי יש לך מכשירים זרים ברשת שמאפשרים לתוקפים "להיכנס ולצאת" מבלי לעקוף את ההיקף, אז ניתוח הטלמטריה ממנו לא ייתן לך כלום. לכן, לכיסוי מרבי, מומלץ לאפשר איסוף טלמטריה ברמת הגישה. יחד עם זאת, ראוי לציין שגם אם אנחנו מדברים על וירטואליזציה או קונטיינרים, תמיכה בזרימה נמצאת לרוב גם במתגים וירטואליים מודרניים, המאפשרים לשלוט על התעבורה גם שם.

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

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

אנו משתמשים בפתרון משלנו כמערכת ניטור של Netflow Cisco Stealthwatch, המתמקד במיוחד בפתרון בעיות אבטחה. יש בו מנועים מובנים רבים לאיתור פעילות חריגה, חשודה וזדונית בעליל, מה שמאפשר לזהות מגוון רחב של איומים שונים – מהצפנה ועד דליפות מידע, מהפצת קוד זדוני ועד הונאה. כמו רוב מנתחי הזרימה, Stealthwatch בנוי לפי סכימה בת שלוש רמות (גנרטור - אספן - מנתח), אך מתווספות לו מספר תכונות מעניינות שחשובות בהקשר של החומר הנבחן. ראשית, הוא משתלב עם פתרונות לכידת מנות (כגון Cisco Security Packet Analyzer), המאפשר לך להקליט הפעלות רשת נבחרות לחקירה וניתוח מעמיקים מאוחר יותר. שנית, במיוחד כדי להרחיב את משימות האבטחה, פיתחנו פרוטוקול nvzFlow מיוחד, המאפשר "לשדר" את פעילות האפליקציות בצמתי קצה (שרתים, תחנות עבודה וכו') לטלמטריה ולשדר אותה לאספן להמשך ניתוח. אם בגרסה המקורית שלו Stealthwatch עובד עם פרוטוקול זרימה כלשהו (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) ברמת הרשת, אז תמיכת nvzFlow מאפשרת מתאם נתונים גם ברמת הצומת, ובכך. להגדיל את היעילות של המערכת כולה ולראות יותר התקפות מאשר מנתחי זרימת רשת רגילים.

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

SiLK היא מערכת כלים (המערכת לידע ברמת אינטרנט) לניתוח תעבורה, שפותחה על ידי ה-CERT/CC האמריקאית ותומכת, בהקשר של המאמר של היום, Netflow (5 ו-9, הגרסאות הפופולריות ביותר), IPFIX ו-sFlow ושימוש בכלי עזר שונים (rwfilter, rwcount, rwflowpack וכו') לביצוע פעולות שונות על טלמטריית רשת על מנת לזהות סימנים של פעולות לא מורשות בה. אבל יש לציין כמה נקודות חשובות. SiLK הוא כלי שורת פקודה המבצע ניתוח מקוון על ידי הזנת פקודות כמו זו (זיהוי מנות ICMP הגדולות מ-200 בתים):

rwfilter --flowtypes=all/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15

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

• ניסוח השערה. עלינו להבין מה נחפש בתוך הטלמטריה של הרשת, להכיר את התכונות הייחודיות שבאמצעותן נזהה חריגות או איומים מסוימים.
• בניית מודל. לאחר שגיבשנו השערה, אנו מתכנתים אותה באמצעות אותו Python, מעטפת או כלים אחרים שאינם כלולים ב- SiLK.
• בדיקה. כעת מגיע התור לבדוק את נכונות ההשערה שלנו, אשר מאושרת או מופרכת באמצעות כלי עזר של SiLK המתחילים ב-'rw', 'set', 'bag'.
• ניתוח נתונים אמיתיים. בתפעול תעשייתי, SiLK עוזרת לנו לזהות משהו ועל האנליטיקאי לענות על השאלות "האם מצאנו את מה שציפינו?", "האם זה תואם את ההשערה שלנו?", "כיצד להפחית את מספר התוצאות השוואיות?", "כיצד לשפר את רמת ההכרה? » וכולי.
• הַשׁבָּחָה. בשלב הסופי אנו משפרים את הנעשה קודם - יוצרים תבניות, משפרים ומייעלים את הקוד, מנסחים מחדש ומבהירים את ההשערה וכו'.

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

אם אתה הולך גבוה יותר בפירמידה "בתשלום" עבור תוכנת ניתוח זרימה, אז אחרי ה-SiLK החינמי לחלוטין תהיה ELK תוכנת שיתוף, המורכבת משלושה מרכיבים מרכזיים - Elasticsearch (אינדקס, חיפוש וניתוח נתונים), Logstash (קלט/פלט נתונים. ) ו-Kibana (הדמיה). בניגוד ל-SiLK, שבו אתה צריך לכתוב הכל בעצמך, ל-ELK יש כבר הרבה ספריות/מודולים מוכנים (חלקם בתשלום, חלקם לא) שמאוטמים את הניתוח של טלמטריית רשת. לדוגמה, מסנן GeoIP ב-Logstash מאפשר לך לשייך כתובות IP מנוטרות למיקומן הגיאוגרפי (ל-Stealthwatch יש תכונה מובנית זו).

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

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

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

באופן כללי, אני לא רוצה להיכנס לוויכוח שעדיף להוציא כסף ולקנות פתרון מוכן לניטור חריגות ואיומים בטלמטריית רשת (לדוגמה, Cisco Stealthwatch) או להבין את זה בעצמך ולהתאים אישית את אותו הדבר. SiLK, ELK או nfdump או OSU Flow Tools עבור כל איום חדש (אני מדבר על השניים האחרונים שבהם סיפר פעם אחרונה)? כל אחד בוחר בעצמו ולכל אחד יש את המניעים שלו לבחור בכל אחת משתי האפשרויות. רק רציתי להראות שטלמטריית רשת היא כלי חשוב מאוד בהבטחת אבטחת הרשת של התשתית הפנימית שלכם ואסור לכם להזניח אותה, כדי לא להצטרף לרשימת החברות ששמם מוזכר בתקשורת יחד עם הכינויים " פרוץ", "לא עומד בדרישות אבטחת מידע" ", "לא חושב על אבטחת הנתונים שלהם ונתוני לקוחות."

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

1. אל תגביל את עצמך רק להיקף! השתמש (ובחר) בתשתית רשת לא רק כדי להעביר תעבורה מנקודה A לנקודה B, אלא גם כדי לטפל בבעיות אבטחת סייבר.
2. למד את מנגנוני ניטור אבטחת המידע הקיימים בציוד הרשת שלך והשתמש בהם.
3. לניטור פנימי, העדיפו ניתוח טלמטריה - הוא מאפשר לזהות עד 80-90% מכל אירועי אבטחת המידע ברשת, תוך ביצוע מה שאי אפשר בעת לכידת מנות רשת וחיסכון במקום לאחסון כל אירועי אבטחת המידע.
4. כדי לנטר זרימות, השתמש ב-Netflow v9 או IPFIX - הם מספקים מידע נוסף בהקשר אבטחה ומאפשרים לך לנטר לא רק IPv4, אלא גם IPv6, MPLS וכו'.
5. השתמש בפרוטוקול זרימה ללא דגימה - הוא מספק מידע נוסף לאיתור איומים. לדוגמה, Netflow או IPFIX.
6. בדוק את העומס על ציוד הרשת שלך - ייתכן שהוא לא יוכל להתמודד גם עם פרוטוקול הזרימה. לאחר מכן שקול להשתמש בחיישנים וירטואליים או ב-Netflow Generation Appliance.
7. הטמע שליטה קודם כל ברמת הגישה - זה ייתן לך את ההזדמנות לראות 100% מכל התעבורה.
8. אם אין לך ברירה ואתה משתמש בציוד רשת רוסי, בחר באחד שתומך בפרוטוקולי זרימה או בעל יציאות SPAN/RSPAN.
9. שלב מערכות זיהוי/מניעת חדירה/תקיפה בקצוות ומערכות ניתוח זרימה ברשת הפנימית (כולל בעננים).

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

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

מידע נוסף:

• תיאור של Cisco IOS Netflow
• מטריצת תמיכה של Netflow בפתרונות Cisco השונים
• מדריך להגדרת Netflow בפלטפורמות שונות של Cisco
• קהילת sFlow
• מעבדה באמצעות Stealtjwatch, SiLK ו-ELK כדי לנתח את Netflow מנקודת מבט אבטחה
• אתר SiLK
• מדריך בן שלוש מאות עמודים לשימוש ב-SiLK עם המון דוגמאות
• Logstash Netflow Module
• סיסקו מדריך שלב אחר שלב לניתוח Netflow ב-ELK
• ניתוח של NetFlow v.9 Cisco ASA באמצעות Logstash (ELK)
• פתרון Cisco Stealthwatch

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

מקור: www.habr.com