תוכן עניינים
נכנסתם לאתר שלכם ופתאום משהו לא נראה כמו שצריך. גולשים מועברים לאתר אחר, גוגל מציג אזהרת אבטחה, או שחברת האחסון שולחת מייל עם מילים כמו "קוד זדוני" ו"גישה חשודה".
התגובה הראשונה של רוב בעלי האתרים היא לנסות להחזיר את הכול לקדמותו כמה שיותר מהר. למחוק קובץ חשוד, לשחזר גיבוי, להתקין תוסף אבטחה ולקוות שזה נגמר.
אבל אם האתר באמת נפרץ, המטרה היא לא רק לגרום לו להיראות תקין. צריך לוודא שלמי שנכנס אין עדיין דרך לחזור. אחרת אתם עלולים לפתוח מחדש אתר שנראה נקי, בזמן שהבעיה נשארה מתחת לפני השטח.
במדריך הזה נעבור על סדר הפעולות שכדאי לבצע כשיש חשד לפריצה לאתר וורדפרס: איך מזהים מה קרה, מה עושים קודם, מתי משחזרים מגיבוי, איך מטפלים באזהרה של גוגל ומה בודקים לפני שחוזרים לקבל פניות והזמנות. חלק מהבדיקות דורשות גישה לשרת וניסיון טכני. אם אין לכם את הניסיון הזה, עדיף להיעזר באיש מקצוע ולא לנסות לנקות קוד לא מוכר לבד.
האתר נפרץ? סדר הפעולות ב-24 השעות הראשונות
אם יש חשד לפריצה, לא חייבים לקרוא את כל המדריך לפני שמתחילים. זה סדר הפעולות שכדאי להכיר:
- מיד עם גילוי הבעיה: מצמצמים חשיפה. אם גולשים נשלחים לעמוד מסוכן, אם יש חשש לדליפת מידע או אם הקופה בחנות נפגעה, פונים לאחסון ומגבילים את הפעילות שעלולה להזיק ללקוחות.
- בתחילת הטיפול: מתעדים ושומרים עותק. מרכזים התראות, צילומי מסך ולוגים זמינים, ומבקשים לשמור עותק מוגן של האתר במצבו הנוכחי לפני מחיקה או שחזור.
- לאחר בלימת החשיפה: מאתרים את דרך הכניסה. בודקים חשבונות והרשאות, קבצים ותוספים, ומחליטים אם נכון לנקות את האתר או לשחזר מגיבוי שנבדק.
- לפני שמחזירים לאוויר: בודקים שהכול באמת עובד. מוודאים שאין סימני פריצה, שהגישה נסגרה ושטפסים, הזמנות ותשלומים פועלים כראוי.
- בהמשך: ממשיכים לעקוב. בודקים התראות, גיבויים ו-Google Search Console, ומטפלים באזהרת אבטחה אם הופיעה.
חשוב: זה סדר עדיפויות ליום הראשון, לא התחייבות שהניקוי יסתיים בתוך 24 שעות. לפעמים צריך יותר זמן כדי לברר את היקף הפגיעה ולשחזר בצורה בטוחה.
האתר שלכם נפגע עכשיו? שלחו לי מה אתם רואים באתר ונבדוק מה נכון לעשות קודם. אל תשלחו סיסמאות או מידע אישי של לקוחות בטופס הפנייה. אם נדרש טיפול באירוע אבטחה מורכב, יש לערב איש מקצוע מתאים.
קודם כול: איך יודעים אם האתר באמת נפרץ?
לא כל אתר שנפל או מציג מסך לבן נפרץ. לפעמים מדובר בעדכון תוסף שנכשל, בתקלה באחסון או בשגיאת קוד. מצד שני, יש פריצות שלא משנות כמעט כלום בעיצוב האתר. לכן לא מספיק לפתוח את עמוד הבית ולהחליט שהכול בסדר.
אלה סימנים שמצדיקים בדיקה:
- הפניות מוזרות: גולש נכנס לאתר שלכם ומגיע לאתר הימורים, חנות לא קשורה או עמוד פרסומות. לפעמים ההפניה מופיעה רק בנייד או רק למי שמגיע מגוגל.
- תוכן שלא העליתם: עמודים בשפות זרות, קישורים חשודים, מוצרים שלא הכנסתם או הודעות שלא כתבתם.
- משתמש מנהל לא מוכר: מופיע חשבון עם הרשאות ניהול שאיש בעסק לא פתח.
- התראה מגוגל או מחברת האחסון: למשל הודעה על נוזקה, דיוג או פעילות חשודה בקבצי האתר.
- שינוי בהתנהגות האתר: הודעות דוא״ל נשלחות בלי ידיעתכם, קבצים משתנים ללא סיבה ברורה או שמתרחשת פעילות חריגה בשרת.
אפשר לבצע בדיקה ראשונית גם דרך Google Search Console, באזור "בעיות אבטחה", ולהקליד בגוגל site:yourdomain.co.il כדי לחפש עמודים שלא מזהים. אלה סימני אזהרה, לא בדיקה שמחליפה סריקה מקצועית; גם אתר שלא מופיעה לגביו אזהרה בגוגל יכול להיות פגוע.
האתר נפרץ: מה לעשות בחצי השעה הראשונה?
כשמגלים פריצה, יש שלושה דברים חשובים יותר מלסדר את העיצוב: לצמצם חשיפה, לשמור את המידע הדרוש לבדיקה ולערב את הגורם שיכול לעזור לטפל בשרת.
1. לתעד את מה שרואים, לפני שמתחילים לשנות
צלמו את השגיאה או ההפניה, שמרו את כתובת העמוד הבעייתי ורשמו מתי זיהיתם את הבעיה. אם התקבלה התראה במייל, שמרו אותה. אם מתגלה משתמש לא מוכר או שינוי חריג, תעדו גם אותו.
זה אולי נשמע כמו בירוקרטיה בזמן הלא נכון, אבל התיעוד עוזר להבין מתי התחילה התקלה, אילו חלקים הושפעו והאם היא חזרה אחרי הטיפול. בלי תיעוד, כל הבדיקה הופכת לניחושים.
אל תנסו לפתוח שוב ושוב עמודים חשודים כדי לראות אם הבעיה חוזרת. אם יש חשש לנוזקה, דיוג או הורדה זדונית, עדיף להסתמך על התראות וצילומי מסך שכבר קיימים ולבקש מאיש מקצוע לבדוק את האתר בסביבה מבודדת. אל תלחצו על קישורים חשודים ואל תורידו מהם קבצים לצורך הבדיקה.
2. ליצור עותק של האתר במצבו הנוכחי
לפני שמוחקים או משחזרים, כדאי לבקש מחברת האחסון או מאיש המקצוע לשמור עותק של קבצי האתר, מסד הנתונים והלוגים הזמינים. כן, גם אם העותק הזה כבר נגוע.
העותק הזה לא נועד להחזיר את האתר לפעילות. הוא נועד לשמר מידע לבדיקה ולאפשר חזרה לאחור אם משהו משתבש בתהליך הניקוי. שומרים אותו במקום מוגן, לא בתיקייה ציבורית שאפשר להגיע אליה דרך הדפדפן.
3. לעצור פעולות שעלולות לפגוע בגולשים
אם יש חשש שהאתר מפנה גולשים לעמוד מסוכן, אוסף נתונים באופן לא מורשה או משנה תהליך תשלום, צריך לצמצם מיד את החשיפה. בהתאם למצב, חברת האחסון יכולה להגביל גישה, להציג עמוד תחזוקה או להשבית באופן זמני רכיבים פגיעים.
בחנות אונליין ייתכן שיהיה נכון לעצור זמנית את הקופה או את קבלת המידע עד לבירור. זה לא צעד נעים, אבל עדיף לאבד זמן פעילות מוגבל מאשר להמשיך להעביר לקוחות דרך תהליך שאינכם בטוחים בו.
4. לעדכן את חברת האחסון ולרכז את הטיפול
שלחו לאחסון את התיעוד ובקשו לדעת אילו התראות זוהו, האם יש גיבויים נקיים, אם נשמרים לוגים והאם נמצאה פעילות חריגה בחשבון או באתרים אחרים שעל השרת. אם יש מפתח שמטפל באתר, כדאי לרכז מולו את כל הפעולות כדי ששני אנשים לא ישנו את אותם הקבצים במקביל.
מה לא לעשות כשהאתר נפרץ?
יש פעולות שנראות כמו פתרון מהיר, אבל עלולות לסבך את הטיפול:
לא למחוק מיד כל קובץ שנראה חשוד. חלק מהקבצים יכולים להיות לגיטימיים, ומחיקה לא מבוקרת עלולה להשבית את האתר או לפגוע ביכולת להבין מה השתנה.
לא לשחזר גיבוי אקראי ולהניח שהבעיה נפתרה. אם הפריצה התחילה לפני תאריך הגיבוי, ייתכן שגם הגיבוי נגוע. ואם הפרצה שדרכה נכנסו נשארת פתוחה, האתר עלול להיפרץ שוב.
לא להתקין שלושה תוספי אבטחה יחד. עומס של כלים לא מבטיח בדיקה טובה יותר. קודם מבינים מה כבר מותקן ומה נדרש.
לא להסתפק בהחלפת סיסמת וורדפרס. אם לתוקף הייתה גישה לאחסון, לחשבון הדוא״ל או למפתח API, שינוי סיסמה אחת לא פותר את הסיפור.
וכמובן, לא להוריד תוסף "ניקוי פריצות" ממקור לא מוכר רק כי הוא מבטיח לתקן הכול בלחיצה אחת.
השעות הבאות: איך מנקים אתר וורדפרס שנפרץ?
כאן מתחילה העבודה הטכנית. אין כפתור שמתאים לכל סוגי הפריצות, מפני שהבעיה יכולה להיות בקבצי וורדפרס, בתוסף, בתבנית, במסד הנתונים, בחשבון מנהל או אפילו בחשבון האחסון.
הבדיקה צריכה לענות על שתי שאלות: מה השתנה באתר, ואיך הצליחו לבצע את השינוי הזה? אם עונים רק על הראשונה, מסתכנים בכך שהפריצה תחזור.
לבדוק את המשתמשים ואת דרכי הגישה
עוברים על חשבונות המנהלים, מזהים מי באמת צריך הרשאות גבוהות ובודקים אם נוספו משתמשים לא מוכרים. בודקים גם חשבונות אחסון, גישת SFTP או SSH, מפתחות API וחיבורים חיצוניים, בהתאם למערכת.
אם יש חשד שסיסמאות נגנבו, כדאי להחליף אותן ממחשב נקי ולבטל חיבורים פעילים או מפתחות שנחשפו. לאחר ניקוי המערכת חשוב לבצע סבב נוסף של החלפת פרטי גישה, כדי לא להשאיר סיסמה חדשה בתוך סביבה שעדיין נמצאת בשליטת תוקף.
לבדוק קבצים, תוספים ומסד נתונים
כלי אבטחה מוכר, כמו Wordfence, יכול לסייע באיתור שינויים בקבצי מערכת וקוד זדוני מוכר. אבל סריקה אחת לא מכסה בהכרח כל סוג של הזרקה, ולכן בודקים גם תוכן ומידע במסד הנתונים, משימות מתוזמנות ורכיבים שלא אמורים להריץ קוד.
במקרים המתאימים מחליפים קבצי ליבה ותוספים בעותקים נקיים ממקור רשמי, בודקים תוספים ותבניות לא מעודכנים ומסירים רכיבים שלא נחוצים. לא עושים את זה בלי גיבוי ובלי להבין אילו התאמות קיימות באתר, כדי לא למחוק פיתוחים או מידע עסקי.
למצוא את הסיבה, לא רק את הסימפטום
נניח שמתגלה קוד זדוני שמפנה גולשים לאתר אחר. אפשר להסיר אותו ולראות שההפניה נעלמה. אבל אם הקוד הגיע דרך תוסף פגיע שעדיין מותקן, הבעיה לא נסגרה.
לפעמים הסיבה היא תוסף שלא עודכן, לפעמים סיסמה שנחשפה ולפעמים פרצה במערכת חיצונית. לא תמיד אפשר להגיע לוודאות מוחלטת, אבל צריך לבצע בירור סביר, לסגור את נתיבי הכניסה שהתגלו ולתעד מה שונה.
אני מציע שיחת אפיון ראשונית מתנה לגמרי ובלי שום התחייבות
לשחזר מגיבוי או לנקות את האתר הקיים?
זאת לא שאלה של "מה יותר מהיר" בלבד. צריך לדעת מתי התחילה הפריצה, האם יש גיבוי שנבדק והאם שמורים בו נתונים חשובים שנוספו מאז.
אם יש גיבוי נקי מלפני האירוע, אפשר לבנות ממנו סביבת שחזור ולבדוק שהקבצים והנתונים לא כוללים סימני פריצה. אחר כך צריך לעדכן את הרכיבים הפגיעים ולהחליף פרטי גישה. רק אז שוקלים להחזיר את האתר לפעילות.
בחנות או באתר עם משתמשים פעילים, שחזור יכול למחוק הזמנות, פניות, חשבונות או עדכונים שנוצרו אחרי תאריך הגיבוי. לכן חייבים לתכנן מה מעבירים מהמערכת הקיימת ואיך מאמתים את הנתונים, במקום ללחוץ על "שחזור" ולקוות לטוב.
כשאין גיבוי נקי, או כשהפער בין הגיבוי למידע הנוכחי גדול מדי, ייתכן שצריך ניקוי מקצועי של המערכת הקיימת או בנייה מחדש של החלקים שנפגעו. אין כאן פתרון אחד שמתאים לכולם.
לפני שמחזירים את האתר לאוויר: מה חייבים לבדוק?
אתר שנטען יפה לא בהכרח חזר לעבוד. אחרי הניקוי צריך לעבור על פעולות אמיתיות של משתמש, ולא רק על עמוד הבית.
- לפתוח עמודים מרכזיים גם מהמחשב וגם מהנייד, ולוודא שאין הפניות מוזרות.
- לבדוק התחברות, הרשאות משתמשים וטפסים שמעבירים פניות.
- בחנות: לבדוק סל קניות, קופה, תשלומים בסביבת בדיקה, עדכוני מלאי והודעות על הזמנות.
- לבדוק אם נוספו עמודי ספאם, קישורים לא מוכרים או שינויים בכותרות ובתיאורים של עמודים.
- להריץ סריקה חוזרת, לבדוק את יומני הפעילות הזמינים ולחפש סימני חדירה נוספים. סריקה תקינה לבדה אינה הוכחה מוחלטת שהאתר נקי.
- לוודא שקיימים גיבויים חדשים ונקיים ושידוע מי מקבל התראות אם משהו חוזר.
הבדיקות האלה חשובות גם מבחינה עסקית. אתר יכול להיות זמין לחלוטין, אבל טופס שלא שולח פניות או קופה שלא משלימה הזמנה עדיין גורמים לעסק להפסיד עבודה.
גוגל מציג אזהרה שהאתר מסוכן. איך מסירים אותה?
אם גוגל זיהה באתר תוכן זדוני, דיוג או סימנים אחרים לפריצה, הוא עשוי להציג אזהרה לגולשים. זה יכול לפגוע בתנועה לאתר ובאמון של הלקוחות, גם אחרי שהעיצוב כבר נראה תקין.
אחרי שסיימתם לנקות את האתר ולסגור את הפרצה, נכנסים ל-Google Search Console, פותחים את דוח "בעיות אבטחה", בודקים אילו בעיות דווחו ושולחים בקשה לבדיקה חוזרת אם האפשרות זמינה. אם הדוח לא מציג בעיה, אין טעם לשלוח בקשת בדיקה שאינה קיימת.
לא כדאי לבקש בדיקה חוזרת לפני שבטוחים שהבעיה טופלה. אם הדוח ממשיך להציג בעיות, חוזרים לטיפול. זמן הבדיקה והשינוי בהצגת האזהרה אינם קבועים, ולכן לא הייתי מבטיח שהכול ייעלם בתוך יום.
כדאי לבדוק גם אם נוצרו עמודים מוזרים שהופיעו בתוצאות החיפוש, האם נוספו משתמשי בעלות לא מוכרים ל-Search Console והאם עמודים מרכזיים עדיין נסרקים כרגיל. תיקון בעיית האבטחה הוא הצעד הראשון; ההתאוששות של התנועה האורגנית יכולה לקחת יותר זמן.
מה אם נחשף מידע של לקוחות?
זה כבר לא רק עניין של אתר שלא עובד. אם יש חשד שגורם לא מורשה נחשף למידע אישי, פרטי הזמנות או נתונים שנשמרים במערכות העסק, צריך לברר מה היקף החשיפה ומה חובות הדיווח והטיפול שחלות על העסק.
בישראל יש אירועי אבטחה חמורים במאגרי מידע שמחייבים דיווח מיידי לרשות להגנת הפרטיות. לא כל תקלה באתר מחייבת דיווח, אבל אם יש חשד לחשיפת מידע, לא מחכים לסיום תיקון האתר כדי לברר את החובות החלות. בודקים את נסיבות המקרה בהקדם עם איש אבטחת מידע או ייעוץ משפטי מתאים, ובמידת הצורך גם מול ספק הסליקה ושירותים חיצוניים.
את ההנחיות אפשר למצוא בעמוד הדיווח הרשמי של הרשות להגנת הפרטיות. עדיף לטפל בזה בזמן מאשר לגלות בדיעבד שהתמקדנו רק בהחזרת האתר לאוויר.
איך מונעים מהפריצה לחזור?
אחרי שהאתר חזר לעבוד, כדאי לשנות את שגרת התחזוקה שלו. לא צריך להתקין כל תוסף אבטחה שקיים, אבל כן חשוב שיהיה מי שאחראי לעדכונים, להרשאות, לגיבויים ולבדיקות.
אני ממליץ לוודא שיש אימות דו-שלבי למשתמשים הרגישים, סיסמאות ייחודיות, גישה מאובטחת לשרת, תוספים ממקורות מוכרים ומדיניות ברורה להסרת רכיבים שכבר לא נמצאים בשימוש. גיבויים צריכים להישמר גם מחוץ לסביבה הראשית, וכדאי לבדוק שאפשר באמת לשחזר מהם.
אם אתם רוצים להעמיק בשכבת המניעה, כתבתי בנפרד מדריך לאבטחת אתר וורדפרס. כאן התמקדתי בטיפול אחרי אירוע; במדריך ההוא תמצאו פעולות שמטרתן להקטין מראש את הסיכון.
אפשר גם לקרוא על תחזוקת אתרים בטוויסט, הכוללת בין השאר עדכונים, גיבויים, בדיקות אבטחה ומעקב אחר פעילות האתר. תחזוקה לא מבטיחה שלא תהיה פריצה, אבל היא עוזרת לזהות בעיות מוקדם יותר ולשמור על תהליך טיפול מסודר.
מה משפיע על המחיר ועל זמן הטיפול באתר שנפרץ?
תיקון של אתר פרוץ יכול להיות עניין ממוקד או טיפול מורכב. הכול תלוי באופי הפריצה, במספר המערכות שנפגעו, במצב הגיבויים ובשאלה אם יש גישה מלאה לשרת ולחשבונות הדרושים.
אתר תדמית קטן עם קובץ פגוע אחד וגיבוי נקי הוא לא אותו סיפור כמו חנות שיש בה הזמנות, סליקה, חיבורים חיצוניים ומידע שמתעדכן בכל שעה. לכן מי שנותן מחיר מדויק בלי לבדוק את המקרה לוקח סיכון, וגם אתם.
הייתי מבקש מבעל המקצוע לפרט מה כולל הטיפול: אבחון, שמירת עותק, ניקוי או שחזור, סגירת נתיב החדירה, בדיקות פעילות ומעקב קצר אחרי החזרה לאוויר. כדאי גם להבין אם תיקון הפריצה הוא עבודה חד-פעמית, ומה כולל שירות התחזוקה השוטף אם בוחרים להמשיך איתו.
שאלות נפוצות על אתר שנפרץ
האם אתר וורדפרס שנפרץ חייב בנייה מחדש?
לא בהכרח. במקרים רבים אפשר לשחזר מגיבוי נקי או לנקות את הקבצים והנתונים שנפגעו. במקרים מורכבים ייתכן שתידרש בנייה מחדש של חלקים מהמערכת. ההחלטה מתקבלת אחרי בדיקה, לא לפי איך שעמוד הבית נראה.
האם שינוי סיסמה מספיק כדי לעצור פריצה?
בדרך כלל לא. צריך לבדוק את כל הגישות הרלוונטיות, חיבורים חיצוניים, הרשאות, קבצים וקוד. אם נשארת דרך כניסה פעילה אחרת, שינוי סיסמה אחת לא יסגור אותה.
יש לי תוסף אבטחה. איך בכל זאת פרצו לאתר?
תוסף אבטחה הוא שכבת הגנה, לא ביטוח מפני כל סוגי התקיפות. תוסף פגיע, חשבון שנפרץ או בעיית שרת עלולים לאפשר חדירה גם כשמותקן כלי אבטחה. לכן חשוב לטפל בכמה שכבות ולא לסמוך על תוסף יחיד.
האם שחזור מגיבוי מחזיר אתר פרוץ לקדמותו?
רק אם הגיבוי נקי, הבעיה שבגללה התאפשרה הפריצה נסגרה ונלקחו בחשבון נתונים שנוצרו מאז. שחזור בלבד יכול להחזיר גם את הנוזקה או למחוק מידע עסקי חשוב.
הפריצה יכולה לפגוע בקידום בגוגל?
כן. גוגל עשוי להזהיר משתמשים מפני האתר, ותוכן ספאם שהוזרק יכול להופיע בחיפוש. אחרי הניקוי כדאי לבדוק את דוח בעיות האבטחה ואת העמודים המאונדקסים. התאוששות הדירוגים אינה בהכרח מיידית.
אפשר לבדוק לבד אם האתר נקי?
אפשר לבצע בדיקות ראשוניות, אבל הן לא מוכיחות בוודאות שאין קוד זדוני או גישה לא מורשית. אם יש סימנים ממשיים לפריצה, כדאי לבצע בדיקה מקצועית של הקבצים, מסד הנתונים והסביבה שבה האתר פועל.
האתר שלכם נפרץ? בואו נבין מה קרה לפני שמתחילים למחוק דברים
אם אתם רואים הפניות מוזרות, התראת אבטחה או פעילות שלא אמורה לקרות באתר שלכם, הדבר החשוב הוא לא למצוא את הכפתור הכי מהיר. צריך לבדוק מה נפגע, לשמור את מה שצריך ולבנות דרך בטוחה להחזיר את האתר לפעילות.
האתר שלכם נפרץ? שלחו לי מה אתם רואים ומה השתנה. נבדוק מה הצעד הנכון להמשך ואילו פרטים צריך לאסוף. המטרה היא לא רק להחזיר את האתר לאוויר, אלא לוודא שגם הטפסים, ההזמנות והעמודים החשובים עובדים כמו שצריך. אם מדובר בפריצה מורכבת שדורשת מומחה אבטחת מידע, חשוב לערב גם איש מקצוע שמתמחה בטיפול באירועים כאלה. אל תשלחו סיסמאות או מידע רגיש דרך טופס הפנייה.
אפשר לפנות אליי דרך האתר, ואם האתר כבר עובד ואתם רוצים שמישהו ידאג לתחזוקה השוטפת שלו, כל הפרטים נמצאים בעמוד תחזוקת האתרים של טוויסט.
