Przejdź do treści
JT CONSULTING
Menu

Uruchomienie i konfiguracja serwera VPS: pierwsza godzina

Juliusz Tomeczek,

Dwa poprzednie teksty tej serii wyjaśniały, co to jest VPS i czy własny serwer w ogóle się opłaca, oraz jak porównać i wybrać serwer VPS, czyli u kogo go wynająć. Ten tekst zaczyna się w chwili, gdy dostawca przysyła dane dostępowe. Serwer działa, ma publiczny adres i już w pierwszych minutach odbiera próby logowania wysyłane przez automaty, które przeczesują sieć w poszukiwaniu słabo zabezpieczonych maszyn.

Opisuję, co robię w pierwszej godzinie, zanim uruchomię na serwerze cokolwiek innego, i dlaczego w tej właśnie kolejności. Nie podaję listy poleceń do przepisania. Polecenia zależą od systemu i dostawcy, a każde warto rozumieć, zanim się je wykona, bo pomyłka w ustawieniach logowania potrafi odciąć dostęp do własnej maszyny.

Trzy decyzje, które zapadają jeszcze przy zamówieniu

Gdzie ma stać maszyna? Moja stoi w warszawskim centrum danych. W poprzednim artykule wyjaśniłem, dlaczego to ma znaczenie: łatwiej wykazać zgodność z przepisami o ochronie danych, odpowiedzi szybciej docierają do odwiedzających, a pomoc techniczna pracuje w tej samej strefie czasowej.

Jaki system na niej zainstalować? Wybrałem Debiana w wersji 12. Na serwerze liczy się przewidywalność, a nie nowości, więc wolę system, który zmienia się rzadko i zapowiada zmiany z wyprzedzeniem. Wybór ma też skutek praktyczny: do popularnego systemu łatwiej znaleźć dokumentację i odpowiedzi na nietypowe pytania.

Jak dużą maszynę wybrać na początek? Ja zacząłem od 6 rdzeni, 11 GB pamięci RAM i 99 GB dysku. Powiększyłem maszynę po niecałych czterech miesiącach, bez przeprowadzki i bez stawiania systemu od nowa. Skoro rozbudowa jest tak prosta, nie ma powodu kupować maszyny na wyrost.

Pierwsza godzina: pięć kroków w ustalonej kolejności

1. Własne konto administratora zamiast domyślnego

Na nowej maszynie dostawca zakłada konto o przewidywalnej nazwie, a przewidywalna nazwa to połowa danych logowania podana atakującemu za darmo. Zakładam więc własne konto z uprawnieniami administratora, sprawdzam, czy da się na nie zalogować i wydawać z niego polecenia administracyjne, i dopiero wtedy blokuję konto domyślne. Kolejność jest tu najważniejsza, bo odwrotna kolejność kończy się zatrzaśniętymi drzwiami i kluczem po niewłaściwej stronie.

2. Logowanie wyłącznie kluczem

Hasło można odgadnąć, a klucza kryptograficznego w praktyce nie. Wyłączam logowanie hasłem i bezpośrednie logowanie na konto główne systemu. Każdy komputer, z którego administruję serwerem, ma własny klucz, więc utrata laptopa oznacza wycofanie jednego klucza, a nie wymianę wszystkich.

3. Zapora: wszystko zamknięte, otwarte tylko to, co niezbędne

Zaczynam od zakazu całego ruchu przychodzącego i otwieram trzy porty: jeden do zdalnego logowania i dwa dla stron internetowych. Bazy danych i usługi pomocnicze pracują w sieci wewnętrznej serwera i z internetu w ogóle ich nie widać. Przy przeglądzie we wrześniu 2026 sprawdziłem to od strony maszyny: na zewnątrz nasłuchują wyłącznie te trzy porty.

4. Blokada po nieudanych próbach i powiadomienia o logowaniu

Zapora nie odróżni właściciela od automatu, który na porcie logowania próbuje kolejnych haseł. Tym zajmuje się drugi mechanizm: po kilku nieudanych próbach adres trafia na listę zablokowanych. Do tego skrypt regularnie przegląda dziennik logowań i wysyła mi powiadomienie, gdy ktoś zaloguje się z nieznanego adresu albo gdy w systemie pojawi się nowe konto.

Skalę zjawiska dobrze pokazuje jedna liczba. We wrześniu 2026 plik z zapisem nieudanych prób logowania zajmował na moim serwerze 61 MB, a każdy wpis w tym pliku to jedna nieudana próba.

5. Aktualizacje i zegar

System sam instaluje poprawki bezpieczeństwa. Aktualizacja nie restartuje jednak maszyny, więc nowe jądro systemu czeka na dysku, aż ktoś zdecyduje o restarcie. U mnie restart jest zawsze osobną, planowaną decyzją, bo na tym serwerze pracuje kilkanaście usług i strony klientów.

Ostatnia rzecz z pierwszej godziny brzmi błaho: strefa czasowa i synchronizacja zegara. Od zegara zależy jednak, czy godziny w dziennikach, w kopiach zapasowych i w powiadomieniach da się ze sobą zestawić, kiedy coś pójdzie nie tak.

Zanim stanie pierwsza aplikacja

Po pierwszej godzinie serwer jest zabezpieczony, ale jeszcze niczego nie robi. Zanim uruchomię na nim pierwszą aplikację, ustawiam cztery rzeczy, które później trudno dołożyć.

