آموزش پیکربندی CSF؛ تنظیم csf.conf، پورت‌ها و هشدارهای ایمیلی

CSF را نصب کرده‌اید، فایل csf.conf را باز کرده‌اید و حالا با ده‌ها گزینه روبه‌رو هستید که معلوم نیست کدام‌شان واقعاً مهم است و کدام‌یک اگر اشتباه تنظیم شود شما را پشت در سرور خودتان جا می‌گذارد. این راهنما بخش‌های ابتدایی و پرکاربرد csf.conf را قدم‌به‌قدم باز می‌کند: حالت TESTING، به‌روزرسانی خودکار، انتخاب کارت شبکه، مدیریت پورت‌های TCP و UDP، پروتکل ICMP، روش درست اعمال تغییرات و در پایان فعال‌سازی هشدارهای ایمیلی برای تلاش‌های ناموفق ورود و اسکن پورت.

CSF دقیقاً چه کار می‌کند و کجا نصب می‌شود؟

CSF (مخفف ConfigServer Security & Firewall) خودش یک فایروال مستقل نیست؛ یک لایهٔ مدیریت روی iptables است که به‌جای نوشتن دستی قواعد، به شما اجازه می‌دهد همه‌چیز را در یک فایل متنی تعریف کنید. در کنار آن سرویس دومی به نام lfd (مخفف Login Failure Daemon) اجرا می‌شود که لاگ‌های سرور را می‌خواند، تلاش‌های ناموفق ورود و اسکن پورت را تشخیص می‌دهد، IP مهاجم را بلاک می‌کند و برای شما ایمیل هشدار می‌فرستد. این تقسیم کار را یادتان باشد، چون در ادامه به آن نیاز دارید: CSF قواعد فایروال را می‌سازد، lfd مغز تحلیل‌گر پشت آن است.

پس از نصب، فایل‌های پیکربندی در مسیر /etc/csf و فایل‌های اجرایی و قالب‌ها در /usr/local/csf قرار می‌گیرند. برای شروع وارد شاخهٔ پیکربندی می‌شویم:

cd /etc/csf/
ls

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

• csf.conf — فایل اصلی تنظیمات؛ تقریباً هر چیزی که در این مقاله می‌خوانید اینجاست.
• csf.allow — IPهایی که همیشه از فایروال عبور می‌کنند (قاعدهٔ ACCEPT برایشان ساخته می‌شود).
• csf.deny — IPهای بلاک‌شده؛ هم دستی و هم مواردی که lfd به‌صورت دائم بلاک کرده است.
• csf.ignore — لیست چشم‌پوشی lfd؛ IPهای این فایل هرگز توسط lfd بلاک نمی‌شوند.
• csf.pignore — پروسه‌هایی که سیستم Process Tracking باید نادیده بگیرد.

یک نکتهٔ مهم که خیلی‌ها را گرفتار می‌کند: قرار دادن IP در csf.allow به‌تنهایی جلوی بلاک شدن آن توسط lfd را نمی‌گیرد. اگر می‌خواهید IP ثابت دفتر یا خانه‌تان تحت هیچ شرایطی بلاک نشود، آن را در هر دو فایل csf.allow و csf.ignore بگذارید.

قبل از دست زدن به csf.conf این چهار کار را انجام دهید

اشتباه در این فایل معمولاً یک نتیجه دارد: قطع شدن دسترسی SSH. چند دقیقه وقت گذاشتن برای این مقدمات، جلوی چند ساعت دردسر را می‌گیرد.

۱. از فایل پیکربندی نسخهٔ پشتیبان بگیرید.

cp /etc/csf/csf.conf /etc/csf/csf.conf.bak-$(date +%F)

۲. IP خودتان را همین حالا مجاز کنید تا حتی اگر پورت SSH را اشتباه تنظیم کردید، راه برگشت داشته باشید (به‌جای IP نمونهٔ زیر، IP واقعی خودتان را بگذارید):

csf -a 203.0.113.10 my-office-ip

۳. مطمئن شوید فایروال دیگری در حال اجرا نیست. روی AlmaLinux، Rocky Linux و CentOS 7 به بعد سرویس firewalld و روی Ubuntu و Debian سرویس ufw با CSF بر سر مدیریت iptables تداخل پیدا می‌کنند و نتیجه، قواعدی است که یکی دیگری را خنثی می‌کند:

