47 уязвимостей за один аудит: защита серверов медицинской сети

Задача клиента

В декабре 2025 года к нам в АйТи Фреш обратилась сеть медицинских клиник из Санкт-Петербурга — 5 филиалов, собственная IT-инфраструктура из 12 Linux-серверов (веб-порталы, медицинская информационная система, хранилище DICOM-снимков, серверы бэкапов).

Клиент столкнулся с критической ситуацией:

  • Требование сертификации — для продления лицензии и заключения договора с ОМС сети необходимо было пройти аудит информационной безопасности по требованиям 152-ФЗ (персональные данные) и приказу ФСТЭК N21
  • Предыдущий аудит провален — проверка выявила 47 критических уязвимостей: root-доступ по SSH с паролем, отсутствие firewall на 3 серверах, устаревшие пакеты с CVE
  • Инцидент безопасности — за месяц до обращения один из серверов был скомпрометирован через SSH brute-force, что привело к утечке адресов электронной почты пациентов
  • Сжатые сроки — повторный аудит назначен через 6 недель
  • Медицинские данные — серверы хранят персональные данные и медицинские карты 50 000+ пациентов, что требует повышенных мер защиты

Наша команда разработала и реализовала комплексную программу безопасности из 15 мер, охватывающую все уровни защиты: от SSH-hardening до системы обнаружения вторжений.

Принцип эшелонированной обороны

Каждый Linux-сервер, имеющий публичный IP-адрес, подвергается тысячам атак ежедневно: brute-force SSH, сканирование портов, эксплуатация уязвимостей, DDoS-атаки. По данным Sophos, среднее время компрометации незащищённого сервера в интернете составляет менее 20 минут. Для медицинской сети с персональными данными пациентов комплексный подход к безопасности — не опция, а жёсткое требование закона.

Мы построили защиту по принципу Defense in Depth — несколько независимых уровней. Если злоумышленник преодолеет один уровень, его остановит следующий:

Архитектура защиты, которую мы спроектировали

  • Сетевой уровень — firewall, port knocking, VPN
  • Аутентификация — SSH-ключи, 2FA, ограничение пользователей
  • Авторизация — sudo, SELinux/AppArmor, файловые права
  • Мониторинг — аудит, IDS, логирование
  • Восстановление — зашифрованные бэкапы, план реагирования

Меры 1-3: Hardening SSH

SSH — главная точка входа на сервер и первая цель атакующих. Именно через SSH был скомпрометирован один из серверов клиента. Мы начали именно с этого.

Мера 1: Отключение аутентификации по паролю

Первым делом мы перевели аутентификацию SSH на все 12 серверах исключительно на ключи:

# Генерируем SSH-ключ на клиенте (Ed25519 — быстрее и безопаснее RSA)
ssh-keygen -t ed25519 -C "admin@company.local" -f ~/.ssh/id_ed25519

# Копируем публичный ключ на сервер
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server

# Настраиваем сервер /etc/ssh/sshd_config
Port 2222                          # Нестандартный порт
Protocol 2
AddressFamily inet                 # Только IPv4
ListenAddress 0.0.0.0

# Аутентификация
PermitRootLogin no                 # Запрет входа root
PasswordAuthentication no          # Запрет паролей
PubkeyAuthentication yes           # Только ключи
ChallengeResponseAuthentication no
KbdInteractiveAuthentication no
UsePAM yes

# Ограничение пользователей
AllowUsers deploy admin
# Или по группам:
# AllowGroups ssh-users

# Таймауты
ClientAliveInterval 300
ClientAliveCountMax 2
LoginGraceTime 30
MaxAuthTries 3
MaxSessions 3

# Отключаем ненужное
X11Forwarding no
AllowTcpForwarding no
AllowAgentForwarding no
PermitTunnel no
GatewayPorts no

# Баннер
Banner /etc/ssh/banner.txt
# Проверяем конфигурацию
sudo sshd -t

