Автоматизированное «ням-обновление» для обеспечения безопасности сервера - плюсы и минусы?

8

Я рассматриваю возможность добавления cronjob, работающего yum -qy updateрегулярно на некоторых машинах, которые не получают регулярного обслуживания. Цель состоит в том, чтобы поддерживать машины в актуальном состоянии в отношении исправлений безопасности, которые в противном случае были бы применены слишком поздно. Я использую только базовые репозитории CentOS.

Вопросов:

  • По вашему опыту - насколько «безопасным» будет этот подход? Стоит ли ожидать сбой обновлений время от времени? Примерно как часто этот подход потребует перезагрузок?
  • Плюсы / минусы или другие недостатки с таким подходом?
  • Как вы обновляете свои машины с помощью автоматизации?
knorv
источник
2
заменить yum -qy на: / usr / bin / yum -R 120 -e 0 -d 0 -y обновить yum И / / usr / bin / yum -R 10 -e 0 -d 0 -y обновить
Адам Бенаюн,
Адам: Спасибо за ваше предложение. Не могли бы вы объяснить, почему это лучше?
knorv
1
Сначала вы обновляете yum, а затем обновляете пакеты, -R означает, что он дает максимальное время ожидания команды, то есть он не истечет, если я прав. -e и -d - просто уровень ошибок / отладки
Адам Бенаюн
Я не уверен, что "-R [время в минутах]" - "устанавливает максимальное количество времени, которое yum будет ждать перед выполнением команды - оно рандомизируется с течением времени". Кажется, что yum будет ждать rand () * минут, прежде чем подать команду? Это хорошо? :-)
knorv

Ответы:

6

Это зависит

По моему опыту с CentOS это довольно безопасно, так как вы используете только базовые репозитории CentOS.

Если вы ожидаете сбой обновлений время от времени ... да ... на том же уровне, на котором вы должны ожидать сбой жесткого диска или сбой процессора время от времени. Вы никогда не можете иметь слишком много резервных копий. :-)

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

Ручные исправления всегда кажутся оттесненными или расцениваются как «низкий приоритет» во многих других вещах, поэтому, если вы собираетесь использовать ручной режим «РАСПИСАНИЕ ВРЕМЕНИ НА КАЛЕНДАРЬЕ», чтобы сделать это.

Я настроил много машин для автоматического обновления yum (с помощью cron) и редко сталкивался с проблемой. На самом деле, я не помню, чтобы когда-либо возникали проблемы с репозиториями BASE. Каждая проблема, о которой я могу подумать (вне моей головы, по моему опыту), всегда была сторонней ситуацией.

Это, как говорится ... У меня есть несколько машин, для которых я вручную делаю обновления. Такие вещи, как серверы баз данных и другие ЧРЕЗВЫЧАЙНО критичные системы, мне нравится иметь практический подход.

То, как я лично понял это, было так ... Я думаю о сценарии «что если», а затем пытаюсь подумать, сколько времени потребуется, чтобы восстановить или восстановить из резервной копии и что (если что-нибудь) будет потеряно ,

В случае нескольких веб-серверов ... или серверов, содержимое которых не сильно меняется ... Я продолжаю и делаю автообновление, потому что количество времени на восстановление / восстановление минимально.

В случае критически важных серверов баз данных и т. Д. Я планирую время один раз в неделю, чтобы просматривать их и вручную исправлять их ... потому что время, необходимое для восстановления / восстановления, занимает больше времени.

В зависимости от того, какие серверы У вас есть в вашей сети и как реализован ваш план резервного копирования / восстановления, ваши решения могут отличаться.

Надеюсь это поможет.

KPWINC
источник
6

Pro : Ваш сервер всегда на последнем уровне исправлений, обычно даже против 0-дневных эксплойтов.

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

Рекомендация: сервер должен отправить вам электронное письмо, когда его нужно обновить. Резервное копирование или знать, как откатить обновления.

Карл Кацке
источник
+1 - я настоятельно рекомендую подписаться на список рассылки centos, они отлично справляются с уведомлением о патчах и приоритетах перед отправкой в ​​репозитории.
Адам Бенаюн
3
По определению нет исправлений против 0-дневных эксплойтов. 0-дневный эксплойт - это тот, для которого еще нет патча.
MarkR
Я считаю, что 0 дней - это день, когда он обнаружен / эксплуатируется / объявлен, и Redhat обычно исправляет серьезные уязвимости в течение нескольких часов, что, по совпадению, остается днем, когда он был обнаружен.
Карл Кацке
2

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

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

До сих пор все работает без сбоев (уже более 4 лет), единственный раз, когда меня поймали врасплох, это когда yum обновил обычное ядро ​​(я виртуализировал свой сервер), изменил grub и выдвинул обычное ядро ​​как стандартное, 2 недели позже во время обслуживания моя система была перезагружена, и все мои виртуальные серверы были отключены на несколько минут, пока мне не пришлось вмешиваться вручную.

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

Адам Бенаюн
источник
1

если у вас нет пользовательских пакетов и вы используете только базовые репозитории от CentOS, это должно быть достаточно безопасно.

Кроме того, лучший способ добиться этого - использовать yum-updatesd с do_update = yesset.

DLU
источник
1
Служба yum-updatesd недостаточно развита для корпоративной среды, и служба может вносить ненужные накладные расходы. Я бы использовал: / usr / bin / yum -R 120 -e 0 -d 0 -y обновление yum И / usr / bin / yum -R 10 -e 0 -d 0 -y обновление
Адам Бенаюн
0

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

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

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

Мои серверы не твои, хотя :-)

Барт Сильверстрим
источник