امنیت Nginx چیست؟ مهم‌ترین تنظیمات Hardening وب‌سرور Nginx

امنیت Nginx به مجموعه‌ای از تنظیمات، کنترل‌های دسترسی و اقدامات حفاظتی گفته می‌شود که برای کاهش آسیب‌پذیری‌های وب‌سرور Nginx و جلوگیری از دسترسی غیرمجاز، افشای اطلاعات، حملات Brute Force، سوءاستفاده از درخواست‌های HTTP و اختلال در سرویس انجام می‌شوند. مهم‌ترین اقدامات شامل فعال‌سازی HTTPS، ایمن‌سازی TLS، تنظیم Security Headers، محدودسازی درخواست‌ها، محافظت از فایل‌های حساس و به‌روزرسانی منظم وب‌سرور است.

مقدمه: چرا امنیت وب‌سرور Nginx اهمیت دارد؟

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

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

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

در سناریوی دیگری، وب‌سایت پشت یک شبکه توزیع محتوا یا CDN قرار گرفته است، اما Nginx آدرس IP واقعی کاربران را اشتباه تشخیص می‌دهد. نتیجه ممکن است اعمال محدودیت روی تمام بازدیدکنندگان یا بی‌اثر شدن سیستم جلوگیری از درخواست‌های مخرب باشد.

اینجاست که مفهوم Nginx Hardening یا سخت‌سازی امنیتی Nginx اهمیت پیدا می‌کند.

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

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

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

امنیت Nginx چیست و چه تهدیداتی را پوشش می‌دهد؟

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

Nginx ممکن است نقش وب‌سرور اصلی، Reverse Proxy، توزیع‌کننده بار یا نقطه ورود ترافیک HTTPS را بر عهده داشته باشد. نوع تهدیدات نیز به همین نقش بستگی دارد.

مهم‌ترین تهدیدات امنیتی Nginx

دسترسی غیرمجاز به فایل‌ها: تنظیم نادرست مسیرهای root و alias یا مجوزهای فایل می‌تواند باعث دسترسی عمومی به اطلاعاتی شود که نباید در اینترنت منتشر شوند.

حملات Brute Force: ارسال تعداد زیادی درخواست ورود با ترکیب‌های مختلف نام کاربری و رمز عبور می‌تواند حساب‌های ضعیف را در معرض خطر قرار دهد.

حملات DoS و DDoS: حجم زیاد درخواست‌ها یا اتصالات می‌تواند منابع سرور، اپلیکیشن یا سرویس‌های وابسته را تحت فشار قرار دهد.

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

حملات لایه وب: تهدیداتی مانند Cross-Site Scripting یا XSS، تزریق SQL، CSRF و سوءاستفاده از ورودی‌های برنامه معمولاً در لایه اپلیکیشن شکل می‌گیرند. Nginx می‌تواند بخشی از دفاع را فراهم کند، اما جایگزین کدنویسی امن نیست.

ضعف ارتباطات رمزنگاری‌شده: استفاده از نسخه‌های قدیمی TLS، گواهی نامعتبر یا تنظیمات نادرست HTTPS می‌تواند امنیت انتقال اطلاعات را کاهش دهد.

تفاوت امنیت Nginx با امنیت سایت

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

فرض کنید یک فروشگاه اینترنتی از Nginx، PHP-FPM، وردپرس و ووکامرس استفاده می‌کند. در این معماری، هر بخش مسئولیت امنیتی مخصوص خود را دارد.

Nginx درخواست‌های ورودی را مدیریت می‌کند، PHP-FPM کدهای PHP را اجرا می‌کند، وردپرس مسئول بخش بزرگی از منطق اپلیکیشن است و پایگاه داده اطلاعات کاربران و سفارش‌ها را نگهداری می‌کند.

اگر افزونه‌ای دارای آسیب‌پذیری SQL Injection باشد، صرفاً فعال کردن HTTPS یا مخفی کردن نسخه Nginx آن مشکل را برطرف نمی‌کند.

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

Hardening وب‌سرور Nginx چیست؟

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

در Nginx این فرایند معمولاً شامل موارد زیر است:

• کاهش اطلاعات قابل مشاهده درباره نرم‌افزار و زیرساخت
• استفاده از پروتکل‌های ارتباطی امن
• کنترل تعداد و نوع درخواست‌های ورودی
• محدودسازی دسترسی به مسیرهای مدیریتی و فایل‌های حساس
• جداسازی دسترسی سرویس‌ها و کاربران سیستم‌عامل
• کنترل ارتباط میان Reverse Proxy و سرورهای داخلی
• فعال‌سازی ثبت رویدادها و پایش رفتار غیرعادی
• آزمون منظم پیکربندی و مدیریت وصله‌های امنیتی

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

برای نمونه، محدود کردن درخواست‌های HTTP ممکن است برای یک وب‌سایت محتوایی مناسب باشد، اما همان تنظیمات روی API یک اپلیکیشن پرترافیک باعث اختلال شود.

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

بررسی وضعیت فعلی Nginx پیش از اعمال تنظیمات امنیتی

اولین مرحله در افزایش امنیت Nginx شناخت وضعیت فعلی سرور است.

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

