Операционная система IOS/IOS-XE роутеров Cisco — источник вдохновения для большого числа других производителей. В Сети навалом инструкций, как сконфигурировать типовой роутер Cisco для сценариев SOHO. Однако, в отличие от «бытовых» роутеров, с настройкой такого конструктора, как Cisco IOS, придётся действовать аккуратно. Если не напрягать голову, то роутер начнёт жить своей жизнью и станет, к примеру, DDoS-амплификатором.
![](https://habrastorage.org/getpro/habr/upload_files/078/554/d3e/078554d3ed5d2d9b9acc6026f1f0d5d0.jpg)
Вообще оборудование на базе 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. Способов два:
Отключение ненужных служб. К примеру, мало кому нужен встроенный HTTP-сервер.
Если службу отключать нежелательно (как в случае с 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 впридачу.