شاخص سخت‌سازی Lynis: از ۶۰ تا ۸۵

نخستین اجرای Lynis روی یک VPS تازه معمولاً چیزی نزدیک به ۶۰ می‌دهد و فهرست بلندی از توصیه‌ها که روشن نیست از کجا باید آغاز کرد. خبر خوش: ۸۰ تا ۸۵ کار یک شامگاه است و بیشتر گام‌ها آرایشی نیستند بلکه واقعاً ارزشش را دارند. خبر ناخوش: پانزده امتیاز آخر روی ماشین مجازی اجاره‌ای دست‌نیافتنی‌اند و دویدن به دنبالشان خطاست.

شاخص چه چیزی را نشان می‌دهد و چه چیزی را نه

شاخص سخت‌سازی نسبت آزمون‌های گذرانده به کل است، همراه با وزن‌ها — نه درصد امنیت. Lynis نزدیک به سیصد آزمون اجرا می‌کند و دو فهرست جداگانه می‌سازد: warnings که مانند مشکلات واقعی‌اند، و suggestions که چیزهایی‌اند که می‌شد بهترشان کرد. همیشه از هشدارها آغاز می‌شود؛ شمارشان معمولاً انگشت‌شمار است.

صد امتیاز وجود ندارد: برخی توصیه‌ها به تصمیم‌هایی نیاز دارند که هنگام نصب سامانه گرفته می‌شوند (پارتیشن‌های جداگانه برای /home، /tmp و /var)، برخی دسترسی به بارگذار راه‌انداز می‌خواهند که VPS ندارد، و برخی با یکدیگر ناسازگارند. و سنجیدن شاخص خود با شاخص دیگری بی‌معناست: Lynis برای آنچه روی ماشین اجرا می‌شود امتیاز کم می‌کند. هر سرویس در حال اجرا یعنی یک پورت باز دیگر، پیکربندی خودش و ده‌ها توصیه تازه — به همین دلیل اعداد بالا بیشتر جایی دیده می‌شوند که جز SSH چیزی اجرا نمی‌شود. برای سروری کارا با سایت و پایگاه داده و ایمیل، ۸۵ نتیجه خوبی است.

آن را با 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 ارزش دارد که بر پایه زمان‌بندی اجرا شود نه یک‌بار، و گزارش‌ها نگه داشته شوند تا چیزی برای سنجش باشد. شکل گردآمده این در یک صفحه را نمایش پایین نشان می‌دهد: شاخص، فهرست هشدارها با شناسه آزمون‌هایشان، و آنچه از اجرای پیشین تغییر کرده است.