עדכנו את וורדפרס ביד, מפני שהכפתור דורש חור

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

מדוע הכפתור הוא הבעיה

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

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

העדכון הידני

הצעדים מניחים שהבלוג נמצא ב-/var/www/blog, בבעלות root, ניתן לקריאה לשרת הרשת, ורק wp-content/uploads ניתנת לכתיבה בידי www-data.

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

mysqldump -u blog -p blog > ~/backup/blog-$(date +%F).sql
sudo tar czf ~/backup/blog-files-$(date +%F).tar.gz -C /var/www blog

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

cd /tmp
wget https://wordpress.org/latest.tar.gz
wget https://wordpress.org/latest.tar.gz.md5
md5sum -c latest.tar.gz.md5
tar xzf latest.tar.gz

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

echo '<?php $upgrading = time(); ?>' | sudo tee /var/www/blog/.maintenance

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

cd /var/www/blog
sudo rm -rf wp-admin wp-includes
sudo cp -a /tmp/wordpress/wp-admin /tmp/wordpress/wp-includes .
sudo cp -a /tmp/wordpress/*.php .
sudo rm -f wp-config-sample.php

ה-cp -a של *.php דורס את קובצי השורש (index.php, wp-login.php, wp-settings.php והשאר) אבל לא את wp-config.php, מפני שהארכיון הטרי אינו מכיל כזה. אל תעתיקו את /tmp/wordpress/wp-content; זה היה דורס את ערכת העיצוב והתוספים שבברירת המחדל, מה שאינו מזיק, אבל זו גם הספרייה האחת שיש לכם סיבה להיזהר איתה.

שחזרו בעלות, ואז הריצו את שלב בסיס הנתונים. הקבצים החדשים בבעלות מי שפרק אותם; עשו אותם של root וניתנים לקריאה:

sudo chown -R root:root /var/www/blog
sudo chown -R www-data:www-data /var/www/blog/wp-content/uploads
sudo find /var/www/blog -type d -exec chmod 755 {} \;
sudo find /var/www/blog -type f -exec chmod 644 {} \;
sudo rm /var/www/blog/.maintenance

עכשיו פתחו את /wp-admin/upgrade.php בדפדפן. אם הגרסה שינתה את סכמת בסיס הנתונים, העמוד הזה מחיל את השינוי; אם לא, הוא אומר זאת. כך או כך העדכון הסתיים.

תוספים וערכות עיצוב באותה דרך

אותו היגיון חל על wp-content/plugins ועל wp-content/themes, ואותה שיטה עובדת: הורידו את הארכיון מעמוד התוסף, אמתו מה שאפשר, פרקו אותו על הספרייה הישנה כ-root, ואפסו את הבעלות. תיארתי את ריקוד ההרשאות לזה בפוסט האבטחה השני. זה איטי יותר מהכפתור. זו גם הדרך היחידה לעדכן תוסף בלי להעניק קודם לשרת הרשת את הזכות להתקין כל קוד שירצה.

הפכו את זה לסקריפט

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

מתי לעשות זאת

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