מה לעשות אם שרת ה-VPS נפרץ? מדריך פעולה

אל תנסו לנקות שרת VPS שנפרץ

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

לא ניתן להוכיח ש-rootkit הוסר, כיוון שהכלים שבאמצעותם תנסו להוכיח זאת הם הכלים שהתוקף שולט בהם.

זהו תמצית הטיעון. להלן המנגנון העומד מאחוריו. תוקף שהשיג הרשאות root יכול להחליף את ps כך שמזהה תהליך (PID) מסוים לעולם לא יופיע בפלט. שורה אחת ב-/etc/ld.so.preload טוענת קוד זדוני לכל תוכנית המקושרת דינמית במערכת, כך ש-ls, ss ו-find כולם משקרים באותה צורה עקבית. מודול ליבה (kernel module) שניתן לטעינה יכול להסתיר קבצים ברמת קריאת המערכת (system call), כך שאפילו קובץ בינארי שהורד זה עתה יציג דיסק נקי. אתם מוחקים את תוכנת הכרייה, גרף ה-CPU יורד, והשרת משתתק. שקט הוא גם המראה של דלת אחורית (backdoor) פעילה.

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

אימות של פריצה בפועל

שרתים רבים מדווחים כפרוצים ללא הצדקה. אלפי ניסיונות התחברות כושלים ב-SSH מדי יום הם רעשי רקע של האינטרנט, שכן כל כתובת IPv4 ציבורית נסרקת ללא הרף. פלט של lastb המלא בניסיונות root ו-admin מעיד רק על כך שהסורקים מצאו את הפורט שלכם. אין בכך כדי להעיד שמישהו הצליח להיכנס.

סימנים אלו, לעומת זאת, מחייבים התייחסות:

• התחברות מוצלחת שאינכם יכולים להסביר, כגון Accepted password for root from 203.0.113.7.
• מפתח ב-authorized_keys שלא הוספתם בעצמכם.
• הודעת ניצול לרעה (abuse) מהספק שלכם בנוגע לתעבורה שיוצאת מהשרת.
• תהליך הצורך 100% מה-CPU ונושא שם המועתק מתהליך ליבה (kernel thread). כורי מטבעות שהוחדרו דרך שקעי Redis או Docker חשופים מדווחים לעיתים קרובות תחת שמות כמו kdevtmpfsi ו-kinsing.
• חיבורים יוצאים לכתובות שאף אחד מהשירותים שלכם אינו משתמש בהן.

לתחפושת של תהליך ליבה יש בדיקה מהירה. תהליכי ליבה אמיתיים מודפסים בתוך סוגריים מרובעים ואין מאחוריהם קובץ הרצה, לכן sudo ls -l /proc/<pid>/exe נכשל עבורם עם No such file or directory. אם תהליך שמוצג כ-[kworker/0:2] כולל קישור exe המצביע על נתיב תחת /tmp, מדובר בתוכנית משתמש רגילה המתחזה לשם של תהליך ליבה.

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

נתקו את הרשת ברמת ספק התשתית, לא מתוך השרת

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

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

ישנן שתי סיבות לא לבצע זאת מתוך השרת. firewall שאתם מגדירים בתוך kernel שנפרץ נאכף על ידי אותו ה-kernel, ומשתמש root יכול לרוקן את ה-nftables באותה קלות שבה אתם כותבים אותם. בנוסף, sudo ip link set enp1s0 down דרך SSH ינתק קודם כל את הסשן שלכם, מה שינעל אתכם מחוץ למכונה שאתם נמצאים באמצע תחקור שלה.

חסמו תעבורה יוצאת בדיוק כפי שאתם חוסמים נכנסת. reverse shell מתקשר החוצה מהשרת שלכם אל התוקף, לכן חסימה של תעבורה נכנסת בלבד תשאיר חיבור קיים פעיל לחלוטין. אם הספק שלכם מציע חוקי כניסה בלבד, האפשרויות הנותרות הן ניתוק ממשק הרשת או כיבוי ה-instance.

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

בצעו Snapshot לדיסק לפני שתגעו בדבר מה

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

בצעו את ה-Snapshot מתוך לוח הבקרה של הספק לפני שתתחברו שוב לשרת. Snapshot חי הוא crash consistent: הוא מתעד את הדיסק כפי שהיה באותו רגע, בדיוק כמו ניתוק פתאומי של החשמל. זה תקין עבור צורכי ראיות. תנו לו שם שימנע מאחרים לשחזר אותו בטעות. שם ישיר כמו COMPROMISED-do-not-restore-2026-08-12 הוא רמת העדינות המתאימה. שמרו אותו עד לסיום החקירה ועד שכל פנייה בנושא abuse מול ספק האירוח שלכם תיסגר.

