Анализатор сетевой безопасности

Аудит сетевой безопасности: гибридная инфраструктура интернет-магазина (PCI DSS)

0. Допущения и вопросы (сначала прочитайте)

В предоставленных данных есть противоречия, которые влияют на выводы. Ниже перечислены допущения, на которых построен анализ.

Аудит будет проводиться по PCI DSS v4.0.1: v4.0 выведен из обращения 31.12.2024. Требования с отложенным сроком (в том числе 8.4.2 MFA для любого доступа в CDE и 10.4.1.1 автоматизированный анализ логов) обязательны с 31.03.2025. Ниже номера требований указаны по v4.0.1.

1. Сводка рисков

2. Детальный разбор

F1. Возможная компрометация и выгрузка данных из CDE

Суть. Хронология из лога:

• 03:14:02–05: перебор root и admin с внешнего 198.51.100.44.
• 03:14:09: неудачный пароль developer с 10.10.10.87.
• 03:14:12: успешный вход с того же адреса.
• 03:15:40: sudo mysqldump --all-databases от имени root.

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

Последствия. Возможная утечка PAN и других данных держателей карт. Это обязывает уведомить эквайера и платёжные системы и может повлечь расследование силами PFI-аудитора. При подтверждённом инциденте сроки сертификационного аудита, скорее всего, сдвинутся.

Вектор. Украденный или подобранный пароль либо компрометация хоста 10.10.10.87, затем прямой SSH в CDE, затем sudo без ограничений.

Не начинайте hardening pci-db01 и 10.10.10.87, пока не сохранены артефакты. Если окажется, что это был пентест, пусть подрядчик подтвердит это письменно. Тогда F1 закрывается как «легитимная активность» с доказательной базой.

F2. permit ip any any на outside

Суть. Все правила выше этой строки бессмысленны: разрешено всё, что достижимо по маршрутизации и NAT. Кроме того (см. допущение 2), вполне возможно, что опубликованные сервисы работают именно благодаря этой строке.

Последствия. Любой сервис с трансляцией адреса доступен из интернета. Это прямое несоответствие 1.3.1/1.4.2, и при таком ACL внешний ASV-скан (11.3.2) почти наверняка не будет пройден.

Вектор. Сканирование интернета, обнаружение забытых сервисов, эксплуатация.

F3. MSSQL из интернета

Суть. Требование 1.4.4 прямо запрещает прямой доступ из недоверенных сетей к компонентам, хранящим данные держателей карт.

Вектор. Перебор sa и SQL-логинов, эксплуатация уязвимостей TDS и непропатченного SQL Server 2017. После входа — xp_cmdshell и RCE, если он включён. MSSQL на 1433 — одна из самых сканируемых целей в интернете.

F4, F5, F6. Отсутствие сегментации CDE

Суть. Правило 0.0.0.0/0 → 10.10.30.0/24 ACCEPT стоит до финального DROP, поэтому весь CDE открыт для любых сегментов: офисов, DMZ, VPN-пула и, через ASA, интернета. Правила для VLAN10 открывают SSH, RDP и 1433 для всех ~250 адресов /24, а не для конкретных администраторов.

Последствия.

• Вся сеть (450 узлов, 3 офиса, AWS) попадает в scope PCI DSS, потому что сегментация не работает.
• Тест сегментации (11.4.5) будет провален.
• Компрометация любой офисной машины (фишинг) даёт путь к картам.

F7, F8. Пароли и неограниченный sudo

Failed/Accepted password означает, что PasswordAuthentication включена. В сочетании с ALL=(ALL) ALL у разработчика это даёт путь от одного пароля до root на сервере с картами.

Кроме того, по 6.5.4 роли в продуктиве и в разработке должны быть разделены: разработчик не должен иметь привилегированного доступа к продуктивной БД с PAN.

F9, F10. RDP и устаревший SSH в интернет

• RDP. NLA снижает риск (BlueKeep-подобные pre-auth уязвимости), но остаются перебор паролей, password spraying против AD и атаки на сам сервис. Для удалённого доступа нужны VPN и MFA (8.4.3).
• SSH. OpenSSH 8.2p1 уязвим к Terrapin (CVE-2023-48795) и ряду других CVE. Под regreSSHion (CVE-2024-6387, затрагивает 8.5p1–9.7p1) эта версия формально не попадает, но сама ОС вне стандартной поддержки. Это нарушение 6.3.3, если нет ESM-патчей.

