Цель доклада:
Пока вокруг шум и пыль от APT-группировок и уязвимостей нулевого дня — пишут громкие заголовки, обновляют CVSS- скоринги, а в реальной эксплуатации DDoS, будто старый знакомый, приходит молча, но регулярно. Разве что пару раз на конференциях подробно разбирали профиль атаки на уровне L7. Пора разобраться: что в этих инцидентах действительно новое, как изменился ландшафт атак к 2026 году, какие ошибки кочуют из команды в команду, и как сетевикам к этому относиться — паниковать в первые минуты, смеяться над старыми ботами или выстроить хладнокровный алгоритм реагирования на практике.

Основные аспекты:

• Анатомия атаки 2026: Как отличить классический ботнет от специализированной генерации трафика и почему старые сигнатуры больше не работают.
• Диагностика в первые минуты: По каким признакам и метрикам отличить внешний DDoS от внутренней деградации сервиса или неудачного деплоя.
• Эшелонирование защиты: Когда достаточно фильтрации на сетевом уровне (L3/L4), а когда требуется глубокая очистка трафика на уровне приложений (L7).
• Психология инцидента: Какие фатальные ошибки допускают команды в условиях хаоса и как подготовить алгоритмы, чтобы не принимать решения на эмоциях.
• Взаимодействие с внешним миром: Когда звонить провайдеру или подключать облачный скруббер, а когда попытка «пережить» атаку своими силами ведет к полной потере доступности.

Инструменты и методики:

• Поведенческий анализ вместо сигнатур: Почему важнее смотреть на энтропию трафика, аномалии в соотношении SYN/ACK и распределение TTL, а не на конкретные паттерны в пакетах.
• Корреляция логов на лету: Как быстро связать рост входящего трафика с ошибками на бэкенде (50x) и таймаутами баз данных, чтобы не уйти в ложную диагностику отказа железа.
• Метрики для эксплуатационной команды: Базовый чек-лист: CPU softirq, RX-DRP сетевыx карт, состояние conntrack таблиц и количество сокетов в состоянии TIME_WAIT.
• Алгоритм эскалации: Готовые сценарии реагирования — от локального ACL и RTBH до BGP FlowSpec и смены IP-адреса, плюсы и минусы каждого шага.
• Подготовка к «тишине»: Какие дашборды, скрипты и каналы связи должны быть развернуты заранее, чтобы инженер в 4 утра видел картину целиком, а не отдельные красные лампочки в мониторинге.

Реальные кейсы, сигнатуры и практические методы защиты
------------------------------------------------------------------

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

Основные аспекты:

• Основные причины сбоев в ИТ-системах
• Ключевые стратегии предотвращения сбоев
• Шаги по внедрению системы предотвращения

Инструменты и методики:

• Мониторинг ключевых метрик: CPU, память, диски, сетевые каналы (Zabbix, Prometheus)
• Анализ трендов и прогнозирование деградации (Grafana, прогнозные алерты)
• Логирование и трассировка для выявления «слепых зон» (ELK, Loki)
• Автоматизация реагирования на инциденты (Runbooks, Ansible)
• Резервирование критических компонентов и регулярное тестирование отказов
• Пошаговый чек-лист внедрения превентивной системы мониторинга

------------------------------------------------------------------

Цель доклада:
Показать, как избирательная фильтрация ICMP сокращает простои сервисов при сбоях, сохраняя базовую диагностику сети без ущерба для безопасности.

Основные аспекты:

• Почему полная блокировка ICMP увеличивает время восстановления сервисов
• Какие типы и коды ICMP критичны для диагностики (echo, ttl exceeded, fragmentation needed)
• Методика «блокируем с умом»: разрешаем необходимое, отсекаем опасное
• Реальные примеры отказов, спровоцированных жёстким запретом ICMP

Инструменты и методики:

• ACL/firewall с фильтрацией по типам ICMP (iptables, nftables, Cisco ACL)
• Разрешение Echo Request/Reply для внутренней диагностики при запрете извне
• Сохранение ICMP Fragmentation Needed для корректной работы Path MTU Discovery
• Ограничение ICMP Rate Limiting вместо полного запрета
• Netflow/sFlow для выявления аномального ICMP-трафика (атаки) без отключения протокола

------------------------------------------------------------------

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

• Утечка заказов FMCG-гиганта через уязвимый браузер в контакт-центре
• Открытый Git-репозиторий с сертификатами — сценарий полного компромисса инфраструктуры
• Типовые провалы: незащищённые API, секреты в коде, слабые звенья CI/CD-пайплайнов
• Почему периметровая защита не спасает, когда ошибка внутри контура

------------------------------------------------------------------