Re: Atualizações do debian!
Em 31/01/07, Felipe Augusto van de Wiel
(faw)<felipe@cathedrallabs.org> escreveu:
On 01/31/2007 08:31 PM, Marcos Lazarini wrote:
> Em 31/01/07, Felipe Augusto van de Wiel
> (faw)<felipe@cathedrallabs.org> escreveu:
>> > E quando ele pergunta "deseja usar a versão do mantendor ou a versão
>> > atual?" O que acontece?
>>
>> Em atualizações de segurança isso não deveria acontecer. :-)
>
> Bom, comigo aconteceu :-D
> Mudamos o clamav aqui para não executar todo dia e sim apenas em
> alguns dias, e agora na ultima atualização em janeiro (nao me lembro
> quando), me foi perguntado se deveria ou não sobrescrever o arquivo
> cron que tinhamos modificado.
Você provavelmente modificou um conffile e o pacote não
lidou bem com isso.
> Isso é/foi um bug?
Depende do ponto de vista e do repositório que você
estava usando, eu uso clamav nos servidores que cuido e as
mudanças que fazemos procuram não tocar os arquivos dos
pacotes, os dist-upgrades não quebram e eles rodam de hora
em hora. ;)
Espero que vc não esteja insinuando que não devo mexer nos arquivos de
configuração!
Vou dar outro exemplo: eu tenho um roteador desprovido de capacidade
de processamento (um 486). Porém notei que de tempos em tempos a
máquina ficava lerda por alguns segundos (30~40s) e depois voltava.
Descobri que ela tinha vários serviços cron que ligavam a cada 5 min
ou 10 min, todos um por cima do outro (mrtg, logcheck, o do sar, são
os que me lembro agora). Entrei lá e mudei p/ cada um começar num
minuto diferente e agora a máquina está mais 'suave'. Não ia achar nem
um pouco legal perder essa configuração a cada atualização de
segurança...
Então p/ mim, perder isso seria um bug - quero que ele pergunte; agora
p/ uma pessoa que queria automatizar a atualização e ele parar
peguntar, isso vai ser bug p/ ele tbm! conflito de interesses...
(ainda comentando sobre o cron: outra coisa que fiz foi mudar o
horário padrão dos cron.{daily|weekly|monthly}, pois são todos 6 e
pouco por padrão. Alguns programas, como o locate, logcheck (p/ citar
dois), demoram um certo tempo, e ai o cron de um período encavalava no
outro, a maquina usava swap, etc e tal)
>> > Eu acho que ele para e fica esperando uma resposta....
>>
>> Você pode programar pra ele dizer "sim".
>
> Eu ia preferir não! :-)
Então eu acho que você não cuida de servidores críticos.
É melhor ter o serviço seguro por default do que sua configuração
querida. :-)
Certamente a configuração padrão funciona, mas ela pode não ser
adequada - veja situação que descrevi acima. Se procurar um pouco,
certamente vão existir casos em que não é nem um pouco interessante a
substituição do arquivo de configuração (o que me vem a cabeça agora é
o 915resolution - ele só funciona depois q vc o configura)
Mas eu parto do pressuposto de que se vc mexe no arq. de configuração
sabe o que está fazendo, e assume a responsabilidade - não acho que o
mantenedor do pacote deva ditar qual deve ser minha preferência sobre
o aplicativo que ele mantém.
> De qquer maneira, queria saber qual a diferença, e depois do pacote
> instalado, dá bem mais trabalho saber...
debdiff, aide, fcheck e controle de versão serve exatamente
pra isso. :-)
Essas coisas oferecem rollback? :-)
Agora não tenho noticia de um gerenciador de pacotes que use controle
de versão nos arquivos q ele instala
Pelo menos já é um começo...
>> > Por isso não é interessante que seja tudo automático. o apt-cron faz
>> > tudo o que pode ser automatizado sem problema. Resta a vc fazer um
>> > 'aptitude upgrade' quando ele mandar um e-mail avisando e acompanhar o
>> > processo... só isso.
>>
>> Quando no "stable", é possível automatizar os dist-upgrades,
>> mesmo sem o cron-apt. Você só recebe o listchanges quando o upgrade
>> acontece.
>
> Sim, é que o apt-cron manda um e-mail avisando do update e com a lista
> de pacotes a ser atualizados p/ o root. Ele, de quebra, já baixa esses
> pacotes de madrugada e ai vc nem precisa esperar baixar tudo quando
> for instalar.
Sim, com certeza, mas entre você ler o seu e-mail e fazer a
atualização, o tempo pode ser crucial para que um ataque aconteça.
Certamente - mas se a janela for de 1 h ou 1 dia, a meu ver não faz
muuita diferença: vc foi exposto da mesma maneira e pode ter sido alvo
da mesma forma. Por isso, são necessários outros métodos (como os IDS
q vc citou acima) p/ cercar por outros caminhos eventuais explorações
de vulnerabilidades. Estou pensando nas relacionadas a escalada de
privilégios; se o prob. é um DoS, ai é potencialmente mais tranquilo.
Sem contar que numa intranet, o ambiente supostamente tem uma relação
de confiança maior do que com outro micro da internet. Agora, em
servidores o assunto é bem diferente.
> Se fosse 100% seguro automatizar assim as atualizações, eu aposto que
> certamente já viria ligado por default, ou então seria mto fácil ligar
> isso. Prefiro a moda antiga ainda :-)
É 100% seguro (com security stable). Tanto que muita gente usa.
;)
A pergunta que não quer calar é: pq não é ao contrário então? já não
vem ligado e desliga se vc não quiser?
Em ultimo caso, eu faria todas as máquinas automáticas, mas a minha
eu ia atualizar na mão p/ acompanhar o processo e ver se correu tudo
bem nas outras - eventualmente pode ser necessário um procedimento de
correção.
Vez por outra pode gerar uma surpresas (hey! Isso é software,
bugs acontecem) mas ainda assim garante que as atualizações de segurança
sejam instaladas no menor tempo possível.
--
Marcos
Reply to: