האתר שלכם נפרץ? המדריך המעשי: מה עושים, שלב אחרי שלב

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

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

איך יודעים שהאתר שלכם באמת נפרץ (ולא רק תקול)

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

• אזהרה מגוגל בתוצאות החיפוש או ב-Chrome ("האתר הזה עשוי להזיק למחשב שלך").
• עמודים או קישורים זרים שלא יצרתם – לרוב תוכן זבל (ספאם) לקידום מוצרים מפוקפקים.
• הפניה אוטומטית מהאתר שלכם לאתר אחר, לפעמים רק מהנייד או רק מגוגל.
• חשבון מנהל שלא יצרתם, או חשבון קיים שמשנה הרשאות בלי שביקשתם.
• קבצים חדשים שלא הועלו על ידכם, בעיקר בתיקיות wp-content/uploads או בתיקיית הליבה.
• מייל מחברת האחסון שמדווח על קובץ נגוע, שימוש חריג במשאבים, או חסימת האתר.

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

15 הדקות הראשונות: מה עושים מיד

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

פנייה לחברת האחסון

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

צמצום החשיפה של האתר

אם אפשר, הגבילו את הגישה לאתר ברמת האחסון, או בקשו מחברת האחסון לעשות זאת. מצב תחזוקה (maintenance mode) יכול למנוע ממבקרים רגילים להגיע לתוכן, אבל הוא לא בהכרח עוצר קוד זדוני שכבר פועל באתר – וורדפרס והקוד הפרוץ עדיין יכולים לרוץ מתחת למסך התחזוקה. אם מדובר בחנות ווקומרס עם הזמנות פעילות, כדאי לשקול גם השבתה זמנית של התשלום עד שתבינו את היקף הפריצה – גם כשהסליקה עצמה מתבצעת אצל ספק חיצוני, אתר פרוץ עלול לשנות את תהליך התשלום או להפנות לקוחות למקום אחר.

החלפת סיסמאות גישה

החליפו את סיסמאות הגישה החשובות, במיוחד חשבונות מנהל, האחסון ו-SFTP, ובטלו חיבורים פעילים. אם אתם משנים את סיסמת מסד הנתונים, צריך לעדכן בהתאם גם את wp-config.php – אחרת האתר יפסיק להתחבר למסד הנתונים. בוורדפרס אפשר גם להחליף את מפתחות האבטחה (salts) ב-wp-config.php, וכך לנתק באופן מיידי משתמשים שכבר מחוברים – זו פעולה שוורדפרס עצמו ממליץ עליה.

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

חשוב לזכור: אם עדיין קיים באתר קוד זדוני או דלת אחורית (backdoor), החלפת הסיסמאות בשלב הזה לא בהכרח "סוגרת" את הפרצה – כדאי להחליף את הסיסמאות שוב אחרי שהניקוי הושלם, והפעילו אימות דו-שלבי (2FA) בכניסה לוורדפרס אם עדיין אין לכם.

שחזור מגיבוי או ניקוי ידני? איך מחליטים

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

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

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

איך מנקים את האתר בפועל (כשאין גיבוי טוב)

אם החלטתם על ניקוי ידני, הנה שלושת האזורים שצריך לעבור עליהם בסדר הזה:

קבצי הליבה של וורדפרס

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

1. מה שסיפקה לכם חברת האחסון – אם ביקשתם מהם סריקה בשלב הקודם, ברוב המקרים הם כבר יגידו לכם בדיוק אילו קבצים שונו או סומנו כחשודים, בלי שתצטרכו לעשות את ההשוואה בעצמכם.
2. כלי שעושה את ההשוואה אוטומטית – Wordfence, למשל, יכול להשוות קבצי ליבה וקבצים של תוספים וערכות עיצוב מהמאגר הרשמי מול עותקים מוכרים. למי שנוח בשורת פקודה, wp core verify-checksums דרך WP-CLI משווה את קבצי הליבה מול ה-checksums הרשמיים של WordPress.org בפקודה אחת.

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

wp-content: תוספים, ערכת עיצוב וקבצים שהועלו

עברו על רשימת התוספים המותקנים – מחקו כל תוסף שאתם לא מזהים או לא משתמשים בו. עדכנו את כל השאר לגרסה האחרונה. בדקו את קבצי ערכת העיצוב (במיוחד functions.php) לקוד מוזר שהוזרק לתוכה. בדקו את תיקיית ה-uploads לקבצי PHP שלא אמורים להיות שם – תמונה אמיתית לא צריכה סיומת .php.

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

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

מסד הנתונים

חפשו בטבלת המשתמשים (wp_users, או שם דומה אם הוגדר לאתר prefix אחר מ-wp_) חשבונות מנהל שלא יצרתם. חפשו בטבלת האפשרויות (wp_options) והפוסטים קוד JavaScript מוזר שהוזרק לתוך שדות תוכן – זו שיטה נפוצה להסתרת קישורי ספאם. אם אתם לא בטוחים מה אתם מסתכלים עליו, זה בדיוק הרגע לעצור ולהיעזר במפתח – מסד הנתונים הוא לא מקום להתנסות.

אחרי הניקוי: איך מוודאים שהאתר באמת נקי

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

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

כדאי גם להריץ סריקה חיצונית שלא תלויה במה שמותקן באתר עצמו – אם האתר כבר נפרץ, אי אפשר לסמוך רק על כלים שרצים מתוכו. שני כלים חיצוניים וחינמיים לבדיקה מהירה: Sucuri SiteCheck (סורק URL חינמי בלי צורך בהתקנה) ו-Google Safe Browsing (בודק אם גוגל כבר סימן את האתר שלכם כמסוכן). אם אתם רוצים בדיקה נוספת, VirusTotal סורק כתובת URL מול עשרות מנועי אנטי-וירוס במקביל. חשוב לדעת: סריקה כזו לא יכולה להוכיח שהשרת נקי, כי היא רואה בעיקר את מה שנחשף מבחוץ – backdoor שלא "מציג" שום דבר כלפי חוץ עלול לא להתגלות בסריקה מרוחקת. אם Google Search Console עדיין מציג בעיית אבטחה אחרי הניקוי, הגישו בקשת בדיקה חוזרת דרך דוח Security Issues.

מתי כדאי לפנות למפתח או לחברת האחסון

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

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

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

איך מונעים את הפעם הבאה

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

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

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

רוצים שמישהו ידאג לאתר בשבילכם? ספרו לי עליו ואחזור עם הצעה.