Zeek Logs: איך חוקרים conn.log, dns.log ו-http.log

מבנה Logs ו-UID

השדות החשובים אינם בהכרח אלה שמוצגים בראש המסך. ב-Zeek Logs יש לזהות מזהים יציבים, זמן, מקור, יעד, תוצאה והקשר. דוגמאות שימושיות הן query name, response code, TTL, subdomain entropy, NXDOMAIN ratio, resolver context. המטרה היא לאפשר Correlation בין רשומות ולא רק קריאה של Event בודד.

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

conn.log

הנושא 'conn.log' הוא חלק מרכזי בעבודה על Zeek Logs. מומלץ לפרק אותו לשלוש שאלות: מהו הקלט, איזו החלטה רוצים לקבל, ואיזו ראיה מספיקה כדי להצדיק אותה. השאלות האלה מונעות שימוש אוטומטי בכלי ללא הבנת המטרה.

בתרגול, רשמו את query name, response code, TTL, subdomain entropy, NXDOMAIN ratio, השוו להתנהגות צפויה והגדירו Pivot אחד לפחות. התוצאה צריכה להיות ניתנת לבדיקה על ידי אנליסט נוסף, כולל מגבלות וצעדי המשך.

dns.log

הנושא 'dns.log' הוא חלק מרכזי בעבודה על Zeek Logs. מומלץ לפרק אותו לשלוש שאלות: מהו הקלט, איזו החלטה רוצים לקבל, ואיזו ראיה מספיקה כדי להצדיק אותה. השאלות האלה מונעות שימוש אוטומטי בכלי ללא הבנת המטרה.

בתרגול, רשמו את query name, response code, TTL, subdomain entropy, NXDOMAIN ratio, השוו להתנהגות צפויה והגדירו Pivot אחד לפחות. התוצאה צריכה להיות ניתנת לבדיקה על ידי אנליסט נוסף, כולל מגבלות וצעדי המשך.

http.log ו-tls.log

הנושא 'http.log ו-tls.log' הוא חלק מרכזי בעבודה על Zeek Logs. מומלץ לפרק אותו לשלוש שאלות: מהו הקלט, איזו החלטה רוצים לקבל, ואיזו ראיה מספיקה כדי להצדיק אותה. השאלות האלה מונעות שימוש אוטומטי בכלי ללא הבנת המטרה.

בתרגול, רשמו את query name, response code, TTL, subdomain entropy, NXDOMAIN ratio, השוו להתנהגות צפויה והגדירו Pivot אחד לפחות. התוצאה צריכה להיות ניתנת לבדיקה על ידי אנליסט נוסף, כולל מגבלות וצעדי המשך.

Correlation ו-Timeline

Timeline הוא עמוד השדרה של Zeek Logs. מנרמלים זמנים ל-UTC או מציינים במפורש את אזור הזמן, שומרים גם Event time וגם Ingestion time, ומחברים אירועים לפי מזהים יציבים. השורה צריכה לכלול זמן, מקור, ישות, פעולה, תוצאה ואמינות.

פער או סתירה אינם תקלה במסמך אלא ממצא. Clock drift, עיכוב קליטה, NAT, reuse של PID או Session מתמשך יכולים לשנות סדר. לכן מציינים טווחי אי-ודאות ומחזיקים קישור חזרה לראיה הגולמית.

מתי חוזרים ל-PCAP

הנושא 'מתי חוזרים ל-PCAP' הוא חלק מרכזי בעבודה על Zeek Logs. מומלץ לפרק אותו לשלוש שאלות: מהו הקלט, איזו החלטה רוצים לקבל, ואיזו ראיה מספיקה כדי להצדיק אותה. השאלות האלה מונעות שימוש אוטומטי בכלי ללא הבנת המטרה.

בתרגול, רשמו את query name, response code, TTL, subdomain entropy, NXDOMAIN ratio, השוו להתנהגות צפויה והגדירו Pivot אחד לפחות. התוצאה צריכה להיות ניתנת לבדיקה על ידי אנליסט נוסף, כולל מגבלות וצעדי המשך.

מוקדי בדיקה ייחודיים

