در این مقاله قصد داریم توضیح دهیم که چگونه از وب سرور Nginx در مقابل حملات DDoS محافظت کنیم. اگر مطلب قبلی ما را در مورد “نحوه (آموزش) محافظت از وب سرور nginx بوسیله fail2ban” را خوانده باشید، اشاره کردیم که می‌توانید با استفاده از fail2ban حتی مقابل حملات دیداس را هم بگیرید. در این مطلب خیلی وارد جزئیات نمی‌شویم و فرض می‌کنیم که شما تا حدی با تنظیمات nginx و fail2ban آشنا شدید.
همانطور‌که می‌دانید fail2ban اسکریپتهای مختلف و پیچیده‌ای را در خودش دارد که به‌وسیله‌ی آنها می‌تواند log ها را بررسی کند و بر اساس تنظیماتی که به آن داده شده، در خصوص اتفاقات مختلف، یک سری محدودیت برقرار کند.
این محدودیت‌ها در واقع می‌تواند در بسیاری از مواقع به نفع سرویس‌های ما، و‌‌ب‌سایت ما، وب سرور ما و منابع ما باشند. در مجموع می‌توان گفت این یک راهکار رایگان برای داشتن یک امنیت خوب است.
اگر تمایل دارید در مورد حملات DDoS اطلاعات کسب کنید، می‌توانید گشتی در صفحات مختلف وب بزنید و ببینید که این حملات چه ضررهایی برای شرکت‌ها دارند که البته همچنان هم ادامه دارند.
شاید شما هم به‌دنبال یه راهکار رایگان باشید و تمایلی برای هزینه کردن برای سرویسی مانند وردپرس که خودتان راه‌اندازی کردیده اید، نداشته باشید. از طرفی هم تمایلی ندارید که امنیت آن به خطر بیفتد و به خاطر رقبایی که هزینه می‌کنند تا شما را زیر بار حملات دیداس قراردهند، ضربه بخورید.
خلاصه به هر دلیلی همیشه امنیت سرور و وب سرور را در اولویت قرار دهید و بیشترین زمان را هم به آن اختصاص دهید؛ چرا که این روش بقای کار و درآمد و زحمات شما را بیمه خواهد کرد.
حتماً قبل از اینکه شروع کنیم مقاله‌ی نصب و راه‌اندازی fail2ban به همراه nginx را بخوانید؛ چون بر مبنای این مقاله کارمان را ادامه خواهیم داد.
بهتر است یک سرور اوبونتو یا debian با یک کاربری که دسترسی sudo دارد، برای ادامه آماده کنید.
قبل از اینکه برویم به سراغ fail2ban به همراه nginx، به شما توصیه می‌کنیم به این بخش توجه کنید.
قصد داریم اینجا چند راهکار مختلف برای شما توضیح دهیم که مربوط به مباحث امنیت وب سرور شما می‌شود. ما باید تلاش کنیم حملات DDoS راخیلی سریع متوقف کنیم و سرور خودمان را از زیر بار حملات نجات دهیم.
اساتید امنیت راه‌های مختلفی را برای اینکار ارائه کرده‌اند. اما واقعیت این است که وقتی حملات DDoS اتفاق بیفتد، همین پیشگیری‌های عاقلانه می‌تواند شما را نجات بدهد؛ چرا که وقتی حجم عظیمی از درخواست‌ها به سمت سرور شما روانه شوند، سرور شما باید به نحوی پاسخ دهد و هر پاسخ یعنی استفاده از منابع و اگر منابع شما اجازه‌ی کنترل کردن این درخواست‌ها را به شما ندهند، با یک Crash خطرناک روبرو می‌شوید و به‌ناچار سرویس شما سقوط می‌کند.
همیشه پیشگیرانه عمل کنید تا سیل دیداس شما را با خودش نبرد. پس اول بهتراست برویم سراغ چند راهکار که از وب سرور شما در حالت کلی محافظت می‌کند. به چند نمونه از این راهکارها در اینجا اشاره می‌کنیم:
یکی از ساده‌ترین راه‌ها برای محافظت از سرور و وب سرور (مثلا Nginx)، این است که از فایروال‌های نرم‌افزاری استفاده کنید. مانند CSF، UFW ،APF یا iptables وغیره. مثلاً اگر بخواهید از سرور nginx با iptables محافظت کنید، می‌توانید از چنین تنظیماتی برای محدود کردن Connection ها روی پورت ۸۰ استفاده کنید (nginx به صورت پیش‌فرض به درخواست‌های پورت ۸۰ گوش می‌دهد):
sudo iptables -A INPUT -p tcp –syn –dport 80 -m connlimit –connlimit-above 20 -j REJECT –reject-with tcp-reset
اکنون با اضافه کردن این تنظیمات به iptables اگر تعداد connection ها از سمت یک IP بیشتر از ۲۰ لینک در ثانیه شود، ارتباطات اضافی از سمت آن IP بلافاصله قطع خواهند شد.
مشابه همین کار را اکثر شرکت‌های میزبانی وب با استفاده از CSF به‌عنوان فایروال روی cPanel انجام می‌دهند. برای مثال با تغییر پارامترهایی مانند CT_LIMIT, CT_BLOCK_TIME, CT_INTERVAL وغیره برای محدود کردن تعداد Connection ها با سرور، می‌توانیم امنیت بیشتری برقرار کنیم.
در یک حالت مشابه مثلاً همین سرور Ubuntu یک فایروال پیش‌فرض به نام UFW یا Uncomplicated FireWall دارد. قانون کلی که برای این فایروال تنظیم شده، این است که از ورود تمامی درخواست‌ها به سمت سرور جلوگیری کند و اجازه‌ی خروج تمامی درخواست‌ها به بیرون را بدهد. اکنون یک کاربر می‌تواند پورت خاص و ارتباط خاص (IP) را خودش با دانش قبلی فعال کند. این قانون در این فایروال باعث امنیت بیشتر شده و سرور در حالت کلی در معرض خطر قرار نمی‌گیرد.
استفاده کردن از سرویس‌ها و پلتفرم‌های Third Party می‌تواند در امنیت سرور و وب سرور شما تاثیر بگذارد. به‌عنوان مثال CloudFlare یکی از محبوب‌ترین و قدرتمندترین پلتفرم هاست که خیلی‌ها ازآن استفاده می‌کنند. اما گزینه‌های متفاوتی برای شما وجود دارد که بسته به نیاز می‌توانید از آن استفاده کنید.
اگر قصد دارید که همیشه یک سرویس مطمئن را داشته باشید و با گروهی کار کنید که توانایی بالایی داشته باشند که بتوانند حملات DDoS را دفع کنند و همچنین کمبود منابع نداشته باشند، باید انتخاب مناسبی داشته باشید. فناوران شبکه سینداد این پتانسیل را دارد که چنین VPS هایی را به شما ارائه دهد. به منظور تهیه سرویس سرور مجازی از سینداد می‌توانید بر روی یکی از لینک‌های زیر کلیک کنید:
اگر قصد دارید دیتاسنتر یا server farm خودتان را داشته و پیاده سازی کنید، بهتراست حتماً از سخت‌افزارهای کنترل و بررسی ترافیک شبکه استفاده کنید. درست است که نرم‌افزارهای زیادی برای این کار طراحی شده‌اند، اما سخت‌افزارهای مخصوص این کار سریع‌تر و قدرتمندتر به این حملات جواب می‌دهند.
اگر روزی مانند گوگل آنقدر بزرگ و قدرتمند شدید، دیگر لازم نیست نگران این حملات باشید؛ چون بعید است کسی این قابلیت را داشته باشد که به شما حمله کند، یا اصلاً بخواهید چنین هزینه‌هایی را داشته باشید. حمله به شرکت‌های بزرگ با منابع بالا و پهنای باند بالا مثل مشت زدن به دیوار آهن یا پرواز به سمت سیاه چاله است !!!
شما می‌توانید با تغییر دادن پارامترهای مختلفی که در nginx وجود دارد، مانع از حملات دیداس شوید، یا حداقل در مقابل آنها مقاوم‌تر شوید. ما تعدادی از آنها را در اینجا به‌عنوان مثال آورده‌ایم:
Worker Process Nginx:
یکی از کارهایی که برای پیشگیری از حملات و نابود شدن وب سرور می‌توان انجام داد. تغییر تعداد worker process ها و تغییر تعداد worker connectionها در فایل تنظیمات nginx یعنی فایل etc/nginx/nginx.conf/ خواهد بود. به‌عنوان مثال می‌توان ارزش و اولویت پروسه‌های worker process و connection processهای nginx را به صورت تدریجی تغییر داد تا بتوانند در زمان بحران جوابگوی درخواست‌های سرازیر شده به سمت سرور باشند. به‌عنوان مثال برای تغییر تعداد Connection ها در فایل etc/nginx/nginx.conf/ این خط‌ها را اضافه می‌کنیم:
etc/nginx/nginx.conf/
events {
worker_connections 50000;
}
با اضافه کردن این خط داخل تنظیمات nginx در واقع به هر کدام از worker process ها اجازه می‌دهید که تا ۵۰۰۰۰ کانکشن را رسیدگی کنند و جواب بدهند. بسیار مهم است که قبل از این کار حتماً منابع سرور را بررسی کنید تا سرورتان نابود نشود؛ چون یک همچین تغییراتی بدون بررسی منابع (resources) می‌تواند کاملاً سرور را نابود کند.
علاوه بر این ما می‌توانیم محدودیت تعداد فایل‌های باز سیستم را تغییر بدهیم. اگر در فایل etc/sysctl.conf/ (در اوبونتو) عبارت fs.file-max = 50000 را اضافه کنیم، می‌توانیم در واقع تعداد connection هایی که از این فایل‌ها استفاده می‌کنند را هم تعریف کنیم. همچنین می‌توان این محدودیت یا افزایش‌ها را برای کاربران مشخص هم تعریف کرد. به‌عنوان مثال برای worker process سرویس Nginx می‌توانیم با تغییر دادن فایل etc/security/limits.conf/ محدودیت‌هایی را قائل شویم.
محدود کردن میزان درخواست‌ها (request rate limiting) یکی از بهترین روش‌ها برای مقابله با حملات DDoS به حساب می‌آید.
با این کار شما می‌توانید میزان درخواست‌ها از سمت یک آی پی مشخص را در یک بازه زمانی مشخص تعریف و محدود کنید و اگر یک IP بخواهد از این محدودیت تجاوز کند،nginx به آن درخواست جواب نمی‌دهد.
به عنوان مثال با تغییر دادن پارامتر limit_req_zone در فایل تنظیمات nginx می‌توانیم روی درخواست‌ها یک میزان مشخص قرار دهیم.
مثلاً به این دستور نگاهی بندازید :
etc/nginx/nginx.conf/
limit_req_zone $binary_remote_addr zone=one:10m rate=30r/m;
این دستور بخشی از حافظه را با نام one به خودش اختصاص می‌دهد که درون آن می‌تواند ۱۶۰,۰۰۰ هزار آی پی منحصربه‌فرد را در مدت ۱۰ دقیقه ذخیره کند (یعنی ۱۶,۰۰۰ هزار آی پی در هر دقیقه) ، و rate=30r/m یعنی اینکه در هر دقیقه فقط ۳۰ درخواست رسیدگی می‌شود (یعنی از هر ۲ ثانیه یک درخواست). همینطور در کنار این تنظیمات با اضافه‌کردن دستور limit_req داخل تنظیمات virtual host مد‌نظر روی یک location یا فایل‌های root مربوطه، می‌توانید این تغییرات را عملی کنید.
یک روش دیگر محدود کردن تعداد connection ها از سمت یک آی‌پی آدرس است که می‌تواند در مقابل حملات DDoS از شما محافظت کند. با تعیین کردن limit_conn_zone و اضافه کردن دستور limit_conn در فایل‌های تنظیمات nginx می‌توانید این کار را انجام دهید. به مثال زیر توجه فرمایید:
etc/nginx/nginx.conf/
limit_conn_zone $binary_remote_addr zone=one:20m;
دقت کنید که اولی را داخل فایل etc/nginx.conf/ اضافه میکنید و بعدی را داخل فایل تنظیمات virtual host مورد نظرتان:
etc/nginx/sites-available/virtualhost.conf/
server {
location /admin/ {
limit_conn addr 20;
}}
ارتباط‌های ضعیف و با سرعت پایین (slow connections) به سرور، علاوه بر اینکه یکی از لینک‌های ارتباطی را برای مدت طولانی اشغال می‌کنند، این ارتباط‌ها را همچنان برقرار و زنده نگه می‌دارند. همین سبب می‌شود سرور نتواند connection های جدیدی را قبول کند.
با اضافه کردن دستورات زیر می‌توانیم مانع از این ارتباط‌های ضعیف شویم. تنظیمات زیر را به فایل virtual host خودتان اضافه کنید و می‌توانید مقادیرش را هم تغییر دهید:
etc/nginx/sites-available/virtualhost.conf/
server {
client_body_timeout 10s;
client_header_timeout 10s;
}
در اینجا اگر رسیدن هر کدام از بخش‌های body یا header درخواست‌های کاربران بیشتر از ۱۰ ثانیه طول بکشد، nginx منتظر نخواهد ماند و آن ارتباط را قطع خواهد کرد.
اندازه بزرگ buffer ها یا درخواست‌های http می‌تواند کار حمله‌کنندگان را برای ddos راحت‌تر کند. برای همین بهتر است مقادیر buffer و http را داخل فایل virtual host مشخص و محدود کنید:
etc/nginx/sites-available/virtualhost.conf/
client_body_buffer_size 200K;
client_header_buffer_size 2k;
client_max_body_size 200k;
large_client_header_buffers 3 1k;
دوستان اگر شما هم از nginx به‌عنوان load balancer استفاده میکنید، به شما توصیه می‌کنیم پارامترهای تنظیمات nginx را به نحوی تغییر دهید که تعداد connection هایی که توسط سرورهای backend درحال رسیدگی هستند، مشخص باشد.
به مثال زیر توجه فرمایید:
etc/nginx/sites-available/virtualhost.conf/
upstream domain {
server 192.125.168.2:80 max_conns=100;
server 192.125.168.3:80 max_conns=100;
queue 20 timeout=10s;
}
منظور از این دستورات چیست؟ دستور max_conns مشخص می‌کند که سرور nginx باید چند تا Connection برای یک سرور باز کند.
Queue یعنی در زمانی‌که ظرفیت connection ها به سمت سرور‌ها پر شده باشند، چند تا درخواست می‌توانند وارد صف شوند؟
در نهایت دستور timeout هم مشخص می‌کند که اگر کسی در صف قرار داشته باشد و ارتباطش قطع شود یا سرعتش به حدی پایین باشد که قطع شده به حساب بیاید، سرور تا چه مدت آن را داخل صف نگه می‌دارد و صبر می‌کند.
علاوه بر تمام این مطالبی که گفتیم، شما می‌توانید nginx را تنظیم کنید تا connection ها را بر اساس URL درخواست‌دهنده User-Agent ، Referer ، Request Header و غیره بلاک کند.
امیدواریم تا اینجا متوجه کلیت قضیه شده باشید. اکنون سراغ fail2ban که به‌عنوان یک ابزار جانبی در امنیت سرور شما فوق‌العاده تاثیرگذار است، می‌رویم.
می‌رویم به‌سراغ fail2ban و نحوه کارکردن آن در‌کنار nginx و مقابله‌ی این دو با حملات DDoS .
ما در مقاله آموزشی چگونه از وب سرور Nginxبا استفاده از Fail2ban محافظت کنیم؟ به اندازه کافی در مورد نحوه‌ی عملکرد و تغییراتی که داخل فایل‌ها می‌دهیم و اینکه به چه صورت کار می‌کنند، صحبت کردیم.
اینجا فقط می‌خواهیم تغییراتی را که در تنظیمات nginx و fail2ban اضافه می‌کنیم را برای شما مطرح کنیم. فقط قبل از آن یک سری توضیحات در مورد خود nginx دادیم که در صورت تمایل بتوانید از گزینه‌های مختلف استفاده کنید.
فرض می‌کنیم شما با استفاده از مطالب قبلی پیش می‌روید. البته اگر هم آن مطلب را نخوانده باشید و فقط اطلاعات کافی از تنظیمات nginx و fail2ban داشته باشید، به‌راحتی می‌توانید با همین بخش جلو بروید.
اگر چند پاراگراف بالاتر را مجدداً نگاهی بیندازید، در مرحله دوم- بخش دوم “محدود کردن میزان درخواست ها” ، در خصوص اعمال محدودیت‌ها در nginx توضیحاتی دادیم. طبیعی است که با این تنظیمات، خود nginx می‌تواند ارتباط را با IP مشخصی که سعی دارد از این محدودیت عبور کند، قطع کند. اما اگر آن آی‌پی و هزاران آی‌پی دیگر با قدرت بیشتر حمله کنند چه اتفاقی می‌افتد؟ آیا درخواست‌های ارسالی منجر به استفادهی بیشتر از منابع شما نمی‌شوند؟
اینجاست که fail2ban با قدرت وارد می‌شود. هر کسی که بخواهد از این محدودیت‌ها عبور کند، یک گزارش در log ها برایش وجود خواهد داشت.fail2ban با داشتن این لاگ فایل‌ها می‌تواند دسترسی مجدد این آی پی‌ها را کاملا محدود کند و حتی قبل از اینکه به سرور ارسال شوند، از طریق iptables، آنها را ban کند.
اکنون در مورد تغییرات آن توضیح می‌دهیم. اگر طبق مقاله‌ی قبلی عمل کرده باشید، اول بهتر است برویم سراغ فایل etc/fail2ban/jail.local/:
sudo vi /etc/fail2ban/jail.local
و این تنظیمات را به ادامه‌ی زندان‌هایی که برای nginx ساختیم، اضافه کنید:
etc/fail2ban/jail.local/
…….
[nginx-req-limit]
enabled = true
filter = nginx-req-limit
action = iptables-multiport[name=ReqLimit, port=”http,https”, protocol=tcp]
logpath = /var/log/nginx/*error.log
findtime = 300
bantime = 3600
maxretry = 3
سپس فایل را ذخیره کرده و خارج شوید. با دو نقطه x (یا x: یا wq:).
اکنون باید برای این زندان (jail) ساخته شده یک فایل فیلترینگ بسازیم تا ip های خاطی را ban کنیم:
cd /etc/fail2ban/filter.d
sudo vi nginx-req-limit.conf
و خطوط زیر را به این فایل اضافه کنید:
etc/fail2ban/filter.d/nginx-req-limit.conf/
[Definition]
failregex = limiting requests, excess:.* by zone.*client: <HOST>
ignoreregex =
فایل را ذخیره کنید و خارج شوید.
اکنون باید فایل Virtual host مد نظرتان را تغییر بدهید و محدودیت را مثلاً برای یک location فعال کنید؛ اگر فرض بگیریم که فایل تنظیمات هاست مجازی شما همان فایل default باشد:
sudo vi /etc/nginx/sites-enabled/default
این تغییرات را در قسمت location وارد می‌کنیم:
etc/nginx/sites-enabled/default/
….
location / {
try_files $uri $uri/ =404;
limit_req zone=one burst=10;
try_files $uri $uri/ /index.php;
}
….
پس از ذخیره و خروج از این فایل باید به سراغ فایل تنظیمات اصلی nginx یعنی etc/nginx/nginx.conf/ برویم:
sudo vi /etc/nginx/nginx.conf
اکنون باید محدودیت موردنظرتان را برای nginx در تنظیمات اصلی آن تعریف کنیم. خط قرمز رنگ را در هر جایی از بخش {}http که تعریف شده، می‌توانید وارد کنید. به طور مثال ما آن را به این شکل به فایل اضافه کردیم:
etc/nginx/nginx.conf/
……
include /etc/nginx/mime.types;
default_type application/octet-stream;
limit_req_zone $binary_remote_addr zone=one:1m rate=1r/m;
……
با ذخیره و خروج از این فایل، باید هر دو سرویس nginx و fail2ban را restart کنید:
sudo service nginx restart
sudo service fail2ban restart
تغییرات اعمال شده از هم‌اکنون در حال اجراست. اکنون شما می‌توانید در خصوص امنیت سرور nginx به مقدار زیادی راضی باشید. با اینکار نه تنها شما می‌توانید فشار را از روی سرور بردارید، بلکه حتی اگر کسی بخواهد تلاش کند تا به سرور شما حمله کند، متوجه خواهد شد که شما آنقدرها هم هدف راحتی نیستید.
در مورد مفهوم خطوط اضافه شده در تنظیمات، هم در مطلب قبلی و هم اینجا توضیحات کافی را دادیم.
اگر جایی احساس کردید که به کمک نیاز دارید یا کسی نسبت به کسب‌وکار اینترنتی شما سوء نیت دارد و نیاز به مشاوره داشتید، با کارشناسان فنی سینداد تماس بگیرید.
جمع‌آوری شده توسط: حمید نبی زاده
سینداد یعنی هدیه‌ی سیمرغ، یا فرزند سیمرغ؛ به عبارتی یعنی خود سیمرغ، با همه ی شگفتی هایش، اما جوانتر و سرزنده تر. و این چیزی است که ما سعی می کنیم در سینداد باشیم. از سال ۱۳۸۵ دانش مان را به صورت خدماتی در حوزه ی هاستینگ، شبکه و تولید نرم افزار در اختیار مشتریان مان قرار داده ایم و به این افتخار می کنیم که تک تک آنها تا به امروز همراه ما مانده اند. باور داریم که سینداد صرفاً یک شرکت نیست، بلکه نوعی باور است به ارائه ی شگفت انگیز از هر چیز.
