בית › מרכז הידע › שיטת D-Office
מדריך יישוםביניים

הקשחת אבטחה ל-WordPress, עם קוד להעתקה

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

מדריך יישום · 9 דקות · קוד הגנתי מאומת

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

שיטת D-Office · מודל ארבע השכבות
יסודותהמנועהמרהתחזוקה
בונים מערכת, לא אתר.
מסלול קריאה מומלץ: אבטחה ואמינות, התפיסהמדריך ההקשחה עם הקוד (כאן)
פעולההשפעהסיכון
עדכונים וגיבוי🟢 גבוהה🟢 בטוח
כפיית HTTPS🟢 גבוהה🟡 לבדוק
אבטחת התחברות🟢 גבוהה🟢 בטוח
חומת אש (WAF)🟢 גבוהה🟢 בטוח
הרשאות קבצים🟡 בינונית🟡 לבדוק
ביטול עריכת קבצים🟡 בינונית🟢 בטוח
חסימת PHP בהעלאות🟡 בינונית🟡 לבדוק
כותרות אבטחה🟡 בינונית🟡 לבדוק
ביטול XML-RPC🟡 בינונית🟡 לבדוק
הסתרת גרסה⚪ נמוכה🟢 בטוח
בקצרה: זהו הצד המעשי של מאמר האבטחה. כל הקטעים כאן הם הקשחה הגנתית מקובלת, לא פעולות התקפיות, והם מקטינים את הסיכון עוד לפני שקורה משהו. כל סעיף בנוי באותה תבנית: דירוג השפעה וסיכון, למה עושים, מתי לא, הקוד, ואיך בודקים.
למי מיועד המדריך: לאתרים בפיתוח או למנהלי אתרים שמכירים WordPress. אם אינכם בטוחים מה עושה קטע קוד מסוים, עדיף לעצור ולהתייעץ. גם קוד תקין עלול להתנגש עם תוסף או תבנית מסוימים, לכן גבו את האתר לפני, והוסיפו קטע אחד בכל פעם.
קוד PHP מיועד ל-functions.php של Child Theme או תוסף Code Snippets. שורות define נכנסות ל-wp-config.php (מעל שורת הסיום stop editing). קטעי .htaccess הם ל-Apache בלבד.
למה אין כאן תוסף אחד שעושה הכול?

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

לפני שמתחילים: גיבוי

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

עדכונים וגיבוי

🟢 השפעה גבוהה🟢 סיכון: בטוח

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

wp-config.php (מעל שורת הסיום stop editing)
define( 'WP_AUTO_UPDATE_CORE', true );

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

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

איך בודקים: ✔ ודאו שעדכוני הליבה האוטומטיים פעילים. ✔ ודאו שהגיבוי רץ ונשמר ליעד חיצוני.

כפיית HTTPS

🟢 השפעה גבוהה🟡 סיכון: לבדוק

למה עושים את זה: בלי HTTPS הדפדפן מסמן "אתר לא מאובטח" והמידע עובר גלוי. כפייה מוודאת שכל מבקר מגיע לגרסה המאובטחת. לכפיית HTTPS על אזור הניהול, ב-wp-config.php:

wp-config.php (מעל שורת הסיום stop editing)
define( 'FORCE_SSL_ADMIN', true );

ולהפניית כל התעבורה מ-http ל-https (Apache), ב-.htaccess:

.htaccess (Apache בלבד)
<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTPS} off
  RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

מתי לא להשתמש: רק לאחר שיש תעודת SSL תקינה ומותקנת. כפייה בלי תעודה תנעל את האתר. בשרתי Nginx ההפניה מוגדרת בקונפיג השרת.

איך בודקים: ✔ גשו לאתר עם http:// וודאו הפניה אוטומטית ל-https. ✔ ודאו מנעול בכל העמודים.

אבטחת ההתחברות

🟢 השפעה גבוהה🟢 סיכון: בטוח

