אבטחת מבנה תיקיות WordPress: חסימת גישה לתיקיית "wp-includes"

אבטחת מבנה תיקיות WordPress נעשית בצורה הבטוחה ביותר על ידי חסימת גישה ישירה לתיקיית "wp-includes", במקום לחסום את כל התיקייה באופן עיוור. יש לסגור את הגישה לקבצי PHP בתיקייה זו ולמנוע רשימת תיקיות. הסיבה לכך היא ש-wp-includes מכילה קבצי JavaScript, CSS וקבצים סטטיים חיוניים לפעולה של ליבת WordPress; חסימת הגישה לכל התיקייה עלולה להפריע לעיצוב האתר, לעריכה או לפונקציות של תוספים. הגישה הנכונה היא, אם אתם משתמשים ב-Apache, לחסום גישה ישירה ל-PHP באמצעות כללים ב-.htaccess, ואם אתם משתמשים ב-Nginx, לחסום זאת בתוך בלוק השרת עם כלל location, ולאחר מכן לאמת את האתר עם תשובות 403/404 ובדיקות עמודים קריטיות.

אחת הטעויות הנפוצות ביותר באבטחת WordPress היא להסתפק רק בסיסמאות חזקות או תוספי אבטחה. תוקפים לרוב סורקים תיקיות שמכילות קבצים קריטיים, תוספים ישנים, הרשאות קבצים שגויות ורשימות תיקיות פתוחות. תיקיית wp-includes היא אחת מהמטרות של סריקות אלו. במדריך זה, תמצאו צעדים ישימים בסביבות אירוח אמיתיות לחסימת הגישה ל-wp-includes, אילו כללים עלולים להפר את האתר, דוגמאות לתצורות עבור Apache ו-Nginx, שיטות בדיקה ורשימת בדיקות לתחזוקה. אתם יכולים גם לשקול אפשרויות עבור אחסון WordPress ולשכבת הגנה כללית עבור תעודת SSL.

מהי תיקיית wp-includes ולמה יש להגן עליה?

wp-includes היא אחת התיקיות העיקריות שמכילה את הספריות הבסיסיות של ליבת WordPress. מערכת התבניות, עורך הבלוקים, רכיבי REST API, עיבוד מדיה, מחלקות, פונקציות וקבצי JavaScript שונים נמצאים במבנה זה. בקצרה, wp-includes היא אחת ממנועי הפעולה של WordPress; זהו לא אזור תוכן שצריך לבקר בו ישירות על ידי משתמשים.

מבקר רגיל לא צריך לפתוח כתובת כמו site.com/wp-includes/. עם זאת, ניתן לראות בקוד המקור של העמוד כמה נכסים סטטיים מתיקיית wp-includes. לדוגמה, קבצי הסקריפט ברירת המחדל של WordPress, סקריפטים של אמוג'י או רכיבי עורך עשויים להיות נטענים מתיקייה זו. לכן, כאשר לוקחים אמצעי אבטחה, יש לקבוע את המטרה בצורה נכונה: לחסום את הגישה הישירה לקבצי PHP מבלי למנוע את הפעלת הקבצים הסטטיים.

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

מה היתרונות בחסימת הגישה ל-wp-includes?

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

אמצעי זה מספק את היתרונות הבאים:

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

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

שגיאות נפוצות בעת חסימת wp-includes

חסימת כל התיקייה

שגיאה נפוצה היא לחסום את כל הבקשות HTTP לתיקיית wp-includes באמצעות קוד 403. שיטה זו עשויה להיראות הגיונית במבט ראשון; אך כיוון ש-WordPress טוען כמה נכסים סטטיים מתיקייה זו, זה עשוי לגרום לבעיות בלתי צפויות. לדוגמה, עורך הבלוקים עשוי שלא להיפתח, כמה קבצי JavaScript עשויים שלא לעלות, או עלולים להופיע בעיות עיצוב קטנות אך קריטיות בחזית.

לקחת את הכלל חי לפני בדיקה

