Server Hardening چیست؟ چک‌لیست کامل امن‌سازی سرور لینوکس برای وب‌سایت

Server Hardening چیست؟ سخت‌سازی سرور یا Server Hardening مجموعه‌ای از اقدامات امنیتی برای کاهش سطح حمله (Attack Surface)، جلوگیری از دسترسی غیرمجاز، محدودسازی سرویس‌های آسیب‌پذیر و افزایش مقاومت سرور در برابر حملات سایبری است. در سرورهای لینوکسی، این فرایند شامل ایمن‌سازی SSH، پیکربندی فایروال، مدیریت دسترسی کاربران، نصب به‌روزرسانی‌های امنیتی، محافظت از وب‌سرور و پایگاه داده، فعال‌سازی سیستم‌های نظارتی و تهیه نسخه پشتیبان مطمئن می‌شود.

اگر یک وب‌سایت وردپرسی، فروشگاه ووکامرسی، اپلیکیشن تحت وب یا چندین سرویس اینترنتی روی سرور لینوکس اجرا می‌کنید، صرف نصب سیستم‌عامل و راه‌اندازی وب‌سرور برای تأمین امنیت کافی نیست. حتی یک تنظیم اشتباه در SSH، مجوزهای فایل یا سرویس پایگاه داده می‌تواند مسیر نفوذ به زیرساخت را فراهم کند.

در این راهنمای جامع، مراحل امن‌سازی سرور لینوکس برای وب‌سایت را به‌صورت عملی بررسی می‌کنیم و در پایان، چک‌لیستی برای ارزیابی و نگهداری امنیت سرور ارائه خواهیم داد.

Server Hardening چیست و چرا اهمیت دارد؟

Server Hardening به فرایند اصلاح و تقویت تنظیمات سیستم‌عامل، شبکه، سرویس‌ها و نرم‌افزارهای سرور گفته می‌شود تا احتمال سوءاستفاده از ضعف‌های امنیتی کاهش پیدا کند.

هر سرور معمولاً دارای اجزای متعددی است؛ از هسته لینوکس و سرویس SSH گرفته تا Nginx، Apache، PHP، MySQL، سیستم مدیریت فایل و ابزارهای مانیتورینگ.

هرکدام از این اجزا ممکن است در صورت پیکربندی نامناسب به نقطه ورود مهاجم تبدیل شوند.

برای مثال، تصور کنید یک سرور Ubuntu دارای شرایط زیر باشد:

• دسترسی مستقیم SSH برای کاربر root فعال باشد.
• ورود با رمز عبور ضعیف امکان‌پذیر باشد.
• پورت پایگاه داده در اینترنت قابل‌دسترسی باشد.
• سیستم‌عامل مدت زیادی به‌روزرسانی نشده باشد.
• سرویس‌های بلااستفاده همچنان فعال باشند.
• فایل‌های حساس وب‌سایت مجوزهای بیش از حد داشته باشند.
• نسخه پشتیبان مستقل و آزمایش‌شده‌ای وجود نداشته باشد.

ممکن است وب‌سایت از نظر ظاهری کاملاً سالم باشد، اما این شرایط ریسک نفوذ به زیرساخت را افزایش می‌دهند.

سخت‌سازی سرور با شناسایی و کاهش این ریسک‌ها تلاش می‌کند یک محیط عملیاتی کنترل‌شده ایجاد کند.

هدف اصلی Server Hardening چیست؟

هدف اصلی سخت‌سازی سرور، غیرممکن کردن تمام حملات نیست؛ زیرا هیچ سیستم متصل به اینترنت را نمی‌توان کاملاً مصون دانست.

هدف، کاهش احتمال موفقیت حملات و محدود کردن پیامدهای نفوذ احتمالی است.

این هدف از طریق چند اصل اساسی دنبال می‌شود:

کاهش سطح حمله: حذف سرویس‌ها، پورت‌ها و قابلیت‌هایی که ضرورتی برای عملکرد سرور ندارند.

اصل حداقل دسترسی: اعطای فقط مجوزهایی که کاربران و سرویس‌ها واقعاً به آن‌ها نیاز دارند.

دفاع چندلایه: استفاده هم‌زمان از کنترل‌های امنیتی مختلف، به‌گونه‌ای که شکست یک کنترل به معنی نفوذ کامل نباشد.

نظارت مستمر: شناسایی تغییرات، رفتارهای مشکوک و خطاهای امنیتی.

بازیابی‌پذیری: فراهم کردن امکان بازگردانی خدمات پس از خرابی، حمله باج‌افزاری یا اشتباه مدیریتی.

تفاوت سرور معمولی با سرور Hardened

نکته مهم این است که Hardened بودن یک وضعیت دائمی نیست. سروری که امروز به‌درستی پیکربندی شده، ممکن است چند ماه بعد به دلیل نصب نرم‌افزار جدید، تغییر تنظیمات یا انتشار آسیب‌پذیری امنیتی، دوباره در معرض خطر قرار بگیرد.

چرا امن‌سازی سرور لینوکس برای وب‌سایت ضروری است؟

لینوکس به دلیل پایداری، انعطاف‌پذیری و امکانات مدیریتی گسترده، یکی از سیستم‌عامل‌های رایج در میزبانی وب‌سایت‌هاست.

اما استفاده از لینوکس به‌تنهایی امنیت ایجاد نمی‌کند.

امنیت واقعی به نسخه سیستم‌عامل، تنظیمات، نرم‌افزارهای نصب‌شده و شیوه مدیریت زیرساخت بستگی دارد.

جلوگیری از دسترسی غیرمجاز

یکی از مهم‌ترین تهدیدهای سرورهای اینترنتی، تلاش برای دسترسی غیرمجاز به حساب‌های مدیریتی است.

مهاجمان ممکن است از رمزهای افشاشده، کلیدهای سرقت‌شده یا آسیب‌پذیری‌های نرم‌افزاری استفاده کنند.

ایمن‌سازی SSH، محدودسازی دسترسی مدیریتی و استفاده از احراز هویت مناسب می‌تواند این خطر را کاهش دهد.

محافظت از اطلاعات کاربران

وب‌سایت‌ها ممکن است اطلاعاتی مانند مشخصات حساب کاربری، تاریخچه سفارش‌ها، اطلاعات تماس و توکن‌های احراز هویت را نگهداری کنند.

نفوذ به سرور می‌تواند محرمانگی و یکپارچگی این اطلاعات را به خطر بیندازد.

در فروشگاه‌های اینترنتی و سامانه‌های دارای اطلاعات حساس، این موضوع اهمیت بیشتری دارد.

جلوگیری از تغییر فایل‌های سایت

اگر یک مهاجم به حساب کاربری دارای مجوز نوشتن دسترسی پیدا کند، ممکن است بتواند فایل‌های سایت را تغییر دهد.

این وضعیت می‌تواند به تزریق بدافزار، تغییر محتوای صفحات یا ایجاد دسترسی‌های پنهان منجر شود.

تنظیم مجوزهای فایل، جداسازی سرویس‌ها و پایش تغییرات از اقدامات مؤثر در کاهش این خطر هستند.

افزایش پایداری خدمات

بعضی اقدامات سخت‌سازی علاوه بر امنیت، قابلیت اطمینان سیستم را نیز افزایش می‌دهند.

برای مثال، مدیریت صحیح منابع، نظارت بر ظرفیت دیسک و حذف سرویس‌های اضافی می‌تواند احتمال اختلال عملیاتی را کاهش دهد.

البته تنظیمات بیش از حد سخت‌گیرانه نیز ممکن است باعث اختلال شوند؛ بنابراین باید میان امنیت و نیازهای واقعی سرویس تعادل برقرار کرد.

پیش از شروع Hardening چه اقداماتی ضروری است؟

یکی از اشتباهات خطرناک این است که مدیر سرور بدون شناخت زیرساخت، مجموعه‌ای از دستورات امنیتی را اجرا کند.

تغییر اشتباه تنظیمات شبکه، SSH یا فایروال می‌تواند ارتباط مدیریتی را قطع کند و باعث از دست رفتن دسترسی به سرور شود.

به همین دلیل، بهتر است قبل از اعمال تغییرات، وضعیت فعلی مستندسازی شود.

شناسایی سیستم‌عامل و نسخه آن

برای مشاهده اطلاعات توزیع لینوکس می‌توانید از دستور زیر استفاده کنید:

cat /etc/os-release

این دستور معمولاً نام توزیع، شناسه و نسخه سیستم‌عامل را نمایش می‌دهد.

همچنین برای مشاهده نسخه کرنل:

uname -r

شناسایی نسخه سیستم‌عامل اهمیت زیادی دارد؛ زیرا روش مدیریت فایروال، سرویس‌ها و بسته‌ها در توزیع‌های مختلف یکسان نیست.

دستورهای آموزشی این مقاله عمدتاً برای Ubuntu Server و توزیع‌های مبتنی بر Debian در نظر گرفته شده‌اند.

بررسی کاربران و دسترسی‌های مدیریتی

ابتدا حساب‌های کاربری موجود را بررسی کنید:

getent passwd

برای مشاهده اعضای گروه sudo در Ubuntu:

getent group sudo

