Руководство по защите сетевой инфраструктуры


1. Введение


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

В данном отчете представлены лучшие практики для обеспечения общей безопасности сети и защиты отдельных сетевых устройств, и поможет администраторам предотвратить попытки атак на сетевую инфраструктуру. Хотя представленные здесь рекомендации носят общий характер и могут быть применены ко многим типам сетевых устройств, в качестве примера используются команды оборудования компании Cisco (Cisco Internetwork Operational System, IOS).

1.1 Модель безопасности «Zero Trust»


Модель «нулевого доверия» (Zero Trust) – это модель безопасности, набор принципов проектирования систем и стратегия кибербезопасности, основанная на том, что угрозы существуют как внутри, так и за пределами традиционных сетевых границ и часть рекомендаций, приведенных в данном отчете, могут применяться на различных границах, как это рекомендуется в руководстве Zero Trust. Тем не менее, в данном отчете основное внимание уделяется предоставлению рекомендаций по снижению рисков использования распространенных уязвимостей и слабых мест в существующих сетях.

2. Архитектура и дизайн сети


Безопасный дизайн сети, который реализует несколько защитных уровней, имеет решающее значение для защиты от угроз и защиты ресурсов внутри сети. Дизайн должен соответствовать новейшим практикам безопасности и моделировать принципы Zero Trust как для периметра сети, так и для внутренних устройств.

2.1 Защита периметра и внутренних устройств


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

  • Установить пограничный маршрутизатор для обеспечения подключения к внешней сети, например интернет-провайдеру (Internet Service Provider).

  • Установить несколько уровней межсетевых экранов нового поколения (Next-generation firewall, NGFW) по всей сети для ограничения входящего и исходящего трафика, и проверки активности между разнесенными сегментами сети. Для защиты от действий злоумышленников, которые для проникновения в сетевую инфраструктуру будут пытаться использовать известные уязвимости, на каждом уровне должны использоваться межсетевые экраны разных производителей.

  • Разместить общедоступные системы и исходящие прокси-серверы между различными уровнями сетевых экранов в одном или нескольких демилитаризованных сегментах (Demilitarized zone, DMZ), где доступ может быть между внешними устройствами, устройствами DMZ и внутренними системами.

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

  • Развернуть несколько выделенных удаленных серверов протоколирования (логирования) для обеспечения анализа активности между устройствами и обнаружения подозрительной активности (Lateral movement).

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


2.2 Группировка сетевых систем


Аналогичные системы в сети должны быть логически сгруппированы для защиты от проникновения из других типов систем. Злоумышленники будут выбирать системы, которые легко поддаются взлому, например, принтеры, и использовать полученный доступ для дальнейшего проникновения в другие системы сетевой инфраструктуры. Правильная сегментация сети значительно снижает возможность злоумышленников по получению доступа к другим системам и использования их в своих целях (см. «Многоуровневая защита сети посредством сегментации»/Layering Network Security Through Segmentation [1] и «Сегментация сетей и применение межсетевых экранов уровня приложений»/Segment Networks and Deploy Application-aware Defenses [2]). Кроме того, ограничениями доступа между различными типами систем легче управлять, контролировать и отслеживать, если они логически сгруппированы.

Рекомендуется выносить схожие системы в разные подсети или виртуальные локальные сети (Virtual local area networks, VLAN) или физически разделять различные подсети с помощью сетевых экранов или фильтрующих маршрутизаторов – рабочие станции, серверы, принтеры, телекоммуникационные системы и другие сетевые периферийные устройства должны быть отделены друг от друга. Промышленные системы управления, как правило, должны быть изолированы от других сегментов и сетей повышенного риска, таких как Интернет. Такое физическое разделение обеспечивает более надежную защиту, поскольку для получения доступа к закрытым сегментами сети злоумышленник должен пройти промежуточное устройство. Внедрение ограничений доступа на внутренних маршрутизаторах, коммутаторах или сетевых экранах, должно осуществляться таким образом, чтобы разрешено было использовать только те порты и протоколы, которые требуются для работы сети. Списки контроля доступа (Access control lists, ACL) могут быть продублированы и применены непосредственно к коммутаторам для ограничения доступа между виртуальными локальными сетями, или они могут применяться на магистральных маршрутизаторах в тех случаях, когда маршрутизация выполняется между внутренними подсетями.

2.3 Удаление скрытых подключений

 
Скрытое сетевое соединение (Backdoor connections) устанавливается между двумя или более устройствами, расположенными в разных сегментах сети, как правило, с разными типами данных и требованиями безопасности. Если одно устройство скомпрометировано, злоумышленник может использовать это соединение для обхода ограничений доступа и получить доступ к другим сегментам сети. Примером скрытого сетевого подключения является внешний пограничный маршрутизатор, подключенный к интернет-провайдеру, который также напрямую подключен к внутренней или управляющей подсети. Злоумышленник, который может скомпрометировать внешний пограничный маршрутизатор, скорее всего, получит доступ к внутренней сети в обход установленных сетевых экранов.

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

2.4 Контроль доступа к периметру сети


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

Рекомендуется использовать подход «запрещено всё, кроме необходимого», который достигается путем тщательного рассмотрения того, какие соединения следует разрешить, а затем создания наборов правил, которые направлены на разрешение только необходимых соединений. Этот метод позволяет одним правилом запретить несколько типов соединений, вместо того чтобы создавать отдельное правило для каждого заблокированного соединения. Невозможность использования подхода «запрещено всё, кроме необходимого» может санкционировать доступ к информационным системам и увеличить риск компрометации и перехвата данных. В случае необходимости применения динамических правил доступа к устройствам периметра (например, в случае дополнительного уровня защиты от действий злоумышленников, которые будут пытаться использовать известные уязвимости), рекомендуется использовать систему предотвращения вторжений (Intrusion Prevention System, IPS).  Также рекомендует включить протоколирование, как минимум, для всех наборов правил, которые запрещают или игнорируют трафик, и активировать функцию протоколирования успешного и неуспешного доступа администратора к критическим устройствам.

2.5 Внедрение решений по контролю доступа к сети


Злоумышленник, стремящийся получить доступ к сети, должен либо найти путь через внешний периметр сети, либо получить доступ изнутри сети. Решения по контролю доступа к сети (Network Access Control, NAC) предотвращает несанкционированные физические подключения и контролирует авторизованные физические подключения в сети. Рекомендуется внедрить решения по контролю доступа к сети, которые идентифицирует и аутентифицирует уникальные устройства, подключенные к сети. Защита портов – это механизм, который может быть реализован на коммутаторах для обнаружения подключения неавторизованных устройств к сети по MAC-адресу устройства. Однако управление защитой портов может быть затруднено. Например, увеличивается количество обращений в службу поддержки из-за блокировок сетевых портов (например, подключенных устройств, которые часто меняются, таких как конференц-залы). Кроме того, злоумышленники могут обойти подобного рода ограничения за счет использования технологии подмены MAC-адреса (MAC-spoofing). Более надежные решения используют 802.1X, который аутентифицирует устройства на основе доверенного цифрового сертификата, установленного на устройстве. Несмотря на то, что подобные решения сложнее в реализации из-за использования сертификатов, они менее трудоемки в использовании по сравнению с обычной защитой портов, и обеспечивают более высокий уровень защиты.

2.6 Ограничение использования виртуальных сетей


Виртуальные сети (Virtual Private Networks, VPN) могут быть созданы между двумя конечными точками при помощи зашифрованного канала, но их следует использовать только в тех случаях, когда конфиденциальность и целостность трафика не могут быть обеспечены другими методами. Шлюзы виртуальных сетей (VPN gateway) обычно доступны из Интернета и подвержены сканированию сети, попыткам взлома методом перебора учётных данных и уязвимостям «нулевого дня» (Zero-day vulnerabilities). В целях снижения количества уязвимостей необходимо отключить все ненужные функции на шлюзах виртуальных сетей и применить строгие правила фильтрации трафика [2].

Рекомендуется ограничить доступ к шлюзам виртуальных сетей по протоколу User Datagram Protocol (UDP) на порты 500 и 4500, протоколу Encapsulating Security Payload (ESP) и другим портам по мере необходимости. По возможности необходимо ограничить принимаемый трафик только с доверенных узлов в сети Интернет (если удалённый узел неизвестен, то его нельзя добавлять в список разрешённых для установления подключений). В тех случаях, когда трафик не может быть отфильтрован по определенным IP адресам непосредственно на шлюзе виртуальных сетей, необходимо использовать систему предотвращения вторжений перед шлюзом виртуальных сетей, что позволит отслеживать подозрительные сессии по протоколу IPSec и проводить проверку процесса установления подобных сессий. [3]

Конфигурирование сессий по протоколу IPSec требует определения правил установления соединений и обмена ключами Интернета (Internet Key Exchange, IKE). Правила определяют способ согласования параметров сессии при создании защищенного туннеля по протоколу IPSec. В том случае, если для установления соединения используется слабая криптография, то виртуальная сеть может оказаться под угрозой, а конфиденциальность данных будет скомпрометирована. Правила обмена ключами, как правило, включают три ключевых компонента:

1.      Diffie-Hellman algorithm/group (Протокол Диффи — Хеллмана)

2.      Encryption algorithm (Протокол шифрования трафика)

3.      Hashing algorithm (Криптографическая хеш-функция)

Ниже приведены минимальные требования при конфигурировании соединений виртуальных сетей:

1.       Diffie-Hellman Group: Группа 16 – 4096-bit Modular Exponent (MODP)

