Защита IOS: Secure Boot Set, мониторинг и SNMPv3

Мы продолжаем, сегодня у нас 5 октября, 4 день нашего курса Cisco IINS 3.0. Сейчас мы с вами разбираемся с защитой самих сетевых устройств, защитой наших железок, и будем продолжать. Вчера разобрали всё что касается административного доступа, аутентификации, авторизации, RADIUS нам понравился, я думаю вам понравился, и будем сейчас говорить дальше про сами устройства. Сейчас я бы хотел поговорить с вами немножечко про файловые системы, про конфигурацию. Я думаю что здесь мы будем повторять в какой-то мере материал CCNA, поэтому на некоторых моментах я не буду заострять внимание — вы это всё

и так знаете, и любой человек который будет потом записи эти смотреть, я думаю что он тоже будет это знать, потому что CCNA всё-таки здесь необходим. Давайте немножечко поговорим про файловые системы в Cisco IOS. Вы наверное знаете что в Cisco IOS есть большое количество файловых систем — это не одна файловая система как в какой-нибудь операционной системе Linux, и не 5 или 10, немножко побольше. Дело в том что кроме физических файловых систем здесь есть ещё и виртуальные файловые системы, с которыми можно работать почти так же как и с физическими. Скажу что в Cisco IOS не слишком хорошо развиты инструменты для работы с файловой системой, но всё-таки это сетевые устройства, и работа с файловой системой здесь не стоит на первом месте. Скопировать файл, удалить файл — здесь

это всё есть, а большего нам и не надо. Посмотреть содержимое файла — такие простейшие операции. Файловые системы нам нужны, смотрите: для указания файловой системы, когда мы как-то работаем с ней, например копируем файлы, используется префиксная система. Мы указываем специальный префикс и дальше путь. Этот префикс будет обозначать, что за файловая система, что мы хотим делать. Смотрите, физических файловых систем есть основные две, плюс ещё какие-то диски. Есть flash, про который вы все обязаны знать. Есть NVRAM, про который вы тоже знаете. Если вспомнить материал CCNA, то обычно говорится что NVRAM — это отдельное физическое устройство. Cisco когда-то так и говорила, что NVRAM — совсем

отдельное физическое устройство. На самом деле в настоящее время зачастую на многих устройствах NVRAM — это просто кусочек, раздел на флеш-памяти, он особо ничем и не отличается. Раньше когда-то NVRAM было реализовано в качестве отдельной микросхемы, они были быстрые, но очень дорогие. Flash всегда была дешёвой памятью, а NVRAM — дорогой памятью, поэтому отсюда и пошло сжатие конфигурации, startup config его же можно сжимать, я думаю вам на CCNA рассказывали. Вот из тех давних времён. Сейчас NVRAM достаточно большие объёмы представляет из себя, и все эти ужасы ушли в прошлое. Кроме того, файловые системы которые на каких-то внешних дисках, будут так

обозначаться: disk и плюс какое-то число, disk1, disk2. Вообще обычно с нуля начинается. То же самое на многих системах вы можете встретить несколько flash, и они тоже будут flash0, flash1 и так далее. Что касается виртуальных файловых систем, их на самом деле достаточно много, мы сейчас посмотрим с вами, но основная — это system. System — это такая самая главная виртуальная файловая система, она просто содержит указатель на какие-то области памяти, это виртуальная файловая система, и содержит running config. Если быть точным, то running config, я думаю что вам тоже на CCNA это говорили, это не файл. Вообще никакой — на курсах Cisco, в официальных руководствах говорится что running config — это файл,

который хранится в оперативке. Можно встретить в некоторых источниках такое утверждение. На самом деле это никакой не файл и ни в какой оперативке он не хранится. Всё правильно, эта сущность — это просто моментальный снимок состояния программных компонентов операционной системы. Вы попросили running config — вам операционная система опросила все свои модули, все свои программные компоненты и сказала, где у нас что хранится. Глеб Вадимович очень правильно уточняет — там даже пишется building. Но в то же время эта сущность позволяет работать с ней как с обычным файлом. Это я считаю невероятно удобная штука, которую придумали инженеры компании Cisco. Мы можем как обычный файл её копировать, например — это невероятно удобно. Также у нас есть TFTP, FTP, HTTP, HTTPS, SCP. Я думаю

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

использования файловых систем: посмотреть файловые системы можно простой командой show file systems. Я не думаю что нам сейчас надо лабораторную работу на это делать, на IINS это тем более все уже знаете. Резервное копирование на удалённый сервер осуществляется обычной командой copy — либо из running config, либо startup config мы можем скопировать практически куда угодно, посмотрев файловые системы которые поддерживает наше устройство, можно их использовать практически без ограничений для того же самого резервного копирования конфигов. Восстановление начальной конфигурации — это откуда-нибудь скопировать startup config. Я думаю полезно будет здесь точно вам сказать про одну командочку — сейчас нарисую. Это configure replace — восстановление

текущей конфигурации: откуда-нибудь мы берём файл, не обязательно с удалённого сервера. В данном примере у нас по SSH копируется с какого-то удалённого сервера файл, можно с локальной flash, и сразу же записываем это в running config. Оправдано это или нет — копировать что-либо в running config штука опасная, я думаю что вы это всё знаете. С другой стороны бывают такие ситуации, может быть вы мне даже в чате напишете, когда без этого просто не обойтись. Смотрите, дело в том что эта команда, вообще даже если сделать copy startup config в running config, он мерджит — будет merge, просто слияние. То что было, никуда не денется, но что-то

новое добавится. Вот эту операцию очень важно понимать, поэтому все эти игры «я сейчас восстановлю из стартапа быстро текущую конфигурацию» иногда доводят до плохого результата. Лучше делать всё руками. С другой стороны бывают ситуации, я не знаю, наверное на CCNA все видели такой пример, когда без этого не обойтись. Роман правильно сказал, если ещё там листы писать, он покажет что восстановил, покажет результат мерджа. Бывают ситуации когда нам нужно применить, например, какие-то две новые команды — перенастроить интерфейс и сразу маршрут по умолчанию. Если на удалённом устройстве делать эти две операции руками, это

сделать нельзя: поменяешь IP-адрес на интерфейсе — потеряешь доступ к железке, поменяешь сначала маршрут по умолчанию — тоже потеряешь доступ к железке. В таких ситуациях, когда нужно сразу несколько мест конфига поправить безболезненно, чтобы не перезагружать железку — а как перезагружать мы тоже уже поговорили в критических ситуациях — чтобы не перезагружать и чтобы сделать это корректно, можно в принципе воспользоваться configure replace. Дальше, как посмотреть MD5-хеш. Мы с вами про хеши разговаривали во второй день, мы знаем что это классная штука, и при скачивании с сайта Cisco, например, нового образа операционной системы, когда мы заливаем её на flash, неплохо бы было сверить MD5-хеш. Лучше всего это делать уже после того

как мы записали на flash. Мы в принципе можем скачать на компьютер, посмотреть хеш, сошёлся — значит файл не битый, но лучше сделать это на flash, потому что могут быть ошибки при записи на flash. Команда verify с ключиком MD5 нашего образа, которая иногда отрабатывает долго на каком-нибудь старом слабом железе, и которая нам показывает MD5-хеш, ради которого всё затевалось. Это что касается такого беглого обзора файловых систем. Я думаю что-то новое может быть вы узнали, но всё это по-моему должно быть из CCNA. Теперь — образы операционной системы IOS с цифровой подписью. Про цифровую подпись мы тоже с вами поговорили и знаем, что с помощью цифровой подписи удостоверяется идентичность того, кто нам эти файлы прислал, или в данном случае — кто их изготовил. С давних уже

времён компания Cisco, когда собирает образы операционных систем, она их подписывает своей цифровой подписью. Эта цифровая подпись прикрепляется к образу, доступна для маршрутизаторов, ASR и других сетевых устройств. Я не могу сказать что все образы операционной системы IOS для всех устройств подписываются, но я думаю что на большинстве — на ASR точно совершенно, на коммутаторах тоже подписывается почти всегда. Цифровая подпись производителя, сокращение SPA. Это не SPA которая сауна, а цифровая подпись. Правда, не знаю как это расшифровывается, я думаю что не обязательно нам расшифровывать эту аббревиатуру, но сокращение такое есть. Как проверять цифровую подпись — есть

такая команда, она длинная, и я думаю что может быть я не уверен что на наших роутерах она сработает, хотя должна. Нет, на наших роутерах она тоже работает. Если у вас есть доступ к роутеру, а я думаю у вас есть, можете посмотреть как она работает и полюбоваться на цифровую подпись. Я сейчас проверяю, я не завис, просто проверяю на втором мониторе. Отлично, Иннокентий, спасибо большое про расшифровку. SPA: первый символ говорит что это подписанный образ, второй символ говорит production либо может быть development, и третий символ — A, B, C может быть. Вообще я SPA например

что-то не припоминаю в своей работе. Смотрите, у себя на железе эта команда работает даже на виртуальном роутере — там тоже образ операционной системы есть, с которого он грузится, так что она работает, и Cisco Systems, который его подписала, там всё это видно. Подписывается всё алгоритмом хеширования SHA-512, это всегда можно посмотреть. Я думаю что случай, чтобы на вашем устройстве оказалась неподписанная система, которая взялась непонятно откуда, конечно вряд ли будет, но кто знает. Просто надо знать, что угодно может случиться. Давайте дальше

смотреть. Теперь мы поговорим про защиту образов IOS и стартовой конфигурации. Это я думаю для вас новая информация, потому что на CCNA этого нет. Это было на CCNP, если я правильно помню. На CCNP — нет? На CCNA точно не говорят. Хорошо, тогда давайте поподробнее немножечко рассмотрим. В операционной системе IOS есть такая классная возможность — защитить сам образ IOS и защитить стартовую конфигурацию, сделать из них такой непробиваемый набор, который никто не сможет повредить. Это очень полезная вещь, сейчас мы

немножко это рассмотрим. Зачем он нужен: он упрощает восстановление в случае потери образа или конфигурации. Разные бывают ситуации, может быть как-то вы потеряли образ — мы сейчас про злоумышленников не говорим, хотя может быть и так. Восстановление из этого защищённого набора достаточно несложное. Иннокентий подсказывает — кривые ручки. Плюс самая наверное полезная возможность — это та самая защита от кривых рук, когда мы делаем невозможным изменение или удаление конфигурации либо самого образа операционной системы. Ещё раз, называется эта сущность Secure Boot Set. Как всё это включается: у нас есть

две команды — secure boot-image и secure boot-config. Я точно знаю что это не работает на виртуальных машинах, потому что смысла делать это в виртуальном окружении нет совершенно никакого. Хотя Иннокентий сказал... Ладно, нет, на виртуальном роутере не работает. Хотя кто знает. Просто я лично смысла не вижу. С другой стороны, виртуалку всегда можно восстановить из бэкапа. Иннокентий, если найдёшь эту штуку, подскажи, потому

что у меня не работает, я на своём роутере вот только что проверяю. А нет, работает! Играйте на роутерах, очень здорово. Сейчас я вам наврал, каюсь, не надо было врать с самого начала — на этих виртуалках работает. Я знаю на каких не работает, но это выходит за рамки нашего курса. Ладно, давайте я расскажу как это всё применяется и как потом отменяется, а потом попробуйте сами на роутерах. Отдельную лабораторную работу делать не надо. Смотрите, первое — secure boot-image включает возможности Secure Boot Set. Текущий образ IOS она делает защищённым. На самом

деле просто создаётся копия, которую потом нельзя никаким образом ничего сделать с этой копией. Этот образ невозможно никаким образом удалить, и при просмотре содержимого flash он просто не будет никак отображаться. Вторая команда — secure boot-config — в принципе то же самое делает со startup config: копирует в защищённую область памяти. И потом просто делает бэкап. Когда вы делаете copy running-config startup-config, обновляете startup config, этот бэкап автоматически обновляться не будет, он так и будет лежать в защищённой области памяти, и никаким образом невозможно его обновить. Может только вручную: сначала сказать no secure boot-config, отменить защиту стартовой

