Безопасность в сетях Cisco (продолжение)

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

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

если вы не покажете логин. На консоли изначально из коробки вы получаете доступ к линии управления бесплатно, и вы переходите в enable бесплатно. Для того чтобы злоумышленник, который всё-таки может гипотетически получить доступ к консольному порту, не получил привилегированный доступ внезапно к вашему устройству, есть смысл включать логины пароля. Соответственно, сделаем так, чтобы парольную защиту на линиях управления наша система активировала. Чтобы тот, кто получает доступ к консольному порту, не мог получить доступ даже к пользовательскому режиму, чтобы у него спрашивали логин и пароль. И отдельно назначается пароль на переход в привилегированный режим. Это парольный enable. Если мы говорим про VTI, про виртуальную линию управления, то можно дополнительно ограничить IP-адреса, с которых можно подключаться к самой линии управления. И в качестве бонуса настраиваем баннеры.

Это тот текст, который Cisco выводит при попытке подключиться к ней издалека. Начинаем мы с парольной защиты на консоль. Самый простой способ, каким можно защитить консольку Cisco, это повесить на нее просто пароль без логина. Вы подключаетесь, система говорит: «Привет, скажи пароль и проходи». И вы говорите пароль и проходите. Вас не спрашивают, кто вы, вас спрашивают только пароль. И на картинке как раз пример того, как это происходит. Так. Когда вы подключаетесь к устройству, на котором настроена парольная защита, система показывает вам приглашение к вводу. На экране показывается, что роутер доступен, нажмите Enter для того, чтобы начать работать. Когда вы нажимаете Enter, система говорит, что у нас включена проверка на пользователя, спрашивает просто пароль, без ничего. Вы здесь вводите какой-то пароль, он не отображается. Здесь на картинке нарисованы звездочки.

На самом деле звездочки не показываются. Как будто вы что-то пишете, но это не срабатывает. На самом деле всё срабатывает. Нажимаете Enter и проваливаетесь в пользовательский режим. Для того чтобы эту штуку включить, нужно сделать два действия. Первое действие — нужно сказать, что если кто-то вводит пароль, то этот пароль должен быть определенный. Делается это в настройках линии управления. В нашем случае мы делаем это на консоли, line con 0, мы переходим в настройку консоли на линию управления CTI. И затем мы указываем команду password и дальше просто какой-то пароль, cisco. Понятно, здесь можно сделать password какой-нибудь другой пароль. Но какой вы хотите, такой сделайте. И затем эта команда, которую вы вводите, password cisco, она делает следующее. Она говорит, что если кто-то показывает пароль,

то этот пароль обязан совпадать со словом cisco. Если же вы ввели эту команду, эта команда не говорит, что пароль проверять надо. Поэтому если вы не сделаете следующую, вторую команду, ничего не будет происходить. Если пользователь будет пытаться вводить пароль, этот пароль будет совпадать с cisco, его пропустят. Но если он подключается, и второй команды, login, нету, то система просто у него не будет спрашивать пароль. Да, если бы она спросила, пароль требовалось бы, чтобы совпадал со словом cisco. Но вторая команда требует ввод пароля. Система не позволит вам ввести эти команды в обратном порядке, потому что это будет небезопасно. Если вы сначала введете команду login, «скажи пароль, и только после этого ты сможешь попасть в привилегированный режим», и дальше, если вы не указали password cisco, то система не поймет, какой пароль надо у вас проверять. У нее будет указание login, что пароль проверять надо, но с чем сравнивать то, что будет пользователь вводить,

не будет присутствовать в конфиге, поэтому если вы введете просто login, вы перестанете попадать в консоль. Для того чтобы этого не происходило, эти команды вы обязаны вводить в правильном порядке. Если вы попытаетесь их ввести в порядке сначала login, а потом password, то система вам выдаст ошибку, и команду login просто не примет. Сначала password, потом login. Этот механизм довольно простой, и у него есть фундаментальный недостаток. Все, кто имеет доступ к консоли, гипотетически, они все должны знать этот самый пароль. И пароль будет на всех всего один. Тот самый общий пароль. Если же вы хотите сделать так, чтобы у вас разные пользователи получали разные пароли, чтобы можно было, допустим, 10 разных айтишников иметь в компании, и 10 разным айтишникам давать разные доступы, то в этом случае вы должны будете использовать более продвинутый, более изощренный механизм, где будут использоваться и логины, и пароли.

Смысл заключается в том, чтобы не давать всем один и тот же пароль, а давать каждому индивидуальную пару логин и пароль, и с помощью этой индивидуальной пары пользователь сможет заходить на устройство. И дальше, если нам не понравится, как работает конкретный пользователь, мы можем взять и отключить его пару логин и пароль, и тем самым отобрать у него доступ. С одинаковым паролем для всех вы такое сделать не можете. То есть сделать можете, конечно. У вас был раньше пароль cisco, а вы, допустим, меняете его на cisco1. Можно так сделать. Но вы должны будете всех пользователей, которые пользовались старым паролем, предупредить и сказать, что, ребята, у нас теперь новый пароль cisco1. Это неудобно. Если мы будем использовать пары логин и пароль, то тогда у нас получится, что каждый имеет свою собственную пару, и мы можем к каким-то устройствам выдавать доступ каким-то конкретным пользователям, и пользователей мы можем включать, выключать по своему усмотрению. Для того чтобы это сделать, нам потребуется

какая-то база пользователей на железке, которая бы хранила пары логин и пароль. И в Cisco это делается с помощью команды username. Мы указываем, что у нас есть username. Дальше даем название юзеру. Здесь конкретно используется слово cisco. По умолчанию из коробки, кстати, пароль cisco/cisco на многие железки. И дальше используем конструкцию password cisco. Мы создали пользователя cisco с паролем cisco. Дальше мы переходим в линию управления консоли, и указываем слово login local. Что означает login local по сравнению с предыдущим вариантом, где у нас был password и login? Password задавал пароль, а login без параметров говорил, что надо требовать только пароль и проверять его с тем, что написано в password. Здесь у нас указывается login local. И в отличие от просто login, мы не требуем просто пароль.

Мы требуем пару логин и пароль и проверяем ее по локальной базе пользователей. Слово local обозначает, что мы проверяем по локальной базе пользователей пару вводимых логина и пароля. И после того, как пользователь получает приглашение к вводу, у нас опять показывается, что роутер готов к подключению, мы нажимаем Enter. Система говорит, окей, проверяем тебя как пользователя. Спрашивается уже и username, и password. Мы вводим логин и пароль, нажимаем Enter и проваливаемся в пользовательский режим. Обратите внимание, здесь нету каких-то уровней доступа или чего-то еще. Любой пользователь, которого вы заведете в локальной базе пользователей, здесь покатит. Главное, чтобы он просто был. Вы можете создать любого пользователя, какого захотите. Хотите сделать пользователя admin.

Хотите сделать пользователя root. Они все будут пользователями, и они все получат доступ к пользовательскому режиму. Дальше. Точно такой же механизм вы можете сделать на линии управления, к которой будете подключаться издалека, например, по телнету. Для того чтобы настраивать линию управления, у нас есть конструкция line VTI. Если вы захотите, вы можете отдельные все виртуальные линии управления настраивать независимо. В случае с консолью, возвращаясь на предыдущий слайд, у нас была консолька с номером 0. Роутер или switch выглядит так, что у него всего одна консолька, на ней написано console. И это будет линия управления с номером 0. Con 0. Но виртуальных линий управления у нас много. Если есть роутер, и у него есть один консольный порт, то виртуальных линий управления у роутера много-много-много. Они все невидимы, потому что они виртуальны.

Соответственно, их в зависимости от конкретной платформы может быть либо 5 штук, либо 16 штук, либо 925 штук, либо много. И каждую отдельную линию управления вы можете настроить точно таким же образом. Можете создать username, password в локальной базе пользователей. И дальше вы можете указать login local в настройке линии управления. Line VTI 0, line VTI 1, line VTI 2, и дальше перебирайте их все по одной. Но если у вас их действительно много, 925 штук, то неудобно по одной штуке настраивать каждую линию управления. Их намного удобнее настраивать пачкой. Соответственно, вы указываете line VTI, дальше пишете 0, это первый номер в пачке, потом пробел, и дальше вы указываете последний номер в пачке. И очень удобно для того, чтобы все одновременно линии управления настроить однотипно, это типовая задача, чаще всего так и нужно делать. Вы указываете line VTI 0,

дальше вопросик, и система говорит, какое допустимое число будет являться последним номером в пачке VTI. В нашем случае мы видим, что если мы указываем диапазон, то самое маленькое значение для диапазона будет линия номер 1, а самое большое значение для диапазона будет 924. Если мы укажем line VTI 0 924, то мы проваливаемся в контекст настройки всех линий управления одновременно, мы указываем login local. Любой, кто подключается по любой из этих VTI, должен показать логин и пароль, и эти логин и пароль будут проверяться по локальной базе пользователей. Вот у нас пример того, как это происходит. Мы с некоторого свитча подключаемся по телнету на некий IP-адрес, 172.31.2.0. И мы видим, что подключение установилось, система говорит, скажи пароль и проходи. Username cisco, password cisco. Мы попадаем на роутер.

Рекомендуется делать именно так. Не рекомендуется делать просто пароль на консоль, рекомендуется делать именно логин и пароли и каждому отдельному пользователю выдавать отдельную пару логин и пароль. Естественно, что если у вас прямо много администраторов, то не очень удобно на всех железках иметь прописанные эти самые логины и пароли, потому что если у вас 10 администраторов и, допустим, 10 железок, это значит, что на каждой железке вам нужно 10 раз прописать отдельную учетку каждого администратора. Это всего 100 операций. Если у вас кто-то новый нанимается, то вам надо на 10 железок зайти и прописать этого нового пользователя на каждой железке отдельно. Если у вас кто-то увольняется, надо на 10 железок зайти и удалить учетку того, кто увольняется. Гипотетически это реализуемо, практически это не очень удобно. Количество административных задач будет довольно неприятное. Поэтому в реальности чаще всего

всё это дело будет сочетаться с каким-то механизмом централизованного управления. У вас есть некая централизованная база пользователей. И дальше по протоколу Radius ваш роутер будет подключаться и спрашивать, можно ли аутентифицировать такого-то пользователя с таким-то логином и паролем. Пользователь всё равно показывает свой username и password, но дальше они проверяются не по локальной базе пользователей, как здесь, login local, а по Radius обращаются на некий внешний сервер. А он уже знает, у кого какой пароль. Мы ему этот логин и пароль показываем. Он говорит, да, этот логин и пароль действительно работают, действительно можно пустить пользователя в сеть. Понятное дело, что если у вас 10 или 20 или 50 или 100 железок, то это намного удобнее, потому что если у вас появляется новый юзер, вы его записываете на Radius-сервере и даёте ему право подключаться к железкам. Любая из ваших 50–100 железок

подключается к Radius, спрашивает, можно ли Васю пустить в консольку. И Radius говорит, да, можно, если у него логин и пароль правильный, а судя по тому, что ты показываешь, пароль правильный, то Вася имеет право доступа к консольке. Если Вася увольняется, и он пытается подключиться к тем же самым железкам со своим логином и паролем, который ещё вчера работал, Radius говорит, извините, Вася уволен, поэтому его логин и пароль больше не работают. Как правило, это в предприятиях сочетается с Active Directory. У вас есть локальная база пользователей Active Directory, и Radius-сервер консультируется с базой AD. Если в AD у вас пользователь есть, и он в какой-то определённой группе, то Radius говорит, да, можно. Если в AD либо пользователя такого нету, либо пароль у него не такой, либо в соответствующей группе вы его не ввели, то Radius даёт отлог. Наш курс не предусматривает настройку Radius, потому что

эта операция достаточно трудная и требует некоторого количества дополнительных знаний. Но в рамках нашего курса и в рамках экзамена от вас будет проверяться умение настраивать локальные политики, эти самые локальные базы пользователей, и локально требовать проверку имени пользователя и пароля, проверки их по локальной же базе. Так, дальше. Если вы работаете с виртуальными линиями управления, то есть теми, которые используются для удалённого доступа, то по умолчанию на старых IOS, которые 15.1 и раньше, все протоколы управления, которые поддерживаются железкой, включены для этих линий управления. То есть у вас есть роутер. У него есть Telnet, SSH, какой-нибудь удалённый R-логин, какой-нибудь LAT, то есть старые древние протоколы, и вы по любому из этих протоколов можете подключаться и получать доступ к вашей железке, как только вы повесили туда login

или login local или что-то ещё. Никаких специальных действий на старых IOS'ах не нужно делать для того, чтобы включить отдельно какой-то конкретный протокол. Чаще всего, напротив, на старых IOS'ах надо было выключать ненужные вам протоколы, то есть вы должны были сказать, что у нас Telnet, допустим, может использоваться, SSH может использоваться, а R-логин не может, хотя он поддерживается, но нам он не нравится. Мы его выключали. На новых IOS'ах поведение по умолчанию изменилось с 15.2. По умолчанию поведение такое, что все протоколы выключены, и вы должны в явном виде включать то, что вы хотите использовать. Это более разумное, более безопасное, конечно, поведение, но обязательно требует дополнительную строчку, которая на старых IOS'ах не требовалась. Это была хорошая идея, если вы выключали какие-то протоколы, но это всё-таки было опционально. На новых IOS'ах вы должны прям в явном виде включить то, что вы хотите. Команда будет, опять же,