بررسی نسخه نصب‌شده Nginx

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

nginx -v

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

nginx -V

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

این اطلاعات برای بررسی پشتیبانی از TLS، ماژول Real IP و سایر قابلیت‌های امنیتی مفید است.

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

شناسایی محل فایل‌های پیکربندی

در بسیاری از نصب‌های لینوکسی، پیکربندی اصلی در مسیر زیر قرار دارد:

/etc/nginx/nginx.conf

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

/etc/nginx/sites-available/
/etc/nginx/sites-enabled/
/etc/nginx/conf.d/

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

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

sudo nginx -T

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

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

تهیه نسخه پشتیبان از تنظیمات

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

برای نمونه:

sudo cp -a /etc/nginx /root/nginx-config-backup

این دستور صرفاً یک نمونه برای محیط‌های متداول است و باید متناسب با سیاست پشتیبان‌گیری سرور تنظیم شود.

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

به‌روزرسانی Nginx و مدیریت آسیب‌پذیری‌های امنیتی

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

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

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

نصب به‌روزرسانی از مخازن معتبر

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

برای مثال:

sudo apt update
sudo apt list --upgradable

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

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

اهمیت به‌روزرسانی OpenSSL

OpenSSL یکی از کتابخانه‌هایی است که در بسیاری از نصب‌ها برای قابلیت‌های TLS استفاده می‌شود.

قدیمی بودن یا وجود ضعف امنیتی در کتابخانه رمزنگاری می‌تواند بر امنیت ارتباطات تأثیر بگذارد.

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

حذف ماژول‌های غیرضروری

هر ماژول اضافه می‌تواند پیچیدگی و سطح حمله را افزایش دهد.

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

این موضوع به‌ویژه درباره ماژول‌های شخص ثالث اهمیت دارد؛ زیرا ممکن است چرخه انتشار اصلاحات امنیتی آن‌ها با خود Nginx متفاوت باشد.

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

تنظیم مجوزها و کاهش دسترسی پردازش‌های Nginx

یکی از اصول امنیت سرور، اجرای سرویس‌ها با کمترین سطح دسترسی لازم یا Least Privilege است.

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

تفکیک پردازش اصلی و Worker

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

در مقابل، پردازش‌های Worker معمولاً باید با حساب کاربری محدود اجرا شوند.

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

ps aux | grep '[n]ginx'

همچنین تنظیم user در بخش اصلی پیکربندی Nginx قابل بررسی است.

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

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

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

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

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

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

سخت‌سازی Nginx بدون ایمن‌سازی میزبان کامل نیست.

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

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

تنظیمات امنیتی SSL و TLS در Nginx

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

HTTPS با استفاده از TLS به محافظت از محرمانگی و یکپارچگی داده‌های در حال انتقال کمک می‌کند.

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

استفاده از TLS 1.2 و TLS 1.3

برای بسیاری از سرویس‌های عمومی امروزی، استفاده از TLS 1.2 و TLS 1.3 نقطه شروع مناسبی است.

نمونه تنظیم:

ssl_protocols TLSv1.2 TLSv1.3;

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

پروتکل‌های قدیمی‌تر مانند TLS 1.0 و TLS 1.1 نباید بدون نیاز سازگاری مستند فعال بمانند.

نکته مهم این است که پشتیبانی واقعی از TLS 1.3 به نسخه Nginx و کتابخانه رمزنگاری آن وابسته است.

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

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

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

تنظیم ssl_ciphers عمدتاً روی مجموعه الگوریتم‌های TLS 1.2 و نسخه‌های قدیمی‌تر اثر می‌گذارد؛ مدیریت Cipher Suiteهای TLS 1.3 به سازوکار کتابخانه رمزنگاری و تنظیمات مرتبط وابسته است.

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

تنظیم گواهی SSL معتبر

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

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate /etc/ssl/example/fullchain.pem;
    ssl_certificate_key /etc/ssl/example/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
}

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

گواهی باید نام دامنه را پوشش دهد، زنجیره اعتبار آن صحیح باشد و تاریخ انقضای آن کنترل شود.

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

مدیریت Session و TLS Tickets

Nginx امکاناتی برای ازسرگیری نشست‌های TLS دارد که می‌توانند تعداد Handshakeهای کامل را کاهش دهند.

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

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

ssl_session_tickets off;

این اقدام باید با توجه به نوع TLS، سیاست مدیریت کلید و اثر احتمالی بر کارایی بررسی شود.

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

فعال‌سازی HTTPS اجباری و HSTS در Nginx

یکی از اقدامات مهم امنیتی جلوگیری از استفاده ناخواسته کاربران از HTTP است.

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

انتقال HTTP به HTTPS

نمونه تنظیم ریدایرکت:

server {
    listen 80;
    server_name example.com;

    return 301 https://example.com$request_uri;
}

در این نمونه، درخواست‌های HTTP به نسخه HTTPS همان دامنه هدایت می‌شوند.

در سایت‌هایی با چند دامنه یا ساختار خاص، آدرس مقصد باید متناسب با طراحی سایت تعیین شود.

هدر HSTS چیست؟

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

نمونه تنظیم:

add_header Strict-Transport-Security "max-age=31536000" always;

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

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

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

