مدل امنیتی

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

لایه‌های بسته

هر بسته، از داخل به بیرون، چهار لایه دارد:

رمزنگاری سرتاسری

ترافیک بین دستگاه‌های شما با WireGuard بدون تغییر رمز می‌شود: Noise IK، Curve25519، ChaCha20-Poly1305 و BLAKE2s. فقط دو دستگاهی که در دو سر اتصال هستند می‌توانند آن را رمزگشایی کنند. ارائه‌دهنده‌ی اینترنت شما، سامانه‌های فیلترینگ و همه‌ی رله‌های میان راه فقط داده‌ی رمزشده می‌بینند.

رله‌ها هیچ‌وقت کلید ندارند

رله‌ها بسته‌هایی را جابه‌جا می‌کنند که از قبل با WireGuard رمز شده‌اند. هیچ‌وقت کلید ندارند، محتوا را نمی‌بینند و هرگز دو شبکه‌ی مختلف را به هم وصل نمی‌کنند. این هم درباره‌ی Global Relayها صدق می‌کند که نردبون تعیینشان می‌کند، و هم درباره‌ی دستگاه‌های خودتان که نقش رله دارند و فقط داخل شبکه‌ی خودتان رله می‌کنند. مسیر دومرحله‌ای هم فرقی ندارد: هیچ‌کدام از دو رله نمی‌تواند ترافیک را بخواند.

شبکه‌های هر سازمان کاملاً از سازمان‌های دیگر جدا هستند.

پنهان‌سازی

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

• بایت‌های ثابت WireGuard را پنهان می‌کند؛
• اندازه‌های ثابت handshake در WireGuard (۱۴۸ و ۹۲ بایت) را با padding از بین می‌برد؛
• پیش از handshakeها و در زمان بیکاری، مقدار محدودی ترافیک پوششی می‌فرستد؛
• فقط به handshakeها تأخیر تصادفی کوچکی اضافه می‌کند، هیچ‌وقت به داده؛
• نسخه‌دار است تا اگر روزی نسخه‌ای شناسایی شد، نسخه‌ی تازه سریع منتشر شود.

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

مقاومت در برابر شناسایی فعال

سامانه‌های فیلترینگ فقط ترافیک را زیر نظر نمی‌گیرند؛ به سرورهای مشکوک هم وصل می‌شوند تا ببینند چه جوابی می‌دهند. نود نردبون فقط به اتصال‌هایی جواب می‌دهد که در همان بایت‌های اول ثابت کنند یک secret را می‌دانند. هر اتصال دیگری جوابی نمی‌گیرد: روی UDP سکوت کامل است و روی ترنسپورت‌های TLS، بازدیدکننده‌ای که احراز هویت نشده فقط یک وب‌سایت معمولی می‌بیند. پیام‌های ضبط‌شده هم قابل تکرار نیستند؛ پس ضبط یک اتصال واقعی و فرستادن دوباره‌ی آن هم فایده‌ای ندارد. این secret داخل خود برنامه نیست: دستگاه مقدار مربوط به control plane را هنگام پیوستن به شبکه می‌گیرد (همراه auth key، یا وقتی کسی اجازه‌ی ورودش را بدهد) و هر relay مقدار مخصوص خودش را دارد که فقط دستگاه‌هایی که اجازه‌ی استفاده از آن را دارند می‌دانند.

جلوگیری از downgrade

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

چیزهایی که هرگز جمع‌آوری نمی‌شوند

نردبون هیچ‌وقت محتوای ترافیک شما یا کوئری‌های DNS شما را جمع‌آوری نمی‌کند.

سرور کنترل برای اداره‌ی شبکه‌تان با داده‌های عملیاتی سروکار دارد؛ مثلاً:

• نام، آدرس و endpointهای دستگاه‌ها؛
• اینکه هر اتصال از چه مسیر و ترنسپورتی استفاده می‌کند و کیفیتش چطور است، همان‌طور که در داشبورد نمایش داده می‌شود؛
• حجم ترافیک رله، که برای هر سازمان شمرده می‌شود؛
• اینکه هر دستگاه به کدام رله‌ها می‌رسد، و کشوری که از آن وصل می‌شود، که از آدرس عمومی‌اش خوانده می‌شود و خودِ آن آدرس نگه داشته نمی‌شود: برای اینکه معلوم باشد یک رله از کجا در دسترس نیست.

nardeboon bugreport بسته‌ی عیب‌یابی را به‌صورت محلی و بدون کلید یا داده‌ی حساس می‌سازد. شما آن را بررسی می‌کنید و خودتان تصمیم می‌گیرید که به اشتراکش بگذارید یا نه.

به‌روزرسانی امضاشده

دستگاه‌ها خودکار به‌روز می‌شوند و فقط نسخه‌های امضاشده را نصب می‌کنند. مدیر می‌تواند از داشبورد به‌روزرسانی را شروع کند، اما این کار فقط می‌تواند از دستگاه بخواهد یک نسخه‌ی امضاشده را نصب کند: داشبورد هیچ‌وقت نمی‌تواند دستور دلخواهی روی دستگاه‌های شما اجرا کند. اگر بررسی امضا یا یکپارچگی شکست بخورد، CLI کد خروج 9 (verify) را برمی‌گرداند.

وقتی سرور کنترل در دسترس نیست

اگر سرور کنترل در دسترس نباشد، مثلاً چون در کشور شما فیلتر شده است، دستگاه‌ها با آخرین network map امضاشده و داده‌هایشان به کار ادامه می‌دهند، حتی بعد از راه‌اندازی مجدد. این وضعیت تا پایان بازه‌ی اعتبار آفلاین ادامه پیدا می‌کند؛ بازه‌ای که برای هر شبکه جداگانه تعیین می‌شود و مقدار پیش‌فرضش طولانی است. در این مدت:

• nardeboon status هشدار نشان می‌دهد؛
• دستگاه‌ها پیوسته با همه‌ی ترنسپورت‌ها و همه‌ی endpointهای شناخته‌شده، از جمله از طریق رله‌ها و دستگاه‌های دیگر، برای رسیدن به سرور کنترل تلاش می‌کنند؛
• دستگاه‌ها به‌روزرسانی‌های امضاشده‌ی endpointها و ابطال‌های امضاشده را بین خودشان دست‌به‌دست می‌کنند؛ پس ابطال یک دستگاه به دستگاه‌هایی هم می‌رسد که خودشان به سرور کنترل دسترسی ندارند.

وقتی سرور کنترل در دسترس نیست را ببینید.

چرخه‌ی عمر کلیدها

امنیت حساب کاربری

• با ایمیل و رمز عبور (همراه با تأیید ایمیل)، یا با SSO از طریق Google، GitHub یا Microsoft وارد شوید.
• از حسابتان با MFA محافظت کنید: اپ احراز هویت (TOTP) یا passkey، به‌علاوه‌ی کدهای بازیابی.
• سازمان می‌تواند ورود با SSO را برای همه‌ی اعضایش الزامی کند.
• نقش‌ها (مالک، مدیر، مدیر شبکه، مدیر مالی، ناظر و عضو) کمک می‌کنند به هر کس فقط همان دسترسی‌ای را بدهید که لازم دارد.
• گزارش رویدادها همه‌ی کارهای مهم را ثبت می‌کند.
• کلیدهای API و توکن‌های OAuth فقط scopeهای محدودی دارند و هرگز نمی‌توانند credential بسازند یا پول جابه‌جا کنند. مرجع API را ببینید.