Нечеловеческим усилием воли :) таки дописал обещанный кусочек по защите маршрутизатором — cut-through proxy. Я описал здесь далеко не все тонкости, а скорее как всегда «на пальцах», чтобы проще было понять. Умный боец да разберется дальше без меня :)
Задача этой технологии – проверять имя и пароль пользователя перед тем, как выпустить его наружу или пустить внутрь периметра. Это часть общей идеологии IBNS (Identity Based Network System), где определяющим является имя пользователя и именно по имени можно сопоставлять настройки конкретного клиента, например, список доступа, в котором описано, что можно данному клиенту.
Для проверки пользователей можно использовать внешние базы данных, доступных по протоколу TACACS (цискина технология, ТСР/49), RADIUS (стандартная технология, UDP/1645 или UDP/1812 для аутентификации, UDP/1646 или UDP/1813 для сбора статистики) или Kerberos 5 (технология Microsoft).
Для того, чтобы заставить маршрутизатор спрашивать внешние базы пользователей, необходимо включить новую модель ААА (Authentication,Authorization,Accounting)
aaa new-model
Эта команда коварна, т.к. включает правила аутентификации по умолчанию, а эти правила гласят «Использовать локальную базу данных пользователей». Если же локальных пользователей нет, то вы попадаете в ловушку (lockout), из которой выход только один – процедура восстановления пароля (password-recovery)
Далее, надо создать правило аутентификации, указывающее на внешний сервер и описать сам этот сервер: по какому протоколу с ним связываться, на какой адрес и с каким ключом
radius-server host {ip} key {ключ}
Или
tacacs-server host {ip} key {ключ}
aaa authentication login {имя} group {radius|tacacs}
Надо настроить правило перехватывающей аутентификации, указав по какому протоколу происходит первичное обращение клиента (http,telnet,ftp) и какой трафик инициирует ответ клиенту от циски (описывается списком доступа, где строчки permit означают «выдать клиенту окошко запроса на логин/пароль)
ip auth-proxy name {имя} {http|ftp|telnet} [list {ACL}]
По умолчанию – любой трафик по выбранному протоколу.
Теперь осталось описать, каким правилом аутентификации пользоваться при доступе по http и привесить правило аутентификации на интерфейс (правило всегда вешается на вход интерфейса)
Ro(config)# ip http authentication aaa [login-authentication {имя}]
Ro(config)# int f0/0 (внутренний интерфейс, откуда приходят пакеты от клиента)
Ro(Config-if)# ip auth-proxy {имя}
В старых IOS не было возможности явно указать правило аутентификации, используемое для аутентификации по http, т.е. всегда использовалось дефолтное правило и надо было его обязательно поменять для использования сервера TACACS или RADIUS
aaa authentication login default group {radius|tacacs}
Теперь же есть возможность явно указать не только правило для login по http, но и отдельно правило для командной авторизации и входа в режим exec через http (SDM,CCE)
Дополнительно, чтобы изначально пользователю разрешить чуть-чуть, и только после аутентификации явно разрешить ему то, что ему положено, надо на тот же интерфейс повесить довольно строгий список доступа, который бы разрешал только то, что можно всем и всегда, например, начальные пакеты для аутентификации и, например, какие то общие локальные ресурсы
ip access-list ext ZLOY
permit tcp any host 1.2.3.4 eq 80
permit tcp any host 172.16.1.100 eq 135
int f0/0
ip access-group ZLOY in
Т.к. входящий список доступа на интерфейсе всегда отрабатывает первым, то работать это будет так:
1. Приходит пакет. Мы его проверяем списком доступа, разрешен ли
2. Если разрешен, то дальше проверяем, пришёл ли пакет от аутентифицированного ip адреса источника.
3. Если нет, то проверяем, по какому протоколу пришёл пакет.
4. Если по протоколу, указанному в правиле ip auth-proxy, то выдаём в броузере, ftp или telnet приложении клиента окошко на ввод логин/пароля, в противном случае просто уничтожаем пакет
Разберём пример:
Пусть есть маршрутизатор, с внутренним интерфейсом f0/0. Мы хотим, чтобы трафик, направленный во все сети, кроме сети 172.16.1.0/24, сначала должен быть аутентифицирован по протоколу http.
Ro(config)# ip access-l ext AUTHACL
Ro(config-ext-nacl)#deny ip any 172.16.1.0 0.0.0.255
Ro(config-ext-nacl)#permit ip any any
Ro(config)# username admin pass cisco (на всякий случай, чтобы случайно себя не заблокировать)
Ro(config)# aaa new-model
Ro(config)# radius-server host 1.1.1.1 key cisco
Ro(config)# aaa authentication login AUTH group radius
Ro(config)# ip http server (включаем на циске http сервер)
Ro(config)# ip http authentication aaa login-authentication AUTH
Ro(config)# ip auth-proxy name OUT http list AUTHACL
Ro(config)# ip access-l ex ZLOY
Ro(config-ext-nacl)# permit tcp any h 1.2.3.4 eq 80
Ro(config)# int f0/0
Ro(config-if)# ip access-group ZLOY in
Ro(config-if)# ip auth-proxy OUT
Если вас не устраивает небезопасный протокол http, то можно использовать безопасный протокол https. Для этого надо выработать ключевую пару RSA и включить https сервер (самоподписанный сертификат циска выпишет сама)
Router(config)# hostname Ro (нужно задать не дефолтный hostname)
Ro(config)# ip domain name mydomain.com
Ro(config)#crypto key generate rsa [modulus-size {размер}] [label <метка>]
Ro(config)# do wr
Ro(config)# ip http secure-server
После этого соединения по https тоже будут перехватываться циской на предмет проверить логин/пароль.
Надо отметить, что технология довольно громоздкая, при работе по https существенно тормозит первое подключение, если не сохранить самоподписанный сертификат циски, как доверенный, и не слишком гибкая. Однако, позволяет проверять пользователей и их права и является неотъемлемой частью ряда реализаций по защите периметра.
Сергей Фёдоров
Задача этой технологии – проверять имя и пароль пользователя перед тем, как выпустить его наружу или пустить внутрь периметра. Это часть общей идеологии IBNS (Identity Based Network System), где определяющим является имя пользователя и именно по имени можно сопоставлять настройки конкретного клиента, например, список доступа, в котором описано, что можно данному клиенту.
Для проверки пользователей можно использовать внешние базы данных, доступных по протоколу TACACS (цискина технология, ТСР/49), RADIUS (стандартная технология, UDP/1645 или UDP/1812 для аутентификации, UDP/1646 или UDP/1813 для сбора статистики) или Kerberos 5 (технология Microsoft).
Для того, чтобы заставить маршрутизатор спрашивать внешние базы пользователей, необходимо включить новую модель ААА (Authentication,Authorization,Accounting)
aaa new-model
Эта команда коварна, т.к. включает правила аутентификации по умолчанию, а эти правила гласят «Использовать локальную базу данных пользователей». Если же локальных пользователей нет, то вы попадаете в ловушку (lockout), из которой выход только один – процедура восстановления пароля (password-recovery)
Далее, надо создать правило аутентификации, указывающее на внешний сервер и описать сам этот сервер: по какому протоколу с ним связываться, на какой адрес и с каким ключом
radius-server host {ip} key {ключ}
Или
tacacs-server host {ip} key {ключ}
aaa authentication login {имя} group {radius|tacacs}
Надо настроить правило перехватывающей аутентификации, указав по какому протоколу происходит первичное обращение клиента (http,telnet,ftp) и какой трафик инициирует ответ клиенту от циски (описывается списком доступа, где строчки permit означают «выдать клиенту окошко запроса на логин/пароль)
ip auth-proxy name {имя} {http|ftp|telnet} [list {ACL}]
По умолчанию – любой трафик по выбранному протоколу.
Теперь осталось описать, каким правилом аутентификации пользоваться при доступе по http и привесить правило аутентификации на интерфейс (правило всегда вешается на вход интерфейса)
Ro(config)# ip http authentication aaa [login-authentication {имя}]
Ro(config)# int f0/0 (внутренний интерфейс, откуда приходят пакеты от клиента)
Ro(Config-if)# ip auth-proxy {имя}
В старых IOS не было возможности явно указать правило аутентификации, используемое для аутентификации по http, т.е. всегда использовалось дефолтное правило и надо было его обязательно поменять для использования сервера TACACS или RADIUS
aaa authentication login default group {radius|tacacs}
Теперь же есть возможность явно указать не только правило для login по http, но и отдельно правило для командной авторизации и входа в режим exec через http (SDM,CCE)
Дополнительно, чтобы изначально пользователю разрешить чуть-чуть, и только после аутентификации явно разрешить ему то, что ему положено, надо на тот же интерфейс повесить довольно строгий список доступа, который бы разрешал только то, что можно всем и всегда, например, начальные пакеты для аутентификации и, например, какие то общие локальные ресурсы
ip access-list ext ZLOY
permit tcp any host 1.2.3.4 eq 80
permit tcp any host 172.16.1.100 eq 135
int f0/0
ip access-group ZLOY in
Т.к. входящий список доступа на интерфейсе всегда отрабатывает первым, то работать это будет так:
1. Приходит пакет. Мы его проверяем списком доступа, разрешен ли
2. Если разрешен, то дальше проверяем, пришёл ли пакет от аутентифицированного ip адреса источника.
3. Если нет, то проверяем, по какому протоколу пришёл пакет.
4. Если по протоколу, указанному в правиле ip auth-proxy, то выдаём в броузере, ftp или telnet приложении клиента окошко на ввод логин/пароля, в противном случае просто уничтожаем пакет
Разберём пример:
Пусть есть маршрутизатор, с внутренним интерфейсом f0/0. Мы хотим, чтобы трафик, направленный во все сети, кроме сети 172.16.1.0/24, сначала должен быть аутентифицирован по протоколу http.
Ro(config)# ip access-l ext AUTHACL
Ro(config-ext-nacl)#deny ip any 172.16.1.0 0.0.0.255
Ro(config-ext-nacl)#permit ip any any
Ro(config)# username admin pass cisco (на всякий случай, чтобы случайно себя не заблокировать)
Ro(config)# aaa new-model
Ro(config)# radius-server host 1.1.1.1 key cisco
Ro(config)# aaa authentication login AUTH group radius
Ro(config)# ip http server (включаем на циске http сервер)
Ro(config)# ip http authentication aaa login-authentication AUTH
Ro(config)# ip auth-proxy name OUT http list AUTHACL
Ro(config)# ip access-l ex ZLOY
Ro(config-ext-nacl)# permit tcp any h 1.2.3.4 eq 80
Ro(config)# int f0/0
Ro(config-if)# ip access-group ZLOY in
Ro(config-if)# ip auth-proxy OUT
Если вас не устраивает небезопасный протокол http, то можно использовать безопасный протокол https. Для этого надо выработать ключевую пару RSA и включить https сервер (самоподписанный сертификат циска выпишет сама)
Router(config)# hostname Ro (нужно задать не дефолтный hostname)
Ro(config)# ip domain name mydomain.com
Ro(config)#crypto key generate rsa [modulus-size {размер}] [label <метка>]
Ro(config)# do wr
Ro(config)# ip http secure-server
После этого соединения по https тоже будут перехватываться циской на предмет проверить логин/пароль.
Надо отметить, что технология довольно громоздкая, при работе по https существенно тормозит первое подключение, если не сохранить самоподписанный сертификат циски, как доверенный, и не слишком гибкая. Однако, позволяет проверять пользователей и их права и является неотъемлемой частью ряда реализаций по защите периметра.
Сергей Фёдоров
