По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Сетевые устройства могут работать в режимах, которые подразделяются на три большие категории.
Первая и основная категория- это передача данных (плоскость данных, data plane). Это режим работы коммутатора по передаче кадров, генерируемых устройствами, подключенными к коммутатору. Другими словами, передача данных является основным режимом работы коммутатора.
Во-вторых, управление передачей данных относится к настройкам и процессам, которые управляют и изменяют выбор, сделанный передающим уровнем коммутатора. Системный администратор может контролировать, какие интерфейсы включены и отключены, какие порты работают с какой скоростью, как связующее дерево блокирует некоторые порты, чтобы предотвратить циклы, и так далее. Так же важной частью этой статьи является управление устройством, осуществляемое через плоскость наблюдения (management plane). Плоскость наблюдения - это управление самим устройством, а не управление тем, что делает устройство. В частности, в этой статье рассматриваются самые основные функции управления, которые могут быть настроены в коммутаторе Cisco. В первом разделе статьи рассматривается настройки различных видов безопасности входа в систему. Во втором разделе показано, как настроить параметры IPv4 на коммутаторе, чтобы им можно было управлять удаленно. В последнем разделе рассматриваются практические вопросов, которые могут немного облегчить жизнь системного администратора.
Защита коммутатора через CLI
По умолчанию коммутатор Cisco Catalyst позволяет любому пользователю подключиться к консольному порту, получить доступ к пользовательскому режиму, а затем перейти в привилегированный режим без какой-либо защиты. Эти настройки заданы в сетевых устройствах Cisco по умолчанию и, если у вас есть физический доступ к устройству, то вы спокойно можете подключиться к устройству через консольный порт или USB, используя соответствующий кабель и соответственно производить различные настройки.
Однако не всегда имеется физический доступ к коммутатору и тогда необходимо иметь доступ к устройствам для удаленного управления, и первым шагом в этом процессе является обеспечение безопасности коммутатора так, чтобы только соответствующие пользователи могли получить доступ к интерфейсу командной строки коммутатора (CLI).
Настройка парольного доступа к коммутатору Cisco
В данной части рассматривается настройка безопасности входа для коммутатора Cisco Catalyst.
Защита CLI включает защиту доступа в привилегированный режим, поскольку из этого режима злоумышленник может перезагрузить коммутатор или изменить конфигурацию.
Защита пользовательского режима также важна, поскольку злоумышленники могут видеть настройки коммутатора, получить настройки сети и находить новые способы атаки на сеть.
Особенно важно, что бы все протоколы удаленного доступа и управления, чтобы IP-настройки коммутатора были настроены и работали.
Для того чтобы получить удаленный доступ по протоколам Telnet и Secure Shell (SSH) к коммутатору, необходимо на коммутаторе настроить IP-адресацию.
Чуть позже будет показано, как настроить IPv4-адресацию на коммутаторе.
В первой части статьи будут рассмотрены следующие вопросы защиты входа:
Защита пользовательского режима и привилегированного режима с помощью простых паролей;
Защита доступа в пользовательский режим с использованием локальной базы данных;
Защита доступа в пользовательский режим с помощью внешних серверов аутентификации;
Защита удаленного доступа с помощью Secure Shell (SSH);
Защита пользовательского и привилегированного режима с помощью простых паролей.
Получить полный доступ к коммутатору Cisco можно только через консольный порт.
В этом случае, настройки по умолчанию, позволяют получить доступ сначала к режиму пользователя, а затем можно перейти в привилегированный режим без использования паролей.
А вот по протоколам удаленного доступа Telnet или SSH получить доступ даже к режиму пользователя невозможно.
Настройки по умолчанию идут у совершенно нового коммутатора, но в производственной среде необходимо обеспечить безопасный доступ через консоль, а также включить удаленный вход через Telnet и/или SSH, чтобы была возможность подключаться ко всем коммутаторам в локальной сети.
Можно организовать доступ к сетевому оборудованию с использованием одного общего пароля.
Этот метод позволяет подключиться к оборудованию, используя только пароль - без ввода имени пользователя - с одним паролем для входа через консольный порт и другим паролем для входа по протоколу Telnet. Пользователи, подключающиеся через консольный порт, должны ввести пароль консоли, который был предварительно настроен в режиме конфигурации. Пользователи, подключающиеся через протокол Telnet, должны ввести пароль от Telnet, также называемый паролем vty, так называемый, потому что это режим конфигурации терминальных линий (vty). На рисунке 1 представлены варианты использования паролей с точки зрения пользователя, подключающегося к коммутатору.
Как видно из рисунка 1, на коммутаторах Cisco стоит защита привилегированного режима (enable) с помощью еще одного общего пароля, задаваемый командой enable password. Системный администратор, подключающийся к CLI коммутатора попадает в режим пользователя и далее, вводит команду enable.
Эта команда запрашивает у пользователя пароль входа в привилегированный режим; если пользователь вводит правильный пароль, IOS перемещает пользователя в привилегированный режим.
Пример 1. Пример входа в коммутатор из консоли, когда пароль консоли и пароль привилегированного режима были заранее установлены. Предварительно пользователь запустил эмулятор терминала, физически подключил ноутбук к консольному кабелю, а затем нажал клавишу Enter, чтобы войти в коммутатор.
(User now presses enter now to start the process. This line of text does not appear.)
User Access Verification
Password: cisco
Switch> enable
Password: cisco
Switch#
В примере показаны пароли в открытом виде, как если бы они были набраны в обычном текстовом редакторе (cisco), а также команда enable, которая перемещает пользователя из пользовательского режима в привилегированный режим (enable). В реальности же IOS скрывает пароли при вводе, чтобы никто не смог увидеть их.
Чтобы настроить общие пароли для консоли, Telnet и привилегированного режима (enable), необходимо ввести несколько команд. На рис. 2 показан порядок задания всех трех паролей.
На рисунке 2 показаны два ПК, пытающиеся получить доступ к режиму управления устройством. Один из ПК подключен посредством консольного кабеля, соединяющейся через линию console 0, а другой посредством Telnet, соединяющейся через терминальную линию vty 0 15. Оба компьютера не имеют Логинов, пароль для консоли и Telnet -cisco. Пользовательский режим получает доступ к привилегированному режиму (enable) с помощью ввода команды "enable secret cisco". Для настройки этих паролей не надо прилагать много усилий. Все делается легко. Во-первых, конфигурация консоли и пароля vty устанавливает пароль на основе контекста: для консоли (строка con 0) и для линий vty для пароля Telnet (строка vty 0 15). Затем в режиме консоли и режиме vty, соответственно вводим команды:
login
password <пароль задаваемый пользователем>
Настроенный пароль привилегированного режима, показанный в правой части рисунка, применяется ко всем пользователям, независимо от того, подключаются ли они к пользовательскому режиму через консоль, Telnet или иным образом. Команда для настройки enable password является командой глобальной конфигурации: enable secret <пароль пользователя>.
В старых версиях, для задания пароля на привилегированный режим, использовалась команда password. В современных IOS применяется два режима задания пароля: password и secret.
Рекомендуется использовать команду secret, так как она наиболее безопасна по сравнению с password.
Для правильной настройки защиты коммутатора Cisco паролями необходимо следовать по шагам, указанным ниже:
Шаг 1. Задайте пароль на привилегированный режим командой enable secret password-value
Шаг 2. Задайте пароль на доступ по консоли
Используйте команду line con 0 для входа режим конфигурирования консоли;
Используйте команду liassword liassword-value для задания пароля на консольный режим;
Используйте команду login для запроса пароля при входе по консоли;
Шаг 3. Задайте пароль на терминальные подключения vty (Telnet)
Используйте команду line vty 0 15 для входа режим конфигурирования терминальных линий. В данном примере настройки будут применены ко всем 16 терминальным линиям;
Используйте команду liassword liassword-value для задания пароля на режим vty;
Используйте команду login для запроса пароля при входе по Telnet
В Примере 2 показан процесс настройки, согласно вышеописанным шагам, а также установка пароля enable secret. Строки, которые начинаются с ! - это строки комментариев. Они предназначены для комментирования назначения команд.
! Enter global configuration mode, set the enable password, and also set the hostname (just because it makes sense to do so)
Switch# configure terminal
Switch(config)# enable secret cisco
Switch#(config)# line console 0
Switch#(config-line)# password cisco
Switch#(config-line)# login
Switch#(config-line)# exit
Switch#(config)# line vty 0 15
Switch#(config-line)# password cisco
Switch#(config-line)# login
Switch#(config-line)# end
Switch#
Пример 3 показывает результирующую конфигурацию в коммутаторе, выводимой командой show running-config. Выделенный текст показывает новую конфигурацию. Часть листинга было удалено, что бы сконцентрировать ваше внимание на настройке пароля.
Switch# show running-config
!
Building configuration...
Current configuration: 1333 bytes
!
version 12.2
!
enable secret 5 $1$OwtI$A58c2XgqWyDNeDnv51mNR.
!
interface FastEthernet0/1
!
interface FastEthernet0/2
!
! Several lines have been omitted here - in particular, lines for
! FastEthernet interfaces 0/3 through 0/23.
!
interface FastEthernet0/24
!
interface GigabitEthernet0/1
!
interface GigabitEthernet0/2
!
line con 0
password cisco
login
!
line vty 0 4
password cisco
login
!
line vty 5 15
password cisco
login
В следующей статье рассмотрим тему защиты доступа в пользовательском режиме с помощью локальных имен пользователей и паролей.
В данной статье посмотрим и разберем, как создать простейшие ресурсы в облаке AWS (Amazon Web Services) с помощью замечательного инструмента IaaS, под названием Terraform. Для того, чтобы можно было повторить то, о чем пойдет речь в статье необходим действующий аккаунт AWS и рабочая машина (виртуальный сервер) с установленным Terraform, и текстовым редактором Atom + плагин для Terraform.
Первоначальная настройка данных инструментов разбиралась в предыдущих статьях. Описание в статье пойдет под операционную систему CentOS. Вы можете для тренировки использовать на свой вкус любую.
Для начала создадим папку под наш новый проект, можно непосредственно в домашней директории.
sudo mkdir terraform
Создадим первый файл нашего терраформ кода. Можно создать непосредственно в редакторе, через меню или в командной строке sudo touch myterr.tf. Принципиальной разницы, как будет создан файл нет. Если создали через командную строку открываем, как обычный файл в редакторе.
Далее схема работы следующая: пишем код в файле, сохраняем, производим управляющие команды в командной строке для выполнения или проверки данного кода, уничтожения, модификации элементов или объектов в облаке.
Как в начале статьи было сказано, нам необходим аккаунт AWS, чтобы терраформ взаимодействовал с облачной инфраструктурой, а более конкретно нам нужно создать пользователя и получить access key и secret key, для доступа к облаку. Это необходимо для аунтификации Terraform в AWS облаке.
Заходим в AWS консоль и выбираем сервис IAM. Заходим во вкладку пользователи и создаем новую учетную запись. Вводим имя пользователя в пустое поле. Нужно поставить Programmatic Фccess. Далее нажимаем Создать пользователя и попадаем на закладку назначения прав. Тут необходимо присоеденить уже созданный по умолчанию в AWS набор прав администратора. Далее переходим к страничке назначения Tag, тут по желанию вашему, если хотите то можете добавить тэги. Нажимаем кнопку создать пользователя.
Финальное окно будет выглядеть следующим образом.
Получаем те данные, которые нам необходимы для Terraform.
Очень важно - Secret key показывается только один раз!
Теперь в принципе все готово для создания первого ресурса в AWS.
Начинаем с объявления с каким облаком мы работаем.
provider “aws” {
}
Тем самым мы обозначили с каким облачным провайдером мы будем работать. В данном коде в отличии от YAML, количество пробелов не важно. Далее прописываем access key и secret key. В каком регионе будут использоваться ресурсы. Регион мы укажем eu-central-1 – это ЦОД расположенный в Европе во Франфуркте. Старайтесь регион указывать, поближе к себе, чтобы до ресурсов была минимальная задержка прохождения пакетов.
provider “aws” {
access_key = “тут ключ доступа”
secret key = “тут секретный ключ”
region = “eu-central-1”
}
При нажатии Ctrl+S, мы сохраняем и видим, что плагин аккуратно выправляет для удобства написанный код.
Теперь можно сделать первый ресурс. Например, инстанс в Амазон. Добавляем ниже:
resource “aws_instance” “my_название” {
ami = “”
instance_type = “”
}
Для поднятия ресурса необходимо указать 2 минимальные вещи. Это ami – image id и instance_type. Теперь необходимо пойти в указанный регион, открыть EC2 и посмотреть ami интересующего инстанса.
А тип возьмем t2.micro. Данный тип для новых аккаунтов на год бесплатный. Получаем код полностью готовый для развертывания первого инстанса.
В принципе все готово для запуска первого инстанса. Код Terraform будет выглядеть следующим образом:
provider “aws” {
access_key = “тут ключ доступа”
secret key = “тут секретный ключ”
region = “eu-central-1”
}
resource “aws_instance” “TestUbuntu” {
ami = “ami-0767046d1677be5a0”
instance_type = “t2.micro”
}
Запускаем консоль и переходим в директорию, где находится у нас Terraform.
Далее есть небольшой нюанс запуска, чтобы в коде не светить свои access_key и secret_key, эти данные можно убрать, экспортировав в переменные. Делается это следующим образом. С помощью команды export.
export AWS_ACCESS_KEY_ID=ключ
export AWS_SECRET_ACCESS_KEY=ключ
И можно убирать эти 2 строчки из кода.
Теперь запускаем Terraform. Первая команда, которую необходимо сделать это команда terraform init, данная команда пройдется по всем tf файлам, она увидит провайдера и скачает дополнительные файлы, необходимые для запуска в том числе и бинарники. Сам Terraform – это такая оболочка, которая подкачивает все, что ей необходимо.
Следующая команда, которая понадобится это terraform plan, данная команда позволяет посмотреть, что Terraform будет делать. Т.е нечто вроде Whatif. Данная команда очень важна т.к в крупных проектах, позволяет заранее посмотреть, что будет если мы запустим файл терраформа. Вывод ее большой, кусочек представлен на картинке.
Можно увидеть, что добавится. Достаточно удобно. Как мы видим, при команде на deploy, Terraform добавит в амазон 1 instance, т.е 1 виртуальную машину из указанного шаблона, указанного типа и размера.
Непосредственно для deploy, необходимо ввести команду terraform apply, прочитать что Terraform будет делать и явным образом, командой yes подтвердить.
После подтверждения видим следующую картину. Со стороны консоли.
Со стороны амазона спустя полминуты.
Как мы видим сервер создался и проходит инициализацию.
Привет, бро! В статье расскажем в чем разница между RIPv1 (Routing Information Protocol Version 1) и его продолжение RIPv2. Погнали?
Про Routing Information Protocol Version 1 (RIPv1)
Прямо и по пунктам:
RIPv1 это Distance-Vector протокол. Если переводить на русский - дистанционно-векторный. ;
Distance vector routing - так называемая дистанционно-векторная маршрутизация, главный принцип которой основан на вычислении специальных метрик, которые определяют расстояние (количество узлов) до сети назначения
RIPv1 это classfull протокол. Это означает, что он не отправляет маску подсети в апдейтах маршрутизации;
RIPv1 не поддерживает VLSM (Variable Length Subnet Masking);
VLSM (Variable Length Subnet Masking) - метод эффективного использования IP – адресации, который избавляет от привязки к классу сети (класс A, класс B, класс C). VLSM позволяет дробить подсеть на подсеть и так далее. Тем самым, мы можем эффективно использовать адресное пространство согласно реальных потребностей, а не класса сети;
RIPv1 поддерживает максимум 15 хопов! Это означает, что любой маршрутизатор, который расположен от вас в больше, чем 15 узлов (маршрутизаторов) будет отмечен как недоступный;
Раз в 30 секунд RIPv1 отправляет широковещательные апдейты маршрутизации – каждый узел должен принять и обработать этот апдейт;
Первая версия RIP не поддерживает авторизация апдейтов маршрутизации – это означает, что потенциально, роутер может обновить таблицу маршрутизации от любого источника;
Вот такой он, RIP первой версии. Двигаем дальше и посмотрим, а на что способен его брат – RIP второй версии?
Про Routing Information Protocol Version 2 (RIPv2)
RIPv2 это гибридный протокол. Он реализован на базе Distance-Vector, но так же поддерживает часть алгоритмов Link State маршрутизации, то есть, может отслеживать состояние каналов;
Link State routing - отслеживает состояние каналов и отправляет LSA (Link-state advertisement) пакеты, в которых рассказывает о состоянии своих каналов. Примером link state протокола маршрутизации является OSPF
RIPv2 - classless протокол. В отличие от своего старшего брата первой версии, второая версия умеет отправлять маску подсети в апдейтах маршрутизации;
RIPv2 поддерживает VLSM!;
RIPv2, как и RIPv1 поддерживает максимум 15 хопов;
RIPv2 отправляет мультикаст сообщения об апдейтах на адрес 224.0.0.9. Это уменьшает нагрузку на сеть и в первую очередь на узлы, на которых не запущен RIP;
Вторая версия RIP поддерживает аутентификацию апдейтов маршрутизации. Это значит, что теперь нельзя будет подсунуть ложный апдейт роутеру (в целом, этим могли пользоваться злоумышленники) – только авторизированные источники;