ipset و nftables؛ مدیریت مجموعهٔ IP با backend مناسب

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

در سروری که از ipset استفاده می‌کند، فرمان ipset list مجموعه‌های موجود را نشان می‌دهد. در سروری که nftables دارد، nft list ruleset قوانین فعلی را می‌خواند. این دو فرمان برای دیدن وضعیت‌اند؛ قرار نیست با اجرای آن‌ها کاربران مسدود شوند.

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

مجموعه فقط آدرس‌ها را نگه می‌دارد. برای اثر داشتن، قاعدهٔ فایروال باید به آن اشاره کند. ساختن یک set و افزودن IP به آن، بدون قاعدهٔ مرتبط، الزاماً چیزی را مسدود نمی‌کند. از طرف دیگر، حذف مجموعه‌ای که قاعده به آن وابسته است می‌تواند رفتار یا بارگذاری قواعد را مختل کند.

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

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

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

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

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

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

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