или

2.       Diffie-Hellman Group: Группа 20 – 384-bit elliptic curve group (ECP)

3.       Encryption: Advanced Encryption Standard, AES – 256

4.       Hash: Secure Hash Algorithm, SHA – 384

Для установления соединений может применяться Группа 15 протокола Диффи-Хеллмана, но из-за возможных проблем с совместимостью её не рекомендуется использовать.

При разработке внутренних документов и политик сделайте сверку со следующими документами: CNSS Policy 15 [4] и Commercial National Security Algorithm Suite Cryptography for Internet Protocol Security [5].

В целях снижения рисков непреднамеренного (неправомерного) использования протоколов Internet Security Association and Key Management Protocol (ISAKMP) и IKEv2при помощи следующих команд:

no crypto isakmp default policy

no crypto ikev2 policy default

no crypto ikev2 proposal default

no crypto ipsec transform-set default

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

Профили и правила для протокола IKEv2 настраиваются при помощи следующего набора команд:

crypto ikev2 proposal <IKEV2_PROPOSAL_NAME>

  encryption aes-gcm-256

  group [16|20]

crypto ikev2 policy <IKEV2_POLICY_NAME>

  proposal <IKEV2_PROPOSAL_NAME>

crypto ikev2 profile <IKEV2_PROFILE_NAME>

  match identity remote ...

  authentication remote ...

  authentication local …

Конфигурация профиля зависит от сети, для которой он настраивается, и должна иметь локальный и удаленный методы аутентификации и кодовую фразу. Также можно создать отдельную связку ключей и применять её к профилю для предварительно созданных ключей (Pre-Shared Keys, PSK).

Конфигурирование преобразований по протоколу IPsec настраивается при помощи следующего набора команд:

crypto ipsec transform-set <IPSEC_TRANSFORM_NAME> esp-gcm 256

  mode tunnel

Создание профиля IPsec, который использует профиль IKEv2 и набор преобразований IPsec, приведенный выше, можно при помощи следующего набора команд:

crypto ipsec profile <IPSEC_PROFILE_NAME>

  set transform-set <IPSEC_TRANSFORM_NAME>

  set pfs group16

  set ikev2-profile <IKEV2_PROFILE_NAME>

Профиль IPsec необходимо применить к туннельному интерфейсу при помощи следующего набора команд:

interface <TUNNEL_INTERFACE_NAME>

  tunnel protection ipsec profile <IPSEC_PROFILE_NAME>

  no shutdown

С подробной информацией по конфигурированию виртуальных сетей можно ознакомиться в следующих документах: «Configuring IPsec Virtual Private Networks» [6], «Mitigating Recent VPN Vulnerabilities» [7] и «Eliminating Obsolete Transport Layer Security (TLS)» [8].

3. Обеспечение безопасности


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

3.1 Проверка целостности программного обеспечения и конфигурации


Злоумышленник может внедрить вредоносное программное обеспечение в сетевые устройства путем изменения файлов операционной системы, исполняемого кода, выполняющегося в памяти, микропрограммы или загрузчика, который загружает операционную систему сетевого устройства. Программное обеспечение сетевого устройства, которое было модифицировано злоумышленником, может быть использовано для нарушения целостности данных, утечки конфиденциальной информации или проведения атаки «Отказ в обслуживании» (Denial of Service, DoS).

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

verify /sha512 <PATH:filename>

Иногда старые версии устройств могут поддерживать только хэш типа Message Digest 5 (MD5), который можно вычислить с помощью команды:

verify /md5 <PATH:filename>

Полученный в результате проверки хэш можно сравнить с информацией, опубликованной на сайте производителя [12]. Более подробную информацию о проверке сетевых устройств можно найти в документах «Network Device Integrity (NDI) Methodology» [30], «Network Device Integrity (NDI) on Cisco IOS Devices» [31] и «Validate Integrity of Hardware and Software» [32].

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

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

3.2 Управление файловой системой и загрузкой


Сетевые устройства, как правило, имеют две различные конфигурации: одну или несколько сохраненных в постоянном запоминающем устройстве (ПЗУ) и активную копию, работающую в оперативной памяти (ОЗУ). Изменения в конфигурации должны быть сохранены или зафиксированы для предотвращения несоответствия конфигурации в случаях перезагрузки устройства или отключения электропитания. Изменения конфигурации могут быть сохранены на устройстве с помощью команды:

copy running-config startup-config

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

Используйте защищенный протокол при удаленном копировании конфигураций, например Secure File Transfer Protocol (SFTP) или Secure Copy Protocol (SCP). Процесс копирования, используемый для резервного копирования или архивирования конфигураций, и хранилище резервных копий должны быть защищены от несанкционированного доступа.

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

dir /recursive all-filesystems

delete <PATH:filename>

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

3.3 Поддержка актуального состояния программного обеспечения и операционных систем


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

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

Для определения последних версий операционных систем можно воспользоваться ссылками на сайты производителей из Таблицы №1.

Производитель

Ссылка

Arista Networks
https://www.arista.com/en/support/ [9]

Aruba Networks
https://www.arubanetworks.com/support-services/ [10]

Broadcom
https://www.broadcom.com/support [11]

Cisco Systems
https://www.cisco.com/c/en/us/support/index.html [12]

Dell
https://www.dell.com/support/home/en-us/ [13]

Extreme Networks
https://www.extremenetworks.com/support/ [14]

F5
https://www.f5.com/services/support [15]

Fortinet
https://www.fortinet.com/support [16]

Hewlett Packard Enterprise (HPE)
https://www.hpe.com/us/en/services.html [17]

International Business Machines (IBM)
https://www.ibm.com/mysupport/ [18]

Juniper Networks
https://support.juniper.net/support/ [19]

Linksys
https://www.linksys.com/us/support/ [20]

NETGEAR
https://www.netgear.com/support/ [21]

Palo Alto Networks
https://support.paloaltonetworks.com/support/ [22]

Riverbed Technology
https://support.riverbed.com/ [23]

Ruckus Networks
https://support.ruckuswireless.com/ [24]

SonicWall
https://www.sonicwall.com/support/ [25]

TRENDnet
https://www.trendnet.com/support/ [26]

Tripp Lite
https://www.tripplite.com/support/ [27]

Ubiquiti
https://help.ui.com/hc/en-us/ [28]

WatchGuard
https://www.watchguard.com/wgrd-support/overview [29]

Таблица №1. Ссылки на страницы технической поддержки

3.4 Поддержание оборудования в актуальном состоянии


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

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

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

Для определения списка поддерживаемых устройств необходимо ознакомиться с информацией, опубликованной на сайтах производителей (см. Таблицу №1).

4. Аутентификация, авторизация и аккаунтинг (AAA)


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

aaa new-model

Исполнение команды гарантирует, что устройство не будет использовать устаревшие методы аутентификации и авторизации.

4.1 Внедрение серверов ААА


Все устройства должны быть настроены на использование серверов AAA. Рекомендуется внедрить как минимум два сервера AAA для обеспечения отказоустойчивости – если один сервер останавливается на плановое обслуживание или по другим причинам, остальные серверы будут продолжать оказывать услуги ААА. Серверы должны соответствовать следующим требованиям:

  • Настроены на аутентификацию устройств с помощью уникального ключа, чтобы только авторизованные устройства могли использовать службы AAA (см. раздел 5.5 Создание надежных паролей).

  • Настроены на использование одного и того же протокола (например, TACACS+, RADIUS или LDAP) для согласованности и используют зашифрованный транспорт (например, RadSec, Diameter, LDAPS или IPsec encapsulated).

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

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

aaa group server {tacacs+ | radius | ldap} <GROUP_NAME>

  server-private <IP_ADDRESS_1> key <KEY_1>

  server-private <IP_ADDRESS_2> key <KEY_2>

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

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

4.2 Настройка аутентификации


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

Рекомендуется настроить централизованную аутентификацию для входа в систему (login) и разрешения привилегированного доступа (enable) при помощи следующего набора команд:

aaa authentication login default group <GROUP_NAME> local

aaa authentication enable default group <GROUP_NAME> enable

Использование ключевого слова default гарантирует, что конфигурация будет применяться во всех случаях, когда способ аутентификации не указан в явном виде. Если вместо этого используется список, определенный пользователем, необходимо будет использовать этот список во всех экземплярах в явном виде, где задействованы сервера AAA и, возможно, некоторые службы управления будут неправильно настроены и уязвимы для компрометации. Список по умолчанию (default) применяется в том случае, если список, определенный пользователем, не указан в явном виде.

При помощи параметра <GROUP_NAME> определяется группа серверов AAA, которая включает IP-адреса серверов и связанные с ними ключи.

В связи с недостаточной защищенностью не рекомендуется использовать параметр line. Так же не рекомендуется использовать параметр none, так как этот параметр отключает аутентификацию.

4.3 Настройка авторизации


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

Рекомендуется ограничить полномочия учетных записей администраторов, чтобы предотвратить выполнение несанкционированных действий злоумышленником при помощи скомпрометированной учетной записи. Большинство администраторов используют первый уровень (level 1) для доступа обычного пользователя и пятнадцатый уровень (level 15) для доступа на привилегированном уровне.

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

aaa authorization console

aaa authorization exec default group <GROUP_NAME> local

aaa authorization commands 1 group <GROUP_NAME> local

aaa authorization commands 15 group <GROUP_NAME> local

aaa authorization config-commands

В случае необходимости задания режима авторизации «по умолчанию» необходимо использовать параметр default.