конфигурации, и потом опять включить. Считайте что это просто бэкап конфиг-файла, защищённый в памяти, не более того. Дальше, работа с защищённой конфигурацией — здесь я сделал снимки консолей, чтобы наглядно было, но вы можете в принципе у себя эти две командочки попробовать. Как проверить — у нас есть замечательная команда show secure bootset, которая покажет состояние нашего защищённого образа и состояние защищённой конфигурации. Что важно — эта самая защищённая конфигурация будет храниться в таком архиве, начинающемся с точки, так что в принципе её на flash можно увидеть и с ней можно дальше работать. Ещё возможности этого самого Secure Boot Set: можно

восстановиться из этого бэкапа startup config. Сделали secure boot-config, и потом из него очень удобно сделать восстановление — есть такое магическое заклинание в виде команды secure boot-config restore с указанием этого файла. Я не ошибусь если скажу что здесь вопросик работать тоже не должен, надо будет руками набирать — просто скопировать, сначала посмотреть show secure bootset, и потом это имя файла без .tar указать. Отключение Secure Boot Set: одна единственная команда — no secure boot-image. Если сделать, то это будет работать только в том случае, если вы подключились по консольной линии, по-другому никак. Точка в начале файла —

он типа невидимый. Включить это можно и когда вы через Telnet заходите — система позволяет включить этот самый Secure Boot Set. Но отключить эти возможности можно только с консоли. Система должна быть уверена, что вы стоите рядом с консольным кабелем, с голубеньким, и никак иначе, по-другому ничего с этим сделать нельзя. Только с console 0, по-другому не получится. Андрей, смотрите, никто не мешает жить с этим — вы можете сделать Secure Boot Set и всё, он так и будет храниться. Просто когда вы захотите например обновить образ операционной системы, а у вас Secure Boot Image, вы не сможете удалить старый. С другой стороны в принципе можно рядом новый образ положить, из него загрузиться — я так ни разу

не пробовал делать, но работать должно. С другой стороны secure boot-config вы поменять не сможете, здесь будет зависеть от того, что выберет система при загрузке, какой из образов. На удалённом сайте этого делать — почему не стоит? Если вы точно знаете что у вас будет возможность это отключить, делайте ради бога. Это ещё одна из неплохих, я считаю, возможностей самой операционной системы — как её защитить. Теперь давайте поговорим про такую вещь, про которую на CCNA не рассказывают, но очень полезную — это архивирование, резервное копирование конфигурации. Есть такая вещь — встроенный механизм Cisco IOS.

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

достаточно указать путь, куда нам складывать эти файлы — как правило, по TFTP, или я складываю по SSH на файловый сервер, как хотите, и FTP можно, и так далее. Имена файликов можно красиво оформлять, есть некоторое количество переменных в самой системе. На flash тоже можно, на flash без проблем, но лучше конечно это делать на удалённый сервер. Иннокентий правильный смысл подсказывает — никакого смысла на flash делать нет. Можно на flash, не хотите? Просто какой смысл в этом — обычно этот бэкап конфига он ценен когда лежит где-то ещё, не на той железке которая вдруг неожиданно сгорела, и вам сейчас привезут новую на замену. Правильно — куда складывать бэкапы? Конечно же туда, где все данные.

Бэкап диска C можно, диск C в Windows тоже неплохая идея, но лучше делать по-другому. Смотрите, про переменные я сказал — их можно красиво оформлять: имя хоста здесь указано и время когда создан архив. Честно скажу что есть ещё какие-то переменные, на это надо смотреть документацию, но вот этих двух хватает, я использую только эти. Плюс к этому можно настроить архивацию при каждом сохранении — команда write memory или copy running-config startup-config будет постоянно вызывать механизм архивации. Можно сделать так, можно указать чтобы архивировалась через какое-то время, например каждый день система будет сама запускать этот механизм. Там есть такой параметр time-period, в минутах указывается, и каждые

сколько-то минут она будет делать этот архив. Также в архиве можно указать, по-моему, что пароли тоже не писались. Там есть ещё некоторые параметры, они нам сейчас не важны, главное то что я рассказал, потому что про это почему-то все забывают говорить. Вручную можно сделать просто archive config. Без всего этого «copy running-config TFTP 192.168...» — всё это очень долго набивать, можно просто сказать archive config, и ваш конфиг отправится туда, куда вы указали при настройке. По поводу пароля — Андрей, не даёт?

В write memory — да, в принципе они будут работать одинаково. Но в write memory, хотя я не знаю, по-моему, подольше будет отрабатывать. Archive config в принципе делает то же самое — он running config формирует и потом отправляет. В принципе по времени должно быть одинаково. Не даёт задать пароль на SCP? Андрей, куда вы пытаетесь? Где сейчас задать пароль на SCP? У нас нигде SCP-сервера нет, чтобы на него лить конфиг. Если вы сейчас прямо пытаетесь мои слова повторять в лабе, думаю у вас не получится. Где у нас пример был пароль на SCP? Если по SSH, то пароли задаются вот в таком формате. Прошу прощения,

пароли задаются вот в таком формате, просто себе отметьте где-нибудь. Этот слайд не для нашей лабы. Роман правильно говорит — у нас SCP нет. Можно поднять если хотите, но не сейчас. На коммутаторе поднимите, потом попробуете. Да, у нас будет сейчас про SSH разговор, и я не думаю что лабу нужно делать на поднятие SSH, но мы просто ещё раз это проговорим с уже полученными знаниями по поводу сертификатов и ключей. Давайте продолжим. Дальше тема защиты сетевых устройств. Записи включил. Пару слов скажу про NTP — протокол

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

гарантирую. Почему нужно синхронизировать время — синхронизация времени напрямую относится к безопасности самым прямым образом. Посыпались вопросы, давайте на вопросы отвечу. По поводу часовых поясов — давайте сразу поговорим про часовые пояса. Show clock — время нормальное на железке смотрю. Show logging — часовой пояс минус три часа. Часовой пояс нужно настраивать вообще на всём

железе, которое будет работать. Даже по протоколу NTP оно будет синхронизироваться и будет использовать время по Гринвичу, не ваш часовой пояс, а UTC-время. Часовой пояс будет использоваться только для отображения вам времени. Но есть возможность писать логи в своём часовом поясе. Давайте не забегать вперёд, у нас будет разговор про syslog сегодня. Игорь, напомните мне — я вам покажу как это делается, это всё делается совершенно точно. Ладно, давайте про NTP ещё порассуждаем в разрезе безопасности. Синхронизация времени — штука крайне важная для безопасности, у нас курс всё-

таки по безопасности. Во-первых, это работа с цифровыми сертификатами. Мы уже говорили с вами в теме про PKI, что сертификаты не вечные и сертификаты всегда выдаются на какое-то время. Если время у нас в сети рассинхронизировано, тот момент когда сертификат закончился у одного, но ещё действует у другого — это очень критично скажется на безопасности. Представьте, пароль администратор заблокировал, а в половине сети этот пароль работает. В сети так не будет конечно, скажем в Active Directory виндовой. Но в случае с сертификатами такая штука может быть — когда, например, сертификат истёк. А бывают же сертификаты, которые выдаются не на два года, как мы брали пример веб-серверов,

какие-то временные сертификаты, которые выдаёт внутренняя служба — вот со сроком истечения этих временных сертификатов могут быть проблемы. Михаил, я очень прошу, это всё потом обсудим, сейчас будут все чатик читать. Мы же про NTP говорим. Clock timezone — всё правильно, поговорим с вами про clock timezone. Дальше, для чего ещё важна синхронизация времени — для анализа журналов сообщений. Мы с вами уже говорили про syslog, про логирование, ещё будем дальше про это говорить, что это очень важная вещь для безопасности, особенно в расследовании каких-то инцидентов, любых инцидентов. В расследовании каких-то инцидентов синхронизация времени на устройствах будет невероятно важна. Если время разъехалось, а иногда бывает так что время разъезжается в сети

на годы — такое тоже бывает. Представляете — где-то сдохла батарейка на материнской плате, устройство перезагрузили, и сервер получил время, когда сделана материнская плата — 2003 год. Я такое видел, и я думаю что вы такое тоже видели. Поэтому это разъезжание по времени очень страшно. Опять же, всякие системы типа Kerberos, которые выдают временные билеты, там тоже всё завязано на время. Иннокентий меня поправит, но по-моему максимальное расхождение по времени пять минут может составлять в сети. Поэтому когда операционная система Windows работает в домене, все компьютеры доменные — сразу когда вводишь компьютер в домен, во-первых, ввести компьютер в домен нельзя, если время больше чем на пять минут

разъехалось. А потом сразу как только ваш компьютер в домене, он первым делом синхронизируется с контроллером домена время, потому что пять минут — и всё, и ничего сделать нельзя. Никак не войдёшь, даже нельзя войти в систему чтобы время поправить — только там в BIOS-е тыкать, переставлять, сеть отключать и потом что-то пытаться сделать. Поэтому синхронизация — штука такая. Плюс мы вчера про RADIUS говорили, и сегодня парни в чатике продолжили разговаривать. Я упомянул, что с тем же самым RADIUS-ом политики очень часто делаются на основе времени. Например, можно входить только в рабочее время. Опять же, все эти рассинхронизации по времени здесь тоже будут очень нехорошо действовать.

NTP с любым расхождением будет синхронизироваться, спрашивает меня Михаил. Нет, Миша, не будет с любым расхождением. Если расхождение какое-то совсем огромное — я не могу сказать какое, потому что это зависит от реализации — например в Linux NTP говорит «stratum too high», и по-моему ещё какая-то вещь — есть ошибка что слишком большое расхождение. Если на год будет расхождение, NTP-демон вылетит с ошибкой. Хотя я не пробовал, у меня не было такой задачи, но попробовать можно — сделать расхождение на несколько дней и попробовать синхронизироваться. Дальше, устройства под управлением Cisco IOS могут быть как в роли клиента, так и в роли сервера NTP.

Нужно ли это — я думаю что иногда может быть полезно сделать, если не хочется поднимать в своей сети отдельный сервер NTP. Поднять его не так сложно, но бывает так что и возможности нет, и желания нет, и времени на это нет. Тогда можно один из роутеров или какой-нибудь коммутатор — не очень хороший вариант, но коммутатор тоже можно. дистрибьюшна почему бы не сделать нтп сервером если у него много вычислительной способности если он особо ничем не занят хотя нтп он такой по по математике он довольно копеечный протокол он не сильно грузит систему ничего страшного в этом нет можно сделать какой-то коммутатор или маршрутизатор нтп сервером и все остальные будут синхронизироваться с ним а он в свою очередь будет синхронизироваться уже с теми серверами и с которыми вы ему укажете есть одна грустная особенность у операционной системы циск и вас она не умеет синхронизироваться с

microsoft овске манте пи ну это то что я вижу у себя в сети 38 53 750 вот эти компьютеры и маршрутизаторы 19 29 не умеет то есть не знаю вероятно что какие-то версии могут но вот на контроллеры домена же крутится нтп сервер вот и я думаю что 2960 и 3850 работает а ну возможно у меня не работает но может быть винда специфическая а windows какой игорь 2008 r2 именно как контроллер домена работает или на нем поднята а прям с контроллером домена блин у меня не работает с контроллером домена но может у меня руки кривые я

я я могу это признать есть общедоступный олег отвечая на вопрос на ваш да есть общедоступные сервера нтп которые доверены на самом деле в интернете есть много вот правильно кирилл говорит много серверов нтп штах которым все доверяют они стоят в каких-то научных организациях в правительных правительственных организациях они доступны по сети с ними можно синхронизироваться всем желающим есть тайм не с гов до time windows ком пул нтп . орг которые включают пул это никто не запрещает в москве вон в посольстве америки стоит нтп сервера с которым можно синхронизироваться ни для кого не секрет или уже может быть уже не стоит вообще нтп сервер можно поднять самим

