Практика: IPS-сигнатуры и IPsec site-to-site VPN

Запись пошла. Сегодня у нас с вами 12 октября 2017 года, 9 день курса Cisco CCNA Security. Это последнее наше занятие, мы с вами прочитали все слайды, и у нас остались лабораторные работы. Сейчас мы посмотрим с вами в лабе, как работает IPS, про который вчера было много сказано, как работают у нас сигнатуры, как с ними можно поиграться, поработать, и может быть ещё что-то посмотрим. Я забыл сказать — я сегодня занимался там ASA, и в новой ОС, в новых версиях, начиная по-моему с версии 87, может быть — сейчас не скажу с какой версии — появилась возможность

делать VTI, виртуальные туннельные интерфейсы. На ASA это появилось... ладно, я не буду врать, с какой версии. Раньше их не было, раньше вообще не было никаких виртуальных интерфейсов. Сейчас с виртуальными интерфейсами тоже не слишком всё хорошо на ASA, но туннельный интерфейс есть, что-то с ними можно попробовать. Кстати, почему нет — попробуем, заведётся — не заведётся, не знаю. Давайте сначала с IPS разберёмся. Мы с вами проговорили всё про IPS на роутерах, я рассказал вам и про сигнатуры, и про микродвижки. Давайте теперь будем это всё настраивать. ASA мы пока не трогаем, нам нужен будет здесь роутер. Давайте ASA будет как пинговалка, и хватит. Сценарий у нас

будет такой: неважно в принципе, какой интерфейс внутренний, какой внешний, на каком интерфейсе IPS будет работать. Мы сделаем так: мы будем настраивать функционал IPS на интерфейсе GigabitEthernet 0/0, который смотрит на ASA. ASA будет пинговать сервер 10.10.1.200 — он должен сейчас работать, мы с него будем сигнатуры загружать. ASA будет пинговать сервер, и IPS на прохождение трафика ICMP у нас должен ругаться. По умолчанию трафик ICMP в роутерном IPS считается нормальным, и роутер на него не ругается. Но мы будем негодовать — IPS, когда будет видеть ICMP-трафик. Поехали! Настройка очень простая. Сейчас быстренько настраиваем роутер — два интерфейса его — и ASA настроим просто: один интерфейс, на котором

укажем там по умолчанию шлюзом на ASA роутер. Этого достаточно будет. Давайте всё это дело настраивать. У нас всё сброшено почти в дефолт, поэтому я буду вместе с вами настраивать. Все у всех же роутера работают, правильно? Давайте сначала интерфейс GigabitEthernet 0/1. Он смотрит на сервер, IP-адрес у него будет 10.10.0.1 и номер комплекта. Что ещё? Да ничего больше не надо нам на этом интерфейсе делать. Проверим доступность сервера 10.1.200 — сервер доступен, он пингуется. Теперь внутренний интерфейс, который смотрит на ASA: 10.1.номер_комплекта.1. Интерфейс GigabitEthernet 0/0. 10.1.номер_комплекта.1.

Нам достаточно, никакие DHCP пока не будем поднимать. Так, у меня тут ничего нет, у меня роутер и DHCP 100 — он нам не нужен, все эти протоколы, все остальные выключены. Дальше, на ASA у нас будет адрес 10.1.номер_комплекта.2. Тут у нас ошибочка на слайде — это будет интерфейс GigabitEthernet 0/0. Надо не забывать, что интерфейс должен на ASA как-то называться. 10.1.номер_комплекта.2, security-level пусть будет 100.

Этого достаточно. Если с ASA пропинговать роутер, то всё должно быть видно. Тут тоже DHCP по-моему был настроен — DHCP нам не нужен. И сделаем маршрут по умолчанию на наш роутер вот таким образом. Маршрут по умолчанию статически у нас на ASA есть. Дальше нам нужно сделать вот какую вещь — мне нужно сделать... Я сейчас поставлю на паузу и настрою сервер. С первым заданием, очень простым, мы справились, у всех ASA пингует наш замечательный сервер. Давайте

IPS заниматься. Давайте заниматься IPS. Я буду рассказывать, как это настраивается. Может быть, это будет не супер подробно, но я думаю, что этой информации всем нам хватит, чтобы настроить. Я не буду сейчас останавливаться на том, как на старых IOS раньше настраивалось немножечко по-другому. На старых роутерах, когда система там версии 12.2 с балансом, как-то вообще там три команды задаёшь и всё работало. Но настройка была совсем не гибкая, там мало сигнатур было, и короче было не интересно. Сейчас у нас настраивается намного интереснее — у нас и сигнатуры хранятся отдельно

в специальном таком файле, сейчас всё немножечко по-другому. Давайте — с чего мы начнём настройку? Для начала неплохо бы нам создать на flash место, где мы будем с вами хранить конфигурационные файлы. IPS на роутере — ему нужна прям директория, конкретно создать. Он её и будет использовать. Если посмотреть, где мы её можем создать — мы можем создать на flash1. Создать директорию IPS просто командой mkdir. Она будет по умолчанию создавать на flash какие-то директории. Если кто-то про это на CCNP слушал, хотя на CCNP по-моему там работа с файловой системой — кто совсем нет ничего. Дальше, вторая задача. Роутерный IPS он будет использовать криптографию, асимметричную

криптографию, для того чтобы проверять подписи сигнатур. У файла с сигнатурами есть — Cisco, когда выпускает файл с сигнатурами, она подписывает его своей цифровой подписью. Для того чтобы этот файл всё-таки заработал у нас, эту подпись необходимо сначала проверить. Чтобы проверить подпись, нужен публичный ключ, который нужно забивать руками. Давайте создадим сейчас с вами ключ. Мы его руками прям создаём, ниоткуда не сертификаты берём, а прям руками создаём хранилище для ключа и забиваем в него ключ. Это делается следующим образом, если я правильно помню все команды. Тоже команд на самом деле много здесь будет. По-моему, я помню их правильно. Остановился на том,

что нам нужен публичный ключ от Cisco. Делаем таким образом: создаём хранилище ключей — это будет crypto key pubkey-chain, и создадим собственно сам ключ named-key. Дальше здесь мы можем назвать — я не помню, может, по-моему, можно называть как угодно. И публичный — вот таким образом. Давайте дальше смотреть. Сейчас подождите секундочку. И теперь нужно забить сам ключ. Сам ключ у нас

представляет вот такую hex-строку. Я сейчас подключусь ко всем вашим роутерам и забью этот ключ, а то у вас copy-paste не работает, вы будете до утра забивать. Давайте теперь собственно к настройке самого IPS. Можно делать таким образом: можно сначала всё настроить, а потом уже загрузить сигнатуры. Можно в принципе сначала сигнатуры скачать с сервера, а потом всё настроить. Давайте сначала скачаем сигнатуры, и потом уже всё остальное настроим. Идём в директорию IPS, всё, я уже в ней. И говорим copy TFTP flash — сюда положим. Теперь адрес хоста 10.10.1.200. Файл у нас будет называться — сейчас я посмотрю, как он

называется. Он переименованный, я надеюсь, что при проверке файл не будет ругаться, я надеюсь, что имя файла в хэш не входит. Я думаю, что прокатит. SigPackage — вот так он назвался. И копируем файлы. Здесь есть очень важный момент: чтобы не делать сразу несколько действий, мы можем скопировать эти файлы и сразу их уже развернуть. Есть такая область памяти, idconf называется. Её можно представить как что-то типа show running для сигнатур. Можно просто скопировать файл на flash, а потом развернуть. А можно, по-моему,

