Сказ о том, как случайно не сделать роутер Cisco публичным DNS и NTP сервером

Операционная система IOS/IOS-XE роутеров Cisco — источник вдохновения для большого числа других производителей. В Сети навалом инструкций, как сконфигурировать типовой роутер Cisco для сценариев DDoS-амплификатором.

Вообще оборудование на базе Cisco IOS — нечастый гость в сегменте SOHO. Препятствует этому цена: у бытовых «коробок» за те же деньги характеристики поинтереснее. Но Cisco в SOHO всё же случается.

Не будем забывать: пишем IOS, подразумеваем ещё и IOS-XE. И ещё давайте договоримся: не надо бездумно копипастить из статьи, для начала ознакомьтесь со справкой по применяемым командам.

В IOS присутствует фаервол, но по умолчанию он отключён. Включение фаервола (особенно zone-based firewall) таит в себе набор особенностей, с которыми справиться готов не каждый. Поэтому большинство использует роутеры без фаервола вовсе.

В целом, в жизни без фаервола ничего катастрофического нет. Разве что не стоит забывать, что все поднятые службы будут светить не только в локалку, но и в публичный интернет, включая DNS, NTP, HTTP, SSH, Telnet и т.д. И если L2-службы, типа CDP, не несут непосредственной угрозы, то с остальными сложнее. Так что если от фаервола отказались, то нужно по крайней мере закрыть доступ к чувствительным службам просто на уровне самих служб. Почти все из них вполне поддерживают назначение ограничений доступа через ACL.

У базового конфига под SOHO такие особенности:

• Имеется публичный интерфейс с «белым» адресом провайдера.

• За NAT расположена внутренняя «серая» сеть.

• Непосредственно на роутере подняты базовые сетевые службы типа DNS, DHCP, NTP.

Ниже представлены ключевые параметры конфига. Безусловно, это не целый конфиг, а только строчки для предметного изучения проблемы.

hostname R1 ! ip name-server 1.1.1.1 no ip domain lookup ! ip dhcp pool LAN  network 192.168.0.0 255.255.255.0  default-router 192.168.0.1  option 42 ip 192.168.0.1  dns-server 192.168.0.1  lease 3  update arp ! vlan 1  name LAN ! interface GigabitEthernet0/0/0  description Uplink  ip address 192.0.2.2 255.255.255.0  ip nat outside  negotiation auto  ip virtual-reassembly ! interface GigabitEthernet0/1/0  description LAN Trunk  switchport trunk native vlan 1  switchport trunk allowed vlan 1  switchport mode trunk ! interface Vlan1  description LAN  ip address 192.168.0.1 255.255.255.0  ip nat inside  ip virtual-reassembly ! ip nat inside source list NAT-networks interface GigabitEthernet0/0/0 overload ! ip dns server ! ip route 0.0.0.0 0.0.0.0 192.0.2.1 250 ! ip access-list extended NAT-networks  permit ip 192.168.0.0 0.0.0.255 any

Заметим из конфига:

• В нём есть локалка с префиксом 192.168.0.0/24, а роутеру в сети назначен адрес 192.168.0.1.

• Провайдер выделяет адрес 192.0.2.2, который также является публичным и по совместительству — NAT-адресом локалки.

• Поднят DHCP. Он указывает клиентам, что DNS отвечает по адресу роутера.

• Роутер выступает в качестве рекурсивного сервера имён. Запросы он форвардит на 1.1.1.1.

• В конфиге определён ACL NAT-networks, соответствующий клиентам локальной сети.

С таким конфигом всё заработает. Разве что встроенный DNS-рекурсор роутера будет обрабатывать рекурсивные запросы не только от клиентов локалки, но и со всего мира через публичный интерфейс. Да, если сделать снаружи dig @router_public_ip example.com, то роутер отдаст ответ.

Страшного в таком подходе ничего нет. Долгое время подобное было популярно на заре интернета, но не сегодня. Дело в том, что публичный DNS-сервер таит в себе угрозу для иных участников сети из-за DDoS-атак категории amplification. Если злоумышленник подделает SRC пакета DNS и вместо него передаст адрес жертвы, то ответ роутер отдаст жертве. К сожалению, спуфинг IP-адресов до сих пор возможен, и на этом основан популярный вид DDoS-атак.

Попробуем ограничить доступ к основным службам в IOS. Способов два:

1. Отключение ненужных служб. К примеру, мало кому нужен встроенный HTTP-сервер. 

2. Если службу отключать нежелательно (как в случае с DNS-сервером), надо назначить группу доступа отдельно для каждой из них.

Для второго способа начать сто́ит с заведения стандартного ACL с перечнем тех, кому доступ разрешён. Если это только клиенты LAN-сегмента, возможно переиспользовать уже существующий ACL для NAT-сетей. В примере конфига выше это NAT-networks, который выглядит так: 

ip access-list extended NAT-networks  permit ip 192.168.0.0 0.0.0.255 any

Другой подход: завести выделенный ACL для целей администрирования, если предполагается расширение этого списка. Не забывайте, что бывает ещё и IPv6, но в нашем примере его нет:

ip access-list standard Maintenance-v4  permit 192.168.0.0 0.0.0.255 log  permit host 198.51.100.254 log  deny   any log

Здесь мы видим наш сегмент LAN и некий отдельный хост 198.51.100.254, который тоже имеет права доступа. Представим, что это внешняя система мониторинга.

Немного коснёмся защиты типовых сетевых служб.

SSH и Telnet ограничиваются в секциях line. Количество vti уточняйте у своей модели.

line vty 0 4  access-class Maintenance-v4 in line vty 5 97  access-class Maintenance-v4 in

SNMP-сервер в принципе отвечает только явно прописанным хостам.

snmp-server host 198.51.100.254 version 2c CommunityName

HTTP-сервер, если он вам зачем-то нужен, закрывается следующим образом.

ip http access-class ipv4 Maintenance-v4

Общий обзор логики происходящего: если нужен сервис servername, то в секции ip servername ищем что-то похожее на access-class и указываем там наш ACL, не забыв про address-family.

А вот с DNS не так всё очевидно. Впрочем, и там есть возможность ограничить доступ через функционал DNS view, которых может быть ещё и несколько. Делается это в два этапа: создаём view, а дальше применяем его для DNS-сервера. У нас примитивный рекурсивный резолвер для локалки, так что во view не будет ничего больше, чем разрешение резолвить имена нашей локалке. В этом случае логично будет переиспользовать ACL для NAT:

ip dns view-list Recursor  view default 1   restrict source access-group NAT-networks

Следом надо применить этот view к серверу добавлением строки:

ip dns server view-group Recursor

Итак, конфиг DNS будет выглядеть примерно так:

ip name-server 1.1.1.1 ! ip dns view-list Recursor  view default 1   restrict source access-group NAT-networks ip dns server view-group Recursor ip dns server

Бонусом обсудим технологию из прошлого, которую эксплуатируют для DDoS-атак в тандеме с DNS — NTP.

Дело в том, что если настроить синхронизацию времени на роутере по NTP с внешними пулами, то сам роутер станет NTP-сервером. Это стандартное поведение, обусловленное спецификой протокола. Пользуются этим сервером NTP как во благо (нужен сервер времени в локалке), так и во вред всякие пионеры-дидосеры всё для тех же amplification атак. Типовой конфиг NTP выглядит примерно так:

ntp max-associations 32 ntp master ntp server server_1 ntp server server_2

Напомним: будьте поаккуратнее с использованием DNS-имён для NTP-серверов — это часто тормозит загрузку роутера. Рекомендуется использовать IP-адреса.

Если зачем-то необходимо указывать сервера пулов с использованием доменных имён, то рекомендуется устанавливать список таких серверов времени через планировщик, чтобы это происходило уже после полноценной загрузки железки, когда она гарантированно уже имеет доступ к внешним службам. Тем не менее, использовать DNS всё равно не рекомендуется. Проиллюстрируем, почему.

Ограничение доступа к NTP осуществляется тоже через access-group, но с нюансом. Дело в том, что в отдельном списке должны быть перечислены IP-адреса серверов пулов, с которыми вы синхронизируетесь. Если так не делать, то либо время синхронизироваться не будет, либо сервер NTP будет публичным. Таковы особенности протокола.

Например, если адреса ваших референс мастеров 198.51.100.5 и 203.0.113.5, то настройки ограничения доступа должны выглядеть примерно так:

ip access-list standard NTP-servers  permit 198.51.100.5  permit 203.0.113.5 ! ntp max-associations 32 ntp access-group peer NTP-servers ntp access-group serve NAT-networks ntp master ntp server 198.51.100.5 ntp server 203.0.113.5

Напоследок: не забудьте ограничить L2-сервисы, которые смотрят в сторону провайдера. Риски работы без ограничений небольшие, конечно, но всё же есть.

Эти настройки традиционно вешаются на конкретный интерфейс. Список ниже не исчерпывающий. Часть из них уже применяется в современных версиях и скрыта из конфига по умолчанию:

interface GigabitEthernet  description WAN  no ip redirects  no ip proxy-arp  ipv6 nd ra suppress all  no ipv6 mfib forwarding input  no cdp enable  no lldp transmit  no lldp receive

Забавный факт в том, что хотя статья посвящена применению роутера Cisco в качестве «железки» для SOHO, мы натолкнулись на проблему не в SOHO-применении. У нас много оборудования на IOS-XE, где нет DNS, а есть BGP, OSPF и прочие «серьёзные» штуки, да и роутеры зафаерволленные по самые помидоры. Зато присутствует так называемая OOB-сеть, намеренно физически и логически очень примитивная. Она изолирована от основной сети и имеет отдельный канал в интернет с LTE-резервированием.

Фактически  это роутер ISR4331 с жирной свитч-картой в SM-слоте, которая смотрит во всякие админки иных железок. Именно там у нас и случилась ситуация категории «и на старуху бывает проруха», где мы раздали наружу DNS и NTP впридачу.