VPN, SSH та базова безпека інфраструктури

event 30.05.2026 10:00
| category Security | person iron_will | comment 0 | visibility 11 | |

Вступ

Сучасна IT-інфраструктура функціонує в умовах постійного зовнішнього впливу: сканування портів, автоматизовані брутфорс-атаки, експлуатація вразливостей сервісів та цільові кібератаки. Навіть невеликі системи без належного захисту можуть стати об’єктом компрометації протягом кількох хвилин після появи в публічному інтернеті.

VPN та SSH залишаються базовими, але критично важливими компонентами захищеної інфраструктури. Вони забезпечують шифровану взаємодію між вузлами, контроль доступу та мінімізацію поверхні атаки. Однак їх неправильна конфігурація часто створює ілюзію безпеки замість реального захисту.

Ця стаття розглядає практичні підходи до побудови базового рівня безпеки інфраструктури з використанням VPN і SSH, включно з прикладами конфігурацій, типовими помилками та рекомендаціями, які застосовуються в реальних production-середовищах.

Роль VPN та SSH у сучасній інфраструктурі

VPN як захищений транспортний шар

VPN (Virtual Private Network) створює зашифрований тунель між клієнтом і приватною мережею. Його основна функція - приховати внутрішню інфраструктуру від публічного доступу та забезпечити контрольований вхід.

Основні сценарії використання:

  • Доступ до внутрішніх сервісів (адмін-панелі, CI/CD, бази даних)
  • З’єднання між дата-центрами або хмарними середовищами
  • Безпечний віддалений доступ співробітників
  • Сегментація мережі

Ключові вимоги до VPN у production:

  • Сильна криптографія (AES-256-GCM або ChaCha20-Poly1305)
  • Мінімальна затримка
  • Підтримка MFA
  • Логування підключень
  • Ротація ключів

SSH як базовий інструмент адміністрування

SSH (Secure Shell) використовується для віддаленого керування системами та автоматизації.

Його ключові можливості:

  • Захищене виконання команд
  • Тунелювання портів
  • Передача файлів (SCP/SFTP)
  • Автоматизація (Ansible, CI/CD)

SSH часто стає першою ціллю атак, тому його безпека критично важлива.

Архітектурний підхід до базової безпеки

Правильна модель безпеки будується за принципом defense in depth:

  1. Мережевий рівень (firewall, VPN)
  2. Рівень автентифікації (SSH keys, MFA)
  3. Рівень сервісів (ізоляція процесів)
  4. Моніторинг і аудит

Ключова мета - ніколи не виставляти критичні сервіси напряму в інтернет.

Налаштування SSH: безпечна базова конфігурація

1. Заборона входу по паролю

Парольна автентифікація є найбільш вразливою до brute-force атак.

Файл конфігурації:
/etc/ssh/sshd_config

PasswordAuthentication no
PermitRootLogin no
PubkeyAuthentication yes

2. Використання SSH-ключів

Генерація ключа:

ssh-keygen -t ed25519 -C "admin@company"

Копіювання ключа на сервер:

ssh-copy-id user@server-ip

3. Обмеження доступу за користувачами

AllowUsers deploy admin

4. Зміна стандартного порту (опціонально)

Port 2222

Важливо: зміна порту не є засобом безпеки, але знижує кількість автоматичних сканувань.

5. Додаткові параметри безпеки

ClientAliveInterval 300ClientAliveCountMax 2MaxAuthTries 3

Захист SSH через Fail2Ban

Fail2Ban автоматично блокує IP-адреси після невдалих спроб входу.

Встановлення:

sudo apt install fail2ban

Базова конфігурація:

/etc/fail2ban/jail.local

[sshd]
enabled = true
port = 22
maxretry = 3
bantime = 3600
findtime = 600

VPN-рішення: практичний огляд

WireGuard як сучасний стандарт

WireGuard є легким і високопродуктивним VPN-протоколом, який активно використовується в сучасних інфраструктурах.

Переваги:

  • Мінімальний кодовий базис
  • Висока швидкість
  • Простота конфігурації
  • Вбудована криптографія

Приклад конфігурації WireGuard (сервер)

[Interface]
Address = 10.10.0.1/24
ListenPort = 51820
PrivateKey = <server_private_key>

PostUp = iptables -A FORWARD -i %i -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

PostDown = iptables -D FORWARD -i %i -j ACCEPT
PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

Конфігурація клієнта

[Interface]
PrivateKey = <client_private_key>
Address = 10.10.0.2/24

[Peer]
PublicKey = <server_public_key>
Endpoint = vpn.example.com:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

OpenVPN як корпоративне рішення

OpenVPN використовується у великих корпоративних середовищах через гнучкість і підтримку складних сценаріїв.

Ключові особливості:

  • Підтримка TLS
  • Гнучка маршрутизація
  • Інтеграція з LDAP/AD
  • Підтримка MFA

Мережевий рівень безпеки

Базові правила firewall

Приклад UFW:

ufw default deny incoming
ufw default allow outgoing

ufw allow 22/tcp
ufw allow 51820/udp
ufw enable

Розділення мережі (network segmentation)

