Если сервер хоста виртуальной машины Linux не имеет выхода в Интернет, используется исключительно в локальной сети и использует относительно хорошо протестированный дистрибутив, такой как Proxmox, насколько опасно будет отключать все средства устранения уязвимостей с помощью аргумента ядра mitigations=off?
Кроме того, проверял ли кто-нибудь, какой прирост производительности можно получить, отключив все подобные меры?
Недавно у меня возник этот вопрос, когда я увидел такой большой успех, который retbleedсоздают меры по смягчению последствий:https://www.phoronix.com/review/retbleed-benchmark
Эта линия мысли распространилась на любопытство относительно того, каковы могут быть последствия — как негативные, так и позитивные — удаления всех или некоторых смягчающих мер либо посредством приведенного выше аргумента ядра, либо путем индивидуального отключения смягчающих мер с высоким уровнем воздействия.
решение1
Флаг ядра Linux mitigations=[on|off]— это единый переключатель, позволяющий легко включать/отключать все доступные средства защиты ядра от уязвимостей оборудования, перечисленные здесь.https://docs.kernel.org/admin-guide/hw-vuln/index.html
Влияние этого, конечно, полностью зависит от вашего процессора:
Если ваш процессор не подвержен ни одной из известных уязвимостей, то ни одно из мер по смягчению последствий не применимо, и воздействие фактически должно быть нулевым.
Когда ваш процессор уязвим к некоторым (есть ли вообще процессоры, уязвимые квсеиз них?) влияние зависит от конкретных уязвимостей и вашей рабочей нагрузки.
Что касается анализа рисков, то он также зависит от вашей рабочей нагрузки и пользовательской базы.
На хосте виртуализации, которым управляет провайдер общедоступных VPS, гостям доверяют меньше, и вероятность того, что они окажутся вредоносными (или будут скомпрометированы), гораздо выше, чем я ожидал бы на внутреннем хосте виртуализации, который используется исключительно моими коллегами.
Например, на наших хостах виртуализации, используемых для конвейеров CI/CD и вычислительных кластеров, все гости недолговечны, развертываются из доверенных образов, работают до пары часов, а затем снова уничтожаются. Там нам нужна вся возможная производительность и отключение смягчений.
На другом общем кластере мы размещаем более классические рабочие нагрузки консолидации серверов; гостевые системы, которые там развертываются, могут (и с большей вероятностью будут) работать «вечно», а не часами. Он имеет смесь производственных и непроизводственных рабочих нагрузок, а гостевые системы управляются командами DevOps, которые не все так усердны в исправлении и обновлении своих систем и приложений.
Там риск вредоносного или скомпрометированного гостя намного выше, возможное снижение производительности для определенных рабочих нагрузок является приемлемым компромиссом, и поэтому там включаются смягчения, и мы ограничиваем, какие флаги ЦП будут открыты для гостей.
решение2
неужели к серверу действительно невозможно подключиться даже косвенно из-за пределов вашей сети?
Это первый вопрос, который вы должны себе задать. Если к локальной сети можно получить доступ с машины, которая имеет 2 сетевых подключения, одно к этой локальной сети, а другое к другой сети, которая подключена к Интернету (надеюсь, через несколько уровней брандмауэров), вы только что подключили этот сервер к Интернету.
И помните, что компьютеру не обязательно быть подключенным к Интернету, чтобы быть уязвимым для атак. Компьютер может быть заражен вредоносным ПО, которое просто намерено нанести ему вред через USB-флешку, дискету или даже вводя команды на терминале.
В конце концов, вся безопасность, как и все улучшения производительности, является компромиссом. Каков приемлемый уровень риска для получаемых вознаграждений.
Чтобы узнать потенциальный прирост производительности, запустите тесты на машине, когда у нее вообще нет сетевых подключений, и убедитесь сами. Скорее всего, это будет не очень много, но этого может быть достаточно, чтобы выжать те несколько дополнительных циклов ЦП, которые помогают старому оборудованию продержаться еще немного, пока у вас есть время убедить высшее руководство, что вам действительно, действительно следует получить бюджет на новый сервер.
решение3
«... используется исключительно в локальной сети и использует относительно хорошо протестированный дистрибутив, такой как Proxmox, насколько опасно будет отключить все средства защиты от уязвимостей с помощью аргумента ядра mitigations=off?»
...
«Эта линия мысли распространилась на любопытство относительно того, какими могут быть последствия — как негативные, так и позитивные — удаления всех или некоторых средств защиты либо с помощью приведенного выше аргумента ядра, либо путем индивидуального отключения средств защиты с высоким уровнем воздействия».
Вам все равно следует учитывать ответственность и увеличение времени на устранение даже небольшого количества проблем.
Тем не менее, большинство мер по снижению рисков уже встроены в новейшие процессоры, поэтому их отключение не принесет вам практически никакой потери производительности на новых системах — да, обычно система работает медленнее с отключенными мерами снижения рисков, но, как и в любом бенчмарке, есть исключения.
«... какой прирост производительности можно получить, отключив все подобные меры?»
Майкл Ларабель из Phoronix говорит:
В своей статье от 7 декабря 2022 года:«Сравнение производительности по смягчению последствий Intel Raptor Lake»:
«... по большей части программные меры по смягчению последствий, которые по-прежнему актуальны для Raptor Lake, можно оставить без каких-либо существенных изменений в производительности».
В своей статье от 30 сентября 2022 года:«С AMD Zen 4, как ни странно, не стоит отключать меры безопасности ЦП»:
«... для широкого диапазона из 190 различных проведенных тестов сохранение смягчения по умолчанию было примерно на 3% быстрее в целом, чем работа с выключенными смягчениями. По сути, это противоположно тому, что мы обычно видим с другими, более старыми процессорами».
В старых системах вам все равно нужно учитывать, что недовольные сотрудники могут повысить свои привилегии или иным образом повредить вашу локальную сеть перед уходом. Часть их недовольства может быть вызвана устаревшим оборудованием, которое они используют против вас. Кроме того, привязанный мобильный телефон нарушит презумпцию «не подключенного к Интернету», зарядка телефона и запуск мошеннического приложения или открытие тщательно созданного электронного письма могут использовать только имеющиеся уязвимости.