כיצד להיכנס למערכת כאשר הגישה ב-SSH אבדה

קיימות שתי דרכים, שתיהן זמינות בלוח הבקרה של ספק הענן. ה-web console (באמצעות VNC או חיבור טורי) מתחבר למכונה כאילו חיברתם אליה מקלדת פיזית. הוא פועל כאשר שירות ה-sshd מושבת, כאשר ה-firewall מוגדר בצורה שגויה, או כאשר תוקף שינה את פורט ה-SSH. החיבור דורש סיסמה מקומית, לכן בשרת המוגדר לעבודה עם מפתחות בלבד, ייתכן שיהיה צורך באיפוס סיסמת ה-root לפני שהקונסולה תהיה שימושית.

מצב Rescue הוא האפשרות העדיפה. הוא מפעיל מערכת live קטנה כאשר הדיסק שלכם מחובר אך אינו פעיל, כך שהפקודות שלכם מהימנות: ה-kernel הפרוץ והקבצים הבינאריים הנגועים אינם רצים. יש לבצע mount לדיסק במצב קריאה בלבד (read-only).

lsblk -f
sudo mkdir -p /mnt/victim
sudo mount -o ro /dev/vda1 /mnt/victim

אם lsblk מציג כרכי LVM (logical volume manager) במקום מחיצה רגילה, יש להפעיל אותם תחילה באמצעות sudo vgchange -ay, ורק לאחר מכן לבצע mount להתקן שמופיע תחת /dev/mapper/.

אל תבצעו chroot לתוך הדיסק שביצעתם לו mount כדי לסייר בו. פעולת chroot מריצה את הקבצים הבינאריים של התוקף בהרשאות שלכם, ובכך מבטלת את כל הסיבה שבגללה הפעלתם את מצב ה-rescue.

איסוף ראיות שעדיין ניתן לסמוך עליהן

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

sudo grep -aE 'Accepted (password|publickey)' /mnt/victim/var/log/auth.log
sudo last -f /mnt/victim/var/log/wtmp
sudo lastb -f /mnt/victim/var/log/btmp
sudo journalctl -D /mnt/victim/var/log/journal -u ssh --since "2026-07-01"

היעדרות של /var/log/auth.log אינה חשודה כשלעצמה. חלק מהפצות Ubuntu המודרניות מגיעות ללא rsyslog, ולכן sshd מתעד ל-journal בלבד, וזה מה ששורת ה-journalctl -D קוראת. מה שראוי לציון הוא פער ביומנים שצריכים להיות רציפים, או קובץ יומן שקוצץ לאפס בתים. מחיקת יומנים היא פעולה נפוצה ובדרך כלל מבוצעת בצורה מרושלת.

לאחר מכן, בדקו את החשבונות ואת המפתחות.

sudo find /mnt/victim/root /mnt/victim/home -name 'authorized_keys*' -exec ls -l {} +
sudo awk -F: '$3 == 0 {print $1}' /mnt/victim/etc/passwd
sudo lsattr /mnt/victim/root/.ssh/authorized_keys

שורת ה-awk מדפיסה כל חשבון עם מזהה משתמש (UID) 0. כל ערך שאינו root בפלט זה הוא חשבון root נוסף. התבנית find תואמת במכוון גם ל-authorized_keys2, כיוון ש-OpenSSH קורא את שני שמות הקבצים כברירת מחדל, והשני קל מאוד לפספוס. אם lsattr מדפיס i ברשימת המאפיינים, הקובץ הוא immutable (בלתי ניתן לשינוי): תוקף מגדיר דגל זה כדי שהניסיון שלכם למחוק את המפתח שלו ייכשל עם Operation not permitted, ומנהל מערכת עייף עלול להניח בטעות שהעריכה הצליחה.

עקבות של נוכחות מתמשכת (persistence) מסתתרים במספר מצומצם של מקומות, לכן בדקו את כולם.

sudo ls -lt /mnt/victim/etc/systemd/system
sudo ls -l /mnt/victim/etc/cron.d /mnt/victim/var/spool/cron/crontabs
sudo cat /mnt/victim/etc/ld.so.preload
sudo grep -rnE 'curl|wget|base64|/dev/tcp' /mnt/victim/etc/update-motd.d /mnt/victim/etc/rc.local /mnt/victim/root/.bashrc /mnt/victim/root/.profile