F11. Мониторинг

fail2ban — локальная реактивная мера, а не система обнаружения. Нет признаков:

• SIEM с корреляцией (событие «вход в CDE не с jump-host» + «массовый дамп» + «ночное время»);
• IDS/IPS на границе CDE (11.5.1);
• контроля целостности файлов (11.5.2);
• централизованного хранения логов 12 месяцев, из них 3 месяца в оперативном доступе (10.5.1).

Высокие счётчики fail2ban (1284 попытки) говорят о том, что сервис вообще не должен быть доступен атакующему, а не о том, что защита работает.

F12. Egress

Если исходящий трафик из CDE не ограничен, выгрузку данных наружу ничто не останавливает: нет контроля по 1.3.2 и нет возможности обнаружить утечку по блокировкам.

F13–F15

• Неучтённые хосты и неясная топология NAT — это проблема scope. QSA потребует актуальные сетевую схему и схему потоков данных (1.2.3, 1.2.4).
• Баннер Postfix облегчает подбор эксплойтов.
• HTTP/80 допустим только как редирект на HTTPS.

3. План усиления (6 недель)

Работы разбиты на фазы по приоритету. Все изменения межсетевых экранов проводятся через change management (1.2.2) с записанным планом отката.

Фаза 0. Сутки 0–1: реагирование на F1 (параллельно с фазой 1)

1. Выяснить, пентест это или нет. Запросить у подрядчика журнал активности за 21.09 03:00–03:30 и список исходных IP.
2. Сохранить артефакты до любых изменений (на pci-db01, с записью хэшей):

   sudo tar czf /root/ir-$(hostname)-$(date +%F).tgz /var/log/auth.log* /var/log/syslog* \
        /home/developer/.bash_history /root/.bash_history /etc/sudoers /etc/sudoers.d
   sha256sum /root/ir-*.tgz
   last -F; lastb -F | head -200            # история входов
   grep -E "Accepted|session opened" /var/log/auth.log*    # были ли успешные входы с 198.51.100.44
   sudo find / -xdev -newermt "2025-09-21 03:10" ! -newermt "2025-09-21 04:00" -type f 2>/dev/null
   ss -tanp                                 # текущие соединения
   

   (Подставьте год события. find ищет, куда записан дамп.) Проверить в логах ASA и pfSense исходящие передачи с 10.10.30.15 и 10.10.10.87 в этом окне.
3. Хост 10.10.10.87. Изолировать через EDR или перевести порт в карантинный VLAN, а не выключать: память нужна для анализа. Снять образ.
4. Учётные данные. Заблокировать учётную запись developer на серверах CDE, сменить пароли и ключи, проверить AD-учётку разработчика и его активные сессии.
5. Если выгрузку не удаётся объяснить пентестом, запустить план реагирования (12.10.1): эскалация руководству, уведомление эквайера в договорные сроки, привлечение PFI при необходимости. Об этом стоит сразу сказать QSA.

Фаза 1. Дни 1–3: закрыть периметр (F2, F3, F9, F10)

1.1. Оценить, что реально проходит через permit ip any any (несколько часов, но не недель):

show access-list OUTSIDE_IN | include any any
show conn | include 203.0.113
show run nat
show run access-group

ASA — stateful-экран: ответный трафик на исходящие соединения не зависит от входящего ACL. VPN, терминируемый на самом ASA, тоже не проходит через interface ACL (при sysopt connection permit-vpn). Поэтому риск поломки ограничен недокументированными входящими публикациями. Их и нужно найти по счётчикам.

1.2. Собрать новый ACL и переключить его атомарно, сохранив старый для отката:

object network OBJ_WEB01
 host <реальный_IP_web01>          ! реальный IP, если ASA 8.3+ и используется NAT
object network OBJ_MAIL01
 host <реальный_IP_mail01>

access-list OUTSIDE_IN_V2 remark CHG-XXXX Public web
access-list OUTSIDE_IN_V2 extended permit tcp any object OBJ_WEB01 eq https
access-list OUTSIDE_IN_V2 extended permit tcp any object OBJ_WEB01 eq www
access-list OUTSIDE_IN_V2 remark Inbound SMTP
access-list OUTSIDE_IN_V2 extended permit tcp any object OBJ_MAIL01 eq smtp
access-list OUTSIDE_IN_V2 remark Default deny with logging
access-list OUTSIDE_IN_V2 extended deny ip any any log 6 interval 300