systemctl disable --now firewalld    # AlmaLinux / Rocky / CentOS
systemctl disable --now ufw          # Ubuntu / Debian

روی اوبونتو و دبیان دستور معادل و رسمی‌تر ufw disable است. این کار را درست پیش از راه‌اندازی CSF انجام دهید، چون در فاصلهٔ بین غیرفعال شدن فایروال قبلی و فعال شدن CSF سرور شما بدون هیچ فیلتری روی اینترنت است.

۴. پورت واقعی SSH خود را پیدا کنید. اگر پورت پیش‌فرض را عوض کرده‌اید و آن را در لیست پورت‌های ورودی نگذارید، در همان لحظهٔ اعمال قواعد از سرور بیرون می‌افتید:

ss -tlnp | grep -i ssh

دستور قدیمی netstat روی توزیع‌های امروزی معمولاً نصب نیست؛ ss جایگزین استاندارد آن است. همچنین اگر nano روی سرور مینیمال شما نصب نبود، یا با vi کار کنید یا آن را نصب کنید:

dnf install -y nano        # AlmaLinux / Rocky
apt install -y nano        # Ubuntu / Debian

حالا فایل تنظیمات را باز کنید:

nano /etc/csf/csf.conf

TESTING؛ مهم‌ترین گزینه‌ای که اکثر سرورها اشتباه تنظیمش می‌کنند

TESTING = "1"

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

• TESTING = "1" یعنی حالت آزمایشی. در این حالت یک Cron ساخته می‌شود که هر چند دقیقه یک‌بار قواعد فایروال را پاک می‌کند. یعنی اگر خودتان را بیرون بیندازید، حداکثر بعد از چند دقیقه دوباره دسترسی پیدا می‌کنید — ولی در همان مدت هم سرور شما عملاً بدون فایروال است.
• TESTING = "0" یعنی فایروال به‌صورت واقعی و دائمی فعال است. این همان چیزی است که در نهایت باید تنظیم کنید.

نکته‌ای که در آموزش‌های قدیمی گفته نمی‌شود: تا وقتی TESTING روی ۱ باشد، سرویس lfd اصلاً اجرا نمی‌شود. یعنی نه بلاک خودکار IP مهاجم کار می‌کند، نه هیچ‌کدام از هشدارهای ایمیلی که در بخش‌های بعدی همین مقاله تنظیم می‌کنیم. تعداد سرورهایی که ماه‌ها با TESTING = "1" رها شده‌اند و صاحب‌شان فکر می‌کند فایروال دارد، کم نیست.

روش درست این است: تا وقتی مشغول تنظیم پورت‌ها هستید TESTING را روی ۱ نگه دارید، بعد از اینکه مطمئن شدید دسترسی SSH برقرار است آن را روی ۰ بگذارید و CSF را ری‌استارت کنید.

TESTING_INTERVAL = "5"

این عدد بر حسب دقیقه است و مشخص می‌کند آن Cron حالت آزمایشی هر چند دقیقه یک‌بار قواعد را پاک کند. برخلاف چیزی که گاهی نوشته می‌شود، این گزینه قواعد را «بررسی» یا CSF را «استارت» نمی‌کند؛ کارش پاک کردن قواعد است. عدد کمتر (مثلاً ۱) یعنی اگر خودتان را قفل کردید سریع‌تر برمی‌گردید. به‌محض اینکه TESTING را صفر کنید، این گزینه دیگر هیچ نقشی ندارد.

AUTO_UPDATES؛ توجه کنید که ۱ یعنی «فعال»

AUTO_UPDATES = "1"

در کل فایل csf.conf قرارداد یکسانی برقرار است: عدد ۱ یعنی فعال و ۰ یعنی غیرفعال. در بعضی آموزش‌های قدیمی این گزینه برعکس توضیح داده شده است؛ درست آن این است که AUTO_UPDATES = "1" یعنی CSF خودش را به‌روز نگه می‌دارد و "0" یعنی به‌روزرسانی خودکار خاموش است.

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

csf -u

انتخاب کارت شبکه: ETH_DEVICE و ETH_DEVICE_SKIP

ETH_DEVICE = ""
ETH_DEVICE_SKIP = ""

