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

Привет! Я Семёнов Евгений Сергеевич, директор ITFresh. У меня за плечами уже 15 лет погружения в корпоративные сети по всей Москве и Подмосковью. Знаете, сейчас под моим личным присмотром 28 офисов, и все они работают исключительно на оборудовании Cisco. Мы ставим всё: от скромных маршрутизаторов ISR 4321 в нотариальных конторах до мощнейших коммутаторов Catalyst 9300 на производстве, где до 50 рабочих мест. Вот о чём я сегодня хочу поговорить: как ACL на самом деле, по-живому, работают в реальных офисах. Забудьте про сухие учебники и класс A – давайте посмотрим правде в глаза!

Зачем ACL малому и среднему бизнесу

Какой вопрос я слышу от руководителей чаще всего? «Зачем нам вообще эти ACL, если на каждом компьютере Касперский стоит?» Понимаю их сомнения. В таких случаях я всегда привожу один очень показательный пример. Он произошёл совсем недавно, в 2024 году, и заставил многих пересмотреть свои взгляды.

Представьте себе: мебельное производство в Москве, наш клиент, всего 32 рабочих места. Типичная история, но с ужасающими последствиями. Почему-то гостевой Wi-Fi совсем не был изолирован от основной корпоративной сети. А вишенка на торте? К роутеру можно было спокойно достучаться из гостевого сегмента по адресу 192.168.1.1, да ещё и с паролем по умолчанию: admin/admin! В кабинете директора стоял сервер 1С – там вся клиентская база, все финансовые отчёты. Что в итоге? На встречу пришёл подрядчик, подключился к гостевому Wi-Fi. Через 15 минут он уже был в админке роутера. Ещё 5 минут, и вот, через 20 минут вся база 1С у него в кармане. А мы? Мы узнали об этом лишь полгода спустя! Конкуренты начали обзванивать наших клиентов, предлагая им их же заказы, но дешевле. Вот так, друзья, бывает.

Именно поэтому после такого случая я не просто рекомендую — я ставлю минимум одну ACL в каждый офис, где есть серверы 1С. Это даже не обсуждается! Главное здесь — изоляция гостевого сегмента. Поймите, это не какая-то там «защита от хакеров» в стиле голливудских фильмов. Это просто базовое разделение трафика. Чтобы ни один случайный человек, случайно оказавшийся в вашем офисе, даже близко не смог увидеть или дотянуться до ваших ценнейших серверов.

В офисе от 25 до 50 рабочих мест, но корпоративная сеть не сегментирована? Значит, у вас так называемая «плоская» сеть. А это что значит? Любой, кто воткнул кабель или подключился по Wi-Fi, автоматически видит все устройства. Смотрите сами: бухгалтер видит сервер 1С — это, конечно, норма. Но когда уборщица, подключенная к гостевому Wi-Fi, тоже видит тот же сервер 1С — вот это уже проблема. А представьте, если уязвимый сетевой принтер с устаревшей прошивкой получает доступ к серверу 1С? Это уже настоящая катастрофа! И тут на помощь приходят ACL – главный инструмент Cisco. Именно они помогают навести порядок в этом цифровом беспорядке.

Стандартные vs расширенные ACL: разница на пальцах

В Cisco IOS существуют два основных типа списков доступа. Признаюсь, поначалу в них легко запутаться, поэтому я всегда показываю их работу на живых, практических задачах. Никакой сухой теории!

Стандартный ACL — простой как палка. Фильтрует только по адресу источника, не различает протоколы и порты. Номера 1–99 и 1300–1999. Пример:

access-list 10 permit 192.168.10.0 0.0.0.255
access-list 10 deny any log

Что это даёт? Разрешаем трафик только от источников из подсети 192.168.10.0/24, а всё остальное — блокируем, причём с обязательным логированием. Идеально для простых, но критичных задач. Допустим, вам нужно ограничить доступ к management VLAN строго определённой подсетью — вот тут он незаменим.

Расширенный ACL — основной рабочий инструмент. Номера 100–199 и 2000–2699 либо именованные. Различает протоколы, источники, назначения, порты. Пример из моей практики (изоляция гостевого Wi-Fi):

