Послуги із забезпечення мережевої безпеки

Мережева безпека: SIEM (Wazuh, Splunk), IDS/IPS (Suricata, Snort), WAF, firewall-аудит, penetration testing, compliance (ISO 27001, SOC 2, PCI DSS).
Показано 30 з 42Усі 1054 послуг
Wildcard TLS у Kubernetes через DNS-01 та GitOps
Середній
від 4 годин до 2 днів
Налаштування PAM на Linux: політики, 2FA, LDAP
Середній
від 1 дня до 3 днів
Часті запитання

Наші компетенції:

Останні роботи

  • Розробка сайту компанії B2B ADVANCE
    Розробка сайту компанії B2B ADVANCE
    1542
  • Розробка веб-додатків для компанії FEEDME
    Розробка веб-додатків для компанії FEEDME
    1393
  • Розробка веб-сайту для компанії БЕЛФІНГРУП
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    1081
  • Розробка інтернет магазину для компанії FURNORO
    Розробка інтернет магазину для компанії FURNORO
    1368
  • Розробка логотипу компанії B2B Advance
    Розробка логотипу компанії B2B Advance
    815
  • Розробка веб-додатків для компанії Enviok
    Розробка веб-додатків для компанії Enviok
    1139

Мережева безпека: SIEM, IDS, аудит та compliance

У логах nginx за три дні — 2,3 мільйона запитів. З них 40 тисяч з одного /24‑діапазону, патерн /admin, /wp-login, /.env, /config.php. Класичний сканер — автоматично блокується fail2ban, якщо він налаштований. Якщо ні, запити просто йдуть ухолосту. А поряд, у тих же логах, один рядок: успішний POST /api/v2/export з токеном сесії, який п'ять хвилин тому був створений з IP у Нідерландах, хоча користувач завжди ходить з Москви. Цей рядок fail2ban не знайде. Ми щодня стикаємося з такими кейсами і за роки практики виробили системний підхід: SIEM + IDS/IPS + compliance‑аудит. Зв'яжіться з нами для аудиту вашої мережі.

Які проблеми вирішуємо: від сканерів до прихованих витоків

Сучасні атаки рідко бувають прямолінійними. Ми бачимо три основні напрями:

  • Сканування та брутфорс — масові атаки на веб‑додатки (WordPress, Jenkins, GitLab). Обробляються fail2ban, iptables, nginx-лімітами. Але якщо їх не налаштувати — вразливість на автопілоті.
  • Ексфільтрація даних — запити до API з незвичайних геолокацій, нестандартні обсяги вивантажень. fail2ban їх не бачить, потрібна кореляція подій за користувачем та поведінкою.
  • Compromise внутрішніх хостів — після фішингу або експлойту зловмисник отримує доступ до рідко використовуваних серверів. Logwatch або стандартні auditd не спрацьовують, а SIEM з FIM та правилами аномалій — так.

Докладніше розберемо інструменти та підходи, які ми застосовуємо.

Чому SIEM виявляє те, що не бачить fail2ban?

fail2ban аналізує частоту однотипних подій — 5 невдалих логінів за хвилину, 404 з одного IP. Це працює проти брутфорсу. Але якщо атакуючий робить один запит з різних IP (мережа ботів) або використовує легітимну сесію (вкрадений токен), fail2ban непотрібний. SIEM корелює події за різними ознаками: геолокація, часовий ряд, послідовність дій, стрибки обсягів трафіку. Wazuh з кастомними правилами — типове рішення.

Wazuh SIEM: від встановлення до реальної користі

Wazuh — це не просто IDS. Це SIEM з агентами, файловим моніторингом (FIM), детекцією вразливостей та compliance‑перевірками в одному стеку: Wazuh Manager + Elasticsearch/OpenSearch + Kibana/OpenSearch Dashboards.

Архітектура: Manager отримує події від агентів (Linux, Windows, macOS). Агенти збирають системні логи (/var/log/auth.log, Windows Event Log), syscheck (зміни файлів), rootcheck, а також виконують активні відповіді.