# Перезапускаем (через существующую сессию!)
sudo systemctl restart sshd

# ВАЖНО: не закрывайте текущую сессию, пока не убедитесь, что новое подключение работает

Мера 2: Криптографическое усиление SSH

# Добавляем в /etc/ssh/sshd_config — разрешаем только современные алгоритмы

# Обмен ключами
KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256@libssh.org,curve25519-sha256

# Шифры
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com

# MAC
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

# Ключи хоста
HostKeyAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256

# Перегенерируем ключи хоста (удаляем устаревшие)
sudo rm /etc/ssh/ssh_host_dsa_key* /etc/ssh/ssh_host_ecdsa_key* 2>/dev/null
sudo ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ''
sudo ssh-keygen -t rsa -b 4096 -f /etc/ssh/ssh_host_rsa_key -N ''

Мера 3: Двухфакторная аутентификация (2FA) для SSH

# Устанавливаем Google Authenticator PAM-модуль
sudo apt install -y libpam-google-authenticator

# Настраиваем для каждого пользователя
su - admin
google-authenticator -t -d -f -r 3 -R 30 -w 3
# Сканируем QR-код в Google Authenticator / Authy

# Настраиваем PAM /etc/pam.d/sshd
# Добавляем строку:
auth required pam_google_authenticator.so nullok

# В /etc/ssh/sshd_config
AuthenticationMethods publickey,keyboard-interactive
ChallengeResponseAuthentication yes
KbdInteractiveAuthentication yes

sudo systemctl restart sshd

# Теперь при входе потребуется: SSH-ключ + OTP-код

Меры 4-6: Firewall и сетевая безопасность

На трёх серверах клиника вообще не была настроена фильтрация пакетов. Мы развернули nftables на всех 12 серверах с едиными правилами.

Мера 4: Настройка nftables на всех серверах

# /etc/nftables.conf

#!/usr/sbin/nft -f

flush ruleset

table inet filter {
    # Множество для автоматической блокировки
    set blacklist {
        type ipv4_addr
        flags timeout
    }

    # Множество доверенных IP
    set whitelist {
        type ipv4_addr
        elements = { 10.0.0.0/8, 192.168.0.0/16 }
    }

    chain input {
        type filter hook input priority 0; policy drop;

        # Разрешаем loopback
        iifname lo accept

        # Блокируем blacklist
        ip saddr @blacklist drop

        # Разрешаем established/related
        ct state established,related accept

        # Отбрасываем invalid
        ct state invalid drop

        # ICMP (ping) — ограничиваем
        ip protocol icmp icmp type echo-request limit rate 5/second accept

        # SSH (порт 2222)
        tcp dport 2222 ct state new limit rate 5/minute accept

        # HTTP/HTTPS
        tcp dport { 80, 443 } accept

        # Логируем отброшенное
        log prefix "[nftables DROP] " flags all counter drop
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
    }

    chain output {
        type filter hook output priority 0; policy accept;
    }
}

# Защита от сканирования портов
table inet portscan_protection {
    set port_scanners {
        type ipv4_addr
        flags dynamic,timeout
        timeout 1h
    }

    chain input {
        type filter hook input priority -10; policy accept;
        tcp flags & (fin|syn|rst|ack) == syn ct state new \
            limit rate over 20/minute \
            add @port_scanners { ip saddr timeout 1h } drop
    }
}
# Применяем
sudo nft -f /etc/nftables.conf
sudo systemctl enable nftables

# Проверяем правила
sudo nft list ruleset

Мера 5: Fail2ban — защита от brute-force

# Установка
sudo apt install -y fail2ban

# Создаём локальную конфигурацию
sudo cat > /etc/fail2ban/jail.local <<'EOF'
[DEFAULT]
bantime = 3600
findtime = 600
maxretry = 3
backend = systemd
action = %(action_mwl)s
ignoreip = 127.0.0.1/8 10.0.0.0/8

