# Webship Serwer WWW: Domyślne ustawienia zabezpieczeń
Bezpieczny serwer internetowy nie powinien polegać na tym, że operator zapamięta dodatkowe ustawienie o 2 w nocy. Powinien zaczynać od ochronnej podstawy, odrzucać niebezpieczne konfiguracje i wymagać świadomych decyzji, zanim ujawni wrażliwe funkcje.
To jest model stojący za Webship. Jego domyślna konfiguracja włącza główne zabezpieczenia żądań i odpowiedzi, ogranicza zasoby, które atakujący może wykorzystać, i pozostawia opcjonalne powierzchnie kontrolne wyłączone. Możesz dostosować te domyślne ustawienia dla rzeczywistej aplikacji, ale nie musisz odkrywać wszystkich zabezpieczeń przed nadejściem pierwszego żądania.
Bezpieczeństwo domyślne nie oznacza bezpieczeństwa bez kontekstu. Certyfikaty, autoryzacja aplikacji, polityka sieciowa, tajemnice i reagowanie na incydenty wciąż należą do operatora. Zadaniem Webship jest uczynienie bezpiecznego punktu wyjścia oczywistym — i utrudnienie przypadkowego osłabienia.
Ochrony, które są włączone na start
Webship w swojej podstawowej konfiguracji umożliwia sześć warstw:
| Warstwa | Zachowanie domyślne | Co redukuje | | --- | --- | --- | | Ochrona plików kropkowych | Odrzuca statyczne segmenty ścieżki poprzedzone kropką | Przypadkowe ujawnienie plików środowiskowych, metadanych repozytorium i lokalnej konfiguracji | | Zapora aplikacji internetowej | Blokuje znane wzorce ataków | Wstrzyknięcia SQL, skrypty międzywitrynowe (cross-site scripting), traversale, sondy wrażliwych ścieżek, wstrzyknięcia poleceń, przemyt nagłówków i nieobsługiwane kodowania żądań | | Kontrola DDoS | Działa w normalnym trybie z ograniczonym stanem klienta | Zalewanie żądań, nieograniczone śledzenie i możliwe do uniknięcia wyczerpanie zasobów | | Wyzwolenie bota | Wykorzystuje podpisane ciasteczko wyzwania | Niskokosztowe zautomatyzowane nadużycia i powtarzalne skanowanie | | Nagłówki bezpieczeństwa odpowiedzi | Dodaje restrykcyjną politykę przeglądarki | Zamieszanie MIME, ramkowanie, wyciek referera, niebezpieczne możliwości przeglądarki i szerokie ładowanie treści | | API Shield | Używa trybu blokowania i odrzuca nieznane trasy po zdefiniowaniu kontraktu API | Cienie punktów końcowych, niezamierzone metody, nieoczekiwane typy treści i brakujące wymagania dotyczące autoryzacji |
Domyślny WAF ustala również twarde granice tego, co analizuje: 32 KiB nagłówków żądań, ścieżkę o długości 2 048 bajtów oraz ciało żądania o wielkości 1 MiB. Są to limity bezpieczeństwa, a nie arbitralne przełączniki wydajności. Jeśli aplikacja rzeczywiście potrzebuje większych żądań, zwiększ odpowiedni limit dla tej aplikacji i przetestuj wynik, zamiast wyłączać inspekcję globalnie.
Ochrona DDoS rozpoczyna się w trybie normalnym przy 600 żądaniach na minutę z zezwoleniem na nagły wzrost wynoszącym 100 na klucz klienta. Jej tabela stanu klienta jest ograniczona do 65 536 wpisów. Te wartości stanowią wartość bazową, a nie uniwersalny model ruchu: publiczne API, serwis pobierania i wewnętrzny panel administracyjny nie powinny dzielić tych samych ograniczeń specyficznych dla aplikacji.
Ochrona przeglądarki jest częścią podstawowego poziomu
Polityka nagłówków odpowiedzi Webship jest włączona nawet wtedy, gdy aplikacja zapomni dodać własną. Domyślnie obejmuje:
- X-Content-Type-Options: nosniff;
- polityka odmowy ram
- Polityka-Referrera: brak-referrera;
- Strict-Transport-Security na jeden rok, w tym subdomeny;
- Polityka bezpieczeństwa treści ograniczona do zawartości pochodzącej z tej samej domeny, z ograniczeniami dotyczącymi ramek i bazowego URI;
- Polityka uprawnień wyłączająca dostęp do geolokalizacji, mikrofonu i kamery.
Te ustawienia domyślne są celowo restrykcyjne. Przejrzyj HSTS przed zastosowaniem go na domenie z subdomenami, które nie są w pełni gotowe na HTTPS. Przejrzyj Content-Security-Policy, zanim aplikacja załaduje skrypty, style, czcionki, obrazy lub połączenia z innych źródeł. Bezpieczne ustawienie domyślne powinno wyraźnie zawieść podczas wdrożenia, a nie być cicho osłabiane w produkcji.
Powierzchnie opcjonalne pozostają zamknięte
Webship nie udostępnia każdej funkcji tylko dlatego, że znajduje się ona w binarce. Reverse proxy, WebTransport, punkty końcowe obserwowalności, automatyczne TLS, pochodzenie odpowiedzi oraz punkt końcowy kontroli MCP są domyślnie wyłączone.
Punkt końcowy MCP jest ograniczony do pętli zwrotnej, gdy jest włączony, i wymaga wyraźnej konfiguracji bezpieczeństwa. Metryki i statystyki wymagają celowego włączenia instrumentacji. Automatyczne zarządzanie certyfikatami wymaga od operatora wyboru katalogu ACME, kontaktów, magazynu oraz akceptacji warunków świadczenia usług. To zapobiega, aby funkcje operacyjne stały się nieoczekiwanymi punktami sieciowymi.
Podstawowy nasłuchiwacz również wiąże się z adresem 127.0.0.1. Operator musi wyraźnie wybrać publiczny adres. Ten pojedynczy wybór tworzy użyteczny punkt przeglądu dla reguł zapory, uprawnień usług, tożsamości TLS i topologii wdrożenia.
Odwrócone proxy zachowuje granicę zaufania
Gdy włączone jest działanie w trybie reverse proxy, przekazywanie TLS pozostaje domyślne. Webship przekazuje zaszyfrowany ruch bez przejmowania jawnego tekstu aplikacji ani aktywnych kluczy sesji. Źródło pozostaje odpowiedzialne za TLS i negocjowany protokół.
Włącz zakończenie TLS tylko wtedy, gdy Webship musi analizować żądania HTTP, kierować według ścieżki, stosować politykę WAF i API, przepisywać nagłówki lub buforować odpowiedzi. Zakończenie nie jest z zasady mniej bezpieczne; przesuwa granicę zaufania. Ważną decyzją jest, która maszyna może zobaczyć tekst jawny i dlaczego.
Przekazywanie również ma ograniczenia funkcjonalne. Routing TCP opiera się na ClientHello SNI, ponieważ żądanie HTTP jest szyfrowane. Przekazywanie HTTP/3 wymaga, aby trasy dzieliły jeden punkt początkowy UDP. Jeśli potrzebujesz zabezpieczenia wrażliwego na zawartość na krawędzi, zakończ TLS tam i osobno chroń połączenie między krawędzią a punktem początkowym.
Podstawowy poziom produkcji, który możesz przeglądać
Poniższy fragment wyraźnie pokazuje istotne wartości domyślne zamiast polegać na pominięciu:
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=()"W przypadku multi-domenowego nasłuchiwacza, unknown_sni = "reject" uniemożliwia nieznanemu hostowi otrzymanie domyślnego certyfikatu nasłuchiwacza. Automatyczne-TLS nasłuchiwacze Webship już odrzucają nieznane nazwy, dopóki certyfikat nie istnieje.
Walidacja jest kontrolą bezpieczeństwa
Webship weryfikuje konfigurację przed powiązaniem nasłuchiwaczy. Nieznane pola, nieprawidłowe limity, niekompletne tożsamości, kolidujący nasłuchiwacze i nieobsługiwane kombinacje protokołów powodują niepowodzenie uruchomienia z określonym błędem. Ta sama weryfikacja jest przeprowadzana przed instalacją aktywnej konfiguracji. Niepowodzenie przeładowania pozostawia aktywną bieżącą konfigurację.
Uwierzytelniona ścieżka konfiguracji MCP dodaje kolejny element ochronny: odrzuca zmiany na żywo, które mogłyby wyłączyć aktywny WAF, warstwę DDoS, API Shield, wyzwanie dla botów, politykę uwierzytelniania na krawędzi lub warstwę nagłówków odpowiedzi. Kontrole wersji zapobiegają nadpisaniu nowszego zrzutu konfiguracji przez jednego administratora. Ustawienia związane z procesem nadal wymagają ponownego uruchomienia, zamiast udawać, że częściowa zmiana na żywo zakończyła się sukcesem.
To jest przydatne rozróżnienie. Bezpieczne ustawienia domyślne chronią nową instalację. Walidacja transakcyjna i chronione aktualizacje chronią działającą instalację.
Jakie operatorzy nadal muszą zdecydować
Przed wystawieniem Webship w internecie:
- Skonfiguruj zaufaną tożsamość TLS i chroń klucz prywatny.
- Ustaw nieznane obsługiwanie SNI dla topologii nasłuchiwacza.
- Potwierdź, że HSTS i Content-Security-Policy są zgodne z każdą aplikacją i subdomeną.
- Zdefiniuj punkty końcowe API Shield, akceptowane metody, typy zawartości oraz wymagania dotyczące autoryzacji.
- Dodaj ograniczenia szybkości specyficzne dla trasy zamiast polegać wyłącznie na globalnym poziomie bazowym.
- Włącz uwierzytelnianie brzegowe dla chronionych hostów lub ścieżek i używaj tokenów o krótkim czasie życia.
- Utrzymuj MCP oraz nasłuchiwacze obserwowalności prywatne, uwierzytelnione i oddzielone od ruchu publicznego.
- Uruchom Webship przy użyciu dedykowanego konta bez uprawnień, w miarę możliwości aplikacyjnego katalogu głównego tylko do odczytu oraz z wykorzystaniem jedynie tych możliwości systemu operacyjnego, które są potrzebne.
- Zweryfikuj konfigurację przed wdrożeniem, a następnie przetestuj blokowany i dozwolony ruch w środowisku kanarkowym.
- Monitoruj zdarzenia związane z audytem bezpieczeństwa i przećwicz przełączenie z trybu normalnego na tryb ataku lub blokady.
Bezpieczniejsza domyślna opcja to początek, a nie twierdzenie
Żaden serwer internetowy nie może zdecydować, którzy użytkownicy powinni widzieć twoje faktury, które źródła mogą wywoływać twoje API ani jak szybko twój punkt końcowy biznesowy powinien akceptować żądania. Te kontrole wymagają wiedzy aplikacyjnej.
Webship dostarcza niższą warstwę: ograniczonych parserów, rygorystycznej konfiguracji, defensywnych nagłówków odpowiedzi, inspekcji żądań, kontroli nadużyć i zamkniętych opcjonalnych powierzchni. Wynikiem nie jest „rozwiązane bezpieczeństwo”. Efektem jest mniejsza przepaść między zainstalowaniem serwera a odpowiedzialnym jego użytkowaniem.
Przejrzyj kompletną Webship dokumentację przed wdrożeniem produkcyjnym. Schemat konfiguracji i działający plik binarny pozostają autorytatywnymi źródłami dla dokładnej wersji, w której pracujesz.