сделать одной командой. Сейчас попробуем, будет ли он разворачиваться — сначала копируется файл, а потом он сразу разворачивается в нужную область памяти. У нас в принципе вся та же самая команда IPS, только добавляется idconf. По-моему, можно сделать... Нет, так сделать нельзя, я вас обманул, придётся сначала на flash копировать. Файл скачали. Теперь этот файл — он сначала не позволит развернуть в память, потому что ничего у нас ещё не настроено. Это в принципе нормально. Почему он не позволяет развернуть сигнатуры сразу в память? Потому что нужно сначала указать, какие сигнатуры для нас нужны и какие мы вообще не хотим компилировать, а потом уже ему дать команду, и он скомпилирует только нужные сигнатуры и их развернёт. Давайте смотреть, как всё это дело настраивается, будем командочки разбирать. Во-первых, ip ips name — мы

создаём именованный экземпляр нашего IPS. Потом по этому имени мы будем к нему обращаться, когда будем настраивать на интерфейсе. На интерфейсе будет именно работать IPS. Он настраивается на интерфейсе — какой трафик обрабатывать. Давайте назовём его там, не знаю, super IPS, super mega hyper IPS... потом не забыть, как его назвал. Дальше... IPS мы настроили. Ладно, хорошо, не будем так называть. Назовите его каким-нибудь простым, понятным именем. IPS... Как те, кто занимается программированием, знают —

очень часто программист пишет там my, если какой-то объект создают, копию объекта, то принято говорить my. Я не знаю, откуда взялось. Окей, теперь нам необходимо указать место, где IPS будет хранить свои конфиги. Это полезная команда, потому что IPS — смотрите, IPS в роутере он работает немножечко обособленно. Это отдельный программный модуль, и ему нужны прям отдельные места, где хранить свои конфиги, где хранить свои файлы. Поэтому эти вещи можно настраивать. В принципе можно, по-моему, не указывать, и он не должен ругаться — он будет хранить просто в корне flash. Дальше — ip ips config location — мы ему зададим, мы ему создали директорию: flash:/ips. На самом

деле и flash, и flash0 — прошу прощения — можно указывать по-разному, на этой платформе и то, и то ссылается туда же. Окей, теперь неплохо бы сказать, каким образом наш IPS будет ругаться. Есть такая вещь, как ip ips notify, где указывать ему, каким образом он будет посылать свои алерты, свою информацию о том, что что- то случилось. У нас есть вариант log — это обычный syslog-сообщение, про который мы уже очень хорошо всё знаем. Есть вариант SDEE — SDEE — это есть такой специальный протокол Security Device Event Exchange. По-моему, я правильно назвал. Security Device Event Exchange — этот протокол мы не рассматривали, просто надо сказать, что он

есть. Этот протокол предназначен для обмена именно сообщениями безопасности между устройствами. Он задумывался таким образом, в принципе многие устройства его поддерживают. Это протокол уровня приложений, это не какой-то свой сетевой протокол, как например у OSPF там или EIGRP, которые имеют свои сетевые протоколы. Нет, это протокол именно уровня приложений, он работает поверх HTTP. Теперь с помощью него роутер на IPS тоже умеет отправлять сообщения. Давайте мы в syslog будем всё отправлять, дополнительных параметров здесь никаких нет. Да, Миша правильно сказал, спасибо большое — на всякий случай сказать на консоли logging synchronous, чтобы у нас удобно было работать. Спасибо, Миша.

Давайте дальше смотреть, что ещё ему можно указать IPS. Вообще на самом деле здесь настроек дофига, и настраивать его из консоли очень и очень неудобно. Можно указать deny — нет, это мы пока сюда не будем лезть. Настройки памяти у него есть, мы можем сказать, сколько памяти ему выделять. Самое главное — теперь по поводу сигнатур. Смотрите, работать с сигнатурами я уже говорил — в консоли мега неудобно, правда неудобно. Поэтому лучше используйте, например, тот же Cisco Configuration Professional, в нём работать с сигнатурами удобнее. Но мы попробуем сейчас, как настоящие джедаи, всё повключать именно здесь. Смотрите,

все сигнатуры они будут разделены на какие-то категории. Этих категорий на самом деле дофига. Если посмотреть ip ips signature category и дальше сказать category — давайте наберём ещё раз, чтобы вы не путались, где команда, где просто я вопросик нажимаю. ip ips signature category — это мы входим в контекст работы именно с категориями этих сигнатур. И можем сказать category какая-то, категория, с которой мы сейчас будем работать. Какие категории есть: всякие там adware, spyware, атаки, DoS, email — их дофига на самом деле. Какие-то специфичные для операционных систем категории, там

peer-to-peer, вирусы, черви, спам, и cookie, и троянские кони, и так далее. На самом деле категорий у IPS много, все сигнатуры разбиты на категории просто для удобства работы и чтобы можно было выключать эти сигнатуры пачками. Не нужно держать включёнными все сигнатуры — я ещё раз повторю мысль, которую я уже высказывал: очень неплохо во-первых почистить трафик перед тем, как его скармливать IPS. Плюс мы должны знать, какой трафик вообще может появиться в нашей сети. Мы когда про zone-based firewall с вами рассуждали, я сказал, что неплохо бы вообще сначала понять, нарисовать может быть где-то весь трафик, который входит. С этим может помочь NBAR — есть такая штука NBAR, Network-Based

Application Recognition — это автоматическое распознавание трафика, типов трафика, приложений, которое есть на обычных роутерах. Но это здесь обсуждаться не будет, не всё в CCNP Security — не знаю, сейчас это обсуждается ли. Дело в чём — просто я свою мысль закончу: что если вы точно знаете, какой трафик у вас проходит через IPS, то включайте только те категории сигнатур, которые действительно нужны. Если у вас нет почтового трафика, то зачем вам нужны сигнатуры из категории email? Ну правда, не нужны. Если у вас здесь не будет, не знаю, никаких например SQL-серверов в этом сегменте, то эти сигнатуры тоже можно выключить. Зачем проверять трафик, где никогда в жизни не будет никаких атак на SQL-сервер? Если у вас нет SQL-сервера, то зачем проверять атаки на SQL-сервер? Они все

не достигнут никогда своей цели, потому что цели нет. Лучше всего IPS жалеть в этом отношении — это всё-таки дорогие очень операции в вычислительном плане. Поэтому мы говорим вот таким образом: category all — все категории — и мы их тупо выключаем. Помните, я вам рассказывал, что бывают сигнатуры retired и unretired? Retired — это те, которые не компилируются у нас и в память IPS не загружаются. Мы говорим category all и говорим retired yes — true. Мы выключаем вообще сначала все категории, а потом включим только самые основные. У нас есть такая категория ios-ips — это основные сетевые атаки, у них будет описано. Их мы включим. Сначала мы всё выключили, теперь идём в другую