[sshd]
enabled = true
port = 2222
filter = sshd
maxretry = 3
bantime = 86400

[sshd-aggressive]
enabled = true
port = 2222
filter = sshd[mode=aggressive]
maxretry = 2
bantime = 604800

[nginx-http-auth]
enabled = true
port = http,https
filter = nginx-http-auth
maxretry = 5

[nginx-botsearch]
enabled = true
port = http,https
filter = nginx-botsearch
maxretry = 3
bantime = 86400

[nginx-limit-req]
enabled = true
port = http,https
filter = nginx-limit-req
maxretry = 10
bantime = 3600
EOF

sudo systemctl enable --now fail2ban

# Проверяем статус
sudo fail2ban-client status
sudo fail2ban-client status sshd

# Разбанить IP
sudo fail2ban-client set sshd unbanip 1.2.3.4

Мера 6: Port knocking для серверов с медицинскими данными

# Устанавливаем knockd
sudo apt install -y knockd

# Конфигурация /etc/knockd.conf
[options]
    UseSyslog
    Interface = eth0

[openSSH]
    sequence = 7000,8000,9000
    seq_timeout = 10
    tcpflags = syn
    command = /usr/sbin/nft add element inet filter whitelist { %IP% }
    cmd_timeout = 30
    stop_command = /usr/sbin/nft delete element inet filter whitelist { %IP% }

[closeSSH]
    sequence = 9000,8000,7000
    seq_timeout = 10
    tcpflags = syn
    command = /usr/sbin/nft delete element inet filter whitelist { %IP% }
# Включаем knockd
sudo systemctl enable --now knockd

# Стучимся с клиента
knock server.example.com 7000 8000 9000
ssh -p 2222 admin@server.example.com

# Или одной командой
knock server.example.com 7000 8000 9000 && ssh -p 2222 admin@server.example.com

Меры 7-9: Управление пользователями и правами

Принцип наименьших привилегий — фундамент безопасной системы. Особенно важен для медицинской инфраструктуры, где доступ к данным пациентов должен быть строго ограничен.

Мера 7: Правильная настройка sudo

# Создаём группу sudo-пользователей
sudo groupadd -r sudoers

# Настраиваем /etc/sudoers через visudo
sudo visudo

# Настройки безопасности sudo
Defaults    env_reset
Defaults    mail_badpass
Defaults    secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
Defaults    logfile="/var/log/sudo.log"
Defaults    log_input,log_output
Defaults    iolog_dir="/var/log/sudo-io/%{user}"
Defaults    passwd_timeout=1
Defaults    timestamp_timeout=5
Defaults    use_pty
Defaults    requiretty

# Запрещаем sudo для root
root ALL=(ALL:ALL) ALL

# Группа администраторов
%sysadmins ALL=(ALL:ALL) ALL

# Деплой-пользователь — ограниченные команды
deploy ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx, /usr/bin/systemctl restart app, /usr/bin/docker compose *

Мера 8: Аудит файловых разрешений

# Находим файлы с SUID/SGID битом
find / -type f \( -perm -4000 -o -perm -2000 \) -exec ls -la {} \; 2>/dev/null

# Удаляем ненужные SUID
sudo chmod u-s /usr/bin/chfn /usr/bin/chsh /usr/bin/newgrp

# Находим файлы, доступные для записи всем
find / -type f -perm -o+w ! -path "/proc/*" ! -path "/sys/*" 2>/dev/null

# Находим файлы без владельца
find / -nouser -o -nogroup 2>/dev/null

# Защищаем критические файлы
sudo chmod 600 /etc/shadow /etc/gshadow
sudo chmod 644 /etc/passwd /etc/group
sudo chmod 700 /root
sudo chmod 600 /etc/ssh/sshd_config
sudo chmod 600 /etc/crontab
sudo chmod 700 /etc/cron.d /etc/cron.daily /etc/cron.hourly /etc/cron.monthly /etc/cron.weekly