в настройке линии управления, transport input, и дальше вы указываете через пробел те протоколы, которые вы хотите включить для конкретных линий управления. В реальности, да, либо Telnet, либо SSH, либо оба сразу. Больше ничего наверное, не понадобится. Ещё одна штука, которую хорошо бы делать на линиях управления. Указать, с каких адресов разрешено подключаться. Смысл заключается в том, что если у вас есть роутер, который находится на границе между интернетом и локальной сетью, то вы должны будете сказать, что отсюда подключаться можно, а отсюда подключаться нельзя. И вы должны будете создать access-лист и повесить этот access-лист на вашу линию управления. Если подключение идёт из внутренней сети, то пакеты, которые будут идти из внутренней сети, будут удовлетворять этому самому access-листу, а пакеты, которые пойдут из интернета, они удовлетворять этому access-листу не будут. На них будет выноситься вердикт deny. И получить доступ к линии управления из внешних сетей не получится.

Так. Если вы настраиваете не все линии управления одинаково, вы можете это сделать. Если у вас линий управления много, например, как на слайде, у нас 925 линий управления с нулевой по 924, вы можете сказать, чаще всего мы пользуемся SSH. И по SSH можно подключаться откуда угодно. А Telnet мы тоже говорим, что он тоже разрешён, но подключаться по Telnet можно только изнутри сети. В этом случае никаких проблем. Вы можете сказать, окей, мы выделяем первые 25 линий управления с нулевой по 24-ю. И говорим transport input telnet без SSH. И на линии управления с нулевой по 24-ю подключиться можно только по Telnet. И вы на этих линиях управления вешаете указание, что IP-шники, с которых можно подключаться, это только локальная сеть. А дальше все остальные линии управления, вы делаете отдельную пачку, указываете line VTY 25 924.

Вы говорите transport input SSH и вешаете тоже команду access-class, но уже с другим access-листом, который будет разрешать подключение откуда угодно, в том числе и снаружи. Так что вы можете на разных линиях управления давать разные команды transport input, можете давать разные настройки, можете вешать разные ограничения на IP-адреса. В любом случае вы получите ровно то, что настроили. И если у вас есть отдельная линия управления для Telnet, отдельная линия управления для SSH, то система подберёт такую свободную линию управления, которую можно использовать для вашей задачи. Если идёт подключение по Telnet, это подключение получит одну свободную линию, которая для Telnet используется. Если вы подключаетесь по SSH, вы получите свободную линию управления, на которой разрешён SSH. Если вы вообще в конфиге ничего не упоминаете, то они всё равно есть, эти записи в конфиге. И поведение по умолчанию

в 15-м IOS, что все линии управления не поддерживают никакие протоколы управления. Поэтому по умолчанию никакую линию управления вы использовать просто не сможете. Если вы скажете, окей, мы настраиваем только с нулевой по 24-ю, а остальные 900 штук мы не настраиваем никак, то на 900 штук вы подключиться не сможете, потому что по умолчанию на них всё выключено, а на первых 25 сможете с теми конфигами, которые вы задали. Далее. Что касается ограничения по IP-адресам. Для ограничения доступа к VTY-кам хорошо подходят стандартные access-листы. Подходят. Почему стандартные access-листы? Почему нет смысла использовать, например, расширенные? Потому что вы и так знаете, какие протоколы вы используете. У всех подключений на вашу VTY-ку

будут одни и те же номера портов, к примеру. И поле протокол тоже будет всегда предсказуемое. И IP-шник назначения, который вы тоже можете гипотетически анализировать, тоже чаще всего будет предсказуемым. Это будет ваш собственный IP-шник. Единственное, чем будут отличаться пакеты, которые приходят на вашу систему, содержащие в себе трафик этих самых протоколов управления, это IP-шниками источника. А стандартные access-листы как раз ничего, кроме разбора IP-шников источника, и не умеют делать. Поэтому прекрасно подходят стандартные access-листы в том смысле, что нет смысла заморачиваться с расширенными access-листами, учитывая, что всё то, что расширенный access-лист может проверять по сравнению со стандартным, здесь не понадобится. И вот access-лист. Можно сделать именованный access-лист, можно нумерованный. На некоторых системах требуются только нумерованные. И дальше, номер 23, например, по номеру порта Telnet. Мы указываем, что подключаться можно только из сетей 192.168.17.0 по 24-й маске.

Обратите внимание, это штука с перевёрнутой маской, то есть где нули стоят, мы требуем совпадения, где единички, мы не требуем совпадения. Мы требуем совпадения у IP-шников источника в первых трёх октетах, 192.168.17. В четвёртом октете может быть что угодно. И дальше этот access-лист мы приклеиваем к линиям управления. На всех линиях управления, которые здесь есть, с нулевой по 924, мы указываем команду access-class. Дальше номер или имя access-листа. И вот это in — это направление, в котором мы вешаем access-лист. Смысл заключается вот в чём для этого направления. Если у нас есть роутер, к этому роутеру, ну или к свитчу на самом деле, можно либо подключаться издалека для цели удалённого управления, и тогда под это дело выделяется эта самая VTY. Или можно с этой железки осуществлять подключение куда-нибудь. Например, вы по Telnet пытаетесь с роутера

подключиться на какой-то другой роутер или на свитч, и под это дело тоже выделяется VTY. Из того же самого пула VTY, их всего ограниченное количество, и они и на вход, и на выход работают. Если вы подключаетесь к своей железке, то вам выделяется VTY на вход. Если вы подключаетесь со своей железки куда-нибудь, то вам выделяется VTY на выход. И когда вы указываете, что кто-то с определёнными IP-шниками может к вам подключаться, то вы должны повесить как раз access-class или ограничение IP-шников на вход. Что те, кто подключаются к вам, они получают ограничение на IP-адреса источника. Если вдруг вы захотите указать, что ваша система может по телнету подключаться только к определенным IP-шникам по телнету, то вы можете там на выход поставить, но в реальности, как вы понимаете, это не используется никогда. Вот на access-class чего-то там in — это то, что в реальности используется и на экзамене проверяться будет.

Так. Далее. Что здесь еще хотелось бы заметить? Ага-га-га-га. Так, да. Команда имеет синтаксис access-class, и это меня немножко раздражало всегда, потому что нам нужно запомнить отдельную команду, которая создает access-list. Она так и называется access-list. Отдельная команда, которая вешается на VTI-ку — это access-class. Есть еще access-group, которая вешает access-list на интерфейс. То есть три разные команды — access-list, access-class и access-group. Это невозможно понять, и надо запомнить. То есть перед экзаменом это просто надо зазубрить, какая команда где используется, что делает. Далее. Если мы хотим использовать телнет, то для телнета достаточно, в общем, базовые действия сделать. Это сказать на удаленную линию управления, что мы хотим использовать либо проверку просто пароля, либо проверку логина и пароля

по локальной базе пользователей и включить сам телнет, если у нас свежий юз. Для телнета этого достаточно. То есть уже сразу можно подключаться по IP-шнику железки, и телнет будет работать. Если вы хотите использовать SSH, это Secure Shell, то есть тот же самый телнет, по сути, только шифрованный, вам потребуется задействованная подсистема шифрования. Не на любых цисках подсистема шифрования имеется. То есть в зависимости от конкретной вашей циски, в зависимости от конкретного артикула у вашей железки, от конкретного EOS, может быть такое, что шифрования на вашей циске просто не будет. Если говорить про артикулы самих устройств, вот на конце полного артикула, когда вы там, не знаю, в пресс-листе смотрите, условно говоря, циски, они будут называться там циска 8.8.1-к9 или тире К8, или там, допустим, еще бывает НПЕ. Вот этот вот К9 означает поддержку сильного шифрования,

К8 означает поддержку слабого шифрования, то есть она какое-то шифрование умеет, но тяжелое шифрование, на которое накладывается ограничение на экспорт, она, соответственно, не поддерживает. И НПЕ обозначает, соответственно, no pay load encryption, что вы не можете шифровать пользовательские данные, но вы можете для цели управления трафик самой железки шифровать. И еще бывают артикулы, в которых вообще нету никаких вот этих вот букв, К9, К8, НПЕ, вообще ничего нету, просто там С8, 8, 1, и все, сразу символ, как называется, равенства, означающий конец артикула. Вот если вы видите такую артикул, то там вообще никакого шифрования нету, даже для целей управления. И вы в таких железках SSH включить в принципе не сможете. То есть там не поддерживается никакое шифрование, даже самое простенькое. Но вот если вы видите К9, К8 или НПЕ, то вы можете задействовать подсистему шифрования для цели управления вашей железкой.

И, соответственно, вы должны будете проверить, что у вас и на самой железке поддерживается все это дело, и сам ИОС, который прошит на железку, он тоже поддерживает шифрование. Secure Shell использует алгоритм RSA, который предлагает, соответственно, шифрование передаваемых данных. И для того, чтобы Secure Shell использовать, нам потребуется ключевая пара. Ключевая пара состоит из открытого и закрытого ключа. Они называются так, потому что открытый ключ, вы его можете показывать кому угодно, а закрытый ключ вы никому не показываете никогда, ни при каких обстоятельствах. Он потому и называется закрытый, что только вы его знаете. Ну, как ваша железка. Зачастую его даже из этой железки нельзя извлечь. Все, что шифруется одним ключом, можно расшифровать только другим. То есть если вдруг какие-то данные расшифрованы открытым ключом из ключевой пары, то только закрытый ключ из этой же ключевой пары

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

и, соответственно, для того, чтобы вторую версию заказать, чтобы мы, во-первых, могли использовать и логин, и пароль, потому что SSH первая версия не позволяет, точнее, позволяет подключаться без указания логина. И, соответственно, у SSH второй версии более стойкий крипталгоритм, более длинные ключи по умолчанию. Вот если мы используем SSH второй версии, то мы должны будем сгенерировать ключ, который будет длиной как минимум 768 битв. И команда по генерации ключевой пары, она работает тогда, когда вы указали несколько параметров для нее. То есть, ну, понятное дело, размер ключа, и плюс ключевая пара, она генерируется на так называемое доменное имя. То есть у вас предварительно перед генерацией ключа нужно будет еще задать fully qualified domain name, полностью квалифицированное доменное имя. И делается это следующими командами. Первая команда, вы указываете хостнейм для железки, мы ее уже знаем. Вторая команда, вы указываете доменное имя.

Команда это будет IP, доменное имя, и дальше какая-то там вот команда, ну, какой-то параметр. В принципе, по большому счету, вот этот вот самый IP, доменное имя в реальных сценариях играет довольно мало роли, довольно маленькую роль. Он единственный, зачем нужен, это вот как раз генерация ключевой пары. И по большому счету, если вы делаете это для какой-то небольшой компании, то вы можете писать там любую билиберду. Но, соответственно, это будет, да, являться частью вашего полного доменного имя. То есть в нашем случае полное доменное имя у нас будет cisco-router.networkeducation.ru Рекомендую вам не писать в доменном имени какую-то прям откровенную пургу, хотя это технически и можно. Но лучше будет, если вы там все-таки укажете либо ваш, не знаю, купленный домен, либо что-то еще, просто потому что это красиво. Если вдруг вы потом будете когда-нибудь

использовать ваши cisco с инфраструктурой открытых ключей, то вот на эту вот ключевую пару у вас будет выписываться сертификат. Ну и понятно, что если вы скажете, что ваш роутер зовут, не знаю, mainrouter.microsoft.com, то выписать сертификат на это имя вам будет довольно тяжело. Вот. Ну и после того, да, когда у вас есть полностью указанное домен имя fqdn, fully qualified domain name, вы можете сгенерировать ключевую пару. Вы указываете crypto key. Эта команда может у вас отсутствовать, если у вас нету шифрования на железке. То есть тогда у вас просто контекста крипты не будет. Но если есть crypto key generate RSA, вы указываете, что ключи вы будете использовать для как раз алгоритма RSA. И указываете, что ключи вам нужны общего назначения. Размер ключа должен быть 1024 бита. Можно 1024, можно 768, можно 2048. Размер ключа по большому счету

не сильно на что-то влияет. Дело в том, что чем больше ключ, тем меньше вероятность того, что ваше взаимодействие с помощью этого открытого ключа будут взламывать бродфорсом. Но даже, честно говоря, на 768 битах бродфорсом RSA сегодня взломать довольно тяжело. То есть может быть это, конечно, и возможно, но это требует какого-то катастрофического объема вычислительных ресурсов, и смысла в этом особого нет. Намного больше результата даст простейший терморектальный криптоанализ, когда к администратору приходят такие квадратные люди и говорят, ну смотри, у тебя есть выбор. Либо ты знакомишься с вот этим вот паяльником, либо ты просто нам говоришь, какой у тебя пароль, и мы тебе даже за это какую-нибудь маленькую денежку дадим, чтобы ты не расстраивался очень сильно. Вот, поэтому, да, даже 768 бит будет достаточно для того, чтобы защитить вас от хулиганов, которые просто снифают трафик. А больше смысла особого делать и нет.

