לדלג לתוכן

שיעור 16: ניתוח לוגים

חלק א': מאגר ידע למדריך (vEXP)

הנחיית מבנה (Structural Mandate): מסמך זה משמש כ-"Book-Book" מדריך למדריך, ומכיל עומק טכני מקסימלי עבור כל אחד מהנושאים בסילבוס, תוך היצמדות קשיחה לפורמט של 4 חלקים לכל נושא, בדגש על 80% ארכיטקטורת מערכת הליבה ו-20% תיבול ארגוני.

1. מערכת הלוגים המאוחדת (Unified Logging System): הבנת הגישה המודרנית של אפל ללוגים

1. High-Level Theory & History

במשך עשורים, מנהלי מערכות הסתמכו על קובצי טקסט פשוטים וגלוים (Plain-text log files) כדי לאבחן תקלות, לאתר באגים ולעקוב אחר אירועי מערכת. החל מהימים הראשונים של Mac OS X (בסביבות שנת 2000), אימצה אפל את הגישה המסורתית של מערכות Unix. מערכות ההפעלה ייצרו קובצי טקסט לא מובנים כמו system.log, console.log ו-mail.log, אשר אוחסנו לרוב בתיקיית /var/log. בכל פעם שהתרחש אירוע, חותמת זמן והטקסט החופשי נוספו לסוף הקובץ. מכיוון שאירועים אלו היו נדירים יחסית בתחילת שנות ה-2000, היה פשוט למנהל מערכת לקרוא את הלוג שורה אחר שורה ולזהות את שורש הבעיה. הלוגים עברו סבב תחזוקה (Rotation) באופן יומי, נדחסו לארכיוני .gz, ולבסוף נמחקו במהלך פעולות הניקוי השגרתיות של המערכת.

עם זאת, ככל שמערכות ההפעלה הפכו למורכבות בצורה אקספוננציאלית, היקף נתוני הלוגים זינק שחקים. עד לשחרור של OS X El Capitan, התקנה נקייה למדי יכלה לייצר כ-4,000 רשומות לוג כל 8 עד 9 שעות. במצב הגרוע ביותר, שגיאת מערכת יכלה להציף את הלוג עם אותם 4,000 אירועים בתוך דקה או שתיים. הזרם האדיר הזה של פעולות קריאה וכתיבה (I/O) יצר צוואר בקבוק משמעותי בביצועים. עצם פעולת כתיבת הלוגים החלה להאט את כונני ה-SSD והמעבדים של המחשבים שעליהם נועדה לפקח – תופעה המוכרת כ"אפקט הצופה" (Observer effect).

[!TIP] הקשר היסטורי (Legacy Context): הקובץ המסורתי system.log עדיין קיים במערכות macOS מודרניות, אך הוא למעשה ריק לחלוטין ונחשב למיושן ומוקצה (Deprecated). בעבר, פתרון תקלות ב-Mac הסתמך ברובו על גלילה ממושכת בתוך system.log. כיום, הסתמכות על /var/log/system.log מהווה אנטי-תבנית (Anti-pattern). מרבית ה-APIs הישנים (כמו NSLog ו-syslog) מנותבים כעת באופן אוטומטי למערכת החדשה.

מתוך הבנה שמגמה זו אינה בת קיימא, חוללה אפל מהפכה יסודית במנגנון הלוגים בשנת 2016 עם שחרור מערכת macOS Sierra (10.12), כשהציגה את מערכת הלוגים המאוחדת (Unified Logging System). מטרותיה של אפל, כפי שהוצהרו בכנס WWDC 2016, היו שאפתניות: ליצור מנגנון רישום יחיד ויעיל עבור מצבי המשתמש והקרנל גם יחד, למקסם את איסוף המידע עם מינימום פגיעה בביצועים (Observer effect), לדחוס את נתוני הלוג בזמן אמת, ולשלב בקרות פרטיות מחמירות באופן מובנה אל תוך ארכיטקטורת הרישום. המערכת המאוחדת למעשה "חטפה" את קובצי הטקסט הישנים, והחליפה אותם בפורמט בינארי מובנה, דחוס וקנייני.