احتیاط درباره includeSubDomains و Preload

گزینه includeSubDomains دامنه‌های فرعی را نیز تحت پوشش سیاست HSTS قرار می‌دهد.

همچنین امکان درخواست قرار گرفتن دامنه در فهرست HSTS Preload مرورگرها وجود دارد.

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

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

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

مهم‌ترین Security Headers برای افزایش امنیت Nginx

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

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

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

هدر X-Content-Type-Options

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

نمونه:

add_header X-Content-Type-Options "nosniff" always;

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

در کنار این تنظیم، سرور باید MIME Type مناسب هر فایل را نیز ارسال کند.

هدر X-Frame-Options

یکی از تهدیدات مرتبط با صفحات وب، Clickjacking است.

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

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

add_header X-Frame-Options "SAMEORIGIN" always;

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

اگر سایت نباید تحت هیچ شرایطی داخل Frame قرار بگیرد، مقدار DENY نیز قابل بررسی است.

در کاربردهای جدید، دستور frame-ancestors در CSP کنترل دقیق‌تری ارائه می‌دهد.

سیاست امنیت محتوا یا CSP

Content Security Policy یکی از کنترل‌های مهم امنیتی سمت مرورگر است.

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

CSP همچنین می‌تواند اثر بعضی حملات XSS را کاهش دهد.

اما طراحی یک CSP مناسب به ساختار واقعی سایت بستگی دارد.

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

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

add_header Content-Security-Policy-Report-Only "default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'" always;

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

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

همچنین باید توجه داشت که frame-ancestors در حالت Report-Only مانع عملی بارگذاری در Frame نمی‌شود.

هدر Referrer-Policy

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

نمونه تنظیم:

add_header Referrer-Policy "strict-origin-when-cross-origin" always;

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

البته نباید اطلاعات حساس مانند Tokenهای احراز هویت را در URL قرار داد و صرفاً به Referrer-Policy اتکا کرد.

هدر Permissions-Policy

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

مثال:

add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;

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

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

نکته مهم درباره ارث‌بری هدرها در Nginx

یکی از اشتباهات رایج آن است که مدیر سرور هدرهای امنیتی را در بخش server تعریف می‌کند و تصور می‌کند تمام مسیرها حتماً همان هدرها را خواهند داشت.

در مدل معمول ارث‌بری Nginx، تعریف add_header در یک سطح داخلی مانند location می‌تواند مانع به ارث رسیدن مجموعه هدرهای سطح بالاتر شود.

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

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

مخفی کردن نسخه Nginx و کاهش افشای اطلاعات

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

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

استفاده از server_tokens off

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

server_tokens off;

این دستور معمولاً در بخش http یا server قرار می‌گیرد.

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

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

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

مدیریت صفحات خطای سرور

صفحات خطا نیز باید از نظر افشای اطلاعات بررسی شوند.

بهتر است خطاهای قابل مشاهده برای کاربران، جزئیات داخلی مانند مسیر فایل‌ها، اطلاعات برنامه، تنظیمات Debug یا داده‌های حساس را نشان ندهند.

در مقابل، جزئیات موردنیاز برای عیب‌یابی باید در لاگ‌های محافظت‌شده ثبت شوند.

جلوگیری از دسترسی به فایل‌های حساس در Nginx

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

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

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

جلوگیری از نمایش فایل‌های مخفی

در بسیاری از پروژه‌ها، نام فایل‌های مخفی با نقطه آغاز می‌شود.

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

location ~ /\.(?!well-known(?:/|$)) {
    deny all;
}

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

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

بااین‌وجود، ترتیب و اولویت قوانین location در Nginx باید بررسی شود تا قانون واقعاً اجرا شود.

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

فایل‌هایی با پسوندهای مرتبط با Backup یا خروجی پایگاه داده نباید در مسیر عمومی قابل دانلود باشند.

نمونه قانون:

location ~* \.(?:bak|old|orig|save|swp|sql|log)$ {
    deny all;
}

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

اما نباید آن را یک فهرست کامل در نظر گرفت؛ زیرا نام و پسوند فایل‌های پشتیبان در پروژه‌های مختلف متفاوت است.

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

غیرفعال کردن Directory Listing

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

در Nginx می‌توان تنظیم زیر را بررسی کرد:

autoindex off;

قابلیت Autoindex در تنظیم پیش‌فرض Nginx غیرفعال است؛ بااین‌حال، باید مطمئن شد که در فایل‌های دیگر یا مسیرهای خاص فعال نشده باشد.

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

اگر نام یک فایل محرمانه معلوم باشد و فایل همچنان در مسیر عمومی قرار داشته باشد، صرفاً خاموش بودن Directory Listing از دانلود آن جلوگیری نمی‌کند.

اهمیت تنظیم صحیح root و alias

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

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

هنگام بررسی این تنظیمات باید مشخص شود هر URL دقیقاً به کدام مسیر فایل‌سیستم نگاشت می‌شود.

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

محدود کردن حجم درخواست‌ها و تنظیم Timeout در Nginx

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

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

تنظیم client_max_body_size

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

مثال:

client_max_body_size 20m;

