SPL למתחילים: חיפוש וחקירה ב-Splunk

החיפוש הראשוני

חיפוש פשוט ב-Splunk יכול להתחיל כך:

index=lab sourcetype=auth earliest=-24h

ה-Time Range Picker יכול להגדיר את הזמן, אך כתיבה מפורשת של earliest ו-latest מועילה לשחזור ולתיעוד. index מגביל למאגר מסוים ו-sourcetype מתאר את מבנה המקור. אפשר להוסיף תנאי שדה כבר בחיפוש הראשוני:

index=lab sourcetype=auth action=failure earliest=-24h

כאשר שדה קיים בזמן החיפוש, ציון `field=value` מדויק יותר מחיפוש טקסט חופשי. גרשיים נדרשים לערכים עם רווחים. Wildcards יכולים להיות שימושיים, אך Wildcard מוביל או חיפוש רחב פוגעים בביצועים ועלולים ליצור תוצאות לא צפויות.

Pipe ופקודות תצוגה

הסימן | מעביר את התוצאות לפקודה הבאה. `fields` שומר או מסיר שדות, ו-`table` מציג טבלה בסדר שנבחר. בתחילת חקירה table עוזר לקריאה, אך אל תשתמשו בו מוקדם מדי אם פקודה מאוחרת זקוקה לשדות שהסרתם.

index=lab sourcetype=auth earliest=-24h
| fields _time user src_ip action host
| table _time user src_ip action host

`rename` משנה שמות לתצוגה. `sort` ממיין, ו-`head` מגביל תוצאות. אירועים מוצגים בדרך כלל מהחדש לישן, אך כאשר בונים Timeline מומלץ למיין במפורש:

index=lab sourcetype=auth user="student" earliest=-4h
| table _time user src_ip action host
| sort 0 _time

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

eval — יצירת שדות

`eval` מחשבת או יוצרת שדה. אפשר להשתמש ב-if, case, lower, coalesce, tonumber ופונקציות נוספות. לדוגמה, יצירת Outcome אחיד:

index=lab sourcetype=auth earliest=-24h
| eval outcome=case(action="success", "Success", action="failure", "Failure", true(), "Other")
| table _time user src_ip action outcome

`where` מסננת באמצעות ביטוי לאחר שהאירועים נאספו או לאחר שנוצרו שדות. החיפוש הראשוני `action=failure` בדרך כלל עדיף לסינון בסיסי. `where` שימושית להשוואת שדות, תנאים מספריים או שדות שנוצרו ב-eval.

index=lab sourcetype=auth earliest=-24h
| stats count as attempts by user src_ip
| where attempts >= 5
| sort - attempts

stats — להפוך Events לשאלה

`stats` מחשבת Aggregations על התוצאות. ללא BY מתקבלת שורה אחת; עם BY מתקבלת שורה לכל שילוב ערכים. פקודות נפוצות כוללות count, sum, avg, min, max, values ו-dc — distinct count.

index=lab sourcetype=auth action=failure earliest=-24h
| stats count as failures,
        earliest(_time) as first_seen,
        latest(_time) as last_seen,
        values(src_ip) as src_ips
  by user
| convert ctime(first_seen) ctime(last_seen)
| sort - failures

`values` מחזירה ערכים ייחודיים ללא סדר מובטח ויכולה לגדול. השתמשו בה בזהירות והעדיפו רשימה מצומצמת או Drill-down כאשר יש הרבה IPs. `list` שומר ערכים לפי סדר אך עלול לצרוך יותר זיכרון.

stats מול eventstats ו-streamstats

מתחילים צריכים לשלוט ב-stats לפני שימוש ב-transaction. `transaction` יכולה להיות נוחה לקיבוץ, אך על נפחים גדולים היא יקרה ולעיתים מסתירה לוגיקה. פעמים רבות stats, streamstats או eventstats נותנות פתרון יעיל ושקוף יותר.

חלונות זמן ו-timechart

`timechart` יוצרת סדרת זמן ומקבצת לפי `_time`. היא טובה לזיהוי Spike, מגמה ושינוי בנפח. לדוגמה:

index=lab sourcetype=auth action=failure earliest=-24h
| timechart span=30m count by src_ip limit=10

בחרו span לפי השאלה. חלון קטן מדי ייצור רעש, וחלון גדול מדי יסתיר Burst. timechart היא Transforming command: התוצאה היא טבלה מסוכמת, לא האירועים הגולמיים. לצורך Evidence, בצעו Drill-down לטווח ול-IP הרלוונטיים.

