יש טקס מעבר לכל מי שחדש בהרצת שרת משלו: אתם מחליטים להגדיר חומת אש, אתם מקלידים כמה פקודות ufw, אתם לוחצים enable — והטרמינל שלכם משתתק. SSH נעלם. לא קרסתם משהו, לא נפרצתם. פשוט נעלתם את הדלת עם עצמכם בחוץ.
זה קורה גם ל-sysadmins טובים. זה קרה לאחד מהלקוחות שלנו בשבוע שעבר, ולכן אני כותב את זה. החדשות הטובות: זה לגמרי בר-שחזור תוך פחות מדקה, ואתם לא צריכים להתקין מחדש או לאבד קובץ אחד. הנה איך.
מה בעצם השתבש
ufw (Uncomplicated Firewall) כברירת מחדל דוחה הכל נכנס. ברגע שאתם מריצים ufw enable, כל מה שלא התרתם במפורש נזרק — כולל סשן ה-SSH שאתם יושבים בו. אם שכחתם לעשות ufw allow לפורט ה-SSH שלכם קודם, חתכתם את החיבור שלכם עצמכם ברגע שהכלל נכנס לתוקף.
זו הגרסה הקלאסית. יש שני טעמים אחרים שתופסים אנשים:
- התרתם את הפורט הלא נכון. שגיאת הקלדה, או שהתרתם את פורט השירות (נניח 8080) ושכחתם את 22.
- התרתם 22 אבל אז הגדרתם כלל
denyגבוה יותר ברשימה שמצל עליו. ufw רגיש-סדר.
כך או כך השרת עצמו בסדר — רץ, דיסק שלם, האפליקציה שלכם עדיין מזמזמת מאחורי הקיר. זו טהורות בעיית גישה-לרשת. וזו בדיוק הסיבה שהתיקון קל.
המהלך הלא נכון: התקנה-מחדש
האינסטינקט הראשון הוא לעתים קרובות "פשוט אפס את השרת והתחל מחדש." אל — לא לזה. התקנה-מחדש מוחקת הכל כדי להחזיר SSH עובד, כשהדבר שחוסם את SSH הוא פקודת חומת אש אחת שאתם יכולים לבטל בעשר שניות. הייתם שורפים את הבית כי נעלתם את הדלת הקדמית.
התקנה-מחדש היא המהלך הנכון כשאתם רוצים לוח חלק. לנעילת ufw, זה מוגזם.
המהלך הנכון: הקונסולה של ה-web
כל VPS ששווה משהו נותן לכם קונסולה מחוץ-לפס — דרך למכונה שלא רוכבת מעל SSH או אפילו ה-network stack. ב-EQVPS זה כפתור ה-Console בעמוד השרת שלכם. זו serial console: טקסט-בלבד, מחוברת ישר ל-VM כמו שמסך ומקלדת היו. לכלל חומת אש אין כוח עליה, כי היא אינה תעבורת רשת.
לחצו עליו, התחברו עם אישורי ה-root שלכם (או חשפו את הסיסמה בפאנל אם אין לכם אותה בהישג יד), ואתם על הארגז — חומת אש או לא.
עכשיו בטלו את הנזק. הנתיב המהיר ביותר:
sudo ufw disable
זה מכבה את חומת האש ושומר את הכללים שלכם, כך שאתם יכולים להפעיל אותה שוב אחר כך ברגע שתיקנתם את הטעות. SSH חוזר ישר.
אם אתם מעדיפים לא להפיל את חומת האש לגמרי, פשוט פתחו את הפורט שפספסתם:
sudo ufw allow 22
sudo ufw status numbered
התצוגה status numbered שווה מבט — היא מראה את סדר הכללים, שם המקרים של "התרתי 22 אבל זה עדיין חוסם" מתחבאים. אם deny יושב מעל ה-allow שלכם, מחקו אותו עם sudo ufw delete <number>.
מלכודת ה-NAT שרוב המדריכים מפספסים
אם אתם בתוכנית NAT, יש מלכודת כאן. אתם מתחברים ב-SSH על פורט גבוה — משהו כמו 20266 — אז האינסטינקט הטבעי הוא ufw allow 20266. זה לא עושה כלום.
ב-NAT, הפורט החיצוני הזה מועבר לפורט 22 בתוך ה-VM. ufw רץ בתוך ה-VM ורואה אי-פעם רק 22. אז הכלל שאתם באמת צריכים הוא:
sudo ufw allow 22
התירו 20266 ותבהו בחיבור עדיין-שבור ותתהו למה. התירו 22 ואתם בפנים. אותו רעיון לכל שירות: התירו את הפורט שהתהליך מאזין עליו בתוך הארגז, לא את המועבר שאתם מתחברים אליו מבחוץ.
איך לעולם לא לעשות את זה שוב
התיקון לוקח דקה, אבל לא לצטרך אותו נחמד יותר. שני הרגלים:
התירו את פורט ה-SSH שלכם לפני שאתם מפעילים. בסדר הזה, תמיד:
sudo ufw allow 22
sudo ufw enable
עשו את זה הפוך ואתם חזרה בקונסולה.
שמרו סשן שני פתוח בזמן שאתם משנים כללי חומת אש. התחברו פעמיים. עשו את השינויים שלכם בחלון אחד; אם SSH מת, החלון השני עדיין חי כדי לתקן. טריק ישן, מציל אתכם כל פעם.
ואם אתם מגדירים ארגז טרי, רשימת התיוג לאבטחת VPS חדש שלנו מכסה את ufw בסדר הנכון, לצד מפתחות SSH וקומץ הדברים האחרים שבאמת חשובים בעשר הדקות הראשונות.
המסקנה
נעילת ufw נראית מפחידה והיא כמעט כלום. השרת אף פעם לא עזב; אתם פשוט צריכים דלת שחומת אש לא יכולה לטרוק — הקונסולה של ה-web — ופקודה אחת. שמרו את ufw disable ואת הקונסולה בכיס האחורי, התירו את הפורט לפני שאתם מפעילים בפעם הבאה, ולעולם לא תזיעו על זה שוב.
תגובות
אין עדיין תגובות. היו הראשונים.