четверг, 26 октября 2017 г.

CCNP Route "Full Scale" Лаба: Management



Признаться, я порядком подустал в процессе этой лабароторки. Сегодня "свежая струя", скажем так. Ну вот прям по списку и пойдем...


8. Management (IPv4/IPv6)
- SNMP v2
- SNMP v3
- TFTP/SCP operation
- Archives
- Syslog
- Netflow
- VTY ACL (IPv4/IPv6)
- Debugging (conditional)
- Time Based ACL
- NTP (Server, Peer, Client, Authentication, ACL)
- TACACS server
- uRPF

SNMPv2

Тут все довольно просто. Указываем сервер, community и ACL, который ограничивает доступ. Настроим, например, на О3.

snmp-server community SECRET_COMMUNITY RO 10
snmp-server community WRITE_COMMUNITY RW 10
access-list 10 permit 192.168.0.100

Теперь заходим на наш SNMP Manager, роль которого выполняет Cacti. Для начала указываем адрес и community.


 Далее проходит проверка


После этого Cacti будет строить несколько графиков для устройства O3.



SNMPv3

Здесь немного улучшили вопрос безопасности, но в продакшене я SNMPv3 так и не видел.
В SNMPv3 есть три "стратегии":
  • noAuthNoPriv - для аутентификации используется username, шифрования нет
  • AuthNoPriv - аутентификация с помощью MD5 или SHA-1, шифрования нет
  • AuthPriv - аутентификация с помощью MD5 или SHA-1, шифрование с помощью DES, 3DES, AES
Также в SNMPv3 используется концепция USER, GROUP, VIEW.
  • VIEW
  • GROUP
  • USER
Произведем настройки на E5.

Первым делом создадим ACL для ограничения доступа.

access-list 10 permit 192.168.0.100

Создадим два VIEW. Один с полным доступом к дереву MIB, второй только для просмотра Up Time.

snmp-server view ALL iso included
snmp-server view UPTIME_ONLY sysUpTime included

Создадим пару групп. Первая группа сможет и читать и писать во view ALL. Дополнительно указываем ACL. Вторая группа сможет только читать данные из view с именем UPTIME_ONLY. Наворачиваем ACL и здесь. В первой группе используем модель priv, что означает, что мы будем использовать максимально защищенную стратегию AuthPriv. Вторая группа использует политику auth, т.е. шифрования нет.

snmp-server group RW v3 priv read ALL write ALL access 10
snmp-server group OPERATORS v3 auth read UPTIME_ONLY access 10

Теперь создаем пользователей и помещаем их в группы. Здесь же указываем аутентификацию и параметры шифрования. Первый пользователь - administrator, использует SHA аутентификацию с паролем admin_pass и шифрование с алгоритмом AES 128 c ключом CRYPTO_KEY.  Второй пользователь - operator, для него мы ничего шифровать не собираемся, использует пароль oper_pass по алгоритму SHA.

snmp-server user administrator RW v3 auth sha admin_pass priv aes 128 CRYPTO_KEY
snmp-server user operator RW v3 auth sha oper_pass

Все. Юзеров, к слову, в CLI в running-config посмотреть не получится, только специфическими командами show.


Возвращаемся к Cacti.

Железки у нас не нагружены, так что и графики будут так себе )


TFTP


Для начала старый добрый TFTP. На стороне клиента самый обычный tftpd-hpa со следующими настройками.

TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/srv/tftp"
TFTP_ADDRESS=":69"
TFTP_OPTIONS="--secure --create"

Заходим на E5 и копируем running-config, например.


Смотрим на сервере


SCP

По сути, это способ передавать файлы поверх SSH. Удобно. На стороне наших устройств нужно дать всего лишь две команды.

ip scp server enable
aaa authorization exec default local

После чего без труда копируем конфиг прям с нашей линукс машины средствами стандартного SCP.


Archives

Простой способ бекапить конфигурацию устройств по расписанию или при сохранении конфигурации.

Настройка проста. Указываем путь. Используем две переменные ($h - имя хоста, $t - время). Далее указываем, что мы хотим бэкапить конфиг при выполнении команды wr. Ну и раз в сутки (1440 минут) тоже не помешает.

archive
 path tftp://192.168.0.100/$h-$t
 write-memory
 time-period 1440

Теперь, когда мы будем выполнять wr, мы увидим маленький такой восклицательный знак...