никто это не запрещает если у вас есть атомные часы там или или gps то но если вдруг найдутся энтузиасты если у вас какой то есть хороший gps приемник то можно сделать на основе него нтп серверы и у вас будет прям вот свой свое спутниковое время прям будет здорово на хабре поищите есть статьи как самостоятельно сварганить на основе там gps приемников свой сервер это не так сложно да с преферансом и поэтессами давайте дальше говорить мы так сейчас нтп я чувствую зацепила всех всех тема очень важно будет сказать что михаил ну ну зачем так сразу прямо энтузиазм по убавилась у всех когда речь пошла про 500 баксов ну может быть и так

давайте дальше поговорим про безопасность в нтп устройство что важно очень устройство циск и use они поддержат аутентификацию сообщений нтп то есть сообщение нтп которые передаются между устройствами можно подписать это важно я все время говорю слово важно важно важно важно уже вам надоело этим словом но это действительно так почему бы не подписывать сообщение вообще протоколов если есть такая возможность если это будет очень обидно если кто-то вдруг в сети начнет подменять сообщение нтп тогда представляете да какой-то левый нтп сервер если подсунуть в сеть если сбить время в сети но там можно вообще много делов там творить поэтому будем защищать как работает аутентификация в нтп все те же самые воронки все те же самые ключи те же самые картинки которые были у нас до этого

аутентификация в нтп работает элементарно сервер ну не обязательно сервер тот кто отправляет сообщение он его будет просто подписывать так же как подписываются также как подписываться другие сообщения в других протоколах обратите внимание здесь это не электронная цифровая подпись помните мы про цифровые подписи говорили когда с открытым и закрытым ключом здесь этого нет не путайте пожалуйста здесь просто есть общий ключ у двух участников и с помощью вот этих общих ключей и будут подписываться сообщения это не открытый закрытый ключ это не пики ай и это это все другое да да да здесь есть общий ключ у участников который будет вместе с обновлениями нтп прогоняться через хэш функцию и полученный отпечаток будет

прилепляться к этому самому сообщению с обновлениями и вместе ехать с другой стороны роутер будет делать точно такую же операцию он будет брать сообщение с ключом который есть у него точно также прогонять через хэш функцию и смотреть совпали отпечатки или не совпали вот если дайджест совпадают все прекрасно если дайджест не совпали у того что принял и того что получил сам мы понимаем что где-то посередине что-то пошло не так либо сообщение побилось либо его подменили ну в общем его там его может оказаться пример настройки нтп нтп вы настраивали на сессийный мы так заострять не будем здесь из интересного хочется сказать что неплохо бы использовать лупбеки вот она

указочку вам видно неплохо бы использовать лупбеки вообще для многого неплохо бы использовать лупбек интерфейс и я говорил и на кенте говорил лупбек интерфейс классная вещь он никогда не падает он всегда живой и на нем вообще очень много завязано если вы сейчас начать вспоминать синые си си пи и что слабо к берется и роутер айди и и там много чего как правило неплохо как как источник сообщений в нтп да даже в бит же пида везде вот где можно там лучше указать именно лупбек в том же си слоги неплохо бы указать лупбек адрес как источник сообщений чтобы не запутаться и чтобы он был постоянный этот адрес что еще из интересного вот эта самая команда

ntp аутентикей и плюс ключик вот это и настраивает стоп даже не так надо выделить это и настраивает собственно аутентификацию в протоколе ntp вот они вот эти строчки в принципе больше ничего не нужно для того чтобы включить вот эту самую подпись сообщений после этого ваше сообщение будут подписаны и все будет работать прекрасно дальше у нас будет разговор про системный журнал циск и иус про логирование журнали ровани и ну давайте про си слог поговорим си слогом вы знакомы уже с курса си си си най си слог облегчает задачи мониторинга и аудита без я даже не знаю как люди бы жили без

такой вещь как си слог мы все понимаем что важные события влияющие на сервисы их надо где-то сохранять сохранять их нужно на центральный сервер почему так важно конфигурация центрального сервера си слог с точки зрения безопасности вот вообще в разрезе безопасности си слог сервер это такой черный ящик для сети это последняя надежда разобраться с теми инцидентами которые произошли поэтому си слог сервер он должен быть абсолютно точно выделенным он может быть виртуальным он может быть и железным здесь все зависит от от возможностей компании но совершенно точно что к этому серверу должен должны получать доступ только те

люди которые занимаются расследованием инцидентов никто другой что к этому серверу к этому серверу никакой другой доступ кроме самого си слога из в сети предприятия не должен осуществить вообще допускаться то есть вот а запустили на нем там софт который будет собирать логи открыли порт юдипе какой порт юдипе помните напишите в чатик без гугла или не помнить вот все правильно открыли 514 порт и все этого достаточно все остальное закрыть вообще нафиг си слог работает по юдипе поэтому достаточно вот юдипе 514 порта если сисло к серверу не доступен ничего страшного в этом не будет опять же есть возможность сделать логирование по тси пи

и мы знаем все что есть замечательный протокол тси пи и у нас будет и надежнее доставка с другой стороны я призываю этого не делать потому что в случае недоступности си слог сервера непонятно как себя поведут те системы которые будут туда отправлять логи потому что кто знает кто знает вообще к чему это может привести ну ну вот недоступности слог сервера какой-то сервак который пишет на него логи будет ругаться что сервер недоступен будет накапливать логи в какой-нибудь свою область памяти у него это область памяти забьется конечно перифол переполнение буфер то не будет но все равно там и оперативка может закончен в общем здесь будет все зависит от реализации того софта который будет писать логи но тси пи лучше не использовать юди пи это просто выплюнул пакет в сторону сисло к серверу и забыл про него поэтому

лучше использовать и дипи но устройство циско могут отправляться сообщение в несколько мест во первых на консоль на виртуальной терминальной линии в локальный буфер размер этого буфера можно регулировать и также на удаленный какой-то сервер нужно ли хранить сообщение сисло к централизованно я думаю что на этот вопрос вы ответите все вместе со мной утвердительно конечно нужно так делать есть некоторые оговорки нужно ли все сообщения хранить либо только самые важные это будут решать уже администраторы конкретных систем потому что я понимаю что было бы здорово было бы неплохо вообще журналировать все на свете но у вас никогда в жизни

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

определять собственно что это за сообщение и какое внимание ему нужно уделить всего есть у нас 8 уровней важности 8 все верите запомнить их не так сложно если ну все по-разному запоминают я запоминаю по первым буквам я запоминаю их вот роман ассо капка капчи это совсем другое не это не си слог фейс винт фейс винт но можно и так запомни я не знаю я за запомнил запомнил их вот так в таком порядке дебага до emergency

быстро проговорим эти уровни эти уровни нужно запомнить и чтобы в них не плавали потому что на экзамене как инакентий правильно сказал будет обязательно на любом экзамене на си си иные на си си на security на си си а и это совершенно точно будет и так самое важное сообщение или давайте начнем наброс внизу мне больше не нравится на си си пи свечи дверь это везде есть на всех экзаменах надо просто эти уровни знать и зазубрить один раз и в них никогда не путаться и так начинается все с дебага это отладочные сообщения 7 уровень собственно дебаг это то что мы это вообще низкоуровневые сообщения каких-то под систем они в повседневной жизни не нужны они нужны только тогда когда что-то не работает и тогда мы можем уже попросить операционной системы ну-ка покажи к нам дебаг в случае когда мы с ней работаем через консоль

либо просто получить лог сообщение дебаги куда-то куда-то еще в буфер например или на сис лог сервер кстати одна из один из таких стилей работы с железом не включать дебаг в в консоли и не пялиться на него потому что это не всегда удобно например но не знаю какой-нибудь там айпи сек когда настраивается там блин дебагов стоп там вываливается 78 экранов потом их листать читать неудобно иногда хорошим стилем вот может являться то что можно включить именно логирование вот это 7 уровня в буфер а потом уже буфер спокойненько почитать можно и так сделать да да да андрей правильно сказал шестой уровень это информационные сообщения просто информационные сообщения пятый уровень это нормальные события

на тайс которые не являются ни ошибками не предупреждение ничего это нормальный но они уже важны четвертый уровень это ворнинги это возможные проблемы ворнинг от эрора отличается тем что ворник можно игнорировать но он это не ошибка в работе а это работа продолжается нормально но какие-то потенциальные возможные проблемы он собой олицетворяет поэтому если у у вас какие-то ворнинги есть их нужно обязательно обработать с ними нужно разобраться это как в работе программистов например когда вот у разработчиков очень часто такое бывает что пишется какой-то код потом он компилируется и там не компилируется сразу прогоняется скриптовые какие-то языки да и вот если в орденге возникают но все все работает программа работает

зачастую программисты ленится и на эти ворнинги просто забивают ну часто такое бывает и я сам занимался когда ты этим я сам иногда тоже забивал если там что-то такое неважно делаешь вот но с каждым ворнингом нужно разбираться точно потому что потом я ну вот при написании приложений это часто возникает что потом в дальнейшем каком-то развитие продукта оказывается что эти ворнинги они были не напрасно и работу может быть нарушена так что призываю вас всегда с ворнингами разбираться даже если он есть все работает все функционирует прекрасно но блин какой-то ворник появился лучше разобраться докопаться иногда это бывает очень непросто победить но надо приложить все усилия третий уровень это эрор это сообщение уже конкретных ошибках в работе системы я желаю чтобы выше третьего уровня у вас вообще ничего не появлялась

вашей работе то что касается второго уровня это критические состояния системы вот здесь уже и и второй и первый уровень когда система требует немедленного вмешательства чаще всего говорит о проблемах с железом то есть если у вас какие-то сообщения критикалы или alert значит ну скорее всего уже будут проблем какие-то на железном уровне это самые неприятные проблемы emergency это код 0 который ну я надеюсь что вы никогда не увидите своей жизни но увидеть его наверное можно уже только тогда когда устройство отправляется в мир иной она вот умирает и говорит все мерзженсе до свидания и потом умирает совсем есть такой код сообщений тернул паник да еще есть

то есть но кернул паник больше и unix выражение вот просто windows пишет кернул панике никогда не видел в windows и кернул бать паник именно такого сообщения юзда вы усе я просто не видел своими глазами никогда вы усе кернул паник и надеюсь я буду пореже видеть такие сообщения давайте продолжать про сис лог но сейчас посыпется истории жизни как настраивается сис лог мы сейчас в лобе наверное его поковыряем но сейчас я быстро расскажу а потом давайте в лобе поковыряем и посмотрим там еще есть некоторые приколы некоторые фишки с ним

как облегчить но во первых неплохо бы настраивать буфер всегда буфер не бесконечный он будет на разных системах разные поэтому здесь нельзя однозначно сказать в курсе что буфер у нас там максимум один мегабайт это будет зависеть от конкретного оборудования буфер настроить нужно это не так сложно логин буферит и сказали сколько ему выделить памяти в байтах в данном случае 64 к но логинг консоль полезно иногда делать отключать вообще сообщение на консоль потому что если вас это огромное количество логов вы просто работать не сможете Уровень важности сообщения задаётся командой logging trap notification. Logging trap notification — это уровень. Здесь уровень можно задать как в виде числа от 0 до 7, так и в виде

текстового представления. Хотя это всё зависит от версии, по-моему. Где-то я видел, что числом нельзя задавать, не вспомню где. Но имейте в виду, что лучше вопросик нажать, когда вы к этому подойдёте. Отправка сообщений настраивается очень просто, надо просто всего лишь указать хост, на который вы хотите отправлять. По умолчанию будет использоваться UDP порт 514. Можно даже без слова host в новых системах обойтись, и указывается, какой source-интерфейс нам нужно подставить. Так же, как в случае с NTP, в случае с большим количеством других протоколов лучше использовать loopback. Просто будет надёжнее, может быть, в каких-то сценариях и надёжности тоже добавит. Некоторые полезные настройки. Во-первых, service timestamps. Service timestamps log — здесь можно настроить кучу всего и

