הקשחת שרת Linux: צ'קליסט מעשי למערכות פרודקשן

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

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

מתחילים עם גישת משתמשים ו-SSH

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

כיבוי Root Login ואימות סיסמה

שני השינויים הראשונים שכדאי לבצע על כל שרת חדש:

# In /etc/ssh/sshd_config PermitRootLogin no PasswordAuthentication no PubkeyAuthentication yes

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

אחרי העריכה, טענו מחדש את ה-daemon:

systemctl reload sshd

שינוי פורט ה-SSH ברירת המחדל

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

# In /etc/ssh/sshd_config Port 2222

זכרו לפתוח את הפורט החדש בפיירוול לפני שטוענים מחדש את SSH, אחרת תינעלו בחוץ.

יצירת משתמש אדמין ייעודי

לעולם אל תשתמשו בשם משתמש גנרי כמו admin או ubuntu לגישה שוטפת. צרו משתמש בשם עם הרשאות sudo:

useradd -m -s /bin/bash yourname usermod -aG sudo yourname mkdir -p /home/yourname/.ssh cp ~/.ssh/authorized_keys /home/yourname/.ssh/ chown -R yourname:yourname /home/yourname/.ssh chmod 700 /home/yourname/.ssh chmod 600 /home/yourname/.ssh/authorized_keys

הגדרת פיירוול עם UFW

פיירוול הוא לא אופציה. במערכות Ubuntu ו-Debian, UFW נותן לכם ממשק פשוט ל-iptables שקשה לטעות בו.

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

ufw default deny incoming ufw default allow outgoing ufw allow 2222/tcp # Your custom SSH port ufw allow 80/tcp ufw allow 443/tcp ufw enable

בדקו את הסטטוס בכל עת:

ufw status verbose

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

שמרו את המערכת מעודכנת — אוטומטית

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

הפעלת Unattended Upgrades

על Debian/Ubuntu:

apt install unattended-upgrades dpkg-reconfigure --priority=low unattended-upgrades

הגדרות המפתח נמצאות ב-/etc/apt/apt.conf.d/50unattended-upgrades. לכל הפחות, הפעילו עדכוני אבטחה אוטומטיים:

Unattended-Upgrade::Allowed-Origins { "${distro_id}:${distro_codename}-security"; }; Unattended-Upgrade::Automatic-Reboot "false"; Unattended-Upgrade::Mail "you@yourdomain.com";

הגדרת Automatic-Reboot ל-false במערכות פרודקשן מאפשרת לכם לשלוט במתי מתבצעות הפעלות מחדש לצורך עדכוני kernel — חשוב לזמינות. תקבלו עדיין מייל כשנדרשת הפעלה מחדש.

בתוכניות אחסון מנוהלות, עדכוני kernel ותיקוני OS בדרך כלל מטופלים עבורכם. אבל אם אתם מנהלים VPS עצמאי, unattended upgrades הם לא אופציה.

הקשחת ה-Kernel עם sysctl

ה-Linux kernel חושף הרבה התנהגויות רשת וזיכרון דרך sysctl. כמה ברירות מחדל בסדר לפיתוח אבל צריך להדק אותן בשרתי פרודקשן.

הוסיפו את הבא ל-/etc/sysctl.d/99-hardening.conf:

# Disable IP source routing net.ipv4.conf.all.accept_source_route = 0 net.ipv6.conf.all.accept_source_route = 0 # Ignore ICMP redirects net.ipv4.conf.all.accept_redirects = 0 net.ipv6.conf.all.accept_redirects = 0 # Enable SYN flood protection net.ipv4.tcp_syncookies = 1 # Disable IP forwarding (unless this is a router) net.ipv4.ip_forward = 0 # Protect against time-wait assassination net.ipv4.tcp_rfc1337 = 1 # Restrict dmesg to root kernel.dmesg_restrict = 1 # Prevent core dumps from setuid programs fs.suid_dumpable = 0

החילו את השינויים מיד:

sysctl -p /etc/sysctl.d/99-hardening.conf

ביקורת על שירותים פעילים

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

ss -tulnp

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

systemctl stop service-name systemctl disable service-name

עברייני שכיחים בהתקנות ברירת מחדל כוללים: avahi-daemon, cups, ושירותי Bluetooth שונים — אף אחד מהם לא שייך על שרת פרודקשן headless.

הגדרת Fail2ban לזיהוי פריצות

Fail2ban מנטר קובצי לוג וחוסם זמנית IP-ים שמראים התנהגות זדונית — ניסיונות כניסה נכשלים חוזרים ב-SSH, למשל.

apt install fail2ban

צרו קובץ override מקומי (כדי שההגדרות שלכם ישרדו עדכוני חבילות):

cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

ואז הגדירו את ה-SSH jail ב-/etc/fail2ban/jail.local:

[sshd] enabled = true port = 2222 filter = sshd logpath = /var/log/auth.log maxretry = 4 bantime = 3600 findtime = 600

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

גיבויים: קו ההגנה האחרון שלכם

הקשחה מצמצמת את משטח התקיפה, אבל אין הקשחה מושלמת. אם משהו אכן משתבש — credential שנפרץ, zero-day, הגדרה שגויה — גיבויים הם מה שמאפשר לכם להתאושש בלי אובדן נתונים קטסטרופלי.

מדדי המפתח לכל אסטרטגיית גיבוי הם RPO (Recovery Point Objective) ו-RTO (Recovery Time Objective). RPO מגדיר כמה נתונים אתם יכולים להרשות לעצמכם לאבד; RTO מגדיר כמה מהר אתם צריכים לחזור לפעילות.

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

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

שרת מוקשח הוא שרת שמתוחזק

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

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

apt install lynis lynis audit system

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

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