Это значит, что конфиг был отправлен на tftp сервер. Это можно проверить как локально


, так на сервере


К слову, можно их ещё и сравнивать. Команда show archive config diff не уместилась на скриншоте.


Вообще, штука очень полезная и простая в настройках.

Syslog


Этот сервис позволяет слать логи на удаленный сервер, что удобно, если устройство, например, совсем умерло. Есть и возможность слать вообще все команды на syslog. Со стороны сервера обычный rsysog c практически дефолтными настройками. Скажу лишь, что накрутить там можно многое. И ротацию и разбор по директориям и прочее такое.

Настроить отправку логов на уделаннеый syslog сервер очено просто.

logging host 192.168.0.100

Также сделаем необходимые изменения в секции archive, включим отправку всех команд на syslog.

archive
 log config
  logging enable
  notify syslog contenttype plaintext
 path tftp://192.168.0.100/$h-$t
 write-memory
 time-period 1440

Немного поконфигурируем E5 и глянем в логи на сервере.


Netflow


Настроить NetFlow в Cisco можно разными способами. Мы же настроим простейший вариант. Будем отслеживать что там делает наш одинокий клиент только в диагностических целях. Будем смотреть на порт e0/3 на R5 и отправлять флоу на наш сервер, на котором запущен nfcapd командой nfcapd -p 2056 -l /tmp.



На R5 настраиваем сам net-flow

ip flow-export source Loopback2
ip flow-export version 9
ip flow-export interface-names
ip flow-export destination 192.168.0.100 2056

И запихивает туда все с интерфейса e0/3

interface Ethernet0/3
 ip vrf forwarding CUSTOMER1
 ip address 10.0.1.1 255.255.255.0
 ip flow ingress
 ip flow egress

Можно посмотреть локальные net-flow данные.


Так, соответствующая flow должна прилететь на нашу линукс машину. Чем там клиент занимается? Пингует что-то...


VTY ACL

Все тривиально. Создаем ACL

ip access-list extended VTY_ACCESS
 permit ip 10.0.0.0 0.255.255.255 any

Вешаем на VTY

line vty 0 4
 access-class VTY_ACCESS in
 exec-timeout 0 0
 transport input ssh

Теперь попробуем зайти на устройство  R5 с подсети 10.0.0.0/8.


А вот с сервера 192.168.0.100 не работает.


Debugging

Про обычный дебаг все ясно, а вот с conditional не совсем. Этот инструмент позволяет как-то сузить поиски и сократить количество сообщений валящихся в дебаг.

Допустим, нужно отдебажить RIP на R5, но нас интересует только интерфейс eth0/0. Установим соответствующий condition. Их может быть и несколько, кстати. Далее запускаем debug и радуемся.


Time-based ACL


Позволяют нам применять ACL по времени. Например, пусть на R5 можно будет зайти только в рабочее время. Доработаем уже существующий ACL, но сначала нужно создать сам time-range.

time-range WORKDAYS
 periodic weekdays 8:00 to 17:00
!
ip access-list extended VTY_ACCESS
 permit ip 10.0.0.0 0.255.255.255 any
 permit ip 10.0.0.0 0.255.255.255 any time-range WORKDAYS

Ну и как бы все.

NTP

Тут все несколько сложней и надо освежать знания из CCNP Switch.

Сущесвтует три режима NTP:
  • Server - является источником времени для клиентов
  • Client - получает время от серверов синхронизируя с ними часы
  • Peer - синхронизирует время в двустороннем порядке с другим пиром
Доставлять время клиентам можно как средствами broadcast, так и multicast.

В нашей топологии E3/R2 и E4/O2 будут является серверами для всей сети. Между собой они будут синхронизировать время и являться пирами. На них абсолютно симметричная настройка.

clock timezone MSK 3 0
ntp master 1
ntp peer 10.0.30.X

После чего они начнут синхронизировать свои часы.


Подвох в том, что сервера у нас два и IP у них два, а нужен один. Логично настроить FHRP, хоть он и в скойпе CCNP Switch. Для этого немного изменим подсеть на линке между E3/R2 и E4/O2, чтобы в неё влез Virtual IP.

interface Ethernet0/1
 ip address 10.30.34.1 255.255.255.0
 standby 1 ip 10.30.34.100
 ipv6 address 2001:A:0:3034::A/127

interface Ethernet0/1
 ip address 10.30.34.2 255.255.255.0
 standby 1 ip 10.30.34.100
 ipv6 address 2001:A:0:3034::B/127