access-group OUTSIDE_IN_V2 in interface outside
write memory

• Откат: access-group OUTSIDE_IN in interface outside.
• SSH (22), RDP (3389) и MSSQL (1433) не публикуются вовсе.
• Убрать соответствующие nat/static для 203.0.113.12–14, в том числе трансляции в VLAN30: show run nat, затем no nat ....
• Если внешнему партнёру нужен доступ к БД, сделать site-to-site IPsec с ограничением по источнику, а не открытый порт.

1.3. Удалённое администрирование — только через VPN-шлюз с MFA (8.4.3), дальше через jump-host (фаза 2).

1.4. Сразу после изменений на ASA:

threat-detection basic-threat
threat-detection scanning-threat shun except ip-address <mgmt_net> <mask>
logging enable
logging timestamp
logging host inside <SIEM_IP>
logging trap informational

1.5. Скрыть баннер. ASA:

policy-map global_policy
 class inspection_default
  inspect esmtp

Postfix (/etc/postfix/main.cf):

smtpd_banner = $myhostname ESMTP

Затем postfix check && systemctl reload postfix.

1.6. Веб. Порт 80 оставить только для 301-редиректа на HTTPS и включить HSTS.

Фаза 2. Дни 2–10: сегментация CDE и доступ через jump-host с MFA (F4–F8)

2.1. Целевая модель потоков в VLAN30.

2.2. pfSense (GUI, Firewall → Aliases / Rules):

• Алиасы: CDE_NET = 10.10.30.0/24, JUMP_HOSTS = 10.10.40.10, 10.10.40.11, CDE_APP_SRC = <app IPs>, CDE_MGMT_PORTS = 22, 3389.
• Интерфейс VLAN10: удалить разрешения 22/3389/1433 в CDE. Добавить правило Block, source VLAN10 net, destination CDE_NET, Log выше любых общих разрешений.
• Интерфейс JUMP: Pass, source JUMP_HOSTS, destination CDE_NET, ports CDE_MGMT_PORTS.
• Интерфейс VLAN30 (egress): Pass только на NTP, DNS, SIEM и репозитории. Затем Block any, Log.
• Удалить эквивалент 0.0.0.0/0 → CDE ACCEPT. В pfSense такое правило часто оказывается правилом «Pass any» на одном из интерфейсов (DMZ, OpenVPN) либо плавающим правилом (Floating). Проверьте все интерфейсы и вкладку Floating.
• Перед изменением: Diagnostics → Backup & Restore (выгрузка config.xml).

Если между VLAN всё-таки стоит Linux-шлюз с iptables, эквивалент такой:

iptables-save > /root/fw-backup-$(date +%F).rules
# новая цепочка FORWARD (порядок важен)
-A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -m conntrack --ctstate INVALID -j DROP
-A FORWARD -s 10.10.40.10/32,10.10.40.11/32 -d 10.10.30.0/24 -p tcp -m multiport --dports 22,3389 -j ACCEPT
-A FORWARD -s <APP_IPs> -d 10.10.30.15/32 -p tcp --dport 1433 -j ACCEPT
-A FORWARD -s 10.10.30.0/24 -d <NTP,DNS,SIEM,REPO> -j ACCEPT      # по портам, отдельными правилами
-A FORWARD -d 10.10.30.0/24 -m limit --limit 10/min -j LOG --log-prefix "CDE-IN-DENY "
-A FORWARD -s 10.10.30.0/24 -m limit --limit 10/min -j LOG --log-prefix "CDE-OUT-DENY "
-A FORWARD -j DROP

Применять через iptables-apply -t 120: если подтверждение не придёт, правила автоматически откатятся.

2.3. Jump-host с MFA и записью сессий (8.4.2, 8.5.1, 10.2.1.2). Варианты по сложности:

• Teleport или Apache Guacamole + TOTP/WebAuthn — SSH и RDP, запись сессий, привязка к AD.
• Windows RD Gateway + NPS extension (Azure MFA / Duo) — для RDP.
• Минимальный вариант: Linux bastion с pam_google_authenticator или privacyIDEA плюс AuthenticationMethods publickey,keyboard-interactive.

Требования:

• на jump-host входят только администраторы CDE (отдельная группа AD);
• у администраторов отдельные привилегированные учётки, не повседневные;
• MFA нельзя обойти, и она устойчива к повтору (8.5.1);
• сессии записываются, а логи уходят в SIEM.