این بررسی باید با شناخت حساب‌های سیستمی انجام شود.

وجود یک حساب کاربری به‌تنهایی به معنی خطرناک بودن آن نیست؛ بسیاری از سرویس‌های لینوکس با حساب‌های اختصاصی اجرا می‌شوند.

تهیه نسخه پشتیبان قبل از تغییرات

پیش از اصلاح تنظیمات حساس، از فایل‌های پیکربندی و اطلاعات مهم نسخه پشتیبان تهیه کنید.

در سرورهای مجازی، Snapshot نیز می‌تواند برای بازگردانی سریع وضعیت مفید باشد.

بااین‌حال، Snapshot جایگزین بکاپ مستقل نیست.

بهتر است امکان بازگردانی نسخه پشتیبان در محیط آزمایشی بررسی شده باشد.

اطمینان از دسترسی اضطراری

قبل از تغییر تنظیمات SSH یا فایروال باید حداقل یک روش جایگزین برای دسترسی به سرور وجود داشته باشد.

برای مثال:

• کنسول مدیریتی ارائه‌دهنده VPS
• کنسول KVM یا Serial Console
• دسترسی از طریق پنل زیرساخت ابری
• حساب مدیریتی جایگزین و آزمایش‌شده

اگر تنها روش مدیریت سرور SSH است، هر تغییر در احراز هویت یا فایروال باید با احتیاط بیشتری انجام شود.

مرحله اول: به‌روزرسانی سیستم‌عامل و بسته‌های امنیتی

یکی از پایه‌ای‌ترین اقدامات Server Hardening، به‌روز نگه داشتن سیستم‌عامل و بسته‌های نصب‌شده است.

آسیب‌پذیری‌های امنیتی ممکن است در کرنل لینوکس، کتابخانه‌های سیستمی، سرویس SSH، وب‌سرور یا نرم‌افزارهای دیگر کشف شوند.

در بسیاری از موارد، تولیدکنندگان با انتشار وصله امنیتی مشکل را برطرف می‌کنند.

سروری که مدت زیادی به‌روزرسانی نشده است، ممکن است همچنان از نسخه‌های آسیب‌پذیر استفاده کند.

بررسی بسته‌های قابل‌به‌روزرسانی

در Ubuntu و Debian ابتدا اطلاعات مخازن را به‌روزرسانی کنید:

sudo apt update

برای مشاهده بسته‌های دارای نسخه جدید:

apt list --upgradable

این دستور نشان می‌دهد کدام بسته‌ها در مخازن تنظیم‌شده دارای به‌روزرسانی هستند.

نصب به‌روزرسانی‌ها

برای نصب نسخه‌های جدید بسته‌های موجود:

sudo apt upgrade

پیش از تأیید تغییرات، فهرست بسته‌هایی را که قرار است به‌روزرسانی شوند بررسی کنید.

در سرورهای عملیاتی مهم بهتر است وصله‌ها ابتدا روی محیط آزمایشی مشابه بررسی شوند.

برای به‌روزرسانی‌هایی که به تغییر وابستگی‌ها نیاز دارند، ممکن است استفاده از full-upgrade ضروری باشد؛ اما این دستور باید با آگاهی از تغییرات احتمالی اجرا شود.

بررسی نیاز به راه‌اندازی مجدد

بعضی به‌روزرسانی‌ها، به‌خصوص تغییرات مرتبط با کرنل و اجزای بنیادی سیستم، ممکن است به راه‌اندازی مجدد نیاز داشته باشند.

در برخی سیستم‌های Ubuntu می‌توان وضعیت درخواست راه‌اندازی مجدد را با دستور زیر بررسی کرد:

test -f /var/run/reboot-required && echo "Reboot required"

راه‌اندازی مجدد سرور عملیاتی باید با برنامه نگهداری و بررسی تأثیر بر خدمات انجام شود.

فعال‌سازی به‌روزرسانی‌های امنیتی خودکار

در Ubuntu، بسته unattended-upgrades می‌تواند برای نصب کنترل‌شده برخی به‌روزرسانی‌ها استفاده شود.

برای نصب:

sudo apt install unattended-upgrades

پس از آن باید تنظیمات مربوط به مخازن مجاز، زمان‌بندی، گزارش‌ها و سیاست راه‌اندازی مجدد بررسی شوند.

فعال بودن سرویس به‌تنهایی تضمین نمی‌کند تمام به‌روزرسانی‌های موردنیاز نصب شوند.

همچنین نصب خودکار به‌روزرسانی در زیرساخت‌های حساس باید با الزامات پایداری هماهنگ باشد.

مرحله دوم: امن‌سازی SSH در سرور لینوکس

SSH یکی از مهم‌ترین ابزارهای مدیریت سرور لینوکس است.

این پروتکل امکان اجرای دستورات و مدیریت سیستم را از راه دور فراهم می‌کند.

از آنجا که SSH معمولاً در دسترس مدیران زیرساخت قرار دارد، محافظت از آن اهمیت بالایی دارد.

ایجاد حساب مدیریتی غیر از root

استفاده روزمره از حساب root توصیه نمی‌شود.

بهتر است یک حساب مدیریتی مشخص ایجاد شود و دسترسی‌های لازم مطابق مسئولیت او اختصاص پیدا کند.

برای ایجاد کاربر در Ubuntu:

sudo adduser adminuser

برای افزودن کاربر به گروه sudo:

sudo usermod -aG sudo adminuser

نام adminuser نمونه است و باید متناسب با ساختار مدیریت سرور انتخاب شود.

پس از ایجاد حساب، ورود و اجرای یک دستور مجاز با sudo را آزمایش کنید.

استفاده از SSH Key به‌جای رمز عبور

احراز هویت مبتنی بر کلید عمومی معمولاً انتخاب مناسبی برای مدیریت SSH است.

در این روش، یک جفت کلید عمومی و خصوصی ایجاد می‌شود.

کلید عمومی روی سرور قرار می‌گیرد و کلید خصوصی باید نزد کاربر و در محل امن نگهداری شود.

برای ایجاد یک کلید Ed25519 روی سیستم مدیر:

ssh-keygen -t ed25519 -a 100

بهتر است برای کلید خصوصی یک Passphrase قوی نیز تعیین شود.

این کار می‌تواند در صورت افشای فایل کلید، لایه محافظتی دیگری ایجاد کند.

برای انتقال کلید عمومی به سرور، در محیط‌های پشتیبانی‌شده می‌توان از ابزار زیر استفاده کرد:

ssh-copy-id adminuser@SERVER_IP

مقدار SERVER_IP باید با آدرس واقعی سرور جایگزین شود.

قبل از غیرفعال کردن ورود با رمز عبور، اتصال با کلید را در یک نشست جدید به‌صورت کامل آزمایش کنید.

غیرفعال کردن ورود مستقیم root

یکی از اقدامات رایج، جلوگیری از ورود مستقیم کاربر root از طریق SSH است.

در OpenSSH می‌توان از تنظیم زیر استفاده کرد:

PermitRootLogin no

این تنظیم باید در فایل پیکربندی SSH یا فایل‌های پیکربندی تکمیلی مرتبط اعمال شود.

مسیر رایج در Ubuntu:

/etc/ssh/sshd_config

همچنین ممکن است فایل‌های داخل مسیر زیر مؤثر باشند:

/etc/ssh/sshd_config.d/

پیش از تغییر باید ترتیب و اولویت تنظیمات مؤثر بررسی شود.

غیرفعال کردن ورود با رمز عبور

پس از اطمینان از عملکرد SSH Key می‌توان ورود با رمز عبور را محدود کرد.

تنظیم مرتبط:

PasswordAuthentication no

در بعضی پیکربندی‌ها، احراز هویت تعاملی از طریق Keyboard-Interactive یا PAM نیز باید متناسب با سیاست امنیتی بررسی شود.

برای مثال، تغییر KbdInteractiveAuthentication ممکن است بر ورود با رمز یک‌بارمصرف یا راهکارهای MFA اثر بگذارد.

بنابراین نباید بدون شناخت روش احراز هویت فعال، همه گزینه‌ها را غیرفعال کرد.

اعتبارسنجی تنظیمات SSH

قبل از اعمال تنظیمات جدید:

sudo sshd -t

در برخی توزیع‌ها مسیر اجرایی sshd ممکن است نیاز به تعیین کامل داشته باشد.

برای بررسی پیکربندی مؤثر نیز می‌توان از حالت نمایش تنظیمات استفاده کرد:

sudo sshd -T

اگر خطایی وجود نداشت و دسترسی جایگزین آماده بود، سرویس را با روش مناسب توزیع Reload کنید.

در Ubuntu معمولاً:

sudo systemctl reload ssh

نشست SSH فعلی را نبندید تا ورود موفق از یک نشست جدید تأیید شود.

آیا تغییر پورت SSH امنیت را افزایش می‌دهد؟

انتقال SSH از پورت پیش‌فرض 22 به پورتی دیگر ممکن است بخشی از تلاش‌های خودکار و کم‌کیفیت را کاهش دهد.

اما تغییر پورت جایگزین احراز هویت قوی، محدودسازی دسترسی و به‌روزرسانی امنیتی نیست.

