איך לאבטח VPS: צ'ק־ליסט האבטחה לשעה הראשונה

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

שאר המדריך הוא הצ'ק־ליסט המלא, בסדר שבו כדאי לבצע אותו, עם פקודות ל‑Debian ו‑Ubuntu וגם למשפחת RHEL (כולל Rocky ו‑AlmaLinux). ומשפט אחד לפני הכול: חבילות ה‑VPS של Devoster הן unmanaged עם גישת root מלאה. כל סעיף כאן הוא באחריותכם, לא שלנו. אי אפשר לאבטח שרת שאתם מניחים בשקט שמישהו אחר מאבטח.

עיקרי הדברים

• הסדר חשוב יותר מכל הגדרה בודדת. בדקו התחברות עם מפתח בטרמינל שני לפני שאתם מבטלים סיסמאות, ופתחו את הפורט בפיירוול לפני שאתם מעבירים אליו את SSH. כמעט כל סיפור נעילה בחוץ הוא טעות סדר, לא טעות הגדרה.
• מפתחות SSH עם ביטול אימות סיסמה הם השינוי בעל הערך הגבוה ביותר ברשימה. הם מסיימים את איום ניחוש הסיסמאות במקום רק להאט אותו.
• העברת SSH מפורט 22 מקטינה מאוד את רעש הלוגים, אבל זו הסתרה ולא אבטחה. עושים את זה אחרי מפתחות ופיירוול, לעולם לא במקומם.
• ב‑Debian 12 ומעלה rsyslog כבר לא מותקן כברירת מחדל, ולכן ייתכן שאין קובץ /var/log/auth.log. ה‑jail של sshd ב‑Fail2ban יזדקק ל‑backend = systemd אחרת הוא פשוט לא יעלה.
• שרת בלי swap מאפשר ל‑OOM killer של הקרנל להרוג את מסד הנתונים בלחץ זיכרון. הגדרת swap לא עולה כלום ומונעת משפחה שלמה של תקלות בשלוש לפנות בוקר.
• גיבוי ששוכן על אותו VPS הוא לא גיבוי, וגיבוי שמעולם לא שחזרתם הוא השערה. קבעו תרגיל שחזור ביומן.

השעה הראשונה, לפי הסדר

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

שלב	משימה	למה דווקא כאן
1	עדכון כל החבילות	ה‑image שהרמתם נבנה לפני שבועות או חודשים.
2	יצירת משתמש עם sudo	צריך חלופת התחברות עובדת לפני שמבטלים את זו של root.
3	התקנת מפתח SSH ובדיקה שלו	חייב להצליח לפני שלב 4, ובטרמינל חדש.
4	הקשחת sshd והפעלה מחדש	בטוח רק אחרי שהוכחתם שהמפתח עובד.
5	פיירוול שחוסם הכול נכנס	לפני התקנת שרת web או מסד נתונים, לא אחריה.
6	Fail2ban	צריך מקור לוגים תקין, ולכן אחרי ש‑SSH יציב.
7	עדכוני אבטחה אוטומטיים	המנגנון היחיד שממשיך לעבוד כשאתם ישנים.
8	סנכרון שעון ו‑swap	משעמם, ובזכותו הלוגים ומסד הנתונים שורדים.
9	TLS, כותרות אבטחה, הסתרת גרסאות	רק כשיש שרת web בפועל.
10	נעילת מסד הנתונים	אחרי ההתקנה, לפני שהאפליקציה עולה לאוויר.
11	גיבוי מחוץ לשרת ותרגיל שחזור	אחרון ברשימה, ראשון שתרצו כשמשהו נשבר.

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

שלב 1-2: עדכון ומשתמש לא root

ב‑Debian ו‑Ubuntu הריצו sudo apt update && sudo apt upgrade -y, ובמשפחת RHEL sudo dnf upgrade -y. אם התעדכן קרנל, אתחלו עכשיו כשעדיין אין כלום על השרת.