2. Deep Technical Architecture

בלב מערכת הלוגים המאוחדת פועל תהליך הרקע (Daemon) הנקרא logd. כאשר אפליקציה, מנהל התקן (Driver) או הרחבת קרנל (kext) מייצרים הודעת לוג באמצעות ה-APIs המודרניים, ה-logd מיירט אותה. במקום לבצע פעולת כתיבה יקרה לדיסק באופן מיידי, התהליך דוחס את רשומת הלוג ושומר אותה במאגר זיכרון (Memory buffer ב-RAM).

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

  1. ארעי (Ephemeral): ההודעה נשמרת בזיכרון לזמן קצר ואז נמחקת מבלי לגעת בדיסק. תהליך זה אופייני להודעות רגילות מסוג Info או Debug, אלא אם כן פרופיל תצורה ספציפי דורש אחרת.
  2. קבוע (Persistent): ההודעה נכתבת מהזיכרון ונשמרת על גבי הדיסק. קבצים קבועים אלו, המוכרים כקובצי tracev3, מאוחסנים תחת הנתיב /var/db/diagnostics/Persist/. רשומות קצרות-חיים נוספות עשויות להיכתב ל-/var/db/diagnostics/Special/, בעוד שנתוני מחרוזות (Strings) ארוכים מאוחסנים על פי מזהה ייחודי (UUID) תחת /var/db/uuidtext/.

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

בעדכוני macOS אחרונים, כולל macOS Tahoe 26, המערכת מנהלת באגרסיביות את שימור הקבצים הללו. הלוג המאוחד מבצע רוטציה לקובצי ה-tracev3 שלו כדי לשמור על נפח קובץ כולל מרבי (Maximum total file size). מכיוון ש-macOS מודרנית מייצרת כמות אסטרונומית של רשומות לוג, פרק הזמן שמכסות הרשומות הקבועות התכווץ דרסטית. מה שהיה בעבר מספיק כדי לכסות 20 ימי היסטוריה בימים הראשונים של Sierra, עשוי כיום לכסות שעות ספורות בלבד במערכת Tahoe בשימוש אינטנסיבי.

בנוסף, הארכיטקטורה עושה שימוש נרחב ב-Signposts, תכונה שהוצגה ב-High Sierra ו-Mojave. סמני ה-Signposts מאפשרים למפתחים לסמן את ההתחלה והסיום של משימות מסוימות, ומאפשרים למערכת למדוד ביצועים, ניצולת מעבד ופרקי זמן ברמת דיוק של מיקרו-שניות.

קריסות ליבה (Kernel Panics) ומאגר הלוגים: מכיוון שמערכת הלוגים המאוחדת מתעדפת שמירת רשומות עדכניות ב-RAM כדי לייעל ביצועים, היא מציבה אתגר ייחודי במהלך קריסת ליבה (Kernel Panic). כאשר מתרחשת שגיאת קרנל קריטית, המערכת נעצרת מיד. כל רשומות הלוג הממתינות בזיכרון שטרם נכתבו לספריית הדיסק /var/db/diagnostics/Persist/ מושמדות באופן מיידי. לכן, אם תנסו לקרוא את הלוג המאוחד כדי להבין מה קרה באלפיות השנייה שקדמו לקריסה, סביר להניח שלא תמצאו דבר.

במקום זאת, אפל מסתמכת על מנגנון רישום קריסות (Panic logging) ייעודי. כאשר ה-Mac מבצע הפעלה מחדש לאחר קריסה, החומרה ברמה הנמוכה או מערכת ההתאוששות (Recovery OS) כותבת דוח קריסה ספציפי (Panic log, הנשמר לרוב סמוך ל-/var/db/PanicReporter או /Library/Logs/DiagnosticReports). הלוג הזה הוא פיסת הראיה החשובה ביותר, ולרוב מוצג למשתמש בהודעה מיד לאחר ההתחברות חזרה למערכת.

3. Terminal Commands, Plists & Logs

