ACL и межсетевой экран на маршрутизаторе: пошаговые инструкции для Cisco, MikroTik, Huawei

Зачем совмещать маршрутизацию и фильтрацию? Основы безопасности на сетевом уровне

Маршрутизатор, как шлюз между сетевыми сегментами, становится идеальной точкой принуждения политик безопасности. Совмещение функций маршрутизации и фильтрации на одном устройстве позволяет контролировать трафик на границе сети без необходимости в отдельном межсетевом экране. Это экономит бюджет, упрощает архитектуру и снижает задержки. Типичные сценарии включают разделение офисных и гостевых сетей Wi-Fi, защиту серверного сегмента от пользовательского и ограничение доступа в интернет для определенных групп.

Ключевой принцип - понимание порядка обработки пакетов. На большинстве платформ политики безопасности применяются либо до, либо после поиска маршрута, что напрямую влияет на логику правил и их взаимодействие с протоколами маршрутизации, такими как OSPF или BGP. Ошибка в порядке может полностью заблокировать связность, даже если таблица маршрутизации корректна.

Как пакет проходит через маршрутизатор: порядок обработки ACL и маршрутов

Путь пакета через маршрутизатор Cisco IOS (версии 15.x и выше) строго регламентирован. Для трафика, входящего на интерфейс, последовательность следующая:

1. Входной ACL (Access Control List): Пакет проверяется по спискам контроля доступа, примененным к интерфейсу с ключевым словом in. Если правило deny совпадает, пакет отбрасывается.
2. Маршрутизация: На основе IP-адреса назначения определяется исходящий интерфейс и next-hop, консультируясь с таблицей маршрутизации (FIB).
3. Выходной ACL: Пакет проверяется по ACL, примененному к исходящему интерфейсу с ключевым словом out.
4. Исходящий интерфейс: Пакет передается на физический или виртуальный интерфейс для отправки.

На MikroTik RouterOS (версии 7.x) логика реализована через цепочки фильтров в /ip firewall filter. Основные цепочки для маршрутизируемого трафика - forward. Однако для полного контроля важно понимать цепочки prerouting (до маршрутизации) и postrouting (после маршрутизации).

Для диагностики потерь пакетов на Cisco используйте команду debug ip packet [detail] <access-list-number> с крайней осторожностью и только в тестовой среде, так как она генерирует высокую нагрузку на CPU. Альтернатива - анализ счетчиков срабатываний правил ACL командой show access-lists.

Классические списки контроля доступа (ACL): настройка на Cisco, Huawei и MikroTik

Списки контроля доступа - это фундаментальный статический (stateless) механизм фильтрации. На Cisco IOS синтаксис разделен на стандартные ACL (номер 1-99, 1300-1999), фильтрующие только по исходному IP-адресу, и расширенные (номер 100-199, 2000-2699), которые работают с протоколом, исходным/целевым адресом и портами.

Пример создания расширенного именованного ACL, который запрещает доступ из сети пользователей 192.168.10.0/24 к серверному сегменту 10.0.0.0/24, но разрешает весь остальной трафик:

ip access-list extended PROTECT-SERVERS
 deny ip 192.168.10.0 0.0.0.255 10.0.0.0 0.0.0.255
 permit ip any any

После создания ACL применяется к интерфейсу:

interface GigabitEthernet0/1
 ip access-group PROTECT-SERVERS in

Важно помнить о неявном правиле deny any any в конце каждого ACL. Если его не переопределить явным permit, весь трафик, не совпавший с предыдущими правилами, будет заблокирован.

Практический пример: ACL для изоляции гостевой Wi-Fi сети на Cisco IOS

Рассмотрим типовой сценарий: гостевой Wi-Fi в подсети 172.16.30.0/24, основная корпоративная сеть - 192.168.1.0/24, интернет доступен через интерфейс GigabitEthernet0/0.

Цель: разрешить гостям доступ только в интернет по HTTP, HTTPS и DNS, полностью запретив доступ к корпоративной сети.

! Создаем ACL для гостевого трафика
ip access-list extended GUEST-POLICY
 ! Разрешаем DNS (UDP/TCP порт 53) на внешние серверы
 permit udp 172.16.30.0 0.0.0.255 any eq 53
 permit tcp 172.16.30.0 0.0.0.255 any eq 53
 ! Разрешаем HTTP и HTTPS
 permit tcp 172.16.30.0 0.0.0.255 any eq 80
 permit tcp 172.16.30.0 0.0.0.255 any eq 443
 ! Явно запрещаем доступ к корпоративной сети
 deny ip 172.16.30.0 0.0.0.255 192.168.1.0 0.0.0.255
 ! Разрешаем установленные соединения (ответный трафик из интернета)
 permit tcp any 172.16.30.0 0.0.0.255 established
 ! Неявный deny any any блокирует все остальное

! Применяем ACL на интерфейс, смотрящий в гостевую сеть
interface Vlan30
 description Guest-WiFi
 ip address 172.16.30.1 255.255.255.0
 ip access-group GUEST-POLICY in