שגיאה של תו אחד במבנה של .htaccess או תצורת Nginx יכולה לגרום לשגיאת Server Internal 500. במיוחד באתרים שמקבלים תנועה רבה, לקיחה ישירה של הכלל לחיים היא מסוכנת. יש קודם כל לגבות את הקובץ, לנסות במידת האפשר בסביבת staging ולאחר מכן לעבור לחיים באופן מבוקר. אם יש אפשרויות staging או גיבוי בתשתית Hostragons, ניתן להוסיף את זה כקישור פנימי טבעי ל-גיבוי אחסון אתרים.

להסתמך לחלוטין על תוסף אבטחה

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

רשימת בדיקה לפני היישום

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

• גבו את התצורה הנוכחית של .htaccess או Nginx.
• עדכנו את ליבת WordPress, התבניות והתוספים.
• ודאו שגרסת ה-PHP שלכם היא גרסה נתמכת ובטוחה.
• בדקו את הרשאות הקבצים: תיקיות בדרך כלל צריכות להיות 755, קבצים 644.
• אל תשאירו הרשאות כתיבה פתוחות על קבצים קריטיים כמו wp-config.php ו-.htaccess.
• אם אתם משתמשים במטמון, CDN או תוסף אבטחה, תכננו לנקות את המטמון לאחר השינוי.
• צרו רשימה שתבדוק אזורים קריטיים כמו לוח הבקרה, דף הבית, דף הפוסט, טופס יצירת קשר ודף תשלום.

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

חסימת גישת PHP ל-wp-includes עם .htaccess בשרת Apache

הדרך הנפוצה ביותר באירוח משותף המשתמש ב-Apache היא דרך קובץ .htaccess. ההוספה הנכונה של כללים לקובץ .htaccess שנמצא בתיקיית הליבה של WordPress יכולה לחסום קריאות PHP מסוימות בתוך wp-includes. לפני שמתחילים, יש להוריד עותק של הקובץ למחשב או ליצור גיבוי דרך מנהל הקבצים בפאנל האירוח.

הכלל המומלץ עבור .htaccess

הגישה הבאה מתמקדת בחסימת גישה ישירה ל-PHP ב-wp-includes ומגנה על הפעלת קבצים סטטיים:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^wp-includes/.*[.]php$ - [F,L]
</IfModule>

ההיגיון מאחורי כלל זה הוא פשוט: אם ה-URL מתחיל ב-wp-includes ומסתיים ב-.php, הבקשה נחסמת. כך קבצי PHP בתיקיית wp-includes לא יכולים להיות נקראים על ידי הדפדפן. לעומת זאת, הגישה לקבצים סטטיים כמו .js, .css, .png, .svg נשמרת. זו האיזון הבטוח יותר עבור חזית WordPress ולוח הבקרה.

חסימת רשימת תיקיות

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

Options -Indexes

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

בדיקות לאחר השינוי

לאחר הוספת הכלל, בצעו את הבדיקות הבאות:

• פתחו את הכתובת siteadresiniz.com/wp-includes/; רשימת תיקיות לא צריכה להופיע.
• נסו לקרוא לקובץ PHP ידוע מתיקיית wp-includes; אתם צריכים לקבל 403 או 404.
• בדקו את דף הבית, הפוסט ולוח הבקרה.
• בדקו אם יש שגיאות 404/403 בלשוניות Console ו-Network בכלים המפתחים של הדפדפן.
• אם אתם משתמשים בתוסף מטמון או CDN, נקו את המטמון.

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

חסימת גישת PHP ל-wp-includes בשרת Nginx

ב-SVP, שרת ייעודי או סביבות שרת מנוהלות המשתמשות ב-Nginx, קובץ .htaccess לא פועל. יש להוסיף את הכלל לקובץ התצורה של האתר ב-Nginx, בדרך כלל בתוך בלוק השרת. תהליך זה דורש גישה SSH ורשות לערוך את קובץ התצורה. אם אינכם בטוחים, עדיף לבקש עזרה מצוות התמיכה של האירוח.

הכלל המומלץ עבור Nginx location

