Quão urgente é necessária uma reinicialização do sistema *** por segurança?


56

Para aprender um pouco sobre administração de servidores, configurei um servidor Ubuntu 14.04 simples no qual administro um site pessoal. Eu o configurei para instalar automaticamente as atualizações de segurança, mas deixe de fora as outras atualizações. Isso parece funcionar muito bem. Ocasionalmente, recebo uma mensagem ao entrar no servidor (com ssh) dizendo:

*** System restart required ***

Nas vezes em que isso aconteceu, reiniciei o Ubuntu e tudo estava bem. Tudo bem, porque é um site pessoal simples. No entanto, o que me pergunto é como isso funciona para servidores da Web, que devem estar acima de 99.9999etc% do tempo? Eles simplesmente não reiniciam e correm o risco de a segurança ser violada porque as atualizações de segurança não estão instaladas (o que eu não consigo imaginar)? Ou eles tomam o tempo de inatividade como garantido (o que também não consigo imaginar)?

Como devo lidar com isso se esse era um servidor de produção muito importante que eu quero manter em funcionamento? Todas as dicas são bem-vindas!

[EDIT] Eu sei que posso fazer cat /var/run/reboot-required.pkgspara listar os pacotes que causam a reinicialização. O comando atualmente produz o seguinte:

linux-image-3.13.0-36-generic
linux-base
dbus
linux-image-extra-3.13.0-36-generic
linux-base

mas como sei se as atualizações são pequenas coisas sobre se tenho uma vulnerabilidade de segurança séria se não faço a reinicialização?

[EDIT2] Ok, agora eu combinei os comandos que achei úteis em um:

xargs aptitude changelog < /var/run/reboot-required.pkgs | grep urgency=high

Se isso não produzir nada, não parece haver problemas de segurança com alta urgência.

Uma última pergunta: são low, mediume highas únicas possibilidades de urgência, ou existem mais como por exemplo criticalou extremelyimportant?


Eu não entendo a pergunta. Sites com tráfego maior simplesmente agendam esse tempo de inatividade por um período com menos tráfego. A urgência depende do que está sendo atualizado exatamente.
Ramhound 23/09/19

14
Eu me pergunto quantas pessoas vieram aqui porque viram a questão na lista "Network Hot perguntas" e se perguntou o que os palavrões foram ... * levanta a mão *
David Richerby

6
@ Ramhound: Ehm, não, eles alternam de forma transparente para um servidor secundário durante a manutenção.
Lightness Races com Monica

11
Re: Última pergunta: Estou pensando em filtrar baixa e média e considerar urgentes todos os outros níveis / desconhecidos: | grep 'urgency=' | egrep -v '=(low|medium)'
KajMagnus 15/05

Respostas:


45

A resposta não é simples, pois depende das atualizações feitas. Se o kernel teve um sério problema de segurança, é bom reiniciar o mais rápido possível. Se o kernel tiver apenas pequenas correções, o reinício poderá ser adiado.

Se você garantir uma disponibilidade> 99,9%, quase sempre terá um sistema em cluster no qual poderá reiniciar os nós um por um sem interromper o serviço.

Portanto, você reinicializa o primeiro sistema e o anexa novamente ao cluster. Depois o segundo e assim por diante. Em seguida, o serviço nunca ficará indisponível.


2
Obrigado pela sua resposta. Adicionei um pequeno pedaço à minha pergunta inicial; Eu sei que posso fazer cat /var/run/reboot-required.pkgspara obter os pacotes que exigem a reinicialização. Mas como sei se essas são apenas pequenas correções ou se é uma grave vulnerabilidade de segurança?
precisa saber é o seguinte

2
@ kramer65 cada pacote possui um changelog. Por exemplo, o changlog do kernel pode ser encontrado aqui .
Uwe Plonus 23/09

2
Tudo bem, então cabe ao administrador de sistemas (ou seja: neste caso eu mesmo) determinar se essas alterações são importantes? Eu tenho muito pouco conhecimento para determinar isso no kernel do Linux, e muito menos em todo o zilhão de outros pacotes. Não existe um local central onde eu possa determinar se a atualização é absolutamente necessária para segurança?
precisa saber é o seguinte

8
@ kramer65 Run aptitude changelog <package>, aqui está um exemplo de saída: paste.ubuntu.com/8410798 (Este é em um sistema Debian, Ubuntu não, mas o mesmo trabalho vontade no Ubuntu também.)
nyuszika7h

5
Obrigado por toda a ajuda aqui. Finalmente, combinei todas as coisas que aprendi aqui em um comando: xargs aptitude changelog < /var/run/reboot-required.pkgs | grep urgency=high(adicionei também à pergunta inicial), o que fornece uma saída sobre quais pacotes têm patches altamente urgentes. Depois disso, é claro que pacotes individuais podem ser inspecionados. Um milhão de agradecimentos por todas as respostas e idéias!
precisa saber é o seguinte

3

addon para a solução de tópicos

Realizo verificação semelhante para o 'requisito de reinicialização' do sistema de monitoramento zabbix

Vejo 2 problemas na solução 'Tópico':

  1. O aptitude geralmente funciona mal em scripts. Eu mato algumas horas, mas ainda não o fiz funcionar com o zabbix
  2. se apenas 1 registro de alterações incluir atualização urgente - sua verificação sempre mostrará resultados positivos

