הקדמה
פגיעות kernel חמורה מתפרסמת. PoC זמין. ניצול מתחיל תוך 48 שעות.
ואז מישהו אומר: "בסדר, נתזמן reboot לסוף השבוע."
עד סוף השבוע – ארבעה ימים. ארבעה ימים שבהם השרת חשוף, ידוע, עם exploit זמין לציבור.
זה היה המציאות של ניהול שרתי Linux עד לא מזמן. ו-live kernel patching שינה את זה.
הבעיה: הפער בין "יש patch" ל-"הpatch הותקן"
כשיוצא עדכון אבטחה לאפליקציה – WordPress plugin, nginx, PHP – ההתקנה היא עניין של דקות.
מפסיקים את התהליך, מחליפים את הקובץ, מפעילים מחדש. אפס downtime, אפס סיכון.
kernel Linux עובד אחרת.
הkernel הוא הבסיס שכל שאר המערכת רצה עליו –
הוא לא עוצר ומפעיל מחדש תוך כדי עבודה. עדכון kernel מחייב reboot מלא של השרת.
בסביבת shared hosting זה לא פשוט כמו שזה נשמע:
- כל אתר על השרת יורד לכמה דקות
- לקוחות עם SLA צריכים הודעה מראש
- תיאום עם צוותים, תזמון maintenance window, וידוא שהשרת קם כראוי
- על פני מאות שרתים – זה פרויקט לוגיסטי שלם
התוצאה הפרקטית: בארגונים רבים, עדכוני kernel נדחים. לא מתוך רשלנות –
מתוך מציאות תפעולית. ובמהלך הדחייה, הפגיעות פתוחה.
מה זה Live Kernel Patching?
Live kernel patching הוא מנגנון שמאפשר להחיל תיקוני אבטחה על קרנל Linux שרץ בזיכרון – בלי reboot.
הרעיון: במקום להחליף את kernel הדיסק ולהפעיל מחדש, הpatch מוזרק ישירות לזיכרון.
הkernel הרץ "מתעדכן" תוך כדי תנועה. האתרים על השרת לא מרגישים כלום.
אין downtime.
אין maintenance window.
הכלי שאנחנו עובדים איתו הוא KernelCare של TuxCare –
הוא תומך ב-CloudLinux, AlmaLinux, Ubuntu, Oracle Linux, ובמרבית ה-Distro שמרכיבים את הצי שלנו.
[למידע נוסף על SPD Kernel Shield] (https://www.spd.co.il/cyber-security/spd-kernel-shield)
איך זה עובד בפועל
הפשטות היא חלק מהיופי. על כל שרת שמותקן עליו KernelCare רץ agent קטן שבודק בצורה תקופתית אם יש patches חדשים.
כשיש – הוא מוריד את ה-patch ומחיל אותו על הkernel הרץ. ללא התערבות ידנית. ללא הפסקת שירות.
אפשר לאמת את הסטטוס בכל רגע:
kcarectl --infoהפלט מראה את גרסת הקרנל הבסיסית, אילו patches הוחלו מעליה, ומתי הם הוחלו. השרת לא עבר reboot – אבל הוא מוגן כאילו כן.
בזמן אמת: אך הגנו על הלקוחות עוד לפני פרסום החולשה Copy.Fail
כשפורסמה CVE-2026-31431 (Copy.Fail), חלק מהשרתים בפלט שלנו קיבלו את ה-patch דרך KernelCare תוך שעות –
עוד לפני שה-patched kernels הרשמיים יצאו לכל ה-Distro.
השרתים האלה לא נדרשו למיטיגציה ידנית (blacklist מודולים), לא חיכו ל-maintenance window, ולא היו חשופים לחלון הניצול.
ה-patch הוחל, vkernel ממשיך לרוץ, הלקוחות לא הרגישו כלום.
על השרתים שKernelCare לא כיסה – עבדנו עם מיטיגציות ידניות עד שה-patches הרשמיים יצאו, ואז ביצענו reboot מתוזמן.
זה עבד – אבל ראינו בצורה ברורה את ההבדל בין שני המסלולים.
מה Live Patching לא מחליף
חשוב להיות ברורים כאן – live kernel patching הוא כלי, לא קסם.
הוא מטפל בפגיעויות kernel בלבד. עדכוני אבטחה לאפליקציות, ספריות, ו-userspace packages עדיין מחייבים ניהול נפרד.
KernelCare לא מחליף yum update או apt upgrade.
reboot עדיין צריך לקרות – רק לא בדחיפות. Patches שמוחלים דרך live patching תקפים לkernel הרץ.
בפעם הבאה שהשרת יעלה מחדש (תחזוקה מתוזמנת, החלפת חומרה, upgrade מערכת),
הוא יעלה עם הkernel המעודכן מהדיסק. זה תקין ורצוי – רק לא דחוף.
לא כל patch ניתן להחיל live. שינויים מבניים עמוקים בkernel דורשים לפעמים reboot בכל זאת. אלה נדירים, אבל קיימים.
הלוגיסטיקה על צי של אלפי שרתים
לנהל patch policy על שרת אחד זה פשוט. על אלפי שרתים עם מגוון OS versions –
CloudLinux 7, 8, 9, 10, AlmaLinux 9, Ubuntu 20.04, 22.04, Oracle Linux – זה אתגר אחר לגמרי.
live patching מפשט את זה בצורה משמעותית: במקום לתאם maintenance windows לכל שרת בנפרד,
ה-patches מוחלים באופן שוטף ברקע. ה-"reboot backlog" – אותו צבר של שרתים שממתינים לתחזוקה כי "אין זמן טוב" – מצטמצם.
זה לא אומר שאנחנו לא עושים reboots. אנחנו כן – כחלק מתחזוקה מתוכננת. אבל הם לא עוד מירוץ נגד חלון ניצול פתוח.
אז מה זה אומר לכם?
אם האתר שלכם מתארח עלינו – live kernel patching הוא חלק מהתשתית שרצה מתחת. כשיוצאת פגיעות kernel,
אתם לא צריכים לחכות ל-maintenance window של סוף השבוע.
הטיפול קורה – לרוב – הרבה לפני שאתם בכלל שומעים על הפגיעות.
אם אתם מנהלים שרתים בעצמכם – live kernel patching הוא אחד הכלים שכדאי להכניס ל-stack.
לא בגלל שהוא מסיר את הצורך בניהול patches – אלא בגלל שהוא מסיר את התירוץ לא לטפל בהם מיד.
צוות SPD Hosting support@spd.co.il