При помощи параметра <GROUP_NAME> определяется группа серверов AAA, которая включает IP-адреса серверов и связанные с ними ключи.

При желании параметр if-authenticated может вместе с параметром local. Например, если администратор успешно вошел в систему, но при этом пропал доступ до всех серверов ААА, то администратор не сможет выполнять команды. В таком случае параметрif-authenticated гарантирует, что аутентифицированный пользователь сможет исполнять команды. Следует, однако, внимательно, отнестись к использованию параметра if-authenticated, поскольку существует вероятность повышения уровня доступа, выходящего за рамки определенного на серверах AAA.

Не рекомендуется использовать параметр none, так как этот параметр отключает аутентификацию.

4.4 Настройка протоколирования


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

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

Аналогично авторизации, процесс протоколирования должен применяться ко всем уровням привилегий администратора при помощи следующего набора команд:

aaa accounting exec default start-stop group <GROUP_NAME>

aaa accounting commands 1 default start-stop group <GROUP_NAME>

aaa accounting commands 15 default start-stop group <GROUP_NAME>

В случае необходимости задания режима протоколирования «по умолчанию» необходимо использовать параметр default.

При помощи параметра <GROUP_NAME> определяется группа серверов AAA, которая включает IP-адреса серверов и связанные с ними ключи.

4.5 Использование принципа минимально необходимых привилегий


Минимально необходимые привилегии – это концепция безопасности, которая разрешает доступ лицу или организации на самом минимально необходимом уровне, который требуется для выполнения задач. Большинство обычных задач не требуют доступа на привилегированном уровне, например, просмотр состояния сетевых интерфейсов или просмотр таблиц маршрутизации. Для реализации принципа администраторы должны изначально входить в систему с минимально необходимым уровнем привилегий – такой подход обеспечивает дополнительный уровень безопасности, который злоумышленник должен обойти, чтобы полностью скомпрометировать устройство и предотвращает случайное внесение администраторами изменений в конфигурацию устройства. Рекомендуется настроить все учетные записи на уровень привилегий 1 или 0 и требовать от администраторов ввода дополнительных учетных данных для повышения уровня привилегий для выполнения необходимых задач. Уровни привилегий следует периодически пересматривать и удалять ненужные доступы, чтобы предотвратить непреднамеренное использование команд привилегированного уровня на более низких уровнях привилегий.

Уровень привилегий отдельных локальных учетных записей можно изменить с помощью параметра privilege. Назначить локальным учетным записям уровень привилегий 1 можно с помощью команды:

username <USER_NAME> privilege 1

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

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

Аналогичная концепция должна применяться к консольным (CON), вспомогательным (AUX), и виртуальным портам (VTY). Если авторизация AAA настроена должным образом, она не должна зависеть от конфигурации тех или иных портов. Тем не менее, необходимо проверить, что порты настроены на использование минимально необходимого уровня привилегий при помощи следующего набора команд:

line con 0

  privilege level 1

line aux 0

  privilege level 1

line vty 0 4

  privilege level 1

line vty 5 15

  privilege level 1

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

4.6 Ограничение количества попыток аутентификации


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

Рекомендуется ограничится тремя (или менее) неудачными попытками получения удаленного доступа при помощи следующей команды:

aaa authentication attempts login 3

Аналогичную концепцию трех (или менее) попыток необходимо применить к сессиям Secure Shell с помощью следующей команды:

ip ssh authentication-retries 3

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

login delay 1

5. Учетные записи и пароли локального администратора


Важность учетных записей локального администратора при управлении сетевыми устройствами трудно переоценить – если централизованная аутентификация не работает, локальные учетные записи предоставляют администраторам доступ к сетевым устройствам для устранения неполадок и диагностики сетевых проблем. Локальные учетные записи должны быть уникальными, аутентифицироваться с помощью уникального и сложного пароля и обеспечивать протоколирование действий администраторов. Если в организации не существует правил в части паролей, то необходимо разработать и обеспечить внедрение новых правил. После разработки и введения новых правил необходимо их пересматривать с учетом последних рекомендаций в части обеспечения безопасности.

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

5.1 Использование уникальных имен пользователей и настройка учетных записей


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

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

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

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

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

Рекомендуется использовать локальные учетные записи только в чрезвычайных ситуациях и при недоступности ААА серверов. Уникальные пароли локальных учетных записей должны храниться у доверенного лица, не имеющего прямого доступа к устройствам. Во время чрезвычайной ситуации администраторы могут запросить локальную учетную запись и пароль, а по окончании чрезвычайной ситуации доверенное лицо может сменить пароль – это предотвратит повторное использование пароля и обеспечит подотчетность администраторов. Все остальные запросы на аутентификацию должны выполняться посредством серверов AAA.

5.2 Изменение паролей, используемых по умолчанию


Большинству устройств присваивается пароль по умолчанию, а иногда пароль и вовсе не используется, чтобы обеспечить администратору легкий доступ для первоначальной настройки. Многие из этих паролей общеизвестны и обычно не требуют изменения для правильной работы устройства – они являются основной целью для вредоносных автоматических сканеров (ботнетов), поскольку учетные данные по умолчанию предоставляют привилегированный доступ к устройству.

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

5.3 Удаление ненужных учетных записей


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

Рекомендуется ограничить количество учетных записей, авторизованных для входа на устройства, а все избыточные и ненужные учетные записи необходимо удалить. Когда администратор уходит из организации или меняет роль, связанные с ним учетные записи должны быть отключены или удалены. Удаление локальной учетной записи выполняется при помощи команды:

no username <NAME>

5.4 Хранение паролей с помощью безопасных алгоритмов


Пароли обычно хранятся в конфигурации устройства или в локальной базе данных в виде открытого/зашифрованного текста, или одностороннего хэша. Никогда не следует использовать открытый текст, а некоторые функции шифрования или хэширования считаются слабыми и могут быть легко взломаны с помощью общедоступных инструментов. Злоумышленник может получить пароли или хэши от конфигурации или локальной базы данных с помощью сетевого анализатора или путем взлома центральной системы управления, хранящей файлы конфигурации. Открытый текст и слабые алгоритмы паролей могут быть легко взломаны и использованы для получения пользовательского или привилегированного уровня доступа к устройству. Оборудование компании Cisco поддерживает следующие односторонние хэшированные и зашифрованные типы:

  • Пароли типа 0 (Type 0) не следует использовать, поскольку они хранятся в открытом виде

  • Хеши паролей типа 4 (Type 4) не следует использовать, поскольку они легко поддаются взлому

  • Следует избегать хэшей паролей типа 5 (Type 5), за исключением старых операционных систем, которые не поддерживают типы 6, 8 или 9

  • Пароли типа 6 (Type 6) зашифрованы при помощи алгоритма AES и должны использоваться только для паролей, которые необходимо шифровать, а не хэшировать (например, для ключей VPN), или в системах, не поддерживающих тип 8 (Type 8) и тип 9 (Type 9)

  • Пароли типа 7 (Type 7) не следует использовать, поскольку они подвержены взлому, даже если хранятся в зашифрованном виде

  • Рекомендуется использовать хэши паролей типа 8 (SHA-256 PBKDF2)

  • Хеши паролей типа 9 (Scrypt) не одобрены Национальным институтом стандартов и технологий (National Institute of Standards and Technology, NIST).

Более подробную информацию о вышеуказанных типах паролей см. в разделе «Типы паролей Cisco» [33].

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

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

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

service password-encryption

Сохранить хэш пароля типа 8 для локальной учетной записи можно с помощью команды:

username <NAME> algorithm-type sha256 secret <PASSWORD>

Примечание: Параметр algorithm-type не сохраняется в файле nvram:/startup-config; вместо этого параметр secret заменяется на secret 8 перед хешем пароля.

В том случае, если нужно хранить пароли с возможностью восстановления (например, для ключей VPN), используйте тип 6 AES с помощью команд:

password encryption aes key config-key password-encrypt <KEY>

Параметр <KEY> должен быть уникальным и сложным паролем, который используется для генерации ключа при шифровании паролей типа 6. Он не должен быть стандартным, слабым или легко угадываемым, и не должен повторно использоваться в конфигурации. Злоумышленник, который угадает этот ключ, сможет использовать его для расшифровки всех паролей типа 6, хранящихся в конфигурации. После выбора ключа его, как правило, не нужно сохранять.

Примечание: Параметр key config-key password-encrypt не сохраняется в nvram:/startup-config.

Поскольку ключ не сохраняется, рекомендуется использовать уникальный ключ для каждого устройства, что не позволит злоумышленнику использовать один и тот же ключ для расшифровки паролей типа 6 на всех устройствах.

Примечание: Если по каким-то причинам ключ необходимо заменить, то нужно будет заново переопределить зашифрованные пароли типа 6.

5.5 Создание надежных паролей


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

Рекомендуется выбирать уникальный и сложный пароль для всех уровней доступа, включая привилегированный. Уникальные и сложные пароли также должны использоваться для аутентификации маршрутизации, синхронизации времени, VPN-туннелей, обеспечения работы протокола сетевого управления (Simple Network Management Protocol, SNMP). Пароли должны отвечать следующим требованиям:

  • Содержать все классы символов (прописные, строчные, цифры и специальные символы)

  • Длина пароля должна быть не менее 15 символов

  • Не должен содержать акронимы и распространённые слова

  • Не должен использовать раскладку клавиатуры (например – qwerty, asdfg, qazwsx…)

  • Не должен совпадать с именем пользователя

  • Не должен совпадать с названиями сетевых элементов, организацией, местоположением, местной спортивной командой или иными функциональными идентификаторами

  • Не должен повторять пароли, используемые на других устройствах

  • Не должен использовать значения по умолчанию, быть пустым или общеизвестным.

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