ip access-list extended GUEST-OUT
 deny ip any 192.168.10.0 0.0.0.255 log
 deny ip any 192.168.20.0 0.0.0.255 log
 permit ip any any

Этот ACL работает так: он полностью блокирует любой гостевой трафик, который пытается попасть в корпоративные подсети 10 и 20, но при этом даёт гостям свободно выходить в интернет. Куда мы его ставим? Прямо на интерфейс VLAN гостевого Wi-Fi, на исходящем направлении.

Шесть рабочих сценариев из моих проектов

Сценарий 1: изоляция гостевого Wi-Fi

Сейчас расскажу про базовый сценарий, который я настраиваю буквально на каждом проекте. Просто наш стандарт. У нас есть гостевая сеть в VLAN 99. И, конечно, несколько корпоративных подсетей: VLAN 10 — для пользователей, VLAN 20 — для серверов, а VLAN 30 — специально для IP-камер.

ip access-list extended GUEST-FILTER
 remark Block internal access from guest network
 deny ip any 10.0.0.0 0.255.255.255 log
 deny ip any 172.16.0.0 0.15.255.255 log
 deny ip any 192.168.0.0 0.0.255.255 log
 remark Allow DNS to corporate DNS
 permit udp any host 10.20.0.10 eq 53
 remark Allow everything else (Internet)
 permit ip any any
!
interface Vlan99
 ip access-group GUEST-FILTER in

Сценарий 2: доступ к серверу 1С только из бухгалтерии

Бухгалтерия находится в подсети 192.168.10.0/24. Сервер 1С стоит на 192.168.20.10, используя порт 1541 — это стандартный порт для 1С, кстати. Важно: все остальные пользователи не должны иметь прямого доступа к базе. Они работают через тонкие клиенты, подключенные к терминальному серверу, что намного безопаснее.

ip access-list extended PROTECT-1C
 remark Allow accountants
 permit tcp 192.168.10.0 0.0.0.255 host 192.168.20.10 eq 1541
 permit tcp 192.168.10.0 0.0.0.255 host 192.168.20.10 eq 1560
 permit tcp 192.168.10.0 0.0.0.255 host 192.168.20.10 range 1561 1591
 remark Allow terminal server
 permit tcp host 192.168.20.20 host 192.168.20.10 eq 1541
 permit tcp host 192.168.20.20 host 192.168.20.10 eq 1560
 permit tcp host 192.168.20.20 host 192.168.20.10 range 1561 1591
 remark Allow admin from management
 permit tcp 192.168.30.0 0.0.0.255 host 192.168.20.10 eq 3389
 deny ip any host 192.168.20.10 log
 permit ip any any
!
interface Vlan20
 ip access-group PROTECT-1C in

Сценарий 3: блокировка SMB/RDP в гостевой Wi-Fi

Что, если гость по какой-то случайности всё-таки оказался в корпоративном сегменте? Ну, бывает, с коммутатором ошиблись. Так вот, даже тогда он не должен получить доступ ни к каким общим папкам (шарам), ни к RDP! Мы ставим превентивный ACL прямо на уровне агрегации — это наш надёжный запасной план.

ip access-list extended BLOCK-RANSOMWARE
 remark Block SMB ports across segments
 deny tcp any any eq 445 log
 deny tcp any any eq 139 log
 deny udp any any eq 137
 deny udp any any eq 138
 remark Block RDP except from helpdesk
 deny tcp any any eq 3389 log
 permit tcp 192.168.30.0 0.0.0.255 any eq 3389
 permit ip any any

Этот ACL мы применяем на всех vlan-интерфейсах, кроме серверных. Зачем? Он буквально отсекает латеральное распространение шифровальщиков. Знаете, после одной серьёзной атаки в 2025 году, когда пострадал один из наших офисов, я твёрдо решил: теперь такую защиту ставим абсолютно везде!

Сценарий 4: VTY ACL — защита от подключения к маршрутизатору

