אבטחת שרת לינוקס: צ'קליסט מעשי ל-Ubuntu 24.04

אבטחת שרת לינוקס היא לא מוצר שמתקינים אלא רשימת הרגלים. שרת ענן חדש עם כתובת IP ציבורית מתחיל לקבל ניסיונות התחברות אוטומטיים תוך זמן קצר מרגע שהוא עולה - מספיק להציץ בלוג של כמעט כל שרת כדי לראות את זה. הצ'קליסט הבא כתוב ל-Ubuntu 24.04 LTS, אבל כמעט הכול רלוונטי גם ל-Debian ובשינויים קלים גם ל-AlmaLinux ו-Rocky. אם עוד לא בחרתם מערכת הפעלה, ראו את עמוד שרת ענן לינוקס.

מה הצ'קליסט המלא לאבטחת שרת לינוקס?

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

איך מעדכנים שרת Ubuntu ומפעילים עדכוני אבטחה אוטומטיים?

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

sudo apt update && sudo apt full-upgrade -y
sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure --priority=low unattended-upgrades

כדי לוודא שהמנגנון פעיל, בדקו שהקובץ /etc/apt/apt.conf.d/20auto-upgrades מכיל:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

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

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";

בדיקה יבשה שמראה מה היה מותקן: sudo unattended-upgrade --dry-run --debug. הקובץ /var/run/reboot-required מופיע כשנדרש אתחול.

למה לא לעבוד כ-root ואיך יוצרים משתמש sudo?

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

adduser dana
usermod -aG sudo dana
# העתקת המפתחות המורשים של root למשתמש החדש (אם הותקן מפתח בהקמה)
rsync --archive --chown=dana:dana ~/.ssh /home/dana

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

איך מאבטחים SSH עם מפתחות ומבטלים כניסה בסיסמה?

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

מהמחשב המקומי:

ssh-keygen -t ed25519 -C "dana@laptop"
ssh-copy-id dana@203.0.113.10

ב-Ubuntu 24.04 עדיף לא לערוך את הקובץ הראשי אלא ליצור קובץ משלכם בתיקיית ההרחבות, כך שעדכוני חבילה לא ידרסו אותו:

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

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
LoginGraceTime 30
AllowUsers dana
X11Forwarding no

בודקים תקינות תחביר ורק אז טוענים מחדש:

sudo sshd -t && sudo systemctl reload ssh

איך מגדירים חומת אש ufw בשרת לינוקס?

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

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80,443/tcp      # רק אם זה שרת ווב
sudo ufw enable
sudo ufw status verbose

אם יש לכם IP קבוע במשרד, צמצמו את SSH אליו בלבד:

sudo ufw allow from 198.51.100.25 to any port 22 proto tcp
sudo ufw delete allow OpenSSH

מלכודת נפוצה: Docker עוקף את ufw וכותב חוקי iptables משלו, כך שקונטיינר שמפרסם פורט (למשל -p 5432:5432) חשוף לאינטרנט גם אם ufw "חוסם". פרסמו פורטים של קונטיינרים על 127.0.0.1 בלבד (-p 127.0.0.1:5432:5432) או השתמשו בחומת אש ברמת הרשת.

מה זה fail2ban ואיך מתקינים אותו?

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

sudo apt install fail2ban -y
sudo nano /etc/fail2ban/jail.local

[DEFAULT]
bantime  = 1h
findtime = 10m
maxretry = 5
backend  = systemd
ignoreip = 127.0.0.1/8 ::1 198.51.100.25

[sshd]
enabled = true

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

הוסיפו את כתובת המשרד ל-ignoreip כדי לא לחסום את עצמכם. בשרתי ווב אפשר להפעיל גם כלאות מוכנות כמו nginx-http-auth, או לכתוב פילטר לעמוד ההתחברות של וורדפרס.

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

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