למה עושים את זה: מסך ההתחברות הוא היעד מספר אחת להתקפות ניחוש סיסמה. שלוש הגנות משלימות: הגבלת ניסיונות התחברות (תוסף כמו Limit Login Attempts Reloaded חוסם כתובת IP אחרי כמה כישלונות), סיסמאות חזקות וייחודיות, ואימות דו-שלבי (2FA) דרך תוסף ייעודי. שלושתם יחד הופכים ניחוש סיסמה למעשית בלתי אפשרי.

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

איך בודקים: ✔ נסו סיסמה שגויה כמה פעמים וודאו שנחסמתם. ✔ ודאו שה-2FA מבקש קוד בכניסה.

הרשאות קבצים

🟡 השפעה בינונית🟡 סיכון: לבדוק

למה עושים את זה: הרשאות נכונות מונעות מתהליך או תוקף לכתוב לקבצים שאסור לגעת בהם. הכלל המקובל: תיקיות 755, קבצים 644, ו-wp-config.php מחמיר יותר (640). אין קוד PHP כאן, זו פעולה ברמת השרת דרך FTP, מנהל הקבצים באחסון, או SSH:

SSH (למי שיש גישה)
# תיקיות: 755
find /path/to/wordpress/ -type d -exec chmod 755 {} \;
# קבצים: 644
find /path/to/wordpress/ -type f -exec chmod 644 {} \;
# wp-config מחמיר יותר
chmod 640 wp-config.php

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

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

ביטול עריכת קבצים מהפאנל

🟡 השפעה בינונית🟢 סיכון: בטוח

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

wp-config.php (מעל שורת הסיום stop editing)
define( 'DISALLOW_FILE_EDIT', true );

מתי לא להשתמש: אם אתם נשענים על העורך המובנה לעבודה שוטפת. עדיף בכל מקרה לערוך דרך Child Theme או FTP.

איך בודקים: ✔ ודאו שתחת "מראה" ו"תוספים" האפשרות "עורך קבצים" נעלמה.

חסימת הרצת PHP בתיקיית ההעלאות

🟡 השפעה בינונית🟡 סיכון: לבדוק

למה עושים את זה: תיקיית wp-content/uploads מיועדת לתמונות וקבצים, לא לקוד. אם תוקף מצליח להעלות לשם קובץ PHP זדוני, חסימת הרצת PHP בתיקייה מונעת ממנו לרוץ. ב-Apache, צרו קובץ .htaccess בתוך תיקיית ההעלאות:

wp-content/uploads/.htaccess (Apache)
# הקובץ: wp-content/uploads/.htaccess
<Files *.php>
  Require all denied
</Files>

מתי לא להשתמש: אם תוסף לגיטימי מריץ PHP מתוך uploads (נדיר). ב-Nginx הכלל מוגדר בקונפיג השרת. אם משהו נשבר, הסירו את הקובץ.

איך בודקים: ✔ ודאו שתמונות וקבצים עדיין נטענים ומוצגים כרגיל.

כותרות אבטחה

🟡 השפעה בינונית🟡 סיכון: לבדוק

למה עושים את זה: כותרות אבטחה אומרות לדפדפן איך להתנהג בבטחה: למנוע הטמעה במסגרת זרה (Clickjacking), למנוע ניחוש סוגי קבצים, ולאכוף HTTPS. ב-.htaccess (Apache):

.htaccess (Apache בלבד)
<IfModule mod_headers.c>
  Header set X-Content-Type-Options "nosniff"
  Header set X-Frame-Options "SAMEORIGIN"
  Header set Referrer-Policy "strict-origin-when-cross-origin"
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</IfModule>

HSTS דורש זהירות: הוסיפו את Strict-Transport-Security רק כש-HTTPS עובד מצוין בכל האתר. חשוב לדעת שהוא "דביק": ברגע שהדפדפן קיבל אותו, הוא יתעקש על https למשך התוקף שהוגדר (כאן שנה), וקשה מאוד לבטל את זה אצל מבקרים שכבר קיבלו אותו.

