האתר נפרץ — מה עושים, בסדר הנכון

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

שלב 1 — לעצור את הדימום (15 הדקות הראשונות)

1. העבירו את האתר למצב תחזוקה או החזירו דף סטטי. אתר פרוץ שממשיך לרוץ יכול לפגוע במבקרים ולהיכנס לרשימות שחורות של גוגל.
2. אל תמחקו כלום עדיין. צרו עותק מלא של המצב הנוכחי — קבצים ומסד נתונים — ושמרו אותו בנפרד. זה החומר שיאפשר להבין איך נכנסו.
3. החליפו סיסמאות בסדר הזה: חשבון האחסון, SSH/FTP, מסד הנתונים, ואז משתמשי WordPress.
4. נתקו אינטגרציות רגישות זמנית — סליקה, ספק דיוור, וובהוקים.

שלב 2 — להבין את היקף הפגיעה

לפני שמנקים, כדאי לדעת מה נגעו בו. שלוש בדיקות נותנות תמונה מהירה:

• השוואת קבצי הליבה מול הגרסה הרשמית — כל שינוי בליבה הוא דגל אדום מיידי.
• חיפוש קבצי PHP בתיקיות שאמורות להכיל רק מדיה (wp-content/uploads).
• רשימת משתמשי מנהל, ותאריך היצירה שלהם.

wp core verify-checksums
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
find wp-content/uploads -name '*.php'

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

שלב 3 — לשחזר, לא לנקות

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

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

שלב 4 — להחליף כל סוד, בלי יוצא מן הכלל

אם התוקף הגיע לקבצים, הוא קרא את wp-config.php. משמע: פרטי מסד הנתונים ומפתחות ההצפנה של העוגיות בידיו.

• החליפו את מפתחות האבטחה (SALT) — זה מנתק כל מי שמחובר, כולל התוקף.
• החליפו סיסמת מסד נתונים ועדכנו אותה בקובץ ההגדרות.
• בטלו מפתחות API של שירותים חיצוניים שהופיעו בקוד.
• אפסו סיסמאות לכל המשתמשים והפעילו אימות דו-שלבי למנהלים.

שלב 5 — לנקות את התוצאות החיצוניות

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

• בקשו בדיקה חוזרת בכלי למנהלי אתרים של גוגל אם הוצג אזהרה.
• בדקו אם ה-IP של השרת נכנס לרשימות שחורות בגלל דואר זבל שנשלח ממנו.
• ודאו שאין הפניות שנשארו בקובץ .htaccess או ברמת השרת.
• בדקו שהאתר לא מגיש תוכן שונה לגוגל מאשר למבקר רגיל.

שלב 6 — לסגור את הפער שגרם לזה

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

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

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