הגדרת שרת VPS חדש: מדריך אבטחה ל-10 דקות

עשר הדקות הראשונות קובעות את רמת האבטחה של השרת שלכם

שרת VPS חדש אינו מאובטח. מרגע שיש לו כתובת IP ציבורית, סורקים מנסים להתחבר אליו, והתמונה (image) המוגדרת כברירת מחדל מציבה בפניהם מטרה נוחה: חשבון root לרוב נגיש, סיסמאות לרוב מותרות, אין firewall, ושום דבר אינו מעודכן לפי לוח זמנים. החדשות הטובות הן שסגירת כל הפרצות הללו אורכת כעשר דקות ומספר פקודות. זהו ה-runbook שאני מריץ על כל שרת חדש לפני שאני מתקין עליו דבר.

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

דקה 1: עדכון המערכת

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

apt update && apt upgrade -y

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

דקה 2: יצירת משתמש רגיל עם הרשאות sudo

אל תמשיך לעבוד כ-root. צור משתמש עבור עצמך והענק לו הרשאות sudo:

adduser matt
usermod -aG sudo matt

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

דקה 4: הגדרת מפתחות SSH

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

ssh-keygen -t ed25519

לאחר מכן, העתיקו את החלק הציבורי לשרת:

ssh-copy-id matt@YOUR_SERVER

ssh-copy-id דורש שחיבור באמצעות סיסמה יהיה פעיל עבור המשתמש החדש; אם הוא כבר כבוי, העתיקו את ה-~/.ssh/authorized_keys של root לתוך /home/matt/.ssh/authorized_keys (בבעלות matt), או הדביקו את המפתח הציבורי שלכם לקובץ זה באופן ידני.

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

התנתקו והתחברו מחדש כ-matt באמצעות המפתח, וודאו שהחיבור עובד לפני שתעברו לשלב הבא. נעילת SSH לפני שווידאתם שניתן להיכנס עם מפתח היא הדרך שבה משתמשים נועלים את עצמם מחוץ לשרת. אם ניסיון ההתחברות מחזיר את השגיאה Permission denied (publickey), טפלו בכך כעת במקום לחזור לשימוש בסיסמה, כיוון שהודעה זו מכסה חמש תקלות שונות והפלט של ssh -v יציין איזו מהן היא התקלה הספציפית שלכם.

דקה 6: ביטול התחברות root וסיסמאות

כעת, כשהמפתח שלך פועל, סגור את שתי הדלתות שסורקים מסתמכים עליהן. השתמש בקובץ drop-in כדי ששדרוגי חבילות לא ידרסו את ההגדרות. תן לו את השם 00- כדי שימוין לפני 50-cloud-init.conf, שבו תמונות ענן של Ubuntu משתמשות כברירת מחדל ב-PasswordAuthentication yes; שירות sshd שומר את הערך הראשון שהוא קורא, לכן קובץ שימוין מאוחר יותר יתעלם מההגדרה ללא התראה:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

לאחר מכן, טען מחדש את SSH:

sudo systemctl restart ssh

בדוק את ההגדרות ש-sshd משתמש בהן בפועל, כדי שקובץ drop-in שנדחה לא יטעה אותך:

sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin'

כאשר סיסמאות מבוטלות והתחברות root חסומה, תעבורת ה-brute-force הבלתי פוסקת נגד השרת שלך פשוט לא תוכל להצליח. הטיפול המלא, כולל שינוי פורט אופציונלי, נמצא ב-הקשחת SSH בשרת VPS.

דקה 8: הפעלת ה-firewall

הגדירו מדיניות של default-deny לכל תעבורה נכנסת, ולאחר מכן אפשרו רק את מה שנחוץ. אפשרו SSH לפני הפעלת ה-firewall, אחרת תנותקו מהשרת:

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

הוסיפו חוקי allow עבור כל שירות שאתם מריצים בפועל, כגון 80/tcp ו-443/tcp עבור אתר אינטרנט. אם סשן SSH חדש מפסיק להתחבר לאחר מכן, קראו את השגיאה לפני שתבצעו שינויים, כיוון ש-סירוב חיבור מעיד על כך ש-sshd ענה, בעוד ש-timeout מעיד בדרך כלל על כך שה-firewall חסם את החבילה. ודאו שגם IPv4 וגם IPv6 מכוסים, שכן firewall שמסנן רק IPv4 משאיר את צד ה-IPv6 חשוף לחלוטין. המדריך המלא נמצא ב-מבוא ל-firewalls ב-VPS. פקודות ufw אלו מניחות שאתם משתמשים ב-Ubuntu או ב-Debian; בשרתי Rocky או AlmaLinux היעד של default-deny זהה, אך הכלי הוא firewalld, לכן עבדו לפי גרסת ה-firewalld של שלב זה במקום.

דקה 10: האטו את הסורקים בעזרת Fail2ban

לבסוף, הוסיפו את Fail2ban כדי לחסום כתובות שמנסות לבצע brute-force לפורטים שלכם:

sudo apt install -y fail2ban

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

רשימת הבדיקה שלך

זהו ה-runbook. השתמש במחולל להלן כדי לסמן כל בקרה ולהפיק רשימת בדיקה מותאמת אישית שתוכל לשמור לצד השרת, כולל הפקודה המדויקת לכל שלב:

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

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

FAQ

מה עלי לעשות תחילה ב-VPS חדש?

עדכנו את המערכת באמצעות apt update && apt upgrade -y, לאחר מכן צרו משתמש רגיל עם הרשאות sudo והפסיקו לעבוד כ-root. משם, הגדירו מפתחות SSH, בטלו התחברות כ-root ואימות באמצעות סיסמה, הפעילו firewall במדיניות של חסימה כברירת מחדל, והתקינו את Fail2ban. ביצוע השלבים לפי סדר זה מבטיח שכל שלב בטוח לביצוע מבלי להינעל מחוץ לשרת.

כיצד אוכל להימנע מנעילה מחוץ לשרת בעת הקשחת SSH?

הגדירו ובדקו את ההתחברות באמצעות מפתח SSH לפני שאתם מבטלים סיסמאות או גישת root. התנתקו והתחברו מחדש עם המפתח כדי לוודא שהוא עובד, ורק אז כבו את PasswordAuthentication ואת PermitRootLogin. כאשר אתם מפעילים את ה-firewall, אפשרו את פורט 22 לפני הרצת ufw enable. אם בכל זאת ננעלתם, מסוף הניהול (web console) של ספק השרתים יאפשר לכם להיכנס בחזרה ללא צורך ב-SSH.

האם אני באמת צריך את כל אלו בשרת קטן?

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

מהו הצעד החשוב ביותר?

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

כיצד אוכל לוודא שהשרת אכן מאובטח?

בדקו שלושה דברים באופן ידני לפני שאתם סומכים על ההגדרות. הריצו את sudo ss -tlnp וודאו שרק הפורטים שהתכוונתם לפתוח מאזינים בכתובת ציבורית, ללא שירות 0.0.0.0 או [::] ששכחתם. הריצו את sudo ufw status verbose וודאו שמדיניות ברירת המחדל לנכנסים היא deny ושהחוקים עבור IPv4 ו-(v6) קיימים. תמיד פתחו סשן SSH שני לפני שאתם סוגרים את הראשון, כך שטעות בתצורת ה-SSH לא תנעל אתכם מחוץ לשרת. אם שלושת הדברים נראים תקינים, הבסיס מוגדר כראוי.