הכלל הבסיסי יכול להיות מיושם כך:

location ~* ^/wp-includes/.*[.]php$ {
deny all;
}

כלל זה חוסם בקשות לקבצי PHP בתיקיית wp-includes. לאחר השינוי, חשוב לבדוק את התצורה:

nginx -t

אם הבדיקה מצליחה, יש לטעון מחדש את Nginx:

systemctl reload nginx

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

דברים שצריך לשים לב אליהם בעת שימוש ב-Nginx

• ודאו שהכלל נוסף לבלוק השרת הנכון; עשויות להיות מספר אתרים על אותו השרת.
• אם אתם משתמשים ב-CDN או בפרוקסי הפוך, בצעו בדיקות אמיתיות לאחר ניקוי המטמון של ה-CDN.
• ודאו ש- PHP-FPM מעבד רק את הקבצים הנחוצים.
• בדקו את קבצי הלוג: access.log ו-error.log יציגו שגיאות במהירות.

בסביבת Nginx, סדר לא נכון של ה-location עלול לגרום לתוצאות בלתי צפויות. לכן יש לוודא שהכלל לא מתנגש עם קישורי permalinks של WordPress ובלוקי עיבוד PHP.

השוואת שיטות

הטבלה הבאה מסכמת את השיטות העיקריות להגבלת הגישה ל-wp-includes:

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

הרשאות קבצים והגדרות בעלות

חסימת הגישה ל-wp-includes לא תהיה שלמה אם הרשאות הקבצים שגויות. ההרשאות המקובלות ב-WordPress הן 755 לתיקיות ו-644 לקבצים. ערכים אלו מתירים לשרת האינטרנט לקרוא את הקבצים תוך הפחתת הרשאות כתיבה מיותרות. בסביבות אירוח מסוימות עשויות להיות הגדרות משתמש וקבוצה שונות; לכן יש לקחת בחשבון גם את ההמלצות של הפאנל שלכם.

במיוחד, הרשאת 777 היא סיכון אבטחה חמור. האפשרות שכל אחד יוכל לכתוב לתיקייה מקלה על תסריטים של העלאת קבצים זדוניים. גם בתיקיות שצריכות להיות ניתנות לכתיבה כמו wp-content/uploads, יש לחסום את הפעלת PHP. בדרך כלל wp-includes לא צריכה להיות ניתנת לכתיבה על ידי משתמשים, למעט עדכונים של WordPress.

בבדיקת אבטחה ניתן לבדוק את הערכים הבאים:

• תיקיית wp-includes: בדרך כלל 755
• קבצי PHP בתיקיית wp-includes: בדרך כלל 644
• wp-config.php: אם אפשרי 600 או הרשאות מצומצמות יותר שמתאימות לתשתית האירוח
• .htaccess: בדרך כלל 644, ללא הרשאות כתיבה מיותרות לאחר עריכה

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

האם תוספי אבטחה מבצעים את התהליך הזה?

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

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

אם אתם משתמשים בתוסף אבטחה, בצעו את הבדיקות הבאות:

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

שימוש במספר תוספי אבטחה בו זמנית לרוב לא מומלץ. כללי חומת אש, כניסה ו-rewrite מתנגשים עלולים להפחית את הביצועים או לגרום לחסימות שגויות.

בדיקת ההגנה על wp-includes: תרחיש מעשי

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

• 1. פתחו את דף הבית בלשונית פרטית ובדקו אם יש עיוותים חזותיים.
• 2. בקרו בפוסט בבלוג, בדף קטגוריה ובדף תוצאות חיפוש.
• 3. התחברו ללוח הבקרה של wp-admin; פתחו את עורך הבלוקים ואת ספריית המדיה.
• 4. בדקו את לשונית Console בכלים המפתחים של הדפדפן.
• 5. ודאו שאין חסימות מיותרות לקבצים סטטיים בתיקיית wp-includes בלשונית Network.
• 6. ניסיון לקרוא לקובץ PHP ישירות בתיקיית wp-includes; צפו לתשובה 403 או 404.
• 7. בדקו אם יש שגיאות חדשות וחוזרות בלוגי השגיאות של השרת.

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