Kopia zapasowa od pierwszego dnia. Skrypt robi kopię codziennie o trzeciej w nocy, szyfruje ją i odkłada w dwóch miejscach: na serwerze, gdzie leży siedem dni, i w chmurze u innego dostawcy, gdzie leży trzydzieści dni. Do tego dochodzi płatna kopia całej maszyny po stronie dostawcy serwera, opisana w poprzednim artykule. Zasada jest jedna: kopia, która leży tylko na tej samej maszynie, zginie razem z nią.

Porządek na dysku. Każda usługa ma własny katalog, a hasła leżą w osobnym pliku, który może odczytać tylko administrator. W plikach konfiguracji nie ma żadnych haseł, więc konfigurację można przechowywać w repozytorium, porównywać i odtwarzać bez ryzyka, że razem z nią wycieknie dostęp do baz.

Jedno wejście z internetu. Wszystkie aplikacje działają w kontenerach za jednym pośrednikiem, który przyjmuje ruch, kieruje go do właściwej usługi i sam odnawia certyfikaty. Tę warstwę opiszę osobno w odcinku o Dockerze.

Nadzór nad dostępnością. Narzędzie co minutę sprawdza, czy strony i aplikacje odpowiadają, i daje znać, gdy któraś przestanie odpowiadać. Temu narzędziu poświęcam następny odcinek serii.

Trzy błędy, które popełniłem na tym serwerze

Pierwsza konfiguracja nie była kompletna. Po pewnym czasie pracy serwera zrobiłem pełny przegląd bezpieczeństwa. Śladów włamania nie było, ale przegląd znalazł kilka rzeczy, które pominąłem przy pierwszej konfiguracji, i wszystkie od razu poprawiłem. Ten przypadek dobrze pokazuje, dlaczego przegląd bezpieczeństwa warto zaplanować na stałe i powtarzać, zamiast robić go raz, po uruchomieniu serwera. U mnie wraca on regularnie, według harmonogramu.

Kontrola kopii patrzyła nie na to, co trzeba. Sprawdzała, czy plik kopii jest cały, a nie czy jest świeży. Kiedy nowe kopie przestały powstawać, kontrola dalej zgłaszała, że wszystko jest w porządku, a przerwę wykrył dopiero przegląd serwera. Niczego nie straciłem, bo w chmurze leżały wcześniejsze kopie. Wniosek jest prosty: kontrola kopii ma sprawdzać datę ostatniego przebiegu, a nie tylko to, czy plik da się otworzyć.

Automatyczna aktualizacja, której nie zamówiłem. Narzędzie, które aktualizuje kontenery, podmieniło w nocy wersję pośrednika, przez który idzie ruch do wszystkich stron na serwerze. Nic się nie zepsuło, a zmianę wychwycił przegląd. Teraz wersje kluczowych składników są ustalone na sztywno, a każda podmiana przychodzi do mnie jako powiadomienie z numerem wersji przed zmianą i po niej.

Wszystkie trzy błędy mają wspólną przyczynę: coś wyglądało na działające, więc nie budziło podejrzeń. Dlatego pierwsza godzina to dopiero początek pracy przy serwerze, a nie jej koniec.

Kiedy oddać to komuś innemu

Po pierwszej godzinie przychodzą przeglądy i aktualizacje, a na powiadomienia trzeba reagować również w weekendy. Jeżeli w firmie nie ma osoby, która się tym zajmie, warto policzyć koszt tej pracy tak samo jak abonamenty w pierwszym artykule serii. Zakładam i prowadzę takie serwery dla firm, a zakres tej pracy opisuje strona Własny serwer zamiast abonamentów.

Lista kontrolna pierwszej godziny

  1. Własne konto administratora, sprawdzone przed zablokowaniem konta domyślnego.
  2. Logowanie wyłącznie kluczem, osobny klucz dla każdego komputera, bez logowania na konto główne systemu.
  3. Zapora zamykająca wszystko poza niezbędnymi portami.
  4. Blokada adresów po nieudanych próbach i powiadomienie o logowaniu z nieznanego adresu.
  5. Automatyczne poprawki bezpieczeństwa i restart planowany jako osobna decyzja.
  6. Strefa czasowa i synchronizacja zegara.
  7. Kopia zapasowa poza maszyną, z kontrolą daty ostatniego przebiegu, zanim na serwerze pojawią się dane.

Co dalej w tej serii

W następnym odcinku opiszę monitoring, czyli narzędzie, które co minutę sprawdza, czy moje strony i aplikacje odpowiadają, i powiadamia mnie, gdy któraś przestanie odpowiadać. Później po kolei przedstawię pozostałe narzędzia, które pracują na tym serwerze.

Ten tekst powstał z użyciem narzędzi sztucznej inteligencji, bo tak pracuję na co dzień i tego uczę. Każde twierdzenie w nim sprawdziłem i odpowiadam za nie z imienia i nazwiska. Rysunki w tym dziale powstały tak samo: są wektorowe, napisane jako kod przy tej samej pomocy. Zrzuty ekranu pokazują prawdziwe programy i robię je sam.

Juliusz Tomeczek, JT CONSULTING

Porozmawiajmy o współpracy

Napisz krótko, czego potrzebujesz, a odezwę się z propozycją następnego kroku. Odpowiadam osobiście, bo w JT CONSULTING nie ma działu obsługi.

Jeżeli wolisz najpierw poczytać, więcej tekstów o sztucznej inteligencji znajdziesz na moim blogu AI for Everyone. Zobacz blog