• מה מאזין לרשת? sudo ss -tulpn - כל שורה שאינה מוכרת לכם היא שירות להסיר או לחסום.
• הסרת שירותים מיותרים: sudo apt purge <package> או sudo systemctl disable --now <service>.
• מסדי נתונים: MySQL ו-PostgreSQL צריכים להאזין ל-127.0.0.1 בלבד (bind-address / listen_addresses), עם משתמש DB נפרד לכל אפליקציה.
• קבצי אתר: שייכים למשתמש הפריסה, ושרת הווב מקבל הרשאת קריאה בלבד, חוץ מתיקיית ההעלאות. לעולם לא chmod 777.
• sudo מצומצם: משתמש שצריך רק להפעיל מחדש שירות אחד יקבל כלל ספציפי דרך visudo, לא הרשאות sudo מלאות.
• יחידות systemd: לשירותים שאתם כותבים בעצמכם הוסיפו NoNewPrivileges=yes, ProtectSystem=strict ו-PrivateTmp=yes.

איך מוסיפים TLS (HTTPS) לשרת?

כל שירות שנגיש מהאינטרנט - אתר, API, פאנל ניהול - צריך להצפין תעבורה ב-TLS. הדרך הפשוטה היא תעודה חינמית של Let's Encrypt דרך certbot, שמתחדשת אוטומטית.

sudo apt install certbot python3-certbot-nginx -y
sudo certbot --nginx -d example.co.il -d www.example.co.il
sudo certbot renew --dry-run

אחרי ההתקנה ודאו שהשרת מפנה מ-HTTP ל-HTTPS, שפרוטוקולים ישנים (TLS 1.0/1.1) כבויים, ושממשקים כמו phpMyAdmin אינם חשופים לכל העולם - עדיף לגשת אליהם דרך VPN או מנהרת SSH.

איזה גיבוי צריך שרת לינוקס?

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

דוגמה לגיבוי מוצפן ואינקרמנטלי עם restic ליעד חיצוני:

sudo apt install restic -y
export RESTIC_REPOSITORY=sftp:backup@backup.example.co.il:/srv/restic/web1
export RESTIC_PASSWORD_FILE=/root/.restic-pass
restic init
restic backup /etc /var/www /home --exclude-caches
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

למסדי נתונים - גבו dump ולא רק את קבצי התיקייה החיה (mysqldump --single-transaction או pg_dump). פעם ברבעון שחזרו לשרת בדיקה: גיבוי שלא נבדק הוא השערה. אם אתם מעדיפים פתרון מנוהל, ראו את שירות גיבוי ענן.

מה צריך לנטר בשרת לינוקס?

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

• זמינות: בדיקת HTTP/TCP חיצונית כל דקה, עם התראה במייל או בהודעה.
• משאבים: כלים כמו Netdata, Prometheus עם node_exporter, או Zabbix. התראה על דיסק מעל 80% חוסכת הרבה לילות.
• אבטחה: התראה על התחברות SSH מוצלחת מכתובת לא מוכרת ועל שינויים בקבצי מערכת.
• תעודות: התראה כשבועיים לפני פקיעת תעודת TLS, למקרה שהחידוש האוטומטי נכשל.

איך עושים Auditing ובודקים לוגים?

Auditing הוא תיעוד של מי עשה מה ומתי, כך שאפשר לחקור אירוע אחרי שקרה. ב-Ubuntu רוב המידע כבר נאסף ב-journald וב-auth.log - צריך לדעת לקרוא אותו ולשמור אותו מספיק זמן.

sudo journalctl -u ssh --since "24 hours ago"    # התחברויות SSH
last -n 20                                       # כניסות אחרונות
sudo grep sudo /var/log/auth.log | tail          # פקודות sudo
sudo apt install auditd -y
sudo auditctl -w /etc/passwd -p wa -k identity
sudo auditctl -w /etc/ssh/sshd_config -p wa -k sshd
sudo ausearch -k identity

כדי שחוקי auditd ישרדו אתחול, שמרו אותם בקובץ תחת /etc/audit/rules.d/. הכלי Lynis (sudo lynis audit system) מפיק דו״ח הקשחה עם המלצות - כדאי להריץ אותו אחרי ההקמה ופעם ברבעון. מומלץ גם להעביר לוגים לשרת מרוחק, כי תוקף שהשיג root יכול למחוק לוגים מקומיים. עסקים שחלות עליהם תקנות אבטחת המידע ימצאו רקע נוסף במדריך על תיקון 13 לחוק הגנת הפרטיות.

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

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

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