قواعد ورود SSH و VPN: فهرست مجاز در واقع چه چیزی را کنترل می‌کند

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

یک تلاش SSH را تا قلاب ورودی دنبال کنید

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

سپس شنونده را تأیید کنید، زیرا هیچ قاعده‌ای سرویسی را که آنجا نیست نجات نمی‌دهد. ss -ltnp را اجرا کنید و بررسی کنید که چیزی به درگاه و خانواده نشانی مورد انتظار شما بسته شده است، سپس ssh -v را روی کارخواه بخوانید تا ببینید کجا متوقف می‌شود.

ارسال به جلو تصمیمی جداگانه است

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

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

انداختن و رد کردن کنش‌اند، نه سیاست

سیاست زنجیره پایه می‌پذیرد یا می‌اندازد و این تمام فهرست انتخاب‌ها است، همان‌گونه که مرجع nftables می‌گوید. رد کردن به‌صورت کنش قاعده با پاسخی برگزیده وجود دارد، از همین رو نوشتن آن به‌عنوان سیاست هم روی nftables و هم روی iptables شکست می‌خورد. در عمل drop هیچ اطلاعاتی به کارخواه نمی‌دهد، در حالی که reject خطایی به آن می‌دهد که می‌تواند بر اساسش کاری کند.

table inet admin {
    chain input {
        type filter hook input priority filter; policy drop;
        ct state established,related accept
        ip saddr 203.0.113.0/28 tcp dport 22 accept
        udp dport 51820 accept
        icmp type { destination-unreachable, time-exceeded } accept
    }
}

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

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

مسدود کردن همه ICMP پیش‌فرض محبوبی است که کشف MTU مسیر را می‌شکند، و نشانه آن اتصالی است که برقرار می‌شود و سپس روی بسته‌های بزرگ‌تر گیر می‌کند. کشف همسایه در IPv6 به انواع ICMPv6 خودش وابسته است و دور انداختن آن‌ها پیوند را پیش از آن‌که هیچ قاعده TCP بررسی شود می‌شکند. هر دو به‌عنوان وابستگی‌های نام‌دار به فهرست مجاز تعلق دارند نه به‌عنوان اجازه‌های فراگیر. سیاستی که کشف را بی‌صدا می‌شکند از سیاستی که کمی ترافیک عیب‌یابی را می‌پذیرد بدتر است.

وضعیت‌های established و related را برای اتصالاتی که خودتان آغاز کردید مجاز کنید و بگذارید موتور حالت‌مند پاسخ‌ها را انجام دهد. سپس تأیید کنید که مسیر پاسخ دورتر مسدود نیست، زیرا محدودیتی که فقط ترافیک خروجی را بالا دست محدود می‌کند همان مهلتی را می‌سازد که می‌خواستید گردن میزبان بیندازید.

پیش از کنار گذاشتن مسیر قدیمی بازیابی را اثبات کنید

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

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