IOS vty ACL

Обнаружил одну интересную, нет, скорее подойдёт слово “странную”, особенность в использовании ACL для ограничения сетевого доступа к узлу. Уверен, что можно спокойно жить и без знания этой детали, но меня она действительно удивила.
Если искать в интернетах статьи, где рассказывается как ограничить доступ к vty, посредством как telnet, так и SSH, то можно отметить, что в 100% случаев используется standard ACL (ещё и обязательно цифровой, а не именованный, но, видимо, это такая дань old school).

Давайте лучше я объясню в чём проблема на примере конкретной схемы.

  • PC1 и PC2 это конечные узлы у которых R1 является default gateway;
  • R1 полностью сконфигурирован для успешного к нему доступа по SSHv2;
  • в line vty нет сконфигурированного access-class, поэтому любой может пытаться получить R1 CLI и более того, успешно получает.

В процессе роста сети всё большее внимание стало уделяться безопасности и было принято логичное решение – ограничить возможность получения удалённого доступа к сетевым узлам, а именно разрешить попытки подключения по SSH только из подсети 192.168.1/24. Подготовленные конфигурационные изменения R1 выглядели следующим образом:

Тесты показали, что действительно, с PC2 доступ уже не получить:

Фирма росла, в штате появился безопасник. И вот однажды, увидев это дело он говорит: “Вы что?! Все знают, что надо ограничивать доступ так узко, насколько это возможно! Необходимо, чтобы ограничивался не только IP “откуда”, но и “куда”! Распоряжение через час положу к тебе на стол!”. Никто не удивиться, что безопасник не понимает следующее:

  • мы уже сделали это ограничение на конкретном узле;
  • все интерфейсы R1 видны всем спользующим его хостам, благодаря обычной маршрутизации (он ведь DG для конечных станций);

И как бы понимаем, что, ладно уж, мы можем вместо подсети указать явно хост с которого возможно получить доступ к терминалу, но указывать “куда” ведь не имеет никакого смысла, как минимум по двум причинам указанным выше. Но, работа – делаем.
Начиная с релиза 12.4 доступны как именнованые ACL, так и возможность использоваться extended ACL, чем и воспользуемся.

Проверяем:

Как надо, а теперь с нашей станции:

(картинка позаимствована, как максимально уместная, из блога twistedminds.ru)

Похоже мы что-то неправильно сделали. Опечаток вроде нет, SRC и DST местами не перепутали. Давайте уберём упоминание TCP (ну мало ли), номер порта и добавим log к этому правилу, а так же log к deny.

И видим на R1 следующее сообщение:

Похоже, что несмотря на то что, нам дозволили использовать extended ACL, указывать явно Destination мы не имеет права, иначе потеряем доступ к терминалу вовсе.
Ну, не такой уж это и плохой результат, ведь мы сможет сказать безопаснику, что желаемое не реализуемо. Но с другой стороны, может быть немало конфигураций, где подобное ограничение будет необходимо уже именно нам и в этом случае “не получится” будет уже грустным.

Пример: менеджмент подсеть, в которую подцепляются out-of-band интерфейсы наших сетевых узлов и эти интерфейсы находятся в отдельном management VRF. Мы хотим на самих устройствах указать “куда” можно цепляться для получения терминала (это IP-адреса mgmt-интерфейсов), а на некоем устройстве агрегирующем линки от них указать “откуда” можно пытаться это сделать. Тем самым упростив общую конфигурацию, благодаря чему можно быстро эту политику менять. И, к сожалению, слово “можем” здесь только рядом с “хотеть”, а не со “сделать”.

Надеюсь ознакомление с этим фактом уже сейчас, избавит вас от удивления потом.

Hint: в NX-OS это работает отлично.

SHARE: Tweet about this on TwitterShare on FacebookShare on VKShare on LinkedInShare on Google+Email this to someone