به‌صورت پیش‌فرض هر دو خالی هستند و این یعنی CSF قواعد را روی تمام کارت‌های شبکه اعمال می‌کند؛ در بیشتر سرورها دقیقاً همان چیزی است که می‌خواهید. با ETH_DEVICE می‌توانید دامنه را به اینترفیس مشخصی محدود کنید و با ETH_DEVICE_SKIP اینترفیسی را از شمول قواعد خارج کنید. دقت کنید قالب این دو یکی نیست: ETH_DEVICE یک اینترفیس یا یک الگو (مثل eth+) می‌گیرد، در حالی که ETH_DEVICE_SKIP فهرستی از اینترفیس‌ها را می‌پذیرد که با کاما از هم جدا می‌شوند. با این حال پیش از هر تغییری، توضیح بالای همین دو گزینه در فایل csf.conf نسخهٔ خودتان را هم بخوانید.

اینجا یک نکتهٔ مهم دربارهٔ آموزش‌های قدیمی وجود دارد: مقادیری مثل eth0 و eth1 مربوط به دوران قبل از نام‌گذاری پایدار اینترفیس‌ها هستند. روی CentOS 7 به بعد، AlmaLinux، Rocky Linux و Ubuntu 16.04 به بعد، کارت شبکه معمولاً نام‌هایی مثل ens3، enp1s0 یا eno1 دارد. اگر کورکورانه eth0 را از یک آموزش قدیمی کپی کنید، قواعد روی اینترفیسی اعمال می‌شود که اصلاً وجود ندارد و نتیجه‌اش سروری بدون محافظت است. اول نام واقعی را ببینید:

ip -br link

و دربارهٔ ETH_DEVICE_SKIP حواستان باشد: اینترفیسی که در این لیست بگذارید کاملاً بدون فیلتر می‌ماند. این کار فقط برای شبکهٔ داخلی و خصوصی منطقی است، نه برای اینترفیسی که به اینترنت وصل است.

مدیریت پورت‌ها؛ حساس‌ترین بخش پیکربندی

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

TCP_IN — پورت‌های ورودی

TCP_IN = "20,21,22,25,53,80,110,143,443,465,587,993,995"

این‌ها پورت‌هایی هستند که از بیرون اجازهٔ ورود به سرور دارند. پیش از هر چیز یک هشدار جدی: اگر پورت SSH خود را در این لیست نگذارید، به‌محض ری‌استارت CSF دسترسی‌تان قطع می‌شود. در آموزش‌های قدیمی گاهی نمونه‌هایی دیده می‌شود که نه پورت ۲۲ در آن‌ها هست و نه پورت ۴۴۳ — کپی کردن چنین لیستی هم شما را بیرون می‌اندازد و هم سایت HTTPS شما را از دسترس خارج می‌کند.

کاربرد پورت‌های رایج:

• ۲۲ — SSH (یا هر پورت جایگزینی که خودتان تنظیم کرده‌اید)
• ۸۰ و ۴۴۳ — HTTP و HTTPS؛ روی هر وب‌سروری هر دو لازم است
• ۲۰ و ۲۱ — FTP (کانال داده و کانال کنترل)
• ۲۵، ۴۶۵، ۵۸۷ — ارسال ایمیل؛ ۴۶۵ و ۵۸۷ نسخه‌های رمزنگاری‌شده هستند
• ۱۱۰ و ۹۹۵ — POP3 و POP3 روی SSL
• ۱۴۳ و ۹۹۳ — IMAP و IMAP روی SSL
• ۵۳ — DNS؛ فقط اگر سرور شما واقعاً نیم‌سرور است

اگر کنترل‌پنل هاست دارید، پورت‌های آن را هم اضافه کنید: cPanel و WHM پورت‌های 2082,2083,2086,2087,2095,2096 و WebDAV آن 2077,2078 را می‌خواهند، DirectAdmin پورت 2222 و Plesk پورت 8443 را. برای یک وب‌سرور ساده بدون کنترل‌پنل و بدون سرویس ایمیل، لیست زیر کاملاً کافی است:

TCP_IN = "22,80,443"

یک اشتباه پرتکرار را هم اضافه کنم: پورت 3306 (MySQL/MariaDB) را در TCP_IN باز نگذارید مگر اینکه واقعاً به اتصال دیتابیس از بیرون نیاز داشته باشید. اگر نیاز دارید، به‌جای باز کردن آن برای کل اینترنت، در فایل csf.allow فقط برای IP مشخصی بازش کنید. قالب فیلتر پیشرفتهٔ CSF این‌طور است:

tcp|in|d=3306|s=203.0.113.10

TCP_OUT — پورت‌های خروجی

TCP_OUT = "20,21,22,25,53,80,110,113,443,587,993,995"

