Firewall на VPS: минимальный набор правил для старта

Введение

Если VPS «смотрит» в интернет, у него есть две роли: работать и не светиться лишним. Firewall — это как дверной замок: не делает дом неуязвимым, но резко сокращает число случайных гостей и неприятных сюрпризов.

Эта статья рассчитана на владельцев VPS с базовыми навыками Linux (SSH, sudo, редактирование конфигов). ОС не указана, поэтому примеры даны для Debian/Ubuntu и отдельно отмечены нюансы для CentOS/RHEL-подобных систем. В фокусе три стека управления правилами: UFW, iptables и nftables (и как между ними не запутаться). UFW — штатный «упрощённый фасад» над netfilter/iptables для Ubuntu , nftables — современный наследник iptables, который всё чаще оказывается «под капотом» даже там, где вы продолжаете писать iptables … .

Что вы получите на выходе:

• минимальную безопасную базу (default deny inbound + allowlist нужных портов);
• готовые наборы правил и команды для пяти типовых сценариев: SSH‑only, Web, Mail, Docker‑host, Control panel (с акцентом на ISPmanager, которую King Servers предлагает предустановленной) ;
• безопасный порядок применения (включая «страховку от самоизоляции»), откат и проверку;
• короткую шпаргалку по выбору инструмента и чек‑лист деплоя.

Контекст, аудитория и выбор инструмента без лишней философии

