Wazuh הגדרה: מדוע אירועים אינם הופכים לאותות
איסוף לוגים וזיהוי איומים הם שתי משימות שונות, והגדרת Wazuh לרוב נכשלת בדיוק בנקודת החיבור. הסוכנים מותקנים, אירועים משרתים, אפליקציות וציוד רשת זורמים כסדרם לאינדקס, אך כללי המתאם נכתבו לתרחישים סטנדרטיים ואינם מכירים את התשתית שלכם.
כתוצאה מכך ניתוח הלוגים מתבצע, אך אין אות: בקונסולה אלפי אירועים, ומתוכם אפס התראות על תקיפה אמיתית.
המחיר של תצורה כזו מתגלה ברגע האירוע. ניסיונות ניחוש פרטי גישה לשירות, כניסה חריגה בשעות לא שגרתיות, סדרת כשלי אימות מכתובת אחת — כל אלה נמצאים בלוגים, אך אינם מעלים התראה.
האירוע מתגלה בדיעבד, כאשר מדווח עליו משתמש או קבלן, והחקירה מתחילה בחיפוש ידני באירועים גולמיים במקום בכרונולוגיה מוכנה.
סיבה טיפוסית שנייה היא רעש. כאשר כללים מופעלים על כל סטייה, זרם ההתראות הכוזבות גדל מהר יותר מקצב הטיפול של הצוות. התורן מפסיק לפתוח התראות, התראות קריטיות הולכות לאיבוד בין שגרתיות, והמערכת פועלת פורמלית אך למעשה אינה מגנה.
הגדרת Wazuh מתחילה לא בעריכת התצורה, אלא במלאי המקורות: אילו יומנים כבר נאספים, אילו אירועים בכלל מסוגלים להצביע על איום במתחם שלכם, והיכן עובר הגבול בין תקין לחריגה.
לאחר מכן כללי המתאם נקושרים לתרחישים אמיתיים — שרשראות אירועים ולא רשומות בודדות, והספים והחריגים מוגדרים כך שיסירו את הרעש ברקע מבלי לאבד רגישות.
מפרקים כיצד זה נסגר: מביקורת מקורות והגדרת כללים ועד בדיקה בתרחישי תרגול, כאשר אנו משחזרים בכוונה תקיפה ומוודאים שהאות הועלה, הגיע לתורן ומכיל מספיק הקשר לתגובה.
מה נותנת מערכת גילוי איומים בנויה היטב
מערכת גילוי איומים נמדדת לא במספר הסוכנים המותקנים, אלא בזמן מרגע האירוע החשוד הראשון ועד לתגובה ברורה. כל עוד יומני השרתים, ציוד הרשת והשירותים בענן מונחים במקומות שונים, וניתוח האירוע מתחיל באיסוף ידני של לוגים, כל תקיפה מרוויחה על פני המגנים שעות ויממות.
בדיוק את החלון הזה סוגרת מערכת בנויה היטב המבוססת על Wazuh: האירועים זורמים למאגר אחיד, כללי המתאם מופעלים על שרשרת פעולות, והתורן מקבל לא זרם של שורות גולמיות אלא תמונה מוכנה עם הקשר.
האפקט המדיד הראשון — צמצום הזמן עד לגילוי. במקום ללמוד על הבעיה מהמשתמשים או מדוח בסוף השבוע, הצוות רואה את האנומליה ברגע התפתחותה: כניסה חשודה, שינוי הרשאות, פנייה לפורט לא סטנדרטי.
בפועל החלון בין פעולת התוקף לבין האות מתכווץ משעות לדקות, וזה קובע ישירות אם הצוות מספיק לבודד את האיום לפני הוצאת הנתונים.
האפקט השני — שיעור מבוקר של התראות שווא. הכללים מותאמים לתשתית האמיתית: סקריפטים ניהוליים מוכרים, משימות מתוכננות וסורקים לגיטימיים מועברים לחריגים, והעדיפויות נקבעות לפי קריטיות הנכס.
התורן מפסיק לטבוע ברעש ומגיב למה שבאמת דורש תשומת לב — אחרת תוך כמה שבועות פשוט מפסיקים לקרוא את האותות.
השלישי — כיסוי מחלקות התקיפה ונראות התשתית. נבדקים תרחישים של ניחוש פרטי זיהוי, הסלמת הרשאות, פעילות חשודה על מארחים ובקונטיינרים, ושינויים בשלמות הקבצים. כל כלל קשור למקור האירועים, ולכן רואים אילו צמתים ושירותים נמצאים באמת תחת מעקב ואילו נותרו אזור עיוור.
התגובה לאירועים הופכת לשחזורית: יש מסלול הסלמה, פעולות טיפוסיות לפי מחלקות איומים וחומר לניתוח לאחר הסגירה.
השורה התחתונה — לא "עוד כלי", אלא מתאר צפוי: זמן גילוי ברור, רעש מבוקר, כיסוי ידוע ונוהל פעולה מתורגל בעת אירוע.
דרכי פריסה ואיסוף אירועים
הגדרת Wazuh מתחילה בבחירת ארכיטקטורת פריסה, ובחירה זו קובעת אילו אירועים בכלל ייכנסו לקורלציה. קיימות שלוש סכמות בסיסיות: סוכנים מקומיים על המארחים, איסוף דרך זרמי רשת, ואפשרות היברידית שבה חלק מהמקורות מעבירים טלמטריה ישירות, וחלק — דרך סוכן.
אין תשובה אוניברסאלית: הסכמה נקבעת לפי אילו מערכות נמצאות במתחם וכמה עמוק יש צורך לראות את המתרחש בתוכן.
הסוכן מספק את העומק המרבי — הוא קורא יומני יישומים, עוקב אחר שלמות קבצים, מיירט קריאות תהליכים ורואה את מה שבזרם רשת אינו משתקף באופן עקרוני. איסוף רשת, לעומת זאת, אינו דורש להתקין דבר על הצמתים: התעבורה נלקחת מפורט מראה או מנקודת אגרגציה ומנותחת בצד האוסף.
זה נוח למקטעים שאליהם לא ניתן להתקין סוכן — ציוד רשת, בקרים תעשייתיים, תת-רשתות זרות. ההיברידי מכסה מתחמים מעורבים, אך דורש נרמול קפדני: אירועים ממקורות שונים חייבים להיכנס לסכמת שדות משותפת, אחרת כללי הקורלציה פועלים לחינם.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| סוכנים מקומיים | מארחים ושירותים בניהולנו, נדרש עומק בתוך המערכת | דורש פריסה ועדכון בכל צומת, אינו עובד על התקנים סגורים |
| איסוף דרך זרמי רשת | ציוד רשת, מקטעים זרים, התקנים ללא אפשרות להתקין תוכנה | אין ראות בתוך המארח, תלוי באיכות שיקוף התעבורה |
| איסוף היברידי | תשתית מעורבת: שרתים שלנו בתוספת מקטעים חיצוניים | נרמול אירועים מורכב יותר ותמיכה בסכמת שדות אחידה |
בפועל בוחרים סכמה עבור כל מקטע בנפרד, ולא עבור כל התשתית כולה. מתחילים במיפוי מקורות האירועים: מה כבר מעביר יומנים, מה זמין רק דרך הרשת, והיכן אין טלמטריה כלל.
לאחר מכן קובעים אילו מקורות קריטיים לזיהוי, ומתאימים להם את שיטת האיסוף — כך ארכיטקטורת הפריסה צומחת מנתונים אמיתיים, ולא מתבנית.
שלבי יישום: מביקורת ועד מסירה לתפעול
את היישום אנו מתחילים בסקר: אוספים רשימה של מקורות אירועים — שרתים, התקני רשת, יישומים, שירותי ענן — ומתעדים אילו יומנים כבר נכתבים ובאיזה פורמט, והיכן הם הולכים לאיבוד בעת אתחול מחדש. התוצר — מפת כיסוי: אילו צמתים נראים, אילו לא, ומה יניב את הגידול הגדול ביותר בגילוי ראשוני.
- ביקורת תשתית. ספירת מלאי של צמתים ומקורות, הערכת עומס על איסוף האירועים, בדיקה שיומנים קריטיים אינם מושבתים ונשמרים מספיק זמן לניתוח אירועים.
- תכנון הסכמה. מגדירים טופולוגיה: היכן ממוקמים האוספים, כיצד האירועים מגיעים לצומת האנליטי, כיצד מפרידים זרמים לפי קריטיות. מתכננים מראש עמידות לתקלות — אובדן צומת לא אמור להותיר אותנו ללא נראות.
- הגדרת כללים. כותבים ומתאימים כללי קורלציה לתרחישים אמיתיים: התחברות חשודה, הסלמת הרשאות, שינוי בקונפיגורציות קריטיות. כל כלל נבדק לזיהויים שגויים — רעש בהתראות מפחית מערכה של המערכת מהר יותר מהחמצה.
- בדיקת תרחישים. מריצים סימולציות מבוקרות של תקיפות וחריגות, בודקים אם הכלל הופעל, אם ההתראה הגיעה לתורן, ואם יש מספיק הקשר לקבלת החלטה. מכווננים ספים באופן איטרטיבי.
- מסירה לתפעול. מנסחים נהלי תגובה, מכשירים את המשמרת התורנית, מגדירים ניתוב התראות. מוסרים תיעוד ונשארים בקשר בתקופת הליווי.
רצף כזה נותן תוצאה צפויה: עד מועד ההפעלה הצוות מבין מה המערכת רואה, כיצד יש להגיב לכך ולאן להסתכל בעת ניתוח. נדון במשימה שלכם — נחזור עם הערכה ותוכנית לפי שלבים.
כללי מתאם ותעדוף אותות
כללי המתאם ב-Wazuh הם השכבה שהופכת זרם של אירועים גולמיים למערכת מוגבלת של אינצידנטים. מנוע הבסיס מפרסר לוגים באמצעות מפענחים, מתאים אותם לחתימות ומקצה רמת חומרה; תפקיד המהנדס הוא להגדיר את הכללים כך שההפעלות ישקפו איום אמיתי, ולא פעילות של סורקים ומשימות שגרה. ללא עבודה זו, תור ההתראות גדל מהר יותר מקצב הטיפול של האנליסט.
סינון רעש לפני תעדוף
בשלב הראשון מסירים התראות שווא במקור: מחריגים תת-רשתות מהימנות, חשבונות שירות, משימות מתוכננות וסורקי פגיעויות ידועים. לאחר מכן מקבצים אירועים קשורים לכלל אחד — לדוגמה, סדרת כניסות כושלות ואחריהן התחברות מוצלחת מאותה כתובת מייצרת אינצידנט אחד במקום עשרות שורות. כך התור מצטמצם פי כמה, ואירועים משמעותיים אינם שוקעים ברקע.
רמות וניתוב אותות
התעדוף נבנה על רמות חומרה וספים: רמות נמוכות עוברות לארכיון לצורכי רטרוספקטיבה, בינוניות — לתור לטיפול, גבוהות — להתראה מיידית לתורן. את הספים בוחרים לפי תדירות ההפעלות על תעבורה אמיתית, ולא "לפי העין": כלל שמופעל מאות פעמים ביממה חסר תועלת ללא תלות ברמה. עבור כל תרחיש מקבעים תנאי הסלמה ואחראי.
בדיקת כללים על זרם חי
את הכללים המוגדרים מריצים על לוגים היסטוריים ותרחישים מבוקרים — מדמים כניסה חשודה, שינוי הרשאות, גישה למשאב רגיש. בודקים אם הכלל הופעל, באיזו רמה, והאם לא יצר כפילויות. תוצאת ההגדרה — תור צפוי, שבו לכל אירוע יש סיבת הפעלה ברורה ובעלים.
מה הלקוח מקבל לידיו לאחר ההטמעה
ההטמעה אינה מסתיימת בשרת פועל, אלא בחבילה שלפיה ניתן להפעיל את המערכת, להעביר אותה לצוות אחר ולעבור בדיקה. כל מה שאנו מגדירים מתועד בארטיפקטים: קונפיגורציות, תרשימים, מדיניות גישה, נהלי תגובה ותיעוד.
- קונפיגורציות — קבצי חוקים ומפענחים, הגדרות איסוף לוגים משרתים, ציוד רשת ויישומים, פרמטרי אחסון וסבב אירועים. הכול במערכת בקרת גרסאות, כך ששינוי חוקים עובר סקירה ולא נעשה ידנית בפרודקשן.
- תרשימי תשתית — זרימת נתונים מהמקור ועד מאגר האירועים: היכן מותקנים הסוכנים, מה נאסף ישירות, כיצד בנויים הפלחים ונקודות הכשל. התרשים מסיר מחצית מהשאלות בעת חיבור צומת חדש.
- מדיניות גישה — תפקידים והרשאות לאנליסטים, למשמרת התורנית ולקבלנים, חלוקת תחומי אחריות, סדר הענקה ושלילת גישות. בנפרד אנו מתעדים מי ועל איזה בסיס רואה אירועים רגישים.
- נהלי תגובה — לכל סוג של הפעלה: מה נחשב לאירוע, למי נשלחת התראה, תוך כמה זמן, מי מקבל החלטה וכיצד נסגר הרשומה. החוקים מתואמים עם השירות שלכם, ולא נכתבו "למראית עין".
- תיעוד — הוראות הפעלה, סדר עדכון חוקים, צ'ק-ליסט לחיבור מקור חדש, תיאור תקלות אופייניות ופעולות התורן.
- דוח קבלה — אילו תרחישי תקיפה נבדקו, כיצד המערכת הגיבה להם, אילו חוקים מייצרים התראות שווא ומה נעשה בנוגע לכך.
החבילה נשארת אצלכם: הצוות יכול לפתח את המערכת בעצמו או להעביר אותה לקבלן אחר בלי לשחזר את הלוגיקה מהזיכרון. תארו את המשימה — נחזור עם הערכה ותוכנית.
במה שונה ההגדרה של Wazuh מהטמעת SIEM טיפוסית
Wazuh — זוהי פלטפורמה בקוד פתוח לזיהוי איומים, ניטור שלמות קבצים ובקרת אבטחה, הבנויה סביב סוכנים על נקודות הקצה.
בשונה מ-SIEM קלאסיים, אשר בראש ובראשונה אוספים ומתאמים אירועים מהתקני רשת ויישומים, Wazuh מלכתחילה מציב סוכן על המארח עצמו — שרת, תחנת עבודה, קונטיינר — ומשם אוסף טלמטריה: שינויים בקבצים, תהליכים חשודים, ניסיונות להעלאת הרשאות, מצב קונפיגורציות.
זה משנה את ההיגיון של ההטמעה: אינכם רק מגדירים קליטת לוגים, אלא פורסים רשת סוכנים מנוהלת עם מדיניות מרוכזת.
SIEM קלאסי חזק בתיאום אירועים ממקורות מגוונים ובבניית אנליטיקה על זרימת נתונים גדולה, אך דורש סוכן נפרד לכל סוג מקור ולעיתים קרובות משאיר את רמת המארח מחוץ לתמונה.
Wazuh מכסה בדיוק את השכבה הזו: מודולים מובנים לבדיקת שלמות, סריקת פגיעויות וזיהוי חדירות פועלים באופן מובנה, ללא רכישת רישיונות נוספים לכל צומת. לכן הבחירה בין הגישות היא שאלה של מה קריטי יותר עבורכם: עומק הנראות בנקודות הקצה או רוחב הכיסוי של תשתית הרשת.
הייחוד של הגדרת Wazuh מתבטא במספר דברים. חוקי הזיהוי מתוארים באופן הצהרתי ומורשים בין קבוצות סוכנים, לכן מדיניות אחת מיושמת על מאה שרתים ללא עריכה ידנית בכל אחד. ערכי סף וחריגים מוגדרים ברמת החוקים, ולא נמרחים על פני הקונפיגורציה של כל צומת.
לבסוף, Wazuh משתלב היטב עם SIEM קלאסי: הסוכנים אוספים אירועי מארח, והפלטפורמה מעבירה אותם הלאה למעגל התיאום הכללי — כך אתם מקבלים גם עומק וגם רוחב.
זה חשוב כאשר התשתית מפוזרת, חלק מהצמתים נמצאים מחוץ להיקף, וצוות האבטחה מוגבל. אז מודל הסוכנים עם מדיניות מרוכזת מספק כיסוי צפוי ללא ניפוח הצוות.
אם לעומת זאת המשימה העיקרית היא תיאום אירועי רשת ועמידה בדרישות הרגולטור לתיעוד ביומן, SIEM קלאסי נשאר הבסיס, ו-Wazuh משלים אותו בשכבת המארח.
מקרה בוחן: קיצור זמן הגילוי ברשת מבוזרת
מה היה לפני
רשת מבוזרת: מספר אתרים, עשרות שירותים, חלק מהתעבורה עוברת בין סגמנטים. הלוגים נאספו לפי שרתים — כל אחד לקובץ משלו, עם פורמט זמן משלו. חקירת תקרית החלה בשאלה "איפה בכלל מסתכלים".
חשד לפגיעה בחשבון נבדק בהשוואה ידנית של כניסות משלושה מקורות: חצי יום עבודה של מהנדס, וגם זה רק אם הוא ידע מה לחפש.
זמן ממוצע מהאירוע ועד להשערה מאומתת עמד על 6-8 שעות. חלק מהתקיפות — ניסיונות כוח גס על חשבונות שירות, תנועה אופקית בין צמתים — לא זוהו כלל: אירועים בודדים לא נראו חשודים, ואת הקורלציה ביניהם אף אחד לא חישב.
מה שינו
פרסו Wazuh כשכבת איסוף וקורלציה אחודה: סוכנים על הצמתים, אינדקס מרכזי, נרמול זמן ושדות ממקורות הטרוגניים. לאחר מכן — חוקי גילוי המותאמים לטופולוגיה שלנו, ולא סט טיפוסי מהקופסה.
- קורלציה בין מספר אירועים: סדרת כניסות כושלות, ולאחריהן כניסה מוצלחת — מופעלת כתקרית אחת, ולא כעשר רשומות בלוג.
- חוקים נפרדים לתנועה אופקית: חיבורים חריגים בין סגמנטים שבדרך כלל לא מתקשרים ישירות.
- בקרת שלמות קבצים על צמתים קריטיים — שינוי תצורה או החלפת בינארי נותן אות מיד.
- תיעדוף לפי קריטיות הצומת: התראה מהפרימטר והתראה מסביבת בדיקה לא מתערבבות לאותה תור.
מה נהיה
זמן הגילוי הצטמצם מ-6-8 שעות ל-15-40 דקות — בעיקר בזכות העובדה שהקורלציה מתבצעת בצד המערכת, ולא בראשו של התורן. סוגי תקיפות שבעבר עברו unnoticed, כעת נותנים התראה: ניסיונות כוח גס על פרטי גישה, תנועה בין צמתים, שינויים בקבצים קריטיים.
התראות שווא — עבודה נפרדת. בשבועות הראשונים היה צריך לכוונן את החוקים: חלק מהאותות היו רעש מסקריפטים לגיטימיים. לאחר הכיוונון שיעור ההתראות השווא ירד בערך פי שלושה, והתורן הפסיק להתעלם מהתור.
ספקות טכניים נפוצים בעת הגדרת Wazuh
הספקות בדרך כלל זהים: האם הסוכן ישתלב בשרתים הקיימים, האם הוא יאכל את משאבי הפרודקשן, האם הצוות ייטבע בהתראות ומה יקרה עם העדכונים. להלן — כיצד שאלות אלו נסגרות בפועל, בלי הבטחות «נתקין וזה יעבוד».
האם זה תואם לתשתית שלנו — חלק מהצמתים על הפצות ישנות?
הסוכן מותקן על ענפי Linux, Windows ו-macOS עדכניים, ועבור צמתים שבהם ההתקנה אינה רצויה פועל איסוף ללא סוכן דרך יומנים וזרמי רשת. הפצות ישנות מחברים דרך העברת syslog: האירועים מגיעים, אם כי חלק מהטלמטריה ברמת הליבה לא תהיה זמינה. בשלב ניתוח המלאי אנו מסמנים צמתים כאלה בנפרד, כדי שתבינו אילו בדיקות לא יפעלו עליהם.
מה יהיה העומס על השרתים והרשת?
הסוכן מחזיק חוצץ על הדיסק ושולח אירועים במנות, לכן שיאים לא מכים במעבד. בצומת טיפוסי הצריכה היא אחוזים בודדים, אך נתון מדויק נותן רק מדידה על פרופיל העומס שלכם: אנו לוקחים מדדים לפני ואחרי על קבוצת פיילוט. את הרשת אנו מגבילים בדחיסה ובלוח זמנים לשליחה, ובערוצים חלשים מציבים צומת-מאגד ביניים.
האם לא נטבע בהתראות שווא?
מערך החוקים הבסיסי רועש — זה נורמלי להתחלה. השבועות הראשונים מוקדשים לכוונון: מכבים חוקים לא רלוונטיים, מוסיפים רשימות החרגה לפי השירותים שלכם, מורידים עדיפות של פעולות ניהוליות ידועות. המטרה — לא «אפס התראות», אלא זרימה צפויה שבה כל אירוע דורש פעולה. את סף הרגישות אנו מתאימים לפי הסביבה שלכם, ולא לפי ברירת מחדל.
מה עם עדכונים וחזרה לאחור?
החוקים והתצורה נשמרים במערכת בקרת גרסאות, לכן כל שינוי ניתן לחזרה לאחור. עדכונים אנו מתקינים תחילה על קווי בדיקה, בודקים על העתקת תעבורה, ואז פורסים לפרודקשן. גרסאות הסוכנים והשרת נשמרות תואמות, ולפני עדכון גדול אנו לוקחים תמונת מצב — החזרה אורכת דקות, ולא שעות של ניתוח.
אם משהו מזה מעורר שאלות בסביבה שלכם — תארו את המשימה, נחזור עם הערכה ותוכנית.
בואו נדון במשימה שלכם לזיהוי איומים
כדי לחזור עם הערכה ותוכנית, ולא עם מילים כלליות, אנחנו צריכים מינימום של נתוני פתיחה על התשתית שלכם. אנחנו אוספים אותם בשיחה אחת: אילו מקורות אירועים כבר קיימים, היכן הם נשמרים, מי אחראי על ההרשאות. לפי הנתונים האלה אנחנו בונים תוכנית עבודה וקובעים לוחות זמנים — בלי ביקורת מקדימה "בעין".
מה שעוזר לנו להעריך במהירות את ההיקף ולא להמציא דברים מיותרים:
- רשימת מקורות אירועים: שרתים ותחנות עבודה, ציוד רשת, שירותי ענן, יישומים — מה מהם כבר מפיק יומנים, ומה עדיין לא.
- מצב נוכחי: האם יש איסוף יומנים, לאן הם נכתבים, כמה זמן נשמרים, מי ואיך בוחן אותם היום.
- תרשים רשת וסגמנטציה: היכן עוברים הגבולות, אילו צמתים קריטיים, האם יש מתחמים מבודדים.
- דרישות לזיהוי: אילו סוגי איומים בעדיפות — כניסה עם חשבונות חשודים, שינויי הרשאות, אנומליות בשרתים, דליפות נתונים.
- מגבלות על הרשאות ותקנות: מה ניתן להתקין על הצמתים, אילו מדיניויות אבטחה חלות, מי מאשר שינויים.
- אחראים מצדכם: מי יקבל את המערכת, מי יטפל בהתראות לאחר ההפעלה.
הגישה לפרויקט פשוטה: תחילה סוגרים את הנראות — מחברים מקורות ומגדירים איסוף, לאחר מכן כללי זיהוי לתרחישים שלכם, ואז בודקים שההתראות מגיעות ומטופלות. Wazuh התקנה כאן נעשית לא "לפי המדריך", אלא לפי מפת האיומים שלכם: מערך הכללים והעדיפויות תלוי במה שבאמת קריטי עבורכם.
תארו את המשימה בצורה חופשית — אילו מערכות צריך לכסות ומה מטריד כרגע. נחזור עם הערכת לוחות זמנים, הרכב העבודות ותוכנית לפי שלבים.