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

سناریو: سیاست یک میزبان آزمایشی را طراحی می‌کنید: ارتباط‌های موجود و loopback کار کنند، SSH فرضی روی 2222 مجاز باشد و میزبان روتر نشود. هدف، فهم قواعد و بررسی فایل است. نمونه را روی سرور موجود، رایانهٔ اصلی یا ماشینی که فقط با SSH در دسترس است اعمال نکنید. تمرین پیش‌فرض با کاربر معمولی، نوشتن فایل و تحلیل بسته‌هاست؛ دسترسی مدیریتی لازم ندارد.

نام زنجیره با مسیر بسته فرق دارد

در خانوادهٔ inet می‌توان قواعد IPv4 و IPv6 را کنار هم نوشت. جدول ظرف زنجیره‌هاست؛ زنجیرهٔ پایه با hook به مسیر واقعی بسته متصل می‌شود. input برای بستهٔ مقصد همین میزبان، forward برای بستهٔ عبوری به میزبان دیگر و output برای بسته‌ای است که خود میزبان تولید می‌کند. نام زنجیره دلخواه است؛ نوشتن نام input بدون اتصال به hook آن را فعال نمی‌کند. policy تصمیم پیش‌فرض در پایان زنجیرهٔ پایه است، پس ترتیب و مسیر بررسی قواعد باید روشن باشد.

پیش از نوشتن قاعده، قرارداد را با جمله بیان کنید: ورودی تازه فقط برای SSH آزمایش، ترافیک کنترلی شبکه و loopback مجاز است؛ پاسخ ارتباط‌های معتبر موجود پذیرفته می‌شود؛ عبور میان رابط‌ها مجاز نیست؛ خروجی آزاد است. آزادبودن output تصمیم همین سناریو است و برای هر محیط مناسب نیست. هیچ قاعده‌ای سرویس SSH را راه نمی‌اندازد یا پورت آن را عوض نمی‌کند. عدد 2222 فقط فرض این آزمایش است؛ روی سرور واقعی جایگزینی آن بدون شناخت سرویس می‌تواند دسترسی را قطع کند.

fw_lab=$(mktemp -d)

نمونه را در فایل course.nft داخل پوشهٔ fw_lab ذخیره کنید. ذخیره‌کردن فایل سیاست شبکه را تغییر نمی‌دهد. خط‌های ICMP و ICMPv6 اجازهٔ پیام‌های کنترلی شبکه را می‌دهند؛ حذف شتاب‌زدهٔ آن‌ها ممکن است تشخیص خطا یا IPv6 را مختل کند. برای هر خط بنویسید کدام بند قرارداد را پیاده می‌کند.

table inet course_demo {
    chain input {
        type filter hook input priority 0; policy drop;
        ct state invalid drop
        iifname "lo" accept
        ct state established,related accept
        meta l4proto { icmp, ipv6-icmp } accept
        tcp dport 2222 ct state new accept
    }
    chain forward {
        type filter hook forward priority 0; policy drop;
    }
    chain output {
        type filter hook output priority 0; policy accept;
    }
}

ct از اطلاعات رهگیری اتصال استفاده می‌کند. invalid بستهٔ دارای وضعیت نامعتبر را کنار می‌گذارد؛ established و related اجازهٔ ادامه یا ترافیک مرتبط با ارتباط شناخته‌شده را می‌دهند. این مفهوم با بازکردن همهٔ پورت‌های ورودی فرق دارد. بستهٔ تازهٔ TCP برای 2222 به قاعدهٔ مشخص نیاز دارد؛ بستهٔ تازهٔ TCP برای 8080 به policy drop می‌رسد. loopback زود پذیرفته می‌شود تا ارتباط محلی مختل نشود. forward با سیاست بسته، نقش عبور ترافیک را در این قرارداد رد می‌کند.

بررسی فایل، اجرای سیاست نیست

گام اختیاری فقط در کنسول یک VM دورریختنی مستقل انجام می‌شود؛ فایل را همان‌جا دوباره بسازید. فرمان زیر مخصوص کاربر root همان VM یا فرایندی با CAP_NET_ADMIN در فضای شبکهٔ مربوط است. آن را برای گرفتن مجوز روی میزبان اصلی با sudo تکرار نکنید. گزینهٔ -c تغییرها را اعمال نمی‌کند، اما یک تجزیه‌گر کاملاً آفلاین هم نیست: nft برای بررسی معتبر بودن درخواست‌ها با کرنل و Netlink تعامل دارد. نبود قابلیت لازم یا پشتیبانی کرنل می‌تواند مانع بررسی شود.

# Optional: disposable VM console, root/CAP_NET_ADMIN only
nft -c -f "$fw_lab/course.nft"

خروج موفق یعنی درخواست در بافت همان کرنل بررسی شده است؛ عبور بسته، بازبودن SSH یا ماندگاری پس از راه‌اندازی مجدد را ثابت نمی‌کند. پیام Operation not permitted شاهد محدودیت اختیار است، نه اثبات دستور زبان غلط. در محیط نویسنده UID صفر، قابلیت‌های مؤثر صفر و nft ناموجود بود؛ اجرای بررسی ادعا نمی‌شود. نام root در کانتینر به‌تنهایی مجوز مدیریت شبکه ایجاد نمی‌کند.

حتی یک جدول جدید ممکن است با قواعد فعلی تعامل داشته باشد. accept در یک زنجیره لزوماً آخرین تصمیم همهٔ زنجیره‌های همان hook نیست؛ زنجیره‌ای که بعداً اجرا می‌شود می‌تواند بسته را drop کند. بنابراین این فایل طرح استقرار آماده برای سرور موجود نیست. هیچ فرمان پاک‌کردن کل ruleset یا ترکیب کورکورانهٔ iptables و nft در این تمرین نداریم. تغییر واقعی به شناخت همهٔ زنجیره‌ها، کنسول مستقل، برنامهٔ بازگشت و آزمون مجاز جداگانه نیاز دارد.

تمرین و پاسخ: پاسخ اتصال وبی که همین میزبان آغاز کرده، درخواست تازهٔ SSH روی 2222 و بستهٔ عبوری میان دو رابط از چه مسیری می‌گذرند؟ پاسخ وب وارد input می‌شود و در صورت وضعیت established پذیرفته می‌شود؛ درخواست تازهٔ SSH نیز input را طی می‌کند و به قاعدهٔ پورت می‌رسد. بستهٔ عبوری به forward می‌رود و در مدل ما حذف می‌شود. هیچ‌کدام از این استدلال‌ها به‌تنهایی موفقیت سرویس در یک شبکهٔ واقعی را تضمین نمی‌کند.

منابع رسمی انگلیسی:
nft: https://netfilter.org/projects/nftables/manpage.html
Chains: https://wiki.nftables.org/wiki-nftables/index.php/Configuring_chains
Conntrack: https://wiki.nftables.org/wiki-nftables/index.php/Matching_connection_tracking_stateful_metainformation
Internals: https://wiki.nftables.org/wiki-nftables/index.php/Portal:DeveloperDocs/nftables_internals
Capabilities: https://www.man7.org/linux/man-pages/man7/capabilities.7.html

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