Крайне не рекомендуется использовать протокол SNMP версий 1 или 2c. С дополнительной информацией можно ознакомиться в разделах «7.1 Отключение служб администрирования с открытым текстом» и «7.8 Удаление конфигурации SNMP для чтения-записи».

Злоумышленник, знающий сеть, местоположение, приложения и т.д., может воспользоваться уязвимостями SNMP, что поможет ему взломать пароли.

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

5.6 Использование уникальных паролей


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

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

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

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

5.7 Периодическая смена паролей


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

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

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

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

Примечание: Если пароль хранится с использованием алгоритма девятого типа (Type 9), где хэш пароля начинается с $14$, это указывает на то, что пароль давно не менялся. По всей видимости хэш пароля был преобразован из хеша пятого типа (Type 5) во время обновления операционной системы. системы. Хеши девятого типа (Type 9) должны быть заменены на хеши восьмого типа (SHA-256), как это описано в разделе 5.4.

6. Протоколирование попыток удаленного доступа


Протоколирование – важный механизм для записи действий и отслеживания событий. Он предоставляет администраторам возможность просматривать журналы на наличие подозрительных действий и расследовать инциденты. Неправильная конфигурация протоколирования может привести к отсутствию или неточности информации и трудностям с сопоставлением событий, которые произошли на устройствах или в сети. Правильное ведение журнала включает в себя ведение протоколов на нескольких удаленных серверов, синхронизацию времени с аутентифицированными источниками, а также внедрение правил и процедур протоколирования. Для анализа файлов протоколов могут применятся системы управления информаций по безопасности и сбору событий (Security Information and Event Management, SIEM). Требования к процессу протоколирования описаны в документе Office of Management and Budget Memorandum M-21-31 [34].  

6.1 Включение режима протоколирования


Сообщения в файлах протоколов будут генерироваться на сетевых устройствах только при включённом режиме протоколирования. Устройства должны быть настроены на ведение файла протокола на локальном устройстве и отправку событий на удаленный сервер.

Рекомендуется включить режим протоколирования, установить размер локального буфера для файла протокола в 16 или более мегабайт, а также настроить процедуру отправки протоколов на удаленный сервер и просмотр полученных протоколов на регулярной основе. Большинство устройств поддерживает бОльший размер буфера, но он может быть уменьшен для конкретного устройства для снижения рисков переполнения памяти.

Для активации режима протоколирования используется команда:

logging on

Увеличение размера буфера для файла протокола обеспечивается командой:

logging buffered 16777216 informational

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

6.2 Настройка удаленного протоколирования


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

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

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

Рекомендуется настроить минимум два удаленных сервера для протоколирования событий:

Настройте как минимум два удаленных сервера журналов с помощью команд:

logging host <IP_ADDRESS_1>

logging host <IP_ADDRESS_2>

6.3 Настройка уровня протоколирования


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

Рекомендуется устанавливать уровень протоколирования на значение «информационный» (informational). Устройства могут быть настроены на режим «отладки» (debugging), но это приведет к увеличению количества генерируемых сообщений и замедлит процесс просмотра журнала. Уровни протоколирования и размер буфера устанавливаются командами:

logging trap informational

logging buffered 16777216 informational

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

Протоколирование также может быть включено на линиях консоли и VTY с помощью параметров console и monitor соответственно. При использовании этого методы администратор немедленно оповещается о произведённом входе в систему, но сообщения не сохраняются. В связи с тем, что данный вид протоколирования малоинформативен и, если по какой-то причине он не нужен сетевым администраторам, его рекомендуется отключить при помощи команд:

no logging console

no logging monitor

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

clock timezone UTC 0 0

service timestamps log datetime msec localtime show-timezone year

service timestamps debug datetime msec localtime show-timezone year

Наконец, также рекомендуется включить протоколирование удачных и неудачных попыток входа в систему – даже если эти события пересылаются на удаленные сервера, эта информация не сохраняется в локальном буфере.

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

login on-failure log

login on-success log

6.4 Синхронизация времени


Протокол сетевого времени (Network Time Protocol, NTP) используется для синхронизации времени устройств по всему миру и для обеспечения точности временных меток, включаемых в файлы протоколов. Для обеспечения надежности каждое устройство должно синхронизироваться как минимум с двумя надежными источниками времени. Такая точность очень важна для того, чтобы временные метки сообщений можно было легко соотнести между географически разнесенными часовыми поясами и использовать для анализа событий в сети.

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

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

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

Установка ключей NTP и включение аутентификации NTP осуществляется при помощи команд:

ntp authentication-key <#1> md5 <KEY>

ntp trusted-key <#1>

ntp authentication-key <#2> md5 <KEY>

ntp trusted-key <#2>

ntp authenticate

Для работы по протоколу NTP может использоваться любое количество доверенных ключей. Следует обратить внимание, что ключи аутентификации NTP хранятся в конфигурации как пароли типа 7 (Type 6). Пароли типа 6 (Type 6), зашифрованные при помощи алгоритма AES, не поддерживаются для аутентификации NTP.

Синхронизация устройства с серверами NTP настраивается при помощи команд:

ntp server <IP_ADDRESS_1> key <#1>

ntp server <IP_ADDRESS_2> key <#2>

Примечание: Число в конце каждой команды – доверенный ключ NTP, используемый для аутентификации конкретного сервера.

После синхронизации часов проверьте текущее состояние NTP с помощью команд:

show ntp status

show ntp associations

Примечание: Необходимо проверять синхронизацию часов после каждого изменения конфигурации NTP, а сам процесс синхронизации может занять несколько часов.

7. Удаленное администрирование и сетевые сервисы


Сетевые устройства могут управляться администраторами удаленно с помощью различных служб. Некоторые распространенные сетевые службы включают SSH, Hypertext Transfer Protocol (HTTP), SNMP и File Transfer Protocol (FTP). Эти службы полезны для администраторов, но они также могут использоваться злоумышленниками для получения доступа к устройству на привилегированном уровне. Все они должны быть правильным образом настроены, чтобы снизить вероятность взлома.

7.1 Отключение уязвимых сервисов


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

Для защиты сетевых коммуникаций рекомендуется использовать зашифрованные службы и отключить уязвимые сервисы (например, Telnet, HTTP, FTP, SNMP 1/2c). Это гарантирует, что злоумышленник, перехватывающий сетевой трафик, не сможет легко получить конфиденциальную информацию. Подробную информацию о том, как включить шифрованные службы, см. в разделе 7.11.

Если устройство не поддерживает протоколы шифрования, подключите систему управления непосредственно к консоли или порту управления, или создайте выделенную сеть управления (out-of-band), чтобы уменьшить возможность перехвата противником конфиденциальной информации. Отключить службу Telnet можно при помощи команд:

line vty 0 4

  transport input none

line vty 5 15

  transport input none

В зависимости от тип устройства, может потребоваться настройка дополнительных методов доступа. Если виртуальных интерфейсов с 5 по 15 не существуют на конкретном устройстве, нет необходимости выполнять эти команды.

Примечание: Эти команды могут также отключить другие сервисы, включая SSH. Подробную информацию о том, как включить SSH, см. в разделе 7.11.1.

Отключить сервис HTTP можно при помощи команды:

no ip http server

Подробную информацию о том, как включить защищенную службу HTTP, см. в разделе 7.11.2.

Отключение сервисов SNMP и SNMP trap версий 1 и 2c осуществляется при помощи команд:

no snmp-server community <COMMUNITY_STRING>

no snmp-server host <HOSTNAME_OR_IP_ADDRESS> <COMMUNITY_STRING>

Подробную информацию о том, как включить SNMP версии 3, смотрите в разделе 7.11.3.

Отключение сервиса TFTP осуществляется при помощи команды:

no tftp-server <FILENAME>

Сервис передачи файлов по протоколу FTP обычно не включается по умолчанию, но может использоваться в качестве клиента. Удалить учетные данные FTP можно при помощи команд:

no ip ftp username

no ip ftp password

7.2 Использование стойкой криптографии


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

С информацией по использованию стойкой криптографии для систем разного уровня можно ознакомиться в обзорном документе CNSSP 15 «USE OF PUBLIC STANDARDS FOR SECURE INFORMATION SHARING» [4], а более детальная информация приводится в проектах документов IETF «Commercial National Security Algorithm Suite Cryptography for Internet Protocol Security (IPsec)» [5], «Commercial National Security Algorithm Suite Profile for TLS and DTLS 1.2 and 1.3» [35] и «Commercial National Security Algorithm (CNSA) Suite Cryptography for Secure Shell (SSH)» [36], «NIST SP 800-52 Revision 2 Appendix F» [37].

При использовании криптографических средств рекомендуется использовать ключи длинной 3 072 бита или выше для генерации асимметричных (открытых и закрытых) ключей, 384 бита для ключей эллиптических кривых (elliptic-curve cryptography) и 256 бит для ключей симметричного шифрования. Некоторые системы не поддерживают длину ключа в 3 072 бита, поэтому может потребоваться использование длины в 4 096 бит. Для любого устройства, использующего ключи меньшего размера, сгенерируйте новую пару ключей и настройте протоколы шифрования на использование стойких алгоритмом. Больший размер ключа может увеличить время подключения к сервису (из-за необходимости проведения дополнительных вычислений), но на большинстве устройств это время очень незначительно. Дополнительную информацию о настройке служб с использованием средств шифрования см. в разделе 7.11.