Это моё правило номер один. Первое, что я делаю, когда начинаю работать с новым маршрутизатором. Если этого не сделать? Тогда к консоли может подключиться кто угодно и откуда угодно. А это, согласитесь, совсем не дело.

ip access-list standard VTY-ALLOW
 permit 192.168.30.0 0.0.0.255
 permit host 10.20.30.40
 deny any log
!
line vty 0 4
 access-class VTY-ALLOW in
 transport input ssh
 login local
line vty 5 15
 access-class VTY-ALLOW in
 transport input ssh
 login local

Сценарий 5: блокировка известных вредоносных IP

У меня есть свой, личный чёрный список IP-адресов. Это те, с которых наши клиенты, ITFresh, уже сталкивались с атаками. И что вы думаете? Каждый месяц я вручную обновляю ACL на всех пограничных маршрутизаторах, чтобы ни один из них не проскочил!

ip access-list extended BLACKLIST-IN
 deny ip 185.244.25.0 0.0.0.255 any log
 deny ip 45.153.160.0 0.0.0.255 any log
 deny ip 89.248.165.0 0.0.0.255 any log
 permit ip any any
!
interface GigabitEthernet0/0/0
 description WAN to ISP
 ip access-group BLACKLIST-IN in

Сценарий 6: time-based ACL для гостевого Wi-Fi только в рабочее время

Один наш клиент — салон красоты прямо в центре Москвы. У них такая история: с обеда гости подключаются к Wi-Fi, а к вечеру... ну, половина этих «гостей» уже соседи из соседнего здания! Признайтесь, кто не любит сэкономить на своём интернете? Вот поэтому мы настроили гостевой Wi-Fi так, чтобы он работал строго в рабочее время. И всё, никаких «халявщиков» после закрытия!

time-range WORKING-HOURS
 periodic weekdays 9:00 to 21:00
 periodic Saturday 10:00 to 20:00
!
ip access-list extended GUEST-TIME
 permit ip any any time-range WORKING-HOURS
 deny ip any any
!
interface Vlan99
 ip access-group GUEST-TIME in

Грабли при работе с ACL

Пятнадцать лет в IT — это, знаете, сколько шишек набить можно? Лично я наступал на одни и те же грабли по пять, а то и больше раз. Своим опытом делюсь специально, чтобы вы могли обойти эти ловушки стороной.

• Implicit deny в конце. В каждом ACL в конце неявно стоит deny ip any any. Если забыть финальный permit ip any any, отрежете весь трафик. Особенно болезненно при удалённой настройке.
• Wildcard mask vs subnet mask. В ACL используется wildcard (инверсия маски). Подсеть 192.168.10.0/24 в ACL пишется как 192.168.10.0 0.0.0.255, а не 255.255.255.0. Перепутать легко, отлаживать тяжело.
• Порядок правил имеет значение. ACL обрабатывается сверху вниз, при первом совпадении работа прекращается. Если поставить permit ip any any первой строкой, всё остальное игнорируется.
• Применение в обоих направлениях. Часто забывают, что ACL ограничивает трафик в одном направлении. Для двусторонней защиты нужны два ACL — на in и на out.
• Обновление существующего ACL. На IOS до версии 12.3 при удалении строки удалялся весь ACL. На современных IOS можно добавлять/удалять отдельные строки через sequence numbers, но если вы редактируете критичный ACL — сначала сохраните копию через show run | section.
• Логирование любого правила. Опция log заставляет CPU обрабатывать каждый матч в software вместо hardware. На больших объёмах трафика это валит маршрутизатор. Лог только на отладке или для критичных правил.

Отладка ACL: как понять, что работает

Самые полезные команды для отладки:

• show ip access-list NAME — счётчики совпадений по каждому правилу.
• show access-list NAME | include matches — фильтр строк со счётчиками больше нуля.
• clear access-list counters NAME — обнуление счётчиков перед тестом.
• debug ip packet detail NAME — детальный лог каждого пакета (только для маленького тестового трафика, иначе CPU умрёт).
• show ip interface VlanX — показывает, какой ACL применён на интерфейсе.