Целевая аудитория. Администратор или разработчик, который арендует VPS, подключается по SSH, умеет читать вывод ss, пользоваться systemctl, править /etc/* и хочет быстро прийти к «разумно закрытому» серверу.

Цели настройки.Сделать сервер безопасным «по умолчанию»: входящие соединения запрещены, кроме явно нужных. При этом правила должны быть минимальными, чтобы вы не потратили вечер на отладку, и адаптируемыми, чтобы легко добавлять сервисы и нестандартные порты.

Область охвата (что учтём).UFW / iptables / nftables; SSH (включая rate‑limit); типовые веб‑порты; базовые почтовые порты; нюансы Docker; логирование; fail2ban; DNS и systemd-resolved (чтобы не «сломать интернет» на ровном месте) .

Ограничения и реальность.1) Примеры — для Debian/Ubuntu и CentOS/RHEL‑линейки. 2) Порт‑лист «вашего проекта» может отличаться: держите в голове правило «добавили сервис → открыли порт → проверили → задокументировали». 3) Не смешивайте несколько управлялок одновременно: параллельная работа legacy‑iptables и nft‑инструментов может давать неожиданные эффекты .

Как выбрать инструмент на старте.

• UFW: когда хочется быстро и аккуратно, а правил немного. Он специально задуман как простой интерфейс к netfilter/iptables .
• nftables: когда сервер живёт долго, правил становится больше, или вы хотите «современный чистый» ruleset. В RHEL 8+ nftables — рекомендуемый путь для кастомной фильтрации, а iptables‑утилита там работает через nf_tables (совместимость) .
• iptables: когда есть legacy‑скрипты/инструкции или конкретная необходимость. Но помните: в новых системах iptables часто «переводит» команды в nftables, а не работает как старый xtables .

Безопасное внедрение: порядок действий, тестирование, откат и аварийный доступ

Самая частая авария при настройке firewall — закрыли SSH и потеряли доступ. Это лечится дисциплиной и двумя страховками: порядком применения и планом отката.

Правильная последовательность настройки

1) Убедитесь, что вы понимаете, какой порт у SSH и откуда вы подключаетесь.Быстро проверить, что слушает sshd:

sudo ss -tlnp | grep -E 'sshd|:22'

2) Подготовьте «страховку» до включения правил:

• откройте вторую SSH‑сессию (в идеале — через другой клиент/канал);
• запустите tmux, чтобы не потерять контекст при разрыве соединения (tmux сохраняет сессию при обрыве SSH) .

tmux new -s fw

3) Сохраните текущее состояние правил (даже если «там пусто»).

• iptables:

sudo iptables-save > ~/iptables.backup.$(date +%F_%H%M%S).rulessudo ip6tables-save > ~/ip6tables.backup.$(date +%F_%H%M%S).rules

• nftables:

sudo nft list ruleset > ~/nftables.backup.$(date +%F_%H%M%S).nft

4) Делайте изменения с возможностью автоматического отката.

Для iptables есть готовая «защита от самоизоляции»: iptables-apply. Она применяет набор правил и просит подтвердить, что всё ок; если вы не подтвердили (например, SSH умер) — откатит назад по таймауту .

5) После применения — проверка доступности и логов, и только потом — «постоянство» (автозагрузка правил на reboot).

Две «кнопки паники»: что делать, если всё пошло не так

Вариант A: есть доступ по SSH, но что-то сломалось.

• UFW:

sudo ufw disable

ufw disable выгружает firewall и отключает его автозапуск .

• iptables (осторожно: это откроет всё входящее, пока вы не восстановите правила):

sudo iptables -P INPUT ACCEPTsudo iptables -P FORWARD ACCEPTsudo iptables -P OUTPUT ACCEPTsudo iptables -Fsudo iptables -X

• nftables (тоже «открывает всё», потому что пустой ruleset = нет фильтрации):

sudo nft flush ruleset

flush ruleset очищает правила и фактически оставляет систему без фильтрации (ядро принимает пакеты, если нет правил) .

Вариант B: SSH уже отвалился.

Тут спасает консоль провайдера (VNC/serial/remote console) или rescue mode. Большинство провайдеров это дают как «аварийный вход», когда SSH недоступен . В консоли вы выполняете одну из команд выше (для UFW/iptables/nftables), возвращаете доступ и спокойно исправляете правила.

Мини‑диаграмма безопасного внедрения

flowchart TDA[Открыли 2-ю SSH-сессию + tmux] --> B[Сохранили текущие правила]B --> C[Добавили правило для SSH]C --> D[Включили default deny inbound]D --> E[Открыли нужные сервисы]E --> F[Проверили доступность снаружи + логи]F --> G[Настроили автозагрузку / persistence]F -->|SSH пропал| H[Консоль/Rescue → отключить/flush → откатить]

Минимальная логика правил: что обязательно, а что по желанию

Вне зависимости от инструмента, «здоровый скелет» правил одинаковый.

Минимум, который почти всегда нужен:

• Loopback (lo): разрешить. Иначе начинают «странно» ломаться локальные сервисы (включая DNS‑stub от systemd‑resolved).
• Established/Related: разрешить ответы на уже начатые соединения.
• Default deny incoming: всё входящее — закрыто, кроме allowlist.
• Только нужные порты: SSH, HTTP/HTTPS и т.д.
• Логирование: умеренно, чтобы видеть «что стучится», но не залить диск логами.

DNS и systemd-resolved: важная мелочь, о которую часто спотыкаются

На многих системах systemd-resolved поднимает локальный DNS‑stub на 127.0.0.53 (и 127.0.0.54) на loopback-интерфейсе . Если вы «перекрыли» loopback или слишком агрессивно режете локальный трафик — DNS начинает вести себя как будто «интернет пропал», хотя сеть жива.

Вывод: loopback разрешаем всегда, а исходящий трафик (например, DNS наружу) в базовом варианте проще оставить разрешённым (default allow outgoing). Это соответствует типовой модели UFW: «входящее закрыть, исходящее оставить» .

SSH: риск‑компромиссы и минимальная защита от брутфорса

Открытый SSH в интернет почти гарантированно увидит перебор паролей через минуты. Компромисс простой:

• Можно открыть SSH «на весь мир» и включить rate‑limit и fail2ban.
• Лучше открыть SSH только с вашего IP (или через VPN/bastion), а остальным — отказ.

UFW умеет rate‑limit встроенно: ufw limit ssh/tcp. По manpage, лимит начинает «резать» попытки, если IP инициирует 6+ соединений за 30 секунд .

Fail2ban читает логи (например, auth.log) и банит IP, обновляя правила firewall . У него есть actions и для iptables, и для nftables (в репозитории присутствуют action.d/iptables*.conf и action.d/nftables*.conf) .

Docker: почему «я закрыл порт, а он всё равно открыт?»

Docker активно управляет iptables‑правилами и создаёт свои цепочки. Для пользовательских правил перед докеровскими есть цепочка DOCKER-USER — именно туда Docker рекомендует помещать ограничения . Это ключевой момент для сценария «Docker‑host».

Готовые минимальные наборы правил по сценариям

Ниже — пять практичных шаблонов. В каждом: логика правил, команды для UFW, iptables и nftables, «постоянство», проверка и быстрый troubleshooting.

Обозначения, которые стоит заменить под себя:

• ADMIN_IP — ваш внешний IP/32 (или офисная подсеть).
• SSH_PORT — порт SSH (часто 22, но не всегда).
• Если у вас нестандартные порты — адаптация всегда одна: откройте конкретный порт/протокол и ограничьте источник.

Сценарий: минимальный сервер только с SSH (SSH-only)

Смысл правил.Входящее: разрешить только SSH (желательно только с ADMIN_IP). Остальное — drop. Исходящее — разрешить (чтобы работали обновления и DNS).

UFW (Debian/Ubuntu)

# 1) Базаsudo ufw default deny incomingsudo ufw default allow outgoing# 2) SSH: сначала открыть (лучше с ограничением по IP)sudo ufw allow from ADMIN_IP to any port SSH_PORT proto tcp# 3) Опционально: вместо allow — limit (если SSH в интернет)# sudo ufw limit SSH_PORT/tcp# 4) Логи (умеренно)sudo ufw logging low# 5) Включение (включает и автозапуск на boot) sudo ufw enable

UFW поддерживает --dry-run, чтобы посмотреть изменения, не применяя их :

sudo ufw --dry-run enable

Проверка.

sudo ufw status verbosesudo ss -tlnp | grep -E ":${SSH_PORT}\b"

Troubleshooting.Если после ufw enable пропал доступ — сразу через консоль провайдера: ufw disable .

iptables (универсально, но аккуратно)

Для безопасного применения удалённо используйте iptables-apply (автооткат при потере связи) .

Создадим файл ~/rules.v4:

cat > ~/rules.v4 <<'EOF'*filter:INPUT DROP [0:0]:FORWARD DROP [0:0]:OUTPUT ACCEPT [0:0]# 1) Loopback-A INPUT -i lo -j ACCEPT# 2) Established/Related-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT# 3) SSH только с ADMIN_IP-A INPUT -p tcp -s ADMIN_IP --dport SSH_PORT -m conntrack --ctstate NEW -j ACCEPT# 4) (Опционально) ICMP для диагностики-A INPUT -p icmp -j ACCEPTCOMMITEOF

Проверка синтаксиса без коммита (iptables-restore --test) :

sudo iptables-restore --test < ~/rules.v4

Применение с автооткатом:

sudo iptables-apply -t 60 ~/rules.v4

Проверка.

sudo iptables -Ssudo iptables -L -n -v

nftables (рекомендуемый «чистый» вариант)

Проверка команды без применения: nft --check .

Файл /etc/nftables.conf (минимальный skeleton):

#!/usr/sbin/nft -fflush rulesettable inet filter {  chain input {    type filter hook input priority 0; policy drop;    iif "lo" accept    ct state established,related accept    ip saddr ADMIN_IP tcp dport SSH_PORT ct state new accept    ip protocol icmp accept    ip6 nexthdr ipv6-icmp accept  }  chain forward {    type filter hook forward priority 0; policy drop;  }  chain output {    type filter hook output priority 0; policy accept;  }}

Проверка:

sudo nft --check -f /etc/nftables.confsudo nft -a list ruleset

Важно. В базовых цепочках nftables policy drop отбрасывает всё, что не принято правилами .

Сценарий: веб‑сервер (HTTP/HTTPS)

Смысл правил.SSH для администрирования (желательно ограничить по IP), плюс открыть 80/443 на весь мир.

UFW

sudo ufw default deny incomingsudo ufw default allow outgoingsudo ufw allow from ADMIN_IP to any port SSH_PORT proto tcpsudo ufw allow 80/tcpsudo ufw allow 443/tcpsudo ufw logging lowsudo ufw enable

Проверка.

sudo ufw status numberedsudo ss -tlnp | grep -E ':(80|443|SSH_PORT)\b'

iptables (пример rules.v4)

cat > ~/rules.v4 <<'EOF'*filter:INPUT DROP [0:0]:FORWARD DROP [0:0]:OUTPUT ACCEPT [0:0]-A INPUT -i lo -j ACCEPT-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT# SSH admin-only-A INPUT -p tcp -s ADMIN_IP --dport SSH_PORT -m conntrack --ctstate NEW -j ACCEPT# HTTP/HTTPS-A INPUT -p tcp --dport 80  -m conntrack --ctstate NEW -j ACCEPT-A INPUT -p tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPTCOMMITEOFsudo iptables-restore --test < ~/rules.v4sudo iptables-apply -t 60 ~/rules.v4

nftables (фрагмент)

flush rulesettable inet filter {  chain input {    type filter hook input priority 0; policy drop;    iif "lo" accept    ct state established,related accept    ip saddr ADMIN_IP tcp dport SSH_PORT ct state new accept    tcp dport { 80, 443 } ct state new accept  }  chain forward { type filter hook forward priority 0; policy drop; }  chain output  { type filter hook output  priority 0; policy accept; }}

Сценарий: базовый mail-server

Смысл правил.Почтовый сервер — это больше портов и больше «публичной поверхности». Минимально обычно открывают:

• SMTP: 25 (приём), 465 и/или 587 (submission) — зависит от схемы;
• IMAP/IMAPS: 143/993 (если есть почтовые ящики);
• POP3/POP3S: 110/995 (если нужен POP3; многие обходятся без него).

Такие наборы портов фигурируют в документации популярных панелей (например, Plesk перечисляет 25/465/110/995/143/993)  и в требованиях ISPmanager (25/465/587/110/143/993/995) .

UFW

sudo ufw default deny incomingsudo ufw default allow outgoingsudo ufw allow from ADMIN_IP to any port SSH_PORT proto tcp# SMTPsudo ufw allow 25/tcpsudo ufw allow 465/tcpsudo ufw allow 587/tcp# IMAP/IMAPSsudo ufw allow 143/tcpsudo ufw allow 993/tcp# POP3/POP3S (если нужно)sudo ufw allow 110/tcpsudo ufw allow 995/tcpsudo ufw logging lowsudo ufw enable

iptables (пример)

cat > ~/rules.v4 <<'EOF'*filter:INPUT DROP [0:0]:FORWARD DROP [0:0]:OUTPUT ACCEPT [0:0]-A INPUT -i lo -j ACCEPT-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT# SSH admin-only-A INPUT -p tcp -s ADMIN_IP --dport SSH_PORT -m conntrack --ctstate NEW -j ACCEPT# SMTP / Submission-A INPUT -p tcp --dport 25  -m conntrack --ctstate NEW -j ACCEPT-A INPUT -p tcp --dport 465 -m conntrack --ctstate NEW -j ACCEPT-A INPUT -p tcp --dport 587 -m conntrack --ctstate NEW -j ACCEPT# IMAP/IMAPS-A INPUT -p tcp --dport 143 -m conntrack --ctstate NEW -j ACCEPT-A INPUT -p tcp --dport 993 -m conntrack --ctstate NEW -j ACCEPT# POP3/POP3S (опционально)-A INPUT -p tcp --dport 110 -m conntrack --ctstate NEW -j ACCEPT-A INPUT -p tcp --dport 995 -m conntrack --ctstate NEW -j ACCEPTCOMMITEOFsudo iptables-restore --test < ~/rules.v4sudo iptables-apply -t 60 ~/rules.v4

nftables

flush rulesettable inet filter {  chain input {    type filter hook input priority 0; policy drop;    iif "lo" accept    ct state established,related accept    ip saddr ADMIN_IP tcp dport SSH_PORT ct state new accept    tcp dport { 25, 465, 587, 143, 993, 110, 995 } ct state new accept  }  chain forward { type filter hook forward priority 0; policy drop; }  chain output  { type filter hook output  priority 0; policy accept; }}

Риск‑компромиссер для почты.Открыть «все почтовые порты» — нормально, но обязательно усиливайте аутентификацию (DKIM, SPF, строгие пароли, rate‑limit/ban). Здесь особенно полезен fail2ban: он предназначен банить адреса при множественных ошибках аутентификации, меняя правила firewall .

Сценарий: Docker-host

Смысл проблемы.Docker создаёт свои цепочки и правила в iptables, и «обычные» ожидания от UFW/iptables иногда не совпадают с реальностью. Правильная точка входа для ваших ограничений — цепочка DOCKER-USER: Docker прямо описывает её как место для пользовательских правил, которые обрабатываются до докеровских цепочек .

Практический минимум:

• на хосте держать строгий inbound (SSH + то, что реально публикуете);
• для контейнеров — фильтрация через DOCKER-USER (если нужно ограничивать источники).

UFW (минимум)

UFW можно использовать, но помните: Docker управляет iptables сам. Если вам нужно жёстко ограничивать доступ к опубликованным контейнерным портам, проще делать это через DOCKER-USER (iptables) или через native nftables‑правила (в продвинутых схемах).

База UFW на хосте:

sudo ufw default deny incomingsudo ufw default allow outgoingsudo ufw allow from ADMIN_IP to any port SSH_PORT proto tcp# Открывайте только реально опубликованные порты контейнеров:# пример: контейнер публикует 80/443 на hostsudo ufw allow 80/tcpsudo ufw allow 443/tcpsudo ufw enable

iptables: DOCKER-USER как «фильтр перед Docker»

Пример: разрешаем опубликованный порт 443 только с ADMIN_IP, остальным — drop (но не ломаем внутреннюю кухню Docker).

# Разрешить established/related в DOCKER-USER (безопасная база)sudo iptables -I DOCKER-USER 1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT# Разрешить доступ к 443 только с ADMIN_IPsudo iptables -I DOCKER-USER 2 -p tcp -s ADMIN_IP --dport 443 -j ACCEPT# Остальное к 443 — дропнутьsudo iptables -A DOCKER-USER -p tcp --dport 443 -j DROP

Почему именно так: DOCKER-USER обрабатывается перед DOCKER‑FORWARD и DOCKER‑цепочками, и предназначена для пользовательских правил .

nftables: общий принцип

С nftables Docker‑интеграции сложнее «универсальным рецептом», потому что Docker традиционно работает через iptables‑стек. На современных системах iptables может быть nf_tables‑вариантом и переводить правила в nft , но это уже зона «проверьте на конкретной ОС».

Если вы делаете firewall полностью на nftables, важно не запускать параллельно другой firewall‑сервис, чтобы они не влияли друг на друга .

Сценарий: сервер с control panel

Здесь два главных правила выживания:

1) Панель — это самый лакомый публичный интерфейс, поэтому её лучше открывать только с доверенных IP (ваш офис/VPN).2) Открывайте только то, что реально используете (вендоры панелей сами это подчёркивают) .

ISPmanager (актуально для King Servers)

King Servers предлагает VPS/VDS с предустановленной ISPmanager . По документации ISPmanager web‑интерфейс доступен по HTTPS на порту 1500 . В server requirements ISPmanager также перечисляет типовой набор портов для веба, почты, DNS и базы данных .

Минимальная «разумная» модель:

• 1500/tcp — только с ADMIN_IP;
• 80/443 — публично (если хостите сайты);
• mail/dns/db — открывать только если реально используете и понимаете, кому они доступны.

UFW (пример для ISPmanager + web)

sudo ufw default deny incomingsudo ufw default allow outgoing# SSH (admin-only)sudo ufw allow from ADMIN_IP to any port SSH_PORT proto tcp# ISPmanager UI (admin-only): порт 1500 по умолчанию sudo ufw allow from ADMIN_IP to any port 1500 proto tcp# Websudo ufw allow 80/tcpsudo ufw allow 443/tcpsudo ufw logging lowsudo ufw enable

iptables (пример)

cat > ~/rules.v4 <<'EOF'*filter:INPUT DROP [0:0]:FORWARD DROP [0:0]:OUTPUT ACCEPT [0:0]-A INPUT -i lo -j ACCEPT-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT# SSH admin-only-A INPUT -p tcp -s ADMIN_IP --dport SSH_PORT -m conntrack --ctstate NEW -j ACCEPT# ISPmanager UI admin-only (1500)-A INPUT -p tcp -s ADMIN_IP --dport 1500 -m conntrack --ctstate NEW -j ACCEPT# Web-A INPUT -p tcp --dport 80  -m conntrack --ctstate NEW -j ACCEPT-A INPUT -p tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPTCOMMITEOFsudo iptables-restore --test < ~/rules.v4sudo iptables-apply -t 60 ~/rules.v4

nftables (пример)

flush rulesettable inet filter {  chain input {    type filter hook input priority 0; policy drop;    iif "lo" accept    ct state established,related accept    ip saddr ADMIN_IP tcp dport { SSH_PORT, 1500 } ct state new accept    tcp dport { 80, 443 } ct state new accept  }  chain forward { type filter hook forward priority 0; policy drop; }  chain output  { type filter hook output  priority 0; policy accept; }}

Другие панели: Plesk / cPanel / DirectAdmin (быстрые ориентиры)

• Plesk: административный интерфейс обычно на 8443/tcp (HTTPS), а также сервисные порты для веба/почты/DNS перечислены в официальной базе знаний Plesk .
• cPanel/WHM: список портов и рекомендацию «открывать только используемые» даёт сама документация cPanel .
• DirectAdmin: по умолчанию слушает 2222 .

Принцип одинаковый: порт панели — только с ADMIN_IP, а веб/почта — по необходимости.

Persistence, логирование и fail2ban

Как сделать, чтобы правила сохранялись после перезагрузки

UFW.ufw enable не просто включает фильтрацию — он «включает firewall на boot» (прямо указано в manpage) . Если после reboot правила «неожиданно пропали», частая причина — конфликт с другим сервисом, который позже перезаписывает iptables (это типовой класс проблем, и его диагностируют через journalctl -b -u ufw.service) .

nftables.На Ubuntu пакет nftables содержит systemd unit, который может автоматически загружать конфиг из /etc/nftables.conf при старте системы . В Debian правила по умолчанию тоже ожидаются в /etc/nftables.conf, а systemctl enable nftables.service включает nftables на boot .

iptables (Debian/Ubuntu).Самый практичный путь — netfilter-persistent / iptables-persistent. Debian прямо описывает netfilter-persistent как загрузчик netfilter‑конфигурации на boot/halt и систему плагинов для iptables/ip6tables .

iptables (CentOS/RHEL‑подобные).На старых ветках (RHEL 6/7, CentOS 6/7) классика — сохранение в /etc/sysconfig/iptables и автоприменение сервисом iptables; Red Hat описывает это как «rules applied whenever service started or machine rebooted» . На RHEL 8+ чаще выбирают firewalld/nftables, а iptables‑утилита работает поверх nf_tables (совместимость) .

Логирование: что включить, чтобы не утонуть

UFW умеет включать/выключать logging и задавать уровень, а также логировать конкретные правила (allow log …) .

nftables имеет statement log с префиксом и может сочетать log+accept в одной строке — удобнее, чем классический iptables‑подход .

Пример nftables: логировать новые SSH‑подключения (и принять):

tcp dport SSH_PORT ct state new log prefix "NEW SSH: " accept

Fail2ban (минимум для SSH)

Fail2ban отслеживает логи и банит IP с множественными ошибками, обновляя правила firewall . Если вы используете nftables, в fail2ban есть соответствующие actions (например, nftables.conf, nftables-multiport.conf) .

Минимальный пример /etc/fail2ban/jail.local (идея, не догма):

[sshd]enabled = truemaxretry = 5findtime = 10mbantime  = 1h

Здесь важно не «магия конфига», а принцип: firewall закрывает поверхность, fail2ban добавляет динамический «анти‑перебор» поверх.

Шпаргалка: чек-лист деплоя и quick reference по UFW vs iptables vs nftables

Короткий чек‑лист перед тем, как нажать Enter

1) У вас есть консоль/Rescue у провайдера на случай lockout .2) Открыта вторая SSH‑сессия, лучше в tmux .3) Вы знаете SSH_PORT и свой ADMIN_IP.4) Сделан бэкап текущих правил (iptables-save / nft list ruleset).5) Правило на SSH добавлено до включения default deny.6) После применения выполнены проверки: ss, ufw status / iptables -S / nft list ruleset.7) Настроено persistence (UFW enable; nftables.service; netfilter-persistent).8) Включено умеренное логирование и вы знаете, где смотреть (journalctl, syslog).

One-page quick reference: сравнение инструментов