התקנת OSSEC ו-Wazuh HIDS לזיהוי חדירות ברמת המארח
בפרויקט מסוים, תוקף השיג גישה למארח באמצעות הזרקת SQL ביישום אינטרנט ושינה את /usr/bin/ssh. מערכות אבטחת הרשת נותרו דוממות מכיוון שהתעבורה הייתה לגיטימית. רק HIDS בזמן אמת זיהה את השינוי ב-hash והתריע למהנדס באופן מיידי. מערכת זיהוי חדירות מבוססת מארח היא קו ההגנה האחרון שיכול להבחין בחריגות ברמת מערכת ההפעלה ש-NIDS אינו יכול לראות. הצוות שלנו מתקין OSSEC ואת הפיצול שלו Wazuh עבור לקוחות בפינטק וקמעונאות. במשך יותר מ-5 שנים, פרסנו HIDS על יותר מ-5000 מארחים—אנחנו מכירים את המלכודות האופייניות וכיצד לעקוף אותן במהירות. Wazuh הוא חינמי, וחוסך בתקציב על רישיונות בהשוואה לחלופות מסחריות כמו CrowdStrike.
למה HIDS ולא רק NIDS?
NIDS תופס חריגות בתעבורה אך חסר אונים כאשר תוקף כבר חדר פנימה. לדוגמה, rootkit מהיר (החלפת ls) אינו מייצר מנות רשת, אך HIDS יזהה את אי-ההתאמה ב-hash. ניטור שלמות קבצים (FIM) הוא אחד המאפיינים המרכזיים: baseline + בדיקות כל שעתיים (ניתן להגדרה באמצעות frequency). עבור ספריות קריטיות (/etc, /usr/bin, /var/www), אנו מפעילים realtime="yes"—inotify מייצר אירוע מיידי בעת שינוי. ההתראה כוללת diff של הקובץ ששונה, ומראה בדיוק מה השתנה. עם הגדרת FIM נכונה, אנו מפחיתים תוצאות חיוביות שגויות ל-1-2% על ידי החרגת קבצים זמניים וספריות עם שינויים תכופים. אנו משתמשים ברשימות לבנות וביטויים רגולריים לסינון.
איך פועל זיהוי Rootkit?
OSSEC בודק תהליכים נסתרים: הבדלים בין פלט /bin/ps לקריאת /proc, קבצים נסתרים ב-/dev, מודולי קרנל חשודים. מסד הנתונים של rootkits ידועים הוא rootkit_files.txt, בנוסף לבדיקות שלמות מול רשימות טרויאנים. תצורת rootcheck ברירת המחדל (מספקת):
<rootcheck>
<frequency>36000</frequency>
<rootkit_files>/var/ossec/etc/shared/rootkit_files.txt</rootkit_files>
<rootkit_trojans>/var/ossec/etc/shared/rootkit_trojans.txt</rootkit_trojans>
</rootcheck>לצורך עמידה ברגולציה (PCI DSS, SOX), אנו מוסיפים בדיקות CIS באמצעות <rootcheck> <frequency>36000</frequency> <rootkit_files>/var/ossec/etc/shared/rootkit_files.txt</rootkit_files> <rootkit_trojans>/var/ossec/etc/shared/rootkit_trojans.txt</rootkit_trojans> </rootcheck> . בפרויקט אחד, rootcheck זיהה rootkit שהתחזה לדרייבר כרטיס קול—זה מנע דליפת נתונים של לקוח.
איך להגדיר Rootcheck ליעילות מרבית?
כדי להשיג תוצאות מיטביות, אנו בוחרים ספריות לבדיקת שלמות (כל בינאריות המערכת, ספריות, קובצי תצורה), מגדירים תדירות: זמן אמת לקבצים קריטיים, 2-4 שעות לאחרים. לאחר מכן אנו משתלבים עם SIEM: כל ההתראות נשלחות ל-Elasticsearch או Splunk לניתוח מרכזי. אנו מעדכנים באופן קבוע מסדי נתונים של rootkits וכללי זיהוי באמצעות עדכונים אוטומטיים מ-Wazuh. אנו מבצעים בדיקות חדירה כדי לוודא זיהוי. המהנדסים שלנו יעזרו לכם להגדיר rootcheck תוך התחשבות במאפייני התשתית שלכם.
איך להגדיר תגובה פעילה לאירועים?
זיהוי הוא דבר אחד, תגובה אוטומטית היא דבר אחר. תגובה פעילה מקשרת כלל לפעולה: חסימת IP באמצעות system_audit_cis_rcl.txt, סיום תהליך, הרצת סקריפט. דוגמה: brute force ל-SSH—כלל 5720 (8 כשלונות סיסמה) → הוספת IP ל-host-deny לשעה אחת. חסימת IP מונעת נזק מהתקפה שעלולה לעלות מיליונים.
<active-response>
<command>host-deny</command>
<location>local</location>
<rules_id>5720</rules_id>
<timeout>3600</timeout>
</active-response>הסוכן מבצע את הפקודה מקומית—אין צורך לחכות לשרת. משך החסימה ניתן להגדרה, וניתן להחליפו בכלל firewall (iptables). עבור תשתיות גדולות, אנו משתמשים בחסימה אוטומטית ב-firewall באמצעות API.
למה לבחור ב-Wazuh על פני OSSEC המקורי?
| מאפיין | OSSEC (מקורי) | Wazuh | Atomic OSSEC |
|---|---|---|---|
| פעילות פיתוח | הופסקה | גבוהה (שחרורים שבועיים) | בינונית (מסחרי) |
| ממשק Web | לא | Kibana מובנה | כן |
| אינטגרציית SIEM | דרך syslog | Elasticsearch + Kafka | טבעית |
| עדכוני כללים | רבעוני | שבועי | חודשי |
| רישיון | GPLv2 | GPLv2 | קנייני |
עבור פרויקטים חדשים, אנו בוחרים ב-Wazuh—הוא מעבד אירועים פי 3 מהר יותר מהמקורי ומספק לוח מחוונים מוכן לניטור. Wazuh תומך גם בקונטיינרים ו-Kubernetes, מה שחיוני לפרקטיקות DevOps מודרניות. Wazuh הוא חינמי, וחוסך בתקציב על רישיונות בהשוואה ל-HIDS מסחריים שעלותם יכולה להגיע למאות—חיסכון של כ-$9–13 בשנה.
אילו טעויות אופייניות נעשות בהגדרת HIDS?
- סריקת כל הספריות בתדירות גבוהה מדי יוצרת עומס והרבה תוצאות חיוביות שגויות. הגדירו זמן אמת רק עבור
/etc/hosts.deny,<active-response> <command>host-deny</command> <location>local</location> <rules_id>5720</rules_id> <timeout>3600</timeout> </active-response>ושורש ה-web. - התעלמות מרשימות לבנות: יש להחריג קבצי לוג זמניים וקבצי cache.
- חוסר בדיקה של תגובה פעילה: חסימת ה-IP שלכם יכולה לשתק פעולות.
- אי עדכון מסדי נתונים של rootkits—איום חדשים לא מזוהים.
מה כלול בהתקנת HIDS סוהר?
- ביקורת תשתית קיימת: אילו מארחים, מערכות הפעלה, עומס.
- בחירת פיצול וארכיטקטורה (שרת/סוכנים/איסוף מרכזי).
- התקנה והגדרה: FIM, rootcheck, ניתוח לוגים, תגובה פעילה.
- אינטגרציה עם ה-SIEM שלכם (ELK, Splunk, CloudWatch).
- תיעוד כללים ונהלי תגובה.
- הדרכת צוות (שעתיים) ואחריות להגדרה נכונה (בדיקת 7 ימים).
אנחנו מוסמכים על Wazuh ו-OSSEC—מהנדסים עם ניסיון של 5+ שנים. אנו תומכים גם בקלאסטרים קטנים (10 מארחים) וגם בגדולים (2000+).
| היקף | לוח זמנים |
|---|---|
| התקנה על 10–20 שרתים, מערכת כללים בסיסית | 2–3 ימים |
| הגדרת FIM + rootkit + תגובה פעילה | 3–5 ימים |
| OSSEC מרכזי + כללים מותאמים אישית | 1–2 שבועות |
צרו קשר לביקורת תשתית—אנו נבחר את ה-HIDS האופטימלי ונגדיר אותו בהתאם לדרישות הרגולציה שלכם. הזמינו התקנת OSSEC סוהר: אנו מבטיחים שהמערכת תתפוס אירועים, לא תייצר מבול של תוצאות חיוביות שגויות. קבלו ייעוץ ממהנדס עוד היום.







