Vissza a Webship bloghoz

Webship mérnöki munka

Webship Webszerver: Alapértelmezett biztonsági beállítások

Webship alapértelmezés szerint engedélyezi a fő HTTP-védelmeit, az erőforrás-korlátokat és a válaszvédelmeket, miközben az opcionális vezérlőfelületeket privátban tartja vagy kikapcsolja. Íme az alapértelmezett beállítás és a termelési ellenőrzőlista.

# Webship Webszerver: Alapértelmezett biztonságos beállítások

Egy biztonságos webszervernek nem szabad attól függnie, hogy az üzemeltető éjjel 2-kor emlékezzen még egy beállításra. Védekező alapállásból kell kiindulnia, el kell utasítania a nem biztonságos konfigurációt, és tudatos döntéseket kell megkövetelnie, mielőtt érzékeny funkciókat tesz elérhetővé.

Ez a modell áll a Webship mögött. Alapértelmezett konfigurációja bekapcsolja a fő kérés- és válaszvédelmi mechanizmusokat, korlátozza a támadó által felhasználható erőforrásokat, és az opcionális vezérlőfelületeket letiltva hagyja. Ezeket az alapértelmezett beállításokat egy valós alkalmazáshoz finomhangolhatja, de nem szükséges minden védelmet felfedeznie, mielőtt megérkezik az első kérés.

Az alapértelmezett biztonság nem jelenti azt, hogy kontextus nélkül biztonságos. A tanúsítványok, az alkalmazásengedélyezés, a hálózati szabályzat, a titkok és az incidenskezelés továbbra is az üzemeltető feladata. A Webship feladata, hogy a biztonságos kiindulópontot egyértelművé tegye—és megnehezítse a véletlen gyengítést.

Azok a védelmek, amelyek engedélyezve kezdődnek

Webship alapértelmezett konfigurációjában hat réteget engedélyez:

| Réteg | Alapértelmezett viselkedés | Mit csökkent | | --- | --- | --- | | Dot-fájl védelem | Megtagadja a ponttal kezdődő statikus útvonal szegmenseket | A környezeti fájlok, a tároló metaadatai és a helyi konfiguráció véletlen kiszolgáltatása | | Webalkalmazás-tűzfal | Blokkolja a ismert támadási mintákat | SQL injekció, cross-site scripting, traversal, érzékeny útvonal vizsgálatok, parancs injekció, fejléc csempészés és nem támogatott kérés kódolások | | DDoS-vezérlés | Normál módban fut, korlátozott kliensállapottal | Kéréshullámok, korlátlan nyomon követés és elkerülhető erőforrás-kimerülés | | Bot kihívás | Aláírt kihívás sütit használ | Olcsó automatizált visszaélés és ismételt vizsgálat | | Válasz biztonsági fejlécek | Szigorú böngészőpolitika hozzáadása | MIME zavar, keretezés, hivatkozó szivárgás, veszélyes böngésző funkciók és széles tartalombetöltés | | API Shield | Blokkmódot használ, és elutasítja az ismeretlen útvonalakat, miután egy API-szerződés definiálva lett | Árnyék végpontok, nem kívánt módszerek, váratlan tartalomtípusok és hiányzó hitelesítési követelmények |

Az alapértelmezett WAF szintén szigorú határokat állít arra, amit ellenőriz: 32 KiB kérésfejléc, 2 048 bájtos útvonal és 1 MiB kérés-törzs. Ezek biztonsági korlátok, nem önkényes teljesítménykapcsolók. Ha egy alkalmazásnak jogosan nagyobb kérésekre van szüksége, emelje meg a releváns határt az adott alkalmazásnál, és tesztelje az eredményt ahelyett, hogy globálisan letiltaná az ellenőrzést.

A DDoS-védelem normál módban indul percenként 600 kéréssel, kliensenként 100 hirtelen megengedett kéréssel. A kliensállapot-táblája 65 536 bejegyzésben van korlátozva. Ezek az értékek alapértékek, nem univerzális forgalmi modell: egy nyilvános API, egy letöltési szolgáltatás és egy belső admin panel nem oszthatja meg ugyanazokat az alkalmazás-specifikus korlátokat.