Чем длиннее ключ вы будете генерить, тем дольше это будет длиться. Ну и, соответственно, тем медленнее у вас все это будет работать. На реальных железках, соответственно, ключи, которые требуются указывать по стандарту, ну, там, 2-килобитные ключи, 4-килобитные ключи, они генерятся действительно довольно долго. Так, дальше. После того, как вы сгенерировали ключ, у вас пробегает сообщение. Вот такое вот интересное сообщение. SSH включился. Вот он включился. И показывает версию, на которой включился SSH. Cisco показывает 1.99. Это намекает на то, что это почти двоечка, но не совсем. И действительно, версия 1.99 – это версия фирменная, цисковская, то есть это проприетарная версия SSH, которая позволяет реализовывать все те фичи, которые предусмотрены в версии 2.0, но, тем не менее, все фичи, которые есть в 1.0, тоже, соответственно, поддерживает. То есть это и первая, и вторая версия одновременно.

Вот нас, когда SSH будет интересовать, нас будет интересовать как раз и вторая версия именно тем, чтобы отказаться от того, что есть в первой версии. Поэтому мы в явном виде ее переключаем, указываем IP SSH версии 2. Нас будет интересовать. И вот этого вот всего должно быть достаточно для того, чтобы SSH у нас корректно работал. Если вдруг мы захотим подключиться к удаленной железке с SSH, то, соответственно, мы указываем SSH, дальше указываем логин. Вот минус L циск – это логин. И можем указать fully qualified domain name, если у нас в DNS оно резолвится, можем указать IP-шник. Вот. Ну, то есть что хотим, то и указываем. Система скажет, давай пароль. Мы говорим der пароль и попадаем в пользовательский режим. То есть вот такая вот штука, она позволяет с использованием шифрования получить доступ к удаленной командной строке. Естественно, что если вы подключаетесь к своим устройствам издалека через интернет,

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

и показывается, что роутер на терминальной линии кон 0 ожидает от нас, принимает подключение, согласен подключаться к нам и предлагает нажать Enter для того, чтобы начать работу. В то же время, если я сейчас нажму Enter, то система просто переходит в пользовательский режим. Эта штука работает так только на консольном порту. Она не работает так просто на телнете, например. На телнете, если вы попытаетесь подключиться телнетом к железке, на которой линия VTI не настроена, система не пустит вас в пользовательский режим. Для того, чтобы на консоли мы все-таки спрашивали логин-пароль, нам нужно, как вы уже знаете, настроить эту самую линию кон 0. Для того, чтобы это сделать, мы переходим в привилегированный режим, затем Configure Terminal, и затем LineCon 0.

Мы настраиваем линию управления, консоль, и в этой линии управления можно сделать очень много всякого разного. Но нас интересуют сейчас две строчки. Первая строчка — password, вторая строчка — login. Как уже было показано, нельзя использовать эти строчки в обратном порядке. Если я сейчас сначала наберу login, тем самым я говорю, что пользователь, который подключается по консоли, обязан показать пароль, но не указывая сам пароль. Система скажет «Извини, это небезопасно», потому что если вдруг ты наберешь login и потом начнешь набирать password, а потом ты отвалишься, то ты потом на консоль зайти не сможешь. Поэтому сначала нужно ввести слово «password» и указать, какой пароль нужно вводить. И только потом надо указывать login для того, чтобы указать, что пароль вводить нужно. Две команды, каждая отвечает за свое. Password указывает, какой пароль надо вводить. Login указывает, что пароль вводить надо. И в правильном порядке. Password. Cisco. Я простенький пароль делаю, и я рекомендую вам в лабораторных сценариях

использовать этот же пароль, потому что запомнить его очень просто, облажаться с его вводом достаточно тяжело. И для упрощения траблшутинга такой пароль весьма подходит. И затем уже login. Система приняла эту команду без особых проблем. Сейчас у нас при подключении к консоли будет спрашиваться пароль, и мы этот самый пароль вводим, и нас пускают в пользовательский режим. Чтобы мне это продемонстрировать, мне нужно завершить сессию. Logout. Exit. Logout. Logiut. Нет, не logiut, logout. Сейчас еще ждать, пока он прочухается. Долго.

Он пытается сейчас распознать имя logiut и подключиться к этому имени по протоколу управления. Причем протокол управления у него старый древний — LAD. Сейчас мы ему скажем, что не надо так делать. И logout. Здесь уже не печатался. Система завершила сессию. Говорит: скажи пароль, проходи. И если я нажимаю Enter, то я не сразу попадаю в пользовательский режим, а только через ввод пароля. Если я пытаюсь ввести какой-то неправильный пароль, совершенно произвольно неправильный пароль ввожу, он мне говорит: просто давай, вводи правильный, проходи. Если я несколько раз неправильный ввожу, сессия принудительно закрывается. И показывает, что пароль неправильный. В то же время, если я правильный пароль введу — cisco — без особых проблем меня пускает в пользовательский режим. Это самый простой механизм, которым можно защитить вашу циску от подключения каких-то совершенно левых людей.

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

но будет прикольнее, если у нас будет проверяться все-таки и логин, и пароль. И для того, чтобы это сделать, нам надо будет отключить нынешнюю проверку только пароля на консоли и заставить циску проверять вводимые логины и пароли по локальной базе пользователей. Enable, conf t. Нам потребуется эта самая локальная база пользователей, поэтому мы в ней создаем юзера. Username. Неважно, какого юзера вы создадите, как он будет называться, абсолютно любое имя, абсолютно любой пароль, который вы захотите. Давайте username cisco, cisco. Еще раз подчеркну, нигде не написано, что логин cisco или логин admin, или логин Вася какие-то специальные или особенные, просто достаточно быть в этой самой базе для того, чтобы вы получили доступ к пользовательскому режиму. И вот у нас есть пользователь cisco.

Затем line con 0. Указываем новый login. No password. Отменяем все старые команды, которые у нас были. И вводим новую команду login local. По большому счету, можно было сразу набрать login local и тем самым заменить команду просто login, а потом сказать no password. Но более корректно сделать так. Просто потому, что если вдруг у нас случится какое-то затмение мозга, и мы забудем, что у нас сначала была настроена аутентификация по паролю, а потом была перенастроена на локальную базу пользователей, просто чтобы не торчали у нас какие-то хвосты, если вдруг мы забудем удалить отдельно после этого команду password. Как бы там ни было, сейчас, после того, как этими двумя строчками мы отменили то, что сделали на предыдущем шаге, а этой командой мы сказали, что мы требуем ввода логина и пароля

и проверяем логин и пароль по локальной базе пользователей, которая сейчас состоит только из этого пользователя, logout. Сейчас должно происходить то, что мы и ожидаем. Когда мы завершили сессию, нажимаем Enter, система говорит «Скажи логин», и здесь мы говорим «cisco», дальше «Скажи пароль» — «cisco», и получаем доступ к пользовательскому режиму. После того, как у нас получилось настроить доступ на консоли, а мы сейчас подключены к нашим железкам именно по консоли, давайте сделаем что-нибудь более интересное. В частности, у нас есть Telnet, который мы можем настроить и заставить наши железки подключаться с использованием протокола удаленного управления. Что для этого нам потребуется? Нам нужно будет, чтобы наши роутеры и свитчи были между собой некоторым образом связаны. Сейчас у нас роутеры и свитчи, если мне память не изменяет,

предыдущего задания связаны с использованием DHCP. Show IP Interface Brief. Да, у нас есть эти интерфейсы, на которых у нас есть IP-адреса. Предлагаю сбросить конфигурацию и переделать эти адреса на статические, благо все равно придется сейчас что-то настраивать. Заодно отточим навыки повешения IP-адресов на интерфейсы. Мы с вами поменяли конфигурацию, которая у нас была до сего момента, на статические адреса 10.0.0.1, 10.0.0.2, 10.0.0.3, у меня 10.0.0.8, и все эти адреса находятся в одном большом широковещательном домене, в котором у нас находятся все роутеры, все свитчи. И гипотетически я сейчас могу проверить, что все эти адреса должны пинговаться.

10.0.0.1 пингуется, 10.0.0.3 тоже пингуется. Наши роутеры сейчас все друг друга видят. Наша хотелка — сделать так, чтобы все эти роутеры были доступны по протоколу Telnet, чтобы я со своего восьмого роутера мог зайти на роутер, допустим, первый, попасть в его командную строку. Давайте мы сейчас этим и займемся. Сделаем так, чтобы по командной строке было понятно, куда мы попали. Переименуем нашу железку, сделаем hostname R08 в моем случае. У меня восьмой комплект. И как вкладка называется, так пусть железка и называется. У вас будет первый роутер и третий, R01 и R03. После того, как этот hostname мы сделали, когда мы будем попадать в командную строку, мы легко сможем понять, где мы находимся.

R08 в моем случае легко позволит это определить. После того, как мы имя железки задали, у нас есть IP-адрес, у нас есть hostname, который позволяет нам легко определить, где мы находимся. Пришла пора настраивать саму линию управления, точнее, сами линии управления, потому что виртуальных линий управления VTY их много. Line VTY. И здесь показывают, что если мы настраиваем линии управления, то мы можем в качестве первой линии управления в пачке взять номер с нуля по 4. Самую маленькую наберем 0, и самую большую, конкретно на этой железке, можно указать номер 4. Да, на наших железках только 5 линий управления есть, это нормально, для наших задач больше и не нужно. Нам, напротив, иногда бывает полезно как раз все линии управления загрузить.

Если бы у нас на лабораторной железке их было слишком много, то это было бы тяжело. А 5 линий управления загрузить без особых проблем можно. Я указываю line VTY, дальше начиная с какой и заканчивая какой линии управления я одновременно скопом буду настраивать. Я указываю, что буду настраивать все линии управления одновременно. И, наконец, transport input. Указываю, что мне следует разрешить подключаться с использованием протокола Telnet. По умолчанию стоит настройка... Сейчас я покажу, какие здесь возможные варианты есть. По умолчанию стоит настройка NONE. Transport input NONE, потому что IOS на этих роутерах достаточно свежий, и он не позволяет кому попало подключаться к нему. Но я хочу поменять это и сказать transport input Telnet. Telnet. Вы у себя то же самое делаете. На всех линиях управления,

которые у вас есть, line VTY 0 4, указываете transport input Telnet. Тем самым мы скажем, что подключаться по Telnet к нашим роутерам можно. Давайте проверим, что у нас получается. Я хочу показать, что действительно с помощью протокола Telnet на этот роутер подключиться можно. Я указываю Telnet в решёточке, в обычной решётке, не в конфиге. Telnet. Дальше IP-шник моего роутера. 10.0.0.8. Вы тоже, если хотите, можете этот же адрес указать, и вы получите доступ к моему роутеру. И нажимаю Enter. И здесь меня ждёт отлуп, потому что система предупреждает: Password required, but not set. Это означает, что у нас в конфигурации есть команда login, но нет команды password. Я покажу, что это действительно так. Show running config. Показывает текущую конфигурацию. И в самом-самом конце, вот она, видите? Line VTY 0 4.

Вот эту строчку мы написали. А вот эту мы не написали, она там изначально была. И этот login без пароля как раз и означает, что мы требуем, чтобы подключающиеся пользователи показали пароль, но сам пароль при этом не задаём. И когда такая конфигурация есть, подключиться по Telnet на железку не получается. Чтобы это стало возможным, надо либо поменять этот login на login local, и тогда проверять пользователя мы будем по локальной базе, либо добавить команду password, и тогда подключающиеся по Telnet смогут предъявить тот самый пароль, который мы зададим командой password, и смогут попасть в пользовательский режим. Либо третьей опцией сказать no login. И тогда у подключающихся по Telnet пользователей ничего не будет спрашиваться, и пользователь будет просто сразу проваливаться в приглашение пользовательского режима. Давайте мы сделаем то, что в реальности может быть приближено к тому, что вам потребуется, и зададим login local на линию управления

с 0 по 4. Conf t, line VTY 0 4, login local. У нас есть локальная база пользователей. Она осталась с предыдущей конфигурации. Осталась ли она, кстати? По-моему, нет. По-моему, не осталась. Я же конфигурацию сбрасывал? Сбрасывал. У меня нету юзернеймов никаких. Так что надо создать. Exit. Username Cisco. Password Cisco. Теперь у нас есть локальная база пользователей. Теперь у нас есть в конфигурации юзер с паролем. И сейчас уже получится подключиться по Telnet к нашему устройству. Проверяем. Telnet 10.0.0.8. Система говорит нам: скажи, кто ты, и проходи.