Правило established разрешает только TCP-пакеты с установленным флагом ACK, что позволяет ответам из интернета возвращаться гостям, но блокирует новые входящие соединения извне.

Особенности настройки ACL на MikroTik RouterOS и Huawei VRP

Хотя концепция фильтрации по адресам и портам едина, синтаксис и реализация различаются.

В MikroTik порядок правил в цепочке критически важен - обработка идет сверху вниз. Для блокировки нежелательного трафика правило с действием drop должно находиться выше общих разрешающих правил. Подробнее о методологии аудита и анализе существующих правил на разных платформах читайте в полном руководстве по аудиту сетевого периметра.

Zone-Based Firewall (ZBF) на Cisco IOS: современный подход к безопасности

Zone-Based Firewall (ZBF) - это более гибкая и мощная stateful-модель безопасности по сравнению с классическими ACL. Вместо привязки политик к интерфейсам, ZBF работает с концепцией зон (Zones). Интерфейсы назначаются зонам, а политики безопасности определяются для трафика, перемещающегося между парами зон (zone-pair).

Основные преимущества ZBF:

• Stateful инспекция: Отслеживание состояния соединений (как в полноценном межсетевом экране).
• Централизованное управление: Политики определяются между зонами, а не на каждом интерфейсе.
• Гибкость: Легко добавлять новые интерфейсы в существующие зоны без изменения политик.

Базовая модель включает зоны: Inside (доверенная внутренняя сеть), Outside (ненадежная сеть, например, интернет) и DMZ (демилитаризованная зона для публичных серверов).

Пошаговая настройка Zone-Based Firewall для малого офиса

Сценарий: офисная сеть (Inside) имеет доступ в интернет (Outside) и к веб-серверу в DMZ. Интернет-пользователи могут обращаться только к веб-серверу в DMZ.

1. Создание зон безопасности:

   zone security INSIDE
   zone security OUTSIDE
   zone security DMZ
   

2. Назначение интерфейсов зонам:

   interface GigabitEthernet0/1
    zone-member security INSIDE
   interface GigabitEthernet0/0
    zone-member security OUTSIDE
   interface GigabitEthernet0/2
    zone-member security DMZ
   

3. Создание class-map для идентификации трафика:

   ! Трафик от Inside к Outside (веб-серфинг)
   class-map type inspect match-any INSIDE-TO-OUTSIDE-CLASS
    match protocol http
    match protocol https
    match protocol dns
   
   ! Трафик от Outside к DMZ (доступ к веб-серверу)
   class-map type inspect match-any OUTSIDE-TO-DMZ-CLASS
    match protocol http
    match protocol https
   

4. Создание policy-map с действиями:

   ! Политика для трафика из Inside в Outside
   policy-map type inspect INSIDE-TO-OUTSIDE-POLICY
    class type inspect INSIDE-TO-OUTSIDE-CLASS
     inspect
    class class-default
     drop
   
   ! Политика для трафика из Outside в DMZ
   policy-map type inspect OUTSIDE-TO-DMZ-POLICY
    class type inspect OUTSIDE-TO-DMZ-CLASS
     inspect
    class class-default
     drop
   

   Действие inspect включает stateful проверку, разрешая ответный трафик.
5. Создание пар зон и применение политик:

   zone-pair security INSIDE-TO-OUTSIDE source INSIDE destination OUTSIDE
    service-policy type inspect INSIDE-TO-OUTSIDE-POLICY
   
   zone-pair security OUTSIDE-TO-DMZ source OUTSIDE destination DMZ
    service-policy type inspect OUTSIDE-TO-DMZ-POLICY
   

6. Проверка конфигурации: Используйте команды show zone security, show zone-pair security и show policy-map type inspect zone-pair sessions для проверки состояния сессий.

Сравнение механизмов безопасности: Cisco ZBF vs. MikroTik Filter vs. Huawei ACL

Выбор инструмента зависит от задачи, требуемого уровня безопасности и доступной платформы.

Выводы: Для простых задач «разрешить/запретить» по адресу и порту достаточно классических ACL на Cisco или Huawei. Если требуется отслеживание состояний соединений и более четкое разделение сетевых зон, выбирайте Cisco ZBF. MikroTik предлагает компромисс - мощный и гибкий инструментарий фильтрации, который, при правильной настройке connection tracking, может выполнять многие функции stateful-фаервола, что делает его популярным решением для малого и среднего бизнеса. Для защиты критически важных сервисов, таких как игровые или веб-серверы, часто требуется комбинация подходов. Пример комплексной настройки для защиты инфраструктуры можно найти в руководстве по защите CS2 серверов от DDoS-атак.

Готовые шаблоны правил для распространённых угроз и задач

Ниже представлены проверенные шаблоны правил для разных платформ. Порядок правил внутри ACL или цепочки имеет решающее значение - от более конкретных к общим.

1. Защита от IP-спуфинга (на внешнем интерфейсе):
Запрещаем входящий трафик из приватных (RFC 1918) и зарезервированных адресных пространств, который не должен приходить из интернета.