Як налаштувати кореляцію подій для детекції аномалій?

Дефолтні правила Wazuh покривають очевидне: брутфорс SSH, sudo‑ескалацію, зміни /etc/passwd. Реальна цінність — у кастомних правилах під специфіку додатка. Приклад для детекції аномального експорту даних:

<rule id="100200" level="12"> <if_sid>31100</if_sid> <url>/api/v2/export</url> <description>Data export API called — potential exfiltration</description> <group>web,data_exfiltration</group> </rule> <rule id="100201" level="15"> <if_sid>100200</if_sid> <different_srcgeoip>yes</different_srcgeoip> <same_field>data.src_user</same_field> <timeframe>3600</timeframe> <description>Data export from unusual geolocation for this user</description> <group>web,data_exfiltration,anomaly</group> </rule> 

Правило 100201 спрацює, якщо один і той самий користувач робить запит до /api/v2/export з іншої країни протягом години — кореляція за користувачем та геолокацією.

FIM для критичних директорій з inotify (realtime="yes") фіксує зміни негайно, не за розкладом. report_changes="yes" для /etc покаже diff прямо в алерті.

Active Response — при 8 невдалих SSH‑спробах за 60 секунд IP блокується через iptables на 10 хвилин. Акуратно з параметром location: all — це заблокує IP на всіх агентах одразу, включаючи production.

На одному проекті fail2ban не реагував на запити до /api/internal/status — їх було лише кілька на годину. Але Wazuh з правилом на нестандартний URI (не описаний в документації) та перевіркою геолокації відправив алерт level 10. Виявилося, що це бот з Південно-Східної Азії шукав відкриті ендпоїнти. Блокування на рівні WAF вирішило проблему.

Suricata IDS: налаштування мережевого периметра

Suricata — high‑performance IDS/IPS з multi‑threading. Працює в пасивному режимі (IDS) та inline (IPS). Принципове налаштування:

af-packet: - interface: eth0 threads: 4 cluster-id: 99 cluster-type: cluster_flow defrag: yes 

cluster_flow гарантує, що всі пакети одного TCP‑з'єднання обробляються одним потоком — критично для коректної збірки TCP‑потоку.

eve.json у форматі JSON відправляється безпосередньо в Wazuh або Elasticsearch. Кібанівський Security App працює з ним нативно.

Порівняння IDS/IPS‑інструментів для мережевої безпеки

Інструмент Режим Продуктивність Інтеграція з SIEM Типове застосування
Suricata IDS/IPS 10+ Gbps на багатоядерному CPU Відмінна (eve.json) Периметр, inline-блокування
Snort IDS/IPS 1-2 Gbps (single thread) Через barnyard2 Legacy-мережі, правило‑орієнтований аналіз
Zeek IDS (аналіз) 5+ Gbps Через JSON-лог Глибокий протокольний аналіз, метадані
OSSEC (Wazuh) HIDS Залежить від агентів Вбудована Хости, FIM, compliance

Suricata в 3-5 раз продуктивніша за Snort на однаковому залізі завдяки багатопоточності та підтримці AF_PACKET.

Мережева безпека: що перевіряємо системно під час аудиту

Структурований аудит охоплює кілька шарів:

  • Vulnerability scanning — OpenVAS/Greenbone для мережі, Trivy для контейнерів. trivy image --severity HIGH,CRITICAL nginx:latest у CI/CD блокує образи з критичними CVE до деплою.
  • Compliance — lynis audit system дає hardening index та конкретні рекомендації; CIS‑CAT Pro — детальний мапінг на CIS Benchmarks з pass/fail по кожному пункту.
  • Мережевий аудит — nmap -sV -sC -O --script vuln на периметрі дає знімок відкритих портів, версій сервісів, відомих вразливостей; --script ssl-enum-ciphers перевіряє підтримку слабких шифрів.
  • Хмарний аудит — ScoutSuite для AWS/GCP/Azure: відкриті S3 buckets, security groups з 0.0.0.0/0, IAM‑користувачі без MFA, незашифровані EBS.

