Для тех, кто не знает с чего начать…

Практическая
безопасность сетей
Ольков Евгений, 2017
blog.netskills.ru
От автора 6

О чем эта книга? 6

Для кого эта книга? 7

Применение 8

Введение 9

Миф безопасности 9

1. Доступ к оборудованию 11
1.1 Физический доступ 11
1.1.1 Вход в систему 12
1.1.2 Задаем пароль на enable 14
1.1.3 Создание пользователей 18
1.1.4 Подключение по консоли 20
1.1.5 Сброс пароля 21
1.2 Удаленный доступ 22
1.2.1 VTY 23
1.2.2 Telnet 25
1.2.3 SSH 26
1.2.4 HTTP/S 29
1.2.5 Ограничение доступа 31
1.2.6 Списки доступа к оборудованию 32
1.2.7 Защита от Brute Force 33
1.2.8 Идентификация устройства 34
1.3 AAA 36
1.3.1 RADIUS 37
1.3.2 TACACS+ 38
1.3.3 RADIUS vs TACACS+ 38
1.3.4 Настройка ААА-сервера 39
1.3.5 Настройка Authentication 42
1.3.6 Настройка Authorization 44
1.3.7 Настройка Accounting 46
1.3.8 Ограничения ААА 46
1.4 Парольная политика 47
1.5 Чек-лист №1 51
1.6 Пример конфигурации 52

2. Лучшие практики 54
2.1 Logs 54
2.1.1 Методы сбора логов 55
2.1.2 Уровни логирования 55

1
 2.1.3 Console Logging 56
2.1.4 Buffered Logging 56
2.1.5 Terminal Logging 57
2.1.6 Syslog-сервер 57
2.1.7 SNMP Traps 59
2.1.8 Безопасность логов 59
2.1.9 Время 60
2.2 Лишние сервисы 61
2.3 Резервная память 62
2.4 Защищенные протоколы 62
2.4.1 SCP 62
2.4.2 SNMP 63
2.5 Резервные копии 64
2.6 Логирование команд 66
2.7 Обновления 66
2.8 Чек-лист №2 67
2.9 Пример конфигурации 68

3. Защищаем локальную сеть 70

3.1 Уровень доступа 71
3.1.1 Сегментация 71
3.1.2 Неиспользуемые порты 73
3.1.3 VLAN1 73
3.1.4 DTP 75
3.1.5 Trunk - порты 76
3.1.6 Имена портов и VLAN 78
3.1.7 Штормы 79
3.1.8 PortFast 80
3.1.9 BPDU Guard 81
3.1.10 Port Security 83
3.1.11 DHCP snooping 84
3.1.12 IP Source Guard 86
3.1.13 Dynamic ARP Inspection 87
3.1.14 IEEE 802.1X 87
3.2 Уровень распределения и ядра 88
3.2.1 STP priority 88
3.2.2 Root Guard 89
3.2.3 RSTP 89
3.2.4 Общие рекомендации 90
3.3 Чеклист №3 90
3.4 Пример конфигурации 91

4. Управление безопасностью 95

2
 4.1 Иерархия средств защиты 96
4.2 Политика безопасности 97
4.2.1 Верхний уровень 98
4.2.2 Средний уровень 98
4.2.3 Нижний уровень 99
4.2.4 Пример политики безопасности 99
4.4 Чеклист №4 100

5. Управление доступом 101

5.1 С чего начать? 101
5.2 Что защищать? 102
5.3 От чего защищать? 102
5.4 Как защищать? 103
5.5 Чем защищать? 104
5.6 Списки доступа 105
5.6.1 Матрица прав доступа 106
5.6.2 Методы назначения прав. RBAC 108
5.6.3 VLAN и RBAC 109
5.6.4 Порты 109
5.6.5 Входящий или исходящий 111
5.6.6 Два главных подхода 112
5.7 Лучшие практики 113
5.7.1 Именованные списки доступа 114
5.7.2 Логирование правил 114
5.7.3 Топ-правила 115
5.7.4 Неиспользуемые правила 116
5.7.8 Паразитный трафик 116
5.8 Обратные списки доступа 117
5.9 Чеклист №5 117
5.10 Пример конфигурации 118

6. Защита периметра 120

6.1 Stateful Packet Inspection 121
6.2 Zone-Based Firewall 123
6.2.1 Подготовка (NetFlow) 124
6.2.2 Zone 126
6.2.3 Zone-pair 126
6.2.4 Class-map 127
6.2.5 Policy-map 129
6.2.6 Service-policy 129
6.2.7 Интерфейсы 130
6.2.8 DoS 130
6.3 DMZ 131

3
 6.3.1 Зачем? 131
6.3.2 Лишние сервисы 132
6.3.3 Private VLAN 133
6.4 Чеклист №6 136
6.5 Пример конфигурации 136

Заключение 141

4
Посвящается моей жене Ксении и маленькому сыну Степану, которые всегда
меня поддерживали и были моей самой главной мотивацией.

5
От автора
Данная книга является результатом нескольких лет работы в области
системной интеграции, а также основана на анализе и переработке огромного
количества профессиональной литературы. Руководство носит исключительно
информативный характер. Приведенные рекомендации всего лишь личное мнение
автора и не являются абсолютной истиной!
Я буду придерживаться свободного стиля изложения и возможно у вас иногда
будет возникать ощущение, что вы читаете художественную, а не техническую
литературу. Надеюсь, что это позволит гораздо легче воспринимать весь материал.
Автор имеет техническое образование и совершенно однозначно не может
назвать себя писателем. Книга не проходила никакой модерации, поэтому с большой
долей вероятности вы встретите как орфографические, так и пунктуационные ошибки.
Заранее прошу прощения (буду благодарен, если вы сообщите мне об ошибках в
тексте)!
Кроме того, хотел бы обратиться к читателям с просьбой не
распространять эту книгу в сети Интернет. Автор потратил очень много сил на
ее написание. Хоть и небольшой доход от продаж книги позволяет поддерживать и
развивать бесплатный проект NetSkills, где и в дальнейшем будут публиковаться
бесплатные видео курсы.

О чем эта книга?

Если взять мою предыдущую книгу “Архитектура корпоративных сетей”, то
можно узнать практически о всех средствах защиты сети. Однако следует понимать,
что в той книге описывается идеальный случай, когда вы не ограничены бюджетом и
можете покупать все, что вам нужно. Также стоит помнить, что даже самый дорогой
межсетевой экран не сможет защитить вашу сеть, если вы не будете его настраивать
должным образом. Информационная безопасность это не результат, это непрерывный
процесс. Нельзя установить средства защиты и решить, что теперь ваша сеть
безопасна. Вам придется постоянно дорабатывать свою систему защиты.
Мы живем в реальном мире и далеко не всегда располагаем нужными
средствами в ИТ/ИБ бюджете для закупки тех или иных средств. Что же делать тем, у
кого отсутствует какое-либо оборудование для защиты сети? Неужели придется
поставить крест на безопасности? Многие так и делают, говоря: “О какой безопасности
может идти речь, если компания не хочет или не может выделять средства”. С этой
мыслью многие почему-то совершенно забывают о встроенных средствах защиты в
обычном сетевом оборудовании, не соблюдают простейшие правила безопасности и
оставляют огромные “дыры” в своей сети. Не делайте так. Если вы беретесь за
какую-то работу, то делайте ее максимально хорошо, используя все доступные
возможности.
По работе мне часто приходилось участвовать в очень крупных проектах, где
ставилась задача по защите сети в 5-10 тысяч пользователей. Закупалось огромное
количество дорого оборудования - межсетевые экраны, системы предотвращения

6
вторжений, прокси-сервера и т.д. Бюджет проектов исчислялся десятками миллионов
рублей. Представьте мое удивление, когда после внедрения таких “дорогущих”
проектов обнаруживалось, что на обычном сетевом оборудовании использовались
пароли вроде “admin” или “1234” (и эти пароли не менялись годами, даже после смены
системных администраторов). Для подключения к коммутаторам использовался
незащищенный протокол “Telnet”. В офисах стояли хабы, которые принесли сами
пользователи, “потому что им так удобнее”. В корпоративную сеть подключались
личные ноутбуки сотрудников. В ИТ инфраструктуре была полная анархия.
Таким образом, несмотря на потраченные миллионы, такую сеть мог бы
“положить” даже школьник в течении 5 минут. А все из-за безалаберного отношения к
обычным коммутаторам и маршрутизаторам, которые обычно никто даже не
рассматривает в качестве средств защиты.
-----------------------------
В данной книге мы узнаем каким образом можно “закрутить гайки
безопасности” на обычных коммутаторах и маршрутизаторах. Попробуем описать
лучшие практики по настройке оборудования и процессы, необходимые для
обеспечения информационной безопасности.
-----------------------------

Для кого эта книга?

Современный работодатель считает (или хочет так считать) что ИТ-специалист
и специалист по ИБ, это одно и то же. Безусловно это не так. Это совершенно разные
профессии. Но в силу различных обстоятельств (не зависящих от нас), очень часто
приходится совмещать эти две профессии. Возможно кого-то возмутит данный факт,
но я убежден, что любой уважающий себя ИТ-специалист должен обладать хотя бы
элементарными знаниями в области сетевой безопасности и придерживаться
некоторых принципов при построении или администрировании сети.
-----------------------------
Если перед вами вдруг встала задача обезопасить свою сеть, но тема
сетевой безопасности для вас темный лес, то стоит начать именно с этой книги.
-----------------------------
Безусловно, это руководство не сделает из вас эксперта в области ИБ. Но мы и
не ставим такой цели. Эта книга для тех, кто хочет в кратчайшие сроки улучшить
защиту своей сети. Выжмите максимум из имеющегося оборудования, а уж затем
можно думать о таких вещах как DLP, SIEM, Proxy, IPS и т.д. Строительство дома
всегда начинается с фундамента. В нашем случае, фундамент безопасности -
грамотно настроенное сетевое оборудование и выстроенный процесс сопровождения
сети.
Эта книга будет вам интересна, если вы:
1. хотите узнать об основных опасностях для вашей сети;
2. хотите узнать как от них защищаться;
3. вам нужны практические советы по защите сети;
4. хотите стандартизировать настройки безопасности для сетевого
оборудования;

7
 5. вам интересны лучшие практики в области сетевой безопасности;
6. просто интересуетесь сетевой безопасностью.
Также это руководство отлично подойдет для обучения сотрудников внутри
организации - сетевых инженеров и системных администраторов. Данная книга
особенно рекомендуется для завершивших “​Курс молодого бойца​”, как логическое
продолжение основ сетевых технологий.

Применение
Данное руководство описывает основные аспекты построения защищенной
сети на основе коммутаторов и маршрутизаторов, без использования
специализированных средств (межсетевых экранов, IPS, DLP и т.д.).
-----------------------------
В книге будут даны не только рекомендации, но и конкретные примеры
конфигурации оборудования. Все примеры будут касаться исключительно
оборудования компании Cisco Systems.
-----------------------------
Это не значит, что если вы используете коммутаторы другой фирмы, то данная
книга вам не подойдет. Все описанные настройки присутствуют в подавляющем
большинстве сетевого оборудования. Принцип остается тем же, отличаться будет
только синтаксис команд.
Следует отметить, что описанные в книге методы не гарантируют абсолютной
безопасности вашей сети. Руководство дает некий “шаблон”, придерживаясь которого
вы сможете существенно обезопасить сетевую инфраструктуру.
Также предполагается, что читатель обладает необходимым уровнем знаний и
способен отличить коммутатор от маршрутизатора.
После прочтения данного руководства настоятельно рекомендую к
ознакомлению книгу “Архитектура корпоративных сетей”. Книга познакомит вас с
принципами построения более комплексной и надежной защиты на основе
специализированных продуктов.
Важное замечание! Абсолютно все описанные технологии и настройки, можно
попробовать в ​GNS3​, ​UNetLab (EVE NG) ​или ​Cisco Packet Tracer​. Если у вас нет
опыта работы с данными программами, то вы можете воспользоваться бесплатными
видео уроками, которые вы найдете на сайте ​blog.netskills.ru​.

8
Введение
Информационная безопасность (ИБ). Это очень емкое понятие, которое
трактуется по-разному. Но почти всегда эту фразу ассоциируют с чем-то сложным,
непонятным и даже раздражающим. Некоторые пользователи вообще ненавидят эту
самую безопасность, особенно когда им неожиданно закрыли доступ к любимому
сайту или ограничили права на файловом хранилище. Большинство воспринимают ИБ
как нечто мифическое, пока сами не столкнутся с неприятностями. А учитывая
последние тенденции компьютеризации всего и вся, возможностей у
злоумышленников становится все больше, в то время как мы становимся все более и
более уязвимыми.
Многие часто используют понятие “сетевая безопасность” как синоним
“информационной безопасности”. Это в корне не верно. Под сетевой безопасностью
мы будем подразумевать защиту нашей ИТ - инфраструктуры от злоумышленников
(как внешних так и внутренних), а также защиту от случайных ошибок персонала. Да,
опасность исходит не только от хакеров. Наш собственный пользователь
представляет не меньшую опасность, сам того не подозревая.
Мы начнем с базовых вещей, которые можно сделать “здесь и сейчас”, без
серьезного переделывания сети. Уделим внимание типичным ошибкам
администраторов сети. Узнаем об основных угрозах для сети и каким образом от них
защититься. Рассмотрим лучшие практики по настройке оборудования.
К концу книги мы рассмотрим более сложные вещи. Научимся производить
простейший аудит сети. Узнаем каким образом разграничивать доступ к
корпоративным ресурсам и попробуем разработать свою первую матрицу доступа.
-----------------------------
В итоге мы получим некий “чек-лист”, на который следует ориентироваться
при построении безопасной сети.
-----------------------------

Миф безопасности
Прежде чем продолжишь повествование, я должен сделать небольшое
лирическое отступление.
-----------------------------
Если вас захотят взломать, вы не сможете этому противостоять. Чтобы
вы не делали.
-----------------------------
Возможно данный тезис не очень мотивирует к дальнейшему чтению, но нужно
правильно понимать смысл этого утверждения. Ни одна система защиты не даст 100%
гарантию. Пока вы дочитали до этой строки уже появилось несколько новых (ранее
неизвестных) уязвимостей, которые уже кто-то использует с весьма корыстными
целями. Обеспечение информационной безопасности похоже на гонку вооружений,
вот только хакер всегда на шаг впереди. Всегда будут первые жертвы, после которых
появляются описания данных брешей, выходят всевозможные патчи и обновления для

9
средств защиты. Периодически взламываются такие серьезные структуры как ФБР,
Пентагон, ФСБ, Kaspersky, где бюджеты ИБ исчисляются миллиардами, а в службе
безопасности работают лучшие из лучших. Но даже они не могут защититься от
таргетированных (целенаправленных) атак, когда высококлассный хакер кропотливо
пытается подобрать ключик к самой современной системе защиты. Как бы дико не
звучало, но даже полностью изолированные сети (отключенные от Интернета)
подвержены успешным атакам. Современные вирусы способны внедряться в
закрытые сети через флеш-носители сотрудников, собирать нужную информацию и
терпеливо ждать, когда они смогут выбраться через те же флешки.
Но зачем тогда защищаться, если все так плохо? Но все плохо только на
первый взгляд. Процент таких таргетированных атак ничтожно мал, по сравнению с
атаками “на дурака”. Подавляющее большинство вторжений в сеть происходит с
применением простейших и давно известных приемов. Для воспроизведения таких
атак не требуется быть хакером - экспертом. Достаточно скачать специализированные
дистрибутивы (например Kali Linux) и воспользоваться уже готовыми программами для
взлома. Не нужно глубокое понимание работы стэка TCP/IP, не нужно уметь
программировать, не нужно разбираться в современных средствах защиты. Просто
скачать дистрибутив, нажать пару кнопок и готово. Можно даже скачать готовый
вирус/троян и закинуть его по почте. Наблюдается интересная статистика, в
праздничные дни возрастает кол-во атак. Как вы думаете, почему? Из-за студентов и
школьников на каникулах, которые пробуют свои силы в хакинге с помощью
популярных и весьма доступных утилит.
Кроме того, как было сказано выше, угрозу представляют не только внешние
“враги”, но и внутренние пользователи. Неосторожные действия могут привести к
весьма длительному простою сети, либо открыть окно для внешнего злоумышленника.
Поэтому не стоит пенять на отсутствие средств защиты, забывая о грамотной
настройке основного сетевого оборудования. Даже на уровне коммутаторов и
маршрутизаторов вы сможете отсечь подавляющее большинство опасностей для
вашей сети.

10
1. Доступ к оборудованию
Ограничить доступ к сетевому оборудованию, как физически, так и удаленно.
Это первое с чего вы должны начать. Просто поразительно сколько неприятностей
происходит в корпоративных сетях только из-за неограниченного доступа к
оборудованию.

1.1 Физический доступ

