פתרון בעיות נפוצות

נתמך ב:

במאמר הזה ריכזנו טיפים ושיטות שיעזרו לכם לאבחן ולפתור בעיות נפוצות שנתקלים בהן במהלך הפריסה וההפעלה של הסוכן המרוחק של Google Security Operations.

בעיה של אי-התאמה במפתחות

הבעיה הזו מתרחשת כשהמפתחות הפרטיים ב-Google Security Operations וב-Remote Agent לא תואמים. כדי לפתור את הבעיה, צריך לוודא שהמפתח במשאבי הנציג תואם למפתח ב-Siemplify agent_db.

כשל במחבר המרוחק

אם מחבר מרחוק נכשל, פועלים לפי השלבים הבאים:

  1. מוודאים שמופע השילובים הותקן בהצלחה בנציג.
  2. בודקים את יומני הפעילות של סוכן ברמת השגיאה כדי למצוא כשלים בתהליך החיבור.
  3. בודקים את אותה הגדרת מחבר באופן מקומי ורואים אם יש שגיאות.

ההתקנה נכשלה: מערכת ההפעלה המארחת לא נתמכת או שיש חוסר תאימות בגלל סוף תקופת התמיכה (EOL)

אם התקנות חדשות או שדרוגים אוטומטיים נכשלים בגלל שגיאות מעקב של glibc וחסימות של קריאות מערכת, צריך לפעול לפי השלבים הבאים:

  1. מוודאים שבסביבת המארח לא פועלת מערכת הפעלה מדור קודם, שייתכן שאין בה הוקים מודרניים של קריאות מערכת.
  2. לארח מחדש את סביבת הסוכן בהפצת Linux ארגונית עם הגרסה הרשמית האחרונה.
  3. בפריסות של תוכנת התקנה ידנית, צריך לוודא שהמארח מריץ מערכת הפעלה נתמכת, כמו Debian 12 או Red Hat Enterprise Linux (RHEL) 8.7:

    בודקים את /etc/os-release: מריצים את הפקודה הבאה ומחפשים את NAME= ו-VERSION_ID=:

    cat /etc/os-release
    • ב-Debian 12: מחפשים את NAME="Debian GNU/Linux" ו-VERSION_ID="12".
    • ב-RHEL 8.7: מחפשים את NAME="Red Hat Enterprise Linux" ו-VERSION_ID="8.7".

    אם המארח מריץ את RHEL 9 או 10 (או גרסה מאוחרת יותר), צריך לפרוס את הסוכן המרוחק באמצעות מנוע קונטיינר נתמך (Podman או Docker) במקום באמצעות תוכנת ההתקנה הידנית. קובצי אימג' של קונטיינרים שנוצרו מראש לגרסאות של Remote Agent אחרי 2.5.0.4 מבוססים על Debian 12, שגם פותר בעיות של חוסר תאימות בינארית של Python wheel (.whl) (כמו ModuleNotFoundError ל-TIPCommon או SiemplifyAddressProvider) בסוכני CentOS 7. מידע נוסף זמין במאמר מערכות הפעלה נתמכות.

הגדרת הקונטיינר שולפת את השכבה התפעולית הקודמת במקום את ה-build האחרון

אם הרצה מחדש של פקודות להגדרת קונטיינר מושכת בטעות שכבה תפעולית קודמת במקום את ה-build של התוכנה החדשה, מריצים את הפקודות הבאות כדי למשוך באופן מפורש את קובץ האימג' האחרון:

  • ב-Docker:

    docker pull us-docker.pkg.dev/siem-ar-public/images/agent:latest

  • ל-Podman:

    podman pull us-docker.pkg.dev/siem-ar-public/images/agent:latest

כדי לוודא שהפריסה פועלת בגרסת התוכנה העדכנית ביותר, תמיד צריך לשלוף את קובץ האימג' האחרון לפני שמריצים את קונטיינר הסוכן. אם משיכה מ-docker.io מבקשת פרטי כניסה בגלל הגבלת קצב של יצירת בקשות, צריך למשוך את קובץ האימג' מנקודת הקצה הציבורית של Artifact Registry‏ (us-docker.pkg.dev/siem-ar-public/images/agent:latest). לדומיינים הנדרשים ברשימת ההיתרים של חומת האש, ראו דרישות הרשת וחומת האש.

כשל בפריסת סוכן Docker

