ASA. Статья 4. Удаленное управление

Удаленное управление

Понятно, что при нынешнем развитии сетей передачи данных было бы неразумно не внедрять удаленное управление межсетевыми экранами. Поэтому ASA, как и большинство устройств cisco, предоставляет несколько способов удаленного управления.

Самое простое и небезопасное – telnet. Чтобы предоставить доступ на ASA по телнету необходимо явно указать, с каких хостов и сетей и на каком интерфейсе разрешен доступ, а также необходимо задать пароль на телнет командой passwd:

telnet 192.168.1.128 255.255.255.128 inside
telnet 192.168.1.254 255.255.255.255 inside
passwd {пароль}

В целях безопасности работа по телнету на самом небезопасном (с наименьшим уровнем безопасности в рамках данной ASA) интерфейсе заблокирована и обеспечить работу на этом интерфейсе по телнету можно только в том случае, если он приходит через IPSec туннель.

Более безопасный доступ к командной строке обеспечивается протоколом ssh. Однако, для обеспечения доступа по ssh кроме явного указания того, с каких хостов можно заходить для управления, необходимо также задать RSA ключи, необходимые для шифрования данных о пользователе. По умолчанию для подключения по ssh используется пользователь pix и пароль, задаваемый командой passwd (пароль на telnet).

! Задаем имя домена
domain name {имя}
!
! Желательно задать недефолтовое имя хоста
hostname {имя}
!
! После этого можно сгенерировать ключи
crypto key generate rsa
!
! Разрешаем ssh
ssh 192.168.1.128 255.255.255.128 inside
ssh 1.2.3.4 255.255.255.255 outside
passwd {пароль}

Как правило, на ASA начиная с версии 7.2 имя домена уже задано (domain.invalid) и дефолтные ключи сгенерированы, однако как минимум это надо проверить

show crypto key mypubkey rsa

Наличие хотя бы каких то ключей RSA уже позволяет работать по ssh. Но можно дополнительно создать и недефолтовые ключевые пары. Для этого надо указать явно имя ключевой пары

crypto key generate rsa label {имя пары}

Чтобы удалить ключевую пару (или все пары) используется команда

crypto key zeroize rsa [label {имя пары}]

Совет: после любых действий  с ключевыми парами (создание, удаление) обязательно сохраняйтесь. Для этого можно использовать стандартные команды cisco

copy running-config startup-config
write memory

или короткий вариант последней команды

wr

Также ASA предоставляет крайне популярный метод настройки с использованием веб-броузера. Этот метод называется ASDM (Adaptive Security Device Manager). Для доступа используется безопасный протокол https. Обеспечение доступа настраивается очень похоже на настройку ssh: необходимо выработать или убедиться в наличии дефолтовых RSA ключей и указать, откуда можно подключаться.

domain name {имя}
hostname {имя}
crypto key generate rsa
! Включаем сам https сервер, по умолчанию часто включен. При включении
! генерирует самоподписанный сертификат.
http server enable
! Разрешаем https
http 192.168.1.128 255.255.255.128 inside
http 1.2.3.4 255.255.255.255 outside

Если больше ничего не настраивать, то доступ будет обеспечен без указания пользователя. Если же был указан пароль на привилегированный режим

enable password {пароль}

то при подключении надо в качестве пароля указывать именно его, не указывая пользователя.

Надо проверить, что во флеше ASA лежит файл ASDM, соответствующий используемой ОС.

dir flash:
show flash

При работе с ASDM используется java и верно следующее: если вы используете ОС версии 7.Х, то ASDM нужен версии 5.Х и java 1.5. Если же используется ОС 8.Х, то ASDM нужен версии 6.Х и java версии 1.6.  К чести разработчиков и радости настройщиков, ASDM версии 6 работает не в пример лучше и быстрее версии 5.Х. Чья тут заслуга: java или cisco или обоих – не знаю.

Возникает резонный вопрос: а если хочется использовать не дефолтовые правила доступа, а явно указывать, откуда брать пользователя? Для этого используются команды

aaa authentication telnet console {имя AAA сервера} [LOCAL]
aaa authentication ssh console {имя AAA сервера} [LOCAL]
aaa authentication http console {имя AAA сервера} [LOCAL]

Если используется только локальная база данных пользователей, то в правиле аутентификации можно указывать только LOCAL (проверьте, что хотя бы один пользователь создан, иначе можно себе заблокировать доступ), а если требуется использовать внешние базы, доступные по протоколам TACACS+, RADIUS или LDAP, то такие сервера надо предварительно настроить

aaa-server {имя AAA сервера} protocol {tacacs|radius|ldap}
aaa-server {имя AAA сервера} ({interface}) host {ip}
key {ключ}
! и другие команды, специфичные для данного типа сервера

Локальная база пользователей задается командой

user {пользователь} password {пароль} [privilege #]

Доступ по ASDM возможен только от имени пользователя с уровнем привилегий 15 (максимальный, означает, что пользователю можно все настраивать)

Также локальным пользователям можно задать ряд атрибутов, используя команду

user {пользователь} attributes
! различные атрибуты пользователя

Завершая эту часть приведу кусочек конфига. В нем настроено 2 интерфейса (в данном случае это gigabitethernet 0/0 и 0/1, однако на разных платформах это могут быть и другие физические интерфейсы), inside и outside, дефолтный маршрут, разрешен удаленный доступ по ssh и https ото всюду, при этом аутентификация использует локальную базу данных пользователей.

hostname MyAsa
!
domain name anticisco.ru
!
interface g0/0
nameif outside
security-level 0
ip address 1.1.1.2 255.255.255.252
no shut
!
int g0/1
nameif inside
security-level 100
ip address 10.1.1.1 255.255.255.0
no shut
!
! на ASA запись 0.0.0.0 можно сократить до 0
!
route outside 0 0 1.1.1.1
!
username admin password cisco privilege 15
!
ssh 0 0 inside
ssh 0 0 outside
!
http 0 0 inside
http 0 0 outside
!
aaa authentication ssh console LOCAL
aaa authentication http console LOCAL

Используя такие настройки вы разрешите пакетам ходить из непосредственно присоединенной сети за интерфейсом inside наружу. Снаружи будут приходить только ответы по сессиям, открытым изнутри, т.к. напомню по умолчанию трафик идущий «внутрь» весь запрещен. Как его разрешить поговорим в следующей части.

Источник: anticisco.ru/blogs/2010/02/asa-статья-4-удаленное-управление/