در این نمونه، درخواست‌هایی که بدنه آن‌ها از حد تعیین‌شده بزرگ‌تر باشد می‌توانند با پاسخ HTTP 413 رد شوند.

مقدار مناسب به کاربرد سایت بستگی دارد.

برای یک وب‌سایت ساده، سقف نسبتاً کوچک ممکن است کافی باشد؛ اما سایت‌هایی که آپلود ویدئو، فایل‌های حجیم یا تصاویر بزرگ دارند به محدودیت متفاوتی نیاز خواهند داشت.

در وردپرس نیز تنظیمات PHP مانند upload_max_filesize و post_max_size باید با محدودیت Nginx هماهنگ باشند.

تنظیم Timeout دریافت درخواست

نمونه تنظیمات:

client_body_timeout 15s;
client_header_timeout 15s;
keepalive_timeout 30s;
send_timeout 30s;

این مقادیر صرفاً مثال اولیه هستند.

client_header_timeout مدت مجاز برای دریافت کامل سربرگ درخواست را محدود می‌کند.

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

keepalive_timeout مدت انتظار اتصال Keep-Alive در حالت بیکار را کنترل می‌کند.

send_timeout نیز به فاصله زمانی میان عملیات ارسال داده مربوط است و به معنای محدودیت زمانی کل دانلود نیست.

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

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

جلوگیری از Brute Force با Rate Limiting در Nginx

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

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

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

تنظیم limit_req_zone

برای تعریف یک ناحیه محدودسازی درخواست می‌توان از تنظیم زیر در بخش http استفاده کرد:

limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;

این دستور یک ناحیه حافظه مشترک با نام perip تعریف می‌کند.

در این نمونه، نرخ پایه برای هر IP برابر با ۱۰ درخواست در ثانیه است.

اما این مقدار به معنای سقف ثابت و مطلق ۱۰ درخواست در هر ثانیه تقویمی نیست؛ رفتار واقعی به سازوکار محدودسازی، تنظیم Burst و زمان‌بندی درخواست‌ها بستگی دارد.

اعمال محدودیت درخواست

در یک مسیر مشخص می‌توان از دستور زیر استفاده کرد:

limit_req zone=perip burst=20 nodelay;

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

گزینه nodelay باعث می‌شود درخواست‌های مجاز در محدوده Burst بدون تأخیر ناشی از صف محدودسازی پردازش شوند.

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

استفاده از کد وضعیت 429

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

برای مشخص‌تر شدن دلیل رد درخواست، می‌توان تنظیم زیر را اعمال کرد:

limit_req_status 429;

کد 429 نشان‌دهنده Too Many Requests است.

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

انتخاب محدودیت مناسب برای مسیرهای مختلف

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

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

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

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

بهتر است ابتدا رفتار واقعی ترافیک بررسی شود و سپس برای مسیرهای حساس سیاست اختصاصی تعریف شود.

محدودسازی اتصالات هم‌زمان با limit_conn

Rate Limiting و Connection Limiting دو مفهوم مرتبط اما متفاوت هستند.

Rate Limiting سرعت پردازش درخواست‌ها را کنترل می‌کند، درحالی‌که Connection Limiting تعداد درخواست‌ها یا اتصالات هم‌زمان محاسبه‌شده را محدود می‌کند.

نمونه تنظیم محدودیت اتصال

در بخش http:

limit_conn_zone $binary_remote_addr zone=peripconn:10m;

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

limit_conn peripconn 20;

این نمونه یک محدودیت مبتنی بر IP تعریف می‌کند.

در HTTP/2 و HTTP/3، درخواست‌های هم‌زمان می‌توانند جداگانه در محاسبه محدودیت اتصال لحاظ شوند؛ بنابراین نباید این عدد را صرفاً معادل تعداد اتصال‌های TCP دانست.

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

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

استفاده از حالت Dry Run

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

برای Rate Limiting:

limit_req_dry_run on;

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

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

امنیت Nginx پشت CDN و تشخیص IP واقعی کاربران

بسیاری از وب‌سایت‌ها ترافیک خود را از طریق CDN یا Reverse Proxy دریافت می‌کنند.

در این معماری، Nginx ممکن است به‌جای IP کاربر، آدرس سرور CDN را مشاهده کند.

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

مشکل تشخیص اشتباه IP

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

اگر Nginx تمام درخواست‌ها را متعلق به IP همان نقطه تشخیص دهد، Rate Limiting ممکن است کاربران مختلف را به‌عنوان یک کلاینت واحد محدود کند.

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

استفاده امن از Real IP

ماژول Real IP امکان جایگزینی آدرس کلاینت با آدرس ارسال‌شده از سوی پروکسی‌های مورد اعتماد را فراهم می‌کند.

دستورهای اصلی شامل موارد زیر هستند:

set_real_ip_from ...;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

مقدار set_real_ip_from باید فقط شامل آدرس‌ها یا محدوده‌های واقعی پروکسی‌های مورد اعتماد باشد.

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

همچنین نوع هدر باید با مستندات ارائه‌دهنده CDN و نحوه ارسال ترافیک مطابقت داشته باشد.

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

بنابراین محدودسازی دسترسی به Origin Server نیز بخش مهمی از امنیت این معماری است.

