Комментарии 33
Возможно я не прав, ибо с цисками только начинаю общаться, но точно ли высказывание «во второй строке разрешает трафик из сетей 192.168.1.0 – 192.168.31.0. » В аксес листе же от 192.168.0.0 или так и должно быть?
А вообще, очень познавательно. Спасибо за статью. Странно, что минусуют. Для меня, как для начинающего цисковода и пользователя ACL это интересно.
Минусуют потому, что есть как минимум
habrahabr.ru/post/147996/,
habrahabr.ru/post/121806/,
habrahabr.ru/post/60492/,
и еще 100500 таких же статей в Интернете.
habrahabr.ru/post/147996/,
habrahabr.ru/post/121806/,
habrahabr.ru/post/60492/,
и еще 100500 таких же статей в Интернете.
Идея динамический ACLов полезна, чтобы добавить второй фактор авторизации без VPN-а, например для удаленный пользователей которые ходят в терминал. Но вот реализация что-то мне не очень нравится. У DFL-ов она сделана отдельным специальным способом (то есть даже если там ввести админские логин и пароль, то конфигурировать роутер не даст), через http(s), и позволяет применять разные динамические политики в зависимости от того, кто авторизовался. Объяснить простому пользователю про телнет, да еще и выставлять интерфейс конфигурации роутера на всеобщее обозрение — плохая идея.
Возможно конечно такое и на циске можно сделать, надо порыться. Но в том виде в котором динамические ACL-ы приведены в статье, они сильно менее полезны чем таковые в реализации NetDefend от (прости господи) D-Link-а.
Возможно конечно такое и на циске можно сделать, надо порыться. Но в том виде в котором динамические ACL-ы приведены в статье, они сильно менее полезны чем таковые в реализации NetDefend от (прости господи) D-Link-а.
a) Речь идет про базовый функционал
b) Можно использовать для подключения ssh (плюс подключаться на альтернативый порт). Интерфейс не совсем выставляется.
c) Для аутентификации (и последующей авторизации) можно использовать внешние TACACS или RADIUS.
b) Можно использовать для подключения ssh (плюс подключаться на альтернативый порт). Интерфейс не совсем выставляется.
c) Для аутентификации (и последующей авторизации) можно использовать внешние TACACS или RADIUS.
Да то все понятно. Для таких целей вообще хорошо бы VPN использовать и не париться.
Но согласитесь, авторизация по http(s) в два клика все равно всяко удобнее, чем RADIUS, особенно если вам нужно всего пяток таких пользователей пустить.
По поводу b): что значит «интерфейс не совсем выставляется». Если я так подключусь, пусть и на нестандартный порт, и введу админские логин и пароль, то меня что, не пустит в режим конфигурации?
Но согласитесь, авторизация по http(s) в два клика все равно всяко удобнее, чем RADIUS, особенно если вам нужно всего пяток таких пользователей пустить.
По поводу b): что значит «интерфейс не совсем выставляется». Если я так подключусь, пусть и на нестандартный порт, и введу админские логин и пароль, то меня что, не пустит в режим конфигурации?
При чем здесь админские права? Если я назвал пользователя root, это не означает получение доступа к роутеру вообще :)
В IOS изначально нет никаких пользователей.
В IOS изначально нет никаких пользователей.
Извиняюсь за резкость. Идея: человек подключается, аутентифицируется – потом доступ к ресурсу. Не к роутеру, а сквозь него. Т.е. роутер выступает посредником между пользователем и ресурсом. Про доступ к роутеру речь вообще не идет.
Смысл поста понятен более чем полностью. Вопрос не в этом.
Для того, чтобы авторизоваться, пользователь должен подключится к роутеру по telnet/ssh. то есть попасть в стандартный vty.
Когда пользователь подключается с логином и паролем (неважно каким) что он видит? Стандартное приглашение на ввод, типа ciscoGATE>?
Если да, то введя логин и пароль пользователя с 15 уровнем привилегий, я спокойно смогу сказать en, потом conf t и конфигурировать роутер.
Если при подключении так маршрутизатор активирует ACL, и сразу отключает сессию, то как тогда войти в локальный vty для конфигурации устройства (иногда есть потребность иметь такую возможность)?
Для того, чтобы авторизоваться, пользователь должен подключится к роутеру по telnet/ssh. то есть попасть в стандартный vty.
Когда пользователь подключается с логином и паролем (неважно каким) что он видит? Стандартное приглашение на ввод, типа ciscoGATE>?
Если да, то введя логин и пароль пользователя с 15 уровнем привилегий, я спокойно смогу сказать en, потом conf t и конфигурировать роутер.
Если при подключении так маршрутизатор активирует ACL, и сразу отключает сессию, то как тогда войти в локальный vty для конфигурации устройства (иногда есть потребность иметь такую возможность)?
Но пользователей и ssh доступ иногда некоторые извращенцы еще используют и для конфигурирования устройства. :)
А в качестве сервера аутентификации можно использовать AD (при наличии Cisco ACS) или любой RADIUS.
Хехе, похоже на укороченную скомпонованную статью из официального руководства cisco к CCNA. Готовитесь или только что сдали? ;)
Кроме log есть еще log-input, когда асл один на многих интерфейсах, что бы понимать, на каком интерфейсе правило сработало. Еще можно метить произвольным текстом
WORD User defined cookie (max of 64 char)
Облегчает парсинг, что бы регекспом не выбирать по сложному условию на коллекторе логов (а правило может быть достаточно широким), можно искать по ключевому слову, которым метится строка правила.
WORD User defined cookie (max of 64 char)
Облегчает парсинг, что бы регекспом не выбирать по сложному условию на коллекторе логов (а правило может быть достаточно широким), можно искать по ключевому слову, которым метится строка правила.
НЛО прилетело и опубликовало эту надпись здесь
CBAC естественно лучше. Но требует лицензирования.
В одной очень не маленькой сети одного очень не маленького холдинга на inspect так обожглись, что больше не страдают этой фигней. Оно красиво… в теории. Раз прикладной протокол «порвало» этим инспектом, два, три… на четвертый это людям надоело.
НЛО прилетело и опубликовало эту надпись здесь
Не надо самому приписывать собеседнику нечто, а потом это высмеивать. Обожглись не на файрволе, а на попытке «сделать из роутера маленький универсальный файрвольчик». Для этого есть другие решения. Тоже, кстать, не идеальные. Косячит в той или иной степени все, что пытается лезть в ent-to-end протоколы, будь это хоть L7, хоть L4. Опорному роутеру это делать вообще ни к чему, если только по бедности. И на счет марлевой повязки — ерунда. Надо разделять задачи. L3 ACL прекрасно справляются со своими. А то, что льется через открытые в них «дыры» все сложней и сложней подвергать нормальной инспекции. Тренд корпоративный последнего времени — размытие периметра, везде ssl тунели и подобное (+ необходимость учитывать контекст более сложный, чем время суток), защита смещается на уровень хоста, чем бы он не являлся, обычным компом или мобильным девайсом. Что не отменяет необходимость классических L3 ACL как первого рубежа защиты.
net-geek.org/dbg/2008/08/dont-fuck-with-tcp.html
net-geek.org/dbg/2008/08/dont-fuck-with-tcp.html
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Cisco IOS ACLs