سرویس SSH همچنان می‌تواند از طریق شناسایی پورت‌های باز کشف شود.

برای سرورهای حساس، محدودسازی SSH به IPهای مدیریتی مشخص یا دسترسی از طریق VPN معمولاً اهمیت بیشتری دارد.

مرحله سوم: تنظیم فایروال سرور لینوکس

فایروال یکی از اجزای کلیدی در کاهش سطح حمله سرور است.

این ابزار تعیین می‌کند کدام ارتباطات شبکه مجاز و کدام ارتباطات محدود شوند.

در بسیاری از سرورهای Ubuntu، ابزار UFW برای مدیریت ساده‌تر قواعد فایروال استفاده می‌شود.

بررسی وضعیت UFW

برای مشاهده وضعیت:

sudo ufw status verbose

اگر UFW غیرفعال باشد، این موضوع لزوماً نشان‌دهنده نبود هرگونه فایروال نیست.

ممکن است کنترل ترافیک از طریق nftables، iptables، فایروال ابری یا ابزارهای دیگر انجام شود.

تعیین سیاست پیش‌فرض

در یک وب‌سرور ساده، معمولاً سیاست بستن ارتباطات ورودی غیرمجاز و اجازه ارتباطات خروجی موردنیاز قابل بررسی است.

نمونه:

sudo ufw default deny incoming
sudo ufw default allow outgoing

این تنظیمات برای همه سرورها مناسب نیستند.

سرورهایی که نقش Router، Gateway یا سرویس شبکه خاص دارند ممکن است نیازمند سیاست متفاوت باشند.

اجازه دسترسی به SSH

پیش از فعال‌سازی فایروال، باید مطمئن شوید پورت SSH مورد استفاده مجاز است.

اگر SSH روی پورت 22 اجرا می‌شود:

sudo ufw allow 22/tcp

در صورت امکان، بهتر است دسترسی مدیریتی فقط از شبکه‌ها یا IPهای مجاز فراهم شود.

قانون مبتنی بر IP ثابت باید با توجه به احتمال تغییر آدرس مدیریت شود.

اجازه دسترسی HTTP و HTTPS

برای یک وب‌سرور عمومی:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

این دو پورت به‌ترتیب برای HTTP و HTTPS کاربرد دارند.

اگر وب‌سایت صرفاً از طریق Reverse Proxy یا Load Balancer در دسترس است، ممکن است نیازی نباشد سرور اصلی مستقیماً از کل اینترنت قابل‌دسترسی باشد.

فعال‌سازی UFW

پس از بررسی قوانین:

sudo ufw enable

هشدار: فعال‌سازی فایروال با قوانین ناقص ممکن است اتصال مدیریتی را قطع کند. این دستور را فقط پس از بررسی SSH و اطمینان از وجود دسترسی بازیابی اجرا کنید.

بررسی نهایی قوانین

sudo ufw status numbered

قواعد غیرضروری باید شناسایی و پس از تأیید وابستگی سرویس‌ها حذف شوند.

اهمیت فایروال IPv6

یکی از اشتباهات رایج، اعمال محدودیت روی IPv4 و فراموش کردن IPv6 است.

اگر سرور دارای آدرس IPv6 عمومی باشد، باید قوانین مربوط به آن نیز بررسی شوند.

در غیر این صورت ممکن است سرویسی که روی IPv4 محدود شده، از طریق IPv6 همچنان در دسترس باشد.

مرحله چهارم: بستن پورت‌ها و سرویس‌های غیرضروری

هر سرویس فعال می‌تواند بخشی از سطح حمله سرور باشد.

بنابراین یکی از اصول Server Hardening این است که فقط نرم‌افزارها و سرویس‌های موردنیاز فعال باشند.

مشاهده پورت‌های در حال Listen

برای شناسایی پورت‌هایی که برنامه‌ها روی آن‌ها منتظر اتصال هستند:

sudo ss -tulpen

این دستور اطلاعاتی درباره ارتباطات TCP و UDP و برنامه‌های مرتبط ارائه می‌کند.

برای نمونه ممکن است پورت‌های زیر مشاهده شوند:

وجود پورت در این جدول به معنای باز بودن آن در اینترنت نیست.

باید آدرس Bind سرویس، قوانین فایروال و مسیر دسترسی شبکه نیز بررسی شوند.

مشاهده سرویس‌های فعال

systemctl --type=service --state=running

فهرست سرویس‌ها را با معماری واقعی سرور مقایسه کنید.

برای مثال، اگر سرور صرفاً نقش وب‌سرور دارد، وجود برخی سرویس‌های آزمایشی یا نرم‌افزارهای قدیمی ممکن است غیرضروری باشد.

غیرفعال‌سازی سرویس‌های بلااستفاده

برای توقف یک سرویس شناخته‌شده:

sudo systemctl stop SERVICE_NAME

برای جلوگیری از اجرای خودکار هنگام راه‌اندازی:

sudo systemctl disable SERVICE_NAME

نام سرویس باید با سرویس واقعی جایگزین شود.

پیش از غیرفعال‌سازی باید وابستگی سایر برنامه‌ها بررسی شود.

حذف کورکورانه بسته‌ها و سرویس‌ها می‌تواند باعث از کار افتادن وب‌سایت شود.

مرحله پنجم: مدیریت کاربران و اصل Least Privilege

اصل حداقل دسترسی یا Least Privilege می‌گوید هر کاربر یا فرایند باید فقط مجوزهای لازم برای انجام وظیفه خود را داشته باشد.

این اصل یکی از مهم‌ترین مفاهیم امنیت سیستم‌عامل است.

محدود کردن کاربران دارای sudo

اعضای گروه sudo معمولاً توانایی اجرای دستورات مدیریتی را دارند.

بنابراین تعداد این حساب‌ها باید محدود و قابل توجیه باشد.

حساب‌های مدیریتی بهتر است شخصی و قابل انتساب باشند، نه مشترک میان چند نفر.

جلوگیری از استفاده از حساب مشترک

استفاده چند مدیر از یک حساب مشترک باعث کاهش قابلیت ردگیری فعالیت‌ها می‌شود.

اگر تغییر مهمی در سرور انجام شود، تشخیص اینکه چه کسی آن را انجام داده دشوار خواهد شد.

بهتر است هر مدیر حساب مشخصی داشته باشد و فعالیت‌های دارای امتیاز بالا ثبت شوند.

بررسی دسترسی فایل‌ها

برای مشاهده مجوزهای یک فایل:

ls -l /path/to/file

برای مشاهده اطلاعات مالکیت و مجوزهای مسیر:

stat /path/to/file

مجوزهای اشتباه می‌توانند باعث افشای اطلاعات حساس یا تغییر غیرمجاز فایل‌ها شوند.

جلوگیری از استفاده بی‌دلیل از chmod 777

یکی از اشتباهات خطرناک، اختصاص مجوز 777 برای حل مشکلات دسترسی است.

این مجوز به همه کاربران محلی اجازه خواندن، نوشتن و اجرا در چارچوب معنای مجوزهای مربوط می‌دهد.

در بسیاری از سناریوهای میزبانی وب، چنین سطح دسترسی‌ای ضروری نیست.

برای رفع خطا باید مالک فایل، گروه، کاربر اجرای وب‌سرور و نیاز واقعی برنامه بررسی شود.

مرحله ششم: امن‌سازی فایل‌ها و دایرکتوری‌های وب‌سایت

فایل‌های وب‌سایت شامل کد برنامه، تنظیمات، فایل‌های بارگذاری‌شده و گاهی اطلاعات محرمانه هستند.

اگر مجوزهای آن‌ها به‌درستی مدیریت نشود، یک آسیب‌پذیری ساده در برنامه ممکن است به تغییر گسترده فایل‌ها منجر شود.

جداسازی فایل‌های برنامه از فایل‌های قابل‌نوشتن

همه بخش‌های وب‌سایت نباید برای کاربر اجرای وب‌سرور قابل‌نوشتن باشند.

برای مثال، ممکن است تنها پوشه‌های مشخصی برای Cache، Upload یا Session به قابلیت نوشتن نیاز داشته باشند.

بهتر است فایل‌های اصلی برنامه تا حد امکان فقط توسط فرایند استقرار یا حساب مدیریتی مجاز تغییر کنند.

انتخاب مجوز مناسب برای فایل‌ها

در بعضی محیط‌های وب، مجوزهای زیر به‌عنوان نقطه شروع بررسی می‌شوند:

• دایرکتوری‌های معمولی: 755
• فایل‌های معمولی: 644

اما این اعداد یک قانون جهانی نیستند.

اگر مالکیت، گروه یا معماری اجرای سرویس متفاوت باشد، ممکن است تنظیم مناسب نیز تغییر کند.

برای فایل‌های حاوی Secrets، مجوزهای محدودتری ضرورت دارد.

محافظت از فایل‌های حساس

فایل‌هایی مانند موارد زیر باید با توجه به نوع برنامه محافظت شوند:

• .env
• فایل‌های تنظیمات اتصال پایگاه داده
• کلیدهای خصوصی
• فایل‌های حاوی توکن API
• فایل‌های پشتیبان پایگاه داده
• فایل‌های تنظیمات حاوی اطلاعات ورود