Cisco. С паролем Cisco. И пользовательский режим — я здесь получаю доступ. Пожалуйста, проверьте, что вы можете тоже подключиться к, например, тому же самому 10.0.0.8. Именно такую команду можете ввести. И вы сразу увидите, что действительно получаете доступ именно к моей железке, не к своей. Приглашение командной строки на вашем роутере будет там Router R01, R03, а на моей железке он будет R08. Ещё одна замечательная особенность заключается в том, что на консоли у нас расслабленный режим безопасности, и enable срабатывает без пароля. Я сейчас, чтобы два раза не вставать, покажу вам. Если здесь enable набрать, система не пускает нас в enable. Дело в том, что сейчас я сам к себе подключился по Telnet. И формально говоря, я нахожусь не в консоли, а в этой самой виртуальной линии управления VTY. А там enable без пароля не работает. Если я выйду отсюда,

попаду в консоль, здесь disable сделаю, то здесь уже, конечно, enable сработает, потому что я нахожусь сейчас уже в консоли, а не в линии управления VTY. Здесь enable срабатывает без ввода пароля. Так, в качестве упражнения, Telnet 10.0.0.1. Так, на 10.0.0.1 нету команды login. Пожалуйста, пропишите что-то аналогичное. И юзера создайте тоже. И 10.0.0.3. Здесь уже всё есть. Cisco, Cisco. Действительно попал на третий роутер. После того, как мы смогли настроить Telnet, было бы неплохо настроить Secure Shell,

то есть SSH. Сделать так, чтобы наше подключение нельзя было перехватить. Давайте я вам покажу, что подключения сейчас идут действительно plain-текстовые. И когда мы подключаемся по Telnet и вводим логин-пароль, злоумышленник, который находится где-то посерединке, между точкой, откуда идёт трафик, и куда идёт трафик, он действительно эти пароли видит plain-текстом, в открытом виде. Я сейчас запустил специальное приложение, которое отслеживает любую активность на порту, и все IP-пакеты, и даже более структурно, Ethernet-кадры, которые отправляются с интерфейса этого роутера R08, оно здесь показывает. Здесь видно CDP, здесь видно DTP, который динамический транк согласовывает, здесь DHCP и всякую разную активность, в этом широковещательном домене много чего бегает. Нас сейчас интересует Telnet. Telnet пока здесь не видно. Я пытаюсь подключиться по Telnet на узел 10.0.0.1, и вон они пошли, эти Telnet-пакеты.

Cisco, Cisco, и попадаю в пользовательский режим роутера R01. Смотрите, я сейчас нажимаю вот эту штуку. Follow TCP Stream. Это деконструкция, реконструкция TCP-потока. Красненьким показано то, что я посылаю в сторону этой самой железки, синеньким — то, что железка мне отрисовывает. Я набрал буковку C, она немедленно мне отрисовалась. Я нажал буковку I, она немедленно мне отрисовалась. Набрал буковку S, она отрисовалась. Это юзернейм, который я вводил, два раза каждый символ показывается, потому что я нажимаю буковку, она отправляется в сторону Telnet-сервера, а дальше Telnet-сервер мне отрисовывает, что он эту буковку получил. А пароль я нажимаю, и он уже не отрисовывается, но тем не менее он в открытом виде здесь содержится. Поэтому если где-то на подозрительном центральном свитче сидит злоумышленник, который подслушивает весь трафик, он всё это увидит, и естественно с вашим логином и паролем может сделать что-то нехорошее. Абсолютной нормой в индустрии, к сожалению, является тотальное подслушивание открытых протоколов связи, и ваши провайдеры и сотрудники этих провайдеров, они, естественно, перехватывают такой трафик и его слушают. Более того, как вы понимаете, весь трафик, который в России проходит через порты пользователей, гипотетически может пройти через систему оперативно-розыскных мероприятий, точнее через специальное оборудование для такой системы — СОРМ-2, и трафик ваш может зеркалироваться на компьютер товарища майора совершенно без особых проблем. И товарищ майор тоже подслушает, что вы там такое передаёте, и как именно товарищ майор решит распорядиться вашими логинами и паролями — заранее неизвестно.

Поэтому лучше до такого не доводить, лучше всегда использовать протоколы связи, которые будут зашифрованы, и просто не позволять перехватывать ваши данные, чтобы там plaintext что-то было видно. Для этого нам потребуется Secure Shell. Выходим из командной строки первого роутера, возвращаемся в свою восьмую. Дальше. Нам потребуется для того, чтобы настроить Secure Shell, полностью квалифицированное доменное имя — FQDN.

Сейчас у нас его нету. Оно состоит из двух частей: hostname и доменного имени, которое задаётся командой ip domain-name. У нас сейчас есть только hostname R08, а второй части — доменного суффикса — нету. Давайте его зададим. ip domain-name. Неважно, какое вы сделаете, можно любой, реально любой доменный суффикс задать, это ни на что не повлияет, но я в корпоративных целях пишу networkeducation.ru. Вы у себя, пожалуйста, тоже это делаете. Теперь у нас полностью квалифицированное доменное имя будет R01.networkeducation.ru. Замечу сразу, что если я вдруг захочу, я могу посмотреть, какие у вас доменные имена заданы, поэтому не надо там делать что-то неприличное в качестве доменного суффикса или hostname. Это будет не очень красиво.

Какой-нибудь сделайте, всё равно какой. Можете тоже networkeducation.ru. И после того, как у нас сделан доменный суффикс, у нас получилось полностью квалифицированное доменное имя, мы можем создавать ключевую пару. Для ключевой пары потребуется следующее действие. Crypto key generate RSA. У нас на роутерах есть этот контекст, в нём можем всякое разное делать. Нам потребуется создать ключевую пару. Что с этой ключевой парой мы хотим сделать? Мы хотим её создать. Generate. Какие ключи нам нужны? Нам нужны ключи для протокола RSA общего назначения. General keys. И нам нужны ключи не любого размера. Нам нужны ключи как минимум 768-битные.

Modulus 1024. Это такой надёжный размер, с которым SSH версии 2 точно заводится. Эти ключи довольно быстро генерируются. И нам показывают, что ключи сделались. Это ключи хорошие, рабочие, от хулиганов нас защитят. И показывается, что сразу же включился SSH почти второй версии. Эта «почти вторая версия» нам не нравится. Мы его переводим в жёстко вторую версию. IP SSH version 2. Вы у себя, пожалуйста, то же самое всё делаете. Первое — создаём доменный суффикс. Второе — генерируем ключи размера 1024 бита. Третье — включаем SSH второй версии. И последний шаг. На линии управления VTY разрешаем этот самый SSH. Потому что, если вы помните, на предыдущем шаге мы разрешили подключаться только по протоколу Telnet. Поэтому идём в line VTY 0 4 и указываем transport input SSH. Если хотим, Telnet в принципе тоже можем здесь разрешить.

Если укажете вот такую команду, вы разрешаете и SSH, и Telnet. Насколько вы хотите это делать — я не знаю. Я бы Telnet не разрешал, по крайней мере для подключения по каким-то недоверенным сетям. Итого. Что у нас получилось? Доменный суффикс. Ключевая пара. SSH второй версии. И ограничение, что мы разрешаем подключаться по SSH. Если у вас всё это сделано, то SSH на вашей железке заводится и разрешает подключаться к себе с использованием шифрованного соединения. И это, конечно же, рекомендуемый вариант, как вы хотите разрешать подключаться к вашим устройствам в 2019 году. Особенно если вы разрешаете подключаться через какие-то недоверенные соединения, через интернет или что-то в этом духе. Как проверить, что оно работает? SSH минус L. Cisco.

Дальше куда подключаемся? 10.0.0.8. Что-то он задумался. Cisco. Я зашёл сам на себя по SSH. Выхожу из этого SSH и попадаю обратно в свою консольку. Давайте проверим, получилось ли у вас это. 10.0.0.1. Система сейчас согласует параметры соединения, согласует симметричный ключ, который она будет использовать,

Поэтому на некоторое время она подвисает. Спрашивает пароль. Действительно, R.0.1 сработала. Ключевая пара сгенерирована. Без доменного имени она не сможет быть сгенерирована. Здесь она сгенерировалась. И, соответственно, SSH включился. Ради смеха 10.0.0.3 тоже проверяем. Тоже он, скорее всего, сейчас заработает. Так. К Cisco. Да, всё хорошо. Далее. Когда мы с вами вешаем пароль на консоль или на виртуальную линию управления, мы тем самым ограничиваем доступ к пользовательскому режиму. В этом пользовательском режиме, как вы знаете, сделать можно не так много. Поэтому обычно, когда мы хотим предоставить кому-то доступ к железке, мы хотим предоставить доступ именно к привилегированному режиму, а не к пользовательскому.

И для перехода из одного режима в другой, как вы знаете, есть команда enable. Эта команда требует пароль. Всегда, когда вы вводите enable, вы не просто вводите enable, вы должны ввести свой пароль. И этот пароль отдельный, пароль на enable. Вы его должны задать в конфигурации. Просто когда вы через консоль подключаетесь, пароль на enable не требуется. Но через telnet или через что-либо ещё там потребуется пароль. Если вы его в конфигурации не задали, то система будет ругаться. Дальше. Есть две команды, которыми вы можете задать пароль на enable. Они делают одно и то же. Разница между ними заключается в том, как в конфигурации будет храниться этот пароль. Соответственно, команда enable password и enable secret. Синтаксис одинаковый. Enable, дальше либо password, либо secret. И сам пароль, который вы будете использовать в качестве пароля на enable. Если вы хотите, вы можете задать обе эти команды.

И тогда будет использоваться только enable secret. Разница между ними заключается в том, что в enable secret не будет храниться сам тот пароль, который вы ввели. По факту будет храниться только хэш от него. А если вы делаете enable password, то он будет храниться именно в том виде, в конфиге, как вы его и задали. Если вы введёте и одно, и другое, как здесь, например, у нас есть команда и enable password в конфигурации, и enable secret, и затем вы вводите show running config, то enable password, как вы её ввели, так она и получилась, а enable secret превратилась вот в такую кашицу. Из этой кашицы нельзя сделать обратное преобразование и получить пароль в исходном виде. Поэтому enable secret считается более безопасным. И, соответственно, если у вас в конфигурации есть и enable password, и enable secret, то браться будет пароль тот, который закодирован в enable secret.

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

никакого нет. Поэтому вывод. Если у вас железка в 2019 году не требует какой-то обратной совместимости с чем-то древним, используйте enable secret. Это в подавляющем большинстве случаев будет работать лучше, чем что-либо ещё. Сценарий, где вам может потребоваться enable password, это отсутствие поддержки enable secret, если у вас железка без поддержки вообще какого-либо шифрования. Но в России, как правило, все железки, которые есть, они с поддержкой хотя бы слабого шифрования продаются, поэтому проблемы там быть не должно. Далее. Что касается этой циферки 5. Когда вы в конфигурации видите, что у вас пароль предваряется какой-то циферкой, это значит, что пароль в конфиге хранится зашифрованным. Если используется пятёрка, это значит, что используется хэш на основе MD5. Если используется четвёрка, то это хэш на основе SHA.

Ещё есть семёрка. Про неё мы поговорим на следующем слайде. И ноль — это пароль в открытом виде. По поводу семёрки и по поводу шифрования тех строчек, которые заданы командой password. Можно enable password, можно вспомнить те команды, которые мы на предыдущих слайдах разбирали. Это username, password или просто password в конфиге. Все команды, которые содержат в себе слово password, Cisco умеет скрывать. Использует она для этого обратимое шифрование, которое можно легко расшифровать. И единственная задача этого шифрования — чтобы тот, кто вам через плечо заглядывает, увидел не пароли в открытом виде, а какую-то кашицу. Выглядит это следующим образом. Вы в конфигурации вводите enable password Cisco. Рядышком вводите username Cisco, password Cisco. Все эти команды содержат слово password. И Cisco не сами команды, а пароли, которые в них содержатся, она будет кодировать.

И если вы введёте команду service password encryption, то все строчки в конфиге, которые содержат пароли, пароли, заданные командой password, они превратятся вот в такую колбасу. Вот такая. И семёрочка намекает на то, что используется метод Cisco 7. Это обратимое шифрование, и вы можете взять эту строчку и запихать её в раскодировщик, и оно вам вернёт оригинальный пароль. Этот механизм не позволяет защититься от потери целиком файла с конфигурацией. Если злоумышленник получит доступ к этому значению, он сможет восстановить оригинальный пароль. Но если кто-то вам через плечо заглядывает, он увидит это, и, конечно же, не сможет понять, что это на самом деле пароль Cisco. Если только у него не фотографическая память. Команда service password encryption, используя обратимое шифрование,