Кожен клієнт отримує звіт зі знайденими проблемами, їх критичністю та планом виправлення. Закажіть повний аудит безпеки — ми перевіримо всі рівні вашої інфраструктури.

Як підготувати інфраструктуру до аудиту мережі?

Перед початком аудиту зберіть схему мережі, список усіх серверів і сервісів, інформацію про те, які порти відкриті назовні. Це прискорить роботу та зменшить кількість хибних спрацювань. Наприклад, якщо на сервері стоїть Jenkins на порту 8080, сканер може позначити його як потенційно небезпечний, але ви це знаєте — виключаємо зі списку. Аудит без такої інформації займає на 30-40% більше часу.

Кроки, які ми рекомендуємо виконати до аудиту:

  1. Сформуйте актуальну топологію мережі (схема, IP-адресація, VLAN).
  2. Зберіть логіни та паролі для доступу до ключових систем (SSH, веб-інтерфейси, API).
  3. Підготуйте список дозволених зовнішніх IP та сервісів.
  4. Визначте критичні активи (БД, сховища, контролери домену).
  5. Забезпечте доступ до логів та конфігураційних файлів.

Compliance: як підготуватися до PCI DSS та ISO 27001?

Compliance — це не лише документи. Технічні вимоги PCI DSS 4.0 включають контролі, які потрібно реалізувати в інфраструктурі:

  • Requirement 6.3.3: всі компоненти оновлено — автоматичний scanning + patch management.
  • Requirement 10.3: логи захищено від зміни — centralized log management з write‑once сховищем.
  • Requirement 8.3.6: MFA для всього нетконсольного адміністративного доступу.

Wazuh з compliance‑модулем генерує готові звіти по PCI DSS, HIPAA, GDPR з мапінгом алертів на конкретні вимоги.

Як ми працюємо: етапи та результати

Ми надаємо:

  • Звіт по аудиту — список вразливостей, критичність, рекомендації.
  • Робочий SIEM — встановлений та налаштований Wazuh з кастомними правилами.
  • IDS на периметрі — Suricata з правилами Emerging Threats, інтегрована в систему моніторингу.
  • Документація — архітектурна схема, конфігурації, runbook для реагування на інциденти.
  • Навчання команди — як читати алерти, писати правила, працювати з Kibana.
  • Підтримка — 2 тижні пост‑проектного супроводу.

Етапи співпраці:

  1. Аудит інфраструктури — збір даних, сканування, аналіз логів.
  2. Проектування рішення — вибір інструментів, архітектура, правила.
  3. Розгортання — встановлення Wazuh, Suricata, налаштування інтеграцій.
  4. Тестування — перевірка алертів, симуляція атак, навчання команди.
  5. Здача — документація, супровід, рекомендації щодо подальшого моніторингу.

Терміни та вартість

Завдання Термін
Базовий аудит (до 20 хостів) 3–5 днів
Розгортання Wazuh SIEM (до 50 агентів) 1–2 тижні
Налаштування Suricata IDS на периметрі 3–5 днів
Повний penetration test + звіт 2–4 тижні
Підготовка до PCI DSS / ISO 27001 4–12 тижнів

Вартість розраховується індивідуально після аудиту. Інвестиція в безпеку окупається багаторазово — середній запобігнутий збиток від витоку даних, за даними IBM, становить мільйони доларів.

Отримайте консультацію з налаштування SIEM та аудиту мережі — ми об'єктивно оцінимо вашу інфраструктуру та запропонуємо план дій. Звертайтеся до нас: багаторічний досвід, 30+ впроваджень SIEM, 5 років на ринку, працюємо з компаніями від стартапів до enterprise. Зв'яжіться для обговорення вашого завдання.