گروه امنیتی ابری برای VPN: شنونده را باز کنید، نه همه چیز

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

پیش از قاعده، پروتکل را نام ببرید

قاعده یعنی پروتکل، بازه درگاه و منبع. WireGuard روی UDP گوش می‌دهد، معمولاً 51820. OpenVPN بسته به پیکربندی معمولاً UDP یا TCP 1194 است. IPsec به تبادل IKE روی UDP 500 و 4500 و همچنین خود پروتکل ESP نیاز دارد که شماره پروتکل است نه درگاه. حدس زدن TCP چون قاعده‌های دیگر TCP هستند، همان راهی است که به قاعده‌ای می‌رسد که درست به نظر می‌رسد و با هیچ چیز نمی‌خواند.

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

منبع را به بازه کارخواه‌هایی محدود کنید که طراحی اجازه می‌دهد، نه به کل اینترنت.

گروه‌های امنیتی حالت‌مند هستند؛ ACLهای زیرشبکه نیستند

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

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

سیاست مؤثر اجتماع آن چیزی است که متصل است، نه پرونده‌ای که ویرایش کردید.

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

سیاست ابری ترافیک را به واسط شبکه راه می‌دهد و سپس سیستم‌عامل تصمیم می‌گیرد که دیمن آن را ببیند یا نه. فایروال میزبان با سیاست رد پیش‌فرض بسته‌ای را که گروه امنیتی اجازه داده بود دور می‌ریزد و کنسول ابری هیچ ردی نشان نمی‌دهد چون هرگز نظری نداشته است. هر دو را بررسی کنید، به ترتیبی که بسته به آن‌ها می‌رسد.

اگر میزبان از نمای جلویی فایروال توزیع استفاده می‌کند، قاعده‌های زیرین را تأیید کنید نه نام نمایه را، چون نمایه می‌تواند فعال باشد در حالی که درگاه بسته است.

یک ضبط روی واسط به شما می‌گوید کدام مرز بسته را دور ریخته است.

اجازه دادن به شنونده به معنای مسیریابی کارخواه‌ها نیست

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

اینجاست که دست‌دادن کارآمد و مسیر داده شکسته از هم جدا می‌شوند و به همین دلیل وضعیت تونل می‌تواند سالم به نظر برسد در حالی که هیچ چیز بارگذاری نمی‌شود.

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

راهی برای بازگشت نگه دارید، سپس قاعده را باریک کنید

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

هر اجازه گسترده آزمایشی را به محض کار کردن اجازه باریک حذف کنید و بنویسید که قاعده چرا وجود دارد. AWS رفتار حالت‌مند گروه‌های امنیتی را مستند می‌کند و همان سند است که باید وقتی کسی بازه گسترده را به عنوان میان‌بر پیشنهاد می‌کند به آن استناد کرد.

اتصال را هم مستند کنید، وگرنه یک واسط جانشین سیاست را بی‌صدا از دست می‌دهد.