תרגיל: כשלונות והצלחה באותו חלון

המטרה היא למצוא חלונות שבהם אותו משתמש ו-IP יצרו כמה כשלונות ולפחות הצלחה אחת. Query הבאה משתמשת ב-eval, bin ו-stats:

index=lab sourcetype=auth earliest=-24h
| eval failed=if(action="failure", 1, 0), success=if(action="success", 1, 0)
| bin _time span=30m
| stats sum(failed) as failures,
        sum(success) as successes,
        earliest(_time) as window_start,
        latest(_time) as window_end
  by _time user src_ip
| where failures >= 5 AND successes >= 1
| sort - failures

ה-Query מצביעה על חלון שדורש חקירה. משום שהנתונים סוכמו, היא אינה מוכיחה שההצלחה הייתה אחרי הכשלונות. השתמשו בתוצאה כדי להריץ Drill-down על user, src_ip והזמן:

index=lab sourcetype=auth user="student" src_ip="203.0.113.25" earliest="08/01/2026:09:00:00" latest="08/01/2026:09:30:00"
| table _time user src_ip action host reason
| sort 0 _time

בדקו: האם ההצלחה שייכת לאותו Host או App? האם כתובת המקור היא VPN? האם הכשלונות נגרמו מסיסמה ישנה בשירות? האם קיימת פעילות המשך? SPL מספקת את הנתונים; Classification דורשת הקשר.

שדות, Extraction ו-CIM

Splunk מחלצת שדות בזמן Indexing או Search. שדה חסר עשוי לדרוש `rex`, `spath` ל-JSON או הגדרת Field extraction. Extraction אד-הוק יכולה לעזור במעבדה, אך Detection production צריכה Parser ו-Data model מתוחזקים.

CIM מנרמלת מושגים בין מקורות, למשל Authentication.user או Network_Traffic.src. כאשר הארגון משתמש ב-CIM, אפשר לבנות Detections ו-Dashboards שניתנים לשימוש על כמה מוצרים. יש לבדוק שהנתונים באמת עומדים במודל ולא רק שה-App מותקן.

שיפור ביצועים וקריאות

• הגדירו Time range צר ככל האפשר.
• התחילו ב-index, sourcetype ושדות ממופים.
• סננו מוקדם לפני stats או sort.
• הימנעו מ-Wildcard מוביל ומחיפוש טקסט רחב כשקיים שדה.
• השתמשו ב-fields כדי לצמצם Payload, אך לא לפני פקודה שזקוקה לשדה.
• הגבילו values/list ופעולות עתירות זיכרון.
• תנו שמות ברורים לשדות באמצעות `as`.
• שמרו Query עם תיאור, Owner, זמן וגרסה.
• בדקו על Sample קטן לפני טווח ארוך.

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

• לחפש בכל ה-indexes ללא צורך.
• להניח ששדה action או user קיים בכל sourcetype.
• להשתמש ב-table מוקדם ולהסיר שדה שנדרש בהמשך.
• לפרש stats כ-Timeline מדויק.
• להשתמש ב-transaction כברירת מחדל.
• להפעיל Alert על Query שלא נבדקה מול Baseline.
• להעתיק SPL מגרסה או Data model אחר ללא התאמה.
• להתעלם מאזור הזמן ומ-Ingestion delay.

Checklist לתרגול

1. מצאו את ה-index וה-sourcetype של נתוני המעבדה.
2. הציגו חמישה Events ובדקו את השדות.
3. סננו משתמש או IP אחד.
4. הציגו Timeline באמצעות table ו-sort.
5. סכמו כשלונות באמצעות stats.
6. צרו שדה באמצעות eval וסננו אותו ב-where.
7. הציגו נפח לאורך זמן באמצעות timechart.
8. כתבו מה כל Query מוכיחה ומה אינה מוכיחה.

סיכום ו-CTA

הקימו index מעבדה קטן או השתמשו בנתונים מורשים, והריצו את אותו תרחיש בשלוש תצוגות: Raw events, stats ו-timechart. כתבו ליד כל תצוגה איזו שאלה היא עונה ואיזה Context חסר. השלב הבא הוא להפוך חיפוש יציב ל-Detection עם Owner, Threshold ו-Playbook — לא רק לשמור Query מרשימה.

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

מקורות

• Splunk Documentation — Get started with Search
• Splunk Documentation — About the search language
• Splunk Documentation — stats command
• Splunk Documentation — timechart command
• Splunk Documentation — Command quick reference