این فایل‌ها نباید از طریق وب‌سرور عمومی قابل دانلود باشند.

همچنین نگهداری آن‌ها در مخزن Git عمومی یا آرشیوهای قابل‌دسترسی اینترنتی خطرناک است.

بررسی فایل‌های مخفی و آرشیوها

گاهی توسعه‌دهندگان فایل‌هایی مانند نسخه قدیمی تنظیمات، آرشیو ZIP یا فایل پشتیبان را داخل مسیر عمومی سایت باقی می‌گذارند.

اگر وب‌سرور امکان دسترسی به آن‌ها را فراهم کند، اطلاعات حساس ممکن است افشا شوند.

در فرایند Hardening باید مسیرهای انتشار فایل و سیاست دسترسی وب‌سرور بررسی شود.

مرحله هفتم: امن‌سازی Nginx و Apache

امنیت وب‌سرور نقش مهمی در محافظت از وب‌سایت دارد.

Nginx و Apache هر دو امکانات مختلفی برای محدودسازی درخواست‌ها، مدیریت دسترسی و کنترل پاسخ‌های HTTP ارائه می‌کنند.

حذف تنظیمات و صفحات نمونه

در محیط عملیاتی نباید صفحات آزمایشی، تنظیمات توسعه یا سرویس‌های نمونه غیرضروری باقی بمانند.

همچنین Virtual Hostهای پیش‌فرض باید بررسی شوند.

ممکن است یک درخواست با Host ناشناخته به سایتی هدایت شود که قرار نبوده عمومی باشد.

کاهش افشای اطلاعات نسخه نرم‌افزار

در Nginx می‌توان بسته به نیاز و پیکربندی از گزینه زیر استفاده کرد:

server_tokens off;

این گزینه برخی اطلاعات نسخه Nginx را از پاسخ‌های معمول پنهان می‌کند.

در Apache نیز تنظیماتی مانند ServerTokens و ServerSignature برای کنترل بخشی از اطلاعات نمایشی وجود دارند.

بااین‌حال، پنهان کردن نسخه نرم‌افزار مانع قطعی شناسایی فناوری یا سوءاستفاده از آسیب‌پذیری نمی‌شود.

این اقدام باید در کنار به‌روزرسانی و تنظیمات امنیتی انجام شود.

محدودسازی روش‌های HTTP

وب‌سرور باید فقط روش‌های HTTP موردنیاز برنامه را بپذیرد.

روش‌هایی مانند GET و POST کاربرد گسترده‌ای دارند، اما سایر روش‌ها نیز ممکن است برای APIها یا امکانات خاص لازم باشند.

غیرفعال‌سازی روش‌های HTTP باید بر اساس رفتار واقعی برنامه و پس از آزمایش انجام شود.

فعال‌سازی HTTPS

تمام بخش‌هایی که اطلاعات حساس منتقل می‌کنند باید از HTTPS استفاده کنند.

گواهی TLS معتبر و تنظیمات رمزنگاری مناسب اهمیت زیادی دارند.

همچنین باید نسخه‌های قدیمی و ناامن پروتکل‌های رمزنگاری مطابق سازگاری موردنیاز محدود شوند.

برای وب‌سایت‌های عمومی، استفاده از TLS 1.2 و TLS 1.3 در پیکربندی‌های مناسب رایج است.

استفاده از HSTS

HTTP Strict Transport Security یا HSTS به مرورگر اعلام می‌کند برای مدت مشخصی اتصال به دامنه را از طریق HTTPS برقرار کند.

نمونه هدر:

Strict-Transport-Security: max-age=31536000

فعال‌سازی HSTS باید پس از اطمینان از عملکرد صحیح HTTPS انجام شود.

گزینه includeSubDomains نیز تنها زمانی مناسب است که تمام زیردامنه‌های مشمول از HTTPS به‌درستی پشتیبانی کنند.

همچنین استفاده از preload نیازمند رعایت شرایط خاص و تصمیم‌گیری دقیق است.

سایر هدرهای امنیتی

هدرهایی مانند موارد زیر می‌توانند بخشی از امنیت مرورگر و برنامه را تقویت کنند:

• Content-Security-Policy
• X-Content-Type-Options
• Referrer-Policy
• Permissions-Policy

برای مثال:

X-Content-Type-Options: nosniff

این هدر برای محدود کردن برخی رفتارهای تشخیص نوع محتوا در مرورگر کاربرد دارد.

تنظیم CSP باید متناسب با منابع واقعی وب‌سایت انجام شود.

اعمال سیاست نامناسب ممکن است فایل‌های جاوااسکریپت، فونت‌ها یا منابع لازم سایت را مسدود کند.

مرحله هشتم: امن‌سازی PHP و محیط اجرای برنامه

در سرورهایی که وردپرس، ووکامرس یا برنامه‌های PHP اجرا می‌شوند، امنیت PHP اهمیت زیادی دارد.

تنظیمات PHP می‌توانند بر نحوه نمایش خطا، دسترسی به فایل‌ها و اجرای اسکریپت‌ها تأثیر بگذارند.

استفاده از نسخه پشتیبانی‌شده PHP

استفاده از نسخه‌های خارج از دوره پشتیبانی امنیتی، ریسک بهره‌برداری از آسیب‌پذیری‌های اصلاح‌نشده را افزایش می‌دهد.

نسخه PHP باید علاوه بر داشتن پشتیبانی امنیتی، با افزونه‌ها و برنامه‌های مورد استفاده سازگار باشد.

غیرفعال کردن نمایش خطا در محیط Production

نمایش مستقیم خطاهای PHP می‌تواند مسیر فایل‌ها، ساختار برنامه یا اطلاعات فنی حساس را آشکار کند.

در محیط عملیاتی معمولاً بهتر است نمایش خطا برای کاربران غیرفعال و ثبت خطا در یک مسیر محافظت‌شده فعال باشد.

برای مثال:

display_errors = Off
log_errors = On

این تنظیمات باید در فایل پیکربندی مؤثر PHP و متناسب با معماری PHP-FPM یا روش اجرای برنامه اعمال شوند.

تنظیم محدودیت منابع

گزینه‌هایی مانند موارد زیر باید بر اساس نیاز واقعی برنامه تنظیم شوند:

• memory_limit
• max_execution_time
• post_max_size
• upload_max_filesize

محدودیت منابع می‌تواند به کنترل مصرف غیرعادی کمک کند، اما جایگزین محافظت در برابر حملات DoS نیست.

مقادیر بیش از حد پایین نیز ممکن است عملکرد برنامه را مختل کنند.

جداسازی PHP-FPM Poolها

اگر چند وب‌سایت روی یک سرور میزبانی می‌شوند، استفاده از Poolهای جداگانه با کاربران محدود می‌تواند امنیت را افزایش دهد.

در این معماری، بهتر است هر وب‌سایت تا حد امکان در محدوده دسترسی خودش اجرا شود.

بااین‌حال، جداسازی Poolها به‌تنهایی معادل ایزوله‌سازی کامل امنیتی نیست.

برای محیط‌های حساس ممکن است استفاده از کانتینر، ماشین مجازی یا معماری جداگانه مناسب‌تر باشد.

مرحله نهم: امن‌سازی MySQL، MariaDB و PostgreSQL

پایگاه داده معمولاً یکی از حساس‌ترین بخش‌های سرور وب‌سایت است.

در این بخش ممکن است اطلاعات کاربران، محتوای سایت، تنظیمات برنامه و داده‌های عملیاتی ذخیره شوند.

جلوگیری از دسترسی عمومی غیرضروری

در بسیاری از معماری‌های تک‌سروری، پایگاه داده نیازی به پذیرش اتصال مستقیم از اینترنت ندارد.

در چنین شرایطی می‌توان سرویس را برای اتصال محلی پیکربندی کرد.

برای نمونه، در برخی پیکربندی‌های MySQL مقدار زیر بررسی می‌شود:

bind-address = 127.0.0.1

اما مسیر فایل و نحوه تفسیر این تنظیم به نسخه و معماری نصب وابسته است.

اگر پایگاه داده در سرور جداگانه قرار دارد، دسترسی باید از طریق شبکه خصوصی یا مسیر کنترل‌شده فراهم شود.

ایجاد کاربر اختصاصی برای هر برنامه

نباید تمام وب‌سایت‌ها با یک حساب مدیریتی پایگاه داده کار کنند.

برای هر برنامه بهتر است حساب اختصاصی با حداقل مجوزهای ضروری ایجاد شود.

برای مثال، یک برنامه معمولاً به دسترسی مدیریتی کامل روی تمام پایگاه‌های داده سرور نیاز ندارد.

محافظت از اطلاعات اتصال

نام کاربری و رمز عبور پایگاه داده باید در فایل‌های محافظت‌شده یا سامانه مدیریت Secrets نگهداری شوند.

نباید این اطلاعات در لاگ‌های عمومی، مخازن کد یا پاسخ‌های خطای وب‌سایت نمایش داده شوند.

رمزنگاری ارتباطات پایگاه داده