A böngészővédelmek a alapvető szint részét képezik

Webship válaszfejléc-politikája akkor is engedélyezett, ha egy alkalmazás elfelejti hozzáadni a sajátját. Az alapértelmezett tartalmazza:

  • X-Content-Type-Options: nosniff;
  • keret-megtagadási irányelv;
  • Referrer-Policy: no-referrer;
  • Szigorú szállítási biztonság egy évre, aldomain-ekkel együtt;
  • Tartalom-biztonsági irányelv korlátozva az azonos eredetű tartalomra, keretezési és alap-URI korlátozásokkal;
  • Engedélyek-házirend a földrajzi hely, a mikrofon és a kamera hozzáférésének letiltására.

Ezek az alapbeállítások szándékosan korlátozó jellegűek. Vizsgálja felül az HSTS-t, mielőtt azt egy olyan domainre alkalmazná, amelynek almappái nem teljesen HTTPS-képesek. Vizsgálja felül a Content-Security-Policy-t, mielőtt egy alkalmazás betöltene szkripteket, stílusokat, betűtípusokat, képeket vagy kapcsolatokat más forrásokból. Egy biztonságos alapértelmezett beállításnak látható hibát kell jeleznie a telepítés során, nem pedig csendesen gyengülnie a termelésben.

Az opcionális felületek zárva maradnak

Webship nem teszi elérhetővé az összes funkciót csak azért, mert a bináris tartalmazza azt. A fordított proxy, WebTransport, az obszervabilitási végpontok, az automatikus TLS, a válasz eredetisége és a MCP vezérlő végpont alapértelmezés szerint le van tiltva.

A MCP végpont bekapcsolt állapotban loopback-hatókörű, és explicit biztonsági konfigurációt igényel. A mérésekhez és statisztikákhoz a műszerelés szándékos engedélyezése szükséges. Az automatikus tanúsítványkezeléshez az üzemeltetőnek ki kell választania egy ACME könyvtárat, kapcsolatokat, tárolót és a szolgáltatási feltételek elfogadását. Ez megakadályozza, hogy az operatív funkciók váratlan hálózati felületekké váljanak.

Az alapértelmezett hallgató is a 127.0.0.1 címhez kötődik. Egy üzemeltetőnek kifejezetten ki kell választania egy nyilvános címet. Ez az egyetlen választás hasznos ellenőrzési pontot teremt a tűzfalszabályok, a szolgáltatási engedélyek, a TLS-azonosság és a telepítési topológia szempontjából.

A visszairányító proxy megőrzi a bizalmi határt

Amikor a reverse proxy engedélyezve van, a TLS áthaladás továbbra is az alapértelmezett. Webship titkosított forgalmat továbbít anélkül, hogy átvenné az alkalmazás szöveges tartalmát vagy az aktív munkamenetkulcsokat. Az eredeti szerver továbbra is felelős a TLS-ért és a megállapodott protokollért.

A TLS megszakítását csak akkor engedélyezze, ha a Webship-nak HTTP-kéréseket kell ellenőriznie, útvonal szerint kell irányítania, WAF és API szabályzatot kell alkalmaznia, fejlécet kell átírnia, vagy gyorsítótáraznia kell a válaszokat. A megszakítás önmagában nem kevésbé biztonságos; csupán áthelyezi a bizalmi határt. A fontos döntés az, hogy melyik gép láthatja a tiszta szöveget és miért.

A pass-through-nak is vannak funkcionális korlátai. A TCP útválasztás a ClientHello SNI alapján történik, mert a HTTP-kérés titkosított. A HTTP/3 pass-through megköveteli, hogy az útvonalak egy UDP forrást osszanak meg. Ha tartalom-tudatos biztonságra van szükséged a peremnél, ott fejezd be a TLS-t, és az edge-origin ugrást külön védelmezd.

Egy termelési alapvonal, amelyet áttekinthet

A következő részlet az alapértelmezett beállításokat teszi egyértelművé a kihagyásra való hagyatkozás helyett:

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

