Înapoi la blogul Webship

Inginerie Webship

Webship Server Web: Setări Sigure Implicit

Webship activează în mod implicit principalele sale protecții HTTP, limitele de resurse și protecțiile răspunsurilor, păstrând în același timp suprafețele de control opționale private sau dezactivate. Iată lista de bază și lista de verificare pentru producție.

# Webship Server Web: Setări Sigure Implicit

Un server web sigur nu ar trebui să depindă de faptul că un operator își amintește încă o setare la ora 2 dimineața. Ar trebui să înceapă de la un punct de referință protector, să respingă configurațiile nesigure și să necesite alegeri deliberate înainte de a expune capabilități sensibile.

Acesta este modelul din spatele Webship. Configurația sa implicită activează principalele apărare pentru cereri și răspunsuri, limitează resursele pe care un atacator le poate consuma și lasă suprafețele de control opționale dezactivate. Puteți ajusta aceste valori implicite pentru o aplicație reală, dar nu trebuie să descoperiți fiecare protecție înainte ca prima cerere să sosească.

Securizarea implicită nu înseamnă securitate fără context. Certificatele, autorizarea aplicațiilor, politica de rețea, secretele și răspunsul la incidente aparțin în continuare operatorului. Rolul Webship este să facă punctul de pornire sigur evident — și să facă mai dificilă slăbirea accidentală.

Protecțiile care pornesc activate

Webship permite șase straturi în configurația sa de bază:

| Strat | Comportament implicit | Ce reduce | | --- | --- | --- | | Protecția fișierelor dot | Refuză segmente de cale statică prefixate cu dot | Expunere accidentală a fișierelor de mediu, metadatelor depozitului și configurației locale | | Firewall pentru aplicații web | Blochează tiparele de atac cunoscute | Injecție SQL, cross-site scripting, traversări, teste ale căilor sensibile, injecție de comenzi, contrabandă de anteturi și codificări de cereri neacceptate | | Controale DDoS | Rulează în modul normal cu starea clientului limitată | Inundații de cereri, urmărire nelimitată și epuizare evitabilă a resurselor | | Provocare bot | Folosește un cookie de provocare semnat | Abuz automatizat și scanare repetată cu cost redus | | Antete de securitate pentru răspuns | Adaugă o politică restrictivă a browser-ului | Confuzie MIME, încadrare (framing), scurgerea referer-ului, capabilități periculoase ale browser-ului și încărcarea largă de conținut | | API Shield | Folosește modul blocare și respinge rutele necunoscute odată ce un contract API este definit | Endpoint-uri fantomă, metode neintenționate, tipuri de conținut neașteptate și cerințe de autorizare lipsă |

WAF-ul implicit stabilește, de asemenea, limite stricte pentru ceea ce inspectează: 32 KiB pentru anteturile cererii, un traseu de 2.048 de octeți și un corp al cererii de 1 MiB. Acestea sunt limite de securitate, nu comutatoare arbitrare de performanță. Dacă o aplicație are nevoie în mod legitim de cereri mai mari, crește limita relevantă pentru acea aplicație și testează rezultatul în loc să dezactivezi inspecția la nivel global.

Protecția DDoS începe în modul normal la 600 de cereri pe minut cu o permitir de vârf de 100 pe cheia clientului. Tabelul său de stare a clientului este limitat la 65.536 de intrări. Aceste valori sunt un reper, nu un model universal de trafic: o API publică, un serviciu de descărcare și un panou de administrare intern nu ar trebui să împartă aceleași limite specifice aplicației.

Protecțiile browserului fac parte din baza de referință

Politica de antet de răspuns a Webship este activată chiar și atunci când o aplicație uită să adauge propria sa. Implicit include:

  • X-Content-Type-Options: nosniff;
  • o politică de refuz al încadrării;
  • Politica de referință: fără referință;
  • Strict-Transport-Security pentru un an, inclusiv subdomenii;
  • Politica de Securitate a Conținutului limitată la conținut din aceeași origine, cu restricții de încadrare și URI de bază;
  • Politica de permisiuni dezactivează accesul la geolocalizare, microfon și cameră.

Aceste setări implicite sunt intenționat restrictive. Revizuiește HSTS înainte de a-l aplica unui domeniu cu subdomenii care nu sunt complet pregătite pentru HTTPS. Revizuiește Content-Security-Policy înainte ca o aplicație să încarce scripturi, stiluri, fonturi, imagini sau conexiuni de la alte origini. O setare implicită sigură ar trebui să eșueze vizibil în timpul implementării, nu să fie slăbită silențios în producție.

Suprafețele opționale rămân închise

Webship nu expune toate funcțiile doar pentru că binarul le conține. Proxy-ul invers, WebTransport, endpoint-urile de observabilitate, TLS automat, proveniența răspunsului și endpoint-ul de control MCP sunt dezactivate implicit.

