To generyczny baseline operacyjny Linuxa, nie przewodnik wdrożenia Laravela. Utrzymywalny serwer ma nazwanych ownerów, dostęp bez roota, ograniczoną ekspozycję, politykę patchy, odtwarzalne backupy i dowód działania kontroli.
Ustal dostęp przed hardeningiem
Utwórz imiennego użytkownika sudo, zainstaluj klucz publiczny Ed25519, potwierdź logowanie w drugim terminalu, dopiero potem wyłącz root oraz password login. Przed zmianą SSH zachowaj out-of-band console. Przez UFW dopuść wyłącznie wymagane porty i zweryfikuj reguły z innego hosta.
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose
Fail2ban jest warstwą reakcji, nie zamiennikiem aktualnego software i ograniczonej ekspozycji. Potwierdź, że jail wskazuje źródło logu SSH i bezpiecznie przetestuj błąd.
systemd posiada procesy długo działające
Nie polegaj na nohup, tmux ani sesji SSH. Unit opisuje użytkownika, katalog, restart i granicę środowiska.
[Unit]
Description=Example worker
After=network.target
[Service]
User=deploy
WorkingDirectory=/srv/example
ExecStart=/usr/local/bin/example-worker
Restart=on-failure
RestartSec=5
[Install]
WantedBy=multi-user.target
systemctl status example-worker pokazuje stan, a journalctl -u example-worker -f chronologiczną historię incydentu. Ustaw retencję journala świadomie, aby disk-full nie usunął dowodów diagnostycznych.
Patchuj, backupuj i ćwicz odtwarzanie
Włącz unattended security upgrades, gdy pozwala polityka floty, ale monitoruj reboot-required i planuj restarty kernela. Backup wymaga szyfrowanego off-host storage, retencji, alertingu i testu restore; udana komenda backupu nie jest dowodem recovery. Zapisz hostname, ownera usługi, zależności, rotację sekretów, rollback i runbook restore.
SSH, systemd i journald jako dowód operacyjny
Utwórz użytkownika sudo z kluczem Ed25519, zaloguj się drugim terminalem i dopiero wtedy ustaw PermitRootLogin no, PasswordAuthentication no oraz AllowUsers deploy. Zachowaj konsolę dostawcy i najpierw wykonaj sshd -t. Fail2ban czyta rzeczywiste źródło logów SSH; nie zastępuje kluczy ani patchy.
[Service]
User=deploy
WorkingDirectory=/srv/example
EnvironmentFile=/etc/example/worker.env
ExecStart=/usr/local/bin/example-worker
Restart=on-failure
RestartSec=5
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=full
# /etc/systemd/journald.conf.d/retention.conf
[Journal]
Storage=persistent
SystemMaxUse=1G
MaxRetentionSec=14day
sudo systemctl daemon-reload
sudo systemctl enable --now example-worker
journalctl -u example-worker --since '1 hour ago'
sudo fail2ban-client status sshd
Unattended security upgrades wymagają alertu o reboocie i zaplanowanego restartu kernela. Baseline monitoringu obejmuje CPU/RAM, dysk i inode, stan usługi, wygasanie certyfikatu oraz wiek backupu. Backup staje się dowodem dopiero po szyfrowanym restore poza produkcją.
Kiedy tego NIE używać
Nie stosuj tych komend w ciemno do immutable images, node'ów managed Kubernetes ani zarządzanego appliance: użyj control plane platformy. Nie otwieraj portów „tymczasowo” bez daty wygaśnięcia. Konfiguracja PHP-FPM, kolejek i Nginx Laravela należy do przewodników deploymentowych, gdzie da się ją testować razem.