7.3 Использование защищенных протоколов


Некоторые сервисы используют протоколы, содержащие недостатки в реализации, которые могут быть использованы злоумышленниками. Некоторые протоколы, такие как SSH, могут быть настроены на обратную совместимость и работать со старыми небезопасными протоколами. Старые протоколы подвержены атаке «посредника» (Man in the middle), при которой клиенты и серверы согласовывают более слабые алгоритмы без ведома пользователя.

Рекомендуется убедиться, что сервисы используют последнюю версию протоколов с соответствующими настройками безопасности. SSH версии 2 является предпочтительным методом для удаленного доступа к устройствам. Защищенные HTTP-серверы должны быть настроены на прием только протокола Transport Layer Security (TLS) версии 1.2 или выше. Для дополнительную информацию об ограничении сервисов определенными версиями протокола см. в разделе 7.11.

7.4 Ограничение доступа к службам


Если большому количеству устройств разрешено подключаться к сервисам управления – это повышает риски взлома. Для снижения рисков противоправного доступа рекомендуется использовать списки доступа, посредством которых необходимо разрешить только определенным системам подключаться к устройствам для удаленного управления. Устройства, которые не поддерживают списки доступа, должны быть размещены в отдельном сегменте управления (например, VLAN).

После создания списков доступа его следует применить к виртуальной локальной сети или на входящем маршрутизаторе для ограничения доступа к этому сегменту сети. Может потребоваться внедрение отдельного сетевого экрана перед критическими сегментами сети для ограничения того, какие системы могут подключаться к виртуальной локальной сети. В качестве одного из вариантов ограничения доступа посредством списков доступа можно использовать протокол динамической конфигурации хоста (Dynamic Host Configuration Protocol) с зарезервированным пулом IP-адресов или назначить выделенным системам статические IP-адреса.

Большинство сервисов могут работать только со стандартными списками доступа. Более одного устройства или сети могут быть перечислены при помощи параметра permit. Несмотря на то, что в конце каждого списка доступа подразумевается использование параметра deny, лучше всего включить его в явном виде, т.к. в этом случае все случаи срабатывания правила будут протоколироваться. Создание стандартного списка доступа для разрешения подключения только с адресов, используемых администраторами, осуществляется при помощи команд:

access-list <ACL#> permit <NETWORK> <WILDCARD_MASK> log

access-list <ACL#> deny any log

Более подробная информация о применении списков доступа к определенным сервиса приведена в разделе 7.11.

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

no access-list <ACL#>

7.5 Установка времени ожидания ответа


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

Рекомендуется устанавливать время ожидания для соединений не более пяти минут на всех удаленных устройствах (например, exec-timeout на линиях VTY, SSH, консольных и вспомогательных портах). Не устанавливайте период ожидания ответа на ноль, так как большинство устройств отключат функцию ожидания ответа при такой настройке. Дополнительную информацию об ограничении времени ожидания см. в разделе 7.11.

7.6 Использование функции поддержания соединения в открытом состоянии


Сообщения TCP keep-alive, отправленные и полученные устройством, позволяют оценить состояние соединения, если в течение определенного периода времени не было никакой активности. Эти сообщения можно использовать для обнаружения непреднамеренной потери соединения и защиты от потенциальной компрометации сети. На некоторых устройствах отсутствие службы TCP keep-alive заставляет установленные TCP-соединения оставаться открытыми после непреднамеренной потери соединения на одном конце, что делает сессию уязвимой для перехвата. Кроме того, аутентификация может даже не требоваться, особенно для незашифрованных соединений, и злоумышленник может просто возобновить сессию, возможно, получив доступ к привилегированному уровню.

Рекомендуется включить параметры TCP keep-alive для всех TCP-соединений с помощью следующих команд:

service tcp-keepalives-in

service tcp-keepalives-out

Обратите внимание, что некоторые устройства не поддерживают настройку сообщений TCP keep-alive.

7.7 Отключение исходящих соединений


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

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

line con 0

transport output none

line vty 0 4

transport output none

line vty 5 15

transport output none

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

Если исходящие соединения необходимы для копирования файлов наили с устройств для обслуживания или проверки целостности, ограничьте их только SSH и ограничьте количество устройств, к которым можно получить доступ при помощи списков доступа.

7.8 Удаление конфигурации SNMP для чтения-записи


Параметры настройки протокола SNMP версии 1 или 2c для чтения-записи по своему функционалу похожы на пароли и могут использоваться для доступа или изменения конфигурации устройства и файлов операционной системы. Подобные действия обычно невозможно выполнить с помощью использования параметра «только чтение». Поскольку параметры настройки SNMP для чтения и записи передаются открытым текстом, злоумышленник может использовать их для получения полного контроля над сетевым устройством.

Рекомендуется удалить все параметры настройки SNMP для чтения и записи и перейти на SNMP версии 3 с шифрованием и аутентификацией. Если параметры настройки SNMP версии 1 или 2c для чтения-записи необходимы для удаленного администрирования и не могут быть удалены, рекомендуется, чтобы параметры настройки для чтения-записи отличались от других параметров, чтобы злоумышленник не смог их угадать в случае перехвата параметра настройки «только чтение».

Параметры настройки SNMP версий 1 и 2c можно проверить при помощи команды:

show running-config | include snmp-server community

Примечание: Параметры настройки для чтения-записи содержат ключевое слово RW, а параметры «только для чтения» – ключевое слово RO.

Отключите параметр настройки SNMP для чтения-записи можно с помощью команды:

no snmp-server community <COMMUNITY_STRING>

7.9 Отключение неиспользуемых сетевых сервисов


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

Например, сервис Cisco Smart Install часто не нужен, но если его оставить включённым, то неаутентифицированный злоумышленник может воспользоваться этим сервисом для получения файла конфигурации устройства, загрузки новой конфигурации или файла образа операционной системы или принудительной перезагрузки. Такая возможность была задокументирована в рекомендации по безопасности cisco-sa-20170214-smi, но сообщество специалистов по безопасности заметило и признало эту проблему в качестве серьезной уязвимости, используемую противниками для получения конфигурационных файлов через Интернет [38], [39].

Рекомендуется отключать все ненужные сервисы на устройствах. Если сервис необходим и поддерживать пароль и списки доступа, то необходимо создайть пароль в соответствии с рекомендациями по созданию паролей (см. раздел 5.5) и применить списки доступа, чтобы разрешить подключение к сервису только определенным системам. Если устройство не поддерживает списки доступа, его можно переместить в отдельный VLAN и применить список доступа к этому VLAN-у.

Также рекомендуется отключить службу Cisco Smart Install на всех устройствах с помощью команды:

no vstack

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

Отключение ненужных сетевых сервисов осуществляется при помощи команд:

no service tcp-small-servers

no service udp-small-servers

no service finger

7.10 Отключение протоколов на интерфейсах


Протоколы Cisco Discovery Protocol и Link Layer Discovery Protocol являются широковещательными протоколами, которые с некоторой периодичностью оповещают устройства в сети об изменении сетевой топологии. Эти протоколы включены по умолчанию и могут быть полезны сетевым администраторам для получения информацию о сети, но подобного рода информация также чрезвычайно полезна для злоумышленников, которые могут собирать информацию о конфигурации сети в скрытом режиме. Злоумышленник, скрытно запустивший сетевой анализатор, может собирать типы моделей устройств, версии операционных систем, информацию о виртуальных сетях, физических и логических адресах, что позволяет спланировать атаку на сетевые ресурсы.

Рекомендуется отключить протоколы CDP и LLDP на всех используемых устройствах, а в том случае, если протоколы необходимы для нормального сетевого взаимодействия (например, телефонов Cisco VoIP), включайте их только на соединениях типа «точка-точка» между устройствами, которым требуется данные протоколы, или на портах с поддержкой голосовой связи.

Протоколы CDP и LLDP можно отключить с помощью команд:

no cdp run

no lldp run

В том случае, если CDP требуется на определенных интерфейсах, он должен быть включен на уровне устройства, но отключен на всех остальных интерфейсах при помощи команд:

interface <INTERFACE>

no cdp enable

7.11 Настройка сетевых сервисов


В данном разделе приводятся общие рекомендации по правильной конфигурации сетевых сервисов.

7.11.1 Настройка сервиса SSH для удаленного администрирования


Настройка входящих SSH сессий осуществляется при помощи команд:

line vty 0 4

  transport input ssh

line vty 5 15

  transport input ssh

Примечание: Выполнение команд может привести к отключению сетевых сервисов, сконфигурированные по умолчанию, например, Telnet. Если виртуальных интерфейсов с номерами с 5 по 15 не существуют на конкретном устройстве, нет необходимости выполнять эти команды. В зависимости от устройства, может потребоваться выполнить аналогичные команды и на других виртуальных интерфейсах.

Разрешенные виртуальные интерфейсы можно проверить при помощи команды:

show line <LINE> <LINE_NUMBER>

Разрешить подключение только по протоколу SSH v.2 можно при помощи команды:

ip ssh version 2

Сформировать новую асимметричную пару ключей по алгоритму RSA для использования SSH соединений можно при помощи команды:

crypto key generate rsa modulus 3072

Примечание: Исполнение команды приведет к перезаписи существующей пары ключей RSA.

Формирование новой асимметричной пары ключей по алгоритму ECC для использования SSH соединений выполняется при помощи команды:

crypto key generate ec keysize 384

Примечание: Исполнение команды приведет к перезаписи существующей пары ключей ECC.

Установка минимального размера ключа RSA на 4096 бит осуществляется при помощи команды:

ip ssh dh min 4096

Примечание: Некоторые устройства не поддерживают 3072 бита в качестве размера ключа RSA, поэтому рекомендуется установить 4096 бит.

Алгоритмы шифрования, обмена ключами (Key Exchange, KEX) и кода аутентификации сообщений принимаемые протоколом SSH, задаются (включая предпочтительный порядок) с помощью следующих команд:

ip ssh server algorithm encryption <ALGORITHM> [<ALGORITHM> ...]

ip ssh server algorithm kex <ALGORITHM> [<ALGORITHM> ...]

ip ssh server algorithm mac <ALGORITHM> [<ALGORITHM> ...]

Более подробную информацию о допустимых алгоритмах см. в CNSSP 15 [4]. Требования CNSSP 15 комментируются в проекте документа IETF Commercial National Security Algorithm (CNSA) Suite Cryptography for Secure Shell (SSH) [36].

Статус сервиса SSH проверяется командой:

show ip ssh

Применение стандартного правила для разрешения доступа только с адресов, используемых администраторами, осуществляется при помощи команд:

line vty 0 4

  access-class <ACL#> in

line vty 5 15

  access-class <ACL#> in

Примечание: В случае отсутствия виртуальных интерфейсов с 5 по 15 нет необходимости в выполнении указанных команд. Обратите внимание, что правило доступа применятся также к сервису Telnet, если он был если он был активирован на виртуальных интерфейсах. В зависимости от устройства, может потребоваться применить аналогичные команды и к другим виртуальным интерфейсам. Дополнительные сведения о создании списков доступа см. в разделе 7.4.

Установка срока действия сессии на 5 минут реализуется при помощи команд:

line con 0

  exec-timeout 5 0

line vty 0 4

  exec-timeout 5 0

line vty 5 15

  exec-timeout 5 0

Примечание: В случае отсутствия виртуальных интерфейсов с 5 по 15 нет необходимости в выполнении указанных команд. Обратите внимание, что правило доступа применятся также к сервису Telnet, если он был если он был активирован на виртуальных интерфейсах. В зависимости от устройства, может потребоваться применить аналогичные команды и к другим виртуальным интерфейсам.

7.11.2 Настройка сервиса HTTP для удаленного администрирования

 
Если для управления сетевыми устройствами планируется использование сервиса HTTP, необходимо включить HTTP по TLS с помощью команды:

ip http secure-server

Использование TLS версии 1.2 осуществляется при помощи команды:

ip http tls-version TLSv1.2

Наборы шифров, принимаемые службой HTTP, включая предпочтительный порядок, указываются командой:

ip http secure-ciphersuite <CIPHERSUITE> [<CIPHERSUITE> ...]

Более подробную информацию о допустимых алгоритмах см. в CNSSP 15 [4]. Требования CNSSP 15 комментируются в проекте документа IETF Commercial National Security Algorithm (CNSA) Suite Profile for TLS and DTLS 1.2 and 1.3 [35].

Применение стандартного правила для разрешения доступа только с адресов, используемых администраторами, осуществляется при помощи команд:

ip http access-class <ACL#>

Примечание: Правило доступа применяется к защищенный и незащищённой версии службы HTTP. Дополнительные сведения о создании списков доступа см. в разделе 7.4.

По умолчанию время ожидания соединения с HTTP-сервером составляет 180 секунд (три минуты), поэтому нет необходимости изменять это значение.

7.11.3 Настройка SNMP для удаленного администрирования


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

snmp-server group <SNMPv3_GROUP> v3 priv access <ACL#>

snmp-server user <USER> <SNMPv3_GROUP> v3 auth sha <AUTH_PASSWORD> priv aes

256 <PRIV_PASSWORD> access <ACL#>

Для корректного использования протокола необходимо определить группу, где ключевое слово privэквивалентно authPriv (как аутентификация, так и шифрования). Помимо этого, необходимо создать несколько служебных пользователей и привязать к группе SNMP. В дополнение к параметрам аутентификации и шифрования, для каждого пользователя должны быть заданы два разных пароля, один для аутентификации, другой для шифрования. В связи с проблемами совместимости протоколов AES-192 и AES-256 необходимо использовать AES-128 для шифрования вместо AES-256 с параметром aes 128. Как показано выше, списки доступа можно применить как к группе, так и к каждому пользователю, указав его в качестве отдельной опции в конце каждой команды с параметром access.

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

snmpget -v 3 -u <USER> -a sha -l authPriv -A '<AUTH_PASSWORD>' -x AES

-X '<PRIV_PASSWORD>' <IP_ADDRESS> 1.3.6.1.2.1.1.5.0

8. Маршрутизация


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

8.1 Отключение функции маршрутизации по источнику


Маршрутизация по источнику (IP source routing) – это редко используемая функция, которая позволяет отправителю пакета указать заранее сформированный список промежуточных узлов, куда он должен быть направлен вместо того, чтобы использовать внутреннюю таблицу маршрутизации. Используя эту настройку, злоумышленник может передавать пакеты по выбранному им маршруту. Наряду с подделкой IP-адресов, злоумышленник может использовать функцию маршрутизации по источнику для успешного обхода списков контроля доступа и других сетевых ограничений, задавая собственный маршрут.

Хотя эта уязвимость связана с маршрутизаторами и способами маршрутизации пакетов, её можно использовать и на коммутаторах. Рекомендуется отключить функцию маршрутизации по источнику на всех устройствах, а не только на маршрутизаторах, поскольку эта функция не требуется для нормальной работы сети. В зависимости от производителя, может потребоваться отключить все варианты маршрутизации по источнику. Аналогичная функция доступна в IPv6, и ее нужно отключать отдельно. Отключить маршрутизацию по источнику можно с помощью следующих команд:

no ip source-route

no ipv6 source-route

8.2 Активация функции unicast Reverse Path Forwarding (uRPF)


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

Рекомендуется активировать функцию uRPF на внешних интерфейсах маршрутизаторов. На маршрутизаторах это необходимо для работы функции Cisco Express Forwarding (CEF), которая обеспечивает оптимизированный поиск для эффективной пересылки пакетов, и которую необходимо активировать до активации функции uRPF. Обратите внимание, что uRPF не следует включать на внутренних интерфейсах или маршрутизаторах с асимметричной маршрутизацией (когда для заданного адреса источника может существовать два или более обратных маршрута), поскольку такая ситуация может привести к отбрасыванию легитимных пакетов. Включить uRPF на одном интерфейсе можно с помощью следующих команд:

ip cef

interface <INTERFACE>

  ip verify unicast reverse-path

8.3 Активация функции аутентификации маршрутизации


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

Рекомендуется включать проверку подлинности маршрутизации для любых протоколов динамической маршрутизации, которые используются для получения обновлений маршрутизации от других устройств. Активация аутентификации маршрутизации по протоколу Open Shortest Path First (OSPF), происходит с помощью следующих команд:

key chain <KEY_CHAIN_NAME>

  key <KEY_NUMBER>

  key-string <KEY>

  cryptographic-algorithm hmac-sha-512

interface <INTERFACE>

  ip ospf authentication key-chain <KEY_CHAIN_NAME>

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

Активация аутентификации маршрутизации по протоколу Border Gateway Protocol (BGP) с применением уникального ключа-пароля к каждому отдельному узлу осуществляется при помощи следующих команд:

router bgp <AS_NUMBER>

  peer <IP_ADDRESS_1> password <KEY>

Активация аутентификации по протоколу Enhanced Interior Gateway Routing Protocol (EIGRP) путем создания связки ключей и применения ее к каждому интерфейсу осуществляется при помощи следующих команд:

key chain <KEY_CHAIN_NAME>

  key <KEY_NUMBER>

  key-string <KEY>

  cryptographic-algorithm hmac-sha-512

interface <INTERFACE>

  ip authentication key-chain eigrp <AS_NUMBER> <KEY_CHAIN_NAME>

Примечание: Для каждой ключа можно задать произвольное имя и номер. Параметр <KEY> – это заранее заданный ключ, назначенный соседним устройствам. Параметр cryptographic-algorithm нужно установить на hmac-sha-384, что будет соответствовать руководству CNSSP 15 [4].

Не рекомендуется использовать протокол Routing Information Protocol (RIP) из-за ограничений по сходимости и масштабируемости. Помимо этого, протокол RIP версии 1 не может быть настроен на аутентификацию соседних маршрутизаторов, что позволяет злоумышленником легко использовать его в своих целях. Устройства, поддерживающие только RIP, должны использовать статические маршруты или маршруты по умолчанию к другим устройствам, поддерживающим современные протоколы маршрутизации с аутентификацией.

9. Интерфейсные порты


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

9.1 Отключение функции динамического транкинга Dynamic Trunking Protocol (DTP)


Транк – это канал связи «точка-точка» между двумя устройствами, которые обмениваются инкапсулированными кадрами VLAN. В зависимости от трафика, передаваемого по каналу, порт интерфейса может динамически конфигурироваться как транковый порт или порт доступа. Злоумышленник, подключенный к динамическому порту, может сконфигурировать его в транковый и потенциально получить доступ к сетевому трафику без учета разделения VLAN.

