בקצרה
- רוב הפרצות בוורדפרס נמצאות בתוספים ובתבניות, ולכן עדכונים שוטפים ומחיקת תוספים שלא בשימוש הם הצעד החשוב ביותר.
- לכל מנהל באתר: סיסמה ייחודית, אימות דו‑שלבי, והרשאה שלא גבוהה ממה שהוא באמת צריך.
- שינוי כתובת ההתחברות מוריד רעש, אבל לא מגן. מה שמגן הוא הגבלת ניסיונות, חומת אש, וחסימת XML-RPC כשלא משתמשים בו.
- גיבוי שלא שוחזר מעולם הוא השערה. בודקים שחזור, וקוראים את הלוגים כדי לגלות בעיה לפני שהיא גדלה.
למה אתרי וורדפרס נפרצים
הליבה של וורדפרס מתוחזקת היטב, ועדכוני האבטחה שלה יוצאים מהר. רוב הפרצות נמצאות במקומות אחרים: בתוספים ובתבניות, שכל אחד מהם נכתב על ידי מפתח אחר וברמה אחרת, ובסיסמאות חלשות או כאלה שדלפו משירות אחר. התוקפים כמעט אף פעם לא בוחרים אתר מסוים. הם מריצים סריקות אוטומטיות (תוכנות שעוברות על אלפי אתרים ומחפשות גרסה פגיעה או סיסמה שקל לנחש), ופורצים לכל מי שנמצא.
יש בזה גם חדשות טובות: לא צריך להיות מומחה אבטחה כדי לא להיות המטרה הקלה. הרשימה שבהמשך מסודרת לפי סדר חשיבות, וליד כל סעיף: מה זה, למה זה חשוב, ואיך עושים את זה. בחלק מהסעיפים יש פקודות WP-CLI (כלי שורת הפקודה של וורדפרס) למי שיש לו גישת SSH, אבל כמעט הכול אפשר לעשות גם מלוח הבקרה.
עדכונים, ומחיקת תוספים שלא צריך
מה זה: עדכון של ליבת וורדפרס, התוספים והתבניות לגרסה האחרונה. למה: ברגע שמתפרסמת פרצה בתוסף, היא מתפרסמת גם לתוקפים, והסריקות אחריה מתחילות מהר. כל יום שבו האתר מריץ את הגרסה הישנה הוא יום שבו הוא פתוח לכל מי שמחפש אותה.
איך:
- עדכונים אוטומטיים לליבה ולרוב התוספים. במסך התוספים יש לכל תוסף אפשרות להפעיל עדכון אוטומטי.
- תוספים קריטיים, כמו חנות וסליקה, מעדכנים קודם ב‑Staging (עותק של האתר שסגור לגולשים), ואז באתר החי. בודקים, אבל לא דוחים לשבועות.
- מוחקים כל תוסף ותבנית שלא בשימוש. תוסף כבוי לא רץ בעמודים, אבל הקבצים שלו עדיין יושבים בשרת, ופרצות מסוימות אפשר לנצל גם כשהוא כבוי. משאירים תבנית ברירת מחדל אחת כגיבוי, ואת השאר מוחקים.
- מחליפים תוספים נטושים: תוסף שלא עודכן זמן רב, או שהוסר ממאגר התוספים של וורדפרס, כבר לא יקבל תיקוני אבטחה.
wp plugin list --update=available
wp plugin list --status=inactive
wp plugin update --all
wp core update
סיסמאות, אימות דו‑שלבי והרשאות
סיסמה ייחודית לכל מנהל
סיסמה חזקה היא ארוכה ואקראית, ובעיקר ייחודית. שימוש באותה סיסמה בכמה שירותים פותח את הדלת ל‑Credential Stuffing (ניסיון התחברות עם סיסמאות שדלפו משירות אחר). מנהל סיסמאות, כמו Bitwarden או 1Password, פותר את זה בלי לזכור כלום.
אימות דו‑שלבי
אימות דו‑שלבי (2FA) מוסיף לסיסמה שלב שני: קוד מאפליקציה בטלפון או מפתח אבטחה פיזי. גם אם הסיסמה דלפה, בלי השלב השני אי אפשר להתחבר. מוסיפים אותו דרך תוסף, למשל Wordfence, שכולל אימות דו‑שלבי, או התוסף Two Factor, ומחייבים אותו לכל מי שיש לו הרשאת מנהל או עורך. אפליקציית קודים עדיפה על SMS.
הרשאות מינימליות
העיקרון נקרא Least Privilege (הרשאה מינימלית): כל משתמש מקבל את התפקיד הנמוך ביותר שמאפשר לו לעבוד. כותב תוכן מקבל עורך (Editor) או מחבר (Author), מי שמטפל בהזמנות מקבל מנהל חנות (Shop Manager), ורק אחד או שניים הם מנהלים (Administrator). בעלי מקצוע חיצוניים מקבלים משתמש משלהם, לא את הסיסמה שלכם, ובסוף העבודה מוחקים אותו. פעם בחודש עוברים על רשימת המנהלים:
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
מנהל שאתם לא מזהים הוא סימן מובהק לפריצה. אל תמחקו אותו מיד: קודם בודקים מתי ואיך הוא נוצר, כי זה מוביל לפרצה שדרכה נכנסו.
מסך ההתחברות: הגבלת ניסיונות, XML-RPC, ולמה הסתרה לא מספיקה
הגבלת ניסיונות התחברות
כברירת מחדל, וורדפרס מאפשרת לנסות סיסמאות בלי הגבלה. Brute Force (ניחוש סיסמאות בכוח, אלפי ניסיונות ברצף) הוא מהדברים הראשונים שבוטים עושים. הגבלת ניסיונות חוסמת כתובת אחרי כמה כישלונות. Wordfence עושה את זה, וגם תוספים ייעודיים, למשל Limit Login Attempts Reloaded. אם האתר עובר דרך Cloudflare, ודאו שהשרת מזהה את כתובת הגולש האמיתית. אחרת החסימה תיפול על הכתובות של Cloudflare, ותנעל גם גולשים תמימים.
XML-RPC
הקובץ xmlrpc.php הוא ממשק ישן שמאפשר לתוכנות חיצוניות לעבוד מול האתר. הבעיה: הוא דלת התחברות נוספת מלבד מסך ההתחברות הרגיל, ובוטים תוקפים אותו בהמוניהם. הגנות שמוגדרות רק על מסך ההתחברות, כמו CAPTCHA או כתובת מוסתרת, לא חלות עליו. בנוסף, אפשר לנצל את מנגנון ה‑Pingback שלו כדי לגרום לאתר לשלוח בקשות לאתרים אחרים. אם אף שירות שלכם לא נשען עליו (Jetpack, למשל, כן), חוסמים אותו: דרך תוסף האבטחה, או בשרת Apache או LiteSpeed Enterprise, בקובץ .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>
למה שינוי כתובת ההתחברות לא מספיק
Security through obscurity (אבטחה דרך הסתרה) היא ניסיון להגן על משהו רק בכך שמסתירים אותו. העברת wp-login.php לכתובת אחרת מורידה את כמות הבוטים שמגיעים למסך ההתחברות, וזה נחמד ללוגים. אבל זו לא הגנה. הכתובת יכולה לדלוף מתוסף, מקישור בתבנית או מעובד לשעבר. XML-RPC ממשיך לקבל ניסיונות התחברות. ושמות המשתמשים נחשפים בקלות, למשל דרך עמודי המחבר או דרך ה‑REST API (ממשק התכנות של וורדפרס). ובעיקר: אם סיסמה דלפה, ההסתרה רק מעכבת את מי שמחזיק בה, ולא עוצרת אותו. אפשר להסתיר, בתנאי שכל השאר כבר במקום.
חומת אש וסריקת נוזקות
WAF (Web Application Firewall, חומת אש לאתרים) קוראת כל בקשה לפני שהיא מגיעה לקוד של האתר, ועוצרת דפוסי תקיפה מוכרים: הזרקת SQL, העלאת קבצים זדוניים, וניסיונות לנצל פרצה ידועה בתוסף. לפעמים כלל חדש ב‑WAF חוסם ניצול של פרצה עוד לפני שהספקתם לעדכן את התוסף.
ההגנה יכולה לשבת בשלושה מקומות, וכדאי שלפחות שניים יעבדו יחד: ברשת, לפני השרת (למשל ה‑WAF של Cloudflare); ברמת השרת, כמו Imunify360, שמגינה על כל האתרים והשירותים בשרת; ובתוך וורדפרס, כמו Wordfence, שמכיר את התוספים והמשתמשים של האתר.
סריקת נוזקות (Malware, קוד זדוני) מחפשת קבצים שהשתנו או נוספו: דלתות אחוריות, קוד שמפנה גולשים לאתרים אחרים, וקבצי PHP בתיקיית ההעלאות, שבה אמורים להיות רק תמונות ומסמכים. בדיקה מהירה עם WP-CLI משווה את קבצי הליבה ואת התוספים מהמאגר הרשמי למקור:
wp core verify-checksums
wp plugin verify-checksums --all
כל קובץ ששונה או נוסף בלי שאתם שיניתם אותו דורש בדיקה. לבדיקה חיצונית מהירה של האתר אפשר להשתמש גם בכלי הסריקה החינמי שלנו.
HTTPS, הרשאות קבצים ו‑DISALLOW_FILE_EDIT
HTTPS בכל האתר
HTTPS מצפין את החיבור בין הגולש לאתר, כך שסיסמאות ועוגיות התחברות לא עוברות כטקסט גלוי, למשל ברשת Wi-Fi ציבורית. תעודת SSL חינמית זמינה היום כמעט בכל אחסון. אחרי ההתקנה מוודאים שכתובת האתר בהגדרות הכלליות מתחילה ב‑https://, ושכל בקשה ב‑HTTP מופנית ל‑HTTPS.
הרשאות קבצים
הרשאות קבצים (Permissions) קובעות מי יכול לקרוא, לכתוב ולהריץ כל קובץ בשרת. הערכים המקובלים בוורדפרס: 755 לתיקיות ו‑644 לקבצים. את wp-config.php, שמחזיק את סיסמת מסד הנתונים, מחמירים ל‑640 או 600, לפי הגדרות השרת. לעולם לא 777, שמאפשר לכל תהליך בשרת לכתוב לקובץ.
find /home/USER/public_html -type d -exec chmod 755 {} \;
find /home/USER/public_html -type f -exec chmod 644 {} \;
chmod 640 /home/USER/public_html/wp-config.php
את USER מחליפים בשם המשתמש שלכם, ואחרי השינוי בודקים שהאתר ולוח הבקרה עדיין עולים.
DISALLOW_FILE_EDIT
לוח הבקרה של וורדפרס כולל עורך קבצים לתבניות ולתוספים. מי שהשיג סיסמת מנהל יכול להשתיל דרכו קוד זדוני בכמה לחיצות. שורה אחת ב‑wp-config.php מסירה את העורך, והתקנות ועדכונים ממשיכים לעבוד כרגיל:
define( 'DISALLOW_FILE_EDIT', true );
על ההגדרה הזו, ועל הגדרות נוספות שכדאי להכיר באותו קובץ, כמו כיבוי מצב דיבאג באתר חי, כתבנו במדריך הגדרות wp-config.php למהירות ולבטיחות.
גיבויים שנבדקו, ולוגים שמישהו קורא
גיבויים
גיבוי הוא רשת הביטחון כשכל השאר נכשל. שלושה תנאים הופכים אותו לשימושי: הוא אוטומטי ויומי; הוא נשמר מחוץ לשרת של האתר, כי גיבוי שיושב באותה תיקייה נמחק או נדבק יחד עם האתר; והוא נשמר מספיק זמן אחורה. פריצה מתגלה לפעמים רק אחרי שבועות, וגיבוי מאתמול כבר מכיל את הקוד הזדוני.
והתנאי הרביעי, שהכי קל לדלג עליו: לבדוק שחזור. פעם ברבעון משחזרים גיבוי לסביבת בדיקה, ומוודאים שהאתר עולה, שהתמונות במקום ושמסד הנתונים שלם.
לוגים
לוג (Log, יומן אירועים) מתעד מה קרה ומתי. שני סוגים שימושיים במיוחד: יומן הגישה של השרת, שמתעד כל בקשה, ו‑יומן פעילות בתוך וורדפרס, דרך תוספים כמו WP Activity Log או Simple History, שמתעד התחברויות, משתמשים חדשים, התקנות ושינויי הגדרות. מה מחפשים:
- מנהל חדש, או שינוי הרשאה שלא אתם עשיתם.
- התחברות מוצלחת בשעה חריגה או ממדינה שאין לכם בה אף אחד.
- תוסף שהותקן, או קובץ שהשתנה, בלי סיבה ידועה.
- מאות בקשות POST ל‑
wp-login.phpאו ל‑xmlrpc.phpמאותה כתובת.
את האחרון רואים ביומן הגישה. הפקודה הבאה מציגה את הכתובות ששלחו הכי הרבה בקשות כאלה:
grep "POST /xmlrpc.php" access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head
ואם כבר מצאתם סימנים לפריצה, יש סדר פעולות שכדאי להכיר: הצעדים הראשונים אחרי שאתר נפרץ.
הרשימה המקוצרת: מה עושים ומתי
| פעולה | מתי |
|---|---|
| עדכון ליבה, תוספים ותבניות | אוטומטית, עם בדיקה פעם בשבוע |
| מחיקת תוספים ותבניות שלא בשימוש | פעם בחודש |
| מעבר על משתמשים והרשאות | פעם בחודש, ובכל עזיבה של עובד או ספק |
| אימות דו‑שלבי למנהלים ולעורכים | פעם אחת, ולכל משתמש חדש |
| הגבלת ניסיונות, WAF וחסימת XML-RPC | פעם אחת, ומבט בחסימות פעם בחודש |
| HTTPS, הרשאות קבצים ו‑DISALLOW_FILE_EDIT | פעם אחת, ושוב אחרי כל מעבר שרת |
| סריקת נוזקות | אוטומטית, וידנית בכל חשד |
| שחזור ניסיון מגיבוי | פעם ברבעון |
| קריאת יומן הפעילות | פעם בשבוע |
באחסון מנוהל, חלק מהסעיפים, כמו חומת אש ברמת השרת, סריקת נוזקות וגיבויים, נמצאים באחריות חברת האחסון. שווה לברר מה בדיוק כלול אצלכם. העדכונים, הסיסמאות וההרשאות נשארים תמיד בידיים שלכם.
שאלות נפוצות
תוסף אבטחה אחד מספיק כדי להגן על וורדפרס?
לא. תוסף כמו Wordfence מוסיף חומת אש, סריקה והגנה על ההתחברות, אבל הוא לא מעדכן תוספים, לא בוחר סיסמאות ולא מחליף גיבויים. הוא שכבה אחת מתוך כמה, ועדיף שתעבוד לצידו גם הגנה ברמת השרת.
כדאי להפעיל עדכונים אוטומטיים לתוספים?
לרוב התוספים כן. בתוספים קריטיים, כמו חנות וסליקה, עדיף לבדוק את העדכון קודם בסביבת בדיקה, אבל לא לדחות אותו לאורך זמן: גרסה פגיעה שנשארת באתר שבועות היא בדיוק מה שהבוטים מחפשים.
צריך להחליף את שם המשתמש admin?
כן, זה צעד קטן ששווה לעשות, כי admin הוא הניחוש הראשון של כל בוט. יוצרים מנהל חדש, מתחברים איתו ומוחקים את הישן תוך העברת התוכן שלו. אבל לא סומכים על זה: שמות משתמשים נחשפים בקלות, ומה שמגן הוא סיסמה חזקה ואימות דו‑שלבי.
איך יודעים שאתר וורדפרס כבר נפרץ?
סימנים נפוצים: הפניות לאתרים זרים, לפעמים רק למי שמגיע מגוגל או מהנייד, משתמשי ניהול שלא יצרתם, קבצי PHP בתיקיית ההעלאות, אזהרה בדפדפן או בתוצאות החיפוש, ועומס פתאומי על השרת. סריקה של הקבצים והשוואה שלהם למקור מאשרות או שוללות את החשד.
לחסום את XML-RPC?
אם אף שירות שלכם לא משתמש בו, כן. לפני החסימה בודקים שאין תוסף או כלי חיצוני שנשען עליו, למשל Jetpack, ואחרי החסימה מוודאים שהם עדיין עובדים.
כל כמה זמן לבדוק את האבטחה של האתר?
עדכונים: אוטומטית, עם מבט פעם בשבוע. משתמשים, הרשאות ותוספים: פעם בחודש ובכל עזיבה של עובד או ספק. שחזור ניסיון מגיבוי: פעם ברבעון ואחרי כל שינוי גדול באתר.