צעדים נוספים לאבטחת מבנה תיקיות WordPress

הגנה על wp-includes היא התחלה טובה; אך יש לחשוב על אבטחת WordPress באופן כולל. הצעדים הנוספים הבאים מפחיתים עוד יותר את שטח המתקפה:

• שמרו על ליבת WordPress מעודכנת במקום לנסות להסתיר את גרסת WordPress.
• מחקו לחלוטין תוספים ותבניות שאינכם משתמשים בהם.
• הפכו את שם המשתמש של המנהל לקשה לניחוש.
• השתמשו באימות דו-שלבי.
• אם אינכם משתמשים ב-XML-RPC, גבילו את הגישה אליו.
• הוסיפו הגבלת קצב או אימות נוסף ל-wp-login.php.
• בצעו גיבוי אוטומטי יומי ובדיקת שיחזור.
• השתמשו ב-HTTPS בכל האתר; מידע ללא SSL מסוכן.

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

מתי כדאי לקבל תמיכה מקצועית?

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

מומלץ לקבל תמיכה מקצועית במקרים הבאים:

• אם אתם מארחים מספר אתרי WordPress על השרת.
• אם אתם משתמשים ב-Nginx, Varnish, CDN ו-WAF יחד.
• אם לאחר שינויים אחרונים, שגיאות 403, 404 או 500 הולכות ומתרבות.
• אם האתר חווה בעבר הידבקות ב-malware.
• אם אתם מפעילים מערכת המנהלת מידע אישי, תשלומים או מנויים.

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

סיכום

הדרך הנכונה לחסום גישה לתיקיית wp-includes במסגרת אבטחת מבנה תיקיות WordPress היא לא לחסום את התיקייה כולה, אלא לחסום את הגישה הישירה לקבצי PHP שבתוכה ולכבות את רשימת התיקיות. עבור Apache ניתן ליישם זאת באמצעות .htaccess, ועבור Nginx באמצעות כללי location. עם זאת, לפני כל שינוי יש לגבות את הקבצים, ולאחר מכן לבצע בדיקות בלוח הבקרה ובחזית.

בקצרה: אל תשברו קבצים סטטיים, גבילו את גישת PHP, כבו את רשימת התיקיות, בדקו את הרשאות הקבצים ועדכנו באופן סדיר. עבור תשתית WordPress בטוחה יותר וניתנת לניהול, ניתן לבדוק את הפתרונות של Hostragons עבור אירוח, דומיינים ו-SSL; ולקבל תמיכה לגבי תצורה מתאימה לצרכים שלכם.

שאלות נפוצות

האם חסימת תיקיית wp-includes היא פעולה בטוחה?

בדרך כלל, לא מומלץ. בתוך wp-includes עשויים להיות קבצי JavaScript, CSS וקבצים סטטיים ש-WordPress זקוק להם. חסימה מוחלטת עלולה לפגוע במראה האתר או בלוח הבקרה. הגישה הבטוחה יותר היא לחסום את הגישה הישירה לקבצי PHP בתיקייה זו.

מה לעשות אם אני מקבל שגיאת 500 לאחר הוספת כלל .htaccess?

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

האם .htaccess פועל בשרת Nginx?

לא. .htaccess משמש בסביבות Apache ו-LiteSpeed. בשרתים של Nginx, מגבלות דומות נעשות עם כללי location בתוך בלוק השרת, ויש לבדוק את התצורה לאחר השינוי עם nginx -t.

האם תהליך זה עושה את אתר ה-WordPress שלי בטוח לחלוטין?

לא. חסימת גישת PHP ל-wp-includes היא שכבת אבטחה חשובה אך לא מספיקה לבדה. יש ליישם עדכונים, סיסמאות חזקות, אימות דו-שלבי, SSL, גיבויים, חומת אש והרשאות קבצים נכונות יחד.

אם אני משתמש בתוסף אבטחה, האם כדאי להוסיף גם כלל ל-wp-includes?

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