این لیست مشخص می‌کند سرور شما اجازه دارد به چه پورت‌هایی روی اینترنت وصل شود. سخت‌گیری بیش از حد اینجا معمولاً بی‌سروصدا چیزهایی را خراب می‌کند: بدون ۸۰ و ۴۴۳ مدیر بستهٔ سیستم (dnf/apt)، دریافت گواهی Let’s Encrypt و به‌روزرسانی خود CSF از کار می‌افتد؛ بدون ۵۳ نام‌ها resolve نمی‌شوند؛ بدون ۲۵ و ۵۸۷ ایمیل خروجی ارسال نمی‌شود.

UDP_IN و UDP_OUT

UDP_IN = "53"
UDP_OUT = "20,21,53,113,123,873,6277"

پورت‌های UDP از پورت‌های TCP کاملاً جدا هستند و اشتباه گرفتن این دو باعث می‌شود ساعت‌ها دنبال مشکلی بگردید که وجود ندارد. UDP_IN فقط زمانی به ۵۳ نیاز دارد که سرور شما نیم‌سرور باشد. در سمت خروجی، 53 برای DNS و 123 برای همگام‌سازی ساعت (NTP) عملاً اجباری هستند؛ اگر ۱۲۳ بسته باشد ساعت سرور به‌مرور از واقعیت فاصله می‌گیرد و همین یک مورد می‌تواند اعتبارسنجی گواهی‌های TLS و ورودهای دومرحله‌ای را خراب کند. پورت 873 مربوط به rsync، 113 مربوط به ident و 6277 مربوط به سرویس DCC است که SpamAssassin از آن استفاده می‌کند.

اگر IPv6 روی سرور فعال است

این نکته در آموزش‌های قدیمی‌تر معمولاً غایب است، ولی امروز اهمیت زیادی دارد: بستن یک پورت در TCP_IN هیچ تأثیری روی ترافیک IPv6 ندارد. CSF برای IPv6 مجموعهٔ جداگانه‌ای از گزینه‌ها دارد:

IPV6 = "1"
TCP6_IN = "22,80,443"
TCP6_OUT = "20,21,22,25,53,80,110,113,443,587,993,995"
UDP6_IN = "53"
UDP6_OUT = "20,21,53,113,123,873,6277"

اگر سرور شما آدرس IPv6 دارد و سرویس‌ها روی آن هم Listen می‌کنند، تا وقتی این لیست‌ها را هم تنظیم نکرده‌اید، نیمی از سطح حملهٔ سرورتان بدون فیلتر باقی مانده است. با دستور ip -6 addr ببینید اصلاً آدرس IPv6 فعالی دارید یا نه.

پروتکل ICMP

ICMP_IN = "1"
ICMP_IN_RATE = "1/s"

ICMP_IN تعیین می‌کند از بیرون بتوانند سرور شما را پینگ کنند یا نه؛ ۱ یعنی باز و ۰ یعنی بسته. ICMP_IN_RATE هم سقف نرخ پاسخ‌گویی است و مقدار متداول آن 1/s یعنی یک بسته در ثانیه است. اگر لازم داشتید می‌توانید آن را بالاتر ببرید (مثلاً 2/s)، و مقدار 0 یعنی محدودیت نرخ برداشته شود.

بستن کامل ICMP ورودی یک تصمیم سلیقه‌ای است، اما دو واقعیت را در نظر بگیرید. اول اینکه در برابر یک حملهٔ حجمی واقعی، بستن ICMP در سطح سیستم‌عامل کمکی نمی‌کند؛ ترافیک تا کارت شبکهٔ سرور رسیده و پهنای باند مصرف شده است و مقابله با آن باید یک لایه بالاتر و در سطح شبکه انجام شود. دوم اینکه پینگ ابزار عیب‌یابی و پایش شماست؛ با بستن آن، بسیاری از سرویس‌های مانیتورینگ آپ‌تایم سرور شما را «خاموش» گزارش می‌کنند. راه میانهٔ منطقی، باز گذاشتن ICMP با نرخ محدود است، همان کاری که ICMP_IN_RATE انجام می‌دهد.

ICMP_OUT = "1"
ICMP_OUT_RATE = "0"

ICMP خروجی را باز بگذارید؛ سرویس‌های خود سرور و ابزارهای عیب‌یابی مثل ping و traceroute به آن نیاز دارند. مقدار 0 برای ICMP_OUT_RATE یعنی بدون محدودیت.