категорию. Немножечко неудобно работать, но вы понимаете, что я сейчас перемещаюсь по контекстам: сначала зашёл в общий контекст работы с категориями, потом зашёл в контекст категории all и сказал, что всё retired — ничего не нужно, не компилировать, ничего вообще не надо делать. Теперь мы идём в категорию ios-ips. Можно и конкретную подкатегорию, потому что ios-ips — вот эта категория, видите, здесь она разбивается ещё на подкатегории. Нам нужны только basic-сигнатуры, самые простые, самые основные. Вот эти сигнатуры мы включаем. Мы говорим, что retired false — то есть здесь нет команды unretire, есть команда retired, они выключены — да, либо они выключены — нет. Мы сейчас говорим: выключены? Нет, не выключены. Всё, этого достаточно для начальной настройки категорий. Нам предложат сохранить эти настройки, и

IPS сейчас уже скажет, что мы применяем конфигурацию категорий ко всем сигнатурам. IPS пока не знает ещё, у него не загружено — это ничего, он просто знает, какие у него есть категории. Дальше, следующим шагом мы ещё ничего не включили — мы только с категориями разобрались. Следующим шагом мы в принципе уже можем загрузить всё в память. Почему бы и нет, давайте всё загрузим. Смотрите, основной шаг мы сделали — мы определили категории, с которыми наш IPS будет работать, и теперь в принципе можно всё это дело уже попробовать развернуть в памяти. Хотя нет, ещё нельзя — ещё нужно вот что сделать: мы настроили категории, теперь нужно его включить на

интерфейсе. Пока мы не включим на интерфейсе, он в памяти ничего не скомпилирует. Давайте идём на интерфейс. Какой у нас интерфейс? Интерфейс GigabitEthernet 0/0, тот который на ASA смотрит. Мы будем на нём всё делать. Теоретически это то же самое, как с access-листами — мы можем с другой стороны смотреть, но в этом не будет никакого смысла. Идём на интерфейс GigabitEthernet 0/0 и говорим, что на этом интерфейсе ip ips — я его назвал my-ips — включаем в направлении inbound. Можно в направлении outbound включить, также как access-лист, я в этом особого смысла не вижу — лучше на входе в наш роутер уже рубить всё. Теперь IPS нам ругается на нашу версию сигнатур. Сейчас я исправлю свою ошибку. На записи это — я протупил. То, что

последний раз я руками ключ добавлял 100 лет назад... Ключ нельзя именовать как угодно! Этот ключ должен быть именован, как сказано у Cisco. Именованный ключ он называется realm cisco.pub. После этого ключ будет работать, и сигнатуры наши нормально распакуются и скомпилируются. Давайте повторяйте команду: copy flash — где у нас лежит файл с сигнатурами, да, по такому пути — и мы копируем это в idconf, специальную область памяти. Это то же самое, как copy startup-config running-config — это же не копирование файла, а именно применение команд. Здесь похожая штука. После этого сейчас у нас ключ правильный, и у нас нормально цифровая подпись проверится. И смотрите логи — в принципе даже логи интересно почитать и посмотреть, потому что он здесь будет

говорить, например, про то, какие сигнатуры он загружает. Normalizer — помните, мы говорили про нормализацию протоколов, я немножечко рассказывал? Про atomic IP — вот эти микродвижки. Atomic IP смотрит только по одному IP-пакетику. Сервисные микродвижки — вот есть там сервисы, ищите. Теперь до сервисов — SAMBA вот, как пример. Сервисы HTTP, вот для HTTP больше всех сигнатур. String — вот эти тоже движки типа string и multi-string, которые смотрят регулярные выражения. String и multi-string смотрят регулярные выражения по содержимому пакета. В принципе всё. Когда нам IPS отрапортовал о том, что все движки у нас

скомпилировали свои сигнатуры, сейчас у нас IPS в принципе готов к работе. Его можно посмотреть: show ip ips signature count, например — количество сигнатур. Есть такая команда show ip ips count — он у нас в принципе покажет, сколько каких сигнатур какого типа у него есть, какие у нас сигнатуры enabled, какие retired, какие там устаревшие уже — здесь мы всё с вами видим. Вспоминайте наш разговор вчерашний про enabled, retired, unretired. Всего у нас сигнатур достаточно дофига загружено. Сейчас в настоящее время всего сигнатур у нас 2297 в этом наборе. Сейчас у нас

загружено 967 — вот они, включённые сигнатуры. Дальше, теперь давайте что ещё посмотреть: show ip ips configuration — конфигурация нашего IPS. Полезная команда, чтобы просто посмотреть, что где он держит, как мы его сконфигурировали, какие у нас нотификации установлены: syslog у нас включён, SDEE у нас выключен. По сигнатурам он тоже нам здесь скажет: активных 338, неактивных сигнатур столько-то. Дальше, давайте смотреть собственно его работу. Ходите, перерыв сделаем — уже полтора часа тут. Давайте тогда маленький перерыв, и мы сейчас попробуем посмотреть — сработает или не сработает на IPS нашу задачу. Все — пять минут, сейчас быстро чайку глотнём, и попробуем подкрутить сигнатурки и

посмотреть, как это делается. Смотрите, что в принципе нам хочется добиться от IPS: у нас сейчас как такового трафика не проходит через него, и специально какой-то вредоносный трафик мы с вами не можем сгенерить. Мы попробуем просто ICMP-трафик посчитать как вредоносный трафик и на него каким-то образом отреагировать. Работа с сигнатурами здесь представляет, я уже говорил, боль такую конкретную. Но мы попробуем, я думаю, что у нас получится. Давайте настраивать сигнатуры. Я уже рассказывал, что там в принципе можно что-то подкрутить, что-то посмотреть. Я забыл очень важную вещь вам рассказать — сейчас немножечко от сигнатур мы отступим. Есть ещё одна единственная простая команда, но эта

команда необходима вообще, когда мы работаем с сенсорами, и её лучше не забывать. Смотрите, мы с вами на интерфейсе GigabitEthernet 0/0 его включили. Если пойти на этот интерфейс, у нас есть офигенная команда: ip virtual-reassembly. Что делает эта команда? Помните вчерашние наши разговоры про некоторые техники обхода IPS, когда мы фрагментацию можем хитрую придумывать, фрагментацию, Stateless — вот такие все вещи? Эта команда включает сборку фрагментированных пакетов на интерфейсе. Это не только для IPS нужно, например, для zone-based firewall тоже полезно было бы. Теперь, когда роутер будет получать какие-то фрагментированные пакеты, фрагменты IP-пакета, он их не будет отправлять дальше до тех пор, пока не

получит последний фрагмент. Он получит все фрагменты, соберёт этот пакет полностью, дальше подсистема IPS либо zone-based firewall его обработает. Смысл я объясняю, Андрей: зачем его собирать — собирать для того, чтобы обработать полностью пакет. Мы же вчера — вспоминаете, я вчера рассказывал техники обхода IPS, когда можно взять и побаловаться с фрагментами? Вот эта команда очень полезная. В принципе она нагружает каким-то образом систему, я не хочу сказать, что прям будет какая-то бешеная нагрузка от пересборки этих пакетов. После проверки пакет роутер будет отправлять уже в собранном виде. Но если он пролезает по MTU, то он дальше отправит уже нормальный пакет собранный, он не

будет опять фрагментировать и опять эти фрагменты отправлять. Михаил говорит справедливо — в некоторых IOS я не могу сказать точно, на каких платформах, но в новых IOS эта команда, когда IPS включается, она тоже включается. Вот это очень важная такая ремарка. Когда работаете с IPS, неплохо было бы это включать — но не то что неплохо бы, надо это включить на интерфейсе. Давайте дальше разбираться с сигнатурами. Мы немножечко разобрались, как посмотреть сигнатуры, конфигурацию IPS мы посмотрели. Теперь давайте попробуем — давайте просто посмотрим, как выглядит сигнатура, что вообще в ней содержится. Можно посмотреть каждую конкретную сигнатуру: show ip ips — там длинная очень команда, я