בנושא הזה מומלץ לבנות מראש מפת ראיות ממוקדת. מוקדי הבדיקה המרכזיים הם: query name, response code, TTL, subdomain entropy, NXDOMAIN ratio, resolver context, uid, conn.log, dns.log, http.log. הרשימה אינה Checklist אוטומטי; כל פריט נבחר משום שהוא יכול לקשור בין ישות, פעולה וזמן או להסביר התנהגות לגיטימית.

• query name: הגדירו מהו הערך הצפוי, מה ייחשב חריג ואיזה מקור נוסף יאמת את הממצא.
• response code: הגדירו מהו הערך הצפוי, מה ייחשב חריג ואיזה מקור נוסף יאמת את הממצא.
• TTL: הגדירו מהו הערך הצפוי, מה ייחשב חריג ואיזה מקור נוסף יאמת את הממצא.
• subdomain entropy: הגדירו מהו הערך הצפוי, מה ייחשב חריג ואיזה מקור נוסף יאמת את הממצא.
• NXDOMAIN ratio: הגדירו מהו הערך הצפוי, מה ייחשב חריג ואיזה מקור נוסף יאמת את הממצא.
• resolver context: הגדירו מהו הערך הצפוי, מה ייחשב חריג ואיזה מקור נוסף יאמת את הממצא.

כאשר אחד המוקדים אינו זמין, יש לתעד את הפער ולבחור חלופה. לדוגמה, אם Process identifier אינו יציב, אפשר להיעזר בזמן, Host, User ו-Parent; אם Payload מוצפן, משתמשים ב-Metadata, נפח, תדירות ו-TLS/DNS context.

תהליך עבודה מומלץ

1. הגדירו Scope ושאלת עבודה אחת בנושא Zeek Logs.
2. רשמו את מקורות הנתונים והראיות הדרושים: query name, response code, TTL, subdomain entropy.
3. צרו Baseline קצר של התנהגות תקינה או תוצאה צפויה.
4. בצעו את הבדיקה המינימלית בסביבת מעבדה ושמרו זמן, קלט ופלט.
5. בנו Timeline או טבלת השוואה והפרידו בין עובדה לפרשנות.
6. בצעו Pivot למקור נוסף כדי לאמת או להפריך את ההסבר הראשוני.
7. סכמו החלטה, מגבלות, פעולה מומלצת וקריטריון Retest.

תרחיש מעשי

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

בסיום התרגיל יש להגיש תוצר שאנליסט או בודק אחר יכול לבקר: צילום או Export של הראיה, Timeline קצר, הנחה ראשונית, ראיה מאמתת, מגבלה והמלצה. כאשר אין ראיה מספקת, המסקנה התקינה היא שהתרחיש לא הוכח.

Checklist מעשי

• ✓בדקו ותעדו: חמשת רכיבי ה-Flow.
• ✓בדקו ותעדו: זמן התחלה, משך ונפח.
• ✓בדקו ותעדו: DNS name ו-TLS metadata.
• ✓בדקו ותעדו: HTTP method, host ו-URI כאשר גלויים.
• ✓בדקו ותעדו: TCP flags ו-stream.
• ✓בדקו ותעדו: קשר ל-Host ול-Process.
• ✓ציינו Time zone, גרסת כלי ושעת איסוף.
• ✓שמרו את הנתון הגולמי לפני סינון או שינוי.
• ✓כתבו מה הממצא מוכיח ומה עדיין אינו ידוע.
• ✓הגדירו בעלים ופעולת המשך עם מועד.

טעויות נפוצות

• לבלבל Capture Filter עם Display Filter.
• להסיק תוכן כאשר התעבורה מוצפנת.
• לנתח IP בלי DNS/TLS context.
• להתעלם מ-NAT או Proxy.
• להתמקד ב-Packet יחיד.
• לא לשמור Capture מקורי.

סיכום ו-CTA

Zeek Logs: איך חוקרים conn.log, dns.log ו-http.log הוא נושא שמחבר ידע טכני למשמעת עבודה. התחילו משאלה, אספו רק ראיות רלוונטיות, שמרו הקשר וזמן, ובחרו פעולה שאפשר להצדיק ולבדוק מחדש.

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

שאלות ותשובות

מקורות

• Zeek Documentation — Log files
• Wireshark User’s Guide
• Wireshark Display Filter Reference
• Suricata Documentation — EVE JSON
• MITRE ATT&CK — Command and Control