Операционная система 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. Ниже представлены ключевые параметры конфига. Безусловно, это не целый конфиг, а только строчки для предметного изучения проблемы. Заметим из конфига: В нём есть локалка с префиксом 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, который выглядит так:  Другой подход: завести выделенный ACL для целей администрирования, если предполагается расширение этого списка. Не забывайте, что бывает ещё и IPv6, но в нашем примере его нет: Здесь мы видим наш сегмент LAN и некий отдельный хост 198.51.100.254, который тоже имеет права доступа. Представим, что это внешняя система мониторинга. Немного коснёмся защиты типовых сетевых служб. SSH и Telnet ограничиваются в секциях line. Количество vti уточняйте у своей модели. SNMP-сервер в принципе отвечает только явно прописанным хостам. HTTP-сервер, если он вам зачем-то нужен, закрывается следующим образом. Общий обзор логики происходящего: если нужен сервис servername, то в секции ip servername ищем что-то похожее на access-class и указываем там наш ACL, не забыв про address-family. А вот с DNS не так всё очевидно. Впрочем, и там есть возможность ограничить доступ через функционал DNS view, которых может быть ещё и несколько. Делается это в два этапа: создаём view, а дальше применяем его для DNS-сервера. У нас примитивный рекурсивный резолвер для локалки, так что во view не будет ничего больше, чем разрешение резолвить имена нашей локалке. В этом случае логично будет переиспользовать ACL для NAT: Следом надо применить этот view к серверу добавлением строки: Итак, конфиг DNS будет выглядеть примерно так: Бонусом обсудим технологию из прошлого, которую эксплуатируют для DDoS-атак в тандеме с DNS — NTP. Дело в том, что если настроить синхронизацию времени на роутере по NTP с внешними пулами, то сам роутер станет NTP-сервером. Это стандартное поведение, обусловленное спецификой протокола. Пользуются этим сервером NTP как во благо (нужен сервер времени в локалке), так и во вред всякие пионеры-дидосеры всё для тех же amplification атак. Типовой конфиг NTP выглядит примерно так: Напомним: будьте поаккуратнее с использованием DNS-имён для NTP-серверов — это часто тормозит загрузку роутера. Рекомендуется использовать IP-адреса. Если зачем-то необходимо указывать сервера пулов с использованием доменных имён, то рекомендуется устанавливать список таких серверов времени через планировщик, чтобы это происходило уже после полноценной загрузки железки, когда она гарантированно уже имеет доступ к внешним службам. Тем не менее, использовать DNS всё равно не рекомендуется. Проиллюстрируем, почему. Ограничение доступа к NTP осуществляется тоже через access-group, но с нюансом. Дело в том, что в отдельном списке должны быть перечислены IP-адреса серверов пулов, с которыми вы синхронизируетесь. Если так не делать, то либо время синхронизироваться не будет, либо сервер NTP будет публичным. Таковы особенности протокола. Например, если адреса ваших референс мастеров 198.51.100.5 и 203.0.113.5, то настройки ограничения доступа должны выглядеть примерно так: Напоследок: не забудьте ограничить L2-сервисы, которые смотрят в сторону провайдера. Риски работы без ограничений небольшие, конечно, но всё же есть. Эти настройки традиционно вешаются на конкретный интерфейс. Список ниже не исчерпывающий. Часть из них уже применяется в современных версиях и скрыта из конфига по умолчанию: Забавный факт в том, что хотя статья посвящена применению роутера Cisco в качестве «железки» для SOHO, мы натолкнулись на проблему не в SOHO-применении. У нас много оборудования на IOS-XE, где нет DNS, а есть BGP, OSPF и прочие «серьёзные» штуки, да и роутеры зафаерволленные по самые помидоры. Зато присутствует так называемая OOB-сеть, намеренно физически и логически очень примитивная. Она изолирована от основной сети и имеет отдельный канал в интернет с LTE-резервированием. Фактически  это роутер ISR4331 с жирной свитч-картой в SM-слоте, которая смотрит во всякие админки иных железок. Именно там у нас и случилась ситуация категории «и на старуху бывает проруха», где мы раздали наружу DNS и NTP впридачу.  Sysadmin