Абсолютно в каждой компании найдется сотрудник, который считает себя
намного умнее системного администратора. И когда ему кажется, что в сети возникли
какие-то проблемы (или же ему захотелось поменять местами пару проводов) он
уверенно идет к коммутатору и делает все, что душе угодно (вплоть до перезагрузки
оборудования). В результате в сети возникают “петли”, либо просто путаница с
подключениями. Данный инцидент можно смело причислять к “вторжениям”. Это
прямая опасность для вашей сети.
В идеале все сетевое оборудование должно находится в серверной комнате,
которая закрывается на ключ и доступ туда имеет лишь ограниченный круг лиц. Но мы
живем не в идеальном мире и очень часто коммутаторы оказываются либо в коридоре
помещения, либо вовсе в кабинете под столом. Отличным решением в данном случае
будет установка специализированных телекоммуникационных шкафов. Наиболее
удобны небольшие настенные шкафы имеющие замок (см. рис. X).

Рис. X. Настенный 19 - и дюймовый шкаф.

Естественно, установленный замок не поможет от целенаправленной попытки

добраться до сетевого оборудования. Но мы и не ставим такой цели. Данный шкаф
это скорее “защита от дурака”. Вряд ли офисный сотрудник начнет ломать замок
желая переключить пару проводов. Именно это нам и нужно. В случае невозможности

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

1.1.1 Вход в систему

Для входа в саму операционную систему Cisco IOS есть два способа: через
консольный порт и удаленно (протоколы telnet, ssh, https). Прежде чем рассмотреть
вопрос удаленного доступа необходимо описать некоторые моменты, касающиеся
входа через консоль и в Cisco IOS в целом.
Возможно шкаф с замком не остановил злоумышленника и он получил прямой
физический доступ к коммутатору. Первое что он попытается сделать - подключиться
по консоли. Именно поэтому очень важно принять меры по защите консольного
подключения.
Наверняка большинство читателей уже немного знакомы с Cisco IOS, но я все
же расскажу несколько базовых вещей. Из соображений безопасности в Cisco IOS
существует два режима доступа к командной строке:
1. Пользовательский режим (User EXEC Mode). Если вы зашли на коммутатор или
маршрутизатор и видите приглашение вроде “​Switch>​”, т.е. строка
оканчивающаяся на знак “​>​”, то вы именно в пользовательском режиме. Из
данного режима невозможно производить настройку оборудования или
просмотреть текущую конфигурацию.
2. Привилегированный режим (Privileged EXEC Mode). В данном режиме
приглашение выглядит следующим образом - “​Switch#​”, т.е. заканчивается на
знак “​#​”. Для входа в данный режим необходимо ввести команду ​enable​. Из
данного режима можно производить настройку оборудования и просматривать
конфигурацию.
Многие почему-то пренебрегают защитой пользовательского режима и
оставляют вход по консоли совершенно открытым, ограничиваясь лишь паролем на
привилегированный режим (т.е. пароль на ​enable​). Казалось бы, из User mode
злоумышленник не сможет поправить или просмотреть конфигурацию. Но это
безопасно только на первый взгляд. Получив доступ к оборудованию из

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

Предположим что злоумышленник подключился по консоли к коммутатору

Switch1. Вход в привилегированный режим закрыт паролем. Для просмотра доступных
команд ему достаточно набрать знак “​?​”:

Switch>?
Exec commands:
connect Open a terminal connection
disable Turn off privileged commands
disconnect Disconnect an existing network connection
enable Turn on privileged commands
exit Exit from the EXEC
logout Exit from the EXEC
ping Send echo messages
resume Resume an active network connection
show Show running system information
telnet Open a telnet connection
terminal Set terminal line parameters
traceroute Trace route to destination

Как видим довольно большой список. По умолчанию на всех устройствах Cisco

включен протокол CDP. Это проприетарный протокол компании Cisco позволяющий
обнаруживать подключенное напрямую сетевое оборудование (опять же компании
Cisco). Какую же информацию можно получить набрав команду ​show cdp neighbors
detail​?
Switch>show cdp neighbors detail

Device ID: Switch

Entry address(es):
IP address : 192.168.1.3
Platform: cisco 2960, Capabilities: Switch
Interface: FastEthernet0/1, Port ID (outgoing port): FastEthernet0/1

13
Holdtime: 136

Version :
Cisco IOS Software, C2960 Software (C2960-LANBASE-M), Version 12.2(25)FX, RELEASE SOFTWARE (fc1)
Copyright (c) 1986-2005 by Cisco Systems, Inc.
Compiled Wed 12-Oct-05 22:05 by pt_team

advertisement version: 2
Duplex: full
---------------------------

Device ID: Switch

Entry address(es):
IP address : 192.168.1.4
Platform: cisco 2960, Capabilities: Switch
Interface: FastEthernet0/2, Port ID (outgoing port): FastEthernet0/1
Holdtime: 161

Version :
Cisco IOS Software, C2960 Software (C2960-LANBASE-M), Version 12.2(25)FX, RELEASE SOFTWARE (fc1)
Copyright (c) 1986-2005 by Cisco Systems, Inc.
Compiled Wed 12-Oct-05 22:05 by pt_team

advertisement version: 2
Duplex: full
---------------------------

Device ID: Router

Entry address(es):
IP address : 192.168.1.254
Platform: cisco C1900, Capabilities: Router
Interface: FastEthernet0/3, Port ID (outgoing port): GigabitEthernet0/0
Holdtime: 139

Version :
Cisco IOS Software, C1900 Software (C1900-UNIVERSALK9-M), Version 15.1(4)M4, RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2012 by Cisco Systems, Inc.
Compiled Thurs 5-Jan-12 15:41 by pt_team

advertisement version: 2
Duplex: full

Теперь злоумышленник знает практически все о нашей сети: ip адреса, модели

устройств и даже версии их прошивки. Сведения о прошивке позволяют использовать
известные уязвимости. Ситуация усугубляется тем, что далеко не все администраторы
следят за выходом новых прошивок, в которых закрываются эти известные
уязвимости. Кроме того, ему доступны такие команды как ​ping, traceroute, telnet,
show vlan, show arp и т.д. В итоге он получает идеальную площадку для сбора
информации и дальнейшей атаки, пытаясь проникнуть на другие устройства (telnet).
-----------------------------
Закрывайте доступ к консольному порту даже для пользовательского
режима.
-----------------------------
Ниже мы рассмотрим как сделать это правильно.

1.1.2 Задаем пароль на enable

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

14
 Большинство руководств в сети Интернет описывает процесс установки пароля
с помощью команд:

Switch#configure terminal /вход в режим глобальной конфигурации

Switch(config)#enable password cisco /установка пароля

Казалось бы, что на этом можно и закончить. Привилегированный режим

защищен паролем. Отчасти да. Однако стоит знать, что данный пароль хранится в
конфигурации устройства как обычный текст и если использовать команду ​show run​
,
то можно увидеть следующее:

Switch#show running-config | include enable password

enable password cisco /пароль хранится в открытом виде

Чем же это опасно? Возможно вы, как добросовестный администратор, храните

резервные копии конфигураций, что вполне логично. Как правило такие резервные
копии лежат на FTP либо TFTP сервере. Возможна ситуация, когда злоумышленник
получил доступ к этому серверу. Просмотрев конфигурации устройств и найдя пароли,
он получит доступ ко всей вашей сети. Другой вариант, когда вы открыли сессию
удаленного доступа (telnet, ssh) к одному из коммутаторов, но вас вдруг позвали в
другую комнату. Вы оставили окошко с открытой сессией буквально на 2 минуты.
Возможно этого времени недостаточно, чтобы внести серьезные изменения в
конфигурацию, но этого точно хватит, чтобы ваш коллега или случайный “прохожий” из
другого отдела успел подглядеть пароль. Более того, подсмотреть пароль могут
просто находясь у вас за спиной, когда вы просматриваете конфигурацию.
Очевидно, что пароль нужно хранить в зашифрованном виде. В этом случае в
сети Интернет советуют использовать следующую команду:

Switch(config)#service password-encryption

Данная команда призвана шифровать все имеющиеся пароли в конфигурации

устройства. Вот так выглядит пароль после применения команды:

Switch#show running-config | include enable password

enable password 7 0822455D0A16 /зашифрованный пароль

Как видим пароль уже выглядит совсем иначе. Это так называемые Type 7
пароли. Но и этого недостаточно. Дело в том, что команда ​service
password-encryption использует довольно слабый и широко известный метод
шифрования. Данные пароли очень просто поддаются дешифрации. В интернете
огромное количество утилит, которые позволяют это сделать. Яркий пример - утилита
Cain&Abel. Также доступны онлайн ​ресурсы (это всего лишь пример и вы можете
найти другие сайты используя в google поисковый запрос “cisco type 7 password
decrypt”). Давайте попробуем восстановить пароль из нашей зашифрованной
последовательности 0822455D0A16.

15
 Пароль успешно восстановлен. Таким образом, если злоумышленник все же
смог получить доступ к конфигурации устройства (или возможно он смог запомнить
зашифрованный пароль одним лишь взглядом), то он с легкостью расшифрует
реальный пароль. Шифрование здесь не помогло.
Для решения этой проблемы существует ​enable secret​. Именно эту команду
необходимо использовать при задании пароля. Функция secret использует совершенно
другой принцип. Вместо шифрования, пароль проходит через определенный алгоритм
(MD5) и на выходе получается так называемый hash (хэш).

Это операция в одну сторону. Ее можно сравнить с мясорубкой. Если вы

перекрутите кусок мяса в фарш, то обратно кусок мяса вы уже не получите никаким
образом. В конфигурации отображается именно hash, который невозможно
расшифровать. Для примера давайте зададим пароль и посмотрим, что получится на
выходе:

Switch(config)#enable secret cisco

Switch#show running-config | include enable
enable secret 5 $1$mERr$hx5rVt7rPNoS4wqbXKX7m0 /hash исходного пароля “cisco”

16
 В конфигурации мы видим hash нашего исходного пароля. Цифра “5” после
enable secret означает, что используется алгоритм хэширования (в случае с ​enable
password отображается цифра 7). Как было сказано выше, данный пароль
невозможно декодировать. Однако и это не дает нам 100% защиты. Данный пароль
можно брутфорсить (от англ. brute force), т.е. подбирать. В интернете существуют
таблицы, где для самых распространенных паролей приведены их хэши. Есть даже
специализированные сервисы, ​например (можете найти другой сервис в google,
используя запрос “Cisco IOS Enable Secret Type 5 Password Cracker”).

Если поместить наш хэш ($1$mERr$hx5rVt7rPNoS4wqbXKX7m0) в эту форму, то

в поле “Plain text” мы получим исходный пароль менее чем за секунду. Т.е. данный
сервис просто перебирает значения в таблице, где хранятся хэши часто используемых
паролей. Если же в существующей таблице нет приведенного хэша, можно
попробовать применить “атаку по словарю”. В этом случае подбирается пароль, затем
генерируется его хэш и сравнивается с исходным. В этом может помочь утилита
Cain&Abel. Преимущества данного брутфорса перед обычным (когда пароль
подбирается непосредственно на устройстве) в том, что вы не увидите данный
процесс в логах своего устройства и не сможете заблокировать IP адрес атакующего.
Получив доступ к вашей конфигурации, злоумышленник может неделями подбирать
пароль и вы об этом даже не узнаете.
Но данный брутфорс будет успешен, только если вы используете очень
простой пароль. Попробуйте сгенерировать с помощью enable secret хэш для более
сложного пароля и воспользуйтесь представленным выше сервисом (либо утилитой
Cain&Abel). В этом случае на подбор пароля могут уйти годы.
Какой вывод можно сделать? Как написано на картинке выше “Don’t use stupidly
simple passwords”. Думаю перевод не требуется. О том, как выбирать пароли мы
поговорим чуть позже.
-----------------------------
Не используйте ​enable password даже в связке с ​service
password-encryption​. Используйте сложные пароли и ​enable secret​.
-----------------------------
Важное замечание, если у вас в системе используется и пароль enable
password, и enable secret, то последний будет иметь более высокий приоритет (т.е. при
входе в привилегированный режим будет использоваться пароль заданный с помощью
enable secret).

17
1.1.3 Создание пользователей
Мы разобрались каким образом задавать пароль на вход в привилегированный
режим. Но этого недостаточно. Нам также необходимо защитить и пользовательский
режим, как это было описано выше. Для этого требуется настройка аутентификации по
учетной записи. В этом случае при входе на устройство (даже с консоли) необходимо
ввести логин (login) и пароль. Пример:
User Access Verification

Username: admin
Password:

Switch>

Для настройки учетных записей существует два основных способа:

1. Использование локальной базы пользователей. В этом случае учетные записи
создаются непосредственно на устройстве и хранятся в его памяти.
2. Использование AAA-серверов. Все учетные записи хранятся на выделенном
сервере. При этом нет необходимости создавать пользователей на сетевом
оборудовании.
Я категорически не рекомендую использовать первый способ. Он менее
безопасен, менее гибок и требует значительного внимания со стороны
администратора. Использование локальной базы затрудняет соблюдение парольной
политики (о которой мы поговорим чуть позже). Только представьте, что у вас около 30
сетевых устройств. И в компании три администратора с разными правами. Вам
придется зайти на каждое устройство и вручную “вбить” учетные записи. Когда придет
время менять пароли (а их нужно менять!), то данную процедуру придется повторить.
Поэтому я настоятельно рекомендую использовать AAA-сервера (о них мы поговорим
в следующей главе).
Но и не стоит забывать об адекватности применяемых решений. Как правило
AAA-сервер рекомендуется если у вас больше 10 устройств. Если в вашей сети всего
3 - 5 устройств, то установка AAA-сервера будет выглядеть немного странно. Поэтому
мы рассмотрим некоторые аспекты использования локальной базы пользователей.
Удивительно сколько внимания уделяется сложности паролей, но при этом все
забывают про еще один параметр учетной записи - имя пользователя.
-----------------------------
НИКОГДА не используйте стандартные учетные записи. Придумывайте
уникальные имена пользователей.
-----------------------------
Пример типичных учетных записей: admin, adm, administrator, root, cisco, user,
usr и т.д. При брутфорсе почти всегда идет подбор паролей к стандартным именам.
Задав уникальное имя учетной записи вы снижаете риск несанкционированного
доступа во множество раз. Даже если вы будете использовать стандартный пароль
вроде “cisco” или “1234” (хоть я это и не рекомендую), но имя учетной записи будет
нестандартным, то злоумышленник не сможет получить доступ методом перебора
паролей.

18
 Теперь рассмотрим сам процесс создания учетных записей на устройствах
Cisco. Как правило рекомендуют использовать команду:

Switch(config)#username admin privilege 15 password cisco

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