Minha lógica é:

  1. Verifique a última alteração apenas no changelog para cada pacote que requer reinicialização do sistema
  2. Como uma saída, mostre apenas a atualização de prioridade mais alta

Usando a documentação da Debian, encontrei 5 valores possíveis para 'urgency' e também o fato de que ele pode ser seguido por caracteres iguais ("=") ou ponto-e-vírgula (":"). Também pode haver caracteres maiúsculos e minúsculos

Então acabei com o seguinte:

#!/bin/bash
##################################
# Zabbix monitoring script
#
# Checking urgency in changelog 
# for updates which require system restart
#
##################################
# Contact:
#  anton.lugovoi@yandex.ru
##################################
# ChangeLog:
#  20151205    initial creation
#  20151208    check uniq packages only 
##################################

case "$1" in

status)
    if [ -f /var/run/reboot-required ]; then
      echo 1
    else
      echo 0
    fi 
    ;;

urgency)
    if [ -f /var/run/reboot-required.pkgs ]; then
      while read pkg; do
        tmp=`/usr/bin/apt-get changelog $pkg | \
             /bin/grep -m1 -ioP '(?<=[Uu]rgency[=:])(low|medium|high|emergency|critical)' | \
             tr '[:upper:]' '[:lower:]'`
        if [ -n $tmp ]; then
          if   [ "$tmp" == "low" ] && \
               [ "$urgency" != "medium" ] && \
               [ "$urgency" != "high" ] && \
               [ "$urgency" != "emergency" ] && \
               [ "$urgency" != "critical" ]; then 
            urgency=low
          elif [ "$tmp" == "medium" ] && \
               [ "$urgency" != "high" ] && \
               [ "$urgency" != "emergency" ] && \
               [ "$urgency" != "critical" ]; then 
            urgency=medium
          elif [ "$tmp" == "high" ] && \
               [ "$urgency" != "emergency" ] && \
               [ "$urgency" != "critical" ]; then 
            urgency=high
          elif [ "$tmp" == "emergency" ] && \
               [ "$urgency" != "critical" ]; then 
            urgency=emergency
          elif [ "$tmp" == "critical" ]; then 
            urgency=critical
            break
          fi
        fi 
      done < <(sort -u /run/reboot-required.pkgs)
    else
      urgency=none
    fi

    case "$urgency" in
        none)      urgency=0 ;;
        low)       urgency=1 ;;
        medium)    urgency=2 ;;
        high)      urgency=3 ;;
        emergency) urgency=4 ;;
        critical)  urgency=5 ;;
        *)         urgency=42 ;;
    esac

    echo $urgency
    ;;
esac
exit 0

Como um resultado:

  • reboot_required_check.sh status retorna 1 se a reinicialização for necessária, 0 se não for
  • reboot_required_check.sh urgency retorna o nível mais alto de 'urgência' ou '0' se a reinicialização não for necessária

Espero que ajude alguém a economizar um tempo;)


0

No entanto, o que me pergunto é como isso funciona para servidores da Web, que devem estar acima de 99.9999etc% do tempo? Eles simplesmente não reiniciam e correm o risco de a segurança ser violada porque as atualizações de segurança não estão instaladas (o que eu não consigo imaginar)? Ou eles tomam o tempo de inatividade como garantido (o que também não consigo imaginar)?

Grandes servidores web são reiniciados quando * Reinicialização do sistema necessária * aparece por motivos de segurança.

Mas isso é transparente para o usuário e o site nunca fica inativo porque os servidores grandes geralmente executam dois ou três servidores que armazenam exatamente os mesmos arquivos e exibem o mesmo site. O primeiro é o servidor principal, enquanto os outros dois são secundários e são usados ​​apenas quando o servidor principal está inativo.


11
Embora isso esteja teoricamente correto, Big web serversexecute versões personalizadas do Linux. Eles não verão um System restart requireddiálogo, atualizam o que precisam para permanecer seguros. Na maioria dos casos, muitas atualizações, senão todas, podem ser feitas enquanto o sistema está em execução (acredito que seja possível atualizar um kernel Linux em um sistema em execução sem reinicialização).
Joeey

Interessante. Eu tenho um servidor na Amazon e geralmente o reinicio por causa dessa mensagem ... Estou executando o Ubuntu no meu servidor. Como personalizá-lo para que eu não precise reiniciá-lo de vez em quando?
rom

Não tenho nenhuma experiência com servidores da Amazon. Big web serverssão executados em servidores dedicados e VPS. Por esse motivo, o administrador do sistema tem mais controle sobre o software. A Amazon fornece acesso ao shell raiz do seu servidor?
Joeey

Sim, é possível ter acesso root.
rom

Atualizar os pacotes manualmente, reiniciar os serviços afetados e usar algo como o Ksplice para as atualizações do kernel seria uma maneira. Vale ressaltar que o Ksplice freezes execution of a computer so it is the only program runningao aplicar um patch, ainda pode haver um pouco de tempo de inatividade (devido ao processo do servidor da Web estar 'congelado'). Isto é onde a resposta por @Uwe Plonus entra.
joeeey
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.