сейчас документацию подглядываю, честно скажу, я наизусть не помню конечно. Show ip ips signature, и дальше нас просят сказать — там можно попросить сигнатуры для конкретных движков, можно в принципе всё сразу вывести, но это будет такая простыня, в которой никто не разберётся. Можно прям конкретную сигнатуру — у каждой сигнатуры есть ID, идентификатор — и сказать, что нам нужна сигнатура конкретного идентификатора. И у неё ещё есть sub-ID, то есть в каждой сигнатуре содержится не просто одно правило, может быть много правил. Сигнатура для ICMP, для пинга, echo request — она будет иметь ID 2004, и sub-ID здесь будет нулевой. Вот сейчас нам

система покажет всё, что касается этой сигнатуры. Сигнатура у нас enabled — она включена, она у нас скомпилирована. Теперь смотрите, я сказал, что в сигнатуре много чего содержится. Например, actions, которые будут содержаться в сигнатуре. Если посмотреть, то action у неё — alert: она будет просто ругаться. В принципе можно изменить action на deny. Я же говорил, что сигнатуры их можно подкручивать, можно подстраивать их все значения — вот эти значения можно там подкручивать, если нужно. Хотя зачастую значений по умолчанию хватает. Дальше — что это за сигнатура? Это просто реакция на пинг, на echo request.

Комментарий никакой не написан, и она относится к движку atomic IP. Этот движок проверяет единичные пакеты. И параметры: про фрагментацию ничего не сказано, ICMP type 8 и протокол ICMPv4. У нас здесь всё рассказано про то, что мы будем искать, какой движок запускать, что будем делать. Сейчас эта сигнатура — если посмотреть — она retired. Вот смотрите, все эти значения: она enabled — то есть да, enabled, она не disabled. Но она ещё retired. Она выключена по умолчанию — ну зачем действительно по умолчанию реагировать на каждый запрос, на каждый пинг? Поэтому всё это выключено. Дальше — скомпилирована? Нет, она не

скомпилирована, потому что она retired. Здесь будет всё расписано: severity — это какой будет severity отправляться в syslog. Андрей, вот в этом весь прикол, что так работать с ними не очень удобно. У IPS нет... Он по умолчанию — я к сожалению не могу сказать, какие сигнатуры включены по умолчанию, какие выключены по умолчанию. Здесь очень неудобно смотреть в консоли всё это дело, поэтому здесь удобнее пользоваться именно CCP, тем же самым, где будет наглядное графическое представление. Здесь можно в принципе посмотреть статистику какую-то — да, он скажет, но она тоже непонятная, потому что сигнатуры просто по ID, и мы не знаем, что это за сигнатуры, что

они делают. Сколько раз там срабатывалась, сколько раз alarm посылались — статистика очень такая, простым взглядом её не посмотреть. Сейчас это какие у нас на самом деле engine и enabled — какие возможны... Короче, ладно, мы сейчас с одной сигнатурой работаем. Вот мы её взяли, потому что такая тестовая сигнатура — её во всех курсах и во всех учебных пособиях обычно рассматривают, потому что очень наглядно получается. Сейчас мы видим, что сигнатура наша на самом деле выключена, она даже не скомпилирована. Нам её нужно включить, она автоматически скомпилируется и начнёт работать. И просто посмотрим — работает, не работает, что вообще происходит при этом. Как всё это делается: опять же ip ips signature definition.

Здесь мы будем указывать, что сигнатура у нас 2004, status, и изменяем статус этой сигнатуры на enabled true и retired false. Сейчас она у нас уже enabled и unretired — она скомпилируется и загрузится в память IPS. Выходим из всего этого безобразия, из всех этих контекстов. Нас предупреждают, что нужно применить изменения, мы говорим «да», применяем изменения. Сейчас syslog в принципе должен сказать нам — он сейчас подвиснет немножечко — syslog нам скажет, что сигнатура у нас скомпилировалась. Он будет не весь набор перекомпилировать, а только нужную сигнатуру, поэтому в принципе включать можно безболезненно. Нет, я вам соврал. Смотрите, там ещё есть прикол в IPS: он будет компилировать не по одной сигнатуре,

а по-моему кусками. Для каждого движка, если какую-то сигнатуру включать — atomic IP — он, по-моему, пачку сигнатур берёт и перекомпилирует. И в этот момент IPS эти сигнатуры не берёт в расчёт, они не работают. Это важный момент, я правильно сейчас вспомнил: если вы вдруг на рабочем IPS будете играть с сигнатурами, включать-выключать, то в момент перекомпиляции — а сигнатур может быть очень много — вот в этом наборе ios-ips basic там мало сигнатур, они достаточно быстро перекомпилируются. Но если будет какой-то большой набор сигнатур, и одну сигнатуру включите — он будет перекомпилировать для вот этого движка, для atomic IP, всю пачку. И в этот момент у вас трафик не будет по ним проверяться, то есть в этот момент может проскочить что-то нехорошее через IPS.

Имейте это в виду. Ну да, оставайтесь на ночь и играйтесь, ничего. Теперь смотрим — работает всё это или не работает. Делаем простой ping и смотрим, что нам говорит IPS. IPS увидел ICMP-пакет, он сработал. Сработал он очень простым образом: он просто сказал, что послал alert, просто послал сообщение в syslog. Сказал, какой номер сигнатуры у нас, ID, какой sub-ID — то есть что сработало вообще. Severity — это важность сигнатуры, помните, я вам говорил про то, что каждая сигнатура имеет severity (не syslog severity, а сама важность сигнатуры). Severity, по-моему если я не ошибаюсь, считается от единицы до

100. По-моему так. И какие-то сработки они могут быть более важными, чем другие. Пинг имеет достаточно низкий severity — всего 25. Я боюсь соврать, но по-моему от единицы до 100, хотя если уточнить — может быть до 255, может быть и так. Но предположим, пусть это будет до 100, правда не помню, мне не стыдно, что я это не помню. И собственно он сказал, что произошло: у нас был отправлен ICMP echo request с такого-то адреса на такой-то адрес. Плюс ещё risk rating — опять же каждая сигнатура она кроме важности будет иметь ещё такой risk rating. Он считается точно от 0 до 100, это я помню. А важность сигнатуры

правда не помню. Risk rating он подсчитывается для того, чтобы не указывать сенсору реакцию для каждой сигнатуры. Вместо этого можно просто настроить реакцию на risk rating. Не обязательно сенсор должен прям на всё ругаться — можно просто по рейтингу: если у нас risk rating какой-нибудь 50, то мы можем сенсору сказать, что вообще не надо реагировать на рейтинг ниже 50. Если risk rating будет какой-то более высокий, там уже нужно как-то реагировать. Вот такая штука. Этот роутерный IPS, как видите, он работает. Я не вижу причин, чтобы он не работал и не заработал. Просто немножечко неудобно с ним работать, вот как мы привыкли в консоли. Давайте с IPsec