Egy többtartományos hallgatónál az unknown_sni = "reject" megakadályozza, hogy egy fel nem ismert hosztnév megkapja a hallgató alapértelmezett tanúsítványát. Webship automatikus TLS hallgatói már elutasítják az ismeretlen neveket, amíg tanúsítvány nem létezik.

Az érvényesítés egy biztonsági ellenőrzés

Webship ellenőrzi a konfigurációt, mielőtt hallgatókat kötne hozzá. Ismeretlen mezők, érvénytelen korlátok, hiányos identitások, ellentmondó hallgatók és nem támogatott protokollkombinációk indítási hibát okoznak egy konkrét hibaüzenettel. Ugyanez az ellenőrzés lefut, mielőtt egy élő konfigurációt telepítenek. Sikertelen újratöltés esetén a jelenlegi konfiguráció marad aktív.

A hitelesített MCP konfigurációs útvonal egy további védelmet ad: megtagadja az élő változtatásokat, amelyek egy aktív WAF, DDoS réteg, API Shield, bot kihívás, edge-auth szabályzat vagy válaszfejléc réteg kikapcsolását eredményeznék. A verzióellenőrzések megakadályozzák, hogy egy rendszergazda felülírja egy újabb konfigurációs pillanatképet. A folyamat-kötött beállítások továbbra is újraindítást igényelnek, ahelyett hogy úgy tűnne, mintha egy részleges élő változás sikeres lett volna.

Ez hasznos megkülönböztetés. A biztonságos alapértelmezések védik az új telepítést. A tranzakciós érvényesítés és a védett frissítések pedig a működő rendszert védik.

Mely üzemeltetőknek kell még dönteniük

Mielőtt Webship-t kiteszi az internetre:

  1. Állítson be egy megbízható TLS-azonosságot, és védje a privát kulcsot.
  2. Ismeretlen SNI kezelés beállítása a hallgatói topológiához.
  3. Erősítse meg, hogy az HSTS és a Content-Security-Policy minden alkalmazás és aldomain esetében megegyezik.
  4. Határozza meg az API Shield végpontjait, elfogadott módszereit, tartalomtípusait és engedélyezési követelményeit.
  5. Adj hozzá útvonal-specifikus korlátozásokat ahelyett, hogy csak az általános alapértékre támaszkodnál.
  6. Engedélyezze a perem-hitelesítést a védett hosztoknál vagy útvonalaknál, és használjon rövid élettartamú tokeneket.
  7. Tartsd a MCP és az észlelhetőségi hallgatókat privát, hitelesített és a nyilvános forgalomtól elkülönített állapotban.
  8. Futtassa a Webship-et egy dedikált, jogosultság nélküli fiókkal, lehetőleg egy csak olvasható alkalmazásgyökérrel, és csak a szükséges operációs rendszer képességekkel.
  9. Ellenőrizze a konfigurációt a bevezetés előtt, majd tesztelje a letiltott és engedélyezett forgalmat egy kanári környezetben.
  10. Figyelje a biztonsági audit eseményeket, és gyakorolja a váltást a normál üzemmódról a támadás alatt vagy zárolt állapotra.

A biztonságosabb alapértelmezett egy kezdet, nem pedig állítás

Egyetlen webkiszolgáló sem döntheti el, hogy mely felhasználók láthatják a számláit, mely eredetek hívhatják az API-ját, vagy milyen gyorsan kell a vállalati végpontjának fogadnia a kéréseket. Ezek a vezérlések alkalmazási ismereteket igényelnek.

Webship biztosítja az alsó réteget: korlátozott elemzőket, szigorú konfigurációt, védelmi válaszfejléceket, kérés-ellenőrzést, visszaélés elleni kontrollokat és zárt opcionális felületeket. Az eredmény nem a „biztonság megoldva”. Ez inkább egy kisebb rés a szerver telepítése és felelősségteljes üzemeltetése között.

Tekintse át a teljes Webship dokumentációt a termelési telepítés előtt. A konfigurációs séma és a futó bináris marad az irányadó forrás az Ön által használt pontos verzióhoz.