2.4. sshd на серверах CDE — /etc/ssh/sshd_config.d/10-pci.conf:

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
AllowGroups cde-admins
# доступ только с jump-host (дублирует сетевой фильтр):
Match Address *,!10.10.40.10,!10.10.40.11
    DenyUsers *
Match all
MaxAuthTries 3
LoginGraceTime 30
ClientAliveInterval 300
ClientAliveCountMax 3      # ≈15 мин простоя (8.2.8)
X11Forwarding no
AllowTcpForwarding no
AllowAgentForwarding no
LogLevel VERBOSE

Порядок применения:

1. Держать открытую root-сессию.
2. Выполнить sshd -t.
3. Выполнить systemctl reload ssh (на CentOS — sshd).
4. Проверить вход из новой сессии и только потом закрывать старую.

2.5. sudo (7.2.x, 6.5.4):

sudo visudo -c
sudo grep -rn developer /etc/sudoers /etc/sudoers.d/
# удалить неограниченную запись; разработчику в продуктиве CDE привилегий не нужно

Если операционная задача реально существует (например, резервное копирование), её должен выполнять сервисный механизм (cron под сервисной учёткой, выгрузка в защищённое хранилище с шифрованием), а не интерактивный пользователь. Не выдавайте sudo на отдельные бинарники вроде mysqldump, vim или less: через них можно получить shell или записать произвольный файл.

2.6. MSSQL/MySQL:

• отключить или переименовать sa, отключить xp_cmdshell;
• включить Force Encryption;
• выдать учётки приложения с минимальными правами;
• поставить последние CU и GDR для SQL Server 2017 (расширенная поддержка до октября 2027);
• MySQL слушать только нужный интерфейс (bind-address);
• проверить, где хранится PAN и зашифрован ли он (3.5.1).

2.7. AWS. Security Group фронтенда: входящий только 443 (и 80 для редиректа) от ALB или CloudFront. Доступ к CDE — только через site-to-site VPN или Direct Connect на конкретный порт БД. Включить VPC Flow Logs, GuardDuty и CloudTrail. Если карта вводится на вашей странице, ваши зоны ответственности — 6.4.3 (инвентаризация скриптов платёжной страницы) и 11.6.1 (контроль изменений заголовков и страницы).

Фаза 3. Недели 2–4: мониторинг и устранение уязвимостей (F10–F13)

3.1. Централизация логов (10.2–10.7):

• источники: ASA и pfSense (syslog), Linux (rsyslog по TLS), Windows/AD (WEF/агент), jump-host, AWS;
• стек на выбор: Wazuh, Elastic или Splunk;
• синхронизация времени (NTP, 10.6);
• хранение 12 месяцев, из них 3 в оперативном доступе.

Пример для rsyslog:

# /etc/rsyslog.d/90-siem.conf
*.* @@(o)siem.internal:6514

(плюс настройка gtls).

3.2. Правила корреляции (минимум для аудита):

• успешный вход на хост CDE с источника не из JUMP_HOSTS;
• sudo на хостах CDE, особенно mysqldump, pg_dump, bcp, sqlcmd -Q "BACKUP", tar по каталогам БД;
• более 10 неудачных входов за 5 минут (8.3.4: блокировка не позже чем после 10 попыток);
• любой исходящий DENY из VLAN30 (признак попытки выгрузки);
• изменения ACL на ASA и pfSense, изменения групп AD cde-admins и Domain Admins;
• вход в нерабочее время.

3.3. IDS/IPS (11.5.1): Suricata на pfSense на интерфейсах VLAN30 и DMZ (пакет suricata, наборы ET Open или ET Pro). Первые 1–2 недели в режиме IDS, затем IPS для отобранных правил.

3.4. Контроль целостности (11.5.2): Wazuh syscheck или AIDE на /etc, /usr/bin, /usr/sbin, конфигурации СУБД и веб-корне. Проверка минимум еженедельно, с оповещениями.

3.5. Уязвимости:

• хост с Ubuntu 20.04: как минимум подключить Ubuntu Pro/ESM и обновить, в идеале мигрировать на 22.04/24.04;
• в любом случае он не должен быть доступен из интернета;
• закрыть все critical/high в пределах 1 месяца (6.3.3);
• проверить, что компоненты AD и Windows Server 2019 в актуальном состоянии.

3.6. Документация для QSA:

• актуальная сетевая схема (1.2.3) и схема потоков данных держателей карт (1.2.4);
• обоснование каждого разрешающего правила (1.2.5);
• проверка правил межсетевых экранов (1.2.7);
• обновлённый инвентарь.

Фаза 4. Недели 4–5: валидация и доказательства

• Внутренний скан уязвимостей (11.3.1) с аутентификацией и внешний ASV-скан (11.3.2) после изменений периметра.
• Повторный пентест сегментации (11.4.5) из VLAN10, DMZ, VPN-пула, AWS и внешний. Без него QSA не примет сокращённый scope.
• Retest находок исходного пентеста у того же подрядчика с письменным подтверждением закрытия.

Неделя 6: буфер

Остаток замечаний, сбор артефактов (скриншоты, выгрузки конфигураций, тикеты изменений), обучение администраторов работе через jump-host.

4. Проверка (без простоев)

Общий подход

• Каждое изменение делается в согласованное окно, с бэкапом конфигурации и заранее подготовленной командой отката.
• Синтетический мониторинг бизнес-сервисов (HTTPS-проверка витрины, SMTP-проба, транзакция в тестовом платёжном режиме) запускается до изменения и наблюдается 30–60 минут после.

Периметр (ASA)

! моделирование без реального трафика
packet-tracer input outside tcp 198.51.100.10 40000 203.0.113.14 1433 detailed   ! ожидается DROP
packet-tracer input outside tcp 198.51.100.10 40000 203.0.113.13 3389 detailed   ! DROP
packet-tracer input outside tcp 198.51.100.10 40000 203.0.113.10 443  detailed   ! ALLOW
show access-list OUTSIDE_IN_V2      ! счётчики: permit 443/25 растут, deny ловит сканеры
show run access-group               ! активен V2

Внешняя проверка — только авторизованный скан по вашему scope, например тем же пентест-подрядчиком или ASV:

nmap -Pn -sT -p 22,25,80,443,1433,3389 203.0.113.10-14

Ожидается: открыты только 80/443 на .10 и 25 на .11. Postfix-баннер без версии: openssl s_client -starttls smtp -connect 203.0.113.11:25 или nc 203.0.113.11 25.

Сегментация (pfSense)

• С офисной станции VLAN10:

  nc -zv -w3 10.10.30.15 22
  nc -zv -w3 10.10.30.15 1433
  

  Ожидается таймаут, а в Status → System Logs → Firewall — запись block.
• С jump-host: nc -zv 10.10.30.15 22 проходит.
• С сервера приложений: 1433 проходит, 22 не проходит.
• Из CDE: curl -m5 https://example.com блокируется, NTP и DNS работают.
• Diagnostics → States: нет активных состояний из VLAN10 в 10.10.30.0/24.

Аутентификация на хостах CDE

sudo sshd -T | grep -Ei 'passwordauth|permitroot|authenticationmethods|allowgroups'
ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no admin@10.10.30.15
#   ожидается: Permission denied (publickey)
sudo -l -U developer            # ожидается: not allowed / нет записей

Вход через jump-host запрашивает второй фактор, сессия появляется в записи и в SIEM.

Мониторинг

Контролируемые тестовые события на тестовом хосте CDE по согласованию с SOC:

• 11 неверных паролей подряд;
• попытка SSH с офисного адреса;
• sudo от администратора.

Каждое событие должно вызвать оповещение в SIEM в пределах заданного SLA. Для IDS — тестовая сигнатура (curl http://testmynids.org/uid/index.html из сегмента под наблюдением) должна дать алерт Suricata. Для FIM — изменение тестового файла в /etc должно дать оповещение.

Критерии готовности к аудиту

• F1 закрыт: подтверждён пентестом или расследован по 12.10 с отчётом.
• В ACL outside нет permit ip any any, 22/3389/1433 не опубликованы.
• В CDE нет разрешений с any в источнике, egress из CDE ограничен.
• Доступ в CDE только через jump-host с MFA, парольный SSH отключён.
• У developer нет привилегий в CDE.
• SIEM, IDS и FIM работают, проверены тестовыми событиями.
• Чистый ASV-скан, успешный тест сегментации, повторный пентест, актуальные схемы.

Если пришлёте выгрузки show run nat, show version, config.xml pfSense (без секретов) и подтверждение по активности 21.09, могу уточнить конкретные правила и пересмотреть оценку F1 и scope.