Рекомендуется отключить динамическое транкирование, поскольку нет необходимости в том, чтобы порт интерфейса конфигурировался динамически. Когда устройство добавляется в сеть, убедитесь, что все интерфейсные порты явно настроены как транковы порты или порты доступа. Системы, которые не обрабатывают инкапсулированные кадры VLAN, должны быть подключены к порту, который сконфигурирован как порт доступа.

Строгая настройка порта интерфейса для статического доступа выполняется при помощи следующих команд:

interface <INTERFACE>

  switchport mode access

Строгая настройка порта интерфейса в качестве транкового выполняется при помощи следующих команд:

interface <INTERFACE>

  switchport mode trunk

9.2 Активация функции защиты портов


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

Рекомендуется активировать функцию защиты портов на всех активных коммутационных портах устройства и установить максимальное количество разрешенных MAC-адресов для каждого порта равным одному или двум, если используются возможности VoIP. Защита портов не заменяет функционала Network Access Control (NAC), например 802.1X, но должна использоваться, когда NAC не может быть реализован. Если возможно, назначьте фиксированный MAC-адрес каждому порту коммутатора, и настройте каждый порт коммутатора на отключение или отправку сообщения SNMP в случаях нарушения безопасности порта. Функция безопасность портов может быть активирована и на транковых интерфейсах, но это не рекомендуется делать, так как требуется знать количество устройств, трафик которых проходит через этот конкретный транковый порт. Динамический коммутационный порт не может иметь одновременно включенную защиту порта, и сначала должен быть сконфигурирован для статического доступа, прежде чем можно будет активировать защиту порта.

Активация защиты порта на статическом порту доступа с максимально возможным одним MAC-адресом выполняется при помощи следующих команд:

interface <INTERFACE>

  switchport mode access

  switchport port-security

  switchport port-security maximum 1

  switchport port-security violation shutdown

  switchport port-security mac-address sticky

Параметр stickyпозволит устройству вставить MAC-адрес в конфигурацию после первого подключения авторизованной системы к порту.

Примечание: Конфигурацию необходимо сохранить, чтобы информация сохранилась после перезагрузки. Если отключение порта не является приемлемым действием из-за проблем с доступностью устройства, параметр shutdown может быть заменен на restrict, чтобы предотвратить подключение дополнительных MAC-адресов.

9.3 Отключение заводского VLAN


Большинство коммутаторов используют VLAN 1 по умолчанию, включая порты управления, которые могут обеспечить прямой доступ к коммутатору для администрирования. Кроме того, некоторые протоколы второго уровня должны отправляться в определенный VLAN на транковых портаах, и VLAN 1 обычно выбирается по умолчанию. Если не предпринять меры по снижению риска, используемый по умолчанию VLAN может распространяться на всю сеть и подвергнуть авторизованные системы повышенному риску эксплуатации неавторизованными системами.

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

Кадры данных, которые отправляются и принимаются на транковых портах, обычно помечаются идентификатором VLAN ID связанным с кадром. Любые не помеченные кадры данных автоматически помещаются в VLAN, связанный с этим портом. Такой VLAN должен быть сконфигурирован на обоих концах транкового канала. Аналогично, кадры, отправленные и полученные на портах доступа, передаются в VLAN, связанный с этим портом. Все порты привязывается на VLAN доступа или транковый VLAN, вне зависимости от того, являются ли они транковыми портами или портами доступа.

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

Создать уникальный транковый VLAN (500) и неиспользуемый и отключенный VLAN доступа (997), назначенный на транковый порт, можно с помощью следующих команд:

vlan 500

  name NATIVE-TRUNK

vlan 997

  name UNUSED-ACCESS

  shutdown

interface <INTERFACE>

  switchport mode trunk

  switchport access vlan 997

  switchport trunk native vlan 500

  switchport trunk allowed vlan 2-4094

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

Создать неиспользуемый и отключенный VLAN (998), назначенный на транковый VLAN порт доступа, можно с помощью следующих команд:

vlan 998

  name UNUSED-NATIVE

  shutdown

interface <INTERFACE>

  switchport mode access

  switchport access vlan <ACCESS_VLAN#>

  switchport trunk native vlan 998

В том случае, если в сети используется функционал VoIP, то порты коммутатора также можно привязать к отдельному VLAN при помощи следующих команд:

interface <INTERFACE>

  switchport voice vlan <VOICE_VLAN#>

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

show interfaces switchport

9.4 Отключение неиспользуемых портов


Если оставить неиспользуемые порты включенными на устройстве, злоумышленник может подключить неавторизованное устройство к сети и произвести сбор информации или попытаться скомпрометировать сетевые устройства. Все неиспользуемые порты должны быть отключены и помещены в неиспользуемый VLAN, который не используется по умолчанию.

Рекомендуется отключать все неиспользуемые порты на устройстве путем отключения соответствующих интерфейсов и, если это поддерживается устройством, назначить неиспользуемые порты в неиспользуемый VLAN – это позволит предотвратить доступ к сети, даже если порты со временем перейдут в активное состояние. Перед отключением порта необходимо убедиться, что он действительно не используется и к нему ничего не подключено. Если устройство, подключенное к порту, отключено от питания, может показаться, что порт коммутатора не используется.

Отключить неиспользуемые интерфейсы и привязать VLAN портов доступа и транковый VLAN к неиспользуемому и отключённому VLAN можно при помощи команды:

vlan 999

  name UNUSED-DISABLED

  shutdown

interface <INTERFACE>

  switchport mode access

  switchport access vlan 999

  switchport trunk native vlan 998

  no switchport voice vlan

  shutdown

Примечание: Нет необходимости назначать VLAN для сервиса VoIP в неиспользуемый VLAN, так как она останется не назначенной, если функционал VoIP не используется.

9.5 Отключение мониторинга портов


Мониторинг портов используется на сетевом коммутаторе для отправки копии сетевых пакетов, принимаемых на одном коммутационном порту, на соединение для мониторинга сети на другом коммутационном порту. Устройство, в котором определены один или несколько сеансов мониторинга портов, позволяет набору портов-источников отслеживать указанный порт назначения, и весь трафик, отправляемый на порты-источники или с них, будет также отправляться на порт назначения.

Мониторинг портов обычно используется для подключения систем обнаружения вторжений – Network Intrusion Detection System (NIDS), диагностики проблем или использования сетевого анализатора для мониторинга сети. В зависимости от производителя, мониторинг портов также известен как «зеркалирование портов» (port mirroring) или «проброс портов» (port spanning). Злоумышленник, подключенный к порту мониторинга, сможет собирать сетевой трафик, отправленный через все порты-источники, указанные в конфигурации сервиса.

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

Примечание: Некоторые производители не позволяют отправлять трафик с порта мониторинга, запрещая доступ к сети с этого порта. Такой тип поведения предпочтителен, когда к сеансу мониторинга порта подключена система NIDS.

Проверить сеансы мониторинга, определенные в конфигурации, можно с помощью следующей команды:

show monitor session [1|2|all]

Примечание: Если поддерживается параметр all, то будут перечислены все сессии; в противном случае каждый отдельный номер сессии нужно будет указать в отдельных командах, обычно 1 и 2.

Удалить сеанс мониторинга, определенный в конфигурации, можно с помощью следующей команды:

no monitor session <SESSION#>

9.6 Отключение функции проксирования протокола Address Resolution Protocol


Проксирование протокола Address Resolution Protocol (ARP) – это метод, при котором прокси-сервер в сети отвечает на ARP-запросы для IP-адреса, который не находится в этой сети. Это помогает устройствам в подсети связаться с удаленными подсетями без настройки маршрутизации на шлюзе по умолчанию. Это может быть удобно, поскольку его можно добавить к маршрутизатору, не меняя таблицы маршрутизации других сетей, но эта функция позволяет злоумышленникам подделывать и перехватывать пакеты.

Рекомендуется отключить функцию проксирования ARP на всех интерфейсах, если только устройство не используется в качестве шлюза локальной сети или для преобразования входящих сетевых адресов по протоколу Network Address Translations (NAT) для нескольких IP-адресов. Может потребоваться отключить прокси ARP на каждом отдельном интерфейсе, а не отключать его для всей системы.

Определить интерфейсы, на которых включена функция проксирования ARP, можно с помощью следующей команды:

show ip interface

Отключить функцию Proxy ARP на интерфейсе можно с помощью следующих команд:

interface <INTERFACE>

  no ip proxy-arp

10. Баннеры


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

10.1 Баннер уведомления


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

Например, системы Министерства обороны (Department of Defense) должны использовать баннер, отвечающий требованиям инструкции 8500.01. Другие государственные организации США должны применять требования NIST SP800-53, AC-8. Для организаций частного сектора Агентство по кибербезопасности и безопасности инфраструктуры (Cybersecurity and Infrastructure Security Agency) выпустило очень полезное руководство по разработке соответствующего баннера [40].

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

Устройства Cisco IOS имеют два типа баннеров – баннер входа отображается перед входом пользователя в систему, а после успешной аутентификации пользователя отображается «сообщение дня» (message of the day). Как минимум, баннер уведомления должен отображаться как для авторизованных, так и для неавторизованных пользователей, пытающихся войти в систему. При необходимости, та же или дополнительная информация может быть предоставлена аутентифицированным пользователям после входа в систему.

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

banner login ^

INSERT NOTIFICATION BANNER HERE

^

Примечание: Символ каретки («^») используется в качестве разделителя, чтобы баннер мог охватывать несколько строк, при условии, что символ каретки не используется в самом баннере. После вставки этой команды в конфигурацию разделитель обычно отображается как «^C» вместо "^".