אם הפריסה של Docker נכשלת, פועלים לפי השלבים הבאים:

  1. מסירים את מאגר Docker:

    1. מריצים את הפקודה הבאה כדי להציג את הקונטיינרים שפועלים:

      docker ps 

    2. מריצים את הפקודה הבאה כדי להסיר את הקונטיינרים שנכשלו:

      docker rm -f container_id_or_name
  2. הסרת תמונות:

    1. מריצים את הפקודה הבאה כדי להציג את רשימת התמונות:

      docker images 

    2. מריצים את הפקודה הבאה כדי להסיר את התמונה:

      docker rmi image_id_or_name
  3. הסרת כרכים:

    1. מריצים את הפקודה הבאה כדי להציג את רשימת אמצעי האחסון:

      docker volume ls

    2. מריצים את הפקודה הבאה כדי להסיר את אמצעי האחסון:

      docker volume rm volume_name
  4. פורסים מחדש את הנציג. מידע נוסף זמין במאמר יצירת סוכן באמצעות Docker.

הסוכן תקוע בסטטוס "בהמתנה לסוכן"

אם הנציג נפרס בהצלחה אבל הסטטוס נשאר "בהמתנה לנציג", בצעו את השלבים הבאים כדי לפתור בעיות:

  1. בדיקת הקישוריות של המארח: בודקים את הקישוריות לאינטרנט של המכונה המארחת של הסוכן (לדוגמה, curl www.google.com או ping 8.8.8.8). אם הבדיקה נכשלת, הבעיה היא בחיבור לאינטרנט של המארח.

  2. בדיקת הקישוריות של הקונטיינר: אם בדיקת המארח עוברת, נכנסים למעטפת של הקונטיינר באמצעות docker exec -it container_ID bash ובודקים שוב את הקישוריות. אם אין קישוריות בקונטיינר, מפעילים מחדש את שירות Docker במכונה המארחת (service docker restart).

    1. מריצים את הפקודה הבאה:

      docker exec -it bash

    2. בודקים שוב את הקישוריות כמו קודם.
    3. אם אין קישוריות, מריצים את הפקודה הבאה כדי להפעיל מחדש את שירות Docker מהמכונה המארחת (לא מהמאגר):

      service docker restart

    4. מריצים את הפקודה הבאה כדי להפעיל מחדש את הקונטיינר:

      docker start

  3. בדיקת שגיאות ביומני הקונטיינרים

    אם השלב הקודם לא עזר, וסטטוס הסוכן עדיין "ממתין לסוכן" אחרי רענון הדף Remote agent ב-Google SecOps, מתחברים שוב לקונטיינר ומורידים את היומנים.

    1. מאתרים את היומנים בספרייה /var/log/SiemplifyAgent/.
    2. כדי לזהות את שורש הבעיה, חפשו שגיאות בקובצי היומן.

  4. מוודאים שחומת האש מאפשרת תנועת HTTPS יוצאת ביציאת TCP ‏443 אל נקודות הקצה של Publisher, של ה-API של Chronicle לפי מיקום ושל Google Cloud האימות. צריך גם לוודא ששרתי proxy בשכבת האפליקציה או חומות אש של Deep Packet Inspection‏ (DPI) עוקפים את בדיקת ה-SSL/TLS של המארח של Remote Agent. רשימת הדומיינים הנדרשים מופיעה במאמר דרישות הרשת וחומת האש.

בעיות ברשת ה-DNS

אם יש שגיאות בפענוח ה-DNS או בעיות בחיבור לרשת בקונטיינר, מוסיפים את --network host לפקודה docker run. שימוש במצב רשת מארחת מאפשר לקונטיינר לשתף ישירות את מקבץ הרשת (network stack) ואת הגדרת ה-DNS של המכונה המארחת.

קובץ האימג' של Docker לא נטען (העברת IP4 מושבתת)