учетную запись ​admin​. Для задания пароля здесь используется ​password​, недостатки
которого мы уже обсудили выше. Используйте ​secret​. Про пароль комментарии
излишни. В этой команде есть еще один параметр, на который обычно не обращают
внимания - ​privilege​. Это уровень доступа. По умолчанию в Cisco IOS существует три
уровня:
1. Уровень привилегий 0 (privilege 0). Это самый низкий уровень из которого
доступны всего несколько команд: ​disable, enable, exit, help ​и logout​ .
Используется редко.
2. Уровень привилегий 1 (privilege 1). Соответствует пользовательскому режиму
(т.е. в качестве приглашения в командной строке ​switch>​). Команды из
привилегированного режима недоступны.
3. Уровень привилегий 15 (privilege 15). Привилегированный режим, где доступны
все команды (приглашение в командной строке ​switch#​).
Уровни 2-14 по умолчанию не используются, но команды, относящиеся к
уровню 15, могут быть перенесены на один из этих уровней, также как и команды с
уровня 1. Данная модель используется для разграничения пользователей в правах в
зависимости от их роли. К примеру, администратору Интернет-провайдерской сети
нужен доступ ко всем командам, поэтому ему понадобится наивысший уровень
привилегий, т.е. 15. Специалистам тех. поддержки из первой линии возможно нужны
только команды диагностики (вроде ​ping или ​show mac-address-table​), без доступа к
командам конфигурации . В таком случае подходит обычный пользовательский режим
- уровень 1. Остальные уровни (2-14) можно использовать для создания кастомных
(индивидуальных) профилей со строго определенным перечнем команд. Пример:
Switch(config)#username worker privilege 2 secret cisco/создаем пользователя
Switch(config)#privilege exec level 2 show running-config /определяем доступные команды
Switch(config)#privilege exec level 2 ping

Если зайти в систему под пользователем ​worker​, то вам будет доступно всего две
команды: ​show running-config​и p
​ ing​.
-----------------------------
Не создавайте учетные записи с уровнем привилегий 15. Пароль учетной записи и
пароль на ​enable​должны быть разными!
-----------------------------
Гораздо разумнее будет создавать пользователей с уровнем 1, тогда при входе
на устройство вы будете попадать в пользовательский режим (​switch>​). Для перехода
в привилегированный режим (​switch#​) будет необходимо дополнительно ввести
команду ​ enable и пароль. Это позволяет повысить уровень защищенности
(злоумышленнику придется угадывать два пароля вместо одного). Таким образом
создавая пользователя должна использоваться команда подобная примеру:

Switch(config)#username krok privilege 1 secret ​пароль

19
Здесь мы используем нестандартное имя учетной записи и пониженный уровень
привилегий. Вопрос выбора паролей будет описан чуть позже.
При использовании AAA сервера учетные записи не хранятся на оборудовании,
в этом случае можно присваивать уровень 15 (об этом мы поговорим чуть позже).

1.1.4 Подключение по консоли

Пароль на привилегированный режим задан, учетные записи созданы, пора
обсудить настройку подключения. Начнем мы с консоли. Как было сказано выше,
недостаточно задавать пароль только на привилегированный режим.
Несанкционированный доступ к пользовательскому режиму также очень опасен.
Поэтому мы настроим вход в консоль устройства по учетной записи, т.е. по логину и
паролю. Чаще всего в интернете можно встретить следующую инструкцию:
Router#conf t /вход в привилегированный режим
Router(config)#line console 0 /вход в настройки консоли
Router(config-line)#login local /указываем использование локальной базы пользователей

После этого при попытке входа в консоль устройства будет запрошен логин и пароль.
Однако это довольно старый способ и в любой современной литературе
используют новый метод, который так и называется ​new-model​. Настройка
производится следующим образом:
Router(config)#aaa new-model /указываем что будем использовать метод new-model
Router(config)#aaa authentication login default local /создаем method list

На этом настройка заканчивается. Если попробовать подключиться по консоли, то

получим следующее:
User Access Verification

Username: admin
Password:
Router>

Теперь разберемся с использованными командами:

● aaa new-model включает функцию ААА (Authentication Authorization and
Accounting) - систему аутентификации, авторизации и учета событий. Данная
функция встроена в большинство версий IOS, однако по умолчанию она
отключена. Преимущество ​aaa new-model в гибкости настройки
аутентификации (в отличие от ​login local​
).
● aaa authentication login свидетельствует о настройке аутентификации. При
этом создается так называемый метод аутентификации (​method list​
).
● default - имя метода аутентификации. Для метода аутентификации всегда
указывается имя (​list-name​). ​Это может быть либо default (как в нашем
примере), либо другое конкретное имя. Таким образом, на разные типы линий
(aux, vty, con...) можно назначить разные методы аутентификации, в
зависимости от политики безопасности.
● local​указывает на использование локальной базы пользователей.
В нашем примере используется ​method list под названием ​default​, а это
значит, что применяемые настройки касаются всех доступных линий на устройстве.

20
Таким образом мы одновременно настроили аутентификацию для консоли (​console​ )и
для удаленных подключений (​vty​).
Используя ​aaa new-model (вместо login local) в дальнейшем вы сможете более
плавно перейти к использованию AAA-серверов, т.к. там используется именно этот
метод. В главе AAA мы более подробно рассмотрим создание методов
аутентификации.
-----------------------------
Для настройки аутентификации используйте ​aaa new-model​.
-----------------------------
Как ни странно, все еще встречаются прошивки, которые не поддерживают AAA. В
этом случае ничего не остается, как использовать метод ​login local ​(либо обновить
прошивку).

1.1.5 Сброс пароля

Последний параграф из секции “Физический доступ” касается возможности
сброса пароля на устройстве. Казалось бы, вход в консоль устройства запаролен и
можно не волноваться даже если злоумышленник получил физический доступ к
оборудованию. Однако это ложное чувство безопасности. Все еще остается одна
лазейка. Подключившись к устройству по консоли довольно просто установить новый
пароль, даже не зная текущего. Вообще говоря, данная тема выходит за рамки книги,
но мы обязаны рассмотреть сам процесс сброса, чтобы понять, насколько это просто
сделать. Для примера рассмотрим алгоритм сброса пароля на коммутаторе:
1) Подключаемся по консоли к устройству (Мы рассмотрим пример с
коммутатором. Для маршрутизатора процесс немного отличается, но идея та
же.).
2) Вытаскиваем шнур питания коммутатора.
3) На лицевой панели коммутатора зажимаем кнопку ​mode​.

4) Вставляем шнур питания не отпуская кнопку ​mode​.

5) Не отпускаем кнопку ​mode до тех пор, пока индикатор над портом 1, не будет
гореть, как минимум 2 секунды.
6) Вводим в консоли устройства команду ​flash_init​.
7) Затем команду ​load_helper​.
8) Переименуем текущую конфигурацию командой ​rename flash:config.text
flash:config.old​. Таким образом, при загрузке коммутатор не увидит файл с
конфигурацией и запустится с заводскими настройками.
9) Загружаемся командой ​boot​ .

21
 10) Входим в привилегированный режим командой ​enable​. Вход будет без пароля.
11) Вернем название файла конфигурации: ​rename flash:config.old
flash:config.text​.
12) Теперь копируем первоначальную конфигурацию в текущую: ​copy
startup-config running-config​.
13) Мы оказались в привилегированном режим с первоначальными
конфигурациями. Для смены пароля необходимо войти в режим глобальной
конфигурации: ​conf t​.
14) Теперь мы можем делать с конфигурацией все, что угодно. Сменить пароль на
enable, создать своего пользователя, настроить удаленное подключение и т.д.
15) Со​храняем конфигурацию: ​copy running-config startup-config​ .
Вообще говоря, процедура сброса может отличаться от устройства к
устройству. Цель этого примера - показать наличие данной возможности. Как видим,
получить полный контроль над коммутатором или маршрутизатором не составляет
особого труда. При этом администратор сети может ничего не узнать, т.к. мы
сохранили первоначальную конфигурацию и это не скажется на работе сети (за
исключением времени, когда происходила перезагрузка коммутатора).
Чтобы избежать данной ситуации есть два варианта:
1. Ограничить физический доступ, как было сказано ранее. Сетевое оборудование
должно быть либо в серверном помещении либо в специальном
телекоммуникационном ящике с замком. К сожалению это не всегда возможно,
особенно для коммутаторов уровня доступа, когда подключаются обычные
пользователи.
2. Запретить возможность сброса пароля. Делается это на программном уровне
используя команду no ​service password-recovery​. Данная команда
поддерживается в относительно новых прошивках. После ее применения уже
не получится сбросить пароль с помощью описанной выше процедуры.
Злоумышленник все еще сможет сбросить устройство в заводские настройки,
но он не сможет получить доступ к текущей конфигурации. Однако подумайте
несколько раз, прежде чем использовать эту функцию. Возможна ситуация,
когда вы сами захотите сбросить пароль на устройстве (по причине его утери),
но сделать это вы уже не сможете. Лично я рекомендую использовать данную
функцию только на коммутаторах уровня доступа, находящихся вне серверной
комнаты.
-----------------------------
Запретите сброс пароля (​no service password-recovery)​ на коммутаторах уровня
доступа к которым возможен физический доступ.
-----------------------------

1.2 Удаленный доступ

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

22
1.2.1 VTY
Прежде чем приступить к описанию методов защиты, необходимо рассмотреть
сам процесс организации удаленного доступа. Если вам когда либо приходилось
настраивать “удаленку”, то вы обязательно сталкивались с такой аббревиатурой как
VTY - Virtual TeletYpe (хотя некоторые считают, что это расшифровывается как virtual
terminal, а “y” достался по наследству от tty, применяемого в linux… однозначного
ответа я так и не нашел). По-русски говоря это механизм позволяющий получить
удаленный доступ к так называемому ​command line interface (​cli​), т.е., по сути, к
виртуальной консоли устройства. Для подключения к этой самой ​vty могут
использоваться различные протоколы, о которых мы поговорим чуть позже.
Чаще всего в интернете можно встретить следующие инструкции по настройке
VTY​:
1) Вход по паролю
Router#conf t
Router(config)#line vty 0 4
Router(config-line)#password cisco
Router(config-line)#login

Как видим, в этом случае пароль задается непосредственно для VTY. Если
попытаться подключиться с помощью telnet, то увидим следующее:
Router#telnet 192.168.1.1
Trying 192.168.1.1 ...Open

User Access Verification

Password:

Никогда не используйте этот метод!

2) Вход по учетной записи (username и password)

Router#conf t
Router(config)#line vty 0 4
Router(config-line)#login local

Здесь уже есть такой параметр как ​local​, что означает использование локальной базы
пользователей (т.е. у вас уже должен быть хотя бы один созданный ​username​ ). При
попытке удаленного доступа получим следующее:
Router#telnet 192.168.1.1
Trying 192.168.1.1 ...Open

User Access Verification

Username: admin
Password:
Router>

Если ваше устройство не поддерживает функцию ​aaa new-model​, то этот способ

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

23
 Однако оба метода это устаревший вариант настройки. Как было сказано выше,
сейчас рекомендуется использовать ​aaa new-model​. В параграфе по настройке
консольного доступа (1.1.4) мы использовали следующие команды:
Router(config)#aaa new-model
Router(config)#aaa authentication login default local

В этом случае, благодаря параметру ​default мы настроили не только доступ по

консоли, но и для ​vty​. При этом мы указали, что нужно использовать локальную базу
пользователей (​local​).
-----------------------------
Для настройки удаленного доступа используйте ​aaa new-model​.
-----------------------------
Думаю у большинства читателей возникал вопрос, что это за цифры ​0 4​? К
тому же иногда встречаются ​0 15​. Что это значит? Эти цифры означают всего лишь
возможное количество удаленных подключений. Если мы используем ​vty 0 4​, то
создается 5 (0,1,2,3,4) виртуальных линий (консолей), к которым могут подключаться
пользователи. Если к устройству одновременно попытаются подключиться 6 человек,
то последний (шестой) не сможет этого сделать, т.к. все линии будут уже заняты.
Используя команду ​who можно посмотреть кто подключен к устройству и к какой
линии.

Изначально оборудование cisco поддерживало именно 5 подключений. Но

впоследствии эта цифра была увеличена до 16 (т.е. вариант ​vty ​0 15​). Если мы
используем метод ​aaa new-model​, то автоматически настраивается максимальное
количество виртуальных линий. Если же вы используете ​login local​, указав при этом
параметр ​
line vty 0 15​, то после настройки в конфигурации можно увидеть следующее:
line vty 0 4
login local
line vty 5 15
login local

Т.е. 16 линий разделились на две группы: ​0 4 и ​5 15​. Зачем это делается,

однозначного ответа нет. Скорее всего это сделано для некого разграничения прав
при удаленном подключении, однако на практике это редко используется. Как правило
5 виртуальных линий достаточно для любой организации. Дополнительные 11 линий
(5 15), могут быть использованы для сторонних сервисов.
Следует заметить, что по умолчанию для удаленного подключения
используется протокол ​Telnet​. Кроме него еще существуют ​SSH и ​HTTPS​. В
следующих параграфах мы рассмотрим их более подробно.
Также не стоит забывать про таймаут сессии, т.е. время, в течении которого
подключение будет активным, даже если не происходит никаких действий:
Router(config-line)#exec-timeout 5 0

24
В данном случае мы установили таймаут сессии в 5 минут и 0 секунд. Эта команда
весьма полезна если вы подключились к устройству, а потом “пошли пить чай”. Сессия
автоматически прервется через 5 минут и никто не сможет ей воспользоваться без
вашего ведома.

1.2.2 Telnet
Telnet​. Этот протокол доступен практически на любом сетевом оборудовании и
почти всегда используется по умолчанию. Имеет ярко выраженный недостаток - все
данные передаются в открытом виде. Давайте рассмотрим простейший пример (вы
можете его с легкостью повторить в GNS3 или UNetLab). Имеется следующая схема:

Предположим, что хакер получил доступ к коммутатору ​SW1​. Либо он мог

поставить свой коммутатор в разрыв существующей линии. Настроил зеркалирование
трафика (​SPAN порт​) на свой компьютер, где в свою очередь запущен ​Wireshark -
софт для анализа трафика. Администратор ни о чем не подозревает и инициирует
удаленное telnet соединение с роутером ​R2​. Вводит имя, пароль, просматривает
конфигурацию. В это время на компьютере злоумышленника видно весь проходящий
трафик, в том числе ​TELNET​:

Если воспользоваться встроенной функцией Wireshark, а именно

Analyze->Follow->TCP Stream​, то можно получить следующую картину:

25
Как видно из картинки, злоумышленник теперь знает и логин, и пароль, и даже всю
конфигурацию устройства. Сказывается отсутствие шифрования Telnet - сессии.
-----------------------------
Не используйте ​Telnet​в качестве протокола удаленного подключения.
-----------------------------

1.2.3 SSH
Очевидное решение проблемы Telnet - шифрование данных. Для этой цели
был создан протокол ​SSH ​(​S​ecure ​Sh​ell - “Безопасная оболочка”) - сетевой протокол
прикладного уровня, предназначенный для удаленного управления. SSH является
практически стандартом для удаленного администрирования и поддерживается
большинством операционных систем. Протокол создает виртуальный шифрованный
канал между двух устройств. При этом одно устройство выступает в качестве ​SSH
сервера (например маршрутизатор или коммутатора), а другое - в качестве ​SSH
клиента (например наш компьютер). Все данные внутри канала шифруются, в том
числе login и password. Вообще говоря, SSH может использоваться не только для

26
удаленного управления, но и для безопасной передачи любых данных, будь-то звук,
видео и т.д.
Следует отметить, что существует две версии протокола, это ​SSHv1 и ​SSHv2​ .
Как можно догадаться, предпочтительнее использовать именно SSHv2, он более
безопасен. Эта безопасность достигается за счет использования более криптостойких
алгоритмов шифрования ​3DES или ​AES​. При этом следует учитывать, что некоторое
оборудование по умолчанию не поддерживает данные алгоритмы, а значит возможно
использовать только SSHv1. Эта проблема решается банальным обновлением
прошивки. Как правило это прошивка в названии которой присутствуют символы “​k9​”.
Вернемся к описанному ранее примеру:

Предположим, что теперь администратор использует SSH для подключения к

маршрутизатору ​R2​. Он подключается с помощью ​Putty (либо ​SecureCRT​, это не
важно), вводит пароль, просматривает конфигурацию. Злоумышленник, как и в первом
примере, видит весь трафик и использует ​Wireshark для анализа пакетов. Если
посмотреть “дамп” трафика, то можно увидеть следующее:

Можно заметить, что используется протокол ​SSHv2 и все пакеты в зашифрованном

виде - ​Encrypted​. Если снова воспользоваться утилитой ​Analyze->Follow->TCP
Stream​, то мы увидим следующее:

27
 В данном случае мы уже не можем увидеть ни пароль, ни конфигурацию, что
делает нецелесообразным “прослушку” управляющего трафика.
-----------------------------
Используйте защищенные протоколы удаленного подключения (например ​SSHv2​).
-----------------------------
Давайте теперь вкратце рассмотрим процесс настройки SSH подключений, тем
более что это довольно простой процесс. Большую часть настроек мы уже выполнили
в предыдущих этапах. На всякий случай напомню, что у вас уже должен быть задан
пароль для ​enable ​и создан хотя бы один ​username​. Затем настроена аутентификация
либо с помощью ​aaa new-model ​(aaa authentication login default local) либо ​login local​
,
для настройки SSH нет никакой разницы, т.к. в данном случае мы всего лишь
выбираем протокол. Вот так выглядит процесс настройки:
R2(config)#ip domain-name netskills.ru /имя домена используется для генерации ключей
R2(config)#crypto key generate rsa modulus 1024 /генерируем пару ключей, где длина ключа - 1024

Длина ключа может варьироваться от 360 до 2048. После ввода команды

маршрутизатор сообщит об успешной генерации ключей и о том, что был включен
SSH:
The name for the keys will be: R1.netskills.ru

% The key modulus size is 1024 bits

% Generating 1024 bit RSA keys, keys will be non-exportable...[OK]
*Mar 1 00:01:54.243: %SSH-5-ENABLED: SSH 1.99 has been enabled

Теперь укажем, что нужно использовать SSH версии 2:

R2(config)#ip ssh version 2

Воспользуемся дополнительными настройками:

28
R2(config)#ip ssh time-out 15 /Ограничиваем время ввода логина/пароля
R2(config)#ip ssh logging events /Логируем все попытки входа

И последнее, что нам нужно сделать, это указать SSH в качестве протокола
удаленного доступа:
R2(config)#line vty 0 4
R2(config-line)#transport input ssh

Обратите внимание, что если в конфигурации устройства присутствуют две группы

(​vty 0 4​и ​vty 5 15​), то команду ​transport input ssh​нужно указать дважды.
По завершении настройки обязательно проверьте возможность подключения по
Telnet​, доступ должен быть запрещен.