کنترل دسترسی به بخش‌های مدیریتی Nginx

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

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

محدودسازی دسترسی با آدرس IP

برای مسیرهای مشخص می‌توان از دستورات allow و deny استفاده کرد.

مثال:

location /internal-admin/ {
    allow 192.0.2.10;
    deny all;

    proxy_pass http://127.0.0.1:8080;
}

آدرس IP در این مثال نمایشی است و باید با آدرس واقعی و مجاز جایگزین شود.

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

این روش برای سرویس‌هایی با کاربران مدیریتی محدود مناسب است، اما در محیط‌هایی که IP کاربران مرتب تغییر می‌کند ممکن است نگهداری دشواری داشته باشد.

استفاده از HTTP Basic Authentication

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

نمونه:

location /private/ {
    auth_basic "Restricted Area";
    auth_basic_user_file /etc/nginx/.htpasswd;
}

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

Basic Authentication باید روی HTTPS اجرا شود؛ زیرا سازوکار انتقال اطلاعات ورود آن به‌تنهایی رمزنگاری مستقل فراهم نمی‌کند.

برای سرویس‌های حساس، احراز هویت چندمرحله‌ای یا 2FA، دسترسی مبتنی بر هویت و استفاده از VPN یا Zero Trust Access می‌تواند لایه حفاظتی مناسب‌تری باشد.

محافظت از صفحات وضعیت

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

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

امنیت Reverse Proxy در Nginx

Nginx در بسیاری از معماری‌ها به‌عنوان Reverse Proxy در مقابل اپلیکیشن قرار می‌گیرد.

در این ساختار، درخواست ابتدا به Nginx می‌رسد و سپس به سرویس Backend منتقل می‌شود.

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

انتقال صحیح هدرها به Backend

نمونه تنظیم برای یک سرویس داخلی:

location / {
    proxy_pass http://127.0.0.1:8080;

    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

این تنظیمات به Backend کمک می‌کنند اطلاعاتی مانند Host و پروتکل اصلی درخواست را دریافت کند.

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

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

محافظت از ارتباط Nginx با Upstream

اگر ارتباط با سرور Backend از طریق شبکه غیرمطمئن برقرار می‌شود، استفاده از HTTPS همراه با اعتبارسنجی گواهی اهمیت دارد.

یکی از نکات مهم آن است که در ارتباطات HTTPS به Upstream، اعتبارسنجی گواهی باید به‌صورت صریح بررسی و پیکربندی شود.

دستور مرتبط:

proxy_ssl_verify on;

برای عملکرد صحیح، ممکن است تنظیم مرجع گواهی‌های مورد اعتماد، نام سرور TLS و SNI نیز لازم باشد.

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

جلوگیری از دسترسی مستقیم به Backend

اگر Backend تنها باید از طریق Nginx در دسترس باشد، بهتر است مستقیماً روی اینترنت منتشر نشود.

برای سرویس‌های مستقر روی همان ماشین، گوش دادن روی آدرس Loopback یا استفاده از Unix Socket می‌تواند مناسب باشد.

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

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

امنیت Nginx در سایت‌های وردپرسی

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

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

محافظت از wp-config.php

فایل wp-config.php یکی از حساس‌ترین فایل‌های وردپرس است.

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

دسترسی مستقیم HTTP به آن باید مسدود باشد.

نمونه:

location = /wp-config.php {
    deny all;
}

این قانون یک لایه دفاعی اضافی ایجاد می‌کند.

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

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

جلوگیری از اجرای PHP در پوشه Uploads

پوشه wp-content/uploads معمولاً برای نگهداری تصاویر، اسناد و فایل‌های رسانه‌ای استفاده می‌شود.

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

نمونه قانون دفاعی:

location ~* ^/wp-content/uploads/.*\.(?:php|phtml|phar)$ {
    return 403;
}

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

باید مطمئن شد که ترتیب این قانون نسبت به Location عمومی PHP صحیح است.

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

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

تنظیم امن PHP-FPM

در سایت‌های PHP، Nginx معمولاً از طریق FastCGI با PHP-FPM ارتباط برقرار می‌کند.

پیکربندی باید طوری باشد که فقط فایل‌های PHP مجاز و موجود به PHP-FPM ارسال شوند.

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

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

try_files $uri =404;

اما این دستور باید در کنار سایر تنظیمات واقعی FastCGI بررسی شود.

اگر چندین قانون location با هم تداخل داشته باشند، امکان دارد نتیجه متفاوت از انتظار باشد.

امنیت فایل‌های آپلودی در ووکامرس

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

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

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

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

نقش WAF در افزایش امنیت Nginx

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

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

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

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

در مقابل، WAF محتوای درخواست‌های HTTP و بعضی ویژگی‌های مرتبط با اپلیکیشن را بررسی می‌کند.

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

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

استفاده از ModSecurity و قواعد امنیتی

ModSecurity یکی از فناوری‌های شناخته‌شده WAF است که در بعضی معماری‌های مبتنی بر Nginx از طریق اتصال‌دهنده مناسب استفاده می‌شود.

OWASP Core Rule Set یا CRS نیز مجموعه‌ای از قواعد عمومی برای شناسایی برخی الگوهای حملات وب فراهم می‌کند.

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

False Positive زمانی رخ می‌دهد که یک درخواست سالم به‌اشتباه مخرب تشخیص داده شود.

این مسئله در APIها، فرم‌ها و فروشگاه‌های اینترنتی اهمیت زیادی دارد.

آیا WAF جلوی تمام حملات را می‌گیرد؟

خیر.

WAF می‌تواند بخشی از دفاع چندلایه باشد، اما تضمینی برای جلوگیری از تمام انواع حملات ندارد.

برای مثال، اگر کاربر مجاز بتواند از طریق یک ضعف منطقی به اطلاعات سایر کاربران دسترسی پیدا کند، ممکن است درخواست او از نظر ظاهری کاملاً عادی باشد.

در چنین وضعیتی، اصلاح منطق مجوزدهی اپلیکیشن ضروری است.

امنیت Nginx در برابر حملات DDoS

حملات Distributed Denial of Service یا DDoS با ایجاد ترافیک یا درخواست‌های گسترده تلاش می‌کنند دسترسی کاربران واقعی به سرویس را مختل کنند.

Nginx ابزارهایی مانند Rate Limiting و Connection Limiting برای کنترل بخشی از این فشار دارد.

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

تفاوت حملات لایه شبکه و لایه HTTP

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

در چنین شرایطی، Nginx به‌تنهایی قادر به جلوگیری از پر شدن پهنای باند ورودی نیست.

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

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

استفاده از دفاع چندلایه

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

• استفاده از CDN یا سرویس مقابله با DDoS در لایه بالادستی
• جلوگیری از دسترسی غیرمجاز مستقیم به Origin
• اعمال Rate Limiting متناسب با رفتار کاربران
• استفاده از کش برای منابع عمومی و قابل کش
• پایش ظرفیت پردازشی، حافظه و اتصالات
• تعریف برنامه واکنش به رخداد و ارتباط با ارائه‌دهنده زیرساخت

نکته مهم این است که هیچ محدودیت ثابتی برای تمام سایت‌ها و تمام انواع حمله مناسب نیست.

ثبت لاگ و مانیتورینگ امنیتی Nginx

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

Access Log اطلاعات مرتبط با درخواست‌ها را ثبت می‌کند و Error Log برای بررسی خطاها و وضعیت‌های غیرعادی کاربرد دارد.

بررسی Access Log

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

/var/log/nginx/access.log

اطلاعات متداول شامل آدرس IP، زمان درخواست، مسیر درخواست‌شده و کد وضعیت HTTP است.

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

بررسی Error Log

فایل خطا معمولاً در مسیری مشابه زیر قرار دارد:

/var/log/nginx/error.log

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

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

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

جلوگیری از ثبت اطلاعات حساس

ثبت لاگ نباید باعث افشای اطلاعات محرمانه شود.

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

بنابراین فرمت لاگ باید با دقت طراحی شود.

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

چه شاخص‌هایی باید مانیتور شوند؟

افزایش ناگهانی کدهای 401، 403، 404، 429 و 5xx می‌تواند نیازمند بررسی باشد.

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

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

امنیت کش، کوکی‌ها و داده‌های حساس در Nginx

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

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

تفاوت محتوای عمومی و خصوصی

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

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

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

تنظیم Cache-Control

هدر Cache-Control برای مشخص کردن سیاست ذخیره‌سازی پاسخ استفاده می‌شود.

برای بعضی پاسخ‌های حساس، سیاستی مانند زیر ممکن است مناسب باشد:

add_header Cache-Control "no-store" always;

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

همچنین ممکن است اپلیکیشن یا CDN سیاست‌های کش جداگانه‌ای داشته باشند.

محافظت از کوکی‌ها

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

ویژگی Secure باعث می‌شود مرورگر کوکی را فقط در ارتباطات امن ارسال کند.

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

ویژگی SameSite نیز می‌تواند در کاهش برخی خطرات ارسال کوکی در درخواست‌های میان‌سایتی مؤثر باشد.

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

نقش امنیت سیستم‌عامل و شبکه در Hardening وب‌سرور

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

محدودسازی پورت‌های باز

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

برای نمونه، پورت‌های 80 و 443 ممکن است برای ارائه وب موردنیاز باشند.

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

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

محافظت از SSH

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

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

جداسازی سرویس‌ها

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

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

امنیت Nginx در Docker و Kubernetes

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

استفاده از Imageهای معتبر، محدود کردن قابلیت‌های لینوکس، جلوگیری از دسترسی غیرضروری به فایل‌سیستم میزبان و مدیریت امن Secretها اهمیت دارد.

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

نمونه پیکربندی Hardening وب‌سرور Nginx

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

این مثال برای یک معماری ساده با Backend داخلی در نظر گرفته شده است و نباید بدون تطبیق با سرور واقعی مستقیماً جایگزین فایل پیکربندی موجود شود.

http {
    server_tokens off;

    client_max_body_size 20m;
    client_header_timeout 15s;
    client_body_timeout 15s;
    keepalive_timeout 30s;
    send_timeout 30s;

    limit_req_zone $binary_remote_addr
        zone=perip:10m rate=10r/s;

    limit_conn_zone $binary_remote_addr
        zone=peripconn:10m;

    limit_req_status 429;

    server {
        listen 80;
        server_name example.com;

        return 301 https://example.com$request_uri;
    }

    server {
        listen 443 ssl;
        server_name example.com;

        ssl_certificate
            /etc/ssl/example/fullchain.pem;

        ssl_certificate_key
            /etc/ssl/example/privkey.pem;

        ssl_protocols TLSv1.2 TLSv1.3;

        add_header X-Content-Type-Options
            "nosniff" always;

        add_header X-Frame-Options
            "SAMEORIGIN" always;

        add_header Referrer-Policy
            "strict-origin-when-cross-origin" always;

        add_header Strict-Transport-Security
            "max-age=31536000" always;

        location ~ /\.(?!well-known(?:/|$)) {
            deny all;
        }

        location ~* \.(?:bak|old|sql|log)$ {
            deny all;
        }

        location / {
            limit_req zone=perip burst=30 nodelay;
            limit_conn peripconn 20;

            proxy_pass http://127.0.0.1:8080;

            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For
                $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto
                $scheme;
        }
    }
}

نکات مهم درباره نمونه تنظیمات

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

بنابراین نباید یک بلوک http جدید را داخل بلوک موجود قرار داد.

همچنین مسیر گواهی، نام دامنه و آدرس Backend باید با مقادیر واقعی جایگزین شوند.

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

در این نمونه، سیاست HSTS با مقدار یک‌ساله نمایش داده شده است؛ این مقدار فقط پس از بررسی کامل HTTPS و زیردامنه‌های مرتبط باید استفاده شود.

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

اگر سایت از PHP-FPM، وردپرس، WebSocket یا مسیرهای متفاوت Proxy استفاده می‌کند، پیکربندی کامل آن با این مثال تفاوت خواهد داشت.

روش بررسی امنیت Nginx پس از اعمال تغییرات

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

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

بررسی صحت Syntax

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

sudo nginx -t

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

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

sudo systemctl reload nginx

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

بااین‌حال، موفق بودن بررسی Syntax تضمین نمی‌کند که تمام رفتارهای امنیتی و عملکردی صحیح هستند.

بررسی هدرهای HTTP

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

curl -I https://example.com

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

بررسی فقط صفحه اصلی کافی نیست.

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

بررسی پشتیبانی TLS

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

نمونه دستور:

openssl s_client -connect example.com:443 -servername example.com

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

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

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

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

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

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

بررسی عملکرد سایت

پس از اعمال Hardening باید بخش‌های اصلی سایت آزمایش شوند:

ورود و خروج کاربران، بارگذاری فایل، ارسال فرم، API، دریافت فایل و عملیات مدیریتی.

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

اگر قانون امنیتی باعث اختلال در عملکرد سالم سایت شود، باید علت آن شناسایی و تنظیم اصلاح شود.

مهم‌ترین تنظیمات امنیت Nginx از نظر اولویت

همه اقدامات امنیتی تأثیر یکسانی ندارند.

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

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

برای نمونه، در یک API عمومی پرترافیک، Rate Limiting و مدیریت دسترسی Backend ممکن است از بعضی تنظیمات مربوط به نمایش مرورگر اهمیت عملی بیشتری داشته باشند.

اشتباهات رایج در تأمین امنیت Nginx

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

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

تصور اینکه HTTPS تمام مشکلات امنیتی را حل می‌کند

HTTPS داده‌های در حال انتقال را محافظت می‌کند، اما لزوماً مانع سوءاستفاده از منطق برنامه، دسترسی غیرمجاز یا آسیب‌پذیری‌های Backend نمی‌شود.

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

استفاده از تنظیمات آماده بدون شناخت معماری

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

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

اعتماد کردن به هدرهای IP نامعتبر

پیکربندی نادرست Real IP می‌تواند باعث ثبت IP اشتباه و بی‌اثر شدن کنترل‌های مبتنی بر آدرس شود.

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

اعمال محدودیت بیش‌ازحد درخواست

Rate Limiting تهاجمی می‌تواند درخواست‌های سالم را رد کند.

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

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

بستن تمام متدهای HTTP، محدودسازی شدید آپلود یا اجرای CSP بسیار سخت‌گیرانه ممکن است عملکرد ضروری سایت را مختل کند.

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

تکیه کامل بر WAF

WAF می‌تواند کمک‌کننده باشد، اما آسیب‌پذیری کد یا منطق دسترسی را به‌صورت قطعی برطرف نمی‌کند.

اصلاح ریشه‌ای ضعف امنیتی همچنان ضروری است.

فراموش کردن ارث‌بری تنظیمات

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

وجود یک قانون در سطح بالاتر همیشه به معنای اجرای موردانتظار آن در تمام مسیرها نیست.

ذخیره فایل‌های پشتیبان در مسیر عمومی

نگهداری نسخه‌های پشتیبان در Document Root یکی از تصمیمات پرخطر است.

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

اعمال تغییرات بدون آزمایش و برنامه بازگشت

حتی یک تغییر کوچک ممکن است باعث اختلال در سرویس شود.

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

چک‌لیست امنیت Nginx برای مدیران سرور

برای ارزیابی دوره‌ای وب‌سرور، موارد زیر باید بررسی شوند:

وضعیت نرم‌افزار و سیستم‌عامل

• نسخه Nginx و بسته‌های وابسته از نظر وصله‌های امنیتی بررسی شده باشد.
• ماژول‌های غیرضروری شناسایی و درباره استفاده از آن‌ها تصمیم‌گیری شده باشد.
• پردازش‌های Worker با سطح دسترسی محدود اجرا شوند.
• مجوز فایل‌های تنظیمات و کلیدهای خصوصی مناسب باشند.
• سرویس‌های غیرضروری روی اینترنت منتشر نشده باشند.

امنیت ارتباطات

• گواهی TLS معتبر و دارای زنجیره صحیح باشد.
• نسخه‌های قدیمی پروتکل‌های رمزنگاری غیرفعال باشند.
• درخواست‌های HTTP به HTTPS منتقل شوند.
• HSTS پس از بررسی سازگاری فعال شده باشد.
• ارتباطات حساس میان Proxy و Backend محافظت شوند.

کنترل درخواست و دسترسی

• فایل‌های حساس در مسیر عمومی قابل دانلود نباشند.
• Directory Listing ناخواسته فعال نباشد.
• بخش‌های مدیریتی با کنترل دسترسی مناسب محافظت شوند.
• Rate Limiting بر اساس رفتار واقعی کاربران تنظیم شده باشد.
• آدرس IP واقعی کاربران پشت CDN به شکل قابل اعتماد تشخیص داده شود.
• مسیرهای آپلود امکان اجرای ناخواسته کد را فراهم نکنند.

مانیتورینگ و عملیات

• Access Log و Error Log متناسب با نیاز امنیتی فعال باشند.
• لاگ‌ها از نظر اطلاعات محرمانه بررسی شوند.
• هشدارهای عملیاتی و امنیتی تعریف شده باشند.
• نسخه پشتیبان معتبر از پیکربندی وجود داشته باشد.
• تغییرات ابتدا آزمایش شوند و امکان بازگشت فراهم باشد.
• تنظیمات پس از هر تغییر مهم در زیرساخت دوباره ارزیابی شوند.

سؤالات متداول درباره امنیت Nginx

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

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

بهترین تنظیمات Hardening برای Nginx چیست؟

به‌روزرسانی منظم، استفاده از HTTPS و TLS مناسب، محافظت از فایل‌های حساس، کنترل دسترسی، تنظیم Security Headers، محدودسازی درخواست‌ها و پایش لاگ‌ها از اقدامات اصلی هستند. انتخاب مقدار دقیق هر تنظیم باید بر اساس معماری و ترافیک سایت انجام شود.

آیا server_tokens off جلوی هک Nginx را می‌گیرد؟

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

آیا فعال کردن WAF برای Nginx ضروری است؟

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

چگونه از حملات Brute Force در Nginx جلوگیری کنیم؟

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

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

Nginx می‌تواند بخشی از فشار درخواست‌های HTTP را مدیریت یا محدود کند، اما برای حملات حجیم شبکه‌ای معمولاً به زیرساخت مقابله با DDoS در لایه بالادستی نیاز است.

تفاوت Rate Limiting و Connection Limiting چیست؟

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

آیا HSTS برای همه سایت‌ها مناسب است؟

HSTS برای سایت‌هایی که به‌طور کامل از HTTPS استفاده می‌کنند مفید است. بااین‌حال، قبل از فعال‌سازی مدت‌زمان طولانی، includeSubDomains یا Preload باید سازگاری تمام سرویس‌های مرتبط بررسی شود.

چگونه امنیت Nginx در وردپرس را افزایش دهیم؟

علاوه بر تنظیمات عمومی وب‌سرور، باید از فایل wp-config.php محافظت کرد، اجرای ناخواسته PHP در مسیر آپلود را محدود کرد، تنظیمات PHP-FPM را بررسی کرد و وردپرس، افزونه‌ها و قالب‌ها را به‌روز نگه داشت.

آیا Nginx از Apache امن‌تر است؟

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

چگونه متوجه شویم Nginx به‌درستی Hardening شده است؟

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

آیا استفاده از CDN باعث می‌شود نیازی به Hardening Nginx نباشد؟

خیر. CDN می‌تواند بخشی از ترافیک و تهدیدات را مدیریت کند، اما سرور اصلی همچنان باید ایمن باشد. کنترل دسترسی Origin، تشخیص صحیح IP و محافظت از سرویس‌های داخلی اهمیت خود را حفظ می‌کنند.

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

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

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

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

پس از آن، می‌توان با استفاده از Security Headers، Rate Limiting، Connection Limiting، WAF و مانیتورینگ امنیتی، سطح محافظت را افزایش داد.

در سایت‌های وردپرسی و فروشگاه‌های ووکامرس، هماهنگی تنظیمات Nginx با PHP-FPM، مسیرهای آپلود، APIها و فرایندهای پرداخت اهمیت ویژه‌ای دارد.

همچنین باید به خاطر داشت که حتی یک پیکربندی فنی صحیح نیز ممکن است با تغییر معماری یا اضافه شدن سرویس جدید نیازمند بازبینی باشد.

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

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