По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Привет! Сегодня в статье мы расскажем как скачать и установить VMware Workstation. Процесс установки одинаков для разных версий. Начнем!
Перед началом:
Перед загрузкой и установкой VMware Workstation:
Убедитесь, что ваш компьютер соответствует системным требованиям VMware Workstation
Убедитесь, что вы используете поддерживаемую гостевую операционную систему. Эти сведения можно найти в Руководстве по совместимости VMware.
Загрузка VMware Workstation
Чтобы загрузить VMware Workstation:
Перейдите в центр загрузки VMware Workstation Download Center.
В зависимости от ваших требований нажмите кнопку Go to Downloads для VMware Workstation для Windows или Linux.
Нажмите Download Now.
Если высветилась подсказка, войдите в свой профиль My VMware. Если у вас нет профиля, создайте его.
Убедитесь, что ваш профиль заполнен, и введите все обязательные поля.
Просмотрите лицензионное пользовательское соглашение и нажмите кнопку Yes.
Нажмите Download Now
Если установщик не загружается:
Удалите кэш в вашем браузере.
Отключите блокировку всплывающих окон в вашем браузере.
Загрузите с помощью другого приложения браузера.
Отключите любое локальное программное обеспечение брандмауэра.
Перезагрузите виртуальный компьютер.
Загрузите установщик с другого компьютера или из другой сети.
Установка VMware Workstation
Примечания:
У вас должна быть установлена только одна версия VMware Workstation. Перед установкой новой версии необходимо удалить предыдущую.
Если установщик сообщает об ошибке при запуске, необходимо проверить скачанные файлы.
Установка VMware Workstation в Windows
Войдите в хост-систему Windows как пользователь-администратор или как пользователь, являющийся членом локальной группы администраторов.
Откройте папку, в которую был загружен установщик VMware Workstation. По умолчанию он располагается в папке Downloads (Загрузки) для учётной записи пользователя в Windows host. Название файла установщика выглядит как VMware-workstation-full-xxxx-xxxx.exe, где xxxx-xxxx это номер версии и текущего варианта программы.
Правой кнопкой мыши щёлкните на установщик и выберите пункт Run as Administrator (Запуск от имени администратора).
Выберите вариант установки:
Стандартный: Устанавливает стандартные функции Workstation. Если в хост-системе есть встроенный виртуальный отладчик для Visual Studio или Eclipse, то устанавливаются соответствующие дополнительные модули Workstation.
Пользовательский: Позволяет выбрать, какие компоненты Workstation установить, а также указать место их установки. Выберите этот параметр, если Вам необходимо изменить каталог общих виртуальных компьютеров, изменить канал сервера VMware Workstation или установить расширенный драйвер виртуальной клавиатуры. Расширенный драйвер виртуальной клавиатуры обеспечивает лучшее управление международными клавиатурами и клавиатурами с дополнительными клавишами.
Следуйте инструкциям на экране, чтобы завершить установку.
Перезагрузите размещающее устройство.
Установка VMware Workstation в Linux
VMware Workstation для Linux доступна в качестве .bundle загрузки в Центре загрузки VMware. Установщик пакетов Linux запускает мастер графического интерфейса в большинстве форм распространения Linux. В некоторых дистрибутивах Linux установщик пакетов запускает мастер командной строки вместо мастера графического интерфейса.
Войдите в учётную запись пользователя Linux, которую вы планируете использовать с VMware Workstation.
Откройте интерфейс терминала.
Войдите рутом. Например:su root. Команда будет зависеть от дистрибутива и конфигурации Linux.
Измените каталог на тот, что содержит установочный файл пакета VMware Workstation. По умолчанию используется каталог Download (Загрузки).
Запустите соответствующий файл установщика Workstation для хост-системы. Например: sh VMware-workstation-Full-xxxx-xxxx.architecture.bundle [--option], где xxxx-xxxx это номер версии и текущего варианта программы, architecture это i386 или x86_64, option это параметр командной строки. В данной таблице описаны параметры командной строки:
ПараметрОписание --gtkОткрывает установщик VMware с графическим интерфейсом, опция по умолчанию. --consoleИспользуйте терминал для установки.--customИспользуйте этот параметр, чтобы настроить расположение установочных каталогов и поставить жёсткое ограничение на количество открытых файловых дескрипторов. --regularПоказывает необходимые вопросы по установке или те, на которые ранее не были даны ответы. Это опция по умолчанию. --ignore-errors или -IПозволяет продолжить установку даже при наличии ошибки в одном из сценариев установки. Поскольку раздел с ошибкой не завершен, компонент может быть настроен неправильно.
Примите лицензионное соглашение. Если Вы используете параметр --console или устанавливаете VMware Workstation на Linux host, который не поддерживает мастер графического интерфейса, нажмите клавишу Enter для прокрутки и чтения лицензионного соглашения или напечатайте q, чтобы перейти к полю да/нет.
Следуйте инструкциям или подсказкам на экране, чтобы завершить установку.
Перезапустите Linux host.
После установки
На хост-системах Windows:
Установщик создает ярлык рабочего стола, ярлык быстрого запуска или сразу оба в дополнение к пункту в меню Пуск.
Чтобы запустить VMware Workstation на системе Windows, выберите Start -> Programs -> VMware Workstation.
На хост-системах Linux:
VMware Workstation можно запустить из командной строки во всех дистрибутивах Linux.
В некоторых дистрибутивах Linux, VMware Workstation можно запустить в графическом интерфейсе из меню System Tools в разделе Applications.
Чтобы запустить VMware Workstation на хост-системе Linux из командной строки, введите команду vmware & в окне терминала. Например: /usr/bin/vmware &
При первом запуске Workstation предложит вам принять лицензионное пользовательское соглашение. После запуска открывается окно Workstation.
Готово! Мы успешно установили VMware Workstation.
Определение проблемного пространства
Сетевые инженеры часто сталкиваются с проблемой слишком большого трафика для слишком малого канала связи. В частности, почти в каждом пути через сеть одно звено ограничивает весь путь, так же как один перекресток или одна дорога ограничивает поток трафика. Рисунок ниже иллюстрирует это.
На рисунке A обменивается данными с G, а B обменивается данными с E. Если каждая из этих пар устройств использует близкую к доступной полосе пропускания на своих локальных каналах ([A, C], [B, C], [F, G] и D, E]), предполагая, что все каналы имеют одинаковую скорость, канал [C, D] будет перегружен трафиком, превратившись в узкую точку в сети.
Когда канал перегружен, например канал [C, D] на рисунке ниже, по каналу будет отправлено больше трафика, чем пропускная способность канала. Во время перегрузки сетевое устройство, такое как маршрутизатор или коммутатор, должно определять, какой трафик следует перенаправить, какой отбросить и в каком порядке следует пересылать пакеты. Для решения этой проблемы были созданы различные схемы приоритезации.
Управление перегрузкой каналов путем приоритизации одних классов трафика над другими входит в широкий раздел качества обслуживания (QoS). Восприятие QoS среди сетевых инженеров вызывает беспокойство по многим причинам. Например, многие реализации, даже недавние, как правило, не так хорошо продуманы, как могли бы быть, особенно в том, как они настроены и поддерживаются. Кроме того, ранние схемы не всегда работали хорошо, и QoS часто может добавить проблем в сети, а не облегчить их, и, как правило, очень трудно устранить неполадки.
По этим причинам, а также из-за того, что конфигурация, необходимая для реализации схем приоритезации, имеет тенденцию к непостижимости, QoS часто считается темным искусством. Чтобы успешно реализовать стратегию QoS, вы должны классифицировать трафик, определить стратегию организации очередей для различных классов трафика и согласованно установить стратегию на всех сетевых устройствах, которые могут испытывать перегрузку каналов.
Хотя можно погрузиться во множество различных функций и функций схем и реализаций QoS, результат всегда должен быть одним и тем же.
Почему бы просто не сделать линии связи достаточно большими?
После обдумывания ценностного предложения QoS очевидной реакцией будет вопрос, почему сетевые инженеры просто не выбирают достаточно большие линии связи, чтобы избежать перегрузки. В конце концов, если бы линии связи были достаточно большими, перегрузка исчезла бы. Если перегрузка исчезнет, исчезнет необходимость отдавать приоритет одному типу трафика над другим. Весь трафик будет доставлен, и все эти досадные проблемы, связанные с недостаточной пропускной способностью, будут устранены. Действительно, избыточное выделение ресурсов, возможно, является лучшим QoS из всех.
К сожалению, стратегия избыточного обеспечения не всегда является доступным вариантом. Даже если бы это было так, самые большие доступные каналы связи не могут преодолеть определенные модели трафика. Некоторые приложения будут использовать столько пропускной способности, сколько доступно при передаче данных, создавая точку перегрузки для других приложений, совместно использующих линию связи. Другие будут передавать в микроперерывах, подавляющих сетевые ресурсы в течение короткого времени, и некоторые транспортные механизмы-такие как протокол управления передачей (TCP)-будут намеренно собирать путь время от времени, чтобы определить наилучшую скорость передачи данных. В то время как более крупная линия связи может сократить время существования состояния перегрузки, в некоторых сценариях нет такой вещи, как наличие достаточной полосы пропускания для удовлетворения всех требований.
Большинство сетей построены на модели избыточной подписки, когда некоторая совокупная пропускная способность распределяется в определенных узких местах. Например, коммутатор Top of Rack (ToR) в загруженном центре обработки данных может иметь 48 портов 10GbE, обращенных к хостам, но только 4 порта 40GbE, обращенных к остальной части центра обработки данных. Это приводит к коэффициенту переподписки 480:160, который уменьшается до 3:1. Неявно, 160 Гбит/с полосы пропускания центра обработки данных является потенциальным узким местом - точкой перегрузки - для 480 Гбит/с полосы пропускания хоста. И все же соотношение переподписки 3:1 является обычным явлением в схемах коммутации центров обработки данных. Зачем?
Окончательный ответ - часто деньги. Часто можно спроектировать сеть, в которой граничные порты соответствуют доступной пропускной способности. Например, в структуре центра обработки данных, приведенной выше, почти наверняка можно добавить достаточную пропускную способность канала, чтобы обеспечить 480 Гбит / с из ToR в структуру, но стоимость вполне может быть непомерно высокой. Сетевой инженер должен учитывать не только стоимость порта и оптоволокна, но и стоимость дополнительного питания, а также стоимость дополнительного охлаждения, необходимого для управления окружающей средой после добавления необходимых дополнительных устройств, и даже затраты дополнительного места в стойке и веса пола.
Затраты денег на обеспечение более высокой пропускной способности сети также могут быть трудно оправданы, если сеть редко перегружена. Некоторые события перегрузки не являются достаточно частыми, чтобы оправдать дорогостоящее обновление сети. Будет ли город тратить миллионы или миллиарды долларов на улучшение транспортной инфраструктуры, чтобы облегчить движение раз в год, когда политик приезжает с визитом? Нет. Вместо этого для решения проблемы с трафиком вносятся другие корректировки.
Например, компании могут наиболее остро столкнуться с этим ограничением в глобальных сетях, где каналы арендуются у поставщиков услуг (SP). Частично поставщики услуг зарабатывают деньги на объединении разрозненных географических регионов для организаций, которые не могут позволить себе прокладывать и использовать оптоволоконные кабели большой протяженности самостоятельно. Эти линии дальней связи обычно предлагают гораздо более низкую пропускную способность, чем более короткие, местные линии связи в одном кампусе или даже в одном здании. Высокоскоростное соединение в университетском городке или центре обработки данных может легко перегрузить более медленные каналы дальней связи.
Организации будут устанавливать максимально возможные размеры дальних (таких как межсайтовые или даже межконтинентальные) линий связи, но, опять же, важно помнить о деньгах.
В мире избыточной подписки и последующих точек перегруженности, а также временных моделей трафика, которые требуют тщательного управления, схемы приоритизации трафика QoS всегда будут необходимы.
Классификация
Схемы приоритизации QoS действуют на различные классы трафика, но что такое класс трафика и как он определяется?
Классы трафика представляют собой агрегированные группы трафика. Потоки данных из приложений, требующих аналогичной обработки или представляющих аналогичные схемы трафика в сети, помещаются в группы и управляются политикой QoS (или классом обслуживания, CoS). Эта группировка имеет решающее значение, поскольку было бы трудно определить уникальные политики QoS для потенциально бесконечного числа приложений. С практической точки зрения сетевые инженеры обычно группируют трафик в четыре класса. Конечно, возможны и другие классы, и такие схемы существуют в производственных сетях. Однако управление системой классификации и политическими действиями становится все более утомительным по мере того, как число классов превышает четыре.
Каждый пакет может быть отнесен к определенной CoS на основе адреса источника, адреса назначения, порта источника, порта назначения, размера пакета и других факторов. Предполагая, что каждое приложение имеет свой собственный профиль или набор характеристик, каждое приложение может быть помещено в определенный CoS и действовать в соответствии с локальной политикой QoS. Проблема с этим методом классификации трафика заключается в том, что классификация является только локально значимой-действие классификации относится только к устройству, выполняющему классификацию.
Такая классификация пакетов требует много времени, а обработка каждого пакета потребует больших вычислительных ресурсов. Поэтому лучше не повторять эту обработку на каждом устройстве, через которое проходит пакет. Вместо этого лучше один раз классифицировать трафик, пометить пакет в этой единственной точке и действовать в соответствии с этой маркировкой на каждом последующем переходе в сети.
Примечание: Несмотря на то, что пакеты и кадры в сети различны, в этой статье будет использоваться термин пакеты.
Были разработаны и стандартизированы различные схемы маркировки, такие как 8-битное поле типа обслуживания (ToS), включенное в заголовок Интернет-протокола версии 4 (IPv4). Версия 6 того же протокола (IPv6) включает 8-битовое поле класса трафика, служащее аналогичной цели. Кадры Ethernet используют 3-битное поле как часть спецификации 802.1p. На рисунке показано поле ToS IPv4.
В наилучшей сетевой практике классификация трафика должна приводить к одному действию и только к одному действию-маркировке. Когда пакет помечен, присвоенное значение может сохраняться и действовать на протяжении всего пути следования пакета по сетевому пути. Классификация и последующая маркировка должны быть "одноразовым" событием в жизни пакета.
Лучшая практика QoS - рекомендуется маркировать трафик, как близко к источнику, насколько это возможно. В идеале трафик будет помечен в точке входа в сеть. Например, трафик, поступающий в сетевой коммутатор с персонального компьютера, телефона, сервера, устройства Интернета вещей и т. д. будет помечена, и метка будет служить классификатором трафика на пути следования пакета по сети.
Альтернативная схема классификации и маркировки трафика входящим сетевым устройством заключается в том, что приложение само маркирует свой собственный трафик. Другими словами, пакет отправляется с уже заполненным байтом ToS. Это поднимает проблему доверия. Следует ли разрешить приложению ранжировать собственную важность? В худшем случае все приложения эгоистично помечают свои пакеты значениями, указывающими наивысшую возможную важность. Если каждый пакет помечен как очень важный, то на самом деле ни один пакет не является особо важным. Чтобы один пакет был более важным, чем любой другой, должна быть дифференциация. Классы трафика должны иметь разные уровни важности, чтобы схемы приоритезации QoS имели какое-либо значение.
Для сохранения контроля над классификацией трафика все сети, реализующие QoS, имеют границы доверия. Границы доверия позволяют сети избежать ситуации, когда все приложения помечают себя как важные. Представьте, что произошло бы на перегруженной дороге, если бы у каждого автомобиля были мигающие аварийные огни - действительно важные автомобили не выделялись бы.
В сети некоторым приложениям и устройствам доверяют отмечать свой собственный трафик. Например, IP-телефонам обычно доверяют соответствующим образом маркировать свой потоковый голосовой трафик и трафик протокола управления, то есть метки, которые IP-телефоны применяют к своему трафику, принимаются входным сетевым устройством. Другие конечные точки или приложения могут быть ненадежными, что означает, что байт ToS пакета стирается или перезаписывается при входе. По умолчанию большинство сетевых коммутаторов стирают метки, отправленные им, если они не настроены на доверие определенным устройствам. Например, производителям, помещенным в пакет сервером, часто доверяют, а маркировкам, установленным конечным хостом, - нет. На рисунке ниже показана граница доверия.
На рисунке 3 пакеты, передаваемые B, помечены AF41. Поскольку эти пакеты исходят от хоста в домене доверия QoS, маркировка остается, пока они проходят через D. Пакеты, исходящие от A, помечаются EF; однако, поскольку A находится за пределами доверенного домена QoS, эта маркировка удаляется в D. Пакеты в пределах доверенного домена, исходящие из A, рассматриваются как немаркированные с точки зрения QoS. Маркировка протокола физического уровня и верхнего уровня может быть связана, а может и не быть. Например, маркировка верхнего уровня может быть скопирована в маркировку нижнего уровня, или маркировка нижнего уровня может быть перенесена через сеть, или маркировка нижнего уровня может быть удалена. Существует множество различных возможных реализаций, поэтому вы должны быть осторожны, чтобы понять, как маркировка обрабатывается на разных уровнях, а также на каждом переходе.
Хотя операторы сети могут использовать любые значения, которые они выбирают в байте ToS для создания различных классов трафика, часто лучше придерживаться некоторых стандартов, таких как значения, определенные стандартами IETF RFC. Эти стандарты были определены для того, чтобы дать сетевым инженерам логическую схему, позволяющую надлежащим образом различать множество различных классов трафика.
Две из этих схем "Per Hop Behavior" появляются в RFC2597, Assured Forwarding (AF), и RFC3246, Expedited Forwarding (EF), а также в различных других RFC, обновляющих или уточняющих содержание этих основополагающих документов. Оба эти RFC определяют схемы маркировки трафика, включая точные значения битов, которые должны заполнять байт ToS или байт класса трафика IP-заголовка, чтобы указать конкретный тип трафика. Они известны как точки кода дифференцированного обслуживания или значения DSCP.
Например, схема гарантированной пересылки RFC2597 определяет 12 значений в побитовой иерархической схеме для заполнения восьми битов в поле байта ToS. Первые три бита используются для идентификации класса, а вторые три бита определяют приоритет отбрасывания. Последние два бита не используются. Таблица 1 иллюстрирует маркировку кода для нескольких классов AF.
В таблице 1 показано значение бита DSCP для AF11, трафика класса 1 с низким приоритетом отбрасывания, равным 001 010, где "001" обозначает класс 1, а "010" обозначает приоритет отбрасывания. Изучение таблицы более глубоко раскрывает бинарный паттерн, выбранный авторами RFC. Весь трафик класса 1 помечается 001 в первых трех битах, весь класс 2-010 в первых трех битах и т. д. Весь трафик с низким приоритетом отбрасывания помечается 010 во-вторых трех битах, весь трафик со средним приоритетом отбрасывания-100 во-вторых трех битах и т. д.
Схема гарантированной пересылки показана в таблице 2 для примера. Это не исчерпывающий список кодовых точек, используемых при классификации трафика QoS. Например, схема выбора класса, описанная в RFC2474, существует для обратной совместимости со схемой маркировки приоритета IP. Приоритет IP использует только первые три бита байта ToS, всего восемь возможных классов. Селектор классов также использует восемь значений, заполняя первые три бита шестибитового поля DSCP значимыми значениями (соответствующими устаревшей схеме приоритета IP), а последние три бита - нулями. В таблице 2 показаны эти селекторы классов.
RFC3246 определяет требования к задержке, потерям и джиттеру трафика, который должен быть перенаправлен быстро, вместе с единственной новой кодовой точкой - EF, которой присвоено двоичное значение 101 110 (десятичное 46).
Количество и разнообразие формально определенных значений DSCP может показаться ошеломляющим. Комбинированные определения AF, CS и EF сами по себе приводят к формальным определениям для 21 различных классов из возможных 64, использующих шесть битов поля DSCP. Ожидается ли, что сетевые инженеры будут использовать все эти значения в своих схемах приоритезации QoS? Следует ли разбивать трафик с такой высокой степенью детализации для эффективного QoS?
На практике большинство схем QoS ограничиваются от четырех до восьми классов трафика. Различные классы позволяют обрабатывать каждую группу по-своему во время перегрузки. Например, один класс трафика может быть сформирован так, чтобы соответствовать определенному порогу пропускной способности. Другой класс трафика может иметь приоритет над всем остальным трафиком. Еще один может быть определен как критически важный для бизнеса или трафик, который важнее большинства, но менее важен, чем некоторые. Трафик сетевого протокола, критичный для стабильности инфраструктуры, можно рассматривать как очень высокий приоритет. Класс трафика scavenger может находиться в конце списка приоритетов, получая немного больше внимания, чем немаркированный трафик.
Схема, включающая эти значения, вероятно, будет представлять собой сочетание кодовых точек, определенных в различных RFC, и может несколько отличаться от организации к организации. Обычно принятые значения включают EF для критического трафика с требованием своевременности, например VoIP, и CS6 для трафика управления сетью, такого как протоколы маршрутизации и резервирования на первом этапе. Немаркированный трафик (т.е. значение DSCP, равное 0) доставляется по принципу "максимальных усилий", без каких-либо гарантий уровня обслуживания (обычно это считается классом scavenger, как указано выше).
Сетевая инфраструктура (роутеры, коммутаторы, МСЭ, АТС и так далее) являются очень важными ресурсами организации, и поэтому очень важно корректно настроить доступ к данным устройствам – для достижения нужного уровня защиты.
Множество корпораций фокусируются на защите своих серверов, приложений, баз данных и прочих компонентов сети, но они могут совершенно забыть о том, что часть установленных у них устройств содержат, к примеру, дефолтные логин и пароль.
К примеру, скомпрометированный маршрутизатор может доставить гигантское количество проблем – злоумышленники могут получить доступ к информации, трафик может улетать на другое направление и так далее. Так что корректная настройка устройств с точки зрения сетевой безопасности является крайне важным моментом при обеспечении защиты информации вашей организации.
К примеру Cisco разделяет любое сетевое устройство на 3 функциональных плоскости, а именно:
Плоскость менеджмента – это все о том, как непосредственно управлять железкой. То есть данная плоскость используется для доступа, настройки и мониторинга устройства. В нашей статье мы непосредственно расскажем, как защитить данную плоскость;
Плоскость управления – данная плоскость содержит в себе сигнальные протоколы и процессы, которые отвечают за связность между устройствами – например такие известные вам протоколы как OSPF, EIGRP и так далее;
Плоскость данных – плоскость, ответственная за перемещение информации по сети от источника до ее назначения. В данной плоскости и происходит, как правило, обмен пакетами между устройствами;
Из этих трех плоскостей наиболее защитить первую и вторую плоскости, однако в нашей статье мы сконцентрируемся на плоскости менеджмента и обсудим 10 важных шагов по улучшению защищенности сетевого устройства Cisco с IOS.
Десять пунктов ниже не являются избыточными, но они включают в себя наиболее важные команды и настройки, которые позволят «закрыть» устройство от нежелательного доступа и повысить степень защищенности. Данные пункты применимы как к маршрутизаторам, так и к коммутаторам.
Создание секретного пароля
В целях предоставления доступа к IOS устройству только людям, имеющим право (например, сисадмину/эникею/инженеру) всегда нужно создавать сложный «секретный» пароль (enable secret). Мы советуем придумать/сгенерировать пароль минимум 12 знаков, содержащий цифры, буквы и специальные символы. Проверьте, что вы вводите именно enable secret - тогда в конфиге пароль будет отображаться в зашифрованном виде.
Router# config terminal
Router(config)# enable secret сложныйпароль
Зашифруйте пароли на устройстве
Все пароли, настроенные на устройстве (за исключением «секретного»), не шифруются от слова совсем и легко видны в конфиге. Чтобы зашифровать все пароли в конфиге, необходимо использовать глобальную команду service password encryption
Router# config terminal
Router(config)# service password-encryption
Используйте внешний сервер авторизации для аутентификации пользователей
Вместо использования локальных учетных записей на каждом устройстве для доступа администратора, мы рекомендуем использование внешнего AAA сервера (TACACS+ или RADIUS) для обеспечения Аутентификации, Авторизации и Учета (вольный перевод Authentication, Authorization, Accounting).
С централизованным ААА сервером гораздо проще управлять учетными записями, реализовывать политики безопасности, мониторить использование аккаунтов и многое другое.
Ниже на схеме вы можете видеть как настроить TACACS+ и RADIUS серверы с использованием enable secret пароля в случае отказа этих серверов.
TACACS+
Router# config terminal
Router(config)# enable secret K6dn!#scfw35 //создаем “секретный ” пароль
Router(config)# aaa new-model //включаем ААА службу
Router(config)# aaa authentication login default group tacacs+ enable //Используем TACACS сервер и обычный пароль на случай отказа
Router(config)# tacacs-server host 192.168.1.10 //указываем внутренний ААА сервер
Router(config)# tacacs-server key ‘secret-key’ //указываем секретный ключ для ААА сервера
Router(config)# line vty 0 4
Router(config-line)# login authentication default //применяем ААА аутентификацию для линий удаленного доступа (telnet, ssh)
Router(config-line)# exit
Router(config)# line con 0 //применяем ААА аутентификацию для консольного порта
Router(config-line)# login authentication default
RADIUS
Router# config terminal
Router(config)# enable secret K6dn!#scfw35 //создаем “секретный ” пароль
Router(config)# aaa new-model //включаем ААА службу
Router(config)# aaa authentication login default group radius enable //Используем RADIUS сервер и обычный пароль на случай отказа
Router(config)# radius-server host 192.168.1.10 //указываем внутренний ААА сервер
Router(config)# radius-server key ‘secret-key’ //указываем секретный ключ для ААА сервера
Router(config)# line vty 0 4
Router(config-line)# login authentication default //применяем ААА аутентификацию для линий удаленного доступа (telnet, ssh)
Router(config-line)# exit
Router(config)# line con 0 //применяем ААА аутентификацию для консольного порта
Router(config-line)# login authentication default
Создайте отдельные аккаунты для пользователей
Если у вас отсутствует возможность использовать внешний ААА сервер, по инструкции, описанной в предыдущем шаге, то как минимум, вам необходимо создать несколько отдельных локальных аккаунтов для всех, у кого должен быть доступ к устройству. Приведем пример создания трех локальных аккаунтов для троих системных администраторов.
Кроме того, в версии IOS начиная с 12.2(8)T и позднее, есть возможность настроить повышенную надежность паролей (Enhanced Password Security) для локальных учетных записей – это зашифрует пароли с помощью MD5 хэша.
Ниже пример настройки трех учетных записей:
Router# config terminal
Router(config)# username efstafiy-admin secret Lms!a2eZf*%_rete
Router(config)# username evlampiy-admin secret d4N3%sffeger
Router(config)# username vova-admin secret 54sxSFT*&_(!zsd
Настройте лимит возможных попыток подключения
Для того, чтобы избежать взламывания вашей учетной записи на маршрутизаторе с помощью брутфорса, вы можете настроить ограничение количества попыток подключения, когда после определенного предела система заблокирует пользователя. Это работает для локальных учетных записей.
Router# config terminal
Router(config)# username john-admin secret Lms!a2eZSf*%
Router(config)# aaa new-model
Router(config)# aaa local authentication attempts max-fail 5 //max 5 failed login attempts
Router(config)# aaa authentication login default local
Открытие доступа на управление устройством только для определенных IP – адресов
Данный пункт является одним из наиболее важных для сетевых устройств Cisco – необходимо оставить доступ к Telnel или SSH только для определенных сетевых адресов (например, рабочей станции системного администратора). В нашем примере сисадмин находится в пуле 192.168.1.0/28
Router# config terminal
Router(config)# access-list 10 permit 192.168.1.0 0.0.0.15
Router(config)# line vty 0 4
Router(config)# access-class 10 in //применить ограничения на все VTY линии (SSH/Telnet)
Включить логирование
Логирование является очень полезной функцией для отслеживания, аудита и контроля инцидентов. Вы можете включить логирование во внутренний буфер устройства или на внешний лог-сервер. Вторая опция является более предпочтительной, так как вы можете хранить там больше информации и проще производить различного рода аналитику.
Всего существует 8 уровней логирования (от 0 до 7), каждый из которых делает лог более насыщенным деталями. Лучше всего избегать 7 уровень логирования (дебаг), т.к это может легко потратить все ресурсы вашего устройства.
Ниже пример, как включить логирование и на внешний сервер, и на сам девайс (можно использовать два варианта одновременно).
Router# config terminal
Router(config)# logging trap 6 //Включить 6 уровень логирования для логов, отправляемых на внешний сервер
Router(config)# logging buffered 5 //Включить 5 уровень логирования для логов, хранимых на самом девайсе
Router(config)# service timestamps log datetime msec show-timezone //Включить таймстампы с милисекундной точностью
Router(config)# logging host 192.168.1.2 //Отправлять логи на внешний сервер
Router(config)# logging source-interface ethernet 1/0 //Использовать интерфейс Eth1/0 для отправки логов
Включение NTP (Network Time Protocol)
Данный шаг необходим для корректной работы логирования – т.к вам необходимо синхронизированное и точное системное время на всех сетевых устройствах, для правильного понимания ситуации при траблшутинге. Вы можете использовать как публичный, так и свой собственный NTP cервер.
Router# config terminal
Router(config)# ntp server 3.3.3.3
Router(config)# ntp server 4.4.4.4
Использование безопасных протоколов управления
По умолчанию, протоколом, с помощью которого можно управлять устройством является Telnet. Однако весь трафик передается в незашифрованном виде – поэтому предпочтительно использовать SSH.
Важно – для использования SSH необходимо настроить хостнейм и доменное имя, а также сгенерировать SSH ключи. Также следует разрешить только протокол SSH на VTY линиях
Защитить SNMP доступ
Про SNMP мы писали в одной из наших статей – это протокол для управления сетью, который, однако, также может служить «дырой» для доступа в вашу сеть. Для защиты данного направления, вам необходимо установить сложную Community String (что-то вроде пароля для SNMP) и разрешить доступ только с определенных рабочих станций.
Давайте настроим две Community String – одну с правами на чтение, и другую с правами на чтение и изменение. Также добавим ACL с нужными сетевыми адресами.
Router# config terminal
Router(config)# access-list 11 permit 192.168.1.0 0.0.0.15
Router(config)# access-list 12 permit 192.168.1.12
Router(config)# snmp-server community Mer!0nET RO 11 //создание community string с правами на чтение и использование ACL 11 для SNMP доступа
Router(config)# snmp-server community Mer!0NeTRules RW 12 //создание community string с правами на чтение/запись и использование ACL 12 для SNMP доступа
Команды выше позволят сети сисадмина 192.168.1.0/28 иметь доступ на чтение и хосту 192.168.1.12 иметь полный доступ на SNMP чтение / запись к устройствам.