смотреть. IKE версии 2 — в принципе настройка будет похожа. Сначала нам нужно настроить параметры самого протокола IKE, а потом параметры самого протокола IPsec. В каком-то месте мы должны параметры связать воедино и применить на интерфейсе. Интерфейс у нас будет в этот раз туннельный, чтобы красиво всё было, и через этот интерфейс уже делать какую-то маршрутизацию. Давайте начнём. С чего начнём? Начинаем как всегда с первой фазы. Здесь она будет не первая фаза, но настройки самого IKE. Поехали, командочки будут немножко отличаться, но там ничего сложного. Всё те же crypto — мы настраивали раньше crypto isakmp. ISAKMP — это относится к первой версии IKE. Мы будем настраивать crypto IKE версии 2, и сначала настроим именно его

параметры. Они будут называться словом proposal. Proposal — здесь все объекты именованные, поэтому нужно везде придумывать имя. Не знаю даже, как будем называть — пусть будет ikev2-prob. Здесь нам сразу подсказывает оболочка, что нужно как минимум алгоритм шифрования задать: алгоритм шифрования, алгоритм целостности, Diffie-Hellman — те же самые параметры HAGLE, которые мы с вами уже запомнили. Они все здесь будут настраиваться. Давайте encryption поставим самый простой DES, ничего страшного. Hash — hash в первой версии настраивался словом hash, здесь это будет параметр integrity — целостность, в принципе говорит само за себя. MD5 возьмём. Группа Diffie-Hellman — давайте первую, просто минималку такую сделаем, нам большего и не

требуется. Это первые параметры, которые мы здесь указали в настройке IKE версии 2. Тут можно немножечко более гибко настраивать. Если мы настраивали первую версию — помните, параметры ISAKMP? Они просто были: policy 10, 20, 30, и наборы определяли этих параметров, а потом роутер их перебирал, отправлял первый набор, второй набор, третий. А другой роутер с другой стороны их сравнивал до первого совпадения — совпало, всё нормально. Здесь можно немножечко более гибко это сделать: можно в принципе для каждого пира уже указать вот эти наборы. Мы сейчас

Сделаем один набор на всех, но просто имейте в виду, что здесь погибче и роутер не нужно будет перебирать. Для пира все наборы подряд этих параметров он посмотрит. Если у него указано, что для этого пира использовать этот proposal, он будет использовать его. Следующее — мы настраиваем второй объект, он называется IKE policy. Это схоже с тем, что мы настраивали в ISAKMP policy, просто разнесено в два объекта. Ещё раз напоминаю: ISAKMP policy мы настраивали просто одной простынёй, и номер этих наборчиков — policy 10, policy 20, policy 30 — потом их перебирали. Здесь мы отдельно настраиваем эти наборчики — proposal (да, такое слово дурацкое, не знаю как переводить правильно; можно «предложение»), они именованные. А потом настраиваем отдельно policy, то есть политику, в которой будем говорить, что для какого пира использовать.

Но у нас политика будет одна. Она настраивается таким образом: crypto ikev2 policy, назовём мы её как-нибудь простым способом. Я всё буду однотипно пытаться называть. Policy нам подсказывает, что как минимум один proposal нужно в него включить. Здесь можно указать match peer, то есть для конкретного какого-то адреса. Не будем сейчас, я общее сделаю. Proposal — v2-prob. Этого достаточно. Теперь, когда у нас будет отрабатывать протокол версии 2, роутер будет смотреть: в policy, в этих правилах, у нас написано, что всем отправлять предложение — вот этот proposal, набор параметров, которые мы определили до этого.

Дальше — это второй объект, который нужно настроить. Вспоминайте, что ещё нужно нам для работы IKE первой версии и второй версии. Нужна такая штука, как аутентификация. Аутентификация будет здесь сделана опять же по-другому. Помните, про связки ключей мы с вами разговаривали? У нас есть связка ключей, в которую мы добавляем ключи, и потом протоколы с этими ключами работают. Здесь похожая вещь. Она тоже называется keyring, в которой мы можем для каждого пира определить pre-shared key конкретный. Давайте настраивать. Keyring настраивается: crypto ikev2 keyring, назовём его... я назову его вот так. А дальше здесь параметры — мы говорим, для какого пира. Здесь пиры тоже будут все именованы.

Я, по-моему, правильно помню, что можно сделать — это будет для всех. Я попробую сделать. А вы здесь напишите peer — там router1 или как-то по-своему. Я для всех же настраиваю, мне надо будет ещё туннельный интерфейс на каждого из вас поднять. Keyring — это как keychain для протокола IKE версии 2, просто хранилище ключей. Там keychain, а здесь keyring. Но в принципе то же самое. В названии — как хотите, так и называйте. Теперь дальше, у этого пира есть адрес или hostname, можно использовать. Давайте писать адрес. Я надеюсь, что я могу все нули написать, и это будет общий для всех. В ISAKMP первой версии так работало, я думаю, что здесь такая же логика.

Я, честно признаюсь, такой общий pre-shared key в своей практике что-то не настраивал, не было у меня такой потребности. Мой IP-адрес, судя по нашей схеме, 10.10.1... То есть вы пишете peer R1, и адрес у вас будет 10.10.1. Дальше, здесь нам нужно указать pre-shared key. Смотрите, можно указать local и remote — два разных ключа. Но остановимся на одном, просто pre-shared key cisco. У нас общий ключ, для всего хватит. Теперь — здесь чуть-чуть больше надо настраивать, но этого хватает. Аутентификацию мы сделали, я думаю, что она сработает. Если не сработает у меня, я для каждого пира пропишу всё что нужно. Pre-shared key cisco.

Теперь надо связать эти сущности в какой-то понятный профиль — профиль именно IKE версии 2. Как настраивается этот профиль? Здесь будет у нас команда: crypto ikev2 profile, и назову его ikev2-profile. Здесь мы должны указать метод аутентификации — и наш, и тот, который на той стороне. Можно сделать такую схему, когда с одной стороны будет один метод аутентификации, а с другой — другой. Это может быть немножечко запутано, но где-то в каких-то условиях оправдано. Например, с другой стороны железо не умеет определённый метод аутентификации — можно так сказать и задать.

Для начала match identity — это для кого мы будем использовать. Remote identity — здесь вы будете писать мой адрес 10.10.1.1, а я напишу any, то есть для всех этот профиль будет работать у меня. Дальше, что ещё здесь нужно указать. Нужно указать тип аутентификации, который будет использоваться. Локальный у нас — pre-shared, authentication с той стороны тоже у нас работает pre-shared key. И указать, откуда брать эти pre-shared ключи. Мы с вами уже keyring создали, и сказать, что keyring наш локальный будет у нас называться, как я назвал. Я не знаю, как вы называли.

Всё, наш профиль создан. IKE версии 2 profile — он объединяет все объекты, которые мы описали до этого. Теперь с профилем всё ясно, с первой фазой более-менее разобрались. Сейчас ещё раз покажу. Do show crypto ikev2 profile... сейчас я кусок show run своего покажу. Вот, смотрите, создали профиль. Здесь будет у вас match identity — у меня remote any, а у вас будет мой адрес. Match identity remote address — и пишите мой IP 10.10.1.1.

