«Защита от спуфинга — это не просто блокировка «плохих» адресов. Это понимание того, как протоколы, созданные для доверия, становятся оружием, и выстраивание барьеров там, где это доверие заканчивается.»
4.6.1Защита от атак IP-спуфинга
Списки контроля доступа (ACL) — это фундаментальный механизм фильтрации трафика на сетевых устройствах. Их корректное применение позволяет отсечь значительную часть нелегитимного трафика, особенно связанного с подменой IP-адресов (спуфингом), которая лежит в основе многих распределённых атак на отказ в обслуживании (DDoS).
При IP-спуфинге злоумышленник произвольно указывает в пакете адрес источника, не соответствующий реальному отправителю. Это не только маскирует источник атаки, но и может использоваться для обмана систем, полагающихся на IP-адресацию для аутентификации или маршрутизации. Блокировка таких пакетов на периметре — первая и обязательная линия обороны.
Диапазоны адресов, которые не должны приходить извне
Логика проста: определённые диапазоны IP-адресов зарезервированы для специальных целей или для использования внутри частных сетей. Их появление в поле «адрес источника» во входящем из интернета трафике — всегда аномалия, указывающая либо на ошибку в конфигурации, либо на целенаправленную атаку.
Рассмотрим интерфейс маршрутизатора, обращённый в интернет (например, S0/0/0). На нём необходимо блокировать входящие пакеты со следующими адресами источника:
| Диапазон адресов | Назначение и причина блокировки |
|---|---|
| 0.0.0.0/8 | Адреса «все нули». Используются в служебных целях (например, DHCP-запросы от клиента без адреса). В интернете не маршрутизируются. |
| 127.0.0.0/8 | Loopback-адреса (localhost). Предназначены для внутренней коммуникации внутри одного устройства. Их появление извне — явный признак спуфинга. |
| 169.254.0.0/16 | Адреса APIPA (Automatic Private IP Addressing). Автоматически назначаются хостам, если не удалось получить адрес по DHCP. Чисто локальный диапазон. |
| 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 | Частные (приватные) адреса, определённые в RFC 1918. Предназначены для использования внутри организационных сетей и не маршрутизируются в глобальном интернете. |
| 224.0.0.0/4 | Диапазон multicast-адресов (от 224.0.0.0 до 239.255.255.255). Трафик с такими адресами источника не имеет практического смысла. |
| 255.255.255.255 | Ограниченный широковещательный адрес. Используется только в пределах локального сегмента сети. |
Если ваш пограничный маршрутизатор принимает такие пакеты, это брешь в безопасности. Их нужно отбрасывать на самом внешнем интерфейсе.
Практика: настройка ACL против спуфинга
Предположим, локальная сеть 192.168.1.0/24 подключена к интерфейсу G0/0 маршрутизатора R1. На этом интерфейсе следует разрешать входящий трафик только с адресов этой же подсети. Основная же фильтрация нелегитимных адресов происходит на интерфейсе, смотрящем в интернет (S0/0/0).
Конфигурация для интерфейса S0/0/0 (входящий трафик из интернета):
R1(config)# access-list 150 deny ip 0.0.0.0 0.255.255.255 any
R1(config)# access-list 150 deny ip 10.0.0.0 0.255.255.255 any
R1(config)# access-list 150 deny ip 127.0.0.0 0.255.255.255 any
R1(config)# access-list 150 deny ip 169.254.0.0 0.0.255.255 any
R1(config)# access-list 150 deny ip 172.16.0.0 0.15.255.255 any
R1(config)# access-list 150 deny ip 192.168.0.0 0.0.255.255 any
R1(config)# access-list 150 deny ip 224.0.0.0 15.255.255.255 any
R1(config)# access-list 150 deny ip host 255.255.255.255 any
! Разрешаем весь остальной трафик (к нему позже добавятся правила для конкретных служб)
R1(config)# access-list 150 permit ip any anyКонфигурация для интерфейса G0/0 (входящий трафик из локальной сети):
R1(config)# access-list 105 permit ip 192.168.1.0 0.0.0.255 anyКак работает wildcard-маска
В ACL Cisco используется обратная маска (wildcard mask), которая определяет, какие биты адреса нужно проверять. Ноль означает «бит должен совпадать», единица — «бит может быть любым».
| Диапазон (префикс) | Wildcard-маска | Логика |
|---|---|---|
| 10.0.0.0/8 | 0.255.255.255 | Проверяем только первый октет (10). Остальные три октета игнорируются. |
| 172.16.0.0/12 | 0.15.255.255 | Проверяем первые два октета, но для второго октета только первые 4 бита (16-31). Маска 15 в бинарном виде: 00001111. |
| 192.168.0.0/16 | 0.0.255.255 | Проверяем первые два октета (192.168). Последние два — любые. |
4.6.2Принцип минимальных привилегий на межсетевом экране
После блокировки заведомо ложных адресов нужно определить, какой именно легитимный трафик может проходить через периметр. Эффективная стратегия — политика «запрещено всё, что не разрешено явно». Вместо того чтобы пытаться блокировать все известные угрозы, вы разрешаете только строго определённый набор служб и протоколов.
Типичные службы, доступ к которым из интернета может быть оправдан:
- DNS (UDP/TCP 53) — для разрешения доменных имён.
- SMTP (TCP 25) — для приёма входящей электронной почты на почтовый сервер.
- HTTPS (TCP 443) — для доступа к публичным веб-сервисам компании.
Для управления инфраструктурой извне может потребоваться доступ к административным службам, но его необходимо жёстко ограничить:
- SSH (TCP 22) — для безопасного удалённого управления сетевыми устройствами и серверами.
- Syslog (UDP 514) — для приёма журналов событий с удалённых устройств.
- SNMP (UDP 161/162) — для мониторинга состояния оборудования (использовать с крайней осторожностью).
Пример: ACL для разрешения конкретных служб
Допустим, у нас есть сервер с адресом 192.168.20.2 во внутренней сети, который должен быть доступен извне для почты и передачи файлoв. Административный доступ к маршрутизатору (10.0.1.1) разрешён только с доверенного хоста 200.5.5.5.
Конфигурация расширенного ACL для входящего трафика на интерфейсе S0/0/0:
! Разрешаем публичные службы на сервер 192.168.20.2
R1(config)# access-list 180 permit udp any host 192.168.20.2 eq domain
R1(config)# access-list 180 permit tcp any host 192.168.20.2 eq smtp
R1(config)# access-list 180 permit tcp any host 192.168.20.2 eq ftp
! Разрешаем административный доступ ТОЛЬКО с доверенного хоста 200.5.5.5
R1(config)# access-list 180 permit tcp host 200.5.5.5 host 10.0.1.1 eq 22
R1(config)# access-list 180 permit udp host 200.5.5.5 host 10.0.1.1 eq syslog
R1(config)# access-list 180 permit udp host 200.5.5.5 host 10.0.1.1 eq snmp
! Неявный запрет всего остального (в ACL Cisco добавляется автоматически)
R1(config)# access-list 180 deny ip any any| Правило | Что делает | Важный нюанс |
|---|---|---|
permit udp any host 192.168.20.2 eq domain |
Разрешает DNS-запросы к серверу из любого места. | Делает сервер видимым для внешнего мира через DNS. Убедитесь, что на сервере запущен DNS-сервер. |
permit tcp host 200.5.5.5 host 10.0.1.1 eq 22 |
Разрешает SSH только с конкретного IP. | Критически важно. Административный доступ не должен быть открыт для «any». |
4.6.3Контроль ICMP: больше чем просто ping
Протокол ICMP часто воспринимается лишь как инструмент для ping, но он включает десятки типов сообщений для диагностики и управления сетью. Злоумышленник может использовать их для разведки топологии сети или нарушения её работы.
- ICMP Echo Request/Reply (ping) — позволяет обнаружить активные хосты и измерить задержки. Ping-flood — простая, но эффективная DoS-атака.
- ICMP Redirect — сообщение маршрутизатора хосту о том, что для определённой сети есть лучший путь. Злоумышленник может отправить поддельный redirect, чтобы перенаправить трафик через себя (атака «человек посередине»).
- ICMP Destination Unreachable — может использоваться для «отравления» таблиц маршрутизации или сброса TCP-соединений.
Полная блокировка ICMP нарушит работу многих диагностических инструментов. Нужен избирательный подход.
Избирательная фильтрация ICMP-сообщений
Разрешать следует только те типы сообщений, которые необходимы для штатной работы сети, блокируя потенциально опасные.
| Тип сообщения | Рекомендация для входящего трафика (из интернета) | Обоснование |
|---|---|---|
| Echo Reply | Разрешить | Чтобы внутренние пользователи могли пинговать внешние ресурсы и получать ответ. |
| Echo Request | Заблокировать | Предотвращает обнаружение ваших внутренних хостов извне и ping-flood атаки. |
| Destination Unreachable | Разрешить | Важно для диагностики (например, при недоступности порта). |
| Redirect | Заблокировать | В корпоративной сети маршрутизацию определяют администраторы, а не внешние узлы. | Packet Too Big (для IPv4 — Fragmentation Needed) | Разрешить (для исходящего) | Критически важно для работы Path MTU Discovery, без него могут «падать» крупные пакеты (например, по VPN). |
Настройка ACL для ICMP
ACL для входящего трафика (разрешаем только безопасные ответы извне):
R1(config)# access-list 112 permit icmp any any echo-reply
R1(config)# access-list 112 permit icmp any any unreachable
R1(config)# access-list 112 permit icmp any any packet-too-big
R1(config)# access-list 112 deny icmp any any
R1(config)# access-list 112 permit ip any anyACL для исходящего трафика (разрешаем внутренним хостам инициировать диагностику):
R1(config)# access-list 114 permit icmp 192.168.1.0 0.0.0.255 any echo
R1(config)# access-list 114 permit icmp 192.168.1.0 0.0.0.255 any parameter-problem
R1(config)# access-list 114 permit icmp 192.168.1.0 0.0.0.255 any packet-too-big
R1(config)# access-list 114 deny icmp any any
R1(config)# access-list 114 permit ip any any4.6.4SNMP: невидимый вектор атаки
SNMP — это «ахиллесова пята» многих сетей. Протокол создавался в эпоху доверия и по умолчанию использует слабые строки сообщества (community strings), такие как «public» (только чтение) и «private» (чтение/запись). Злоумышленник, получивший доступ к SNMP, может не только собрать детальную информацию о топологии сети, типах устройств и их конфигурации, но и внести изменения: изменить маршруты, отключить интерфейсы, загрузить новую прошивку.
Фильтрация SNMP-тракта с помощью ACL — лишь полумера. Если злоумышленник находится внутри разрешённого диапазона адресов или использует спуфинг, ACL не поможет.
Единственная надёжная мера
Если SNMP не используется для мониторинга конкретного устройства, его следует полностью отключить. На устройствах Cisco IOS это делается одной глобальной командой:
R1(config)# no snmp-serverЭта команда удаляет всю конфигурацию SNMP, включая строки сообщества, ACL и настройки trap-сообщений.
Если SNMP необходим: жёсткое ограничение
Когда без SNMP не обойтись, применяйте комплекс мер:
- Используйте SNMPv3. Только третья версия протокола поддерживает криптографическую аутентификацию пользователей и шифрование трафика. SNMPv1/v2c небезопасны.
- Смените и усложните строки сообщества. Никогда не используйте значения по умолчанию. Используйте сложные пароли.
- Жёстко ограничьте доступ по IP. Разрешите SNMP-запросы только с IP-адресов вашей системы мониторинга.
- Минимизируйте права. Для большинства устройств достаточно прав только на чтение (RO). Права на запись (RW) давайте в исключительных случаях.
Пример настройки SNMPv2c с ACL (как временное решение, если v3 недоступен):
! Создаём ACL, разрешающий только хост системы мониторинга
R1(config)# ip access-list standard SNMP-MONITOR
R1(config-std-nacl)# permit host 192.168.1.100
R1(config-std-nacl)# deny any
! Применяем ACL к строке сообщества с правами только на чтение
R1(config)# snmp-server community J8#sD$fq2p RO SNMP-MONITORИтог: многоуровневая фильтрация как основа периметра
Эффективная защита периметра строится на последовательном применении фильтров, каждый из которых решает свою задачу:
- Базовый антиспуфинг. Блокировка пакетов с заведомо ложными адресами источника. Это отсекает грубые, но массовые атаки.
- Политика минимальных привилегий. Явное разрешение только необходимых портов и протоколов. Сужает поверхность атаки.
- Контекстный контроль служебных протоколов. Избирательное управление ICMP и полное отключение неиспользуемых служб вроде SNMP. Убирает скрытые векторы атаки.
Такая комбинация не даёт абсолютной защиты, но создаёт серьёзный барьер для автоматизированных атак и значительно повышает сложность проведения целевого взлома.