اگر IPv6 فعال است، یک هشدار: ICMPv6 برخلاف ICMP نسخهٔ چهار، بخش تفکیک‌ناپذیری از خود پروتکل است و Neighbor Discovery و کشف MTU مسیر بر پایهٔ آن کار می‌کنند. بستن یکپارچهٔ ICMPv6 ارتباط IPv6 سرور را می‌شکند، پس در این بخش تنظیمات پیش‌فرض CSF را بدون دلیل روشن دستکاری نکنید.

هشدار ایمیلی برای ورود ناموفق و اسکن پورت

تا اینجا فایروال ساخته شده، اما فایروالی که وقتی کسی در حال کوبیدن به در است چیزی به شما نمی‌گوید، نیمی از فایدهٔ خودش را از دست داده. این بخش کار lfd است و همان‌طور که بالاتر گفتیم، تا وقتی TESTING = "1" باشد اصلاً اجرا نمی‌شود.

اول مشخص کنید هشدارها به کجا برود. اگر LF_ALERT_TO خالی بماند، ایمیل‌ها به حساب کاربر root روی خود سرور می‌روند که معمولاً هیچ‌کس آن را نمی‌خواند:

LF_ALERT_TO = "you@example.com"
LF_ALERT_FROM = "csf@server.example.com"

حالا هشدار تلاش ناموفق ورود را روشن کنید. این همان موردی است که برای حمله‌های Brute Force روی SSH، FTP، ایمیل و صفحهٔ ورود کنترل‌پنل به کار می‌آید:

LF_EMAIL_ALERT = "1"

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

PS_EMAIL_ALERT = "1"

اینجا یک نکتهٔ حیاتی هست که در بیشتر آموزش‌ها جا می‌افتد: فعال کردن PS_EMAIL_ALERT به‌تنهایی هیچ کاری نمی‌کند. سیستم تشخیص اسکن پورت به‌صورت پیش‌فرض خاموش است و تا وقتی PS_INTERVAL صفر باشد، اصلاً چیزی برای هشدار دادن وجود ندارد. مجموعهٔ درست تنظیمات این‌هاست:

PS_INTERVAL = "300"
PS_LIMIT = "10"
PS_PORTS = "0:65535,ICMP"
PS_PERMANENT = "0"

یعنی: اگر در هر بازهٔ ۳۰۰ ثانیه‌ای بیش از ۱۰ بستهٔ بلاک‌شده از یک IP در لاگ iptables ثبت شود، آن IP به‌عنوان اسکنر شناخته می‌شود. ملاک، تعداد بلاک‌های ثبت‌شده است نه لزوماً تعداد پورت‌های متمایز؛ اگر می‌خواهید حداقل تعداد پورت‌های متفاوت هم شرط باشد، گزینهٔ PS_DIVERSITY دقیقاً برای همین است. چون این سازوکار روی لاگ‌های iptables بنا شده، اگر DROP_LOGGING را خاموش کرده باشید تشخیص اسکن پورت هم از کار می‌افتد.

PS_PERMANENT = "0" یعنی بلاک موقت باشد نه دائم و طول این بلاک موقت را PS_BLOCK_TIME بر حسب ثانیه تعیین می‌کند. برای شروع گزینهٔ امن‌تری است، چون در برابر تنظیم اشتباه، لیست بلاک دائمی شما بی‌رویه بزرگ نمی‌شود.

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

LF_SSH_EMAIL_ALERT = "1"
LF_SU_EMAIL_ALERT = "1"

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

متن این ایمیل‌ها از قالب‌های آماده‌ای خوانده می‌شود که در مسیر زیر قرار دارند و در صورت نیاز می‌توانید ویرایش‌شان کنید:

ls /usr/local/csf/tpl/

و در نهایت یک شرط بدیهی ولی فراموش‌شدنی: این هشدارها از خود سرور ارسال می‌شوند. اگر روی سرور هیچ MTA فعالی نصب نباشد یا ارسال ایمیل خروجی مسدود باشد، همهٔ این تنظیمات درست است ولی هیچ ایمیلی به دست شما نمی‌رسد. بعد از پیکربندی حتماً با یک ورود ناموفق عمدی تست کنید که ایمیل واقعاً می‌رسد.

اعمال تغییرات؛ بدون این مرحله هیچ‌کدام از تنظیمات بالا اجرا نمی‌شود