Успеваете за мной? Дальше — настройку IKE версии 2 мы с вами и закончили. Кто интересовался настройкой прямо IKE версии 1 — больше здесь ничего нет. Так, Кирилл, вы забыли указать — сейчас — remote authentication. Надо local pre-shared и authentication remote тоже pre-shared. Вот, смотрите, у меня в профиле IKE надо указать и локальный способ аутентификации, и на той стороне. Дальше, Михаил правильно подсказывает. Настройка протокола IKE версии 2 на этом закончена. Теперь будем приступать ко второй фазе, которую в терминологии версии 2 будут называть child SA, — короче, вторая фаза, IPsec, наше боевое шифрование назовём. Я не очень люблю слово «боевой», но оно очень ёмкое и точное.

Окей. Помните, для того чтобы настроить сам IPsec, нам нужно, во-первых, указать все его параметры — создать так называемый transform set, где сказать, какое мы будем шифрование использовать, какую будем использовать аутентификацию, какие будут хэши. Здесь уже команды всё те же самые, потому что к IKE версии 2 никакого отношения не имеют. Мы говорим: crypto ipsec transform-set, назовём его TS-1 пусть будет у меня, и говорим, какое шифрование мы будем использовать. Мы будем использовать протокол ESP, шифрование у нас будет самое простое — давайте DES возьмём, и подпись у нас будет с помощью хэша MD5. Mode transport поставим — транспортный режим. Почему? Потому что у нас же будет туннельный интерфейс, туннельный интерфейс будет свои заголовки добавлять, здесь не надо ещё во что-то дополнительно запаковывать.

Mode tunnel оправдан, когда мы просто пакет зашифровали и куда-то хотим передать через интернет, чтобы он нормально там маршрутизировался, — мы к нему ещё IP-заголовок добавляем. Здесь у нас будет туннельный интерфейс, который всю эту работу будет делать сам. Transform set создали, то есть IPsec теперь знает, что делать. И последняя очень важная сущность — это нужно связать работу IPsec и работу протокола IKE версии 2. Когда мы работали с crypto map, у нас была crypto map, которая этим и занималась. Здесь мы тоже можем использовать crypto map, нам никто не запрещает. В crypto map будем указывать, какой transform set использовать, и так далее. Но так как мы работаем с виртуальным туннельным интерфейсом, здесь будет другая сущность — она будет называться IPsec profile.

А потом уже на интерфейсе будем говорить, что защищаемся с помощью вот этого IPsec profile. IPsec profile — это не означает, что он будет описывать правила только для IPsec, но и для IKE версии 2, вся подсистема в нём будет настраиваться. Создаём этот IPsec profile. Команда у нас будет: crypto ipsec profile, назовём его понятным языком — ipsec-prof. И дальше здесь у нас есть некоторое количество параметров, где нужно сказать, что же делать. Мы сейчас на интерфейс повесим это — что делать на интерфейсе? У нас есть две сущности: IKE версии 2, у него уже создан профиль, и есть transform set, где сказано, что делать с IPsec. Мы скажем, что transform set мы будем использовать TS-1, который мы только что создали, и профиль протокола IKE — ikev2-profile. Я, конечно, забыл, как я уже здесь назвал. Он должен называться ikev2-profile.

Настройка почти закончена. Мы описали всё, что нам нужно сделать для того, чтобы трафик на нашем туннельном интерфейсе начал шифроваться, чтобы у нас отработал протокол IKE версии 2, чтобы шифрование у нас заработало. Посмотреть всё это дело теперь можно командами. Сразу show crypto ipsec profile — у нас есть профиль дефолтный, который тоже может по сути использоваться, но зачем нам он, мы и свой кастомный сделали. Где написано, какой IKE версии 2 профиль использовать, в котором, в свою очередь, описана работа протокола IKE версии 2. Какой transform set использовать, как у нас шифрованием заниматься.

Нужно ли включать Perfect Forward Secrecy — помните, я говорил, что это такое? Это когда роутеры по-честному будут перегенерировать свой ключ, запускать Diffie-Hellman и запускать генерацию ключей. Но в лабораторных условиях не обязательно, хотя эту штуку включать полезно. Давайте теперь с туннельным интерфейсом разберёмся. Я думаю, что все меня пингуют, я тоже вас пингую. У нас IP-связность есть, надеюсь. Так, давайте я сейчас запишу, какие у нас есть. Перекличка: 2, 3 — у нас нет, 4, 5 — нет, 5, 6 есть, 8, 9, 10. Семь — нет. У нас комплектов маловато, народу вроде бы восемь человек. Кто ещё не сказал мне свой номер? 2, 4, 5, 6, 8, 9, 10 — участников восемь.

Я просто хочу... так, 3 — нет, 4, 5 работает, 4 работает, 6, есть, 7 — сейчас ARP отработает у нас, чтобы всё быстро пинговалось. 8, 9, 10. 2, 4, 5, 6, 8, 9, 10. Ладно, может быть, кто-то отошёл и не с нами. Восемь участников, наблюдателей можно отключить. Романа нет, я так подозреваю. Роман — четвёртый. Кирилл, Олега нет третьего. Михаил, Юрий... ладно, короче, давайте не тратить время, я всех настрою.

Что нам осталось сделать? Осталось создать туннельный интерфейс. Я этих туннельных интерфейсов создам дофига, а вы создадите один единственный. Вы создаёте interface tunnel с любым номером, здесь не важен номер. Андрей, про mGRE попозже поговорим. Давайте сейчас сначала просто классические IPsec-туннели понастраиваем. Окей, что нам в туннеле нужно указывать? Андрей у нас на поезд торопится — всё, Андрей, беги на поезд, завтра в Москве увидимся. Скажу про multipoint GRE: можно использовать вместо обычных туннелей, но это уже будет DMVPN, там уже и multipoint GRE сам по себе не заработает — там надо ещё кое-что настроить, и NHRP.

Окей, Андрей отваливает, а мы дальше продолжим. Счастливого пути, хорошей дороги. Так, что нужно на туннельном интерфейсе? Во-первых, IP-адрес. Давайте возьмём такую адресацию, которой у нас нет в лабе: 172.16... У меня — .1.1, а у вас будет .1.2, .1.3 — номер комплекта. Кроме IP-адреса, в туннеле обязательно нужно указать source и destination. Мы говорим tunnel source — возьмём просто наш интерфейс GigabitEthernet 0/1. А tunnel destination — у вас будет мой IP-адрес, а я на вас буду ставить 10.100.1.2. В этом случае будет у меня... Запись идёт, конечно. Андрей никак не уйдёт, волнуется, вдруг не попадёт на запись.

Теперь надо обязательно указать тип интерфейса, потому что по умолчанию — кто помнит, какой тип будет на туннельном интерфейсе включаться, какая инкапсуляция? Кто-нибудь помнит? Давно прошли, кто не помнит — ладно. По умолчанию будет всегда инкапсуляция GRE включаться. Если посмотреть show interface tunnel 0 (у меня tunnel 2 создан), то здесь будет видно, что tunnel protocol у нас — GRE. GRE-шный туннель нам не нужен сейчас, у нас уже IPsec-туннель. Мы говорим: tunnel mode ipsec ipv4. Всё, более-менее туннель настроен, он у нас уже появился. Если посмотреть список интерфейсов — протокол пока down, он ещё не включился. Почему? Потому что тип мы указали IPsec, но сам IPsec ещё не настроили.