اگر ارتباط برنامه و پایگاه داده از طریق شبکه برقرار می‌شود، باید نیاز به TLS و سازوکارهای احراز هویت متقابل بررسی شود.

شبکه خصوصی خطر دسترسی عمومی را کاهش می‌دهد، اما لزوماً جایگزین رمزنگاری ارتباطات نیست.

بکاپ و بازیابی پایگاه داده

تهیه نسخه پشتیبان باید با موتور پایگاه داده و نیازهای سازگاری اطلاعات هماهنگ باشد.

همچنین بازیابی بکاپ باید به‌صورت دوره‌ای آزمایش شود.

وجود فایل بکاپ بدون امکان بازگردانی سالم، اطمینان کافی ایجاد نمی‌کند.

مرحله دهم: محافظت از سرور در برابر حملات Brute Force

حملات Brute Force شامل تلاش‌های تکراری برای حدس زدن اطلاعات ورود هستند.

این حملات ممکن است سرویس‌هایی مانند SSH، پنل مدیریت یا سامانه‌های احراز هویت را هدف قرار دهند.

استفاده از Fail2ban

Fail2ban ابزاری است که می‌تواند لاگ‌های مشخص را بررسی کرده و در واکنش به الگوهای تعریف‌شده، محدودیت موقت اعمال کند.

در Ubuntu می‌توان آن را از مخازن مناسب نصب کرد:

sudo apt install fail2ban

پس از نصب، باید Jailهای موردنیاز و مسیرهای لاگ بررسی شوند.

برای مشاهده وضعیت کلی، در صورتی که سرویس فعال و تنظیم شده باشد:

sudo fail2ban-client status

محدودیت‌های Fail2ban

Fail2ban جایگزین SSH Key، MFA یا محدودسازی دسترسی شبکه نیست.

همچنین ممکن است رفتار آن در مواجهه با حملات توزیع‌شده از IPهای فراوان محدود باشد.

پیکربندی اشتباه نیز می‌تواند موجب مسدود شدن IP مدیر سرور شود.

برای کاهش این احتمال، باید سیاست بازیابی و دسترسی اضطراری وجود داشته باشد.

محدودسازی تعداد درخواست‌ها

در وب‌سرور نیز می‌توان از Rate Limiting برای کنترل برخی الگوهای درخواست پرتکرار استفاده کرد.

این قابلیت باید با رفتار واقعی کاربران، APIها و سرویس‌های خودکار هماهنگ باشد.

محدودیت بیش از حد سخت‌گیرانه ممکن است باعث اختلال برای کاربران قانونی شود.

مرحله یازدهم: فعال‌سازی AppArmor یا SELinux

یکی از لایه‌های مهم امنیت لینوکس، Mandatory Access Control یا MAC است.

این رویکرد امکان اعمال محدودیت بر رفتار فرایندها را فراتر از مجوزهای سنتی فایل فراهم می‌کند.

AppArmor چیست؟

AppArmor یک چارچوب امنیتی است که می‌تواند با استفاده از Profileهای مشخص، دسترسی برنامه‌ها به منابع سیستم را محدود کند.

در بسیاری از سیستم‌های Ubuntu از AppArmor استفاده می‌شود.

برای بررسی وضعیت:

sudo aa-status

در بعضی سیستم‌ها ممکن است ابزار مربوطه نیاز به نصب بسته مناسب داشته باشد.

Profileهای AppArmor می‌توانند در حالت‌هایی مانند Enforce یا Complain قرار بگیرند.

حالت Enforce محدودیت‌ها را اجرا می‌کند، درحالی‌که Complain معمولاً برای ثبت و ارزیابی رفتار بدون اجرای همان محدودیت‌ها کاربرد دارد.

SELinux چیست؟

SELinux یک چارچوب MAC است که در برخی توزیع‌های لینوکسی، به‌خصوص خانواده Red Hat، کاربرد گسترده‌ای دارد.

این فناوری از سیاست‌های امنیتی برای کنترل دسترسی فرایندها استفاده می‌کند.

آیا باید AppArmor را غیرفعال کرد؟

غیرفعال کردن AppArmor یا SELinux صرفاً برای رفع سریع یک خطای برنامه، روش مناسبی نیست.

ابتدا باید مشخص شود کدام سیاست مانع عملکرد برنامه شده است.

در بسیاری از موارد امکان اصلاح Profile یا Policy وجود دارد.

خاموش کردن کامل یک لایه امنیتی می‌تواند سطح حفاظت سیستم را کاهش دهد.

مرحله دوازدهم: امن‌سازی کرنل و تنظیمات سیستم

هسته لینوکس مسئول مدیریت حافظه، پردازش‌ها، سخت‌افزار و بخش مهمی از ارتباطات سیستم است.

برخی قابلیت‌های امنیتی کرنل به کاهش پیامدهای سوءاستفاده از آسیب‌پذیری‌ها کمک می‌کنند.

بررسی وضعیت به‌روزرسانی کرنل

نسخه کرنل باید با چرخه پشتیبانی سیستم‌عامل هماهنگ باشد.

بااین‌حال، جدیدترین شماره نسخه الزاماً امن‌ترین انتخاب برای هر توزیع نیست.

بعضی توزیع‌ها وصله‌های امنیتی را به نسخه‌های پشتیبانی‌شده خود منتقل می‌کنند.

بنابراین تصمیم‌گیری باید بر اساس بسته‌های رسمی و وضعیت پشتیبانی انجام شود.

بررسی ASLR

Address Space Layout Randomization یا ASLR یک سازوکار امنیتی برای تصادفی‌سازی محل قرارگیری برخی ساختارهای حافظه است.

در سیستم‌های لینوکسی، وضعیت مرتبط با آن را می‌توان بررسی کرد:

sysctl kernel.randomize_va_space

مقدار مناسب باید بر اساس سیاست امنیتی سیستم‌عامل و سازگاری برنامه‌ها تعیین شود.

ASLR به‌تنهایی مانع تمام حملات حافظه نیست، اما یکی از لایه‌های دفاعی محسوب می‌شود.

کنترل تنظیمات sysctl

تنظیمات sysctl امکان مشاهده و اصلاح برخی پارامترهای کرنل را فراهم می‌کنند.

برای مثال، وضعیت یک پارامتر شبکه را می‌توان با دستور زیر بررسی کرد:

sysctl net.ipv4.tcp_syncookies

بااین‌حال، اعمال مجموعه‌ای از تنظیمات sysctl بدون شناخت نقش سرور توصیه نمی‌شود.

پارامترهایی که برای یک وب‌سرور مناسب هستند ممکن است در Router، سرویس VPN یا محیط کانتینری مشکلات جدی ایجاد کنند.

بهتر است تغییرات بر اساس Baseline سازگار با توزیع، نسخه کرنل و نقش سرور انجام شوند.

مرحله سیزدهم: محافظت از سرور در برابر بدافزار و تغییرات غیرمجاز

هرچند بخش زیادی از بدافزارهای رایج کاربران عادی روی سیستم‌های دسکتاپ متمرکز هستند، سرورهای لینوکسی نیز می‌توانند هدف بدافزار، ابزارهای استخراج رمزارز یا دسترسی‌های مخفی قرار گیرند.

استفاده از ابزارهای شناسایی بدافزار

در بعضی محیط‌ها استفاده از ابزارهایی مانند ClamAV می‌تواند بخشی از راهکار بررسی فایل‌ها باشد.

اما این ابزارها نباید به‌عنوان تضمین شناسایی تمام بدافزارها در نظر گرفته شوند.

روش اسکن، به‌روزرسانی امضاها و نحوه برخورد با فایل‌های مشکوک اهمیت دارد.

پایش یکپارچگی فایل‌ها

File Integrity Monitoring یا FIM برای شناسایی تغییرات غیرمنتظره فایل‌های مهم استفاده می‌شود.

برای مثال، ابزار AIDE می‌تواند در برخی زیرساخت‌ها برای ایجاد پایگاه مرجع و مقایسه تغییرات به کار رود.

در این رویکرد باید مشخص شود کدام فایل‌ها اهمیت امنیتی دارند.

همچنین لازم است تغییرات قانونی ناشی از به‌روزرسانی یا استقرار نرم‌افزار از تغییرات غیرمجاز تفکیک شوند.

بررسی فرایندهای مشکوک

برای مشاهده فرایندهای فعال:

ps aux

برای مشاهده مصرف منابع نیز می‌توان از ابزارهایی مانند top استفاده کرد.

مصرف بالای CPU یا حافظه به‌تنهایی نشانه قطعی بدافزار نیست.

ممکن است پردازش قانونی، عملیات پشتیبان‌گیری یا یک مشکل عملکردی باعث افزایش مصرف منابع شده باشد.

تحلیل باید با بررسی فرایند، مالک، مسیر اجرایی و رفتار شبکه انجام شود.

مرحله چهاردهم: مدیریت لاگ‌ها و مانیتورینگ امنیتی

بدون لاگ‌برداری مناسب، تشخیص زمان و علت رخدادهای امنیتی دشوار می‌شود.

لاگ‌ها می‌توانند اطلاعاتی درباره ورود کاربران، خطاهای سیستم، درخواست‌های وب و تغییرات عملیاتی ارائه کنند.