/etc/ld.so.preload אינו קיים במערכת Ubuntu או Debian סטנדרטית, לכן No such file or directory הוא התוצאה התקינה, וכל תוכן אחר ראוי לתשומת לבכם. קובץ התחברות שמזרים פלט של base64 -d לתוך shell הוא באותו הקשר: תצורה לגיטימית אינה צריכה להסתיר את הטקסט של עצמה.

בנו את ציר הזמן לפי זמן שינוי (change time) ולא לפי זמן עריכה (modification time).

sudo find /mnt/victim -xdev -newerct '2026-08-01' -type f -printf '%TF %TT %p\n' | sort

touch מגדיר את זמן העריכה לכל ערך שהתוקף בוחר, לכן mtime הוא שקר זול. זמן השינוי (ctime) מתעדכן בכל שינוי ב-inode, ו-touch אינו יכול להזיז אותו אחורה, לכן -newerct מספק רשימה אמינה יותר של מה שנכתב לאחרונה. זו עדיין אינה הוכחה מוחלטת, כיוון ש-root יכול להזיז את שעון המערכת או לכתוב ישירות להתקן הבלוק.

שלמות החבילות שווה פקודה אחת ואזהרה אחת. במערכת חיה, sudo dpkg --verify מדפיס שורה עבור כל קובץ מחבילה שסכום הביקורת שלו כבר אינו תואם, עם 5 בעמודת סכום הביקורת, ו-sudo debsums -ac מבצע את אותה עבודה כולל קובצי תצורה כאשר חבילת debsums מותקנת. קראו את התוצאות בכיוון אחד בלבד. /usr/sbin/sshd שונה הוא ראיה ממשית. דוח נקי אינו מוכיח דבר, כיוון שאותו חשבון root שהחליף את הקובץ הבינארי יכול לשכתב את רשימות סכומי הביקורת תחת /var/lib/dpkg/info/. סורקי rootkit כגון rkhunter ו-chkrootkit פועלים לפי אותו כלל: ממצא הוא מידע, הרצה נקייה אינה אישור תקינות.

העתיקו את מה שאספתם מחוץ למכונה לפני שתבצעו פעולה הרסנית כלשהי.

sudo tar --ignore-failed-read -C /mnt/victim -czf /root/evidence-2026-08-12.tgz \
  var/log etc root/.ssh root/.bash_history home
sha256sum /root/evidence-2026-08-12.tgz

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

איתור נקודת הכניסה

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

התחברות בסיסמה ל-SSH. שורת Accepted password for root מכתובת שאינכם מזהים היא התשובה לכך. בדקו את PasswordAuthentication בתוך /etc/ssh/sshd_config ובכל קובץ תחת /etc/ssh/sshd_config.d/. השירות sshd משתמש בערך הראשון שהוא מוצא עבור כל הגדרה, והשורה Include מופיעה בראש הקובץ הראשי ב-Ubuntu, לכן קובץ תצורה שהוסף לתיקייה יגבר בשקט על ההגדרה ששיניתם בהמשך הקובץ.

שירות שפורסם ללא אימות. Redis בפורט 6379, ה-Docker API בפורט 2375, או מסד נתונים שמאזין ל-0.0.0.0 במקום ל-127.0.0.1. Docker הוא הגורם המפתיע הנפוץ ביותר. פרסום פורט של מכולה מוסיף חוקי DNAT (תרגום כתובות רשת ליעד) שמוערכים לפני השרשראות של ufw, לכן ufw status עשוי לדווח על פורט כחסום בזמן שהמכולה שמאחוריו משיבה לכל האינטרנט. הבינו זאת לפני הבנייה מחדש: מדוע פורטים שפורסמו על ידי Docker עוקפים את ufw מסביר את סדר החוקים ואת התיקון.

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

דליפת פרטי הזדהות. מפתח שהועלה למאגר קוד, אסימון (token) שהודבק בצ'אט, או קובץ .env שמוגש כקובץ סטטי על ידי שרת אינטרנט שהוגדר בצורה שגויה. אוטומציה הופכת טעויות כאלו לקלות לביצוע, וזו הסיבה ל-שמירה על סודות מחוץ לסוכני AI וקובצי התצורה שלהם.

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

החלפת כל פרטי הגישה שהיו חשופים לשרת

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