И последняя команда, которая будет применять наш ранее созданный профиль IPsec (в котором уже всё собрано вместе) к туннельному интерфейсу, будет называться tunnel protection. Tunnel protection у нас будет ipsec profile, и профиль у нас будет — как же я назвал — ipsec-prof. Tunnel protection ipsec profile ipsec-prof. Теперь дайте мне одну минуточку, я скопирую для всех эту настройку. Давайте смотреть, что же получилось у меня. Туннельный интерфейс сросся со вторым пиром и с восьмым пиром. Маршруты — подождите, сначала. Не обязательно здесь маршруты. Когда у нас включается туннельный интерфейс, он будет посылать уже пакеты — keepalive или DPD он будет посылать, IKE уже будет срастаться сразу.

В случае route map нужно какой-то трафик пустить, а здесь он должен срастаться. Маршруты сейчас попозже посмотрим. Судя по тому, как тормозит у меня роутер, у нас что-то ещё срастается. Loopback потом увидим. Сейчас я хочу посмотреть show crypto ikev2 sa. Вот, смотрите, помните, я раньше показывал команду show crypto isakmp sa? SA — это массив данных, в котором содержится уже информация о сессии. Вот сессия протокола IKE — так называемый наш служебный туннельчик — он будет описан здесь. Мы видим, что с remote peer .1.2 по порту UDP 500 у нас всё срослось, статус у нас ready. Мы согласовали с ним параметры: encryption у нас для этого служебного туннельчика — DES, hash у нас MD5, группа Diffie-Hellman — 1, аутентификация у нас pre-shared, lifetime у нас...

Все параметры как раз мы здесь видим. Остальных я пока не вижу, если честно. Давайте поставлю на паузу, попробуем потраблшутить. Давайте вот про это ещё раз проговорим. В профиле IKEv2 мы должны будем указать, для какого пира какая аутентификация у нас используется. Match identity remote — у вас будет адрес 10.10.1, и локальная аутентификация, remote — pre-shared, и какой keyring использовать. Keyring мы определили до этого. Вот у кого не срастается аутентификация — в этих двух кусках конфига можно всё найти. Так, у нас пока ещё продолжается какой-то траблшутинг, кто-то ещё не смог. Давайте расскажу про маршрутизацию — собственно, ради чего всё это затевается.

На кой нужно поднимать интерфейс, когда можно обойтись route map? Мы уже говорили, что через интерфейс может работать нормальная человеческая маршрутизация. Почему бы нам не поднять EIGRP? А почему бы не поднять OSPF — даже прикольнее будет. Мы сейчас на этих туннельных интерфейсах включим с вами OSPF и обменяемся нашими loopback. Вот этим туннельные интерфейсы и хороши — не нужно там никаких сложных схем придумывать, раз включили — и всё должно заработать. Значит, включать будем OSPF просто на интерфейсах, никаких router ospf. Будем по-пацански, по-нормальному. Сначала на loopback — все в одном регионе, это нормально. На loopback скажем: ip ospf <номер процесса любой> area 0. Не надо включать OSPF везде, я объясню, почему — только на нужных интерфейсах.

Очень распространённая ошибка, в которую вляпываются все. Чаще это с EIGRP случается, потому что EIGRP можно включить тупо вообще везде — он везде включится. Распространённая ошибка — когда включается протокол динамической маршрутизации (например, EIGRP или OSPF) на туннельном интерфейсе и на физическом интерфейсе, который будет в ту же... представляете, который будет как source для туннельного интерфейса работать. Вот если мы сейчас включим OSPF на туннельном интерфейсе и на интерфейсе GigabitEthernet 0/1 — мы же там в одной сети, OSPF там тоже срастётся — мы с вами получим петлю маршрутизации. Сейчас долго не будем разрисовывать, просто представьте, что у вас будут доступны одни и те же сети сразу через два интерфейса — там будет совсем некрасиво.

Поэтому помните о том, что если есть такая штука, как туннельные интерфейсы, то на туннельном интерфейсе нужно включать соседство, а тех же самых соседей не нужно видеть по простым интерфейсам. EIGRP там будет прям ругаться и выключать. Я могу даже сказать, что, по-моему, интерфейс будет гасить туннельный. Вот кто сейчас на CCNP учится — у вас DMVPN, наверное. Накидывали вам, показывали такой прикол, по-моему. EIGRP даже интерфейс выключит туннельный, и это нормально — он говорит: «Тут петля» — и всё, до свидания. Окей, на loopback включили. Интерфейс tunnel — мне сейчас нужно будет для всех включить. Вот, кто-то там доделал, прекрасно — это у нас Александр подтянулся. Так, interface tunnel 2 — я скажу то же самое. Потом 4, 5 — на пятом я включил, на шестом включил, на восьмом включил, на девятом включил, и на десятом тоже включил.

Do show ip ospf interface brief — у меня на втором, четвёртом, пятом, шестом, восьмом, девятом, десятом. 2, 4, 5, 6, 8, 9, 10 — да. Я ещё хочу настроить на самом деле... ещё секундочку. Но давайте смотреть, что у нас получается. Маршрутизация — show ip ospf neighbors — соседи наши: пятый вижу, поднялся, и второй поднялся. Так, Михаил, наверно, пошёл на перекур. Так, дальше. Если посмотреть таблицу маршрутизации OSPF, то смотрите, какая вещь прекрасная произошла. Девятый подтянулся — я вижу ваши loopback за вашим туннельным интерфейсом. То есть если я посмотрю show ip route 2.2.2.2 — развёрнутая маршрутная информация — нам скажут, что за tunnel 0 через 172.16.2.1 этот маршрут будет доступен. Дистанция — 110, метрика у него 1001.

Метрика, конечно, здесь такая большая — на туннельных интерфейсах на разных платформах будет разная метрика по умолчанию. Кстати, пингуется всё от меня прекрасно. И если посмотреть теперь маршрут до loopback .2.2, то мы увидим, что маршрут будет идти через туннельный интерфейс и не через какой-то другой. Никаких больше адресов не будет, никаких там 10.100 — всё, туннельные интерфейсы работают. Более того, если посмотреть show crypto ipsec sa, то можно увидеть, что на tunnel 2, на интерфейсе tunnel 2, у нас пакетики прекрасно шифруются и прекрасно расшифровываются. IPsec работает.

Так как у нас tunnel mode ipsec, то пока IPsec не срастётся, пока IKE версии 2 не отработает, туннельный интерфейс не поднимется, и ничего там тоже не заработает. Имейте в виду. В данном случае всё прекрасно срослось — пакетики бегают, и маршрутизация у нас работает очень здорово. Я ещё раз на паузу поставлю, давайте доделаем всё это. Кто уже устал — может, конечно, забить на это дело. Так, значит, на этом мы заканчиваем наш курс. Сейчас мы покажем какую-нибудь красивую картинку, финальную. С котиками — ни одной картинки с котиками здесь. Здесь немножко по-другому. Нет, давайте — пусть будет. Иннокентий, котики есть у меня. К сожалению, котов нет дома, и мне показывать нечего. В качестве финальной картинки пусть будет вот такая картинка, чтобы она вам напоминала всё-таки, с чем мы с вами научились работать.