Теперь настроим на всей остальной сети NTP сервер 10.30.34.100. Active HSRP нода будет обрабатывать запросы до тех пор, пока с ней что-то не случится. Обратимся к E7, пока что достаточно только одной команды ntp server 10.30.34.100.


Добавим немного секьюрности. Во-первых, мы можем авторизовать источник (!) по ключу. Т.е. мы настраиваем на сервере некий ключ, если клиент ему доверяет, он будет синхронизировать время, если нет, то нет.

На серверах указываем ключ и включаем аутентификацию

ntp authentication-key 1 md5 NTP_KEY
ntp authenticate
ntp trusted-key 1

На клиенте делаем похожие операции. Крепим его к серверу.

ntp authentication-key 1 md5 NTP_KEY
ntp authenticate
ntp trusted-key 1
ntp server 10.30.34.100 key 1

После чего, все продолжает работать в номральном режиме. 

Вопрос. Что будет, если мы уберем ассоциацию ключа и сервера на клиенте? Перестанет ли синхронизироваться время. Правильный ответ - нет. Все будет работать как и раньше. Потому что мы аутентифицируем не клиента, а источник времени - сервер. А вот если на сервере нет соотвесвтующего ключа, а клиент его хочет видеть, то синхронизация не произойдет.

Можно ещё и ACL навернуть на серверах, чтобы абы кто не лез со своими запросами. Настроим пару ACL, одним будем ограничивать то, с кем мы будем пириться. А вторым обозначим клиентов.

access-list 2 permit 10.30.34.0 0.0.0.255  
access-list 3 permit 10.0.0.0 0.255.255.255

Далее применяем их в соответствующих направлениях.

ntp access-group peer 2
ntp access-group serve-only 3

TACACS server

Ох, моя любимая тема. Такие протоколы как TACACS или RADIUS позволяют выносить AAA за пределы устройства.

Ещё при подготовке окружения я смастерил простенький конфиг.

key = "supersecretkey"

user = melhiour {
    default service = permit
    login = cleartext "melhiour"
    member = admin
}

group = admin {
    service = exec {
        priv-lvl = 15
    }
  
Теперь настроим Е7

Укажем сервер

tacacs server FIRST
 address ipv4 192.168.0.100
 key supersecretkey

Определим его в группу, если вдруг появится второй.

aaa group server tacacs+ TAC_GROUP
 server name FIRST

Теперь непосредсвтенная настройка.
Аутентификация через группу, если не получится, то локально. Авторизация консоли включена. Авторизация команд - с TACACS сервера или локально, но только если пользователь аутентифицирован. Отправляем начало и конец конфигурирования на TACACS, как и сами команды, но только 15го уровня.

aaa authentication login default group TAC_GROUP local
aaa authorization console
aaa authorization exec default group TAC_GROUP local if-authenticated
aaa accounting exec default start-stop group TAC_GROUP
aaa accounting commands 15 default start-stop group TAC_GROUP

Т.к. используем группу default, то указывать его на VTY и консоли нет смысла. Если бы группа была отлично от дефолтной, то везде пришлось бы её указывать. 

Теперь SSH будет использовать TACACS, в случае его недоступности - локальную базу пользователей.

Зайдем на E7 через SSH и "выстрелим себе в ногу".


На сервере теперь можно посмотреть, кто это сделал.


uRPF

Позволяет отслеживать ситуацию с несимметричным роутингом. Каждый раз при получении пакета, роутер будет проверять в какой интерфейс пришел пакет. Сущесвует несколько режимов:
  • Strict mode - Если роутер не использует этот интерфейс для передачи трафика обратно, то он такой пакет прибьет.
  • Loose mode - роутер будет проверять только доступность источнка по своей таблице маршрутизации. С опцией allow-default маршрут по умолчанию тоже будет учитываться.

Команды довольно просты.

ip verify unicast source reachable-via rx
ip verify unicast source reachable-via any allow-default

Фух...

8. Management (IPv4/IPv6)
- SNMP v2
- SNMP v3
- TFTP/SCP operation
- Archives
- Syslog
- Netflow
- VTY ACL (IPv4/IPv6)
- Debugging (conditional)
- Time Based ACL
- NTP (Server, Peer, Client, Authentication, ACL)
- TACACS server
- uRPF
Ярлыки: , , , ,

Комментариев нет:

Отправить комментарий