Не вводите «^C» как часть команды, иначе баннер будет начинаться с «C». Добавить такой же баннер уведомления или дополнительную информацию для авторизованных пользователей, успешно прошедших аутентификацию, можно при помощи команды:

banner motd ^

INSERT NOTIFICATION BANNER HERE

ADDITIONAL INFORMATION

^

11. Заключение


Руководство в этом отчете было разработано на основе обширного опыта Агентства Национальной Безопасности – National Security Agency (NSA) по оценке сетей и предоставления рекомендаций по защите сетевых устройств. Наряду с выполнением основных функций по обслуживанию, администраторы играют важную роль в защите сетей от различных угроз. Следование данному руководству поможет сетевым администраторам внедрить передовые методы обеспечения кибербезопасности, снизить риск компрометации и обеспечить более безопасную и защищенную сеть.

Используемые аббревиатуры


AAA – Authentication, authorization, and accounting

ACL – Access control list

AES – Advanced Encryption Standard

ARP – Address Resolution Protocol

AUX – Auxiliary

BGP – Border Gateway Protocol

CDP – Cisco Discovery Protocol

CEF – Cisco Express Forwarding

CISA – Cybersecurity and Infrastructure Security Agency

CNSA – Commercial National Security Algorithm Suite

CNSSP – Committee on National Security Systems Policy

CON – Console

DHCP – Dynamic Host Configuration Protocol

DMZ – Demilitarized zone

DoS – Denial of service

ECC – Elliptic curve cryptography

ECP – Elliptic curve group modulo a prime

EIGRP – Enhanced Interior Gateway Routing Protocol

ESP – Encapsulating Security Payload

FTP – File Transfer Protocol

HTTP – Hypertext Transfer Protocol

IETF – Internet Engineering Task Force

IKE – Internet Key Exchange

IOS – Internetwork Operating System

IP – Internet Protocol

IPS – Intrusion prevention system

IPsec – Internet Protocol Security

ISAKMP – Internet Security Association and Key Management Protocol

ISP – Internet service provider

KEX – Key exchange

LAN – Local area network

LLDP – Link Layer Discovery Protocol

MAC – Media access control

MD5 – Message Digest 5

MODP – Modular Exponent

NAC – Network access control

NAT – Network address translation

NDI – Network Device Integrity

NIDS – Network intrusion detection system

NIST – National Institute of Standards and Technology

NSA – National Security Agency

NSS National Security System(s)

NTP – Network Time Protocol

OMB – Office of Management and Budget

OSPF – Open Shortest Path First

RIP – Routing Information Protocol

RSA – Rivest-Shamir-Adleman

SCP – Secure Copy Protocol

SFTP – Secure File Transfer Protocol

SHA – Secure Hash Algorithm

SIEM – Security information and event management

SNMP – Simple Network Management Protocol

SSH – Secure Shell

TCP – Transmission Control Protocol

TFTP – Trivial File Transfer Protocol

TLS – Transport Layer Security

UDP – User Datagram Protocol

uRPF – Unicast reverse-path forwarding

UTC – Coordinated Universal Time

VLAN – Virtual local area network

VoIP – Voice over IP

VPN – Virtual private network

VTY – Virtual teletype

Список литературы


[1] Cybersecurity and Infrastructure Security Agency (2022), Layering Network Security Through Segmentation. Available at: https://www.cisa.gov/sites/default/files/publications/layering-networksecurity-segmentation_infographic_508_0.pdf

[2] National Security Agency (2019), Segment Networks and Deploy Application-aware Defenses. Available at: https://www.nsa.gov/cybersecurity-guidance

[3] National Security Agency (2021), Selecting and Hardening Remote Access VPN Solutions. Available at: https://www.nsa.gov/cybersecurity-guidance

[4] Committee on National Security Systems (2016), CNSS Policy 15. Available at: https://www.cnss.gov/CNSS/issuances/Policies.cfm

[5] Corcoran, Jenkins, NSA (2021), Commercial National Security Algorithm (CNSA) Suite Cryptography for Internet Protocol Security (IPsec). Available at: https://datatracker.ietf.org/doc/html/draft-corcoran-cnsa-ipsec-profile

[6] National Security Agency (2020), Configuring IPsec Virtual Private Networks. Available at: https://www.nsa.gov/cybersecurity-guidance

[7] National Security Agency (2019), Mitigating Recent VPN Vulnerabilities. Available at: https://www.nsa.gov/cybersecurity-guidance

[8] National Security Agency (2021), Eliminating Obsolete Transport Layer Security (TLS) Protocol Configurations. Available at: https://www.nsa.gov/cybersecurity-guidance

[9] Arista Networks, Inc. (2022), Support Overview. Available at: https://www.arista.com/en/support/

[10] Aruba Networks (2022), Aruba Support Services. Available at: https://www.arubanetworks.com/support-services/

[11] Broadcom Inc. (2022), Support and Services. Available at: https://www.broadcom.com/support/

[12] Cisco Systems, Inc. (2022), Support & Downloads. Available at: https://www.cisco.com/c/en/us/support/index.html

[13] Dell (2022), Support. Available at: https://www.dell.com/support/home/en-us/

[14] Extreme Networks (2022), Support. Available at: https://www.extremenetworks.com/support/

[15] F5, Inc. (2022), Support | Services. Available at: https://www.f5.com/services/support/

[16] Fortinet, Inc. (2022), FortiCare Technical Support and Services. Available at: https://www.fortinet.com/support

[17] Hewlett Packard Enterprise Development LP (2022), Services and Support. Available at: https://www.hpe.com/us/en/services.html

[18] International Business Machines Corporation (2022), IBM Support. Available at: https://www.ibm.com/mysupport/

[19] Juniper Networks, Inc. (2022), Support. Available at: https://support.juniper.net/support/

[20] Linksys Holdings (2022), Official Linksys Support Site. Available at: https://www.linksys.com/us/support/

[21] NETGEAR (2022), Support. Available at: https://www.netgear.com/support/

[22] Palo Alto Networks (2022), Customer Support. Available at: https://support.paloaltonetworks.com/support/

[23] Riverbed Technology (2022), Riverbed Support. Available at: https://support.riverbed.com/

[24] CommScope, Inc. (2022), Ruckus Wireless Support. Available at: https://support.ruckuswireless.com/

[25] SonicWall (2022), Support Portal & Downloads. Available at: https://www.sonicwall.com/support/

[26] TRENDnet Inc. (2022), Customer Support. Available at: https://www.trendnet.com/support/

[27] Eaton (2022), Help Center | Tripp Lite. Available at: https://www.tripplite.com/support/

[28] Ubiquiti Inc. (2022), Ubiquiti Support and Help Center. Available at: https://help.ui.com/hc/en-us/

[29] WatchGuard Technologies, Inc. (2022), WatchGuard Support. Available at: https://www.watchguard.com/wgrd-support/overview

[30] National Security Agency (2016), Network Device Integrity (NDI) Methodology. Available at: https://www.iad.gov/iad/library/reports/network-device-integrity-methodology.cfm

[31] National Security Agency (2016), Network Device Integrity (NDI) on Cisco IOS devices. Available at: https://www.iad.gov/iad/library/reports/network-device-integrity-ndi-cisco-iosdevices.cfm

[32] National Security Agency (2016), Validate Integrity of Hardware and Software. Available at: https://www.iad.gov/iad/library/ia-guidance/security-tips/validate-integrity-of-hardware-andsoftware.cfm

[33] National Security Agency (2022), Cisco Password Types: Best Practices. Available at: https://www.nsa.gov/cybersecurity-guidance

[34] Office of Management and Budget (2021), Improving the Federal Government’s Investigative and Remediation Capabilities Related to Cybersecurity Incidents. Available at: https://www.whitehouse.gov/wp-content/uploads/2021/08/M-21-31-Improving-the-FederalGovernments-Investigative-and-Remediation-Capabilities-Related-to-Cybersecurity-Incidents.pdf

[35] Cooley, D, NSA (2021), Commercial National Security Algorithm (CNSA) Suite Profile for TLS and DTLS 1.2 and 1.3. Available at: https://datatracker.ietf.org/doc/html/draft-cooley-cnsa-dtlstlsprofile

[36] Gajcowski, Jenkins, NSA (2021), Commercial National Security Algorithm (CNSA) Suite Cryptography for Secure Shell (SSH). Available at: https://datatracker.ietf.org/doc/html/draftgajcowski-cnsa-ssh-profile

[37] National Institute for Standards and Technology (2020), Special Publication 800-52 Rev. 2: Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations. Available at: https://csrc.nist.gov/publications/detail/sp/800-52/rev-2/final

[38] Cisco Systems, Inc. (2017), Cisco Smart Install Protocol Misuse. Available at: https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20170214-smi

[39] National Security Agency (2017), Cisco Smart Install Protocol Misuse. Available at: https://www.nsa.gov/cybersecurity-guidance

[40] Cybersecurity and Infrastructure Security Agency (2022), Guidance on Consent Banners. Available at: https://www.cisa.gov/publication/guidance-consent-banners

Дополнительные документы



Сведения о переводе


Перевод выполнен с документа «CTR: Network Infrastructure Security Guide (June 2022 Update)»: https://media.defense.gov/2022/Jun/15/2003018261/-1/-1/0/CTR_NSA_NETWORK_INFRASTRUCTURE_SECURITY_GUIDE_20220615.PDF

Переводчик: Александр Стихин

astikhin.ru

https://t.me/alex_stikhin

28.08.2022



Alexander (c) Stikhin