אחר כך צרו משתמש: sudo adduser yourname. ב‑Debian ו‑Ubuntu מוסיפים אותו לקבוצה עם sudo usermod -aG sudo yourname, ובמשפחת RHEL הקבוצה נקראת wheel ולא sudo — בלבול בין השתיים הוא טעות נפוצה שמייצרת משתמש שלא יכול להסלים הרשאות בכלל. בדקו בטרמינל שני עם sudo whoami. אם חוזר root, אפשר להמשיך.

האם sudo צריך לדרוש סיסמה? כן, כמעט תמיד. sudo ללא סיסמה הופך כל באג הרצת קוד בכל דבר שהמשתמש מריץ ל‑root מיידי. היוצא מן הכלל הוא חשבון פריסה אוטומטי שמריץ רשימה מצומצמת ומפורשת של פקודות, וגם אז בקובץ תחת /etc/sudoers.d/ שמפרט אותן. ערכו תמיד עם sudo visudo -f /etc/sudoers.d/deploy כדי ששגיאת תחביר תיתפס לפני שהיא נועלת את sudo לגמרי.

שלב 3: אבטחת SSH עם מפתחות במקום סיסמאות

זה השלב הכי חשוב. סיסמה אפשר לנחש במהירות מכונה מרשת בוטים; מפתח של 256 ביט לא.

על המחשב שלכם, לא על השרת, צרו מפתח: ssh-keygen -t ed25519 -C "laptop-2026". Ed25519 הוא ברירת המחדל ההגיונית היום. השתמשו בסיסמת הגנה למפתח — לפטופ גנוב עם מפתח לא מוגן הוא שרת גנוב.

העתיקו את המפתח הציבורי עם ssh-copy-id yourname@your.server.ip. אם אין לכם את הכלי, הוסיפו את תוכן קובץ ה‑pub לתוך ~/.ssh/authorized_keys על השרת ותקנו הרשאות: chmod 700 ~/.ssh ו‑chmod 600 ~/.ssh/authorized_keys. SSH מסרב בשקט למפתחות בתיקייה עם הרשאות רחבות מדי, וזו הסיבה הנפוצה ביותר שמפתח שהועתק נכון עדיין לא עובד.

עכשיו בדקו בטרמינל חדש: ssh yourname@your.server.ip. רק אם נכנסתם בלי סיסמה — ממשיכים.

עריכת הגדרות שרת ה‑SSH

