Webship ویب سرور: ڈیفالٹ کے طور پر محفوظ ترتیبات

# Webship ویب سرور: ڈیفالٹ کے طور پر محفوظ ترتیبات

ایک محفوظ ویب سرور کو اس بات پر انحصار نہیں کرنا چاہیے کہ آپریٹر صبح کے 2 بجے ایک اور سیٹنگ یاد رکھے۔ یہ ایک حفاظتی بنیاد سے شروع ہونا چاہیے، غیر محفوظ ترتیب کو مسترد کرنا چاہیے، اور حساس صلاحیتیں ظاہر کرنے سے پہلے جان بوجھ کر انتخاب کی ضرورت ہونی چاہیے۔

یہ Webship کے پیچھے ماڈل ہے۔ اس کی ڈیفالٹ کنفیگریشن بنیادی درخواست اور جواب کے دفاع کو فعال کرتی ہے، اس بات کی حد مقرر کرتی ہے کہ حملہ آور کتنے وسائل استعمال کر سکتا ہے، اور اختیاری کنٹرول سطحیں غیر فعال رہتی ہیں۔ آپ حقیقی ایپلیکیشن کے لیے ان ڈیفالٹس کو ایڈجسٹ کر سکتے ہیں، لیکن آپ کو یہ دریافت کرنے کی ضرورت نہیں کہ پہلی درخواست آنے سے پہلے ہر حفاظت کیا ہے۔

بنیادی طور پر محفوظ کا مطلب یہ نہیں کہ بغیر سیاق و سباق کے محفوظ ہو۔ سرٹیفیکیٹس، ایپلیکیشن کی اجازت، نیٹ ورک کی پالیسی، راز، اور حادثاتی جواب دہی اب بھی آپریٹر کی ذمہ داری ہیں۔ Webship کا کام یہ ہے کہ محفوظ آغاز کو واضح بنایا جائے—اور غیر ارادی کمزوری کو مشکل بنایا جائے۔

وہ تحفظات جو فعال شروع ہوتے ہیں

Webship اپنی بنیادی ترتیب میں چھ پرتیں فعال کرتا ہے:

| پرت | ڈیفالٹ رویہ | یہ کیا کم کرتا ہے | | --- | --- | --- | | ڈاٹ-فائل کی حفاظت | ڈاٹ سے شروع ہونے والے سٹیٹک پاتھ سیگمنٹس کو مسترد کرتا ہے | ماحول کی فائلوں، ریپوزیٹری میٹاڈیٹا، اور مقامی کنفیگریشن کے حادثاتی انکشاف کو روکتا ہے | | ویب ایپلیکیشن فائر وال | معروف حملوں کے نمونوں کو بلاک کرتا ہے | ایس کیو ایل انجیکشن، کراس-سائٹ اسکرپٹنگ، ٹراورسل، حساس راستے کی پروبنگ، کمانڈ انجیکشن، ہیڈر اسمگلنگ، اور غیر معتمد درخواست انکوڈنگ | | ڈی ڈی او ایس کنٹرولز | محدود کلائنٹ اسٹیٹ کے ساتھ معمول کے موڈ میں چلتا ہے | درخواستوں کی بھرمار، غیر محدود ٹریکنگ، اور قابل اجتناب وسائل کے خاتمے | | بوٹ چیلنج | دستخط شدہ چیلنج کوکی استعمال کرتا ہے | کم لاگت خودکار بدعنوانی اور بار بار اسکیننگ | | رسپانس سیکیورٹی ہیڈرز | ایک محدود براؤزر پالیسی شامل کرتا ہے | MIME کنفیوزن، فریمنگ، ریفرر لیکیج، خطرناک براؤزر صلاحیتیں، اور وسیع مواد لوڈنگ | | API شیلڈ | بلاک موڈ استعمال کرتا ہے اور ایک بار جب API معاہدہ متعین ہو جائے تو نامعلوم راستوں کو مسترد کر دیتا ہے | شیڈو اینڈ پوائنٹس، غیر متوقع طریقے، غیر متوقع مواد کے اقسام، اور غائب اجازت کے تقاضے |

