# Webship Web Server: Ligtas na Mga Setting sa Default
Ang isang ligtas na web server ay hindi dapat umasa sa operator na maalala ang isa pang setting sa alas-2 ng umaga. Dapat itong magsimula mula sa isang protektadong baseline, tanggihan ang hindi ligtas na configuration, at mangailangan ng sinasadyang pagpili bago ito ilantad ang mga sensitibong kakayahan.
Iyan ang modelo sa likod ng Webship. Ang default na konfigurasyon nito ay nagbubukas ng pangunahing depensa sa kahilingan at tugon, nililimitahan ang mga resource na maaaring gamitin ng isang umaatake, at ipinapanatiling naka-disable ang mga opsyonal na kontrol na ibabaw. Maaari mong i-tune ang mga default na ito para sa isang totoong aplikasyon, ngunit hindi mo kailangang matuklasan ang bawat proteksyon bago dumating ang unang kahilingan.
Ang 'Secure by default' ay hindi nangangahulugang ligtas nang walang konteksto. Ang mga sertipiko, awtorisasyon ng aplikasyon, patakaran sa network, mga lihim, at tugon sa insidente ay nananatili pa rin na responsibilidad ng operator. Ang trabaho ng Webship ay gawing malinaw ang ligtas na panimulang punto—at gawing mas mahirap ang aksidenteng pagpapahina.
Ang mga proteksyon na nagsisimula na naka-enable
Webship nagpapagana ng anim na layer sa kanyang pangunahing configuration:
| Patong | Karaniwang asal | Kung ano ang binabawasan nito | | --- | --- | --- | | Proteksyon sa dot-file | Ipinagbabawal ang mga static path segments na may prefix na tuldok | Di-sinasadyang paglantad ng mga environment file, metadata ng repository, at lokal na konfigurasyon | | Web application firewall | Humaharang sa mga kilalang pattern ng atake | SQL injection, cross-site scripting, traversal, sensitive-path probes, command injection, header smuggling, at mga hindi suportadong pag-encode ng kahilingan | | Mga kontrol sa DDoS | Tumakbo sa normal na mode na may limitadong estado ng kliyente | Pagbaha ng mga kahilingan, walang limitasyong pagsubaybay, at maiiwasang pagkaubos ng mapagkukunan | | Hamon sa Bot | Gumagamit ng nilagdaang cookie ng hamon | Mababang-gastusing awtomatikong pang-aabuso at paulit-ulit na pag-scan | | Mga header ng seguridad ng tugon | Nagdaragdag ng mahigpit na patakaran sa browser | Pagkalito sa MIME, pagsasagawa ng framing, pagtagas ng referrer, mapanganib na kakayahan ng browser, at malawak na pag-load ng nilalaman | | API Shield | Gumagamit ng block mode at tinatanggihan ang mga hindi kilalang ruta kapag naitakda na ang kontrata ng API | Mga shadow na endpoints, hindi sinasadyang mga pamamaraan, hindi inaasahang mga uri ng nilalaman, at nawawalang mga kinakailangan sa awtorisasyon |
Ang default na WAF ay naglalagay din ng mahigpit na hangganan sa kung ano ang sinusuri nito: 32 KiB ng mga header ng kahilingan, isang 2,048-byte na path, at isang 1 MiB na katawan ng kahilingan. Ito ay mga limitasyon sa seguridad, hindi mga pabago-bagong switch para sa pagganap. Kung ang isang aplikasyon ay tunay na nangangailangan ng mas malalaking kahilingan, itaas ang kaukulang limitasyon para sa aplikasyon na iyon at subukan ang resulta sa halip na huwag paganahin ang pagsusuri sa kabuuan.
Nagsisimula ang proteksyon laban sa DDoS sa normal na mode sa 600 na kahilingan bawat minuto na may pahintulot na pag-burst na 100 bawat client key. Ang client-state table nito ay limitado sa 65,536 na mga entry. Ang mga halagang ito ay isang baseline, hindi isang pangkalahatang modelo ng trapiko: ang isang pampublikong API, isang download service, at isang internal na admin panel ay hindi dapat magbahagi ng parehong mga limitasyong tiyak sa aplikasyon.
Ang mga proteksyon ng browser ay bahagi ng batayang pamantayan
Pinapagana ang patakaran sa response-header ng Webship kahit na makalimutan ng isang aplikasyon na idagdag ang sarili nito. Kasama sa default ang:
- X-Content-Type-Options: nosniff;
- isang patakarang pagtanggi sa frame;
- Patakaran-sa-Tagapagpahiwatig: walang-tagapagpahiwatig;
- Striktong Seguridad sa Transportasyon sa loob ng isang taon, kasama ang mga subdomain;
- Patakaran sa Seguridad ng Nilalaman na limitado sa nilalaman mula sa parehong pinagmulan, na may mga paghihigpit sa pag-frame at base-URI;
- Patakaran sa Pahintulot na nagpapahinto sa pag-access ng geolocation, mikropono, at kamera.
Sadyang mahigpit ang mga default na ito. Suriin ang HSTS bago ito ilapat sa isang domain na may mga subdomain na hindi pa ganap na handa para sa HTTPS. Suriin ang Content-Security-Policy bago mag-load ang isang aplikasyon ng mga script, estilo, font, larawan, o koneksyon mula sa ibang pinagmulan. Ang isang ligtas na default ay dapat magpakita ng mali sa panahon ng deployment, hindi tahimik na pinahina sa production.
Mananatiling nakasara ang mga opsyonal na ibabaw
Webship ay hindi ipapakita ang bawat tampok kahit na kasama ito sa binary. Ang reverse proxying, WebTransport, observability endpoints, automatic TLS, response provenance, at ang MCP control endpoint ay naka-disable bilang default.
Ang MCP na endpoint ay may loopback-scope kapag pinagana at nangangailangan ng tahasang konfigurasyon ng seguridad. Ang mga metriko at estadistika ay nangangailangan ng instrumental na sinadyang pinagana. Ang awtomatikong pamamahala ng sertipiko ay nangangailangan na pumili ang operator ng directory ng ACME, mga kontak, imbakan, at pagtanggap sa mga tuntunin ng serbisyo. Pinipigilan nito na ang mga operasyonal na tampok ay maging mga hindi inaasahang network surface.
Ang pangunahing tagapakinig ay nakakabit din sa 127.0.0.1. Ang isang operator ay kailangang tahasang pumili ng isang pampublikong address. Ang nag-iisang pagpiling iyon ay lumilikha ng isang kapaki-pakinabang na punto ng pagsusuri para sa mga patakaran ng firewall, mga pahintulot ng serbisyo, pagkakakilanlan ng TLS, at topolohiya ng deployment.
Ang reverse proxying ay pinapanatili ang hangganan ng tiwala
Kapag pinagana ang reverse proxying, nananatiling default ang TLS pass-through. Webship ay nagpapasa ng naka-encrypt na trapiko nang hindi iniingatan ang plaintext ng application o aktibong session keys. Ang pinagmulan ay nananatiling responsable para sa TLS at sa napagkasunduang protocol.
Paganahin ang TLS termination lamang kapag kinakailangang suriin ng Webship ang mga HTTP request, i-route ayon sa path, magpatupad ng WAF at patakaran sa API, i-rewrite ang mga header, o i-cache ang mga tugon. Ang termination ay hindi likas na mas hindi ligtas; inilipat nito ang hangganan ng tiwala. Ang mahalagang desisyon ay kung aling makina ang pinapayagang makita ang plaintext at bakit.
Mayroong ring mga limitasyon sa pagdaan ang pass-through. Ang TCP routing ay batay sa ClientHello SNI dahil ang HTTP request ay naka-encrypt. Ang pass-through ng HTTP/3 ay nangangailangan ng mga ruta na magbahagi ng isang UDP origin. Kung kailangan mo ng content-aware security sa gilid, tapusin ang TLS doon at protektahan ang edge-to-origin na hakbang nang hiwalay.
Isang batayang produksyon na maaari mong suriin
Ang sumusunod na sipi ay nagpapakita ng mahahalagang default nang tahasan sa halip na umasa sa pagpapaliban:
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=()"Sa isang multi-domain na tagapakinig, ang unknown_sni = "reject" ay pumipigil sa isang hindi kilalang hostname na makatanggap ng default na sertipiko ng tagapakinig. Ang mga automatic-TLS listener ng Webship ay awtomatikong tinatanggihan ang mga hindi kilalang pangalan hanggang sa magkaroon ng sertipiko.
Ang pagpapatunay ay isang kontrol sa seguridad
Webship ay sinusuri ang configuration bago nito ipatali ang mga listener. Ang mga hindi kilalang field, invalid na limitasyon, hindi kumpletong pagkakakilanlan, nagkakasalungat na listener, at hindi suportadong kumbinasyon ng protocol ay magdudulot ng error sa pagsisimula. Ang parehong pagsusuri ay isinasagawa bago ipatupad ang isang live na configuration. Ang nabigong reload ay nag-iiwan sa kasalukuyang configuration na aktibo.
Ang na-authenticate na MCP na configuration path ay nagdadagdag ng isa pang proteksyon: tinatanggihan nito ang mga direktang pagbabago na magpapahina sa aktibong WAF, DDoS layer, API Shield, bot challenge, edge-auth policy, o response-header layer. Pinipigilan ng version checks ang isang administrator na ma-overwrite ang mas bagong configuration snapshot. Ang mga process-bound na setting ay nangangailangan pa rin ng restart sa halip na magkunwaring matagumpay ang isang partial na live change.
Ito ay isang kapaki-pakinabang na pagkakaiba. Pinoprotektahan ng ligtas na mga default ang isang bagong deployment. Pinoprotektahan ng transactional na pagsusuri at guwardiyang mga pag-update ang isang tumatakbong deployment.
Ano ang mga operator na kailangan pang magpasiya
Bago ilantad ang Webship sa internet:
- I-configure ang isang pinagkakatiwalaang TLS na pagkakakilanlan at protektahan ang pribadong susi.
- Itakda ang unknown SNI handling para sa listener topology.
- Kumpirmahin na ang HSTS at Content-Security-Policy ay tugma sa bawat aplikasyon at subdomain.
- Tukuyin ang mga endpoint ng API Shield, mga tinatanggap na pamamaraan, mga uri ng nilalaman, at mga hinihinging awtorisasyon.
- Magdagdag ng mga limitasyon sa rate para sa bawat ruta sa halip na umasa lamang sa pangkalahatang baseline.
- Paganahin ang pagpapatunay sa gilid para sa mga protektadong host o landas at gumamit ng mga panandaliang token.
- Panatilihing pribado, may awtentikasyon, at hiwalay sa pampublikong trapiko ang MCP at mga tagapakinig ng obserbasyon.
- Patakbuhin ang Webship gamit ang isang nakatalagang account na walang pribilehiyo, isang read-only na ugat ng aplikasyon kung maaari, at tanging ang mga kakayahan ng operating system na kailangan nito.
- Patunayan ang konfigurasyon bago ang rollout, pagkatapos subukan ang naka-block at pinapayagang trapiko sa isang canary na kapaligiran.
- Subaybayan ang mga kaganapan sa seguridad na audit at magsanay sa paglilipat mula sa normal na mode patungo sa under_attack o lockdown.
Ang isang mas ligtas na default ay isang simula, hindi isang paghahabol
Walang web server ang maaaring magpasya kung aling mga gumagamit ang dapat makakita ng iyong mga invoice, kung aling mga pinagmulan ang maaaring tumawag sa iyong API, o kung gaano kabilis dapat tanggapin ng iyong business endpoint ang mga kahilingan. Ang mga kontrol na iyon ay nangangailangan ng kaalaman sa aplikasyon.
Webship ay nagbibigay ng mas mababang layer: mga bounded parser, mahigpit na configuration, mapanagutang response headers, pagsusuri ng request, kontrol sa pang-aabuso, at saradong opsyonal na mga surface. Ang resulta ay hindi “nalutas ang seguridad.” Ito ay isang mas maliit na puwang sa pagitan ng pag-install ng server at ang responsableng pagpapatakbo nito.
Suriin ang kumpletong Webship dokumentasyon bago ang deployment sa produksyon. Ang configuration schema at ang tumatakbong binary ay nananatiling mga awtoritatibong pinagmulan para sa eksaktong bersyon na iyong ginagamit.