امنیت

پنل چه کارهایی برایتان انجام می‌دهد

• HTTPS به‌طور پیش‌فرض. نصب‌کننده برای دامنه‌تان یا برای آدرس خود سرور گواهی می‌گیرد و بدون دخالت شما تمدیدش می‌کند.
• چیزی برای پیدا کردن نیست. پورت تصادفی و پیشوند تصادفی در آدرس. هر مسیری بیرون از آن، حتی صفحه‌ی ورود، خطای 404 می‌دهد.
• چیزی برای حدس زدن نیست. نام و رمز مدیر خودکار ساخته می‌شوند و admin / admin وجود ندارد.
• محدودسازی ورود برای هر آدرس و هر حساب، و یک jail در fail2ban (w-ui ← 22. Connection limit) که آدرس را بعد از چند تلاش ناموفق مسدود می‌کند. این jail فقط پورت پنل را زیر نظر دارد، پس تونل مشتری‌ها و SSH شما دست‌نخورده می‌مانند.
• ورود دومرحله‌ای (TOTP) که فقط بعد از درست بودن رمز پرسیده می‌شود؛ پس هیچ‌وقت لو نمی‌دهد کدام حساب‌ها آن را دارند.
• سیاست سخت‌گیرانه‌ی Content-Security-Policy، با یک nonce برای هر درخواست.
• اطلاعات ورود بیرون از صفحه‌ی مشتری. اطلاعات ورود L2TP، PPTP، IKEv2 و OpenConnect پوشیده نشان داده می‌شوند و هر کدام با یک کلیک کپی می‌شوند؛ فقط خود صفحه می‌تواند آنها را بگیرد و هر درخواست شمرده و در لاگ نوشته می‌شود. متن خام لینک، دانلود و آرشیو هم ماسک دارند. در صفحه‌ی سابسکریپشن آمده که این روش جلوی چه چیزی را می‌گیرد و جلوی چه چیزی را هیچ صفحه‌ای نمی‌تواند بگیرد.
• حساب سرویس بدون امتیاز. پنل با کاربر wui اجرا می‌شود، فقط با CAP_NET_ADMIN و CAP_NET_BIND_SERVICE، زیر ProtectSystem=strict، و با یک پوشه‌ی قابل نوشتن.
• رازها سر جایشان می‌مانند. رمزها به شکل هش bcrypt نگه داشته می‌شوند. توکن‌های API هش ذخیره و فقط یک بار نشان داده می‌شوند. کلید خصوصی اینترفیس‌ها و دستگاه‌ها هیچ‌وقت در چیزی که پنل برای نمایش می‌سازد نمی‌آید؛ فقط در فایل خود مشتری.
• خبر پیش از انقضای گواهی. هشدارهای امنیتی بالای تنظیمات می‌گویند کی کمتر از دو هفته به انقضای گواهی پنل یا سرویس سابسکریپشن مانده، و بعد از انقضا بلندتر هشدار می‌دهند. تمدید همچنان کار نصب‌کننده و acme.sh است؛ این هشدار فقط مطمئن می‌شود که خبر انقضا را از مشتری نشنوید.
• نسخه‌های امضاشده. پنلی که با کلید عمومی پروژه ساخته شده، به‌روزرسانی‌ای را که امضایش جور نباشد رد می‌کند.

رازها کجا هستند

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

• روی سرور، دیتابیس در /var/lib/wui/wui.db است و فقط کاربر خود پنل می‌تواند آن را بخواند: مجوز 0600، در پوشه‌ای با مجوز 0750 که مال همان کاربر است. از 3.0 پنل موقع شروع این فایل را خصوصی می‌کند، چون نسخه‌های قبلی آن را برای همه خواندنی گذاشته بودند.
• در بکاپ، اگر رمز بکاپ تنظیم شده باشد، آرشیو با آن رمزنگاری می‌شود (بکاپ و بازگردانی). کلیدی که نشست‌ها با آن امضا می‌شوند هیچ‌وقت در بکاپ نیست، پس با بکاپ نمی‌شود وارد پنلش شد.
• نه ستون به ستون. اگر عامل دوم و اطلاعات ورود نودها داخل دیتابیس با کلیدی رمزنگاری می‌شدند که بیرون از بکاپ نگه داشته شود، بعد از بازگردانی روی سرور دیگر خوانده نمی‌شدند و مالک نمی‌توانست وارد پنل خودش شود. مجوز فایل و رمزنگاری بکاپ از همان رازها محافظت می‌کنند، بدون این خطر.

شما چه کنید

• فایروال را به پورت پنل، پورت تونل‌ها، پورت 80 برای تمدید گواهی، و SSH محدود کنید. پورت‌ها و فایروال را ببینید.
• ورود دومرحله‌ای را روشن کنید. رمز تنها چیزی است که بین مهاجم و کانفیگ همه‌ی مشتری‌ها قرار دارد.
• رمز بکاپ بگذارید و بکاپ‌ها را جای دیگری بفرستید: تلگرام، یا /var/backups/wui را از سرور بیرون ببرید.
• فایل install-result.env را یک بار بخوانید و بعد پاکش کنید.

گزارش آسیب‌پذیری

SECURITY.md را ببینید. لطفاً برای مشکل امنیتی، issue عمومی باز نکنید.