6. Функції та сервіси хоста
Вимоги безпеки, перевірка параметрів та інженерні рекомендації для розділу «Функції та сервіси хоста».
Рекомендацій: 18
VMware ESXi 8.0 v1.4.0
6.1.1 Послуги хосту CIM, якщо їх увімкнено, мають обмежити доступ (Вручну)
Система загальної інформаційної моделі (CIM) дозволяє керувати на апаратному рівні із віддалених програм через стандартні API. Забезпечення лише мінімального доступу необхідні для цих програм, є обов’язковим для запобігання потенційним порушенням безпеки. Щоб обмежити, слід створити спеціальний обліковий запис служби для кожної програми CIM доступ і привілеї.
Обмеження доступу до послуг CIM має важливе значення для запобігання несанкціонованому або надмірному привілейований доступ, що може призвести до потенційної вразливості безпеки. Ця практика дотримується принципу найменших привілеїв, сприяючи більш безпечному середовищу.
Якщо надано неналежний доступ до інструментів моніторингу обладнання на основі CIM або інших сторонніх програм, вони можуть не працювати належним чином або можуть бути використані для поставити під загрозу безпеку хоста.
Щоб переконатися, що доступ до CIM обмежено, перевірте обліковий запис служби з обмеженими привілейованими правами з такими застосованими ролями CIM: Host.Config.SystemManagement Host.CIM.CIMInteraction Крім того, можна використати таку команду PowerCLI: # Перелік усіх облікових записів користувачів на хості – Потрібне локальне підключення до хосту – Get-VMHostAccount
Щоб обмежити доступ до CIM, виконайте такі дії:
- Створіть обліковий запис служби з обмеженими привілейованими правами для CIM та інших програм сторонніх розробників.
- Цей обліковий запис має отримати доступ до системи через vCenter.
- Надайте обліковому запису лише привілей CIM Interaction. Це дозволить обліковому запису отримати квиток CIM, який потім можна використовувати для виконання операцій читання та запису CIM на цільовому хості. Якщо обліковий запис має підключатися до хосту безпосередньо, цьому обліковому запису має бути надано повну роль «Адміністратор» на хості. Це не рекомендується, якщо це не вимагається програмним забезпеченням моніторингу, яке використовується. Сторінка 174 Лише для внутрішнього використання – загальне Крім того, виконайте таку команду PowerCLI: # Створіть новий обліковий запис користувача хоста -Потрібне локальне підключення до хосту- New-VMHostAccount -ID ServiceUser -Password
-UserAccount
📋 CIS Controls & Нормативні посилання
- https://docs.vmware.com/en/VMware-
- vSphere/7.0/com.vmware.vsphere.security.doc/GUID-645EBD81-CF86-44D7-
- BE77-224EF963D145.html
IG 1, 2
IG 1, 2, 3
Page 175 Internal Only – General 6.2 Core Storage
Page 176 Internal Only – General
6.2.1 Хост повинен ізолювати комунікації зі сховищем (Вручну)
Ізоляція зв’язків зі сховищем через зонування та номер логічного блоку (LUN) маскування є важливим у відокремленні діяльності мережі зберігання даних (SAN). Зонування визначає з’єднання між адаптерами хост-шини (HBA) і цілями, забезпечуючи пристрої за межами зони залишаються невидимими для пристроїв усередині, таким чином полегшуючи незалежне управління зонами, такими як тестування та виробництво. З іншого боку, Крім того, маскування LUN контролює видимість і доступність LUN для різних хостів підвищення деталізації контролю доступу в мережі зберігання. Шляхом реалізації завдяки цим заходам поверхня атаки SAN зменшується, а системи без ESXi – зменшуються заборонено доступ до SAN і розділення середовищ, таких як test і виробництво досягнуто.
Застосування зонування та маскування LUN для ізоляції комунікацій сховища є життєво важливим зменшити ризик несанкціонованого доступу та потенційного перехресного зараження між ними різні робочі середовища. Це дозволяє зробити його більш структурованим і безпечним управління ресурсами зберігання, гарантуючи, що неавторизовані або несумісні системи не можуть взаємодіяти з SAN або отримувати доступ до неї, таким чином сприяючи загальна безпека та експлуатаційна цілісність середовища.
Неможливість ізоляції зв’язку зі сховищем може призвести до підвищеного ризику несанкціонованого доступу доступ до ресурсів зберігання, потенційний витік даних або перешкоди між різними операційні зони. Відсутність сегрегації також може створити проблеми в управлінні та усунення несправностей у роботі мережі зберігання, що призводить до неефективності роботи та потенційні ризики безпеки.
Процедури аудиту для перевірки належного відокремлення діяльності SAN залежать від постачальника SAN або продукту.
Процедури виправлення для належного відокремлення діяльності SAN залежать від постачальника SAN або продукту. Загалом, для хостів ESXi використовуйте зонування з одним ініціатором або зонування з одним ініціатором і однією цільовою зоною. Останнє є кращою практикою зонування. Використання більш обмеженого зонування запобігає проблемам і неправильним налаштуванням, які можуть виникнути в SAN. Сторінка 177 Тільки для внутрішнього використання – Загальні
📋 CIS Controls & Нормативні посилання
- https://docs.vmware.com/en/VMware-
- vSphere/6.7/com.vmware.vsphere.storage.doc/GUID-6029358F-8EE8-4143-
- 9BB0-16ABB3CA0FE3.html
- https://docs.vmware.com/en/VMware-
- vSphere/6.7/com.vmware.vsphere.security.doc/GUID-BFE9046A-2278-4026-
- 809A-ED8F9D8FDACE.html
- https://docs.vmware.com/en/VMware-
- vSphere/6.7/com.vmware.vsphere.storage.doc/GUID-39A4551F-4B03-43A6-
- BEDF-FAB1528C070D.html
IG 1, 2
IG 1, 2
IG 1, 2
Page 178 Internal Only – General
6.2.2 Хост повинен переконатися, що всі сховища даних мають унікальні імена (Вручну)
Забезпечення унікального іменування для сховищ даних має вирішальне значення, щоб уникнути можливих помилок, які можуть впливають на цілісність і доступність даних. Описове та унікальне ім’я для кожного сховище даних полегшує ідентифікацію та керування. Хоча конкретного немає параметр, щоб забезпечити це, слід дотримуватися ручних або автоматичних умов іменування до.
Унікальні та описові імена для сховищ даних мінімізують ризик помилок, покращують керованість і допомагає швидше ідентифікувати, особливо в середовищах з численні сховища даних. Це проактивний захід для підтримки порядку та уникнення проблем, які виникають із імен за замовчуванням, наданих сховищам даних VMFS і vSAN.
Недотримання унікальної угоди про іменування може призвести до плутанини, неправильної конфігурації або некоректний доступ до даних. У той час як перейменування сховищ даних може мати низькі наслідки системи автоматизації, моніторингу та резервного копіювання, переваги унікального іменування умовності переважують потенційні негативи.
Список сховищ даних за допомогою: список файлової системи зберігання esxcli
- — АБО — PowerCLI Get-Datastore Переконайтеся, що імена сховищ даних є унікальними в керованому інвентарі vCenter і є достатньо описовими, щоб запобігти адміністративній неоднозначності. Сторінка 179 Тільки для внутрішнього використання – Загальні
📋 CIS Controls & Нормативні посилання
IG 1, 2
IG 1
Page 180 Internal Only – General 6.3 iSCSI
Page 181 Internal Only – General
6.3.1 Хост-клієнт iSCSI, якщо ввімкнено, має використовувати двонаправлену/взаємну автентифікацію CHAP (Автоматизовано)
Реалізація двонаправленої автентифікації CHAP для підключень iSCSI підвищує безпеку через необхідність взаємної перевірки між ініціатором (клієнтом) і метою (сервером), забезпечення цілісності даних під час передачі. Конфігурація передбачає налаштування iSCSI автентифікація адаптера зберігання для “Використовувати двонаправлений CHAP” і надання необхідного облікові дані. Це налаштування забезпечує весь зв’язок між клієнтом і сервером залишається безпечним і незмінним, значно знижуючи ризик перехоплення даних неуповноважені особи. Параметром, який регулює цю поведінку, є встановлене сховище iSCSI автентифікація адаптера на «Використовувати двонаправлений CHAP» із рекомендованим налаштуванням Увімкнено.
Використання двонаправленої автентифікації CHAP значно мінімізує пов’язані ризики з перехопленням або зміною даних неавторизованими особами під час передачі між ініціатором і метою. Цей додатковий рівень безпеки має вирішальне значення для підтримки цілісність даних і конфіденційність підключень iSCSI.
Функціональний вплив впровадження цього контролю не очікується. Однак це важливо забезпечити правильну конфігурацію, щоб уникнути можливих збоїв у зв’язку між клієнтом і сервером iSCSI.
Щоб перевірити, чи ввімкнено двонаправлену автентифікацію CHAP для трафіку iSCSI, виконайте такі дії:
- У веб-клієнті vSphere виберіть хост.
- Натисніть «Налаштувати», а потім розгорніть «Сховище».
- Виберіть «Адаптери зберігання», а потім виберіть адаптер iSCSI.
- У розділі «Властивості» переконайтеся, що для методу автентифікації встановлено значення «Використовувати двонаправлений CHAP». Крім того, можна використати наступну команду PowerCLI: Page 182 Лише для внутрішнього використання – загальне # Список ініціатора Iscsi та імені CHAP, якщо визначено Get-VMHost | Get-VMHostHba | Де {$_.Type -eq “Iscsi”} | Виберіть VMHost, Device, ChapType, @{N=”CHAPName”;E={$_.AuthenticationProperties.ChapName}}
Щоб увімкнути двонаправлену автентифікацію CHAP для трафіку iSCSI, виконайте такі дії:
- У веб-клієнті vSphere виберіть хост.
- Натисніть «Налаштувати», а потім розгорніть «Сховище».
- Виберіть «Адаптери зберігання», а потім виберіть адаптер iSCSI.
- У розділі «Властивості» натисніть «Редагувати» біля пункту «Автентифікація».
- У розкривному списку «Метод автентифікації» виберіть «Використовувати двонаправлений CHAP».
- Укажіть назву вихідного CHAP. • Переконайтеся, що назва, яку ви вказуєте, відповідає імені, налаштованому на стороні сховища. o Щоб встановити ім’я CHAP на ім’я адаптера iSCSI, виберіть «Використовувати ім’я ініціатора». o Щоб встановити ім’я CHAP на будь-яке інше, ніж ім’я ініціатора iSCSI, зніміть прапорець «Використовувати ім’я ініціатора» та введіть ім’я в текстовому полі Ім’я.
- Введіть вихідний секрет CHAP, який буде використовуватися як частина автентифікації. Використовуйте той самий секрет, що й секрет сторони зберігання.
- Укажіть вхідні облікові дані CHAP. Переконайтеся, що ваші вихідні та вхідні секрети не збігаються.
- Натисніть OK.
- Клацніть передостанній символ із позначкою Rescan Adapter. Або запустіть таку команду PowerCLI: # Установіть параметри Chap для адаптера Iscsi Get-VMHost | Get-VMHostHba | Де {$_.Type -eq “Iscsi”} | Set-VMHostHba # Використовуйте потрібні параметри тут
📋 CIS Controls & Нормативні посилання
- https://docs.vmware.com/en/VMware-
- vSphere/7.0/com.vmware.vsphere.storage.doc/GUID-AC65D747-728F-4109-
- 96DD-49B433E2F266.html
- https://docs.vmware.com/en/VMware-
- vSphere/7.0/com.vmware.vsphere.storage.doc/GUID-2F1E64DB-20BB-4D18-
- A083-8E65FE380899.html
Page 183 Internal Only – General Additional Information: Prerequisites- Before setting up CHAP parameters for software or dependent hardware iSCSI, determine whether to configure unidirectional or bidirectional CHAP. Independent hardware iSCSI adapters do not support bidirectional CHAP. • Verify CHAP parameters configured on the storage side. Parameters that you configure must match the ones on the storage side. • Required privilege: Host.Configuration.Storage Partition Configuration
IG 1
6.3.2 Хост-клієнт iSCSI, якщо ввімкнено, має використовувати унікальні секрети автентифікації CHAP (Вручну)
Протокол автентифікації Challenge-Handshake (CHAP) вимагає, щоб і клієнт, і хост знати секрет, щоб встановити зв’язок. Важливо використовувати унікальний CHAP секрети автентифікації для кожного сеансу iSCSI для забезпечення безпечного зв’язку. The параметр, що регулює цю поведінку, описано в адаптері зберігання iSCSI або iSER у налаштуваннях CHAP.
Використання унікальних секретів автентифікації CHAP для кожного сеансу iSCSI сприяє забезпеченню безпеки передачі даних і зменшує ризик несанкціонованого доступу.
Під час підвищення безпеки, неправильне налаштування або обмін секретами CHAP між сеансами потенційно може призвести до проблем із підключенням або несанкціонованого доступу.
Щоб переконатися, що секрети CHAP унікальні, запустіть наступне, щоб перелічити всі адаптери iSCSI та їх відповідну конфігурацію CHAP: # Список ініціатора Iscsi та імені CHAP, якщо визначено Get-VMHost | Get-VMHostHba | Де {$_.Type -eq “Iscsi”} | Виберіть VMHost, Device, ChapType, @{N=”CHAPName”;E={$_.AuthenticationProperties.ChapName}}
Щоб змінити значення секретів CHAP, щоб вони були унікальними, виконайте такі дії:
- У веб-клієнті vSphere виберіть хост.
- Натисніть «Налаштувати», а потім розгорніть «Сховище».
- Виберіть «Адаптери зберігання», а потім виберіть адаптер iSCSI.
- У розділі «Властивості» натисніть «Редагувати» біля пункту «Автентифікація».
- Поруч із пунктом «Метод автентифікації» вкажіть метод автентифікації зі спадного списку. o Немає o Використовувати однонаправлений CHAP, якщо це вимагає ціль o Використовувати однонаправлений CHAP, якщо це не заборонено цільовим o Використовувати однонаправлений CHAP o Використовувати двонаправлений CHAP Сторінка 185 Тільки для внутрішнього використання – загальне
- Укажіть назву вихідного CHAP. • Переконайтеся, що назва, яку ви вказуєте, відповідає імені, налаштованому на стороні сховища. o Щоб встановити ім’я CHAP на ім’я адаптера iSCSI, виберіть «Використовувати ім’я ініціатора». o Щоб встановити ім’я CHAP на будь-яке інше, ніж ім’я ініціатора iSCSI, зніміть прапорець «Використовувати ім’я ініціатора» та введіть ім’я в текстовому полі Ім’я.
- Введіть вихідний секрет CHAP, який буде використовуватися як частина автентифікації. Використовуйте той самий секрет, що й секрет сторони зберігання.
- У разі налаштування двонаправленого CHAP укажіть вхідні облікові дані CHAP. • Переконайтеся, що ваші вихідні та вхідні секрети не збігаються.
- У разі налаштування двонаправленого CHAP укажіть вхідні облікові дані CHAP. • Переконайтеся, що ваші вихідні та вхідні секрети не збігаються.
- Натисніть OK.
- Клацніть передостанній символ із позначкою Rescan Adapter
📋 CIS Controls & Нормативні посилання
- https://docs.vmware.com/en/VMware-
- vSphere/7.0/com.vmware.vsphere.storage.doc/GUID-AC65D747-728F-4109-
- 96DD-49B433E2F266.html
- https://docs.vmware.com/en/VMware-
- vSphere/7.0/com.vmware.vsphere.storage.doc/GUID-2F1E64DB-20BB-4D18-
- A083-8E65FE380899.html
- Additional Information:
- If you change the CHAP parameters, they are used for new iSCSI sessions. For existing
- sessions, new settings are not used until you log out and log in again.
IG 1, 2, 3
Page 186 Internal Only – General Controls Version Control IG 1 IG 2 IG 3 v7 4.4 Use Unique Passwords Where multi-factor authentication is not supported (such as local administrator, root, or service accounts), accounts will use passwords that are unique to that system. ● ●
Page 187 Internal Only – General 6.4 SNMP
Page 188 Internal Only – General
6.4.1 Сервіси хосту SNMP, якщо їх увімкнено, повинні обмежувати доступ (Вручну)
Щоб безпечно керувати хостами, якщо SNMP увімкнено, доступ має бути обмежено. Бажано, Слід використовувати SNMPv3, оскільки він забезпечує чудову безпеку через автентифікацію за допомогою ключа і шифрування порівняно з SNMPv1 або SNMPv2. Налаштування пункту призначення для Пастки SNMP є важливими для того, щоб дані моніторингу спрямовувалися до легітимних і безпечний хост.
Правильна конфігурація SNMP має вирішальне значення для зниження ризику неправильного використання або компрометації, особливо якщо існують інші засоби управління. Покращений захист SNMPv3 функції є ключовими для безпечного керування та моніторингу.
Неправильна конфігурація SNMP може перенаправляти конфіденційні дані моніторингу на шкідливі хости, ризик використання та порушення безпеки хоста.
Щоб підтвердити правильну конфігурацію SNMP, виконайте такі дії в ESXi Shell або vCLI:
- Виконайте наступне, щоб визначити, чи використовується SNMP: esxcli system snmp get
- Якщо використовується SNMP, зверніться до посібника з моніторингу та продуктивності vSphere, розділ 8, щоб дізнатися, як перевірити параметри. Крім того, для перегляду конфігурації SNMP можна використовувати наступну команду PowerCLI: # Перелік конфігурації SNMP хоста (потрібне підключення до одного хоста) Get-VMHostSnmp
Щоб виправити конфігурацію SNMP, виконайте такі дії в ESXi Shell або vCLI:
- Якщо SNMP не потрібний, вимкніть його, виконавши: Сторінка 189 Лише для внутрішнього використання – Загальне esxcli system snmp set –enable false
- Якщо потрібен SNMP, зверніться до посібника з моніторингу та продуктивності vSphere, розділ 8, щоб дізнатися, як його налаштувати. Крім того, для реалізації конфігурації можна використати таку команду PowerCLI: # Оновити конфігурацію SNMP хоста (потрібне з’єднання з одним хостом) Get-VmHostSNMP | Set-VMHostSNMP -Enabled:$true -ReadOnlyCommunity ‘
‘ Примітки: • SNMP необхідно налаштувати на кожному хості ESXi • Параметри SNMP можна налаштувати за допомогою профілів хоста
📋 CIS Controls & Нормативні посилання
- https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-monitoring-
- performance/GUID-8EF36D7D-59B6-4C74-B1AA-4A9D18AB6250.html
IG 1, 2
IG 1, 2
Page 190 Internal Only – General 6.5 SSH
Page 191 Internal Only – General
6.5.1 Демон хосту SSH, якщо ввімкнено, має використовувати підтверджені шифри FIPS 140-2/140-3 (Вручну)
Для підвищення безпеки, якщо демон SSH увімкнено на хості, він має використовувати FIPS Перевірені шифри 140-2/140-3. Ця вимога забезпечує дотримання стандартів шифрування надійний і відповідає нормативним вимогам.
Використання підтверджених FIPS шифрів є життєво важливим для підтримки високого рівня безпеки та чесність у спілкуванні. Він узгоджується з найкращими галузевими практиками та нормативними актами відповідність вимогам, забезпечення безпечних з’єднань SSH.
Немає функціонального впливу цього елемента керування; однак це значно покращує безпеку шляхом використання надійних, перевірених шифрів шифрування для SSH комунікацій.
Перегляньте ефективні параметри /etc/ssh/sshd_config і ESXi SSH для шифрів. Переконайтеся, що ввімкнено лише схвалені організацією перевірені алгоритми шифрування FIPS 140-2/140-3, які підтримуються ESXi 8.
Щоб виправити цю рекомендацію, налаштуйте демон SSH на використання лише затвердженого списку шифрів із підтримкою FIPS, який підтримується встановленою збіркою ESXi. Перевірте доступ від затверджених клієнтів адміністрування перед широким розгортанням.
📋 CIS Controls & Нормативні посилання
IG 1
6.5.2 Демон хосту SSH, якщо його ввімкнено, має використовувати підтверджені криптографічні модулі FIPS 140-2/140-3 (Вручну)
Якщо ввімкнено, демон SSH на хості має використовувати FIPS 140-2/140-3 підтверджені криптографічні модулі, надані OpenSSH. Хоча ці модулі є увімкнено за замовчуванням, їх можна дезактивувати для зворотної сумісності, таким чином, перевіряючи і забезпечення правильного налаштування має вирішальне значення для підтримки стандартів безпеки.
Використання підтверджених FIPS криптографічних модулів забезпечує дотримання визнаних стандартів безпеки, що важливо для захисту даних під час сеансів SSH. Це відповідає найкращим галузевим практикам і вимогам відповідності, сприяючи безпечному операційне середовище.
Немає функціонального впливу, пов’язаного з цим елементом керування. Це значно посилює безпеку шляхом забезпечення використання підтверджених криптографічних модулів, зведення до мінімуму ризики, пов’язані з комунікаціями SSH.
Переконайтеся, що ESXi працює з криптографічними модулями, що підтримуються Broadcom, і що SSH використовує надані платформою OpenSSH/криптобібліотеки. Перегляньте встановлені VIB і не приймайте двійкові файли SSH/крипто на заміну сторонніх виробників.
Щоб виправити цю рекомендацію, видаліть непідтримувані SSH/криптографічні двійкові файли та відновіть підписані компоненти ESXi із затвердженого образу/профілю. Підтримуйте виправлення ESXi, щоб підтверджені криптографічні модулі залишалися актуальними.
📋 CIS Controls & Нормативні посилання
IG 1
6.5.3 Демон хосту SSH, якщо ввімкнено, не має дозволяти використання портів шлюзу (Вручну)
Якщо ввімкнено, демон SSH на хості повинен мати функцію портів шлюзу вимкнено, щоб запобігти пересиланню з’єднань віддаленими хостами. Це загартовування заходи, щоб переконатися, що служба SSH безпечно налаштована проти потенційних пересилання зловживань.
Вимкнення портів шлюзу є профілактичним заходом, щоб уникнути несанкціонованого пересилання віддалені хости, таким чином підвищуючи безпеку системи. Це розумний крок мінімізація поверхні атаки, пов’язаної зі службою SSH.
Немає помічених функціональних впливів, пов’язаних із цим контролем. Це ініціатива захід безпеки, призначений для запобігання потенційному зловживанню переадресацією служб SSH можливості, не впливаючи на нормальну роботу хоста.
Перегляньте /etc/ssh/sshd_config і перевірте номер GatewayPorts.
Щоб виправити цю рекомендацію, установіть GatewayPorts no у підтримуваній конфігурації ESXi SSH. Перезапустіть SSH лише під час авторизованого технічного обслуговування/вікна адміністратора та перевірте ефективність налаштування.
📋 CIS Controls & Нормативні посилання
IG 1, 2
Page 196 Internal Only – General Controls Version Control IG 1 IG 2 IG 3 v7 9.2 Ensure Only Approved Ports, Protocols and Services Are Running Ensure that only network ports, protocols, and services listening on a system with validated business needs, are running on each system. ● ● v7 12.4 Deny Communication over Unauthorized Ports Deny communication over unauthorized TCP or UDP ports or application traffic to ensure that only authorized protocols are allowed to cross the network boundary in or out of the network at each of the organization’s network boundaries. ● ● ●
Page 197 Internal Only – General
6.5.4 Демон SSH хоста, якщо його ввімкнено, не повинен дозволяти автентифікацію на основі хоста (Вручну)
Важливо переконатися, що демон SSH на хості забороняє автентифікацію на основі хоста крок до зміцнення системних послуг. Це запобігає автентифікації хоста від імені користувачів, тим самим забезпечуючи індивідуальну відповідальність і мінімізуючи ризик несанкціонований доступ.
Заборона автентифікації на основі хоста забезпечує більш безпечну автентифікацію користувача механізм, що сприяє індивідуальній відповідальності. Це мінімізує ризик, пов’язаний з довірчі відносини між хостами, тим самим підвищуючи загальну безпеку системи.
Жодного функціонального впливу цей контроль не пов’язує. Він діє лише для підвищення безпеки за допомогою застосування суворішої практики автентифікації без перешкоджання роботі системи.
Перегляньте /etc/ssh/sshd_config і перевірте номер HostbasedAuthentication.
Щоб виправити цю рекомендацію, установіть HostbasedAuthentication no, перезапустіть SSH, якщо він авторизований для запуску, і переконайтеся, що автентифікація на основі хоста відхилена.
📋 CIS Controls & Нормативні посилання
IG 1, 2, 3
IG 1, 2, 3
Page 198 Internal Only – General
Page 199 Internal Only – General
6.5.5 Демон хосту SSH, якщо його ввімкнено, має встановлювати кількість часу очікування для неактивних сеансів (Вручну)
Встановлення підрахунку часу очікування для неактивних сеансів SSH гарантує, що неактивні сеанси є автоматично відключається через визначений період. Цей період розраховується за множення кількості тайм-ауту на інтервал тайм-ауту простою. Автоматичне відключення неактивні сеанси зменшують вікно можливостей для неавторизованого доступу.
Впровадження підрахунку часу очікування для неактивних сеансів сприяє кращій гігієні безпеки мінімізація впливу відкритих сеансів SSH. Це додає рівень захисту від потенційний неавторизований доступ через забуті або неконтрольовані сеанси.
Немає повідомлень про функціональний вплив цього елемента керування. Це профілактичний захід на підвищення рівня безпеки шляхом пом’якшення ризиків, пов’язаних із тривалим простоєм сесії.
Перегляньте /etc/ssh/sshd_config
- Переконайтеся, що для ClientAliveCountMax встановлено значення контрольного тесту/організації, щоб неактивні сеанси не могли залишатися нескінченно.
Щоб виправити цю рекомендацію, установіть ClientAliveCountMax на затверджене значення, потім перезапустіть SSH, якщо ввімкнено, і перевірте, чи неактивні сеанси закриваються після налаштованого інтервалу/лічильника. Сторінка 200 Тільки для внутрішнього використання – Загальні
📋 CIS Controls & Нормативні посилання
IG 1, 2, 3
IG 1, 2, 3
Page 201 Internal Only – General
6.5.6 Демон хосту SSH, якщо ввімкнено, має встановити інтервал очікування для неактивних сеансів (Вручну)
Реалізація інтервалу очікування для неактивних сеансів SSH гарантує, що будь-який неактивний сеанс відключається через певний період, покращуючи стан безпеки. Загальна сума Тривалість тайм-ауту обчислюється шляхом множення кількості тайм-аутів на тайм-аут простою інтервал.
Застосування інтервалу очікування для неактивних сеансів SSH мінімізує ризик несанкціонованого доступу доступ через забуті або неконтрольовані сесії, тим самим зміцнюючи систему послуги відповідно до найкращих практик безпеки.
Не повідомляється про функціональний вплив цього елемента керування. Захід є профілактичним, спрямованим на зменшити ризики, пов’язані з відкритими неактивними сеансами SSH.
Перегляньте /etc/ssh/sshd_config
- Переконайтеся, що для параметра ClientAliveInterval встановлено значення інтервалу неактивного сеансу, схваленого тестом/організацією.
Щоб виправити цю рекомендацію, установіть ClientAliveInterval на затверджену кількість секунд. Перезапустіть SSH, якщо ввімкнено, і перевірте поведінку тайм-ауту разом із ClientAliveCountMax. Сторінка 202 Лише для внутрішнього використання – Загальні
📋 CIS Controls & Нормативні посилання
IG 1, 2, 3
IG 1, 2, 3
Page 203 Internal Only – General
6.5.7 Демон хосту SSH, якщо ввімкнено, має відображати банер входу в систему перед наданням доступу (Вручну)
Реалізація банера входу в систему перед наданням доступу SSH гарантує, що це важливо інформація або сповіщення передаються користувачам, які намагаються увійти. Текст банера встановлено через розширений параметр Config.Etc.Issue хоста.
Відображення банера входу в систему допомагає надавати юридичні повідомлення або інші критичні повідомлення інформація для користувачів, гарантуючи, що вони проінформовані перед отриманням доступу, що є кроком для зміцнення та захисту системних послуг.
Немає повідомлень про функціональний вплив застосування цього контролю. Це в першу чергу служить для інформування користувачів або надання юридичних застережень, допомоги в юридичних і нормативних актах відповідність.
Перегляньте /etc/ssh/sshd_config на наявність директиви Banner і переконайтеся, що файл, на який посилається, містить затверджене попередження про використання системи/вхід.
Щоб виправити цю рекомендацію, налаштуйте затверджений файл банера SSH і директиву банера. Перезапустіть SSH, лише якщо ввімкнено/авторизовано, і підтвердьте, що банер з’являється перед автентифікацією.
📋 CIS Controls & Нормативні посилання
IG 1, 2, 3
Page 204 Internal Only – General Controls Version Control IG 1 IG 2 IG 3 v7 5.1 Establish Secure Configurations Maintain documented, standard security configuration standards for all authorized operating systems and software. ● ● ●
Page 205 Internal Only – General
6.5.8 Демон хосту SSH, якщо ввімкнено, має ігнорувати файли .rhosts (Вручну)
Ігнорування файлів .rhosts має вирішальне значення для посилення демона SSH на хості, гарантуючи, що довірчі відносини чітко визначені, а не неявно прийняті, тим самим зменшуючи поверхню атаки.
Ігнорування файлів .rhosts усуває потенційні ризики безпеці, пов’язані із застарілими або надмірними дозвільні довірчі відносини, що є кроком до більш жорстких і безпечних налаштування системної служби.
Немає повідомлень про функціональні наслідки, пов’язані з ігноруванням файлів .rhosts; однак, ця практика покращує рівень безпеки, зменшуючи ризики, пов’язані з несанкціонований доступ.
Перегляньте /etc/ssh/sshd_config і переконайтеся, що IgnoreRhosts так.
Щоб виправити цю рекомендацію, установіть для IgnoreRhosts так, перезапустіть SSH, якщо авторизовано, і переконайтеся, що довіра на основі .rhosts ігнорується.
📋 CIS Controls & Нормативні посилання
- https://developer.broadcom.com/xapis/esxcli-command-
- reference/latest/namespace/esxcli_system.html
- https://developer.broadcom.com/tools/esxcli/latest/
Page 206 Internal Only – General
IG 1, 2, 3
IG 1, 2, 3
Page 207 Internal Only – General
6.5.9 Демон хосту SSH, якщо ввімкнено, має вимкнути локальне пересилання потоку (Вручну)
Вимкнення локального пересилання потоку на демоні SSH гарантує відсутність домену Unix сокети пересилаються, таким чином забезпечуючи кордон безпеки. Цей захід сприяє збереження цілісності та конфіденційності системи.
Вимкнення локального пересилання потоку допомагає запобігти можливому зловживанню доменом Unix сокети, які можуть бути вектором для певних типів атак або витоку даних.
Немає повідомлень про функціональний вплив, що вказує на те, що локальне пересилання потоку вимкнено є безпечним заходом для підвищення безпеки системи без впливу на роботу.
Перегляньте /etc/ssh/sshd_config
- Перевірте номер AllowStreamLocalForwarding.
Щоб виправити цю рекомендацію, установіть AllowStreamLocalForwarding ні, перезапустіть SSH, якщо авторизовано, і переконайтеся, що локальне пересилання потоку не встановлено.
📋 CIS Controls & Нормативні посилання
IG 1, 2, 3
IG 1, 2, 3
Page 208 Internal Only – General
Page 209 Internal Only – General
6.5.10 Демон хосту SSH, якщо ввімкнено, має вимкнути переадресацію TCP (Вручну)
Вимкнення переадресації TCP у демоні SSH є заходом для запобігання потенційним несанкціоноване тунелювання та пересилання, які можуть призвести до витоку даних або несанкціонований доступ до даних. Цей захід додає рівень безпеки до служби SSH коли ввімкнено, система стає більш стійкою до певних типів мереж напади.
Запобігання переадресації TCP допомагає гарантувати, що демон SSH не використовується з метою несанкціоноване проходження тунелів. Цей захід допомагає підтримувати більш безпечний і контрольоване мережеве середовище.
Не повідомлялося про функціональний вплив. Це вказує на те, що вимкнення переадресації TCP є запобіжний захід, що не перешкоджає нормальній роботі хоста.
Перегляньте /etc/ssh/sshd_config
- Перевірте AllowTcpForwarding ні, якщо цього не вимагає схвалений адміністративний варіант використання.
Щоб виправити цю рекомендацію, установіть AllowTcpForwarding ні, перезапустіть SSH, якщо авторизовано, і перевірте, чи пересилання TCP заблоковано. Задокументуйте всі затверджені винятки.
📋 CIS Controls & Нормативні посилання
- https://developer.broadcom.com/xapis/esxcli-command-
- reference/latest/namespace/esxcli_system.html
- https://developer.broadcom.com/tools/esxcli/latest/
Page 210 Internal Only – General
IG 1, 2, 3
IG 1, 2, 3
Page 211 Internal Only – General
6.5.11 Демон хосту SSH, якщо ввімкнено, не повинен дозволяти тунелі (Вручну)
Запобігання створенню тунелів у демоні SSH є заходом безпеки, спрямованим на перешкоду несанкціоноване мережеве тунелювання через хост. Цей контроль, коли його застосовують, допомагає зменшити ризики, пов’язані з можливим викраденням даних або неавторизованою мережею доступ, який може відбуватися через тунелі SSH.
Заборонивши створення тунелів, організації можуть переконатися, що демон SSH не є використовувати для несанкціонованого тунелювання, таким чином сприяючи більшій безпеці положення мережі.
Немає повідомлень про функціональний вплив, пов’язаний із цим контролем безпеки, що вказує що запобігання тунелювання SSH не впливає негативно на нормальний хост оперативна поведінка.
Перегляньте /etc/ssh/sshd_config і перевірте номер PermitTunnel.
Щоб виправити цю рекомендацію, установіть PermitTunnel no, перезапустіть SSH, якщо авторизовано, і переконайтеся, що пристрої SSH-тунелю неможливо створити.
📋 CIS Controls & Нормативні посилання
- https://developer.broadcom.com/xapis/esxcli-command-
- reference/latest/namespace/esxcli_system.html
- https://developer.broadcom.com/tools/esxcli/latest/
Page 212 Internal Only – General
IG 1, 2, 3
IG 1, 2, 3
Page 213 Internal Only – General
6.5.12 Демон хосту SSH, якщо ввімкнено, не повинен дозволяти налаштування середовища користувача (Вручну)
Запобігання налаштувань середовища користувача в демоні SSH забезпечує послідовність і контрольоване середовище, зменшуючи поверхню атаки за рахунок обмеження налаштування користувачами середовища SSH.
Заборона налаштувань середовища користувача в демоні SSH зменшує потенціал для зловмисна або ненавмисна неправильна конфігурація, таким чином підвищуючи рівень безпеки.
Немає жодного функціонального впливу, що вказує на обмеження налаштувань середовища користувача не впливає негативно на робочі аспекти хоста.
Перегляньте /etc/ssh/sshd_config і перевірте номер PermitUserEnvironment.
Щоб виправити цю рекомендацію, установіть PermitUserEnvironment no, перезапустіть SSH, якщо авторизовано, і переконайтеся, що користувачі не можуть змінювати середовище SSH за допомогою налаштувань середовища для кожного користувача.
📋 CIS Controls & Нормативні посилання
- https://developer.broadcom.com/xapis/esxcli-command-
- reference/latest/namespace/esxcli_system.html
IG 1, 2, 3
Page 214 Internal Only – General Controls Version Control IG 1 IG 2 IG 3 v7 5.1 Establish Secure Configurations Maintain documented, standard security configuration standards for all authorized operating systems and software. ● ● ●
Page 215 Internal Only – General 7 Virtual Machine This section contains recommendations for settings related to guest virtual machines.
Page 216 Internal Only – General
Потрібні інші розділи стандарту?
Перегляньте повний інтерактивний перелік усіх рекомендацій у головному хабі стандарту.