шифрует все пароли, которые заданы командой password. Если вдруг вы хотите, вы можете сказать no service password encryption после того, как вы эту команду задали, и у вас ничего не произойдёт, кроме того, что новые пароли, которые вы будете добавлять, они уже шифроваться не будут. Если у вас был какой-то пароль, который изначально был в открытом виде, но вы потом сделали service password encryption, он у вас зашифровался, и вы подумали, что что-то вам не нравится в конфиге зашифрованные данные хранить. Вы сделали no service password encryption, и пароли останутся закодированные по-прежнему. Если вдруг вы хотите, чтобы они в конфиге стали расшифрованные, вы должны их сменить. Ещё раз создать этого username Cisco, password Cisco. И тогда новые пароли, которые будут в конфигурацию попадать, они уже будут не зашифрованы. Эта штука работает со многими, не со всеми,

но со многими строчками, которые командой password задаются. Разница между тем, как можно закодировать пароли, заданные командой password, и как кодируются по факту пароли, заданные командой secret, заключается в том, что secret необратимо кодирует пароли. Соответственно, из того, что enable secret задаёт, восстановить оригинальный пароль нельзя. А из этой штуки восстановить оригинальный пароль можно. Ещё одна штука, которую вы должны будете знать, которая имеет напрямую отношение к безопасности, это баннеры. Баннеры — это просто какой-то текст, который показывается при некоторых действиях пользователя. В Cisco есть много разных баннеров, их там пять штук. Нас будут интересовать два. Первый — banner login, который показывается тогда, когда вы собираетесь ввести пароль. И второй — banner message of the day, сообщение дня. Он показывается всем, кто получает доступ к командной строке.

Стандартная практика в IT-индустрии — это показывать banner login о том, что человек, который подключается к устройству, должен вести себя хорошо. Он не должен подключаться с каким-то злым умыслом. Если вы хотите, вы можете вывести текст, что железка принадлежит компании «ЗАО Ромашка», и подключаться имеете право только, если вы сотрудник «ЗАО Ромашка». Какой-то такой текст вы должны будете ввести. По умолчанию там ничего не показывается, но если вы хотите, вы можете этот текст показывать. И, как правило, если у вас в компании есть некая политика безопасности, то она же должна и указывать, какой именно текст вам следует выводить. Текст этот должны составлять безопасники. Это не ваша задача как айтишника этот текст создавать. Для чего это вообще нужно? Для того, чтобы гипотетический злоумышленник не мог сказать, что он не знал, что к этой железке нельзя подключаться.

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

не вызывает немедленного срабатывания. Смысл этого заключается в том, чтобы вывести текст, содержащий переносы строк. Соответственно, в некоторых ситуациях вы можете хотеть задать баннер, который состоит из нескольких строк, и там будет символ переноса строки, который, естественно, вводится с помощью клавиши Enter. И для того, чтобы обозначить, что вы находитесь в состоянии ввода той самой строки с переносами строк, вы должны будете предварить текстовую строчку, содержащую переносы, неким символом. Синтаксис будет следующий. Banner. Потом указываете, какой баннер вас интересует, например, banner login. Дальше указываете некий символ, который заведомо не встретится в тексте. Любой, который вам больше нравится. Например, доллар. Дальше вы пишете любые символы, которые могут встретиться в вашем тексте. Можно ставить переносы строк. Можно использовать псевдографику. Можно использовать даже символ вопросика.

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

Ctrl-C, да. И, соответственно, если вы там введёте какие-то символы, то они будут показываться всем, кто получает доступ к командной строке. В нормальной ситуации, когда пользователь видит какую-то командную строку, подключается по линии управления консоли, например, система говорит, что роутер готов подключиться по консоли, дальше нажимаете Enter, и система показывает сначала banner login, а потом фразу «Скажи пароль и проходи». Вы вводите логин-пароль, проходите, здесь показывается message of the day, если мне память не изменяет, и дальше приглашение к вводу. Давайте попробуем это всё тоже пощупать. Соответственно, сначала попытаемся повесить пароли на enable, а затем повесим баннер и посмотрим, к чему это нас приведёт. Вот наш роутер. Сейчас мы находимся в консоли,

поэтому мы можем в enable перейти без особых проблем. Система не спрашивает логин и пароль, потому что это консоль. На консоли гайки в части безопасности обычно расслаблены. Но мы хотим, чтобы даже тот, кто получил доступ к консоли, получал бы доступ к привилегированному режиму только после ввода пароля. И пароль у нас будет предсказуемый. Cisco. Первый вариант. enable password Cisco. Так, Cisco. Cisco. И второй вариант enable secret. Я сейчас обе команды задаю. Так делать не надо. В реальном мире вы всегда должны использовать только enable secret. Просто я хочу показать, что и enable password, и enable secret работают. Оно работает по-разному. Давайте я сейчас покажу, что enable password тогда без enable secret работает.

Exit. Disable. Enable. Сейчас только enable password в конфигурации есть. Я указываю Cisco. И прохожу в решётку. Если я указываю неправильный пароль, enable, какой-то случайный пароль, три раза подряд ввожу, система говорит «неправильный пароль» и оставляет меня в пользовательском режиме. Я сейчас задал пароль. Он задан командой enable password. Никакого enable secret сейчас нет. Cisco show run include enable. Вот оно. И оно в plaintext в конфигурации хранится. Дальше. Conf t enable secret Cisco 1. Я делаю разные пароли. Если я сделаю одинаковый пароль, Cisco будет ругаться, но при этом примет такую конфигурацию.

То есть сейчас и enable password, и enable secret есть, но проверяется только тот, который enable secret. При этом, естественно, что если у вас пароли одинаковые, то нет смысла хранить надежно защищенный пароль, если plaintext он же рядышком и лежит. Поэтому Cisco ругается, говорит, что ты выбрал такой пароль, который лежит plaintext. Так делать бессмысленно. Но при этом в конфигурацию он все равно добавится. Do show run include enable. Вот. Он все равно добавил эту строчку. Enable secret все равно есть. Ну, естественно, надежно закодировано. Только смысла в этом кодировании нет, учитывая, что вот мы plaintext. Поэтому мы сейчас добавим символ единичку, сделаем другой пароль на enable secret. Уже не ругается, потому что пароль другой. И я показываю, что действительно, если у нас и одна, и другая команда есть, а они действительно сейчас обе в конфигурации есть, срабатывает только enable secret,

enable password не срабатывает. Disable. Enable. Вы не видите этого, но, честное слово, даю вам, что я сейчас ввожу Cisco, то есть enable password. И система не принимает пароль Cisco, несмотря на то, что вот enable password Cisco у нас в конфигурации есть. Вот если я сейчас наберу Cisco 1, который соответствует паролю на enable secret, оно меня пустит. Опять же, вы не видите, но, честное слово, я такое набрал. И это показывает, что если у вас в конфигурации есть и пароль enable password, и пароль enable secret, то enable password не работает, работает только enable secret. Вам может показаться немножко странным это поведение, но логика там такая, что вы можете гипотетически одну и ту же конфигурацию разливать на разные устройства. И у вас может быть гипотетические ситуации, когда один и тот же конфиг разливается на железке

с поддержкой шифрования и без поддержки шифрования. То есть похожие, но разные устройства. И в этом случае как раз на железке без поддержки шифрования будет попадать enable password. Они не понимают, что такое enable secret, но файлы на них все равно разливаются, просто они эту строчку не примут. Но enable password они примут, и можно будет пользоваться им. А, соответственно, на железке с поддержкой шифрования будет разливаться enable secret. Так, далее. По поводу кодирования паролей. Сейчас show run include password. Сейчас у нас все строчки, которые мы вводили, и enable password, и вот username cisco password, чего-то там cisco, они содержат пароли, которые plain text там в открытом виде в конфигурации лежат. Если злоумышленник возьмет и украдет startup config, то, соответственно,

он эти пароли увидит просто вот как нечего делать. Частично эту проблему можно решить с использованием secret. То есть и, в принципе, команда username принимает в качестве аргумента параметра secret. Можно не паспорт делать, а secret. User name cisco, secret cisco. Давайте покажу. Conf t. User name cisco 1. Secret cisco 1. Exit. Так. User name. Include username. Вот у нас добавился еще один пользователь, и, как видите, у него нету пароля, у него есть только секрет. И вот этот вот secret, это, конечно же, необратимое шифрование, то есть восстановить из-за вот этой вот колбасы оригинальный пароль cisco 1 нельзя. Но, соответственно, да, не всегда такие юзернеймы нам подходят. В некоторых случаях нам нужны юзернеймы

в локальной базе, которые именно с пасвордом созданы. То есть нам от них нужны оригинальные plaintextовые пароли, поэтому мы обязаны plaintextовые пароли хранить в конфиге. И, как следствие, это может привести к неприятности в виде, что кто-то с этим plaintextовым паролем к нашей железке может подключиться. Поэтому, если мы хотим, чтобы у нас не палился вот этот вот пароль прям вот в открытом-открытом виде, что если кто-то через плечо нам заглядывает, когда мы showrun делаем, вот для того, чтобы сам пароль просто прикрыть, есть команда service password encryption. Conf.t. Сделайте, пожалуйста, тоже ее. Service password encryption. Если я ввожу эту команду, то все пароли, которые в конфиге есть заданной командой password, они все шифруются с использованием обратимого шифрования. Плюс все пароли, которые я новые создаю,

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

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

могут ее быстро запомнить, ну, делайте длинные пароли, и тогда их будет тяжелее с одного взгляда запомнить и воспроизвести потом в дескрипторе. Если убрать эту команду no-service-password-энкрипшн, то пароли, которые были зашифрованы в конфиге, не сохранятся, то есть они будут по-прежнему закодированы, но новые пароли, которые вы будете добавлять со словом паспорт, они уже, соответственно, не будут plaintext добавляться. показывают, что на конфигурации это не сказалось, что те пароли, которые у нас были, они как были зашифрованы, так и остались. Но если я добавляю новый юзернейм, csco2, password, csco2, то новый пароль совершенно без особых проблем добавился уже plaintext. Этот нолик показывает plaintext. Дальше следующий пароль, эта семёрка означает,

что этот decrypt csco7 используется, а пятёрка — это хэш на основе md5. На самом деле, это хэш на основе md5 плюс некой соли. Вот эта штука — это соль, а вот это — как раз хэш от пароля плюс этой соли. Когда вы храните пароль от пользователя в режиме secret, то есть храните только хэш от него, то такой пароль можно использовать для проверки того, что пользователь логинится на вашу железку. Он приходит, говорит, у меня логин csco, пароль тоже csco, вы от его пароля берёте хэш и сравниваете с тем, что у вас в конфиге лежит. Или если у вас в конфиге лежит соответственно хэш с солью, вы берёте его пароль, который он вам показывает, берёте эту соль, считаете хэш от пароля плюс соль и сравниваете с этим значением. Если результат совпал, то пароль, который у вас в конфиге хранится, действительно csco. Вы его не храните,

но вы вычисляете, что он действительно такой, который надо. Соответственно, если злоумышленник украдёт ваш конфиг, то из этого он не восстановит оригинальный пароль csco. И последнее, что здесь хотелось бы заметить, это как раз баннеры. Давайте попробуем баннеры понастраивать. Баннер логин. Дальше какой-нибудь символ, который не встретится в тексте. Я догадываюсь, что доллар у меня в тексте не встретится. Дальше давайте попробуем какой-нибудь псевдографикой поиграть. Раз, два, три, четыре, пять, шесть, семь, восемь, девять, десять, одиннадцать. Нажимаю Enter. У меня первая строчка состоит из 11 символов звёздочка и Enter. Дальше. Звёздочка, пробел, пробел, логин.

Как-то так. И соответственно снова символ доллара. И у меня получился такой смешной баннер, состоящий из 11 звёздочек. Дальше 11 символов логин и ещё 11 звёздочек. После последней звёздочки символ переноса строки и после него уже снова идёт доллар. Что получилось в конфигурации? Show, do show running con- фига. Надо отмотать. Где у нас баннер? Вот он, баннер. Вот так эта штука выглядит в конфигурации. Мой символ доллара заменился на ctrl-c и вот здесь тоже ctrl-c. Обратите внимание, я мог бы тут не ставить символ переноса строки. В принципе, я мог там же и завершить, но это было бы не так красиво. И сейчас вы поймёте,

почему. Логаут. Да, я забыл, что у меня на консоли нету логина. Баннер логин показывается только тогда, когда у вас выводится приглашение к вводу юзернейма. На консоли у меня нету юзернейма, поэтому я сейчас сам на себя зайду с Telnet. И вот она моя псевдографика. За счёт того, что я добавил один символ переноса строки, у меня здесь появилось красивое отделение моего баннера от текста user access verification. Если бы я не сделал этот символ переноса строки, то оно могло бы у меня прилипнуть. То есть показать мой прекрасный баннер, а потом вплотную к нему шло бы user access verification. Это было бы не так красиво. Но здесь как раз такой хороший пример того, что баннер-логин показывается только тем пользователям,

