האם unattended-upgrades מופעל ב-Ubuntu 24.04 כברירת מחדל?

מדוע כדאי להגדיר עדכוני אבטחה אוטומטיים

שרת שאינו מעודכן הוא המטרה הקלה ביותר באינטרנט. רוב הפריצות לשרתים קטנים אינן מתוחכמות; הן מנצלות באג ידוע בחבילה ישנה שבעל השרת מעולם לא עדכן. Ubuntu מספקת כלי שסוגר את הפער הזה באופן עצמאי: unattended-upgrades מתקין עדכוני אבטחה באופן אוטומטי, לפי לוח זמנים, מבלי שתצטרכו להתחבר לשרת. זהו צעד האבטחה המשתלם ביותר שניתן לבצע ב-VPS, וב-Ubuntu ההגדרה שלו אורכת דקות ספורות.

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

שלב 1: התקנה והפעלה

ב-Ubuntu 24.04 החבילה לרוב קיימת אך לא תמיד מופעלת. התקינו אותה והפעילו אותה:

sudo apt update
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

ההנחיה של dpkg-reconfigure מציגה שאלה של כן או לא, האם להוריד ולהתקין עדכונים יציבים באופן אוטומטי. ענו "כן". פעולה זו יוצרת את הקובץ שמפעיל את המשימה היומית:

cat /etc/apt/apt.conf.d/20auto-upgrades

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

השורה הראשונה מרעננת את רשימת החבילות מדי יום; השנייה מריצה את ה-unattended upgrade מדי יום. שניהם מוגדרים ל-1, מה שאומר שהמכונה בודקת ומחילה עדכוני אבטחה בכל יום, באמצעות systemd timer, ללא צורך בפעולה נוספת מצדכם.

שלב 2: החלטה אילו עדכונים יוחלו אוטומטית

המדיניות נמצאת ב-/etc/apt/apt.conf.d/50unattended-upgrades. פתחו אותו והביטו בבלוק Allowed-Origins בחלק העליון:

Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}";
    "${distro_id}:${distro_codename}-security";
    "${distro_id}ESMApps:${distro_codename}-apps-security";
    "${distro_id}ESM:${distro_codename}-infra-security";
};

שורות ה--security הן החשובות, והן מופעלות כברירת מחדל. זוהי המדיניות השמרנית: עדכוני אבטחה נכנסים, עדכוני תכונות רגילים נשארים עבורכם להחלה ידנית לפי בחירתכם. ניתן להוסיף את שורת ה-"${distro_id}:${distro_codename}-updates" כדי להחיל אוטומטית את כל העדכונים, אך עבור שרת המארח שירותים חשובים, החלת עדכוני אבטחה בלבד היא ברירת המחדל הבטוחה יותר. השאירו זאת כפי שהוגדר אלא אם יש לכם סיבה ספציפית לשנות זאת.

שלב 3: טיפול באתחולים

עדכונים מסוימים, כמו עדכון ליבה (kernel) או ספריית ליבה, נכנסים לתוקף מלא רק לאחר אתחול. unattended-upgrades לא יאתחל את השרת שלכם אלא אם תורו לו לעשות זאת, מה שאומר שליבה מעודכנת עלולה להישאר לא בשימוש עד שתבצעו אתחול. החליטו כיצד ברצונכם לטפל בכך, והגדירו זאת במפורש ב-50unattended-upgrades:

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";

הגדרה זו מאתחלת את השרת בארבע לפנות בוקר כאשר, ורק כאשר, עדכון דורש זאת. ב-VPS יחיד ללא cluster למעבר גיבוי, אתחול קצר לפנות בוקר הוא לרוב הפשרה הנכונה כדי להישאר מעודכנים בתיקוני ליבה. אם השרת מריץ שירות שאסור שיאותחל באופן בלתי צפוי, השאירו את האתחול כבוי והרגילו את עצמכם לבצע אתחול ידני לאחר בדיקת /var/run/reboot-required.

שלב 4: אימות תקינות

אל תחכו יום שלם כדי לגלות אם המשימה רצה. הריצו הרצה יבשה (dry run) שמציגה בדיוק מה יוחל, מבלי לשנות דבר:

sudo unattended-upgrade --dry-run --debug

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

cat /var/log/unattended-upgrades/unattended-upgrades.log

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

הקשר רחב יותר

עדכונים אוטומטיים הם שכבה אחת של שרת מאובטח, אך לא הכל. הם מונעים מבאגים ידועים להישאר, אך אינם עוזרים בנוגע למי יכול להתחבר או מה חשוף. שלבו אותם עם אבטחת SSH מבוססת מפתחות בלבד כדי שהדלת הקדמית לא תהיה חשופה ל-brute-force, חומת אש מסוג UFW עם מדיניות ברירת מחדל של חסימה (deny) כך שרק מה שתבחרו יהיה נגיש, ו-משתמשי שירות ללא הרשאות מיוחדות כך שאפליקציה שנפרצה לא תוכל להשתלט על כל השרת. האפליקציות שאתם מארחים נושאות את ה-secrets שלהן מעבר לכל זה, לכן אם השרת מריץ כספת סיסמאות בניהול עצמי, מדריך אבטחת Vaultwarden יכסה את ה-admin token וקובץ הגיבוי ששום כמות של עדכוני apt לא תגן עליהם. עדכונים סוגרים את הפרצות שאתם מכירים; השכבות האחרות מגבילות את הנזק מאלו שאינכם מכירים.

FAQ

האם unattended-upgrades מחיל כל עדכון או רק עדכוני אבטחה?

כברירת מחדל, רק עדכוני אבטחה. בלוק ה-Allowed-Origins ב-/etc/apt/apt.conf.d/50unattended-upgrades מאפשר את המקורות של -security ומשאיר עדכוני תכונות רגילים להחלה ידנית. זה נעשה במכוון: תיקוני אבטחה הם בעלי סיכון נמוך וראויים להחלה אוטומטית, בעוד ששדרוגי תכונות עלולים לשנות התנהגות, לכן רוב השרתים צריכים לשמור על ברירת המחדל השמרנית.

האם עדכונים אוטומטיים יאתחלו את השרת שלי?

רק אם תורו להם לעשות זאת. הגדירו את Unattended-Upgrade::Automatic-Reboot "true" ואת ה-Automatic-Reboot-Time בקובץ התצורה, והשרת יאותחל בשעה המוגדרת כאשר עדכון דורש זאת, למשל לאחר עדכון ליבה. אם האפשרות כבויה, ליבה מעודכנת תמתין עד שתבצעו אתחול בעצמכם; בדקו את /var/run/reboot-required כדי לדעת מתי עדכון כזה ממתין.

כיצד אוכל לבדוק שעדכונים אוטומטיים אכן רצים?

הריצו את sudo unattended-upgrade --dry-run --debug כדי לראות מה יוחל כרגע, מבלי לשנות דבר, וקראו את /var/log/unattended-upgrades/unattended-upgrades.log עבור תיעוד הרצות קודמות; כל התקנה אוטומטית נרשמת גם ב-/var/log/apt/history.log. אם הלוג מציג חבילות אבטחה שמותקנות בלוח זמנים יומי, ה-timer עובד. אם ההרצה היבשה מדפיסה No packages found that can be upgraded unattended, או שהכל כבר מעודכן או שהמקורות המורשים שלכם מצומצמים מדי מכדי להתאים למאגר האבטחה.

האם unattended-upgrades מספיק כדי לשמור על השרת שלי מאובטח?

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