ذخیره کردن csf.conf به‌تنهایی کافی نیست. برای بارگذاری مجدد قواعد فایروال:

csf -r

اما توجه کنید که تنظیمات مربوط به lfd — یعنی همهٔ گزینه‌های LF_ و PS_ که در بخش قبل تنظیم کردیم — با csf -r اعمال نمی‌شوند و به ری‌استارت خود lfd نیاز دارند. ساده‌ترین راه، دستوری است که هر دو را با هم انجام می‌دهد:

csf -ra

در آموزش‌های قدیمی برای این کار دستورهایی مثل service csf restart یا /etc/init.d/csf restart نوشته شده است. این‌ها مربوط به سیستم init قدیمی هستند و روی CentOS 7 به بعد، AlmaLinux، Rocky Linux، Ubuntu 16.04 به بعد و Debian 8 به بعد که همگی از systemd استفاده می‌کنند، معادل امروزی‌شان این است:

systemctl restart csf
systemctl restart lfd
systemctl status lfd

با این حال برای بارگذاری مجدد قواعد، همان csf -r و csf -ra روش استاندارد و بی‌دردسر است. در پایان حتماً وضعیت را بررسی کنید:

csf -v
grep -E '^TESTING *=' /etc/csf/csf.conf

خروجی دستور دوم باید TESTING = "0" را نشان دهد. اگر هنوز "1" است، هر چقدر هم پورت‌ها را دقیق تنظیم کرده باشید، فایروال شما واقعاً فعال نیست.

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

• csf -a IP — افزودن IP به لیست مجاز (csf.allow)
• csf -d IP — بلاک دائم یک IP (csf.deny)
• csf -dr IP — خارج کردن IP از لیست بلاک دائم
• csf -t — نمایش فهرست بلاک‌ها و مجوزهای موقت
• csf -tr IP — حذف یک ورودی موقت
• csf -g IP — جستجوی یک IP در قواعد فعلی فایروال و فایل‌های allow و deny
• csf -f — پاک کردن تمام قواعد فایروال (راه اضطراری وقتی خودتان را قفل کرده‌اید و از طریق کنسول یا رسکیو مود وارد شده‌اید؛ بعد از آن سرور تا اجرای csf -r بدون فایروال است)
• csf -x و csf -e — غیرفعال و فعال کردن کامل CSF؛ با csf -x هم فایروال و هم lfd خاموش می‌شوند و سرور کاملاً بی‌محافظ می‌ماند، پس فقط برای عیب‌یابی کوتاه‌مدت از آن استفاده کنید

وقتی مشتری یا همکاری می‌گوید «به سایت وصل نمی‌شوم»، اولین دستوری که باید بزنید csf -g با IP اوست؛ در بیشتر موارد پاسخ همان‌جاست.

جمع‌بندی و چک‌لیست نهایی

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

• پورت SSH شما در TCP_IN هست و در یک ترمینال دوم، اتصال جدید برقرار می‌شود.
• پورت‌های ۸۰ و ۴۴۳ برای وب و پورت کنترل‌پنل (در صورت وجود) باز است.
• پورت ۳۳۰۶ یا هر سرویس داخلی دیگری برای کل اینترنت باز نیست.
• TESTING روی 0 تنظیم شده و بعد از آن csf -ra اجرا شده است.
• AUTO_UPDATES = "1" است.
• LF_ALERT_TO با ایمیلی پر شده که واقعاً آن را می‌خوانید و رسیدن ایمیل تست شده است.
• اگر سرور آدرس IPv6 دارد، لیست‌های TCP6_IN و UDP6_IN هم تنظیم شده‌اند.
• firewalld یا ufw غیرفعال است تا با CSF تداخل نکند.

گزینه‌های csf.conf به همین‌جا ختم نمی‌شوند؛ بخش‌های مربوط به آستانه‌های بلاک خودکار، مدیریت کانکشن‌ها (Connection Tracking با گزینهٔ CT_LIMIT)، ردیابی پروسه‌ها (Process Tracking با گزینهٔ PT_LIMIT)، حفاظت از فرم‌های ورود و ادغام با لیست‌های سیاه، هر کدام موضوع مستقل خودشان را دارند. اما آنچه در این مقاله تنظیم کردید، همان لایه‌ای است که اگر درست باشد، بقیهٔ تنظیمات معنا پیدا می‌کنند و اگر غلط باشد، هیچ تنظیم دیگری نجات‌تان نمی‌دهد.