بررسی لاگ‌های systemd

در توزیع‌هایی که از systemd استفاده می‌کنند، ابزار journalctl برای مشاهده لاگ‌ها کاربرد دارد.

برای مشاهده پیام‌های اخیر:

sudo journalctl -n 100

برای بررسی لاگ سرویس SSH در Ubuntu:

sudo journalctl -u ssh

نام سرویس ممکن است در توزیع‌های دیگر متفاوت باشد.

بررسی لاگ‌های وب‌سرور

وب‌سرورها معمولاً Access Log و Error Log تولید می‌کنند.

Access Log اطلاعاتی درباره درخواست‌های دریافت‌شده ارائه می‌دهد.

Error Log نیز برای شناسایی خطاهای عملکردی یا پیکربندی مفید است.

تنظیم نگهداری لاگ

اگر لاگ‌ها بدون محدودیت ذخیره شوند، ممکن است فضای دیسک را مصرف کنند.

از طرف دیگر، حذف زودهنگام لاگ‌ها می‌تواند تحلیل رخداد امنیتی را دشوار کند.

مدت نگهداری باید بر اساس نیاز عملیاتی، الزامات قانونی و ظرفیت ذخیره‌سازی تعیین شود.

انتقال لاگ به سامانه مرکزی

برای زیرساخت‌های مهم، ارسال لاگ‌ها به سامانه جداگانه می‌تواند مزیت امنیتی داشته باشد.

اگر مهاجم به سرور دسترسی پیدا کند، ممکن است تلاش کند لاگ‌های محلی را تغییر دهد.

وجود نسخه مستقل و محافظت‌شده از لاگ‌ها می‌تواند بررسی رخداد را آسان‌تر کند.

تعریف هشدارهای امنیتی

هشدارها بهتر است بر اساس رفتارهای مهم تنظیم شوند؛ مانند:

• افزایش غیرعادی تلاش‌های ورود ناموفق
• ورود مدیریتی از موقعیت یا شبکه غیرمنتظره
• تغییر فایل‌های حساس
• توقف سرویس‌های امنیتی
• افزایش ناگهانی مصرف منابع
• تغییر غیرمنتظره قوانین فایروال
• کاهش شدید فضای آزاد دیسک

هشدارهای بیش از حد و کم‌اهمیت می‌توانند باعث خستگی تیم مدیریت و نادیده گرفتن رخدادهای مهم شوند.

مرحله پانزدهم: تهیه بکاپ امن و قابل‌بازیابی

بکاپ یکی از مهم‌ترین اقدامات برای کاهش پیامدهای رخدادهای امنیتی است.

اگر سرور دچار آلودگی، تخریب اطلاعات یا خطای مدیریتی شود، نسخه پشتیبان سالم می‌تواند امکان بازیابی خدمات را فراهم کند.

قانون 3-2-1 در پشتیبان‌گیری

یکی از الگوهای شناخته‌شده بکاپ، قانون 3-2-1 است:

• نگهداری سه نسخه از داده، شامل داده اصلی
• استفاده از دو نوع رسانه یا محل ذخیره‌سازی متفاوت
• نگهداری حداقل یک نسخه خارج از محیط اصلی

در معماری‌های جدید، استفاده از بکاپ Immutable یا محافظت‌شده در برابر تغییر و حذف نیز اهمیت زیادی دارد.

چرا بکاپ روی همان سرور کافی نیست؟

اگر نسخه پشتیبان روی همان سرور اصلی قرار داشته باشد، ممکن است در صورت نفوذ گسترده، خرابی دیسک یا حذف اطلاعات از بین برود.

بنابراین بهتر است حداقل یک نسخه مستقل از سرور تولیدکننده داده نگهداری شود.

رمزنگاری بکاپ

نسخه‌های پشتیبان ممکن است شامل اطلاعات پایگاه داده، کلیدهای خصوصی و اطلاعات کاربران باشند.

در نتیجه باید دسترسی به آن‌ها محدود شود و در صورت نیاز با رمزنگاری مناسب محافظت شوند.

کلید بازیابی نیز باید جداگانه و امن نگهداری شود.

آزمایش بازیابی

بکاپی که هرگز Restore نشده است، قابلیت اطمینان اثبات‌شده‌ای ندارد.

بهتر است در بازه‌های مشخص، فرایند بازیابی در محیط آزمایشی اجرا شود.

این آزمایش باید شامل صحت فایل‌ها، پایگاه داده و عملکرد برنامه پس از بازگردانی باشد.

تعیین RPO و RTO

برای برنامه‌ریزی بازیابی دو شاخص اهمیت دارند:

RPO: حداکثر میزان قابل‌قبول از دست رفتن داده، از نظر فاصله زمانی.

RTO: حداکثر زمان هدف برای بازیابی خدمت پس از اختلال.

برای مثال، یک فروشگاه پرتراکنش ممکن است به فاصله‌های کوتاه‌تر بین بکاپ‌ها نیاز داشته باشد.

در مقابل، یک سایت محتوایی کم‌تغییر ممکن است الزامات متفاوتی داشته باشد.

مرحله شانزدهم: امن‌سازی Docker و کانتینرها

بسیاری از وب‌سایت‌ها و اپلیکیشن‌های جدید با Docker اجرا می‌شوند.

کانتینرسازی مدیریت استقرار را ساده‌تر می‌کند، اما به‌تنهایی امنیت کامل ایجاد نمی‌کند.

استفاده از Imageهای معتبر

Imageها باید از منابع قابل‌اعتماد دریافت شوند.

همچنین بهتر است نسخه مشخص و قابل‌ردگیری استفاده شود و وابستگی‌ها از نظر آسیب‌پذیری بررسی شوند.

استفاده بدون کنترل از برچسب latest می‌تواند قابلیت پیش‌بینی و تکرارپذیری استقرار را کاهش دهد.

جلوگیری از اجرای غیرضروری با root

در صورت امکان، برنامه داخل کانتینر باید با کاربر غیرممتاز اجرا شود.

البته اجرای برنامه با کاربر غیر root به‌تنهایی برای ایزوله‌سازی کامل کافی نیست.

محدود کردن قابلیت‌های کانتینر

Docker امکان مدیریت Capabilityها، محدودیت منابع و تنظیمات امنیتی اضافی را فراهم می‌کند.

کانتینرها نباید بدون ضرورت با حالت Privileged اجرا شوند.

محافظت از Docker Socket

دسترسی به Docker Socket بسیار حساس است.

کاربری که به این رابط دسترسی مدیریتی داشته باشد، ممکن است بتواند کنترل قابل‌توجهی بر میزبان اعمال کند.

بنابراین این رابط نباید بدون احراز هویت و کنترل مناسب در معرض شبکه عمومی قرار گیرد.

جداسازی شبکه سرویس‌ها

پایگاه داده و سرویس‌های داخلی بهتر است فقط برای اجزایی که به آن‌ها نیاز دارند قابل‌دسترسی باشند.

در Docker Compose نیز باید انتشار پورت‌ها به میزبان با دقت بررسی شود.

انتشار یک پورت بدون محدودسازی مناسب ممکن است سرویس داخلی را ناخواسته در دسترس قرار دهد.

همچنین باید تعامل قوانین Docker با فایروال میزبان بررسی شود؛ زیرا قوانین انتشار پورت کانتینرها ممکن است با برخی انتظارات از UFW متفاوت باشند.

مرحله هفدهم: استفاده از WAF برای محافظت از وب‌سایت

Web Application Firewall یا WAF یک لایه امنیتی برای بررسی و کنترل بخشی از ترافیک HTTP و HTTPS است.

این فناوری می‌تواند در کاهش برخی حملات متداول وب نقش داشته باشد.

برای مثال:

• الگوهای مشکوک مرتبط با SQL Injection
• بخشی از درخواست‌های مرتبط با XSS
• درخواست‌های غیرعادی به مسیرهای حساس
• برخی الگوهای اسکن خودکار
• برخی حملات پرتکرار در لایه برنامه

آیا WAF جایگزین Server Hardening است؟

خیر.

WAF عمدتاً روی ترافیک وب تمرکز دارد.

این ابزار نمی‌تواند به‌تنهایی مشکلاتی مانند رمز SSH ضعیف، مجوز اشتباه فایل‌ها یا آسیب‌پذیری یک سرویس شبکه دیگر را برطرف کند.

تفاوت WAF و فایروال شبکه

فایروال شبکه معمولاً ارتباطات را بر اساس عواملی مانند IP، پورت و پروتکل مدیریت می‌کند.

WAF روی درخواست‌های وب و قواعد مرتبط با لایه برنامه تمرکز دارد.

استفاده هم‌زمان از هر دو می‌تواند پوشش دفاعی کامل‌تری فراهم کند.

اهمیت تنظیم صحیح WAF

قوانین بیش از حد سخت‌گیرانه ممکن است درخواست‌های قانونی کاربران را مسدود کنند.

به همین دلیل، فعال‌سازی WAF باید همراه با نظارت بر False Positive و آزمایش مسیرهای مهم سایت باشد.

مرحله هجدهم: بررسی امنیت سرور با ابزارهای Audit