# Устанавливаем sticky bit на /tmp
sudo chmod 1777 /tmp /var/tmp

# Защищаем /boot
sudo chmod 700 /boot

Мера 9: Автоматические обновления безопасности

# Debian/Ubuntu — unattended-upgrades
sudo apt install -y unattended-upgrades apt-listchanges

# Включаем автообновления
sudo dpkg-reconfigure -plow unattended-upgrades

# Настройка /etc/apt/apt.conf.d/50unattended-upgrades
Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
    "${distro_id}ESMApps:${distro_codename}-apps-security";
};

// Автоматический перезапуск при необходимости (в 3:00)
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "03:00";

// Уведомление
Unattended-Upgrade::Mail "admin@company.local";
Unattended-Upgrade::MailReport "on-change";

// Удаление неиспользуемых зависимостей
Unattended-Upgrade::Remove-Unused-Dependencies "true";
Unattended-Upgrade::Remove-New-Unused-Dependencies "true";
# Проверяем работу
sudo unattended-upgrade --dry-run --debug

# Логи
tail -f /var/log/unattended-upgrades/unattended-upgrades.log

Меры 10-12: MAC, аудит и централизованное логирование

Для прохождения сертификации по 152-ФЗ обязательны Mandatory Access Control и системный аудит. Мы развернули оба компонента на всех 12 серверах.

Мера 10: AppArmor для ограничения сервисов

# Проверяем статус AppArmor
sudo aa-status

# Устанавливаем дополнительные профили
sudo apt install -y apparmor-profiles apparmor-profiles-extra apparmor-utils

# Создаём профиль для Nginx
sudo aa-genprof nginx
# Или вручную:
sudo cat > /etc/apparmor.d/usr.sbin.nginx <<'EOF'
#include 