1.2.4 HTTP/S
Кроме Telnet и SSH, коммутаторы и маршрутизаторы Cisco поддерживают еще
один вариант управления - через веб-интерфейс. Могут использоваться такие
протоколы, как ​HTTP ​и ​HTTPS​. Пример веб-интерфейса представлен на картинке
ниже.

Многие сетевые инженеры даже не знают о такой возможности по причине довольно

удобной командной строки Cisco.
Для реализации управления черезе веб-интерфейс на устройстве используется
локальный http/https сервер​. На самом деле, практически никто не использует
веб-интерфейс для управления устройством. ​HTTP/S сервер включают только ради
использования специализированных программ (с графическим интерфейсом)
управления устройствами Cisco. Наиболее популярны следующие программы:
1) CNA - Cisco Network Assistant​. Программа с графическим интерфейсом
которая существенно упрощает администрирование устройств Cisco
(коммутаторы и маршрутизаторы) и автоматизирует выполнение рутинных
задач. Программа позволяет управлять сетевой инфраструктурой, которая
включает до 40 устройств.

29
 2) SDM - Security Device Manager​ . Данная программа позволяет управлять
маршрутизаторами Cisco. Существенно упрощает создание VPN туннелей, а
также предоставляет более удобную работу со списками доступа (access-list).

Подробное рассмотрение данных программ выходит за рамки нашей книги.

Однако мы не можем не затронуть проблему безопасности, связанную с
использованием HTTP/S сервера. В первую очередь стоит отметить, что именно с
HTTP/S серверами связано наибольшее количество уязвимостей, позволяющих
получить удаленный контроль над устройством. К тому же, большинство вендоров
весьма халатно относятся к устранению этих самых уязвимостей, поскольку не
считают эту задачу приоритетной. Оно и неудивительно, как я сказал ранее, мало кто
пользуется данной функцией. В итоге получается, что ваше устройство может
месяцами “святиться” в сети с набором известных уязвимостей. Используйте данную

30
функцию весьма осторожно и следите за обновлением прошивок. Мы поговорим о
прошивках чуть подробнее в следующих главах.
Как ни странно, но на некоторых устройствах функция HTTP включена по
умолчанию, даже если вы ее не используйте. Обязательно проверьте это, либо
выполните команду ​no ip http server​в режиме глобальной конфигурации (​conf t​).
Если же по какой-либо причине вам все же необходимо использовать web
доступ (например для CNA или SDM), то выбирайте ​HTTPS​. Здесь можно провести
аналогию и сравнить HTTP с Telnet, а HTTPS с SSH. HTTPS шифрует все данные, в то
время как HTTP передает их в открытом виде, в том числе и пароли.
Давайте рассмотрим сам процесс настройки:
R1(config)#ip domain-name netskills.ru /должно быть задано доменное имя
R1(config)#ip http secure-server /включаем https сервер
R1(config)#no ip http server /убедитесь, что http сервер выключен

На этом настройка закончена. Т.к. мы ранее использовали ​aaa new-model и команду

aaa authentication login default local​, то аутентификация уже настроена и вход будет
выполняться по созданным локальным учетным записям (​username​ ). Для
подключению к устройству используйте браузер с запросом ​https://ip-address-router​ ,
либо озвученные ранее программы (CNA, SDM).
-----------------------------
При необходимости организации web-доступа к оборудованию, используйте HTTPS
вместо HTTP. Помните об огромном количестве уязвимостей, связанных с HTTP/S.
-----------------------------

1.2.5 Ограничение доступа

В 90% организаций, где мне приходилось работать, к сетевому оборудованию
был разрешен удаленный доступ абсолютно с любого компьютера. Только подумайте,
насколько повышается риск несанкционированного доступа к коммутатору или
маршрутизатору, если доступ возможен не с одного - двух компьютеров, а с тысячи?
Для повышения безопасности, логичным выходом является ограничение доступа к
оборудованию. Есть два основных способа:
1) Out-of-band (OOB) - управление сетью по выделенному каналу. В этом случае
управляющий трафик изолируется от общего (пользовательского). При этом
под управляющим трафиком может пониматься не только SSH или Telnet
сессия, но и такой трафик как SNMP и Log (мы поговорим об этом в следующих
главах). Есть два способа отделить управляющий трафик от общего:
а) ​Физически​. Устройства, которыми необходимо управлять, объединяются в
выделенную физическую сеть. Для этого на маршрутизаторах и коммутаторах,
как правило, имеется специальный порт - ​management port (mgmt)​. Если
такового не имеется, то можно в произвольном порядке выделить порт под эти
нужды. Таким образом, управлять оборудованием сможет только тот
компьютер, который физически находится в управляющей сети. Это может быть
специально выделенный компьютер системного администратора. Данный
способ обладает наибольшей безопасностью, но весьма редко применяется.
Связано это в первую очередь со сложностью исполнения, т.к. приходится
создавать отдельную сеть для всех устройств, а это либо дорого (тянуть

31
 дополнительные линии связи, устанавливать дополнительный коммутатор),
либо просто невозможно (в случае большой распределенной сети).
б) ​Логически​. В этом случае управляющий трафик отделяется от
пользовательского посредством выделения в отдельный логический сегмент -
VLAN​. Данный способ является компромиссным решением, т.к. мы изолируем
управляющий трафик без необходимости в дополнительных линиях связи.
Получить удаленный доступ к оборудованию сможет только тот компьютер,
которых находится в управляющем VLAN. Логическое изолирование также не
применимо в случае распределенной сети, если при этом невозможно
“прокинуть” управляющий VLAN до удаленного объекта.
Оба варианта требуют настройки на оборудовании IP - адреса из сети,
отличной от сети пользователей.
2) In-band (IB) - управление оборудованием осуществляется по общим каналам.
Данный способ используется чаще всего, либо из-за отсутствия возможности
организации способа ​OOB​, либо из-за обычной халатности системного
администратора. В этом случае значительно повышается вероятность
несанкционированного доступа (или попытки доступа). Для повышения уровня
защищенности единственным разумным решением является применение
списков доступа (​Access-list​). Мы поговорим о них более подробно в
следующем параграфе.

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

1.2.6 Списки доступа к оборудованию

Если у вас нет возможности вынести управляющий трафик в отдельный VLAN,
то практически единственным средством ограничения доступа являются списки
доступа - ​
Access List​. Используя их вы сможете указать с каких именно компьютеров
возможно управление устройствами, т.е. подключение по Telnet, SSH или HTTPS. Тем
самым вы отсечете саму возможность несанкционированного доступа с запрещенных
узлов, в том числе сети Интернет (на самом деле все еще остается лазейка в виде
спуфинга, о которой мы поговорим чуть позже).
Первое что необходимо сделать, это четко определить с каких компьютеров
будет возможно удаленное подключение к устройствам. Как правило это компьютер
системного администратора. Разумеется IP-адрес этого компьютера должен быть
статическим. При этом, если вы используете в сети DHCP сервер, следует заранее
зарезервировать данный адрес, чтобы он не был случайно выдан другому
пользователю.
Также я настоятельно не рекомендую настраивать удаленное подключение из
сети Интернет, даже если вы используете защищенные протоколы вроде SSH.
Гораздо логичнее будет организация ​VPN соединения​, где компьютеру удаленного
пользователя будет присваиваться некий зарезервированный IP-адрес и уже с этого
адреса будет возможен доступ к оборудованию.

32
 Сам процесс настройки списков доступа предельно прост. Давайте рассмотрим
ограничение доступа по SSH (при этом у вас уже должны быть выполнены
предыдущие настройки):
R1(config)#ip access-list standard SSH-ACCESS /создание списка доступа с понятным названием
R1(config-std-nacl)#permit host 192.168.2.2 /определяем хосты имеющие доступ по SSH
R1(config-std-nacl)#permit host 192.168.2.3
R1(config-std-nacl)#exit
R1(config)#line vty 0 4 /заходим в режим конфигурации vty
R1(config-line)#access-class SSH-ACCESS in /”вешаем” список доступа

Теперь доступ по SSH возможен только с двух узлов - 192.168.2.2 и 192.168.2.3. При
этом если нужно указать целую сеть, то можно использовать команду ​permit
192.168.2.0​.
Функция ​ip access-list (именованные списки доступа) может быть недоступна
на устройствах со старой прошивкой. Тогда необходимо либо обновить прошивку,
либо использовать следующий вариант настройки:
R1(config)#access-list 1 remark SSH-ACCESS
R1(config)#access-list 1 permit host 192.168.2.2
R1(config-std-nacl)#exit
R1(config)#line vty 0 4
R1(config-line)#access-class 1 in

Если вы используете HTTPS на ваших устройствах, то ограничение доступа

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

R1(config)# ip http access-class 1

1.2.7 Защита от Brute Force

Кроме упомянутых выше методов (выбор сложного пароля, нестандартной
учетной записи и списков доступа) есть еще один способ, который позволит
защититься от попытки взломать ваше устройство. Это так называемая защита от
Brute Force (т.е. от перебора паролей).
Здесь я хотел бы сделать небольшое отступление и вспомнить один случай из
жизни. Пару лет назад я помогал своему другу настроить Mikrotik в качестве
пограничного маршрутизатора (т.е. он использовался для выхода в Интернет).
Проделав базовые настройки мы организовали выход в Интернет буквально за 10
минут. После мы взяли по бутылочке пива и я в расслабленном режиме принялся ему
рассказывать про Mikrotik, как его администрировать, где и что настраивать. Когда мы
дошли до функции просмотра логов, то заметили странную вещь. Из внешней сети
постоянно кто-то пытался подключиться к нашей “железке”. При этом в попытках
использовались такие учетные записи как “root”, “admin”, “guest” и так далее (т.е.
стандартные учетки). Посмотрев IP - адреса атакующих мы выяснили, что эта
активность ведется из Китая. Но кому нужен наш Mikrotik? Немного “погуглив” и
почитав форумы, мы поняли, что это обычные китайские боты, которые в
автоматическом режиме по всему миру ищут уязвимые устройства и выполняют “атаку
на дурака”. Естественно для них не представляет интерес какая-то наша личная
информация (хотя кто знает?). С большой вероятностью им просто нужны взломанные
устройства с помощью которых они смогут осуществлять массированные DDoS атаки

33
(чуть позже мы обсудим этот тип атак). Именно поэтому не пренебрегайте ранее
данными советами:
1) Не используйте стандартные имена в учетных записях;
2) Придумывайте сложные пароли (мы обсудим каким образом выбирать пароль в
следующей главе);
3) Ограничьте удаленный доступ с помощью списков доступа (для сети Интернет
его лучше вообще выключить).
Однако бывают экзотические случаи, когда все же необходим доступ к
оборудованию из сети Интернет. При этом нет возможности указать конкретный
удаленный хост, с которого будет разрешен доступ. Да и кто даст гарантию, что внутри
вашей сети нет зараженного компьютера, который будет пытаться подобрать пароли
ко всем доступным хостам? Именно для таких случаев есть дополнительный уровень
защиты - задержка между повторными вводами учетных данных. Настраивается это
следующим образом:
R1(config)#login delay 5
R1(config)#login block-for 60 attempts 3 within 30

Первой командой мы указываем интервал в 5 секунд между повторными вводами

паролей. Второй командой мы настраиваем блокировку входа на 60 секунд, если в
течении 30 секунд было 3 попытки неудачного входа. Данный способ существенно
ограничивает злоумышленников при подборе паролей. Получается, что они смогут
подбирать всего 3 пароля в течении 15 секунд, а затем блокировка на 60 секунд. Даже
если вы используете довольно простой пароль, у злоумышленников уйдет очень много
времени на подбор, что становится совершенно нецелесообразно. При этом в консоли
устройства вы увидите сообщение примерно следующего содержания:
*Mar 1 00:04:55.899: %SEC_LOGIN-1-QUIET_MODE_ON: Still timeleft for watching failures is 4 secs, [user: admin]
[Source: 192.168.10.3] [localport: 23] [Reason: Login Authentication Failed] [ACL: sl_def_acl] at 00:04:55 UTC Fri Mar 1
2002
R1#
*Mar 1 00:05:03.491: %SEC-6-IPACCESSLOGP: list sl_def_acl denied tcp 192.168.10.3(62741) -> 0.0.0.0(23), 1 packet

Т.е. при 3-х неудачных попытках создается временный access-list, который блокирует
дальнейшие попытки с определенного хоста. Максимальное время блокировки - 65535
секунд (т.е. примерно на 18 часов). Крайне не рекомендую выставлять такой интервал,
т.к. вы и сами можете быть заблокированы если вдруг сделаете несколько неудачных
попыток (перепутали пароль, русская раскладка клавиатуры, зажатый caps lock).
-----------------------------
Для защиты от подбора паролей (Brute Force) настройте временную блокировку
повторной аутентификации.
-----------------------------

1.2.8 Идентификация устройства

Почти уверен, что в работе каждого сетевого администратора были моменты
когда он нечаянно вводил команду “не на том” коммутаторе/маршрутизаторе после
чего падала сеть, либо пропадал доступ к оборудованию. Наверняка многие
сталкивались с ситуацией, когда зайдя на устройство было трудно понять куда именно
вы попали. Все это также является аспектами безопасности вашей сети. Как вы уже

34
наверно поняли, здесь пойдет речь о таких вещах, как ​hostname и ​login banner​
.
Довольно часто про эти опции просто забывают.
Вообще говоря, многие начинают настройку устройства с имени - ​hostname​.
Это уже дело привычки. Имя должно быть осмысленным и однозначно определять
предназначение устройства. Пример:
- Коммутатор ядра - ​4507_Core
- Коммутатор доступа на втором этаже - ​2960_2flor
- Пограничный маршрутизатор - ​1710_Edge
Это лишь примеры, которые отражают суть идеи. Естественно, что у каждого могут
быть собственные стандарты. Сама настройка элементарна:
Router>enable
Router#conf t
Router(config)# hostname R1 /задаем имя
R1(config)# /имя изменено

Кроме имени есть еще одна полезная опция - ​login banner​. Это сообщение
которое мы видим при подключении к устройству. Пример:
User Access Verification

Username: admin
Password:

Test banner for netskills

R1>
Какую же информацию можно поместить в сообщение баннера? Как правило в
нем указывают информацию об устройстве, о том, что нужно быть аккуратным при
конфигурировании и о том, что нужно немедленно выйти если вы попали на это
устройство случайно (такое все же иногда случается). Когда это может быть полезно?
К примеру у вас несколько администраторов сети и не каждому позволено
конфигурировать некоторые устройства. В этом случае, зайдя на устройство, можно
однозначно увидеть предостережение и сделать вывод о “законности” дальнейшей
настройки.
При этом у нас есть выбор когда показывать это сообщение - до
аутентификации или уже после (как в примере выше). На мой взгляд гораздо логичнее
это делать после, особенно если в сообщении содержится важная информация
(например, что данный коммутатор является ядром сети). Настройка также
элементарна:
R1(config)#banner exec c /начало баннера
Enter TEXT message. End with the character 'c'.
Test banner for NetSkills /сообщение
c /​конец баннера
R1(config)#

Теперь при аутентификации на устройстве вы увидите сообщение “​Test banner for

NetSkills​”. Если же есть необходимость использовать баннер до аутентификации, то
используйте команду ​banner login​вместо ​banner exec​.
-----------------------------
Задавайте имя устройства (​hostname​) и сообщение после аутентификации
(​banner exec​), чтобы в будущем не “перепутать” оборудование.
-----------------------------

35
1.3 AAA
Как уже было сказано выше, ​AAA-сервер позволяет централизованно хранить
все учетные записи пользователей. Это отличная альтернатива локальной базе на
самих устройствах. Какие же преимущества несет в себе AAA-сервер:
1) Удобное администрирование учетных записей. Если у вас больше 10-и сетевых
устройств, то добавление даже одного пользователя превращается в весьма
нудную и долгую процедуру. ААА-сервер решает эту проблему.
2) Безопасность учетных записей. В случае с локальной базой пользователей
(login local), при несанкционированном доступе к устройству, злоумышленник
потенциально получает доступ ко всем паролям, которые как правило
одинаковы для всех коммутаторов и маршрутизаторов. При использовании
AAA-сервера, все пароли хранятся централизованно, а на устройствах
отсутствуют какие-либо записи. Здесь есть и обратная сторона медали. Если
злоумышленник сможет получить доступ к AAA-серверу, то вся сеть окажется
скомпрометирована. Поэтому уделяйте особое внимание защите
AAA-серверов.
3) Простота соблюдения парольной политики. Как я уже говорил ранее, пароли
должны обязательно меняться с определенной периодичностью. В этом случае
AAA-сервер является незаменимым помощником. Смена паролей занимает
считанные секунды, даже если в вашей сети сотни устройств. Что такое
“парольная политика” мы подробно рассмотрим в следующих главах.
-----------------------------
Если в вашей сети более 10-и устройств, то вы просто обязаны использовать
AAA-сервер​.
-----------------------------
Но обо всем по порядку. Что же значат эти три буквы? Расшифруем:
A - Authentication​(аутентификация)
A - Authorization​(авторизация)
A - Accounting​(учет)
Буквы расшифровали, но это не сильно прояснило смысл этой технологии. Для
разъяснений я воспользуюсь примером моего любимого коуча - Keith Barker из CBT
Nuggets. Представим, что вы пришли в банк, чтобы снять часть своих сбережений. Для
начала вас попросят предоставить документы, чтобы убедиться, что вы являетесь
клиентом банка. После того как вы показали документы, вы прошли аутентификацию
(​authentication​), если конечно вы являетесь клиентом банка. Далее, девушка, которая
вас обслуживает, проверяет, можете ли вы снимать деньги и снимать именно такую
сумму. Если все нормально, то вы прошли авторизацию (​authorization​). А после всех
этих действий, естественно ведутся записи в журнал, что вы приходили, сняли деньги,
на счету осталось столько то денег. В данном случае прошел учет (​accounting​ ).
Надеюсь теперь вам более понятно, что такое AAA и для чего это используется.
У многих возникают сложности при произношении “AAA”. Как же правильно
произносить имя этой технологии? Чаще всего используется фраза “​трипл эй​” (triple
A), т.е. “тройное А”.

