לניטור שלמות יש תכונה לא נוחה: הוא זקוק לנקודת ייחוס שנלקחה ממערכת שידוע שהיא נקייה. ואם השרת רץ שלוש שנים ושאלת הפריצה עלתה רק היום, לקחת את נקודת הייחוס הזאת כבר מאוחר מדי — הייתם רושמים כתקין את מה שנמצא שם.
אבל ב-Debian וב-Ubuntu נקודת הייחוס כבר קיימת, והיא אינה שלכם: כל חבילה מותקנת נושאת את סכומי הביקורת של הקבצים שלה. השוואה מולם אינה דורשת לא הגדרות ולא תצלום קודם, ועובדת בכל מערכת בכל רגע. שם הכלי הוא debsums.
שימוש
sudo apt install debsums
sudo debsums -cהדגל -c מדפיס רק את הקבצים שלא תאמו לנקודת הייחוס. בלעדיו הפלט הוא דוח שורה-שורה על כל קובץ במערכת, עשרות אלפי שורות.
הבדיקה נמשכת כמה דקות ומעמיסה על הדיסק, ולכן בשרת פעיל שווה להריץ אותה בעדיפות מופחתת:
sudo ionice -c3 nice -n19 debsums -cאיך קוראים את התוצאה
פלט ריק פירושו שכל קובץ שנבדק תואם למה שההפצה התקינה. פלט לא ריק דורש בדיקה, והממצאים מתחלקים לשתי מחלקות שונות מאוד.
קובצי הגדרות ב-/etc. לשנות אותם זו עבודה רגילה: ערכתם את sshd_config, הגדרתם nginx, הוספתם פרמטרי ליבה. הבדלים כאלה צפויים. וכדי שלא יסתובבו לכם ברגליים יש מצב נפרד:
sudo debsums -e -c-e בודק רק קובצי הגדרות — לפעמים שימושי כדי לראות רשימה של כל מה ששיניתם במכונה הזאת.
קובצי הפעלה וספריות. הבדל ב-/usr/bin, ב-/usr/sbin, ב-/bin או ב-/usr/lib הוא בדיוק מה שלשמו הבדיקה הורצה. יש סיבות לגיטימיות אבל לא רבות: הקובץ נערך ידנית בזמן איתור תקלות, הוחל טלאי של צד שלישי, או שהחבילה שודרגה בזמן הבדיקה. אם אף אחת מהן אינה מתאימה, הגיע הזמן לבדוק ברצינות.
היעדים הקלאסיים להחלפה הם ls, ps, netstat, ss, find, sshd. גרסה שהוחלפה מסתירה מהפלט שלה את השורות החשובות, וכל בדיקה שלכם מכאן ואילך מפסיקה לומר את האמת.
הכיסוי חלקי — וצריך לדעת את זה
מגבלה שבדרך כלל אינה מוזכרת: לא כל החבילות מספקות סכומי ביקורת. קבצים מחבילות כאלה אינם נבדקים כלל ולא יופיעו בדוח בשום מצב. את הרשימה רואים כך:
sudo debsums -lלכן דוח debsums נקי פירושו «בחלק שנבדק הכול בסדר», ולא «המערכת לא שונתה». אותו דבר נכון לכל מה שהותקן מחוץ למנהל החבילות: מה שהודר מקוד מקור, מה שהורד כקובץ בינארי, מה שהותקן בסקריפט מאתר המפתח — אחרי כל אלה debsums אינו עוקב מעצם הגדרתו, ובדיוק כאן דרוש AIDE.
הרצה סדירה
החבילה מספקת משימה מוכנה שמופעלת ב-/etc/default/debsums:
CRON_CHECK=weeklyפעם בשבוע היא תדירות סבירה: הבדיקה מעמיסה על הדיסק במידה מורגשת, וקובצי מערכת משתנים לעיתים רחוקות בין עדכונים. הרצה יומית אינה מוסיפה דבר מלבד עומס.
אם קובץ אכן הוחלף
הדחף הראשון הוא להתקין מחדש את החבילה ולהחזיר את המקור:
sudo apt install --reinstall coreutilsהפקודה נכונה, אבל לא כפעולה ראשונה. קובץ בינארי מערכתי שהוחלף פירושו שלמישהו היה root, ושחזור הקובץ אינו פותר את הבעיה הזאת — הוא רק משמיד את העקבות. הסדר צריך להיות הפוך: תחילה שמרו עותק של הקובץ החשוד ואת שעת השינוי שלו, ראו מה עוד השתנה באותה תקופה, ובדקו את משימות ה-cron, את מפתחות ה-SSH ואת רשימת המשתמשים. לשחזר — רק אחרי כל זה.
ושווה לזכור גם את גבולות השיטה: אם המערכת נפרצה לעומק, ייתכן ש-debsums עצמו והספריות שהוא משתמש בהן הוחלפו יחד עם כל השאר. בדיקה מבפנים אינה נותנת ערובה מוחלטת — את זה נותנת אתחול ממדיה חיצונית. לעבודה יומיומית זה בכל זאת מספיק: הרוב המכריע של ההתקפות אוטומטי ואינו מתוחכם כל כך.
מקומו בתמונה הכללית
debsums טוב בכך שאינו דורש דבר ועובד מיד — וזה הופך אותו לנקודת פתיחה נוחה לשרת שאת ההיסטוריה שלו אינכם מכירים. חולשתו היא הכיסוי החלקי וחוסר הידיעה על כל מה שהותקן מחוץ לחבילות. והצמד «debsums ועוד AIDE» סוגר את שני הצדדים: נקודת הייחוס המוכנה של ההפצה לקובצי המערכת, והתצלום שלכם עצמכם לכל השאר.
וכרגיל, המשמעות אינה בהרצה אלא בכך שהתוצאה האחרונה תהיה גלויה לעין יחד עם התאריך שלה. איך זה נראה מראה ההדגמה למטה.