/usr/sbin/nginx {
    #include 
    #include 

    capability net_bind_service,
    capability setuid,
    capability setgid,
    capability dac_override,

    /etc/nginx/** r,
    /var/log/nginx/** w,
    /var/www/** r,
    /run/nginx.pid rw,
    /var/lib/nginx/** rw,

    # Запрещаем доступ к остальным файлам
    deny /etc/shadow r,
    deny /etc/passwd w,
    deny /home/** rwx,
}
EOF

sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.nginx

# Переводим профиль в enforce mode
sudo aa-enforce /etc/apparmor.d/usr.sbin.nginx

# Проверяем
sudo aa-status | grep nginx

Мера 11: Системный аудит (auditd) — требование сертификации

# Устанавливаем
sudo apt install -y auditd audispd-plugins

# Конфигурация правил /etc/audit/rules.d/hardening.rules

# Мониторинг изменений в файлах аутентификации
-w /etc/passwd -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/gshadow -p wa -k identity
-w /etc/sudoers -p wa -k sudoers
-w /etc/sudoers.d/ -p wa -k sudoers

# SSH конфигурация
-w /etc/ssh/sshd_config -p wa -k sshd_config

# Мониторинг системных команд
-a always,exit -F arch=b64 -S execve -F euid=0 -k root_commands

# Мониторинг cron
-w /etc/crontab -p wa -k cron
-w /etc/cron.d/ -p wa -k cron
-w /var/spool/cron/ -p wa -k cron

# Мониторинг загрузки модулей ядра
-w /sbin/insmod -p x -k kernel_modules
-w /sbin/modprobe -p x -k kernel_modules
-w /sbin/rmmod -p x -k kernel_modules

# Попытки доступа к запрещённым файлам
-a always,exit -F arch=b64 -S open -F exit=-EACCES -k access_denied
-a always,exit -F arch=b64 -S open -F exit=-EPERM -k access_denied

# Мониторинг сетевых настроек
-a always,exit -F arch=b64 -S sethostname -S setdomainname -k network_changes
-w /etc/hosts -p wa -k network_changes
-w /etc/network/ -p wa -k network_changes

# Сделать конфигурацию неизменяемой (требует перезагрузки для изменения)
-e 2
# Применяем правила
sudo augenrules --load
sudo systemctl restart auditd

# Просмотр событий
sudo ausearch -k identity --start today
sudo aureport --auth --start today
sudo aureport --summary

Мера 12: Централизованное логирование со всех 12 серверов

# Настраиваем rsyslog для отправки логов на удалённый сервер
# /etc/rsyslog.d/60-remote.conf

# Отправляем все логи на центральный сервер
*.* @@log-server.company.local:514;RSYSLOG_SyslogProtocol23Format

# Локальные логи тоже сохраняем
*.* /var/log/syslog

# Ротация логов /etc/logrotate.d/custom
/var/log/auth.log
/var/log/syslog
/var/log/sudo.log
{
    daily
    rotate 90
    compress
    delaycompress
    missingok
    notifempty
    create 640 root adm
}
# Устанавливаем logwatch для ежедневных отчётов
sudo apt install -y logwatch

# Настраиваем ежедневную отправку
echo '/usr/sbin/logwatch --output mail --mailto admin@company.local --detail high' | sudo tee /etc/cron.daily/00logwatch
sudo chmod +x /etc/cron.daily/00logwatch

Меры 13-14: Hardening ядра и шифрование бэкапов

Настройка параметров ядра и защита резервных копий медицинских данных — критически важные меры для соответствия 152-ФЗ.

Мера 13: Hardening ядра Linux (sysctl)

# /etc/sysctl.d/99-hardening.conf

# === Защита от IP-спуфинга ===
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# === Запрет ICMP-redirect ===
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv6.conf.all.accept_redirects = 0

# === Запрет source routing ===
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0

# === Защита от SYN-flood ===
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.tcp_synack_retries = 2

# === Логирование подозрительных пакетов ===
net.ipv4.conf.all.log_martians = 1
net.ipv4.conf.default.log_martians = 1

# === Запрет IP-форвардинга (если не роутер) ===
net.ipv4.ip_forward = 0
net.ipv6.conf.all.forwarding = 0

# === Защита от MITM ===
net.ipv4.conf.all.arp_announce = 2
net.ipv4.conf.all.arp_ignore = 1

# === ASLR (Address Space Layout Randomization) ===
kernel.randomize_va_space = 2

# === Ограничение dmesg для непривилегированных пользователей ===
kernel.dmesg_restrict = 1

# === Защита символических ссылок ===
fs.protected_symlinks = 1
fs.protected_hardlinks = 1

# === Ограничение core dumps ===
fs.suid_dumpable = 0

# === BPF ограничения ===
kernel.unprivileged_bpf_disabled = 1
net.core.bpf_jit_harden = 2
# Применяем
sudo sysctl -p /etc/sysctl.d/99-hardening.conf

Мера 14: Шифрование резервных копий медицинских данных

#!/bin/bash
# /usr/local/bin/encrypted-backup.sh

set -euo pipefail

BACKUP_DIR="/backup"
ENCRYPT_KEY="/root/.backup-key.gpg"
REMOTE_DIR="backup-server:/encrypted-backups/$(hostname)"
DATE=$(date +%Y%m%d)

# Создаём ключ шифрования (один раз)
# gpg --gen-key
# gpg --export-secret-keys backup@company.local > /root/.backup-key.gpg

# Бэкап системных конфигов
tar czf - /etc /var/spool/cron /root/.ssh 2>/dev/null | \
    gpg --batch --yes --symmetric --cipher-algo AES256 \
    --passphrase-file /root/.backup-passphrase \
    --output "${BACKUP_DIR}/system_${DATE}.tar.gz.gpg"

# Бэкап базы данных
sudo -u postgres pg_dump -Fc app_production | \
    gpg --batch --yes --symmetric --cipher-algo AES256 \
    --passphrase-file /root/.backup-passphrase \
    --output "${BACKUP_DIR}/db_${DATE}.dump.gpg"

# Отправляем на удалённый сервер
rsync -az "${BACKUP_DIR}/" "${REMOTE_DIR}/"

# Удаляем локальные бэкапы старше 7 дней
find "${BACKUP_DIR}" -name "*.gpg" -mtime +7 -delete

# Проверяем целостность
gpg --batch --yes --passphrase-file /root/.backup-passphrase \
    --decrypt "${BACKUP_DIR}/db_${DATE}.dump.gpg" | pg_restore --list > /dev/null \
    && echo "Backup verification: OK" \
    || echo "Backup verification: FAILED"
# Расшифровка при восстановлении
gpg --batch --passphrase-file /root/.backup-passphrase \
    --decrypt db_20260331.dump.gpg | pg_restore -d app_production

Мера 15: Система обнаружения вторжений (IDS)

Система обнаружения вторжений — последний рубеж, который фиксирует факт компрометации, если все предыдущие меры были преодолены. Для медицинских данных это обязательное требование аудита.

AIDE — мониторинг целостности файлов

# Устанавливаем AIDE (Advanced Intrusion Detection Environment)
sudo apt install -y aide

# Настраиваем /etc/aide/aide.conf
# Мониторим критические директории
/etc p+i+u+g+sha256
/bin p+i+u+g+sha256
/sbin p+i+u+g+sha256
/usr/bin p+i+u+g+sha256
/usr/sbin p+i+u+g+sha256
/lib p+i+u+g+sha256
/usr/lib p+i+u+g+sha256

# Исключаем часто изменяемые файлы
!/var/log
!/var/cache
!/tmp
!/var/tmp
!/var/lib/docker
!/proc
!/sys
# Инициализируем базу данных
sudo aideinit
sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db

# Проверяем целостность
sudo aide --check

# Обновляем базу после легитимных изменений (обновления, установка ПО)
sudo aide --update
sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db

# Автоматическая проверка по cron
echo '0 5 * * * root /usr/bin/aide --check | mail -s "AIDE Report: $(hostname)" admin@company.local' | sudo tee /etc/cron.d/aide-check

Rkhunter — поиск rootkits

# Устанавливаем
sudo apt install -y rkhunter

# Обновляем базу
sudo rkhunter --update
sudo rkhunter --propupd

# Полная проверка
sudo rkhunter --check --skip-keypress

# Автоматическая ежедневная проверка
echo '30 4 * * * root /usr/bin/rkhunter --check --skip-keypress --report-warnings-only | mail -s "Rkhunter: $(hostname)" admin@company.local' | sudo tee /etc/cron.d/rkhunter-check

# Настройка /etc/rkhunter.conf
UPDATE_MIRRORS=1
MIRRORS_MODE=0
WEB_CMD="wget -q"
MAIL-ON-WARNING=admin@company.local
MAIL_CMD=mail

Итоговый чеклист, который мы передали аудиторам

Сводная таблица всех 15 мер для проверки:

#МераКоманда проверки
1SSH — только ключиgrep PasswordAuthentication /etc/ssh/sshd_config
2SSH — современная криптографияssh -Q cipher; ssh -Q kex
32FA для SSHgrep pam_google_authenticator /etc/pam.d/sshd
4nftables firewallsudo nft list ruleset
5Fail2bansudo fail2ban-client status
6Port knockingsudo systemctl status knockd
7Настройка sudosudo cat /var/log/sudo.log
8Файловые разрешенияfind / -perm -4000 -type f
9Автообновленияsudo unattended-upgrade --dry-run
10AppArmor/SELinuxsudo aa-status
11Аудит (auditd)sudo aureport --summary
12Централизованные логиlogger -t test 'check'; tail /var/log/syslog
13Hardening ядраsysctl -a | grep rp_filter
14Шифрование бэкаповfile /backup/*.gpg
15IDS (AIDE)sudo aide --check

Результаты внедрения

Комплексная программа безопасности была реализована за 4 недели на всех 12 серверах. Через 2 недели после завершения работ клиент прошёл повторный аудит ИБ. Вот измеримые результаты:

  • Аудит ИБ пройден с оценкой «отлично» — все 47 ранее выявленных уязвимостей устранены, ноль критических замечаний
  • Сертификация по 152-ФЗ получена — клиника продлила лицензию и заключила договор с ОМС
  • Brute-force атаки заблокированы — Fail2ban блокирует в среднем 2 000 IP-адресов в сутки, ни одна атака не прошла
  • 12 серверов защищены по единому стандарту — все 15 мер применены на каждом сервере
  • Двухфакторная аутентификация для всех администраторов — SSH-ключ + OTP-код
  • Шифрованные бэкапы — ежедневное резервное копирование с AES-256, хранение 90 дней
  • Мониторинг целостности файлов — AIDE проверяет системные файлы ежедневно и отправляет отчёт
  • Централизованное логирование — все события безопасности со всех 12 серверов агрегируются на центральном сервере с хранением 90 дней
  • Port knocking — серверы с медицинскими данными полностью невидимы при сканировании портов
  • Автоматические обновления безопасности — критические патчи устанавливаются автоматически в ночное время

После внедрения всех мер клиника не фиксировала ни одного инцидента безопасности. Ежемесячные отчёты Lynis показывают hardening index 87/100, что соответствует уровню enterprise-инфраструктуры.

Часто задаваемые вопросы

Начните с трёх самых критичных мер: 1) настройте SSH-аутентификацию только по ключам и отключите root-логин, 2) установите и настройте firewall (nftables или ufw), разрешив только необходимые порты, 3) установите fail2ban для защиты от brute-force. Эти три меры блокируют более 95% автоматизированных атак. Затем последовательно внедряйте остальные меры из списка.

Да, обязательно. Firewall защищает от внешних сетевых атак, а SELinux/AppArmor ограничивает возможности процессов внутри системы. Если злоумышленник эксплуатирует уязвимость в веб-приложении и получает shell, AppArmor не позволит процессу nginx читать /etc/shadow или записывать в /root. Это разные уровни защиты, которые дополняют друг друга.

Автоматические проверки (AIDE, rkhunter) — ежедневно. Анализ логов аудита (auditd) — еженедельно. Полный ручной аудит с проверкой всех 15 мер — ежемесячно. Тестирование на проникновение (pentest) — ежеквартально или после существенных изменений в инфраструктуре. Используйте инструменты Lynis (lynis audit system) для автоматизированного аудита.

Признаки компрометации: неизвестные процессы в ps aux, неизвестные учётные записи в /etc/passwd, изменённые системные бинарники (проверьте через debsums -c или rpm -Va), подозрительные соединения в ss -tlnp, необъяснимая нагрузка на CPU/сеть, изменённые cron-задачи, файлы в /tmp или /dev/shm. Используйте rkhunter и chkrootkit для поиска rootkits. При подозрении — изолируйте сервер от сети и анализируйте офлайн.

Большинство мер (SSH hardening, firewall, fail2ban, sudo) практически не влияют на производительность. AppArmor добавляет 1-3% overhead. Аудит (auditd) может добавить до 5% overhead при агрессивных правилах — настройте только необходимые. AIDE проверка выполняется по cron в нерабочее время. Шифрование бэкапов увеличивает время бэкапа на 10-20%. В целом, суммарное влияние на производительность не превышает 5%, что несопоставимо с последствиями взлома.

Нужна помощь с настройкой?

Специалисты АйТи Фреш помогут с внедрением и настройкой — 15+ лет опыта, обслуживание от 15 000 ₽/мес

📞 Связаться с нами
#безопасность Linux сервера#SSH hardening Linux#fail2ban настройка#firewall Linux nftables#Linux аудит безопасности#SELinux AppArmor#двухфакторная аутентификация SSH#port knocking Linux