которые по факту должны предъявить логин и пароль. Или просто пароль. Если вы на консоли не требуете предъявления логина и пароля, то вам такой баннер не показывается. В то же время message of the day, motd, он показывается вообще всем. Даже тем, кто не должен предъявлять логин и пароль. Поэтому, если вы хотите показать какой-то баннер всем, показывайте его в message of the day. Если вы хотите показать баннер только тем, кто показывает логин и пароль, используйте баннер-логин. Cisco 1, Cisco 1. Попал в Telnet. Exit. Вышел из Telnet. Если у вас есть сетевые устройства Cisco, то защищайте вашу физическую доступность этих устройств, ставьте их в шкафчики, закрывайте эти шкафчики на ключ. Не позволяйте

подключаться к вашим устройствам кому попало к консольному порту. Консольный порт — это порт с расслабленной безопасностью. Там не требуется вводить пароль на enable, там не требуется вводить пароль для доступа к самой линии управления, поэтому консольку имеет смысл защищать отдельно. Для того, чтобы защитить ваши VTY, используйте те же самые механизмы, что и для консоли. То есть указывайте, что к VTY можно подключаться только с использованием логина и пароля. Указывайте, что вы разрешаете подключаться только с разрешенными сетевыми протоколами Telnet или SSH или, соответственно, оба. Указывайте, что к VTI можно подключаться только из-под определенных IP-шников сети управления. То есть создайте стандартный аксесс-лист, который будет указывать на ваши IP-шники, из-под которых разрешено подключаться к вашим CISC. Сделайте так, чтобы кто попал подключаться к ним не смог. И используйте

команду Access Class для ограничения доступа. Вот. Хорошей идеей будут сами сетевые устройства, CISC-овские вот эти вот сами роутеры, свечи, по крайней мере, их IP-шники управления, вынести в отдельную сеть. И просто на уровне маршрутизации или чего-то еще доступ обычных пользователей туда просто ограничить. Выключайте неиспользуемые сервисы. То есть по умолчанию из коробки на CISC-ах могут работать всякие разные вещи типа HTTP веб-серверах, HTTPS секюр-веб-сервера. Они вам не нужны, как правило, поэтому выключайте их, если вы точно не знаете, что это вам зачем-то нужно. В каких ситуациях HTTPS сервер вам может пригодиться? Например, если вы хотите на вашу CISC-у подключаться с использованием EasyVPN или SSLVPN, там

HTTPS сервер будет нужен. Если у вас включен IPv6, то не забывайте, что там все то же самое, что в IPv4. То есть если вы в IPv4 пишете, что подключаться можно из-под определенных IP-шников, то в IPv6 тоже надо будет указать все то же самое, потому что IPv6 это фактически точно такой же протокол, как IPv4, и в нем все те же самые проблемы есть. Поэтому если у вас в организации развернут IPv6 или тем патче развернут доступ по IPv6 к интернету, то закрывайтесь и в IPv6 тоже. Если у вас есть какие-то порты маршрутизаторов, то с ними все довольно просто, потому что то, что вы не настроили на маршрутизаторах, оно, как правило, все выключено. На маршрутизаторах все порты изначально, как правило, выключены, и вы должны в явном виде включить и настроить для того, чтобы маршрутизатор начал работать. Они все находятся в первом вилане в динамическом

режиме согласования транка. Они, правда, там ничего особо не согласуют, но, тем не менее, чаще всего они получают в итоге согласование access. Если у вас есть коммутаторы цисковские, то сделайте им типовую конфигурацию порта доступа, который по факту не используется. То есть административный даун, то есть шатдауном гасите такие порты, прибивайте им гвоздями static access, и прибивайте им гвоздями такой вилан, который либо отсутствует в базе, либо присутствует в базе, но он просто выключен. Ну и, соответственно, никогда ни в каких ситуациях в этом вилане трафик боевой не заведется и коммутироваться не будет. Если у вас есть порты, которые используются на коммутаторах, то защищайте их с помощью порт security, как минимум от атаки на переполнение таблиц и MAC-адресов. Неплохой идеей будет рассмотреть 802.1x для того, чтобы защититься от подключения к сети неавторизованных устройств. Ну и из того, что в курсе мы рассматривали,

отключайте CDP на пользовательских портах, если только у вас нет IP-телефонов Cisco. Если Cisco-телефоны есть, то CDP там, к сожалению, придется оставить. Так, далее. Давайте поговорим про то, как можно защитить трафик пользователей. В некоторых ситуациях мы можем сказать, что через интерфейс у нас могут проходить какие-то пакеты, и некоторые из этих пакетов будут хорошие, а некоторые нет. И здесь нам понадобится механизм, который будет решать, что хорошее, а что не очень. Если у нас есть механизм, который должен что-то решать, то мы вспоминаем, что это у нас называется Access Control List или ACL. Как правило, если мы говорим про Access Control List применительно для фильтрации трафика, все, что Access List классифицируют как Permit, мы разрешаем. То, что Access List классифицируют как Deny, мы на пакетном фильтре запрещаем. Вот этот

вердикт Permit и Deny, сами по себе вердикты, они не влияют на судьбу трафика. То есть это просто ответы да или нет, условно говоря, мы говорим похоже это на слона, не похоже это на слона. Вот Permit это да, Deny это нет. Да, похоже, нет, не похоже. Но, соответственно, в случае с пакетной фильтрацией, вот все, на что мы говорим Permit, у нас получается будет пропущено через интерфейс. То, на что мы говорим Deny, пропущено не будет. Мы на каждом интерфейсе роутера, вот это все для роутеров будет актуально, мы на каждом интерфейсе можем повесить два пакетных фильтра. Один на вход, другой на выход. Вот у нас есть, допустим, компьютер, и у нас есть роутер, который думает, пропустить ли пакет этого компьютера в интернет или нет. Соответственно, пакеты, которые у нас идут, они проходят через входящий интерфейс на наш роутер. Мы можем на входе проанализировать эти пакеты

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

Один на вход, другой на выход. Причем отдельно вешаются IPv4 аксесс-листы до двух штук на вход-на выход. И отдельно вешаются IPv6 аксесс-листы тоже до двух штук на вход-на выход. Они независимы, и, соответственно, мы можем фильтровать отдельно IPv4, отдельно IPv6. На каждый протокол мы можем повесить отдельные аксесс-листы. У CISC есть замечательная формулировка, что аксесс-листы вешаются по одному аксесс-листу на интерфейс, на протокол, на направление. То есть в каждом направлении для каждого конкретного протокола на каждом интерфейсе мы можем повесить только один аксесс-лист. Нельзя повесить два аксесс-листа на одном интерфейсе для IPv4 на выход. Это было бы лишено смысла. Но вот один аксесс-лист для IPv4 на интерфейсе на выход мы повесить можем. И один на вход можем. И один на вход и выход для IPv6 можем отдельно. И на другие интерфейсы тоже можем. Дальше. Если мы хотим назначить аксесс-лист, который будет фильтровать трафик на интерфейсе,

то команда будет следующая. В IPv4 это будет команда ipaccessgroup. И дальше даем название аксесс-листа или номер аксесс-листа и указываем направление. In — это те пакеты, которые входят в наш роутер. Out — это те пакеты, которые выходят с нашего роутера. То есть вот у нас роутер. У него есть там входящий и выходящий интерфейс. Пакеты, которые входят, вот здесь вот это, соответственно, in. Пакеты, которые промаршетизировались и выходят с нашего роутера, это, соответственно, out. Ну и в обратную сторону это будет уже другое направление. In и, соответственно, out. В IPv6 команда, в общем, немножко модифицировалась. Она стала более осмысленно называться. И IPv6 traffic filter. Опять же, на вход и на выход можно будет повесить аксесс-листы. Запомните, эти команды в IPv4, они называются абсолютно по-дурацки. Это невозможно понять, а надо запомнить. Аксесс-лист создает аксесс-лист, аксесс-класс вешает аксесс-лист на VTI-ку,

и IP-аксесс-групп вешает аксесс-лист на интерфейс. На экзамене нужно будет просто запомнить. В IPv6 команда уже называется разумным образом traffic filter. Ну, по названию понятно, что имеется в виду. Примеры того, как можно с помощью аксесс-листов фильтровать трафик. У нас есть роутер. Вот он. Этот роутер одним интерфейсом смотрит во внутреннюю сеть. И, соответственно, двумя интерфейсами, Gigabit 0.0 и Gigabit 0.1 смотрят куда-то еще. За Gigabit 0.0 у нас находится интернет. За Gigabit 0.1 у нас находится некий сервер. Давайте назовем его DMZ. И вот наша задача требуется сделать так, чтобы узел 10.0.0.1 не мог ходить в интернет. То есть вот отсюда, чтобы пакеты в интернет не ходили. Но при этом не стоит ограничивать его в праве хождения в DMZ.

Каким образом можно эту задачу реализовать? На самом деле ее можно реализовать множеством разных способов. Но самый простой способ сказать. Нас интересует, в общем, только IP-шник источника 10.0.1. И на основании этого IP-шника источника все мы будем, все решения сможем принимать без особых проблем. Нам потребуется аксесс-лист, который говорит нет на 10.0.1 и да на все остальное. Вот такой вот аксесс-лист с номером 1. Deny 10.0.1. Аксесс-лист 1. Permit Any. Он говорит нет на такой IP-шник и да на все остальное. Как раз то, что нам и требуется. И дальше мы этот аксесс-лист должны будем где-нибудь повесить. Возникает вопрос, где мы его можем повесить, учитывая, что у нас есть много интерфейсов, много направлений, где на этом интерфейсе можно будет аксесс-листы вешать. Соответственно, у нас есть вот здесь вот на вход и на выход. Здесь есть на вход и на выход. И вот тут вот есть тоже на вход и на выход. И возникает вопрос.

Можем ли мы повесить его, например, вот тут вот, на входе, на интерфейсе, который смотрят из локалки? Гипотетически можем, но тогда мы повлияем на путь трафика в вот этот вот самый DMZ. Потому что если мы скажем, что мы не хотим пропускать никакие пакеты от 10.0.0.1, то тогда у нас поломается связь 10.0.0.1 с сервером. Это не совсем то, что нам хочется. Можем ли мы повесить этот аксесс-лист на интерфейс, который смотрит в сторону сервера? Можем, только опять же мы поломаем связь с сервером. Можем ли мы повесить его на гигабит 0.0.0 на выход? Можем. Потому что в этом случае как раз пакеты, которые идут из-под 10.0.0.1 сюда, они будут отбиваться. И пакеты из 10.0.0.1 в интернет ходить не будут. В то же время взаимодействие с сервером у нас осталось нетронутым. Поэтому такой аксесс-лист мы вешаем на интерфейсе гигабит 0.0.0 на выход.

Это один из вариантов, как можно решить такую задачу. Мы указываем на интерфейсе. Интерфейс гигабит 0.0. IP access group 1 out. Это номер аксесс-листа — это направление, в котором мы вешаем аксесс-лист. Понятное дело, что нет смысла вешать этот аксесс-лист на вход, нет смысла здесь, допустим, на выход, но и тут тоже особо смысла на вход вешать такой аксесс-лист нет. Поэтому из всех возможных вариантов, где его можно было бы применить, мы его вешаем здесь и фильтруем трафик, который идёт в интернет. Так. У нас более сложная задача может быть. Пример того, какая задача может быть. У нас есть роутер, у него есть внутренняя сетка и есть внешний мир. Во внешний мир всего один интерфейс смотрит, гигабит 0.0. И мы хотим сказать следующее: во внутренней сети у нас есть некоторое количество компьютеров, и там есть узел с IP-шником 10.1.0.1.

Этот товарищ очень любит сидеть в каком-нибудь ВКонтактике. И IP-шник ВКонтактика у нас 203.0.1.1. Этому самому узлу надо запретить доступ в ВКонтактик в любом случае. А всем остальным узлам, в том числе и этому самому 10.1.0.1, надо предоставить доступ к любым веб-страницам, которым только им захочется. Куда угодно можно ходить, но именно 10.1.0.1 именно на 203.0.1.1 ходить не может. У нас есть дополнительные ограничения, что использовать можно протоколы HTTP и HTTPS. Это означает, что мы должны будем на уровне аксесс-листа уметь разбирать, во-первых, заголовок IP в части поля протокол, а во-вторых, мы должны будем работать с отдельными портами в TCP. Поэтому нам потребуются расширенные аксесс-листы. И для этого мы создаём новый расширенный аксесс-лист, для простоты нумерованный. Указываем аксесс-лист, дальше номер аксесс-листа 101.

И дальше нам надо ввести некоторые правила, которые скажут, что мы можем сделать. Первое правило. Нам нужно будет запретить этого товарища ходить на этот IP-шник. Потому что если мы этого не сделаем, то этот товарищ к этому IP-шнику сможет ходить по протоколам HTTP и HTTPS. Мы хотим сначала запретить товарища, а потом разрешить всё остальное. И поэтому мы указываем правило: deny на любые подключения из-под IP-шника 10.1.0.1 на IP-шник 203.0.1.1. Любой доступ от этого адреса до этого адреса будет невозможен. Дальше вторая и третья строчка. Они очень похожи друг на друга. У них вердикт будет одинаковый, permit. Подключения будут возможны, если они идут по TCP, из-под сети 10.1.0.0 по 16-й маске.

