# Webship سرور وب: تنظیمات ایمن بهصورت پیشفرض
یک سرور وب امن نباید به یادآوری یک تنظیم دیگر توسط اپراتور در ساعت ۲ صبح وابسته باشد. باید از یک پایه محافظتی شروع کند، پیکربندیهای ناامن را رد کند و قبل از اینکه قابلیتهای حساس را آشکار کند، انتخابهای آگاهانه را الزامی سازد.
این مدل پشت Webship است. پیکربندی پیشفرض آن، دفاعهای اصلی درخواست و پاسخ را فعال میکند، منابعی که یک مهاجم میتواند مصرف کند را محدود میکند و سطوح کنترلی اختیاری را غیرفعال باقی میگذارد. شما میتوانید آن پیشفرضها را برای یک برنامه واقعی تنظیم کنید، اما نیازی نیست قبل از رسیدن اولین درخواست، هر حفاظتی را کشف کنید.
امن به صورت پیشفرض به معنای امن بدون زمینه نیست. گواهیها، مجوزهای برنامه، سیاست شبکه، اسرار و واکنش به حادثه همچنان به عهدهی اپراتور است. وظیفهی Webship این است که نقطه شروع ایمن را آشکار کند و تضعیف تصادفی را سختتر نماید.
حفاظتهایی که بهطور پیشفرض فعال هستند
Webship در پیکربندی پایه خود شش لایه را فعال میکند:
| لایه | رفتار پیشفرض | چه چیزی را کاهش میدهد | | --- | --- | --- | | محافظت از فایلهای نقطهدار | جلوگیری از مسیرهای استاتیک با پیشوند نقطه | افشای تصادفی فایلهای محیطی، متادیتای مخزن و پیکربندی محلی | | فایروال برنامه وب | مسدود کردن الگوهای حمله شناختهشده | تزریق SQL، اسکریپتنویسی سمتمشتری (XSS)، عبور مسیر، بررسی مسیرهای حساس، تزریق دستور، قاچاق هدر و کدگذاریهای درخواست پشتیبانینشده | | کنترلهای DDoS | در حالت عادی با وضعیت محدود مشتری اجرا میشود | سیل درخواستها، پیگیری نامحدود و خستگی منابع که قابل اجتناب است | | چالش ربات | استفاده از یک کوکی چالش امضا شده | سوء استفاده خودکار کمهزینه و اسکن تکراری | | هدرهای امنیتی پاسخ | افزودن سیاست مرورگر محدودکننده | سردرگمی MIME، فریمبندی، نشت مرجع، قابلیتهای خطرناک مرورگر و بارگذاری گسترده محتوا | | سپر API | از حالت مسدودسازی استفاده میکند و مسیرهای ناشناخته را پس از تعریف قرارداد API رد میکند | نقاط پایانی سایهای، روشهای ناخواسته، نوع محتواهای غیرمنتظره، و الزامات مجوز از دست رفته |
WAF پیشفرض همچنین محدودیتهای سختی برای آنچه بررسی میکند قرار میدهد: ۳۲ کیلوبایت هدرهای درخواست، یک مسیر ۲۰۴۸ بایتی و یک بدنه درخواست ۱ مگابایتی. اینها محدودیتهای امنیتی هستند، نه سوئیچهای عملکردی دلخواه. اگر یک برنامه واقعاً به درخواستهای بزرگتر نیاز دارد، محدودیت مربوطه را برای آن برنامه افزایش دهید و نتیجه را آزمایش کنید به جای اینکه بررسی را به طور جهانی غیرفعال کنید.
حفاظت DDoS در حالت عادی از ۶۰۰ درخواست در دقیقه با اجازه انفجار ۱۰۰ درخواست برای هر کلید مشتری شروع میشود. جدول وضعیت مشتری آن به ۶۵,۵۳۶ ورودی محدود شده است. این مقادیر یک خط مبنا هستند، نه یک مدل ترافیک جهانی: یک API عمومی، یک سرویس دانلود و یک پنل مدیریت داخلی نباید همان محدودیتهای خاص برنامه را داشته باشند.
حفاظتهای مرورگر بخشی از خط مبنا هستند
سیاست هدر پاسخ Webship فعال است حتی زمانی که یک برنامه فراموش میکند هدر خودش را اضافه کند. پیشفرض شامل موارد زیر است:
- گزینههای نوع محتوا X: nosniff;
- یک سیاست عدم اجازه فریم؛
- سیاست ارجاعدهنده: بدون ارجاعدهنده؛
- امنیت انتقال سخت به مدت یک سال، شامل زیردامنهها؛
- سیاست امنیت محتوا محدود به محتوای همان منبع، با محدودیتهای فریمبندی و URI پایه؛
- سیاست مجوزها که دسترسی به موقعیت جغرافیایی، میکروفون و دوربین را غیرفعال میکند.
این پیشفرضها به طور عمدی محدودکننده هستند. قبل از اعمال HSTS به یک دامنه با زیردامنههایی که به طور کامل آماده HTTPS نیستند، آن را بررسی کنید. قبل از اینکه یک برنامه اسکریپتها، استایلها، فونتها، تصاویر یا ارتباطات از منابع دیگر را بارگذاری کند، سیاست امنیت محتوا (Content-Security-Policy) را بررسی کنید. یک پیشفرض امن باید به طور قابل مشاهده در هنگام استقرار شکست بخورد، نه اینکه به طور پنهانی در محیط تولید ضعیف شود.
سطوح اختیاری بسته میمانند
Webship هر ویژگی را فقط به این دلیل که در باینری وجود دارد، در دسترس قرار نمیدهد. پروکسی معکوس، WebTransport، نقاط پایش، TLS خودکار، منشاء پاسخ و نقطه کنترل MCP به طور پیشفرض غیرفعال هستند.
نقطه پایانی MCP زمانی که فعال شود در محدوده لوپبک قرار دارد و نیاز به پیکربندی امنیتی صریح دارد. اندازهگیریها و آمار نیاز به فعالسازی عمدی ابزارگذاری دارند. مدیریت خودکار گواهینامه نیازمند آن است که اپراتور یک دایرکتوری ACME، مخاطبین، ذخیرهسازی و پذیرش شرایط خدمات را انتخاب کند. این کار مانع از آن میشود که ویژگیهای عملیاتی به سطوح شبکه غیرمنتظره تبدیل شوند.
شنونده پایه نیز به 127.0.0.1 متصل میشود. یک اپراتور باید بهطور صریح یک آدرس عمومی را انتخاب کند. آن انتخاب واحد یک نقطه بازبینی مفید برای قوانین فایروال، مجوزهای سرویس، هویت TLS و توپولوژی استقرار ایجاد میکند.
پراکسی معکوس مرز اعتماد را حفظ میکند
هنگامی که پروکسی معکوس فعال است، عبور TLS همچنان به عنوان پیشفرض باقی میماند. Webship ترافیک رمزگذاری شده را منتقل میکند بدون آنکه به متن ساده برنامه یا کلیدهای جلسه فعال دست یابد. منشأ مسئول TLS و پروتکل مذاکره شده باقی میماند.
فعالسازی خاتمه TLS تنها زمانی انجام شود که Webship باید درخواستهای HTTP را بررسی کند، بر اساس مسیر مسیریابی کند، سیاست WAF و API را اعمال کند، هدرها را بازنویسی کند یا پاسخها را کش کند. خاتمه ذاتاً کمتر ایمن نیست؛ بلکه مرز اعتماد را جابجا میکند. تصمیم مهم این است که کدام ماشین اجازه دارد متن ساده را ببیند و چرا.
پاسترو همچنین محدودیتهای عملکردی دارد. مسیردهی TCP بر اساس SNI در ClientHello است زیرا درخواست HTTP رمزگذاری شده است. پاسترو HTTP/3 نیاز دارد که مسیرها یک منبع UDP را به اشتراک بگذارند. اگر به امنیت محتوا محور در لبه نیاز دارید، TLS را در آنجا خاتمه دهید و مسیر لبه به منبع را بهصورت جداگانه محافظت کنید.
یک خط مبنای تولید که میتوانید بررسی کنید
بخش زیر به جای تکیه بر حذف، پیشفرضهای مهم را صریح نشان میدهد:
listen = "0.0.0.0:443"
deny_dotfiles = true
[tls]
unknown_sni = "reject"
[ddos]
enabled = true
mode = "normal"
requests_per_minute = 600
burst = 100
block_seconds = 60
max_tracked_clients = 65536
[security]
enabled = true
rate_limit_max_entries = 65536
[security.waf]
enabled = true
mode = "block"
sqli = true
xss = true
traversal = true
sensitive_paths = true
header_abuse = true
max_header_bytes = 32768
max_path_bytes = 2048
max_body_bytes = 1048576
[security.response_headers]
enabled = true
nosniff = true
frame_deny = true
referrer_no_referrer = true
hsts = "max-age=31536000; includeSubDomains"
content_security_policy = "default-src 'self'; frame-ancestors 'none'; base-uri 'self'"
permissions_policy = "geolocation=(), microphone=(), camera=()"در یک شنونده چند دامنهای، unknown_sni = "reject" مانع از آن میشود که یک نام میزبان ناشناخته گواهی پیشفرض شنونده را دریافت کند. شنوندههای TLS خودکار Webship از قبل نامهای ناشناخته را تا زمانی که گواهی وجود نداشته باشد رد میکنند.
اعتبارسنجی یک کنترل امنیتی است
Webship قبل از اتصال شنوندهها، پیکربندی را اعتبارسنجی میکند. فیلدهای ناشناخته، محدودیتهای نامعتبر، هویتهای ناقص، شنوندههای متناقض و ترکیبهای پروتکل غیرقابل پشتیبانی باعث شکست راهاندازی با یک خطای خاص میشوند. همان اعتبارسنجی قبل از نصب پیکربندی زنده نیز اجرا میشود. بارگذاری مجدد ناموفق باعث میشود پیکربندی فعلی فعال باقی بماند.
مسیر پیکربندی معتبر MCP یک محافظ دیگر اضافه میکند: این مسیر تغییرات زندهای را که منجر به غیرفعال شدن WAF فعال، لایه DDoS، API Shield، چالش بات، سیاست احراز هویت لبه یا لایه هدر پاسخ میشوند، رد میکند. بررسیهای نسخه از بازنویسی یک نسخه پیکربندی جدیدتر توسط یک مدیر جلوگیری میکند. تنظیمات متصل به فرآیند همچنان نیاز به راهاندازی مجدد دارند و نمیتوان وانمود کرد که یک تغییر جزئی زنده موفق شده است.
این یک تمایز مفید است. پیشفرضهای امن از یک پیادهسازی جدید محافظت میکنند. اعتبارسنجی تراکنشی و بهروزرسانیهای محافظتشده از یک پیادهسازی در حال اجرا محافظت میکنند.
چه اپراتورهایی هنوز باید تصمیم بگیرند
قبل از در معرض اینترنت قرار دادن Webship:
- یک هویت TLS معتبر پیکربندی کرده و کلید خصوصی را محافظت کنید.
- تنظیم نحوه مدیریت SNI ناشناخته برای توپولوژی شنونده.
- تأیید کنید که HSTS و سیاست امنیت محتوا با هر برنامه و زیردامنه مطابقت دارند.
- نقاط پایانی API Shield، روشهای پذیرفته شده، انواع محتوا و الزامات مجوز را تعریف کنید.
- به جای تکیه تنها بر خط مبنای جهانی، محدودیتهای نرخ خاص مسیر را اضافه کنید.
- احراز هویت لبه را برای میزبانها یا مسیرهای محافظتشده فعال کرده و از توکنهای کوتاهمدت استفاده کنید.
- نگه داشتن MCP و شنوندههای قابلیت مشاهده خصوصی، احراز هویت شده، و جدا از ترافیک عمومی.
- اجرای Webship با یک حساب اختصاصی بدون امتیازات، یک ریشه برنامه فقط خواندنی در صورت امکان، و فقط قابلیتهای سیستم عامل مورد نیاز آن.
- پیکربندی را قبل از انتشار اعتبارسنجی کنید، سپس ترافیک مسدود شده و مجاز را در یک محیط کاناری آزمایش کنید.
- رویدادهای حسابرسی امنیتی را نظارت کنید و تغییر از حالت عادی به حالت تحت حمله یا قفلشده را تمرین کنید.
یک پیشفرض امنتر یک شروع است، نه یک ادعا
هیچ سرور وبی نمیتواند تصمیم بگیرد که کدام کاربران باید فاکتورهایتان را ببینند، کدام مبداءها میتوانند به API شما فراخوانی کنند، یا سرعت پذیرش درخواستها توسط نقطه پایانی کسبوکار شما چقدر باشد. آن کنترلها به دانش برنامه نیاز دارند.
Webship لایه پایینتر را تأمین میکند: پارسرهای محدود، پیکربندی سختگیرانه، هدرهای پاسخ محافظتی، بازبینی درخواستها، کنترلهای سوءاستفاده و سطوح اختیاری بسته. نتیجه «امنیت حل شده» نیست. این یک فاصله کوچکتر بین نصب یک سرور و اداره مسئولانه آن است.
قبل از استقرار در محیط تولید، مستندات کامل Webship را مرور کنید. طرح پیکربندی و فایل اجرایی در حال اجرا منابع معتبر برای نسخه دقیق مورد استفاده شما باقی میمانند.