настроить именно то, как будет выглядеть ваше сообщение. Это оправдано, когда у вас есть много разных сетевых устройств, и не только сетевых устройств. Например, на один syslog-сервер собираете сообщения из маршрутизаторов Cisco, из коммутаторов каких-нибудь HP, и с Linux-серверов, может быть, из Windows-серверов. В этом случае у вас в логах получаются очень разнородные сообщения по своей структуре, и мы с вами уже говорили про то, что логи обрабатывать вручную — это плохая идея. Обрабатывать логи должны только автоматически. Кроме автоматизированной обработки логов все остальные методы работы с ними не канают. И когда у нас есть много разнородных сообщений,

будет просто неудобно их обрабатывать, неудобно парсить, неудобно делать по ним какие-то выборки. Поэтому можно привести нашу строку сообщения, именно строку сообщения, к какому-то понятному виду, может быть, чтобы совпадала со строками сообщений других систем. Это полезно. Очень полезно делать, иногда даже не иногда — я всегда делаю. На линии, на консольной линии, logging synchronous — есть такая команда. На VTY тоже можно logging synchronous. Это, я думаю, все видели в консоли, когда log-сообщения не перебивают ваш ввод, они будут более корректно отображаться. Иногда знаете, пишешь какую-то команду — бац, log- сообщение вывалилось, и оно в ту же строку вывалилось.

Logging synchronous будет означать, что в строку ввода никогда не попадёт сообщение syslog. Это полезная штука. Logging facility. Есть ещё в syslog такая концепция — это facility. Я попробую её на пальцах объяснить. Не путайте, кстати, severity и facility — очень часто путают. Severity — это важность сообщений от 0 до 7, а facility — это назначение сообщений. Дело в том, что когда отправляется log-сообщение, это же не просто текстовая строка, где написано, что у меня поднялся интерфейс, у меня опустился интерфейс. Плюс ещё к этому идёт какая-то служебная информация. Служебная информация там может быть много всего, но есть такое понятие facility — это канал, можно

иногда говорят, что это канал логирования. Сейчас, может, Иннокентий меня поправит, как это объяснить правильно. Facility — это назначение. Очень часто подставляется программа, которая отправила. Facility от 0 до 15 — программа, которая отправляет лог, она в качестве facility может написать имя демона, своё имя. А можно использовать такие пустые места в этом, и именно как назначение написать, направить в нужный канал. От 0 до 23, но это будет всё зависеть от системы. В Cisco от 0 до 23: 16 именованных, от 0 до 15, а ещё 8 нумерованных. Всё, тогда

всё сошлось у меня в голове. Смотрите, зачем нужны эти facility. Есть стандартные facility, они относятся... Есть именованные: это почта, cron, старые юниксовые news, UUCP, LPR, по-моему, отдельный facility имеет. То есть старые такие назначения там встречаются. С UUCP точно, и news — кто-нибудь вообще пользовался этими новостями старинными? Наверное, я такой старый. И есть ещё нумерованные, которые можно тоже использовать под какие-то свои назначения. Сейчас мы с вами тоже посмотрим. Local — да, они называются local, от 0 до 7. Вот эти

local — они не используются в стандартных системах, хотя некоторые демоны... Cisco в local 7 отправляет, некоторые демоны отправляют тоже. Например, DHCP-сервер он отправляет в local 5, если я правильно помню, могу ошибаться. Сейчас я плохо помню эти local, потому что syslog настраивается не так часто. Обычно syslog настраивается один раз, и всё. Я же говорил, да? Я вам говорил, что вместе с самой текстовой строкой, вот с этой, плюс ещё идут служебные данные, которые в заголовке сообщений syslog идут. Severity там, и так и facility там же. Там ещё восемь целых бит. Всё, хватит. Смысле, всё, хватит, давайте ещё раз объясню, что такое

facility. Facility — это просто обозначение. Иннокентий сказал: 5 бит — это указание syslog-серверу. Это где это было сделано — не для Cisco IOS, где валится всё в одно место, а для старых UNIX-систем, где каждая подсистема отправлялась, из логи со своей этой меткой, чтобы потом syslog-сервер просто по этим меточкам разобрал, куда записывать, в какой, например, файл, в какое место записывать. И всё. Это как 802.1Q тег, и чтобы потом было понятно, какому VLAN принадлежит кадр. Просто такая метка. И Cisco пишет всё в local 7, но теоретически можем в другой писать. Это чтобы на syslog-сервере было удобно уже разбирать. Их так мало потому, что syslog — это древняя, очень

древняя система, и в ней этих facility было очень мало. У меня в своё время, я когда-то давным-давно настраивал веб-сервер, правда, там 10 лет назад, и отправку делал syslog с него. И мне хотелось сделать красиво: чтобы несколько было сайтов на этом веб-сервере, и чтобы каждый сайт отправлял syslog со своим facility, чтобы потом на сервере красиво всё это разложить по директориям. Но когда сайтов стало много, я понял, что мне просто facility не хватает, и пришлось переписывать с нуля. Давайте приступим быстро к ковырянию syslog в лабораторных условиях.

Посмотрим, как всё это настраивается. Для начала — как с буфером работать. Мы можем задать буфер лога на нашей системе. Максимально можно задать сколько же это у нас будет — сейчас 2 с половиной мегабайта. Это в принципе достаточно, чтобы комфортно работать с логом. Это даже очень много. Но текущий размер можно посмотреть просто show logging. И show logging у нас должен показать — он log buffer показывает. Смотрите, давайте с show logging начнём. Есть команда show logging без параметров, она просто показывает, как у нас настроена подсистема журналирования. Во-первых, у нас там по сообщениям показывает,

сколько куда свалилось: у нас сколько в консоль было сообщений, буфер, exception. Дальше, persistent logging не будем касаться. Он размер того же буфера — сейчас у нас буфер 8 килобайт. Можно задать его какой угодно — до 2 мегабайт на этой системе. Чуть-чуть подтормаживает у меня консоль. И можно сказать, например, столько. Теперь для каждого назначения — для буфера, для консоли — можно задать свой уровень важности. Это тоже полезно. Мы можем сказать, что в буфер мы будем, например, валить debug. Можно и в числовом виде severity задавать важность, можно и в текстовом

варианте тоже. Сказать, например, мы сюда будем валить... нет, debug не хочется, там все сообщения которые у нас не шестого уровня. Не надо. Если мы пишем логи в буфер, как его рассчитать, чтобы не потерять нужные логи? Миш, не знаю, как его рассчитать. Мы же не знаем, сколько у нас логов валится. Теоретически мы можем подсчитать количество сообщений в минуту, прикинуть средний размер одного сообщения просто по символам, и прикинуть, сколько в буфер. Но в буфер логировать — не очень хорошая идея вообще. Логировать в буфер что-то... В буфер логировать можно, чтобы, например, по-быстрому debug посмотреть. Но туда

валить само по себе... Хорошая идея — только в буфере хранить? А, ну или... Просто я не слежу за чатом уже. Плохая идея debug выводить в консоль, да. Мы уже говорили, что есть разные стили работы с debug. Неплохо бы его в буфер сохранить, а потом почитать. Можно для какой-то отладки сказать logging buffered debug, потом что-то сделать, например, OSPF поднять, отключить его, чтобы не засорялся буфер, и уже спокойно сидеть читать, что там у нас в буфере накопилось. Но вообще, Игорь, чем меньше мы включаем debug, тем лучше мы работаем — ответил Иннокентий. Ладно, хватит

перепалок, давайте отставить. Давайте дальше. С syslog начали разбираться. Дальше — logging можно настроить для консоли. Конкретные вещи логирования опять же можно указать свой уровень для конкретного назначения — и для консоли, и для буфера. Можно просто отключить вывод всех логов на консоль, и тогда у нас на консоли вообще ничего не останется. Но это делать не очень хорошо, пусть всё-таки на консоли что-то остаётся. После ввода severity, похоже, сбросился размер буфера. Это куда вы вводили logging buffered? А, буфер потом severity мы пишем. А это у меня сбросился, потому что я просто написал debug. Да, всё

правильно, потому что я не дописал. Надо написать размер, а потом указать уровень. Вот так надо правильно. Тут команда такая, она немножечко заморочена: сначала обязательно сказать размер. Если не сказал размер — он сбросится. Можно задать в принципе общий уровень — logging trap — и здесь задать уже общий уровень важности. Тогда все логи будут у нас с таким уровнем важности, например, только два. А ещё можно сказать no logging trap. Пусть вас не путает параметр trap. Он тоже для логинга. Trap — это вообще просто сообщение, которое инициирует устройство. Это не обязательно относится к SNMP.

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

файлы люди копируют и удаляют. Или вообще ещё какой-нибудь более простой сервер, который запускает один скрипт в день. И там бывает такое, что в логах вообще тишина неделями может быть. И в некоторых операционных системах, по-моему, в Red Hat так было до недавнего времени, в новом не знаю, Миша подскажет. Там по умолчанию syslog был настроен, он отправлял эти сообщения mark, по-моему, каждую минуту. Типа, syslog живой, syslog живой. Потому что когда тишина в логах — тоже плохо: ты не понимаешь, либо syslog умер, подсистема сдохла, либо просто ничего не происходит. Сообщения mark — очень полезная штука. Логирование на внешний сервер: logging host. У меня этот хост — у нас общий стоит log-сервер 10.101.201... Я его проверю, он живой. Всё правильно. Logging trap — это отправляемые сообщения,

пусть будет notification. И если посмотреть на наш syslog-сервер, то мы увидим, что... Кто у нас работает на восьмом комплекте? Удачно запустил. Только я не знаю, на восьмом комплекте как вы догадались, что адрес... А, вы просто посмотрели здесь адрес, на котором слушает. Я его просто адрес до этого не говорил. А смотрю — сообщения уже приходят. Вот, у нас есть хакер среди нас, который просто посмотрел адрес syslog-сервера, и пока я тут распинался, Михаил уже всё быстро настроил. Visual hacking, всё правильно, самый натуральный visual hacking. Теперь по поводу настройки. Source-интерфейс — у нас тут loopback-ов сейчас нет. В общем, мы знаем, что это можно настроить.

Теперь что ещё под запись нам надо сказать — этот самый service timestamps. Service timestamps log — есть такие настройки service timestamps. Они для логов и для debug настраиваются отдельно, но в принципе то же самое. Service timestamps log — там очень много параметров, которые можно включить. Если вопросик понажимать. Во-первых, можно uptime использовать в качестве времени. Service timestamps — это то, что будет в качестве времени у нас записываться в логе. Там ещё есть другие сервисы, мы сейчас посмотрим. Можно использовать либо uptime, и тогда в логе будет писаться не текущее время, а просто сколько uptime у железа. Иннокентий правильно говорит: если нет

никакого нормального времени на железе, то только uptime. Давайте с datetime. Этот datetime можно настроить, в принципе тут параметров много. Можно указать то, что спрашивал... Кирилл спрашивал или Роман спрашивал? То, что мы можем указывать localtime. Вот эта самая настройка, и тогда у вас будет использоваться локальная... Игорь спрашивал, прошу прощения. Будет локальная зона использоваться в логах, время будет написано локальное. Можно сказать, чтобы миллисекунды писались. Можно, чтобы показывалась timezone или не показывалась timezone. Можно ещё и год, чтобы писался. Настройка этого отображаемого времени в логах — она такая развесистая, в принципе можно туда много всего написать. Я сейчас туда написал всё