پس از اعمال تنظیمات، باید وضعیت امنیتی سرور بررسی شود.

فرایند Security Audit برای شناسایی ضعف‌ها، عدم انطباق با سیاست‌ها و مشکلات پیکربندی کاربرد دارد.

استفاده از Lynis

Lynis ابزاری برای ارزیابی امنیتی سیستم‌های مبتنی بر Unix و لینوکس است.

این ابزار می‌تواند مجموعه‌ای از بررسی‌های امنیتی را انجام دهد و پیشنهادهایی برای بهبود تنظیمات ارائه کند.

در توزیع‌هایی که بسته مناسب در مخازن موجود باشد:

sudo apt install lynis

برای اجرای ارزیابی محلی:

sudo lynis audit system

نتایج باید با توجه به نقش واقعی سرور تحلیل شوند.

هر پیشنهاد ابزار الزاماً برای تمام محیط‌ها مناسب نیست.

استفاده از OpenSCAP

OpenSCAP در بعضی محیط‌ها برای ارزیابی پیکربندی سیستم بر اساس سیاست‌ها و Baselineهای امنیتی کاربرد دارد.

قابلیت‌ها و محتوای ارزیابی به توزیع، نسخه و Profile مورد استفاده بستگی دارند.

استفاده از CIS Benchmark

CIS Benchmark مجموعه‌ای از توصیه‌های امنیتی برای سیستم‌عامل‌ها و نرم‌افزارهای مختلف است.

این توصیه‌ها می‌توانند در تعریف Baseline سخت‌سازی کمک کنند.

اما اجرای تمام کنترل‌ها بدون بررسی اثر آن‌ها بر سرویس‌های عملیاتی توصیه نمی‌شود.

اهمیت اسکن آسیب‌پذیری

در کنار Audit پیکربندی، بررسی آسیب‌پذیری بسته‌ها و سرویس‌ها نیز ضرورت دارد.

اسکن آسیب‌پذیری باید روی دارایی‌های تحت مالکیت یا با مجوز مشخص انجام شود.

نتیجه اسکن نیز باید از نظر احتمال سوءاستفاده، میزان در معرض بودن سرویس و اهمیت دارایی اولویت‌بندی شود.

اشتباهات رایج در Server Hardening

بسیاری از مشکلات امنیتی سرور نه از نبود ابزارهای پیشرفته، بلکه از تصمیم‌های نادرست مدیریتی ناشی می‌شوند.

کپی کردن دستورات بدون شناخت زیرساخت

یک دستور مناسب برای Ubuntu ممکن است در توزیع دیگر رفتار متفاوتی داشته باشد.

حتی دو سرور با سیستم‌عامل یکسان نیز ممکن است به دلیل تفاوت نقش، نیازمند تنظیمات متفاوت باشند.

بستن SSH قبل از آزمایش دسترسی جایگزین

غیرفعال کردن ورود با رمز عبور یا تغییر قوانین فایروال بدون آزمایش SSH Key می‌تواند دسترسی مدیر را قطع کند.

تصور اینکه تغییر پورت SSH کافی است

تغییر پورت تنها یک اقدام جانبی است و جایگزین کنترل‌های اصلی احراز هویت نمی‌شود.

غیرفعال کردن AppArmor یا SELinux برای رفع خطا

این اقدام ممکن است مشکل ظاهری برنامه را رفع کند، اما یکی از لایه‌های مهم دفاعی را از بین ببرد.

استفاده از مجوزهای بیش از حد برای فایل‌ها

اعمال chmod 777 روی مسیرهای حساس می‌تواند ریسک تغییر غیرمجاز فایل‌ها را افزایش دهد.

نصب ابزارهای امنیتی بدون نگهداری

ابزارهایی مانند Fail2ban، WAF و سامانه‌های مانیتورینگ اگر درست پیکربندی و بررسی نشوند، ارزش امنیتی محدودی خواهند داشت.

نگهداری همه بکاپ‌ها روی سرور اصلی

این روش می‌تواند در برابر خرابی گسترده یا نفوذ به سرور آسیب‌پذیر باشد.

فراموش کردن IPv6

اگر دسترسی IPv6 فعال باشد، باید محدودیت‌های شبکه برای آن نیز بررسی شوند.

استفاده از نسخه‌های قدیمی و خارج از پشتیبانی

حتی پیکربندی مناسب نمی‌تواند تمام ضعف‌های یک نرم‌افزار بدون وصله امنیتی را جبران کند.

بی‌توجهی به مانیتورینگ پس از استقرار

امن‌سازی یک‌باره سرور برای حفاظت بلندمدت کافی نیست.

تغییرات زیرساختی، نصب افزونه‌ها و انتشار آسیب‌پذیری‌های جدید نیازمند بازبینی مستمر هستند.

چک‌لیست کامل Server Hardening برای سرور لینوکس

چک‌لیست زیر برای ارزیابی اولیه سرورهای لینوکسی میزبان وب‌سایت طراحی شده است.

امنیت سیستم‌عامل

• [ ] از نسخه پشتیبانی‌شده سیستم‌عامل استفاده می‌شود.
• [ ] بسته‌های امنیتی به‌روز هستند.
• [ ] نسخه کرنل و وضعیت وصله‌های امنیتی بررسی شده است.
• [ ] سرویس‌های غیرضروری شناسایی و حذف یا غیرفعال شده‌اند.
• [ ] تغییرات مهم سیستم مستندسازی می‌شوند.
• [ ] راهکار مناسب برای بازیابی اضطراری وجود دارد.

امنیت SSH

• [ ] ورود مستقیم root مطابق سیاست امنیتی محدود شده است.
• [ ] احراز هویت مبتنی بر SSH Key فعال است.
• [ ] کلیدهای خصوصی به‌صورت امن نگهداری می‌شوند.
• [ ] ورود با رمز عبور در صورت امکان و پس از آزمایش جایگزین محدود شده است.
• [ ] دسترسی SSH به شبکه‌ها یا کاربران مجاز محدود است.
• [ ] رویدادهای ورود ناموفق بررسی می‌شوند.

امنیت شبکه و فایروال

• [ ] فایروال مناسب فعال و تنظیم شده است.
• [ ] فقط پورت‌های ضروری در دسترس هستند.
• [ ] قوانین IPv4 و IPv6 بررسی شده‌اند.
• [ ] سرویس‌های داخلی مستقیماً در معرض اینترنت نیستند.
• [ ] تنظیمات فایروال ابری و میزبان هماهنگ هستند.
• [ ] تغییرات قوانین شبکه ثبت می‌شوند.

امنیت کاربران و دسترسی‌ها

• [ ] کاربران غیرضروری حذف یا غیرفعال شده‌اند.
• [ ] دسترسی sudo محدود و قابل‌ردگیری است.
• [ ] حساب‌های مشترک مدیریتی استفاده نمی‌شوند یا کنترل مشخص دارند.
• [ ] مجوز فایل‌ها و دایرکتوری‌ها بررسی شده است.
• [ ] فایل‌های حساس برای کاربران غیرمجاز قابل‌خواندن نیستند.
• [ ] اصل Least Privilege اجرا می‌شود.

امنیت وب‌سرور

• [ ] نسخه Nginx یا Apache پشتیبانی می‌شود.
• [ ] سایت‌ها از HTTPS معتبر استفاده می‌کنند.
• [ ] پروتکل‌ها و تنظیمات TLS بررسی شده‌اند.
• [ ] صفحات و پیکربندی‌های نمونه حذف شده‌اند.
• [ ] Virtual Hostهای پیش‌فرض بررسی شده‌اند.
• [ ] هدرهای امنیتی متناسب با برنامه تنظیم شده‌اند.
• [ ] فایل‌های محرمانه از مسیر عمومی قابل دریافت نیستند.

امنیت برنامه و PHP

• [ ] نسخه PHP دارای پشتیبانی امنیتی است.
• [ ] نمایش خطاهای حساس در Production غیرفعال است.
• [ ] فایل‌های پیکربندی محافظت می‌شوند.
• [ ] کاربران اجرایی برنامه حداقل مجوز لازم را دارند.
• [ ] فایل‌های قابل‌نوشتن از کد اصلی تفکیک شده‌اند.
• [ ] کلیدها و توکن‌ها در محل مناسب نگهداری می‌شوند.

امنیت پایگاه داده

• [ ] دسترسی پایگاه داده محدود به مسیرهای ضروری است.
• [ ] حساب اختصاصی برای برنامه‌ها تعریف شده است.
• [ ] مجوزهای پایگاه داده حداقلی هستند.
• [ ] ارتباطات شبکه‌ای حساس رمزنگاری می‌شوند.
• [ ] نسخه پشتیبان پایگاه داده تهیه می‌شود.
• [ ] عملیات بازیابی دوره‌ای آزمایش شده است.

نظارت و محافظت

• [ ] لاگ‌های سیستم و وب‌سرور ثبت می‌شوند.
• [ ] دسترسی به لاگ‌ها محدود است.
• [ ] مدت نگهداری لاگ‌ها مشخص شده است.
• [ ] رخدادهای مهم هشدار تولید می‌کنند.
• [ ] تغییرات فایل‌های حساس در صورت نیاز پایش می‌شوند.
• [ ] سامانه‌های امنیتی مانند AppArmor یا SELinux مطابق معماری فعال‌اند.
• [ ] ابزارهای مقابله با تلاش‌های ورود مکرر بررسی شده‌اند.