הדרך העוצמתית ביותר לאינטראקציה עם מערכת הלוגים המאוחדת היא דרך ה-Terminal באמצעות פקודת log.

  • צפייה בלוגים בזמן אמת (Streaming): כדי לצפות בלוגים בזמן אמת כשהם נוצרים בזיכרון, השתמשו בפקודה stream. קריטי להשתמש במסננים (Predicates) כדי לסנן את הרעש. 

    log stream --predicate 'subsystem == "com.apple.loginwindow"' --info

  • חיפוש היסטורי (Historical Search): כדי לתשאל את קובצי ה-tracev3 בדיסק על אירועי עבר, השתמשו בפקודה show. 

    log show --predicate 'process == "kernel"' --last 1h

  • איסוף לוגים לניתוח (Log Collection): אם עליכם לחלץ לוגים ממחשב מסוים כדי לנתח אותם ב-Mac אחר, תוכלו לארוז אותם לארכיון .logarchive. 

    sudo log collect --last 1d --output /tmp/macOS_logs.logarchive

  • הגדרות קונפיגורציה: מדיניות האיסוף והשימור של תתי-מערכות שונות נשלטות על ידי קובצי XML (Plists). הגדרות ברירת המחדל הכלליות של המערכת נעולות היטב בכונן המערכת החתום (SSV) לקריאה בלבד בנתיב /System/Library/Preferences/Logging. מעקפים והגדרות פרופילים מוגדרי-משתמש מאוחסנים ב-/Library/Preferences/Logging.

4. Edge Cases & Troubleshooting