Рекомендована модель:

  • Public subnet: веб-сервери
  • Private subnet: бази даних
  • Management subnet: SSH/VPN доступ

Типові помилки в інфраструктурі

1. Відкритий SSH в інтернет без обмежень

Це дозволяє автоматизовані brute-force атаки 24/7.

2. Використання паролів замість ключів

Паролі легко підбираються або викрадаються через фішинг.

3. Відсутність логування

Без логів неможливо виявити компрометацію.

4. Надмірні права доступу

Принцип least privilege часто ігнорується.

Практичний кейс: захищена інфраструктура малого проєкту

Вхідні умови

  • 3 сервери (web, api, db)
  • віддалена команда розробників
  • публічний доступ лише до web

Рішення

  1. SSH закритий ззовні, доступ тільки через VPN
  2. WireGuard як єдина точка входу
  3. Fail2Ban на всіх вузлах
  4. UFW з default deny policy
  5. Key-based SSH authentication
  6. Моніторинг логів через centralized logging (ELK або Loki)

Схема доступу

  • Користувач → VPN → приватна мережа → SSH → сервери
  • Відсутній прямий доступ до backend та DB

Приклад автоматизації доступу через SSH config

Host prod-server
    HostName 10.10.0.10
    User deploy
    IdentityFile ~/.ssh/id_ed25519
    ProxyJump vpn-gateway

Моніторинг і аудит безпеки

Без моніторингу будь-яка система безпеки є неповною.
Рекомендовані підходи:

  • централізовані логи (ELK / Loki)
  • алерти на failed login attempts
  • auditd для системних змін
  • регулярні security scans
    Приклад перевірки логів SSH:
journalctl -u ssh | grep "Failed password"

Рекомендована модель безпеки для production

Мінімальний стандарт:

  • SSH тільки по ключах
  • VPN як єдина точка входу
  • Firewall з default deny
  • Fail2Ban на всіх вузлах
  • регулярна ротація ключів
  • централізоване логування

Розширений рівень:

  • MFA для VPN
  • Zero Trust Network Access (ZTNA)
  • сегментація мережі
  • SIEM-система

Висновки

VPN і SSH є фундаментальними компонентами безпечної інфраструктури, але їх ефективність залежить від правильної архітектури та конфігурації. Основний принцип полягає не лише у використанні шифрування, а у створенні багаторівневої системи захисту.

Найбільш критичні фактори безпеки:

  • мінімізація відкритих сервісів
  • контроль доступу через VPN
  • ключова автентифікація замість паролів
  • автоматичний захист від brute-force атак
  • постійний моніторинг

Правильно побудована базова інфраструктура значно знижує ризик компрометації навіть у разі появи нових вразливостей на рівні сервісів.

Related posts

Kubernetes для новачків: базові концепції

Вступ Сучасна розробка програмного забезпечення дедалі більше орієнтується на мікросервісну архітектуру, контейнеризацію та автоматизацію інфраструктури. У центрі цієї трансформації знаходиться Kubernetes - одна з найпопулярніших платформ оркестраці...

category Kubernetes person iron_will event 17/05/2026

Що таке RAID: рівні RAID, принцип роботи та навіщо він потрібен

Вступ У сучасній ІТ-інфраструктурі дані є одним із найцінніших ресурсів. Сервери, системи віртуалізації, бази даних, файлові сховища та резервні копії постійно працюють із великими обсягами інформації. Втрата даних через збій накопичувача може призв...

category System administration person iron_will event 10/05/2026

Docker: як оптимізувати розмір контейнера з 50 ГБ до керованого рівня

Вступ Контейнери давно стали стандартом де-факто для доставки застосунків у production. Проте з ростом складності систем часто виникає нетривіальна проблема - неконтрольоване збільшення розміру Docker-образів. Сценарій, коли образ досягає 30–50 ГБ,...

category DevOps person iron_will event 06/05/2026

Як знайти головну IP-адресу джерела DDoS у лог-файлі на 10 млн рядків у Linux

Вступ Коли сервер потрапляє під DDoS-атаку, одним із перших завдань адміністратора є швидке визначення джерел аномального трафіку. На практиці це означає аналіз великих лог-файлів вебсервера, балансувальника, firewall або reverse proxy. Якщо файл мі...

category System administration person iron_will event 25/04/2026

Kubernetes: сучасна платформа оркестрації контейнерів для production-середовищ

Вступ Kubernetes став де-факто стандартом для запуску контейнеризованих застосунків у production-середовищах. Якщо Docker вирішив проблему пакування застосунку разом із залежностями, то Kubernetes вирішує значно складніше завдання - як масштабувати,...

category DevOps person iron_will event 19/04/2026

Файлові системи ext4, XFS, Btrfs - що обрати для production

Вступ Вибір файлової системи в Linux-середовищі - це не просто технічна деталь, а стратегічне рішення, яке безпосередньо впливає на продуктивність, надійність і масштабованість інфраструктури. У production-системах, де критичними є стабільність і пе...

category DevOps person iron_will event 14/04/2026
cookie
This website uses cookies to improve your experience. Learn more