Операционная система IOS/IOS-XE роутеров Cisco — источник вдохновения для большого числа других производителей. В Сети навалом инструкций, как сконфигурировать типовой роутер Cisco для сценариев SOHO. Однако, в отличие от «бытовых» роутеров, с настройкой такого конструктора, как Cisco IOS, придётся действовать аккуратно. Если не напрягать голову, то роутер начнёт жить своей жизнью и станет, к примеру, 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 впридачу.