ڈیفالٹ WAF بھی اس بات کے گرد سخت حدود طے کرتا ہے جس کی وہ جانچ کرتا ہے: 32 KiB کی درخواست ہیڈر، 2,048 بائٹس کا راستہ، اور 1 MiB کا درخواست باڈی۔ یہ حفاظتی حدود ہیں، کسی بھی قسم کی کارکردگی کی غیرمعمولی ترتیبات نہیں۔ اگر کسی ایپلیکیشن کو قانونی طور پر بڑی درخواستوں کی ضرورت ہے تو، متعلقہ حد کو اس ایپلیکیشن کے لیے بڑھائیں اور نتیجہ آزما کر دیکھیں، بجائے اس کے کہ جانچ کو عالمی سطح پر غیر فعال کریں۔

DDoS تحفظ عام موڈ میں 600 درخواستیں فی منٹ پر شروع ہوتا ہے جس کے ساتھ ہر کلائنٹ کی کلید کے لیے 100 اضافی درخواستوں کی اجازت ہے۔ اس کی کلائنٹ-اسٹیٹ جدول 65,536 اندراجات پر محدود ہے۔ یہ قدریں ایک بنیادی معیار ہیں، نہ کہ ایک عالمی ٹریفک ماڈل: ایک پبلک API، ایک ڈاؤن لوڈ سروس، اور ایک داخلی ایڈمن پینل کو ایک ہی ایپلیکیشن مخصوص حدود شیئر نہیں کرنی چاہئیں۔

براؤزر تحفظات بنیادی حصہ ہیں

Webship کی ریسپانس-ہیڈر پالیسی فعال رہتی ہے یہاں تک کہ جب کوئی ایپلیکیشن اپنا ہیڈر شامل کرنا بھول جائے۔ ڈیفالٹ میں شامل ہیں:

• X-Content-Type-Options: nosniff;
• ایک فریم-انکار کرنے والی پالیسی؛
• ریفَرر-پالیسی: کوئی ریفَرر نہیں؛
• ایک سال کے لیے سخت ٹرانسپورٹ سیکیورٹی، ذیلی ڈومینز سمیت؛
• مواد کی حفاظتی پالیسی صرف وہی اصل مواد تک محدود ہے، جس میں فریم اور بنیادی یو آر آئی پر پابندیاں شامل ہیں؛
• اجازتوں کی پالیسی، جیو لوکیشن، مائیکروفون، اور کیمرہ تک رسائی کو غیر فعال کرنا۔

یہ ڈیفالٹس جان بوجھ کر محدود ہیں۔ کسی ایسے ڈومین پر 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 روٹنگ ClientHello SNI پر مبنی ہوتی ہے کیونکہ 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=()"

ایک کثیر المجال سامع (multi-domain listener) پر، unknown_sni = "reject" ایک غیر معروف ہوسٹ نام کو سامع کے ڈیفالٹ سرٹیفکیٹ وصول کرنے سے روک دیتا ہے۔ Webship کے خودکار-TLS سامع پہلے ہی غیر معروف ناموں کو اس وقت تک مسترد کر دیتے ہیں جب تک کہ کوئی سرٹیفکیٹ موجود نہ ہو۔

تصدیق ایک حفاظتی کنٹرول ہے

Webship سننے والوں کو باندھنے سے پہلے ترتیب کی تصدیق کرتا ہے۔ نامعلوم فیلڈز، غلط حدود، نامکمل شناختیں، متصادم سننے والے، اور غیر معاون پروٹوکول کے امتزاج اسٹارٹ اپ میں مخصوص غلطی کے ساتھ ناکام ہو جاتے ہیں۔ ایک ہی تصدیق اس وقت چلتی ہے جب کسی لائیو ترتیب کو نصب کیا جاتا ہے۔ ناکام ری لوڈ موجودہ ترتیب کو فعال چھوڑ دیتا ہے۔