پشتیبان‌گیری و بازیابی

• [ ] بکاپ منظم و متناسب با اهمیت داده‌ها تهیه می‌شود.
• [ ] حداقل یک نسخه مستقل از سرور اصلی وجود دارد.
• [ ] دسترسی به بکاپ‌ها محدود است.
• [ ] نسخه‌های مهم در برابر حذف یا تغییر غیرمجاز محافظت شده‌اند.
• [ ] بازیابی بکاپ آزمایش شده است.
• [ ] RPO و RTO متناسب با نیاز کسب‌وکار مشخص شده‌اند.

نگهداری امنیتی

• [ ] ارزیابی امنیتی دوره‌ای انجام می‌شود.
• [ ] آسیب‌پذیری‌های جدید بررسی می‌شوند.
• [ ] تغییرات مهم قبل از اعمال آزمایش می‌شوند.
• [ ] تنظیمات امنیتی با نسخه سیستم‌عامل سازگارند.
• [ ] مسئولیت هر بخش از زیرساخت مشخص است.
• [ ] فرایند پاسخ به رخداد تعریف شده است.

برنامه پیشنهادی برای نگهداری امنیت سرور

یکی از مؤثرترین روش‌ها برای حفظ نتیجه Server Hardening، تعریف برنامه بازبینی دوره‌ای است.

اقدامات روزانه

بررسی هشدارهای مهم، وضعیت سرویس‌های حیاتی، موفقیت عملیات بکاپ و رخدادهای غیرعادی ورود.

اقدامات هفتگی

بررسی وضعیت وصله‌های امنیتی، مصرف منابع، تغییرات غیرمنتظره تنظیمات و مشکلات ثبت‌شده در لاگ‌ها.

اقدامات ماهانه

بازبینی کاربران مدیریتی، پورت‌های باز، سرویس‌های نصب‌شده، وضعیت گواهی‌های TLS و نتایج Auditهای امنیتی.

اقدامات دوره‌ای و پس از تغییرات مهم

آزمایش بازیابی بکاپ، ارزیابی سیاست‌های فایروال، بررسی دسترسی‌های سرویس‌ها و به‌روزرسانی مستندات معماری.

این زمان‌بندی یک نمونه است و باید بر اساس اهمیت خدمات، حجم تغییرات و الزامات امنیتی هر سازمان تنظیم شود.

سؤالات متداول درباره Server Hardening

Server Hardening چیست؟

Server Hardening فرایند کاهش سطح حمله و تقویت پیکربندی امنیتی سرور است. این فرایند شامل مدیریت دسترسی‌ها، ایمن‌سازی شبکه، حذف سرویس‌های غیرضروری، نصب وصله‌های امنیتی و نظارت مستمر می‌شود.

آیا لینوکس به‌صورت پیش‌فرض امن است؟

توزیع‌های معتبر لینوکس دارای قابلیت‌های امنیتی متعددی هستند، اما امنیت نهایی به تنظیمات، نرم‌افزارهای نصب‌شده، نسخه سیستم‌عامل و شیوه مدیریت آن بستگی دارد.

مهم‌ترین اقدام برای امن‌سازی سرور لینوکس چیست؟

نمی‌توان یک اقدام را برای همه سرورها مهم‌ترین دانست. به‌روزرسانی امنیتی، محدودسازی دسترسی مدیریتی، استفاده از احراز هویت قوی و کاهش سرویس‌های در معرض اینترنت از اقدامات پایه محسوب می‌شوند.

آیا تغییر پورت SSH امنیت سرور را تضمین می‌کند؟

خیر. تغییر پورت ممکن است بخشی از تلاش‌های خودکار را کاهش دهد، اما جایگزین SSH Key، MFA و محدودسازی دسترسی نیست.

آیا نصب Fail2ban کافی است؟

خیر. Fail2ban تنها یکی از کنترل‌های کمکی برای پاسخ به الگوهای مشخص ورود ناموفق است و نمی‌تواند جایگزین سخت‌سازی کامل سرور شود.

آیا UFW برای محافظت از سرور کافی است؟

UFW برای مدیریت قوانین فایروال در بسیاری از سرورهای Ubuntu مفید است، اما امنیت سرور به احراز هویت، وصله‌های امنیتی، تنظیمات سرویس‌ها و کنترل‌های دیگر نیز وابسته است.

آیا Server Hardening سرعت سایت را کاهش می‌دهد؟

بعضی کنترل‌های امنیتی ممکن است مصرف منابع یا تأخیر محدودی ایجاد کنند، اما تأثیر واقعی به نوع تنظیمات و زیرساخت بستگی دارد. حذف سرویس‌های اضافی و مدیریت صحیح منابع حتی می‌تواند عملکرد عملیاتی را بهبود دهد.

آیا Hardening برای سرور وردپرس ضروری است؟

بله. امنیت وردپرس تنها به افزونه‌ها و تنظیمات خود وردپرس وابسته نیست. امنیت SSH، وب‌سرور، PHP، پایگاه داده و فایل‌های سیستم نیز اهمیت دارند.

آیا می‌توان Server Hardening را کاملاً خودکار کرد؟

بخشی از فرایند را می‌توان با ابزارهای مدیریت پیکربندی و اسکریپت‌های کنترل‌شده خودکار کرد. بااین‌حال، انتخاب سیاست‌ها، ارزیابی ریسک و بررسی سازگاری نیازمند تصمیم‌گیری فنی هستند.

آیا پس از Hardening امکان هک سرور وجود دارد؟

بله. سخت‌سازی احتمال موفقیت برخی حملات و دامنه پیامدهای آن‌ها را کاهش می‌دهد، اما امنیت مطلق ایجاد نمی‌کند.

تفاوت Server Hardening و Penetration Testing چیست؟

Server Hardening بر اصلاح تنظیمات و کاهش ریسک تمرکز دارد. Penetration Testing یا تست نفوذ، با مجوز مشخص برای ارزیابی امکان سوءاستفاده از ضعف‌های امنیتی انجام می‌شود. این دو فعالیت مکمل یکدیگر هستند.

هر چند وقت یک‌بار باید سرور را Hardening کرد؟

Hardening یک فرایند مستمر است. پس از استقرار اولیه، تنظیمات باید به‌صورت دوره‌ای و پس از تغییرات مهم، نصب سرویس جدید یا انتشار آسیب‌پذیری‌های مرتبط بازبینی شوند.

آیا Server Hardening از حملات DDoS جلوگیری می‌کند؟

بعضی اقدامات مانند Rate Limiting و مدیریت منابع می‌توانند در کاهش اثر برخی حملات کمک کنند. اما حملات DDoS بزرگ معمولاً به زیرساخت دفاعی شبکه، سرویس‌های توزیع‌شده یا محافظت بالادستی نیاز دارند.

آیا Server Hardening جایگزین WAF است؟

خیر. Hardening بر امنیت کلی سرور و سرویس‌ها تمرکز دارد، درحالی‌که WAF بیشتر بر کنترل ترافیک لایه وب متمرکز است.

جمع‌بندی؛ چگونه امنیت سرور لینوکس را به‌صورت اصولی افزایش دهیم؟

Server Hardening یکی از مهم‌ترین اقدامات برای محافظت از زیرساخت میزبانی وب‌سایت است. این فرایند با کاهش سطح حمله، مدیریت دسترسی‌ها و اصلاح تنظیمات امنیتی، احتمال سوءاستفاده از ضعف‌های سیستم‌عامل و سرویس‌ها را کاهش می‌دهد.

برای امن‌سازی سرور لینوکس باید ابتدا معماری و سرویس‌های موجود شناسایی شوند. سپس اقدامات پایه مانند به‌روزرسانی بسته‌ها، ایمن‌سازی SSH، تنظیم فایروال، حذف سرویس‌های غیرضروری و اجرای اصل حداقل دسترسی انجام شوند.

در مراحل بعدی، محافظت از وب‌سرور، PHP، پایگاه داده، فایل‌های حساس و محیط‌های کانتینری اهمیت پیدا می‌کند. استفاده از AppArmor یا SELinux، ثبت و تحلیل لاگ‌ها، پایش تغییرات و ارزیابی امنیتی دوره‌ای نیز می‌تواند لایه‌های دفاعی بیشتری ایجاد کند.

در کنار این اقدامات، تهیه بکاپ مستقل و آزمایش‌شده برای کاهش پیامدهای رخدادهای امنیتی ضروری است.

نکته اساسی این است که امن‌سازی سرور یک اقدام یک‌باره نیست؛ بلکه فرایندی مستمر از پیکربندی، ارزیابی، اصلاح و نظارت محسوب می‌شود.

با استفاده از چک‌لیست Server Hardening و اجرای کنترل‌های متناسب با نقش سرور، می‌توان زیرساختی امن‌تر، قابل‌مدیریت‌تر و مقاوم‌تر برای میزبانی وب‌سایت‌ها و سرویس‌های اینترنتی ایجاد کرد.