подряд. Сейчас, если я закончу писать, он сюда должен отправить. А, timezone, ок, timezone. Вот так. Trap у меня стоит, поставим... Я уж забыл, я столько параметров перебрал, что я забыл, что на самом деле настроено. Смотрите, у меня теперь получилось — где моя... Я сюда написал всё, что можно, и timezone. Роман уже придумал, как сюда писать своё имя. Можно ещё и это настроить. Service sequence-number можно включить. Service sequence-number — это полезно, когда будет нумероваться каждая линия. В принципе это полезно.

Смотрите, sequence-number — полезная штука, когда в каждое сообщение будет дописываться номер этой линии. Может так быть, что, не дай бог, кто-то потёр логи на устройстве после себя. Обычно когда злоумышленник пробирается на устройство, потом все логи подчищаются. И в принципе можно понять по этим линиям — они там сквозная нумерация — были удалены какие строки, не были удалены. Подождите, блин, я просёкся. Нам Берган... На самом деле, говорю line number, а я перепутал — sequence number. Line number — это другой номер. Витя, это разве? Сейчас я посмотрю. Да, прошу прощения, это service sequence-number. У нас

ещё интересного в logging есть... Блин, тут в logging на самом деле можно настраивать origin-id. Это у нас будет добавляться либо имя хоста, либо адрес хоста, либо любая строка, которую вы сами придумаете. Можно задать очередь сообщений. Можно задать количество сообщений в секунду. Иногда бывает так, что если у вас много устройств — больше одного, больше ста или больше тысячи — и что-то происходит в сети нехорошее, то syslog-сервер может просто не справиться с количеством принимаемых сообщений. Поэтому бывает иногда полезно немножко приджать, это rate limit. На сервере сделать всё-таки какое-то нормальное количество сообщений, чтобы он не долбил по 5000 сообщений в секунду. Что ещё такого полезного сказать?

Дальше, дальше, дальше. Весь syslog не будем разбирать. Про host мы поговорили, про facility я вам рассказал, про buffered мы рассказали. Message discriminator... Пока хватит. Origin-id мы сделали, настройку назначения сделали. Всё, давайте я паузу поставлю. Продолжаем. Сейчас у нас этот слайд. Небольшая заметка об оповещениях о проблемах с памятью и процессором. В Cisco IOS есть такая возможность — отправить сообщение при нехватке памяти или при нехватке ресурсов процессора. Полноценных инструментов,

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

память для каких-то критических процессов. Есть такая команда — она выделена красным — memory reserve critical. Извиняюсь. И просто указать нижний порог свободной памяти. Вот эта команда memory free low-watermark — она обозначает нижний порог, после которого у нас система начинает отправлять syslog-сообщения, что не хватает памяти, что у нас всё плохо. Имейте в виду, такая возможность есть. То же самое у нас с процессором — мы можем указать определённый порог ресурсов процессора. Можно сказать process cpu threshold, и при достижении этого порога у нас будут тоже отправляться сообщения. Но если сообщения о нехватке памяти обязательно отправляются с помощью

syslog, то сообщения о недостаточных ресурсах процессора будут отправляться с помощью SNMP. Давайте дальше, про NetFlow. На CCNA был разговор про NetFlow или не было? Здесь мы не будем настраивать и копать глубоко NetFlow, я просто напомню ещё раз концепцию NetFlow — она важна. Давайте тогда я кратко её ещё раз опишу под запись, если вы с ней хорошо знакомы, и объясню, почему она важна в контексте безопасности. Потому что, конечно же, удобнее работать именно с NetFlow. Здесь под NetFlow мы сейчас будем не конкретный механизм подразумевать, а просто концепцию потоков в сети. Вообще, в сетях мы

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

схалтурить и работать с потоком. Этот самый поток — собственно то, с чем обычно будут работать системы безопасности. Те же самые современные файрволы с пакетами уже давным-давно не работают, оперируют потоками, потому что это гораздо эффективнее. Соответственно, поддержка NetFlow в Cisco позволяет собрать статистику прохождения через интерфейс, например, трафика. Зачем это нужно? Смотрите, позволяет распознать необычные паттерны трафика. Паттерны трафика — это действительно важная вещь. Мы можем отличить с помощью анализа NetFlow нормальный трафик от вредоносного. Разные системы делают очень много различных действий для этого. Анализ может быть

на основе многих факторов. Но опять же, здесь будет работа с потоком. Просто анализируя пакеты единичные, мало чего добьёшься. Будет дальше рассказ про то, как про техники обхода IPS, у нас небольшой. И там вы поймёте, что работа с единичными пакетами она вообще неэффективна. Мало того, что она медленная, если говорить про маршрутизацию и коммутацию, так она ещё неэффективна в плане безопасности — вообще ничего не поймаешь в современных реалиях. Если рассматривать современные угрозы, попакетная обработка она ничего не даст. Попакетная обработка осталась далеко в прошлом. Плюс также NetFlow помогает в расследовании сетевых атак — и до, и после их возникновения. Обработка NetFlow она уже может нам каким-то

образом подсказать, что планируется сетевая атака — именно по изменениям характера трафика. Выделить какой-то необычный трафик, проанализировать его более тщательно. Этот необычный трафик — это может помочь действительно в распознавании атаки. Также и после возникновения атаки, после какого-то инцидента, очень удобно проанализировать собранный NetFlow и применить какие-то меры. Меры — какие, помните или не помните уже? Detective, corrective — меры расследования, либо уже какую-то коррекцию произвести. Вне контекста безопасности NetFlow тоже можно использовать как угодно. Например, просто считать трафик. Провайдер может считать трафик своих абонентов — как один из примеров. Это хорошие счётчики,

достаточно подробные, поэтому применение придумать можно много. Надо запомнить ключевые признаки потока. Есть семь ключевых признаков. Если у двух и более пакетов эти признаки совпадают, то эти пакеты относятся к одному потоку. И уже все остальные пакеты, у которых эти признаки будут такие же, они все будут относиться к этому потоку и обрабатываться однотипно. Именно в этом и есть эффективность: пришёл пакет, у него семь признаков есть, мы выделили его в отдельный поток. Пришёл точно такой же пакет с такими же признаками — мы точно такую же обработку на него повесили, точно так же расковыряли его содержимое с помощью конкретного фильтра или конкретной сигнатуры. Не будем уже обрабатывать каждый пакет. Давайте по поводу этих семи признаков. Это не только поля заголовка, но и кое-что ещё:

адреса источника и назначения — IP-адреса, номера портов источника и назначения, номер протокола, поле ToS — Type of Service, и входной логический интерфейс. Здесь надо понимать, что именно логический интерфейс, не физический. И по этим семи полям мы однозначно можем сказать — пакет пришёл новый совершенно, либо пакет уже можно отнести к какому-то потоку. И на CCNA, Игорь подсказывает, Олег говорит, что на CCNA эти вопросы возникают везде. Я думаю, что вам эта концепция знакомая, она несложная, и очень здорово, что вы её знаете и понимаете. Система NetFlow, когда она настроена, она будет экспортировать

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

не будет система накапливать информацию о потоках и потом посылать там 20-килобайтный пакет. Во-первых, он никуда не пролезет такой пакет без фрагментации, 20 килобайт. Во-вторых, смысла в этом нет, можно просто чаще отправлять информацию о потоках. Пример настройки NetFlow. NetFlow — штука развесистая, настраивать там есть что. Но в минимальном виде она настраивается очень просто. Надо задать назначение, куда мы будем экспортировать эти пакеты. Запомните, может быть, для экзамена, что обычно стандартный порт 9996. 9996, но... Да, Миша, это старый, но он работает везде. Есть ещё новый способ настройки. Как он, Миш, подскажи, как он называется? У нас Михаил просто недавно снимал по NetFlow, я знаю по

секрету, и поэтому он в этом собаку съел. Это обычный стандартный тип настройки, который там везде работает. Поэтому и на экзамене он тоже везде, я думаю, если встретится, то именно такой тип настройки. По дефолту вообще версия 9. Версии 9 много лет, и я не знаю коллекторов, которые не работают с версией 9. Нет смысла использовать какую-то другую, хотя, может, есть какие-то ещё коллекторы. Но если хотите быть уверенным, настройка NetFlow скорее будет зависеть от коллектора, понимаете. Потому что просто так NetFlow настраивать смысла нет. Его настраивать нужно под конкретный коллектор, за

который вы заплатили денег или не заплатили денег, то, что вы внедряете в вашей сети, уже всё под это затачивать. А если коллектор не держит версию 9, не работает с ней — ну, плохо. Можно сказать, чтобы именно интерфейсы также были включены в пакет. И, как всегда, наша уже любимая настройка — использовать везде source-интерфейс loopback. Это полезно. Как настраивается на интерфейсе, я думаю, тоже вы уже знаете. Можно NetFlow собирать либо на входе в интерфейс, либо пакеты, которые исходящие с конкретного интерфейса. В каждом конкретном случае здесь чётких рекомендаций опять же нет — что вы хотите собрать, что вы хотите анализировать. Это не просто так собирается, а для дальнейшего анализа. Если

вы не знаете, зачем собирать NetFlow, лучше этого не делать, потому что никакого смысла нет. NetFlow на самом деле в активной сети будет занимать прилично дискового пространства. Если кто-то работает в провайдере, он прекрасно знает, что под NetFlow — под провайдерский NetFlow — покупаются там такие серверы, такие хранилища, чтобы его хранить. Провайдеры обычно хранят это долго, не два дня, не месяц, а там очень долго, потому что отчётный период какой-то годовой есть. Годами всё это хранят. Но это всё больше связано с финансовыми претензиями, потому что это всё деньги — потому что они считают трафик, и это всё выражается в денежном эквиваленте. А внутри обычной сети предприятия — ну, какой у вас

Горизонт планирования — сколько у вас есть места на дисках, опять же насколько активно трафик ходит в сети. Включать NetFlow везде, на каждом устройстве, тоже нет никакого смысла. IPFIX и NetFlow — это немножко разные сущности, но я понимаю, какой смысл снимать с Layer 2 интерфейса. Я сейчас к этому подвёл — нет смысла включать NetFlow на коммутаторах, например, вообще никакого смысла. Я понимаю, что можно включить вообще везде, на каждом устройстве в сети, но зачем вам считать этот трафик? Я понимаю, что интересно было бы его анализировать, но для этого есть другие способы. Между сегментами сети лучше ставить какое-то железо для анализа трафика, а NetFlow — это всё-таки больше подсчёт трафика. С Layer 2 интерфейса никак не снимет — это всё-таки штука, завязанная на маршрутизацию.

Только если SPAN куда-нибудь делать, да. Запомним, куда-нибудь законспектировать себе. Проверки настройки — команд на самом деле больше, но основные: это просто показать, где у нас настроен NetFlow, show ip cache flow — показать информацию по потокам, и show ip flow export — посмотреть информацию по экспортированным пакетам, по тем пакетам, которые мы будем отправлять на коллектор. На 15-м IOS — да, это работает в 15-м IOS. Здесь не так критично. Парни, словом, мы так вскользь упомянули. Я не думаю, что на экзамене будет много вопросов по NetFlow.

Эта тема заслуживает отдельного разбора, это такая глубокая тема, но в курсах цисковских, даже там, тоже не очень глубоко разбирается. Защита протоколов управления. Давайте про протоколы управления поговорим. Здесь тоже я не думаю, что будут для вас какие-то откровения. Для тех, кто был на сессии CCNA и CCNP, просто проговорим базовые вещи, которые нужно знать, хотя даже про эти базовые вещи часто забывают. Настройка протоколов управления. Надо просто помнить, что некоторые версии протоколов подвержены атакам, и лучше заменять их на более защищённые. Если есть возможность не использовать Telnet —

не нужно использовать Telnet, вместо него есть возможность использовать SSH. То же самое касается HTTP и SNMP. Если есть возможность SNMP третьей версии использовать — используйте, конечно, её, потому что она намного безопаснее. Мы про SNMP сегодня тоже пару слов скажем. То же самое с HTTP. Вообще не очень хорошая идея использовать HTTP на сетевых устройствах, но иногда бывает так, что приходится. Например, на той же Cisco ASA — завтра будем с ней знакомиться. Гораздо удобнее использовать в ряде случаев тот же инструмент SDM для настройки чего-нибудь, там нужно HTTP включать. HTTPS или там на роутере — на роутере есть некоторые вещи, и я вам их покажу, которые в консоли делать