Что сказать про прошедший курс? Мне курс очень понравился. Мне очень понравилось работать с вашей группой. Группа у нас подобралась классная, и не часто такое бывает, когда все приходят подготовленные, у всех всё нормально, у всех за плечами CCNA, у кого-то CCNP, кто-то сейчас учится на CCNP. Короче, мне очень повезло с вашей группой — это большая удача для тренера, когда собираются нормальные ребята в группе. Я могу столько рассказать историй прошедших курсов, когда иногда курс, конечно, бывает затянутый, иногда приходится какие-то скучные вещи объяснять, протяжённые access-листы. А с вами нам есть о чём поговорить, и всё очень-очень интересно. Так что я хочу вас поблагодарить — вы очень классная группа, и мне с вами было очень приятно работать на этом курсе.

Мне кажется, что мы достаточно материала разобрали, даже для уровня CCNA Security. Если сейчас так оглянуться назад, начиная с первых двух дней, когда мы разложили по полочкам (я надеюсь, у кого-то разложилось по полочкам) все основные понятия безопасности, которые обычно вообще кашу из себя представляют. Вот это, наверное, одна из самых важных частей курса была — не техническая безопасность, которая потом все дни была, а первые два дня. Так что теперь, если у вас спросят что-то про безопасность, вы сможете дать совершенно чёткие конкретные ответы. Зачастую люди, даже которые занимаются безопасностью по своему долгу, не могут объяснить ни одного понятия. И вот эта часть курса была самая важная для тех, кто никогда не задумывался, как всё это классифицировать в своей голове.

Потому что обычно спрашиваешь рядового системного администратора, что у него сделано в плане безопасности, и человек не может объяснить, что у него сделано в плане безопасности. Мы здесь, по-моему, поговорили об огромном количестве вещей — начиная от оценки рисков и заканчивая тем, что нужно принтерам тоже иногда обновлять прошивки и программное обеспечение. Очень классная тема, она очень-очень широкая. Здесь, я думаю, пересмотрите потом ещё раз запись. Я, может быть, где-то запинался, не с первого раза мог какую-то вещь правильно объяснить, иногда забывал какие-то вещи — я тоже человек, это всё забываю. Но я думаю, что я донёс до вас все свои мысли и всё содержимое курса верно. Если вдруг вы обнаружите какие-то неточности, не стесняйтесь — пишите мне в наш Telegram-чат, я всегда всем с радостью отвечаю. Это будет важно и для меня в первую очередь: если я что-то сам неправильно для себя уяснил, я это поправлю, и для будущих слушателей — может быть, что-то исправим в слайдах. Это будет полезно для всех. Ну и для вас — что вы сами уже разобрались и меня поправили, тоже здорово.

Я прошу тех, кто, может быть, расстроен, что мы мало материала охватили, — не расстраивайтесь. Материала было дофига, просто невозможно на одном двухнедельном курсе (там 9 дней) охватить нормальную глубину материала. Что-то мы разобрали очень поверхностно, но, по крайней мере, вы точно теперь знаете, что такие вещи есть в природе и зачем они есть. Главное — понять зачем и как они работают, а как настраиваются — это уже дело десятое. Можно вообще весь этот курс прочитать без единой настройки на оборудовании, и он тоже будет интересным, тоже будет классным. Настройку на оборудовании всегда можно посмотреть в официальной документации на сайте Cisco, Juniper, Huawei, любого другого вендора. Так что это не самое важное, что было в курсе. Главное — концепции, которые мы с вами рассмотрели. Может быть, какие-то вам больше понравились, какие-то меньше. Если остались пробелы в голове — ничего страшного, вы знаете теперь, в какую сторону копать, какой материал и по какой теме читать.

Если вы что-то недопоняли там, защита, 802.1X — вы знаете уже, что гуглить. Как минимум вы знаете, что спросить у Google, какую документацию начать искать. Так что я надеюсь, что у вас всё в голове правильно теперь. По поводу дальнейших курсов: я уже сказал, что CCNP Security мы пока не планируем. Я не думаю, что до следующего лета что-то сдвинется с этой мёртвой точки — просто некому читать, и слушателей мало, и одни проблемы. Проблема ещё в том, чтобы подготовить эти курсы. В этом курсе содержится более 400 слайдов, я уже говорил. Даже нарисовать слайды — это уже занимает огромное количество времени, чтобы это пропустить всё через себя, ещё раз повторить, ещё раз раскурить все эти темы и нарисовать слайды.

Пока у нас нет такого человека, который взялся бы за CCNP Security. Я думаю, что в других учебных центрах, может быть, что-то есть интересное. Не пытайтесь попасть именно на цисковский CCNP Security. Я, может быть, скажу сейчас не очень хорошую вещь, но цисковский CCNP Security во многих местах очень заточен под одного вендора. Но это нормально — это курс Cisco, она его придумала, этот трек, и сама пишет эти курсы под себя. Я не говорю, что он бесполезен, этот трек — он очень полезный и классный. Но там много вещей на Cisco ориентировано. Например, там целый курс SESA — он очень сильно ориентирован на работу с Cisco ISE. Если вы в своей работе с Cisco ISE не работаете и вряд ли когда-то собираетесь работать, то этот курс будет полезен — да, там про 802.1X много говорится. Но именно закладываться, чтобы я точно должен пройти этот курс, потратить деньги и сдать экзамен — не знаю, нужно ли это или нет.

Может быть, стоит просто почитать литературу отдельно. У той же Cisco есть классная литература отдельно по этим темам. По тому же IPsec, по IKE версии 2 у них есть прям отдельные книги. Можно читать отдельные книги по технологиям, не обязательно это в виде курса пытаться найти. Так что не стремитесь прям во что бы то ни стало пойти на курс, а то вы без него умрёте и ничего не будете знать. Тем, кто будет сдавать экзамены, наверное, пару слов скажу. Во-первых, я хочу пожелать вам удачи, потому что она вам точно пригодится на экзамене. Я не скрываю того, что этот курс не покрывает сто процентов материала экзамена. Материал экзамена очень-очень глубокий, и официальный курс Cisco IINS тоже не покрывает весь материал экзамена. И наш курс, хотя мы его попытались расширить и углубить по сравнению с официальным, — всё равно все темы экзамена здесь охватить не получается.

Есть официальное руководство по подготовке к экзамену — читайте его. Если вы сейчас откроете, как и сказал Кирилл, эту книжку, чтобы всё по упорядочить, если сейчас откроете официальное руководство по подготовке к экзамену, то оно будет читаться легко и приятно для вас. Вы уже будете знать больше половины того, что в этом руководстве, уже будете понимать, о чём идёт речь, и в этой книге вам будет легко ориентироваться, легко будет материал восприниматься. Так что даже кто не будет сдавать экзамен — если есть свободное время, чтобы проштудировать эту книжку, берите учебник и читайте. Можете через страницу, можете какие-то наиболее интересные моменты читать внимательно. Лишним не будет — это прикольно, и там тоже есть чему поучиться. Вот такие дела. По поводу ваших дальнейших курсов — думайте сами. Я думаю, что кому понравилось — придёт и на CCNP, если кто-то не был. У нас я не знаю, буду ли я читать CCNP в нашей академии, но буду, наверное, просто пока для меня ещё не набирается группа.

К тому же я ещё к своему экзамену готовлюсь — мне очень надо сейчас начинать готовиться очень усиленно. Всё, давайте тогда запись останавливать. Мы можем ещё болтать сколько угодно, если у вас есть какие-то вопросы, накопились, или просто что-то сказать интересное. Запись мы на этом останавливаем. С теми, кто будет смотреть запись, я прощаюсь. Ещё раз говорю всем спасибо.