تصدیق شدہ MCP کنفیگریشن کا راستہ ایک اور محافظ شامل کرتا ہے: یہ ایسی لائیو تبدیلیوں کو مسترد کر دیتا ہے جو ایک فعال WAF، DDoS لئیر، API شیلڈ، بوٹ چیلنج، ایج-آتھ پالیسی، یا ریسپانس-ہیڈر لئیر کو غیر فعال کر دیں۔ ورژن چیکس ایک ایڈمنسٹریٹر کو زیادہ نئے کنفیگریشن اسنیپ شاٹ کو اوور رائٹ کرنے سے روکتی ہیں۔ پروسیس-بانڈ سیٹنگز اب بھی ری اسٹارٹ کی ضرورت رکھتی ہیں، اس کے بجائے کہ کسی جزوی لائیو تبدیلی کے کامیاب ہونے کا دکھاوا کیا جائے۔

یہ ایک مفید تمیز ہے۔ محفوظ ڈیفالٹس ایک نئی تنصیب کی حفاظت کرتے ہیں۔ لین دین کی تصدیق اور محفوظ اپڈیٹس چلتی ہوئی تنصیب کی حفاظت کرتے ہیں۔

کون سے آپریٹرز کو ابھی فیصلہ کرنا ہے

انٹرنیٹ پر Webship کو ظاہر کرنے سے پہلے:

1. ایک معتبر TLS شناخت ترتیب دیں اور نجی کلید کی حفاظت کریں۔
2. سننے والے ٹاپولوجی کے لیے نامعلوم SNI ہینڈلنگ سیٹ کریں۔
3. تصدیق کریں کہ HSTS اور مواد-سیکیورٹی-پالیسی ہر ایپلیکیشن اور ذیلی ڈومین سے مطابقت رکھتی ہیں۔
4. API شیلڈ کے اینڈ پوائنٹس، قبول شدہ طریقے، مواد کی اقسام، اور اجازت نامہ کی ضروریات کی تعریف کریں۔
5. صرف عالمی بنیادی حد پر انحصار کرنے کے بجائے راستہ مخصوص حد رفتار شامل کریں۔
6. محفوظ شدہ میزبانوں یا راستوں کے لیے ایج تصدیق کو فعال کریں اور مختصر مدت کے ٹوکن استعمال کریں۔
7. MCP اور مشاہداتی سننے والوں کو نجی، مستند، اور عوامی ٹریفک سے الگ رکھیں۔
8. Webship کو ایک مخصوص غیر مراعات یافتہ اکاؤنٹ کے ساتھ چلائیں، جہاں ممکن ہو ایک صرف پڑھنے کے قابل ایپلیکیشن روٹ، اور صرف وہی آپریٹنگ سسٹم کی صلاحیتیں استعمال کریں جن کی اسے ضرورت ہے۔
9. رول آؤٹ سے پہلے کنفیگریشن کی تصدیق کریں، پھر کینری ماحول میں بلاک شدہ اور اجازت شدہ ٹریفک کا ٹیسٹ کریں۔
10. سیکورٹی آڈٹ ایونٹس کی نگرانی کریں اور معمول کے موڈ سے under_attack یا lockdown میں سوئچ کرنے کی مشق کریں۔

ایک محفوظ ڈیفالٹ آغاز ہے، دعویٰ نہیں

کوئی بھی ویب سرور یہ فیصلہ نہیں کر سکتا کہ کون سے صارفین آپ کے انوائسز دیکھیں، کون سے ماخذ آپ کے API کو کال کر سکتے ہیں، یا آپ کے کاروباری اینڈ پوائنٹ کو درخواستیں کتنی جلدی قبول کرنی چاہئیں۔ ان کنٹرولز کے لیے ایپلیکیشن کا علم ضروری ہے۔

Webship نچلی سطح فراہم کرتا ہے: محدود پارسرز، سخت ترتیب، حفاظتی جواب کے ہیڈرز، درخواست کی جانچ، بدسلوکی کے کنٹرولز، اور بند اختیاری سطحیں۔ نتیجہ یہ نہیں کہ “سیکیورٹی حل ہو گئی۔” یہ ایک چھوٹا فرق ہے سرور نصب کرنے اور اسے ذمہ داری کے ساتھ چلانے کے درمیان۔

پیداوری تعیناتی سے قبل مکمل Webship دستاویزات کا جائزہ لیں۔ کنفیگریشن اسکیمہ اور چلنے والی بائنری درستگی کے لیے وہ مستند ذرائع ہیں جو آپ جس مخصوص ورژن کو چلا رہے ہیں اس کی وضاحت کرتے ہیں۔