очень неудобно. Я сам не люблю все эти графические интерфейсы, я работаю всегда в консоли, но на роутере единственная тема, которую делать в консоли очень геморройно, — это настройка IPS. Мы будем делать в консоли, чтобы — на самом деле мы будем немножечко с этим играться, поэтому мы не устанем, — а если серьёзно там заниматься настройкой IPS на роутере, там конечно в консоли уж очень тяжко будет. Про SSH пару слов. Мы знаем, что SSH предоставляет более безопасный метод доступа — это не Telnet, который передаёт всё в открытом виде. Мы с вами в первый или во второй день в начале разбирали, как SSH устанавливает

соединение, как он сессионные ключи генерирует, как передаёт, шифрует. Мы уже примерно знаем, что SSH — протокол надёжный, никакой Telnet нам не нужен. Настраивается он достаточно просто. Мы конфигурируем хостовую ключевую пару. Теперь-то мы уже понимаем, зачем нужна ключевая пара, потому что на сессии CCNA я не думаю, что понимали, зачем эти ключи генерить, там RSA какая-то ерунда. Теперь мы знаем, что ключевая пара — это очень важно, что должно быть два ключа: открытый и закрытый. Соответственно, SSH не будет работать без сущности пользователя, потому что он требует всегда пользователя. Нужно создавать пользователя, его пароль сконфигурировать, VTY-линии для использования локальной аутентификации. Мы с вами про аутентификацию вчера разговаривали. И подкрутить VTY и указать протоколы. Я не уверен, что нам нужно

лабораторную работу для этого делать, я просто покажу вам слайд с настройкой. Вы настраивали это не раз на разных курсах. У нас классно, что собралась такая подготовленная группа, не нужно никакие детсадовские вещи объяснять, мне очень нравится работать. Надо помнить, что для генерации ключевой пары нам требуется FQDN, полное доменное имя. Нужен обязательно hostname и обязательно нужно имя домена. Без указания имени домена или hostname роутер откажется генерировать ключевую пару. Даже если он будет называться просто Router, он вам скажет — обязательно введите имя хоста. Это важная вещь. Ключевая пара генерируется с

указанием длины ключа, либо можно не указывать — тогда по умолчанию, кстати, в разных версиях будет разная длина ключа: 512, а в новых версиях может быть 768. Обычно достаточно, я не знаю, 1024. Можно сделать больше. Мы с вами говорили — здесь можно ключ, по-моему, сделать максимально 4 килобита, прошу прощения. Но вы знаете, что чем больше ключ, тем медленнее работает система. И нужно ли это, потому что сессионные ключи они всё равно будут время от времени перегенерироваться — это делает сам процесс SSH, это не вы будете делать. Сессионные ключи — я про них говорю, не про RSA-ключи, не про ключевую пару. Дальше, что ещё из интересного, про версию 1.99. Я думаю, вы знаете: когда вы включаете SSH и ваш ключ больше чем 768 бит,

то система включает версию 1.99 — так называемая версия 1.99 спецификации протокола. SSH не существует версии 1.99, существует версия 1 и версия 2. Версия 1.99 означает, что процесс SSH-сервер будет поддерживать и первую, и вторую версию. Нет, это не цисковская штука, Игорь. Смотрите, 1.99 — это означает, вот здесь написано сноска, что сервер будет поддерживать клиентов и первой версии, и второй версии. Первую версию мы с вами разбирали, как там соединение устанавливается — в начале слайд был, картиночка. Вот первая версия. Я слышал утверждение одного тренера на курсах, что 1.99 — это чисто цисковская штука, типа версия 2, но ещё до того, как официально опубликовали. Но на самом деле это неправда. В официальной

документации написано, что версия 1.99 — это на самом деле просто поддержка клиентов первой версии. Но некоторые тренеры — я не от одного, а от нескольких тренеров такую штуку слышал — могут ввести в заблуждение. Поэтому именно так, как я сейчас говорю. Как настраивается — username — все видели, как настраивается. Неплохое дополнение к этому будет включить ip ssh authentication-retries — это количество попыток входа, потом будет тайм-аут. И сейчас ещё некоторые удобные фишки SSH мы рассмотрим. Смотрите, штука интересная, которую можно применять, но с

осторожностью — имейте в виду. Это управление попытками входа. Смотрите, интересная штука — управление попытками входа — вещь полезная, но её нужно применять с осторожностью. Сейчас я объясню почему. Есть такая возможность — временно заблокировать вход на устройство, если будут обнаружены несколько неудачных попыток аутентификации. Настраивается она очень просто. Мы говорим — давайте про настройку сразу. Мы говорим, что заблокировать логин на 90 секунд, если в течение 30 секунд было три неудачных попытки входа. Как только мы эту настройку введём, роутер сразу её примет. Просто почему с осторожностью — роутер

сразу её примет, и если в этот момент у вас кто-то на ваше устройство активно ломится — на многие роутеры активно ломятся какие-то нехорошие творческие люди из интернета, подбирают логины-пароли, — если у вас очень активные такие попытки, то роутер скажет: «Окей, всё, я блокирую» — и заблокирует вообще попытки входа. И может получиться так, что вы до него не достучитесь. Это на самом деле не такая интеллектуальная система, как, например, fail2ban для Unix-систем — там она поудобнее работает. Тот же fail2ban, если вы понимаете, о чём я говорю, — там она будет отслеживать с каждого IP-шника попытки входа, именно с каждого IP-шника блокировать. Смотрите, он на самом деле блокирует — он не выкинет,

он будет блокировать. Как он будет — он будет брать и вешать access-лист на интерфейс — раз — на VTY. Дело в том, что я разбирался — меня пригласили тут в одну компанию, я настраивал какой-то роутер, там два роутера, перенастраивал после того, как их внедрили. Внедрили, там год эти роутеры поработали — это образовательное учреждение крупное, — а потом что-то потребовалось переделать, и меня пригласили как специалиста из системного интегратора. Я туда приехал, посмотрел, стал разбираться с роутером, смотреть конфигурацию — там конфигурация такая развесистая и жуткая. Ну, я так не делал, ну ладно, не об этом разговор. Я смотрю running config — а я дурак, не стал смотреть startup config, думаю, может, ещё что-то

после этого настроено, всё посмотреть. И смотрю — какой-то совершенно дебильный access-лист кто-то написал. Я думаю, если человек был на курсе CCNA, то он знает, как нужно писать access-листы. А это access-лист очень короткий, очень дебильный. Я сейчас его не воспроизведу по памяти. Если вы эту штуку настроите — но можем, если время останется, потом напомните мне, мы сделаем лабу, или сами в лабе попробуйте. Короче, эта штука как раз работает — вешается access-лист, и там в этом access-листе есть ошибка. Ошибка заключается в том, что там последняя строчка будет недостижима — никогда, вообще никогда до неё не дойдёт. И никто бы так не написал. Но я не знаю, кто писал эту подсистему, но почему-то такой access-лист получается в результате действия этой системы. Правда, он неправильный — можете сами проверить, или потом мы с вами все вместе проверим этот access-лист.

Смотрите, чтобы не потерять доступ к этой железке — access-лист будет включаться вообще для всех, и вы туда не проберётесь, — но можно настроить исключение: создать access-лист с permit login и указанием каких-то хостов, которым не блокировать ни за что. И добавить ещё команду quiet mode — добавить ещё access-лист, и тогда с этих адресов будет пускать всегда, находится ли устройство в заблокированном режиме или не в заблокированном. Да, Миш, там что-то такое типа было. Потом на лабе попробуем, я попробую воспроизвести. Вот такой там access-лист. А сейчас подождите. Я призываю вас использовать эту вещь — это полезная штука, login delay. Сейчас, подождите.

Роман, вы спрашиваете именно про login block — это на 30 секунд будет блокироваться, а тайм-аут между неудачными попытками логина — это совсем другое. Login delay — это тоже будет работать, login delay будет работать независимо. Это просто когда SSH настроите — login delay сделайте, и всё будет нормально. Смотрите, ещё — нет, они друг другу не будут мешать. По поводу ещё раз access-листов: этот access-лист — это исключение. Я говорю, что в этом quiet mode, в этом режиме, когда всё заблокировалось, пускать людей или хосты из этого access-листа. А когда система блокирует, она создаёт access-лист, который я вам в чатик бросил. Но на самом деле, не знаю, куда он вешается — я не

нашёл. Она просто вешает на интерфейс, но это не отображается в конфиге. И этот access-лист, который неправильный, создаётся автоматически. Ещё раз посмотрю. Сейчас, подождите секундочку. Не могу найти. Ладно, давайте не будем на этом заострять внимание. Короче, сами попробуйте потом, поищите, куда этот неправильный access-лист вешается — вам домашнее задание. Но он, по идее, как он написан, должен на интерфейс вешаться, на линии VTY. А в конфиге он не отображается.

Он отображается как access-лист, но куда применили — не отображается. Да, да, да, он непонятный. Редактировать конечно нельзя, и куда применяется тоже. Может быть, я невнимательно смотрел, но я особо не заморачивался этой темой — посмотрел, настроил, понял. Я не знаю, Миш, мало того что это странный access-лист, всё что с ним связано тоже странно. Так, настройка HTTPS. Давайте не терять время, сейчас проговорим ещё некоторые вещи. Надо понимать, что HTTP и HTTPS сервер в Cisco включается отдельно. В IOS у нас есть две разные команды: ip http server — это включает обычный сервер, secure server включает сервер с TLS. При первом

включении генерируется ключевая пара, про которую мы уже всё знаем, что это такое, и генерируется сертификат. Про сертификаты мы теперь знаем. Все сертификаты они будут самоподписные и они будут храниться в NVRAM в виде таких файлов. Вы можете сами сейчас включить secure server у себя и посмотреть dir nvram, и вы увидите, где будут эти самоподписные сертификаты храниться. Best practice: если вам это не нужно в работе, зачем вам нужен HTTP-сервер или HTTPS-сервер на роутере? Я думаю, что только если вы на нём настраиваете IPS. SDM — не SDM, этот, как он для

роутеров называется — Cisco Configuration Professional — только для этого. А так я нигде не использую. SDM для свичей я не пользуюсь. Графическими этими по разным причинам люди не пользуются. Я не пользуюсь, потому что не люблю, я только в консоли работаю. Дальше, давайте продолжать. Ещё про сертификаты несколько слов. Иногда бывает, что хочется использовать свои сертификаты, потому что Cisco при включении HTTPS-сервера будет там сертификат придумывать, самоподписной, который по сути вам вообще не нужен. Например, хочется свой сертификат — у вас есть PKI, развёрнутая

инфраструктура на предприятии, у вас есть свой центр сертификации локальный, вы там выдаёте сертификаты вашим серверам, у вас всё красиво. В принципе есть возможность его заменить. Из Active Directory там нагенерить сертификатов красивых, и в принципе его можно заменить на свой сертификат — это тоже не проблема. Как они хранятся? Есть такая сущность — trustpoint. Trustpoint — это область памяти, где будут храниться эти самые сертификаты. Посмотреть информацию о сертификатах и ключах можно на самом деле просто — show crypto pki в show run, где будет показан trustpoint, как называется, где будет показываться тип сертификата и некоторые его параметры. Обратите

внимание, например, здесь написан revocation check — это где проверить отзыв сертификата. Но так как сертификат самоподписной, то нигде. И ключевая пара, которая будет сопоставлена с этим сертификатом, хранится тоже там же. Можно посмотреть — это вся цепочка, это просто отпечаток будет сертификата. Полезные команды: crypto pki trustpoint посмотреть и crypto pki certificate посмотреть. Давайте дальше, SNMP v3. Сделаем небольшой перерыв и пробежимся по SNMP. Давайте поговорим немножечко про SNMP третьей версии. Здесь про SNMP будет всего лишь пару слайдов, мы не будем разбирать очень глубоко этот протокол, поверхностно поговорим. Самое главное, что здесь