בעיית צנזורת הפרטיות: כשאפל תכננה את מערכת הלוגים המאוחדת, היא שילבה את נושא הפרטיות ברמה הבסיסית ביותר. הודעות לוג המכילות מידע שעשוי להיות רגיש (כמו שמות משתמשים, כתובות דוא"ל או נתיבי קבצים ספציפיים) מצונזרות באופן דינמי ומוחלפות בתגית המפחידה <private>.

אף שנועדה להגן על נתוני משתמשים, להחלטה זו יש השלכה בלתי רצויה: הסרת המשתנים המדויקים להם זקוקים מנהלי ה-IT כדי לפתור בעיה ספציפית. בעבר (עד macOS Catalina), היה קיים מתג סודי (log config) שאיפשר לבטל לחלוטין את הגנת הפרטיות הזו באופן גלובלי. אפל הסירה כליל את "הדלת האחורית" הזו. כיום, עקיפת צנזורת הפרטיות מחייבת התקנת פרופיל MDM ייעודי (Configuration Profile) המאפשר "Private Data Logging" טרם התרחשות האירוע. מאחר שהתגית <private> "נצרבת" לתוך רשומת הלוג הבינארית בזמן יצירתה, אין שום אפשרות מתמטית לאחזר את הנתונים המצונזרים בדיעבד.

הצפת מידע וקריסת כלים (Information Overload & Tool Crashing): אם מנהל מערכת מריץ את הפקודה log show ללא פילטר קפדני (--predicate), הפקודה תנסה לפרוס ולהציג מאות מיליוני רשומות לוג. הדבר יציף כמעט בוודאות את הטרמינל, יצרוך כמויות עצומות של RAM, ועלול להקריס את כלי שורת הפקודה. בעת חקירת לוגים על פני פרק זמן רחב, מנהלים צריכים להשתמש בשיטת "Stepping time windows" (חלונות זמן מדורגים). לדוגמה, לתשאל מרווח זמן של 5 שניות, לבדוק את התוצאות, ואז להתקדם למרווח ה-5 שניות הבא. שאפו להחזיר לא יותר מ-5,000 רשומות לכל שאילתה כדי לשמור על יציבות המערכת.

2. שליטה באפליקציית Console: סינון רעשים ואיתור תקלות בזמן אמת

1. High-Level Theory & History

אפליקציית ה-Console (Console.app) שימשה כממשק הגרפי (GUI) המרכזי לצפייה בלוגים במחשבי ה-Mac מאז ימי Mac OS X 10.0 Cheetah בשנת 2001. בגלגולה המקורי, Console הייתה למעשה "קורא טקסט" משודרג. היא סיפקה סרגל צד נוח לניווט בין עשרות קובצי לוג בפורמט טקסט פשוט שפוזרו ברחבי המערכת, מה שאיפשר למשתמשים לפתוח במהירות את system.log, mail.log או דוחות קריסה ספציפיים לאפליקציות.

עם זאת, הופעת מערכת הלוגים המאוחדת (Unified Logging System) שינתה לחלוטין את ייעודה של ה-Console. מאחר שנתוני הלוגים הבסיסיים נעולים כעת בתוך קובצי tracev3 בינאריים ובלתי מתועדים, Console נבנתה מחדש. כיום, Console כבר איננה קוראת היסטוריה של לוגים; היא מתפקדת כ-Real-Time Stream Viewer (צופה בזרימת נתונים בזמן אמת).

מנהלי מערכות ותיקים רבים מרגישים שה-Console "נחטפה" מהם, שכן אפל החליטה להגביל את האפליקציה מתשאול ישיר של מאגרי הלוג ההיסטוריים בכונן המקומי. אם תפתחו היום את Console, היא תציג לכם רק אירועי לוג המתרחשים אחרי הרגע שבו לחצתם על כפתור "Start". היא אינה יכולה להסתכל אחורה בזמן אלא אם כן תזינו לתוכה באופן יזום חבילת .logarchive שנאספה מראש. לכן, בעוד ש-Console נותרה כלי רב עוצמה לסינון רעשים ולהזרמת נתונים בזמן אמת, היא איבדה את התועלת שלה לניתוח שלאחר מעשה (Post-mortem analysis) של אירועי עבר, מה שמאלץ משתמשי קצה (Power users) להסתמך על שורת הפקודה (Terminal).

2. Deep Technical Architecture

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

אפליקציית Console משתלבת ישירות גם עם ה-CrashReporter. כאשר אפליקציה קורסת, macOS מייצרת קובץ אבחון ספציפי. ב-macOS Tahoe 26, קובצי אבחון אלו מקובצים בסרגל הצד של Console תחת מספר קטגוריות:

  • דוחות קריסה / Crash Reports (.ips): מידע אודות אפליקציות או תהליכים שנסגרו באופן פתאומי בשל תקלות זיכרון או חריגות (Exceptions).
  • דוחות סחרור / Spin Reports (.spin): פרטים הנוגעים לאפליקציות שהפכו ללא מגיבות (כדור ים צבעוני מסתובב) משום שחוט ה-UI הראשי (Main thread) נחסם לפרק זמן ממושך.
  • דוחות לוג / Log Reports (.log, ._log, .its): מידע רגיל הנוגע לאירועי עיבוד.
  • דוחות אבחון / Diagnostic Reports (.diag, .dpsub): נתונים על משאבי חומרה, רספונסיביות של המערכת ואזורי זיכרון בקרנל (Kernel zones).

בנוסף ללוגים ברמת התוכנה המוצגים ב-Console, ארכיטקטורת macOS כוללת כלי מעקב קרנל (Kernel tracing) ברמות הנמוכות ביותר. fs_usage הוא כלי CLI המתממשק ישירות לקריאות מערכת של הקרנל (Syscalls) כדי לעקוב אחר פעילות מערכת הקבצים בזמן אמת, והוא משמש ככלי המשלים המושלם כאשר הלוגים ב-Console אינם מספקים הקשר מספק לגבי גישה לקבצים.

3. Terminal Commands, Plists & Logs

  • סינון ב-GUI של ה-Console: כדי להתמודד עם הרעש הקיצוני של הלוגים בזמן אמת, Console מספקת סרגל חיפוש מתקדם. הקלדת שאילתה ולחיצה על Enter יוצרת תגית סינון (Filter token). ניתן ללחוץ על התגית הזו כדי לשנות את היקף הסינון מ-"Any" לשדות ספציפיים ומוגדרים כגון Process, Subsystem או Message. ב-macOS Tahoe 26, ניתן אף לקבץ הודעות לוג לפי פעילויות (Activities), מה שמאפשר לעקוב אחר פעולה מורכבת מרובת-שלבים (כמו לחיצת יד בחיבור רשת - handshake) לאורך מספר תהליכים שונים. ניתן גם להשתמש בקיצור Command-F כדי למצוא מחרוזות טקסט ספציפיות בתוך דוח קריסה נרחב.

  • צפייה ואיתור קובצי קריסה: דוחות הקריסה נגישים דרך סרגל הצד (Sidebar). אם עליכם לעבוד עם הקובץ הפיזי עצמו, ניתן ללחוץ לחיצה ימנית על הדוח ולבחור File > Reveal in Finder.

  • מעקב אחר מערכת הקבצים (CLI): כאשר Console אינה מספיקה למעקב אחר קריאה/כתיבה לדיסק (Disk I/O), השתמשו בפקודה: 

    sudo fs_usage -w -f filesys
    (הערה: פקודה זו דורשת הרשאות root ותציג שטף עצום של אירועי גישה למערכת הקבצים בזמן אמת).

  • שיתוף לוגים: Console כוללת תמיכה מובנית בהרחבות השיתוף (Sharing extensions) של macOS, המאפשרות לבחור מקבץ של הודעות לוג או דוח קריסה ולשתף אותם ישירות מול התמיכה של אפל או מול צוות ה-IT שלכם דרך האפליקציות השונות (כמו Mail או AirDrop).

4. Edge Cases & Troubleshooting

עומס מידע בממשק הגרפי (Information Overload in GUI): הזרמת לוגים ב-Console מבלי להחיל פילטרים קפדניים מיד, תגרום לאפליקציה לקפוא ולהאט, ותצרוך משאבי CPU מוגזמים. המק מייצר אלפי רשומות בשנייה; הממשק הגרפי פשוט לא מסוגל לרנדר טקסט בקצב כזה. תמיד השהו את זרימת הלוגים (Pause), החילו את הפילטרים שלכם (Process או Subsystem), ורק אז המשיכו (Resume).

חסימת הרשאות TCC: לעיתים, אפליקציה תקרוס מיד בעת הפעלתה, אך שום דוח קריסה (.ips) לא יופיע ב-Console. מקרה קצה (Edge case) זה נגרם לרוב משחיתות במסד הנתונים של ה-TCC (Transparency, Consent, and Control). אם האפליקציה חסרה את הרשאות ארגז החול (Sandbox) המתאימות כדי לכתוב לתיקיית הדיאגנוסטיקה, דוח הקריסה לא ייווצר, וישאיר את מנהל המערכת "עיוור" למקור התקלה.

אבחון דליפות זיכרון באמצעות דוחות קריסה (Panic Logs): אם מערכת קופאת וקורסת (Panic), דוח הקריסה שנוצר (הניתן לצפייה בעורך טקסט או ב-Console אם נשמר) מחזיק את הפתרון לחידה. חפשו רמזים באזורי הזיכרון (Memory zones). לדוגמה: panic(cpu 8 caller 0xffffff80017729eb): "zalloc: zone map exhausted while allocating from zone kalloc.12288, likely due to memory leak in zone kalloc.48 (6586956000 total bytes)" שורת לוג ספציפית זו היא "האקדח המעשן" לדליפת זיכרון בקרנל, המעידה כי דרייבר או kext צרכו את כל זיכרון ה-RAM הפנוי באזור הקצאה ספציפי של הקרנל (kalloc), מה שאילץ את המערכת לעצור. יתרה מזאת, כל הרחבות קרנל צד-שלישי (kexts) הרשומות בתחתית מעקב הקריסה (Panic log trace) נחשבות לחשודות המיידיות.

3. יצירת Sysdiagnose: דיאגנוסטיקה מתקדמת מתוך ה-GUI

1. High-Level Theory & History

כאשר בעיה ב-macOS מורכבת מדי, מופיעה לסירוגין או עמוקה מכדי לזהותה במבט חטוף ב-Console או על ידי פקודת log show בודדת, מנהלי IT פונים לנשק הדיאגנוסטי האולטימטיבי: ה-Sysdiagnose.

ה-Sysdiagnose מתפקד למעשה כ"קופסה השחורה" או הרשם (Flight recorder) של מחשב ה-Mac. זהו תהליך אוטומטי המפעיל במקביל עשרות סקריפטים לאבחון כדי לצלם תמונה מקיפה של 360 מעלות של כל מערכת ההפעלה ברגע ספציפי בזמן. היסטורית, כלי זה נשמר בסוד יחסית על ידי מהנדסי אפל לאיתור באגים בליבת מערכת ההפעלה. כיום, הוא הפך לסטנדרט הטיפול וההסלמה בתמיכה לארגוני IT. אם תפתחו קריאת שירות ארגונית ברמה גבוהה מול AppleCare, בקשתם הראשונה תהיה כמעט בהכרח: "Please provide a Sysdiagnose."

2. Deep Technical Architecture

יצירת Sysdiagnose היא פעולה אינטנסיבית ביותר. עם הפעלתו, המערכת משגרת תהליך רקע הרץ תחת הרשאות root מוחלטות. כלי הניהול (Orchestrator) מפעיל מספר תוכנות שורת-פקודה במקביל לאיסוף מערכי נתונים שונים:

  • system_profiler: מייצר עץ XML מקיף של כל רכיב חומרה, התקן USB ומסך המחובר למק.
  • log collect: זורק את כל מסד הנתונים של ה-tracev3 של הלוג המאוחד המכסה את הימים האחרונים.
  • spindump ו-tailspin: שואבים את מצב הזיכרון בזמן אמת ואת מחסנית התהליכים של המעבד (Thread execution stack), ומראים בדיוק מה כל אפליקציה מעבדת כעת.
  • מצב רשת (Network State): מריץ כלים כמו netstat, ifconfig ואת טבלאות הניתוב כדי לתעד את המצב המדויק של ממשקי הרשת.
  • קובצי הגדרות (Preference Files): מעתיק קובצי תצורה קריטיים מסוג .plist מ-/Library/Preferences/ כדי להציג את פרופילי ה-MDM והגדרות המערכת שהופעלו.

כל המידע הזה נאגר לתיקייה זמנית, נדחס באופן מאסיבי, ונארז לקובץ ארכיון ענק מסוג .tar.gz.

3. Terminal Commands, Plists & Logs

למרות שניתן להפעיל את Sysdiagnose דרך ה-CLI, היופי של הכלי טמון בנגישותו דרך ה-GUI וקיצורי מקלדת גלובליים.

  • יצירה דרך הממשק (קיצור מקלדת גלובלי): לחצו בו-זמנית על Shift + Control + Option + Command + Period (⇧⌃⌥⌘.). המסך יהבהב בקצרה לאישור הפקודה, והתהליך יתחיל לפעול בשקט ברקע.

  • יצירה ב-CLI: לניהול מרחוק דרך SSH, השתמשו בטרמינל: 

    sudo sysdiagnose -f ~/Desktop/

  • מצב שחזור (Recovery Mode): אם המק אינו מצליח לאתחל את מערכת ההפעלה, ניתן להפעיל אבחון ממצב ההתאוששות (macOS Recovery) על ידי לחיצה על Control-Option-Command-Period.

  • נתיב השמירה כברירת מחדל: כברירת מחדל, המערכת שומרת את הארכיון הסופי בנתיב /private/var/tmp/. מאחר שזוהי תיקייה מוסתרת, macOS תפתח אוטומטית חלון Finder המסמן את הקובץ .tar.gz מרגע שהתהליך יושלם.

4. Edge Cases & Troubleshooting

פגיעה בביצועים במהלך היצירה: מאחר ש-Sysdiagnose מפעיל עשרות כלי ניתוח אינטנסיביים בבת אחת, הוא צורך כמות אדירה של מעבד (CPU) וקריאה/כתיבה לדיסק (Disk I/O). התהליך עלול לארוך בין 2 ל-10 דקות, בהתאם למהירות החומרה ולגודלו של הלוג המאוחד. בזמן זה, מאווררי ה-Mac עשויים להסתובב במהירות, וממשק המשתמש (UI) עשוי להפוך לאיטי. משתמשים שאינם מודעים לכך עשויים לחשוב שהמחשב "קפא" ויבצעו הפעלה מחדש בכפייה (Hard reboot), ובכך יהרסו לצמיתות את נתוני הדיאגנוסטיקה.

סיכוני פרטיות ואבטחת נתונים: ארכיון Sysdiagnose שלם עולה לעיתים קרובות על 300MB עד 500MB בנפחו. כיוון שהוא לוכד תמונת מצב (Snapshot) מלאה של המערכת, קיימת סבירות גבוהה שהוא יכיל מידע אישי ורגיש (PII - Personally Identifiable Information). מידע זה עשוי לכלול כתובות URL שנצפו לאחרונה, שמות רשתות Wi-Fi, כתובות IP פנימיות וייתכן שאף שמות קבצים פרטיים. מחלקות IT בארגונים חייבות לנהוג בזהירות מרבית. שליחת Sysdiagnose גולמי לספק תוכנה של צד-שלישי שאינו כפוף להסכמי סודיות חמורים (NDAs) מהווה סיכון אבטחה כבד ועשויה להוות הפרת רגולציה משמעותית.

4. חדר הבריחה: איתור שורת הלוג הספציפית ("האקדח המעשן") ב-Console

1. High-Level Theory & History

בסביבות ארגוניות מודרניות המנוהלות על ידי שרתי MDM (כדוגמת Jamf, Intune או Workspace ONE), מנהלי ה-IT מסתמכים לחלוטין על פקודות מרחוק (Remote commands). תרחיש נפוץ ומתסכל במיוחד הוא כאשר מנהל המערכת שולח פקודה קריטית - כגון "Install Wi-Fi Profile", "Device Lock", או "Remote Wipe" - והפקודה פשוט נשארת ממתינה בקונסולת ה-MDM בסטטוס "Pending".

מנהל ה-MDM מתעקש שהפקודה נשלחה; מנהל הרשתות נשבע מכל הלב ש"חומת האש (Firewall) הארגונית פתוחה לחלוטין"; בעוד המשתמש טוען שהמק מחובר לאינטרנט וגולש לאתרים כרגיל.

תרחיש זה הוא מעין "חדר בריחה" קלאסי של עולם ה-IT. כדי לפתור את החידה, על איש התמיכה לצלול לתוך אפליקציית ה-Console כדי למצוא את אותה שורת קוד מדויקת - "האקדח המעשן" (Smoking Gun) - המוכיחה שחומת האש של הרשת היא זו שמיירטת ושוברת את החיבור המאובטח לשרתי אפל.

2. Deep Technical Architecture

כדי להבין את הלוגים, חובה להבין את ארכיטקטורת ה-MDM. התקשורת בין שרת ה-MDM למק אינה תקשורת ישירה. היא מסתמכת על שירות התראות הדחיפה של אפל (Apple Push Notification service - APNs) כגורם מתווך:

  1. שרת ה-MDM שולח התראת "דחיפה" קטנה (Push notification) לשרתי ה-APNs של אפל.
  2. ה-Mac מתחזק חיבור מוצפן (TLS/SSL) קבוע ותמידי אל בלוק כתובות ה-IP 17.0.0.0/8 של אפל בפורט 5223. תהליך הרקע האחראי לשמור על פעימת הלב (Heartbeat) הזו פעילה הוא ה-apsd (Apple Push Service Daemon).
  3. כאשר ה-apsd מקבל את "דחיפת העירור" (Wake up push) מאפל, הוא מעיר את ה-MDM Daemon המקומי (mdmd).
  4. רק לאחר מכן, mdmd יוזם תקשורת יוצאת סטנדרטית (Outbound HTTPS) על פורט 443 חזרה לשרת ה-MDM הארגוני כדי להוריד את גוף הפקודה עצמה (Payload).

התקלה מתרחשת כמעט תמיד בשלב 2. חומות אש (Firewalls) ארגוניות מודרניות מפעילות לעיתים קרובות בדיקת תעבורה או פענוח תקשורת מוצפנת (SSL Inspection / Decryption). חומת האש מיירטת את התעבורה היוצאת בפורט 5223, מחליפה את תעודת האבטחה (Certificate) של אפל בתעודה הארגונית שלה, ומנסה לקרוא את התעבורה המוצפנת.

התהליך apsd של אפל משתמש בהצמדת תעודות נוקשה (Certificate Pinning). כאשר הוא מזהה שחומת האש החליפה את התעודה, הוא רושם זאת באופן מיידי כמתקפת "האדם שבאמצע" (Man-in-the-Middle - MitM), מפיל את החיבור, ומתעד שגיאה פטאלית בלוג. ה-Mac כעת "מנותק" מה-MDM, למרות שהמשתמש יכול עדיין לגלוש דרך דפדפן Google Chrome ללא כל בעיה.

3. Terminal Commands, Plists & Logs

  • בדיקת קישוריות ל-APNs (CLI): השתמשו בכלי nc (Netcat) כדי לאמת אם הפורט הפיזי אכן פתוח לכיוון שרתי אפל: 

    nc -zv 17.0.0.0 5223

  • חיפוש "האקדח המעשן" (CLI): בצעו שאילתה בלוג המאוחד עבור תהליכי ה-APNs וה-MDM המדויקים בטווח של השעתיים האחרונות: 

    log show --predicate 'subsystem == "com.apple.apsd" or subsystem == "com.apple.mdm"' --last 2h

  • פתרון 'חדר הבריחה' (Console GUI): פתחו את Console, התחילו להזרים את הלוגים, וצרו מסנן Process עבור המילה apsd. צפו בלוגים בזמן שאתם מנסים לשלוח פקודת דחיפה. "האקדח המעשן" יופיע כהודעת שגיאה בוטה וחד-משמעית: Certificate trust failed או connection timeout. זו ההוכחה הניצחת שתעבירו למנהל הרשת על מנת לאלץ אותו לתקן את חומת האש.

  • איסוף לוגים מרוחק (Remote Log Collection): ב-macOS 13 (Ventura) ומעלה, אפל הוסיפה את הפקודה GetDiagnosticStatus לניהול מרחוק (MDM command), אשר מאפשרת לשרת ה-MDM לשלוף לוגים ממק מרוחק ללא כל התערבות מצד המשתמש.

4. Edge Cases & Troubleshooting

פרדוקס שרתי הפרוקסי (The Proxy Paradox): מקרה קצה נפוץ כולל שרתי פרוקסי (Web proxies) המוגדרים באופן שגוי. אם שרת פרוקסי מאפשר תעבורת רשת סטנדרטית (HTTPS Port 443) דרך הדפדפן, אך נחנק כשהוא נדרש להחזיק חיבורי TCP ארוכי-טווח על Port 5223, ה-Mac ייראה בצורה כוזבת כ"מחובר". הפתרון המוחלט והבלתי מתפשר עבור גופי IT ארגוניים הוא הוספת מעקף מוחלט (Bypass / Allowlist) לכלל שירותי חומת האש והפרוקסי עבור כל רשת הכתובות של אפל (17.0.0.0/8), על מנת להבטיח שה-apsd יכול לתחזק את החיבור הקבוע שלו ללא הפרעה.

מלכוד 22 של האבחון המרוחק (The Catch-22 of Remote Diagnostics): בעוד שהפקודה GetDiagnosticStatus היא גאונית לאיסוף לוגים מעובדים מרוחקים (Remote workers), היא סובלת מ"מלכוד 22" (Catch-22) הרסני. אם חומת האש אכן חוסמת את ה-APNs (פורט 5223), המחשב לעולם לא יקבל את הודעת הדחיפה המורה לו לבצע את פקודת הדיאגנוסטיקה המרוחקת! בתרחישים מסוג זה, פתרון תקלות מרחוק (Remote troubleshooting) הופך למשותק לחלוטין. למנהל ה-IT לא נותרת ברירה אלא לגשת פיזית לעמדה, או להדריך את המשתמש טלפונית כיצד ליצור Sysdiagnose דרך קיצור המקלדת ⇧⌃⌥⌘., ולהעלות אותו באופן ידני לפורטל ה-IT.

💡 עזרים ויזואליים להרצאה (Presentation Visuals)

[!TIP] המחשה ויזואלית (עזר לתלמיד) תמונות אלו ממחישות את הממשק או המנגנון הרלוונטי לנושא השיעור.

Save_and_read_the_panic_log_p1_41 Slide69_image82 Slide69_image83