! Cisco IOS (применить на внешнем интерфейсе 'in')
ip access-list extended ANTI-SPOOFING
 deny ip 10.0.0.0 0.255.255.255 any
 deny ip 172.16.0.0 0.15.255.255 any
 deny ip 192.168.0.0 0.0.255.255 any
 deny ip 127.0.0.0 0.255.255.255 any
 deny ip 224.0.0.0 15.255.255.255 any
 permit ip any any

2. Ограничение доступа к административным интерфейсам (SSH, Telnet, Web):
Разрешаем доступ только с доверенной управляющей подсети 192.168.100.0/24.

! MikroTik RouterOS
/ip firewall filter add chain=input protocol=tcp dst-port=22,23,8291 src-address=192.168.100.0/24 action=accept comment="Allow Admin Access"
/ip firewall filter add chain=input protocol=tcp dst-port=22,23,8291 action=drop comment="Drop All Other Admin Traffic"

Аналогичный подход применяется для защиты веб-интерфейсов любых устройств. Детальный гайд по настройке доступен в статье Безопасность веб-интерфейсов.

3. Базовые правила для VoIP (SIP и RTP):

! Huawei VRP
acl number 3100
 rule 5 permit udp source any destination any destination-port eq 5060  # SIP
 rule 10 permit udp source any destination any destination-port range 10000 20000  # RTP порты

4. Правило для логирования всего запрещенного трафика:
Это правило помогает в аудите и отладке. Размещается в конце ACL перед неявным deny.

! Cisco IOS
ip access-list extended LOGGING-ACL
 ... ваши основные правила ...
 deny ip any any log  ! Логирует каждый отброшенный пакет

Логи с высокой частотой могут перегрузить CPU или syslog-сервер. Используйте это правило временно для диагностики или с осторожностью в рабочих средах.

Отладка и проверка: убеждаемся, что правила работают как задумано

После настройки политик необходимо убедиться в их корректной работе. Методика тестирования: от общего к частному. Сначала проверьте базовую связность (ping), затем доступ к конкретным сервисам (telnet, curl).

Ключевые команды для проверки:

• Cisco IOS: show access-lists - отображает все ACL и счетчики срабатываний (hits) для каждого правила. Нулевые счетчики могут указывать на неверный порядок правил или путь трафика.
• Cisco IOS (ZBF): show policy-map type inspect zone-pair sessions - показывает активные сессии, отслеживаемые Zone-Based Firewall.
• MikroTik RouterOS: /ip firewall filter print stats-only - выводит статистику по каждому правилу фильтрации (packets, bytes).
• Huawei VRP: display acl all или display acl <number> - показывает конфигурацию и счетчики правил ACL.

Простейший план теста для ACL, разделяющего сети:

1. С хоста в сети A выполните ping до адреса в сети B. Ожидаемый результат: «Request timed out».
2. Выполните show access-lists на маршрутизаторе. Убедитесь, что счетчик у правила deny увеличился.
3. Проверьте доступ к разрешенному ресурсу, например, DNS-серверу. Счетчик у соответствующего правила permit также должен увеличиться.

Что делать, если политика безопасности нарушила маршрутизацию?

Типичные ошибки, которые приводят к нарушению связности:

1. Применение ACL на неправильном интерфейсе или направлении (in/out). ACL in фильтрует трафик, входящий на интерфейс, out - исходящий. Неверное направление заблокирует трафик до или после маршрутизации.
2. Забытое правило permit для служебных протоколов. Если на интерфейсе, где работает OSPF или BGP, применен ACL, необходимо добавить правило, разрешающее multicast-адреса 224.0.0.5/224.0.0.6 (OSPF) или TCP-порт 179 (BGP).
3. Блокировка ответного трафика из-за stateless-природы ACL. Классические ACL не отслеживают состояние сессии. Если вы разрешили исходящий HTTP-запрос, нужно также явно разрешить входящий TCP-трафик с установленным флагом ACK (используя ключевое слово established на Cisco) или настроить stateful-механизм.

Алгоритм диагностики:

1. Проверьте счетчики ACL. Команда show access-lists покажет, срабатывают ли ваши правила. Если счетчики не растут, трафик идет другим путем или не достигает интерфейса с ACL.
2. Временно добавьте логгирование. В конце ACL перед неявным deny добавьте правило deny ip any any log (на Cisco) или используйте действие log в MikroTik. Это поможет увидеть, какой трафик отбрасывается.
3. Проверьте таблицу маршрутизации. Убедитесь, что для целевой сети существует корректный маршрут (show ip route на Cisco).
4. Поэтапно откатывайте изменения. Если проблема сложная, последовательно удаляйте или комментируйте последние внесенные изменения, проверяя восстановление связности после каждого шага.

Для защиты от более сложных угроз, таких как распределенные атаки на уровне приложений (L7), часто требуется специализированная настройка. В этом случае может помочь интеграция с сервисами, агрегирующими возможности различных AI-моделей для анализа и фильтрации трафика, подобно тому, как AiTunnel агрегирует доступ к API нейросетей. Однако основой всегда остается корректно настроенный базовый сетевой экран на маршрутизаторе.