То, как у нас и требуется. На куда угодно. Но дополнительное ограничение на порт получателя — либо HTTP, либо 443. HTTP — это 80, а 443 — это HTTPS. И этот аксесс-лист говорит «да» на то, что нам требуется. Это правило. На всё остальное аксесс-лист скажет «нет». И это то, что нам требуется, потому что нас просили разрешить доступ по этим двум протоколам. Больше нас ничего не просили. И, как следствие, неявный запрет на всё остальное в конце аксесс-листа решает поставленную задачу. И наконец, надо этот аксесс-лист применить на каком-то из интерфейсов. Опять же, у нас есть варианты, где это применить. Можно либо на гигабит 0.1, либо на гигабит 0.0 в сторону интернета повесить. И в какой ситуации нам будет лучше какое решение принять, если мы вешаем на каждом из этих интерфейсов такие пакетные фильтры.

Если мы повесим этот пакетный фильтр на гигабит 0.1, то мы трафик отобьём на этапе до того, как он пришёл на наш роутер, и до того, как мы потратили ресурсы на его обработку. В то же время, если мы повесим этот пакетный фильтр на гигабит 0.0, то мы тем самым скажем: окей, мы приняли такие пакеты, мы приняли маршрутизационное решение, мы потратили ресурсы для того, чтобы найти выходной интерфейс, и когда мы нашли выходной интерфейс, мы такие пакеты прибили. Понятное дело, что в такой ситуации нет смысла тратить ресурсы для того, чтобы потом пакеты прибивать, если у нас всё равно путь этого трафика предсказуемый. Поэтому в такой ситуации лучше пакетный фильтр повесить на вход, на интерфейс гигабит 0.1 на вход. И мы идём на гигабит 0.1 и указываем IP access group, дальше номер access-листа и направление на вход. Оба варианта равноценны по логике, но в гигабит 0.0 мы будем тратить ресурсы на обработку пакетов, которые всё равно будут пристрелены.

А в гигабит 0.1 мы сначала пристреливаем пакеты и не тратим ресурсы на их обработку. Ещё один пример того, как с помощью access-листов можно фильтровать трафик. У нас есть, опять же, внутренняя сеть. У нас есть внешний мир, и в этом внешнем мире есть узел 203.0.113.1. Мы хотим сделать так, чтобы все узлы во внутренней сети могли бегать куда угодно, но не могли бы подключаться на этот 203.0.113.1. У нас есть подозрение, что здесь могут появляться ещё хосты с непредсказуемым количеством, с непредсказуемыми IP-шниками, и мы должны будем иметь возможность этот чёрный список пополнять на лету. Эта необходимость пополнять чёрный список на лету на самом деле не даёт свести задачу к предыдущей.

Дело в том, что в предыдущей задаче мы использовали нумерованные access-листы, а с нумерованными access-листами есть одна проблема. Они один раз создаются, и дальше, после того как они созданы, их уже нельзя исправить. Если мы хотим создавать чёрный список адресов, куда ходить нельзя, то мы должны сначала сказать, куда ходить нельзя, а потом сказать, что на все остальные узлы ходить можно. И последняя строчка у нас должна быть фактически permit IP any или что-то в этом духе. И для того, чтобы пополнять чёрный список адресов, нам фактически потребуются именованные access-листы, которые можно редактировать на лету. Создаём такой именованный access-лист. Указываем IP access-лист. Дальше выбираем, какой из двух типов access-листов мы хотим создать. Учитывая, что мы должны будем определять IP-шники назначения, вынуждены создавать расширенный access-лист. Даём ему какое-то название, например, blacklist.

И дальше у нас сначала должны идти какие-то строчки с IP-шниками, куда ходить нельзя, а потом самая последняя строчка должна указывать, куда ходить можно. И мы можем создать такую строчку, у которой номер будет заведомо большой, который заставит нас перенумеровывать access-лист ещё не очень скоро. Мы указываем, что первая строчка с IP-шником, куда ходить нельзя, будет иметь номер, например, 10. Указываем, что ходить нельзя по любому протоколу, откуда угодно, на IP-шник, куда нельзя. А тысячная строчка указывает, что всё остальное делать можно. И такой access-лист мы вешаем на интерфейс, например, gigabit 0.1. Показывается IP access group blacklist in, что на этом самом интерфейсе мы фильтруем трафик на входе на наш роутер. И если вдруг пакеты пойдут на чёрный список, то мы такие пакеты пристрелим.

Если вдруг понадобится новый адрес добавить в этот самый чёрный список, куда ходить нельзя, заходим в процедуру редактирования access-листа — IP access-list extended blacklist, то же самое, что здесь было — и добавляем новую строчку, например, с номером 20. Запретить что угодно, откуда угодно, на такой IP-шник. Этот механизм позволяет нам редактировать чёрный список, поскольку именованные access-листы мы имеем возможность адаптировать — мы можем на лету добавлять в них новые строчки, и нам ещё не скоро потребуется перенумерация этих самых строчек. Причём, если потребуется, никаких проблем — перенумеровываем. Вот такие механизмы у нас есть для управления access-листами. Далее. У нас есть некоторое количество загадок на access-листы. И, как правило, эти загадки будут сформулированы либо так, как на первом слайде, либо чуть дальше они будут сформулированы немножко иначе, но смысл примерно будет следующий.

У нас есть сеть. Эта сеть состоит из двух роутеров, к которым подключено по две сети с пользователями. На роутере R1 у нас есть одна сеть 192.168.1.0, другая сеть 192.168.2.0, и на роутере R2 — 10.0.1.0, 10.0.2.0. И плюс они между собой связаны некоторой тоже IP-сетью, point-to-point. На интерфейсе роутера R2 на вход повешен аксесс-лист. Тот самый аксесс-лист, который показан будет под слайдом. Не надо ожидать подвоха в том, что аксесс-лист висит не на этом интерфейсе или там какой-то другой аксесс-лист висит. Если показан какой-то аксесс-лист, то предполагается, что именно он висит в том самом месте, которое там нарисовано.

Загадка заключается вот в чём. IP-аксесс-лист висит здесь. Вот такое у него содержание. И узел 192.168.1.2 не может подключиться к 10.0.1.2, хотя администратор, который вводил этот аксесс-лист, предполагал, что он сделает всё таким образом, чтобы узел подключаться всё-таки мог. Что-то попытался сделать, настроил и смотрит на результат. Результат такой, что узел не подключается. И возникает вопрос, почему так? Загадка самая первая, она довольно лёгкая, поэтому подумайте, пожалуйста, над ней — что здесь может быть не так. Что здесь мы видим? Давайте посмотрим на адреса, которые у нас есть. 192.168.1.2. Найдём его. Вот он. 10.0.1.2. Вот он. Трафик, который пойдёт от 192.168.1.2, пойдёт по такой трассе. Аксесс-лист, который у нас висит, висит в нужном направлении, он висит на вход.

И мы смотрим на то, что этот аксесс-лист будет делать. Он говорит permit 10.0.1.2. 10.0.1.2 — это адрес назначения. В то же время стандартный аксесс-лист не умеет смотреть на адреса назначения. Он умеет смотреть только на адреса источника. И адрес источника в тех пакетах, которые проходят через этот аксесс-лист, он, естественно, 192.168.1.2. Поскольку у нас первая строчка пермитит какой-то один IP-шник, который не тот, всё остальное она сбрасывает. И как следствие, пакеты из-под 192.168.1.2 не пройдут через такой аксесс-лист. Это вполне естественное следствие. В то же время, если бы мы хотели именно такой аксесс-лист использовать, мы могли бы его использовать, но на выход. И пакеты, которые бы выходили из 10.0.1.2, они бы проходили через этот аксесс-лист, и всё было бы хорошо.

Либо этот аксесс-лист надо было в другом направлении вешать, либо на вход здесь. Но да, это было бы что-то уже совсем другое, какая-то совсем другая история. Поэтому да, действительно, здесь администратор немножко ошибся. Ошибся он в том, что не посмотрел, где и что он может фильтровать. Стандартные аксесс-листы не могут фильтровать адреса назначения, они могут фильтровать только адреса источника. И адрес источника здесь, очевидно, 192.168.1.2. Если мы хотим исправить ситуацию, то здесь у нас вместо IP-шника назначения должен быть 192.168.1.2. Или аксесс-лист поместить в другое место. Вторая загадка. Точно та же самая сеть, точно тот же самый интерфейс. Там точно висит IP-аксесс-лист. Содержимое аксесс-листа здесь нам показали. Администратор решает всё ту же самую проблему. 192.168.1.2 должен подключаться к 10.0.1.2.

И что-то как-то не получается. И вопрос, почему? Если здесь посмотреть на то, что в аксесс-листе написано, то у нас здесь, опять же, одна строчка, которая что-то разрешает. И судя по тому, что узел не может подключиться, эта строчка не срабатывает. Требуется, чтобы узел мог подключиться. У нас есть строчка, которая что-то разрешает, но, видимо, недостаточно хорошо разрешает. И если мы внимательно посмотрим на содержимое аксесс-листа, мы увидим permit 192.168.1.0 по какой-то маске. С предыдущей загадки мы уже помним, что здесь IP-шники источника именно 192.168.1.2 будут. И эта строчка 192.168.1.0 по 255.255.255.0 — она похожа на то, что действительно IP-шники будут именно такие, которые надо. Но проблема в том, что это аксесс-лист, и в аксесс-листах у нас маски перевёрнуты, или wildcard.

И когда мы указываем маску 255.255.255.0 в аксесс-листе, она указывает: неважно, какие первый, второй, третий октеты у нас будут. Главное, чтобы четвёртый октет в изучаемых IP-шниках совпадал с четвёртым октетом эталона. А эталон у нас заканчивается на ноль. Поэтому те пакеты, которые будут идти с IP-шников источника, заканчивающихся на ноль, такой аксесс-лист пропускать будет. Всё остальное он будет сбрасывать. В нашем случае у нас IP-шник не заканчивается на ноль. Он будет 192.168.1.2, и он не будет нормально работать через такой аксесс-лист. Для того чтобы поправить эту ошибку, достаточно использовать маску wildcard. Не 255.255.255.0, как здесь, а 0.0.0.255. Довольно частая ошибка. Не попадайтесь на неё. Shame on you.

Дальше. Третья загадка. Та же самая сеть, та же самая конфигурация, точно такой же интерфейс, точно там же аксесс-лист висит, и по-прежнему у нас администратор пытается нарисовать такой аксесс-лист, который позволил бы узлу 192.168.1.2 подключиться к 10.0.1.2. Но что-то у Данилы каменный цветочек не выходит. Что здесь придётся разобрать? У нас те же самые айпишники 192.168.1.2 и 10.0.1.2. Путь трафика по-прежнему должен быть вот такой. И обратные пакеты тоже, естественно. Обратные пакеты нас не интересуют, потому что направление аксесс-листа у нас на вход. Проверяем, что аксесс-лист у нас содержит. Первая строчка — запретить 192.168.1.0 по правильной маске. И вторая строчка — разрешить 192.168.1.2. Если это показать человеку, он, конечно, скажет: да, разрешить 192.168.1.2,

вот у нас 192.168.1.2, его и разрешить. Но здесь у нас важен порядок строк. Компьютер, к сожалению, не человек, поэтому для него порядок строк имеет явный приоритет. И компьютер проверяет первую строчку, десятую строчку, и говорит: если у нас есть совпадение с этой строчкой, то мы говорим «нет». И соответственно, все остальные строчки просто не проверяем. У нас совпадение здесь есть. Мы говорим: первые три октета в изучаемых образцах должны совпадать с первыми тремя октетами в эталоне. У нас совпадение в первых трёх октетах есть, поэтому мы выносим вердикт deny. До второй строчки 192.168.1.2 с permit дело просто не доходит. Поэтому, если мы хотим исправить такой аксесс-лист, мы должны будем поменять местами десятую и двадцатую строчку. Более общие правила должны находиться после более специфичных, более конкретных, более частных. Четвёртая загадка. У нас есть узел для разнообразия

192.168.2.2, который не может подключиться к тому же самому узлу 10.0.1.2 по протоколу TFTP. Хотя администратор пытался сделать какое-то правило, которое разрешит это. Пытался по мере своих возможностей. И соответственно, вопрос: а что не так? Где ошибка? И как сделать так, чтобы 192.168.2.2 к 10.0.1.2 по TFTP подключиться всё-таки смог бы. Если посмотреть на то, какой у нас здесь будет аксесс-лист, мы можем по строчкам пробежаться. Первая строчка — запретить. Мы внутренне напрягаемся, потому что «не может подключиться» и «запретить» как-то между собой наверняка могут быть связаны. 192.168.0.0 по маске 0.0.255.255. 192.168 вроде попадает. Куда угодно по протоколу Telnet. Расслабляемся. У нас не Telnet, у нас TFTP.