мы отметим некоторые штуки, которые касаются безопасности — у нас всё-таки курс по безопасности. Посмотрим, чем отличается он от второй версии, и дальше продолжим. Ключевой компонент SNMP — вы же знаете, SNMP, тоже в какой-то мере это Management Information Base — MIB, в которой будет храниться всё на свете. Доступ осуществляется посредством операций GET request и SET request. На самом деле операций больше, но надо запомнить, что мы можем получить какое-то значение из этой базы либо записать какое-то значение в эту базу. Есть незатребованные сообщения, которые не будет требовать управляющий NMS — Network Management Station — управляющий модуль, а

которые устройство может отправить само: trap, inform. Главное отличие — community string, который раньше во второй версии мы использовали, это, грубо говоря, пароль. В третьей версии заменён на полноценную аутентификацию, авторизацию, плюс в третьей версии добавлено шифрование и аутентификация всей информации, которая передаётся. Нужно знать три уровня безопасности SNMP v3 — те, кто хочет сдавать экзамен, это должны выучить точно. Первый, самый простой уровень — это noAuthNoPriv, где пароли передаются в открытом виде, шифрование отключено. AuthNoPriv — для аутентификации используется хэширование, шифрование отключено. Есть ещё AuthPriv, где хэширование используется для аутентификации и все сообщения

шифруются. Эти три уровня безопасности — основные, их просто нужно запомнить. Хорошо. Пример настройки SNMP — на самом деле настройка SNMP третьей версии очень развесистая, там можно настроить много всего. Надо просто понимать, что в разрезе безопасности мы можем использовать представление. Мы с вами говорили вчера про представление в командном интерпретаторе — CLI view. Похожая концепция есть в SNMP. Мы можем создать представление — view — куда включить только нужные идентификаторы, а потом к этим представлениям давать доступ. Мы можем создать группу и в эту группу включить пользователей, соответственно, и

для этой группы конкретной мы можем сказать: эта группа только к этому представлению имеет доступ. Это очень удобно, потому что раньше во второй версии — кто настраивал, прекрасно знает, — есть community на запись, community на чтение, всё. Особых других ограничений, механизмов такого гранулированного управления доступом не было. Здесь уже поинтереснее: мы можем сделать view, можем там ограничить всё. View создаются таким образом — это просто пример конфигурации. Вы запоминать, я думаю, не нужно. Надо просто знать эти сущности: что создаётся группа, и для группы мы обозначаем привилегии — что в эту view можно писать, к конкретной view. View — это просто

набор идентификаторов. К этой view мы можем предоставить доступ на запись, а к этому набору идентификаторов — их можно читать. Соответственно, можем потом разделить их по группам: будет группа каких-то систем, которым можно опрашивать только состояние портов, к примеру, а другая view — придумаем, там будет состояние, например, туннелей IPsec. Другой группе к этому представлению дать доступ. Здесь можно уже намного интереснее оперировать. А вообще конечно хорошо давать только на чтение, но с другой стороны, есть инсталляции, где по SNMP происходит управление железом. Хотя по поводу писать или не писать — по SNMP вещь интересная, она древняя. По SNMP можно рулить всем,

но это не так удобно. По SNMP можно выключить интерфейс, как Андрей сказал, включить интерфейс, но настраивать по SNMP какой-нибудь новый туннель — это нетривиальная задача. Например, поднять туннель, либо изменить параметры всех туннелей, либо ещё что-то. SNMP прикольно для снятия параметров железа — общее состояние, загрузка процессоров, состояние портов — диагностические такие вещи. А именно записывать — не очень удобно, просто неудобно. Опять же, сейчас нет продуктов, которые этим занимаются. Другого плана системы автоматизации сейчас, вы знаете, всё идёт немножко по другому направлению уже. Есть системы управления

конфигурациями, есть Ansible тот же самый. С помощью него удобнее именно автоматизированно настраивать даже очень большое количество оборудования. А по SNMP это делать — можно, но дело в том, что это прикольно, когда у вас тысяча свичей одной модели — реально одной модели, у них все эти OID-идентификаторы совпадают. Тогда да, можно что-то сделать сразу на все свичи, какую-то одну настройку залить по SNMP. Но дело сложное, просто неудобно. Здесь мы сейчас про третью версию говорим. Надо просто понимать, что здесь управление безопасностью умное, и есть эти view и представления. Через это можно рулить очень многим — такое прям

очень гибкое управление доступом. Юрий правильно сказал — только чтение, и всё, и ничего больше не надо. SNMP сейчас, наверное, уходит в прошлое уже. С появлением программно-определяемых сетей там другие уже механизмы. SNMP — вещь древняя, и для мониторинга использовать — да, нормально. Zabbix — это же вещь, которая читает по SNMP. Zabbix — система мониторинга, да, пожалуйста, чтение. Читать, опять же, Zabbix требует очень большой ручной настройки. Если у вас много разного, разнотипного оборудования, и там же надо создавать эти шаблоны. Если ещё нет этих MIB-ов готовых — тут вообще, короче, если MIB-ов нет, лучше не работать с SNMP.

Для мониторинга — пожалуйста, а для управления железом я бы не советовал. Блокировка доступа с помощью access-листов. Мы возвращаемся опять к access-листам, к теме, которую мы в принципе неплохо знаем. Здесь мы говорим про management-доступ. Мы сейчас всё-таки про доступ к устройству, этот модуль. Мы знаем, что SSH, SNMP v3 — у них есть свои встроенные средства защиты, они умеют всё шифровать, но всё-таки доступ ограничить к ним неплохо бы с помощью access-листов. Access-листы мы можем в плане управления повесить на линию VTY для доступа по SSH. Telnet — мы говорим, что лучше не использовать. То же самое — access-листы можно использовать для

управления доступом по HTTP, SNMP — тоже можно к SNMP прикручивать access-листы, это не так трудно. Конфигурация у нас на экране, я думаю, просто глазками пробежимся. Разбирать её — мы все видели, как вешается на линию: access-class такой-то. На HTTP удобно, и SNMP — в принципе для группы можно сделать access-лист и можно для конкретного пользователя сделать тоже access-лист. SNMP в этом отношении очень классно, очень гибко. Но блин, уже ушло время SNMP, по моему мнению, как-то уже проходит. Усиление паролей. Про пароли мы с вами знаем немало, давайте вспомним некоторые полезные опции. Может быть, вы про них знаете, может быть, и не про все знаете. Мы помним, что

password мы вообще не используем. По-хорошему мы всегда используем secret. Вместо password мы должны использовать обязательно service password-encryption. Мы помним, что эта команда шифрует все пароли, и они будут храниться в виде хэшей. Стоит сказать, что сейчас новые системы делают хэш либо MD5, либо SHA. Тоже более старые системы — у них было своё хэширование, это даже не хэширование, а именно шифрование. Помните, рассказывали вам на сессии про пароли, которые type 7? Type 7 — это не лучше, чем type 5.

Это обратимое, всё правильно, можно расшифровать. Поэтому следите, чтобы пароли такого типа у вас не попадались. Некоторые полезные опции: минимальная длина пароля. Дальше — no service password-recovery. Знаем мы, что это такое, или не знаем? На сессии CCNA совершенно точно рассказывалось. Помните про восстановление пароля? Помните, когда configuration register можно поменять? Помните эту историю? No service password-recovery запрещает это. Она запрещает с помощью configuration register потом восстановить пароль. Это лучше не делать. Это полезная опция, но только когда вы точно уверены, что не забудете пароль, не потеряете.

Login delay — мы с вами, я уже немножечко упомянул. Это настройка, которая будет включать перед каждым набором пароля задержку на указанное количество секунд. Затрудняется попытка подбора пароля, и в сочетании с блокировкой будет всё прекрасно. Есть опция login on-failure — это логирование неудачных попыток ввода пароля. И очень прикольная вещь — это activation character. Activation character. Давайте в консоли покажу про activation character. На самом деле вам неудобно показывать то, что вы не видите мою клавиатуру. Это хороший способ забронировать консоль.

Идём на консоль и говорим: activation-character a. Дальше мы набираем какой-то символ, любой символ, там буква K например, и после этого, если мы выйдем из консоли, то она не будет реагировать вообще ни на что. Я сейчас нажимаю Enter, но консоль не реагирует, пока я не нажму клавишу K — консоль не проснётся. Это очень хороший способ предотвратить несанкционированный доступ к консоли. Брутфорс — да, там всего 128 символов. С другой стороны, она выглядит как не работающая, так что тоже хороший способ.

Используя такой нехитрый способ — способ на самом деле простой — ваша консоль будет чувствовать себя получше, и вы тоже. Про баннеры — короткий рассказ. Баннеры — это предупреждение, которое отражается в процессе работы с устройством. Помните, deterrent — меры противодействия, отпугивающие. Есть три типа баннера: это MOTD, Login и Exec. MOTD — знаете, что такое? Старые UNIX-сисадмины должны знать, как расшифровывается. Андрей — самый бородатый сисадмин. Есть три типа баннеров, мы на Cisco все их пробовали устанавливать. То, что начинается спецсимволом и заканчивается спецсимволом. Важно помнить — я не знаю, спросят ли это на экзамене, но я показал вам здесь, как они выглядят, потому что сам раньше тоже часто путал. Я просто запомнил: MOTD banner — incoming.

Да, я про него смотрел где-то в документации. Эти три — они стандартные, они вообще есть везде. Сначала идёт MOTD, потом Login показывается, а потом уже процесс аутентификации запускается. Exec-баннер — это только для тех, кто прошёл процедуру аутентификации. Про то, что они должны быть, мы с вами говорили, и я также упоминал, что даже иногда они подпадают под требования регулятора, то есть вы обязаны их устанавливать.

Здесь тоже мы довольно кратко разберём, но здесь будут очень серьёзные концепции, которые лучше усвоить сразу и хорошо. Мы с вами с Management Plane пока закончили. Control Plane — это функция аппаратного и программного обеспечения, которая отвечает за управление маршрутизацией. Мы говорили, что это «думалка» — в этой плоскости у нас работает самый главный мозг, который потом уже Data Plane делает — он говорит Data Plane, что и как ему делать. Control Plane — штука достаточно уязвимая, она нуждается в защите обязательно. Есть некоторые механизмы защиты, которые в RFC написаны, но это просто общие рекомендации, для интересующихся можно тоже посмотреть. Самая главная задача защиты Control Plane — это защитить центральный процессор от его

чрезмерной нагрузки, потому что загрузить Control Plane не так сложно — это своеобразная DoS-атака. Соответственно, DoS-атаку на Data Plane устроить сложнее, Data Plane — всё-таки это мощное железо. DoS-атаку на Control Plane, на центральный процессор, организовать не так трудно. И целостность данных маршрутизации — я бы добавил не только данные маршрутизации, а вообще целостность данных, которые будет обрабатывать Control Plane. Но в первую очередь мы говорим про маршрутизацию, потому что всё-таки эта информация будет очень важна, она будет наиболее критична. Первый инструмент — это Control Plane Policing. Я до сих пор, к своему стыду, не запомнил эту аббревиатуру, потому что есть ещё вторая аббревиатура, будет на следующем слайде. Есть CoPP и CPPr — я их постоянно путаю. Я думаю,

что 99 процентов сетевых инженеров их тоже путает, ничего страшного. Но на экзамен, я думаю, стоит это как-то запомнить. Миша тоже путает, их все путают на самом деле. Они кстати с CCNA R&S 2 дают. На самом деле, в новых книжках, но в книге по подготовке к CCIA — точно, CPP там уже называется другой аббревиатурой: CPPr — Control Plane Protection. В этом курсе он CoPP. Короче, просто запоминайте. Это механизм, который ограничит влияние нежелательного трафика на загрузку