36
 Теперь рассмотрим процесс AAA на примере сетей. Представим, что на
сетевом устройстве уже настроен AAA и в нашей сети есть AAA-сервер с
настроенными учетными записями. В данном случае маршрутизатор выступает в роли
AAA-клиента.

Распишем процесс поэтапно (естественно в упрощенном виде.)

1) Пользователь пытается подключиться к маршрутизатору по telnet или ssh.
2) Маршрутизатор запрашивает у пользователя учетные данные - username и
password.
3) Пользователь вводит свои учетные данные.
4) Маршрутизатор обращается к серверу AAA с вопросом: “Разрешать доступ
этому пользователю?”. И передает введенные данные.
5) ААА-сервер ищет учетные данные пользователя. Находит (или нет) их. В
данном случае пользователь прошел (или не прошел) аутентификацию
(authentication).
6) ААА-сервер также находит уровень привилегий для данного пользователя,
который определяет его права. Это уже авторизация (authorization).
7) Маршрутизатору дается ответ: “Можно пустить этого пользователя с уровнем
привилегий Х”, где Х - от 0 до 15.
8) Маршрутизатор разрешает пользователю доступ к командной строке с
определенным уровнем привилегий.
9) Естественно, что данные операции логируются в журнале событий, т.е.
происходит учет (accounting).
Данное общение (между ААА-клиентом и ААА-сервером) выполняется при
помощи ​ААА-протокола​. В настоящее время наибольшее распространение получили
два протокола: ​RADIUS​и ​TACACS+​. Далее мы рассмотрим их основные отличия.

1.3.1 RADIUS
RADIUS (Remote Authentication in Dial-In User Service) - открытый AAA-протокол.
Рассмотрим ключевые характеристики данного протокола:

37
 1) В качестве транспортного протокола используется ​UDP​. Для аутентификации
порт 1812 (ранее 1645), а для учета - 1813 (ранее 1646).
2) При взаимодействии между ААА-сервером и ААА-клиентом, протокол шифрует
только пароль. Остальные данные передается в открытом виде.
3) Аутентификация и авторизация являются единым процессом. Как только
пользователь проходит аутентификацию, он тут же, автоматически проходит
авторизацию и получает соответствующий ему уровень привилегий
(возможность выполнять ту или иную команду). После этого, пользователь
волен делать все, что ему разрешено в рамках своих привилегий.
4) Имеет очень детальный процесс учета (accounting).
5) Открытый протокол (open source).
Ярким представителем данного протокола является ​FreeRADIUS - AAA-сервер
с открытым исходным кодом. Также может быть интересна реализация этого
протокола с графическим интерфейсом - ​daloRADIUS​.

1.3.2 TACACS+
TACACS+ (Terminal Access Controller Access Control System). Произносится как
ТА-КАКС плюс. Это проприетарная разработка компании Cisco и является более
усовершенствованным вариантом более старого протокола TACACS. Иногда можно
услышать слово TACACS без приставки “+”. Можете быть уверены, что на самом деле
речь идет именно о TACACS+, поскольку протокол TACACS уже практически не
используется. Основные отличия:
1) В качестве транспортного протокола используется ​TCP (порт 49), что конечно
же медленнее, чем UDP у RADIUS.
2) Протокол шифрует все данные между AAA-сервером и AAA-клиентом.
3) Процессы аутентификации и авторизации абсолютно независимы. Это
позволяет выполнять авторизацию каждой команды, которую вводит
пользователь. Таким образом мы получаем более гибкий контроль всех
действий.
4) Проприетарный протокол (т.е. закрытый).
Самый известный TACACS+ сервер - Cisco Secure Access Control Server (​ACS​ ).
Это также проприетарная разработка компании Cisco. Продукт платный, но имеется
demo период (возможность бесплатного тестирования).

1.3.3 RADIUS vs TACACS+

Какой же протокол выбрать для своей сети? Для удобства я вынес в табличку
основные характеристики этих протоколов:
RADIUS TACACS+

UDP
Транспортный
1812/1645 (authentication) TCP, порт 49
протокол
1813/1646 (accounting)

Шифрование Шифрует только пароль Шифрует все данные

38
 Открытый протокол. Проприетарный протокол.
Особенности “Плохо” реализована авторизация. Гибкая авторизация команд.
Детальный учет (accounting). Менее детальный учет.
Ответ как всегда зависит от каждой конкретной задачи.
Есть мнение, что у RADIUS гораздо лучше выполнен учет (accounting). Однако,
лично в моей практике, не было таких случаев, когда данное преимущество играло
важную роль (хотя для Интернет провайдеров это очень критично). А вот авторизация
каждой команды, это действительно важное отличие и здесь TACACS выигрывает.
RADIUS чаще всего используется для аутентификации удаленных пользователей, т.е.
VPN подключений, либо для WiFi пользователей. Также RADIUS сервер встречается в
сети любого Интернет провайдера, где нужно аутентифицировать сотни и тысячи
пользователей. TACACS же чаще всего применяется для аутентификации и
авторизации администраторов на сетевых устройствах. Опять же, данный выбор
обусловлен более гибкой авторизацией, когда можно проверять буквально каждую
команду. При этом RADIUS поддерживается практически любым сетевым
оборудованием, чего не скажешь о TACACS.
Данные протоколы весьма часто используются совместно, распределяя задачи.
Руководствуясь личным опытом, могу дать следующий совет:
-----------------------------
Для аутентификации VPN-пользователей и WiFi-клиентов используйте R ​ ADIUS​.
Для аутентификации и авторизации администраторов на сетевом оборудовании -
TACACS+​.
-----------------------------

1.3.4 Настройка ААА-сервера

Прежде чем перейти к описанию настроек сетевого оборудования будет весьма
полезно рассмотреть настройки ААА-сервера. Хоть данная тема и выходит за рамки
нашей книги, я все же опишу основные моменты. В качестве примера мы будем
рассматривать протокол TACACS+, поскольку он гораздо интереснее в плане
безопасности, т.к. позволяет авторизовать каждую команду.
В качестве ААА-сервера можно выбрать ​Cisco ACS в триальном режиме. Автор
использовал проект ​Tacacs GUI plus​, который совершенно бесплатен и предоставляет
графический Web-интерфейс. Настройка ААА-сервера состоит из трех этапов:
1) Создание устройства​. Как показано на рисунке ниже, мы добавляем
маршрутизатор ​R1​, указываем его ip-адрес и ключ (​Tacacs Key​), который
используется для шифрования данных между маршрутизатором и
ААА-сервером.

39
2) Создание уровней​. Здесь подразумеваются уровни привилегий (​Privilege
Level​). Мы также задаем уровни при использовании локальной базы (​local​). На
рисунке ниже мы создали уровень 15 (​Level15​) и разрешили все команды.

Для примера создадим еще один уровень (​Level1​), которому разрешим всего
несколько команд: ​ping​, s
​ how run​и e
​ xit​.

40
3) Создание пользователей​. Последний этап. Создаем пользователя, указываем
пароль и его уровень привилегий. В нашем примере создан пользователь
admin15 c паролем ​admin15 и уровнем привилегий ​Level15 (т.е. ему доступны
все команды).

41
 Точно таким же способ был создан пользователь ​admin1 с паролем ​admin1 и
уровнем ​Level1​. Согласно нашим настройкам, ему будут доступны всего три команды.
На этом базовая настройка AAA-сервера завершена. Настройка Cisco ACS
имеет весьма схожий процесс и вряд ли может вызвать какие-то затруднения.

1.3.5 Настройка Authentication

Теперь рассмотрим процесс настройки сетевого оборудования для
использования функций ААА. Данную тему нельзя назвать простой, поэтому я
настоятельно рекомендую потренироваться на лабораторном макете, прежде чем
начинать настройку реального оборудования. Может получиться, что вы просто
потеряете доступ.
Для начала рассмотрим настройку Authentication (первая А). Это позволит
избежать некоторой путанницы в голове. Процесс настройки можно разбить на 4
основных этапа:
1) Создание пользователя в локальной базе. Собственно мы уже делали это
ранее (​username admin privilege 15 secret ​cisco​). Здесь может возникнуть
некоторое недопонимание. Мы же используем ААА для того, чтобы
централизованно хранить все учетные записи. Так зачем нам локальная
учетная запись? А теперь представьте, что по какой-то причине ААА-сервер
стал недоступен. Это может случиться из-за сетевого сбоя, либо из-за
42
 хакерской атаки. Тогда вы просто не сможете зайти на оборудование, т.к.
сетевое устройство будет пытаться обратиться к ААА-серверу для проверки
введенных данных. В этом случае и необходима локальная учетная запись. По
сути, она является резервным вариантом входа, когда нет возможности
обратиться к ААА-серверу.
-----------------------------
Никогда не настраивайте вход ТОЛЬКО через ААА-сервер. Вы не сможете зайти на
устройство, если сервер станет недоступен. Используйте локальную учетную
запись, как резервный вариант входа.
-----------------------------
2) Включение функции ААА. Данное действие мы тоже уже выполняли (​aaa
new-model​).
3) Настройка ААА-сервера. Здесь имеется в виду указание IP - адреса
ААА-сервера (или даже нескольких серверов) и секретного ключа (​key​). Эти
данные используются устройством для подключения к ААА-серверу и
дальнейшему общению. Ключ используется для шифрования всей
передаваемой информации.
4) Создание метода аутентификации ​(​method list​). И здесь мы уже попробовали
свои силы (​aaa authentication login default local​). Мы создавали ​method list
под названием ​default​, что означает его применимость сразу ко всем
доступным линиям (console, vty). И в конце команды мы указывали способ
аутентификации - ​local​, т.е. использование локальной базы учетных записей.
Далее мы рассмотрим настройку другого способа - ​tacacs​либо ​radius​.
Теперь приведем пример настройки маршрутизатора, который будет
использовать ААА-сервер в качестве основного метода аутентификации и локальную
базу, как резервный вариант. Для макетирования использовалась следующая схема:

Ниже представлена настройка маршрутизатора:

enable secret cisco /задаем пароль на enable
username admin privilege 15 secret cisco /создаем локального пользователя
aaa new-model /включаем ААА
tacacs-server host 192.168.56.101 /указываем адрес ААА-сервера
tacacs-server key cisco123 /указываем ключ
aaa authentication login default group tacacs+ local /создаем method list

Думаю стоит немного пояснить последнюю команду. В качестве имени ​method list мы
использовали ​default​, т.е. применили его ко всем линиям. Далее, с помощью

43
параметра ​group​, ​мы определяем несколько возможных вариантов аутентификации.
Первым по приоритету идет ​tacacs+​, т.е. если для роутера доступен ААА-сервер, то
для аутентификации будет использоваться именно этот способ. Если же по каким-то
причинам это невозможно, то будет использован второй способ - ​local​
, т.е. локальная
база учетных записей. В данном случае этот способ является резервным и именно для
него мы создали локальную учетку ​admin​. Кроме того, мы можем использовать в
качестве резервного варианта пароль от ​enable​. В этом случае последняя команда
выглядела бы так:
aaa authentication login default group tacacs+ enable

Иногда бывает необходимо создать разные политики доступа к оборудованию.

Для примера рассмотрим случай с консольным портом. Предположим, что мы уже
настроили аутентификацию с помощью ААА и создали ​method list с именем ​default​ .
Но при этом мы хотим, чтобы вход по консоли был без пароля (крайне не
рекомендую). Для этого достаточно создать еще один ​method list и “повесить” его на
консольный порт:
R1(config)#aaa authentication login FREE none
R1(config)#line console 0
R1(config-line)#login authentication FREE

В ​method list с именем ​FREE использует параметр ​none​, который разрешает вход без
пароля.
Настройка ​RADIUS ​для аутентификации практически идентична и заключается
лишь в замене слова “​tacacs​”.
radius-server host 192.168.56.2
radius-server key cisco123
aaa authentication login default group radius local

Таким образом мы рассмотрели процесс базовой настройки аутентификации с

помощью ААА-сервера. При попытке подключения к маршрутизатору получим
следующее:
User Access Verification

Username: admin15
Password:

R1>

Как видим, вход с помощью учетной записи ​admin15 - успешен. Но стоит обратить
внимание на уровень привилегий. Данный пользователь был создан с уровнем ​ 15
(​Level15​), но знак “​>​” говорит о том, что мы все еще в пользовательском режиме, т.е.
уровень ​1​. Причина в отсутствии настроек авторизации (вторая А). Именно
авторизация позволяет пользователю при входе на устройство автоматически
попадать на свой уровень.

1.3.6 Настройка Authorization

Настройка авторизации немного отличается от настройки аутентификации.
Ниже представлен пример конфигурации, где мы разберем каждую команду.

44
aaa authorization exec default group tacacs+ local

Для начала мы настраиваем авторизацию для входа в соответствующий режим -

пользовательский (​user exec mode​) или привилегированный (​privileged exec mode​).
Именно после этой команды мы сможем автоматически попадать в нужный режим
сразу после входа на устройство. Думаю значение ​default group tacacs+ local вам и
так понятно.
aaa authorization config-command
aaa authorization commands 1 default group tacacs+ local
aaa authorization commands 15 default group tacacs+ local

Здесь мы настраиваем авторизацию каждой вводимой команды, как на уровне 1, так и

на уровне 15.
aaa authorization console

Последним шагом идет настройка авторизации при входе через консольный порт.
Несмотря на ранее введенное имя ​default​, авторизация на консольном порту не будет
проходить без этой команды.
Теперь если попробовать подключиться к маршрутизатору с помощью учетной
записи ​admin15​, получим следующее:
User Access Verification

Username: admin15
Password:

R1#

Как видим по знаку “​#​” мы попадаем в нужный нам режим (​privileged exec mode​) без
необходимости ввода пароля ​enable​.
Можно еще раз проверить работу авторизации и войти под учетной записью
admin1​:
User Access Verification

Username: admin1
Password:

R1>

Как и ожидалось, мы попадаем в пользовательский режим. При этом, если вы

помните, данный пользователь ограничен всего тремя командами, в соответствии с
настройками на ААА-сервере (это ​ping​, ​show run и ​exit​). Попробовав выполнить
другие команды получим следующее:
R1>show cdp neighbors
Command authorization failed.

Команда не авторизована и не может быть выполнена. И даже если войти в

привилегированный режим с помощью ​enable​, мы все равно не сможем выполнить
неавторизованные команды:
R1>en
Password:
R1#conf t
Command authorization failed.

45
1.3.7 Настройка Accounting
Последним этапом будет настройка учета (​accounting​) или простым языком -
логирование всех действий пользователей. Делается это элементарно:
aaa accounting exec default start-stop group tacacs+
aaa accounting commands 1 default start-stop group tacacs+
aaa accounting commands 15 default start-stop group tacacs+

Здесь мы включили логирование всех вводимых команд, как на уровне 1, так и на

уровне 15. После этого на ААА-сервер можно увидеть следующую информацию:

Мы видим на каком устройстве, в какое время, кем и как были произведены какие-либо
действия. Данная информация может существенно помочь при поиске причин
“внезапной” недоступности какого-либо устройства после неудачной настройки. Это и
есть основное предназначение функции ​Accounting​.

1.3.8 Ограничения ААА

