להשיג גישה זו חצי מהעבודה; החצי השני הוא לא לאבד אותה. לכן כמעט כל התוכנות הזדוניות האוטומטיות דואגות קודם כול להפעלה חוזרת של עצמן: אחרי אתחול, אחרי מחיקת הקובץ, אחרי החלפת סיסמה. ומכאן הסיפור המוכר — «ניקינו וכעבור יומיים זה חזר».

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

1. מפתחות SSH

הדרך הפשוטה ביותר לחזור: שורה ב-authorized_keys שורדת החלפת סיסמה, עדכון מערכת ואתחול.

sudo find /home /root -name authorized_keys -exec ls -l {} \; -exec cat {} \;

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

2. משימות cron של כל המשתמשים

לא רק ה-crontab שלכם עצמכם דורש בדיקה:

for u in $(cut -f1 -d: /etc/passwd); do echo "== $u"; sudo crontab -u "$u" -l 2>/dev/null; done
sudo ls -la /etc/cron.d/ /etc/cron.hourly/ /etc/cron.daily/
sudo cat /etc/crontab

סימנים ששווה לחפש: שורות @reboot, פקודות מקודדות ארוכות, קריאות curl או wget שמוזרמות למעטפת, וכל דבר שמופעל מ-/tmp, מ-/dev/shm או מ-/var/tmp. שום דבר סטנדרטי אינו רץ מהתיקיות האלה.

3. טיימרים ושירותים של systemd

המקבילה המודרנית ל-cron, ונבדקת לעיתים רחוקות בהרבה:

systemctl list-timers --all
systemctl list-units --type=service --state=running
sudo ls -la /etc/systemd/system/ /run/systemd/system/

ובנפרד, שירותי משתמש, שרצים בלי הרשאות root ואינם מופיעים ברשימה הכללית:

systemctl --user list-units --type=service
sudo ls -la /home/*/.config/systemd/user/

ופרט נוסף: lingering שהופעל למשתמש (loginctl enable-linger) מאפשר לשירותים שלו לרוץ בלי הפעלה פעילה. בדקו את זה עם loginctl list-users.

4. קובצי אתחול של המעטפת

קוד שנוסף לסוף קובץ אתחול של המעטפת רץ בכל כניסה:

sudo tail -5 /root/.bashrc /root/.profile /home/*/.bashrc /home/*/.profile
sudo ls -la /etc/profile.d/

הביטו דווקא בסוף הקובץ — לשם מוסיפים כדי שלא ייתפס במבט חטוף.

5. ld.so.preload

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

ls -l /etc/ld.so.preload

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

6. ווים של מנהל החבילות

שיטה שנזכרים בה לעיתים רחוקות: apt יכול להריץ פקודות לפני ואחרי כל פעולה על חבילות.

sudo ls -la /etc/apt/apt.conf.d/
sudo grep -r 'DPkg::Pre-Invoke\|DPkg::Post-Invoke\|APT::Update' /etc/apt/apt.conf.d/

וו כזה מופעל בכל התקנת עדכון — כלומר באופן סדיר וכ-root.

7. הודעת היום ב-Ubuntu

התיקייה /etc/update-motd.d/ מכילה סקריפטים ניתנים להרצה שרצים בכל כניסת SSH ומרכיבים את טקסט הפתיחה. והמקום נוח דווקא משום שהוא נראה כחלק מהמערכת:

sudo ls -la /etc/update-motd.d/

8. משימות at דחויות

sudo atq
sudo ls -la /var/spool/cron/atjobs/ 2>/dev/null

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

מה לעשות אם מצאתם משהו

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

  1. שמרו עותק של הקובץ או המשימה ואת שעת השינוי שלה.
  2. בעזרת אותה שעה הביטו ביומני שרת האתר וב-auth.log מה קרה באותה דקה. שם נמצאת בדרך כלל נקודת הכניסה.
  3. בדקו את כל שמונת המקומות ברשימה, ולא רק את זה שבו נמצא משהו. דלת אחורית כמעט אף פעם אינה מושארת בעותק אחד.
  4. ורק אחר כך נקו וסגרו את הפרצה עצמה.

לדעת איך נראה המצב התקין

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

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