מדד ההקשחה של Lynis: מ-60 ל-85

ההרצה הראשונה של Lynis ב-VPS טרי נותנת בדרך כלל משהו סביב 60 ורשימה ארוכה של המלצות שבה לא ברור במה לאחוז ראשון. החדשות הטובות: 80 עד 85 הן עבודה של ערב אחד, ורוב הצעדים אינם קוסמטיים אלא באמת שווים. החדשות הרעות: חמש-עשרה הנקודות האחרונות בלתי מושגות במכונה וירטואלית שכורה, ולרדוף אחריהן זו טעות.

מה המדד מראה ומה לא

מדד ההקשחה הוא יחס המבחנים שעברו לסך הכול, עם משקלים — ולא אחוז אבטחה. Lynis מריץ כשלוש מאות מבחנים ומייצר שתי רשימות נפרדות: warnings שנראות כבעיות אמיתיות, ו-suggestions שהם דברים שאפשר היה לשפר. מתחילים תמיד מהאזהרות; בדרך כלל יש בודדות.

מאה נקודות אינן קיימות: חלק מההמלצות דורשות החלטות שהתקבלו בעת התקנת המערכת (מחיצות נפרדות ל-/home, ל-/tmp ול-/var), חלק דורשות גישה למנהל האתחול שאין ב-VPS, וחלק סותרות זו את זו. וגם להשוות את המדד שלכם לשל אחר הוא חסר טעם: Lynis מוריד נקודות על מה שרץ במכונה. כל שירות שרץ הוא עוד פורט פתוח, הגדרות משלו ותריסר המלצות חדשות — ולכן מספרים גבוהים נפוצים יותר במקום שבו לא רץ דבר מלבד SSH. לשרת עובד עם אתר, מסד נתונים ודואר, 85 היא תוצאה טובה.

הריצו כ-root

sudo lynis audit system

בלי sudo מדלג Lynis על כל מבחן שדורש קובצי מערכת ומדווח על מדד נמוך יותר — לא כי השרת גרוע אלא כי הבדיקות היו בלתי נראות. הדוח נכתב אל /var/log/lynis-report.dat, והיומן הקריא אל /var/log/lynis.log.

כל שורת פלט מתחילה במזהה מבחן, כמו SSH-7408 או KRNL-6000. במזהה הזה תמצאו גם את ההסבר וגם את הדרך לכבות את המבחן — זכרו את צורתו, כל מה שלמטה סובב סביבו.

מה באמת מזיז את המספר

SSH (SSH-7408). הבלוק הכבד ביותר: מבחן יחיד בודק תריסר פרמטרים בבת אחת. אל תערכו את כל sshd_config; הניחו קובץ נפרד כדי שעדכון חבילה לא ימחק את עבודתכם:

sudo tee /etc/ssh/sshd_config.d/10-hardening.conf <<'EOF'
PermitRootLogin no
PasswordAuthentication no
MaxAuthTries 3
MaxSessions 2
X11Forwarding no
AllowTcpForwarding no
ClientAliveInterval 300
ClientAliveCountMax 2
LogLevel VERBOSE
TCPKeepAlive no
EOF
sudo sshd -t && sudo systemctl reload ssh

הרצת sshd -t לפני טעינה מחדש של השירות היא חובה: שגיאה בהגדרות בזמן שההפעלה שלכם חיה תשאיר אתכם בחוץ. ולפני שאתם שמים PasswordAuthentication no, ודאו שהמפתח באמת עובד — ממסוף שני פתוח.

פרמטרי ליבה (KRNL-6000). המבחן בודק כעשרים ערכי sysctl. קובץ עבורם:

sudo tee /etc/sysctl.d/99-hardening.conf <<'EOF'
kernel.dmesg_restrict = 1
kernel.kptr_restrict = 2
kernel.sysrq = 0
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.log_martians = 1
EOF
sudo sysctl --system

כלים חסרים. חלק לא קטן מההמלצות הוא פשוט «התקינו את מה שאין»: auditd (רישום אירועי מערכת), aide (שלמות קבצים), debsums (שלמות חבילות), unattended-upgrades (עדכוני אבטחה אוטומטיים), sysstat ו-acct (רישום תהליכים), וסורק תוכנות זדוניות. כל אחד סוגר המלצה או שתיים, אבל אל תתקינו אותם בשביל הנקודות: בלעדיהם לא תשחזרו דבר אחרי אירוע.

דברים קטנים עם יחס טוב בין מאמץ לתמורה. umask 027 ב-/etc/login.defs; התיישנות סיסמאות באותו קובץ; הכרזות ב-/etc/issue וב-/etc/issue.net; ומהדרים שרק root יכול לקרוא (chmod 700 /usr/bin/gcc). ולגבי ההכרזות בכנות: לאבטחה הן אינן עושות דבר, זו פורמליות משפטית — אבל הן נותנות נקודה.

מלכודת אחת ב-login.defs

עריכת umask בהחלפת שורה באמצעות sed משאירה לעיתים קרובות כמה שורות UMASK בקובץ בבת אחת. אז Lynis אינו סופר את הערך והמבחן AUTH-9328 נשאר אדום אף שההגדרה נראית מוכנה. בדקו אחרי העריכה:

grep -c '^UMASK' /etc/login.defs

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

התראות שווא ואיך להשתיק אותן נכון

אזהרות מסוימות אינן נוגעות לשרת שלכם כלל. דוגמה חיה: ב-VPS של ספק גדול אחד המבחן PKGS-7388 מדווח שלא נמצא מאגר אבטחה — פשוט משום שהמאגרים מתוארים בתבנית deb822 עם הפניה לקובץ מראה, ו-Lynis מחפש את השורה המוכרת. ועדכוני האבטחה מגיעים מצוין.

השתיקו זאת לא במחיקת שורות מהדוח אלא בפרופיל. קובצי פרופיל משתמשים בסיומת .prf (לא .prof — כאן קל לאבד חצי שעה), והכללים שלכם הולכים ל-/etc/lynis/custom.prf:

skip-test=PKGS-7388
skip-test=KRNL-5788

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

מה לא לעשות

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

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