Следует отметить, что мы весьма поверхностно рассмотрели возможности
ААА. Описанные выше команды, лишь пример минимально необходимых настроек.
Более подробное рассмотрение данной технологии выходит за рамки нашей книги.
Однако остался еще один момент, который я не могу обойти стороной.
Ранее было сказано, что при настройке ААА необходимо обязательно
оставлять резервный вариант входа в виде локальной учетной записи (либо пароля на
enable). Но как же централизованно администрировать эти учетки? Ведь ААА не
позволят менять локальные пароли на устройствах. Неужели придется это делать
вручную? А если устройств сотни, как у интернет провайдеров? Не менять пароли
локальных учеток также плохая идея.
Как правило, для решения данной проблемы используются менеджеры
конфигураций (​network configuration manager​) либо самописные скрипты. Яркими
примерами менеджеров конфигураций являются ​SolarWinds Network Configuration
Manager ​(платный),и ​rConfig ​(бесплатный).
-----------------------------
Для централизованной смены паролей локальных учетных записей используйте
менеджеры конфигураций (​network configuration manager​).
-----------------------------
Данный софт позволяет централизованно изменять настройки сетевых устройств,
даже если они разных производителей (Сisco, Juniper, HP и т.д.). Описание данных
программ выходит за рамки нашей книги.

46
1.4 Парольная политика
Мы уже частично затронули эту тему в предыдущих главах, теперь мы
рассмотрим данный вопрос более детально. В современном мире, практически любой
человек понимает важность пароля, а точнее важность его секретности. Используете
ли вы соц. сети, электронную почту или онлайн банкинг, везде необходим секретный
пароль. Тоже самое касается и корпоративных сетей. Пароль должен исключать
возможность несанкционированного доступа к сетевому оборудованию. Это касается
как доступа из внешней сети (Интернет), так и из внутренней.
Ранее мы уже обсудили, что пароли в конфигурации нужно шифровать, а сами
пароли не должны быть элементарными (вроде ​cisco ​или ​password​). Однако и этого
недостаточно. Многие пользователи довольно часто используют корпоративные
пароли для личных целей, например при регистрации в соц. сетях, torrent - трекерах,
различных развлекательных порталах. Признаюсь, я и сам делал подобные вещи
несколько раз. Уверен, что каждый слышал о периодических взломах популярных
сайтов, в результате чего в сеть “утекали” огромные базы учетных записей. Среди
этих записей может быть и ваш корпоративный пароль. И неважно насколько он
сложный, т.к. он полностью скомпрометирован. Необходима смена пароля.
-----------------------------
Пароли необходимо периодически менять вне зависимости от их сложности.
-----------------------------
В данном случае, единственный способ обеспечить должный уровень
безопасности это соблюдать парольную политику.

1.4.1 Основные положения

Для начала рассмотрим парольную политику в ее классическом виде и опишем
основные моменты. Как правило, парольная политика содержит следующие
требования:
1) Минимальная длина пароля. На данный момент рекомендуемая длина - не
менее 8 символов. Это ограничение связано с временем, которое необходимо
для подбора пароля при “брутфорсе” (атака по словарю). Думаю не стоит
объяснять, что чем длиннее пароль, тем дольше придется его разгадывать.
2) Используемые символы в пароле. Практически все стандарты требуют наличия
в пароле букв верхнего и нижнего регистра, цифр и специальных символов
(такие знаки как !, @, -, _ и т.д.). Это существенно усложняет процесс атаки по
словарю, т.к. возможных комбинаций становится гораздо больше.
3) Запрет на распространение паролей. Личный пароль не может быть сообщен
кому-либо или записан на бумагу. Многие пользователи любят записывать
пароли на стикеры и приклеивать к мониторам. Это недопустимо. В таком
случае можно считать, что пароль скомпрометирован.
4) Плановая смена паролей. Здесь уже каждая компания сама выбирает
временные интервалы. Как правило это либо раз в полгода, либо раз в квартал.
5) Внеплановая смена паролей. Обычно производится при увольнении
сотрудника, либо при обнаружении факта компрометирования пароля. Ни в

47
 коем случае нельзя оставлять учетные записи пользователей, которые уже не
работают в организации.
Большинство организаций ограничиваются данными пунктами. Однако этого
недостаточно. Есть один фактор, который мешает соблюдению описанных пунктов -
это память человека. Чем сложнее пароль, тем труднее его запомнить. Люди могут
идти на различные ухищрения, чтобы выбрать легкий для запоминания пароль, но при
этом формально соблюдая парольную политику. Приведем пример. Возьмем первые
два пункта: пароль должен содержать минимум 8 символов, включать буквы
верхнего/нижнего регистра, цифры и специальные символы. Данные требования легко
соблюсти выбрав следующие пароли: ​Password1!​, ​P@ssw0rd​, ​Pa$$w0rd и т.д.
Формально парольная политика применена, но данные пароли подбираются за
считанные минуты. В сети Интернет есть целые словари с подобными и самыми
распространенными паролями. Более того, если будет выполнятся “брутфорс”, то в
первую очередь будут подбираться именно такие, типовые варианты.
Приведем еще один пример, касающийся плановой смены паролей.
Предположим, что подошло время смены. Пользователь, дабы не усложнять себе
жизнь, меняет старый пароль ​Password1! на новый - ​Password2!​. Опять же,
формально все соблюдено, но эффективность этой процедуры весьма сомнительна.
Еще один момент. Пункт 3) гласит, что пароль нельзя записывать ни на
физический, ни на электронный носитель. Но что делать если пароль забыт, либо
что-то случилось с тем, кто его знает? А если это пароль от коммутатора ядра в
крупном интернет провайдере? ААА-сервера частично решают эту проблему, но как
быть с локальными паролями на устройствах? Без них все равно не обойтись.
Описанные выше проблемы дали повод к появлению еще нескольких пунктов в
парольной политике:
6. Пароль не должен содержать легко предугадываемые сочетания символов.
Пример: pass, adm, qwert, asdf, 1234, user, либо фразы имеющие отношение к
имени/фамилии пользователя.
7. При смене пароля, новый пароль должен отличаться от старого не менее чем
на 4 символа.
8. Пароли от особо важных узлов должны быть записаны на какой либо носитель
(лист бумаги, флешка) и сохранены в безопасном месте (сейф).
-----------------------------
Соблюдайте парольную политику! Если ее нет - разработайте.
-----------------------------

1.4.2 Самые популярные пароли 2015 года

Как было сказано ранее, в сети Интернет можно найти целые словари наиболее
часто используемых паролей. Данная база обновляется каждый год и публикуется так
называемый ТОП. Делается это с целью показать, насколько часто и насколько
“плохие” пароли мы используем. Ниже представлены 25 самых популярных паролей
2015 года:
1. 123456
2. password
3. 12345678
4. qwerty

48
 5. 12345
6. 123456789
7. football
8. 1234
9. 1234567
10. baseball
11. welcome
12. 1234567890
13. abc123
14. 111111
15. 1qaz2wsx
16. dragon
17. master
18. monkey
19. letmein
20. login
21. princess
22. qwertyuiop
23. solo
24. passw0rd
25. starwars
Кроме пресловутых последовательностей цифр и популярных слов, можно
заметить пароль ​1qaz2wsx​. На первый взгляд он не кажется простым. Но это только
на первый взгляд. Очень большое количество пользователей любят придумывать
пароли, которые удобно вводить с клавиатуры, ведь так легче запомнить:

Можно привести много подобных примеров: ​qaz123​, ​qweasd​, ​zaq1xsw2​, ​qazxsw ​и т.д.
При этом многие администраторы считают, что они придумали хороший пароль. Это в
корне не верно. Современные алгоритмы подбора паролей учитывают данные
“привычки” и позволяют угадывать такие комбинации за считанные секунды.
-----------------------------
Не используйте клавиатурные комбинации при создании пароля.
-----------------------------

49
1.4.3 Пароли по умолчанию
Очень многие администраторы забывают о такой важной вещи, как “Пароль по
умолчанию”. IP - камера, ip - телефон, источник бесперебойного питания, сетевой
принтер или даже холодильник (который подключается к сети Интернет) имеют
дефолтные пароли. Большинство беспечно полагают, что эти устройства не
представляют какой-либо опасности. Это серьезное заблуждение. Пароли для таких
устройств можно с легкостью найти в сети Интернет, что позволяет злоумышленнику
весьма просто подключиться к устройству, которое затем может использоваться как
плацдарм для дальнейшей атаки. Ситуация ухудшается с увеличением сегмента
Интернета вещей, так называемый ​IoT (Internet of Things). Яркий тому пример - ​ботнет
Mirai​.
Mirai ​- одна из самых больших ботнет сетей на сегодняшний день. Однако
больше всего поражает не размер сети, а то, как эта сеть появилась. Метод гениально
прост. Ботнет не использует какую-то сложную уязвимость софта. Все, что он делает -
подбирает пароль. Тот самый “пароль по умолчанию”, который устанавливают
производители различных устройств. Mirai использует всего 61 различную комбинацию
логин/пароль методом перебора (возможно сейчас этих комбинаций уже больше).
Столь малое количество комбинаций обеспечивает высокую скорость обнаружения
уязвимых устройств, которые в дальнейшем используются в ботнет сети. На момент
написания статьи ботнет насчитывал уже более 1 миллиона устройств IoT. На что
способен Mirai? С помощью Mirai была организована самая мощная, в истории
Интернет, DDoS атака - 665 Гбит/с. Эксперты утверждают, что мощность атак будет
только расти. А виной всему дефолтный пароль, который забыли сменить при
установке устройства.
-----------------------------
Ни в коем случае не оставляйте пароли по умолчанию.
-----------------------------
1.4.4 Фишинг
Последнее, о чем я бы хотел поговорить в этой главе - ​Фишинг ​(от английского
fishing - рыбалка). Название говорит само за себя. Злоумышленник кидает крючок с
приманкой и ждет пока клюнет жертва. В качестве приманки может выступать
поддельный сайт социальной сети, куда хакер перенаправляет пользователя, где
последний вводит логин/пароль, не подозревая о зловредности сайта.
Злоумышленник получает нужные данные и использует их в своих целях. Как
говорилось выше, некоторые пользователи зачастую используют корпоративные
пароли для сторонних сервисов, что существенно повышает риск для сети компании.
Еще один популярный инструмент для фишинга - email рассылка.
Пользователю отправляется поддельное письмо (например от банка или начальника)
с просьбой передать пароль или любые другие ценные данные (номер кредитной
карты). Данный тип атак зачастую совмещает элементы социальной инженерии, что
существенно повышает их эффективность.
К сожалению, данный тип атак невозможно предотвратить средствами, которые
мы рассматриваем в рамках этой книги (коммутаторы, маршрутизаторы).
Единственный выход - информирование ваших пользователей/администраторов о

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

1.5 Чек-лист №1
Первая глава книги подошла к концу и хотелось бы резюмировать
вышесказанное. Для этого запишем ключевые мысли предыдущих параграфов в виде
чек-листа:
1) Ограничьте физический доступ к вашему сетевому оборудованию, а также
кабельной системе. Это снизит риски как случайных, так и
целенаправленных вторжений.
2) Закрывайте доступ к консольному порту даже для пользовательского
режима.
3) Не используйте ​enable password даже в связке с ​service
password-encryption​. Используйте сложные пароли и ​enable secret​.
4) НИКОГДА не используйте стандартные учетные записи. Придумывайте
уникальные имена пользователей.
5) Не создавайте учетные записи с уровнем привилегий 15. Пароль учетной
записи и пароль на ​enable ​должны быть разными!
6) Для настройки аутентификации используйте ​aaa new-model​.
7) Запретите сброс пароля (​no service password-recovery​) на коммутаторах
уровня доступа к которым возможен физический доступ.
8) Для настройки удаленного доступа используйте ​aaa new-model​.
9) Не используйте ​Telnet ​в качестве протокола удаленного подключения.
10) Используйте защищенные протоколы удаленного подключения (например
SSHv2​).
11) При необходимости организации web-доступа к оборудованию, используйте
HTTPS ​вместо ​HTTP​. Помните об огромном количестве уязвимостей,
связанных с ​HTTP/S​.
12) Ограничьте удаленный доступ. Лишь несколько компьютеров должны иметь
возможность подключения к оборудованию.
13) Для защиты от подбора паролей (​Brute Force​) настройте временную
блокировку повторной аутентификации.
14) Задавайте имя устройства (​hostname​) и сообщение после аутентификации
(​banner exec​), чтобы в будущем не “перепутать” оборудование.
15) Если в вашей сети более 10-и устройств, то вы просто обязаны
использовать AAA-сервер.
16) Для аутентификации VPN-пользователей и WiFi-клиентов используйте
RADIUS​. Для аутентификации и авторизации администраторов на сетевом
оборудовании - ​TACACS+​.
17) Никогда не настраивайте вход ТОЛЬКО через ААА-сервер. Вы не сможете
зайти на устройство, если сервер станет недоступен. Используйте
локальную учетную запись, как резервный вариант входа.
18) Для централизованной смены паролей локальных учетных записей
используйте менеджеры конфигураций (​network configuration manager​).
19) Пароли необходимо периодически менять вне зависимости от их сложности.

51
 20) Соблюдайте парольную политику! Если ее нет - разработайте.
21) Не используйте клавиатурные комбинации при создании пароля.
22) Ни в коем случае не оставляйте пароли по умолчанию.
Придерживаясь этих советов, при организации доступа к оборудованию, вы
существенно повысите безопасность вашей сети. При этом от вас не требуются
какие-либо глубокие познания в области информационной безопасности.

1.6 Пример конфигурации

Для закрепления материала приведем обобщающий пример настройки доступа
для роутера с использованием ААА-сервера:
1) Задаем пароль на ​enable ​и создаем пользователя
Router#configure terminal
Router(config)#enable secret ​
cisco
Router(config)#username ​admin ​privilege 1 secret ​cisco
Router(config)#service password-encryption
Router(config)#no service password-recovery

2) Задаем ​hostname ​и банер

Router(config)# hostname R1
R1(config)#banner exec c
Enter TEXT message. End with the character 'c'.
Test banner for NetSkills
c
R1(config)#

3) Настраиваем ​SSH
Router(config)#ip domain-name ​ netskills.ru
Router(config)#crypto key generate rsa modulus 1024
Router(config)#ip ssh version 2
Router(config)#ip ssh time-out 15
Router(config)#ip ssh logging events
Router(config)#line vty 0 4
Router(config-line)#transport input ssh
Router(config-line)#exec-timeout 5 0
Router(config-line)#exit

4) Отключаем ​HTTP​и H
​ TTPS
Router(config)#no ip http secure-server
Router(config)#no ip http server

5) Ограничиваем доступ для определенных ip-адресов

Router(config)#ip access-list standard SSH-ACCESS
Router(config-std-nacl)#permit host 192.168.2.2
Router(config-std-nacl)#permit host 192.168.2.3
Router(config-std-nacl)#exit
Router(config)#line vty 0 4
Router(config-line)#access-class SSH-ACCESS in

6) Настраиваем защиту от ​brute force

Router(config)#login delay 5
Router(config)#login block-for 60 attempts 3 within 30

7) Настраиваем ​ААА

52
R1(config)#aaa new-model
R1(config)#tacacs-server host 192.168.56.101
R1(config)#tacacs-server key ​
cisco123
R1(config)#aaa authentication login default group tacacs+ local
R1(config)#aaa authorization exec default group tacacs+ local
R1(config)#aaa authorization config-command
R1(config)#aaa authorization commands 1 default group tacacs+ local
R1(config)#aaa authorization commands 15 default group tacacs+ local
R1(config)#aaa authorization console
R1(config)#aaa accounting exec default start-stop group tacacs+
R1(config)#aaa accounting commands 1 default start-stop group tacacs+
R1(config)#aaa accounting commands 15 default start-stop group tacacs+

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

53
2. Лучшие практики
Перед началом “серьезной” части книги, мне бы хотелось рассмотреть еще
несколько аспектов сетевой безопасности. Советы из данной главы относятся к
категории “​best practice​” и их можно с легкостью применить к любой сети без каких-то
глобальных “переделок”.

2.1 Logs
Если вы когда-нибудь посещали уроки Истории, то наверняка слышали фразу
вроде: “Будущее невозможно без знаний о прошлом”. Это очень глубокая мысль,
которая имеет применение и в сфере информационной безопасности. В нашем случае
в качестве учебника по истории будут выступать ​Логи (logs)​. Их также называют
журналом событий, файлом регистраций и т.д. Название не столь важно, а смысл
один - записи о всех событиях в хронологическом порядке. Что конкретно
подразумевается под “событиями” мы обсудим чуть позже.
Меня всегда удивляло, с какой халатностью относятся к логам многие
системные администраторы. Их (логи) либо не собирают, либо просто не обращают на
них внимания. А между тем, логи, это один из самых мощных инструментов как при
поиске неисправностей (​ troubleshooting​), так и при расследовании различных
инцидентов (в том числе ИБ). Сколько было неудачных попыток доступа к
маршрутизатору? Когда отключился порт fa0/1 и происходило ли это раньше? Когда
произошло падение VPN-туннеля? Сколько прошло времени с перезагрузки
устройства и связано ли это с отключением электричества? Когда были внесены
последние изменения в конфигурацию? На эти и многие другие вопросы мы можем
ответить только обладая логами.
-----------------------------
Информационная безопасность невозможна без использования логов.
-----------------------------
Логирование (​logging​) позволяет видеть практически все, что происходило в
вашей сети. Согласитесь, что невозможно наблюдать за всем оборудованием в
режиме реального времени, особенно если инциденты происходят в ночное время, а
сеть исчисляется десятками коммутаторов и маршрутизаторов. Кроме того,
периодический просмотр логов позволяет избежать проблем, которые могут случиться
в будущем.
К сожалению сетевое оборудование Cisco (и других вендоров) имеет весьма
ограниченное место для логов (буфер), что в свою очередь сказывается на временном
промежутке, который может быть отражен в логах. При исчерпании размера буфера,
самые старые логи просто удаляются. Кроме того, при перезагрузке устройства логи
будут потеряны безвозвратно. Для решения данных проблем используются
Лог-серверы​, но обо всем по порядку.