• כל מפתח SSH פרטי שאוחסן בשרת, וכן כל חשבון במקום אחר שנתן אמון במפתח הציבורי התואם.
• כל מפתח שהעברתם לתוך המכונה באמצעות ssh -A. העברת סוכן (agent forwarding) משאירה socket תחת /tmp, ומשתמש root במכונה זו יכול להשתמש בו כדי לבצע אימות בשמכם בכל מקום שבו המפתח שלכם מקובל, כל עוד הסשן שלכם פתוח.
• אסימוני API בקובצי .env, בשורות Environment= של systemd, בתצורות CI ובפרטי גישה של ספקים.
• סיסמאות מסדי נתונים, וחשבונות היישומים המשתמשים בהן.
• מפתחות פרטיים של TLS (transport layer security) שהיו בשרת. הנפיקו מחדש את התעודה ובטלו את הישנה.
• סיסמת חשבון האחסון שלכם, עם אימות דו-שלבי פעיל. לוח הבקרה הזה יכול לבנות מחדש, לבצע snapshot ולהתחבר לכל שרת שבבעלותכם, לכן הוא מהווה את היקף האבטחה האמיתי.
• כל סיסמה שהוקלדה בתוך סשן shell במארח זה בזמן שהיה פרוץ, כיוון שמשתמש root יכול להקליט סשן טרמינל בזמן אמת.

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

רשימת תיוג לבנייה מחדש

1. צרו שרת חדש מתוך image נקי של ההפצה. אל תשתמשו ב-snapshot של השרת שנפרץ, ואל תשחזרו את כל מערכת הקבצים של ה-root.
2. התקינו חבילות מתוך מאגרי ההפצה הרשמיים. לעולם אל תעתיקו קובץ binary מהדיסק הישן.
3. שחזרו נתונים בלבד, מתוך גיבוי שנוצר לפני העדות המוקדמת ביותר בציר הזמן שלכם. השתמשו ב-dumps של מסדי נתונים, קובצי uploads ומצב היישום. השאירו מאחור את /etc, /usr ואת קובצי ה-unit הישנים.
4. הזינו את ה-secrets שהוחלפו ידנית. אל תעתיקו את ה-.env הישן.
5. בדקו את תוכן האתר המשוחזר כדי לוודא שלא נוספו קבצים במהלך חלון זמן הפריצה, לפני שתגישו אותו שוב.
6. הקשיחו את השרת לפני חשיפתו לאינטרנט: השתמשו ב-SSH עם מפתחות בלבד, חשבון משתמש שאינו root לעבודה שוטפת, חומת אש עם מדיניות default-deny, ואל תחשפו שירותים מעבר לנדרש. עברו על עשר הדקות הראשונות ב-VPS חדש, לאחר מכן הקשיחו את ה-SSH כראוי, והוסיפו fail2ban ב-Ubuntu 24.04 כדי לצמצם רעשי התחברות. העניקו לכל שירות חשבון בעל הרשאות מינימליות כדי שהנקודה הבאה שתיפרץ לא תעניק גישת root.
7. כבו את השרת הישן ושמרו את ה-snapshot שלו עד לסיום החקירה וסגירת כל פנייה בנושא ניצול לרעה.
8. תקנו את הגיבויים. אם שלב 3 התבסס על ניחושים, הלקח האמיתי הוא שהיסטוריית הגיבויים שלכם הייתה קצרה מדי ולא הגיעה לתקופה שלפני הפריצה. גיבויים מחוץ לשרת עם גרסאות ושמירה לטווח ארוך הם מה שיבטיח נקודת שחזור נקייה בפעם הבאה: גיבויי restic ב-VPS מספקים לכם את שניהם.

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

מה משמעות הודעת ניצול לרעה (abuse notice) מהספק שלכם

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

השיבו לפנייה, גם אם התשובה היחידה שלכם היא שהשרת מבודד ונמצא בתהליך הקמה מחדש. ספקים מבצעים null-route או משעים שרת כאשר פנייה נותרת ללא מענה, מה שהופך את האירוע להשבתה מלאה. לאחר מכן, בקשו את שורות הלוג הגולמיות שעומדות בבסיס הדיווח. חותמות זמן אלו תועדו מחוץ למכונה שלכם, ולכן הן החלק היחיד בציר הזמן שהתוקף לא יכול היה לערוך; הן לרוב מתארכות את הפריצה בצורה מדויקת יותר מכל דבר אחר על הדיסק.

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

מתי לפנות לאיש מקצוע