Punctul final MCP are domeniul de tip loopback atunci când este activat și necesită o configurație de securitate explicită. Metricile și statisticile necesită ca instrumentarea să fie activată în mod deliberat. Gestionarea automată a certificatelor necesită ca operatorul să aleagă un director ACME, contacte, stocare și acceptarea termenilor de serviciu. Aceasta împiedică ca funcțiile operaționale să devină suprafețe de rețea neașteptate.

Ascultătorul de bază se leagă, de asemenea, la 127.0.0.1. Un operator trebuie să selecteze în mod explicit o adresă publică. Acea alegere unică creează un punct util de revizuire pentru regulile firewall-ului, permisiunile serviciului, identitatea TLS și topologia de implementare.

Proxy-ul invers păstrează limita de încredere

Când proxy-ul invers este activat, trecerea prin TLS rămâne implicită. Webship redirecționează traficul criptat fără a prelua textul clar al aplicației sau cheile de sesiune active. Originea rămâne responsabilă pentru TLS și protocolul negociat.

Activează terminarea TLS doar atunci când Webship trebuie să inspecteze cererile HTTP, să direcționeze după cale, să aplice politica WAF și API, să rescrie anteturile sau să memoreze răspunsurile în cache. Terminarea nu este în mod inerent mai puțin sigură; aceasta mută limita de încredere. Decizia importantă este care mașină are voie să vadă textul necriptat și de ce.

Trecerile prin tunel au și limite funcționale. Rutarea TCP se bazează pe ClientHello SNI deoarece cererea HTTP este criptată. Trecerea prin tunel HTTP/3 necesită ca rutele să împartă un singur origin UDP. Dacă aveți nevoie de securitate conștientă de conținut la margine, terminați TLS acolo și protejați separat hop-ul de la margine la origin.

O bază de producție pe care o poți revizui

Exemplul următor face ca valorile implicite importante să fie explicite în loc să se bazeze pe omisiune:

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=()"

Pe un ascultător multi-domeniu, unknown_sni = "reject" împiedică un nume de gazdă necunoscut să primească certificatul implicit al ascultătorului. Ascultătorii cu TLS automat ai Webship deja refuză numele necunoscute până când există un certificat.

Validarea este un control de securitate

Webship validează configurația înainte de a lega ascultătorii. Câmpurile necunoscute, limitele invalide, identitățile incomplete, ascultătorii în conflict și combinațiile de protocoale neacceptate duc la eșecul pornirii cu o eroare specifică. Aceeași validare rulează înainte ca o configurație activă să fie instalată. O reîncărcare eșuată lasă configurația curentă activă.

Calea de configurare autentificată MCP adaugă o altă protecție: refuză modificările live care ar dezactiva un WAF activ, un strat DDoS, API Shield, provocarea botului, politica de autentificare la margine sau stratul de antet al răspunsului. Verificările de versiune împiedică un administrator să suprascrie un snapshot de configurație mai nou. Setările legate de proces necesită în continuare o repornire în loc să pretindă că o modificare parțială live a reușit.

Aceasta este o distincție utilă. Setările implicite sigure protejează o implementare nouă. Validarea tranzacțională și actualizările protejate protejează una aflată în funcțiune.

Ce operatori mai trebuie să decidă

Înainte de a expune Webship pe internet:

  1. Configurează o identitate TLS de încredere și protejează cheia privată.
  2. Setați gestionarea SNI necunoscut pentru topologia ascultătorului.
  3. Confirmați că HSTS și Content-Security-Policy corespund fiecărei aplicații și subdomeniu.
  4. Definește endpoint-urile API Shield, metodele acceptate, tipurile de conținut și cerințele de autorizare.
  5. Adăugați limite de rată specifice rutei în loc să vă bazați doar pe baza globală.
  6. Activează autentificarea la margine pentru gazdele sau căile protejate și folosește tokenuri cu durată scurtă de viață.
  7. Păstrează MCP și ascultătorii de observabilitate privați, autentificați și separați de traficul public.
  8. Rulează Webship cu un cont dedicat fără privilegii, un root al aplicației doar pentru citire acolo unde este posibil și doar cu capabilitățile sistemului de operare de care are nevoie.
  9. Validați configurația înainte de implementare, apoi testați traficul blocat și permis într-un mediu canar.
  10. Monitorizați evenimentele de audit de securitate și exersați trecerea de la modul normal la modul sub atac sau izolare.

Un punct de plecare mai sigur este un început, nu o pretenție

Niciun server web nu poate decide care utilizatori ar trebui să vadă facturile tale, ce origini pot apela API-ul tău sau cât de repede ar trebui să accepte punctul tău final de afaceri cererile. Aceste controale necesită cunoștințe despre aplicație.

Webship furnizează stratul inferior: analizatoare limitate, configurare strictă, antete de răspuns defensive, inspectarea cererilor, controale împotriva abuzului și suprafețe opționale închise. Rezultatul nu este „securitatea rezolvată”. Este un decalaj mai mic între instalarea unui server și operarea lui responsabilă.

Revizuiți documentația completă Webship înainte de implementarea în producție. Schema de configurare și binarul executabil rămân sursele autoritare pentru versiunea exactă pe care o utilizați.