ב‑Ubuntu וב‑Debian יש בראש /etc/ssh/sshd_config את השורה Include /etc/ssh/sshd_config.d/*.conf, ו‑OpenSSH משתמש בערך הראשון שהוא מוצא לרוב ההגדרות. כלומר קובץ drop-in גובר על מה שתערכו למטה בקובץ הראשי. הרבה image‑ים של ספקים כוללים drop-in שמחזיר אימות סיסמה למצב פעיל.

לכן קודם כול הסתכלו: ls -l /etc/ssh/sshd_config.d/ וקראו מה שיש שם. אחר כך כתבו את ההגדרות שלכם בקובץ שממוין מוקדם, למשל /etc/ssh/sshd_config.d/00-hardening.conf:

• PermitRootLogin no — ברירת המחדל של OpenSSH היא prohibit-password, לא no, אז זה שינוי אמיתי.
• PasswordAuthentication no
• KbdInteractiveAuthentication no — ביטול סיסמאות לבדו עלול להשאיר פתוח מסלול keyboard-interactive דרך PAM.
• MaxAuthTries 3 — ברירת המחדל היא 6.
• AllowUsers yourname — רשימת היתר עדיפה על רשימת חסימה.

בדקו תחביר לפני הפעלה מחדש: sudo sshd -t. שקט פירושו שהכול נקרא כשורה. אחר כך sudo systemctl restart ssh ב‑Debian וב‑Ubuntu, או sudo systemctl restart sshd במשפחת RHEL. השאירו את החיבור הישן פתוח וודאו שהתחברות חדשה עובדת.

שינוי פורט ה‑SSH: בלי לספר סיפורים

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

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

אם עושים זאת, הסדר קריטי: קודם פותחים את הפורט החדש בפיירוול. במשפחת RHEL צריך גם לתייג אותו ל‑SELinux, אחרת sshd לא יורשה להאזין לו: sudo semanage port -a -t ssh_port_t -p tcp 2222 (הכלי מגיע מהחבילה policycoreutils-python-utils). רק אז משנים, מפעילים מחדש ובודקים מטרמינל חדש לפני שסוגרים את 22.

מלכודת מודרנית: מ‑Ubuntu 22.10 ואילך sshd עולה דרך socket activation של systemd (ssh.socket), כך שהפורט שייך ל‑systemd ולא ל‑sshd. בגרסאות 22.10 עד 23.10 הפורט הועבר לקובץ תחת /etc/systemd/system/ssh.socket.d/, ועריכת Port ב‑sshd_config לבדה לא עושה כלום. ב‑24.04 LTS הפורט נמשך דינמית מהגדרות sshd על ידי generator של systemd, כך שהעריכה כן עובדת — אבל רק אחרי sudo systemctl daemon-reload. בדקו במה אתם עם systemctl is-enabled ssh.socket, ואשרו את התוצאה עם sudo ss -tlnp | grep ssh במקום להניח.

שלב 4: פיירוול שחוסם כברירת מחדל

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

ב‑Ubuntu וב‑Debian: sudo ufw default deny incoming, sudo ufw default allow outgoing, sudo ufw allow OpenSSH, ואם השרת מגיש אתרים גם sudo ufw allow 80/tcp ו‑sudo ufw allow 443/tcp. לסיום sudo ufw enable ואז sudo ufw status verbose.

במשפחת RHEL, firewalld כבר רץ: sudo firewall-cmd --permanent --add-service=ssh, sudo firewall-cmd --permanent --add-service=http --add-service=https, ואז sudo firewall-cmd --reload ו‑sudo firewall-cmd --list-all.

אחר כך בדקו מי באמת מאזין: sudo ss -tulpn. כל שורה שמאזינה על 0.0.0.0 נגישה מהאינטרנט אם הפיירוול מרשה. מסד נתונים, Redis או exporter של מטריקות על ממשק ציבורי הם הדרך הקלאסית לעקוף SSH מוקשח לחלוטין.

החריג של Docker שאף אחד לא מזהיר עליו

אם תתקינו Docker, ufw מפסיק להגן על פורטים שפורסמו מקונטיינרים. התיעוד של Docker אומר זאת מפורשות: תעבורה לפורטים שפורסמו מוסטת בטבלת nat לפני שהיא מגיעה לשרשרת INPUT שבה ufw משתמש, כך שחוקי הפיירוול נעקפים בפועל. קונטיינר עם -p 8080:80 חשוף לאינטרנט גם אם ufw status טוען אחרת. הפתרון הפשוט הוא לפרסם לכתובת מקומית בלבד — -p 127.0.0.1:8080:80 — ולשים reverse proxy מלפנים. בדקו מבחוץ עם nmap ממחשב אחר.

שלב 5: Fail2ban

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

התקינו עם sudo apt install fail2ban, או sudo dnf install fail2ban אחרי הפעלת EPEL במשפחת RHEL. אל תערכו את jail.conf — עדכוני חבילה דורסים אותו. צרו /etc/fail2ban/jail.local עם מקטע [DEFAULT] שמגדיר bantime = 1h, findtime = 10m ו‑maxretry = 3, ומקטע [sshd] עם enabled = true. ברירות המחדל בחבילה הן חסימה של 10 דקות ו‑5 ניסיונות, כלומר סלחניות יותר ממה שרוב האנשים רוצים.

וכאן הנקודה שמפילה אנשים ב‑Debian מודרני: מ‑Debian 12 ואילך rsyslog לא מותקן כברירת מחדל, ולכן ייתכן שאין בכלל /var/log/auth.log והלוגים קיימים רק ב‑journal של systemd. במצב הזה backend = auto לא מוצא מקור לוגים וה‑jail של sshd לא עולה. הוסיפו backend = systemd למקטע [DEFAULT] והוא יקרא ישירות מה‑journal.

ואז ודאו שזה באמת רץ, כי Fail2ban שנכשל בשקט גרוע מכלום — הוא מייצר ביטחון מדומה. הריצו sudo fail2ban-client status לרשימת ה‑jails הפעילים ו‑sudo fail2ban-client status sshd למוני החסימות. אם ה‑jail לא מופיע, הוא לא עלה. הוסיפו את ה‑IP הקבוע של המשרד ל‑ignoreip אם יש לכם כזה.

שלב 6: עדכוני אבטחה אוטומטיים

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

Debian ו‑Ubuntu. התקינו unattended-upgrades והריצו 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";. אימות: apt-config dump APT::Periodic::Unattended-Upgrade. כברירת מחדל מוחל רק מקור האבטחה, וזו ההתנהגות הרצויה בייצור. אם תפעילו אתחול אוטומטי, הגדירו גם שעה קבועה לו.

משפחת RHEL. התקינו dnf-automatic, וב‑/etc/dnf/automatic.conf הגדירו upgrade_type = security ו‑apply_updates = yes. אחר כך sudo systemctl enable --now dnf-automatic.timer. קיימים גם טיימרים ייעודיים כמו dnf-automatic-install.timer; הפעילו אחד בלבד. אימות: systemctl list-timers | grep dnf.

האוטומציה לא מכסה הכול. תלויות אפליקציה — חבילות Composer, מודולי npm, תוספי WordPress — נמצאות מחוץ למנהל החבילות ונשארות באחריותכם.

שלב 7: סנכרון שעון ו‑swap

סטיית שעון שוברת אימות תעודות TLS, פוסלת קודי 2FA מסוג TOTP, מבלבלת את סדר הלוגים בזמן חקירה וגורמת לכשלי אימות מסתוריים מול APIים חיצוניים. בדקו עם timedatectl ששורת הסנכרון מציגה yes. הגדירו אזור זמן במפורש. על שרתים כדאי sudo timedatectl set-timezone UTC ולא Asia/Jerusalem — שעון קיץ ישראלי בלוגים הוא כאב ראש מיותר בדיוק כשאתם מנסים לשחזר רצף אירועים. Ubuntu השתמשה היסטורית ב‑systemd-timesyncd, ומ‑25.10 chrony הוא הלקוח שמותקן כברירת מחדל; במשפחת RHEL זה chrony עם chronyc tracking.

למה היעדר swap הורג את MySQL

הרבה image‑ים מגיעים בלי swap בכלל. כשלינוקס נגמר הזיכרון ואין לאן לדחוף דפים, ה‑OOM killer של הקרנל בוחר תהליך להרוג. השיטה שלו מעדיפה את התהליך שצורך הכי הרבה זיכרון — שעל שרת web טיפוסי זה מסד הנתונים. MySQL או MariaDB נעלמים, האתר מתחיל להחזיר שגיאות חיבור, ובלוג של מסד הנתונים אין הסבר, כי התהליך לא הספיק לכתוב כלום. הראיה נמצאת ב‑dmesg או ב‑journalctl -k.

קובץ swap צנוע נותן לקרנל לאן לדחוף דפים קרים בזמן שיא, כך שגל תנועה קצר מייצר דקה איטית במקום מסד נתונים מת. בחבילות קטנות פי אחד עד פי שניים מהזיכרון זו נקודת פתיחה סבירה, מוגבלת בשטח הדיסק — על נפח של 25 ג'יגה זה 2 ג'יגה swap, לא 16.

• sudo fallocate -l 2G /swapfile
• sudo chmod 600 /swapfile
• sudo mkswap /swapfile ואז sudo swapon /swapfile
• הוסיפו /swapfile none swap sw 0 0 ל‑/etc/fstab כדי שישרוד אתחול
• sudo sysctl vm.swappiness=10, ושמרו את זה ב‑/etc/sysctl.d/99-swappiness.conf

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

שלב 8: שכבת ה‑web

Certbot ממליץ ברוב המערכות על התקנה דרך snap: sudo snap install --classic certbot ואחריה sudo ln -s /snap/bin/certbot /usr/local/bin/certbot. איפה ש‑snap לא מתאים, EFF מתעדת התקנה דרך pip בסביבה וירטואלית תחת /opt/certbot/.

הנפיקו עם sudo certbot --nginx או sudo certbot --apache. השלב הקריטי הוא זה שמדלגים עליו: sudo certbot renew --dry-run. Certbot אמנם מתקין טיימר או cron לחידוש אוטומטי, אבל רק ההרצה היבשה מוכיחה שהחידוש עובד עם חוקי הפיירוול, ה‑vhost וה‑DNS הנוכחיים שלכם. תעודה שפגה בשבת בבוקר היא כמעט תמיד חידוש שנכשל בשקט חודשיים.

לכותרות אבטחה, בסיס סביר לפי ההנחיות של Mozilla: Strict-Transport-Security: max-age=63072000; includeSubDomains, X-Content-Type-Options: nosniff, X-Frame-Options: DENY ו‑Referrer-Policy: strict-origin-when-cross-origin. אזהרה אחת: את ההנחיה preload קשה מאוד לבטל, אז אל תוסיפו אותה לפני שאתם בטוחים שכל תת־דומיין יגיש HTTPS לתמיד.

לבסוף, הפסיקו לפרסם מספרי גרסה. ב‑nginx הגדירו server_tokens off; במקטע http — לפי התיעוד זה מפסיק להציג את גרסת nginx בדפי שגיאה ובכותרת Server. ב‑Apache הגדירו ServerTokens Prod ו‑ServerSignature Off, וב‑PHP הגדירו expose_php = Off. זו עמידות מול טביעת אצבע, לא הגנה: היא מייתרת לסורק את ההתאמה המיידית בין הגרסה שלכם לרשימת בעיות ידועות. עדכנו בכל מקרה.

שלב 9: הקשחת מסד הנתונים

מסד נתונים חשוף הוא הדרך הקצרה ביותר מ"מישהו סרק לי את ה‑IP" ל"למישהו יש את טבלת הלקוחות שלי".

התחילו בקשירה ל‑loopback: ב‑MySQL או MariaDB הגדירו bind-address = 127.0.0.1, ב‑PostgreSQL listen_addresses = 'localhost', וב‑Redis bind 127.0.0.1 יחד עם requirepass. אם האפליקציה רצה על אותו שרת, למסד הנתונים אין שום סיבה להאזין לממשק ציבורי. אמתו עם sudo ss -tulpn | grep 3306 וודאו שמופיע 127.0.0.1:3306 ולא 0.0.0.0:3306.

אחר כך הריצו sudo mysql_secure_installation (ב‑MariaDB אותו כלי נקרא גם mariadb-secure-installation). הוא מגדיר סיסמת root, מסיר חשבונות אנונימיים, חוסם התחברות root מרחוק ומוחק את מסד הנתונים test שנגיש כברירת מחדל לכל משתמש.

ולבסוף הרשאות מינימום למשתמש האפליקציה. האפליקציה לא צריכה ALL PRIVILEGES ובוודאי לא GRANT OPTION. צרו משתמש ייעודי שמוגבל למסד נתונים אחד ולמארח אחד, עם SELECT, INSERT, UPDATE, DELETE בלבד. כשיצוץ באג הזרקת SQL בקוד שלכם, ההבדל בין ההרשאה הזו לבין הרשאות מלאות הוא ההבדל בין דליפת נתונים לבין השתלטות מלאה על השרת.

שלב 10: גיבויים ששחזרתם בפועל

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

שאפו למבנה 3‑2‑1: שלושה עותקים, בשני סוגי מדיה או שירותים, אחד מחוץ לאתר. בפועל על VPS זה אומר הנתונים החיים, snapshot של הספק, ועותק מוצפן שנדחף לאחסון אובייקטים במקום אחר לגמרי.

• ייצאו מסדי נתונים כמו שצריך במקום להעתיק קבצים גולמיים משרת פעיל. mysqldump --single-transaction נותן עותק עקבי של טבלאות InnoDB בלי לנעול את האתר.
• הצפינו לפני העלאה לאחסון של צד שלישי. restic ו‑BorgBackup עושים הצפנה ודה‑דופליקציה בשבילכם.
• השתמשו בהרשאות append-only ליעד הגיבוי היכן שהספק תומך. אם השרת נפרץ ויש לו הרשאת מחיקה, גם לתוקף יש.
• שמרו יותר מדור אחד. שחיתות נתונים שהתגלתה ביום חמישי חסרת ערך אם רביעי כבר דרס את העותק התקין האחרון.
• נטרו את משימת הגיבוי עצמה. cron שנכשל בשקט שישה שבועות הוא כשל הגיבוי הנפוץ ביותר שקיים.

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

שוטף: ניטור וקריאת לוגים

הקשחה היא מצב שיוצאים ממנו, לא מצב שמגיעים אליו. שגרה קצרה שומרת עליה.

שבועית, חמש דקות: sudo fail2ban-client status sshd למוני חסימות, lastb | head -20 להתחברויות כושלות, last | head -20 להתחברויות מוצלחות (כל התחברות שאתם לא יכולים להסביר היא אירוע אבטחה), df -h לשטח דיסק, ו‑sudo ss -tulpn כדי לתפוס שירות חדש שלא התכוונתם אליו. חודשית: ודאו שעדכונים אוטומטיים עדיין מוחלים, שההרצה היבשה של חידוש התעודה עדיין עוברת, ושהגיבוי האחרון באמת הסתיים.

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

הגנת DDoS היא לא הקשחת שרת

חבילות ה‑VPS של Devoster כוללות הגנת DDoS בקצה הרשת. זה אמיתי ושימושי: היא בולעת מתקפות נפח לפני שהן חונקות את הקו, בעיה שאי אפשר לפתור מתוך המכונה עצמה.

אבל זו שכבה אחרת לגמרי ממה שכתוב במאמר הזה. סינון בקצה לא מתעניין בשאלה אם סיסמת ה‑SSH שלכם היא admin123, אם MySQL קשור ל‑0.0.0.0, או אם ה‑WordPress שלכם מפגר בשנתיים. ההתקפות האלה מגיעות כתעבורה שנראית לגיטימית, בפורטים שאתם פתחתם בכוונה. הגנת רשת והקשחת מארח פותרות בעיות שאינן חופפות, וצריך את שתיהן. חבילות ה‑VPS שלנו נותנות את צד הרשת; הצ'ק־ליסט הזה הוא החצי השני.

אם אתם חושבים שנפרצתם: לבנות מחדש, לא לנקות

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

ברגע שלתוקף הייתה גישת root, אי אפשר להאמין לשום דבר שהמכונה מספרת. אפשר להחליף את ps כדי להסתיר תהליך ואת ls כדי להסתיר קובץ, ומודול קרנל יכול להסתיר את שניהם מכל כלי שתריצו. הסרת ה‑webshell שמצאתם לא אומרת דבר על משימת ה‑cron, על מפתח ה‑SSH שנוסף, על יחידת systemd ששונתה או על ה‑webshell השני שלא מצאתם.

1. בודדו. נתקו מהרשת או צמצמו את הפיירוול ל‑IP שלכם בלבד. אל תכבו אם אתם מתכוונים לחקור.
2. צלמו. קחו image מלא לצורכי חקירה וראיות לפני שאתם משנים משהו.
3. החליפו כל סוד. סיסמאות מסד נתונים, מפתחות API, מפתחות SSH, פרטי דואר, טוקנים של סליקה. הניחו שהכול פומבי.
4. בנו מחדש מ‑image נקי ולא מ‑snapshot שנלקח אחרי הפריצה, אחרת אתם משחזרים גם את הפריצה.
5. שחזרו נתונים, לא בינאריים. החזירו dump של מסד הנתונים וקבצי משתמשים. התקינו את האפליקציה מחדש מקוד מקור או מחבילות רשמיות.
6. הבינו איך נכנסו לפני שאתם עולים לאוויר, אחרת פשוט תיפרצו שוב. בדרך כלל זו אפליקציה לא מעודכנת, סוד שדלף או שירות חשוף.

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

טבלת פקודות לפי הפצה

משימה	Debian / Ubuntu	RHEL / Rocky / AlmaLinux
עדכון כל החבילות	sudo apt update && sudo apt upgrade	sudo dnf upgrade
קבוצת מנהלים	sudo	wheel
שם שירות SSH	ssh (וגם ssh.socket מ‑22.10)	sshd
פיירוול	ufw	firewalld
פתיחת HTTPS	sudo ufw allow 443/tcp	sudo firewall-cmd --permanent --add-service=https
עדכוני אבטחה אוטומטיים	unattended-upgrades	dnf-automatic עם timer
מקור Fail2ban	המאגר הראשי	EPEL
בקרת גישה מחייבת	AppArmor	SELinux
פורט SSH לא סטנדרטי דורש	חוק פיירוול (ומודעות ל‑socket unit)	חוק פיירוול ו‑semanage port
סנכרון שעון	systemd-timesyncd (chrony מ‑25.10)	chrony

מתי VPS הוא הבחירה הלא נכונה

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

ותרו על VPS אם אתם מפעילים אתר תדמית או WordPress קטן ואין לכם שום עניין בניהול מערכות — אחסון אתרים משותף מטפל בעדכוני מערכת, פיירוול ו‑TLS בשבילכם ועושה זאת היטב. ותרו גם אם אתם צריכים מישהו אחראי בשלוש לפנות בוקר כשמסד הנתונים לא עולה: unmanaged אומר שהקונסולה שלכם וגם התקלה שלכם, בעוד אחסון מנוהל שם בן אדם בצד השני. וגם אם לצוות שלכם אין ניסיון בלינוקס — VPS מוזנח מאובטח פחות מאחסון משותף מנוהל היטב, והפרש המחיר לא מתקרב לעלות של פריצה.

קחו VPS אם אתם צריכים root מסיבה מוגדרת: סביבות מותאמות, גרסאות PHP או Node ספציפיות, תהליכי רקע, קונטיינרים, סביבות בדיקה או משאבים ייעודיים וצפויים. גישת root היא המוצר. הצ'ק־ליסט הזה הוא המחיר שלה. אם אתם לא בטוחים באיזה צד של הקו אתם נמצאים, דברו איתנו לפני הרכישה.

שאלות נפוצות

כמה זמן לוקח לאבטח VPS חדש?

הסעיפים המרכזיים — משתמש sudo, מפתחות SSH, הקשחת sshd, פיירוול חוסם, Fail2ban ועדכונים אוטומטיים — לוקחים כחצי שעה למי שנוח לו בטרמינל, ושעה עד שעתיים בפעם הראשונה. שכבות ה‑web, מסד הנתונים והגיבוי מוסיפות עוד שעה. אחר כך תכננו כרבע שעה בחודש לבדיקות שוטפות.

האם באמת שווה לשנות את פורט ה‑SSH?

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

צריך Fail2ban אם כבר ביטלתי אימות בסיסמה?

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

מה קורה אם נעלתי את עצמי בחוץ?

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

האם Devoster מאבטחת לי את השרת?

לא. חבילות ה‑VPS של Devoster הן unmanaged עם גישת root מלאה, כך שמערכת ההפעלה, הפיירוול, העדכונים ואבטחת האפליקציה הם באחריותכם. אנחנו מספקים וירטואליזציית KVM, אחסון NVMe, רשת, הגנת DDoS בקצה והעברה חינם. אם אתם רוצים שמערכת ההפעלה תנוהל עבורכם, בדקו אחסון מנוהל או משותף.

כמה swap צריך ב‑VPS קטן?

פי אחד עד פי שניים מהזיכרון היא נקודת פתיחה סבירה בחבילות קטנות, מוגבלת בשטח הדיסק הפנוי — 2 ג'יגה על נפח של 25 ג'יגה, לא 16. שלבו עם vm.swappiness=10 כדי שהקרנל יתייחס ל‑swap כרשת ביטחון. אם השרת מחליף דפים ברציפות ולא מדי פעם, קנו יותר זיכרון.