# Webship Pelayan Web: Tetapan Selamat Secara Lalai
Pelayan web yang selamat tidak seharusnya bergantung kepada pengendali untuk mengingati satu lagi tetapan pada pukul 2 pagi. Ia sepatutnya bermula dari asas perlindungan, menolak konfigurasi yang tidak selamat, dan memerlukan pilihan yang sengaja sebelum mendedahkan keupayaan sensitif.
Itu adalah model di sebalik Webship. Konfigurasi lalainya menghidupkan pertahanan utama permintaan dan tindak balas, mengehadkan sumber yang boleh digunakan oleh penyerang, dan meninggalkan permukaan kawalan pilihan dalam keadaan tidak diaktifkan. Anda boleh menyesuaikan lalai tersebut untuk aplikasi sebenar, tetapi anda tidak perlu menemui setiap perlindungan sebelum permintaan pertama tiba.
Selamat secara lalai tidak bermaksud selamat tanpa konteks. Sijil, kebenaran aplikasi, dasar rangkaian, rahsia, dan tindak balas insiden masih menjadi tanggungjawab pengendali. Tugas Webship ialah menjadikan titik permulaan yang selamat jelas—dan menjadikan pengurangan keselamatan secara tidak sengaja lebih sukar.
Perlindungan yang mula diaktifkan
Webship membolehkan enam lapisan dalam konfigurasi asasnya:
| Lapisan | Tingkah laku lalai | Apa yang dikurangkan | | --- | --- | --- | | Perlindungan fail titik | Menolak segmen laluan statik yang diawali titik | Pendedahan tidak sengaja fail persekitaran, metadata repositori, dan konfigurasi tempatan | | Firewall aplikasi web | Menghalang corak serangan yang diketahui | Suntikan SQL, skrip silang tapak (cross-site scripting), traversal, pemeriksaan laluan sensitif, suntikan arahan, penyeludupan tajuk, dan pengekodan permintaan yang tidak disokong | | Kawalan DDoS | Berjalan dalam mod biasa dengan keadaan pelanggan yang terhad | Banjir permintaan, penjejakan tanpa had, dan keletihan sumber yang boleh dielakkan | | Cabaran bot | Menggunakan kuki cabaran yang ditandatangani | Penyalahgunaan automatik kos rendah dan pengimbasan berulang | | Header keselamatan respons | Menambah dasar penyemak imbas yang tegar | Kekeliruan MIME, pembingkaian, kebocoran perujuk, kebolehan penyemak imbas berbahaya, dan pemuatan kandungan yang luas | | Perisai API | Menggunakan mod blok dan menolak laluan tidak dikenali setelah kontrak API ditentukan | Titik akhir bayangan, kaedah yang tidak dimaksudkan, jenis kandungan yang tidak dijangka, dan keperluan kebenaran yang hilang |
WAF lalai juga meletakkan had ketat terhadap apa yang diperiksa: 32 KiB bagi header permintaan, laluan 2,048 bait, dan badan permintaan 1 MiB. Ini adalah had keselamatan, bukan suis prestasi sewenang-wenangnya. Jika sesebuah aplikasi benar-benar memerlukan permintaan yang lebih besar, naikkan had yang berkaitan untuk aplikasi tersebut dan uji hasilnya daripada mematikan pemeriksaan secara global.
Perlindungan DDoS bermula dalam mod normal pada 600 permintaan setiap minit dengan kebenaran ledakan sebanyak 100 setiap kunci klien. Jadual keadaan kliennya dibatasi pada 65,536 entri. Nilai ini adalah garis asas, bukan model trafik universal: API awam, perkhidmatan muat turun, dan panel pentadbir dalaman tidak seharusnya berkongsi had khusus aplikasi yang sama.
Perlindungan pelayar adalah sebahagian daripada garis asas
Polisi pengepala respons Webship diaktifkan walaupun aplikasi terlupa untuk menambah miliknya sendiri. Default termasuk:
- X-Content-Type-Options: nosniff;
- dasar menolak bingkai;
- Polisi-Penghantar: tiada-penghantar;
- Keselamatan Pengangkutan Ketat selama satu tahun, termasuk subdomain;
- Dasar Keselamatan Kandungan terhad kepada kandungan asal yang sama, dengan sekatan bingkai dan URI asas;
- Dasar-Kebenaran mematikan akses geolokasi, mikrofon, dan kamera.
Tetapan lalai ini sengaja bersifat terhad. Semak HSTS sebelum menggunakannya pada domain dengan subdomain yang tidak sepenuhnya sedia HTTPS. Semak Polisi Keselamatan Kandungan sebelum aplikasi memuatkan skrip, gaya, fon, imej, atau sambungan dari asal lain. Lalai yang selamat harus gagal dengan jelas semasa pelaksanaan, bukan dilemahkan secara diam-diam dalam pengeluaran.
Permukaan pilihan tetap tertutup
Webship tidak mendedahkan setiap ciri hanya kerana binari mengandungi ciri tersebut. Pemproksian terbalik, WebTransport, titik akhir keterlihatan, TLS automatik, asal usul respons, dan titik akhir kawalan MCP dilumpuhkan secara lalai.
Titik akhir MCP mempunyai skop loopback apabila diaktifkan dan memerlukan konfigurasi keselamatan yang jelas. Metik dan statistik memerlukan instrumentasi untuk diaktifkan dengan sengaja. Pengurusan sijil automatik memerlukan pengendali memilih direktori ACME, kontak, penyimpanan, dan penerimaan terma perkhidmatan. Ini memastikan ciri operasi tidak menjadi permukaan rangkaian yang mengejutkan.
Pendengar asas juga mengikat ke 127.0.0.1. Seorang pengendali mesti secara jelas memilih alamat awam. Pilihan tunggal itu mewujudkan titik semakan yang berguna untuk peraturan firewall, kebenaran perkhidmatan, identiti TLS, dan topologi penyebaran.
Penerusan proksi terbalik mengekalkan sempadan kepercayaan
Apabila pemproksian terbalik diaktifkan, pemindahan TLS kekal sebagai tetapan lalai. Webship meneruskan trafik yang disulitkan tanpa mengambil hak milik teks jelas aplikasi atau kunci sesi aktif. Asal masih bertanggungjawab terhadap TLS dan protokol yang dipersetujui.
Dayakan penamatan TLS hanya apabila Webship mesti memeriksa permintaan HTTP, menghala mengikut laluan, menerapkan dasar WAF dan API, menulis semula tajuk, atau menyimpan jawapan dalam cache. Penamatan tidak semestinya kurang selamat; ia mengalihkan sempadan kepercayaan. Keputusan yang penting ialah mesin mana yang dibenarkan melihat teks biasa dan mengapa.
Pass-through juga mempunyai had fungsi. Penghalaan TCP berdasarkan ClientHello SNI kerana permintaan HTTP dienkripsi. HTTP/3 pass-through memerlukan laluan berkongsi satu asal UDP. Jika anda memerlukan keselamatan yang peka kandungan di tepi, hentikan TLS di situ dan lindungi laluan tepi-ke-asal secara berasingan.
Garis asas pengeluaran yang boleh anda semak
Petikan berikut menjelaskan penetapan lalai yang penting secara nyata daripada bergantung kepada pengabaian:
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=()"Pada pendengar multi-domain, unknown_sni = "reject" menghalang nama hos yang tidak dikenali daripada menerima sijil lalai pendengar tersebut. Pendengar automatic-TLS Webship sudah menolak nama yang tidak dikenali sehingga sijil wujud.
Pengesahan adalah kawalan keselamatan
Webship mengesahkan konfigurasi sebelum ia mengikat pendengar. Medan yang tidak dikenali, had yang tidak sah, identiti yang tidak lengkap, pendengar yang bertembung, dan gabungan protokol yang tidak disokong akan menyebabkan permulaan gagal dengan ralat tertentu. Pengesahan yang sama dijalankan sebelum konfigurasi langsung dipasang. Muat semula yang gagal akan meninggalkan konfigurasi semasa tetap aktif.
Path konfigurasi MCP yang disahkan menambah satu lagi pengawal: ia menolak perubahan langsung yang akan mematikan WAF aktif, lapisan DDoS, API Shield, cabaran bot, polisi edge-auth, atau lapisan tajuk-respons. Semakan versi menghalang seorang pentadbir menulis semula snapshot konfigurasi yang lebih baru. Tetapan yang terikat kepada proses masih memerlukan penetapan semula dan bukannya berpura-pura bahawa perubahan langsung sebahagian berjaya.
Ini adalah perbezaan yang berguna. Tetapan lalai yang selamat melindungi pengedaran baru. Pengesahan transaksi dan kemas kini yang dijaga melindungi pengedaran yang sedang berjalan.
Apakah pengendali masih perlu membuat keputusan
Sebelum mendedahkan Webship kepada internet:
- Konfigurasikan identiti TLS yang dipercayai dan lindungi kunci peribadi.
- Tetapkan pengendalian SNI yang tidak diketahui untuk topologi pendengar.
- Sahkan bahawa HSTS dan Polisi Keselamatan Kandungan sepadan dengan setiap aplikasi dan subdomain.
- Tentukan titik akhir API Shield, kaedah yang diterima, jenis kandungan, dan keperluan kebenaran.
- Tambahkan had kadar khusus laluan dan bukannya hanya bergantung pada garis dasar global.
- Dayakan pengesahan tepi untuk hos atau laluan yang dilindungi dan gunakan token jangka pendek.
- Pastikan MCP dan pendengar kebolehlihatan dijaga secara peribadi, diautentikasi, dan dipisahkan daripada trafik awam.
- Jalankan Webship dengan akaun khusus tanpa keistimewaan, root aplikasi hanya baca jika boleh, dan hanya menggunakan keupayaan sistem operasi yang diperlukan.
- Sahkan konfigurasi sebelum pelaksanaan, kemudian uji trafik yang disekat dan dibenarkan dalam persekitaran canary.
- Memantau acara audit keselamatan dan berlatih menukar daripada mod normal kepada mod serangan atau sekatan.
Pilihan lalai yang lebih selamat adalah permulaan, bukan satu tuntutan
Tiada pelayan web yang dapat menentukan pengguna mana yang patut melihat invois anda, asal mana yang boleh memanggil API anda, atau seberapa cepat titik akhir perniagaan anda harus menerima permintaan. Kawalan tersebut memerlukan pengetahuan aplikasi.
Webship membekalkan lapisan bawah: penganalisis terhad, konfigurasi ketat, pengepala tindak balas defensif, pemeriksaan permintaan, kawalan penyalahgunaan, dan permukaan pilihan tertutup. Hasilnya bukanlah “keselamatan diselesaikan.” Ia adalah jurang yang lebih kecil antara memasang pelayan dan mengoperasikannya dengan bertanggungjawab.
Semak Webship dokumentasi sepenuhnya sebelum pengeluaran produksi. Skema konfigurasi dan binari yang sedang berjalan kekal sebagai sumber yang sahih untuk versi tepat yang anda jalankan.