процесса маршрутизации. Этот механизм нужен для того, чтобы просто урезать большое количество трафика, который идёт к центральному процессору. Например, сообщения BGP — как вариант, да? ICMP тоже — можно задосить и положить железку, если их отправлять там несколько тысяч в секунду, то наш центральный процессор скажет «я больше не хочу работать» и сделает kernel panic, нулевой уровень severity, syslog — и попрощается со всеми. Так что штука важная. Настраивается он с помощью — это очень интересная вещь, про которую мы будем говорить на курсе не раз —

Modular QoS Framework. Короче, в Cisco есть несколько механизмов, которые будут настраиваться в принципе с помощью похожих инструментов. Это называется Modular QoS Framework. Дальше я сейчас объясню в двух словах, что это такое, потом вы с этим ещё не раз столкнётесь — возненавидите сначала, потом полюбите. Михаил это любит, я тоже это люблю. Это просто способ настройки, он такой модульный, там сначала чёрт ногу сломит, сначала вообще не понятно. Но с помощью него QoS настраивается, с помощью него настраивается Firewall, ACL, с помощью него будет у нас Firewall на роутере настраиваться, опять же с помощью него — короче, куча вещей настраивается в Cisco

с помощью такого механизма. Просто сейчас объясню совсем кратко. Конфигурация будет разбиваться на три вещи. Нет, Роман, не стоит — full Firewall, Zone-Based Firewall. Смотрите, здесь будет три главных элемента конфигурации. Если кто-то не сталкивался, сейчас у вас будет взрываться мозг. Мы будем настраивать таким образом: сначала мы будем создавать так называемый class-map. Class-map — это описание классов трафика. Это не просто access-list, здесь будет штука помощнее, в которой можно много всяких параметров указать. Сейчас я совсем поверхностно это расскажу. Затем мы будем настраивать отдельно так называемый policy-map. Policy-map — это набор действий, которые нужно сделать с этими классами.

Мы можем сказать: class-map HTTP — и сказать, что в этом class-map подпадает TCP 80 порт или 443 — это будет всё относиться к HTTP. А потом мы второй кусок конфигурации делаем, вторая сущность — policy-map, и здесь мы говорим, что если нам встретится какой-то трафик, который подпадает под этот класс HTTP, мы его зарубаем на корню. И третья сущность — service-policy. Это очень просто перепутать с policy-map, но service-policy — это просто указание, куда применить эту самую policy-map. Я думаю, что сейчас вы не успели запутаться, потому что мы сейчас этим заниматься не будем прямо сейчас. Просто надо понимать, что есть такой Modular Framework. Мы это будем «долбить», Андрей, позже, намного позже, когда

будем настраивать ZBF — Zone-Based Firewall. Наверное, завтра к этому подойдём или даже в понедельник, но там будет интересно, и я научу вас этому. Есть ещё один механизм. Ещё раз: Control Plane Policing — это просто такой тупой полисер, тупой ограничитель. Ну, как тупой — можно сказать, он не очень гибкий, просто ограничитель частоты сообщений, например. Есть более гибкий механизм, называется CPPr — Control Plane Protection. Поэтому эти две аббревиатуры — не знаю, запоминайте как-нибудь. Он выполняет те же самые функции, что и Control Plane Policing, но Control Plane Policing применяется ко

всему трафику, который идёт на Control Plane, вообще ко всему. А этот механизм CPPr позволяет с разным трафиком работать по-разному. Вы же знаете, что на Control Plane идёт несколько типов трафика, не только протоколы динамической маршрутизации, да, ещё какой-то трафик. И сейчас я расскажу, как это сделано. Есть такие виртуальные sub-интерфейсы, реально sub-интерфейсы, которые вообще виртуальные. Представьте, что Control Plane — это внутри вашего роутера стоит ещё компьютер какой-то. Центральный процессор представляется компьютером, у этого компьютера есть три интерфейса. Сейчас на следующем слайде будут примеры. Есть такие три виртуальных интерфейса, сейчас я покажу. Для

настройки тот же MQC используется. Смотрите, эти самые sub-интерфейсы — есть три виртуальных интерфейса, их можно найти в конфигурации и с ними можно работать, на них можно вешать правила. Но это, к сожалению, выходит за рамки нашего курса, потому что мы закопаться в этом можем очень надолго. Просто надо знать, что есть такие виртуальные интерфейсы внутри вашего маршрутизатора. Смотрите, весь трафик, который идёт к роутеру — например, SSH-туннель, который у нас на Layer 3 терминирован, или GRE-туннель, скажем, или IPsec-туннель, SNMP к роутеру — весь этот трафик он будет направляться в Host-интерфейс. Мы можем в принципе с этим типом трафика — смотрите сюда на схему — мы теоретически можем на этот интерфейс

повесить access-list и зарубить вообще весь SSH, весь management-трафик. Такой трафик есть. Не смотрите — GRE-туннель, да. Теперь Transit-интерфейс — туннель, проходящий через роутер, это трафик, который, например, когда мы IPsec будем настраивать — по crypto map, по crypto map это трафик транзитный. Например, мы на нашем роутере из интернета в нашу внутреннюю сеть через туннель идёт. Бывает же такое? Конечно бывает. Или там site-to-site туннель — это не к нашему роутеру трафик, мы его не обрабатываем, его не посылаем на центральный процессор, это просто трафик транзитный, но мы с ним должны что-то делать.

Нет, не пользовательский. Туннель — давайте я нарисую. Всё, Игорь, до завтра — запись будете завтра смотреть. Здесь имеется в виду: мы поставили site-to-site туннель обычный, который будет проходить через наш роутер в нашу внутреннюю сеть. Ну или даже пользовательский — это какой-то транзитный трафик, а туннель, который... Ссылочку у Иннокентия спрашивайте в чатике, ну или там у него лично, я отправлюсь ему, а он будет выкладывать дальше. Трафик, который не подпадает под CEF — все же знают, правда? Трафик, который под CEF не попадает, он тоже будет через этот виртуальный интерфейс якобы

проходить. Это — понимаете — это не интерфейсы, которые мы настраиваем в конфигурации, просто интерфейсы Control Plane — такие немножечко сложные сущности. И есть ещё такой CEF-exception интерфейс. CEF когда посылает какие-то... Помните, как CEF работает? Он ускоряет маршрутизацию трафика. Туннель через роутер — давайте рисовать. Сейчас ещё раз рисуем: это наш роутер, это наша внутренняя сеть, это там какая-то удалённая сеть, это у нас туннель. Если, например, туннель будет использоваться — здесь другой роутер — этот туннель, например, нужен для

OSPF. OSPF-трафик направляется самому роутеру, не куда-то там ещё, а к самому роутеру. В таком случае он будет подпадать под этот sub-интерфейс. А если же по этому туннелю у нас движется трафик просто через роутер в нашу внутреннюю сеть таким образом, то этот трафик будет подпадать под этот виртуальный интерфейс — Transit-интерфейс. Он будет не совсем Data Plane, он, конечно, Data Plane, но дело в том, что он тоже должен обрабатываться роутером — например, IPsec расшифровывать, зашифровывать. Сейчас... Но я, по-моему, сказал вам правильно. Так, Иннокентий дал ссылку на

пустую папку. Давайте теперь немножечко сменим тему — про аутентификацию протоколов маршрутизации. Протоколы маршрутизации вам знакомы хорошо, и почти все они имеют возможность каким-то образом свой трафик защитить. Они все умеют делать аутентификацию. Мы помним с вами, что это не шифрование — шифровать трафик мы не можем. Андрей, по поводу RIP — хороший вопрос. Он не умеет, просто потому что там не устанавливается соседство. Хотя — я соврал, что не умеет — он тоже умеет аутентификацию. Поэтому будем говорить, что

все протоколы умеют каким-то образом проверять достоверность peer-а и информации. Это исключает неавторизованное обновление маршрутной информации. Это очень здорово, что мы можем быть уверены в протоколе маршрутизации, что мы получили апдейты от кого-то, кого мы знаем. Как правило, это настраивается на интерфейсах — если говорить про настройку, то не в процессе маршрутизации, а на интерфейсе, конечно же, для каждой пары маршрутизаторов, потому что ключи-то у них должны быть общие. Шифрование это не обеспечивает — это аутентификация, это просто подпись пакетов. То же самое, как мы с вами пару часов назад смотрели в NTP — здесь будет абсолютно та же штука, сейчас на картинках посмотрим. Основывается на общем ключе — ничего сложного там нет. У нас здесь не будет опять никаких приватных-публичных ключей, просто общий

ключ — взяли, хэшик прилепили к сообщению, отправили. Очень часто для аутентификации используют связки ключей. Кто не знаком с keychain-ами — поднимите, пожалуйста, руки. На сессии этого быть не должно. Это очень классная штука. Смотрите, можем по-разному настраивать аутентификацию в протоколах: можем использовать просто пароль, а можем использовать для этого так называемую связку ключей, то есть набор каких-то уже ключей предопределённых. Чем это здорово — мы можем проводить смену ключа без разрыва связи. Представьте, что у каждого роутера есть этот keychain — связка ключей: там ключ один, ключ два, ключ три. У каждого — ключ один, ключ два, ключ три. И написано, что в понедельник работает

ключ один, во вторник работает ключ два, а в среду работает ключ три. И эти роутеры по времени будут пользоваться разными ключами. Это достаточно полезная штука. Мы с вами говорили, что ключи периодически неплохо бы менять — не пароль, а ключи. И именно с помощью этих keychain-ов не нужно перенастраивать роутер, процесс маршрутизации не надо трогать, на интерфейсе менять ничего не надо, никакие парольные фразы — просто в связку ключей добавили новый ключ, прописали, когда он будет действовать — можно не обязательно прописывать — можно старый, чтобы он всё время работал. А потом старый удалили. Очень гибкий механизм, очень классный. С keychain-ами давайте сейчас поподробнее. Может быть, даже лабу — давайте, может быть, завтра начнём. А сейчас я всё расскажу про них. Это объект в операционной

системе — этот keychain, в котором мы будем хранить ключи. Очень удобно тем, что эти ключи можно использовать в нескольких местах. Мы можем одну связку ключей создать в операционной системе, а потом, например, тот же RIP и EIGRP будут брать оттуда ключи — одни и те же. Чтобы там не делать развесистую клюкву такую: для RIP-а — такие ключи, для этого — такие, для BGP — такие. А для BGP, я не уверен, что BGP в этой реализации умеет со связкой ключей работать — Иннокентий может нам подскажет. Скорее всего нет, не будем. Окей. Важно помнить, что каждый ключ в этой связке имеет свой номер — это важно, потому что этот номер ключа будет передаваться вместе с обновлениями. Процесс OSPF, когда будет посылать свой какой-то апдейт соседу, он будет подписывать его с помощью ключа, и в этом апдейте

будет написано, что он подписан с помощью ключа номер, там, 25. Это важно помнить. Ключ можно, как я говорил, делать бессрочным — он будет всегда действовать — либо срок действия ему назначить. Если назначать срок действия, можно как раз делать прозрачную смену этих ключей: добавить новый ключик, а потом удалить старые ключи — и разрыв соединения никакой не произойдёт, всё будет подписываться, всё хорошо. Иногда для каждого ключа можно там алгоритм хэширования разный задавать: эти ключи с таким алгоритмом, эти ключи с таким. Но можно оставить всё по дефолту. Как всё это настраивается — так, сейчас проверим. Keychain и OSPF — насколько это... А про OSPF и EIGRP — давайте настроим. Тогда лабораторную работу отложим

на завтра, и завтра на свежую голову я покажу вам, как эти связки ключей работают. Поднимем EIGRP или OSPF и там сделаем аутентификацию — это будет прикольно. Всё, тогда на сегодня всё.