אם מופיעה שגיאה ב-CLI כשמנסים לטעון קובץ אימג' של Docker (מערכת) או סוכן של Google SecOps, יכול להיות שהעברת IP4 מושבתת. כדי להפעיל את ה-API ולהפעיל מחדש את הנציג:

  1. מוסיפים את השורה הבאה לקובץ /etc/sysctl.conf:

    net.ipv4.ip_forward=1 שימו לב שצריך להשתמש בכלי לעריכת קבצים (כמו nano, למשל: yum install nano -y

  2. מריצים את הפקודה הבאה כדי להפעיל מחדש את שירות הרשת:

    systemctl restart network

  3. מריצים את הפקודה הבאה כדי להפעיל מחדש את שירות Docker:

    sudo systemctl restart docker

  4. מריצים את הפקודה הבאה כדי לבדוק אם הקונטיינר פועל:

    docker ps

  5. אם הקונטיינר לא פועל, מריצים את הפקודה הבאה כדי להציג את כל הקונטיינרים (כולל אלה שהופסקו):

    docker ps -a

  6. אם הקונטיינר מופיע ברשימה אבל הוא נעצר, מריצים את הפקודה הבאה כדי להפעיל אותו:

    docker start container_id_or_name
  7. אם הסוכן או המערכת עדיין לא פועלים אחרי הפעלה מחדש של Docker ושל הקונטיינר:

    1. מריצים את הפקודה הבאה כדי לעצור את הקונטיינר:

      docker stop container_id_or_name

    2. מריצים את הפקודה הבאה כדי למחוק את הקונטיינר:

      docker rm container_id_or_name

    3. מריצים את הפקודה הבאה כדי למחוק את התמונה:

      docker rmi image_name
    4. טוענים את התמונה שוב.

שגיאה אחרי כיבוי או הפעלה מחדש של Agent

מריצים את הפקודה הבאה כדי לאלץ את ההפעלה של סוכן ההתקנה:
systemctl start supervisord

מריצים את הפקודה הבאה כדי לאלץ את ההפעלה של סוכן Docker:
docker start

משימות של סוכן מרוחק נכשלות בסביבות מוקשחות

כשפורסים סוכן מרוחק במארח Linux מוקשח כמו RHEL 8, יכול להיות שמשימות הסוכן (כולל שמירה או שדרוג של שילוב, או הפעלת מחברים ופעולות) ייכשלו או יסתיימו עקב זמן קצוב לתפוגה בממשק המשתמש, בזמן שסטטוס הסוכן יישאר פעיל. הבעיה הזו מתרחשת כשאכיפת האבטחה של מערכת ההפעלה המארחת – כמו SELinux במצב Enforcing,‏ AppArmor או תוכנת אבטחה של נקודות קצה – חוסמת פקודות של מערכת ההפעלה שמבוצעות על ידי הנציג בתוך הקונטיינר.

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

  1. בודקים אם SELinux נמצא במצב Enforcing במכונה המארחת:

    getenforce
sestatus

    כדי לבדוק אם יש ב-/var/log/audit/audit.log פקודות שנחסמו לאחרונה או פעולות שנדחו, בלי להחזיר את כל קובץ היומן, מריצים את הפקודה הבאה:

    sudo grep -i "denied" /var/log/audit/audit.log | tail -n 50

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

  2. החרגת הסוכן המרוחק ממדיניות האבטחה החוסמת במארח:

    • בפריסות בקונטיינרים (Docker או Podman), צריך להחריג את כל הקונטיינר של הסוכן המרוחק כשמפעילים אותו בפעם הראשונה. כדי לעשות את זה, מוסיפים את --security-opt label=disable (ל-SELinux) או את --security-opt apparmor=unconfined (ל-AppArmor) לפקודה docker run או podman run.
    • מגדירים כללי מדיניות מותאמים אישית של SELinux, פרופילים של AppArmor או פטורים מאבטחה של נקודות קצה (endpoint) מארחות לספריות של הסוכן המרוחק (/opt/SiemplifyAgent,‏ /home/siemplify_agent/agent_source ו-/var/log/SiemplifyAgent) ולקובצי ההפעלה (/usr/local/bin/python3.11,‏ /usr/local/bin/pip3 ו-/usr/bin/supervisord) כדי שפקודות של מערכת ההפעלה לא ייחסמו.

  3. לחלופין, אם אתם לא יכולים להגדיר פטור ממוקד מ-SELinux, הגדירו את SELinux למצב Permissive באופן קבוע בכל ההפעלות מחדש על ידי הגדרת SELINUX=permissive ב-/etc/selinux/config במארח.

    אם אי אפשר לשנות את /etc/selinux/config או שצריך להחיל את השינוי באופן מיידי בלי להפעיל מחדש, מריצים את הפקודה הבאה כדי להעביר את SELinux למצב Permissive באופן זמני:

    sudo setenforce 0

הבעיה עדיין לא נפתרה? קבלת תשובות מחברי הקהילה וממומחי Google SecOps.