54
2.1.1 Методы сбора логов
Всего существует 6 способов сбора логов с оборудования Cisco и не только.
Рассмотрим их:
1) Console Logging - Вывод сообщений в консоль. Данный способ работает по
умолчанию и выводит логи прямо в консоль устройства.
2) Buffered Logging​- Сохранение логов в буфер устройства, т.е. RAM память.
3) Terminal Logging​- Вывод логов в терминал, т.е. для Telnet или SSH сессий.
4) Syslog сервер​- централизованный сбор логов по протоколу Syslog.
5) SNMP Traps​- централизованный сбор логов по протоколу SNMP.
6) AAA ​- использование Accounting. Сбор логово касательно подключения к
оборудованию и ввода команд. Мы уже рассматривали данный метод.
Каждый из способов обладает своими достоинствами и недостатками, поэтому
необходимо использовать их вместе. Ниже мы рассмотрим некоторые аспекты этих
методов.
-----------------------------
Используйте несколько способов сбора логов.
-----------------------------

2.1.2 Уровни логирования

Чуть выше мы сформулировали, что Логи это записи о всех событиях в
хронологическом порядке. Но что является событием? Все зависит от уровня
логирования. Именно он определяет, какую информацию необходимо отображать в
логах. Всего существует 8 уровней логирования:
0 - Emergencies. ​События связанные с неработоспособностью системы.
1 - Alets.​Сообщения о необходимости немедленного вмешательства.
2 - Critical.​Критические события.
3 - Errors.​Сообщения об ошибках.
4 - Warnings.​Сообщения содержащие предупреждения.
5 - Notifications.​Важные уведомления.
6 - Informational.​Информационные сообщения.
7 - Debugging.​Отладочные сообщения.
Данные уровни обладают наследственностью, т.е. выбрав уровень 7, вы будете
получать сообщения всех уровней (от 0 до 7), а выбрав уровень 3 - только от 0 до 3. С
осторожностью повышайте уровень логирования, поскольку чем выше уровень, тем
больше нагрузка на CPU. К примеру, если через маршрутизатор идет “большой”
трафик и процессор уже находится под высокой нагрузкой, то включив 7 уровень
(Debugging) вы можете просто потерять управление над устройством.
-----------------------------
С осторожностью используйте повышенные уровни логирования.
-----------------------------
В корпоративных сетях чаще всего применяется 6-ой (Informational) уровень
логирования. Уровень 7 (Debugging) обычно используется при поиске неисправностей
(troubleshooting), например для определения проблем с построением VPN туннеля.

55
2.1.3 Console Logging
Подключившись к коммутатору или маршрутизатору по консоли вы сразу
увидите отображение логов. По умолчанию включен 5-ый уровень логирования. Если
устройство находится под нагрузкой (т.е. через него идет трафик), то ни в коем случае
не стоит повышать уровень логирования, иначе вы просто не сможете работать из
консоли, т.к. постоянно появляющиеся логи не дадут вам набрать команды. Кроме
того, если вы просто вытащите консольный кабель, то логи будут продолжать
отсылаться в консоль и отнимать существенные ресурсы устройства.
-----------------------------
Используйте ​Console Logging​только при необходимости.
-----------------------------
Однако бывают случаи (обычно на этапе тестирования), когда Console Logging
наиболее удобен, т.к. позволяет наблюдать за устройством в реальном времени. Для
настройки уровня логирования используйте команду:
Router(config)#logging console 7

или
Router(config)#logging console debugging

Если логи начинают мешать работе в консоли, то либо измените уровень

логирования, либо просто отключите их командой:
R1(config)#no logging console

2.1.4 Buffered Logging

Как было сказано выше, логи можно хранить на самом устройстве, в так
называемом буфере - RAM память. При этом вы можете изменять размер этого
буфера, тем самым регулируя “глубину” логирования. Следует весьма аккуратно
подходить к выбору размера буфера. Как правило он зависит от свободной
оперативной памяти устройства. Настроив слишком маленький буфер вы рискуете
упустить важные события, которые будут затерты при исчерпании свободного места.
Выбрав слишком большой буфер вы можете занять всю свободную оперативную
память устройства, что приведет к неизвестным последствиям (обычно это
зависание).
Как правило размер буфера устанавливается в 16, либо 32 Кбайта. Более
современные устройства позволяют выделять под логи несколько мегабайт
оперативной памяти. Настройка элементарна:
Router(config)# logging on
Router(config)# logging buffered 32768
Router(config)# logging buffered informational

В данном случае мы сначала включили Buffered Logging, затем установили размер

буфера в 32 Кбайта и выбрали уровень логирования informational (т.е. 6-ой). Для
просмотра логов используйте команду ​show log​из привилегированного режима.

56
 -----------------------------
Настройте ​Buffered Logging​даже при использовании ​Syslog-сервера​.
-----------------------------

Ни в коем случае не пренебрегайте данным методом сбора логов, даже если

вы используете Syslog-сервер. Может быть ситуация, когда Syslog-сервер окажется
недоступен и тогда логи будут безвозвратно потеряны, если вы не используете
Buffered Logging.

2.1.5 Terminal Logging

Как было сказано ранее, иногда бывают ситуации, когда нужно видеть логи в
режиме реального времени, как в примере с Console Logging. В этом случае вывод
логов прямо в консоль устройства намного удобнее, чем постоянно набирать команду
show log для отображения сообщений из буфера устройства. Но не всегда есть
возможность использовать консоль. Как быть при удаленном подключении (Telnet,
SSH)? Для решения этой проблемы существует команда ​terminal monitor​, которая и
позволяет выводить логи в терминальную сессию. При этом вы также можете задать
уровень логирования:
Router(config)#logging monitor informational
Router(config)#exit
Router#terminal monitor

Обратите внимание, что команда ​ terminal monitor вводится из привилегированного

режима, а не из режима глобальной конфигурации. Для отключения логов
воспользуйтесь командой ​terminal no monitor​.
Включая ​terminal monitor помните об увеличении нагрузки на устройство и
важности уровней логирования. Также стоит учитывать пропускную способность
канала по которому вы подключены. При большом объеме логов канал может
оказаться полностью забит, что приведет к разрыву терминальной сессии (т.е. вы
потеряете управление).
-----------------------------
Используйте ​Terminal Logging​с осторожностью и только в случае острой
необходимости.
-----------------------------
От себя могу добавить, что использовать Terminal Logging необходимо в
весьма редких ситуациях. В остальном, гораздо удобнее использовать Syslog-сервер.

2.1.6 Syslog-сервер
Главная задача ​Лог-сервера - централизованный сбор логов со всех сетевых
устройств.

57
Логи собираются на выделенном Лог-сервере, который может иметь огромное
дисковое пространство, что позволяет хранить события за гораздо больший
временной интервал (6, 12 месяцев и даже больше). Мониторинг существенно
упрощается при использовании Лог-сервера, т.к. в этом случае нет нужды
подключаться к каждому устройству для проверки журнала событий. Лог-сервер
является обязательным элементом любой более-менее серьезной сети.
Сбор логов осуществляется с помощью специализированных протоколов.
Syslog ​является практически стандартом, поэтому Syslog-сервер часто называют
просто Лог-сервер. Данный протокол использует ​514 (UDP) порт, а все данные
пересылаются в открытом виде. Еще одним популярным методом сбора Логов
является ​SNMP Traps​. Выбирая Лог-сервер, убедитесь, что он поддерживает данные
технологии.
В качестве примера Лог-сервера можно привести ​Kiwi Syslog сервер​, который
имеет бесплатную версию для Windows систем. Для Linux систем выбор гораздо
больше. Есть множество вариантов, как бесплатных, так и платных, стоимость которых
достигает сотни тысяч долларов.
-----------------------------
Используйте Лог-серверы для централизованного сбора логов.
-----------------------------
Здесь стоит отметить, что хранение Логов не является панацеей. Представьте,
что ежедневно в вашей сети генерируется более миллиона событий (а это весьма
скромный показатель для сети средних размеров). При этом в Логах содержится не
только полезная информация. Как разобраться в этом хаосе? Именно поэтому сейчас
становятся очень популярными Лог-серверы, которые обладают функцией
расширенного поиска и автоматическим анализом и корреляцией событий. Это
позволяет выделять самое главное из огромной массы событий. Такие Лог-серверы
относятся к категории ​Log Managment или ​SIEM ​системам. Данная тема очень
обширна и заслуживает отдельной книги, поэтому мы не будем рассматривать ее
более подробно. Однако, мне хотелось бы отметить несколько продуктов, которые
заслуживают внимания (по субъективному мнению автора):
1) Splunk
2) Graylog
58
 3) OSSIM
4) ELK (Elastic Stack)
Дабы не перегружать книгу сторонней информацией, оставлю данную тему для
самостоятельного ознакомления. Могу лишь добавить, что если вы пользуетесь
Логами в своей ежедневной работе, то рано или поздно вам придется отказаться от
классических Лог-серверов в пользу систем с функцией анализа и корреляции
событий. Это своего рода эволюция в сегменте продуктов обработки данных.
Теперь рассмотрим элементарный процесс настройки оборудования Cisco для
отправки Логов на выделенный Лог-сервер:
Router(config)#logging host 192.168.1.100 \адрес Syslog-сервера
Router(config)#logging trap informational \6-ой уровень логирования

Кроме того, вы можете настроить категории логов (​facilities​), на основе которых

Syslog-сервер будет сортировать все сообщения. Однако, данная настройка сильно
зависит от выбранного сервера, поэтому мы не будем раскрывать данную тему.

2.1.7 SNMP Traps

Это последний метод сбора логов, который мы рассмотрим (т.к. ААА мы
рассмотрели ранее). Самое главное преимущество ​SNMP Traps - возможность
передачи логов касающихся конкретного параметра устройства, например:
температура процессора, напряжение сети, изменение в конфигурации и т.д. Это
существенно отличается от “классических” уровней логирования, где логи просто
разбиты на категории. С помощью SNMP Traps можно существенно сократить
количество логов и мониторить только действительно нужные параметры, исключая
остальной “мусор”. Тема SNMP весьма обширна и требует изложения серьезной
теоретической базы, поэтому, с вашего позволения, мы не будем рассматривать эту
тему в рамках данной книги.

2.1.8 Безопасность логов

Возвращаясь к теме Syslog-сервера стоит помнить, что все логи передаются в
совершенно открытом виде. Весьма часто в логах содержится очень важная
информация, которой может воспользоваться злоумышленник. Чтобы защитить
Syslog-сообщения от несанкционированного доступа лучше всего использовать
выделенный сегмент (VLAN) для всего управляющего трафика, как это описано в
пункте 1.2.5. Кроме того, сам Лог-сервер представляет большой интерес для хакера.
Злоумышленник может либо получить нужную информацию, либо удалить сообщения,
связанные со взломом системы, что позволит ему “замести следы” своей атаки.
Например он может удалить все сообщения связанные с неудачным вводом пароля,
которые были сгенерированы при brute force атаке.
Еще одним примером атаки на Лог-сервер может быть простое переполнение,
когда злоумышленник генерирует огромное количество ложных сообщений. В
результате на Лог-сервере просто кончается место для обработки настоящих событий.
Это открывает для хакера возможность быть незамеченным при взломе системы.
Учитывая описанные риски, заранее позаботьтесь о защите Лог-сервера.

59
 Первое, что нужно сделать, это ограничить доступ к Syslog-серверу с помощью
access-list-ов. Причем не только доступ к администрированию сервера (SSH, HTTPS и
т.д.), но и доступ устройств к серверу по протоколу syslog (UDP, порт 514). Т.е.
отправлять логи на сервер могут только те устройства, которым вы открыли доступ.
Некоторые события (DDoS) также генерируют огромное количество лог
сообщений, что в итоге может перегрузить Лог-сервер. Чтобы этого избежать в Cisco
IOS предусмотрена возможность ограничения пересылаемых логов за единицу
времени. Ограничение настраивается следующим образом:
Router(config)#logging rate-limit all 50

В данном случае мы ограничили отправку syslog до 50 сообщений в секунду.

-----------------------------
Уделите особое внимание защите ​Syslog-сервера​.
-----------------------------

2.1.9 Время
Логи совершенно бесполезны если по ним нельзя точно определить, когда
именно произошло то или иное событие. Именно поэтому нужно убедиться, что на
всех сетевых устройствах установлено корректное время. Настройку времени можно
производить вручную, но в таком случае вы не сможете с точностью до секунды
синхронизировать время на всем оборудовании. Расхождение даже в пару секунд
может существенно усложнить анализ логов, особенно при расследовании ИБ
инцидентов. Для решения этой проблемы используется протокол ​NTP​.
Network Time Protocol (NTP) - протокол сетевого времени, если дословно. NTP
используется для синхронизации времени. Мы не будем подробно останавливаться на
описании этого протокола. Идея заключается лишь в том, что логи должны
сопровождаться актуальным временем, а это обязывает нас использовать
NTP-сервер​. Настройка оборудования Cisco как NTP-клиента:
Router(config)#ntp server 192.168.1.100 \указывает NTP-сервер

Кроме того, необходимо настроить часовой пояс (в моем случае время по Москве):
Router(config)#clock timezone MSK 4\часовой пояс +4

Но этого недостаточно. Перед отправкой логов, они должны быть снабжены

специальными временными метками, иначе мы не сможем определить время по
сообщению на Лог-сервере. Для установки временных меток используется команда:
Router(config)#service timestamps log datetime msec localtime show-timezone

В результате, каждое лог-сообщение будет снабжаться временной меткой из которой

можно узнать время (с точностью до миллисекунды) и часовой пояс.
-----------------------------
Не забывайте про настройку ​NTP​и ​Timestamps​.
-----------------------------

60
2.2 Лишние сервисы
В первой главе книги ( пункт 1.1.1) я упомянул такой протокол как ​CDP​, который
по умолчанию включен почти на всех устройствах Cisco (речь идет о коммутаторах и
маршрутизаторах). CDP позволяет обнаруживать соседние устройства, включая
информацию о прошивке, платформе, ip-адресе и т.д. За всю свою многолетнюю
практику я лишь пару раз видел, чтобы CDP действительно использовался
системными администраторами по назначению. В 99% случаев, данный протокол
просто продолжал работать в фоновом режиме. Но самое интересное, что таких
“лишних” (неиспользуемых) протоколов или сервисов довольно много (например ​HTTP
или ​Finger​). И почти все имеют свои потенциальные уязвимости, что оставляет для
хакера возможные лазейки.
Ниже приведены команды, которые позволяют отключить те сервисы, которые в
большинстве случаев просто не используются:
no service tcp-small-servers echo
no service tcp-small-servers discard
no service tcp-small-servers daytime
no service tcp-small-servers chargen
no service udp-small-servers echo
no service udp-small-servers discard
no service udp-small-servers daytime
no service udp-small-servers chargen
no ip finger
no ip bootp server
no ip dhcp boot ignore
no service dhcp
no mop enabled
no ip domain-lookup
no service pad
no ip http server
no ip http secure-server
no service config
no cdp enable
no cdp run
no lldp transmit
no lldp receive
no lldp run global

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

после ​conf t​). Наличие некоторых команд сильно зависит от версии прошивки. Мы не
будем описывать каждый из этих сервисов в целях экономии времени читателя.
Неиспользуемые сервисы весьма опасны, т.к. обычно администратор не
занимается их настройкой, а значит все параметры имеют значения по умолчанию, что
в итоге позволяет предсказать поведение системы во время специализированных
хакерских атак. Отключение неиспользуемых сервисов существенно повысит
безопасность вашей сети.
-----------------------------
Отключите неиспользуемые сервисы.
-----------------------------

