פתרון בעיות נפוצות שקשורות להעברת נתונים ב-Linux

נתמך ב:

Google secops SIEM

שימו לב: הוצאנו את המעביר משימוש. רכיב ההעברה יוצא בהדרגה משימוש בפלטפורמת Google SecOps, ויגיע לסוף חיי המוצר (EOL) בינואר 2027. 1 באפריל 2026: לקוחות חדשים של Google SecOps לא יכולים להשתמש ברכיב המעביר. ‫1 בינואר 2027: תאריך סיום התמיכה הרשמי של הכלי להעברת נתונים. לא יפורסמו תיקונים נוספים, כולל תיקונים לפגיעויות באבטחה. 1 באפריל 2027: אי אפשר יותר להעביר נתונים מרכיב ההעברה. ‫Google ממליצה להשתמש ב-Bindplane for Google SecOps כפתרון העיקרי לאיסוף יומנים. מידע נוסף זמין במאמר בנושא שימוש ב-Bindplane עם Google SecOps.

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

העברת הודעות לא מתחילה

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

F0510 06:17:39.013603 202 main_linux.go:153] open /opt/chronicle/external/*.conf: no such file or directory

סיבה אפשרית 1: מיפוי שגוי בקובץ ההגדרות

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

סיבה אפשרית 2: SELinux מופעל

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

   docker run --name cfps --log-opt max-size=100m --log-opt   max-file=10 --net=host -v ~/configuration:/opt/chronicle/external --entrypoint=/bin/bash \
   -it gcr.io/chronicle-container/cf_production_
   

   הפקודה הזו תכניס אתכם למעטפת מתוך הקונטיינר.

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

   ls -lrt /opt.chronicle/external/
   

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

כדי לפתור את הבעיה:

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

     sestatus
   

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

     setenforce 0
   

היומנים לא מגיעים לדייר Google SecOps

סיבה אפשרית 1: פענוח DNS

כדי לבדוק אם המארח לא מצליח לפתור כתובות או להגיע ל-Google SecOps, מריצים את הפקודה הבאה:

  nslookup malachiteingestion-pa.googleapis.com

אם הפקודה נכשלת, צריך לפנות לצוות הרשת כדי לפתור את הבעיה.

סיבה אפשרית 2: חומת אש

כדי לבדוק אם חומת האש המקומית חוסמת את התקשורת בין Google SecOps לבין המעביר, מריצים את הפקודה הבאה:

  firewall-cmd --state

אם חומת האש מופעלת, משביתים אותה באמצעות הפקודה הבאה:

  systemctl stop firewalld

סיבה אפשרית 3: שטח אחסון זמני

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

Memory ceiling (1073741824) reached, freeing a batch from the backlog

כדי לפתור את הבעיה:

1. מפעילים דחיסה בקובץ ההגדרות של המעביר.

2. להגדיל את שטח האחסון הזמני על ידי עדכון הפרמטרים max_memory_buffer_bytes ו-max_file_buffer_bytes בקובץ התצורה. הפרמטרים האלה מציינים את מאגר הנתונים הזמני של אצוות ה-backlog שמאוחסנות בזיכרון או בדיסק.

היומנים לא מתקבלים על ידי המעביר והמארח

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

  netstat -a | grep PORT

מחליפים את PORT במזהה היציאה שרוצים לבדוק.

אם הפקודה לא מפיקה פלט, זה מצביע על כך שהמארח לא מאזין ליציאה הזו, ואתם צריכים להתייעץ עם האדמין של הרשת.

אם הפלט של הפקודה מציין שהמארח מאזין ליציאה, אבל המעביר עדיין לא מקבל יומנים, צריך לבצע את הפעולות הבאות:

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

   ​​docker stop cfps
   
   

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

   ל-TCP:

   nc -l PORT
   

   ל-UDP:

   nc -l -u PORT
   

   מחליפים את PORT במזהה הניוד שרוצים לפתור לגביו בעיות.

3. מפעילים מחדש את השירות החיצוני ובודקים אם הבעיה נפתרה. אם הבעיה נמשכת, [אפשר לפנות לתמיכה של Google SecOps.

הנתב לא מקבל יומנים, אבל המארח מקבל יומנים

אם המארח מקבל יומנים אבל המעביר לא, זה מצביע על כך שהמעביר לא מאזין ליציאה שצוינה בקובץ ההגדרות.

כדי לפתור את הבעיה:

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

   1. בטרמינל הראשון (המעביר), מפעילים את Docker בלי להפעיל את המעביר באמצעות הפקודה הבאה:

      docker run \
      --name cfps \
      --log-opt max-size=100m \
      --log-opt max-file=10 \
      --net=host \
      -v ~/config:/opt/chronicle/external \
      --entrypoint=/bin/bash \
      -it gcr.io/chronicle-container/cf_production_stable
      

   2. מציינים את היציאה שדרכה המעביר צריך להאזין:

      nc -l PORT
      

      מחליפים את PORT במזהה הניוד שרוצים לפתור לגביו בעיות.

2. במסוף השני (המארח), שולחים את הודעת הבדיקה ביציאה על ידי הרצת הפקודה הבאה:

   echo "test message" | nc localhost PORT
   

   מחליפים את PORT במזהה הניוד שרוצים לפתור לגביו בעיות.

3. מריצים מחדש את הפקודה docker. מריצים את הפקודה הבאה כדי לציין את הדגל -p עם היציאות שבהן המעביר צריך להאזין:

   docker run \
   --detach \
   –name cfps \
   --restart=always \
   --log-opt max-size=100m \
   --log-opt max-file=10 --net=host \
   —v /root/config:/opt/chronicle/external \
   -p 11500:11800 \
   gcr.io/chronicle-container/cf_production_stable
   

שגיאות נפוצות בקובץ היומן של המעביר

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

  sudo docker logs cfps

הבקשה מכילה ארגומנט לא תקין

בקובץ היומן של המעביר מוצגת הודעת השגיאה הבאה:

  I0912 18:04:15.187321 333 uploader.go:181] Sent batch error: rpc error: code = InvalidArgument desc = Request contains an invalid argument.
  E0912 18:04:15.410572 333 batcher.go:345] [2_syslog_CISCO_FIREWALL-tid-0] Error exporting batch: rpc error: code = InvalidArgument desc = Request contains an invalid argument.
  I0912 18:04:15.964923 333 uploader.go:181] Sent batch error: rpc error: code = InvalidArgument desc = Request contains an invalid argument.

פתרון:

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

לא ניתן למצוא את השרת

בקובץ היומן של המעביר מוצגת הודעת השגיאה הבאה:

{"log":"Failure: Unable to find the server at accounts.google.com.\n","stream":"stderr","time":"2019-06-12T18:26:53.858804303Z"}`

{"log":"+ [[ 1 -ne 0 ]]\n","stream":"stderr","time":"2019-06-12T18:26:53.919837669Z"}

{"log":"+ err 'ERROR: Problem accessing the Chronicle bundle.'\n","stream":"stderr","time":"2019-06-12T18:26:53.919877852Z"}

פתרון:

פנו לצוות הרשת כדי לוודא שהרשת פועלת.

חתימת JWT לא חוקית

בקובץ היומן של המעביר מוצגת הודעת השגיאה הבאה:

    E0330 17:05:28.728021 162 stats_manager.go:85] send(): rpc error: code = Unauthenticated desc = transport: OAuth 2.0: cannot fetch token: 400 Bad Request Response: {"error":"invalid_grant","error_description":"Invalid JWT Signature."}
    E0404 17:05:28.729012 474 memory.go:483] [1_syslog_FORTINET_FIREWAL-tid-0] Error exporting batch: rpc error: code = Unauthenticated desc = transport: OAuth 2.0: cannot fetch token: 400 Bad Request Response: {"error":"invalid_grant","error_description":"Invalid JWT Signature."}

פתרון:

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

האסימון חייב להיות אסימון לטווח קצר

בקובץ היומן של המעביר מוצגת הודעת השגיאה הבאה:

      token: 400 Bad Request Response:
      {"error":"invalid_grant","error_description":"Invalid JWT: Token must be a
      short-lived token (60 minutes) and in a reasonable timeframe. Check your iat and exp values in the JWT claim."} I0412 05:14:16.539060 480
      malachite.go:212] Sent batch error: rpc error: code = Unauthenticated desc =
      transport: OAuth 2.0: cannot fetch token: 400 Bad Request Response:
      {"error":"invalid_grant","error_description":"Invalid JWT: Token must be a
      short-lived token (60 minutes)

פתרון:

השגיאה הזו יכולה לקרות אם השעונים של המארח ושל מערכת השרת לא מסונכרנים. משנים את השעה במארח או מנסים להשתמש ב-NTP כדי לסנכרן את השעונים.

אין קובץ או ספרייה בשם הזה

בקובץ היומן של המעביר מוצגת הודעת השגיאה הבאה:

    ++ cat '/opt/chronicle/external/*.conf'
    cat: '/opt/chronicle/external/*.conf': No such file or directory

פתרון:

השגיאה הזו יכולה להתרחש אם מפעילים את המעביר עם מיפוי שגוי של הכונן. צריך להשתמש בנתיב המלא של הספרייה בקובץ ההגדרות (אפשר לקבל את הנתיב על ידי הפעלת הפקודה pwd).

לא הצלחנו לאחזר את מספר הלקוח מקובץ ההגדרות

בקובץ היומן של המעביר מוצגת הודעת השגיאה הבאה:

    + err 'ERROR: Failed to retrieve customer ID from configuration file.'
    ++ date +%Y-%m-%dT%H:%M:%S%z
    + echo '[2023-06-28T09:53:21+0000]: ERROR: Failed to retrieve customer ID from configuration file.'
    [2023-06-28T09:53:21+0000]: ERROR: Failed to retrieve customer ID from configuration file.
    + err '==> Please contact the Chronicle support team.'

פתרון:

השגיאה הזו נגרמת בגלל מיפוי שגוי או אם קובץ ההגדרות לא נמצא בספרייה. משתמשים בנתיב המלא של התיקייה בקובץ התצורה (אפשר לקבל את הנתיב באמצעות הפקודה pwd). מוודאים שמריצים את הפקודה הנכונה של docker run ושהקובץ קיים במיקום הבא:

    gcr.io/chronicle-container/cf_production_stable

בדוגמת הקוד הבאה אפשר לראות את הפקודה docker run:

    ​​docker run \
    --detach \
    --name cfps \
    --restart=always \
    --log-opt max-size=100m \
    --log-opt max-file=10 \
    --net=host \
    -v /opt/chronicle/config:/opt/chronicle/external \
    gcr.io/chronicle-container/cf_production_stable

פקודות Docker שימושיות

• כדי לאסוף מידע נוסף על התקנת Docker, משתמשים בפקודה הבאה:

  docker info
  

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

  systemctl is-enabled docker
  

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

  sudo systemctl enable --now docker
  

  sudo systemctl enable /usr/lib/systemd/system/docker.service
  

  פלט:

  Created symlink /etc/systemd/system/multi-user.target.wants/docker.service → /lib/systemd/system/docker.service
  

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

  sudo docker run --restart=always `IMAGE_NAME`
  

  ‫IMAGE_NAME הוא שם קובץ האימג' של המעביר.

• כדי לבדוק את הסטטוס והפרטים של שירות Docker, מריצים את הפקודה הבאה:

  sudo systemctl status docker
  

  פלט:

  ● docker.service - Docker Application Container Engine
      Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
      Active: active (running) since Sat 2020-07-18 11:14:05 UTC; 15s ago
  TriggeredBy: ● docker.socket
        Docs: https://docs.docker.com
    Main PID: 263 (dockerd)
        Tasks: 20
      Memory: 100.4M
      CGroup: /system.slice/docker.service
              └─263 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
  Jul 18 11:14:05 swarm-kraken dockerd[263]: time="2020-07-18T11:14:05.713787002Z" level=info msg="API listen on /run/docker.sock"
  Jul 18 11:14:05 swarm-kraken systemd[1]: Started Docker Application Container Engine
  

  אם נתקלים בבעיות ב-Docker, צוות התמיכה של Google SecOps יכול לבקש את הפלט של הפקודה הזו כדי לעזור ולפתור את הבעיה.

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