האתר נפרץ? מה עושים בשעה הראשונה ובימים שאחריה

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

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

סימנים לכך שהאתר נפרץ

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

סימן	מה זה אומר בדרך כלל	איפה בודקים
דף הבית הוחלף בהודעה או בדגל	השחתה (Defacement), למשל דרך תוסף פגיע או סיסמה שדלפה	בדפדפן, ובתאריך השינוי של קובצי התבנית
גולשים מנייד או מגוגל מועברים לאתר הימורים או ספאם	קוד הפניה ב-.htaccess, בקובצי PHP או במסד הנתונים	בדיקה עם curl ובקובצי ההגדרות
בגוגל מופיעה ההודעה "This site may be hacked"	גוגל זיהתה דפים שהשתנו או דפי ספאם חדשים	דוח בעיות האבטחה ב-Search Console
בתוצאות החיפוש יש דפים שלא יצרתם, בשפות זרות או עם מילים כמו הלוואות ותרופות	הזרקת דפי ספאם	חיפוש site: בגוגל
ספק האחסון השעה את החשבון בגלל נוזקה	סריקה בצד הספק מצאה קבצים זדוניים	הודעת הספק ופנייה לתמיכה
משתמשי ניהול שאינכם מכירים	לתוקף יש גישה קבועה	רשימת המשתמשים במערכת ניהול התוכן
הודעות דוא"ל שלא שלחתם, או החזרות על הודעות כאלה	השרת או תיבה משמשים לשליחת ספאם	תור הדואר היוצא ובדיקת רשימות שחורות

שני חיפושים מהירים בגוגל עוזרים להבין את ההיקף: site:example.co.il מציג מה גוגל מכירה באתר, ואם מוסיפים לו מילה כמו loans או viagra, רואים אם הוזרקו דפים כאלה. מרכז העזרה של Search Console ממליץ על חיפוש כזה. כלי בדיקת כתובות URL ב-Search Console מראה את הדף כפי שגוגל רואה אותו, גם כשהתוקף מסתיר אותו מכם.

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

curl -sIL -A "Mozilla/5.0 (Linux; Android 14; Mobile)" -e "google.com" example.co.il | grep -i -E "^(HTTP|location)"

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

השעה הראשונה: בולמים ושומרים ראיות

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

היום הראשון: מחליפים את כל הסיסמאות והמפתחות

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

• הכניסה לפאנל האחסון ולחשבון אצל רשם הדומיין.
• כל משתמשי הניהול במערכת ניהול התוכן. משתמש שאינכם מזהים מוחקים, אחרי שמתעדים אותו.
• חשבונות FTP ו-SFTP, ומפתחות SSH. מפתח ציבורי שאינכם מכירים בקובץ authorized_keys הוא סימן לגישה קבועה.
• הסיסמה של משתמש מסד הנתונים, ועדכון שלה בקובץ ההגדרות של האתר (wp-config.php בוורדפרס). באותה הזדמנות מחליפים גם את מפתחות ה-Salt.
• מפתחות API של שירותים חיצוניים: סליקה, שליחת דוא"ל, מפות, מערכות CRM.
• תיבות הדוא"ל שמוגדרות על הדומיין, במיוחד אם נשלח מהן ספאם.

בוורדפרס עם WP-CLI אפשר לראות את כל המנהלים בפקודה אחת:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

מוצאים את נקודת הכניסה

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

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

find /var/www/site -type f -name "*.php" -mtime -14 -ls

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

wp core verify-checksums
wp plugin list --update=available

והאחרונה סופרת את ניסיונות ההתחברות לפי כתובת IP ביומן של nginx:

grep "POST /wp-login.php" /var/log/nginx/access.log | cut -d' ' -f1 | sort | uniq -c | sort -rn | head

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

מנקים או משחזרים מגיבוי נקי

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

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

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

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

מעדכנים הכול ומחזירים את האתר לאוויר

לפני שמסירים את דף התחזוקה:

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

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

תעודת SSL אחרי פריצה

אם לתוקף הייתה גישה לשרת כולו, הוא יכול היה להעתיק את המפתח הפרטי של תעודת ה-SSL. במקרה כזה Let's Encrypt מגדירה לבטל את התעודה עם הסיבה keyCompromise ולהנפיק תעודה חדשה עם מפתח חדש:

certbot revoke --cert-path /etc/letsencrypt/live/example.co.il/cert.pem --key-path /etc/letsencrypt/live/example.co.il/privkey.pem --reason keyCompromise

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

בקשת בדיקה בגוגל Search Console

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

1. מאמתים בעלות על האתר ב-Search Console, אם לא עשיתם זאת קודם.
2. פותחים את דוח בעיות האבטחה (Security Issues) ומוודאים שכל כתובת לדוגמה שמופיעה שם תוקנה.
3. מוודאים שגוגל יכולה לסרוק את האתר: אין חסימה ב-robots.txt ואין noindex על הדפים.
4. לוחצים על Request Review וכותבים מה הייתה הבעיה, מה תיקנתם ומה התוצאה. למשל: "תוסף טפסים בגרסה ישנה אפשר העלאת קבצים. התוסף הוסר, קובצי ה-PHP בתיקיית ההעלאות נמחקו, כל הסיסמאות הוחלפו".

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

דוא"ל: רשימות שחורות ותור יוצא

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

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

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

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

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

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

שאלות נפוצות

איך יודעים בוודאות שהאתר נפרץ?

הסימנים הברורים הם הפניה לדומיין זר בבדיקת curl, דפי ספאם בחיפוש site:, משתמשי ניהול שאינכם מכירים, או הודעה בדוח בעיות האבטחה ב-Search Console. אתר איטי או שגיאת 500 בלבד אינם הוכחה לפריצה.

אפשר פשוט למחוק את הקבצים החשודים ולהמשיך?

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

כמה זמן לוקח לגוגל להסיר את האזהרה?

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

ספק האחסון השעה את החשבון. מה עושים?

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

מאיזה גיבוי לשחזר?

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

צריך לדווח לרשות להגנת הפרטיות על כל פריצה לאתר?

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

הגנה על השרתים והמחשבים שמנהלים את האתר

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