הגדרת OSSEC ו-Wazuh HIDS לזיהוי חדירות במארח

כאשר תוקף כבר השיג גישה לשרת, חומות אש ברשת נותרות לעיתים קרובות דוממות—ההתקפה מתרחשת ברמת מערכת ההפעלה. אנו מגדירים OSSEC ו-Wazuh HIDS לזיהוי חדירות למארח, כולל ניטור שלמות קבצים וזיהוי rootkit. הצוות שלנו מספק את הפרויקט במפתח מלא, מבדיקת היתכנות ועד הטמעה ותמיכה שוטפת, תוך הבטחת הגנה אמינה שגדלה עם העסק שלך.

היכולות שלנו:

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1359
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1330
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    776
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1077
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1022
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1113

התקנת 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 סוהר: אנו מבטיחים שהמערכת תתפוס אירועים, לא תייצר מבול של תוצאות חיוביות שגויות. קבלו ייעוץ ממהנדס עוד היום.