61
2.3 Резервная память
Многие хакерские атаки нацелены на исчерпание ресурсов узла, т.е. ​DoS или
DDoS​. Делается это либо с целью создания обычного простоя, либо для эксплуатации
некоторой уязвимости. Для того, чтобы правильно отреагировать на ту или иную атаку,
нужно для начала понять ее природу. Это возможно только при подключении к
устройству. Однако, при таких атаках почти всегда невозможен ни удаленный, ни
локальный (через консоль) доступ к оборудованию. У устройства просто заканчивается
свободная оперативная память, которая необходима для создания консольной или
терминальной сессии. Такая проблема может возникнуть не только при хакерской
атаке, но и при неверной настройке, которая привела к исчерпанию ресурсов
устройства.
В относительно новых прошивках Cisco появилась возможность
резервирования RAM памяти для консольного подключения. Это значит, что даже при
высокоинтенсивной атаке на ваш маршрутизатор, сохраняется достаточное
количество ресурсов для консольной сессии. Это позволит подключиться к устройству
и увидеть, что именно происходит. Настройка элементарна:
Router(config)#memory reserve console 4096 \резервируем 4 Мб

В данном случае мы зарезервировали 4 Мб оперативной памяти. Обычно этого

хватает для консольной сессии.
-----------------------------
Зарезервируйте оперативную память для консольного подключения.
-----------------------------

2.4 Защищенные протоколы

Ранее мы уже описали, что весьма опасно использовать ​Telnet​, т.к. все данные
передаются в открытом виде и злоумышленник может их с легкостью перехватить. В
качестве альтернативы был предложен протокол ​SSH​, который шифрует все по
умолчанию. Аналогичная ситуация с ​HTTP​и ​HTTPS​.
Однако, при работе с сетевым оборудованием редко удается обойтись
вышеуказанными протоколами. Ниже мы рассмотрим еще несколько популярных
протоколов, а точнее их более защищенные версии.

2.4.1 SCP
Перед системными администраторами довольно часто возникает задача по
обновлению прошивки оборудования. Для этого необходимо “закинуть” новую
прошивку на устройство, что обычно делается с помощью ​TFTP или ​FTP​-сервера.
Технология стара как мир, да и подобный сервер разворачивается в несколько кликов.
Данные протоколы (TFTP и FTP) также нередко используются для резервного
копирования конфигураций устройств. Наверняка большинству знакома команда
вроде:
Router#copy running-config tftp:

62
Этой командой мы копируем текущую конфигурацию на удаленный TFTP-сервер.
Либо обратная ситуация, когда TFTP или FTP-сервер используется для
восстановления конфигурации:
Router#copy tftp: running-config

И если в случае с прошивками нет ничего криминального, то при работе с

конфигурациями совершенно недопустимо использовать незащищенный TFTP или
FTP-сервер. По аналогии с Telnet, эти протоколы передают все данные в открытом
виде, что позволяет злоумышленнику перехватить весьма ценную информацию -
конфигурации ваших устройств. Для решения данной проблемы существует более
защищенный протокол, такой как ​SCP​
.
SCP (secure copy) - протокол копирования файлов, который в качестве
транспорта использует SSH (т.е. все передаваемые файлы шифруются). Для работы
необходим ​SCP-сервер​, которым может являться любой Linux дистрибутив с
включенным SSH-сервером. Для Windows имеется специализированное программное
обеспечение, например ​Solarwinds SFTP/SCP Server (доступна бесплатная версия).
Сам процесс резервного копирования выглядит следующим образом:
Router#copy running-config scp://user:[email protected]/Cisco-Conf/Router1.config

Данной командой мы копируем текущую конфигурацию на SCP-сервер с ip-адресом

192.168.1.100 в папку ​Cisco-Conf​, а сам файл будет называться ​Router1.config​. Для
подключения к SCP-серверу используется логин и пароль, которые должны быть
предварительно созданы на сервере. При этом вся передаваемая информация
шифруется.
-----------------------------
Используйте ​SCP​вместо ​TFTP​.
-----------------------------

2.4.2 SNMP
SNMP - Simple Network Management Protocol​. Если перевести дословно, то
получится “простой протокол сетевого управления”. Несмотря на название, данный
протокол весьма редко используют именно для управления. Наиболее частое
применение SNMP - мониторинг. Температура процессора, загрузка канала, свободная
оперативная память и так далее. Те же ​SNMP Traps​, которые мы обсуждали в пункте
2.1.7. Опять же, мы не будем подробно рассматривать работу этого протокола, т.к. это
выходит за рамки нашей книги. Более подробно можно почитать на данном ​ресурсе​ .
Мы же сосредоточимся на лучших практиках.
Существует три версии протокола: ​SNMPv1, SNMPv2c ​и SNMPv3​. Не вдаваясь
в подробности можно резюмировать, что до появления SNMPv3, главной проблемой
SNMP была именно безопасность. Первые две версии протокола имеют очень слабый
механизм аутентификации, по сути это лишь один пароль (строка сообщества),
который передается в открытом виде. Это весьма серьезная уязвимость, которая
позволяет злоумышленнику перехватить этот пароль, после чего он может получить
всю необходимую информацию с устройства, на котором запущен SNMP. Если же вы

63
используете SNMP для управления, то ситуация с безопасностью требует еще
большего внимания.
Для решения данной проблемы безопасности был создан протокол SNMPv3,
который может использоваться в трех вариантах:
1. noAuthNoPriv - пароли передаются в открытом виде, конфиденциальность
данных отсутствует;
2. authNoPriv​- аутентификация без конфиденциальности;
3. authPriv​- аутентификация и шифрование.
Как вы понимаете, лучше использовать именно третий вариант, который обеспечивает
максимальный уровень защищенности.
-----------------------------
Используйте протокол ​SNMPv3​с аутентификацией и шифрованием.
-----------------------------
Хотелось бы добавить, что протокол SNMP является важной частью любой
корпоративной сети. Он широко применяется для мониторинга всей
ИТ-инфраструктуры. Существует даже специализированное программное
обеспечение для этих целей (например ​Zabbix​), которое автоматически собирает
огромное количество информации о всей сети. Эта информация может нести угрозу,
если попадет “в руки” злоумышленника. Именно поэтому защищенный вариант SNMP
является важным шагом к безопасности вашей сети.

2.5 Резервные копии

Наверняка вы слышали поговорку “Админы делятся на два типа. На тех, кто
еще не делает бэкапы, и тех, кто их уже делает”. Поговорка полна иронии, но “в
каждой шутке есть доля шутки”.
Очень многие часто забывают про такой важный элемент информационной
безопасности, как резервное копирование. Отсутствие бэкапа (от англ. backup) может
привести к куда более серьезным последствиям, чем хакерская атака. Системы
резервного копирования являются одним из крупнейших сегментов как в области ИБ,
так и в области ИТ. Существует целый класс программного обеспечения и
оборудования, которое предназначено исключительно для создания бэкапов.
Стоимость таких систем может достигать десятки миллионов (и даже не рублей).
Рентабельность таких проектов зависит исключительно от стоимости данных, которые
могут быть утеряны.
Чаще всего такие дорогостоящие системы применяются для резервного
копирования серверов, виртуальных машин, баз данных и т.д. Мы же рассматриваем
безопасность сетевых устройств. Все что нам нужно бэкапить, это конфигурации
коммутаторов и маршрутизаторов. В данном случае мы сможем обойтись практически
подручными средствами без финансовых затрат. При таком раскладе “проблема”
резервного копирования всего лишь вопрос желания и ответственности
администратора.
В оборудовании Cisco есть два режима бэкапов:
1) Регулярные бэкапы. Название говорит само за себя. Бэкапы создаются
автоматически через некоторый промежуток времени.

64
 2) Бэкапы по команде. Иногда есть необходимость в срочном бэкапе, например
перед серьезными изменениями конфигурации. В случае неудачной настройки
мы можем практически мгновенно восстановить прежнюю, работоспособную
конфигурацию.
Оба режима настраиваются буквально в 5 команд:
Router(config)#archive
Router(config-archive)#path flash:backup-config
Router(config-archive)#maximum 14
Router(config-archive)#time-period 1440
Router(config-archive)#write-memory

Здесь мы указали, что бэкапы нужно “складывать” на ​flash​ -память, при этом
максимальное количество бэкапов - ​14 (затем более новые будут затирать старые).
Периодичность бэкапов составляет ​1440 минут, что соответствует одному дню. Кроме
того, бэкап будет создаваться автоматически при использовании команды ​write
memory​. Если после этого набрать команду ​show archive​, то можно увидеть
созданные бэкапы.
Большинство инструкций на этом заканчивается. Однако на мой взгляд
приведенных действий недостаточно. Т.к. бэкапы создаются локально, то остается
риск потери конфигурации при поломке самого устройства. Т.е. если “сгорит”
маршрутизатор, то мы безвозвратно потеряем настройки, что исключает быстрое
восстановление сети. Очевидно, что бэкапы нужно хранить централизованно, на
выделенном сервере. При этом мы уже обсуждали ранее (пункт 2.4.1), что для таких
целей лучше всего подойдет защищенный ​SCP-сервер (вместо традиционного ​TFTP​ ).
Это исключит возможность перехвата конфигурации при резервном копировании. Для
настройки требуется всего лишь заменить строку с параметром ​path​:
Router(config-archive)#path scp://user:[email protected]/Cisco-Conf/$h-$t

Обратите внимание на параметры ​$h и ​$t​. Это так называемые переменные

окружения. При их использовании ​$h автоматически заменится на ​hostname
устройства (в данном случае это Router), а ​$t - на системное время. В итоге мы
получим бэкап на SCP-сервере в папке ​Cisco-Conf с именем вида
Router-Apr--8-04-19-44.661-0​. Это весьма удобно, особенно когда на один сервер
“льются” бэкапы нескольких устройств. Хотелось бы отметить, что данный функционал
доступен в относительно новых прошивках.
-----------------------------
Настройте резервное копирование конфигураций.
-----------------------------
Следует отметить, что существуют специальные программы для резервного
копирования настроек сетевых устройств. Некоторые пишут свои собственные
скрипты. Во многом эти средства превосходят описанный метод. Однако у нашего
примера есть главное преимущество - простота. От идеи до реализации всего
несколько команд.

65
2.6 Логирование команд
В пункте 1.3.7, который посвящен ​ААА​, мы обсуждали ​Accounting​. Главная
цель использования данной технологии - логирование команд. Т.е. иметь возможность
проследить, что именно делал на оборудовании тот или иной пользователь. Однако
мы также обсуждали, что использование ​ААА-сервера целесообразно если в сети
более 10 устройств. Что же делать администраторам небольших сетей?
Относительно новые версии Cisco IOS позволяют логировать все
используемые команды на устройстве. Делается это также с помощью функции
archive​. Кроме того, из логов можно автоматически “вырезать” вводимые пароли, а
также отправлять эти логи на ​syslog-сервер​. Настройки выглядят следующим
образом:
Router(config)#archive
Router(config-archive)#log config
Router(config-archive-log-cfg)#logging enable /включаем логирование команд
Router(config-archive-log-cfg)#logging size 200 /задаем количество строк
Router(config-archive-log-cfg)#hidekeys /”прячем” пароли
Router(config-archive-log-cfg)#notify syslog /отправляем на syslog-сервер

Теперь с помощью команды ​show archive log config all мы можем видеть кто, как и
что именно настраивал:
Router#show archive log config all
idx sess user@line Logged command
1 1 console@console | logging enable
2 1 console@console | logging size 200
3 1 console@console | hidekeys
4 1 console@console | notify syslog

-----------------------------
В случае отсутствия ​ААА-сервера​настройте логирование вводимых команд.
-----------------------------
Хочу заметить, что метод ААА является более универсальным и
профессиональным решением. Однако, в некоторых случаях, описанное решение
будет более разумным вариантом.

2.7 Обновления
Наверняка вы заметили, что обсуждая некоторые функции безопасности, я
периодически упоминаю, что они доступны только в новых версиях прошивок, что уже
является весомым поводом для обновления. Однако расширенный функционал не
является главной причиной для обновления прошивки. Старое программное
обеспечение несет в себе серьезную угрозу для любой сети.
Весьма часто вендор публикует информацию о новых уязвимостях своих
продуктов и выпускает новую версию прошивки, либо патч, который должен устранить
эти “дыры”. Такие публикации называются “Вендорский бюллетень безопасности”.
Более того, на некоторых ресурсах можно найти соответствующие эксплойты (для
Exploit-DB или Metasploit), которые можно тут же попробовать для оценки
защищенности вашей сети. Для примера можно привести сайт ​Vulners​, который многие
называют “Гугл для хакера”.
66
 Как ни странно, но эта информация может быть полезна не только для “честных
граждан”. Фактически хакерам сообщают о новых уязвимостях, которые с большой
долей вероятности еще не успел никто “закрыть”. Это открывает перед ними широкие
возможности. Вы можете поставить самый дорогой межсетевой экран, однако, после
обнаружения его уязвимостей и выпуска соответствующих эксплойтов, взломать вашу
сеть сможет даже школьник. Именно поэтому очень важно держать все свои системы в
максимально актуальном состоянии - самые последние прошивки, патчи и т.д.
-----------------------------
Регулярно проверяйте наличие обновлений. У вас должны быть самые “свежие”
прошивки.
-----------------------------
Регулярно следите за новостями о новых уязвимостях на специализированных
ресурсах. Кроме того, на сайте ​Vulners можно подписаться на интересующие темы и
автоматически получать информацию о новых угрозах (имеется Telegram-бот). Мы не
будем подробно рассматривать данный сервис, т.к. эта тема выходит за рамки нашей
книги, однако я настоятельно рекомендую ее к ​ознакомлению​.
В заключении данного параграфа мне хотелось бы вспомнить еще один случай
из личной практики. Работая у одного из заказчиков я обнаружил коммутатор, который
работал без перезагрузок (uptime) целых 11 лет. Это конечно великолепный
показатель для оборудования - надежность. Однако за эти 11 лет используемая
прошивка уже перестала поддерживаться, а количество уязвимостей исчисляется
десятками. Не делайте подобных ошибок.

2.8 Чек-лист №2
Вторая глава подошла к концу, резюмируем все вышесказанное в виде
Чек-листа №2:
1) Информационная безопасность невозможна без использования логов.
2) Используйте несколько способов сбора логов.
3) С осторожностью используйте повышенные уровни логирования.
4) Используйте ​Console Logging​только при необходимости.
5) Настройте ​Buffered Logging​даже при использовании ​Syslog-сервера​.
6) Используйте ​Terminal Logging с осторожностью и только в случае острой
необходимости.
7) Используйте Лог-серверы для централизованного сбора логов.
8) Уделите особое внимание защите ​Syslog-сервера​.
9) Не забывайте про настройку ​NTP​и ​Timestamps​.
10) Отключите неиспользуемые сервисы.
11) Зарезервируйте оперативную память для консольного подключения.
12) Используйте ​SCP​вместо T
​ FTP​.
13) Используйте протокол ​SNMPv3​с аутентификацией и шифрованием.
14) Настройте резервное копирование конфигураций.
15) В случае отсутствия ​ААА-сервера настройте логирование вводимых
команд.
16) Регулярно проверяйте наличие обновлений. У вас должны быть самые
“свежие” прошивки.

67
2.9 Пример конфигурации

1) Настройка ​Buffered Logging​и уровня логирования

Router(config)# logging on
Router(config)# logging buffered 32768
Router(config)# logging buffered informational

2) Настройка ​Syslog​-сервера и уровня логирования

Router(config)#logging host 192.168.1.100
Router(config)#logging trap informational

3) Ограничение количества логов с одного устройства

Router(config)#logging rate-limit all 50

4) Настройка времени
Router(config)#ntp server 192.168.1.100
Router(config)#clock timezone MSK 4
Router(config)#service timestamps log datetime msec localtime show-timezone

5) Резервирование оперативной памяти для консольного подключения

Router(config)#memory reserve console 4096

6) Настройка резервного копирования конфигурации на SCP-сервер

Router(config)#archive
Router(config-archive)#path scp://user:[email protected]/Cisco-Conf/$h-$t
Router(config-archive)#maximum 14
Router(config-archive)#time-period 1440
Router(config-archive)#write-memory

7) Настройка логирования команд (в случае отсутствия ААА-сервера)

Router(config)#archive
Router(config-archive)#log config
Router(config-archive-log-cfg)#logging enable
Router(config-archive-log-cfg)#logging size 200
Router(config-archive-log-cfg)#hidekeys
Router(config-archive-log-cfg)#notify syslog

8) Отключение "лишних" сервисов

no service tcp-small-servers echo
no service tcp-small-servers discard
no service tcp-small-servers daytime
no service tcp-small-servers chargen
no service udp-small-servers echo
no service udp-small-servers discard
no service udp-small-servers daytime
no service udp-small-servers chargen
no ip finger
no ip bootp server
no ip dhcp boot ignore
no service dhcp
no mop enabled
no ip domain-lookup

68
no service pad
no ip http server
no ip http secure-server
no service config
no cdp enable
no cdp run
no lldp transmit
no lldp receive
no lldp run global

Для приобретения полной версии книги обращайтесь на электронный адрес

[email protected]​. Книга доступна только в электронной версии!
--------------------
Стоимость книги 399 рублей
---------------------
(Для тех, кто ранее приобретал продукты NetSkills - ​10% скидка​. Не забудьте указать
скидку при заказе!)

69