• השרת הכיל מידע אישי השייך לאנשים אחרים. על פי ה-GDPR (תקנת הגנת המידע הכללית), יש לדווח על פרצת מידע אישי לרשות המפקחת ללא דיחוי בלתי סביר, ובתוך 72 שעות מרגע היוודע הדבר, במידת האפשר. הערכה האם מניין הזמן הזה החל היא עבודה משפטית, לא עבודת סיסאדמין.
• נתוני כרטיסי תשלום היו בטווח החשיפה. חברות כרטיסי האשראי דורשות חוקר פורנזי מאושר, וניסיונות שלכם לבדוק את הנושא עלולים לפגוע בחקירה.
• קיימת דרישת כופר, או שהנתונים שלכם הוצפנו.
• המכונה יכלה להגיע למכונות אחרות: רשת פנימית, hypervisor, או CI runner שמחזיק הרשאות גישה לסביבת הייצור. מארח אחד שנפרץ בקבוצה נחשב לאירוע רוחבי בכל הקבוצה עד שיוכח אחרת.
• אתם תזדקקו לראיות כדי להציגן בפני חברת הביטוח או רשויות אכיפת החוק. עצרו בשלב ה-snapshot, בצעו image מלא לכונן, ותעדו מי טיפל בו ומתי.

עבור VPS בודד שמריץ שירותים אישיים שלכם, ללא מידע של אחרים עליו, המדריך לעיל הוא כל העבודה הנדרשת. בצעו בידוד דרך ספק הענן. בצעו snapshot לצורכי ראיות. אספו את מה שעדיין נחשב אמין. בצעו סבב החלפת הרשאות (rotate) לכל הנתונים. בנו את השרת מחדש בצורה נקייה.

FAQ

האם ניתן לנקות שרת VPS שנפרץ במקום להקים אותו מחדש?

לא בביטחון מלא, כיוון שאתה מסתמך על מערכת פרוצה שתדווח על עצמה. קובץ ps שהוחלף יכול להסתיר תהליך, שורה בתוך /etc/ld.so.preload יכולה להזריק קוד לכל כלי המקושר דינמית שאתה מריץ, ומודול kernel יכול להסתיר קבצים מכל תוכנית בו-זמנית. אתה יכול למצוא ממצאים, כך שתוצאה חיובית היא משמעותית. אינך יכול להוכיח היעדר ממצאים, לכן תוצאה "נקייה" אינה אמינה. ניקוי הוא אפשרות סבירה רק אם השרת אינו מכיל מידע שחשוב לך, ואתה מקבל את העובדה שהוא עלול להיפרץ שוב.

האם עלי לכבות שרת שנפרץ או להשאיר אותו פועל?

נתק תחילה את הגישה לרשת דרך ספק השרתים, ולאחר מכן השאר אותו פועל מספיק זמן כדי לבצע snapshot ולבחון את התהליכים הרצים. כיבוי השרת משמיד את רשימת התהליכים ומוחק את ה-journal לחלוטין כאשר /var/log/journal אינו קיים, כיוון ש-journald כותב במקרה כזה לזיכרון תחת /run. כבה אותו בכל זאת אם הוא תוקף באופן פעיל רשתות אחרות ואין לך דרך לחסום את התעבורה היוצאת שלו. עצירת הנזק קודמת לשמירה על ראיות.

כיצד אוכל לגלות מתי התוקף חדר למערכת?

חפש את השורה המוקדמת ביותר ב-Accepted password או ב-Accepted publickey שאינך יכול להסביר, בתוך /var/log/auth.log או ב-journal. הצלב אותה עם רשימת זמני שינוי באמצעות find / -xdev -newerct 'YYYY-MM-DD' -type f, כיוון ש-ctime קשה יותר לזיוף מאשר mtime. לאחר מכן, השווה את שניהם מול חותמות הזמן בהודעת ה-abuse שקיבלת מהספק, אשר תועדו מחוץ למכונה ולא ניתן לערוך אותן. בחר גיבוי ישן יותר מהתאריך המוקדם ביותר מבין השלושה. אם דבר אינו מסתדר, הנח שהפריצה ישנה יותר מהיסטוריית הגיבויים שלך ושחזר רק נתונים שאתה יכול לבדוק.

האם הגיבויים שלי בטוחים לשחזור לאחר פריצה?

הנתונים בדרך כלל בטוחים, בכפוף לבדיקה. קובצי המערכת אינם בטוחים. גיבוי שנלקח לאחר החדירה מכיל את ה-backdoor, לכן שחזור מלא של מערכת הקבצים root ישחזר גם את התוקף. בדוק גם את מאגר הגיבויים עצמו: אם פרטי הגישה אליו היו מאוחסנים על השרת שנפרץ, ייתכן שההיסטוריה נמחקה או שונתה; זו הסיבה להשתמש ביעדי גיבוי מסוג append-only או מבוססי משיכה (pull-based). שחזר נתוני יישומים בלבד, ולאחר מכן התקן את התוכנה מחדש ממאגרי ההפצה.

האם עלי לדווח למישהו שה-VPS שלי נפרץ?

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