Дальше. Вторая строчка, она же 20-я. Запретить. Здесь мы опять внутренне напрягаемся. Какая сеть? Именно 192.168.2.2. И здесь у нас 192.168.2.2. Мы по-прежнему внутренне напрягаемся. Куда? 10.0.1.2. 10.0.1.2. Внутренне напрягаемся. EQ 69. 69-й порт совпадает с TFTP, но есть нюанс. TFTP — это UDP 69-й порт. А здесь у нас стоит TCP. Поэтому 20-я строчка не срабатывает. Это не то, что нам мешает пройти по протоколу TFTP. Третья строчка. Разрешает подключение по TCP откуда угодно, куда угодно. И в принципе всё бы ничего. Но у нас есть проблема с тем, что TCP здесь никакого отношения к нам не имеет. Поэтому последняя неявная строчка — запретить всё остальное. Она как раз и запрещает прохождение трафика по TFTP. Для того чтобы у нас TFTP мог ходить,

нам нужно будет сделать строчку, в которой это будет разрешено. Строчка будет, возможно, иметь вид... Здесь будет написано permit. Здесь будет соответственно... UDP. UDP. Host останется. Да, всё остальное останется соответственно без особых проблем. И такая конфигурация уже работать будет. Так. Пятая загадка. 192.168.2.2. Тот же самый IP-шник. 10.0.1.2. Тоже тот же самый IP-шник. Но немножко изменилось условие задачи. Администратор пытался сделать так, чтобы 192.168.2.2 не мог подключиться по Telnet, и пытался реализовать запрет на этот самый Telnet, но у него получилось плохо, потому что 192.168.2.2 по Telnet к 10.0.1.2 подключиться таки может. И вопрос: как сделать так, чтобы администратор свою ошибку нашёл и исправил?

Так. Что у нас здесь получается? У нас есть 192.168.2.2. Вот он. У нас есть 10.0.1.2. Вот он. Соответственно, трафик идёт по вот такому маршруту. И как видим, мы проходим по этому маршруту, почему-то мы знаем, что 192.168.2.2 почему-то по факту может подключиться, хотя и не должен. Давайте анализировать аксесс-лист, который будет висеть на входе и должен такое поведение фильтровать. Первая строчка. Запретить подключение по Telnet. У нас Telnet. Telnet. Всё правильно. Откуда угодно. У нас откуда угодно — 192.168.2.2. Но вот это EQ Telnet — смотрите, эта конструкция накладывает ограничения на порт источника, а вот это — на сокет источника, более строго, а вот это — на сокет получателя. В сокете источника порт у нас не будет Telnet. Когда идёт подключение по Telnet, тут будет хорошо известный 23-й порт, а здесь порт,

скорее всего, будет какой-нибудь динамический, выбранный из диапазона с 1024 по 65535. Поэтому здесь мы порт источника предсказать не можем, и когда мы будем видеть прохождение телнетовского пакета сюда, по этому интерфейсу, порт источника 23-м не будет почти точно. Порт получателя 23-м будет, но на него мы не накладываем никаких ограничений во второй части. Вторая строчка. Запретить подключение по TCP из-под нашего хоста на хост 10.0.1.2, но дополнительное ограничение по протоколу SMTP. Здесь EQ SMTP стоит в правильном месте. Оно указывает ограничение на порт получателя. И если бы подключение шло по SMTP, то здесь порт получателя был бы 25-й, и соответственно, оно попадало бы под это правило. Но у нас подключение идёт по Telnet, поэтому вторая строчка не срабатывает

для Telnet, и как следствие, ничего лишнего для нас не фильтрует. И соответственно, 30-я строчка — разрешить всё остальное. Это именно та строчка, по которой у нас прохождение трафика по факту срабатывает. Если бы мы хотели запретить прохождение трафика Телнетовского, то мы должны были бы понять, какую строчку имел в виду администратор. Скорее всего, он имел в виду вот эту вот первую строчку или десятую по номеру. И тогда он должен был вот эту вот EQTелнет перенести вот сюда вот. Так. Дальше. Шестая загадка. 192, 168, 1, 2, вот этот вот снова узел, может подключиться к 10, 0, 1, 2, к вот этому вот узлу по протоколу Телнет. Хотя политика безопасности, опять же, это запрещает, а наш администратор пытался реализовать запрет, возникает вопрос, что он на этот раз сделал не так и как его исправить ситуацию. давайте посмотрим на то, что у нас тут

получается. Соответственно, трафик, который идет от 192, 168, 1, 2, идет на адрес 10, 0, 1, 2, и у нас он идет по вот такому вот маршруту. Аксесс-лист, который висит, он фильтрует трафик на вход, и, соответственно, содержимое у него будет вот такое. Первая строчка запрещает подключение по TCP откуда из под 10, 1, 1, на куда угодно по протоколу Telnet. Что такое 10, 1, 1, 1? Это вот этот вот адрес. Но, соответственно, этот адрес не появляется в наших пакетах от 192, 168, 1, 2 на 10, 0, 1, 2. Если мы не задействуем механизм NAT, про который мы будем говорить в следующем модуле, то адреса, которые указаны в IP-пакете, не меняются при транзите этого пакета. Поэтому пакет у нас идет из-под оригинального адреса 192, 168, 1, 2 на оригинальный адрес 10, 0, 1, 2. IP-адрес самого роутера, через который пакет проходит,

в пакете не фигурирует. Поэтому эта строчка не срабатывает. Она срабатывала бы, если бы сам роутер R1 посылал бы запросы на Telnet. Но это не наш случай. Вторая строчка запретить TCP 192, 168, 1, 2 на 10, 0, 1, 2. Вроде IP-шники наши, но следующее ограничение на порт получателя E-QoS-MTP намекает на то, что это про электронную почту. И, соответственно, последняя строчка разрешит все подряд куда угодно. Очевидно, что здесь администратор, который пытался настроить аксесс-лист, предположил, что трафик, который идет от IP-шника 10.1.1, вот этот вот, что он каким-то образом, да, вот этот вот адрес там фигурирует в самих пакетах. Нет, он не фигурирует в самих пакетах. Если администратор хотел сказать, что все, что идет через роутер R1 по вот этому вот каналу должно фильтроваться, если оно идет по телнету,

то эту строчку имеет смысл немножко переписать, убрать оттуда вообще упоминание вот этого IP-шника 10.1.1. Сказать здесь any, и это будет ровно то, что нужно. Любой трафик, который идет, он проходит по этому проводу, и мы его запрещаем. Ну и альтернативные варианты, да, можно еще одну строчку вот как 20-е сделать, только другую и записать там телнет. Ну то есть смысл от этого не сильно изменится. Следующая загадка. Узел 10.0.1.2 может подключиться к 192.168.1.2 по телнету, хотя политика безопасности это запрещает. Вопрос, что именно администратор упустил и как это исправить? Давайте смотреть на то, что здесь у нас в итоге получается. То есть та же самая сеть, то же самое здесь 192.168.1.2 10.0.1.2 и вот аксесс-лист, который фильтрует трафик. Узел 10.0.1.2 может подключиться к 192.168.1.2

Вот 10.0.1.2 вот 192.168.1.2 Трафик, который будет идти, он будет идти вот по такому вот направлению. И, соответственно, аксесс-лист, который будет здесь висеть, он этот трафик прямой обрабатывать не будет. Он в лучшем случае будет ловить обратный трафик, который будет идти от 192.168.1.2 на 10.0.1.2 Давайте посмотрим на содержимое этого аксесс-листа, который здесь у нас есть. Первая строчка запретить подключение по TCP откуда? С 10.0.1.2 с вот этого адреса куда угодно по протоколу Телнет. Эта строчка не сработает, потому что для пакетов от 10.0.1.2 куда угодно, которые пойдут через этот интерфейс, они будут идти наружу, а не вовнутрь. Обратные пакеты будут идти с 122.168.1.2 на 10.0.1.2, поэтому эта строчка не сработает здесь на вход никогда. Вторая строчка запретить подключение откуда угодно по SMTP

или там ниоткуда угодно, неважно, короче, это явно не наш случай. И третья строчка разрешает все остальное. Если мы хотим сделать так, чтобы этот access-list у нас ловил трафик от 10.0.1.2 на 192.168.1.2, надо его либо развернуть, либо немножко переписать. Ну, если развернуть, здесь все просто. Та же самая строчка deny.tcp host any чего-то там host такой-то any yakutil.net, но только вешать его на выход, это очевидное решение. Второй вариант, это если мы хотим сохранить направление access-листа, но, соответственно, переписать его так, чтобы он срабатывал для нужного нам сценария, это сказать, что подключение должно идти из-под any yakutil.net. Это как бы ограничение на источника. И, соответственно, any это ограничение на получателя. То есть, вот это

источник, вот это получатель. И тогда пакеты с установлением син, соединения с флагом син пройдут нормально, а вот ответы, которые пойдут через этот интерфейс, они будут проходить через access-лист, там будут содержаться син плюс ак флаги, и, соответственно, они будут идти из-под 23-го порта на порт какой-то там случайно динамический 1024. И именно из-под IP-шников, которые здесь нужны. То есть, здесь у нас будет, там, не знаю, host 10.0.1.2, вот тут вот. И оно, правило будет срабатывать для этого случая. То есть, оба варианта здесь сработают, либо менять направление access-листа, либо переписать его таким образом, чтобы он ловил обратные пакеты в рамках установленной тело-нет-сессии. какой вам больше нравится, такой используйте. Понятное дело, что более корректно здесь, наверное, будет развернуть access-list для того, чтобы не пропускать вообще никакие пакеты

в рамках запрещенной сессии. Ну и последняя загадка. Та же самая сеть, тот же самый access-list в том же самом месте висит. Узел 192.168.1.2 может подключиться к роутеру R2 по протоколу тело-нет, хотя в access-list написано, что так делать нельзя. Опять администратор сидит, ломает голову, как такое получилось и почему злой злоумышленник, злой юзер, который вот здесь вот находится, злорадно ухмыляется и получает доступ к атаку тело-нет. Как сделать так, чтобы такого не было? Смотрите, как тут выглядит сеть. У нас есть вот этот вот нехороший человек, который сидит и ухмыляется и получает доступ к консоли роутера. И этот самый доступ не консоли к VTI, к тело-нету. И этот доступ он получает, отправляя какие-то пакеты, которые пробегают по вот этому пути и втыкаются в роутер R2 и дальше роутер R2 их потребляет. Если мы посмотрим на access-list,

который здесь фильтрует трафик, то мы увидим, что первая строчка запрещает подключение по TCP откуда угодно на 10.101.2 по тело-нету. Если вот этот вот товарищ нехороший использует IP-шник 10.101.2, то есть IP-шник вот роутер R2, который прямо на самом интерфейсе висит, он действительно не получит доступа ни к чему, потому что эта строчка сработает. Но не срабатывает она, потому что в пакетах, которые отправляет вот этот вот нехороший человек, IP-шник получателя не 10.101.2, а другой. Он отправляет эти пакеты на другие адреса, которые на этом же роутере есть. Например, на 10.0.1.1 или на 10.0.2.1. Поэтому такие пакеты проходят через пакетный фильтр и по permit IP-Ani они доходят до роутера R2, который их потребляет и, соответственно, отправляет ответы из-под тех IP-шников, которые были указаны в пакетах. Для того, чтобы здесь решить проблему,

надо не вот этот вот IP-аксес-лист допиливать, а надо воспользоваться правилом, что ограничение на доступ к самому роутеру мы делаем не с помощью пакетных фильтров, а делаем с помощью access-class на VTI-ке. У нас есть VTI-ка, у нас есть линия управления, вот на линии управления мы вешаем access-листы. И эти access-листы должны быть стандартными. Ну, не то, что прям должны, они лучше всего их делать стандартными. Стандартный access-лист проверяет только IP-шник источника. Нет смысла в VTI-ке проверять IP-шник назначения. Вот здесь как раз прекрасный пример того, что нет смысла проверять IP-шник назначения, потому что IP-шников может быть много, и пакет, который дойдет на роутер, он может идти на любой из IP-шников этого роутера. Перечислять их все сегодня бесполезное явление, потому что завтра у вас появится еще один интерфейс, на нем будет еще один IP-шник, на него снова можно будет подключиться. В таком пакетном фильтре нет смысла этого делать. Поэтому у вас есть VTI-ка,

на нее вешаем access-лист, не фильтруем там IP-шник получателя, фильтруем только IP-шники источника и смотрим, что, соответственно, там у нас в итоге получилось. Вместо того, чтобы вот здесь с помощью пакетного фильтра это делать, следует вообще всю конфигурацию переделать и повесить access-лист на VTI-ку на раутере R2. Ошибка здесь заключается в том, что использован неверный механизм фильтрации. Не надо это делать с помощью пакетного фильтра. Я понимаю, что загадка была сложная, что да, здесь есть определенная подлость в этой загадке, но, тем не менее, в реальности все эти механизмы встречаются, все эти загвоздки тоже встречаются, поэтому вы должны про них, конечно же, знать. На этом тему безопасности рамочно разобранную я предлагаю считать в рамках нашего курса закрытой и переходить к следующим темам.