Стандартный мой workflow при отладке нового ACL: применяю, очищаю счётчики, генерирую тестовый трафик с проверочной машины, смотрю счётчики через show ip access-list. Если ожидаемое правило не сработало или сработало не то, что нужно — сразу видно по нулевым/ненулевым счётчикам.

Документирование: то, что отличает мастера от шабашника

Любой ACL должен иметь remark-комментарии. Через полгода вы сами не вспомните, зачем поставили эту строку. Через два года придёт новый администратор и сломает всё.

Конечно, короткие ремарки прямо в конфиге — это удобно. Но только их недостаточно! Я, например, для каждого клиента обязательно завожу отдельный, прямо-таки подробный документ. Он живет в Confluence, и там есть кое-что очень важное: матрица доступа. Представьте ее в виде удобной таблицы. Что это вообще за матрица такая, спросите вы? Это, по сути, максимально ясное описание: кто именно, с какого адреса и к каким ресурсам имеет доступ. И что самое главное — зачем ему это нужно. Сейчас покажу, как выглядит типичная строка в такой матрице:

Cisco vs Mikrotik: честное сравнение для SMB

Спорить не буду: Cisco — оборудование, бесспорно, крутое. Но есть один нюанс, давайте взглянем правде в глаза: оно стоит целое состояние! Вот вам свежий пример: тот же ISR 4321 в 2026 году легко потянет на 380 тысяч рублей, а то и больше. А что, если я скажу вам, что есть альтернатива? Например, Mikrotik CCR2004 — он справится с большинством типичных офисных задач, даже если у вас 50 ПК, и при этом обойдётся всего в 65 тысяч. Чувствуете разницу? Именно поэтому мы часто советуем клиентам присмотреться к Mikrotik. Это очень достойная замена Cisco. В плане функционала там всё аналогично: firewall и filter rules в RouterOS выполняют ту же работу, что и ACL в IOS, а stateful inspection вообще идёт «из коробки». Экономия налицо, а качество остается на высоте!

Cisco остаётся оправдан, когда:

• Если у вас уже стоит большой парк оборудования Cisco, тут всё понятно. Полностью его менять? Зачастую это обойдётся дороже, чем просто поддерживать и обслуживать то, что уже есть.
• Нужна интеграция с Cisco ISE для NAC.
• Иногда бывает так: заказчик прямо требует «корпоративное» оборудование, и точка. Такое требование довольно часто встречается, например, в рамках государственных контрактов. Тут особо не поспоришь.
• Когда в офисе работают над по-настоящему тяжёлыми проектами — это, например, видеомонтаж или CAD-системы — обычных скоростей на агрегации просто не хватит. Тут нужны серьёзные цифры: 10 или даже 40 гигабит в секунду. Без этого никак.

FAQ — частые вопросы по Cisco ACL

Чем отличается стандартный ACL от расширенного?

Стандартный ACL фильтрует только по IP-адресу источника. Расширенный — по источнику, назначению, протоколу и порту. В корпоративных сетях я почти всегда использую только расширенные — они дают полный контроль над трафиком.

Где лучше применять ACL — на входе или выходе интерфейса?

По возможности — на входе ближе к источнику. Это разгружает CPU маршрутизатора, потому что нежелательный трафик отфильтровывается до маршрутизации. Расширенные ACL по cisco best practice применяются ближе к источнику.

Сколько ACL можно повесить на интерфейс?

Только по одному в каждом направлении: один на in, один на out. Это ограничение архитектуры IOS. Если нужно несколько правил — объединяйте в один ACL.

Влияет ли ACL на производительность маршрутизатора?

На современных Cisco ISR 4000-й серии — почти нет, обработка идёт в hardware. На старых 1900-х/2900-х серии большие ACL (300+ записей) могут давать просадку 10–15 % при пиковом трафике.

Можно ли заменить Cisco ACL на Mikrotik firewall?

Функционально — да, у Mikrotik firewall rules делает всё то же самое, плюс stateful inspection. Часто переход на Mikrotik экономит клиенту 50–70 % бюджета на оборудование без потери функциональности для офисов до 50 пользователей.