למה לא כללנו Content-Security-Policy?

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

איך בודקים: ✔ בכלי כמו securityheaders.com ודאו שהכותרות מופיעות. ✔ ודאו שהאתר וכל הטמעה לגיטימית עדיין עובדים.

ביטול XML-RPC

🟡 השפעה בינונית🟡 סיכון: לבדוק

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

functions.php (Child Theme) או תוסף Code Snippets
add_filter( 'xmlrpc_enabled', '__return_false' );

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

איך בודקים: ✔ ודאו שהאתר, Jetpack (אם קיים) והאפליקציה עדיין עובדים.

הסתרת גרסת וורדפרס

⚪ השפעה נמוכה🟢 סיכון: בטוח

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

functions.php (Child Theme) או תוסף Code Snippets
remove_action( 'wp_head', 'wp_generator' );
add_filter( 'the_generator', '__return_empty_string' );
איך בודקים: ✔ בקוד המקור של העמוד, ודאו שתגית ה-generator עם הגרסה נעלמה.

חומת אש (WAF): השכבה שמעבר לקוד

🟢 השפעה גבוהה🟢 סיכון: בטוח

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

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

איך לוודא שזה עבד

אחרי כל שינוי: בדקו שהאתר תקין, ובמיוחד שאתם עדיין מצליחים להתחבר, ושטפסים ותשלום עובדים. בדקו את האתר ב-securityheaders.com, וודאו שהגיבוי רץ. עבדו קטע-קטע, ואם משהו נשבר, הסירו את האחרון. לסיום, צ'קליסט מהיר:

✅ HTTPS פעיל בכל העמודים
✅ גיבוי אוטומטי רץ לענן
✅ עדכוני ליבה אוטומטיים
✅ אימות דו-שלבי (2FA)
✅ הגבלת ניסיונות התחברות
✅ כותרות אבטחה
✅ XML-RPC בוטל או מוגבל
✅ חומת אש (WAF) פעילה
✅ כניסה, טפסים ותשלום עדיין עובדים
שאלות נפוצות

שאלות ותשובות על הקשחה

לאן מדביקים כל קטע?
קוד PHP ב-functions.php של Child Theme או בתוסף Code Snippets. שורות define ב-wp-config.php, מעל שורת הסיום. קטעי .htaccess רק בשרת Apache.
הקוד הזה מספיק, או שצריך תוסף אבטחה?
הם משלימים. הקטעים כאן סוגרים דלתות נפוצות, אבל תוסף אבטחה עם חומת אש (כמו Wordfence) מוסיף סריקה וחסימת תוקפים בזמן אמת. יחד הם חזקים בהרבה.
אני על Nginx, מה עם קטעי ה-.htaccess?
קטעי .htaccess לא נקראים ב-Nginx. הפניית HTTPS וכותרות אבטחה מוגדרות שם בקונפיג השרת או בלוח הבקרה של האחסון. קטעי ה-PHP וה-wp-config עובדים בכל שרת.
מה הכי חשוב אם אין לי זמן להכל?
שלושה דברים לפי סדר: עדכונים אוטומטיים, גיבוי אוטומטי לענן, וסיסמאות חזקות עם אימות דו-שלבי. רוב הפריצות נעצרות כבר שם.
ביטלתי XML-RPC ומשהו הפסיק לעבוד, מה עכשיו?
כנראה Jetpack, אפליקציית וורדפרס או אינטגרציה חיצונית שצריכה אותו. החזירו את הקטע, ובמקום ביטול מלא השתמשו בתוסף אבטחה שמגביל את XML-RPC בצורה חכמה.

מעדיפים שנקשיח את האתר עבורכם?

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

בואו נדבר